Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME

[Edward Lewis <[e-mail]>]

At 18:04 -0400 9/24/08, Michael StJohns wrote:
>If "intermediate validation to protect legacy stub resolvers" were deprecated,
>I'd agree with you.  (can we please huh huh can we deprecate it????)

If we deprecate that, what's the point of DNSSEC?  DNSSEC is designed 
to stem cache poisoning, so that caches don't give out answers they 
can't verify to their clients.  The client to cache is protected by 
TSIG, TKEY, IPSEC, or maybe just crossing one's fingers and hoping 
for the link to be secure.  (Legacy has to count on the latter - 
assuming legacy is pre-TSIG et.al.)

>Since we're still touting the utility of having an intermediate make a
>decision about what it wants to send to a stub based on the intermediate's
>understanding of security, we need to pick a consistent understanding of
>that security.  (In other words, the application we're concerned with here
>is the stub side server of the validating resolver).

Or we make use of the CD bit.  In early workshops (about 10 years ago 
I mean) we ran into the problem that not all computers agreed on the 
current time.  (NTP wasn't as widespread as it is now.)  The way 
around that at the time was to use the CD bit and get the answer as 
it passed through from the source.

>ps - anyone want to take a whack at documenting how various applications
>should handle various DNSSEC outcomes?  The ones I can think of off the top
>of my head that should be done are: SMTP (both submitter to MTA and MTA
>to MTA), HTTP (what the browser does *before* the user gets involved -
>pretty sure just exposing the DNSSEC resolution state isn't the best
>answer), SSH,  peer-to-peer.

DNSSEC was built ("repeat chorus") to stem cache poisoning, i.e., 
protect the admission of DNS data to the cache.  It wasn't meant to 
protect the applications making use of the data.  If an application 
wants to act like a cache with a verifier, fine.  Then it asks for 
everything with CD, gets as much raw data, and does it's own check. 
If it can't reach the source (because of firewalls, forwarders, 
etc.,), well it's up a creek anyway.

To an application - either their is an answer in DNS or not.  The 
grey area is too hard to make use of, a general solution isn't 
useful.  It's like with lame delegation testing in the reverse map. 
There are a lot of screw ups there, a lot follow certain pathologies 
that, even common, make up a small percentage of the total problems. 
It isn't worth trying to diagnose for the few predictable 
misconfigurations.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                [phone]
NeuStar

Never confuse activity with progress.  Activity pays more.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>