One more thought I have just realized in the discussion with my colleague and that might tilt the scales towards the Fujiwara-san's proposal.
The modern authoritative nameservers tries to minimize the amount of data given back, so they don't fill an AUTHORITATIVE section for every query. The consequences of that is that a one more roundtrip would be needed to check the child-side NS. I still don't know how to explain: "You absolutely must fill this in, but it will be never used unless the parent and child resides at the same server." 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: "Ondřej Surý" <ondrej.s...@nic.cz> > To: "fujiwara" <fujiw...@jprs.co.jp> > Cc: "dnsop" <dnsop@ietf.org> > Sent: Wednesday, 9 November, 2016 11:59:39 > Subject: Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00 > 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
