forwarder is ignored when authoritative zone is added

[Frank Even]

I've recently had an issue that I'm having some issues finding
information on solving.

I have internal DNS resolvers...they act as recursive name servers for
general internet queries, but we have forwarders explicitly defined
for specific internal zones being served by other name servers.

My configuration has one particular zone configured as such:

zone "internal.organization.com" IN { type forward; forward only;
forwarders {172.x.x.x; 172.x.x.x; }; };

I have our main zone, organization.com, hosted in an external area
outside of a firewall with a wildcard record contained in it for
anything that is not explicitly defined. I have some services that I
need to reach using names that are in this external zone internally.
What I'm trying to do is to slave the organization.com zone to my
internal recursive resolver to mitigate any possible network issues.

So I setup the internal resolver as a slave for the "organization.com"
zone and found that queries against "internal.organization.com" were
getting answered with the wildcard for the external "organization.com"
zone. I can't seem to figure out why the forwarders are getting
ignored. Is it an order of precedence, say authoritative zones are
respected over forwarders...or something else??

Thanks for any assistance anyone can provide, or point me to some
documentation I'm missing,
Frank

[Ben Croswell]

The one thing I can think of off the top of my head is to ensure the child subdomain is properly delegated in the parent. If you try to zone level forward a child domain on a server that loads the parent it will ignore the forward if  it can see the child doesn't exist as a true delegation.
I assume the logic is, why would I forward a subdomain I know doesn't exist.

-Ben Croswell

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Sten Carlsen]

On 26/10/12 12:56, Ben Croswell wrote:

The one thing I can think of off the top of my head is to ensure the child subdomain is properly delegated in the parent. If you try to zone level forward a child domain on a server that loads the parent it will ignore the forward if  it can see the child doesn't exist as a true delegation.
I assume the logic is, why would I forward a subdomain I know doesn't exist.

I should think that internal.org... is properly delegated, so the forward will not be concerned about a subdomain, only about the domain, that is actually forwarded. internal.org... will then be looked up in the normal recursive way, so another forward statement might solve this issue.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"

[Ben Croswell]

The thing that brings me back to a delegation issue is the statement of slaving an external version of the second level domain the internal DNS server. I know if I was splitting a domain I would not put internal only delegations external.

-Ben Croswell

[Barry Margolin]

In article <mailman.521.1351232...@lists.isc.org>,

Forwarders are only used when the server needs to recurse in the first
place. They tell it "Instead of following the NS records, ask the
forwarder(s)." If the server is authoritative for the zone, and there
are no NS records delegating the subdomain away, it doesn't need to
recurse and just returns what it has (in this case the record
synthesized from the wildcard).

Why not configure your resolvers as slaves or stubs for the internal
subdomain?

--
Barry Margolin
Arlington, MA

[Frank Even]

On Fri, Oct 26, 2012 at 7:27 AM, Barry Margolin <bar...@alum.mit.edu> wrote:
> In article <mailman.521.1351232...@lists.isc.org>,
> Frank Even <lists+...@elitists.org> wrote:
>

> Forwarders are only used when the server needs to recurse in the first
> place. They tell it "Instead of following the NS records, ask the
> forwarder(s)." If the server is authoritative for the zone, and there
> are no NS records delegating the subdomain away, it doesn't need to
> recurse and just returns what it has (in this case the record
> synthesized from the wildcard).
>
> Why not configure your resolvers as slaves or stubs for the internal
> subdomain?

Now that you put it that way the behavior makes perfect sense. Thanks!

I'd rather not do that to avoid having any internal records in
external DNS. I'm thinking of maybe running views on the internal box
instead, and putting the authoritative zone in an external view and
the rest of the current config in the internal view and forwarding
lookups to "organization.com" to the "external" view. Seems like the
only real way around it without a delegation of some some sort from
the master zone.