Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
All The call for adoption ended on monday and this has enough consensus to be adopted by the working group. tim On Thu, May 21, 2020 at 9:36 PM Paul Vixie wrote: > On Friday, 22 May 2020 00:31:34 UTC Masataka Ohta wrote: > > ... > > > > While I'm not against the clarification, the draft should mention > > that rfc1034 already states: > > > > To fix this problem, a zone contains "glue" RRs which are not > > part of the authoritative data, and are address RRs for the servers. > > These RRs are only necessary if the name server's name is "below" the > > > > cut, and are only used as part of a referral response. > > ^ > > > > which means the glue RRs are necessary for a referral response. > > Though not very obvious, it logically means that they MUST be > > included as part of a referral response, because it is the only > > reason to make them necessary. > > i agree. this is why later versions of BIND would return referrals rather > than > answers when queried for these names, which were in-bailiwick but > below-zone. > by implication, they can only be retrieved from the delegating server as > part > of a referral, and they will be in the additional section not the answer > section even though they do match the qname. this distinction is also > necessary in the assignment of credibility levels in the downstream cache. > > -- > Paul > > > ___ > 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] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
On Friday, 22 May 2020 00:31:34 UTC Masataka Ohta wrote: > ... > > While I'm not against the clarification, the draft should mention > that rfc1034 already states: > > To fix this problem, a zone contains "glue" RRs which are not > part of the authoritative data, and are address RRs for the servers. > These RRs are only necessary if the name server's name is "below" the > > cut, and are only used as part of a referral response. > ^ > > which means the glue RRs are necessary for a referral response. > Though not very obvious, it logically means that they MUST be > included as part of a referral response, because it is the only > reason to make them necessary. i agree. this is why later versions of BIND would return referrals rather than answers when queried for these names, which were in-bailiwick but below-zone. by implication, they can only be retrieved from the delegating server as part of a referral, and they will be in the additional section not the answer section even though they do match the qname. this distinction is also necessary in the assignment of credibility levels in the downstream cache. -- Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
Tim Wicinski wrote: This starts a Call for Adoption for draft-andrews-dnsop-glue-is-not-optional The draft is available here: https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. While I'm not against the clarification, the draft should mention that rfc1034 already states: To fix this problem, a zone contains "glue" RRs which are not part of the authoritative data, and are address RRs for the servers. These RRs are only necessary if the name server's name is "below" the cut, and are only used as part of a referral response. ^ which means the glue RRs are necessary for a referral response. Though not very obvious, it logically means that they MUST be included as part of a referral response, because it is the only reason to make them necessary. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
On Mon, May 18, 2020 at 1:50 PM Tim Wicinski wrote: > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for > draft-andrews-dnsop-glue-is-not-optional > > The draft is available here: > https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 1 June 2020 > I've read the draft. It's a useful clarification to the spec, so I support adoption and will review etc. I have one question for the Mark A though: Since you specifically cite the example of the GOV servers, did you ask Verisign about this behavior, and if so, what was their response? Maybe this is just a bug, rather than a "widespread misbelief" about additional data & truncation that you more generally attribute as the cause for this. Shumon ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
I am supporting adoption. Yours, Daniel On Thu, May 21, 2020 at 10:41 AM Wes Hardaker wrote: > Tim Wicinski writes: > > > We are looking for *explicit* support for adoption. > > Yes please! > -- > Wes Hardaker > USC/ISI > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Daniel Migault Ericsson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
Tim Wicinski writes: > We are looking for *explicit* support for adoption. Yes please! -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
In article you write: >Not convinced the situation should be this black and white - eg perhaps >partial glue would be enough >not to require TC=1 or behaviour for resolvers could be a little more advanced >to try with partial >before going to TCP. > >If my request seem stupid, the draft needs clarification for stupid people >like me :) The draft, which I hope we adopt, could use clarification if that seems like a good idea. Imagine you have foo.example with two nameservers, ns1.foo.example and ns2.foo.example. Client looks up something.foo.example, server returns a referral with two NS records but only has room for one A record for ns1. The Internet is having a bad day and ns1 is unreachable while ns2 is fine. Since there's no TC=1 the client has no idea that requerying would return the A record for ns2, so it wrongly assumes ns2 has no A record and the domain is kaput. It can't separately requery for ns2, since who would it ask? It's fine to return a partial result with TC=1, that's always been the case. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
On Monday, 18 May 2020 17:49:04 UTC Tim Wicinski wrote: > ... > > This starts a Call for Adoption for draft-andrews-dnsop-glue-is-not-optional > > The draft is available here: > https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. +1. long overdue after false starts by me and others. > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 1 June 2020 i'm willing to review. -- Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
In favour of adoption but like to see text from both AUTH and recursive behaviour. Not convinced the situation should be this black and white - eg perhaps partial glue would be enough not to require TC=1 or behaviour for resolvers could be a little more advanced to try with partial before going to TCP. If my request seem stupid, the draft needs clarification for stupid people like me :) Paul Sent from my iPhone > On May 18, 2020, at 14:30, Brian Dickson > wrote: > > > > >> On Mon, May 18, 2020 at 10:50 AM Tim Wicinski wrote: >> >> All, >> >> As we stated in the meeting and in our chairs actions, we're going to run >> regular call for adoptions over next few months. >> We are looking for *explicit* support for adoption. >> >> >> This starts a Call for Adoption for draft-andrews-dnsop-glue-is-not-optional >> >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/ >> >> Please review this draft to see if you think it is suitable for adoption >> by DNSOP, and comments to the list, clearly stating your view. >> >> Please also indicate if you are willing to contribute text, review, etc. >> > > I support adoption by the WG, believe it is suitable, and am willing to > review and contribute text. > > Brian > > >> This call for adoption ends: 1 June 2020 >> >> Thanks, >> tim wicinski >> DNSOP co-chair >> ___ >> 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
On Mon, May 18, 2020 at 10:50 AM Tim Wicinski wrote: > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for > draft-andrews-dnsop-glue-is-not-optional > > The draft is available here: > https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > I support adoption by the WG, believe it is suitable, and am willing to review and contribute text. Brian > This call for adoption ends: 1 June 2020 > > Thanks, > tim wicinski > DNSOP co-chair > ___ > 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
