Subject: RE: [dnsext] we need an IAB statement on Secure DNS

From: <[email-masked]>
Date: Thu, 23 Apr 2009 16:05:10 -0700

I'm not entirely sure what qualifies one as a "large DNS operator", but
based on my current understanding of the proposal, I do not anticipate
operational changes to support EDNS-PING within my organization. 
However, I must have missed the large operator's concern that you
mentioned.  If you could point me in the right direction on that, I
would appreciate it.

 ----
 Joe Miller
 GoDaddy.com
 [email-masked]
 480.505.8800 x4430

   -------- Original Message --------
 Subject: Re: [dnsext] we need an IAB statement on Secure DNS
 From: Andrew Sullivan <[email-masked]>
 Date: Thu, April 23, 2009 1:40 pm
 To: [email-masked]

 I have doubts that large DNS operators, when confronted with
 as-yet-unknown changes to their traffic patterns due to these
 alternative techniques, will really regard this as a code-only change.
 In places I have worked with operations on any scale, extensions to
 any protocol automatically entailed changes to operations. At the
 very least, I'd bet a number of monitors in some sites would have to
 be adjusted. I am therefore quite sceptical of claims that the
 proposed techniques are a code-only change. We hear one large
 operator expressing doubts also; it would be valuable to me to have
 informed input from other operators as to whether they regard the
 proposed techniques (to the extent they are completely defined) as a
 code-only change, or whether they think the techniques might impose
 operations changes too.
 
 Again, just my personal opinion.
 
 A
 
 -- 
 Andrew Sullivan
 [email-masked]
 Shinkuro, Inc.
 
 --
 to unsubscribe send a message to [email-masked] with
 the word 'unsubscribe' in a single line as the message text body.
 archive: <http://ops.ietf.org/lists/namedroppers/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Apr 2009 13:48:52 -0400

> mentioned.  If you could point me in the right direction on that, I

The one that I was thinking of was Paul Vixie.  I think his experience
with the root servers qualifies him as a large operator, but the
reason I asked a question rather than saying "this is how it is" is
precisely because I don't want to draw conclusions on the basis of one
person's input.

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: [email-masked]
Date: Fri, 24 Apr 2009 18:22:53 +0000

> precisely because I don't want to draw conclusions on the basis of one

	Root Operators are in a novel position wrt being a "large operator".
	The zone is not large by nearly any metric.  We don't do recursion or
	caching so that side of DNS operations is outside the relem of consideration.

	The one thing we root ops do get, is all the random queries that are not
	otherwise resolvable in the namespace...  and there are quite a few of them.

	but I would not consider a root operator to be in the "large" camp at 
	all...  try:

	godaddy - enom - neustar - afilias - nic.br - twc - comcast - et.al.

	for large DNS operators.

--bill

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Apr 2009 16:51:18 -0400

> 	but I would not consider a root operator to be in the "large" camp at 

Ok, so there are three importantly different meanings of "large" here,
and you're quite right that we need to distinguish among them:

1.  Large traffic, mostly delegation, small zone (e.g. root operator).

2.  Large zones, mostly delegation, large traffic (e.g. Verisign,
        Afilias, &c.).

3.  Large numbers of zones, mixed or little delegation, large traffic.  
        (e.g. Go Daddy &c.)

I consider "big single zone with small traffic" not to be an
interesting "large" case, but I guess it might qualify too.  We've
heard from one example of (1) and (3), each, of these cases.  That's
not a great sample.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Otmar Lendl <[email-masked]>
Date: Sat, 25 Apr 2009 09:35:21 +0200

> and you're quite right that we need to distinguish among them:

You're completely missing the resolver side.

Big consumer ISPs like Comcast, Verizon, T-Online, BT, ... all run 
massive clusters of resolvers. You also need to consider what EDNS0-ping
means to them. 

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg

---

From: Paul Vixie <[email-masked]>
Date: Sat, 25 Apr 2009 18:46:21 +0000

> Date: Sat, 25 Apr 2009 09:35:21 +0200
> From: Otmar Lendl <[email-masked]>
> 
> ...

i'm all for considering other endpoint types than "large responder", but
the context for evaluation has to be the whole system, not one implementation
or one installation or one kind of installation.  DNS is already very large
and has a lot of moving parts.  something like PING would have a systemic
effect (just as "just fall back to TCP" or "just use TCP" would have).  our
remit is to consider that whole system.  if looking at installation types is
a helpful lense then let's look at it.  but we have to evaluate systemically.

---

From: "Antoin Verschuren" <[email-masked]>
Date: Mon, 27 Apr 2009 12:50:24 +0200

I consider myself in group 2, and I've expressed my concerns with traffic regarding EDNS0 Ping.

One more thing that comes to mind are other operational issues that Andrew pointed out.
Monitoring or analyzing traffic will change with ENDS0 Ping, and thus has operational impact.
Where I can now easily predict that resending queries is not normal resolver behavior that needs investigating, introducing re-querying by protocol default will make me need to change my detection algorithms.

As a very simple example, re-querying the same query from the same host with specific attributes now indicates botnet abuse with the clear intend not to use the result for the correct working of the Internet, but merely do the re-querying because it does not cost the botnet operator to do the extra queries. The only purpose is to do harm or to get a result the DNS is not intended for. But it does cost us.
Introducing re-querying with the intend to improve the correct working of the infrastructure is something I cannot discard or filter out so I must adjust my detection algorithms.  

I do not question the increase in traffic that is needed to get any security in place.
We can handle that.
But I do question if we need to get multiple different overlapping security measures in place that all need extra traffic, each one addressing a different attack vector. And each one declaring it only costs a few bits. Many few bits make many bits.

Let's make it an efficient as possible protocol.

Antoin Verschuren

Technical Policy Advisor
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T +31 26 3525500
F +31 26 3525505
M +31 6 23368970
E [email-masked]
W http://www.sidn.nl/

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of Andrew Sullivan
> Sent: Friday, April 24, 2009 10:51 PM

������r��zǧu���Ơz�'jg���iz�+z����)�'�~���+a����n�˛���m�jȧ�W��w���^��,j�{[�ܚ��b��m�����"z����l�v�y�覗��

---

From: [email-masked] (Niels Bakker)
Date: Mon, 27 Apr 2009 15:05:22 +0200

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

* [email-masked] (Antoin Verschuren) [Mon 27 Apr 2009, 13:18 CEST]:
>As a very simple example, re-querying the same query from the same host 
>with specific attributes now indicates botnet abuse with the clear 
>intend not to use the result for the correct working of the Internet, 
>but merely do the re-querying because it does not cost the botnet 
>operator to do the extra queries. The only purpose is to do harm or to 
>get a result the DNS is not intended for. But it does cost us.

You're divining quite a bit of information from two nearly identical 
packets.

>Introducing re-querying with the intend to improve the correct working 
>of the infrastructure is something I cannot discard or filter out so I 
>must adjust my detection algorithms.

Your filter is clearly operating way above and beyond the technical. 
Adjusting it to incremental improvements in the DNS protocol seems only 
fair in my eyes.  (I can only assume DNSSEC queries will require much 
more in-depth changes to your IDS tools.)

>I do not question the increase in traffic that is needed to get any 

That's good.  Much in the same vein, I assume your servers are already 
handling the extra traffic for e.g. AAAA queries fine.

>But I do question if we need to get multiple different overlapping 
>security measures in place that all need extra traffic, each one 
>addressing a different attack vector. And each one declaring it only 
>costs a few bits. Many few bits make many bits.

Are you advocating to let some attack vectors go unaddressed?

>Let's make it an efficient as possible protocol.

And what about the people who attach TTLs lower than what SIDN publishes 
in the .nl zone to their NS records returned with glue?  They cause 
more traffic on ccTLD servers than they otherwise would have gotten. 
Are you willing to take as vocal a stand against that practice?

	-- Niels.
--

---

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Apr 2009 14:11:25 +0000

> Let's make it an efficient as possible protocol.

while i agree with this, i am even more concerned about complexity than on
inefficiency.  more state, more flux, at global scale, for not just the
current size of the internet but for the size several decades from now.

---

From: "Antoin Verschuren" <[email-masked]>
Date: Mon, 27 Apr 2009 17:13:35 +0200

> more in-depth changes to your IDS tools.)

I'm more than willing to addapt to protocol changes.
I was only giving an example to the statement that EDNS0 Ping didn't impact operations.
I think it does. Every protocol adjustment does.
How my algorithm works in this example is out of scope for this discussion I think.

> handling the extra traffic for e.g. AAAA queries fine.

Yes, and willing to accept extra DNSSEC traffic as well as long as it follows the protocol and purpose of DNS.
But not willing to accept some 50.000 qps from a single individual using the DNS as a random noise generator because "it can". 
DNS is not invented for that. 
Filtering out those individuals to keep serving the rest of the community that relies on resolving is a growing challenge.

> Are you advocating to let some attack vectors go unaddressed?

I'm advocating as little extra complexity as possible to address all the attack vectors.
If DNSSEC addresses all the attack vectors, I think we should go for that.
If there are other even multiple solutions that address all the attack vectors, I'm happy to listen to them.
But addressing one attack vector now, one more next year, and ending up with more complexity and traffic than DNSSEC plus no end-to-end with no turning back is not what I wish for.

> Are you willing to take as vocal a stand against that practice?

I think that practice is both stupid and yes, we do take a vocal stand.
It's even in our local policy.
We have restrictions on TTL values of NS RRsets and are checking them regularly, and warning registrars by sending them a monthly report.
And as for the stupid: We had an incident about a year ago where the calculation of glue in our registry system messed up.
The situation was corrected but there was some missing glue during the publication of our zone file for some hours.
Most of the zones kept working fine, but some DNS providers that had too low TTL's on their NS sets (some as low as 5 seconds) vanished from the earth until the next zonefile publication 2 hours later. I admit we shouldn't have made the error in the first place, but it proved why we advocate proper TTL's. It makes the DNS more robust to operational errors that do happen. I think that the operators that were affected realized that afterwards as well.
And that is exactly why I don't want the protocol to become so complex that average operators don't understand it anymore.

But I fail to see what that has to do with this discussion. 
The protocol clearly states TTL's should be chosen carefully because it realizes it affects query load and robustness.

Antoin Verschuren

Technical Policy Advisor
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T +31 26 3525500
F +31 26 3525505
M +31 6 23368970

h�{.n�+���zwZ��,j��v�y�覗������-��"z��"�a{
+v�칻�&ފv��x%zX�y�-�鞲Ơzױ��ɪ܆+ކ�i��)�'�~���X����jg���iz�?

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 27 Apr 2009 09:01:40 -0700

On Apr 27, 2009, at 8:13 AM, Antoin Verschuren wrote:
> If there are other even multiple solutions that address all the  
> attack vectors, I'm happy to listen to them.
> But addressing one attack vector now, one more next year, and ending  
> up with more complexity and traffic than DNSSEC plus no end-to-end  
> with no turning back is not what I wish for.

Except were not talking about that.

An attacker can be either in-path (see the packets) or out-of-path  
(not see the packets).  Period.

The question is:

What level of protection should there be for transactions and caches  
for out-of-path attackers?
and
Should the presence but lack of deployment of DNSSEC preclude the  
development and deployment of solutions against out of path attackers?

With sufficient query entropy (48+bits in practice), out of path  
attackers are killed completely, so there is an end-state to out-of- 
path attackers.

Or with decent entropy (32-36 bits) combined with glue policy changes,  
out of path attacks on the cache become impractical because they take  
too much time, rather than too many packets.  You could still do out- 
of-path transaction attacks, but those are far less useful. [1]

These are end state conditions, and if we are willing to deploy the  
changes to reach these end states, nothing else should need to be done  
against out-of-path attackers.

While any defense against in-path attackers requires DNSSEC or  
something that is effectively equivalent in terms of deployment costs  
(maintaining cryptographic relationships across the delegation path  
for every name).

Thus this is not "one attack vector now, one more next year, one more  
after that..."  Its there are only two possible attack classes: in- 
path or out-of-path.

[1] This is pretty much the situation with Unbound with 0x20 turned  
on, since unbound has the paranoid glue-policy policy which eliminates  
"race until win", and with 0x20 this gets to about 36-40 bits of  
entropy per query in practice.