Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)?
Mark Andrews
In message <d791b8790810101526g1d...@mail.gmail.com>, "Matth
ew Dempsky" writes:
> 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.
Names over 255 bytes are a non-starter.
> Thanks.
>
> [1] http://homepages.tesco.net/J.deBoynePollard/FGA/dns-edns0-and-firewalls.h
> tml
> [2] http://en.wikipedia.org/wiki/EDNS#EDNS_in_practice
>
> --
> to unsubscribe send a message to namedroppe...@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
bman...@vacation.karoshi.com
> On Fri, Oct 10, 2008 at 4:22 PM, Mark Andrews <Mark_A...@isc.org> wrote:
> > Names over 255 bytes are a non-starter.
>
>
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
bman...@vacation.karoshi.com
> On Fri, Oct 10, 2008 at 5:04 PM, <bman...@vacation.karoshi.com> wrote:
> > 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."
>
> (not counting the IP or UDP headers)." Did this make EDNS0's support
> of UDP packets greater than 512 bytes a non-starter?
nope - EDNS changed that requirement. EDNS was defined
in an IETF RFC.
> 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.
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.
bman...@vacation.karoshi.com
> > 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.
>
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?
Mark Andrews
In message <d791b8790810101718s657...@mail.gmail.com>, "Matt
hew Dempsky" writes:
> On Fri, Oct 10, 2008 at 5:04 PM, <bman...@vacation.karoshi.com> wrote:
> > 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."
>
> 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?
EDNS0's packet size is hop-by-hop. Nameserver name size
is end-to-end.
> 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.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
--
bman...@vacation.karoshi.com
> On Fri, Oct 10, 2008 at 7:33 PM, <bman...@vacation.karoshi.com> wrote:
> > nope - EDNS changed that requirement. EDNS was defined
> > in an IETF 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?
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
bman...@vacation.karoshi.com
> > > 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?
> >
> > 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?
>
> 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.
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?
Mark Andrews
In message <20081011153...@vacation.karoshi.com.>, bman...@vacation.ka
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.
> --bill
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
--
bman...@vacation.karoshi.com
> On Sat, Oct 11, 2008 at 2:40 PM, Mark Andrews <Mark_A...@isc.org> wrote:
> > As to a formal proposal, I'm not aware of any myself.
>
> RFC? Did it just magically appear on the IETF servers one night?
>
> 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
Mark Andrews
In message <20081011223...@vacation.karoshi.com.>, bman...@vacation.ka
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
> --bill
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
--
bman...@vacation.karoshi.com
>
> > 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.
>
> 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
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
bman...@vacation.karoshi.com
> On Sat, Oct 11, 2008 at 3:38 PM, <bman...@vacation.karoshi.com> wrote:
> > label lengths larger than 255 octets
>
> 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?
bman...@vacation.karoshi.com
> On Sat, Oct 11, 2008 at 4:10 PM, <bman...@vacation.karoshi.com> wrote:
> > On Sat, Oct 11, 2008 at 03:49:05PM -0700, Matthew Dempsky wrote:
> >> DNSCurve only uses labels up to 53 bytes in length.
> >
> > why only 53 bytes?
>
> 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.
my copy of the DNS spec sez lables may not exeed 64 bytes.
where in the spec does it say 53 bytes?
> 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 have no idea what DNSCurve will let people do.
waiting to see the DNSCurve spec.
bman...@vacation.karoshi.com
> On Sat, Oct 11, 2008 at 6:38 PM, <bman...@vacation.karoshi.com> wrote:
> > my copy of the DNS spec sez lables may not exeed 64 bytes.
> > where in the spec does it say 53 bytes?
>
so DNSCurve is not compliant w/ the DNS spec.
thats useful to know.
>
> > i have no idea what DNSCurve will let people do.
> > 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.
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.
bert hubert
> 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?
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
Florian Weimer
> 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?
Seriously, use a different UDP port. As an added bonus, you don't
have to use a separate IP address for the reverse proxy.
--=20
Florian Weimer <fwe...@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstra=DFe 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
Olafur Gudmundsson
Content-Type: text/plain; charset="us-ascii"; format=flowed
<chair-hat= off>
<dns-historian=on>
At 07:42 14/10/2008, Kevin Darcy wrote:
>Matthew Dempsky wrote:
>>On Sat, Oct 11, 2008 at 2:59 PM, Eric Rescorla
>><e...@networkresonance.com> 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?
>>
>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.
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.
>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...
>
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
--=====================_608930926==.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<body>
<font size=3><chair-hat= off> <br>
<dns-historian=on> <br><br>
At 07:42 14/10/2008, Kevin Darcy wrote:<br>
<blockquote type=cite class=cite cite="">Matthew Dempsky wrote:<br>
<blockquote type=cite class=cite cite="">On Sat, Oct 11, 2008 at 2:59 PM,
Eric Rescorla <e...@networkresonance.com> wrote:<br>
<br>
<blockquote type=cite class=cite cite="">Is the suggestion that DNSCurve
should be made an RFC? If so, it<br>
seems to me that a clear prerequisite to that discussion would be<br>
the existence of DNSCurve I-D.<br>
</blockquote><br>
Yes. I've been working on a DNSCurve Internet-Draft since it
was<br>
brought up on Thursday, and I hope to have a publicly available
draft<br>
soon.<br><br>
<br>
<blockquote type=cite class=cite cite="">Barring that, why exactly are we
having a discussion about the<br>
practicality of a specific design decision in DNSCurve?<br>
</blockquote><br>
I initially brought it up because I wanted to know if anyone knew of<br>
*operational* issues with these limitations. I was well aware
that<br>
the RFCs limited names to 255 bytes. Did Bill Manning, Kevin
Darcy,<br>
or anyone else think I just coincidentally picked this number to ask<br>
about?<br>
</blockquote>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.<br>
</font></blockquote><br>
There are two DNS name lengths that implementations need to respect,
<br>
the 63 byte label length and the 255 byte total length. <br>
With the exception of "not-so smart" proposed uses of
bit-labels[1] there <br>
has not been much evidence that the 255 byte name length is a
problem.<br>
Most label names are short (<20 characters) and depth of the DNS tree
<br>
is limited to <10 labels. <br><br>
On the other hand, issues have been raised with the 63 byte <br>
label length, in IDN contexts and in NSEC3 context. In IDN the problem
<br>
is mostly theoretical (and/or political) as the currently used punycode
<br>
encoder is highly effective. <br><br>
As for DNS protocol elements there are a number of them out there that do
<br>
not follow the rules for DNS names because they think they know all
the<br>
rules. For example number of implementations drop DNS packets if the<br>
name on first RRset uncompressed! <br>
<a href="http://psg.com/lists/namedroppers/namedroppers.2006/msg00582.html" eudora="autourl">
http://psg.com/lists/namedroppers/namedroppers.2006/msg00582.html</a><br>
<br>
<font size=3>Based on this I would not make any assumptions if the 255
byte total length<br>
is enforced/honored, without doing serious testing. <br><br>
<blockquote type=cite class=cite cite="">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...<br><br>
</font></blockquote><br>
Exactly, but there is no need to jump to action until we know if there
<br>
is a problem. <br>
Problem == There is a demonstrated need in real life example, either
<br>
<x-tab> </x-tab>an
overflow occurs or we are real close to the overflow <br>
<x-tab> </x-tab>
<br>
Remember: changing the DNS infrastructure takes <br>
REAL REAL REAL LONG LONG LONG time, think decades not years. <br><br>
Historical note: <br>
[1] Bit labels taught us two important lessons: <br>
<x-tab> </x-tab>1. Adding
new label types is almost impossible as the whole<br>
<x-tab> </x-tab>
infrastructure needs to be changed before the type is useful.<br>
<x-tab> </x-tab>
Authoritative high level servers MUST know about the new label <br>
<x-tab> </x-tab>type or
they will return FORMERR for the query. <br>
<x-tab> </x-tab>2.
Changing the semantics of DNS is a difficult process that <br>
<x-tab> </x-tab>has
unexpected side effects all over the place. <br><br>
Bit labels were invented to address perceived need in the IPv6 reverse
tree, <br>
I was one of the people working on proposals that eventually lead to
the<br>
bit labels proposal. IMHO there was a fundamental mistake in that <br>
whole process:<br>
"People wanted to be able to delegate address blocks on any bit
boundary". <br><br>
The discussion that Bill Manning referred to about bit labels name being
<br>
broken up into so many DNS labels that the "ip6.arpa." or
"ipv6.int." <br>
post-fixes did not fit, was resolved by assuming that the IANA block
<br>
would be at least 6 bits long, preferably 12 bits long OR <br>
in the bottom 64 bits people would have fewer than 64 delegations. <br>
Of course the whole discussion was silly because who wants to issue <br>
100+ queries to resolve a name or operate lots of zones that have <br>
only have 1 or 2 delegations. <br><br>
<x-tab> </x-tab>
Olafur </body>
</html>
--=====================_608930926==.ALT--