Host sometimes Succeeds with Empty Output

[Kevin Darcy]

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