Subject: incorporating just-include; dealing with truncation

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 24 Nov 2003 14:22:54 -0600

Although I've argued against just-include-AAAA as a prima strategy (and
for good reasons), that approach does have significant merit in those
cases where A RRs would be included as additional data, but where AAAA RRs
would not. Thus, even though I'm not backing that approach for all
queries, I do plan on incorporating it into the updated qtype=addr draft
as a secondary mechanism for use whenever another query would produce A
RRs as additional data. This approach seems to recognize and incorporate
the strengths of both models, but without mandating that the weaknesses of
either model in isolation also be embraced as a cost of doing business.
Specifically, I'm specifying that qtype=addr be provided as a way for
dual-stack systems to request all of the addressing RRs defined for a
target domain name, and also specifying a just-include algorithm that
should be used with lookups that would produce A RRs as additional data.

One of the sticky points that I raised about just-include has to do with
message size, and what to do with truncated answer sets. What I'm going to
propose here is that if only one of the addressing RRsets can fit in the
message without causing truncation, favor the address type that matches
the protocol used by the query. For example, if the query arrived via
IPv4, then favor the A RRs in the answer and truncate the AAAA RRs if
necessary. Similarly, if a query arrived via IPv6, then favor the AAAA RRs
in the answer and truncate the A RRs if necessary. This rule would take
effect whenever a response would include A RRs as additional data, such as
responses to MX queries, glue data, and so forth.

The nice thing about this approach is that it's transitional; as hosts are
defined with single-stack addresses (either with IPv4 now, or IPv6 in the
distant future), the focus naturally moves along towards the single
addressing syntax in use, and the burden is (appropriately) at its highest
as hosts are defined with dual-stack addresses.

I've got a couple of relatively minor issues here. First of all, what
should be done about the TC flag? Since this rule would only apply to
additional data, the TC flag isn't mandatory (and has some associated
costs) but it would be useful (and its absence would also have costs). On
the one hand, if the TC flag is enabled for incomplete responses, then
single-stack hosts may end up burning costs on TCP requeries for no
meaningful data. On the other hand, if the TC is not enabled, then
dual-stack hosts won't be able to tell that the target supports multiple
address types. Since the planned algorithm favors the address family in
use, however, this may not be so bad (EG, who cares if a dual-stack host
doesn't learn about IPv4 addresses, if it wanted to use IPv6 addresses
anyway). Of course, just because a particular client uses IPv6 for DNS
lookups doesn't necessarily mean that all of the other applications on
that host are capable of supporting IPv6, so the absence of the
information can be critical. I can go either way on this, but I think that
in general it would be easiest to disable TC in these responses, and put
the onus on (the relatively newer) IPv6-aware resolvers to either issue
followup requests for the missing data, or to use EDNS, or whatever. That
seems to be easier than forcing legacy IPv4 resolvers to use TCP to get
meaningless data.

Secondary issue is procedural/administrative: since this algorithm will
affect all of those scenarios where IPv4 address RRs are returned as
additional data, does this document need to "update" all of those specs?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

--
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/>