Subject: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

From: Warren Kumari <[email-masked]>
Date: Sun, 11 Jan 2015 15:52:09 -0500

Hi all,

This document may contain much that makes folk grumpy.

It proposes allowing an authoritative nameserver to return additional
information (surprisingly, in the Additional section), and have
recursives trust it (because it is DNSSEC signed). This makes
responses larger, and so we propose an, um, interesting mitigation to
the DDoS concern... you'll have to read it to find out what :-P

W

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Sun, Jan 11, 2015 at 3:47 PM
Subject: New Version Notification for
draft-wkumari-dnsop-multiple-responses-00.txt
To: Wesley Hardaker <[email-masked]>, Warren Kumari
<[email-masked]>, Zhiwei Yan <[email-masked]>

A new version of I-D, draft-wkumari-dnsop-multiple-responses-00.txt
has been successfully submitted by Warren Kumari and posted to the
IETF repository.

Name:           draft-wkumari-dnsop-multiple-responses
Revision:       00
Title:          Returning multiple answers in a DNS response.
Document date:  2015-01-11
Group:          Individual Submission
Pages:          8
URL:
http://www.ietf.org/internet-drafts/draft-wkumari-dnsop-multiple-responses-00.txt
Status:
https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/
Htmlized:
http://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-00

Abstract:
   This document (re)introduces the ability to provide multiple answers
   in a DNS response.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Davey Song (宋林健) <[email-masked]>
Date: Tue, 13 Jan 2015 12:26:00 +0800

Hi Warren

It's good idea that the authority DNS be smart enough to predict or
configured to package all the information for a URL as a whole object (like
a webpage). It will reduce the latency for user. 

As to the draft itself, there are two questions:

First, for a same transaction, the cost from using TCP may be more than the
gain from the queries you save, which may ultimately let the performance
become even worse. Do you have any consideration on this?

Second, the purpose of using TCP is to mitigate amplify attack as you
describe in the draft. I notice that there is a draft using DNS cookie to
counter that problem. But it lacks incentive to deploy. For my concern, you
can consider to combine the two ideas to achieve better result.

Glad to see more discussion on application and innovation of large packet
which will lead us to break through the limitation of 512B :-)

Davey

-----邮件原件-----
发件人: DNSOP [mailto:[email-masked]] 代表 Warren Kumari
发送时间: 2015年1月12日 4:52
收件人: dnsop
主题: [DNSOP] Fwd: New Version Notification for

Hi all,

It proposes allowing an authoritative nameserver to return additional
information (surprisingly, in the Additional section), and have recursives
trust it (because it is DNSSEC signed). This makes responses larger, and so
we propose an, um, interesting mitigation to the DDoS concern... you'll have
to read it to find out what :-P

W

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Sun, Jan 11, 2015 at 3:47 PM
Subject: New Version Notification for
draft-wkumari-dnsop-multiple-responses-00.txt
To: Wesley Hardaker <[email-masked]>, Warren Kumari <[email-masked]>,
Zhiwei Yan <[email-masked]>

A new version of I-D, draft-wkumari-dnsop-multiple-responses-00.txt
has been successfully submitted by Warren Kumari and posted to the IETF
repository.

http://www.ietf.org/internet-drafts/draft-wkumari-dnsop-multiple-responses-0
0.txt

Abstract:

The IETF Secretariat

--
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Warren Kumari <[email-masked]>
Date: Tue, 13 Jan 2015 12:37:56 -0500

On Tue, Jan 13, 2015 at 9:13 AM, Paul Wouters <[email-masked]> wrote:
> On Tue, 13 Jan 2015, Davey Song (宋林健) wrote:
>
> And also, if already doing tcp the the auth server, why not just ask the
> 4 questions asynchronously over the TCP channel, instead of waiting to
> see if the server will give you a freebie, where you might have to send
> another query (After the RTT) for the data?

Because you don't *know* all of the questions you need to ask until you get:
A: some of the answers and / or
B: some of the resources at the answers.

If I want to send you mail at nohats.ca I do an MX for nohats.ca.
This gives me back the inventively names mx.nohats.ca:

wkumari-macbookpro1:tmp wkumari$ dig +short mx nohats.ca
10 mx.nohats.ca.

Only *after* I get that back do I know that I need resolve
mx.nohats.ca into an address. Similar issues happen with CNAME chains,
etc. Before getting back some answers I don't know that I'll need the
others.

I also hit www.nohats.ca in a webbrowser while running 'tcpdump port
53' and got:
12:16:29.846791 IP 10.2.3.97.31679 >
google-public-dns-a.google.com.domain: 49210+ A? www.nohats.ca. (31)
12:16:30.640061 IP 10.2.3.97.36067 >
google-public-dns-a.google.com.domain: 22581+ A? nohats.ca. (27)
12:16:31.953095 IP 10.2.3.97.32374 >
google-public-dns-a.google.com.domain: 55912+ A? www.paypal.com. (32)
12:16:31.953447 IP 10.2.3.97.39594 >
google-public-dns-a.google.com.domain: 52512+ A? api.flattr.com. (32)
12:16:32.063993 IP 10.2.3.97.57364 >
google-public-dns-a.google.com.domain: 28378+ A?
blog.intelligistgroup.com. (43)
12:16:32.064204 IP 10.2.3.97.22750 >
google-public-dns-a.google.com.domain: 14230+ A? libreswan.org. (31)
12:16:32.064404 IP 10.2.3.97.43119 >
google-public-dns-a.google.com.domain: 42571+ A? heml.is. (25)
12:16:32.265799 IP 10.2.3.97.22719 >
google-public-dns-a.google.com.domain: 60101+ A? www.paypal.com. (32)
12:16:32.825883 IP 10.2.3.97.15536 >
google-public-dns-a.google.com.domain: 65455+ A? flattr.com. (28)
12:16:32.826109 IP 10.2.3.97.36181 >
google-public-dns-a.google.com.domain: 64959+ A? static1.flattr.net.
(36)
12:16:32.826273 IP 10.2.3.97.12831 >
google-public-dns-a.google.com.domain: 1690+ A? static2.flattr.net.
(36)
12:16:32.831187 IP 10.2.3.97.23825 >
google-public-dns-a.google.com.domain: 11673+ A? static3.flattr.net.
(36)
12:16:32.832103 IP 10.2.3.97.32762 >
google-public-dns-a.google.com.domain: 63752+ A? static4.flattr.net.
(36)
12:16:32.897722 IP 10.2.3.97.27532 >
google-public-dns-a.google.com.domain: 18520+ A? 2.bp.blogspot.com.
(35)
12:16:32.930835 IP 10.2.3.97.43140 >
google-public-dns-a.google.com.domain: 57738+ A?
sharoncol.balkowitsch.com. (43)
12:16:32.986412 IP 10.2.3.97.51562 >
google-public-dns-a.google.com.domain: 52486+ A? images.nap.edu. (32)

This involved doing 6 separate queries to ns[12].flattr.net - if these
servers implemented this new thingie, when I did the first lookup
(api.flattr.com) it could have given me the answers for flattr.com,
static1.flattr.net., static2.flattr.net., static3.flattr.net.,
static4.flattr.net.
Until I've spoken to api.flattr.com and done some stuff (~800ms) I
have no idea that need to get static[1-4].flattr.com.

> The cookies wouldn't help much because it per definition introduced
> another round trip.
>
> Also, why hardcode the records on the auth server. I think it is much
> better to leave the auth servers as is, and have resolvers figure out
> dynamically what is often asked in bundles and see if it can stuff
> in an additional record there.

hmmm.. that's an interesting idea. This requires changing the stub as
well, which feels like lots of work :-P

>
> While I see a great use of a long term TCP connection between stubs and
> resolvers, I am not sure I'm much in favour or doing lots of TCP between
> resolver and auth server.
>
> Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 13 Jan 2015 10:45:57 -0800

> well, which feels like lots of work :-P

+1 to Warren's response. From an operational standpoint "an auth server can put more answers in than the querier might expect" is a heck of a lot easier to deploy than "teach the stubs to ask better questions".

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Tue, 13 Jan 2015 09:13:50 -0500 (EST)

Paul

---

From: Mark Andrews <[email-masked]>
Date: Wed, 14 Jan 2015 11:09:00 +1100

In message <[email-masked]>, Paul Wouters wr
ites:
> On Tue, 13 Jan 2015, Davey Song () wrote:
> 
> > First, for a same transaction, the cost from using TCP may be more than 
> > the gain from the queries you save, which may ultimately let the
> > performance become even worse. Do you have any consideration on this?
> 
> > describe in the draft. I notice that there is a draft using DNS cookie 
> > to counter that problem. But it lacks incentive to deploy. For my concern, 
> > you can consider to combine the two ideas to achieve better result.

Nameserver vendors will just turn this on by default, that is ISC's
intention with named once the option is finalized.  Theoretically
it should be ignored if not understood and if not it can be disabled
of a per server basis.

>From BIND 9.10 (configure --enable-sit).

	server 2001:428::7 { request-sit no; };

http://users.isc.org/~marka/ts/gov.optfail.html
http://users.isc.org/~marka/ts/au.optfail.html
http://users.isc.org/~marka/ts/tld.optfail.html
http://users.isc.org/~marka/ts/bottom.optfail.html
http://users.isc.org/~marka/ts/alexa.optfail.html

FORMERR will just cause the nameserver to think that EDNS is not
supported.  This is not a issue unless there are signed zones and
the resolver is validating.

BADVERS is identifiable in the response and you use it as a heuristic
to disable sending the option.

Echoing of the option is not a issue for cookies.

Timeout will be treated like EDNS is not supported.

NXDOMAIN can sometimes be returned by badly configured load balancers.
Adobe's load balance is a example of this.  They just need CNAME's
added to the backend nameserver but Adobe doesn't seem to understand
this.  They also don't respond correctly to CNAME queries despite
returning CNAME to A/AAAA queries.

> The cookies wouldn't help much because it per definition introduced

Cookies don't "require" another round trip.  Authoritative servers
can still adjust the responses they send depending upon whether
there is as valid server cookie or not.

Additionally I don't see nameservers leaving idle TCP connections
around for hours / days.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: George Michaelson <[email-masked]>
Date: Wed, 14 Jan 2015 10:19:36 +1000

>the resolver is validating.

Because somewhere north of 10% of the world now validates..

---

From: Mark Andrews <[email-masked]>
Date: Wed, 14 Jan 2015 12:44:12 +1100

In message <[email-masked]>
> Because somewhere north of 10% of the world now validates..

It is only a problem if the zone is signed and the server is broken
and you are validating.  That combination is miniscule.

	EDNS -> FORMERR -> Plain DNS
	EDNS + OPTION -> FORMERR -> Plain DNS

Now nameservers could do

	EDNS + OPTION -> FORMERR -> EDNS -> FORMERR -> Plain DNS

but that adds yet another round trip if EDNS is not supported.

BADVERS isn't as bad as you at least know that EDNS is supported

	EDNS + OPTION -> BADVERS -> EDNS

That said we need to have a active program to notify operators of
broken servers so they can get them fixed before people run into
these issues.

It is easy enough to identify servers that misbehave with unknown
EDNS options.  It only takes a couple of queries to differentiate
between EDNS not supported and broken EDNS support.

These were generated by looking at subsets of the Alexa top 1M and
processing the root zone.

http://users.isc.org/~marka/gov-report.html
http://users.isc.org/~marka/tld-report.html
http://users.isc.org/~marka/au-report.html
http://users.isc.org/~marka/alexa-report.html
http://users.isc.org/~marka/bottom-report.html

What would be useful would be for all TLD operators to generate
lists of broken servers and inform their operators.

Mark

---

From: "John Levine" <[email-masked]>
Date: 14 Jan 2015 02:17:52 -0000

>another query (After the RTT) for the data?

In most cases, you won't know what other questions to ask until you
get the initial response back.  In some cases, e.g., domains used in
web pages, you won't know the other questions until you've done a lot
of other work, too.

I'm not sure whether this is a good idea, but the motivation makes sense.

R's,
John

---

From: Warren Kumari <[email-masked]>
Date: Tue, 13 Jan 2015 23:19:35 -0500

> I'm not sure whether this is a good idea, but the motivation makes sense.

I'm also not sure that it is a good idea - it may be a case of
premature optimization (30 years on :-)), but I figured it was worth
discussing. It seems that there are a number of places where it might
make things harder^w, better, stronger, faster
(https://www.youtube.com/watch?v=K2cYWfq--Nw&t=0m50s), and doesn't
really violate the spec (too much!)

I'm surprised that no-one has yet commented on the 'Let's just co-opt
the Z bit for this' - I'm guessing that folk are not sure if I'm
kidding or not, and are scared to ask :-)

W

---

From: Paul Vixie <[email-masked]>
Date: Tue, 13 Jan 2015 20:28:06 -0800

> Warren Kumari <mailto:[email-masked]>
> Tuesday, January 13, 2015 8:19 PM
> ... I'm surprised that no-one has yet commented on the 'Let's just
> co-opt the Z bit for this' - I'm guessing that folk are not sure if
> I'm kidding or not, and are scared to ask :-) W

i think you're not kidding, but that you'll ignore input you consider
"grumpy", so i wasn't going to mention any specific defect. instead i'll
ask: what's your use case? do you, or your employer, or indeed anybody
anywhere, need this feature? for what?

i've long believed that just as A and AAAA are optional additional-data
in MX and SRV and NS responses, so it should be that A should be
optional additional-data for AAAA responses, and AAAA should be optional
additional-data for A responses.

those are use cases i understand, and where the protocol impact is
negligible, as in, it could be an FYI.

what have you got for "multiple-responses" in terms of motivation for
the complexity of a protocol change?

(if this is what you meant when you said you were expecting grumpy
responses, feel free to ignore me.)

-- 
Paul Vixie

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 14 Jan 2015 10:14:39 +0530

Hi Warren

I didn't read the whole thing, but quickly browsed it. I will follow up
with a better review, but here's one point:

>   2.  Additional records MUST only be served over TCP connections.
>       This is to mitigate Denial of Service reflection attacks.[1]

I think this draft should not concern itself with this, or at least not
use the word "MUST" here.

It seems this feature will be equally useful via UDP too, when it's
possible to transmit a reply of that size.  If each draft introducing a
feature requires TCP because it could result in amplification, it'll
limit its usefulness. (Take it with a grain of salt, because there may
be better reasons to limit something to TCP.)

The draft could instead suggest or require the use of DNS cookies that's
currently being drafted or RRL which cookies itself may suggest as a
fallback.

		Mukund

---

From: Warren Kumari <[email-masked]>
Date: Wed, 14 Jan 2015 00:22:08 -0500

On Tue, Jan 13, 2015 at 11:28 PM, Paul Vixie <[email-masked]> wrote:

>
>
>   Warren Kumari <[email-masked]>
> ... I'm surprised that no-one has yet commented on the 'Let's just co-opt
> the Z bit for this' - I'm guessing that folk are not sure if I'm kidding or
> not, and are scared to ask :-) W
>
>

*Need* the feature? Nope, it's just an optimization.
It seemed to me that DNSSEC allows you to actually have some faith in the
additional data, and so its worth revisiting if we can use it.  I have no
idea what my employer thinks of this - I wrote it because it seemed
interesting to me. In general they like things that make the user
experience faster, and (if this works), it should do that, so... probably
they'd like it.... but who knows....

>
> i've long believed that just as A and AAAA are optional additional-data in
> MX and SRV and NS responses, so it should be that A should be optional
> additional-data for AAAA responses, and AAAA should be optional

> negligible, as in, it could be an FYI.

Yup. Those seem reasonable. This is (IMO) just an extension of that idea...

>
> what have you got for "multiple-responses" in terms of motivation for the
> complexity of a protocol change?
>

I don't see this as a large protocol change - the 'only over tcp' was only
put in to mitigate the "this will make packets huge" concern that I figured
some people would have.. Other than that there is signaling support - which
I put in because I figured it didn't hurt. The actual including multiple
responses bit doesn't really seem to violate protocol - as you said re: A
and AAA as optional additional-data in MX and SRV and NS, and AAAA for A, A
for AAAA.

The motivation for this is just efficiency / reducing latency - looking up
foo.example, getting a CNAME to bar.example and then looking that up in
another transaction seems inefficient and inelegant.
Similarly, looking up www.example, getting the webpage and then doing a
bunch of separate lookups for all the resources in it, like
 images.example, js.example, css.example simply seems wasteful, and offends
me :-) [0]

This optimization might not be worth it - but I figured drafts are cheap,
and worth discussing...
If the consensus is that this is not worth doing, I'm fine to abandon the
work.

> responses, feel free to ignore me.)

Nah, that wasn't a grumpy response. "Your draft is bad *and you should feel
bad*" would be....

W

[0]: These examples are somewhat self-inflicted pain - you could have
skipped the CNAME, and you could also have put all the resources on www.foo.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 13 Jan 2015 22:08:00 -0800

> Tuesday, January 13, 2015 9:22 PM
>
> ... I wrote it because it seemed interesting to me.

i think you should do a deeper cost:benefit dive before proposing new
signalling on-the-wire.

>
>     i've long believed that just as A and AAAA are optional
>     additional-data in MX and SRV and NS responses, so it should be
>     that A should be optional additional-data for AAAA responses, and
>     AAAA should be optional additional-data for A responses. 
>
>

not just an extension of, because there is no new signalling on-the-wire
in the additional-data behaviours i mentioned above. we could do those
now, and not require any upgrades anywhere. many pre-DNSSEC servers will
cache any additional data that matches the QNAME. we could all literally
start sending AAAA with A, and A with AAAA, and it would not only not
break anything, it would start making eyeballs happier that same day.
>  
>
>
>     what have you got for "multiple-responses" in terms of motivation
>     for the complexity of a protocol change?
>
>
>
> I don't see this as a large protocol change - the 'only over tcp' was
> only put in to mitigate the "this will make packets huge" concern that
> I figured some people would have.. Other than that there is signaling
> support - which I put in because I figured it didn't hurt. The actual
> including multiple responses bit doesn't really seem to violate
> protocol - as you said re: A and AAA as optional additional-data in MX
> and SRV and NS, and AAAA for A, A for AAAA.

as others have pointed out, TCP is the wrong constraint to get what you
mean. like, "proof that the transaction's initiator address has not been
forged, or else, defense against DDoS amplification such as response
rate limiting, are a prerequisite of this new responder behaviour."
>
> The motivation for this is just efficiency / reducing latency -
> looking up foo.example, getting a CNAME to bar.example and then
> looking that up in another transaction seems inefficient and inelegant.

you've left the box i thought we were standing in. CNAME chains are
already returned by authorities, if in your above example, the alias and
the canonical name are served by the same authority server. take a look
at this:

> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54849
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;ss.vix.su.                     IN      AAAA
>
> ;; ANSWER SECTION:
> ss.vix.su.              3600    IN      CNAME   family.redbarn.org.
> family.redbarn.org.     1200    IN      AAAA    2001:559:8000:cd::5

whereas, in a non-authoritative response, even an out-of-zone CNAME
chain is followed and returned in its entirety:

> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10123
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 8, ADDITIONAL: 9
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;www.microsoft.com.             IN      AAAA
>
> ;; ANSWER SECTION:
> www.microsoft.com.      2724    IN      CNAME   toggle.www.ms.akadns.net.
> toggle.www.ms.akadns.net. 300   IN      CNAME  
> www.microsoft.com.edgekey.net.
> www.microsoft.com.edgekey.net. 300 IN   CNAME  
> e10088.dscb.akamaiedge.net.
> e10088.dscb.akamaiedge.net. 20  IN      AAAA    2600:1406:1a:485::2768
> e10088.dscb.akamaiedge.net. 20  IN      AAAA    2600:1406:1a:484::2768

this is true even if the end of the CNAME chain is NXDOMAIN.

> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15097
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;somewhere.vix.su.              IN      AAAA
>
> ;; ANSWER SECTION:
> somewhere.vix.su.       3600    IN      CNAME   nowhere.vix.su.

and if DNSSEC signatures are available, they are all returned. (example
not provided due to excessive size.)

i worry that if you didn't know that CNAME worked like this, how well
was the rest of your proposal researched? that's especially concerning
since your motivation wasn't a use case but rather "it seemed
interesting" and because you're calling it a "small" protocol change
without considering the size of the installed base or the long length of
the tail of deployment.

> Similarly, looking up www.example, getting the webpage and then doing
> a bunch of separate lookups for all the resources in it, like
>  images.example, js.example, css.example simply seems wasteful, and
> offends me :-) [0]

what you may want in this case is to help with the DNS-over-HTTP work,
since HTTP and HTTPS have connection persistency, and pipelining. (i
realize that john dickenson is also working on persistency and
pipelining for TCP/53 but i consider that a much larger change due to
the size of the existing TCP/53 installed base.)
>
> This optimization might not be worth it - but I figured drafts are
> cheap, and worth discussing...

drafts, and discussions, are not cheap. if you amortize the cost of the
time of all the people reading each message on this thread, plus their
air fare for the IETF meetings they go to, the activation energy of
every new draft is "fantastically cosmic" or higher.

> If the consensus is that this is not worth doing, I'm fine to abandon
> the work.

this is dnsop not dnsext. few ideas, no matter how questionable, will
fail to get consensus, since "no" votes aren't counted. if a nominal
number of folks are interested in working on this with you, it'll be
"game on".
> Nah, that wasn't a grumpy response. "Your draft is bad *and you should
> feel bad*" would be....

i do not want you to feel bad. however, i do hope you will re-consider
your approach, in several ways. every problem you're stating in this
draft has either an existing, or a lower cost, or a higher benefit,
solution than what you're proposing.

-- 
Paul Vixie

---

From: Evan Hunt <[email-masked]>
Date: Wed, 14 Jan 2015 06:41:40 +0000

On Tue, Jan 13, 2015 at 10:08:00PM -0800, Paul Vixie wrote:
> the canonical name are served by the same authority server.

Didn't we decide a while back that this was a bad idea, that resolvers
needed to stop trusting CNAME chains sent by authorities, and that
authorities really ought to stop sending them?

The reasoning as I remember it: If I ask the server for vix.su a question,
and it helpfully provides an answer in redbarn.org, I have only its own
assurances that it *is* in fact authoritative for redbarn.org; the answer
can't be trusted until I've chased delegations to redbarn.org too.  Even if
I'm DNSSEC-validating your responses, you *could* be replaying an outdated
answer with a still-valid signature, so I'm safest if I resolve each name
in the CNAME chain separately.

(I vividly remember a thread about this three or four years ago, but I'm
having poor luck with the grepping.)

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: "Guangqing Deng" <[email-masked]>
Date: Wed, 14 Jan 2015 15:33:05 +0800

It is said in this draft that "The authoritative nameserver SHOULD include as many of the additional records as will fit in the response." It may be true that some of the Resource Records in the same DNS zone file are highly related. But authority servers do not know which resource records are in the cache of recursive servers and which not, because the expiration time (due to TTL mechanism) of the resource records from the same DNS zone file are different! So there may be many "additional records" (in the so-called "multiple-response") thrown away by the recursive servers, because there are already "answer records" due to real DNS request in the cache! It is said many times in the mailing list that this draft is for optimization, and maybe it is time to prove that the ratio of "additional records" needed by the recursive servers will be really very high and the ratio of "additional records" thrown away by the recursive servers will be very low, by real data trace or mathematical model.

Guangqing Deng
CNNIC 
 
From: Warren Kumari
Date: 2015-01-14 13:22
To: Paul Vixie
CC: dnsop; Paul Wouters; John Levine
Subject: Re: [DNSOP]答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

Warren Kumari
Tuesday, January 13, 2015 8:19 PM
... I'm surprised that no-one has yet commented on the 'Let's just co-opt the Z bit for this' - I'm guessing that folk are not sure if I'm kidding or not, and are scared to ask :-) W

i think you're not kidding, but that you'll ignore input you consider "grumpy", so i wasn't going to mention any specific defect. instead i'll ask: what's your use case? do you, or your employer, or indeed anybody anywhere, need this feature? for what?

*Need* the feature? Nope, it's just an optimization. 
It seemed to me that DNSSEC allows you to actually have some faith in the additional data, and so its worth revisiting if we can use it.  I have no idea what my employer thinks of this - I wrote it because it seemed interesting to me. In general they like things that make the user experience faster, and (if this works), it should do that, so... probably they'd like it.... but who knows....

i've long believed that just as A and AAAA are optional additional-data in MX and SRV and NS responses, so it should be that A should be optional additional-data for AAAA responses, and AAAA should be optional additional-data for A responses. 

those are use cases i understand, and where the protocol impact is negligible, as in, it could be an FYI.

what have you got for "multiple-responses" in terms of motivation for the complexity of a protocol change?

I don't see this as a large protocol change - the 'only over tcp' was only put in to mitigate the "this will make packets huge" concern that I figured some people would have.. Other than that there is signaling support - which I put in because I figured it didn't hurt. The actual including multiple responses bit doesn't really seem to violate protocol - as you said re: A and AAA as optional additional-data in MX and SRV and NS, and AAAA for A, A for AAAA. 

The motivation for this is just efficiency / reducing latency - looking up foo.example, getting a CNAME to bar.example and then looking that up in another transaction seems inefficient and inelegant.
Similarly, looking up www.example, getting the webpage and then doing a bunch of separate lookups for all the resources in it, like  images.example, js.example, css.example simply seems wasteful, and offends me :-) [0]

This optimization might not be worth it - but I figured drafts are cheap, and worth discussing...
If the consensus is that this is not worth doing, I'm fine to abandon the work.

(if this is what you meant when you said you were expecting grumpy responses, feel free to ignore me.)

Nah, that wasn't a grumpy response. "Your draft is bad *and you should feel bad*" would be....

W

[0]: These examples are somewhat self-inflicted pain - you could have skipped the CNAME, and you could also have put all the resources on www.foo.

-- 
Paul Vixie

-- 
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf

---

From: Paul Vixie <[email-masked]>
Date: Tue, 13 Jan 2015 23:45:18 -0800

> Evan Hunt <mailto:[email-masked]>
> Tuesday, January 13, 2015 10:41 PM
>

yes, we did, "unless dnssec signatures are also sent". that's in
warren's proposal also.
> Even if
> answer with a still-valid signature, ...

no, because you could receive that signature in other ways, and so its
validity-period is all that governs.

-- 
Paul Vixie

---

From: "John R Levine" <[email-masked]>
Date: 14 Jan 2015 09:28:33 -0500

> and it helpfully provides an answer in redbarn.org, ...

That's not what Warren's proposing.  Did you read the draft?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Tony Finch <[email-masked]>
Date: Wed, 14 Jan 2015 14:54:08 +0000

Paul Hoffman <[email-masked]> wrote:
>
> From an operational standpoint "an auth server can put more answers in
> than the querier might expect" is a heck of a lot easier to deploy than
> "teach the stubs to ask better questions".

True. And if authoritative servers include more answers, recursive servers
also need to be taught to pass the additional data to their clients.

An alternative and much easier way to get Warren's performance improvement
is for browsers to remember which domain names were needed by a website.
Then for later visits the browser can do the subordinate lookups in
advance, in the hope that the list of domains hasn't changed much.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire, Forties, Cromarty, Forth, Tyne, Dogger:
Southwesterly 6 to gale 8, occasionally severe gale 9 in Forties and Forth,
backing southerly or southeasterly gale 8 to storm 10. Rough or very rough,
becoming very rough or high. Wintry showers then rain. Moderate or good,
occasionally poor.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 14 Jan 2015 07:16:42 -0800

> also need to be taught to pass the additional data to their clients.

Although the draft doesn't say it explicitly, I think the optimization is only "fill the recursive's cache faster". This reduces latency on the current flow of requests from the stub, but does not reduce the flow itself.

> advance, in the hope that the list of domains hasn't changed much.

I'm pretty sure some browsers have been doing this for years. My interest in the draft is for non-Web requests that have multiple relevant answers, such as SRV. Even there, however, I suspect the increase in speed to the stub will be miniscule.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Wed, 14 Jan 2015 15:26:33 +0000

Paul Hoffman <[email-masked]> wrote:
>
> I'm pretty sure some browsers have been doing this for years.

It doesn't look to me like they try DNS lookups early, based on the web
developer timing graphs.

> My interest in the draft is for non-Web requests that have multiple
> relevant answers, such as SRV.

SRV already has additional section processing (though it is optional).

Tony.