Known Bugs in Dlint 1.4.0
* Dlint reports error in some cases for when A rec's IP addr doesn't have a
PTR rec pointing back to the exact same name. This is not an error.
It should be a warning, at the most. Maybe make it optionally a warning.
There's many reasons now why people would want to use A recs with wrong
* Dlint checks the reverse records on your local machine's default nameserver.
(Dlint 1.3.1 and earlier asked forward-query zone's nameserver).
Neither solution seems right to me, we should determine the list of
authoritative name servers for the reverse domain name to do the query.
However doing so would slot down Dlint a _lot_.
Example: if dlint is linting zone "bbb.com" and the nameserver is ns.bbb.com
and sees the record "aaa.bbb.com. IN A 220.127.116.11", it wants to check for a
PTR record from the IP back to the domain name - what nameserver should it
query to do that? We should really figure out the zone of 18.104.22.168.in-addr.arpa.
and find the nameservers from that, and query _them_ for the PTR record
rather than asking your local host. But this would be very slow.
* There is some redundancy in checking for the illegal "#" character
(using the wrong comment symbol in zone files): the A and PTR records
occasionally will be checked twice, and can generate errors twice
(all RRs are checked by TEST 2, then some RRs are checked again in TEST 3a
and TEST 3b).
OTHER REASONS DLINT MAY NOT WORK RIGHT
* Dlint doesn't work behind some firewalls - it needs to talk to a root
nameserver to get started.
* Dlint uses the zone transfer mechanism (AXFR), which some nameservers deny to
unauthorized hosts. If dlint is denied, it won't work. Other nameservers
happily return zero records with no error message or exit code! Some vendor's
DNS server products do this. It is a bug that should be fixed.