--- Begin Message ---
> On May 29, 2020, at 2:29 AM, Shane Kerr <sh...@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
smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
