> On 27 Feb 2019, at 6:46 am, Bill Woodcock <wo...@pch.net> wrote:
>
>
>
>> On Feb 26, 2019, at 9:15 AM, Jacques Latour <jacques.lat...@cira.ca> wrote:
>> DNSSEC should of never been part of the domain registration process, it was
>> because we didn’t have the CDS/CDNSKEY channel to automated the DS
>> maintenance and bootstrap. But if you keep DNSSEC maintenance outside the
>> registrar control then it can be effective tool (amongst other) in
>> identifying hijacks. Taking away he ability of the bad actors to disable
>> DNSSEC via registrar control panel.
>> This is what happens when you have all your eggs in one basket and you loose
>> the keys to your kingdom.
>
> Agreed. There’s absolutely no reason for registrars to be involved with DS
> records of zones they’re not signing. And, for the same reason, there’s no
> reason for them to be involved with NS records, either, after an initial
> bootstrap.
>
> -Bill
Using https://datatracker.ietf.org/doc/draft-andrews-dnsop-update-parent-zones/
with TSIG or SIG(0)
would have prevented this with TFA for updating the credentials required to
authenticate the updates.
The method works with either TSIG or SIG(0) and you can have specific keys to
update DS records or
NS records and glue records. You can’t MITM TSIG or SIG(0). TSIG and SIG(0)
have time limited replay
windows. This is just bolting together tried and proven technology with
database lookups to determine
which registrar authenticates the update.
Nameservers already forward UPDATE messages to the primary server for
processing using TSIG and
SIG(0) between the UPDATE client and the primary server. The key name is in
the clear so it is
easy to use that to select how to redirect the update. This also works with
existing DNS servers
when EPP is not thrown into the mix. It also doesn’t require DNSSEC to be
deployed.
Tools to do this have been shipped with nameservers since UPDATE, TSIG and
SIG(0) were invented.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
