Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
At Tue, 15 Nov 2016 04:21:05 +0100 (CET), Ondřej Surý wrote: > > I'm not sure how you can be so sure about the author's assumption when > > the draft itself doesn't explicitly clarify the assumption (maybe > > based on an off-list conversation with Fujiwara-san?), but if that's > > actually the assumption, the current draft text is IMO so confusing > > and misleading. In that sense I'm with Bob and Stephan, and the draft > > should be much clearer on the assumption. > > > > And IMO, with the assumption *corrected*, the draft's recommendation > > becomes even less convincing to me. > > True, those are my assumptions about the draft based on the real world > experiences about the general mess that DNS usually is and experiences > with implementing a DNSSEC-validating resolver that has to cope with > such mess. > > Therefore my view is that the resolvers cannot make any assumptions that > anything in the DNS is *correct*, but only that it's as good as it gets > and try hard to fulfill the original query. > > I generally think that we should improve the DNS if the overall outcome > will be a better protocol (in any of stability, determinism, reliability, > resilience, add your own...) even if it attacks or changes the existing > paradigms without breaking existing deployments (to a limit). Okay, in that sense I believe we are basically on the same page, even if we may disagree on some specifics. I also have real world experiences where dogmatic application of what's written in RFCs doesn't really work well and I agree this is one such case. I also think draft-fujiwara-dnsop-resolver-update-00 is a good start. It's just that the initial version of it is so misleading (and perhaps partly as a result of that) the recommendations aren't very persuading. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
- Original Message - > From: "神明達哉" > To: "Ondřej Surý" > Cc: "Stephane Bortzmeyer" , "Bob Harold" > , "dnsop" > Sent: Tuesday, 15 November, 2016 03:40:56 > Subject: Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00 > At Tue, 15 Nov 2016 03:12:43 +0100 (CET), > Ondřej Surý wrote: > >> > Yes, it is. Otherwise, what would be the point of using the NS in the >> > parent instead of the authoritative one? >> >> Let me rephrase it, the assumption here is that parent NS are: >> "as good as they get to resolve the names underneath", and that >> doesn't mean they are necessarily more or less "correct" than >> child NS. > > I'm not sure how you can be so sure about the author's assumption when > the draft itself doesn't explicitly clarify the assumption (maybe > based on an off-list conversation with Fujiwara-san?), but if that's > actually the assumption, the current draft text is IMO so confusing > and misleading. In that sense I'm with Bob and Stephan, and the draft > should be much clearer on the assumption. > > And IMO, with the assumption *corrected*, the draft's recommendation > becomes even less convincing to me. True, those are my assumptions about the draft based on the real world experiences about the general mess that DNS usually is and experiences with implementing a DNSSEC-validating resolver that has to cope with such mess. Therefore my view is that the resolvers cannot make any assumptions that anything in the DNS is *correct*, but only that it's as good as it gets and try hard to fulfill the original query. I generally think that we should improve the DNS if the overall outcome will be a better protocol (in any of stability, determinism, reliability, resilience, add your own...) even if it attacks or changes the existing paradigms without breaking existing deployments (to a limit). Cheers, -- 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.czhttps://nic.cz/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
At Tue, 15 Nov 2016 03:12:43 +0100 (CET), Ondřej Surý wrote: > > Yes, it is. Otherwise, what would be the point of using the NS in the > > parent instead of the authoritative one? > > Let me rephrase it, the assumption here is that parent NS are: > "as good as they get to resolve the names underneath", and that > doesn't mean they are necessarily more or less "correct" than > child NS. I'm not sure how you can be so sure about the author's assumption when the draft itself doesn't explicitly clarify the assumption (maybe based on an off-list conversation with Fujiwara-san?), but if that's actually the assumption, the current draft text is IMO so confusing and misleading. In that sense I'm with Bob and Stephan, and the draft should be much clearer on the assumption. And IMO, with the assumption *corrected*, the draft's recommendation becomes even less convincing to me. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
- Original Message - > From: "Stephane Bortzmeyer" > To: "Ondřej Surý" > Cc: "Bob Harold" , "dnsop" > Sent: Tuesday, 15 November, 2016 01:55:50 > Subject: Re: draft-fujiwara-dnsop-resolver-update-00 > On Thu, Nov 10, 2016 at 08:46:55PM +0100, > Ondřej Surý wrote > a message of 32 lines which said: > >> > 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. >> >> Nope, I don't think this is an assumption of this draft > > Yes, it is. Otherwise, what would be the point of using the NS in the > parent instead of the authoritative one? Let me rephrase it, the assumption here is that parent NS are: "as good as they get to resolve the names underneath", and that doesn't mean they are necessarily more or less "correct" than child NS. Cheers, -- 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.czhttps://nic.cz/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
On Thu, Nov 10, 2016 at 08:46:55PM +0100, Ondřej Surý wrote a message of 32 lines which said: > > 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. > > Nope, I don't think this is an assumption of this draft Yes, it is. Otherwise, what would be the point of using the NS in the parent instead of the authoritative one? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
On Fri, Nov 11, 2016 at 02:08:54AM +0900, fujiw...@jprs.co.jp wrote a message of 41 lines which said: > > 2) It will make debugging more difficult. With your two-caches > > system, "dig @myresolver NS foobar.example" will retrieve the data > > in foobar.example, while the resolver will use, when iterating, > > the data from .example, which is not showed and I don't see a > > standard way to retrieve it from the "delegation cache". > > - The simplest mode for the client is recursive, since in this mode > the name server acts in the role of a resolver and returns either > an error or the answer, but never referrals. (RFC 1034 Section > 4.3.1) > > "dig @myresolver NS foobar.example" returns authoritative data. Sorry, but I do not see how your answer addresses my concern. (I was talking of debugging, not normal use.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
On Fri, Nov 11, 2016 at 04:33:54PM +0200, Andreas Gustafsson wrote a message of 22 lines which said: > A resolver that receives an RD=0 query for a name that is not > present in the cache should respond with a referral. In a two-cache > resolver, the natural place to look for the data to include in such > a referral is the delegation cache, since that is where referrals > are cached. Good idea, but it is not in the current draft. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
Thanks very much for submitting IPR infomation. The idea is not new and I heard that Nominum and some software implemented. -- Kazunori Fujiwara, JPRS > From: Andreas Gustafsson > fujiw...@jprs.co.jp wrote: >> I also received IPR claim from Nominum. >> >> https://datatracker.ietf.org/ipr/2907/ >> https://patents.google.com/patent/US7769826B2/ > > Just to avoid any possible misunderstanding, the IPR statement > referenced above was submitted by me in my capacity as a DNSOP > participant, as a third-party notification under RFC 3979 section > 6.1.3, because I thought the working group should be aware that the > patent exists. I am not currently affiliated with Nominum and did not > submit the statement on their behalf nor at their request. > -- > Andreas Gustafsson, g...@araneus.fi > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
On Nov 5, Stephane Bortzmeyer wrote: > I see the point but I have two practical reservations: [...] > 2) It will make debugging more difficult. With your two-caches system, > "dig @myresolver NS foobar.example" will retrieve the data in > foobar.example, while the resolver will use, when iterating, the data > from .example, which is not showed and I don't see a standard way to > retrieve it from the "delegation cache". A resolver that receives an RD=0 query for a name that is not present in the cache should respond with a referral. In a two-cache resolver, the natural place to look for the data to include in such a referral is the delegation cache, since that is where referrals are cached. If the resolver does that, you can use dig +norecurse @myresolver random-subdomain.foobar.example where random-subdomain is any unguessable label, for example one derived from a 128-bit random number. -- Andreas Gustafsson, g...@araneus.fi ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
fujiw...@jprs.co.jp wrote: > I also received IPR claim from Nominum. > > https://datatracker.ietf.org/ipr/2907/ > https://patents.google.com/patent/US7769826B2/ Just to avoid any possible misunderstanding, the IPR statement referenced above was submitted by me in my capacity as a DNSOP participant, as a third-party notification under RFC 3979 section 6.1.3, because I thought the working group should be aware that the patent exists. I am not currently affiliated with Nominum and did not submit the statement on their behalf nor at their request. -- Andreas Gustafsson, g...@araneus.fi ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
Fujiwara-san, the count of word "unstable" in your reply is exactly the reason why I was so strongly opposed to your original proposal at DNS-OARC as I think the Internet Standards should make things more stable than unstable. I quickly drafted several paragraphs during my PRG-AMS flight and sending them over my short layover, so I won't be able to send any updates in next 10+ hours. Take it or leave it, and I would be also happy to provide more text or co-author the draft if the result would end up in more stable DNS including backwards compatibility and not introduce even more mess into DNS. Here it comes, feel free to incorporate it at various places, or just wait, I'll try to merge it into your draft on my way to Seoul. ~~~ Recent authoritative DNS server implementations try to minimize the size of the DNS answers given to the clients. One such technique to minimize the amount of data sent back to client is removing all unnecessary records from the answer such as content of AUTHORITATIVE and ADDITIONAL section unless it's needed by DNS client to validate the answer. The side effect of such answer minimization is that the recursive DNS server might not see the child zone apex NS records unless some client of such resolver explicitly ask for NS records. Therefore the recursive DNS server behavior related to the delegation path is not deterministic. ~~~ While it might be tempting to remove NS records in the child zone apex as those NS records might never be used, there are several problems we have identified: a) when the child and parent zone are served from the same authoritative DNS server instance, the child apex NS records would override any delegation NS records at the parent zone, thus any invalid or missing child zone apex NS records might cause denial of service for such a zone, especially when QNAME minimization is used by the recursive DNS server; b) behavior of strict recursive DNS implementation that doesn't yet implement delegation NS selection specified in this draft might get erratic or broken causing denial of service for the end user; (TODO: Test all the common DNS server implementation.) The recursive DNS servers MUST use delegation NS records in the parent zone to follow delegation chain. The recursive DNS servers SHOULD NOT update the delegation chain with child zone apex NS records, but the authoritative DNS operators MUST act as if the recursive DNS servers might use the child zone apex NS records. Therefore the delegation NS records in the parent zone and the NS records in the child zone apex MUST follow the old semantics and MUST be kept in sync to allow uninterrupted service for recursive DNS servers that do not implement the delegation NS selection specified in this draft. ~~~ The implementation of this draft will also affect the time to live (TTL) for the delegation records as the TTL of the parent zone delegation NS records will always be used. It will not be possible to update the delegation NS records TTL by changing the TTL in the child zone. Therefore the zone operators(?) are advised to plan the changes in the NS records as if the maximum of child and parent TTLs was in effect. The parent zone operators are advised to allow child zone operators to modify TTL value for parent delegation NS records. The parent zone operators might limit the minimum and maximum TTL values to mitigate adverse effects on the parent zone operations. ~~~ The recursive DNS server implementations SHOULD implement different caches for parent zone delegation NS records and child zone apex NS records. The recursive DNS server MIGHT implement the delegation cache snooping by answering the IN NS query with child zone apex NS records in the ANSWER section and the parent zone delegation NS records in the AUTHORITATIVE section. ~ Cheers, -- 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.czhttps://nic.cz/ - Original Message - > From: "fujiwara" > To: "Ondřej Surý" > Cc: "dnsop" > Sent: Thursday, 10 November, 2016 18:27:14 > Subject: Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00 > Ondrej.Sury-san, > >> From: Ondřej Surý >> 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
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
Bob, - Original Message - > From: "Bob Harold" > To: "fujiwara" > Cc: "Ondřej Surý" , "dnsop" > Sent: Thursday, 10 November, 2016 19:23:07 > Subject: Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00 > 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. Nope, I don't think this is an assumption of this draft or an assumption of DNS status quo in general. > 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. What you have just described is an end-user (human) perception of how the humans think the DNS operates. The recursive DNS doesn't really care about parent vs child distinction if it has at least one working path. In the contrary, always sticking to child NS records and disregarding the changes in the parent might lead to "ghost domains" vulnerability. Cheers, -- 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.czhttps://nic.cz/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
On Thu, Nov 10, 2016 at 12:27 PM, wrote: > Ondrej.Sury-san, > > > From: Ondřej Surý > > 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 > > 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
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
Ondrej.Sury-san, > From: Ondřej Surý > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
> From: Stephane Bortzmeyer > fujiw...@jprs.co.jp wrote > a message of 61 lines which said: > >> I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to >> improve resolver algorithm. > > I see the point but I have two practical reservations: > > 1) Having two separate caches may be a big change for some > implementations. Yes. Two cache approach have patent problem. There may be another implementation method. > 2) It will make debugging more difficult. With your two-caches system, > "dig @myresolver NS foobar.example" will retrieve the data in > foobar.example, while the resolver will use, when iterating, the data > from .example, which is not showed and I don't see a standard way to > retrieve it from the "delegation cache". - The simplest mode for the client is recursive, since in this mode the name server acts in the role of a resolver and returns either an error or the answer, but never referrals. (RFC 1034 Section 4.3.1) "dig @myresolver NS foobar.example" returns authoritative data. > Apart from that, one detail: section 6 on implementations is too > short. You should expand it at least with the name of the > implementations (you mention two in your OARC talk, so it is not a > secret), and may be with RFC 7942 boilerplate. I will add. Regards, -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
Jinmei-san, thanks very much for your detailed comments.
I also received IPR claim from Nominum.
https://datatracker.ietf.org/ipr/2907/
https://patents.google.com/patent/US7769826B2/
I {will,need to} remove detailed algorithm {,to avoid IPR}.
Then, I will change the main contents to focus on problem collection
and proposal of requirements.
> From: 神明達哉
> - general: the title and file name seem to be too generic for the
> actual content. I suggest making them more specific, focusing on
> the subject of this draft.
Agree.
(I will submit next version to remove detailed algorithm to avoid IPR problem.)
> - Section 1
>
>[...] And it may break requirements of resolvers'
>answers described in Section 3.2.
>
> I don't get it. Specifically which requirement does this refer to?
> And, specifically how this override break that requirement?
Ok, I will add more text...
> - Section 3.1
>
>As described above, parent side NS RRSet makes a new zone. Parent
>side NS RRSet (referral) and glue records are all the information to
>access servers for the child zone.
>
>That is, resolvers SHOULD NOT use child side NS RRSet to iterate
>zones.
>
> There seems to be a logical leap between the first and second
> paragraph; I don't get why we SHOULD NOT use the child side NS
> RRset for subsequent iteration simply because the parent NS RRset is
> used for the iteration first time (which I guess the first para
> tries to say). In fact, the child side NS RRset might be a more
> complete, accurate and up to date set of the NS, while some part of
> the parent NS RRset may be unusable. This is related to the high
> level comment I made in my previous message - I see and support the
> seeming background motivation of this requirement, but I believe we
> need more careful considerations and probably a much less drastic
> update.
I agree that we need more careful consideration.
> - Section 4
>
>However, people sets different NS RRSets with mistakes, or
>intentionally.
>
> Specifically what kind of intent does this "intentionally" mean?
I considered "intentionally means "malicious idea".
next version will relfect your excellent comment.
Regards,
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
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.s...@nic.czhttps://nic.cz/ - Original Message - > From: "Ondřej Surý" > To: "fujiwara" > Cc: "dnsop" > 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.czhttps://nic.cz/ > > > - Original Message - >> From: fujiw...@jprs.co.jp >> To: "dnsop" >> 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 >> >>> 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 >
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.czhttps://nic.cz/ - Original Message - > From: fujiw...@jprs.co.jp > To: "dnsop" > 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 > >> 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/ 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
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
Or we could just ask that zone adminstrators and in particular gTLD registry operators actually do what is required of them for operational stability. I don't see "except section 4 or 4.2 or 4.2.2 or 4.2.2 paragraph 3". I do see a exception to restrict the use of hypens in labels. http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.pdf 1. Standards Compliance 1.1. DNS. Registry Operator shall comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF), including all successor standards, modifications or additions thereto relating to the DNS and name server operations including without limitation RFCs 1034, 1035, 1123, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966. DNS labels may only include hyphens in the third and fourth position if they represent valid IDNs (as specified above) in their ASCII encoding (e.g., âxn--ndk061nâ). RFC 1034, Section 4.2.2. Administrative considerations "As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so." Mark In message <20161105175842.ga26...@sources.org>, Stephane Bortzmeyer writes: > On Wed, Nov 02, 2016 at 03:10:18PM +0900, > fujiw...@jprs.co.jp wrote > a message of 61 lines which said: > > > I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to > > improve resolver algorithm. > > I see the point but I have two practical reservations: > > 1) Having two separate caches may be a big change for some > implementations. > > 2) It will make debugging more difficult. With your two-caches system, > "dig @myresolver NS foobar.example" will retrieve the data in > foobar.example, while the resolver will use, when iterating, the data > from .example, which is not showed and I don't see a standard way to > retrieve it from the "delegation cache". > > Apart from that, one detail: section 6 on implementations is too > short. You should expand it at least with the name of the > implementations (you mention two in your OARC talk, so it is not a > secret), and may be with RFC 7942 boilerplate. > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
On Wed, Nov 02, 2016 at 03:10:18PM +0900, fujiw...@jprs.co.jp wrote a message of 61 lines which said: > I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to > improve resolver algorithm. I see the point but I have two practical reservations: 1) Having two separate caches may be a big change for some implementations. 2) It will make debugging more difficult. With your two-caches system, "dig @myresolver NS foobar.example" will retrieve the data in foobar.example, while the resolver will use, when iterating, the data from .example, which is not showed and I don't see a standard way to retrieve it from the "delegation cache". Apart from that, one detail: section 6 on implementations is too short. You should expand it at least with the name of the implementations (you mention two in your OARC talk, so it is not a secret), and may be with RFC 7942 boilerplate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
At Wed, 02 Nov 2016 15:10:18 +0900 (JST), fujiw...@jprs.co.jp wrote: > I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to > improve resolver algorithm. > > Please read it and comment. As promised, here are specific comments on the draft text: - general: the title and file name seem to be too generic for the actual content. I suggest making them more specific, focusing on the subject of this draft. - Section 1 [...] And it may break requirements of resolvers' answers described in Section 3.2. I don't get it. Specifically which requirement does this refer to? And, specifically how this override break that requirement? - Section 3.1 As described above, parent side NS RRSet makes a new zone. Parent side NS RRSet (referral) and glue records are all the information to access servers for the child zone. That is, resolvers SHOULD NOT use child side NS RRSet to iterate zones. There seems to be a logical leap between the first and second paragraph; I don't get why we SHOULD NOT use the child side NS RRset for subsequent iteration simply because the parent NS RRset is used for the iteration first time (which I guess the first para tries to say). In fact, the child side NS RRset might be a more complete, accurate and up to date set of the NS, while some part of the parent NS RRset may be unusable. This is related to the high level comment I made in my previous message - I see and support the seeming background motivation of this requirement, but I believe we need more careful considerations and probably a much less drastic update. - Section 4 However, people sets different NS RRSets with mistakes, or intentionally. Specifically what kind of intent does this "intentionally" mean? btw, there's a typo here: s/sets/set/ - Section 4 If the zone data of name server(s) specified by referrals and specified by zone apex NS RRSet are different, name resolution becomes unstable. I'd suggest changing it "name resolution *may* become unstable", since simply because they are different does not necessarily lead to an unstable behavior. - Section 4 The cache overwrite of NS RRSet may break "Referrals and glue records are information to access servers for child zones" specified by [RFC1034] section 4.2.1. I can't find the quoted text in any of RFC1034, let alone in Section 4.2.1. And, in any case, I don't understand what "may break" means here. Please explain in more detail. - Section 4 The overwrite by zone apex NS RRSet induced security vulnerabilities. In 2012, "Ghost Domain Names: Revoked Yet Still Resolvable" [DUAN2012GHOST] was reported. [...] While I see this incident is relevant to the subject of this draft, I think it can be misleading especially if it's intended to be used to support the current strong recommendation (to which I disagree) of this draft. It may be true that the mastermind behind ghost domain names exploited a larger child-NS TTL with NS RRset replacement behavior of resolvers, I'd say this situation is quite extreme in that the admin of the zone is considered evil for a reason irrelevant to DNS itself and the parent zone tried to kill the delegation without the consent of the child zone admin. In fact, this intent of the child zone admin could even be helpful if they are a good net citizen when there's an outage at the parent zone; as long as the child NS RRset is kept cached from the child zone, resolution attempts for the child zone will survive the outage of the parent. So, this seems to me to be another case where this draft is one sided. Referring to this incident is probably a good idea, but IMO it should actually be just one background story instead of a "vulnerability" evidence to support the killing of RFC2181 data ranking. - Section 5.1 [...] Resolvers MUST NOT use zone apex NS RRSets to iterate. As argued so far, IMO this recommendation is way too strong and should be changed. (If we agree, we can discuss specially how we change it). - Section 5.2 Referrals and glue records in pre-loaded zone files MUST NOT be answered to stub resolvers. I don't understand what this sentence tries to specify. Could this be explained in more detail? I also don't understand why it specifically says "stub" resolvers; isn't it generally impossible for a responding DNS server (whether recursive or authoritative) to differentiate stub resolvers and non-stub resolvers? - Section 5.3 The update does not effect to DNS Query Name Minimisation [RFC7816] because answers from authoritative servers don't change. Delegation cache and authoritative data cache separation will need small implementation changes. I don't understand the relationship between the first and second sentences. Is the second sentence related to qname minimization? - Section 5.4 This update makes impossible to control
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
On Wed, Nov 2, 2016 at 6:52 PM, 神明達哉 wrote: > At Wed, 02 Nov 2016 15:10:18 +0900 (JST), > fujiw...@jprs.co.jp wrote: > > > I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to > > improve resolver algorithm. > > > > Please read it and comment. > > In short: I support the motivation of the draft with some big > reservations about specific observations and proposals. > > I agree that naive application of RFC2181 data ranking can lead to > problems and it's worth considering revisiting it. One real-world > example I know of is the case where child-zone NS RRset is completely > bogus and none of the NSes are reachable while at least some of the > parent NS RRset are valid. If a full-service resolver strictly > follows the RFC2181 ranking and replaces the parent NS RRset with a > "more trustworthy" set, any subsequent resolution attempt for the zone > will fail as long as the replaced RRset exists in the cache. Although > we could say it's an operational error rather than protocol or > resolver implementation, this type of errors can so easily happen, so > I think we should also be able to deal with this situation in terms of > the protocol specification. > > That said, the observation and recommendations of the current version > of this draft are IMO way one-sided and go too far. IMO, the sense of > RFC2181 data ranking largely makes sense in that the people/organization > who has the authority of the zone should know the configuration of the > zone best and it's generally more likely that the data in the child > zone are more up-to-date and accurate. For example, it's quite > possible that a subset of parent NS RRset is bogus while that in the > child zone is complete and accurate. In this case, the recommendation > of this draft can rather lead to more "unstable" behavior as some of the > resolution attempts may unnecessarily try the bogus NS(es), resulting > in problems like longer resolution time or even timeouts > (a sophisticated server selection algorithm of the resolver may > mitigate the issues, but we cannot always rely on the smartness). > > So, although I generally support the motivation of the draft, I'd > suggest making the recommendation more neutral and less drastic. For > example, for the specific example of unreachable child-zone NSes I > mentioned above, it might be enough if we allow a resolver to keep and > use the parent NS RRset if it finds all of the child NSes to be > unreachable or somehow lame. > > I also think it's overkilling to require specific caching data > structures like "authoritative data cache" and "delegation cache". > IMO this kind of details should be left to specific implementations, > and a protocol specification should only describe externally-visible > behaviors. As currently written it's not so obvious whether this is > normative text or not, but at least it could be interpreted that way > given that it's intended to be an update to RFC1034. If this is > just intended to be a conceptual example, it's probably fine, but in > that case the draft should clearly say so. > > I plan to send specific comments on the draft text later. > > -- > JINMEI, Tatuya > I agree: - The child NS records should be used, and only fall back to the parent NS records if all the child NS servers fail to get an answer to the query. - Avoid specifying implementation details. -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
NS mismatch between parent zone and child zone is an issue. I think that this draft is a very good start. Jiankang Yao From: fujiwara Date: 2016-11-02 14:10 To: dnsop 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 > 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/ 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
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
At Wed, 02 Nov 2016 15:10:18 +0900 (JST), fujiw...@jprs.co.jp wrote: > I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to > improve resolver algorithm. > > Please read it and comment. In short: I support the motivation of the draft with some big reservations about specific observations and proposals. I agree that naive application of RFC2181 data ranking can lead to problems and it's worth considering revisiting it. One real-world example I know of is the case where child-zone NS RRset is completely bogus and none of the NSes are reachable while at least some of the parent NS RRset are valid. If a full-service resolver strictly follows the RFC2181 ranking and replaces the parent NS RRset with a "more trustworthy" set, any subsequent resolution attempt for the zone will fail as long as the replaced RRset exists in the cache. Although we could say it's an operational error rather than protocol or resolver implementation, this type of errors can so easily happen, so I think we should also be able to deal with this situation in terms of the protocol specification. That said, the observation and recommendations of the current version of this draft are IMO way one-sided and go too far. IMO, the sense of RFC2181 data ranking largely makes sense in that the people/organization who has the authority of the zone should know the configuration of the zone best and it's generally more likely that the data in the child zone are more up-to-date and accurate. For example, it's quite possible that a subset of parent NS RRset is bogus while that in the child zone is complete and accurate. In this case, the recommendation of this draft can rather lead to more "unstable" behavior as some of the resolution attempts may unnecessarily try the bogus NS(es), resulting in problems like longer resolution time or even timeouts (a sophisticated server selection algorithm of the resolver may mitigate the issues, but we cannot always rely on the smartness). So, although I generally support the motivation of the draft, I'd suggest making the recommendation more neutral and less drastic. For example, for the specific example of unreachable child-zone NSes I mentioned above, it might be enough if we allow a resolver to keep and use the parent NS RRset if it finds all of the child NSes to be unreachable or somehow lame. I also think it's overkilling to require specific caching data structures like "authoritative data cache" and "delegation cache". IMO this kind of details should be left to specific implementations, and a protocol specification should only describe externally-visible behaviors. As currently written it's not so obvious whether this is normative text or not, but at least it could be interpreted that way given that it's intended to be an update to RFC1034. If this is just intended to be a conceptual example, it's probably fine, but in that case the draft should clearly say so. I plan to send specific comments on the draft text later. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
