Glue records are A records that are associated with NS records to provide "bootstrapping" information to the nameserver.  

For example: podunk.xx. in ns ns1.podunk.xx. in ns ns2.podunk.xx. ns1.podunk.xx. in a 1.2.3.4 ns2.podunk.xx. in a 1.2.3.5 Here, the A records are referred to as "Glue records". Glue records are required only in forward zone files for nameservers that are located in the subdomain of the current zone that is being delegated.
You shouldn't have any A records in an in-addr.arpa zone file (unless you're using RFC 1101-style encoding of subnet masks). If your nameserver is multi-homed (has more than one IP address), you must list all of its addresses in the glue to avoid cache inconsistency due to differing TTL values, causing some lookups to not find all addresses for your nameserver. Some people get in the bad habit of putting in a glue record whenever they add an NS record "just to make sure".
Having duplicate glue records in your zone files just makes it harder when a nameserver moves to a new IP address, or is removed.
You'll spend hours trying to figure out why random people still see the old IP address for some host, because someone forgot to change or remove a glue record in some other file.
Newer BIND versions will ignore these extra glue records in local zone files. Older BIND versions (4.8.3 and previous) have a problem where it inserts these extra glue records in the zone transfer data to secondaries.
If one of these glues is wrong, the error can be propagated to other nameservers.
If two nameservers are secondaries for other zones of each other, it's possible for one to continually pass old glue records back to the other.
The only way to get rid of the old data is to kill both of them, remove the saved backup files, and restart them.
Combined with that those same versions also tend to become infected more easily with bogus data found in other non-secondary nameservers (like the root zone data).


Source: RFC1912
Was this answer helpful? 2 Users Found This Useful (3 Votes)