michael orlitzky

haeredes

get it

Release: haeredes-0.5.4.tar.gz
Browse source: gitweb
Clone it: git clone https://gitweb.michael.orlitzky.com/haeredes.git

What is it?

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.

Usage

user $ haeredes [OPTIONS] [DELEGATES] <input>

Normalization

By default, domain/hostnames given will be normalized in two ways:

All names will be lowercased.
All names will have a trailing dot (the DNS root) appended if one is not present. This can be controlled with the --no-append-root flag.

Query Results

When Haeredes makes a query for an MX record, the result is parsed from the answer section of the response. This is straightforward.

For NS records, however, there are two sections that may contain results. If you query the authoritative nameservers for example.com, they will return the response in the answer section, as with MX records:

user $ dig +short @a.iana-servers.net example.com NS
b.iana-servers.net.
a.iana-servers.net.

However, if you ask a root server, they will return the response in another section, called authority. The answer section is empty:

user $ dig +short @a.gtld-servers.net example.com NS

We have to request the authority section explicitly:

user $ dig +noall +authority @a.gtld-servers.net example.com NS
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.

Given Haeredes' use case, it is useful to combine the two. You can query a root server to check the registrar data, or a recursive resolver to check the data on the authoritative nameservers.

So that's what we do. In NS mode, Haeredes will check both the answer and authority sections for results.

Parallel Queries

Haeredes can use multiple threads to perform its queries. It will use a number of threads equal to the number of processors available to the GHC runtime. This can be changed with the +RTS -N flag. For example, to use 10 threads,

user $ haeredes [OPTIONS] [DELEGATES] +RTS -N10

DNS Errors

There are three types of DNS errors that can occur:

Timeouts. If the query times out, we don't get an answer back. The timeout can be adjusted with the --timeout flag.
Sequence number mismatches. Every DNS query is sent with a sequence number; if the response has a different sequence number than the one we sent, something is wrong (foul play, or a bug somewhere in the stack).
Unexpected RDATA. If we ask for an A record, we expect to get a response for an A record. If we get something else—well, something went wrong.

Haeredes is designed to ignore these errors. A timeout or bad response to a query is not an indication that something is wrong with the DNS for the supplied domains. There might be something else wrong with your (caching/recursive) DNS infrastructure, but it isn't one of the problems that Haeredes is designed to detect.

Options

--no-append-root, -n: Don't append a trailing dot to any DNS names. If you know what you're doing, this can be used to check relative results. Otherwise, it will probably just lead to false positives.
--server, -s: Use the given DNS server rather than the resolvers listed in /etc/resolv.conf. Either an IP address or a hostname will work.

Examples

Make sure example.com has the expected name servers, [ab].iana-servers.net:
user $ echo "example.com" | haeredes a.iana-servers.net b.iana-servers.net
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.
user $ echo "example.com" | haeredes --no-append-root a.iana-servers.net b.iana-servers.net
Domain "example.com" delegates somewhere else: "a.iana-servers.net." "b.iana-servers.net."
Check orlitzky.com against the expected name servers, using a root nameserver (this checks the registrar configuration):
user $ echo "orlitzky.com" | haeredes --server d.gtld-servers.net dns1.viabit.com
Domain "orlitzky.com." delegates somewhere else: "dns2.viabit.com."
Check a nonexistent domain (we provide no delegates, since we know .doesnt-exist will not be delegated):
user $ echo "foo.doesnt-exist" | haeredes
Domain "foo.doesnt-exist." not delegated.
Set the timeout to one second, and query a nonexistent nameserver. This should result in a timeout, which will be ignored per the discussion in DNS Errors.
user $ echo "example.com" | haeredes -t 1 -s 10.1.46.12 ns1.example.com

Requirements

All of the software dependencies are listed in the haeredes.cabal file. Just use cabal to build it.

Installation

Cabal handles the build, so do whatever you normally do to install cabal packages. If you just want to install it for your user,

user $ runghc Setup.hs configure --user
user $ runghc Setup.hs build
user $ runghc Setup.hs install

should do it.

How to report bugs

Email them to me at michael@orlitzky.com.