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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 20 Nov 2002 13:43:46 -0800

I agree with Paul. If you are going to move to a different port then you
really have to start asking why design DNSSEC within the straitjacket of
deployed DNS in the first place. 

If you are going to take that approach you could start asking how many
corner cases can be eliminated by simply taking a flag day and modifying
the protocol in a more radical fashion. Drop support for Heisod,
Chaosnet for starters, drop in a cryptographic framing protocol, DIME,
use manifests for signatures, .... 

If however you problem is simply that you need to route arround lossage
then you do not need a standard and in fact you don't want a standard,
all the standard does is help the attacker (the hotel ISP or whatever).

Set up a DNS relay on a random non standard port above 1024, set
yourself up with a DNS relay to that server on localhost. That way you
can adapt to changes in the DoS your ISP is playing against you.

		Phill

> -----Original Message-----
> From: Paul Vixie [mailto:[email-masked]]
> Sent: Wednesday, November 20, 2002 4:13 PM
> To: [email-masked]
> Subject: Re: Clear path? I'll give you clear path 
> 
> 
> i used to love this idea.  i remember when eastlake proposed 
> it in 1996.
> 
> 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.
> 
> 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.
> 
> --