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

["Paul Hoffman" <[e-mail]>]

On 18 Aug 2016, at 8:04, Matthew Pounsett wrote:

> On 18 August 2016 at 10:40, Paul Hoffman <[e-mail]> 
> wrote:
>> Are there QTYPEs that, when I ask for them, I won't know that I 
>> should
>> also ask for the related info?
>
>
> Probably not.  However, there may be owner names you don't know you 
> need to
> ask for.   In the example of SRV, the owner name of the original query
> won't ever match the owner name of hosts in the RDATA, so simply 
> asking for
> extra QTYPEs in a pull is insufficient.

Maybe you have walked down a solution path too far. A pull for SRV might 
indeed allow any A/AAAA records for hosts in the RDATA.

> Also take for example the transition from not having HTTP SRV to 
> having
> it.  One of the arguments against from the browser developer community 
> is
> the additional round trips.  One of those extra round trips is the 
> need to
> request both the A/AAAA of the requested host and the 
> _http._tcp.<apex> SRV
> record in separate queries, not knowing if the latter even exists.   A
> server that can supply the latter (and related records from the RDATA) 
> with
> the former nullifies that argument against implementation.

Indeed it does, and that sounds sensible if the client asked for 
SRV-related info.

> Remember that in the proposals we've been discussing, a PUSH still 
> requires
> that the client signal its ability to deal with pushed data.  That 
> means
> that the only functional difference between a PUSH and a PULL is who
> decides which extra data is supplied.   It's my assertion that the 
> server
> is always going to be in a better position than the client to know 
> when
> there's necessary or useful additional data.

And it is my opinion that some pushers will use that both for good, and 
then for spam. I see no reason to open the door to the second.

Hrm. Or maybe we can.

A different idea: a pull option that says "send me whatever the heck you 
want related to this QNAME", that would likely never be used by stubs, 
but could be used by interested recursive resolvers that feel like they 
have plenty of cache available and want to give faster answers to their 
clients.

--Paul