Subject: [dnsext] Firewall support for large DNS names (>255) and packets (>512)?

From: "Matthew Dempsky" <[email-masked]>
Date: Fri, 10 Oct 2008 15:26:42 -0700

Is anyone aware of any common firewalls that reject DNS packets (or
all UDP packets to/from port 53) longer than 512 bytes or DNS packets
that contain domain names longer than 255 bytes?  E.g., [1] and [2]
have suggested the former has caused problems for EDNS0, but I was
curious if anyone had specific/recent experiences with such firewalls
and knowledge about how prevalent they are today.  I am especially
interested in any cases where these firewalls may not be under control
of either the client or server's admin.

My motivation for this question is the current DNSCurve spec requires
clients and servers to support packets up to 4096 bytes and names over
255 bytes, but a client or server may be behind firewalls that prevent
these packets from reaching their destination.

Thanks.

[1] http://homepages.tesco.net/J.deBoynePollard/FGA/dns-edns0-and-firewalls.html
[2] http://en.wikipedia.org/wiki/EDNS#EDNS_in_practice

--
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: Nicholas Weaver <[email-masked]>
Date: Fri, 10 Oct 2008 15:58:32 -0700

> these packets from reaching their destination.

Just detect and do a fallback.

Note, however, that for UDP, you really want to set max size to 1450B  
or so:  We've seen cases where mpls errors will silently drop a  
default MTU packet (but not MTU-4B) out in the middle of the  
Internet.  Relying on the Internet transport layer to process 4000B  
packets is unwise.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 11 Oct 2008 10:22:24 +1100

In message <[email-masked]>, "Matth
> these packets from reaching their destination.

	Names over 255 bytes are a non-starter.
 
-- 
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: Fri, 10 Oct 2008 16:34:03 -0700

>        Names over 255 bytes are a non-starter.

Can you elaborate on this?

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 10 Oct 2008 20:08:41 -0400

> Can you elaborate on this?

RFC 1034, Section 3.1

"To simplify implementations, the total number of octets that represent 
a domain name (i.e., the sum of all label octets and label lengths) is 
limited to 255."

                                                                - Kevin

---

From: [email-masked]
Date: Sat, 11 Oct 2008 00:04:45 +0000

> Can you elaborate on this?

	well, if you care to look at the IETF DNS specs, say RFC 1034,
you will find the following text:

"To simplify implementations, the total number of octets that represent a
domain name (i.e., the sum of all label octets and label lengths) is
limited to 255."

	your DNS spec might have a different max length.

--bill

---

From: "Matthew Dempsky" <[email-masked]>
Date: Fri, 10 Oct 2008 17:18:06 -0700

> domain name (i.e., the sum of all label octets and label lengths) is

RFC 1035 says "Messages carried by UDP are restricted to 512 bytes
(not counting the IP or UDP headers)."  Did this make EDNS0's support
of UDP packets greater than 512 bytes a non-starter?

To clarify, the current DNSCurve spec only requires support for domain
names greater than 255 bytes long as a possible encapsulation method
for protected queries.  Clients and servers do not otherwise need to
support domain names greater than 255 bytes.  The only concern is
intermediaries dropping DNS packets containing domain names greater
than 255 bytes.

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 10 Oct 2008 20:47:23 -0400

> of UDP packets greater than 512 bytes a non-starter?
RFC 2671 (proposed standard) clearly updated RFC 1035 in this respect, 
even if that is not technically acknowledged in the RFC database.

         - Kevin

---

From: "Matthew Dempsky" <[email-masked]>
Date: Fri, 10 Oct 2008 18:19:56 -0700

On Fri, Oct 10, 2008 at 5:47 PM, Kevin Darcy <[email-masked]> wrote:
> RFC 2671 (proposed standard) clearly updated RFC 1035 in this respect, even
> if that is not technically acknowledged in the RFC database.

So you agree there's precedent for letting an RFC loosen a size
limitation?  You're okay then with an RFC that would allow a client to
send a query for a domain name longer than 255 bytes to a server that
has announced its ability to handle such names?

---

From: [email-masked]
Date: Sat, 11 Oct 2008 02:33:06 +0000

> of UDP packets greater than 512 bytes a non-starter?
	
	nope - EDNS changed that requirement.  EDNS was defined
	in an IETF RFC.

> intermediaries dropping DNS packets containing domain names greater

	DNSCurve website hints at a way to support >255 bytes
	and if the website is the spec, then you might be right.
	anything larger than 255 octets will be dropped by virtually
	every other DNS implementation.  

--bill

---

From: Paul Vixie <[email-masked]>
Date: Sat, 11 Oct 2008 02:53:54 +0000

> 	every other DNS implementation.  

s/other//

---

From: [email-masked]
Date: Sat, 11 Oct 2008 04:53:49 +0000

> > 	every other DNS implementation.  

	er... almost.  DNSCurve(*) talking to DNSCurve(*) could - conceptually -
	pass names larger than 255 octets...

	then there is the little nit of  bytes != octets in all cases.
	(which is why octets were used in 1034 instead of bytes)

	for any practical purpose, you are correct.  for theoretical
	accuracy, you are not.

* based on the wayback machine archive of the web pages from 10oct2008 for 
  DNSCurve and not the 27oct2008 or 13nov2008 pages - noting that the 25dec2008
  web page suggests an incompatable change w/ implementations done from previous
  versions of the web pages(#)

# presuming no web page defacement has occured.

	punting to another vector...  why does DNSCurve remind me of 
	a functional replacement for the SIG(0)/TSIG  tools?

--bill

---

From: "Matthew Dempsky" <[email-masked]>
Date: Fri, 10 Oct 2008 23:01:18 -0700

>        nope - EDNS changed that requirement.  EDNS was defined

You miss the point.  There was a brief, 12-year period between RFC
1034 and RFC 2671 where the most recent RFC limited that DNS packets
sent over UDP to 512 bytes or less.  *During this time period*, why
was the proposal to allow new clients and new servers to communicate
using larger packets not a "non-starter" as well?

---

From: Mark Andrews <[email-masked]>
Date: Sat, 11 Oct 2008 21:11:18 +1100

In message <[email-masked]>, "Matt
> of UDP packets greater than 512 bytes a non-starter?

	EDNS0's packet size is hop-by-hop.  Nameserver name size
	is end-to-end.

---

From: [email-masked]
Date: Sat, 11 Oct 2008 13:02:21 +0000

> using larger packets not a "non-starter" as well?

	you appear to be refereing to a proposal that emerged 
	sometime between RFC 1034 and RFC 2671 which would allow
	DNS packets over UDP to exceed 512 bytes.

	to make sure we are all on the same page, could you provide
	a reference to that proposal?

--bill

---

From: Paul Vixie <[email-masked]>
Date: Sat, 11 Oct 2008 14:08:47 +0000

> 	a reference to that proposal?

more to the point, edns0 as defined in rfc 2671 only allows one case
where a new kind of data can be expressed, that being extended label
types, and that is the part that hasn't worked out, and that's why.

i think a proposal to change the maximum label length would be viewed
as "very controversial" and that an option to signal one's readiness
to accept such labels would not be accepted by the standards body.

furthermore it's been nine years since rfc 2671 came out and we're
still fighting the deployment battle, and the hotels and isp's of the
world who rewrite dns packets in flight are growing not shrinking.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 11 Oct 2008 14:10:22 +0000

> using larger packets not a "non-starter" as well?

it was an option negotiation, defined by the standards body.

---

From: [email-masked]
Date: Sat, 11 Oct 2008 15:36:23 +0000

> world who rewrite dns packets in flight are growing not shrinking.

	Paul, 

	The question on the table here is "what proposal - between
	RFC 1034 and RFC 2671 - allowed DNS packets over UDP to exceed
	512 bytes?   Do you remember any such proposal in circulation
	in that time period?

--bill

---

From: "Matthew Dempsky" <[email-masked]>
Date: Sat, 11 Oct 2008 11:56:06 -0700

>        512 bytes?   Do you remember any such proposal in circulation

Are you serious?  Is there some sort of inside joke I'm missing out
on?  Are you suggesting the IETF accepted RFC 2671 as a standard
without it ever being proposed by someone?

---

From: "Matthew Dempsky" <[email-masked]>
Date: Sat, 11 Oct 2008 12:49:14 -0700

On Sat, Oct 11, 2008 at 7:08 AM, Paul Vixie <[email-masked]> wrote:
> as "very controversial"

Fortunately, DNSCurve needs no such proposal.  It only needs support
for names whose total size exceeds 255 bytes and only when protecting
DNS packets that already contain a name greater than about 100 bytes
in length in the questions section.

---

From: Mark Andrews <[email-masked]>
Date: Sun, 12 Oct 2008 08:40:50 +1100

> 	512 bytes?   Do you remember any such proposal in circulation

	There were servers that sent UDP responses that exceeded
	512 bytes as part of some modifications for HS support by
	MIT I believe.  We had to put code in to named to detect
	such responses and treat them as if TC had been set.

	As to a formal proposal, I'm not aware of any myself.

---

From: "Matthew Dempsky" <[email-masked]>
Date: Sat, 11 Oct 2008 14:49:33 -0700

>        As to a formal proposal, I'm not aware of any myself.

Really?  No one ever formally proposed EDNS0?  How did it become an
RFC?  Did it just magically appear on the IETF servers one night?

Is this some sort of hazing ritual for new subscribers to namedroppers?

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 11 Oct 2008 14:59:03 -0700

At Fri, 10 Oct 2008 18:19:56 -0700,
> has announced its ability to handle such names?

I'm finding this discussion a bit puzzling.

I think it's clear that loosening the size limitation---regardless
of the merits of this idea---would require a new RFC. Is the
suggestion that DNSCurve should be made an RFC? If so, it seems
to me that a clear prerequisite to that discussion would be the
existence of DNSCurve I-D. Barring that, why exactly are we having
a discussion about the practicality of a specific design decision
in DNSCurve?

-Ekr

---

From: [email-masked]
Date: Sat, 11 Oct 2008 22:38:53 +0000

> Is this some sort of hazing ritual for new subscribers to namedroppers?

	not really - its just making sure you understand.

	the EDNS activities were documented in an Internet
	Draft, discussed and debated in the DNSEXT working group
	as part of the IETF process.  

	if and when other interesting ideas emerge -and- they are
	expected to become part of or interoperable with the IETF
	DNS spec, this communuity expects to see the ideas documented
	in an Internet Draft as a stable repository for discussion and
	debate.  Just like the EDNS0 ideas that became RFC 2671.

	as to whether EDNS0 conflated lable length >255 octets
	-AND- DNS UDP packets >512 bytes should be answered by
	the author.  One could also quote chapter/verse from 
	the RFC.

	my feeble recollection was that EDNS0 was primarily to
	extend the number of flags since we were down to two bits.
	Once new flags existed, it became possible to signal divergent
	capabilities - and as Paul has already said, negotiation for
	label lengths larger than 255 octets has not been seen as a
	high value proposition.  on the other hand, negotiation for 
	UDP packet sizes larger than 512 bytes has proven useful.

--bill

---

From: "Matthew Dempsky" <[email-masked]>
Date: Sat, 11 Oct 2008 15:49:05 -0700

On Sat, Oct 11, 2008 at 3:38 PM,  <[email-masked]> wrote:
>        label lengths larger than 255 octets

I have consistently asked about *names* larger than 255 bytes.  It's
even in the subject line of your latest email still.

DNSCurve only uses labels up to 53 bytes in length.

---

From: Mark Andrews <[email-masked]>
Date: Sun, 12 Oct 2008 09:54:43 +1100

> 	UDP packet sizes larger than 512 bytes has proven useful.

	And bit-string labels were a disaster as they required all the
	parent servers as well any other servers involved in servicing
	the request to understand bit-string labels.

	Mark

---

From: Chris Thompson <[email-masked]>
Date: 12 Oct 2008 00:10:04 +0100

>using larger packets not a "non-starter" as well?

Of course it is not impossible, in *theory*, to imagine negotiated
protocol extensions that would allow names longer than (in internal
expanded format) 255 octets.

But the EDNS extensions to increase UDP packet size have been problematic
enough to deploy, in practice, with all sorts of operational issues and
work-arounds. And this was just a point-to-point issue, as has been pointed
out. You are talking about an end-to-end one.

To be clear: pretty much all existing implementations treat the occurrence
of a name that expands to >255 octets as a format error, invalidating the
whole query/response packet. That is your starting point.

-- 
Chris Thompson
Email: [email-masked]

---

From: [email-masked]
Date: Sat, 11 Oct 2008 23:09:05 +0000

> 	the request to understand bit-string labels.

	actually, bit-strings were one of the reasons we tested the
	255 limit...

	128 bits in a v6 address, separated by "." == 256 bits...
	no room left for the ip6.int anchor.  

	But no doubt Olafur remembers this better than I - I do remember
	hashing this out w/ him in some hallway conversation 

	there were implementations at the time which never thought
	anything approching 255 would ever exist. :)  and last I checked,
	there are still deployments of said code...

--bill

---

From: "Matthew Dempsky" <[email-masked]>
Date: Sat, 11 Oct 2008 16:12:31 -0700

On Sat, Oct 11, 2008 at 2:59 PM, Eric Rescorla <[email-masked]> wrote:
> Is the suggestion that DNSCurve should be made an RFC?  If so, it
> seems to me that a clear prerequisite to that discussion would be
> the existence of DNSCurve I-D.

Yes.  I've been working on a DNSCurve Internet-Draft since it was
brought up on Thursday, and I hope to have a publicly available draft
soon.

> Barring that, why exactly are we having a discussion about the
> practicality of a specific design decision in DNSCurve?

I initially brought it up because I wanted to know if anyone knew of
*operational* issues with these limitations.  I was well aware that
the RFCs limited names to 255 bytes.  Did Bill Manning, Kevin Darcy,
or anyone else think I just coincidentally picked this number to ask
about?

I hoped that some DNS implementors might be subscribed to this mailing
list and able to share specific knowledge of their implementations'
limitations.  E.g., I know OpenBSD's relayd software that supports
load-balancing DNS queries does not inspect DNS packets past the 20
byte header, so it can handle TXT format DNSCurve queries that use
names greater than 255 bytes.

Can anyone speak on how common it is for other firewalls to reject
packets with names greater than 255 bytes and whether its possible for
administrators to disable this behavior for these firewalls?  Can
anyone suggest a better mailing list to ask such a question?

---

From: [email-masked]
Date: Sat, 11 Oct 2008 23:10:41 +0000

> even in the subject line of your latest email still.

	indeed - thank you for the correction.

> DNSCurve only uses labels up to 53 bytes in length.

	why only 53 bytes?

--bill

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 11 Oct 2008 16:18:27 -0700

At Sat, 11 Oct 2008 16:12:31 -0700,
> brought up on Thursday, and I hope to have a publicly available draft

Good. I look forward to reading the draft.

-Ekr

---

From: "Matthew Dempsky" <[email-masked]>
Date: Sat, 11 Oct 2008 17:14:17 -0700

On Sat, Oct 11, 2008 at 4:10 PM, Chris Thompson <[email-masked]> wrote:
> And this was just a point-to-point issue, as has been pointed

I think I misunderstood these terms at first. "hop" means a DNS query
packet from one host to another and the DNS response packet in the
other direction; "point-to-point" means something spanning a single
"hop"; "end-to-end" means something spanning multiple "hops".  Is this
right?  (I was still thinking of these terms in the layer 2/3 sense.)

Assuming my understanding of this terminology is correct, then
DNSCurve is only intended for use in "point-to-point" contexts as
well.  It does not require "end-to-end" support for names >255 bytes.

---

From: "Matthew Dempsky" <[email-masked]>
Date: Sat, 11 Oct 2008 17:48:56 -0700

>> DNSCurve only uses labels up to 53 bytes in length.

Not sure, that's just what the current spec says.  The TXT format for
queries could use labels up to 63 bytes, but the difference would be
negligible for most packets.  It might save a byte or two of space.
People concerned about the space savings, though, would gain more by
switching to the streamlined format though.

However, please don't misunderstand my statement to mean users cannot
use DNSCurve to safely query names that contain labels longer than 53
bytes.

---

From: [email-masked]
Date: Sun, 12 Oct 2008 01:38:07 +0000

> switching to the streamlined format though.

	my copy of the DNS spec sez lables may not exeed 64 bytes.
	where in the spec does it say 53 bytes?

> use DNSCurve to safely query names that contain labels longer than 53

	i have no idea what DNSCurve will let people do.
	waiting to see the DNSCurve spec.

--bill

---

From: "Matthew Dempsky" <[email-masked]>
Date: Sat, 11 Oct 2008 19:11:33 -0700

>        where in the spec does it say 53 bytes?

Sorry, by "the current spec" I meant "the current [DNSCurve] spec".

>        waiting to see the DNSCurve spec.

No need to wait.  If you go to http://dnscurve.org/impl.html, you can
find the most relevant details already.

---

From: [email-masked]
Date: Sun, 12 Oct 2008 03:37:50 +0000

> Sorry, by "the current spec" I meant "the current [DNSCurve] spec".

	so DNSCurve is not compliant w/ the DNS spec.
	thats useful to know.

> find the most relevant details already.

	a web page of "the most relevent details" does not a spec make.  
	I'll wait, like ekr, for an ID on DNSCurve before continuing 
	this discussion on an IETF mailing list.  If there is a 
	non-IETF mailing list where DNSCurve is being discussed and
	the default rule is the web page snapshot o' the day is the
	working spec - I'd like to know where that is.

	from what little can be gleaned from the URL provided, this 
	looks like interesting technology.  No one has yet answered
	one of my questions about DNSCurve and I'd like to ask it 
	in a more relevent fora.

--bill

---

From: "Matthew Dempsky" <[email-masked]>
Date: Sat, 11 Oct 2008 21:49:58 -0700

>        so DNSCurve is not compliant w/ the DNS spec.

DNSCurve occasionally needs safe "point-to-point" transit for DNS
packets longer than 512 bytes and/or containing names longer than 255
bytes in the questions section (which is exactly the motivation for
the question starting this thread).  However, otherwise TXT format
packets are compliant with RFC 1034 and 1035.

In what way do you think DNSCurve is not compliant with the DNS spec?
Did you miss when I said:

    However, please don't misunderstand my statement to mean users
    cannot use DNSCurve to safely query names that contain labels
    longer than 53 bytes.

(I also have to apologize that I misstated; it does not use labels
longer than 54 bytes, not 53 bytes.  The above statement still applies
otherwise.)

>        one of my questions about DNSCurve and I'd like to ask it

I'm happy to answer any DNSCurve questions you still have, here or
over private email.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 11 Oct 2008 22:31:16 -0700

At Sat, 11 Oct 2008 21:49:58 -0700,
> I'm happy to answer any DNSCurve questions you still have, here or

Rather than playing 20 questions about DNSCurve, it would be far more
useful for those who want the WG to consider it to describe what
architectural properties they are trying to achieve. With that
in hand, we can have a discussion about whether those properties
are ones the WG is interested in pursuing. If the consensus of
the WG is that some different set of architectural properties
than those provided by DNSSEC are desirable, *then* we can
have a discussion about what protocol mechanisms best achieve
them.

-Ekr

---

From: bert hubert <[email-masked]>
Date: Sun, 12 Oct 2008 12:53:02 +0200

> or anyone else think I just coincidentally picked this number to ask

In practice, and this is deviating from DNSEXT territory, almost anything
that is a tiny bit 'special' a DNS packet will cause widespread failure.

This applies both to DNSSEC's huge (4kbyte) packets and 'new flags', as well
as to any DNSCURVE packets with >255 byte names.

See for example the recent DNSSEC report on common routers/modems, plus heed
http://blog.netherlabs.nl/articles/2006/04/13/the-general-mediocrity-of-the-world
(scroll down to 'go read the rfc already').

DNSCURVE <255 bytes names should not trigger anything special as far as I
can see.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: Florian Weimer <[email-masked]>
Date: Sun, 12 Oct 2008 17:52:32 +0200

* Matthew Dempsky:

> that contain domain names longer than 255 bytes?

Seriously, use a different UDP port.  As an added bonus, you don't
have to use a separate IP address for the reverse proxy.

-- 
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: Kevin Darcy <[email-masked]>
Date: Tue, 14 Oct 2008 01:23:53 -0400

> or anyone else think I just coincidentally picked this number to ask
No, I didn't think it was a "coincidence", but at the same time, I 
didn't know if you were aware how ancient, well-defined and 
well-established that particular limitation is.

Is there any reason why the research into the operational impact of 
changing the name-size limitation can't be conducted in _parallel_ with 
the discussions over the merits of the DNSCurve draft itself? Drafts 
almost always have multiple revisions anyway, whatever operational 
information that comes to light in this regard can be incorporated -- to 
the extent it needs to be -- into a later revision of the draft...

                        - Kevin

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 17 Oct 2008 14:05:55 -0400

<chair-hat= off>
<dns-historian=on>

>well-established that particular limitation is.

There are two DNS name lengths that implementations need to respect,
the 63 byte label length and the 255 byte total length.
With the exception of "not-so smart" proposed uses of bit-labels[1] there
has not been much evidence that the 255 byte name length is a problem.
Most label names are short (<20 characters) and depth of the DNS tree
is limited to <10 labels.

On the other hand, issues have been raised with the 63 byte
label length, in IDN contexts and in NSEC3 context. In IDN the problem
is mostly theoretical (and/or political) as the currently used punycode
encoder is highly effective.

As for DNS protocol elements there are a number of them out there that do
not follow the rules for DNS names because they think they know all the
rules. For example number of implementations drop DNS packets if the
name on first RRset uncompressed!
http://psg.com/lists/namedroppers/namedroppers.2006/msg00582.html

Based on this I would not make any assumptions if the 255 byte total length
is enforced/honored, without doing serious testing.

>changing the name-size limitation can't be conducted in _parallel_ 
>with the discussions over the merits of the DNSCurve draft itself? 
>Drafts almost always have multiple revisions anyway, whatever 
>operational information that comes to light in this regard can be 
>incorporated -- to the extent it needs to be -- into a later 
>revision of the draft...
>

Exactly, but there is no need to jump to action until we know if there
is a problem.
Problem == There is a demonstrated need in real life example, either
         an overflow occurs or we are real close to the overflow

Remember: changing the DNS infrastructure takes
REAL REAL REAL LONG LONG LONG time, think decades not years.

Historical note:
[1] Bit labels taught us two important lessons:
         1. Adding new label types is almost impossible as the whole
         infrastructure needs to be changed before the type is useful.
         Authoritative high level servers MUST know about the new label
         type or they will return FORMERR for the query.
         2. Changing the semantics of DNS is a difficult process that
         has unexpected side effects all over the place.

Bit labels were invented to address perceived need in the IPv6 reverse tree,
I was one of the people working on proposals that eventually lead to the
bit labels proposal. IMHO there was a fundamental mistake in that
whole process:
"People wanted to be able to delegate address blocks on any bit boundary".

The discussion that Bill Manning referred to about bit labels name being
broken up into so many DNS labels that the "ip6.arpa." or "ipv6.int."
post-fixes did not fit, was resolved by assuming that the IANA block
would be at least 6 bits long, preferably 12 bits long OR
in the bottom 64 bits people would have fewer than 64 delegations.
Of course the whole discussion was silly because who wants to issue
100+ queries to resolve a name or operate lots of zones that have
only have 1 or 2 delegations.

         Olafur