Re: 'dig -t any ...' question
Ladislav Vobr
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 <lv...@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
Ladislav Vobr
>>; <<>> DiG 9.2.3 <<>> any ladislav.name.ae
>>;; global options: printcmd
>>;; connection timed out; no servers could be reached
>>
>>ns3.emirates.net.ae# dig any ladislav.name.ae +norec
>>
>>; <<>> DiG 9.2.3 <<>> any ladislav.name.ae +norec
>>;; global options: printcmd
>>;; Got answer:
>>;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 0
>>
>>;; QUESTION SECTION:
>>;ladislav.name.ae. IN ANY
>>
>>;; AUTHORITY SECTION:
>>ladislav.name.ae. 3278 IN NS fake3.ladislav.name.ae.
>>ladislav.name.ae. 3278 IN NS fake4.ladislav.name.ae.
>>ladislav.name.ae. 3278 IN NS fake5.ladislav.name.ae.
>>ladislav.name.ae. 3278 IN NS fake1.ladislav.name.ae.
>>
>>;; Query time: 42 msec
>>;; SERVER: 194.170.1.99#53(194.170.1.99)
>>;; WHEN: Sat Jun 12 15:24:18 2004
>>;; MSG SIZE rcvd: 134
>>
>>can you explain this ?
>
>
> 10.x.x.x addresses are private addresses that are not reachable from the
> Internet. Why do you have your domain delegated to these unusable
> addresses?
>
I set this up purposely, since I faced some weird behaviour, and also I
was wondering how bind handles the situation when all servers are
unreachable,
I have two issues with this setup, as my old posts,
1. bind sends around 150 packets total to all nameservers, when I
request single name for any host from this domain, which seems quite a
lot for me, and it seems to be doing it for every new name again, looks
like pretty ddos amplifier I am trying to understand this logic.
2. I have this +norec/rd flag issue, when I am unable to see the *glue*
from the cache with rd flag.
Ladislav
Kevin Darcy
>>>>>>"Ladislav" == Ladislav Vobr <lv...@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
Barry Margolin
Kevin Darcy <k...@daimlerchrysler.com> wrote:
> 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.
Just what *is* that purpose? I don't see any indication in RFC 1034; no
real justification is given for its existence.
Note also that the OP has made a big deal about whether it should return
records with cred=GLUE, but the DNS specification makes no mention of
credibility levels for cached information. All it says, in section
5.3.3 (the resolver algorithm, which is used by a server when processing
a query that has RD set) is: "Step 1 searches the cache for the desired
data. If the data is in the cache, it is assumed to be good enough for
normal use."
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Kevin Darcy
>In article <calb87$2osn$1...@sf1.isc.org>,
> Kevin Darcy <k...@daimlerchrysler.com> wrote:
>
>
>
>>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.
>>
>>
>
>Just what *is* that purpose? I don't see any indication in RFC 1034; no
>real justification is given for its existence.
>
RFCs are specification documents, they don't necessarily justify the
existence of every aspect of what they specify. But it seems rather
obvious to me that the purpose of QTYPE=* is to efficiently retrieve all
relevant RRsets owned by a particular DNS name, as opposed to querying
all of those RRsets individually. The way QTYPE=* has been implemented,
however, has rendered it so untrustworthy that very few apps that could
benefit from this efficiency even bother to issue QTYPE=* queries any
more. This is a pity, all the more so because it would be a rather
elegant way to retrieve both A and AAAA records for a given name, and
thus ease the migration to IPv6.
>Note also that the OP has made a big deal about whether it should return
>records with cred=GLUE, but the DNS specification makes no mention of
>credibility levels for cached information. All it says, in section
>5.3.3 (the resolver algorithm, which is used by a server when processing
>a query that has RD set) is: "Step 1 searches the cache for the desired
>data. If the data is in the cache, it is assumed to be good enough for
>normal use."
>
RFC 2181 states "... data from the additional data section, and data
from the authority section of a non-authoritative answer, should not be
cached in such a way that they would ever be returned as answers to a
received query." This applies to QTYPE=* queries just as much as any
other query type.
- Kevin
Barry Margolin
Kevin Darcy <k...@daimlerchrysler.com> wrote:
> Barry Margolin wrote:
>
> >In article <calb87$2osn$1...@sf1.isc.org>,
> > Kevin Darcy <k...@daimlerchrysler.com> wrote:
> >
> >
> >
> >>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.
> >>
> >>
> >
> >Just what *is* that purpose? I don't see any indication in RFC 1034; no
> >real justification is given for its existence.
> >
> RFCs are specification documents, they don't necessarily justify the
> existence of every aspect of what they specify. But it seems rather
> obvious to me that the purpose of QTYPE=* is to efficiently retrieve all
> relevant RRsets owned by a particular DNS name, as opposed to querying
> all of those RRsets individually. The way QTYPE=* has been implemented,
> however, has rendered it so untrustworthy that very few apps that could
> benefit from this efficiency even bother to issue QTYPE=* queries any
> more. This is a pity, all the more so because it would be a rather
> elegant way to retrieve both A and AAAA records for a given name, and
> thus ease the migration to IPv6.
But RFC 1034 included an example of QTYPE=* being sent to caching
servers, showing that different servers will return different records
based on what they happened to have cached at the time. So the problem
is in the original design, not BIND's implementation.
>
> >Note also that the OP has made a big deal about whether it should return
> >records with cred=GLUE, but the DNS specification makes no mention of
> >credibility levels for cached information. All it says, in section
> >5.3.3 (the resolver algorithm, which is used by a server when processing
> >a query that has RD set) is: "Step 1 searches the cache for the desired
> >data. If the data is in the cache, it is assumed to be good enough for
> >normal use."
> >
> RFC 2181 states "... data from the additional data section, and data
> from the authority section of a non-authoritative answer, should not be
> cached in such a way that they would ever be returned as answers to a
> received query." This applies to QTYPE=* queries just as much as any
> other query type.
I did notice a change related to that when we upgraded our caching
servers from BIND 8 to 9. Prior to that, if I asked for the A record of
a nameserver, I would often get the address from the glue in the parent
zone. After the upgrade, it seemed to go to the authoritative server
for this -- if all of the zone's servers were down, the query would hang
and eventually return a SERVFAIL error. The only way to get the cached
glue record was to query without the RD flag set.
However, I think ANY queries would still return whatever happened to be
in the cache, no matter how it was learned.
Ladislav Vobr
> servers from BIND 8 to 9. Prior to that, if I asked for the A record of
> a nameserver, I would often get the address from the glue in the parent
> zone. After the upgrade, it seemed to go to the authoritative server
> for this -- if all of the zone's servers were down, the query would hang
> and eventually return a SERVFAIL error. The only way to get the cached
> glue record was to query without the RD flag set.
>
same way as 9 and higher, 8.3.4 returns it as a *answer*, I think this
will be very important to distinguish once it comes to dnssec. What is
glue and what is not, since the glue is not signed.
> However, I think ANY queries would still return whatever happened to be
> in the cache, no matter how it was learned.
if it is cached with *glue* credibility it will not return it to ra
clients. This behavious as you describe is nightmare, it keeps retrying
to all nameservers if all unreachable causing incredible traffic to
remote servers and the network as well, I am sometimes seeing
nameservers querying me with 1000(one thousand)req/s with the same
request, this can really spoil lot's of things, why would ever caching
nameserver has to do such a thing, does it really help to do it this
way....?
how can we say it is perfectly fine to answer the recursive client with
non-authoritative data, when nothing was cached before this request? I
feel recursion means, if it is not available, recurse up to the source
(auth servers) and get it, not from . or 2ndlevel or 3level or 4level,
we can not stop randomly somelevel just because some binds think it was
enough steps(parent 8.3.4 thinks it is enough, parent 8.4.1 thinks try
to go to next level... it seems really very consistent:-), we always
should go up to the source *provided it was not cached before*. How will
this work in dnssec, we just answer to ra client with *glue* and tell
him be happy for it:-)?
Ladislav
Kevin Darcy
Nope. Those example queries were *non-recursive* as per the following
text in the Section 6.2 intro:
Unless otherwise noted, the queries do not have recursion desired (RD)
in the header.
Nowhere is there a specific example in RFC 1034 of a response to a
*recursive* QTYPE=* query, but one would assume, based on generic
descriptions of recursive resolvers and how they are supposed to
operate, that a recursive resolver would make its best efforts to get a
complete answer, which clearly BIND and other implementations do not.
Frankly, I think the implementors misread the RFC 1034 examples the same
way you did, and refuse to admit their mistake.
- Kevin
Barry Margolin
Kevin Darcy <k...@daimlerchrysler.com> wrote:
The server algorithm says that when a query has RD set, the server
should consult its resolver. If you read the section on the resolver
algorithm, it says that if the records are already in the cache it
doesn't need to query the authoritative server.
Ladislav Vobr
> should consult its resolver. If you read the section on the resolver
> algorithm, it says that if the records are already in the cache it
> doesn't need to query the authoritative server.
neither way it is implemented, *glue* credibility is not provided to rd
clients. When and what is cached under *glue* depends purely on *each*
bind reasoning.
Ladislav
Kevin Darcy
>In article <caobi7$1lkv$1...@sf1.isc.org>,
> Kevin Darcy <k...@daimlerchrysler.com> wrote:
>
>
>
>>Nowhere is there a specific example in RFC 1034 of a response to a
>>*recursive* QTYPE=* query, but one would assume, based on generic
>>descriptions of recursive resolvers and how they are supposed to
>>operate, that a recursive resolver would make its best efforts to get a
>>complete answer, which clearly BIND and other implementations do not.
>>
>>
>
>The server algorithm says that when a query has RD set, the server
>should consult its resolver. If you read the section on the resolver
>algorithm, it says that if the records are already in the cache it
>doesn't need to query the authoritative server.
>
Actually, what RFC 1034 says in the resolver algorithm description is
"See if the *answer* is in local information" (emphasis mine). Not just
any old records that happen to be owned by the QNAME, but the *answer*
to the query. I suppose reasonable people could disagree over exactly
what "answer" means in that context, but it seems a rather strange
interpretation to me to say that a recursive resolver can choose to give
the client *less* of an answer than it wanted (note that the description
of the "General Lookup Function" in Section 5.2.1 refers to the client
wanting "*all* of the matching RRs" (emphasis added)), even when a
complete answer is available via recursion, recursion was requested by
the client and the availability of recursion is being advertised by the
recursive resolver via the RA bit. If the client wanted a least-efforts
answer, it wouldn't have set RD=1 in the first place, surely. The
description of the RA flag in the RFCs is not "Recursion Available,
except for QTYPE=* queries, to which I'll give partial answers from
cache if I don't feel like recursing for something better"...
- Kevin
Guido Roeskens
I thought I've seen a discussion about this on namedroppers before
http://marc.theaimsgroup.com/?l=namedroppers&m=106920851901151&w=2
(start of the thread)
Kevin Darcy wrote:
In the thread mentioned above someone (I think it's Paul Vixie says
that QTYPE=* is some sort of debugging aid.
The problem is how a resolver should know if it has to query the
authoritative server(s) or not. It would need to keep a record of
when it last queried the authoritave server for QTYPE=* and set it's
TTL to the lowest anwer given.
Or the resolver would need to query the authoritative servers each time
for the answer, since the QTYPE=* cannot be cached.
This could overload the server easily or open doors for DOS attacks.
Guido