On Tue, Mar 22, 2016 at 1:20 PM, Mark Andrews <ma...@isc.org> wrote: > > 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. >
I don't really like DO being in EDNS instead of header. I'm okay with other address types being in additional as well. > 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. It is unwillingness to include signaling because I still don't see any practical benefit of it. This draft does not significantly change the look of the response (not more than aliases or additional records) to warrant a client 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. > Almost no-one enables EDNS for stub. I mean stub as in getaddrinfo(), not forwarders like dnsmasq (these are updated). > > > 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. Right, we don't have a time machine, but we can amend I-Ds. > 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
