>>>>> On Thu, 25 Mar 2004 17:18:33 +0200 (EET), >>>>> Pekka Savola <[EMAIL PROTECTED]> said:
> For up-to-date copies, see: > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre.txt > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre-diff.html I'm going to make comments on the 05pre revision to avoid making duplicate comments. (I still must admit I may not have been careful about the last call thread and can make duplicates. Please just ignore duplicate ones if any). Overall, I think this documetn is accurate and very useful. Some relatively minor comments below: Substantial (or not-so-editorial) comments: 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 But, in my understanding, the sense of the discussion in RFC3363 ([2]) is that DNAME in the reverse tree is deprecated for the reverse side of the A6 usage. That is, the usage for constructing multi-level, hierarchal reverse trees, particularly with bitstring labels. Perhaps I misunderstood the sense, in which case I hope someone will correct me. Even if I'm correct, this is probably a result of the ambiguous wording in RFC3363. But I believe this document could still be a bit clearer on the meaning of "not recommended". 2. Section 2.2 (Privacy (RFC3041) Address) Privacy addresses (RFC3041 [9]) use a random number as the interface ... "Privacy address" is not really correct as a technical term. RFC3041 calls this "temporary address". I guess the dns-issues draft wanted to make the intention of the address (i.e. privacy purposes), but I still think it should use the correct term with additional explanation. For example, how about saying "Temporary addresses (for privacy purposes defined in RFC3041 [9])"? 3. Section 4.4 (The Use of TTL for IPv4 and IPv6 RRs) example.com. 300 IN MX foo.example.com. foo.example.com. 300 IN A 192.0.2.1 foo.example.com. 100 IN AAAA 2001:db8::1 ... ... So, in this particular case, there is a window of 200 seconds when incomplete information is returned from the cache. I don't see what's wrong with this. In this case, the lost information would be "additional" one (returned in the additional section) after all. If the client (probably an SMTP server in this case) needs the missing AAAA, it can ask for the missing RR(s) separately (otherwise, I'd call this a bug in the client). So, Therefore, when the same name refers to both A and AAAA records, these records should have the same TTL. I don't see a valid reason for this either. Moreover, I can even think of a case we want to use different TTLs for A and AAAA RRsets. For example, if I'm going to renumber an IPv6 address of a host while keeping IPv4 addresses on that host, I might want to use a shorter TTL for the AAAA RRset but a longer, stable TTL for the A RRset. 4. Section 4.5 (Behaviour of Glue in Mixed IPv4/IPv6 Environments) (second paragraph) Consider the case where the query is so long or the number of the additional ("glue") records is so high that the response must either be truncated (leading to a retry with TCP) or some of the additional data removed from the reply. The "the query is so long" part is not really clear. I guess the authors tried to talk about the case where the query *name* is so long, which should be copied to the response and may make the response long too. However, the original text could also read to mean "the query *packet* is so long", and, in this case, the intention is unclear (since there are other possibilities that may make the query packet long, e.g., EDNS0 pseudo RR(s) and are not necessarily related to the length of the response). 5. Section 6 (Considerations about Forward DNS Updating) (second paragraph) Typically forward DNS updates are more manageable than doing them in the reverse DNS, because the updater can, typically, be assumed to "own" a certain DNS name -- and we can create a form of security association with the DNS name and the node allowed to update it to point to a new address. (this is a mostly editorial comment) I think "security association" is a misleading term here because it sounds like something related to IPsec (but it seems to me that the original intention was more generic). I guess the authors perhaps tried to express the intention by adding "a form of" before "security association", but the text could explicitly be clearer. 6. Section 7.5 (DDNS with Dynamic Prefix Delegation) (first paragraph) That is, whether the DNS server is managed by the same entity as the prefix delegator, at the site where the prefixes are delegated, or elsewhere (which is typically equivalent to the latter). (again, mostly editorial) the parenthesized part is not really clear. First, what's the antecedent of this part? I guess it is "the point where the DNS server is managed", but it could also read to specify "elsewhere". Secondly, what does "the latter" at the end of the sentence specify? I guess it's "the site where the prefixes are delegated", but again, it could also specify "elsewhere". ===================== Editorial comments: 1. Section 1.1 (Representing IPv6 Addresses in DNS Records) (first paragraph) PTR records in the nibble format under the ip6.arpa. -tree. Is the "dash" (-) character before "tree" intentional? Probably so, but I was not sure whether this is a typo or an intentional notation. In any case, I think we can even remove the dash (not a strong opinion, though). 2. Section 6.2 (Dynamic DNS) (third paragraph) for the hostname; the second must be configured explicitly unless one chooses to trust the IP address -based authentication (not a good idea); s/address -based/address-based/ ? (fourth paragraph) address; that way, the node can start lowering the DNS TTL if it seems like the address has not be renewed/refreshed in a while. Some discussion on how an administrator could manage the DNS TTL is included in [33]; s/has not be/has not been/ ? 3. Section 7.3 (DDNS with Stateless Address Autoconfiguration) (last paragraph) One way to automate this is looking up the DNS server authoritative (e.g., through SOA record) for the IP address being updated, but the security material (unless the IP address -based authorization is trusted) must also be established by some other means. s/address -based/address-based/ ? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
