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....@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 <project...@gmail.com> > *Date: *Thursday, August 18, 2016 at 8:17 PM > *To: *Mathew Eis <mathew....@nau.edu> > *Cc: *"bind-users@lists.isc.org" <bind-users@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....@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-boun...@lists.isc.org> on behalf of Brian > Pugh <project...@gmail.com> > *Date: *Thursday, August 18, 2016 at 7:15 PM > *To: *"bind-users@lists.isc.org" <bind-users@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? > > > > > > > > > > > > > > > >
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users