'dig -t any ...' question
Ladislav Vobr
lvobr at ies.etisalat.ae
Sun Jun 13 04:09:45 UTC 2004
Dear jim,
if you look back in the list, I have raised this issue here several
times, and I got couple of answers, which made me believe recursive
server will not provide a data cached as glue to a recursive clients,
and I am really facing this kind of problem, if you have a minute you
can look at
http://marc.theaimsgroup.com/?l=bind-users&m=107826242922419&w=2
http://marc.theaimsgroup.com/?l=bind-users&m=107826306124991&w=2
my comments below
Jim Reid wrote:
>>>>>>"Ladislav" == Ladislav Vobr <lvobr at 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.
yes agreed, and in the initial example, and in my case as well, server
provides a recursion, which is clear from the RA flag in the response.
My point was if the recursion is available, how come it doesn't even
check with the authoritative servers, and just returns what I think is a
glue from parent, since the cache was empty before
>
> 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.
agreed, there are different credibilities obtained different ways, but
still it doesn't explain, why when the recursion is available and
required it doesn't even bother to check with authoritative servers,
seems surprising to me, also because from my side I have different
experince with ladislav.name.ae but as well as other domains, I just did
this domain as a test for trying to understand bind behaviour in case
all nameservers are unreachable
>
> 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.
well i would expect this to be definitely true for +norec flag, or if
the recursion is not available, shouldn't this kind of behaviour depends
on recursion required flag and recursion available, shouldn't
caching-only server try to do it's best, if it supports recursion and it
is required, to get better answer than a glue/referral?
>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.
I thought there are certain situations, when bind triggers this kind of
behaviour. Seems logical to me that when I am recursive client unable to
lookup the full answer myself,and my chaching server provides recursion,
I don't expect a glue/referral to be the answer, when the authoritative
servers are up and running and reachable? Perhaps my expectations are
too high :-), in this kind of logic, why does it bother going to .com
servers, and giving me ericsson.com refferal, it can perhaps give me as
well refferal only from . root servers, and tells me that's all I have
my dear recursive client
>
> 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?
could this be bind specific, since in my case I have 9.2.3 as well as
8.3.4 and 9.3.0beta4 but I am unable to get response like you, instead
of it, I see traffic to all fake nameservers, do you have any hints what
might be causing it, I have experince it several times, that certain
parts of the cache, recursive clients can not see. As you can see from
my previous example, I ran snoop and after issuing the dig with rd flag,
it keeps retrying to each ns records, while with +norec it answers :-(.
This looks very weird to me, I tried even on several nameservers and
it's the same, it timesout although it provides it with +norec.
# dig any ladislav.name.ae @194.170.1.6 +time=20
; <<>> DiG 9.3.0beta3 <<>> any ladislav.name.ae @194.170.1.6 +time=20
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 764
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;ladislav.name.ae. IN ANY
;; Query time: 10006 msec
;; SERVER: 194.170.1.6#53(194.170.1.6)
;; WHEN: Sun Jun 13 08:13:19 2004
;; MSG SIZE rcvd: 34
# dig any ladislav.name.ae @194.170.1.6 +norec
; <<>> DiG 9.3.0beta3 <<>> any ladislav.name.ae @194.170.1.6 +norec
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1770
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 0
;; QUESTION SECTION:
;ladislav.name.ae. IN ANY
;; AUTHORITY SECTION:
ladislav.name.ae. 10653 IN NS fake1.ladislav.name.ae.
ladislav.name.ae. 10653 IN NS fake2.ladislav.name.ae.
ladislav.name.ae. 10653 IN NS fake3.ladislav.name.ae.
ladislav.name.ae. 10653 IN NS fake4.ladislav.name.ae.
ladislav.name.ae. 10653 IN NS fake5.ladislav.name.ae.
;; Query time: 2 msec
;; SERVER: 194.170.1.6#53(194.170.1.6)
;; WHEN: Sun Jun 13 08:11:41 2004
;; MSG SIZE rcvd: 134
# dig any ericsson.com @194.170.1.6
; <<>> DiG 9.3.0beta3 <<>> any ericsson.com @194.170.1.6
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1107
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;ericsson.com. IN ANY
;; ANSWER SECTION:
ericsson.com. 172800 IN NS ns1.euro909.com.
ericsson.com. 172800 IN NS ns3.euro909.com.
;; AUTHORITY SECTION:
ericsson.com. 172800 IN NS ns1.euro909.com.
ericsson.com. 172800 IN NS ns3.euro909.com.
;; ADDITIONAL SECTION:
ns1.euro909.com. 46213 IN A 212.209.52.2
ns3.euro909.com. 42075 IN A 194.52.6.2
;; Query time: 228 msec
;; SERVER: 194.170.1.6#53(194.170.1.6)
;; WHEN: Sun Jun 13 08:11:55 2004
;; MSG SIZE rcvd: 134
snap from my named_dump.db
; glue
ladislav.name.ae. 10473 NS fake1.ladislav.name.ae.
10473 NS fake2.ladislav.name.ae.
10473 NS fake3.ladislav.name.ae.
10473 NS fake4.ladislav.name.ae.
10473 NS fake5.ladislav.name.ae.
; glue
fake1.ladislav.name.ae. 10473 A 10.1.1.1
; glue
fake2.ladislav.name.ae. 10473 A 10.2.2.2
; glue
fake3.ladislav.name.ae. 10473 A 10.3.3.3
; glue
fake4.ladislav.name.ae. 10473 A 10.4.4.4
; glue
fake5.ladislav.name.ae. 10473 A 10.5.5.5
>
> 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.
Thank you jim, do you have any explanation for the behaivour I am facing
Ladislav
More information about the bind-users
mailing list