Nameserver hostnames are valid

The data in an NS record is a domain name, not an address. This check reads every name in the set and asks three things of it: that it is a name and not an IP literal, that it is not a CNAME, and that it resolves to at least one address that is routable on the public internet.

An IP literal in an NS record is not interpreted as an address by anything — it is read as a name, and 192.0.2.53 is a perfectly legal hostname that resolves to nothing. A CNAME as an NS target is forbidden by RFC 2181 §10.3, and implementations vary in whether they follow one, so it produces exactly the "works for some people" fault this report exists to surface.

A nameserver on a private or reserved address is the more interesting failure. It cannot be reached from the internet, so it is a lame server by another route — and it is almost always a leak: an internal split-horizon zone published to the outside world, telling anyone who asks how the network behind it is numbered.

Publish A and AAAA records at the nameserver hostnames themselves and point the NS records at those names. Where the nameservers live inside the zone they serve, the addresses also have to be registered as glue at the registrar — the glue check in this report covers that half.

Replace an IP literal with a real hostname. If the server has no name, give it one; a name under your own domain is fine as long as the glue is in place.

For a private address, work out which zone leaked rather than editing the record. The usual cause is one zone file served to both an internal and an external audience, and the next internal change will republish it unless the views are split.