Subject: Clear path? I'll give you clear path

From: "Matt Larson" <[email-masked]>
Date: Wed, 20 Nov 2002 13:15:25 -0500

A way around the non-DNSSEC-aware, non-DS-aware, non-EDNS0-aware,
transparent NATting, broken DNS caches from hell is to use another port
for DNSSEC queries.  Bear with me on this one.

- The alternate port supports the traditional DNS protocol, but with
some assumptions:
  - The protocol speakers are DNSSEC-aware, including DS support and
whatever else gets
    thrown in for the flag day.
  - The protocol speakers support EDNS0 with a large message size, say
1220 bytes as
    specified in RFC 3226.
- A DNSSEC-capable server listens on this alternate port as well as port
53.
- Any query, whether DNSSEC-related or not, can be sent to the alternate
port.  But the assumptions
  about the sender's capabilities (see above) hold.
- A recursive resolver sends a query to the alternate port when it wants
a DNSSEC response or
  has reason to believe the queried server to be DNSSEC-capable (i.e.,
it has a trusted key configured
  for a given apex that's an ancestor of a QNAME it's recursing on).
- When a recursive resolver gets an indication that the server doesn't
support DNSSEC or crosses a
  boundary into an unsigned zone, it reverts to port 53.
- I believe this makes the OK bit redundant, at least for the alternate
port.

This is NOT an attempt to fuss with the DNS protocol or invent something
new for this alternate port.  It's using the same protocol, but with
different underlying assumptions about the speakers' capabilities, on a
different port.

Before you light into me, think about the alternatives: an ugly name
space hack for DS or yet another DNSSEC-capabilities flag (to indicate
DS awareness).  And even with all that, we'd still have EDNS0 probing
issues and other "clear path" issues, such as transparent proxies.  All
this goes away with an alternate port.

Matt

--
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: Jim Reid <[email-masked]>
Date: Wed, 20 Nov 2002 11:27:30 -0800

>>>>> "Matt" == Matt Larson <[email-masked]> writes:

    Matt> A way around the non-DNSSEC-aware, non-DS-aware,
    Matt> non-EDNS0-aware, transparent NATting, broken DNS caches from
    Matt> hell is to use another port for DNSSEC queries. 

It's probably not a good idea to run the same protocol -- albeit where
one flavour has DNSSEC -- on >1 port. Other protocols have not done
this whenever extensions or new versions have come along. An extra
port for DNS may well create lots of operational problems, like
requiring another hole to get punched though everyone's firewall and
router configurations. [And what happens when a DNSSEC-aware query
that becomes DNSSEC-unware (or vice versa) resolves through a stateful
firewall or proxy?] It's not clear to me what benefit arises from
using another port number compared to just using the OK bit, assuming
that bit can helps the clear path issue.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Nov 2002 21:12:35 +0000

i used to love this idea.  i remember when eastlake proposed it in 1996.

>     thrown in for the flag day.

yes, well, other things that would get thrown in for flag day would most
likely include unicode name encoding, xml message encoding, and a pile
of other stuff we havn't even heard of yet.  in other words, this would
be madness, the dns community lacks the required discipline to make a
moderate change.  small or large, we can do.  moderate, i don't think so.

> new for this alternate port.

(as if we'd have a choice about complete reinvention if we cut that deep.)

> It's using the same protocol, but with different underlying
> assumptions about the speakers' capabilities, on a different port.

one more objection, having more to do with deployed human nature than
latent human nature: there are a LOT of firewalls that only allow known
port numbers.  i'd say there are more segments which are isolated from
udp/42 (or whatever this dns++ would speak) than there are segments whose
gateways pervert/rewrite udp/53 as it passes through.

> this goes away with an alternate port.

the edns0 probing issues are tractible, and another flag bit would be 
tractible.  even some kind of odd name hack would be tractible.  but
trying to get an alternate port number standardized without resolving
the rest of the community's long standing gripes against dns would just
be intractible.

it's a nice thought of course, for some kind of alternate universe where
deadlines mattered.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Nov 2002 16:41:42 -0500

I'm going to counter Jim's point.

>one flavour has DNSSEC -- on >1 port. Other protocols have not done

Donald broached this possibility (at least) recently.  What this does 
is remove danger to old implementations (do no/less harm).  It 
removes a need to be overly concerned with remaining compatible with 
"broken" parts of the old protocol.

'Course Jim is right is that mean that the anti-end-to-end boxes will 
have to be updated for this anyway (i.e., you can't just blast 
through a firewall).  But at least if we're messing on another port, 
there's a assurance of a hard failure when there's no clear channel.

Delving in to the realm of conjecture, has adding a second port to a 
protocol ever made improvement easier?  I think there are examples 
where a new port hasn't helped.  Whois, maybe?  (Perhaps I'm wrong, 
but that leaps to mind.)  Okay, hasn't helped yet.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Danny Mayer <[email-masked]>
Date: Wed, 20 Nov 2002 20:12:09 -0500

>that bit can helps the clear path issue.

Well, https, the SSL'ed version of HTTP Protocol DOES use a different
port. You can argue that it's different in the sense that the setup of the
connection is different. I remember having this revelation in December, 1995
in the middle of teaching a seminar on firewalls that maybe we couldn't do
https through our Netscape proxy server. I had to go back to the office to
confirm that it wouldn't work and that furthermore that version of Netscape's
proxy server couldn't handle it.

Danny