Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
On Thu, 2021-03-11 at 19:11 -0800, Brian Dickson wrote: > From the status updates today, I see this draft has expired. I really like it > (and it is quite simple), and would like to see it picked up and completed > (adopted, rough consensus reached, published). > > Having reread it and the discussion, I am wondering if useful guidance can be > provided regarding the TC=1 and records added. > > If as much glue as will fit is included, but not all glue fits, add all the > glue that fits, and set TC=1. > The resolver SHOULD attempt to use the available glue, but retry over TCP if > none of the servers found via the available glue respond. This sounds like something that might be very hard to fit into the flow of at least some code bases out there. > I.e. How is TC=1 interpreted currently by different implementations, and is > THAT an issue that could/should be clarified, either in this document, or in > a separate document? Answered below for us. > Is it necessary (at all) to mention keeping the glue that fits before setting > TC=1? > I don't think so, but maybe some commentary to that effect would be helpful? When we (PowerDNS auth) set TC=1, we empty the packet, based on the (somewhat under-argued) belief that different resolvers may draw different conclusions from what is there and what is not, and emptyingthe packet avoids ambiguity. Mirroring that, if the PowerDNS Recursor receives a TC=1 response (with rcode NOERROR or NXDOMAIN), no records are harvested and the whole query is retried over TCP. Based on only our choices, it is pointless to have any content in a TC=1 response. Others may feel somewhat differently, of course! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
>From the status updates today, I see this draft has expired. I really like it (and it is quite simple), and would like to see it picked up and completed (adopted, rough consensus reached, published). Having reread it and the discussion, I am wondering if useful guidance can be provided regarding the TC=1 and records added. If as much glue as will fit is included, but not all glue fits, add all the glue that fits, and set TC=1. The resolver SHOULD attempt to use the available glue, but retry over TCP if none of the servers found via the available glue respond. I.e. How is TC=1 interpreted currently by different implementations, and is THAT an issue that could/should be clarified, either in this document, or in a separate document? Is it necessary (at all) to mention keeping the glue that fits before setting TC=1? I don't think so, but maybe some commentary to that effect would be helpful? Brian On Fri, Jun 5, 2020 at 11:57 AM Paul Hoffman wrote: > On Jun 5, 2020, at 10:37 AM, Wessels, Duane 40verisign@dmarc.ietf.org> wrote: > > > > The essence of this draft is the addition of once sentence to RFC 1034: > > > > "If glue RRs do not fit set TC=1 in the header." > > > > I worry that this is too ambiguous. Does it mean all glue? One glue? > As much as will fit? > > > > AFAIK most software today is designed to fill up the additional section > with as much glue as possible. Is the name server allowed to add only some > glue RRs, even if more would fit (without truncating, or in a TCP response)? > > > > Is the name server allowed to fill the additional with all records of > one type, or A, when the resolver might only have connectivity of the > other type? > > > > There is also the question of in-domain vs sibling-domain glue. RFC > 8499 (Terminology) notes that "Glue records for sibling domains are > allowed, but not necessary." Should in-domain glue take priority over > sibling-domain glue? Can sibling-domain glue be omitted even if it would > fit? > > The current document is indeed ambiguous. I propose that it be changed to: >If all glue RRs do not fit, set TC=1 in the header. > > Given Duane's questions above, we can do better with another change to RFC > 1034 in this document. In this same paragraph from RFC 1034, it says: >Put whatever addresses are available into the additional >section, using glue RRs if the addresses are not available from >authoritative data or the cache. > That could instead be: >Put at least one available address into the additional >section, using glue RRs if the addresses are not available from >authoritative data or the cache. > > I don't think it is worthwhile to go into more detail about how to choose > how many to put in (because RFC 1034 didn't explicitly talk about message > size), or the mix of A and (because RFC 1034 didn't anticipate more > than one address type). > > --Paul Hoffman___ > 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] [Ext] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
Here's one example, 0124.org which has five in-domain name servers with glue: You're right, that's what it does but it also seems seriously wrong. $ for sz in `seq 604 16 700`; do echo -n "BUFSIZE $sz " ; dig +norec +ignore +dnssec +bufsize=$sz @199.19.57.1 0124.org | grep ';; flags:' ; done BUFSIZE 604 ;; flags: qr tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 BUFSIZE 620 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1 This domain has five NS, but the client only has the IP address of the first one. If that first one doesn't respond, what happens? It can't query any of the others because it doesn't have any of the addresses and it doesn't have any way to ask for them. What's the point of having more than one NS if clients can only find one of them? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
> On Jun 5, 2020, at 1:40 PM, John Levine wrote: > > In article <5e86e9ee-a022-44f0-9483-f498a03c3...@verisign.com> you write: >>> The current document is indeed ambiguous. I propose that it be changed to: >>> If all glue RRs do not fit, set TC=1 in the header. >> >> I believe this is contrary to how most authoritative DNS software works >> today, isn't it? > > I hope not. If it sends only part of the glue without a hint that > there's more if they requery, that's a recipe for failure. People sent > some examples last week. > Here's one example, 0124.org which has five in-domain name servers with glue: $ for sz in `seq 604 16 700`; do echo -n "BUFSIZE $sz " ; dig +norec +ignore +dnssec +bufsize=$sz @199.19.57.1 0124.org | grep ';; flags:' ; done BUFSIZE 604 ;; flags: qr tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 BUFSIZE 620 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1 BUFSIZE 636 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 2 BUFSIZE 652 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 3 BUFSIZE 668 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 4 BUFSIZE 684 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 5 BUFSIZE 700 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 6 Note that one of the Additional RRs is always the OPT RR. And from everyone's favorite, the root servers: $ for s in a b c d e f g h i j k l m ; do echo -n "$s " ; dig @$s.root-servers.net +dnssec +norec +ignore +bufsize=700 example.com | grep ';; flags:' ; done a ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 5 b ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 5 c ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 5 d ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 7 e ;; flags: qr tc; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 5 f ;; flags: qr tc; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 5 g ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 5 h ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 7 i ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 5 j ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 5 k ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 7 l ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 7 m ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 7 DW smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
In article <5e86e9ee-a022-44f0-9483-f498a03c3...@verisign.com> you write: >> The current document is indeed ambiguous. I propose that it be changed to: >> If all glue RRs do not fit, set TC=1 in the header. > >I believe this is contrary to how most authoritative DNS software works today, >isn't it? I hope not. If it sends only part of the glue without a hint that there's more if they requery, that's a recipe for failure. People sent some examples last week. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
> On Jun 5, 2020, at 11:56 AM, Paul Hoffman wrote: > > On Jun 5, 2020, at 10:37 AM, Wessels, Duane > wrote: >> >> The essence of this draft is the addition of once sentence to RFC 1034: >> >> "If glue RRs do not fit set TC=1 in the header." >> >> I worry that this is too ambiguous. Does it mean all glue? One glue? As >> much as will fit? >> >> AFAIK most software today is designed to fill up the additional section with >> as much glue as possible. Is the name server allowed to add only some glue >> RRs, even if more would fit (without truncating, or in a TCP response)? >> >> Is the name server allowed to fill the additional with all records of one >> type, or A, when the resolver might only have connectivity of the other >> type? >> >> There is also the question of in-domain vs sibling-domain glue. RFC 8499 >> (Terminology) notes that "Glue records for sibling domains are allowed, but >> not necessary." Should in-domain glue take priority over sibling-domain >> glue? Can sibling-domain glue be omitted even if it would fit? > > The current document is indeed ambiguous. I propose that it be changed to: > If all glue RRs do not fit, set TC=1 in the header. I believe this is contrary to how most authoritative DNS software works today, isn't it? > > Given Duane's questions above, we can do better with another change to RFC > 1034 in this document. In this same paragraph from RFC 1034, it says: > Put whatever addresses are available into the additional > section, using glue RRs if the addresses are not available from > authoritative data or the cache. > That could instead be: > Put at least one available address into the additional > section, using glue RRs if the addresses are not available from > authoritative data or the cache. And that sounds like the opposite of what you suggested above? DW smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
On Jun 5, 2020, at 10:37 AM, Wessels, Duane wrote: > > The essence of this draft is the addition of once sentence to RFC 1034: > > "If glue RRs do not fit set TC=1 in the header." > > I worry that this is too ambiguous. Does it mean all glue? One glue? As > much as will fit? > > AFAIK most software today is designed to fill up the additional section with > as much glue as possible. Is the name server allowed to add only some glue > RRs, even if more would fit (without truncating, or in a TCP response)? > > Is the name server allowed to fill the additional with all records of one > type, or A, when the resolver might only have connectivity of the other > type? > > There is also the question of in-domain vs sibling-domain glue. RFC 8499 > (Terminology) notes that "Glue records for sibling domains are allowed, but > not necessary." Should in-domain glue take priority over sibling-domain > glue? Can sibling-domain glue be omitted even if it would fit? The current document is indeed ambiguous. I propose that it be changed to: If all glue RRs do not fit, set TC=1 in the header. Given Duane's questions above, we can do better with another change to RFC 1034 in this document. In this same paragraph from RFC 1034, it says: Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache. That could instead be: Put at least one available address into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache. I don't think it is worthwhile to go into more detail about how to choose how many to put in (because RFC 1034 didn't explicitly talk about message size), or the mix of A and (because RFC 1034 didn't anticipate more than one address type). --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
