On 18 August 2016 at 10:40, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
> On 18 Aug 2016, at 7:19, Matthew Pounsett wrote:
>
> On 18 August 2016 at 01:33, william manning <chinese.apri...@gmail.com>
>> wrote:
>>
>> please help me get over the feeling that this argument is founded on the
>>> same logic as that used by folks who "know" I might want, no NEED that
>>> extra bit of email in my inbox. As I read it, it sounds like DNS Server
>>> Spam being "PUSHED" to the Resolver who may or may not want the data.
>>>
>>>
>> Pure hyperbole.
>>
>
> Disagree: partial hyperbole.
>
> If a client is given a delegation today, you don't complain because glue is
>> supplied.
>>
>
> Agree. But...
>
> It's necessary for the obvious next step.
>>
>
> There is a difference between "don't complain" and "needed". I would not
> complain about an Additional with AAAA for an A request, or vice versa.
> However, I would complain about "A of our advertising partner because I
> think you are about to render an HTML page".
>
> We already have
>> other records (e.g. SRV) which is many cases have data which are useless
>> without a followup query. In what way is it like spam to supply those
>> data
>> with the original query?
>>
>
> If I'm making an SRV query, I know I can ask for ("pull" in Tim's wording)
> additional info.
>
> 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.
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.
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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
