At Wed, 02 Nov 2016 15:10:18 +0900 (JST), fujiw...@jprs.co.jp wrote: > I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to > improve resolver algorithm. > > Please read it and comment.
As promised, here are specific comments on the draft text: - general: the title and file name seem to be too generic for the actual content. I suggest making them more specific, focusing on the subject of this draft. - Section 1 [...] And it may break requirements of resolvers' answers described in Section 3.2. I don't get it. Specifically which requirement does this refer to? And, specifically how this override break that requirement? - Section 3.1 As described above, parent side NS RRSet makes a new zone. Parent side NS RRSet (referral) and glue records are all the information to access servers for the child zone. That is, resolvers SHOULD NOT use child side NS RRSet to iterate zones. There seems to be a logical leap between the first and second paragraph; I don't get why we SHOULD NOT use the child side NS RRset for subsequent iteration simply because the parent NS RRset is used for the iteration first time (which I guess the first para tries to say). In fact, the child side NS RRset might be a more complete, accurate and up to date set of the NS, while some part of the parent NS RRset may be unusable. This is related to the high level comment I made in my previous message - I see and support the seeming background motivation of this requirement, but I believe we need more careful considerations and probably a much less drastic update. - Section 4 However, people sets different NS RRSets with mistakes, or intentionally. Specifically what kind of intent does this "intentionally" mean? btw, there's a typo here: s/sets/set/ - Section 4 If the zone data of name server(s) specified by referrals and specified by zone apex NS RRSet are different, name resolution becomes unstable. I'd suggest changing it "name resolution *may* become unstable", since simply because they are different does not necessarily lead to an unstable behavior. - Section 4 The cache overwrite of NS RRSet may break "Referrals and glue records are information to access servers for child zones" specified by [RFC1034] section 4.2.1. I can't find the quoted text in any of RFC1034, let alone in Section 4.2.1. And, in any case, I don't understand what "may break" means here. Please explain in more detail. - Section 4 The overwrite by zone apex NS RRSet induced security vulnerabilities. In 2012, "Ghost Domain Names: Revoked Yet Still Resolvable" [DUAN2012GHOST] was reported. [...] While I see this incident is relevant to the subject of this draft, I think it can be misleading especially if it's intended to be used to support the current strong recommendation (to which I disagree) of this draft. It may be true that the mastermind behind ghost domain names exploited a larger child-NS TTL with NS RRset replacement behavior of resolvers, I'd say this situation is quite extreme in that the admin of the zone is considered evil for a reason irrelevant to DNS itself and the parent zone tried to kill the delegation without the consent of the child zone admin. In fact, this intent of the child zone admin could even be helpful if they are a good net citizen when there's an outage at the parent zone; as long as the child NS RRset is kept cached from the child zone, resolution attempts for the child zone will survive the outage of the parent. So, this seems to me to be another case where this draft is one sided. Referring to this incident is probably a good idea, but IMO it should actually be just one background story instead of a "vulnerability" evidence to support the killing of RFC2181 data ranking. - Section 5.1 [...] Resolvers MUST NOT use zone apex NS RRSets to iterate. As argued so far, IMO this recommendation is way too strong and should be changed. (If we agree, we can discuss specially how we change it). - Section 5.2 Referrals and glue records in pre-loaded zone files MUST NOT be answered to stub resolvers. I don't understand what this sentence tries to specify. Could this be explained in more detail? I also don't understand why it specifically says "stub" resolvers; isn't it generally impossible for a responding DNS server (whether recursive or authoritative) to differentiate stub resolvers and non-stub resolvers? - Section 5.3 The update does not effect to DNS Query Name Minimisation [RFC7816] because answers from authoritative servers don't change. Delegation cache and authoritative data cache separation will need small implementation changes. I don't understand the relationship between the first and second sentences. Is the second sentence related to qname minimization? - Section 5.4 This update makes impossible to control of TTL value of NS RRSet by the child zone owner. However, overwrite of the referral does not occur always and TTL control may increase queries to authoritative servers. s/makes impossible/makes it impossible/ The second sentence didn't parse well to me...could you explain what it tries to say in a different way? - Section 8: I'm not sure about the intent of making this section empty, but I suspect this document will eventually need a non-empty Security Considerations section. If this is just a TODO item for now, it's better to clearly note that in the draft. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
