Re: 'dig -t any ...' question

>>>>> "Ladislav" == Ladislav Vobr <lvobr@ies.etisalat.ae> writes:

Ladislav> when you ask for ANY with a client with rd flag it
Ladislav> doesn't provide a records with cridibilityy level
Ladislav> 'glue', it returnsI believe only 'answer' and
Ladislav> 'authanswer' credibility,

No it doesn't: whatever "it" is. Maybe some other DNS implementation
might do something like that, but BIND clearly doesn't. The output
from the OP's dig postings showed that. As does the output for
ladislav.name.ae below.

BTW, the setting of header bits other than aa -- authoritative answer
-- are irrelevant to this discussion. All the rd bit does is tell the
server that's being queried that the client would like the server to
do recursion for them. Whether the server does that or not is a policy
decision. Most TLD servers have recursion disabled for obvious
reasons. [In fact no authoritative server should offer recursive
service, but that's a story for another time.] So when anything sets
the rd bit and queries the .com name servers (say), all they'll get
back is a referral to the delegated zone's name servers because the
..com name servers won't resolve www.google.com or whatever.

Ladislav> my point is how come the glue
Ladislav> from the parent is considered as a 'answer' credibility
Ladislav> in the mentioned case.

An answer is an answer. BIND's credibility ranking determines whether
certain responses are more trustworthy than others. For instance, the
Answer Section of an authoritative reply from an authoritative name
server is more believable than something in the Additional Section of
non-authoritative answer. This credibility ranking determines what
data goes in BIND's cache and how/when it gets replaced.

Data of low credibility can be cached -- after all it's better than
nothing -- but may well get displaced later by more credible data as a
name server comes across "better data" during routine operations. For
instance, it'll cache the referral info from a TLD: say the NS and any
glue records for google.com returned by the .com servers. This
response from the .com name servers is of course non-authoritative
because they don't serve google.com. But if the local name server then
looks up www.google.com, it'll query one of google.com's servers. This
should provide an answer that also includes definitive, authoritative
data about google.com's name servers and their addresses. That data
will be more credible than the referral data that was stored earlier.
So the old cached data gets displaced by the newer, more trustworthy
info from the google.com servers.

A QTYPE of ANY means "give me any records you have for this name".
That's all. So whatever is in the server's cache for that name gets
returned. This might or might not be all the RRs that exist for the
name. The response might or might not be authoritative. The data could
even be of different credibility weighting: a name's MX records might
have came from the Answer Section of an authoritative reply, but an A
or AAAA record for that name came from a referral or the Additional
Section of some other reply.

You seem to be under the impression that BIND's credibility weighting
to response data determines how it will resolve some query. It
doesn't. The server doesn't say to itself "I've only cached lowest
credibility data for this incoming query. Let's go and hunt for
definitive data from the zone's authoritatve servers and return that
to the client." The server answers from its cache if that has data
that will answer the query: credibility weighting doesn't come into
it. Otherwise it resolves the name, caches the responses during
resolving before returning an answer.

Ladislav> I have a sample domain ladislav.name.ae it has 5 fake
Ladislav> unreachable nameservers, there is no way you can get
Ladislav> them with rd flag using ANY or NS type, since they are
Ladislav> in the cache only as a glue.

So what?

Here's what I get when I lookup this domain:

% dig ladislav.name.ae any

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59905
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 5, ADDITIONAL: 5

;; QUESTION SECTION:
;ladislav.name.ae. IN ANY

;; ANSWER SECTION:
ladislav.name.ae. 10800 IN NS fake5.ladislav.name.ae.
ladislav.name.ae. 10800 IN NS fake1.ladislav.name.ae.
ladislav.name.ae. 10800 IN NS fake2.ladislav.name.ae.
ladislav.name.ae. 10800 IN NS fake3.ladislav.name.ae.
ladislav.name.ae. 10800 IN NS fake4.ladislav.name.ae.

;; AUTHORITY SECTION:
ladislav.name.ae. 10800 IN NS fake3.ladislav.name.ae.
ladislav.name.ae. 10800 IN NS fake4.ladislav.name.ae.
ladislav.name.ae. 10800 IN NS fake5.ladislav.name.ae.
ladislav.name.ae. 10800 IN NS fake1.ladislav.name.ae.
ladislav.name.ae. 10800 IN NS fake2.ladislav.name.ae.

;; ADDITIONAL SECTION:
fake1.ladislav.name.ae. 10800 IN A 10.1.1.1
fake2.ladislav.name.ae. 10800 IN A 10.2.2.2
fake3.ladislav.name.ae. 10800 IN A 10.3.3.3
fake4.ladislav.name.ae. 10800 IN A 10.4.4.4
fake5.ladislav.name.ae. 10800 IN A 10.5.5.5

;; Query time: 2596 msec

Note the long query time. The Answer Section contains your zone's NS
records and the A records for the glue is in the Additional Section. This
is how things are expected to be. So no surprises there then. Note too
that my server didn't try to query your servers for more info about
ladislav.name.ae. The referral was enough to populate my server's
cache with data, albeit not the most credible data, and so answer the
query I made with dig.

% dig fake1.ladislav.name.ae any

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39902
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 4

;; QUESTION SECTION:
;fake1.ladislav.name.ae. IN ANY

;; ANSWER SECTION:
fake1.ladislav.name.ae. 10684 IN A 10.1.1.1

;; AUTHORITY SECTION:
ladislav.name.ae. 10684 IN NS fake3.ladislav.name.ae.
ladislav.name.ae. 10684 IN NS fake4.ladislav.name.ae.
ladislav.name.ae. 10684 IN NS fake5.ladislav.name.ae.
ladislav.name.ae. 10684 IN NS fake1.ladislav.name.ae.
ladislav.name.ae. 10684 IN NS fake2.ladislav.name.ae.

;; ADDITIONAL SECTION:
fake2.ladislav.name.ae. 10684 IN A 10.2.2.2
fake3.ladislav.name.ae. 10684 IN A 10.3.3.3
fake4.ladislav.name.ae. 10684 IN A 10.4.4.4
fake5.ladislav.name.ae. 10684 IN A 10.5.5.5

;; Query time: 12 msec

Note the query time now. This is a local lookup. There's no attempt to
query these bogus name servers of yours. My server is answering
non-authoritatively from its cache. You can also see that from the
lower TTLs. My server is returning the glue record for
fake1.ladislav.name.ae that it cached from the previous lookup.

Ladislav> This seemed confusing to me, how come the answer from
Ladislav> the parent is sometimes considered answer and sometimes
Ladislav> as a glue?

An answer that you call "glue" -- it's actually a referral -- is still
an answer.

Ladislav> Does it depend on the rr type is NS records a different ?

Of course not. There is nothing magical about queries or answers for
NS records. In fact, name servers almost never query for NS records
explicitly. They learn about the NS records and the corresponding A or
AAAA records for some zone in the course of resolving.