Subject: Re: [dnsext] middleboxes and an alternate port number

From: William Allen Simpson <[email-masked]>
Date: Wed, 12 Aug 2009 07:26:34 -0400

Everything old is new again.  I'm fairly sure this was proposed more
than a decade ago....

Jim Reid wrote:
# I wouldn't want to rely on that assumption. If/when DNS uses an
# alternate or fallback port as you suggest, new middleboxes will almost
# certainly get firmware which breaks packets to that port number in the
# same way they break stuff to port 53. The same will no doubt hold if/
# when an alternate transport is used for DNS traffic.
#
I'd prefer that both protocol and port be returned.  The protocol would
provide the upgrade path, and the port could be randomized to prevent
"smart" boxes from interfering, probably greater than 4096.

Every installation would select the random port to listen.

[email-masked] wrote:
 > The overwhelming majority of middleboxes *DO NOT* break DNS traffic
 > that's _routed_ through them.
 >
 > However most SOHO boxes *DO* break DNS requests that are _directed_ at
 > them, particularly those with "large" responses.
 >
That's been my unfortunate experience, too.

 > Unfortunately that's a very common case because that's the "standard"
 > DHCP offer from their built-in DHCP servers, as apparently recommended
 > by the Broadband Forum.
 >
And IETF NAS requirements WG, and many others.  I probably helped build a
half dozen of these in the '90s, too.  Arguably, it helped cache and
reduce the load on the TLD and root servers.

But they complied with the standard, full caching resolvers, handling
fragmentation and everything else.

As Paul Vixie pointed out, many of these companies have long since died
circa 2000, and there's no way to upgrade them to DNSsec.  Even companies
still in business don't offer upgrades, they want you to buy new product.

 > What's really needed is a better way to bootstrap end-device DNS
 > settings so that clients can find their *real* upstream recursive
 > servers and not send queries to their SOHO gateway's proxy.
 >
We know how to do that.  An EDNS0 option that returns an alternate
protocol and port pair.  Then, the resolver send out a second query to
the authoritative server, assuming the middlebox passes Authority and
Additional (EDNS0) sections.

--
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/>