Fujiwara-san, I was strongly opposed to the idea after your DNS-OARC presentation and I am glad you are continuing the effort :).
I had some private conversation with Ralf Weber from Nominum and we have conducted few experiments (and I plan to do more). My biggest concern is that your draft is missing the impact on the authoritative side: 1) what should happen when there's wrong NS at the child? 2) what should happen when there's no NS at the child? 3) what should happen in 1) and 2) when they are at the same server (generally the child NS is served)? The most practical thing would be to require that child and parent NS MUST match, but we would be saying at the same time that it won't be used at all. The second concern is about TTL. You dismiss it very quickly in 5.4, but implementation wise - it would be probably best to split "delegation" and RR caches as you generally the query for: "example.com." IN NS should return child records with child TTL, but the delegation at parent could have different values with different TTL. Also I can imagine this will be very confusing to end-users - when I query my resolver for "IN NS" I generally want to know when the changes in the delegations will be reflected. One possible way might be to return child NS in ANSWER and parent NS in AUTHORITY section in such case - but this needs to be addressed in the draft. This will also have an impact on registries - usually the TTL at the parent is picked by the registry, but when the TTL at the parent could have such strong impact on the resolver behavior, the registries would have to modify their systems to allow TTL specification per delegated domain. This applies especially in the cases when the registry picks some large (but still reasonable) number for TTL. P.S.: I am not so strongly opposed to the idea since I think a more deterministic approach to the resolution is generally a good thing, but I think there are many thing that need to be addressed before we can consider this to be an official standard and change in the paradigm how the domains are resolved. Cheers, Ondrej -- Ondřej Surý -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: fujiw...@jprs.co.jp > To: "dnsop" <dnsop@ietf.org> > Sent: Wednesday, 2 November, 2016 07:10:18 > Subject: [DNSOP] draft-fujiwara-dnsop-resolver-update-00 > Hello, > > I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to > improve resolver algorithm. > > Please read it and comment. > > I also made a presentation of the same topic > at previous DNS-OARC workshop. > > > https://indico.dns-oarc.net/event/25/session/6/contribution/19/material/slides/2.pdf > > Regards, > > -- > Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > >> From: internet-dra...@ietf.org >> >> A new version of I-D, draft-fujiwara-dnsop-resolver-update-00.txt >> has been successfully submitted by Kazunori Fujiwara and posted to the >> IETF repository. >> >> Name: draft-fujiwara-dnsop-resolver-update >> Revision: 00 >> Title: Updating Resolver Algorithm >> Document date: 2016-11-01 >> Group: Individual Submission >> Pages: 9 >> URL: >> https://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-resolver-update-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-resolver-update/ >> Htmlized: >> https://tools.ietf.org/html/draft-fujiwara-dnsop-resolver-update-00 >> >> >> Abstract: >> Parent side NS RRSet and glue records are all information to access >> servers for child zone. However, they may be overwritten by child >> zone data (zone apex NS RRSet and other A/AAAA RRSets). The >> overwrite makes name resolution unstable and induces vulnerabilities. >> RFC 2181 section 5.4.1 specifies trustworthiness of DNS data. And it >> is deemed that that all cached data (authoritative data, non- >> authoritative data, referrals and glue records) are merged into one. >> Resolvers may answer non-authoritative data, referrals and glue >> records that should not be returned. This document proposes updating >> resolver algorithm that separates the cache to "authoritative data >> cache" and "delegation cache". The former is used to answer stub >> resolvers, and the latter is used to iterate zones. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
