Secondly, I think that maintaining rationale in documents is a good idea. E.g., there is a requirement in a document in another WG. I had been asked to see if a proposed specification met the requirements. When I came to the requirement, the words made no sense to me. I asked the WG what the requirement meant and was only given a change history (MUST to MUST NOT to MUST on certain revisions). Even searching the archives, there has never been an explanation of why it was even discussed (the context).
Granted, the issue here is small, and traditionally we leave change history to the mail archives. In this case, the example of QTYPE=ANY isn't significant to the document. It doesn't impact the text as stated in the document but it impacts the suggested replacement (above), so it's not all that important.
In summary, I propose replacing this inside section 1.3:
# the # recommendation is to always keep at least one authoritative server # IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
With
"the recommendation is to always make available equivalent copies of all
zones on all commonly used network layers. E.g., the set of authoritative
servers for each and every zone ought to include at least a server on IPv4
and IPv6 while both are commonly carried on the Internet. In addition,
recursive name servers ought to be able to queried and be able to itself query servers on all network layers in common use."
I don't think that more detail is needed beyond that.
At 12:09 +0300 5/4/04, Pekka Savola wrote:
Hi,
On Fri, 30 Apr 2004, Alain Durand wrote:> "Substantially" - because of the glue question and the truncation > issue in DNS, you can't specify that the answer "is" the same. > > Another case to consider is the the query type any. If my v4 > recursive server does not share the same memory (RAM) as my v6 server, > chances are strong that the caches in the two will differ over time. > QTYPE ANY queries ask for "what you have" about a name, not the > complete data at the name (as far as an authoritative server is > concerned). It's reasonable to consider that the exact responses from > the two servers will differ, regardless of the fact that they are on > different network layers.
Thank you for this clarification I now understand you point. We might want to add text that only focus on those issues. This is an operational issue that is somehow different from the one described in the transport guideline document. I think it should go into the ipv6-dns-issues document, which is the one you commented on first, so I withdraw my previous comment.
Does this need to be stated? As Rob explained, QTYPE=* is a beast that's not really used except by folks playing with "dig" and "nslookup"; the resolvers don't use them, so we might not need to care about them?
I haven't edited ipv6-dns-issues on this subject, but if there are concrete suggestions which do not conflict with the transport guidelines document, shoot! :)
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer
If time travel were ever to be realized, public key crypto is toast. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
