In message <CAC=tb11orh1myro+ccemjwy67nyhdcrgwvhe+jm568o2cl7...@mail.gmail.com>, =?UTF-8?Q?Marek_Vavru=C5=A1a?= writes: > > Thanks everybody for comments! It's a lot so I'll try to rephrase and > answer the questions below. > > 1. No signalling to client when AAAA is unavailable > > I didn't want to include it in the beginning but I see it has a merit. > DNSSEC has means to provide authenticated non-existence for free, so I > think it's worth for auth server to add either data or non-existence proof > for any applicable RR. > e.g. if it has AAAA, but not A, it would provide AAAA RRs and NSECX for A; > if it has A but not AAAA, it would provide A RRs and NSECX for AAAA > > For legacy case of no DNSSEC, an SOA in the authority indicates that no > record matching QNAME+QTYPE exists, but can't effectively signalise > non-existence of the additional address records. Which is not great, but > I'm not in for legalising yet-another EDNS option, and it also would > require client to signalise that it can handle such option before an auth > server raises it in the answer. For this case specifically, I am okay with > client making additional AAAA query to recheck. > To defense: resolvers keep track of auth functionality (ability to do EDNS, > IPv6 availability, ...), this is not any different. If the auth shows that > it either supports this (by at least one positive case) or not (this case), > resolver will remember it and act accordingly next time.
So shove it in the answer and hope the client can do something useful with it verses add it when the client tells us it can handle it. We went this path with DNSSEC records and got DO. Listen to history. Having to remember capabilities is much worse than just having the capability signaled on a per query basis. You don't have to upgrade all the servers behind a load balancer at once, Note this include CPEs which proxy queries to multiple servers. Sometimes you have no choice like with DNS COOKIE, but here there is zero need other than unwillingness to include signaling. > 2. Behavior of stubs is not explicit in the draft > > I should have stated this explicitly, the draft doesn't update behaviour of > stub resolvers. In my opinion, they should use the most basic form of DNS > and work only over local or trusted network, hence no latency issues. It updates clients so it updates stubs. Stubs should be doing DNSSEC for validation, so yes that means EDNS. There is lots of FUD about CPE routers. > 2. Stubs and recursors during NS resolution issue parallel queries > > That is correct, the draft expects software changes if accepted. Saying > that it doesn't have any effect is not entirely true though. The latency is > max(rtt_a, rtt_aaaa) in the best case and one of the queries time out or is > blocked in the worst case. In addition, this doubles query rate on > authoritatives and requires more logic on clients (which is error prone - > see latest glibc bug), especially when one of the replies gets ratelimited, > truncated or answered from different node. On the contrary, waiting for > single answer is simple. Yet, you say it is not for stub resolvers which is the piece of code that could really benefit from it. Nameservers are dealing with lots of parallel lookups all the time. > 3. AAAA query doesn't offer A records > > That is a valid point. Long answer: I think the logic of clients asking for > IPv6 is flawed from the get-go. For a smooth protocol version upgrade, > authoritatives should have had a way to push IPv6 on clients instead of > waiting for them to ask for it. The A record is unfortunately defined as a > 32-bit Internet address. I think it should be redefined as "Internet > address". This way, if a client wants to ask a server about IP address, it > would _always_ use an A query and get a list of A, AAAA and possibly > something new. It would be up to client's discretion to pick an address > version that it understands. The benefit of this is that it doesn't require > additional queries or major client-side changes. Somebody has said IPv6 is > here to stay, I'd like to share this certainty. Meta-types (sort of what I > want an A to become) are considered bad, but DNS was built around name to > address translation so optimising for this case might be worth it. Offering > A records for AAAA drags the need for backward compatibility (even more if > we ever have a newer address record) and more code exceptions. Well we don't have a time machine. We also have the potential to add signaling so adding A to AAAA responses doesn't need to drag backwards compatibility. > Marek > > On Tue, Mar 22, 2016 at 8:55 AM, Shumon Huque <shu...@gmail.com> wrote: > > > On Tue, Mar 22, 2016 at 7:41 AM, Tony Finch <d...@dotat.at> wrote: > > > >> Marek Vavru=C5=A1a <mvavr...@cloudflare.com> wrote: > >> > > >> > there was an interest in reducing latency for address record lookups. > >> > Me and Olafur wrote a draft on adding AAAA records to A answers and > >> > treating them as authoritative. This fixes latency issues with NS > >> > A/AAAA discovery in resolvers and improves caching for clients (AAAA > >> > already cached by the time client comes asking for it). > >> > >> Regarding NS discovery, you should be aware that BIND queries for name > >> server A and AAAA concurrently. So this draft would just make packets > >> bigger without helping latency. > >> > > > > It's worth noting that several "happy eyeballs" style APIs issue > > concurrent > > AAAA/A queries also, like the Apple connect-by-name APIs. Also getdns > > does this. AAAA and A go out back to back, put typically AAAA is put out > > on the wire first. > > > > -- > > Shumon Huque > > > > > > --94eb2c035cd8596a8c052ea7fd8f > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > <div dir=3D"ltr">Thanks everybody for comments! It's a lot so I'll = > try to rephrase and answer the questions below.<div><br></div><div>1. No si= > gnalling to client when AAAA is unavailable</div><div><br></div><div>I didn= > 't want to include it in the beginning but I see it has a merit. DNSSEC= > has means to provide authenticated non-existence for free, so I think it&#= > 39;s worth for auth server to add either data or non-existence proof for an= > y applicable RR.</div><div>e.g. if it has AAAA, but not A, it would provide= > AAAA RRs and NSECX for A; if it has A but not AAAA, it would provide A RRs= > and NSECX for AAAA</div><div><br></div><div>For legacy case of no DNSSEC, = > an SOA in the authority indicates that no record matching QNAME+QTYPE exist= > s, but can't effectively signalise non-existence of the additional addr= > ess records. Which is not great, but I'm not in for legalising yet-anot= > her EDNS option, and it also would require client to signalise that it can = > handle such option before an auth server raises it in the answer. For this = > case specifically, I am okay with client making additional AAAA query to re= > check.</div><div>To defense: resolvers keep track of auth functionality (ab= > ility to do EDNS, IPv6 availability, ...), this is not any different. If th= > e auth shows that it either supports this (by at least one positive case) o= > r not (this case), resolver will remember it and act accordingly next time.= > </div><div><br></div><div>2. Behavior of stubs is not explicit in the draft= > </div><div><br></div><div>I should have stated this explicitly, the draft d= > oesn't update behaviour of stub resolvers. In my opinion, they should u= > se the most basic form of DNS and work only over local or trusted network, = > hence no latency issues.</div><div><br></div><div>2. Stubs and recursors du= > ring NS resolution issue parallel queries</div><div><br></div><div>That is = > correct, the draft expects software changes if accepted. Saying that it doe= > sn't have any effect is not entirely true though. The latency is max(rt= > t_a, rtt_aaaa) in the best case and one of the queries time out or is block= > ed in the worst case. In addition, this doubles query rate on authoritative= > s and requires more logic on clients (which is error prone - see latest gli= > bc bug), especially when one of the replies gets ratelimited, truncated or = > answered from different node. On the contrary, waiting for single answer is= > simple.</div><div><br></div><div>3. AAAA query doesn't offer A records= > </div><div><br></div><div>That is a valid point. Long answer: I think the l= > ogic of clients asking for IPv6 is flawed from the get-go. For a smooth pro= > tocol version upgrade, authoritatives should have had a way to push IPv6 on= > clients instead of waiting for them to ask for it. The A record is unfortu= > nately defined as a 32-bit Internet address. I think it should be redefined= > as "Internet address". This way, if a client wants to ask a serv= > er about IP address, it would _always_ use an A query and get a list of A, = > AAAA and possibly something new. It would be up to client's discretion = > to pick an address version that it understands. The benefit of this is that= > it doesn't require additional queries or major client-side changes. So= > mebody has said IPv6 is here to stay, I'd like to share this certainty.= > Meta-types (sort of what I want an A to become) are considered bad, but DN= > S was built around name to address translation so optimising for this case = > might be worth it. Offering A records for AAAA drags the need for backward = > compatibility (even more if we ever have a newer address record) and more c= > ode exceptions.</div><div><br></div><div>Marek</div></div><div class=3D"gma= > il_extra"><br><div class=3D"gmail_quote">On Tue, Mar 22, 2016 at 8:55 AM, S= > humon Huque <span dir=3D"ltr"><<a href=3D"mailto:shu...@gmail.com"; targe= > t=3D"_blank">shu...@gmail.com</a>></span> wrote:<br><blockquote class=3D= > "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding= > -left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_= > quote"><span class=3D"">On Tue, Mar 22, 2016 at 7:41 AM, Tony Finch <span d= > ir=3D"ltr"><<a href=3D"mailto:d...@dotat.at"; target=3D"_blank">dot@dotat.= > at</a>></span> wrote:<br></span><span class=3D""><blockquote class=3D"gm= > ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= > ft:1ex"><span>Marek Vavru=C5=A1a <<a href=3D"mailto:mvavrusa@cloudflare.= > com" target=3D"_blank">mvavr...@cloudflare.com</a>> wrote:<br> > ><br> > > there was an interest in reducing latency for address record lookups.<= > br> > > Me and Olafur wrote a draft on adding AAAA records to A answers and<br= > > > </span>> treating them as authoritative. This fixes latency issues with = > NS<br> > <span>> A/AAAA discovery in resolvers and improves caching for clients (= > AAAA<br> > > already cached by the time client comes asking for it).<br> > <br> > </span>Regarding NS discovery, you should be aware that BIND queries for na= > me<br> > server A and AAAA concurrently. So this draft would just make packets<br> > bigger without helping latency.<br></blockquote><div><br></div></span><div>= > It's worth noting that several "happy eyeballs" style APIs is= > sue concurrent=C2=A0</div><div>AAAA/A queries also, like the Apple connect-= > by-name APIs. Also getdns</div><div>does this. AAAA and A go out back to ba= > ck, put typically AAAA is put out=C2=A0</div><div>on the wire first.</div><= > span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>--=C2=A0<= > /div><div>Shumon Huque</div><div><br></div></font></span></div></div></div> > </blockquote></div><br></div> > > --94eb2c035cd8596a8c052ea7fd8f-- > > > --===============3282002912730061508== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --===============3282002912730061508==-- > -- 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
