Operational Considerations and Issues with IPv6 DNS
Note: This ballot was opened for revision 12 and is now closed.
(Thomas Narten) Discuss
Discuss (2004-06-18 for -** No value found for 'p.get_dochistory.rev' **)
Overall, there is some useful stuff in this document, but it seems overly long, and not very crisp in what it is trying to say. > over IPv4, and A records over IPv6. The DNS servers must not make > any assumptions about what data to return for Answer and Authority > sections. add "based on the underlying transport used in a query". Actually, after having read the entire document, I wonder about his must; is should good enough? As I point out later, the document has not made a compelling case that the above is required for protocol correctness, vs. just as an optimization. And I might add, if the DNS server has to discard some additional section stuff because the packet will be too big, using the transport as a hint might be better than just flipping a coin... > Temporary addresses defined in RFC3041  (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 ." Actually, registering names of the form "ipv6 address in hex" would be just fine, as it would provide no new information. > Note that it does not seem feasible to provide reverse DNS with the > other automatic tunneling mechanism, Teredo ; this is because the Please don't refer to Teredo as "the other ... mechanism", as it makes it sound like there are only two. Surely, there are many possible. >  Bush, R. and J. Damas, "Delegation of 22.214.171.124.ip6.arpa", > draft-ymbk-6to4-arpa-delegation-00 (work in progress), February > 2003. > Hmm. what is status of this? ID tracker says dead... > 4.1 Use of Service Names instead of Node Names > > > When a node includes multiple services, one should keep them > logically separate in the DNS. This can be done by the use of > service names instead of node names (or, "hostnames"). This > operational technique is not specific to IPv6, but required to > understand the considerations described in Section 4.2 and Section > 4.3. This document should not be making such a general recommendation. Especially not without some context about when/why one might do this. I just asserts "one should". "should" is completely misplaced and lacks context. > 4.2 Separate vs the Same Service Names for IPv4 and IPv6 > > > The service naming can be achieved in basically two ways: when a > service is named "service.example.com" for IPv4, the IPv6-enabled > service could be either added to "service.example.com", or added > separately to a sub-domain, like, "service.ipv6.example.com". Requirment is to use a different name. NOt sure why a subdomain should be the (only) example. At least make clear that the requirment is to use a different name. But this also means that IPv6 vs. IPv4 is not transparent to applications/users, which is a disadvantage. Oh, maybe you want to use a subdomain so you can use a search path??? This seems like a narrow solution, not a general one. > 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments > > > Consider the case where the query name is so long, the number of the > additional records is so high, or for other reasons that the entire > response would not fit in a single UDP packet. In some cases, the > responder truncates the response with the TC bit being set (leading > to a retry with TCP), in order for the querier to get the entire > response later. does one set the T bit if one can't include the additional sections? or if critical info was truncated? > 2. "courtesy" additional data; this could be sent in full, with only > a few RRsets, or with no RRsets, and can be fetched separately as > well but could lead to non-optimal results. better: "... as well, but at the cost of additional queries". > This temptation would have significant problems in multiple areas. this needs to be justified. It is not clear to me what the "significant problem" is. Indeed, is it just poor performance, or incorrectness of result? Please be very clear on this point! Section 4.4 could be more clear that when it starts talking about problems, it is only talking about data in the additional section. Presumably the answer section contains a correct answer. Section distinguishes between "critical" and "courtesy" data (which is good), but then later when talking about problems doesn't make clear which of these two cause problems. Omitting "courtesy" data by definition is never a problem (from a corrrectness perspective). > In the case of too much additional data (whether courtesy or > critical), it might be tempting to not return the AAAA records if the > transport for DNS query was IPv4, or not return the A records, if the > transport was IPv6. However, this breaks the model of independence > of DNS transport and resource records, as noted in Section 1.2. > At this point, the doc is not clear about whether the above problem ocurrs only with critical data. Also, using the transport as a hint seems like it might be better than just flipping a coin... > This temptation would have significant problems in multiple areas. > Remember that often the end-node, which will be using the records, is > not the same one as the node requesting them from the authoritative > DNS server (or even a caching resolver). So, whichever version the > requestor ("the middleman") uses makes no difference to the ultimate > user of the records. This might result in e.g., inappropriately > returning A records to an IPv6-only node, going through a > translation, or opening up another IP-level session (e.g., a PDP > context ). Don't follow. For non-critical Additional Section, one can delete whatever. That shouldn't impact correctness (just performance). Also, don't follow the last part of second paragraph. > The problem of too much additional data seems to be an operational > one: the zone administrator entering too many records which will be > returned either truncated or missing some RRsets to the users. A > protocol fix for this is using EDNS0  to signal the capacity for The operator configures what gets put into additional section? Is this really the case? > Additionally, to avoid the case where an application would not get an > address at all due to non-critical additional data being omitted, the > applications should be able to query the specific records of the > desired protocol, not just rely on getting all the required RRsets in > the additional section. This section has not explained clearly how not including "non-critical" (please use the term you defined earlier, actually) can cause an actual correctness problem. > 4.5 The Use of TTL for IPv4 and IPv6 RRs > > > In the previous section, we discussed a danger with queries, > potentially leading to omitting RRsets from the additional section; > this could happen to both critical and "courtesy" additional data. The above is again really unclear. Is the above a protocol issue, or an implementation issue? > 1. We get back no A or AAAA RRsets: this is the simplest case, > because then we have to query which information is required > explicitly, guaranteeing that we get all the information we're > interested in. Don't know if this is true. If I do an MX query, and don't get back either A or AAAA records, a subsequent query (by the application) may only ask for A records. Thus, at the end of the day, you can't guarantee that both A and AAAA will be in the cache at the same time. > 2. We get back all the RRsets: 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 (the only way to ensure that is to send a > AAAA query for the name after getting the cached reply); however, > one could try to work in the direction to try to ensure it as far > as possible. Again, not true. The only way to ensure you got all the RRsets is to separately query for both A and AAAA (not just AAAA). > 3. We only get back A or AAAA RRsets even if both existed: this is > indistinguishable from the previous case, and problematic as > described in the previous section. I haven't been entirely convinced by the previous section, actually. > 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; 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 recommendation seems broken. I also don't understand what the problem is. > 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. the above seems to make assumptions about what applications do. Yet those assumptions directly contradict correct DNS behavior. Is this in fact a real problem (i.e, that apps don't implement the spec correctly in this context)? > The problems are serious because when looking up a DNS name, typical > getaddrinfo() implementations, with AF_UNSPEC hint given, first try provide reference? > configuration. The only (minor) twist is that with SLAAC, the DNS > server cannot tie the authentication of the user to the IP address, > and stronger mechanisms must be used . As relying on IP > Don't understand this sentence. > Dynamic DNS with SLAAC simpler than forward DNS updates in some > regard, while being more difficult in another. s/simpler/is simpler/?? actuall, I don't understand what this sentence is trying to say... > The address space administrator decides whether the hosts are trusted > to update their reverse DNS records or not. If they are, a simple > address-based authorization is typically sufficient (i.e., check that > the DNS update is done from the same IP address as the record being > updated); stronger security can also be used . If they aren't > allowed to update the reverses, no update can occur. I am surprised to see this recommended, given the ease of address spoofing attacks. > However, it is worth noting that in particular with Dynamic DNS > Updates, security models based on the source address validation are > very weak and cannot be recommended. On the other hand, it should be Actually, earlier text seemed to say this was OK in some circumstances... Which is it? > To re-emphasize which was already stated, reverse DNS checks provide > very weak security at best, and the only (questionable) > security-related use for them may be in conjunction with other > mechanisms when authenticating a user. Actually, this document hasn't done a very good job of defining just what the "reverse DNS check" is. There are several variants, and I thought the one that is actually used in practice is the one in BSD that requires both a reverse and forward lookup, with the _forward_ lookup providing the "security", whereas the revers lookup only provides the name to be used in the forward lookup and is by itself meaningless. > 11. References There are a lot of references to IDs here. Even though many are "informative", I suspect that this document would be most useful if it were not published until a good number of those IDs are RFCs (so they can be referenced). It would be good to think hard about which references are like that and whether those documents are ever going to be published.
(David Kessens) Yes
(Steven Bellovin) (was Discuss, No Objection) No Objection
(Brian Carpenter) No Objection
Comment (2005-06-07 for -** No value found for 'p.get_dochistory.rev' **)
Michael Patton notes: My major concern is with the number of references that are still ID. Are these IDs really close enough to completion? Actually, in the process of doing the review I had reason to want to refer to several of the IDs for further info and crosschecking, all the ones that I tried to look up were expired. It's probably of enough importance to get this draft out as an RFC that holding it up for another draft still being revised would be unfortunate. But even some of the informative references are fairly important, so I'm not sure where to go on this...
(Margaret Cullen) (was Discuss) No Objection
(Bill Fenner) No Objection
(Ted Hardie) No Objection
Comment (2004-06-09 for -** No value found for 'p.get_dochistory.rev' **)
In 3.1, the draft says: The solution is to fix or retire those misbehaving implementations, but that is likely not going to be effective. There are some possible ways to mitigate the problem, e.g. by performing the lookups somewhat in parallel and reducing the timeout as long as at least one answer has been received; but such methods remain to be investigated; slightly more on this is included in Section 5. I note that in the recent MARID interim folks who use DNS lookups as part of related spam abatement procedures talked about using parallel lookups for a variety of RRs (including A and AAAA) as though it were common practice for them. In particular,they seem to use a set of mechanisms for information sharing between query threads that may be more generally useful. The loosely parallel mechanism looks like an attempt to game a race condition, and that seems like it is unlikely to give consistent results.
(Scott Hollenbeck) No Objection
(Russ Housley) No Objection
(Mark Townsley) No Objection
(Bert Wijnen) No Objection
(Alex Zinin) No Objection
Comment (2004-06-10 for -** No value found for 'p.get_dochistory.rev' **)
Feedback from gen-art (Spencer and Brian): generally useful document; would benefit mentioning that not all transition mechanisms considered by v6ops or generally possible are under consideration and why. An editing pass would help eliminate things like: Dynamic DNS with SLAAC simpler than forward DNS updates in some regard, while being more difficult in another.