rec: do not take root NSset authority updates from random packets

[Habbie]

Background:

• https://lists.dns-oarc.net/pipermail/dns-operations/2021-February/020924.html ('Broken A and J root responses')
• https://lists.dns-oarc.net/pipermail/dns-operations/2021-February/020927.html ('Incorrect NSEC responses from Verisign root server instances')

It looks like Recursor accepts the new root NSset from those bad responses. While this makes sense in terms of our whole implementation, and various words from RFC2181, I don't think it makes sense to accept 'authority updates' for the root NSset. Such updates would always fall into any of these 3 classes:

1. it's the root NSset we saw on the last prime
2. it's a new root NSset we will see on the next prime
3. it's garbage

Secondary to that, i wonder if we could/should be doing any DNSSEC validation on authority updates (in general, outside the root), and on our root priming.

[rgacogne]

At a very quick glance, it looks like:

• our sanitization code accepts these records (NS records in the authority section of a AA answer, neither NXDOMAIN nor NXQTYPE) ;
• we do validate these records when DNSSEC validation is enabled ;
• the record cache does not replace valid records with Bogus ones (rec: Keep a cached, valid entry over a fresher Bogus one #9817, backported to 4.4.x in rec: Backport 9817 to rec 4.4.x: Keep a cached, valid entry over a fresher Bogus one #9838 so it will be in 4.4.3).

It might make sense to add a special case to the sanitization code for the root NSset indeed.