[dns-operations] New addresses for b.root-servers.net

[Viktor Dukhovni]

On Sun, Jun 04, 2023 at 08:44:19AM +0100, Matthew Richardson via dns-operations wrote:

> Without wishing to ask a really stupid question, is there any reason
> why root-servers.net is not DNSSEC signed?
> 
> Would signing it provide any additional security?

For the glue records to be beneficially signed, two things would likely
have to happen:

- The current 13 names would probably have to become a single name with
  13 records, so that the combined A and AAAA RRsets would incur just 2
  additional signatures, rather than 26 signatures (too many even after
  a potential rollover of the root zone KSK/ZSK to P-256).

- Resolvers would have to expect RRSIGs for additional records!

    https://datatracker.ietf.org/doc/html/rfc4035#section-3.1.1

   o  When placing a signed RRset in the Answer section, the name server
      MUST also place its RRSIG RRs in the Answer section.  The RRSIG
      RRs have a higher priority for inclusion than any other RRsets
      that may have to be included.  If space does not permit inclusion
      of these RRSIG RRs, the name server MUST set the TC bit.

   o  When placing a signed RRset in the Authority section, the name
      server MUST also place its RRSIG RRs in the Authority section.
      The RRSIG RRs have a higher priority for inclusion than any other
      RRsets that may have to be included.  If space does not permit
      inclusion of these RRSIG RRs, the name server MUST set the TC bit.

   o  When placing a signed RRset in the Additional section, the name
      server MUST also place its RRSIG RRs in the Additional section.
      If space does not permit inclusion of both the RRset and its
      associated RRSIG RRs, the name server MAY retain the RRset while
      dropping the RRSIG RRs.  If this happens, the name server MUST NOT
      set the TC bit solely because these RRSIG RRs didn't fit.

Note that while authoritative servers MUST (strive to) include RRSIGs also
in the additional section, if space does not permit, they can omit them
*without* setting TC=1.

The upshort is that presently resolvers need to be prepared to process
additional records sans RRSIGs, and, therefore, RRSIGs for additional
records don't add much security value, an attacker can always strip
them and the response is still valid.

Since glue A/AAAA records go in the additional section, signing them
does not protect the resolver against (infra) cache poisoning.  Their
signatures could obviate later explicit DO=1 queries for the A/AAAA
records in question, but can't really help with priming unless resolvers
special-case the root zone after we've all learned that it will be
signed, and will return signed glue.

Only resolvers that promptly revalidate the A/AAAA records via explicit
queries for each nameserver will benefit from signed root nameserver
IP RRsets.  And to make this more efficient, we'd want a single root
NS host:

    a-m.root-zone. IN A ...
    ...
    a-m.root-zone. IN RRSIG A ...
    a-m.root-zone. IN AAAA ...
    ...
    a-m.root-zone. IN RRSIG AAAA ...

-- 
    Viktor.