Subject: Re: [dnsext] Danger of coming unstuck

From: Mark Andrews <[email-masked]>
Date: Wed, 24 Jun 2009 16:13:09 +1000

In message <83C433523C814BD994275B1650CB75AA@localhost>, "George Barwood" write
s:
> ----- Original Message ----- 
> From: "Mark Andrews" <[email-masked]>
> To: "Francis Dupont" <[email-masked]>
> Cc: "George Barwood" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, June 23, 2009 3:32 PM
> Subject: Re: [dnsext] Danger of coming unstuck 
> 
> 
> > For the record named already does this.
> > 
> > 1804.   [bug]           Ensure that if we are queried for glue that it fits
> >                        in the additional section or TC is set to tell the
> >                        client to retry using TCP. [RT #10114]
> > 
> > BIND 9.2.6, 9.3.2, 9.4.0
> 
> Thanks for this, that helps considerably.
> 
> There still seem to be conflicting requirements here though.
> 
> For example, for the non-DNSSEC query
> 
> dig net @a.root-servers.net

	Which isn't a realist query.  Add another label and you
	start loosing addresses.

	dig lkkasdh.net @a.root-servers.net
 
> we do not want to set TC ( the response with all required/necessary glue included does not fit in 512 bytes ).
> [ Note: RFC 1034 uses necessary, RFC 1035 uses required, I assume no distinction was intended ]
> 
> So the question arises, how much glue is enough? How many name servers are enough?

	The requirement is not to get a resolution deadlock.  The
	only way to ensure that is to return all the potential glue
	(addresses for names under the delegating zone).

> I don't think the standard needs to be 100% prescriptive here,
> but it ought to indicate the pitfalls.  Since falling back to TCP
> is undesirable and quite likely to fail in practice,

	TCP works in practice.  There are only rare failures.

> I think reasonable efforts should be made to avoid this where
> possible, both on the resolver and server side.

	Which basically has been done.

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

--
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: "George Barwood" <[email-masked]>
Date: Wed, 24 Jun 2009 07:52:43 +0100

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Francis Dupont" <[email-masked]>; "Mark Andrews" <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 24, 2009 7:13 AM
Subject: Re: [dnsext] Danger of coming unstuck 

> Which isn't a realist query.  Add another label and you

If you use +edns=0, you can see that addresses have already been lost.
That's the point of the example really ( full response size is 517 bytes ).

Also I think it is realistic, a good resolver will I suggest keep the question short for TLDs.
That helps.

> (addresses for names under the delegating zone).

Hmm... well I need to think about that, but I'm not convinced.
For example I suspect returning a random subset of 4 glue records is good enough,
and preferable to TCP fallbacks. But this needs thought.
 
> TCP works in practice.  There are only rare failures.

Maybe if you are in the USA with good connections.
I frequently cannot get a TCP connection to .org servers, for example.
I guess UDP(/53?) packets tend to get prioritized by networks ( not my expertise though ).
 
> Which basically has been done.

Maybe, but I think further thought, especially in light of BIND @512, may be worthwhile.

>¶‹§²æìr¸›zÇ§u©ž²Æ zÚ'jg®Šiz»+z«ž²Ú)²'~ŠàÂ+a¶°¢·nžË›±Êâmè§jÈ§‚W¥Šwš²Ø^™ë,j{[¡ÜšÈb½èm¶Ÿÿ¢›"z×è®åŠËlþv¦yÚè¦—«³

---

From: Mark Andrews <[email-masked]>
Date: Wed, 24 Jun 2009 18:36:22 +1000

In message <BD1A7DCCD8C24AFB92FD895C690C381E@localhost>, "George Barwood" write
s:
> For example I suspect returning a random subset of 4 glue records is
> good enough, and preferable to TCP fallbacks. But this needs thought.
>  

	I'm not in the US.

> I guess UDP(/53?) packets tend to get prioritized by networks
> (not my expertise though ).

	I would suggest that you look at your own network.  It's
	not the general case.

> Maybe, but I think further thought, especially in light of BIND @512,

	Plain DNS is the exception not the rule these days.  EDNS@512
	is the exception not the rule.

	Mark

---

From: [email-masked]
Date: Wed, 24 Jun 2009 10:50:37 +0200 (CEST)

> I guess UDP(/53?) packets tend to get prioritized by networks ( not my expertise though ).

"Tend to get prioritized by networks"? Hardly. In most networks UDP
packets are treated just like any other IP packets - i.e. best effort.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 24 Jun 2009 15:03:32 +0000

> Date: Wed, 24 Jun 2009 10:50:37 +0200 (CEST)
> From: [email-masked]
> 

i wish that were the case.  udp/53 gets rampantly monetized by middleboxes
to a degree far beyond that of any other kind of IP packet.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 24 Jun 2009 15:02:03 +0000

> From: Mark Andrews <[email-masked]>
> Date: Wed, 24 Jun 2009 18:36:22 +1000
> 

can we do some measurement and analysis, to prove (or not) that assertion?
for example, ISC SIE sees ~50Mbit/sec of DNS response traffic now.  can we
extract out the EDNS information from a few hours of data to find out what
is actually working?  or if that's too narrow, can someone write a perl or
awk script and post it here so that a lot of folks can all run tcpdump on
busy recursive nameservers and extract out the information needed?  duane
wessels of OARC, i'm looking at *you*.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Jun 2009 09:11:35 +1000

> can we do some measurement and analysis, to prove (or not) that assertion?

	Well for iterative traffic it is.

	Recursive traffic is still mostly plain DNS but recursive
	traffic doesn't need additional data.

	Adding "options edns0" to resolv.conf works for the latter
	but it is not the default.

	Mark

---

From: Paul Vixie <[email-masked]>
Date: Thu, 25 Jun 2009 02:23:16 +0000

> Date: Thu, 25 Jun 2009 09:11:35 +1000
> 
> > > 	Plain DNS is the exception not the rule these days.  EDNS@512 is
> > > 	the exception not the rule.
> > 

i repeat: show me.

> 	but it is not the default.

where are the reproduceable test results that underlay these assertions?

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Jun 2009 13:19:28 +1000

> > 	Well for iterative traffic it is.

	We have ~70% EDNS capable iterative clients (see the recent
	ORG analsyis).  We have > 70% EDNS capable auth servers.
	Both of these figures are growing.  This give a successful
	EDNS transaction > 50% of the time as it requires both ends
	to support EDNS.

	EDNS@512 only capable < 1% (again from recent ORG analsyis).

---

From: [email-masked]
Date: Thu, 25 Jun 2009 07:12:34 +0100

>    EDNS@512 only capable < 1% (again from recent ORG analsyis).

I don't believe that analysis shows that they're _only_ capable of 
EDNS@512, they might still be perfectly capable of EDNS@1460

Ray

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Jun 2009 16:20:17 +1000

In message <[email-masked]
> EDNS@512, they might still be perfectly capable of EDNS@1460

The roots don't emit EDNS answers that would be dropped due to
fragmentation.  EDNS@512 at the root < 1%.  Some of that is from
nameservers that don't see any replies.  Some of that is from
nameservers where all EDNS answers are filtered.

For ORG some of the EDNS@512 will be due to fragmented responses
not getting through but again that is < 1%.

Whatever the case 1% is a over estimate.

---

From: [email-masked]
Date: Thu, 25 Jun 2009 09:11:11 +0200 (CEST)

> to a degree far beyond that of any other kind of IP packet.

That may well be the case - however, as far as I know the big transit
providers (e.g. Global Crossing, Level3 etc) don't do anything special
with DNS traffic. I know the ISP I work for doesn't...

---

From: Florian Weimer <[email-masked]>
Date: Thu, 25 Jun 2009 09:13:50 +0200

* Mark Andrews:

> fragmentation.

They actually do (you posted DF=1 examples yourself), but this lack of
conformance is irrelevant because anyone who can't receive such
packets will only have reduced connectivity (even if they get DNS from
someone else), so they will fix whatever is causing this.

-- 
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: Florian Weimer <[email-masked]>
Date: Thu, 25 Jun 2009 09:43:47 +0200

* Mark Andrews:

> 	ORG analsyis).

I still don't think the ORG numbers are representative due to the way
ORG is currently served.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 25 Jun 2009 14:50:23 +0200

On Wed, Jun 24, 2009 at 03:02:03PM +0000,
 Paul Vixie <[email-masked]> wrote 

> can we do some measurement and analysis, to prove (or not) that

On a .FR authoritative name server:

50.3 % of the requests are EDNS0. (TODO: same metric but only for big
clients, those with many requests.)

Sizes are:

 edns0_size | percentage 
------------+------------
       4096 |  95.86
       4000 |    .00
       2944 |    .00
       2048 |   2.78
       1500 |    .00
       1472 |    .00
       1460 |    .25
       1452 |    .00
       1400 |    .01
       1352 |    .00
       1300 |    .00
       1280 |    .27
       1252 |    .00
       1200 |    .03
       1024 |    .01
        800 |    .00
        730 |    .00
        512 |    .79

> can someone write a perl or awk script and post it here

Perl? Real Men <http://www.dnsmezzo.net/> do not use Perl!

SELECT DISTINCT edns0_size, count(id) AS number FROM Recent_packets
           WHERE query
           GROUP BY edns0_size ORDER BY edns0_size DESC;

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 25 Jun 2009 15:41:57 +0200

On Thu, Jun 25, 2009 at 02:50:23PM +0200,
 Stephane Bortzmeyer <[email-masked]> wrote 

> clients, those with many requests.)

I've set an arbitrary limit at 1000 queries received in two days. DNS
clients above this limit ("big resolvers", 6.0 % of the total number
of clients) are EDNS0 at 59.5 %.

So, there is hope, big clients are a bit better.

Also, in the same spirit, 28.9 % of the clients send at least one
EDNS0 packet. So we have a few big clients which are often EDNS0 and a
lot of small clients which are often not EDNS0 (namedroppers
subscribers playing with dig?)

---

From: bert hubert <[email-masked]>
Date: Thu, 25 Jun 2009 16:00:16 +0200

> subscribers playing with dig?)

Or you are seeing clients that fall back to non-EDNS0 on a timeout,
and stay that way?

I can't imagine bigger resolvers hiding behind NAT, so each client you
see is probably exactly that, a single server.

     Bert

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 25 Jun 2009 16:12:05 +0200

On Thu, Jun 25, 2009 at 04:00:16PM +0200,
 bert hubert <[email-masked]> wrote 
 a message of 13 lines which said:

> > a lot of small clients which are often not EDNS0 (namedroppers

Unfortunately, there is no User-Agent string in DNS requests so it
will be hard to say :-)

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Jun 2009 00:54:27 +1000

In message <[email-masked]>, Florian Weimer writes:
> They actually do (you posted DF=3D1 examples yourself), but this lack of

And the answers the roots produce don't get big enough to trigger
fragmentation on current links.  This assumes that someone hasn't
configured a link to use a dramatically smaller mtu than standard.

> --=20
> Kriegsstra=DFe 100              tel: +49-721-96201-1

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Jun 2009 00:59:29 +1000

> I still don't think the ORG numbers are representative due to the way

The root servers also show this.  I suspect that if you sample any
EDNS capable TLD you will get similar traffic distributions.  If
you sample a TLD which doesn't use EDNS capable servers you will
see more plain DNS than EDNS as the EDNS clients fallback to plain
DNS.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 25 Jun 2009 14:59:59 +0000

> Date: Thu, 25 Jun 2009 16:20:17 +1000
> Sender: [email-masked]
> 

again i say, i'd like to see references to reproduceable results on this.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 25 Jun 2009 15:03:01 +0000

> From: Florian Weimer <[email-masked]>
> Date: Thu, 25 Jun 2009 09:43:47 +0200
> 

florian, perhaps you can do a 24-hour study of ISC SIE's data and tell
us all what you find?

---

From: Matt Larson <[email-masked]>
Date: Thu, 25 Jun 2009 11:06:22 -0400

> The roots don't emit EDNS answers that would be dropped due to

All of the roots?  Source, please.

> EDNS@512 at the root < 1%.

All of the roots?  F root?  Something else?  Source, please.

> not getting through but again that is < 1%.

Do you have direct data from .org?  Source, please.

> Whatever the case 1% is a over estimate.

You have not shown data to back up this claim.

Matt

---

From: Matt Larson <[email-masked]>
Date: Thu, 25 Jun 2009 11:22:25 -0400

On Fri, 26 Jun 2009, Mark Andrews wrote:
> EDNS capable TLD you will get similar traffic distributions.

Not so.  See slide 22 of
https://www.dns-oarc.net/files/workshop-2008/larson.pdf: from 24 hours
of traffic to the .com/.net name servers in September 2008, only
28.48% of queriers were EDNS0 capable.  Even if we assume that many of
those were bots and re-calculate the figure based on the number of
queriers that sent at least ten queries in that 24-hour interval (the
threshold for our analysis), the percentage is only 50% EDNS0 capable.

Matt

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Jun 2009 02:14:00 +1000

In message <[email-masked]>, Matt Larson 
> All of the roots?  Source, please.

It's quite easy to calculate maximum referral sizes to all the TLDs.
None of these is likely to trigger fragmentation today.
 
> All of the roots?  F root?  Something else?  Source, please.

L and F based on the ORG traffic ananlyis pdf from the turning on of DNSSEC
presented at the last NANOG meeting.

---

From: bert hubert <[email-masked]>
Date: Thu, 25 Jun 2009 23:34:44 +0200

> threshold for our analysis), the percentage is only 50% EDNS0 capable.

So what resolver is not EDNS0 capable, except for the PowerDNS Recursor <3.1.8?

Because I don't believe 50% of your queries come from me..

Nominum CNS perhaps? Or Windows? Or Cisco?

I know this is not standards work, but as long as we don't know, any
estimates we make are bound to point us in the wrong direction.

    Bert

---

From: Matthew Dempsky <[email-masked]>
Date: Thu, 25 Jun 2009 15:22:31 -0700

> So what resolver is not EDNS0 capable, except for the PowerDNS Recursor <3.1.8?

dnscache does not use EDNS0.

I also just made OpenDNS's caches forward a few queries to my personal
name server, and none of the queries used EDNS0.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 25 Jun 2009 15:59:05 -0700

> name server, and none of the queries used EDNS0.

Likewise, the Comcast DNS resolvers don't use EDNS0.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 26 Jun 2009 00:02:55 +0100

> Nominum CNS perhaps? Or Windows? Or Cisco?

Guessing here, but $middlebox may contribute to this percentage.

-- 
Alex Bligh

---

From: bert hubert <[email-masked]>
Date: Fri, 26 Jun 2009 01:06:20 +0200

> Guessing here, but $middlebox may contribute to this percentage.

I've always wondered - what are these famed "middleboxes"? Any large
resolver will not be hiding behind a firewall that interferes, nor
will it be hosted on a network with a captive portal.

Stubs generally don't talk to GTLD servers either.

So what does sit in between?

  Bert

---

From: [email-masked]
Date: Thu, 25 Jun 2009 23:37:56 +0000

oh the list is long and distinguished.

http://www.icann.org/en/committees/security/ssac-documents.htm
look at SAC035

--bill

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 25 Jun 2009 16:49:10 -0700

On Jun 25, 2009, at 4:06 PM, bert hubert wrote:

>>> So what resolver is not EDNS0 capable, except for the PowerDNS  
>>> Recursor
>>> <3.1.8?
>>>
> I've always wondered - what are these famed "middleboxes"?

A lot of firewalls have DNS modules, as do a lot of NATs, and a lot of  
these may have bugs.  A common one, for example, is assuming that DNS  
packets don't fragment.

> Any large

I agree with the latter, but NOT the former.  I'm working on a  
releasable writeup, but it is shocking the # of resolvers which  
advertise EDNS0 but can't receive a >1800B EDNS-enabled response.

However, the experience on the probing from the end user's connection  
to our server suggests that middleboxes might easily assume that DNS  
is <512B, or that DNS packets don't fragment, but it is the rare rare  
such box that assumes that EDNS0 is invalid and drops it.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Jun 2009 10:20:40 +1000

In message <[email-masked]>, Nicholas W
> such box that assumes that EDNS0 is invalid and drops it.

And iterative resolvers work around such breakages because they are
a fact of life on the Internet that just has to be dealt with.  No
authoritative server operator should fear turning on EDNS anymore
though some do.

"but the lookups work with this other nameserver" is enough to get
the problem addressed in most cases.

These boxes fall into "it would be nice to get them all fixed but
it is not critical that it be done" category.  They don't cause the
recovery strategies to be triggered often enough to be a worry.
Vendors should be made aware of the faults so the next generation
of the box doesn't have the same fault.

Mark

---

From: Alex Bligh <[email-masked]>
Date: Fri, 26 Jun 2009 08:58:17 +0100

> I've always wondered - what are these famed "middleboxes"?

Perhaps I haven't been following the thread, but I hadn't thought
that figure was just from large resolvers. I was referring to
some of the middleboxen written by those who should have
read draft-ietf-dnsext-dnsproxy first, i.e. either filtering
queries, or acting as a broken forwarder. I would guess this
is mainly consumer/SME CPE, but the world is not short of
broken firewalls for larger organisations either.

-- 
Alex Bligh

---

From: Florian Weimer <[email-masked]>
Date: Fri, 26 Jun 2009 10:22:25 +0200

* Mark Andrews:

> fragmentation on current links.

The last time I saw a fragmented response from a root server was less
then a year ago. *shrug*

---

From: [email-masked]
Date: Fri, 26 Jun 2009 10:43:07 +0100

> http://www.icann.org/en/committees/security/ssac-documents.htm

Much as I appreciate the citation, I don't believe it's relevant.

The middleboxes that we tested were consumer level devices, where 
recursive queries from stubs were addressed directly to the DNS proxies 
sat therein and then forwarded to "real" recursive servers upstream.

I'm not aware of any specific problem with higher-grade firewalls 
interfering with the subsequent queries sent between the recursive 
resolvers and authoritative servers.

Ray

---

From: Alex Bligh <[email-masked]>
Date: Fri, 26 Jun 2009 11:06:10 +0100

> resolvers and authoritative servers.

Sometimes the issue is with the configuration rather than the
device. The following is a snippet from a PIX config.

policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum 512

A google search for "message-length maximum 512" suggests this
is not uncommon, and indeed appears to be splashed over a number
of cisco.com example configs.

-- 
Alex Bligh

---

From: [email-masked]
Date: Fri, 26 Jun 2009 11:15:59 +0100

> of cisco.com example configs.

ah yes, I've heard of that one, but never seen it in person.

Ray

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Jun 2009 00:20:05 +1000

> of cisco.com example configs.

And you will also see people saying to raise this to 4096.

Mark

---

From: Paul Vixie <[email-masked]>
Date: Fri, 26 Jun 2009 15:24:17 +0000

> From: [email-masked]
> Date: Fri, 26 Jun 2009 11:15:59 +0100
> ...
> ...

i don't have real data on how frequent that is compared to other reasons
why edns often fails, but subjectively now, it's not my worst nightmare.
my worst nightmare is a stateless firewall that does not reassemble ip
datagrams before applying pass/drop rules, and does not remember to pass
following fragments if it passed the initial fragment.  to ip, udp is just
payload, and so the transport headers including source-port and dest-port
are only present in the first ip fragment.

if you use ipfw and you have a rule like this:

	add pass udp from any 53 to any
	add pass udp from any to any 53

then you also need a rule like this:

	add pass udp from any to any frag

note that i am still fixing this in various outlying freebsd firewalls,
a decade after RFC 2671 was published.  i can only imagine how many other
firewalls never bothered allowing frags since udp/53 always fit into a
VAX physmem page (512 bytes) back in the day, and fragmentation just did
not happen.

i suppose that if firewalls and nat and proxies had been first class
citizens of the ip architecture rather than bolt-ons that annoyed purists,
then rules like "if you're going to refuse forwarding for some ip datagrams,
then you should perform ip reassembly before deciding whether to do so, so
that your firewall operates on datagrams, not on packets" would be in force.

---

From: [email-masked]
Date: Fri, 26 Jun 2009 17:16:25 +0000

> And you will also see people saying to raise this to 4096.

	is there any good reason not to?  if, of course, they 
	want to follow the protocol...

--bill

---

From: Alex Bligh <[email-masked]>
Date: Fri, 26 Jun 2009 18:40:51 +0100

> 	want to follow the protocol...

Allegedly the 512 byte limit (which was at one point the
default setting and for all I know may still be) was introduced
to mitigate reflection DDOS attacks.

I'm not trying to pick on Cisco here, just point out that
the idea there will be no interfering middleboxen in front of
corporate connections is probably wrong.

-- 
Alex Bligh

---

From: Paul Vixie <[email-masked]>
Date: Fri, 26 Jun 2009 19:36:40 +0000

> Date: Fri, 26 Jun 2009 18:40:51 +0100
> From: Alex Bligh <[email-masked]>
> 
> I'm not trying to pick on Cisco here, just point out that the idea there
> will be no interfering middleboxen in front of corporate connections is
> probably wrong.

no doubt every single operator or implementor or businessman who sees udp/53
as the right shim layer to jam in their extra functionality has a reason, but
the end effect is to make any changes to the protocol extremely expensive, and
i still think it'll drive us toward dns-over-https as a way to drive a stake
through this middleism once and finally.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Jun 2009 08:50:04 +1000

> 	want to follow the protocol...

The protocol was extended 10 years ago give or take a couple of
months.  These firewalls were written well after the extension was
published.  Firewall designers need to understand the protocols
they are playing with.  It was not like there were not active
examples around when these were designed.  The designers just didn't
do their home work.

Network Working Group                                            P. Vixie
Request for Comments: 2671                                            ISC
Category: Standards Track                                     August 1999

If they want to live by RFC1034 then they should examine the queries
and return FORMERR on them for having garbage in the additional
section.  This would have made extending the DNS predicable.

Alternatively they should examine the queries and set the allowed
response size based on the EDNS options in the query.  There is no
need for a one size solution.

And for the record there have been larger than 512 bytes responses
over UDP between co-operating machines as long as I've been involved
with DNS and thats over 20 years now.  EDNS just provided a standards
based mechanism for doing so.  We had code to catch and handle
responses from such servers years before EDNS was dreamed of.

Mark

---

From: [email-masked]
Date: Fri, 26 Jun 2009 22:56:15 +0000

> examples around when these were designed.  The designers just didn't

	so there is no good reason to not change the 
	default configuration to comply with the RFC.
	and this advice should be applicable to all
	designers/developers... to follow the RFCs?

--bill

---

From: Doug Otis <[email-masked]>
Date: Fri, 26 Jun 2009 18:07:13 -0700

On Jun 26, 2009, at 12:36 PM, Paul Vixie wrote:

>> I'm not trying to pick on Cisco here, just point out that the idea  
>> there will be no interfering middleboxen in front of corporate  
>> connections is probably wrong.
>
> no doubt every single operator or implementor or businessman who  
> sees udp/53 as the right shim layer to jam in their extra  
> functionality has a reason, but the end effect is to make any  
> changes to the protocol extremely expensive, and i still think it'll  
> drive us toward dns-over-https as a way to drive a stake through  
> this middleism once and finally.

Does that mean DNSSEC will not be thwarting middleboxen that change  
DNS responses?  HTTPS on a large scale is also fairly expensive  
compared to DNS.  TCP connections not in the ESTABLISHED state are  
normally not controllable by applications, and TCP related kernel  
restrictions against applications are often not aimed at assuring its  
availability.

TCP's band-aided vulnerabilities and clumsy buffer processing is not  
really well suited for DNS.  Reliance upon TCP when under attack will  
likely necessitate significantly greater resources and specialized  
defenses.  Many resource related vulnerabilities or DDoS concerns  
could be better addressed using a different transport.   Having an  
available alternative might represent a valuable refuge during times  
of attack.  Instantiating an alternative may also prove to offer  
valuable insurance.

-Doug

---

From: Paul Vixie <[email-masked]>
Date: Sat, 27 Jun 2009 08:01:26 +0000

> From: Doug Otis <[email-masked]>
> Date: Fri, 26 Jun 2009 18:07:13 -0700

> > ..., and i still think it'll drive us toward dns-over-https as a way to
> > drive a stake through this middleism once and finally.
> 
> Does that mean DNSSEC will not be thwarting middleboxen that change DNS
> responses?

no it doesn't mean that.

---

From: Tony Finch <[email-masked]>
Date: Mon, 29 Jun 2009 00:24:36 +0100

On Sat, 27 Jun 2009, Mark Andrews wrote:
> published.

PIXes are much older than that. They are notorious for screwing up many
higher-level protocols.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 29 Jun 2009 07:00:29 +0100

> PIXes are much older than that. They are notorious for screwing up many

Indeed, but that particular bit of CLI (and it being a default) is far more
recent, and is in (e.g.) ASA 5500 / 5510 / 5520.

-- 
Alex Bligh