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?
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?
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. 😉)
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.
Thanks again for the transparency and keep up the good work! 😆
--
Shane
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
