On Thu, Nov 10, 2016 at 12:27 PM, <fujiw...@jprs.co.jp> wrote: > 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> > > There seems to be an assumption in this draft that the parent NS records are always correct, but I would argue that this is not the case.
If all of the NS records in the child point to servers that fail to answer for that zone, the zone breaks. But the same happens if all the NS records in the parent point to servers that fail to answer for that zone. DNS treats parent NS records similarly to the root hints - as long as one of them points to a working child server, it can get a list of the current (true) list of NS records (from the child zone). The child zone is the authority for the NS records, not the parent zone. -- Bob Harold
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
