At 16:03 +0200 10/12/06, Peter Koch wrote:
What Ed didn't say but could have to avoid myth spread: the schemes described
in RFC 4471 and RFC 4472 (dnsext's work, btw, but never mind ;-) require the
zone maintainer's consent, so they are applied by the person in technical
control of the relevant part of the name space. At best it's the protocol
that is 'cheated', not the user.
Looking at this as a protocol analyst, how can the receiver
distinguish between an answer that is generated by the authoritative
source (whether a "true" answer or an obfuscated answer or an
otherwise synthesized answer) or is generated (usually synthesized)
by an interloper?
In the base DNS protocol, it can't reliably do so despite RFC 2181's
trustworthiness measures. That's why DNSSEC was defined. Three
times, repeatedly so in response to adoption experiences. And maybe
a fourth time (NEC3).
What else can the IETF do? Can the IETF force adoption of it's
products? Can it penalize those that operate in ways not imagined at
the start?
Authenticated denial _is_ a technical issue. See keyword in the last line
of the first quote.
I'm not sure what is meant by that...I know I've had arguments for
authenticated denial with those that oppose it as "too much work."
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Secrets of Success #107: Why arrive at 7am for the good parking space?
Come in at 11am while the early birds drive out to lunch.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf