With help of a list member, we got this figured out.
The problem is that, outside of the config I showed you, I had a
forwarder setup.
zone "foo.example" IN {
type forward;
forward only;
forwarders { x; y };
};
My understanding of things was that BIND would answer most specifically.
So I thought that because I was authoritative for lab.foo.example, it
would only use the foo.example for things that didn't fall under
lab.foo.example. That doesn't seem to be the case. BIND was using the
forwarding, and not even looking at the authoritative zone.
>From my reading of "DNS and Bind (pg 244, 4th paragraph)", I'm wondering
if the book or BIND are mistaken:
"If a resolver requests records that are already in the nameserver's
authoritative data or cached adata, the nameserver answer that with the
information, this part of its operation hasn't changed. However, if the
records aren't in its database, the nameserver sends the query to a
forwarder ..." (this relates to forward only mode)
For forward first mode, the book states (pg 245, 2nd paragraph):
"A nameserver in forward-only mode is a variation on a nameserver that
uses forwarders. It still answers queries from its authoritative data
and cached data."
So, in both cases, the server should be answering authoritatively first,
then going to the forwarders.
Having said that, I reconfigured it to use "forward first" and I'm
getting the behaviour I was looking for - so the server seems to behave
as I thought in "forward first" mode, but not in "forward only" mode.
Has the logic here changed, or am I misinterpreting the book?
Thanks!
Todd.
-----Original Message-----
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Todd Snyder
Sent: Tuesday, May 05, 2009 11:59 AM
To: bind-us...@isc.org
Subject: RE: Delegation or PEBKAC problems?
it's been pointed out that I made a mistake cleaning up my example data
below .. my dig should read:
[10:43:08 r...@ns01.lab.foo.example:~ ()]# dig @ns01.lab.foo.example
record.group.lab.foo.example any
-----Original Message-----
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Todd Snyder
Sent: Tuesday, May 05, 2009 11:08 AM
To: bind-us...@isc.org
Subject: Delegation or PEBKAC problems?
Good day,
(BIND 9.6.0-P1)
Although, to me, delegation seems like a fairly simple configuration, I
seem to be having problems. What I am trying to do is very simple - I
have a lab, and I want to delegate part of the namespace to someone else
in the lab. My configuration looks like this:
(zone lab.foo.example)
;delegation
group.lab.foo.example. IN NS group-ns01.lab.foo.example.
group.lab.foo.example. IN NS group-ns02.lab.foo.example.
; glue
group-ns01 IN A 1.1.1.1
group-ns02 IN A 1.1.1.2
I load the zone, it loads just fine. I can resolve the 2 ns servers
directly, so I know the glue is good.
However, when I dig for a record in that zone, I get
[10:43:08 r...@ns01.lab.foo.example:~ ()]# dig @ns01.lab.foo.example
record.group.lab.foo.example any
; <<>> DiG 9.6.0-P1 <<>> +qr @s01.lab.foo.example
record.group.foo.example any ; (1 server found) ;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59035 ;; flags: rd;
QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;record.group.foo.example. IN ANY
;; connection timed out; no servers could be reached
When I dig directly at the delegated nameserver, I can get the record
just fine.
When I run tcpdump on the nameserver, I see the requests come in,
timeout, come in, time out, come in, timeout, then the resolver gives
up. I don't see packets going out to the other server, nor do I see the
server returning anything to the resolver (ie: authority records)
If I disable recursion on this view, the server, loading the same zone,
returns NS records immediately, which tells me that the server is
loading the zone properly, and that the data is good.
My understanding of delegation is that the resolver goes out to it's
configured nameserver. That nameserver returns the NS records for the
delegated namespace, then the resolver goes to the delegated server to
ask the next question. Am I incorrect in that?
We've been fiddling with this for a bit now, and I can't see what I've
done wrong. My best guess right now is that we're htiting some oddness
with views/delegation.
Can anyone think of something I've missed? Can anyone clarify my view
of delegation?
Thanks,
Todd.
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
