On Sun, 12 Mar 2017, Dave Crocker wrote:
On 3/12/2017 4:23 PM, Paul Wouters wrote:
I do not want to adopt it unmodified
as informational RFC for running existing code.
You do not want the IETF to document existing practice?
Really?
There is a fine line between "bringing existing things to IETF to
standardize" and "bringing existing things to IETF to document".
The draft breaks DNSSEC. In its current form it would not have moved
forward if this work had been done from the start at the IETF. We would
have asked the authors to come up with a modified solution that does
not break DNSSEC. So documenting it now after the fact as RFC basically
bypasses the IETF purposefully.
I have proposed a method that would not change the RPZ response for a
non-DNSSEC client, but would add data for DNSSEC capable clients to be
notified the DNSSEC data was modified (and possibly state why) giving
DNSSEC capable clients a method to act differently, knowing the data was
changed for a reason and is not simply a DNS spoofing attack. It can be
added without breaking existing deployments. If the authors aren't willing
to do this, why should IETF rubberstamp a DNS protocol that breaks DNSSEC?
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
