On 12/17/2003 1:20 PM, Pekka Savola wrote:
> I'm not sure whether I'm imagining things or whether this is a real
> problem .. comments please! :-)
> Am I imagining things or is "additional section selection/filtering" a
> really bad idea especially if at least one entry of each available
> record type is not represented? And the filtering methods proposed
> earlier and in particular in draft-hall-qtype-addr-01.txt section 4
> are pretty broken?
>
> If so, maybe there should be some kind of data on how many records of
> each type exist (or at least, "at least one record of type Foo
> exists"), even though there was no space for all the records to be
> sent?
The concern is valid. I asked the same question to namedroppers when I was
writing the draft (see <[EMAIL PROTECTED]> attached).
A couple of critical points to keep in mind here. First is that RFC 1886
(the ADDR spec) already defined a just-include rule for additional data,
and draft-hall-qtype-addr-01 just tries to optimize the existing rule.
Second is that getting incomplete additional-data is going to be
unavoidable -- perhaps a legacy cache only returns the A RRs in subsequent
responses, one of which goes to your host. Given these considerations,
incomplete additional-data is just something that clients are going to
have to deal with regardless of what we do here. It's a fact of life.
There are ways to improve the clarity but the available mechanisms all
have costs and I'm not sure the costs are worth the benefits, especially
given the realities above. Setting TC just means a whole lot more TCP
requeries, but for very little gain in a very large number of cases (if
the world is 90% IPv4-only now, then 90% of the TC responses will be
unnecessary today; reverse this for whenever IPv6 goes to 51%). Or you
could use some other kind of flagging mechanism (add 128 to the code
value, perhaps, or whatever), but DNS is already too fragile for my liking
and I'm not keen on making it moreso.
There is a free fix to most problem cases, which is to use EDNS.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
--- Begin Message ---
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 PROTECTED] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
--- End Message ---
