In message <1d8c9a4471119a40bd574f9d8d464ae304bd4...@xch60ykf.rim.net>, "Todd S nyder" writes: > 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.
Put a empty forwarders clause in the master/slave zone configuration. e.g. zone lab.foo.example { type master; file "...."; forwarders { /* empty */ }; }; > >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 inform > ation, privileged material (including material protected by the solicitor-cli > ent or other applicable privileges), or constitute non-public information. An > y use of this information by anyone other than the intended recipient is proh > ibited. If you have received this transmission in error, please immediately r > eply to the sender and delete this information from your system. Use, dissemi > nation, distribution, or reproduction of this transmission by unintended reci > pients is not authorized and may be unlawful. > _______________________________________________ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users