Thanks a lot for good comments. (I also took your additional message into account.)
I think this causes us to re-think the TTL/impartial additional-data parts and how it's supposed to operate a bit -- so I'd welcome the others to look at this as well.. I've also updated the temporary copies at: 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 (There is no diff between these two pre-versions though.) Inline.. On Tue, 6 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] [EMAIL PROTECTED]@C#:H 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. > 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])"? Good point. Revised as follows: <t>Temporary addresses defined in <xref target="RFC3041">RFC3041</xref> (sometimes called "privacy addresses") use a random number as the interface identifier. Publishing DNS records relating to such addresses would defeat the purpose of the mechanism and is not recommended. If absolutely necessary, a mapping could be made to some non-identifiable name, as described in <xref target="RFC3041"/>.</t> > 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). 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? Let me try to understand your bug example. Would you consider it a bug that a DNS cache would have cached both A and AAAA records with different TTLs, and when the first-to-expire expires, the DNS cache does not re-query the one that expired? Should it re-query that? I mean, if the cache would return records in an additional section (e.g., when queried for MX record), but would not return all of them (because some of them had expired), would you consider this a bug? (See below for text update.) > 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. I think it should be reasonable to suggest that the TTL should be the same (because that simplifies the operations for those servers which have to handle the both) unless there are valid reasons (like the ones you cite) for handling them differently. As for the current wording I've adopted (this probably requires more tuning still): 4.4 The Use of TTL for IPv4 and IPv6 RRs The behaviour of DNS caching when different TTL values are used for different records of the same name requires explicit discussion. For example, let's consider a part of a zone: 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 When a caching resolver asks for the MX record of example.com, it gets back "foo.example.com". It may also get back either one or both of the A and AAAA records in the additional section. So, there are three cases about returning records for the MX in the additional section: 1. We get back no A or AAAA records: this is the simplest case, because the we have to query which information is required explicitly, guaranteeing that we get all the information we're interested in. 2. We get back all the records: this is an optimization as there is no need to perform more queries, causing lower latency. However, it is impossible to guarantee that in fact we would always get back all the records; however, one could try to work in the direction to try to ensure it as far as possible. 3. We get impartial results: this is indistinguishable from the previous case, and problematic as described in the next section. So, we assume we get back both A and AAAA records of foo.example.com, or the resolver explicitly asks, in two separate queries, both A and AAAA records. After 100 seconds, the AAAA record is removed from the cache because its TTL expired. The cache must re-query the AAAA record when its TTL expires to avoid the situation where there would be a window of 200 seconds when incomplete information is returned from the cache. XXX: if this is not done, is it a bug? To simplify the situation, it is recommended to use the same TTL for all the records referring to the same name. However, there are some scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where a different strategy is preferable. More issues with caching and A/AAAA records is presented in the next section. > 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). Yes, the intent was "query name", as the additional length of the packet for other reasons was also discussed a bit. Possibly this would call for more text? <t>Consider the cases where the query name is so long, the number of he additional records (originated from "glue") is so high, or for other easons that the response must either be runcated (leading to a retry with TCP) or some of the additional data emoved from the reply. [...] I added "query name" there and "or for other reasons" -catchall, but if you have better ideas what to add here, I'm all ears :) > 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. Yes, this is the intent. I've changed "security association" to "security relationship" to make it clearer that the terms don't overlap :) > 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". The wording "at the site where the prefixes are delegated" seems to be unclear. I've reworded it to "at the site where the prefixes are delegated to" to make it clearer. I've also tried to clarify the parentheses by spelling it out: 7.5 DDNS with Dynamic Prefix Delegation In cases where a prefix, instead of an address, is being used and updated, one should consider what is the location of the server where DDNS updates are made. That is, where the DNS server is located: 1. At the same organization as the prefix delegator. 2. At the site where the prefixes are delegated to. 3. Elsewhere, as specified by the delegated site; this is security-wise typically equivalent to the previous case. On one hand, securing the DDNS relationship for prefix delegation is simpler if DNS server and the prefix delegator are in the same administrative domain, and may be more difficult otherwise. On the other hand, if the DNS server resides where the prefixes are delegated to, it is easier to manage reverse DNS updates as they can be done within a single administrative entity. Similarly, then configuring the reverse DNS is typically simpler as well (e.g., if one wanted to insert a wildcard record). > ===================== > > 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). It was intentional notation, but removed as it doesn't seem necessary. > 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/ ? I like how it is at the moment because it's 'IP address'-based rather than just address-based. But I've changed this as you say (two places) as I think this is rather equivalent in any case. (Same for section 7.3.) > (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/ ? Yep. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
