The development version can be found in the haeredes git repository. Official releases can be found on the haeredes hackage page.
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:
Haeredes can alert administrators when NS/MX records are changed.
user $ haeredes [OPTIONS] [DELEGATES] <input>
By default, domain/hostnames given will be normalized in two ways:
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
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.
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
-N flag. For example, to use 10 threads,
user $ haeredes [OPTIONS] [DELEGATES] +RTS -N10
There are three types of DNS errors that can occur:
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.
user $ haeredes a.iana-servers.net b.iana-servers.net <<< "example.com"
user $ 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."
user $ haeredes --server d.gtld-servers.net dns1.viabit.com <<< "orlitzky.com"
Domain "orlitzky.com." delegates somewhere else: "dns2.viabit.com."
user $ haeredes <<< "foo.bar"
Domain "foo.bar." not delegated.
user $ haeredes -t 1 -s 10.1.46.12 ns1.example.com <<< "example.com"
All of the software dependencies are listed in the haeredes.cabal file. Just use cabal to build it.
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.
Email them to me at firstname.lastname@example.org.