headers
Mark Andrews | 1 Mar 2008 08:00

Re: dns-0x20.txt


> 
> On 29-Feb-2008, at 12:57, Paul Vixie wrote:
> 
> >>> marka has made the revolutionary (to me at least) proposal that once
> >>> you've heard EDNS0 from a responder, you should remember that you  
> >>> did, and
> >>> you should not be willing to believe that they've lost this  
> >>> capability.
> >>
> >> I'm worried about how you would determine that the responder was  
> >> the  same
> >> across subsequent queries sent to the same address and port.
> >
> > NSID?
> 
> If we're talking green fields, sure, but I don't think it's reasonable  
> to expect non-EDNS-capable servers to support NSID.
> 
> >> Anycast servers provide meat for this concern. If the query  
> >> frequency is
> >> very low, even routine server renumbering or system administration  
> >> might
> >> provide some protein.
> >>
> >> On the face of it, this proposal does not seem very robust.
> >
> > i agree.  however, we have in the past insisted that all authority  
> > servers for
> > a zone support the same level of dnssec.  could we not also insist
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eastlake III Donald-LDE008 | 2 Mar 2008 20:00

RE: dns-0x20.txt

Hi Wouter, 

> -----Original Message-----
> From: Wouter Wijngaards [mailto:wouter <at> nlnetlabs.nl] 
> Sent: Thursday, February 28, 2008 4:09 AM
> To: Eastlake III Donald-LDE008
> Cc: Michael Graff; namedroppers <at> ops.ietf.org
> Subject: Re: dns-0x20.txt
> 
> Eastlake III Donald-LDE008 wrote:
> | Hi,
> |
> | On using an EDNS0 option, please see my draft at
> | 
>
http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt
> | .
> | For simplicity is proposes a fixed size but it would be 
> trivial to make
> | it variable.
> 
> I like the idea of using an EDNS0 option to contain random data.
> Perhaps without a complicated hashing scheme (as you have), 
> but simpler
> (once you know the server speaks that option; you are guarded by the
> server copying the option back to you; of course the 
> occasional timeout
> or reboot presents small windows of downgrade attack. State could be
> stored on disk though.). Anyway, your proposal is nice.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Vixie | 3 Mar 2008 02:38

dns-0x20 section 5.4

thanks very much to wouters <at> nlnetlabs for this important observation+technique:

Index: dns-0x20.ms
===================================================================
RCS file: /udir/vixie/src/cvsroot/i-d/Working/dns-0x20.ms,v
retrieving revision 1.2
diff -u -r1.2 dns-0x20.ms
--- dns-0x20.ms 3 Mar 2008 01:21:30 -0000       1.2
+++ dns-0x20.ms 3 Mar 2008 01:26:16 -0000
 <at>  <at>  -191,6 +191,14  <at>  <at> 
 their operations log when a mismatch in the 0x20 bits occurs, to help measure
 global cache poisoning attempts, and to diagnose problems which may be due to
 DNS middleboxes.
+.LP
+5.4. Requestors should take care to remember the original question name, so
+that following successful verification of the 0x20-randomized question name,
+the original can be copied into the response message before the other sections
+are uncompressed.  This is because compression pointers in the answer,
+authority, and additional section often point back to the question section,
+with the ugly result of copying the 0x20-randomized bits into the cache, and
+into subsequent responses which include data from the cache.
 .\" -------------------------------
 .Sh "5 - Implementation and Measurement"
 .LP

i noted from the above diff that i had two section 5's.  further investigation
revealed a lack of a section 10.  i renumbered the second 5, and 6..9, by +1.

that URL again is <http://sa.vix.com/~vixie/dns-0x20.txt>.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kenji Rikitake | 3 Mar 2008 04:13
Picon
Favicon
Gravatar

Re: edns0-bis submitted

In the message <200802272321.m1RNLj3L033154 <at> drugs.dv.isc.org>
dated Thu, Feb 28, 2008 at 10:21:22AM +1100,
Mark Andrews <Mark_Andrews <at> isc.org> writes:
> 	The only transitions allowed for packet loss should be.
> 
> 		EDNS -> EDNS  <at> 512 (for broken firewalls)
> 
> 	If a firewall is not going to allow EDNS though then it should be
> 	responding to the query with FORMERR.

Just curious: Mark, what do you think about the following case?

* a resolver send a UDP request to a server for a large RR with EDNS

* the server responds with the answer in a large UDP datagram which
fragments into two or more pieces of IP packets

* unfortunately the resolver is behind a middlebox (firewall, router,
whatever) and could not get the answer due to the blockage of the
DF-bit-set IP packets

In this case, I think falling back to EDNS  <at> IP-MTU-aware-value
(presumably 1500 for IPv4, 1200 or so for IPv6) is worth trying, though
the state management will get more complicated because it's adding
another state between EDNS and "EDNS  <at> 512".

I'd like to see the pros and cons.

I also feel, however, to accept the conservative approach of
(Continue reading)

Permalink | Reply | 7 comments |
headers
Mark Andrews | 3 Mar 2008 04:45

Re: edns0-bis submitted


> In the message <200802272321.m1RNLj3L033154 <at> drugs.dv.isc.org>
> dated Thu, Feb 28, 2008 at 10:21:22AM +1100,
> Mark Andrews <Mark_Andrews <at> isc.org> writes:
> > 	The only transitions allowed for packet loss should be.
> > 
> > 		EDNS -> EDNS  <at> 512 (for broken firewalls)
> > 
> > 	If a firewall is not going to allow EDNS though then it should be
> > 	responding to the query with FORMERR.
> 
> Just curious: Mark, what do you think about the following case?
> 
> * a resolver send a UDP request to a server for a large RR with EDNS
> 
> * the server responds with the answer in a large UDP datagram which
> fragments into two or more pieces of IP packets
> 
> * unfortunately the resolver is behind a middlebox (firewall, router,
> whatever) and could not get the answer due to the blockage of the
> DF-bit-set IP packets

	Any nameserver that sets DF for IPv4 UDP resonses is broken.
	For IPv6 network MTU fragmentation should be being performed.

> In this case, I think falling back to EDNS  <at> IP-MTU-aware-value
> (presumably 1500 for IPv4, 1200 or so for IPv6) is worth trying, though
> the state management will get more complicated because it's adding
> another state between EDNS and "EDNS  <at> 512".
>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Paul Vixie | 3 Mar 2008 21:26

implications of RFC 2181 on cname chains

in a private discussion with jinmei, he showed me this text from RFC 2181:

>    Note that the answer section of an authoritative answer normally
>    contains only authoritative data.  However when the name sought is an
>    alias (see section 10.1.1) only the record describing that alias is
>    necessarily authoritative.  Clients should assume that other records
>    may have come from the server's cache.  Where authoritative answers
>    are required, the client should query again, using the canonical name
>    associated with the alias.

i've struggled with this concept, since i had always restricted this
treatment to "out of zone" cnames.  in other words when i receive...

	www.example.com. cname xxx.example.com.
	xxx.example.com. aaaa  dead::beef

...i had been treating both names as authoritative, since both are children of
the apex i was querying under.  i've realized that xxx.example.com might be an
NS RR for which the example.com authority servers happen to have an AAAA RR
cached (or might have it as glue in the example.com zone).  so, i have altered
my own caching server to ignore the second name in the above example, and to
re-fetch from the end of my cached cname chain, so that i have to build my
cached cname chain one query at a time, no matter what the authority server
says.

i recommend that authority servers stop sending back full cname chains.  i
don't think this implication was obvious during the production of RFC 2181.
only the name matching the qname can be seen as authoritative.  everything
else is just fluff.  cname chains are nec'y for RD=1 RA=1, otherwise useless.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Mark Andrews | 3 Mar 2008 22:49

Re: implications of RFC 2181 on cname chains


> in a private discussion with jinmei, he showed me this text from RFC 2181:
> 
> >    Note that the answer section of an authoritative answer normally
> >    contains only authoritative data.  However when the name sought is an
> >    alias (see section 10.1.1) only the record describing that alias is
> >    necessarily authoritative.  Clients should assume that other records
> >    may have come from the server's cache.  Where authoritative answers
> >    are required, the client should query again, using the canonical name
> >    associated with the alias.
> 
> i've struggled with this concept, since i had always restricted this
> treatment to "out of zone" cnames.  in other words when i receive...
> 
> 	www.example.com. cname xxx.example.com.
> 	xxx.example.com. aaaa  dead::beef
> 
> ...i had been treating both names as authoritative, since both are children o
> f
> the apex i was querying under.  i've realized that xxx.example.com might be a
> n
> NS RR for which the example.com authority servers happen to have an AAAA RR
> cached (or might have it as glue in the example.com zone).  so, i have altere
> d
> my own caching server to ignore the second name in the above example, and to
> re-fetch from the end of my cached cname chain, so that i have to build my
> cached cname chain one query at a time, no matter what the authority server
> says.
> 
> i recommend that authority servers stop sending back full cname chains.  i
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Blacka | 4 Mar 2008 01:05
Picon
Favicon
Gravatar

Re: implications of RFC 2181 on cname chains


On Mar 3, 2008, at 3:26 PM, Paul Vixie wrote:

> in a private discussion with jinmei, he showed me this text from RFC  
> 2181:
>
>>   Note that the answer section of an authoritative answer normally
>>   contains only authoritative data.  However when the name sought  
>> is an
>>   alias (see section 10.1.1) only the record describing that alias is
>>   necessarily authoritative.  Clients should assume that other  
>> records
>>   may have come from the server's cache.  Where authoritative answers
>>   are required, the client should query again, using the canonical  
>> name
>>   associated with the alias.
>
> i've struggled with this concept, since i had always restricted this
> treatment to "out of zone" cnames.  in other words when i receive...
>
> 	www.example.com. cname xxx.example.com.
> 	xxx.example.com. aaaa  dead::beef
>
> ...i had been treating both names as authoritative, since both are  
> children of
> the apex i was querying under.  i've realized that xxx.example.com  
> might be an
> NS RR for which the example.com authority servers happen to have an  
> AAAA RR
> cached (or might have it as glue in the example.com zone).  so, i
(Continue reading)

Permalink | Reply | 3 comments |
headers
Paul Vixie | 4 Mar 2008 05:21

Re: implications of RFC 2181 on cname chains

> > ...
> > i recommend that authority servers stop sending back full cname chains.  i
> > don't think this implication was obvious during the production of RFC
> > 2181.  only the name matching the qname can be seen as authoritative.
> > everything else is just fluff.  cname chains are nec'y for RD=1 RA=1,
> > otherwise useless.
> 
> I was actually thinking about writing a draft about this, but figured that
> it was either too tall a hill to climb or not actually solving a real
> problem (or both).

i've realized that the point in 1034 and 2181 is so subtle that a separate
i-d is required.  perhaps you would do me the honour of co-authoring it?

> I was thinking that authoritative servers should still be allowed to chase
> CNAMEs within zone, but your point suggests otherwise, which I find
> interesting.

i can't escape the feeling that in-zone cnames ought to be chainable in a
single response, nor the feeling that they really, in fact, cannot be.  in
any case any RD=0 initiator has to be prepared to detect and finish incomplete
cname chains, whether due to out-of-zone, or ttl-expired-middle-member, and
so this change adds no new logic, except the part where they have to ignore
all answer records whose owner != qname, even if it otherwise looks like a
complete in-zone chain.  the recommendation that servers stop sending this
swill is minor in comparison to what the initiator has to stop believing.

> My thinking was that, since modern resolvers should certainly ... the rest
> of the CNAME chain when it goes out of zone, then authoritative servers
> should not waste their time.  Your point is stronger.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Phil Pennock | 4 Mar 2008 06:07

Re: implications of RFC 2181 on cname chains

On 2008-03-04 at 04:21 +0000, Paul Vixie wrote:
> i can't escape the feeling that in-zone cnames ought to be chainable in a
> single response, nor the feeling that they really, in fact, cannot be.

This seems reasonable to me, so please shoot holes in it:

If the responder orders the additional records so that authoritative
responses come before non-authoritative responses, then an EDNS0 option
AUTHADDITIONAL could provide an integer N in the range 0 to
number_of_additional_responses (inclusive) with the interpretation that
it is authoritative for the first N additional responses, not counting
the OPT pseudo-RR.

Clients that don't understand the extension treat all additional
responses identically (and hopefully non-authoritative).

Clients that _might_ understand the extension will have issued an EDNS0
query suggesting that it will correctly ignore unknown extended options.
(Worst case, a new extended flag requesting an authadditional response).

Clients that do understand the extension gain the ability to reduce the
number of round-trips to safely chase CNAME chains, providing a
performance benefit to enabling EDNS0 where the server supports this.

Clients that understand the extension talking to a server which doesn't
support the extension won't get the new option response so won't see the
immediate benefit, but no harm done.

No additional octets required for query packets.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane