On Wed, 20 Feb 2019, Mark Andrews wrote:
Think disaster recovery and promoting a slave to master. You have to
transfer state between servers. You can transfer it in band or out of
band. If you transfer it out of band you need to invent / specify
yet-another-protocol to do it on top of specifying when records need to
be removed.
That is not very convincing to me. disaster recovery scenarios seem to
be solvable by proper admin and by the daemon properly writing state to
disk which can be saved off-site. It also seems a rather rare occurance.
If the primary does DNSSEC, you also have to transfer private keys and
that isn't happening in-band either. So I'm not convinced by the
promotion of secondary to master either.
It also seems these two use cases are mostly solved if you keep your
dynamic update clients within their own zone, which I think is pretty
normal for DHCP based nodes that can make up their own hostname anyway
and shouldn't be able to muck with real static records or apex records.
Paul
On 20 Feb 2019, at 9:26 am, Paul Wouters <[email protected]> wrote:
I have read the document.
I have a question about:
A zone administrator may
want to enforce a default lifetime for dynamic updates (such as the
DHCP lease lifetime) or the DNS Update may contain a lifetime using
an EDNS(0) Update Lease option [I-D.sekar-dns-ul].
This seems a local policy and local implementation issue only.
However, this
lease lifetime is not communicated to secondary servers and will not
endure through server software restarts.
Why does the secondary server need to know the lease lifetime? Only the
primary needs to know this because it will need to purge the records and
update the appropriate DNSSEC entries, something the secondary cannot do
anyway? In fact, Section 8 agrees with me:
A secondary server MUST NOT expire the records in a zone it maintains
covered by the TIMEOUT resource record and it MUST NOT expire the
TIMEOUT resource record itself when the last record it covers has
expired. The secondary server MUST always wait for the records to be
removed or updated by the primary server.
So why is the TIMEOUT record needed? If the secondary argument is
gone, the only argument left from the Introduction is server software
restart. Which seems to me to be an application issue and not a protocol
issue?
As others pointed out, introducing SHA3 into the DNS right now is not
appropriate.
I see a use for clients telling the dns update server what the maximum
possibly lifetime can be, so it can go and perform a delete request on
behalf of vanished clients. But again I don't see this as a protocol
issue needing a TIMEOUT RRTYPE ?
Did I miss anything?
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
