Incorrect NSEC responses from Verisign root server instances

[Wessels, Duane]

On February 26, 2021 at ~1431 EST, Verisign was notified that some
of its root server instances were returning incorrect responses for
queries of type NSEC.  We identified the subset of instances affected
and took them out of service (as of ~1506 EST).  The remainder of
our systems are responding appropriately.

The NSEC resource record is used in some DNSSEC-signed zones to
provide proofs of non-existence.  In the normal process of iterating
and resolving domain names, validating recursive name servers do
not send queries of type NSEC.  However, an end-user of a recursive
name server may generate NSEC queries using custom software or
debugging tools, such as 'dig'. These queries are extremely rare
and infrequent in nature and the normal internet user would be
agnostic to this condition existing.

The incorrect responses from Verisign's root server instances
provided an empty owner name in the Authority section records of a
delegation response to the NSEC query.  The empty owner name
corresponds to the root label.  A recursive name server that processed
one of these incorrect responses could change its cached root NS
RRset, meaning that future queries to be resolved in the context
of the root zone could be sent to incorrect names servers which are
not authoritative for the root zone.

Verisign is in the process of patching affected systems, and rolling
out the new version, and bringing affected instances back into
service in accordance with established operational procedures.

Additionally, we expect this may bring some new attention to the
way in which authoritative name servers respond to queries of type
NSEC.  Some implementations respond with referrals, while others
respond with an NSEC RR in the Answer section.  Verisign will be
pleased to work with the community if there are ambiguities in the
relevant RFCs (e.g. 4035) that would benefit from clarification,
as current behavior beyond this subset of our name servers suggests.

Thank you to David Kinzel of Shaw Communications for bringing this to
our attention.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAABAgAGBQJgOaBzAAoJEGyZpGmowJiNJqoH/iQcOWk3eMBondU4qyWR8V+M
sGj61eugKxsj5oTRx8kdDDYqCGxxnvdDZrHqxN5aQlVuXePfwuA3bxne+Mm7Oluo
RH4lWfuLJntrIHD+AStxfthQZGUCUV/LwX/1wRje1+DbxoGUl5dStu/DV03ViNiO
V7SQJf7yxeTtw3Hsb4zrTL/r/gLhy1lXeG9VzW1NIDrLCd1JJQ82WRvWr0YDSEBh
PRHT6p89uzLzGnkAsmp0GlfZ1G5oia2Svc/YlKowbBG28Egmgmu5IrZcyXzltYgg
oLi/YD3HWAxpIvDFEIPLLbbwLKOGowdleKUYlQXNhewkrsH282SyOaewyjGXQX4=
=h364
-----END PGP SIGNATURE-----

-------------- 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/20210227/64caacf8/attachment.bin>