> 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 <[email protected]>
Date: Thursday, August 18, 2016 at 8:17 PM
To: Mathew Eis <[email protected]>
Cc: "[email protected]" <[email protected]>
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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> on
behalf of Brian Pugh <[email protected]<mailto:[email protected]>>
Date: Thursday, August 18, 2016 at 7:15 PM
To: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
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<http://example.com>" IN {
type master;
file "/var/named/db.exampleinside.com<http://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<http://example.com>" IN {
type master;
file "/var/named/db.exampleoutside.com<http://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
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
