Haeredes is primarily useful for ISP network administrators.
Customers will occasionally decide to switch hosts without alerting
the current host; this can cause two problems:
With NS records, the previous host (at the very least) keeps
hosting a DNS zone that does nothing. If that host uses their
authoritative nameserver as a caching lookup server as well, it
may return incorrect results to queries about the domain in
question.
For MX records, the situation is slightly worse. Most mail servers
will immediately accept mail for which the server thinks it is the
ultimate destination. If a mail server is configured as the
destination for a domain, but it is not the MX for that domain,
then mail submitted to that server may possibly be lost. It is
therefore important to remove domains from the old mail host as
soon as the MX record is changed.
Haeredes can alert administrators when NS/MX records are changed. More
detail can be found in the man page.
Examples:
Make sure example.com has the expected name servers,
[ab].iana-servers.net:
$ haeredes a.iana-servers.net b.iana-servers.net <<< "example.com"
If you use --no-append-root and your nameservers are rooted, you
must remember to supply the trailing dot yourself. Otherwise, you'll
get false positives.
$ haeredes --no-append-root
a.iana-servers.net b.iana-servers.net
<<< "example.com"
Domain "example.com" delegates somewhere else: "b.iana-servers.net." "a.iana-servers.net."
Check orlitzky.com against the expected name servers, using
d.gtld-servers.net:
$ haeredes --server 199.7.91.13 dns1.viabit.com dns2.viabit.com
<<< "orlitzky.com"
Check orlitzky.com against only one of the expected two nameservers:
$ haeredes dns1.viabit.com <<< "orlitzky.com"
Domain "orlitzky.com." delegates somewhere else: "dns2.viabit.com."
Check a nonexistent domain (we provide no delegates, since we
know .bar will not be delegated):
$ haeredes <<< "foo.bar"
Domain "foo.bar." not delegated.
