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

[Tony Finch]

william manning  wrote:
>
> Now any v. Concurrent queries.  To ensure the resolver gets all the RRs,

But it doesn't want all the RRs, just the relevant ones.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Northwest Fitzroy, Sole: Variable 3, becoming southwesterly 4 or 5. Slight or
moderate. Showers. Good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[william manning]

Good thing refuse-any is just a draft then isn't it.

Now any v. Concurrent queries.  To ensure the resolver gets all the RRs,
wouldn't you have to query for all defined RR types?   Perhaps you want ALL
instead of ANY?

/Wm

On Thursday, 25 August 2016, Tony Finch  wrote:

> Edward Lewis > wrote:
>
> > The question I keep asking myself is: How is this different from a
> > client just hitting a server with all anticipated questions at one time?
>
> Me too :-)
>
> I can see an advantage to improving the case where the client can't
> predict all the questions in advance, e.g. when the subsequent questions
> depend on a SRV target or an SPF include: directive.
>
> A big problem with additional data at the moment is a client doesn't know
> whether an absence of data (no  records) means the data doesn't exist,
> so it still has to make followup queries to double check. A DNSSEC proof
> of nonexistence could help.
>
> > Why not just ask for qtype ANY all the time, for data sets owned by the
> > same domain name.
>
> Doesn't work reliably through caches, or with draft-ietf-dnsop-refuse-any
> :-)
> Also, ANY doesn't actually improve latency compared to concurrent queries.
>
> Tony.
> --
> f.anthony.n.finch  >  http://dotat.at/  -  I
> xn--zr8h punycode
> Southeast Biscay: Variable 2 or 3, becoming northwesterly 4 or 5 for a
> time.
> Slight or moderate. Occasional showers. Good.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Matthew Pounsett  wrote:
>
> 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/ of the requested host and the _http._tcp. SRV
> record in separate queries, not knowing if the latter even exists.

A client can query for A  and SRV concurrently. The extra latency is
due to the followup SRV target address queries and the higher rate of SRV
lookup failures.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Northwest Fitzroy, Sole: Variable 3, becoming southwesterly 4 or 5. Slight or
moderate. Showers. Good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Edward Lewis  wrote:

> The question I keep asking myself is: How is this different from a
> client just hitting a server with all anticipated questions at one time?

Me too :-)

I can see an advantage to improving the case where the client can't
predict all the questions in advance, e.g. when the subsequent questions
depend on a SRV target or an SPF include: directive.

A big problem with additional data at the moment is a client doesn't know
whether an absence of data (no  records) means the data doesn't exist,
so it still has to make followup queries to double check. A DNSSEC proof
of nonexistence could help.

> Why not just ask for qtype ANY all the time, for data sets owned by the
> same domain name.

Doesn't work reliably through caches, or with draft-ietf-dnsop-refuse-any :-)
Also, ANY doesn't actually improve latency compared to concurrent queries.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Southeast Biscay: Variable 2 or 3, becoming northwesterly 4 or 5 for a time.
Slight or moderate. Occasional showers. Good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

In message <99ce1d3e-18a0-42e6-949f-e78995afc...@icann.org>, Edward Lewis write
s:
> On 8/16/16, 08:57, "DNSOP on behalf of Tim Wicinski"  on behalf of tjw.i...@gmail.com> wrote:
> 
> I've only read briefly the drafts and see hints that issues I raise below
> are still lingering.
>
> There's no denying that there's a desire to solve "this".  I keep in mind
> that this isn't the first time there's been a desire to add this to the
> DNS, each time more issues were raised than solutions put forth.  That
> doesn't mean one can't keep trying, but realize this won't be easy.
>
> >- Do we want to Server to PUSH any or all Associated Answers, or
>
> This is what got DNSSEC started in the first place - the potential for
> servers to push data in the additional section.  With DNSSEC the danger
> of cache poisoning is reduced but now, for out of server bailiwick
> answers, the client will start chasing DNSSEC trust chains, perhaps
> needlessly.

You can chase chains when the client requests the data.  DNSSEC validation
doesn't need to always be done when the answer is received.

> >- Do we want the Client to PULL any or all Associated Answers, or
>
> The question I keep asking myself is: How is this different from a client
> just hitting a server with all anticipated questions at one time?  Why
> not just ask for qtype ANY all the time, for data sets owned by the same
> domain name.
>
> Caching (shared, that is) is supposed to play a role here, keeping
> answers closer to the need than at the authority.
>
> (And, of course as has been mentioned in the list, does this enable
> amplification?  I.e., just like ANY.)

We have solutions to amplification.  It isn't a boggie man.

> >- Do we want the Status Quo?
>
> For quite some years we tried to damp out special processing for types as
> this made rolling out new types easier with old code.  The idea was to
> get to where "Handling of Unknown DNS Resource Record (RR) Types" was
> possible.

Unknown RRs is designed to allow data to get to the client without
*requiring* intermediate servers to know the data content.  The
key word there is requiring.

There is nothing about not specifying additional section rules.  In
fact additional section rules are officially acceptable for unknown
types.

Additionally Unknown RRs expects servers to learn about new types.
Just they that knowledge isn't supposed to be a blocker.

> I can see developing a policy for DNS responders to include other RRsets
> as part of the response to a question, but how is this policy made known
> to the querier?  The querier needs to know it to decide if each other
> RRset is germane or a poisoning attempt.  (Germane meaning, genuinely
> related to the question.)

Stub clients presumably know or they wouldn't be asking for the type.

Recursive servers learn what to expect over time.  If it is signed data
they can just store it and validate it when requested.

> I can see developing a means for a client to ask for something and
> "whatever is relevant."  That's partly done by ANY - and in fact the same
> issue with ANY pops up here, does a cache with part of the answer only
> give back that or try to get the entire answer?  Will a recursive element
> have to track all portions of the response to a question instead of
> caching the sets individually? What if the TTL are set differently (on
> purpose)?

Perfect is the enemy of good enough.  Servers need to learn about new
types.  They just don't need to learn immediately.

> Do we want to split the DNS protocol between what is possible on TCP and
> what is possible on UDP?  Right now, AXFR is only available on TCP due to
> its design.  To we want to define some "dangerous" (so to speak) queries
> to be only on TCP?  And we have to define the semantics of how the
> responses are cached, tracked, etc.
>
> IMHO, if the server can let the client know what the policy regarding
> associated answers is, the server can push data to the client.  I don't
> really see how client pull is better than the client asking for things in
> parallel.

-- 
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

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

[Edward Lewis]

On 8/19/16, 13:24, "william manning"  wrote:

>First off, I take exception to the use of the word "dangerous".  AXFR isn't 
>dangerous, it's just the best way to do the job.  If there are other query 
>types that are better (or only) can be done over TCP, then so be it.  But they 
>aren't per se dangerous.

Dangerous is in the eye of the beholder.  I had in mind the critiques that ANY 
queries were dangerous (with some operators already curtailing them).  AXFR 
isn't dangerous, but it is restricted to TCP because of a different need, the 
need to maintain ordering of the segments.

>End of the day, this question is fundamentally one of which side knows best 
>what the application is looking for, the resolver or the server?   

That's the root cause of the work here.

In 2009 or so I recall an IAB draft document on DNS that urged an end to 
"curving the DNS" to applications.  My response was that the only evidence to 
date was the MX record's inclusion of the A record in the response - harking 
back to the origin of domains in email arguably driving the definition of the 
DNS as a protocol.  (Forgive a lot of hand waving, I do have another draft that 
covers that in more formal detail.)

The DNS has, historically, for better or worse, remained neutral towards the 
applications that use it.  I suspect that the fear was that if the DNS helped 
one protocol out, it might harm another, so we've kept an even keel.  I'm not 
saying that we must remain that way, just that this is the historical record.

The problem with now defining what additional record sets belong to certain 
queries is that we make handling unknown record types murky.  Perhaps we can 
have a subset of RR type codes that are set aside for types with additional 
section expectations - I just can't imagine writing future-proofed code in that 
case.  So maybe that's a stupid idea.  (Not the first one today.)

I'm open to other solutions.  I'm just giving a historical perspective.  What 
can go in EDNS0 or into "session" state is an open topic, as an example.



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Edward Lewis]

On 8/16/16, 08:57, "DNSOP on behalf of Tim Wicinski"  wrote:

I've only read briefly the drafts and see hints that issues I raise below are 
still lingering.

There's no denying that there's a desire to solve "this".  I keep in mind that 
this isn't the first time there's been a desire to add this to the DNS, each 
time more issues were raised than solutions put forth.  That doesn't mean one 
can't keep trying, but realize this won't be easy.

>- Do we want to Server to PUSH any or all Associated Answers, or

This is what got DNSSEC started in the first place - the potential for servers 
to push data in the additional section.  With DNSSEC the danger of cache 
poisoning is reduced but now, for out of server bailiwick answers, the client 
will start chasing DNSSEC trust chains, perhaps needlessly.

>- Do we want the Client to PULL any or all Associated Answers, or

The question I keep asking myself is: How is this different from a client just 
hitting a server with all anticipated questions at one time?  Why not just ask 
for qtype ANY all the time, for data sets owned by the same domain name.

Caching (shared, that is) is supposed to play a role here, keeping answers 
closer to the need than at the authority.

(And, of course as has been mentioned in the list, does this enable 
amplification?  I.e., just like ANY.)

>- Do we want the Status Quo?

For quite some years we tried to damp out special processing for types as this 
made rolling out new types easier with old code.  The idea was to get to where 
"Handling of Unknown DNS Resource Record (RR) Types" was possible.

I can see developing a policy for DNS responders to include other RRsets as 
part of the response to a question, but how is this policy made known to the 
querier?  The querier needs to know it to decide if each other RRset is germane 
or a poisoning attempt.  (Germane meaning, genuinely related to the question.)

I can see developing a means for a client to ask for something and "whatever is 
relevant."  That's partly done by ANY - and in fact the same issue with ANY 
pops up here, does a cache with part of the answer only give back that or try 
to get the entire answer?  Will a recursive element have to track all portions 
of the response to a question instead of caching the sets individually?  What 
if the TTL are set differently (on purpose)?

Do we want to split the DNS protocol between what is possible on TCP and what 
is possible on UDP?  Right now, AXFR is only available on TCP due to its 
design.  To we want to define some "dangerous" (so to speak) queries to be only 
on TCP?  And we have to define the semantics of how the responses are cached, 
tracked, etc.

IMHO, if the server can let the client know what the policy regarding 
associated answers is, the server can push data to the client.  I don't really 
see how client pull is better than the client asking for things in parallel.


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

In message 

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

[Marek Vavruša]

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  wrote:
>
> Named returns associated
>
> * A/ records with MX lookups if available
> * A/ records with SRV lookups if available
> * SRV/A/ records with NAPTR lookups if available
> * A/ records with NAPTR lookups if available
>
> As of 9.11 named returns associated
>
> * A//TLSA records with MX lookups if available
> * A//TLSA records with SRV lookups if available
> * SRV/A//TLSA records with NAPTR lookups if available
> * A/ 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  and  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: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

Named returns associated

* A/ records with MX lookups if available
* A/ records with SRV lookups if available
* SRV/A/ records with NAPTR lookups if available
* A/ records with NAPTR lookups if available

As of 9.11 named returns associated

* A//TLSA records with MX lookups if available
* A//TLSA records with SRV lookups if available
* SRV/A//TLSA records with NAPTR lookups if available
* A/ 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  and  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: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Marek Vavruša]

On Thu, Aug 18, 2016 at 12:52 PM, Paul Hoffman  wrote:
> On 18 Aug 2016, at 11:29, Marek Vavruša wrote:
>
>> Or SRV.
>
>
> I disagree that a user, when asking for a SRV record, doesn't know that it
> is likely that they would want the results for the information that comes
> back in the RDATA.

No question about that, but she doesn't know what the target name is.
Expressing "I want SRV type for this name, and A/ for the SRV
record targets" is doable, at the cost of additional complexity on
both client and server.

>> These are cases where authoritative/resolver adding
>> interesting records as additionals works better.
>> Authoritatives have been doing that with extra SOA/NS in authority for
>> a while (for positive answers), but now
>> resolvers can hardly use them if these records are not secure.
>
>
> Security of additional data is important, but orthogonal to what can be
> asked for or pushed.
>
>> Regardless of which draft is going to be adopted,
>
>
> This thread is not about "which draft", it is about what is needed.

Thank you, I should have phrased that differently.

> --Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On 18 Aug 2016, at 11:29, Marek Vavruša wrote:


Or SRV.


I disagree that a user, when asking for a SRV record, doesn't know that 
it is likely that they would want the results for the information that 
comes back in the RDATA.



These are cases where authoritative/resolver adding
interesting records as additionals works better.
Authoritatives have been doing that with extra SOA/NS in authority for
a while (for positive answers), but now
resolvers can hardly use them if these records are not secure.


Security of additional data is important, but orthogonal to what can be 
asked for or pushed.



Regardless of which draft is going to be adopted,


This thread is not about "which draft", it is about what is needed.

--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Marek Vavruša]

Or SRV. These are cases where authoritative/resolver adding
interesting records as additionals works better.
Authoritatives have been doing that with extra SOA/NS in authority for
a while (for positive answers), but now
resolvers can hardly use them if these records are not secure.

Regardless of which draft is going to be adopted, it should be
explicitly stated which records should client accept.
e.g. pushed A+ matching QNAME could be accepted even from insecure
zones, but records matching SRV target shouldn't be.

Marek

On Thu, Aug 18, 2016 at 10:57 AM, John Levine  wrote:
>>Are there QTYPEs that, when I ask for them, I won't know that I should
>>also ask for the related info?
>
> NAPTR
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

>Are there QTYPEs that, when I ask for them, I won't know that I should 
>also ask for the related info?

NAPTR

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

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

On 18 August 2016 at 10:40, Paul Hoffman  
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/ 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/ of the requested host and the 
_http._tcp. 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthew Pounsett]

On 18 August 2016 at 10:40, Paul Hoffman  wrote:

> On 18 Aug 2016, at 7:19, Matthew Pounsett wrote:
>
> On 18 August 2016 at 01:33, william manning 
>> 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  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/ of the requested host and the _http._tcp. 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

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

[Paul Hoffman]

On 18 Aug 2016, at 7:19, Matthew Pounsett wrote:

On 18 August 2016 at 01:33, william manning 


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  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?


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthew Pounsett]

On 18 August 2016 at 01:33, william manning 
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.

If a client is given a delegation today, you don't complain because glue is
supplied.  It's necessary for the obvious next step.   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?


>
> Please advise.
>
> /Wm
>
> On Wed, Aug 17, 2016 at 8:35 AM, Matthew Pounsett 
> wrote:
>
>>
>> On 16 August 2016 at 08:57, Tim Wicinski  wrote:
>>
>>> All,
>>>
>>>
>>> In Berlin we had two presentations on different methods of returning
>>> multiple responses:
>>>
>>> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/
>>>
>>> https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/
>>>
>>> and a presentation in Buenos Aires:
>>>
>>> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/
>>>
>>> All of these documents are attempting to solve a larger problem in
>>> different ways.
>>> The end result is "Return Associated Answer" to the client.
>>>
>>> The question is starting to coalesce around these two premises:
>>>
>>> - Do we want to Server to PUSH any or all Associated Answers, or
>>>
>>
>>
>> - Do we want the Client to PULL any or all Associated Answers, or
>>>
>>
>> There are times when the server side of the communication will know what
>> the client needs next, much the same as following a CNAME chain.  This
>> might include records included automatically, such as returning the A/
>> records from the RDATA of a SRV record.  It might also include records
>> added by local policy, whether that's from configuration or learned by
>> heuristics.  In the future that might include things like returning an HTTP
>> SRV record for the apex (and associated address records) when a 'www' label
>> is queried for.
>>
>> There's a fair bit of overlap between the use cases for push and pull,
>> but I think more use cases are covered by push than pull.  It's possible
>> that the use cases for pull are a subset of the use cases for push.  I
>> haven't yet thought of any pull use cases that couldn't be covered by push.
>>
>> I think there's some flexibility to be gained from implementers having
>> both tools available, but I think if we were to only pursue one it should
>> be push.  I think the fears of providing a DDoS tool can be  assuaged by
>> requiring the use of things like cookies, or session signalling as a
>> prerequisite.
>>
>>
>>>
>>> - Do we want the Status Quo?
>>>
>>
>> The status quo works ... but I believe there are things to be gained by
>> moving forward.
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[william manning]

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.

Please advise.

/Wm

On Wed, Aug 17, 2016 at 8:35 AM, Matthew Pounsett 
wrote:

>
> On 16 August 2016 at 08:57, Tim Wicinski  wrote:
>
>> All,
>>
>>
>> In Berlin we had two presentations on different methods of returning
>> multiple responses:
>>
>> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/
>>
>> https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/
>>
>> and a presentation in Buenos Aires:
>>
>> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/
>>
>> All of these documents are attempting to solve a larger problem in
>> different ways.
>> The end result is "Return Associated Answer" to the client.
>>
>> The question is starting to coalesce around these two premises:
>>
>> - Do we want to Server to PUSH any or all Associated Answers, or
>>
>
>
> - Do we want the Client to PULL any or all Associated Answers, or
>>
>
> There are times when the server side of the communication will know what
> the client needs next, much the same as following a CNAME chain.  This
> might include records included automatically, such as returning the A/
> records from the RDATA of a SRV record.  It might also include records
> added by local policy, whether that's from configuration or learned by
> heuristics.  In the future that might include things like returning an HTTP
> SRV record for the apex (and associated address records) when a 'www' label
> is queried for.
>
> There's a fair bit of overlap between the use cases for push and pull, but
> I think more use cases are covered by push than pull.  It's possible that
> the use cases for pull are a subset of the use cases for push.  I haven't
> yet thought of any pull use cases that couldn't be covered by push.
>
> I think there's some flexibility to be gained from implementers having
> both tools available, but I think if we were to only pursue one it should
> be push.  I think the fears of providing a DDoS tool can be  assuaged by
> requiring the use of things like cookies, or session signalling as a
> prerequisite.
>
>
>>
>> - Do we want the Status Quo?
>>
>
> The status quo works ... but I believe there are things to be gained by
> moving forward.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[abby pan]

Status Quo  is good for ipv4 to ipv6 migration.

Totally agree with william on PUSH/PULL.

1. Hotest internet service's RDATA always exists in recursive dns cache,
PUSH is not speed up much except hit-miss. ( recursive -> authority )

2. clients known what they want, PULL & prefething is Ockham's Razor. (
stub -> recursive )

Imagine that  if someone visits  serv-a.xxx.com and  serv-b.xxx.com.
If serv-a.xxx.com has the same associate PUSH RRDATA with serv-b.xxx.com,
for example css.xxx.com, image.xxx.com, js.xxx.com, etc.
Dumplicate response and increase the DDoS risk (abuse use).


william manning 于2016年8月17日周三 下午6:59写道：

> from an attacker POV, I would strongly support PUSH, as it would increase
> DDoS effectiveness. The performance enhancement seems to be based on some
> presumptions about servers retaining residual knowledge of the resolver
> behaviours.
> PULL minimizes the attack surface.  wrt cache coherence and delay, I think
> the resolver is closer to the APPs using the data and so may be in a batter
> place to understand what is and will be needed.  Those needs can be met
> with prefetching/caching, which mitigate the RTT/delay issues.
> Status Quo - if it was good enough for Phil Almquist, it's good enough for
> me! :)
>
> /Wm
>
> On Tue, Aug 16, 2016 at 3:32 PM, George Michaelson 
> wrote:
>
>> On Tue, Aug 16, 2016 at 10:57 PM, Tim Wicinski 
>> wrote:
>>
>> > All of these documents are attempting to solve a larger problem in
>> different
>> > ways. The end result is "Return Associated Answer" to the client.
>> >
>> > The question is starting to coalesce around these two premises:
>> >
>> > - Do we want to Server to PUSH any or all Associated Answers, or
>>
>> This option reduces effective RTT delay. It has the most performace
>> improvement in DNS delay reduction, assuming the extra payload is
>> determined to be needed eg flags, or heuristical analysis of client
>> behaviour.
>>
>> Its cost is additional data on the server->client path. Personally, I
>> think this is the best option and the one most likely to increase
>> cache coherence, timeliness, and reduce delay in the DNS phase.
>>
>> >
>> > - Do we want the Client to PULL any or all Associated Answers, or
>>
>> This minimizes traffic. Otherwise, it maximises delay if subsequent
>> query is needed. I would suggest that a client option or flag to
>> request this behaviour is plausible if PUSH is the norm.
>>
>> >
>> > - Do we want the Status Quo?
>>
>> This seems the safest option and the most inherently boring, and
>> pointless. Why are we here if we think the best bet is the status quo?
>> Down down, deeper and down...
>>
>> -G
>> >
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 

Best Regards

Pan Lanlan

+86 186 9834 2356
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthew Pounsett]

On 16 August 2016 at 08:57, Tim Wicinski  wrote:

> All,
>
>
> In Berlin we had two presentations on different methods of returning
> multiple responses:
>
> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/
>
> https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/
>
> and a presentation in Buenos Aires:
>
> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/
>
> All of these documents are attempting to solve a larger problem in
> different ways.
> The end result is "Return Associated Answer" to the client.
>
> The question is starting to coalesce around these two premises:
>
> - Do we want to Server to PUSH any or all Associated Answers, or
>


- Do we want the Client to PULL any or all Associated Answers, or
>

There are times when the server side of the communication will know what
the client needs next, much the same as following a CNAME chain.  This
might include records included automatically, such as returning the A/
records from the RDATA of a SRV record.  It might also include records
added by local policy, whether that's from configuration or learned by
heuristics.  In the future that might include things like returning an HTTP
SRV record for the apex (and associated address records) when a 'www' label
is queried for.

There's a fair bit of overlap between the use cases for push and pull, but
I think more use cases are covered by push than pull.  It's possible that
the use cases for pull are a subset of the use cases for push.  I haven't
yet thought of any pull use cases that couldn't be covered by push.

I think there's some flexibility to be gained from implementers having both
tools available, but I think if we were to only pursue one it should be
push.  I think the fears of providing a DDoS tool can be  assuaged by
requiring the use of things like cookies, or session signalling as a
prerequisite.


>
> - Do we want the Status Quo?
>

The status quo works ... but I believe there are things to be gained by
moving forward.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Bob Harold]

On Tue, Aug 16, 2016 at 8:57 AM, Tim Wicinski  wrote:

> All,
>
>
> In Berlin we had two presentations on different methods of returning
> multiple responses:
>
> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/
>
> https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/
>
> and a presentation in Buenos Aires:
>
> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/
>
> All of these documents are attempting to solve a larger problem in
> different ways.
> The end result is "Return Associated Answer" to the client.
>
> The question is starting to coalesce around these two premises:
>
> - Do we want to Server to PUSH any or all Associated Answers, or
>
> - Do we want the Client to PULL any or all Associated Answers, or
>
>
> There are times when the client knows that it will need multiple pieces of
information, and an efficient way to ask several questions at once is
valuable.
The client would have to track whether the server has trouble with the
requests and fall back to single requests.

There are times when the server knows that the client is likely to want
certain records once it gets an answer, and if it can include those, there
is a benefit.
Those can be records based on the answer - for example an SRV lookup is
likely to want an A and  next.
Or they can be outside knowledge that the server is given or learns - like
if a particular web page is looked up, then these others hosts are likely
to be looked up next for other parts of that web page.
I think that the client should have a way to signal support for this, and
the server only add records if the client signals support.

I say "client" but I think the same could be useful at each link in the DNS
lookup.

-- 
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[fujiwara]

Hello,

> From: Tim Wicinski 
> In Berlin we had two presentations on different methods of returning
> multiple responses:

> All of these documents are attempting to solve a larger problem in
> different ways.
> The end result is "Return Associated Answer" to the client.
> 
> The question is starting to coalesce around these two premises:

Is it true that the extensions are used both RD=1 (stub to full-service 
resolver)
and RD=0 (full-servicce resolver to authoritative) ?

> - Do we want to Server to PUSH any or all Associated Answers, or

> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/

Full-service resolvers need to preserve/cache EXTRA RR and all related
qname/qtype pairs. And then, they need to generate the same answers as
the authoritative servers.

Stub resolvers need to know/detect the full-service resolver support
the extension or not. Currently, stub resolvers send both A and 
queries. We need to consider how to stop sending multiple queries.

> - Do we want the Client to PULL any or all Associated Answers, or

> https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/

PULL (multiple queries) case, the stub resolver first sends QDCOUNT>1
or with new EDNS options, and if it received FORMERR / ignored, it can
switch to traditional mode.

For both cases, we should take care of the nonexistence of additional
names or additional types. The associated answers may need NSEC RR.

# Non-existent pseudo RDATA may be useful, however, RDLENGTH=0 is not reserved.

-- 
Kazunori Fujiwara, JPRS 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[william manning]

from an attacker POV, I would strongly support PUSH, as it would increase
DDoS effectiveness. The performance enhancement seems to be based on some
presumptions about servers retaining residual knowledge of the resolver
behaviours.
PULL minimizes the attack surface.  wrt cache coherence and delay, I think
the resolver is closer to the APPs using the data and so may be in a batter
place to understand what is and will be needed.  Those needs can be met
with prefetching/caching, which mitigate the RTT/delay issues.
Status Quo - if it was good enough for Phil Almquist, it's good enough for
me! :)

/Wm

On Tue, Aug 16, 2016 at 3:32 PM, George Michaelson  wrote:

> On Tue, Aug 16, 2016 at 10:57 PM, Tim Wicinski  wrote:
>
> > All of these documents are attempting to solve a larger problem in
> different
> > ways. The end result is "Return Associated Answer" to the client.
> >
> > The question is starting to coalesce around these two premises:
> >
> > - Do we want to Server to PUSH any or all Associated Answers, or
>
> This option reduces effective RTT delay. It has the most performace
> improvement in DNS delay reduction, assuming the extra payload is
> determined to be needed eg flags, or heuristical analysis of client
> behaviour.
>
> Its cost is additional data on the server->client path. Personally, I
> think this is the best option and the one most likely to increase
> cache coherence, timeliness, and reduce delay in the DNS phase.
>
> >
> > - Do we want the Client to PULL any or all Associated Answers, or
>
> This minimizes traffic. Otherwise, it maximises delay if subsequent
> query is needed. I would suggest that a client option or flag to
> request this behaviour is plausible if PUSH is the norm.
>
> >
> > - Do we want the Status Quo?
>
> This seems the safest option and the most inherently boring, and
> pointless. Why are we here if we think the best bet is the status quo?
> Down down, deeper and down...
>
> -G
> >
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[George Michaelson]

my bad. I've been re-framed.

Contextually, PUSH means (to me at least) 'do this promiscuously' and
PULL means (to me at least) 'do this if asked' -which is not what I
previously understood.

In that case, I think PULL makes more sense: do this, if the client
signals its what it wants. Otherwise, don't do this. Its the POLA
behaviour.

(thanks for Paul Hoffman's cluestick hit)

-G

On Tue, Aug 16, 2016 at 10:57 PM, Tim Wicinski  wrote:
> All,
>
>
> In Berlin we had two presentations on different methods of returning
> multiple responses:
>
> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/
>
> https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/
>
> and a presentation in Buenos Aires:
>
> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/
>
> All of these documents are attempting to solve a larger problem in different
> ways.
> The end result is "Return Associated Answer" to the client.
>
> The question is starting to coalesce around these two premises:
>
> - Do we want to Server to PUSH any or all Associated Answers, or
>
> - Do we want the Client to PULL any or all Associated Answers, or
>
> - Do we want the Status Quo?
>
> thanks
> tim
>
>
>
> (Thanks to Paul Hoffman for assistance)
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On 16 Aug 2016, at 5:57, Tim Wicinski wrote:


- Do we want to Server to PUSH any or all Associated Answers, or

- Do we want the Client to PULL any or all Associated Answers, or

- Do we want the Status Quo?


Client pull, which is really just the client saying "if you have this, 
send it to me in the Additional section", fits the current DNS model the 
best. (Well, "status quo" fits it the best but it causes more overhead 
than client pull.)


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[George Michaelson]

On Tue, Aug 16, 2016 at 10:57 PM, Tim Wicinski  wrote:

> All of these documents are attempting to solve a larger problem in different
> ways. The end result is "Return Associated Answer" to the client.
>
> The question is starting to coalesce around these two premises:
>
> - Do we want to Server to PUSH any or all Associated Answers, or

This option reduces effective RTT delay. It has the most performace
improvement in DNS delay reduction, assuming the extra payload is
determined to be needed eg flags, or heuristical analysis of client
behaviour.

Its cost is additional data on the server->client path. Personally, I
think this is the best option and the one most likely to increase
cache coherence, timeliness, and reduce delay in the DNS phase.

>
> - Do we want the Client to PULL any or all Associated Answers, or

This minimizes traffic. Otherwise, it maximises delay if subsequent
query is needed. I would suggest that a client option or flag to
request this behaviour is plausible if PUSH is the norm.

>
> - Do we want the Status Quo?

This seems the safest option and the most inherently boring, and
pointless. Why are we here if we think the best bet is the status quo?
Down down, deeper and down...

-G
>

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop