Host sometimes Succeeds with Empty Output

Kevin Darcy kcd at
Fri Sep 14 18:46:38 UTC 2012

On 9/14/2012 2:05 PM, Martin McCormick wrote:
> Kevin Darcy writes:
>> 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
>> "", if its parent
>> "" owns no records, it's still an "empty
>> non-terminal" and will return NOERROR instead of NXDOMAIN when queried.
> 	Thank you! I suspected that sort of thing from the
> beginning because when I have run in to this behavior before,
> the response occurred when there were similar records in the
> zone that might look like parents and I wondered if that was
> what was going on. I wasn't sure enough, however, to not have
> doubts.
>> 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.
> 	I sure hope not. Can you imagine the sort of random
> havoc and instability this would create? John Q. Public has XYZ
> browser that has this behavior and now he can't get to this or
> that site because some unrelated record has what amounts to a
> similar-looking name.
> 	Jane Doe's browser is a little older and she makes it to
> the site just fine and everybody's scratching their heads. The
> phones ring and ring and the voices are just sure that DNS is
> broken. What a nightmare!
Well, in order for this to fail, you'd need an authoritative nameserver 
implementation that returns NXDOMAIN for an empty non-terminal (which I 
don't think any of them do) and then a caching resolver implementation 
that optimizes by pruning the namespace tree upon receipt of an NXDOMAIN 
(which I don't think any of them do). So, yes, under those particular 
hypothetical circumstances, you might get inconsistent results depending 
on what was queried in what sequence, and what the respective TTL 
settings were. But, it wouldn't depend on browser version, since 
browsers don't fetch DNS results directly from authoritative 
nameservers; they depend on upstream resolvers -- possibly a whole 
forwarding chain of resolvers -- to do that for them...

                                             - Kevin

More information about the bind-users mailing list