Subject: Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses

From: 延志伟 <[email-masked]>
Date: Wed, 20 Jul 2016 11:03:27 +0800 (CST)

About the DDoS risk, it should not be worried so much because this scheme is controlled/triggered by the recursive server (with a flag as NN bit).
In other words, the recursive server can get the piggybacked multiple responses only when it wants and of cource it can disable this model anytime.

Another scenario to illustrate this proposal is under the DANE case:
A client wants to visit www.example.com.
But this domain name supports DANE can the TLSA record is configured under the domain name: _443._tcp.www.example.com.
The client has to query the two names seperately.
Yes, it is just one more TTL, but why not to do the optimization with a steerable method.

Zhiwei Yan

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 20 Jul 2016 07:07:01 +0200

Moin!

On 20 Jul 2016, at 5:03, 延志伟 wrote:

> About the DDoS risk, it should not be worried so much because this 
> scheme is controlled/triggered by the recursive server (with a flag as 
> NN bit).
> In other words, the recursive server can get the piggybacked multiple 
> responses only when it wants and of cource it can disable this model 
> anytime.
That's not who DDos work. If attacker would only do what the specs say 
we wouldn't have any DDos. But an attacker can just create an UDP packet 
with that bits and a spoofed address and fire it off (or get a botnet to 
fire it off).

> But this domain name supports DANE can the TLSA record is configured 
> under the domain name: _443._tcp.www.example.com.
Again if example.com is popular almost all the time this record will be 
in the cache already.

So long
-Ralf

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Jul 2016 15:19:49 +1000

In message <[email-masked]>, "Ralf Weber" writes:
> Moin!
>
> On 20 Jul 2016, at 5:03,  wrote:
>

Which is why DNS COOKIES with a valid server cookie / TCP / DNS-O-TLS
was suggests as being a necessary precondition.

> Again if example.com is popular almost all the time this record will be

But the cache can be the other side of the world.  The browser vendors
aren't willing to go to SRV because they may need to make a second query
to the recursive server to get the addresses of the SRV targets.

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

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

---

From: 延志伟 <[email-masked]>
Date: Wed, 20 Jul 2016 13:34:03 +0800 (CST)

Good morning, Ralf.

>with that bits and a spoofed address and fire it off (or get a botnet to 

I understand your points, but these risks always be there because DNS response is larger than the request, like DNSSEC. 
How to avoid DNS DDoS is anther problem.
>Again if example.com is popular almost all the time this record will be 

Anyway, the cache should get the data fist and then it can cache them.
:-)

Zhiwei Yan

---

From: Jim Reid <[email-masked]>
Date: Wed, 20 Jul 2016 08:18:44 +0100

> On 20 Jul 2016, at 06:19, Mark Andrews <[email-masked]> wrote:
> 

The draft does not say that Mark.

Under Security Considerations, it says: "One could mitigate this by only serving responses to EXTRA requests over TCP or when using Cookies [RFC5395], although there is no easy way to signal this to a client other than through the use of the truncate bit."

It's a bit of a stretch to call that a suggestion and a far bigger one to claim cookies and/or TCP as a necessary precondition. There's no language like "clients and servers SHOULD (MUST?) use DNS cookies/TCP/DNSoverTLS for EXTRA queries and responses". Well, not yet anyway. Maybe in the next release.

And if DNS over TLS is the answer, the overheads of that handshake would more than cancel out the benefit of optimising away an extra query/response RTT.

FWIW, I think it's a Bad Idea and the start of a very slippery slope to make queries or responses to QTYPEs dependent on the underlying transport protocol (modulo AXFR of course). Are layering violations acceptable nowadays?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Jul 2016 17:40:08 +1000

In message <[email-masked]>, Jim Reid writes:
> >=20
> >> That's not who DDos work. If attacker would only do what the specs =
> say
> >> we wouldn't have any DDos. But an attacker can just create an UDP =
> packet
> >> with that bits and a spoofed address and fire it off (or get a botnet =
> to
> >> fire it off).
> >=20

It was stated up thread.  Additionally aren't these discussion
supposed to get consensus of the changes needed rather than the
"I-D is cast in stone" especially right at the start of the processes.

If this was last call this sort of nit picking would be justified but
at this stage of the development process it seems to be unnecessary.

> Under Security Considerations, it says: "One could mitigate this by only
> serving responses to EXTRA requests over TCP or when using Cookies
> [RFC5395], although there is no easy way to signal this to a client other
> than through the use of the truncate bit."
>
> It's a bit of a stretch to call that a suggestion and a far bigger one to
> claim cookies and/or TCP as a necessary precondition. There's no language
> like "clients and servers SHOULD (MUST?) use DNS cookies/TCP/DNSoverTLS
> for EXTRA queries and responses". Well, not yet anyway. Maybe in the next
> release.
>
> And if DNS over TLS is the answer, the overheads of that handshake would
> more than cancel out the benefit of optimising away an extra
> query/response RTT.
>
> FWIW, I think it's a Bad Idea and the start of a very slippery slope to
> make queries or responses to QTYPEs dependent on the underlying transport
> protocol (modulo AXFR of course). Are layering violations acceptable
> nowadays?

Nameservers make decisions TODAY about what they will put in a message
based on COOKIES / TCP / UDP and a host of other considerations.

Personally I don't think EXTRA is needed.  A nameserver can predict
a lot of the future queries based on the contents of the reply to
the initial query.

MX -> A / AAAA / TLSA of _25._tcp.<MX TARGET> 
SRV -> A / AAAA / if _tcp then TLSA of _<port>._tcp.<SRV TARGET>

Yes, the responses get bigger but bigger isn't the real problem.

---

From: Jim Reid <[email-masked]>
Date: Wed, 20 Jul 2016 09:11:14 +0100

> On 20 Jul 2016, at 08:40, Mark Andrews <[email-masked]> wrote:
> 

True. But that's orthogonal to the point I was making.

The draft *might* be heading in the direction of saying something like EXTRA queries are only valid over TCP. We should think very carefully before going down that path if that path eventually emerges.

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 20 Jul 2016 14:20:45 +0200

Moin!

On 20 Jul 2016, at 7:34, 延志伟 wrote:
> I understand your points, but these risks always be there because DNS 
> response is larger than the request, like DNSSEC.
Yes, which is why we have several proposals on how to mitigate the 
problem by e.g not giving  back ALL qtypes to an ANY question, or rate 
limit any or answers in general. There also are tools out there that can 
limit based on the answer size, all of that to mitigate or make the 
handling of the amplification better.

> How to avoid DNS DDoS is anther problem.
If you introduce something that makes the answer bigger without 
acknowledging that there could be a problem with it or it is another 
problem you have not been following what is going on in the Internet 
lately.

Others have acknowledged that and described a way forward to mitigate it 
(TCP,TLS,Cookies) which introduce a whole other set of problems (some 
introduce additional round trips) which further more diminishes the gain 
to effort ratio IMHO.

> Anyway, the cache should get the data fist and then it can cache them.
That is true, but an answer out of the cache is served a lot of times 
before it has to be cached again, so you are gaining something for that 
tiny fraction of users where the cache is cold or has become cold (not a 
problem if you use software that prefetches), but putting all others to 
risk. Not a good idea IMHO.

So long
-Ralf

---

From: "Peter van Dijk" <[email-masked]>
Date: Wed, 20 Jul 2016 14:39:04 +0200

Jim,

On 20 Jul 2016, at 9:18, Jim Reid wrote:

> It's a bit of a stretch to call that a suggestion and a far bigger one 
> to claim cookies and/or TCP as a necessary precondition. There's no 
> language like "clients and servers SHOULD (MUST?) use DNS 
> cookies/TCP/DNSoverTLS for EXTRA queries and responses". Well, not yet 
> anyway. Maybe in the next release.
>
> And if DNS over TLS is the answer, the overheads of that handshake 
> would more than cancel out the benefit of optimising away an extra 
> query/response RTT.
>
> FWIW, I think it's a Bad Idea and the start of a very slippery slope 
> to make queries or responses to QTYPEs dependent on the underlying 
> transport protocol (modulo AXFR of course). Are layering violations 
> acceptable nowadays?

+lots, I see mentions of TCP and/or cookies popping up in more and more 
drafts and it has to stop. Packet size concerns exist for every usage of 
DNS, and new features should not pretend they are so special that they 
deserve special treatment in this regard. Such decisions are operational 
and they don’t belong in every draft that makes packets slightly 
bigger.

Of course, when it’s obvious we need TCP-like semantics, like in the 
session draft for dnssd push, that’s fine.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 20 Jul 2016 14:48:07 +0200

Moin!

On 20 Jul 2016, at 14:36, 延志伟 wrote:
> But anyway, let's go back to the scenario considered by our draft to 
> illustrate its necessity.
> I show an example as following (although I think we have described it 
> several times. :-)):
> In order to visit the www.baidu.com, the user has to query 
> www.baidu.com and many other related domain names
> (for many related resources such as images, java script, html, flash, 
> video, sound), then a series of queries happen as the attached figure 
> shows.
So what. If your recursive resolver is used by many people these records 
will be in the cache. There will be no gain. Now of course if your 
resolver only serves you that might be the case, but that is not the way 
DNS was designed or is operated today. Oh and your example have out of 
zone queries (also very common like facebook.com asking for fbcdn.com) 
that can not be solved by this anyway. There is no better tool than a 
prefetching hot resolver for lots of users to solve this problem.

So long
-Ralf

---

From: 延志伟 <[email-masked]>
Date: Wed, 20 Jul 2016 20:36:34 +0800 (CST)

Hi, Ralf,
We understand your worries and these negative effects can be fixed or descended in the next version.
But anyway, let's go back to the scenario considered by our draft to illustrate its necessity.
I show an example as following (although I think we have described it several times. :-)):
In order to visit the www.baidu.com, the user has to query www.baidu.com and many other related domain names 
(for many related resources such as images, java script, html, flash, video, sound), then a series of queries happen as the attached figure shows.

Thank you.
Zhiwei Yan

---

From: 延志伟 <[email-masked]>
Date: Wed, 20 Jul 2016 21:40:41 +0800 (CST)

Hi, Ralf, I understand prefetch by the recursive server and it is the common case.
[https://tools.ietf.org/html/draft-liu-dnsop-dns-cache-00]
But if recursive server asks: give me the a RR and all the related RRs under your domain. And the authoritative server sends back  the requested domain name RR and the related RRs under its domain. It can also improve the efficiency.
Zhiwei Yan

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Jul 2016 15:37:30 +0200

On Wed, Jul 20, 2016 at 02:39:04PM +0200,
 Peter van Dijk <[email-masked]> wrote 
 a message of 26 lines which said:

> > start of a very slippery slope to make queries or responses to
> > QTYPEs dependent on the underlying transport protocol (modulo AXFR
> > of course). Are layering violations acceptable nowadays?
> 
> +lots, I see mentions of TCP and/or cookies popping up in more and
> more drafts and it has to stop.

It is already in at least one RFC, 7901 (section 5.1).

---

From: Paul Wouters <[email-masked]>
Date: Thu, 21 Jul 2016 11:10:10 -0400 (EDT)

On Thu, 21 Jul 2016, Stephane Bortzmeyer wrote:

> Subject: [DNSOP] Asking for TCP and/or cookies: a trend? (Was: my lone hum
>     against draft-wkumari-dnsop-multiple-responses
> 

What is the problem with specifying it in the protocol instead of
leaving it to implementors?

Would people feel better if we did a new document on implementor
guidelines for DNS UDP, TCP and DNS-COOKIES and then refer to that?
Surely we could make that happen, and then it technically no longer
depends on the QTYPE, but on the "DNS answer is much larger than the
DNS question" section.

And I have been wondering if we should allow for a DNS padding in the
query packet to ensure answer packets (over UDP) are going to be
smaller then the query packet. And therefore prevents DDOS
amplification.

Paul

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 21 Jul 2016 21:08:45 +0530

Hi Paul

> smaller then the query packet. And therefore prevents DDOS

This has been mentioned before. Some thoughts:

For DNS, this can affect some cases such as query packets not making it
to the server due to size, lack of ability of the client to guess what
the answer's message size may be, and also EDNS UDP payload size
behavior.

In DNS over UDP and its poor-man's-pMTU-discovery, it's the client that
drives the discovery of what works - the server has no idea of whether a
query+answer roundtrip has succeeded in a reply successfully delivered
to the client, whereas the client does. The client can use this to tweak
the UDP payload size, but if the query itself may get dropped, it can't
tell if it was the query or the reply that disappeared - there is some
faith that an unpadded question-only DNS message will go through
somewhat reliably.

Once a client cookie has been established (associated with a source IP
address), there's no need to use padding, so perhaps this could be a
step in the initial handshake when the cookie is established - there
could be message size limits to these cookie-establishment query and
reply.

DJB's curveCP comes to mind about how it prevents amplification for the
initial handshake.

		Mukund

---

From: Paul Wouters <[email-masked]>
Date: Fri, 22 Jul 2016 06:45:16 -0400 (EDT)

> the answer's message size may be, and also EDNS UDP payload size

We only need to make it less attractive, we don't have to guarantee the
question is larger. Just close the gap between question and answer.
So doing a 1200 byte dns query packet could be safe?

> could be message size limits to these cookie-establishment query and

That's very true, but it requires we have a lot more clients supporting
COOKIEs before we can punish those small questions that don't. Which I
guess applies to the padding question too, so yeah I guess my idea is
not enough too late and we should just deploy cookies.

> DJB's curveCP comes to mind about how it prevents amplification for the

some googling only finds marketing material, not a specification I can
read :P

Paul

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 22 Jul 2016 13:21:09 +0200

On Thu, Jul 21, 2016 at 11:10:10AM -0400,
 Paul Wouters <[email-masked]> wrote 
 a message of 33 lines which said:

> And I have been wondering if we should allow for a DNS padding in
> the query packet to ensure answer packets (over UDP) are going to be

Funny, it has been proposed on this blog (French only)
<https://seenthis.net/messages/488019#message490779> two months ago
but I don't remember a discussion about this possibility on dnsop.

---

From: Mukund Sivaraman <[email-masked]>
Date: Fri, 22 Jul 2016 18:22:40 +0530

Hi Paul

> some googling only finds marketing material, not a specification I can

Here it is:
http://curvecp.org/packets.html

(specifically, the section under "Client Hello packet details")

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Fri, 22 Jul 2016 18:51:43 +0530

> but I don't remember a discussion about this possibility on dnsop.

I vaguely remembered mentioning it myself on dnsop@ before but it look a
lot of searching to find that:

https://www.ietf.org/mail-archive/web/dnsop/current/msg12999.html

(see under item 5).

		Mukund

---

From: Bob Harold <[email-masked]>
Date: Mon, 25 Jul 2016 14:56:07 -0400

On Wed, Jul 20, 2016 at 9:40 AM, 延志伟 <[email-masked]> wrote:

> But if recursive server asks: give me the a RR and all the related RRs
> under your domain. And the authoritative server sends back  the requested
> domain name RR and the related RRs under its domain. It can also improve
> the efficiency.
> Zhiwei Yan
>
> Some thoughts:
With CDN's answering based on location, are they using very short TTL's,
and thus the cache goes 'cold' quite frequently?
And even if users of large pre-fetching resolvers are not helped, what if
it helps users of smaller non-pre-fetching resolvers?

-- 
Bob Harold

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Jul 2016 21:28:48 +0200

This is why collecting data is so great...  :)

On Jul 25, 2016 8:56 PM, "Bob Harold" <[email-masked]> wrote:

>> under your domain. And the authoritative server sends back  the
>> requested domain name RR and the related RRs under its domain. It can
>> also improve the efficiency.
>> Zhiwei Yan
>>