Delegation or PEBKAC problems?
Mark Andrews
Mark_Andrews at isc.org
Wed May 6 00:02:24 UTC 2009
In message <1D8C9A4471119A40BD574F9D8D464AE304BD4638 at 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-bounces at lists.isc.org
> [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Todd Snyder
> Sent: Tuesday, May 05, 2009 11:59 AM
> To: bind-users at 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 root at ns01.lab.foo.example:~ ()]# dig @ns01.lab.foo.example
> record.group.lab.foo.example any
>
> -----Original Message-----
> From: bind-users-bounces at lists.isc.org
> [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Todd Snyder
> Sent: Tuesday, May 05, 2009 11:08 AM
> To: bind-users at 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 root at 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 at 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 at 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 at 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_Andrews at isc.org
More information about the bind-users
mailing list