Many administrators encounter this specific DNS validation warning when running named-checkzone:

zone example.com/IN: NS 'ns.example.com' has no address records (A or AAAA)
zone example.com/IN: NS 'ns2.example.com' has no address records (A or AAAA)

The confusing part? Your forward zone clearly contains the required A records:

ns      IN      A       192.168.1.109
ns2     IN      A       192.168.1.109

The validator isn't checking your forward zone - it's examining the reverse zone's requirements. According to RFC 1912 section 2.1:

• Every NS record in a zone must have corresponding A/AAAA records
• These glue records must exist in the same zone file being validated

Your reverse zone declares NS records but lacks their IP mappings:

@       IN      NS      ns.example.com.
@       IN      NS      ns2.example.com.

Add these to your reverse zone file:

ns.example.com.    IN      A       192.168.1.109
ns2.example.com.   IN      A       192.168.1.109

Or for IPv6 environments:

ns.example.com.    IN      AAAA    2001:db8::1
ns2.example.com.   IN      AAAA    2001:db8::2

Here's a properly configured reverse zone for both IPv4 and IPv6:

$TTL    604800
@       IN      SOA    ns.example.com. admin.example.com. (
                            2024010101 ; Serial
                            86400      ; Refresh
                            3600       ; Retry
                            2419200    ; Expire
                            300 )      ; Negative Cache TTL

; Name servers
@       IN      NS      ns.example.com.
@       IN      NS      ns2.example.com.

; Glue records
ns      IN      A       192.168.1.109
ns2     IN      A       192.168.1.110
ns      IN      AAAA    2001:db8::1
ns2     IN      AAAA    2001:db8::2

; PTR records
109     IN      PTR     ns.example.com.
110     IN      PTR     ns2.example.com.

After making changes:

1. Increment the serial number
2. Reload your DNS server:

   rndc reload example.com

3. Validate with:

   named-checkzone example.com /var/named/example.com.rev

When setting up authoritative DNS servers, one of the most common validation errors occurs when BIND's named-checkzone complains about missing address records for nameservers. Let's examine why this happens even when you think you've properly configured everything.

The specific error we're seeing:

zone example.com/IN: NS 'ns.example.com' has no address records (A or AAAA)
zone example.com/IN: NS 'ns2.example.com' has no address records (A or AAAA)

This indicates that while your zone file declares NS records, the nameserver addresses themselves aren't properly resolvable within the same zone.

Looking at the example zone file provided:

@       IN      NS      ns.example.com.
@       IN      NS      ns2.example.com.
ns      IN      A       192.168.1.109
ns2     IN      A       192.168.1.109

The problem here isn't that the A records are missing - they're present. The issue is with name resolution context. The NS records use fully qualified domain names (FQDNs), while the A records use relative names.

Here's how to correctly structure your zone file:

$TTL 604800
@ IN SOA ns.example.com. admin.example.com. (
    2024021401 ; Serial
    604800     ; Refresh
    86400      ; Retry
    2419200    ; Expire
    604800 )   ; Negative Cache TTL

; Name servers - must be FQDNs
@ IN NS ns.example.com.
@ IN NS ns2.example.com.

; Base domain records
@ IN A 192.168.1.109
example.com. IN A 192.168.1.109

; Nameserver A records - must be FQDNs
ns.example.com. IN A 192.168.1.109
ns2.example.com. IN A 192.168.1.109

; Other records
mail IN A 192.168.1.109
www IN A 192.168.1.109

After fixing your zone file, verify with these commands:

named-checkzone example.com /etc/bind/zones/example.com.zone
dig ns.example.com A
dig ns2.example.com A

For reverse zones, ensure your PTR records match:

109 IN PTR ns.example.com.
109 IN PTR ns2.example.com.

• Mixing relative and absolute names in NS/A records
• Forgetting to increment the serial number after changes
• Not waiting for TTL expiration when testing changes
• Missing trailing dots in FQDNs

For domains where your nameservers are subdomains (like ns.example.com), you may need to provide glue records at your domain registrar. These are A/AAAA records that help bootstrap the DNS resolution process.