Hi,
I'm not sure if this helps the discussion, but Knot DNS implements "DS
push", an automated DDNS update updating the DS (not NS) at parent.
It's mostly intended for single-organization parent-child relations,
where TSIG (or soon DDNSoQ) can be configured easily.
Libor
Dne 25. 10. 23 v 17:30 Johan Stenstam napsal(a):
Hi Joe,
On 25 Oct 2023, at 11:32, Joe Abley <jab...@strandkip.nl> wrote:
On 25 Oct 2023, at 10:10, Johan Stenstam
<johan.stenstam=40internetstiftelsen...@dmarc.ietf.org> wrote:
So now there’s a new draft, that further extends the same core idea (locate the
target for the information being sent via a DNS lookup in the parent zone).
However, the new draft (draft-johani-dnsop-delegation-mgmt-via-ddns-00)
proposes that instead of sending a NOTIFY (triggering a scan from the
recipient) the child sends a DNS UPDATE containing the exact change with a
signature that can be verified by the recipient.
I am not at all familiar with SIG(0), so bear with me. What is the key
distribution mechanism for the DNS UPDATE originator's public key? RFC 2931
suggests an unsigned KEY RR, I think?
My answer is “whatever mechanism the child and parent is using today for
communicating critical information like that”. The thing here is that I do not
primarily expect the TLD registries to change from the current path of either
no automation of synchronisation of delegation information OR running a CDS
(and perhaps CSYNC) scanner.
The problem I have with that is that this leaves out major parts of the
namespace. I.e. I want a mechanism that works for the University of Foobar to
automate the delegation information for a ~100 departments. I want a mechanism
that works for the Stockholm Health Care district to deal with hundreds of
hospitals, care givers and other parts of the local health care infora
structure. Etc. Neither of those have DNS as a major focus, DNSSEC even less
and they are extremely unlikely to run any CDS and/or CSYNC scanners in the
foreseeable future.
So what do all these parents that are not registries use today? All sorts of
semi crappy mechanisms, from email, via webforms to various local APIs, etc.
All of these mechanisms have drawbacks, all have security issues and all of
them have a certain failure rate because there is manual labor involved.
I want to completely get rid of the manual part of maintaining existing
delegations and the proposal is to transport the public key to the parent in
any way that is acceptable to both child and parent. I don’t think an unsigned
KEY RR is a particularly attractive alternative, but I have nothing against a
DNSSEC signed KEY RR.
Johan
PS. In the case where the parent *is* a registry, and there are registrars then
I think an EPP extension for the submission of the public SIG(0) keys will work
just fine. But, as I said, that’s not my primary goal at this time.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
