On Wed, Nov 2, 2016 at 6:52 PM, 神明達哉 <jin...@wide.ad.jp> wrote:
> 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 > I agree: - The child NS records should be used, and only fall back to the parent NS records if all the child NS servers fail to get an answer to the query. - Avoid specifying implementation details. -- Bob Harold
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
