Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00

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.sury@nic.cz    https://nic.cz/
 --------------------------------------------

----- Original Message -----
> From: "Ondřej Surý" <ondrej.sury@nic.cz>
> To: "fujiwara" <fujiwara@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.sury@nic.cz    https://nic.cz/
> --------------------------------------------
> 
> ----- Original Message -----
>> From: fujiwara@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 <fujiwara@jprs.co.jp>
>> 
>>> From: internet-drafts@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