On 04/23/2013 02:20 PM, Wes Hardaker wrote:
Doug Barton <[email protected]> writes:
... thus creating a support problem when the customer checks their CDS
record, sees that it is "valid," and then doesn't understand why the
parent won't accept it.
Yes, but a CDS management tool wouldn't.
Yeah, I get that. What I'm saying is, that's the problem.
It's a specific use case. The
above is like saying "my MX record validates with DNSSEC so it must be
valid", even though the label doesn't point to a real name.
No, the cases you describe bear only a surface similarity (they both
have RRSIGs). Whereas given that CDS is a record specifically designed
to signal something to the parent _about DNSSEC_, the fact that (from
the customer's perspective) the DNSSEC is valid would cause confusion as
to why the parent won't accept it.
I realize that you and I understand the fine distinction you are
attempting to make, my point is that customers won't.
It is not
the job of a validator to judge how the data itself will be used and
guess at any additional constraints that may be placed on it. A CDS
record, just like an MX record, can be valid but not usable.
I would argue that as a matter of protocol clarity it shouldn't be
possible for a signer to create a RRSIG that the intended consumer of
that signature will discard as ... inappropriate(?) in spite of the fact
that it validates just fine. But from the standpoint of having been in
the registrar business in the past, I would not want to have to explain
this problem to a customer (not to mention the revenue-destroying nature
of any customer support call in the first place).
[and don't get me started on CNAME breakage in the wild]
https://dougbarton.us/DNS/MX.html :)
And to say that we don't have that elsewhere and this is new isn't
correct either. 5011 has a number of similar semantics. Consider the
revoke bit for the simplest and closest to this case.
Perhaps you could elaborate? It's not clear to me how that case
applies in the child -> parent signalling direction.
A revoke bit is only considered "actionable" (IE, revoke it from your
trust storage) if it was signed by the same key that produced the key
with the revoke bit turned on. IE, you can have a "valid" key with the
revoke bit set, but you shouldn't actually act on it because it wasn't
signed by the key itself. See RFC5011, section 2.1, last sentence for
the quick summary.
The key would still be considered valid by a validator but you shouldn't
act on the knowledge of the data in the key.
Sorry, I don't regard that situation as equivalent at all. I understand
your reasoning, I just don't agree with it.
Doug
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
