The "no GLUE" warning occurs when DNS resolvers can't find accompanying A records for your nameservers during NS record lookups. While not technically an error, it forces additional DNS lookups that can impact resolution time.

Many administrators believe simply having A records in their zone file is sufficient:

ns1.example.com.    3600    IN    A    192.0.2.1
ns2.example.com.    3600    IN    A    192.0.2.2
example.com.        3600    IN    NS   ns1.example.com.
example.com.        3600    IN    NS   ns2.example.com.

However, these records must also exist in the parent zone (typically your domain registrar's DNS).

For authoritative nameservers under your own domain (e.g., ns1.example.com):

1. Add glue records at your domain registrar
2. Verify propagation with dig:

dig +trace example.com NS
dig @8.8.8.8 ns1.example.com A

For BIND configurations, ensure both forward and reverse zones are properly set:

// named.conf
zone "example.com" {
    type master;
    file "/etc/bind/db.example.com";
};

zone "2.0.192.in-addr.arpa" {
    type master;
    file "/etc/bind/db.192.0.2";
};

With corresponding zone files:

;; db.example.com
@       IN      SOA     ns1.example.com. admin.example.com. (
                        2023081501 ; serial
                        3600       ; refresh
                        900        ; retry
                        604800     ; expire
                        86400 )    ; minimum
        IN      NS      ns1.example.com.
        IN      NS      ns2.example.com.
ns1     IN      A       192.0.2.1
ns2     IN      A       192.0.2.2

Use these diagnostic commands:

# Check glue record existence
whois example.com | grep "Name Server"
# Verify authoritative response
dig @a.gtld-servers.net example.com NS
# Check actual resolution path
dig +trace example.com

For AWS Route 53, create hosted zones for both domain and subdomains used as nameservers. In Google Cloud DNS, ensure you create corresponding A records in both zones.

Remember that glue record updates may take up to 48 hours to propagate globally due to TTL caching at various DNS hierarchy levels.

When setting up custom nameservers, you might encounter a situation where DNS lookup tools report "GLUE was not sent" despite having proper A records. This occurs when your authoritative nameserver responds with NS records but doesn't include the corresponding A records (GLUE) in the additional section of the DNS response.

The issue manifests when:

dig example.com NS

Returns only NS records without their IP addresses in the ADDITIONAL SECTION. Here's a proper response should look like:

;; ANSWER SECTION:
example.com.        3600    IN      NS      ns1.example.com.
example.com.        3600    IN      NS      ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.    3600    IN      A       192.0.2.1
ns2.example.com.    3600    IN      A       192.0.2.2

For BIND (named.conf)

Ensure your zone file includes both NS and A records:

zone "example.com" {
    type master;
    file "/etc/bind/db.example.com";
};

// In db.example.com:
@       IN      NS      ns1.example.com.
@       IN      NS      ns2.example.com.
ns1     IN      A       192.0.2.1
ns2     IN      A       192.0.2.2

For PowerDNS

INSERT INTO records (domain_id, name, type, content, ttl) VALUES
(1, 'example.com', 'NS', 'ns1.example.com', 3600),
(1, 'example.com', 'NS', 'ns2.example.com', 3600),
(1, 'ns1.example.com', 'A', '192.0.2.1', 3600),
(1, 'ns2.example.com', 'A', '192.0.2.2', 3600);

After making changes, verify with:

dig +nocmd +nocomments +nostats example.com NS

Check for both the NS records and corresponding A records in the output.

For top-level domains (TLDs), you must also register GLUE records with your domain registrar. This typically involves:

1. Logging into your domain registrar control panel
2. Navigating to DNS settings
3. Adding "Host records" for your nameservers

• Ensure TTL values are sufficiently high (minimum 3600 seconds)
• Verify that NS and A records use fully qualified domain names (FQDNs)
• Check for trailing dots in zone files (ns1.example.com. vs ns1.example.com)

Remember that DNS changes may take up to 48 hours to propagate globally, though typically much faster with modern DNS systems.