Subject: regarding the respsize draft: preferring glue of certain types

From: Paul Vixie <[email-masked]>
Date: Mon, 14 Jul 2003 10:22:16 +0000

i may have a conflict during today's meeting in which case i'd like to
present my recent thoughts about respsize here and hope that kato or
others will represent them in real time.  these issues are highly topical
since they will drive the policies by which IANA will add, or not add,
AAAA RRs for root and tld servers.

---

in the event where a delegation response is going to be truncated, it
is desireable that glue of the appropriate type be added preferentially.
if the query arrived by IPv4, then A RRs ought to be added first; if
the query arrived by IPv6, then AAAA RRs ought to be added first.

this assumes that a dns client will wish to use the same protocol for
reaching the designated servers as it used to reach the delegating
server.

to prevent pathological starvation, at most one glue rrset of each type
should be present even in a truncated response, unless the rrsets
are such that the smallest rrset of each glue type would not fit.

since truncation must be on rrset boundaries, smaller rrsets should be
added before larger ones.  if the smallest rrset of any type is still
too large to fit, then the delegation response's additional data section
will be empty.

---

(before anybody suggests that we add a "glue order" option in EDNS, keep
in mind that when EDNS is available, truncation will only rarely occur,
even with both kinds of glue records and full dns security signatures.
this entire discussion has to do with imputing the best interests of dns
clients who lack the ability to express either preference or capability.)

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: [email-masked]
Date: Tue, 15 Jul 2003 22:43:21 +0900

>reaching the designated servers as it used to reach the delegating

	can't we provide like "one A glue, then one AAAA glue, then A glue,
	then one AAAA glue ..." ?  this way dual stack querier would be able
	to get n A glue records and m AAAA glue records after truncation.

itojun

---

From: "D. J. Bernstein" <[email-masked]>
Date: 15 Jul 2003 16:09:07 -0000

> are such that the smallest rrset of each glue type would not fit.

I found this unnecessarily confusing. Can we please reserve the word
``truncation'' for the TC bit? See RFC 1035.

There are three separate issues:

   (1) the strategy for adding delegation records;
   (2) the strategy for adding AU+AR to authoritative responses; and
   (3) how to handle truncation.

For example, with tinydns,

   (1) NS and corresponding A glue is always added to delegations;
   (2) AU (or AU+AR) is added to authoritative answers only if the
       entire AU (or AU+AR) ends before the 512-byte boundary; and
   (3) if truncation is required, all records are eliminated.

As for mixing A and AAAA in delegations, I don't understand the benefit
to having both in the first place. If a child server provides only one
protocol, there's no decision for the parent to make. If a child server
provides both protocols, and the query to the parent was made through
IPv4, I don't understand the point of including AAAA; and vice versa.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Randy Bush <[email-masked]>
Date: Wed, 16 Jul 2003 07:15:50 +0200

> the query arrived by IPv6, then AAAA RRs ought to be added first.

this assumes that the transport available between the dns resolver and
the dns server is correlated to the transport between the application
client and the server.  i am not sure this assumption holds.

randy

---

From: Rob Austein <[email-masked]>
Date: Wed, 16 Jul 2003 07:56:42 +0200

> client and the server.  i am not sure this assumption holds.

I am fairly certain that there are cases in which we expect this
assumption not to hold, since we expect to use dual-stack recursive
name servers to avoid the namespace fragmentation problems described
in draft-ietf-dnsop-ipv6-transport-guidelines-00.txt.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 16 Jul 2003 06:09:31 -0000

Randy Bush writes:
> client and the server.

No. The issue is delegations, particularly big delegations such as the
DNS root servers' delegation of .com to 13 different DNS servers. Both
levels are DNS; there isn't any ``application client'' here.

Suppose that a .com DNS server has both A and AAAA. I don't see why the
root servers would ever want to provide both addresses. Specifically:

   * If the query shows up through IPv4, why bother sending the .com
     server's AAAA address? Obviously the resolver is capable of
     reaching the A address.

   * If the query shows up through IPv6, why bother sending the .com
     server's A address? Obviously the resolver is capable of reaching
     the AAAA address.

Vixie was suggesting omitting AAAA's past the 512-byte limit in the
first case, and A's past the 512-byte limit in the second, but I don't
see any use of the extra records even if they all fit into 512 bytes.

---

From: Jim Reid <[email-masked]>
Date: Wed, 16 Jul 2003 03:14:40 -0700

>>>>> "djb" == D J Bernstein <[email-masked]> writes:

    djb> As for mixing A and AAAA in delegations, I don't understand
    djb> the benefit to having both in the first place. If a child
    djb> server provides only one protocol, there's no decision for
    djb> the parent to make. If a child server provides both
    djb> protocols, and the query to the parent was made through IPv4,
    djb> I don't understand the point of including AAAA; and vice
    djb> versa.

You're making a false assumption that the transport protocol used for
querying the server matters to the end client. An authoritative server
could well be answering queries over IPv4 from a dual-stack full
service resolver that's serving IPv6-only stub resolvers. Those end
clients will not be happy to get A records instead of AAAAs. Or that
full service resolver may have a (policy) preference for querying over
IPv6 and only uses IPv4 as a last resort. These scenarios may well be
somewhat hypothetical but they are not unreasonable or unrealistic.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 16 Jul 2003 22:12:29 -0000

Jim Reid writes:
> querying the server matters to the end client.

No.

We're talking about delegations. A parent DNS server, specifically one
of the root DNS servers, provides child DNS server addresses, such as
the .com DNS server addresses.

The program using the .com DNS server addresses is the same DNS resolver
that was talking to the root DNS server. Why is it useful for this DNS
resolver to receive _both_ an A record and an AAAA record for a single
.com DNS server? If it reached the root DNS server through IPv4, for
example, then why would it want AAAA records for the .com DNS servers?

---

From: Jim Reid <[email-masked]>
Date: Thu, 17 Jul 2003 04:40:14 -0700

>>>>> "djb" == D J Bernstein <[email-masked]> writes:

    djb> The program using the .com DNS server addresses is the same
    djb> DNS resolver that was talking to the root DNS server. Why is
    djb> it useful for this DNS resolver to receive _both_ an A record
    djb> and an AAAA record for a single .com DNS server? 

Because this .com server has NO WAY of knowing if the querying server
has a preference for IPv6 or IPv4 resource records. Or which of these
is "better" for the resolving server. [And, by implication, that
resolving server's clients which could include forwarding name
servers.] My earlier mail why explained your assumption about using
the query's transport protocol to determine this was flawed. I gave
two counter examples: four if you swap the IPv6 issues for IPv4 and
vice versa. Others have made the same point. I'm sorry if you are
unable to understand this.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Jul 2003 09:14:38 +0300 (EEST)

> example, then why would it want AAAA records for the .com DNS servers?

Why do you think the resolver moving from parent to child is the *only* 
one using that information ?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Mohsen Souissi <[email-masked]>
Date: Thu, 17 Jul 2003 09:52:12 +0200

On 16 Jul, D. J. Bernstein wrote:
| Randy Bush writes:
| > this assumes that the transport available between the dns resolver and
| > the dns server is correlated to the transport between the application
| > client and the server.
| 
| No. The issue is delegations, particularly big delegations such as the
| DNS root servers' delegation of .com to 13 different DNS servers. Both
| levels are DNS; there isn't any ``application client'' here.
| 
| Suppose that a .com DNS server has both A and AAAA. I don't see why the
| root servers would ever want to provide both addresses. Specifically:
| 
|    * If the query shows up through IPv4, why bother sending the .com
|      server's AAAA address? Obviously the resolver is capable of
|      reaching the A address.
| 
|    * If the query shows up through IPv6, why bother sending the .com
|      server's A address? Obviously the resolver is capable of reaching
|      the AAAA address.

==> You know that the second scenario cannot happen today unless the client
can get some IPv6 address for the root server. As far as I know, even
if some root servers already run IPv6, their IPv6 address is not
present in the root zone. Putting AAAA glue records in the root zone
for .COM or whatever TLD is the only way to let iterative resolvers
reach TLD servers in both IPv4 and IPv6 as soon as they receive
referrals from root servers. Maybe you want to read the IESG
recommendation for RC Editor to add explicitely the note below to
RFC1886bis (becoming DS) in order to make things very clear:

"
RFC Editor note:

In the Abstract please change:
s/Domain Name System/Domain Name System (DNS)/
s/RFC1886/RFC 1886/

Please add this at the end of the Introduction section:
        The IP protocol version used for querying resource records is
        independent of the protocol version of the resource records; e.g.
        IPv4 transport can be used to query IPv6 records and vice versa.
"

In one word, the parent is not supposed to decide on behalf of the
client, which version of IP it has to use to reach the authoritative
nameservers for the child.

Hope this will help,

Mohsen.

| 
| Vixie was suggesting omitting AAAA's past the 512-byte limit in the
| first case, and A's past the 512-byte limit in the second, but I don't
| see any use of the extra records even if they all fit into 512 bytes.
| 
| ---D. J. Bernstein, Associate Professor, Department of Mathematics,
| Statistics, and Computer Science, University of Illinois at Chicago
| #----------------------------------------------------------------------
| # To unsubscribe, send a message to <[email-masked]>.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Randy Bush <[email-masked]>
Date: Thu, 17 Jul 2003 14:29:11 +0200

> You know that the second scenario cannot happen today unless the client
> can get some IPv6 address for the root server.

not necessarily.  i could v4 to root server, v4 to com server, v6
to foo.com server, and so forth.

randy

---

From: Mohsen Souissi <[email-masked]>
Date: Thu, 17 Jul 2003 14:33:18 +0200

On 17 Jul, Randy Bush wrote:
| > You know that the second scenario cannot happen today unless the client
| > can get some IPv6 address for the root server.
| 
| not necessarily.  i could v4 to root server, v4 to com server, v6
| to foo.com server, and so forth.

==> I was talking about querying the root-servers in v6 and having the
AAAA for .com as described in the example ;-)

Mohsen.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 17 Jul 2003 18:02:51 -0000

> one using that information ?

Do you have some other use for the name a.gtld-servers.net?

Obviously there's an issue if you (1) want to provide both A and AAAA
records for your HTTP server, and (2) use the same name for your HTTP
server and your DNS server. But #2 is an administrative error.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 17 Jul 2003 18:37:48 -0000

Randy Bush writes:
> i could v4 to root server, v4 to com server, v6 to foo.com server

Sure. However, if the foo.com server has _both_ v4 and v6 addresses,
then you could also reach it through v4. Furthermore, the .com server
knows this, because you reached the .com server through v4.

So why should the .com DNS server bother giving you _both_ v4 and v6
addresses for the foo.com DNS server? What exactly is the benefit that
outweighs the cost of building and sending larger packets?

Let me emphasize again that we're talking about DNS server addresses in
delegations, not about HTTP server addresses.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 17 Jul 2003 18:31:31 -0000

Mohsen Souissi writes:
> As far as I know, even if some root servers already run IPv6, their
> IPv6 address is not present in the root zone

The resolver is configured with the addresses of the root DNS servers,
or of servers that know the root addresses. There are two possibilities
at this point:

   (1) The resolver can't reach IPv6 addresses. This means that the
       initial addresses have to be A---otherwise they _do not work_.
       Similarly, all the subsequent DNS server addresses used by that
       resolver have to be A---otherwise they _do not work_.

   (2) The resolver can reach IPv6 addresses. In this case, if a DNS
       server supports both IPv4 and IPv6, why would the resolver be
       interested in the DNS server's IPv4 address? What's the benefit?

The rule I'm suggesting is ``In a delegation, if a child server has only
A records, provide those records; if it has only AAAA records, provide
those records; if it has both, provide A to clients that asked through
IPv4, AAAA to clients that asked through IPv6.''

The records that I'm eliminating are the same ones that Vixie was
talking about eliminating. The difference is that he'd provide them if
they fit into 512 bytes (which they don't, for the high-level servers),
while I would never provide them. The existing AAAA protocol would seem
to require them in all circumstances (forcing truncation and TCP for the
high-level servers), which is clearly a mistake.

Let me emphasize that we are talking about _delegations_. These are DNS
server addresses used by the resolver. They are not web server addresses
passed through the resolver to browsers with varying connectivity.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 18 Jul 2003 10:43:14 +0300 (EEST)

>        resolver have to be A---otherwise they _do not work_.

You're assuming that if you reach one IPv4 address, you can reach all.
 
>        interested in the DNS server's IPv4 address? What's the benefit?

You're assuming that if you reach one IPv6 address, you can reach all (, 
and that you have no use for IPv4 addresses for fallback).

Also, assume the resolver is caching data.  Someone else with different 
transport protocol capabilities asks the resolver about the addresses of 
these servers -- and get a partial response.

Building assumptions like these doesn't sound like the way to ensure the 
robustness of DNS.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 18 Jul 2003 09:14:36 -0000

Pekka Savola writes:
> Someone else with different transport protocol capabilities asks the
> resolver about the addresses of these servers -- and get a partial response.

So what? Let's focus on what actually works from the user's perspective,
not on religious concepts such as ``partial responses.'' Can you give a
concrete example showing how the user would encounter a failure?

To forestall irrelevant examples, let me emphasize once again that we're
talking about DNS server addresses, not HTTP server addresses.

> You're assuming that if you reach one IPv4 address, you can reach all.

Ever heard of ``global addressing''? Right now, you aren't on the
Internet if you can't reach the entire public IPv4 address space. In the
future, if everyone with a public IPv4 address acquires a public IPv6
address, you'll be able to deploy a site that doesn't have any IPv4
access. Either way, the assumption is valid.