'dig -t any ...' question

[Kevin Darcy]

Jim Reid wrote:

>>>>>>"Ladislav" == Ladislav Vobr <lvobr at ies.etisalat.ae> writes:
>>>>>>            
>>>>>>
>
>    Ladislav> what's so special about ANY? 
>
>Nothing. You just don't seem to understand what it means. A QYTPE of
>ANY means "give me whatever RRs you have for this name". That's all.
>See my earlier posting for more info.
>
>    Ladislav> Why any recursive servers don't do it's best to satisfy
>    Ladislav> the recursive client with the reply from the authoritative
>    Ladislav> server, that's why we call it recursive right?
>
>Wrong. We call it recursive because the server is able to recursively
>make iterative queries to resolve a query on behalf of some client.
>It doesn't mean the server does that: it can answer from its cache
>which might or might not have been populated with data returned from
>earlier queries to authoritative servers. No assumptions can or should
>be made about how a recursive server provides answers. It should of
>course interrogate authoritative servers when nothing has been
>cached. But that cannot be guaranteed. And even if it does query
>authoritative servers, the answer might not be correct. The DNS is
>loosely coupled remember. It can take time for a zone's authoritative
>servers to converge on the same copy of the zone data after the zone
>gets updated. They don't all update the zone simultaneously.
>
>You seem to think that an ANY QTYPE means a server must retrieve every
>RR for the name. That's not the case. In fact this is impossible. The
>master server could change the RRs immediately after answering your
>hypothetical EVERY query before that reply gets back to the client.
>It's not even the case that a server must query an authoritative
>server in order to respond to an ANY query.
>

>Remember too that one of the key strengths of the DNS is caching. In
>some sense this means that recursive servers are lazy. They'll answer
>from cache every time unless there's nothing relevant in the cache and
>they're forced to resolve something. This is why people need to think
>carefully about TTL values. How many times have we seen postings here
>where there's been a long-lived TTL for a web or mail server that then
>gets renumbered and the poster whines that traffic still goes to the
>old address even though they've updated the zone?
>
That's fine and dandy. We all understand that DNS is "loosely coupled", 
and that caching requires all sorts of tradeoffs and compromises. But I 
think personally QTYPE=* has been compromised to the point of almost 
being unusable for its originally-intended purpose. What if instead of 
defining a valid, complete QTYPE=* response from cache as "whatever you 
happen to have in your cache", which as Ladislav rightly points out 
makes a mockery of the RA flag, we define it as

    "RRsets for all record types that were seen in the most recent 
QTYPE=* response, if none of them have expired"

?? Certainly we don't expect recursive servers to recurse *every* 
QTYPE=* query, on the offchance that maybe some RRset has changed, but 
certainly if all of the RRsets for all of the record types previously 
seen in a QTYPE=* response are still present in the cache, regardless of 
whether those RRsets were from the original QTYPE=* query, or from other 
queries, or combination of the two, why not synthesize a response from 
them? That seems perfectly reasonable to me, and not unduly burdensome 
to recursing servers. Note that if the recursing server happens to 
notice that it is missing exactly *one* of the RRsets (a fairly common 
occurrence, I would expect, since A records tend to have smaller TTLs 
than anything else), then it could make a choice between recursing the 
whole QTYPE=* query, or just fetching the missing RRset. The alternative 
is for the client to make the A-record query itself, along with queries 
for whatever other record types in which it is interested, so from the 
recursive-server's standpoint, this can only be a win.

I can understand that this definition could raise a concern about 
"record-type lock", where the recursive server might assume, in 
perpetuity (or at least until the next restart/reboot), that only 
certain record types exist for a given name, and thus keep synthesizing 
QTYPE=* responses from the same set of record types even after one or 
more types have been deleted from or added to the name. Deleted types 
aren't really a problem, since according to the above definition the 
answer is not valid and/or complete if any of the individual RRsets have 
expired, so eventually the deleted RRset will expire and the recursive 
server will be forced to fetch a new QTYPE=* answer. This "staleness" 
problem is thus no worse than if the client was using type-specific 
queries instead of QTYPE=*. Added types are a bit more problematic -- 
how can a recursive server know that records with a given type have been 
added to a name, unless it's actually querying that name & type (or 
QTYPE=*) from its upstream sources? This problem can be solved at the 
protocol level with a very minor clarification/extension of Negative 
Caching, but in the interim, some more-or-less arbitrary limit could be 
set in BIND, such that a fresh QTYPE=* query is forced every so often, 
in order to prevent "record-type lock". This could be just a fixed 
amount of time, such as was implemented before Negative Caching was 
properly specified, and like BIND 9 currently implements for "lame 
server TTL"s, or it could be based on the TTLs of the various RRsets 
associated with the name, either an average, the minimum, the maximum, 
or the result of some sort of multivariable formula...

                                                                         
                                                         - Kevin