headers
Masataka Ohta | 1 Sep 2009 01:49
Picon

Re: [dnsext] Working around proxies

Mark Andrews wrote:

>>which is a lot more difficult than just
>>
>>	support IPv6
>>
>>even which is not happening.

> Except it is.  It's cruch time and residential ISP are now reacting.

Well...

According to some people, yes, IPv6 deployment has been happening
for these 15 years.

So?

> There are commisioning CPE product development, now, to allow them
> to support both IPv4 (NAT'd) and IPv6 into the future.

It's easy to develop products.

However, there is hardly any incentive for ISPs to replace all
the CPEs, which costs a lot.

Anyway, if we can instruct NAT vendors to follow our guideline
on DNS relaying behavior, we can let them implement plain old
DNS securely that there is no point to have DNSSEC, which is
merely weakly secure.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Andrews | 1 Sep 2009 02:14

Re: [dnsext] Working around proxies


In message <4A9C616C.3090408 <at> necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Mark Andrews wrote:
> 
> >>which is a lot more difficult than just
> >>
> >>	support IPv6
> >>
> >>even which is not happening.
> 
> > Except it is.  It's cruch time and residential ISP are now reacting.
> 
> Well...
> 
> According to some people, yes, IPv6 deployment has been happening
> for these 15 years.
> 
> So?
> 
> > There are commisioning CPE product development, now, to allow them
> > to support both IPv4 (NAT'd) and IPv6 into the future.
> 
> It's easy to develop products.
> 
> However, there is hardly any incentive for ISPs to replace all
> the CPEs, which costs a lot.
> 
> Anyway, if we can instruct NAT vendors to follow our guideline
> on DNS relaying behavior, we can let them implement plain old
> DNS securely that there is no point to have DNSSEC, which is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Andrews | 1 Sep 2009 02:55

Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC


In message <20090831182103.GQ13987 <at> shinkuro.com>, Andrew Sullivan writes:
> On Sat, Aug 29, 2009 at 08:07:03AM +1000, Mark Andrews wrote:
> > > I note that adding a new RR is even easier now: we do it with expert
> > > review.  Are you arguing for that route instead of RFC required?
> > 
> > 	No.  You were complaining about the lack of interop testing
> > 	due to there being no code point.
> 
> If I left that impression, I apologise.  That wasn't what I was
> complaining about.  I was complaining that even uncontroversial code
> point additions, like SHA 256, take a very long time because the
> entire IETF WG consensus machinery comes into play.  We need a lot of
> review, there's a tendency for side issues to get explored, and so on.
> 
> If we had a lighter weight procedure, it wouldn't be so costly and it
> might therefore happen faster.

SHA256 was special because we had to teach the working group that
new signature algorithms need to support both NSEC and NSEC3.  SHA256
should not be seen as representative of the time it will take in
future.

DNSEXT goes from one extreme to the other.  RR allocation was a
example of that.  New procedures were defined and people complained
that RR's take too long without even trying the new procedures.

I don't think we need new procedures for DNSSEC algorithm assignments.
Nobody has really demonstrated that there is a problem with the
current procedure.  DNSSEC is too new operationaly to have any
(Continue reading)

Permalink | Reply | 7 comments |
headers
Patrik Fältström | 1 Sep 2009 07:21
Picon
Favicon

Re: [dnsext] EDNS0 fallback "revisited"

On 25 aug 2009, at 21.31, Nicholas Weaver wrote:

> Fragmentation is NOT a problem for ~85% +/- some delta of  
> resolvers.  Which means, for MOST resolvers, its OK if the response  
> fragments.  So let the responses be large, we have these large  
> DNSSEC responses anyway, so go for it.
>
>
> But fragmentation IS a problem for ~15%.

It is a bit more complicated than this. It might be ok with  
fragmentation, as long as the fragments arrive in order. This implies  
it even might work _sometimes_.

> This is probably too large a number for education strategies to  
> work, since that requires upgrading/replacing existing middleboxes.

Well, the 85% number is high enough so that we can say "this is how it  
should be"...but in general I agree with you.

> And too large a number for any strategy which requires timeouts per  
> authority before deciding its a problem, which will kill performance  
> and cause "DNSSEC is broken" complaints once .com starts signing data.

The question is who the complaint is going to. Some DNSSEC problems  
will target the large ISPs that run the large resolvers. They will  
detect people with broken signed zones -- but they will most certainly  
_not_ have the fragmentation issues (or they have serious problems  
anyway). The complaints on fragmentation will hit the smaller  
resolvers that sit behind firewalls that do the wrong thing. I presume
(Continue reading)

Permalink | Reply | 6 comments |
headers
Alex Bligh | 1 Sep 2009 07:55
Picon

Re: [dnsext] Working around proxies


--On 1 September 2009 08:51:27 +1000 Mark Andrews <marka <at> isc.org> wrote:

> You can still work through them.
>
> Fallback to TCP is not a open question for these boxes.  Even if
> you read RFC 3226 as disallowing advertising EDNS <at> 512, EDNS at sizes
> which prevent fragmentation is still expected and this will result
> in TCP occuring.  The amount of TCP depends on lots of factors.

For clarity, the situation I meant was as follows:
 1. Client advertises EDNS0 <at> 4096 which it is perfectly capable of handling
 2. Client addresses DNS query directly to server (outside middlebox)
 3. Middlebox passes query untouched (except perhaps normal NAT stuff)
 4. Response is UDP, and >1500 bytes, so fragmented
 5. Middlebox passes first packet only, and drops UDP fragments
 6. Client never receives all fragments to reassemble

Now you might say "well the client should be advertising EDNS0 <at> 1500 or
whatever" but won't work (even if it is on the fallback path) where
the response is >1500 bytes (and can't be trimmed of extraneous
stuff so as to fit). Ignoring for a moment EDNS page option type
innovations, that one would have to go via TCP as far as I can see.

--

-- 
Alex Bligh
Permalink | Reply | 0 comments |
headers
bert hubert | 1 Sep 2009 09:21
Picon

Re: [dnsext] EDNS0 fallback "revisited"

2009/9/1 Patrik Fältström <paf <at> cisco.com>:
> The question is who the complaint is going to. Some DNSSEC problems will
> target the large ISPs that run the large resolvers. They will detect people
> with broken signed zones -- but they will most certainly _not_ have the
> fragmentation issues (or they have serious problems anyway). The complaints

I'm not sure about the latter. What will probably happen a lot is the
following scenario:

1) ISP/Corporation turns on DNSSEC validation
2) complaints come in that goodsecuritybank.org does not resolve
anymore (because of fragments not arriving or TCP/IP not working), or
is slow to resolve. badsecuritybank.org resolves normally!
3) ISP/Corporation turns off DNSSEC validation, goodsecuritybank.org
is fast again.
3a) goodsecuritybank.org reads about itself online, and its domain not
resolving, and thinks twice about its DNSSEC signing..
3b) badsecuritybank.org thinks they were right all along
4) Wait.. and perhaps go back to step 1

A well-motivated ISP or corporation with time on its hand should of
course launch a good investigation after step 2, and fix their own
(corporate) firewalls or access lists.

The steps outlined above become worse if they only happen over time.
Say, at first things fit within a single packet, and people consider
the 'turn on DNSSEC validation' project a success. Few weeks later
things start breaking down (move to NSEC3, or larger keys, or key
rollover..), no one has time to investigate, and as a workaround,
validation is shut off.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Patrik Fältström | 1 Sep 2009 09:31
Picon
Favicon

Re: [dnsext] EDNS0 fallback "revisited"

On 1 sep 2009, at 09.21, bert hubert wrote:

> Do realise that Nicholas' numbers indicate that 13% of all resolvers
> today that understand EDNS appear to be *unable* to receive an answer
> that requires fragmentation or TCP to be working.

I do understand your scenario description, and I do know about  
Nicholas number. But I do not understand why we have not seen any  
problems in newspapers in Sweden where we have been running DNSSEC for  
quite some time.

Is that because the large resolvers (with many queries) "of course"  
are not behind a firewall (something I find being a pretty weird  
thing) or behind a firewall that do the right thing (those exists,  
remember), and in reality the people that have participated in Nic's  
tests are the ones that really are behind broken things that "just  
want to test"? I.e. you simply do not run Nic's tests if it is not the  
case that you already do see some problems.

Sure, I agree the 13% number is large, very large, and even if the  
real number of affected queries is 0.1% it might be too large. I would  
even be surprised if 13% of the resolvers in the world that send  
queries to the TLDs etc have this problem. But even 1% might be too  
large!

> Anyone not impressed by this number might want to talk to people that
> carry responsibility for system administration, and see what they
> think of it.

Bert, I do. I really do. And that is what confuses me. People that do
(Continue reading)

Permalink | Reply | 4 comments |
headers
bmanning | 1 Sep 2009 10:31

Re: [dnsext] EDNS0 fallback "revisited"

On Tue, Sep 01, 2009 at 09:31:59AM +0200, Patrik Fdltstrvm wrote:
> On 1 sep 2009, at 09.21, bert hubert wrote:
> 
> >Do realise that Nicholas' numbers indicate that 13% of all resolvers
> >today that understand EDNS appear to be *unable* to receive an answer
> >that requires fragmentation or TCP to be working.
> 
> I do understand your scenario description, and I do know about  
> Nicholas number. But I do not understand why we have not seen any  
> problems in newspapers in Sweden where we have been running DNSSEC for  
> quite some time.
> 
> Is that because the large resolvers (with many queries) "of course"  
> are not behind a firewall (something I find being a pretty weird  
> thing) or behind a firewall that do the right thing (those exists,  
> remember), and in reality the people that have participated in Nic's  
> tests are the ones that really are behind broken things that "just  
> want to test"? I.e. you simply do not run Nic's tests if it is not the  
> case that you already do see some problems.
> 
	some very interesting advice from Roland Dobbins - Don't 
	put your webservers/dnsservers behind firewalls.  - this to 
	the assembled folks  <at>  ausnog yesterday.  -  so maybe not so weird.

> Sure, I agree the 13% number is large, very large, and even if the  
> real number of affected queries is 0.1% it might be too large. I would  
> even be surprised if 13% of the resolvers in the world that send  
> queries to the TLDs etc have this problem. But even 1% might be too  
> large!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aki Tuomi | 1 Sep 2009 11:00
Picon
Favicon

RE: [dnsext] EDNS0 fallback "revisited"

> -----Original Message-----
> From: owner-namedroppers <at> ops.ietf.org [mailto:owner-
> namedroppers <at> ops.ietf.org] On Behalf Of bmanning <at> vacation.karoshi.com
> Sent: Tuesday, September 01, 2009 11:32 AM
> To: Patrik Fältström
> Cc: bert hubert; Nicholas Weaver; Alex Bligh; Olafur Gudmundsson/DNSEXT
> chair; namedroppers <at> ops.ietf.org
> Subject: Re: [dnsext] EDNS0 fallback "revisited"
> 
> On Tue, Sep 01, 2009 at 09:31:59AM +0200, Patrik Fdltstrvm wrote:
> > On 1 sep 2009, at 09.21, bert hubert wrote:
> >
> > Is that because the large resolvers (with many queries) "of course"
> > are not behind a firewall (something I find being a pretty weird
> > thing) or behind a firewall that do the right thing (those exists,
> > remember), and in reality the people that have participated in Nic's
> > tests are the ones that really are behind broken things that "just
> > want to test"? I.e. you simply do not run Nic's tests if it is not
> the
> > case that you already do see some problems.
> >
> 	some very interesting advice from Roland Dobbins - Don't
> 	put your webservers/dnsservers behind firewalls.  - this to
> 	the assembled folks  <at>  ausnog yesterday.  -  so maybe not so
> weird.
> 
 
<snip />

There is rarely any need to put border authoritative servers (or resolvers, for that matter) behind
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Thompson | 1 Sep 2009 13:48
Picon
Picon
Favicon

Re: [dnsext] root DNSKEY response is 1749 bytes

On Aug 31 2009, Tony Finch wrote:

>On Mon, 31 Aug 2009, Alex Bligh wrote:
>>
>> Question: do stub resolvers on popular operating systems actually
>> fall back to TCP, and if so, do they pipeline?
>
>The usual high-level resolver APIs don't allow pipelining, but GNU adns
>(for example) makes it easy. You can pipeline using the low-level
>resolver API but it's much more fiddly.

Olaf Kolkman's Perl module Net::DNS supports a "persistent_tcp" option:

| Get or set the persistent TCP setting.  If set to true, Net::DNS
| will keep a TCP socket open for each host:port to which it connects.
| This is useful if you're using TCP and need to make a lot of queries
| or updates to the same nameserver.
| 
| This option defaults to false unless you're running under a
| SOCKSified Perl, in which case it defaults to true.

I have used this in some local applications.

--

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: cet1 <at> ucs.cam.ac.uk    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.
Permalink | Reply | 0 comments |

Gmane