Ondrej.Sury-san, > From: Ondřej Surý <ondrej.s...@nic.cz> > 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?
Resolvers with "overwrite" will become unstable. Resolvers with proposed algorithm don't use the child NS. Queries to parent authoritative servers do not increase. > 2) what should happen when there's no NS at the child? Resolvers with "overwrite" becomes unstable if stub resolvers send child NS queries. Resolvers with proposed algorithm don't use the child NS. Queries to parent authoritative servers do not increase. > 3) what should happen in 1) and 2) when they are at the same server > (generally the child NS is served)? Referrals from the grandparent is used. Queries to the parent zone and the child zone is sent to the shared authoritative server and it answers authoritative data of the child zone. Resolvers with "overwrite" will become unstable if stub resolvers send child NS queries. Resolvers with proposed algorithm don't use the child NS. Queries to authoritative servers do not increase. > 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. True. > 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. It's good idea. Thanks. > 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. However, the overwrite does not happen always. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
