On 9/14/2012 10:48 AM, Martin McCormick wrote:
I needed to delete the CNAME record of
physicscourses.okstate.edu. After the deletion, the host command
would silently exit successfully as if this alias was still
there. I have seen this behavior a few times before but am not
sure what triggers it as one normally gets the usual "host
whatever.com not found" and host exits non zero.
If I specifically command
host -tCNAME physicscourses.okstate.edu
I receive that there is no CNAME record named
physicscourses.okstate.edu but host still exits as if successful
in finding it.
There is a www.physicscourses.okstate.edu CNAME record
and this maybe has something to do with the unusual reply.
I had a script that was using the return status of host
and it works great guns unless you run in to this situation in
which it thinks the alias still exists. This causes an infinite
loop because it is waiting for the lookup to fail which it
normally does as soon as the nsupdate command's results
propagate out in a very short time.
I did check our zone for any other records for
physicscourses.okstate.edu which, of course, would be an error
after having had a CNAME record of that name, but there wre
none.
Thanks for any light you can shed on why host still thinks there
is something there.
I don't use "host" very much, but I would assume it returns a
"successful" exit code as long as the RCODE of the response is NOERROR.
This would explain the behavior you are seeing, since by creating a name
"www.physicscourses.okstate.edu", if its parent
"physicscourses.okstate.edu" owns no records, it's still an "empty
non-terminal" and will return NOERROR instead of NXDOMAIN when queried.
This may seem strange to the current generation of DNS admins, who would
be more likely (from experiences in the Relational Database world, for
instance) to think of the DNS database as nothing more than a collection
of records keyed by (class, owner, type). But the older generation who
designed the DNS thought of it more in a hierarchical fashion, like a
tree, and a branch (point in the hierarchy) still exists even if no
leaves ("terminal" records like A, PTR, MX, SRV, etc.) grow on it,
right? An argument has been made in the past that returning NXDOMAIN for
empty non-terminals is dangerous because resolvers, as an optimization,
might apply that negative caching entry to the entire tree -- "prune"
it, so to speak -- from that point downwards, thus erroneously
"disappearing" leaf nodes further down in the hierarchy, for the
duration of the negative-caching TTL. I don't know, however, if anyone
has proven that there are any resolvers that are smart enough (arguably,
reckless enough) to actually perform this kind of "pruning" optimization.
Google "empty non-terminal" if you want more in-depth discussions of how
this database-taxonomy anomaly has posed challenges for wildcarding,
DNSSEC and so forth.
As for the solution to your problem: sad to say, you may have exceeded
the abilities of a simple command-line utility like "host", at least in
its default invocation. You could add a "-v" to the "host" command and
parse through the verbose output, perhaps, or go all of the way to
generating the queries yourself via the Net::DNS Perl module or similar
tools in other scripting languages, which will give you better
capability to distinguish between different kinds of NOERROR responses.
- Kevin
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
