[dns-operations] Disclosure of root zone TSIG keys

[Wessels, Duane]

> On May 29, 2020, at 2:29 AM, Shane Kerr <shane at time-travellers.org> wrote:
> 
> Duane,
> 
> I really appreciate this level of transparency, thank you.
> 
> This does make me think of a couple of questions.
> 
> 
> First, I assume that the main goal of TSIG is to prevent modification of the zone file(s) in transit, more than preventing access. The root zone is public, right?

That is correct.  There was a time when we did not have IP ACLs and TSIG was the only method of access control, but that is no longer the case.

> 
> Since the goal is to prevent modification, I guess the root server operators could fetch PGP signatures from the Internic server and verify the zone today. Do you know if there is any documentation covering the operational practices of the root server operators in this regard?

I'm not aware of any such documentation or of any operators that actually do that.

> 
> In the future, adding message digests (draft-ietf-dnsop-dns-zone-digest) to the zones and having both that and the DNSSEC signatures verified by root server operators before accepting a new version of the root zone would be a nice additional check. (Whoever thought of those digests seems really on-the-ball. 😉)

Yes, we would very much like to see ZONEMD advance so we can have that check.

> 
> 
> Second, while it is nice that there are IP-based whitelists protecting zone transfers, are there any requirements for IP's on the whitelists to use RPKI or other routing protections? Even if there are no requirements, does Verisign check RPKI if the root server operators *do* sign their routes? We know that there is BGP hijacking in the wild today, so using and encouraging secured routing seems reasonable to me.

Interesting you mention this.  We have been evaluating the pros and cons of RPKI publication for our number resources as well as origin validation for received routes.  While we are working on this and intend to fully implement RPKI given new dependencies it introduces we are being very deliberate and working closely with our carrier partners, etc.. to minimize the new risks it introduces.  More to come on that in the coming months.

Work is underway now to ensure that we monitor all the root zone distribution prefixes just as we monitor own prefixes (commercial and bespoke tools for routing system prefixes, attributes, and changes, IRR objects, and RPKI objects).  

DW

> 
> 
> Thanks again for the transparency and keep up the good work! 😆
> 
> --
> Shane


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4695 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20200529/33c45ff9/attachment.bin>