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.
In short: I support the motivation of the draft with some big reservations about specific observations and proposals. I agree that naive application of RFC2181 data ranking can lead to problems and it's worth considering revisiting it. One real-world example I know of is the case where child-zone NS RRset is completely bogus and none of the NSes are reachable while at least some of the parent NS RRset are valid. If a full-service resolver strictly follows the RFC2181 ranking and replaces the parent NS RRset with a "more trustworthy" set, any subsequent resolution attempt for the zone will fail as long as the replaced RRset exists in the cache. Although we could say it's an operational error rather than protocol or resolver implementation, this type of errors can so easily happen, so I think we should also be able to deal with this situation in terms of the protocol specification. That said, the observation and recommendations of the current version of this draft are IMO way one-sided and go too far. IMO, the sense of RFC2181 data ranking largely makes sense in that the people/organization who has the authority of the zone should know the configuration of the zone best and it's generally more likely that the data in the child zone are more up-to-date and accurate. For example, it's quite possible that a subset of parent NS RRset is bogus while that in the child zone is complete and accurate. In this case, the recommendation of this draft can rather lead to more "unstable" behavior as some of the resolution attempts may unnecessarily try the bogus NS(es), resulting in problems like longer resolution time or even timeouts (a sophisticated server selection algorithm of the resolver may mitigate the issues, but we cannot always rely on the smartness). So, although I generally support the motivation of the draft, I'd suggest making the recommendation more neutral and less drastic. For example, for the specific example of unreachable child-zone NSes I mentioned above, it might be enough if we allow a resolver to keep and use the parent NS RRset if it finds all of the child NSes to be unreachable or somehow lame. I also think it's overkilling to require specific caching data structures like "authoritative data cache" and "delegation cache". IMO this kind of details should be left to specific implementations, and a protocol specification should only describe externally-visible behaviors. As currently written it's not so obvious whether this is normative text or not, but at least it could be interpreted that way given that it's intended to be an update to RFC1034. If this is just intended to be a conceptual example, it's probably fine, but in that case the draft should clearly say so. I plan to send specific comments on the draft text later. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
