Bind 9.5.0-P2 : views and DynDNS

[Kevin Darcy]

mathieu.oudart at gmail.com wrote:
> Hi,
> I am configuring a new DNS server and now it seems recommended to use
> the "views" in named.conf.
> So basically I created the "localhost" view and a "global" for all
> others.
>
> Both views are pretty much the same and use the same zone files. The
> only differences is that localhost can use recursion and includes
> named.rfc1912.zones.
>
> My problem is that when I update dynamically a record (using
> nsupdate), one view is updated but the other one is not !!
>
> Where should I put my dyndns zone so that all views get the updates ?
>   
Each view is in effect a separate "virtual" nameserver instance, and a 
zone defined in one view is logically unrelated to a zone defined in 
another view, even if they have the same name.

So, to answer your question, the way you have things set up now, you'd 
need to nsupdate the zone in *both* views. You'd target the view by a) 
performing separate nsupdates from separate clients, or, with a single 
multi-homed client, specifying a particular source address in the 
nsupdate client (using nsupdate's "local" command), if you're using 
match-clients to select views, or b) specifying a particular destination 
address (using nsupdate's "server" command), if you're using 
match-destinations to select views, or c) specifying a TSIG key (using 
an nsupdate command-line option or the "key" command in-line) if you're 
using keys to select views.

Since parallel updating entails complexity and an 
administrative/capacity burden, you may want to reconsider your view 
design. Perhaps it might make more sense for your authoritative zones to 
only be defined in your "global" view and then for the "localhost" view 
to "loopback" query the other one, for names in those zones, through 
careful configuration of query-source/listen-on (if you have multiple 
interfaces) and/or the use of TSIG keys for view-selection. This should 
also cut down on your memory footprint, since only 1 copy of each 
authoritative zone would be resident in memory at any given time.

For a single interface and selecting views via match-clients, you'd need 
to manipulate view-selection with a TSIG key, and the basic outline would be

key loopback {
    algorithm hmac-md5;
    secret "xxxxxxxxxxxxxxxxx";
};

view localhost {
    match-clients { !key loopback; localhost; };
    server <local_ip_address> {
       keys loopback;
    };

    zone "." {
       type hints;
       file "hints";
    };
};

view global {
    match-clients { any; };
    recursion no;
   
    zone "example.com" {
       type master;
       ...
    };

    ...
};

When the "localhost" view wants to resolve a name in "example.com", it 
finds the delegated IPs via normal iterative resolution, and if it 
happens to query _itself_, will do so by signing its query with the 
"loopback" key. The presence of that key then forces named to select the 
"global" view, in which "example.com" is hosted.

                                                                         
                     - Kevin