At Wed, 7 Apr 2004 11:38:34 +0300 (EEST), Pekka Savola wrote: > > On Tue, 6 Apr 2004, JINMEI Tatuya wrote: > > > > 1. Section 1.1 (1.1 Representing IPv6 Addresses in DNS Records) > > > > In particular one should note that the use of A6 records, DNAME > > records in the reverse tree, or Bitlabels in the reverse tree is not > > recommended [2]. > > > > I think this is an overstatement about DNAME. The text looks meaning > > DNAME is not recommended *in any way* in the IPv6 reverse tree. For > > example, people would read this to mean it is discouraged to use DNAME > > to manage both ip6.arpa and ip6.int zones as described in > > http://www.isc.org/pubs/tn/isc-tn-2002-1.html > [...] > > I'll take this discussion to a separate thread, as this may add some > debate.
<hat wg-co-chair=off author-of-rfc3364=on> As a point of information: RFC 3364 can be read as supporting either of these viewpoints, depending on which parts of it one reads. My bad. The intent was closer to Jinmei's interpretation than Pekka's. DNAME itself has been fairly contentious, but the RFC 3364 discussion (and other debate at that time) was pretty tightly focused on DNAME in the reverse tree as the counterpart to A6 in the forward tree. Other uses of DNAME (including in the reverse tree) were considered out of scope in an attempt to maintain focus on the specific questions about A6 and A6-like use of DNAME. </hat> > You raise a good point. I seem to have been slightly confused here, > thinking that the clients would do somekind of "ANY" or "give me > everything you have about 'name'" queries. > > You can do "ANY" query, but that does not give you the right answer > unless the caching resolvers on the path have also queried for both v4 > and v6 records. So, practically, you have to perform explicit queries > for both A and AAAA records. However, there is a case where you do > not need explicit queries but where you could be led astray: querying > for MX record, as the caches may give you nothing (this leads you to > query both records explicitly), full results, or impartial results. > Here I'm worried of impartial results. > > Or am I missing something and is there some kind of real application > of "ANY" queries? Does anyone use them e.g. on DNS server or stub > resolver implementations? <hat wg-co-chair=off just-another-bozo-on-this-bus=on> This turns out to be a FAQ. Right, QTYPE=* isn't useful in normal operations because of the way it interacts with caching. It's a good debugging tool, but that's about it. Every few years somebody suggests that we can save the world one round trip time by using QTYPE=*, then we have this discussion again until the person who proposed this figures out that the saving is an illusion once one understands the caching behavior. At slightly less regular intervals, somebody who has learned the first lesson suggests that we need a new QTYPE which acts sort of like QTYPE=* but with different caching behavior. So far such proposals have not gained traction, probably because of the size of the installed base and the lack of a demonstrated burning need for a protocol change to address a relatively minor performance hack. I'm not trying to belittle the opposing viewpoints, and I know that at least one of them is on this mailing list, but I suspect the above summary suffices for the purposes of Pekka's question. As far as partial results go: the rules for the additional section are straightforward, but their implications are a bit tricky. Splitting an RRset (anywhere, ever) would be a protocol violation. But it's not a protocol violation to return only N (complete) RRsets, for 0 <= N < M, where M is the maximum number of distinct RRsets that could, in theory, have been included via additional section processing. The only case in which a resolver just depends on additional section processing is the glue case, where it has no other choice. Nit: There's no such thing as QTYPE=ANY. It's QTYPE=*. </hat> . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
