view directive problems

Mark Andrews marka at isc.org
Sat Mar 25 02:38:35 UTC 2017


In message <6840767825452847B8EACEDEBD6D51AD0162BAEA97 at UM-EXMBX02.comm.ad.roke.
co.uk>, "Barrett, Tony" writes:
>
> We have an external named server (BIND
> 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.6) running on Centos 6.
>
> This server is authoritative for all the zones hosted on it (I'll call it
> mydomain.com). We have a new sub-domain (new.mydomain.com) where a
> different DNS server is authoritative for the single zone. The DNS server
> for new.mydomain.com is working ok, but I'm having trouble getting the
> BIND servers in mydomain.com to forward requests to the DNS server in
> new.mydomain.com  that they receive.

>From this I presume you are authoritative for mydomain.com.  Just
add the NS records and glue address records if necessary, for
new.mydomain.com to mydomain.com.  The recursive servers looking
up names new.mydomain.com will follow the referral.

> We use the view directive in our main BIND servers to control internal
> and external access to the zones.
>
> This is the declaration from our "internal" view
>
> view "internal" {
>         match-clients { "our-net"; };
>         allow-query { "our-net"; };
>         recursion yes;
>         additional-from-auth yes;
>         additional-from-cache yes;
>
>        <zone files here>
> };
>
> This is the declaration from our "external" view
>
> view "external" {
>         match-clients { "any"; };
>         allow-query { "any"; };
>         recursion no;
>         additional-from-auth no;
>         additional-from-cache no;
>
>         <zone files here>
> };
>
> "Internal" is listed first in named.conf, followed by "external". I only
> want resolution for new.mydomain.com to work from the external view, but
> we disable recursion in that zone for good reason. I've tried adding
> new.mydomain.com as a zone to the "external" view with the 'type forward'
> and 'forwarders', but I think the 'recursion no' setting in the external
> view is overriding this, as it still doesn't work.

Forget about forwarders.  Your server returns a referral.  That is its
job.  It isn't supposed to answer for new.mydomain.com.

The root servers say to ask the com servers for new.mydomain.com.
The com servers say to ask the mydomain.com servers for new.mydomain.com.
The mydomain.com servers say to ask the new.mydomain.com for new.mydomain.com.

This is how DNS resolution is designed to work.  Recursive servers remember
this for a while so that later queries don't do all the steps that happen
when a nameserver has just started.

> I tried adding a new view "other" at the end of named.conf with
> 'recursion yes', but initially this didn't seem to work either. Out of
> curiosity, I moved this new view above our "internal" view so it was
> processed first, and then it worked. Initially, all looked good, but then
> it became apparent that everything in the "external" view no longer
> resolved at all (everything was denied). So, I'm aware that 'views' are
> processed in the order listed in named.conf, but is there a limit on the
> number of 'view' directives, and if not, why did the 'other' view only
> work when it was listed first?
>
> I've been pulling my hair out on this one, and it just doesn't make sense.
>
> Thanks for any help
>
> -Tony
>
> ________________________________________
> Roke Manor Research Limited, Romsey, Hampshire, SO51 0ZN, United
> Kingdom.Part of the Chemring Group.
> Registered in England & Wales. Registered No: 00267550
> http://www.roke.co.uk
>
> Please update your address book. Roke is currently transitioning to its
> original brand and will no longer
> be branded under Chemring Technology Solutions. Email addresses of Roke
> staff have therefore been changed
> from firstname.surname at chemringts.com to firstname.surname. at roke.co.uk –
> please use this updated format
> with immediate effect.
>
> ________________________________________
> The information contained in this e-mail and any attachments is
> proprietary to Roke Manor Research Limited and
> must not be passed to any third party without permission. This
> communication is for information only and shall
> not create or change any contractual relationship.
> ________________________________________

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


More information about the bind-users mailing list