Subject: [DNSOP] Computerworld apparently has changed DNS protocol

From: Alfred Hönes <[email-masked]>
Date: Wed, 4 Nov 2009 19:58:41 +0100 (MEZ)

Interesting News!

There must be a hidden trick to introduce DNS Jumbograms we just
forgot to mention ....

In a press article [1] entitled
    "Root zone changes may shake up Net in Africa",
Computerworld wrote:

| From January 2010, ICANN will implement DNSSEC -- using a technique
| also known as root signing -- on the root zone, which will affect
| the performance of the Internet.  Currently, queries from domain
| servers to the root are 512 kilobytes or less, but DNSSEC will make
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| them larger because it introduces new signatures and keys as part
  ^^^^^^^^^^^
| of the security features.

:-}

[1]
  http://www.computerworld.com/s/article/9140123/Root_zone_changes_may_shake_up_Net_in_Africa

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 4 Nov 2009 11:09:53 -0800

Question:  Have people been able to estimate how large the signed root  
zone response will be?

I'm assuming its below the magic 1500B level for standard queries.  Is  
this correct?

Oh, and one thing to watch out for:  Some IP stacks I've noticed will  
set DF on UDP datagrams, if the datagram is too small to require  
fragmentation onto the local network!

Add this to the list of things DNS operators need to watch out for  
when turning on DNSSEC.

---

From: [email-masked]
Date: Wed, 4 Nov 2009 19:26:34 +0000

On Wed, Nov 04, 2009 at 11:09:53AM -0800, Nicholas Weaver wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

	David Conrad, ICANN maven and one-time IANA manager, posted some numbers
	from their DNSSEC testbed a month or so back.  Responses were just under
	1800 bytes. 

	The current deployment plan is to stage things to push out large responses
	early - prior to having any actual DNSSEC usable data ... ostensibly to
	flush out DNSmtu problems.

--bill

---

From: [email-masked]
Date: Wed, 4 Nov 2009 19:27:51 +0000

cool eh?  although I suspect she ment responses.

--bill

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 4 Nov 2009 11:43:11 -0800

On Nov 4, 2009, at 11:41 AM, Matthew Dempsky wrote:

> On Wed, Nov 4, 2009 at 11:26 AM,  <[email-masked]>  
> wrote:
> Is this plan to push out large responses indiscriminately, or only in
> response to queries with DO=1?

Also, has someone done a study what the major recursive resolvers do  
on response failures from a root?  Do they go to another first or do  
they try a smaller EDNS MTU?

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 4 Nov 2009 20:56:07 +0100 (MEZ)

>       cool eh?  although I suspect she ment responses.

Yet responses usually did not go *to* the root servers so far.
I'm getting confused.    :-)  :-)

Did anybody ever have a prejudice against journalists?
-- reconsider, please!  :-)

  Alfred.

P.S.: Disclosing that the writer was female seemed politically
      incorrect to me, so I purposely avoided this detail.

> On Wed, Nov 04, 2009 at 07:58:41PM +0100, Alfred Hönes wrote:
>> Interesting News!
>>

---

From: David Conrad <[email-masked]>
Date: Wed, 4 Nov 2009 12:02:30 -0800

[namedroppers dropped as this felt more operational to me]

On Nov 4, 2009, at 11:09 AM, Nicholas Weaver wrote:
> Question:  Have people been able to estimate how large the signed root zone response will be?

Response to what?  Using the current IANA 'normal root servers' testbed:

% dig +bufsize=4096 +dnssec @root.iana.org . ns | grep rcvd
;; MSG SIZE  rcvd: 801
% dig +bufsize=4096 +dnssec @root.iana.org . soa | grep rcvd
;; MSG SIZE  rcvd: 1016
% dig +bufsize=4096 +dnssec @root.iana.org . rrsig | grep rcvd
;; MSG SIZE  rcvd: 2005
% dig +bufsize=4096 +dnssec @root.iana.org x a | grep rcvd
;; MSG SIZE  rcvd: 639

Regards,
-drc

---

From: [email-masked]
Date: Wed, 4 Nov 2009 20:02:54 +0000

Well - her name was attached to the article, so I didn't think
it was inappropriate to mention gender.  And no, shes not the
first journalist to mangle words or misunderstand, or misrepresent.

--bill

---

From: David Conrad <[email-masked]>
Date: Wed, 4 Nov 2009 12:04:41 -0800

On Nov 4, 2009, at 11:41 AM, Matthew Dempsky wrote:
> On Wed, Nov 4, 2009 at 11:26 AM,  <[email-masked]> wrote:

We're not planning on breaking the DNS protocol.  DNSSEC responses will only be provided if DO=1 (currently about 70% of the queries hitting the root have DO=1).

Regards,
-drc

---

From: Florian Weimer <[email-masked]>
Date: Wed, 04 Nov 2009 21:24:40 +0100

* Matthew Dempsky:

> Is this plan to push out large responses indiscriminately, or only
> in response to queries with DO=1?

Eh, the protocol requires that those are sent only with DO=1.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 04 Nov 2009 21:30:10 +0100

> There must be a hidden trick to introduce DNS Jumbograms we just

The claims about firewall issues seems dubious to me.  It's certainly
not the 512 byte limit which is a problem here---I think we've got
pretty good empiric evidence that it's not a problem anymore.  Several
root responses are already larger than 512 bytes, and you can't send
mail to AOL or Yahoo if you're behind a firewall that swallows
responses larger than 512 bytes.  People tend to fix such things,
especially if the Internet is a new thing to them and they want to
communicate with each other, instead of merely being right and
protocol compliant.

---

From: David Blacka <[email-masked]>
Date: Wed, 4 Nov 2009 15:30:15 -0500

> % dig +bufsize=4096 +dnssec @root.iana.org x a | grep rcvd

I actually researched this, and need to spend some time cleaning up  
the report before posting it to this list.  But the bottom line is  
that yes, all responses save a few at the apex of root are below 1500b  
(actually, below 1100b).  The responses that are larger are ". rrsig"  
and ". any" (and ". dnskey" if minimal dnskey responses aren't used).   
". any" is the only one that would actually set TC if, say, the  
advertised buffer size were set to 1280.

--
David Blacka                          <[email-masked]>
Sr. Engineer          VeriSign Platform Product Development

---

From: Florian Weimer <[email-masked]>
Date: Wed, 04 Nov 2009 21:39:42 +0100

> advertised buffer size were set to 1280.

What about a.root-servers.net/IN/A etc.?  (Assuming that
root-servers.net will be signed eventually.)

---

From: Florian Weimer <[email-masked]>
Date: Wed, 04 Nov 2009 21:54:30 +0100

> they try a smaller EDNS MTU?

Note that switching seems beneficial because six roots MTUs clearly
support MTUs less than 1500, and seven roots probably don't (from my
POV, numbers about a week old).

It will be interesting to see if the root ops fix this before or after
they've enabled large responses for DO=1. 8-/

---

From: David Blacka <[email-masked]>
Date: Wed, 4 Nov 2009 17:04:46 -0500

> root-servers.net will be signed eventually.)

My research didn't cover that, but the responses will still be fairly  
small.  I'm also not making the assumption that root-servers.net will  
be signed eventually.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 05 Nov 2009 10:04:10 +1100

In message <[email-masked]>, Nicholas W
> they try a smaller EDNS MTU?

You do realise that the roots have been emitting DNS/UDP responses
bigger that 512 bytes for ages now.  The network did not grind to
a halt when that started.  It won't grind to a halt when the root
is signed.  There would be very few networks that NEVER make queries
to COM or NET zones and referrals to the COM and NET zones have exceed
512 bytes for a long time now.

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

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 4 Nov 2009 11:41:42 -0800

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 4 Nov 2009 13:45:16 -0800

> We're not planning on breaking the DNS protocol.  DNSSEC responses will only be provided if DO=1 (currently about 70% of the queries hitting the root have DO=1).

I'd appreciate if someone could clarify what the "large responses"
that will preexist "actual DNSSEC usable data" that Bill Manning is
referring to are.  It's unclear to me whether it's still technically
DNSSEC data and hence would require a client to send DO=1, or if it
will be something like large additional section TXT records or just
trailing bytes.

---

From: Jay Daley <[email-masked]>
Date: Thu, 5 Nov 2009 12:33:25 +1300

> will be something like large additional section TXT records or just

As far as I am aware, yes it is real DNSSEC data so yes it will  
require DO=1 but the keys will be dummy keys (i.e. secret) that cannot  
be configured as trust anchors and so the signatures will be ignored.   
At the end of that phase, real keys will be used and published.

See

http://sel.icann.org/meetings/seoul2009/presentation-dnssec-workshop-lamb-28oct09-en.pdf

for more details

Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services
desk: +64 4 931 6977
mobile: +64 21 678840

---

From: Mark Andrews <[email-masked]>
Date: Thu, 05 Nov 2009 11:03:45 +1100

In message <[email-masked]>, Florian Weimer writes:
> * Alfred H=F6nes:

And the protocol says that answers bigger than 512 bytes are legal
if EDNS is in use.

Mark

---

From: David Conrad <[email-masked]>
Date: Wed, 4 Nov 2009 17:08:24 -0800

Matthew,

On Nov 4, 2009, at 1:45 PM, Matthew Dempsky wrote:
> referring to are.

They are signed responses, but signed with a 'deliberately unvalidatable root key'.

> It's unclear to me whether it's still technically
> DNSSEC data and hence would require a client to send DO=1,

Yes, it is DNSSEC data and will only be returned if DO=1.  Clients that do not set DO=1 will not receive the DNSSEC responses.

> or if it

No.

Regards,
-drc

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 4 Nov 2009 15:42:43 -0800

On Wed, Nov 4, 2009 at 3:33 PM, Jay Daley <[email-masked]> wrote:
> As far as I am aware, yes it is real DNSSEC data so yes it will require DO=1
> but the keys will be dummy keys (i.e. secret) that cannot be configured as
> trust anchors and so the signatures will be ignored.  At the end of that
> phase, real keys will be used and published.
>
> See
>

I see now.  Thanks for clarifying.

---

From: George Michaelson <[email-masked]>
Date: Wed, 11 Nov 2009 15:43:26 +0900

On 11/11/2009, at 3:29 PM, Duane Wessels wrote:

> 
> 
> On Wed, 4 Nov 2009, Nicholas Weaver wrote:
> 
>> Also, has someone done a study what the major recursive resolvers do on response failures from a root?  Do they go to another first or do they try a smaller EDNS MTU?
> 
> I gave a presentation on this at the DNS-OARC meeting last week:
> 
> https://www.dns-oarc.net/files/workshop-200911/Duane_Wessels.pdf
> 
> I was only able to test BIND (9.4.3) and Unbound (1.3.3) before the
> workshop.
> 
> I've since learned that since my graphs only show 7 seconds after
> the initial query, it misses Unbound's fallback to TCP, which
> takes longer than that.

Great presentation.

I encourage everyone to read this document. Duane shows an incredibly high packet amplification in some circumstances, of 30 or more subsequent (sys/glue) queries each having to hunt to the optimal MTU.

And the total traffic count rises as well of course.

yes, its a corner case. Alas, its a corner case we can predict will exist for disadvantaged people behind broken middleware and old software.

-George

---

From: Florian Weimer <[email-masked]>
Date: Wed, 11 Nov 2009 09:34:52 +0000

> https://www.dns-oarc.net/files/workshop-200911/Duane_Wessels.pdf

Have you installed any trust anchors in the resolver?  (I don't think
so, the packet numbers are a bit on the lower side for that.)

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 11 Nov 2009 06:58:25 -0800

>> the initial query, it misses Unbound's fallback to TCP, which

A strong second, and many thanks for posting this.

The only other thing which needs to be added is understanding what happens at the 1500B MTU point rather than the 512B point (increase key size and/or record count to hit), since our early testing with Netalyzr showed that its the 1500B boundary that is the big problem for most recursive resolvers, due to firewall rules and similar that can't handle UDP fragments.

---

From: George Michaelson <[email-masked]>
Date: Wed, 11 Nov 2009 15:42:16 +0900

Great presentation.

-George

---

From: Duane Wessels <[email-masked]>
Date: Wed, 11 Nov 2009 06:29:19 +0000 (UTC)

On Wed, 4 Nov 2009, Nicholas Weaver wrote:

> Also, has someone done a study what the major recursive resolvers do on 
> response failures from a root?  Do they go to another first or do they try a 
> smaller EDNS MTU?

Duane W.

---

From: Duane Wessels <[email-masked]>
Date: Wed, 11 Nov 2009 17:37:11 +0000 (UTC)

> so, the packet numbers are a bit on the lower side for that.)

I didn't.  I was mostly interested in the "DURZ" case where the root
zone becomes signed but people aren't configuring trust anchors.

And I'm only looking at the traffic between resolver and authorities.

What do you mean by "packet numbers?"  Number of packets or size of packets?

Duane W.