From 355358eed85fff2f06a3ccbb2c2d259845134fc2 Mon Sep 17 00:00:00 2001 From: Michael Orlitzky Date: Sat, 27 Jul 2013 14:08:47 -0400 Subject: [PATCH] Add a man page, and add a description to the cabal file. --- doc/man1/haeredes.1 | 75 +++++++++++++++++++++++++++++++++++++++++++++ haeredes.cabal | 60 +++++++++++++++++++++++++++++++++++- 2 files changed, 134 insertions(+), 1 deletion(-) create mode 100644 doc/man1/haeredes.1 diff --git a/doc/man1/haeredes.1 b/doc/man1/haeredes.1 new file mode 100644 index 0000000..facf5cc --- /dev/null +++ b/doc/man1/haeredes.1 @@ -0,0 +1,75 @@ +.TH haeredes 1 + +.SH NAME +haeredes \- Confirm delegation of NS and MX records. +.SH SYNOPSIS + +\fBhaeredes\fR [\fIOPTIONS\fR] [\fIDELEGATES\fR] +.SH INPUT +.P +A list of domains, separated by whitespace. +.SH OUTPUT +.P +A list of domains which don't have the supplied (expected) delegates +listed as their NS/MX records. +.SH DESCRIPTION +.P +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. +.P +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. +.P +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. +.P +Haeredes can alert administrators when NS/MX records are changed. +.SH OPTIONS + +.IP \fB\-\-server\fR,\ \fB-s\fR +Use the given DNS server rather than the resolvers listed in +/etc/resolv.conf. +.SH EXAMPLES + +.IP \[bu] 2 +Make sure example.com has the expected name servers, +[ab].iana-servers.net: + +.nf +.I $ haeredes a.iana-servers.net b.iana-servers.net <<< \(dqexample.com\(dq +.fi +.IP \[bu] +Check orlitzky.com against the expected name servers, using +d.gtld-servers.net: + +.nf +.I $ haeredes --server 199.7.91.13 dns1.viabit.com dns2.viabit.com \\\\ +.I " <<< \(dqorlitzky.com\(dq" +.fi +.IP \[bu] +Check orlitzky.com against only one of the expected two nameservers: + +.nf +.I $ haeredes dns1.viabit.com <<< \(dqorlitzky.com\(dq +Domain \(dqorlitzky.com.\(dq delegates somewhere else: \ +\(dqdns2.viabit.com.\(dq +.fi +.IP \[bu] +Check a nonexistent domain (we provide no delegates, since we +know .invalid will not be delegated): + +.nf +.I $ haeredes <<< \(dqexample.invalid\(dq +Domain \(dqexample.invalid.\(dq not delegated. +.fi +.SH BUGS +.P +Send bugs to michael@orlitzky.com. diff --git a/haeredes.cabal b/haeredes.cabal index 2463a59..e855984 100644 --- a/haeredes.cabal +++ b/haeredes.cabal @@ -8,9 +8,63 @@ license-file: doc/LICENSE homepage: http://michael.orlitzky.com/code/haeredes.php bug-reports: mailto:michael@orlitzky.com category: DNS, Utils +build-type: Simple +extra-source-files: + doc/man1/haeredes.1 synopsis: Confirm delegation of NS and MX records. -build-type: Simple +description: + 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. + . + /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\" + @ + . + 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 .invalid will not be delegated): + . + @ + $ haeredes <<< \"example.invalid\" + Domain \"example.invalid.\" not delegated. + @ executable haeredes build-depends: @@ -27,6 +81,10 @@ executable haeredes hs-source-dirs: src/ + other-modules: + CommandLine + DNS + ghc-options: -Wall -fwarn-hi-shadowing -- 2.43.2