Hi Wes,
On 6/9/23 19:43, Wes Hardaker wrote:
For lame delegations, I think discussion is needed further. It's
unclear from the draft at the moment (and I think it needs to be very
clear) about what to do with servers that are lame. It discusses
whether or not CDS/CDNSKEY/CSYNC are supposed to do when the server is
unresponsive, but not with respect to other errors or situations and I
think some clarity would be helpful here.
I think it's important that we deal with the multi-signer case, and that
point is very clear (and correct). But we also do need to be able, as a
child, to update a parent's records when a nameserver has gone offline
or stopped responding appropriately. This is very different than one NS
taking over -- IE, I agree that this is the principle thing to defend
against. But we also need to be able to efficiently recover from
operational situations.
Nameservers that went offline are taken care of because the mechanism only
requires that the received responses are consistent (not that responses are
received from all nameservers).
Lame delegations and otherwise inappropriately responding nameservers are indeed
problematic, and I'm looking forward to explore more. However, my current gut feeling is
that such kinds of mess-ups cannot sufficiently reliably be detected and dealt with
automatically. For example, you cannot reliably detect the cause of REFUSED (including
"expired from nameserver" during provider change, or on-wire manipulation
suppressing a conflicting response, or whatever else).
As such, I'd think that the goal of the document should be automation of the
"proper" case, with broken cases continuing to require manual intervention.
Nits as long as I was reading it with a red pen:
- Introduction: CSYNC updates both NS *and glue* records
Section 3.2 mentions "data records" and lists NS as an example -- but yes, that
could be more clear. I'll make a note.
- Lame delegations: "on the other hand, if the delegation is not
protected by DNSSEC," -- I don't understand this because all three
record types require DNSSEC to be in place and valid for any of the
records to work. No changes should ever be permitted without both
present and valid signatures. Maybe I'm misunderstanding the
paragraph though.
RFC 8078 Section 3.3 allows turning on DNSSEC without a pre-existing chain of
trust.
An attacker how hijacked on the nameserver hostnames (after its domain expired)
can exploit this mechanism. The delay prescribed there doesn't help in the
situation at hand. If consistency across NS is not checked, you'll just have to
wait long enough until the parent hits the attacker's nameserver several days
in a row, and then DNSSEC is enabled.
- Section 3 is likely where service failure / error conditions need to
be discussed more fully (IMHO).
Ack.
- 3.2 CSYNC: There are a few things to check here and all the servers
should be consistent with all the records for changes to be made: the
CSYNC record itself, the NS records and the glue records. (or since
CSYNC is generic: the CSYNC record and any records it is referring
to). IE, the CSYNC records could be equal but the NS records need to
be checked for equivalence at each server too.
This is what the last paragraph of Section 3.2 is trying to say, but apparently
it's not clear enough. I'll make a note.
Thanks for the feedback.
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
