Hi, Thanks for the insistence. I think this should address your concerns..
Working copies at: http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-06pre-diff.html http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-06pre.txt (I've only changed what you're commenting, and what Iljitsch was saying about DNS resolver discovery on v6-only networks.) On Tue, 20 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] [EMAIL PROTECTED]@C#:H wrote: > > But as this is the current specification situation, there's not much > > one can do about it. If you want to be positively sure that you > > always get all the records, you have to query them explicitly > > yourself, with the record type you're interested in getting. > > Okay, so I guess my position is not so different than yours...but one > thing I'd like to emphasize is that the application (the SMTP server > in this case) should not assume anything in the additional section, > and should basically have the ability to fetch missing additional > data. In that sense, I disagree on your saying that "the SMTP servers > should not have to have any such code at all". > > But at the same time, it's okay for me to mention that it may help if > we use the same TTL for A and AAAA RRsets in this type of case. It's > just a tip that may optimize the thing, though; I think > "recommendation" is a strong word for this. I'm not sure if I fully agree with this but as I don't have a strong opinion, I've just taken what you say. > Hmm, the sense was not really clear at least to me with the literal > meaning of "impartial". But I'm not an expert on English wording and > I don't have a better suggestion, so I'd leave this to you (I mean > it's okay if you want to keep it). (Note that the latest version of > 05pre still has this term in Section 4.4, which has been Sect. 4.5 so > far). I reworded that to "missing some RRsets". > additional records (originated from "glue") is so high, or for other > reasons that the response must either be truncated (leading to a > retry with TCP) or some of the additional data removed from the > reply. > > It's hard to parse the part "or some of the...from the reply". Do you > mean: > > ...or for other reasons that the response must be truncated (leading > to a retry with TCP) or some of the additional data must be removed > from the reply. > ? Yes, changed. > In the last paragraph, > ... The operational fix > for this is having the DNS server implementations return a warning > when the administrators create the zones which would result in too > much additional data being returned. > > I think this statement is too strong, since it sounds like this is the > only operational fix. I'd suggest to reword this e.g., "An > operational fix for this", etc. Agree, changed. > 4.5 The Use of TTL for IPv4 and IPv6 RRs > > 3. We only get back A or AAAA records even if both existed: this is > indistinguishable from the previous case, and problematic as > described in the next section. > > s/next/previous/ ? OK > As a more essential comment, it's still not clear to me what the > problem described in the previous section is...are you particularly > referring to the 3rd paragraph of Section 4.4, that is, (e.g.) > returning A records to an IPv6-only node? Yes, that's the problem. I can't think of ways to make it clearer. (I'd also like to get to the situation where every v6 enabled node that would prefer to use v6 if possible wouldn't have to do an explicit query for AAAA records every time it's sending mail...) > 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. It would be useful for the cache to > re-query the AAAA record or discard the A record when the shorter TTL > (in this case, for the AAAA record) expires; this would avoid the > situation where there would be a window of 200 seconds when > incomplete information is returned from the cache. However, this is > not mandated or mentioned by the specification(s). > > This paragraph seems to have several problems: > > 1. it's not clear to me why this paragraph begins with "So,". Do you > mean something like this? > "In order to discuss the case where we have both A and AAAA > records, let's assume we get back both records of foo.example.com, > or the resolver explicitly asks, in two separate queries, both A > and AAAA records." Not quite. The target might have both A and AAAA records, but the resolving host might only get back one set of these. We discussed the other case in previous section, so rewording this to: <t>As the third case was considered in the previous section, we assume we get back both A and AAAA records of foo.example.com, or the stub resolver explicitly asks, in two separate queries both A and AAAA records.</t> [...] > 2. in this paragraph, you used the term "resolver". But I'm not sure > what it exactly specifies, partly because you also used the term > "caching resolver" in this section...does the "resolver" mean the > "caching resolver" or the (so-called) "stub resolver"? Similarly, > if you mean the "caching resolver" in "It would be useful for the > cache to..." (I believe you do), then I'd suggest to reword it as > "It would be useful for the caching resolver to...". In the above paragraph, "resolver" meant the stub resolver. Reworded. I don't think we can get much more by honing the terminology as stub resolvers can also include caching, but changed to like: <t>After 100 seconds, the AAAA record is removed from the cache(s) because its TTL expired. It would be useful for the caching resolvers to discard the A record when the shorter TTL (in this case, for the AAAA record) expires; [...] > 3. it might be controversial whether "it would be useful for the cache > to re-query the AAAA record". This behavior is similar to BIND8's > "fetch-glue" feature (though the caching server with fetch-glue > being on does not return the missing additional data to the stub > resolver during re-fetching it). But ISC has deprecated the > feature in BIND9: (from BIND9 ARM) "This is now considered a bad > idea and BIND 9 never does it." I don't know the full detail of > this discussion, but there should be a clear reason for this. OK, I'm fine with dropping re-querying unless there are other opinions; I'll just keep the discarding part. (See above.) > [going to the last paragraph of Section 4.5] > 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. > > As I already said, "recommended" is too a strong word, IMO. I'd also > like to add a note that applications should not make or depend on a > particular assumption on the content of the additional section. So, > I'd revise this part like this: > > To simplify the situation, it might help to use the same TTL for > all the resource record sets referring to the same name, unless > there is a particular reason for not doing so. However, there are > some scenarios (e.g., when renumbering IPv6 but keeping IPv4 > intact) where a different strategy is preferable. > > Thus, applications that use the response should not rely on a > particular TTL configuration. For example, even if an application > gets a response that only has the A record in the example described > above, it should not assume there is no AAAA record for > "foo.example.com". Instead, the application should try to fetch > the missing records by itself if it needs the record. > > (Note that I use "resource record set(s)" instead of just "record(s)" > where I think more appropriate). I don't think "recommends" is too strong, but I took you suggestion. (I also changed some "record(s)" to "RRset(s)" elsewhere in the document where that is appropriate.) -- 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
