Paul Wouters wrote:
> On Fri, 6 Mar 2015, Paul Vixie wrote:
>
>> ...
>>
>> i'd like to see this done. it would not require an internet-draft, ...
>
> At the time, I was more thinking of an EDNS option with a nsec3-style
> bitmap to specify which RRTYPE's you are interested in. Those would
> have to include the proof that something does not exist. It gets
> trickier if you want to support asking for "IPSECKEY and TLSA record for
> www.nohats.ca" and map that to the proper _443._tcp.www.nohats.ca. for
> TLSA and its NSEC3 records.
we don't need new signaling. additional data rules already permit what
i'm proposing here.
>
> People were pretty fast to say "just send multiple queries at once". And
> that is kind of true, and exactly what is now done with A / AAAA. But it
> would be better to get one query reply so you can make an informed
> decision instead of either waiting for the 2nd query or doing v4 when
> you could have done v6 if you had waited on the second query reply.
certainly, sending multiple queries in parallel means more processing
for everybody including the intervening routers, and unless you have a
tcp session open, means you have a smaller chance of success (meaning,
that nothing you want back will face loss or congestion.) if you need to
know whether AAAA exists before you will fall back to IPv4, then you
have to wait for both responses before you can make your next move.
also, if AAAA would satisfy you, then you'll end up hearing an "A"
response that you don't care about, probably after you've made your next
move (initiated a IPv6 TCP session). i don't see how we can build the
star-trek like future that many of us would like to live in, starting
from awful design-by-organic-side-effect like this.
>
> The problem with specifying this without a new EDNS option is that you
> don't know the differenec between old software or a missing A/AAAA
> record - you just know it was not in the reply. So software will still
> use two queries. It's fixable, but the migration path will take years
> while we don't have a good dns library to do this work in that everyone
> will then use.
my proposal is just send the additional data. granted, many RDNS clients
("stub resolvers") wouldn't cache the additional data, but newer ones
like http://getdnsapi.net/ that we hope the world will switch to, can.
and, if ADNS servers did this, then it would prepopulate the RDNS cache,
thus speeding up the non-parallel queries that folks are making today.
(this is the big win from MX, SRV, and NS additional data processing.)
so, no new signaling is needed. this can be done, opportunistically,
now, by anybody and everybody.
--
Paul Vixie
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
