DNS views setup help

[project722]

Thanks Matthew, I got pulled away in some other projects, so I will go over
your last email sometime this week and get back with you with the results.
I appreciate the help so far.

On Fri, Aug 19, 2016 at 11:49 AM, Mathew Ian Eis <Mathew.Eis at nau.edu> wrote:

> > where would I place it in the context of my views on the master?
>
> Inside of the view
>
>
>
> >  Do I only need that one stanza on the master?
>
> I believe it is needed on the slave as well, to tell the slave to use the
> correct key when communicating with the master. That is how we are doing it…
>
>
>
> > Why in the linked doc does it show it listed under the internal view?
>
> Because in the linked doc they are hosting the same zone on the internal
> and external view; in the context of showing how to use tsig keys, you are
> right, that aspect of the example is confusing. They have it that way
> because they are doing a zone transfer from the internal view to the
> external view, which is different than what I think you want to do.
>
>
>
> > If that's the designated external key should that be placed in the
> external view and not the internal?
>
> If I understand what you want to do correctly, yes…
>
>
>
> > And why does the internal view in the linked doc show both the external
> key and a "mykey" in the internal view
>
> “mykey” has nothing to do with zone transfers and is probably meant for
> management, although the example doesn’t specify.
>
>
>
> > Exactly how many keys do I need here?
>
> I think two … but it depends on your architecture. We have one key for
> admin of each view, and another key for each master/slave/view triplet.
> Managing the keys that way is more difficult (a lot of keys!), but less
> likely to accidentally put the wrong data in the wrong place.
>
>
>
> > Using my config from my first email  … can you provide a modified view?
>
> Here’s a possible way to set up your internal view. Try and get this
> working by itself without your external view, then go back and see if
> adding the external view makes more sense.
>
>
>
> ### master:
>
>
>
> view "insideview" {
>
>       match-clients {
>
>             internal-key;
>
>             !external-key;
>
>             internal;
>
>       };
>
>       server 26.26.26.26 {
>
>             keys { internal-key };
>
>       };
>
>       also-notify {
>
>             26.26.26.26 key internal-key;
>
>       };
>
>       zone"example.com" IN {
>
>             type master;
>
>             file "/var/named/db.exampleinside.com";
>
>             allow-transfer {
>
>                   key internal-key;
>
>             };
>
>       };
>
> };
>
>
>
> ### slave:
>
>
>
> view "insideview" {
>
>       match-clients {
>
>             internal-key;
>
>             !external-key;
>
>             internal;
>
>       };
>
>       server 25.25.25.25 {
>
>             keys { internal-key };
>
>       };
>
>       zone"example.com" IN {
>
>             type slave;
>
>             file "/var/named/db.exampleinside.com";
>
>             masters { 25.25.25.25; };
>
>       };
>
> };
>
>
>
>
>
> Mathew Eis
>
> Northern Arizona University
>
> Information Technology Services
>
>
>
> *From: *project722 <project722 at gmail.com>
> *Date: *Thursday, August 18, 2016 at 8:17 PM
> *To: *Mathew Eis <Mathew.Eis at nau.edu>
> *Cc: *"bind-users at lists.isc.org" <bind-users at lists.isc.org>
> *Subject: *Re: DNS views setup help
>
>
>
> That is correct, as I have not setup the TSIG keys yet.
>
> Also, I am still a bit confused on how this code should be implemented in
> my conf file. In the example you posted that refers back to the link, where
> would I place it in the context of my views on the master? Do I only need
> that one stanza on the master and why in the linked doc does it show it
> listed under the internal view? If that's the designated external key
> should that be placed in the external view and not the internal? And why
> does the internal view in the linked doc show both the external key and a
> "mykey" in the internal view while only showing one for the external view?
> Exactly how many keys do I need here?
>
> Lets say my master server IP is 25.25.25.25 and my slave is 26.26.26.26.
> Using my config from my first email and your code from your reply (lets use
> only the part from the linked doc you wrote) can you provide a modified
> view for internal and external for both the master and slave server?
>
> Sorry for all the questions, its just that I'm very new to this view
> thing, as you might have guessed:)
>
>
>
> On Thu, Aug 18, 2016 at 9:50 PM, Mathew Ian Eis <Mathew.Eis at nau.edu>
> wrote:
>
> I think you are pretty close. One detail that you appear to be missing are
> is in the linked document:
>
>
>
> server 10.0.1.1 {
>
> /* Deliver notify messages to external view. */
>
> keys { external-key; };
>
> };
>
>
>
> Your slaves should have a similar statement in each view with the IP of
> the master and the relevant key for that view.
>
>
>
> Two other things we have learned in deploying this:
>
>
>
> * It is helpful to change your allow-transfer section to be key-based
> per-view instead of IP based to save you from accidental zone transfers
> when other configuration errors are made.
>
> * The match-clients rule can be prepended with a key/!key set to prevent
> accidental communication on that view when using keys; e.g.
>
>
>
>         match-clients {
>
>                 # key matching rules
>
>                 key admin-internal;
>
>                 !key admin-external;
>
>                 key slave-internal;
>
>                 !key slave-external;
>
>                 # ip/acl matching rules
>
>                 internal-ips;
>
>         };
>
>
>
>
>
> Regards,
>
>
>
> Mathew Eis
>
> Northern Arizona University
>
> Information Technology Services
>
>
>
> *From: *bind-users <bind-users-bounces at lists.isc.org> on behalf of Brian
> Pugh <project722 at gmail.com>
> *Date: *Thursday, August 18, 2016 at 7:15 PM
> *To: *"bind-users at lists.isc.org" <bind-users at lists.isc.org>
> *Subject: *DNS views setup help
>
>
>
> I am running bind 9.8.2 on a pair of RHEL 6 DNS servers.. One server is
> the master, one is the slave. My goal is to setup 2 views so that our
> internal folks can resolve hostnames to internal IP's while still allowing
> our external customers to resolve from the outside. Both of these servers
> are external facing and have only one public IP each. First of all I would
> like to know if what I am trying to achieve is even possible with my
> current setup. What we have are internal users that are trying to access
> internal resources via a domain name that only exist in our external DNS.
> We do not have an internal zone for this domain or a inside DNS server that
> we can point them to in order to get a result for the query. So that leaves
> us looking at views for the solution.
>
> To be more precise, this is what is happening now.
>
> Internal client > looks up host that's actually on the internal network
> but resolves to an external IP. The problem with this is 2 fold.
>
> 1) DNS returns an external IP
>
> 2) Since the resource is internal, the traffic flow to the outside and
> back in happens on the same outside interface, which results in a hairpin,
> which we do not allow.
>
> Now, what I was told is that a DNS view type solution would not be
> applicable to the hairpin. My understanding is that internal clients query
> the server already to get results for external IP, so if we had a zone file
> in a view that had internal mappings, this would work and the internal user
> could access the resource since they are now being pointed to an internal
> IP.
>
> So what I want to do is setup an "internal" view for the zone in question
> that points to a db file with the internal IP of that host, and an external
> view for everyone else.
>
>
>
> My questions is:
>
> 1) Would DNS views work for my use case now that my server layout has been
> described?
>
> If so I need help in setting up TSIG because in my test lab everything
> seems to work except that on my slave server my zone in "view A" is being
> updated with the data from the master server from "view B". And view B
> seems to be in sync on both servers, although it seems when I update zone
> files I have to restart instead of a reload to get the zones to update.
> Even then, that does not always work. There is a link I found online that
> says TSIG would be the solution for this but it gives very little details
> on what the config is doing, so I do not know how to make TSIG work in my
> environment. This is the link I found:
>
> https://kb.isc.org/article/AA-00295/0/How-do-I-share-a-
> dynamic-zone-between-multiple-views-.html
>
> Here are the relavent parts to my config as it stands now from the master.
>
> acl internal {
>
> 1.2.3.4; // public IP coming from the inside users
>
> };
>
> acl external {
>
> 5.6.7.8; // everyone else
>
> 9.10.11.12;; // everyone else
>
> };
>
> view "insideview" {
>       match-clients { internal; };
>
>       zone"example.com" IN {
>       type master;
>       file "/var/named/db.exampleinside.com"; // this db file will be
> shown to the clients in the internal ACL and map back to internal IP's
> };
> };
>
> view "extview" {
>       match-clients { external; };
>
> zone"example.com" IN {
>       type master;
>       file "/var/named/db.exampleoutside.com";
> };
>
> The conf from the slave is identical to the above. Can anyone help me by
> showing me what a TSIG config would look like for my environemnt?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160821/4d347051/attachment-0001.html>