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

From: Tim Wicinski <[email-masked]>
Date: Tue, 16 Aug 2016 08:57:04 -0400

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

---

From: George Michaelson <[email-masked]>
Date: Wed, 17 Aug 2016 08:32:18 +1000

On Tue, Aug 16, 2016 at 10:57 PM, Tim Wicinski <[email-masked]> 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.
>

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

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 16 Aug 2016 16:57:57 -0700

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

---

From: George Michaelson <[email-masked]>
Date: Wed, 17 Aug 2016 11:03:03 +1000

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 <[email-masked]> wrote:
> ways.
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: william manning <[email-masked]>
Date: Wed, 17 Aug 2016 03:59:01 -0700

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 <[email-masked]> wrote:

> different

---

From: [email-masked]
Date: Wed, 17 Aug 2016 20:28:06 +0900 (JST)

Hello,

> From: Tim Wicinski <[email-masked]>

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

> 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 AAAA
queries. We need to consider how to stop sending multiple queries.

> 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 <[email-masked]>

---

From: Bob Harold <[email-masked]>
Date: Wed, 17 Aug 2016 10:06:05 -0400

On Tue, Aug 16, 2016 at 8:57 AM, Tim Wicinski <[email-masked]> wrote:

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

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 17 Aug 2016 11:35:39 -0400

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/AAAA
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.

---

From: abby pan <[email-masked]>
Date: Thu, 18 Aug 2016 01:48:34 +0000

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

-- 

Best Regards

Pan Lanlan

+86 186 9834 2356

---

From: william manning <[email-masked]>
Date: Wed, 17 Aug 2016 22:33:59 -0700

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 <[email-masked]>
wrote:

> 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

---

From: Matthew Pounsett <[email-masked]>
Date: Thu, 18 Aug 2016 10:19:09 -0400

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

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

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 18 Aug 2016 07:40:20 -0700

>> Spam being "PUSHED" to the Resolver who may or may not want the data.

Disagree: partial hyperbole.

> 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

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

---

From: Matthew Pounsett <[email-masked]>
Date: Thu, 18 Aug 2016 11:04:32 -0400

On 18 August 2016 at 10:40, Paul Hoffman <[email-masked]> wrote:

> If I'm making an SRV query, I know I can ask for ("pull" in Tim's wording)
> additional 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.

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 18 Aug 2016 08:22:30 -0700

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

> the former nullifies that argument against implementation.

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

> 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

---

From: Marek Vavruša <[email-masked]>
Date: Thu, 18 Aug 2016 11:29:09 -0700

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+AAAA 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 <[email-masked]> wrote:
> NAPTR

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 18 Aug 2016 12:52:43 -0700

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

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

---

From: Marek Vavruša <[email-masked]>
Date: Thu, 18 Aug 2016 13:11:23 -0700

On Thu, Aug 18, 2016 at 12:52 PM, Paul Hoffman <[email-masked]> wrote:
> 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/AAAA for the SRV
record targets" is doable, at the cost of additional complexity on
both client and server.

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

Thank you, I should have phrased that differently.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Aug 2016 12:32:32 +1000

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: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Marek Vavruša <[email-masked]>
Date: Thu, 18 Aug 2016 20:06:45 -0700

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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Aug 2016 13:43:31 +1000

In message <CAC=TB13se3egHwRGebkPZG7Fj_JaPG=obR7Mo5-jhEYv=[email-masked]>
> don't follow up with an extra query) ?

Clients can change.  The more servers that return data the more
likely clients will optimise to look for it.

Stub clients should just accept what is sent and smart ones do
(think SMTP servers which remember address records returned with
MX responses).

> I'd like to have a better guideline on what records should be accepted

You have baliwick and DNSSEC to consider.  You can always cache
data + rrsig and validate prior to returning it to clients.  Named
does also do lazy validation like this.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 19 Aug 2016 12:32:19 +0000

On 8/16/16, 08:57, "DNSOP on behalf of Tim Wicinski" <[email-masked] on behalf of [email-masked]> 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.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 19 Aug 2016 19:35:21 +0000

On 8/19/16, 13:24, "william manning" <[email-masked]> 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.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 20 Aug 2016 05:53:54 +1000

In message <[email-masked]>, Edward Lewis write
s:
> 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.
>
> 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.

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

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

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

---

From: Tony Finch <[email-masked]>
Date: Thu, 25 Aug 2016 13:25:01 +0100

Edward Lewis <[email-masked]> 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 AAAA 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  <[email-masked]>  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.

---

From: Tony Finch <[email-masked]>
Date: Thu, 25 Aug 2016 13:33:49 +0100

Matthew Pounsett <[email-masked]> wrote:
> record in separate queries, not knowing if the latter even exists.

A client can query for A AAAA 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  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Northwest Fitzroy, Sole: Variable 3, becoming southwesterly 4 or 5. Slight or
moderate. Showers. Good.

---

From: william manning <[email-masked]>
Date: Thu, 25 Aug 2016 08:35:50 -0700

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 <[email-masked]> wrote:

> Edward Lewis <[email-masked] <javascript:;>> wrote:
>
> f.anthony.n.finch  <[email-masked] <javascript:;>>  http://dotat.at/  -  I
> xn--zr8h punycode
> [email-masked] <javascript:;>

---

From: Tony Finch <[email-masked]>
Date: Thu, 25 Aug 2016 17:25:57 +0100

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

---

From: Shane Kerr <[email-masked]>
Date: Mon, 29 Aug 2016 14:19:16 +0800

Tim,

[ Apologies for coming late to the party. I was on vacation. ]

At 2016-08-16 08:57:04 -0400

> - Do we want the Status Quo?

In Berlin there was discussion of measurement, IIRC.

-----

For the PULL approach, as I mentioned in Berlin it seems like such an
obvious win to collect A and AAAA together into a single query - at
least from the stub to the recursive resolver.

For the recursive-to-authority side it seems much less obvious and less
of a win, since caching will tend to overwhelm any benefit and since you
have to worry about maintaining state about whether a given authority
server supports the protocol change.

Looking at the SIDN statistics it seems like there is about a 4- or
5-to-1 ratio of A to AAAA queries:

https://stats.sidnlabs.nl/#/dns

In this case, the maximum expected "win" on the authority side seems to
be about 10%, which is not great, but maybe worth pursuing.

-----

For the PUSH approach, again metrics would help. I guess the main
beneficiaries would be CDN or other content sites who use low TTL and
generated replies, so maybe someone who works in that environment could
think of a reasonable metric?

Or is the expectation here also that a recursive resolver would be able
to deliver answers before the client asks for them? I can see
potential big benefits for mobile or other high-latency devices if done
right. Instead of thinking about evil advertising deliveries, a smart
recursive resolver can just use statistics and delivery
high-probability answers before the stub resolvers ask for them...

Cheers,

--
Shane