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

[Ben Laurie <[e-mail]>]

Edward Lewis wrote:
>> 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.

Surely the point is that DNSSEC changes the possible answers from:

1. RR exists and here it is.
2. RR does not exist.
3. Server not reachable (or otherwise broken).

to

1. RR exists and here it is.
2. RR does not exist.
3. RR exists but is broken in some way.
4. Server not reachable (or otherwise broken).

The question is: what should applications do for state 3? My answer
would be to treat it like state 4, I think, but there's room for debate.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

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