Subject: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients

From: Matthew Dempsky <[email-masked]>
Date: Tue, 9 Jun 2009 14:10:43 -0700

Currently, the root servers provide IPv6 glue (AAAA records) to
clients that have queried them over IPv4.  They even do this in
preference to providing all of the IPv4 glue; e.g., "dig
www.example.com @a.root-servers.net" returns IPv6 glue for
{a,b}.gtld-servers.net, but no IPv4 glue for m.gtld-servers.net.  This
is seems to be due to omitting records to fit into the 512 byte
boundary: "dig x.com @a.root-servers.net" returns all IPv4 glue.

dnscache from djbdns tries to find A records for all listed NS records
before contacting any of them, which results in an extra root zone
query for m.gtld-servers.net in the above situation.  (This causes a
small slow down and additional network traffic, but is not otherwise a
significant problem.)

Is there any reason why servers shouldn't prefer *for IPv4 clients* to
give all IPv4 glue records and then try to add as many IPv6 glue
records as possible?  (Similarly, for IPv6 clients to give all IPv6
glue records and then try to add as many IPv4 glue records as
possible.)  A records are always potentially useful for clients
contacting a server over IPv4, and AAAA records are always potentially
useful for clients contacting a server over IPv6, but A records are
not useful to IPv6-only clients and AAAA records are not useful to
IPv4-only clients.

One corner case that comes to mind is if an authoritative server is on
an IPv4 only network, but has a gateway that can proxy IPv6 traffic to
IPv4.  However, this seems easy enough to work around (e.g., either
upgrade the internal network to support native IPv6, or configure the
DNS server to treat traffic from the IPv6-to-IPv4 gateway as IPv6
traffic).

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 9 Jun 2009 14:52:37 -0700

> Yes. It's a dumb idea to tamper with the contents of a DNS response based on
> the underlying network protocol that gets used for the query/reply.

It's a dumb idea to omit glue records too, but that's the solution the
root servers have chosen for dealing with their large delegation
record sets.

> There's
> usually a resolving server between the edge client (stub resolver) making
> the query and the authoritative server. That authoritative server doesn't
> see the stub resolver. So it has no way of knowing if that client prefers A
> or AAAA records. It shouldn't (need to) care about the client's preferences
> or network protocol choices anyway.

Huh?  The glue data doesn't go to the stub resolver anyway.  The stub
resolver encodes what data it wants in the questions section by
explicitly asking for either A or AAAA records.

---

From: Jim Reid <[email-masked]>
Date: Tue, 9 Jun 2009 23:39:37 +0100

On 9 Jun 2009, at 22:52, Matthew Dempsky wrote:

> It's a dumb idea to omit glue records too,

No it isn't. There is a limit on the size of a DNS response. So  
dropping stuff from the Additional Section is preferable to sending a  
truncated response and TCP retries. As long as the reponse contains  
*some* glue -- assuming we're talking about the real definition of  
glue -- that's good enough.

In the case you mentioned, who cares if the referral for example.com  
from a.root-servers.net does not have an address record for m.gtld- 
servers.net? It's got A and AAAA records for the other .com servers.  
That response BTW is 501 bytes, so there's not enough room left to  
squeeze in an address record for m.gtld-servers.net. If the querying  
server *really* needs that info, it can just  do a lookup to resolve  
that name.

Oh and NONE of the address records in that referral response are  
glue.Their names don't live under the domain that's being queried  
(example.com). They live under gtld-servers.net. So strictly speaking  
there's no reason for a.root-servers.net to return those address  
records at all. It was just doing that to be nice.

> Huh?  The glue data doesn't go to the stub resolver anyway.

That's irrelevant to your question about making DNS responses  
conditional on the network protocol used for making queries. I just  
used the simple example of a conventional lookup to show why.

> The stub resolver encodes what data it wants in the questions  
> section by

Not always. It may be asking for other stuff: MX or CNAME records and  
so on. In which case any address records returned in the Additional  
Section of the response are a bonus.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 9 Jun 2009 16:03:02 -0700

On Tue, Jun 9, 2009 at 3:39 PM, Jim Reid<[email-masked]> wrote:
> No it isn't.

Sorry, you're right, slowing down DNS resolution time and adding
additional load to the root servers is a great solution.

> So dropping
> stuff from the Additional Section is preferable to sending a truncated
> response and TCP retries.

Fine, but if you're going to drop glue data, then drop the less useful
glue data.

> In the case you mentioned, who cares if the referral for example.com from
> a.root-servers.net does not have an address record for m.gtld-servers.net?

I gave an example of a widely used DNS server in my first email that cares.

> It's got A and AAAA records for the other .com servers. That response BTW is
> 501 bytes, so there's not enough room left to squeeze in an address record
> for m.gtld-servers.net. If the querying server *really* needs that info, it
> can just  do a lookup to resolve that name.

The client asked a root server over IPv4, not over IPv6.  It obviously
prefers to talk to servers over IPv4 instead of over IPv6, so there's
no reason that glue AAAA records provided for names listed in NS
records should have priority over glue A records provided for names
listed in NS records.

> Oh and NONE of the address records in that referral response are glue.Their
> names don't live under the domain that's being queried (example.com). They
> live under gtld-servers.net. So strictly speaking there's no reason for
> a.root-servers.net to return those address records at all. It was just doing
> that to be nice.

Fine, substitute "www.example.com" with "www.example.net".

> That's irrelevant to your question about making DNS responses conditional on
> the network protocol used for making queries.

It's relevant to your argument that what glue records are included in
delegation responses have anything to do with what IPv4/IPv6
connectivity a stub resolver has.

>> The stub resolver encodes what data it wants in the questions section by
> Not always. It may be asking for other stuff: MX or CNAME records and so on.
> In which case any address records returned in the Additional Section of the
> response are a bonus.

They're a bonus for MX records, but they're necessary for NS records
pointing to in-bailiwick names.

---

From: Jim Reid <[email-masked]>
Date: Wed, 10 Jun 2009 00:11:35 +0100

> I gave an example of a widely used DNS server in my first email that  

No you didn't. You gave an example of a broken implementation with a  
small percentage of the installed base. It's so broken it doesn't even  
support EDNS0. Enough said. I have tried to apply clue. You have  
resisted those efforts. This discussion is over.

Welcome to my kill file and goodbye.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 9 Jun 2009 16:23:34 -0700

On Tue, Jun 9, 2009 at 4:11 PM, Jim Reid<[email-masked]> wrote:
> No you didn't. You gave an example of a broken implementation with a small
> percentage of the installed base.

Guess what: the Internet is big! A "small percentage" is still a lot
of installations.

I'm sorry if you think the Internet should only be used by BIND.

> It's so broken it doesn't even support EDNS0.

Since when is not sending DNS queries with EDNS0 considered "broken"?
Why do the root servers bother responding to caches that don't use
EDNS0?  If you want to weed out "broken" software, why not encourage
the root and .com servers to stop responding to queries without EDNS0?
:P

> Enough said. I have tried to apply clue. You have resisted those
> efforts. This discussion is over.
>

ohnoz!

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Jun 2009 12:54:08 +1000

In message <[email-masked]>, Matth
ew Dempsky writes:
> EDNS0?

	To not break legacy (no IPv6 transport support) software.
	Dropping additional records should not cause iterative
	nameservers to break.  If it does the software was not
	compliant in the first place.

	Note: Some of the roots *are* configured to preference A
	records in the additional section.  This should not be
	needed for queries over IPv6 as EDNS support is manditory.
	See IPv6 node requirements.

> If you want to weed out "broken" software, why not encourage
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 9 Jun 2009 20:14:45 -0700

>        To not break legacy (no IPv6 transport support) software.

Sorry, that was a rhetorical question in response to Jim Reid's absurd
claim that software that doesn't support EDNS0 is "broken".

>        compliant in the first place.

It doesn't cause dnscache to break, but it does cause it to do
additional work and to add additional load on the root servers.
Serving all A glue in preference to any AAAA records for IPv4 clients
is a perfectly backwards compatible solution that solves this problem
with no apparent disadvantages.

>        records in the additional section.

Ah, you're right.  It's only {a,c,e,i,j}.root-servers.net that give
AAAA records in preference to A records.

Great, then there's only 5 left to fix. :)

>        This should not be

RFC 4294 (IPv6 Node Requirements) only says "All [IPv6] nodes [...]
SHOULD implement stub-resolver [RFC-1034] functionality [...] with
support for [...] EDNS0 [RFC-2671] to allow for DNS packet sizes
larger than 512 octets."  Is there another RFC that says EDNS support
is mandatory for IPv6 nodes?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Jun 2009 13:47:30 +1000

In message <[email-masked]>, Matth
ew Dempsky writes:
> > =A0 =A0 =A0 =A0To not break legacy (no IPv6 transport support) software.
> 
> > =A0 =A0 =A0 =A0Dropping additional records should not cause iterative
> > =A0 =A0 =A0 =A0nameservers to break. =A0If it does the software was not
> > =A0 =A0 =A0 =A0compliant in the first place.
> 

	Well fix dnscache.  The need for bigger UDP packets has
	been obvious for over 10 years now.  If it slow stop
	complaining and get with the program.

> > =A0 =A0 =A0 =A0Note: Some of the roots *are* configured to preference A
> > =A0 =A0 =A0 =A0records in the additional section.
> 
> > =A0 =A0 =A0 =A0needed for queries over IPv6 as EDNS support is manditory.
> > =A0 =A0 =A0 =A0See IPv6 node requirements.
> 

	If you choose to implement a iterative resolver instead of
	a stub resolver the need for EDNS doesn't change.  A recursive
	nameserver is just a shared iterative resolver.

	Mark

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 9 Jun 2009 21:00:15 -0700

On Tue, Jun 9, 2009 at 8:47 PM, Mark Andrews<[email-masked]> wrote:
>        Well fix dnscache.

Make up your mind: is it "broken" for a DNS cache to not use EDNS0?

If so, then why not change the root servers to stop answering queries
that don't use EDNS0?  That will certainly encourage "broken" DNS
cache administrators to fix their installations! :P

If not, then why not change the 5 root servers in question to behave
the same as the other 8?  Give me a valid argument why the AAAA
records should be preferred to the A records for an IPv4 client and
I'll drop the issue.

>        a stub resolver the need for EDNS doesn't change.

What "need"?  The text I quoted is the only mention of "EDNS" in RFC
4294.  What are you talking about?

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 09 Jun 2009 21:24:42 -0700

Matt and all,

  Don't feel bad Matt, I am also in Jim's "Kill file".  Such is life,
ho hum...  Me thinks that Jim although a smart fellow has an ego
larger than his intelect.

> > Welcome to my kill file and goodbye.

Regards,

Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln
"YES WE CAN!"  Barack ( Berry ) Obama

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

---

From: [email-masked]
Date: Wed, 10 Jun 2009 09:49:43 +0000

> Fine, but if you're going to drop glue data, then drop the less useful

	er...  "useful" - i'd be interested in learning how auth servers
	are supposed to be prescentient in "knowing" what the IMR is going
	to do with said glue.

	the one thing that we have done is to look at the transport that the
	query arrived on and shuffle glue for that transport to the head of
	the line...  not ideal, but an attempt to "know" what is useful or
	not.  Its not foolproof (fools being so clever) but it was a crack
	at not treating one transport as preferable over an other.

--bill

---

From: [email-masked]
Date: Wed, 10 Jun 2009 09:55:50 +0000

> records should be preferred to the A records for an IPv4 client and

	the transport used by the IMR is not equivalent to the
	type of data being asked for - some of the time.

	if the IMR only has a v4 path to the auth server - and the 
	IMR clients have v6 paths to the IMR, should not the IMR get 
	some IPv6 data back from the auth  server for its clients who
	need that data, even though the IMR only has a v4 transit path 
	to the auth server?
--bill

---

From: Andreas Gustafsson <[email-masked]>
Date: Wed, 10 Jun 2009 15:33:07 +0300

> 	type of data being asked for - some of the time.

True, but irrelevant - we are talking about glue, which is not the
data being asked for, but meta-data which is used only by the IMR
itself.
-- 
Andreas Gustafsson, [email-masked]

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Wed, 10 Jun 2009 08:20:09 -0700

> 	are supposed to be prescentient in "knowing" what the IMR is going

If I understand it right then Matthew is saying that IPv6 IMR's will  
use EDNS0 anyway, so pretty much by definition the A records are going  
to be the useful ones to non-EDNS0 requestors.

  - ask

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 10 Jun 2009 11:44:49 -0400

[no hat]

> records should be preferred to the A records for an IPv4 client and

You have the burden of proof the wrong way.  One would need a valid
argument (and not incidentally, true conclusion -- they're not the
same thing) that a DNS server should prefer A records to AAAA records
in the additional section when talking over IPv4 transit.  As Bill
Manning points out, there is no strong link between the network from
which one is querying and the network that one ultimately wants to
use.

Second, there is reason to suppose that different behaviour on the
part of different servers might be desirable, since this could be the
result of different implementations or different code paths in the
same implementation.

Third, given the v4-v6 interoperation work currently being undertaken
in other working groups (such as BEHAVE), I think there is
considerable reason to be sceptical that tying the things in the
additional section to the network whence the query arrived is a good
idea.  For all we know, it might be that someone is somewhere using
the existence of AAAA records in the additional section as a clue that
the v6 network might be worth trying.  If so, I don't want to
discourage such people.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 10 Jun 2009 18:57:37 +0200

> data being asked for, but meta-data which is used only by the IMR

Asking over IPv4 doesn't imply you are not IPv6 capable. It could just
be outdate root.hints file. Also the asking side could have different
strategies which IP protocols to use first when dual stacked. So Bill
is right.

Ondrej
-- 
 Ondrej Sury
 technicky reditel/Chief Technical Officer
 -----------------------------------------
 CZ.NIC, z.s.p.o.  --  .cz domain registry
 Americka 23,120 00 Praha 2,Czech Republic
 mailto:[email-masked]  http://nic.cz/
 sip:[email-masked] tel:+420.222745110
 mob:+420.739013699     fax:+420.222745112
 -----------------------------------------

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 10 Jun 2009 10:20:53 -0700

On Wed, Jun 10, 2009 at 9:57 AM, Ondřej Surý<[email-masked]> wrote:
> Asking over IPv4 doesn't imply you are not IPv6 capable.

There are two sets of resolvers that will contact the root servers
over IPv4: IPv4-only resolvers and dual-stack IPv4/IPv6 resolvers.  A
records are useful to both sets of resolvers, whereas AAAA records are
only useful to the second set.

Mark Andrews has already pointed out that IPv6 nodes SHOULD* support
EDNS0, so these resolvers will be able to get all A and AAAA glue by
advertising a larger buffer size.  Serving A records in preference to
AAAA records for queries over IPv4 avoids causing legacy resolvers to
have to send additional queries to the root servers.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 10 Jun 2009 10:26:21 -0700

2009/6/10 Matthew Dempsky <[email-masked]>:
> EDNS0,

* Mark actually claimed EDNS support is "mandatory" for IPv6 nodes,
but the IPv6 Node Requirements RFC only states IPv6 nodes SHOULD
support EDNS0.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 10 Jun 2009 10:47:59 -0700

On Wed, Jun 10, 2009 at 8:44 AM, Andrew Sullivan<[email-masked]> wrote:
> You have the burden of proof the wrong way.

I already gave a concrete example of existing software that is
adversely affected by the behavior of these five root servers,
resulting in increased load on all of them.  As of yet, no one has
given a good justification to why AAAA glue records over A glue
records in response to queries not using EDNS0 and sent over IPv4.

> As Bill

According to RFC 4294, an IPv6 node SHOULD support EDNS0.  In this
case, the larger buffer size will be able to handle the complete set
of A and AAAA records, and choose however it wants among all of the
record types.

In the event that an IPv6 node does not support EDNS0 and contacts one
of the IPv4 root servers instead of one of the IPv6 root servers, it
seems reasonable to give it A records instead of AAAA records.

> result of different implementations or different code paths in the

I don't follow how that makes it "desirable".

> the v6 network might be worth trying.  If so, I don't want to

Can you elaborate on this point?  I don't follow what problem the
client is trying to solve.  Do you have a concrete example of software
that does this?  If not, is there a reason you want the root servers
to favor a hypothetical IPv6 node that doesn't support EDNS0 and has
some peculiar non-standard behavior in preference to existing software
that is standards conforming?

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 10 Jun 2009 10:48:42 -0700

> have to send additional queries to the root servers.

Stupid question: So what?

IT only affects a trivial fraction of resolvers, and its getting items  
that have very long TTLs, so I don't see why the additional queries  
really matter at all?

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 10 Jun 2009 10:55:27 -0700

2009/6/10 Nicholas Weaver <[email-masked]>:
> IT only affects a trivial fraction of resolvers, and its getting items that
> have very long TTLs, so I don't see why the additional queries really matter
> at all?

Because it's a simple enough problem to fix.  If people are going to
insist that caches always talk to the root servers rather than using a
local copy of the root zone, I think those same people should also be
interested in making sure the root servers behave optimally for all
caches.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 10 Jun 2009 10:57:05 -0700

>        are supposed to be prescentient in "knowing" what the IMR is going

It's a pretty reasonable guess that if I send a "A? www.example.net"
query to a root server and it responds with a delegation to the .net
servers, that I'm going to repeat my query to them.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 10 Jun 2009 11:00:44 -0700

> interested in making sure the root servers behave optimally for all

Again, why?

A few arguably broken resolvers (why fetch ALL the A records for  
everything always before proceeding?) have one extra name lookup to  
the root one in a while?

Why should the root servers be changed to accomadate such broken  
behavior?

The amount of impact on the root servers themselves is trivial, and  
the impact on even the arguably broken resolvers is trivial (one extra  
RTT for looking up a TLD not yet in the cache?).

Why change working code?

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 10 Jun 2009 11:03:15 -0700

At 10:20 AM -0700 6/10/09, Matthew Dempsky wrote:
>On Wed, Jun 10, 2009 at 9:57 AM, OndÞej Sur˜<[email-masked]> wrote:

Say what? I have a V6 host, and I'm using my ISP as my namesever; this is a completely typical set up. The fact that my ISP's box is V4-only is completely unrelated to my queries to it, and its queries to the outside world.

--Paul Hoffman, Director
--VPN Consortium

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 10 Jun 2009 11:07:10 -0700

On Wed, Jun 10, 2009 at 11:00 AM, Nicholas
Weaver<[email-masked]> wrote:
> A few arguably broken resolvers

Sorry, what RFC says the behavior is broken?

> (why fetch ALL the A records for everything
> always before proceeding?)

How/when else should dnscache find out m.gtld-server.net's A records?
Or should it just never contact it then?

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 10 Jun 2009 11:09:15 -0700

On Wed, Jun 10, 2009 at 11:03 AM, Paul Hoffman<[email-masked]> wrote:
> Say what?

Sorry, by "resolvers" I meant "recursive resolvers".

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 10 Jun 2009 11:12:56 -0700

> Or should it just never contact it then?

It should not DELAY the resolving of a name in order to put m.gtld- 
server.net's A record into the cache.

DELAYING resolution to get information which is not necessary for the  
resolution process is arguably broken behavoir.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 10 Jun 2009 11:27:20 -0700

On Wed, Jun 10, 2009 at 11:12 AM, Nicholas
Weaver<[email-masked]> wrote:
> It should not DELAY the resolving of a name in order to put
> m.gtld-server.net's A record into the cache.
>

By design, dnscache limits itself to one active outbound query at a
time per active inbound query to mitigate amplification attacks.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 10 Jun 2009 11:29:06 -0700

> time per active inbound query to mitigate amplification attacks.

So?  Delay that resolution until AFTER the inbound query is resolved.

Blocking resolution to get data you DON'T need to produce a response  
is broken behavior.

That the code is so old that it will never be fixed should not be a  
reason to change the code on the roots.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 10 Jun 2009 11:31:05 -0700

> So?  Delay that resolution until AFTER the inbound query is resolved.

That would mean having an active outbound query without a
corresponding active inbound query.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 10 Jun 2009 11:37:16 -0700

> corresponding active inbound query.

Hu?  Whats the point of waiting then?  Its data NOT NEEDED for the  
resolution process, and yet for some random reason, its not kosher to  
delay it until after the main resolution is complete or to conduct it  
in parallel?

How is this NOT broken?

And I'm all fine and good at changing server behavior to accomidate  
broken code if:

a)  The market share for the broken code is nontrivial

b)  The effect of the broken code would cause things to not work right.

But this fails BOTH tests.

The only resolver affected is DNSCACHE: code that is old, crufty,  
unpopular, and unsupported.

The only effect is one extra RTT to the root for items which do not  
cache.

And for this you want to change code on THE critical servers for  
Internet operation?  F-that.  Just fix the code for DNSCACHE.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 10 Jun 2009 14:42:23 -0400

> records in response to queries not using EDNS0 and sent over IPv4.

You still have the burden of proof the wrong way.  One could just as
easily say, for instance, that it is nowhere defined that a resolver
ought to get all the A records before doing any work.  The software in
question happens to work that way, so now you say that others ought to
change their behaviour so that software can behave as it is
programmed.  That's the wrong answer: it's a bad idea to try to change
the protocol now to specify exactly how to sort the data in the
additional section before truncating.  Even if it happens to work for
you, it would be a protocol change, and I am opposed to doing it.
(That said, with my co-chair hat on, if you want this protocol change,
write the I-D that specifies it and see whether you can get enough
support in the WG to so change the protocol.  Hat off again.)

> of A and AAAA records, and choose however it wants among all of the

SHOULD does not mean MUST.  There is one obvious case I can think of
in which a v6 host is going to have a rough go of that: some broken
middlebox in the way that won't allow the buffer size to be different.
None of that would matter, except that the work going on in BEHAVE is
designed precisely to cope with a lot of these broken pieces of
equipment, which means that there won't even be an incentive to get
rid of them.  

> I don't follow how that makes it "desirable".

It is desirable to have different code paths and different
implementations in the DNS server space, particularly at sensitive
levels of the tree such as ".", ".org", &c.

> that is standards conforming?

The reason I want them to do as they wish is because there _could_ be
such a client.  I don't know, and I have zero reason to go looking for
one.  The mere fact that it is possible leads me to believe that a
change in this area is bad.  But see above.

I should point out one other thing, again with my co-chair hat on: if
you desire to change this _as a matter of protocol_ (i.e. this is not
just for the root servers, but for all DNS servers everywhere), then
you should write the I-D and see if you can find acceptance, as I
suggested.  In that case, this is the right list and the right
audience for the discussion.  If you're saying instead that there
should be an operational convention governing how the root servers are
configured, then this is the wrong WG to chase that problem down.  We
constrain ourselves to the protocol itself.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 10 Jun 2009 11:53:13 -0700

On Wed, Jun 10, 2009 at 11:37 AM, Nicholas
Weaver<[email-masked]> wrote:
> resolution process, and yet for some random reason, its not kosher to delay
> it until after the main resolution is complete or to conduct it in parallel?

I already explained that.  By design, it limits itself to at most one
active outbound query for each active inbound query.  Conducting two
queries in parallel would violate this, as would conducting a second
outbound query after answering the inbound query.  Also, the data *is*
needed for dnscache to be able to send queries to m.gtld-servers.net.

---

From: [email-masked]
Date: Wed, 10 Jun 2009 19:00:09 +0000

> to be the useful ones to non-EDNS0 requestors.

	well... an IMR may in fact be mixed mode, so its
	not appropriate to call an IMR out by a single transport
	protocol.  even if the IMR is dual stack, one can not
	be assured of a clean IPv6 path to all authoritative servers.

--bill

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 10 Jun 2009 12:03:20 -0700

> needed for dnscache to be able to send queries to m.gtld-servers.net.

The data is NOT needed to resolve the question asked unless during  
THIS question, it decides randomly that m.gtld-servers.net is its  
selected item.

This is ridiculous.

The behavior of dnscache is broken:  It is waiting to get data that it  
doesn't actually need to resolve THIS query, because its data it might  
randomly use later.

The brokenness is trivial:  It has a practically nonexistent effect on  
the roots, and even for what few dnscache users, the effect is almost  
trivial: one more RTT to the root in the rare case that the TLD's  
authoritative servers are not already in the cache.

The excuses as to why it remains broken are silly:  There are two  
solutions that can be almost trivially added to the code:  Do a  
concurrent fetch or do a delayed lazy fetch.   Neither fix increases  
the number of packets dnscache would generate, just changes the  
ordering so they don't introduce latency.

And, for the trivial benefit of a few users of a piece of broken open  
source code, you WANT TO CHANGE THE BEHAVIOR OF THE ROOT SERVERS WHEN  
THE SERVERS ARE ALREADY WORKING PROPERLY!?!?

Its like "Because there is a pothole in my private driveway next to  
the onramp, we need to repave the entire freeway?"

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 10 Jun 2009 15:17:11 -0400

> needed for dnscache to be able to send queries to m.gtld-servers.net.

So don't send queries there.  So what?

Also, of course, you only need it in the event you got the answer with
the AAAA records, and we've already determined that you don't always
get that.  So you don't even need this to send queries to m as such --
sometimes you will.  But m will get fewer queries from dnscache users
than other servers, and I don't think that matters.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 10 Jun 2009 12:21:04 -0700

> doesn't actually need to resolve THIS query, because its data it might

It's broken to delay query 1 instead of query X?

> The excuses as to why it remains broken are silly:  There are two solutions
> that can be almost trivially added to the code:  Do a concurrent fetch or do
> a delayed lazy fetch.   Neither fix increases the number of packets dnscache
> would generate, just changes the ordering so they don't introduce latency.

And I've already pointed out the design decision that rules out both
of these solutions: dnscache limits itself to at most one active
outbound DNS query for each inbound DNS query.  This decision helps to
mitigate against amplification attacks.  (However, I suppose defending
against amplification attacks isn't a big concern for the working
group that standardized DNSSEC. ;-))

> And, for the trivial benefit of a few users of a piece of broken open source
> code, you WANT TO CHANGE THE BEHAVIOR OF THE ROOT SERVERS WHEN THE SERVERS
> ARE ALREADY WORKING PROPERLY!?!?

If Paul Vixie and others are going to insist that caches should always
talk to the root servers rather than contacting a local root zone
server, then yes, I think the root servers should serve data in a way
that is compatible with all DNS cache software.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 10 Jun 2009 12:28:04 -0700

>        be assured of a clean IPv6 path to all authoritative servers.

Sorry, can someone clarify what "IMR" stands for?

Is the terminology being used here that "resolver" means the stub
resolver that sends a query with RD=1 to one of a few caching servers
and expects a complete answer, and "IMR" means the recursive resolver
that sends multiple queries with RD=0 to one of many authoritative
servers?

In that case, I mean the "resolver" doesn't care what glue data the
authoritative servers give to the "IMR", and the authoritative server
should give glue according to what the "IMR" can best utilize.  If the
"IMR" contacted it using IPv4, then obviously the "IMR" can make use
of A record glue data; it's not guaranteed it can make use of AAAA
record glue data.  The "resolver"'s IPv4/IPv6 connectivity has no
bearing on how the "IMR" should try to answer a query (except for how
to send the response packet, of course).

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 10 Jun 2009 21:34:06 +0200

[...snip everything...]

Matthew,

it starts to be really boring :(

what you seem to not understand that this group doesn't dictate how
should root servers behave. This group defines internet standards. And
if you want to change the behavior - write an I-D and if it gets
enough support it could become standard. That's how this group works.

If you want to change behavior without an I-D - you can go to each
individual root server operator and ask them to change their software.

Ondrej

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 10 Jun 2009 12:42:31 -0700

> it starts to be really boring :(

Agreed.

> enough support it could become standard. That's how this group works.

Just a short I-D that states DNS servers SHOULD include A record glue
data in preference to AAAA record glue data when doing additional
section processing for NS records in response to a query sent over
IPv4 without an EDNS0 OPT record?

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 10 Jun 2009 12:44:43 -0700

> It's broken to delay query 1 instead of query X?

You don't NEED to delay query X.  You don't need to increase the  
number of packets sent.

>> solutions

It is NOT AN AMPLIFICATION ATTACK IF IT DOESN'T INCREASE THE NUMBER OF  
PACKETS!

You are defending a nonsense "design decision" as somehow being  
invoilate.

Both trivial fixes do not increase the number of packets dnscache  
sends.  And the second doesn't even increase the number of active  
outbound queries per inbound query, it just keeps the outbound query  
active after the inbound query has been answered.

djbdns has been unchanged for 8 years now!  It has a significant  
security vulnerability because it doesn't have birthday-attack  
supression.  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4392

Either fix dnscache yourself (do you want to maintain abandonware open  
source?  Good for you), or stop complaining about a trivial increase  
in latency of lookups.

So why should the roots change NOW to "fix" a trivial slowdown in an 8- 
year old, unmaintained, vulnerable piece of code?

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 10 Jun 2009 13:00:05 -0700

> IPv4 without an EDNS0 OPT record?

Also, before I go to this effort, is there anyone on this mailing list
that actually supports such an I-D?  So far, the responses seem to be
very emotionally against.

---

From: [email-masked]
Date: Thu, 11 Jun 2009 16:26:19 +0000

> to send the response packet, of course).

http://www.cafax.se/dnssec/maillist/2004-05/msg00046.html

Interative Mode Resolver.

--bill

---

From: Matthew Dempsky <[email-masked]>
Date: Thu, 11 Jun 2009 09:52:21 -0700

> Interative Mode Resolver.

Thanks. :-)

---

From: [email-masked]
Date: Thu, 11 Jun 2009 18:34:55 +0000

> servers, that I'm going to repeat my query to them.

	ok... do you care that the query came in over IPv6 and
	so I, as the root server make the informed guess that the
	net servers, which have AAAA records, that maybe I should
	sort the AAAA RR's for .net in the reply?

	mind, you want the A rr for www.example.net - so your sending
	a priming query to the root.  and your IMR is going to cache 
	the data sent from the root.  the IMR will get both AAAA and A
	RR's for some/all of the .net servers. Your still going to have
	a couple more sets of recursive queries.

	You'll next send a query to the .net servers trying to find the
	A RR for www.example.net - and lo'n'behol... the example.net servers
	only talk over IPv6 transport.  so the response, whatever it might
	be, will come over IPv6 transport.  if the example.net NS set has
	both AAAA and A rr's, they might send your reply with the AAAA rr's
	first.

	then - tada - you get to ask the example.net servers, again over
	IPv6 transport for the A RR for www.example.net.  and since there
	are no AAAA for www.example.net, you get back the A.  just what
	you asked for.  

	so... what is your IMR is going to cache both A and AAAA rr's for 
	delegation cuts where such things exist.  And if your IMR decides
	to truncate or to force the auth server to truncate the responses
	to some historically small value - thereby causeing you a loss of
	data...  that sounds like locally induced pain.  

--bill

---

From: Danny Mayer <[email-masked]>
Date: Sun, 14 Jun 2009 23:20:02 -0400

Matthew Dempsky wrote:
> On Wed, Jun 10, 2009 at 9:57 AM, Ondøej Surý<[email-masked]> wrote:

There is a really bad assumption here: that the resolvers are the
consumers of the resulting A and AAAA records. The real consumer is the
application initiating the request of the resolver for an address. The
application may well be IPv6 capable and/or IPv4 capable but the servers
won't know that or have any way of knowing that.

Danny

---

From: Matthew Dempsky <[email-masked]>
Date: Sun, 14 Jun 2009 20:27:20 -0700

On Sun, Jun 14, 2009 at 8:20 PM, Danny Mayer<[email-masked]> wrote:
> consumers of the resulting A and AAAA records.

For delegation glue records, the resolver is the consumer.

> The real consumer is the
> application initiating the request of the resolver for an address.

When you type "http://www.google.com" into your web browser, your web
browser does not care at all what address records the root server gave
for a.gtld-servers.net to the resolver; only the resolver cares.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 15 Jun 2009 07:30:06 +0200

> For delegation glue records, the resolver is the consumer.

And those records should never be promoted to an answer section.

---

From: Michael Sinatra <[email-masked]>
Date: Sun, 14 Jun 2009 22:53:27 -0700

> very emotionally against.

As someone with more of an operational background, I do not care to have 
the protocol (or even the operation of the root nameservers) changed to 
make life slightly better for one implementation, when there are 
multiple independent implementations that don't seem to have a problem 
with A and AAAA glue.  The caching resolvers I operate are all 
dual-stack, so I'd rather not put an additional layer of complexity in 
the protocol or in the operation of the roots, and making the answers 
dependent on the transport protocol adds complexity.

I think your fix is worse than the problem.

I wouldn't support such an I-D, but I am not really the one to ask--I am 
more of an ops person and this is my first post to this list, after 
years of lurking.

michael

---

From: Danny Mayer <[email-masked]>
Date: Mon, 15 Jun 2009 07:34:08 -0400

> for a.gtld-servers.net to the resolver; only the resolver cares.

If I understand this correctly, you want the name servers to behave
differently at the root from the rest of the servers. What operator is
going to want to have a customized server just for the root?

Danny

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 15 Jun 2009 04:39:48 -0700

> going to want to have a customized server just for the root?

No, 8 of the 13 root servers already behave the way I suggest, and the
other 5 are using the same software as some of those 8 (according to
fpdns), so there's no custom software involved.

Also, I've never suggested that this is something that should only
apply to the root servers, it's just the only concrete example I have.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 15 Jun 2009 12:28:30 +0000

we've had this debate before.  the way it ends is, if your ability
to reach a nameserver depends on the order of RRs in the additional
data section, then you are doomed, and no ordering policy can save
you.  hopefully someone will distill the debate from their archives.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 15 Jun 2009 14:44:41 +0200

> you.  hopefully someone will distill the debate from their archives.

+1

Best regards,
   Wouter