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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf