4 haeredes \- Confirm delegation of NS and MX records.
7 \fBhaeredes\fR [\fIOPTIONS\fR] [\fIDELEGATES\fR]
10 A list of domains, separated by whitespace.
13 A list of domains which don't have the supplied (expected) delegates
14 listed as their NS/MX records.
17 Haeredes is primarily useful for ISP network administrators. Customers
18 will occasionally decide to switch hosts without alerting the current
19 host; this can cause two problems.
21 With NS records, the previous host (at the very least) keeps hosting a
22 DNS zone that does nothing. If that host uses their authoritative
23 nameserver as a caching lookup server as well, it may return
24 incorrect results to queries about the domain in question.
26 For MX records, the situation is slightly worse. Most mail servers
27 will immediately accept mail for which the server thinks it is the
28 ultimate destination. If a mail server is configured as the
29 destination for a domain, but it is not the MX for that domain, then
30 mail submitted to that server may possibly be lost. It is therefore
31 important to remove domains from the old mail host as soon as the MX
34 Haeredes can alert administrators when NS/MX records are changed.
37 By default, domain/hostnames given will be normalized in two ways:
39 All names will be lowercased.
42 All names will have a trailing dot (the DNS root) appended if one is
43 not present. This can be controlled with the
44 \fB\-\-no\-append\-root\fR flag.
47 When Haeredes makes a query for an MX record, the result is parsed
48 from the \(dqanswer\(dq section of the response. This is
51 For NS records, however, there are two sections that may contain
52 results. If you query the authoritative nameservers for example.com,
53 they will return the response in the \(dqanswer\(dq section, as with
57 .I $ dig +short @a.iana-servers.net example.com NS
62 However, if you ask a root server, they will return the response in another section, called \(dqauthority\(dq. The \(dqanswer\(dq section is empty:
65 .I $ dig +short @a.gtld-servers.net example.com NS
68 We have to request the \(dqauthority\(dq section explicitly:
71 .I $ dig +noall +authority @a.gtld-servers.net example.com NS
72 example.com. 172800 IN NS a.iana-servers.net.
73 example.com. 172800 IN NS b.iana-servers.net.
76 Given Haeredes' use case, it is useful to combine the two. You can
77 query a root server to check the registrar data, or a recursive
78 resolver to check the data on the authoritative nameservers.
80 So that's what we do. In NS mode, Haeredes will check both the
81 \(dqanswer\(dq and \(dqauthority\(dq sections for results.
84 .IP \fB\-\-no\-append\-root\fR,\ \fB-n\fR
85 Don't append a trailing dot to any DNS names. If you know what you're
86 doing, this can be used to check relative results. Otherwise, it will
87 probably just lead to false positives.
90 .IP \fB\-\-server\fR,\ \fB-s\fR
91 Use the given DNS server rather than the resolvers listed in
92 /etc/resolv.conf. Either an IP address or a hostname will work.
96 Make sure example.com has the expected name servers,
97 [ab].iana-servers.net:
100 .I $ haeredes a.iana-servers.net b.iana-servers.net <<< \(dqexample.com\(dq
103 Check orlitzky.com against the expected name servers, using
104 a root nameserver (this checks the registrar configuration):
107 .I $ haeredes --server d.gtld-servers.net dns1.viabit.com dns2.viabit.com \\\\
108 .I " <<< \(dqorlitzky.com\(dq"
111 Check orlitzky.com against only one of the expected two nameservers:
114 .I $ haeredes dns1.viabit.com <<< \(dqorlitzky.com\(dq
115 Domain \(dqorlitzky.com.\(dq delegates somewhere else: \
116 \(dqdns2.viabit.com.\(dq
119 Check a nonexistent domain (we provide no delegates, since we
120 know .invalid will not be delegated):
123 .I $ haeredes <<< \(dqexample.invalid\(dq
124 Domain \(dqexample.invalid.\(dq not delegated.
128 Send bugs to michael@orlitzky.com.