In message <CAC=TB12xXJNbmexMA4w5oLU+xhQbh=tKH=d7ykblqeklvsj...@mail.gmail.com>, =?UTF-8?Q?Marek_Vavru=C5=A1a?= writes: > > I see the point but I don't really want to go down the EDNS route.
Why not? It is cleaner as it deals with A-only, A and AAAA, and AAAA-only sites without a second lookup once support is deployed. It is supportable on a hop by hop basis. Just adding records w/o signalling is a waste of effort and bandwidth if the server does not support the extra records. https://ednscomp.isc.org/compliance/summary.html show current unknown EDNS flags behaviour. It also shows that you can change behaviour with a little education. Signaling also allows you to put both answers in the answer section. > So presuming that this draft catches on and Alexa 1M NSs publish at least > one AAAA record, there would be no need for two queries in most cases > and no need for additional signalisation. If they don't publish AAAA > records, then the resolver will still have to do the same thing as today, > however that also means that IPv6 adoption is stalled and possibly > irrelevant. IPv6 is here to stay. IPv4 is very much in its death throws at the moment. > TL;DR the draft optimises first case, if the second case proves to be > valid then we can always amend the draft but I don't want to overengineer > it from the start and it's always much easier to add than to remove. You can also under engineer. There is no way to measure client support as it currently is. A flag provides you with the ability to measure client support. > Marek > > > On Mon, Mar 21, 2016 at 5:26 PM, Mark Andrews <ma...@isc.org> wrote: > > > > > Or we could defined the "aaa" (A and AAAA) {E}DNS bit where the > > server guarantees that the response contains both the A and AAAA > > answers for A or AAAA queries if aaa=1 in the response. > > > > Recursive servers would lookup A/AAAA records if cache is missing > > them before returning a response. > > > > If the A / AAAA does not fit into the additional section then TC=1 > > is set. > > > > NOERROR NODATA is valid for both types if aaa=1 in the response. > > > > This way you could signal that you want both A and AAAA records and > > if you don't want both then the response does not have the other > > type added. > > > > Yes, we would have to nuke the stupid servers that reflect back > > {E}DNS flags. We would also have nuke the stupid firewalls that > > block {E}DNS queries with a unknown flag bit set. > > > > Mark > > > > Mark Andrews writes: > > > > > > Well we really want to get rid of A lookups. Why don't we just > > > recommend that we publish mapped A records in AAAA RRsets and have > > > master servers update AAAA RRsets if they are inconsitent with the > > > A RRsets. > > > > > > We also need a way to signal that there are no A records in the > > > AAAA RRset. ::ffff:255.255.255.255 or ::ffff:0.0.0.0 would be > > > sensible records to indicate this. > > > > > > Mark > > > > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > --001a11432b86aea53d052e98798d > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > <div dir=3D"ltr">I see the point but I don't really want to go down the= > EDNS route.<div>So presuming that this draft catches on and Alexa 1M NSs p= > ublish at least one AAAA record,</div><div>there would be no need for two q= > ueries in most cases and no need for additional signalisation.</div><div>If= > they don't publish AAAA records, then the resolver will still have to = > do the same thing as today,</div><div>however that also means that IPv6 ado= > ption is stalled and possibly irrelevant.</div><div><br></div><div>TL;DR th= > e draft optimises first case, if the second case proves to be valid then we= > can always amend the draft but I don't want to overengineer it from th= > e start and it's always much easier to add than to remove.</div><div><b= > r></div><div>Marek</div><div><br></div></div><div class=3D"gmail_extra"><br= > ><div class=3D"gmail_quote">On Mon, Mar 21, 2016 at 5:26 PM, Mark Andrews <= > span dir=3D"ltr"><<a href=3D"mailto:ma...@isc.org"; target=3D"_blank">mar= > k...@isc.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= > =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> > Or we could defined the "aaa" (A and AAAA) {E}DNS bit where the<b= > r> > server guarantees that the response contains both the A and AAAA<br> > answers for A or AAAA queries if aaa=3D1 in the response.<br> > <br> > Recursive servers would lookup A/AAAA records if cache is missing<br> > them before returning a response.<br> > <br> > If the A / AAAA does not fit into the additional section then TC=3D1<br> > is set.<br> > <br> > NOERROR NODATA is valid for both types if aaa=3D1 in the response.<br> > <br> > This way you could signal that you want both A and AAAA records and<br> > if you don't want both then the response does not have the other<br> > type added.<br> > <br> > Yes, we would have to nuke the stupid servers that reflect back<br> > {E}DNS flags.=C2=A0 We would also have nuke the stupid firewalls that<br> > block {E}DNS queries with a unknown flag bit set.<br> > <span class=3D"HOEnZb"><font color=3D"#888888"><br> > Mark<br> > </font></span><span class=3D"im HOEnZb"><br> > Mark Andrews writes:<br> > ><br> > > Well we really want to get rid of A lookups.=C2=A0 =C2=A0Why don't= > we just<br> > > recommend that we publish mapped A records in AAAA RRsets and have<br> > > master servers update AAAA RRsets if they are inconsitent with the<br> > > A RRsets.<br> > ><br> > > We also need a way to signal that there are no A records in the<br> > > AAAA RRset.=C2=A0 ::ffff:255.255.255.255 or ::ffff:0.0.0.0 would be<br= > > > > sensible records to indicate this.<br> > ><br> > </span><div class=3D"HOEnZb"><div class=3D"h5">> Mark<br> > ><br> > > --<br> > > Mark Andrews, ISC<br> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia<br> > > PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">= > +61 2 9871 4742</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = > =C2=A0INTERNET: <a href=3D"mailto:ma...@isc.org";>ma...@isc.org</a><br> > --<br> > Mark Andrews, ISC<br> > 1 Seymour St., Dundas Valley, NSW 2117, Australia<br> > PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">+61 2= > 9871 4742</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= > =A0INTERNET: <a href=3D"mailto:ma...@isc.org";>ma...@isc.org</a><br> > </div></div></blockquote></div><br></div> > > --001a11432b86aea53d052e98798d-- -- 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
