Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

[Marek Vavruša <[e-mail]>]

Very interesting, so BIND already pushes records for the obvious
optimisation cases.
Did you do any research on how many clients use these records (thus
don't follow up with an extra query) ?

Perhaps it would be helpful to look at the it from different perspectives.
As an authoritative DNS implementor, I'd like to be able to add
related records. Since auths are relatively well maintained, I'd feel
more comfortable experimenting here. Signalisation is not strictly
required, but perhaps a flag similar to "DO" to signalise "I want
related records" would be helpful. So both PUSH and PULL are viable
options. PUSH would be nicer if the deployed recursors already
accepted these records, however I don't have any data on this.

As a recursive DNS implementor, I can't trust everything in the
answers. I'd prefer to signalise when I want related records (PULL) to
be conservative, because the recursors are not that well maintained.
I'd like to have a better guideline on what records should be accepted
from the answers.

As a stub resolver DNS implementor, I don't want to change anything
because this code will live forever.

Marek

On Thu, Aug 18, 2016 at 7:32 PM, Mark Andrews <[e-mail]> wrote:
>
> Named returns associated
>
> * A/AAAA records with MX lookups if available
> * A/AAAA records with SRV lookups if available
> * SRV/A/AAAA records with NAPTR lookups if available
> * A/AAAA records with NAPTR lookups if available
>
> As of 9.11 named returns associated
>
> * A/AAAA/TLSA records with MX lookups if available
> * A/AAAA/TLSA records with SRV lookups if available
> * SRV/A/AAAA/TLSA records with NAPTR lookups if available
> * A/AAAA records with NAPTR lookups if available
>
> Now for all of these the original lookup could be stalled for cache
> misses and the related data fetched if the server is offering
> recursive service to the clients.
>
> It would also be possible when offering recursive service to perform
> prefetching on cache misses.
>
> It would also be possible to return A on AAAA and AAAA on A.
>
> It's up to the client to accept or ignore the records.
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]