Reply
Highlighted
Accepted Solution

DNS Views for Split-Tunnel VPN

Authority
Posts: 24
10701     1

Hello.

We're about to add VPN Split-Tunneling for our Lync/Skype services, so they do not traverse the VPN. However, in order to do that we will need to create DNS Views so that the VPN clients receive different responses to DNS queries. As it's a production system I'm concerned about screwing this up.

In the Infoblox documentation, the examples seem to always use an internal view (matching internal network subnets) and then an external view (matching all). In our case, we need it the other way around. Match on a pair of /20 subnets that are used for VPN client user assignment to be given the "vpn" view, and then everyone else gets the "default" view. All of the zone records in our Infoblox system are internal services - our DNS for our publicly routable IP subnets are handled by an external service.

The other thing we want to avoid is to have to create new records going forward in both views.

So basically, for VPN clients on the /20, if they do a lookup for "meet.example.com, the "vpn" view will hand them 161.X.X.X, instead of the 10.X.X.X address that the default view would hand out. However, if the VPN client's request isn't for one of the A records in the vpn view (a host that isn't related to Lync/Skype), it will automatically check for the response in the default view. Is this clear enough? I don't want to have to create records in both views for things unrelated to Skype/Lync. Basically, the "vpn" view only has about 20 records in it (that override what's in the default view). 

If you need additional detail or a diagram to make it clearer, please let me know.

Re: DNS Views for Split-Tunnel VPN

Authority
Posts: 24
10702     1

Figured I'd throw in a diagram too, if that helps. lync-diagram.png

Re: DNS Views for Split-Tunnel VPN

Adviser
Posts: 213
10702     1

Views complicate matters so you'll definitely have to be careful on setting this up.  You can do what you need to do but it will involve some forwarding from one view to another.  You'll define the "vpn" view with the limited network ACL as you indicated.  You'll configure that view to forward to another DNS IP address (which could be serviced on the same member...or maybe not depending on where you data resides and how complex the configuration needs to be).  Just make sure your "vpn" view is at the TOP of the list and your "default" view follows (since it won't have an ACL).  The Grid should automatically manage that view ordering for you but it's sometimes good to double check and make sure it got ordered properly.

 

An alternative approach, if you have at least TE-1400 series appliances, is to use DTC (DNS Traffic Control).  Then you can create rules for different clients and direct them where you want them to go.  This minimizes the distraction and comlication of managing multiple views and hoping everything is working correctly.

 

Re: DNS Views for Split-Tunnel VPN

Authority
Posts: 24
10702     1

That's some great feedback and I appreciate it. 

 

I was looking at Shared Record Groups but if there's a way to simply point unresolvable hosts in the vpn view to a "I don't have an answer for that, use this other view" rule of some kind, that would definitely be the optimal way for me.

 

Please also understand I'm a network engineer (Juniper specifically) so DNS is a bit of a foreign thing to me beyond simple A records. 

 

Can you tell me what part of the documentation I should be looking at to do the "forward to another DNS IP address" part of your suggestion? Won't the address I've forwarded it to (being also the infoblox server) look at the source IP of the request and just plop it back into the vpn zone?

Re: DNS Views for Split-Tunnel VPN

Adviser
Posts: 213
10702     1

Good question about the "next" DNS server in the chain.  Actually, once the first DNS server gets the packet, any "forwarding" is actually a whole new query FROM the DNS server so the target DNS server (the forwarder) will process the query based on the IP address of the forwarding DNS server.  This is why troubleshooting can be complex since many people don't understand this traffic flow and the "recreation" of packets along the way.

 

As for the manual, depending on what version of code you're working with, look for the following:

 

  • Defining multiple forwarders
  • Using Forwarders

 

You are also going to want to look at any text on Views (for defining the ACLs...although this is easy in the GUI) and then setting up loopback IPs (one possible approach) for the members.

 

The Admin Guide is really about the "how-to configuration" steps and less about the "why" you would take a particular approach.  You may have to do a little Internet hunting to relate the tasks to your environment.  If your budget allows, I'd suggest talking to your SE and see if you can get some assistance from PS.  You can discuss whether there's enough work and budget to have someone onsite or, if not, have someone spend some time working with you via WebEx (and perhaps use less time).

Re: DNS Views for Split-Tunnel VPN

Authority
Posts: 24
10702     1

Ah, the "whole new query" part makes it all make sense. 

 

So, I just need to apply a forwarder to the VPN view so that anything not in the view gets forwarded. That seems straight forward enough.

 

I'll look into talking to the SE. I opened a ticket as well looking for some assistance but was basically told "talk to your account team and RTFM". The information you provided is 1000x more helpful, so thank you! 

Re: DNS Views for Split-Tunnel VPN

Adviser
Posts: 213
10702     1

Yep, you're on target now.  Glad I could help.

 

If you do run into something specific or want to post some screen clips, do so and I'm sure myself or someone else can provide some additional feedback.

Re: DNS Views for Split-Tunnel VPN

Authority
Posts: 24
10702     1

@DSmith wrote:

You'll configure that view to forward to another DNS IP address

 


Hello again. I'm trying to figure all this out. It doesn't seem like I can configure forwarders on a per-view basis, and that they are configured for the entire grid. I'm not sure where to go from here. 

 

I have a test grid setup in VMware using vNIOS, with a couple client VMs as well. The view I set up is configured so that only the second host sees that view. It's also at the top of the views list.

 

Any suggestions on how to proceed? 

Re: DNS Views for Split-Tunnel VPN

Adviser
Posts: 213
10702     1

If you're only seeing it at the Grid level, then you're likely attempting to edit the Grid DNS settings.  Instead, you need to navigate down to the view level and edit the properties there.  You can also edit settings at the member level but that's NOT what you want here.

 

See the image below and notice the navigation points.

 

Data Management > DNS > Zones

Then, IF you have multiple views defined, you'll see the list like the one shown.  From there, edit the DNS View that relates to your target, switch to the Forwarders property setting and override the value for that view.  This will then get updated on all of the members service that view.  Also, review the Match Clients and/or Match Destinations settings as well to make sure you have everything set up correctly.

 

Screen Shot 2016-09-12 at 4.18.54 PM.png

Re: DNS Views for Split-Tunnel VPN

Authority
Posts: 24
10702     1

Thank you! I see now where you override the forwarders for the view. I've enabled that, but still no luck.

 

For context, my topology consists of:

  • infoblox-01 (192.168.64.101)
  • infoblox-02 (192.168.64.102)
  • ubuntu-01 (192.168.64.201)
  • ubuntu-02 (192.168.64.202)

 

The view is set up so that a host matching 192.168.64.202/32 source address gets that view. This is set up correctly as I'm getting the expected results when I try to resolve the "foo" and "bar" names:

 

cjones@ubuntu01:~$ nslookup foo.lv426.ca
Server: 192.168.64.101
Address: 192.168.64.101#53

Name: foo.lv426.ca
Address: 192.168.64.11

 

cjones@ubuntu01:~$ nslookup bar.lv426.ca
Server: 192.168.64.101
Address: 192.168.64.101#53

Name: bar.lv426.ca
Address: 192.168.64.22

 

cjones@ubuntu01:~$ nslookup google.com
Server: 192.168.64.101
Address: 192.168.64.101#53

Non-authoritative answer:
Name: google.com
Address: 216.58.199.14

 

 

cjones@ubuntu02:~$ nslookup foo.lv426.ca
Server: 192.168.64.101
Address: 192.168.64.101#53

Name: foo.lv426.ca
Address: 111.111.111.111

 

cjones@ubuntu02:~$ nslookup bar.lv426.ca
Server: 192.168.64.101
Address: 192.168.64.101#53

** server can't find bar.lv426.ca: NXDOMAIN

 

cjones@ubuntu02:~$ nslookup google.com
Server: 192.168.64.101
Address: 192.168.64.101#53

Non-authoritative answer:
Name: google.com
Address: 216.58.199.14

 

I have domain lv426.ca set up as authoritative in both views. In the default view I have:

 

- foo.lv426.ca (192.168.64.11)

- bar.lv426.ca (192.168.64.22)

 

In the vpn view I have:

 

- foo.lv426.ca (111.111.111.111)

 

I configured the forwarders for the vpn zone to be: 192.168.64.101, 192.168.64.102. 

 

No luck.

 

To try some other things, I'd heard some people mention using loopbacks in this setup. So, with that in mind, I configured the loopback of infoblox-01 as 1.1.1.1 and the loopback of infoblox-02 as 2.2.2.2

 

I then went under Member DNS properties for each infoblox server and configured them to listen on the additional IP addresses, and also configured the dns view "vpn" as the loopback under the "Address of Member Used in DNS Views" (1.1.1.1).

 

That hasn't worked for me either. I've got to be missing something. 

 

Re: DNS Views for Split-Tunnel VPN

Adviser
Posts: 213
10702     1
Can you post a clean and sanitized version of your named.conf from one of the Infoblox members? I’m looking for mostly just the top portion where the views are defined (for each view). That may help me see something that’s easy to point to.

Re: DNS Views for Split-Tunnel VPN

Authority
Posts: 24
10702     1

Sure. No sanitization required, as it's just a lab.

 

include "/infoblox/var/named_conf/tsig.key";

acl all_dns_views_updater_keys {  key DHCP_UPDATER1; key DHCP_UPDATER_default; };

options {
	masterfile-format text;
	zone-statistics yes;
	directory "/infoblox/var/named_conf";
	version none;
	recursion yes;
	max-recursion-depth 7;
	max-recursion-queries 150;
	hostname none;
	listen-on { 127.0.0.1; 192.168.64.101; 1.1.1.1; };
	query-source address 192.168.64.101 port *;
	notify-source 192.168.64.101 port *;
	transfer-source 192.168.64.101;
	use-alt-transfer-source no;
	minimal-responses yes;
	max-cache-size 56485888;
        lame-ttl 600;

Enter <return> for next page or q<return> to cancel the command.

	tcp-clients 200;
	transfers-in 10;
	transfers-out 10;
	transfers-per-ns 2;
	serial-query-rate 20;
        max-cache-ttl 604800;
        max-ncache-ttl 10800;
	# for service restart: allow_bulkhost_ddns = Refusal
	infoblox-dtc-enable yes;
	allow-query { 127.0.0.1; any; };
	allow-recursion { any; };
	allow-transfer { !any; };
	forwarders { 4.2.2.2; };
	avoid-v4-udp-ports { 2114; 2113; 2115; 3000; 8000; 8089; 9997; 2222; 4040; 5575; 7077; 7911; 7912; 8000; 8089; 9090; 9091; 9997; 8070; 8787; 9999; 9004; 2022; 3374; 3115; 1194; 8080; 9000; 9183; };
	avoid-v6-udp-ports { 2114; 2113; 2115; 3000; 8000; 8089; 9997; 2222; 4040; 5575; 7077; 7911; 7912; 8000; 8089; 9090; 9091; 9997; 8070; 8787; 9999; 9004; 2022; 3374; 3115; 1194; 8080; 9000; 9183; };
	transfer-format many-answers;
};

# Worker threads: default

# Bulk Host Name Templates:
#	Four Octets: 		"-$1-$2-$3-$4" (Default)

Enter <return> for next page or q<return> to cancel the command.

#	One Octet: 		"-$4"
#	Three Octets: 		"-$2-$3-$4"
#	Two Octets: 		"-$3-$4"

# multi-master master selection: 30-5-120-20

include "/infoblox/var/named_conf/dhcp_updater.key";

include "/infoblox/var/named_conf/rndc.key";

controls {
        inet 127.0.0.1 port 953
        allow { 127.0.0.1; } keys { "rndc-key"; };
};

logging {
	 channel ib_syslog {
		 syslog daemon;
		 severity info;
	};
	 category default { ib_syslog; };
};

Enter <return> for next page or q<return> to cancel the command.

# vpn
view "1" {  # vpn
    match-clients { key DHCP_UPDATER1; !all_dns_views_updater_keys; 192.168.64.202; };
    match-destinations { any; };
    forwarders { 1.1.1.1; };
    lame-ttl 600;
    max-cache-ttl 604800;
    max-ncache-ttl 10800;
    dnssec-enable yes;
    dnssec-validation yes;
    dnssec-accept-expired no;
	filter-aaaa-on-v4 no;
    zone "." in {
        type hint;
        file "named.cache.1";
    };
    zone "0.0.127.in-addr.arpa" in {
	type master;
	database infoblox_zdb;
	masterfile-format raw;
	file "azd/db.0.0.127.in-addr.arpa.1";
    };

Enter <return> for next page or q<return> to cancel the command.

    zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" in {
	type master;
	database infoblox_zdb;
	masterfile-format raw;
	file "azd/db.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.1";
    };
    zone "lv426.ca" in { # lv426.ca
	type master;
	database infoblox_zdb;
	infoblox-multi-master automatic;
	masterfile-format raw;
	file "azd/db.lv426.ca.1";
	notify yes;
    };
};
# default
view "_default" {  # default
    match-clients { key DHCP_UPDATER_default; !all_dns_views_updater_keys; any; };
    match-destinations { any; };
    lame-ttl 600;
    max-cache-ttl 604800;
    max-ncache-ttl 10800;

Enter <return> for next page or q<return> to cancel the command.

    dnssec-enable yes;
    dnssec-validation yes;
    dnssec-accept-expired no;
	filter-aaaa-on-v4 no;
    zone "." in {
        type hint;
        file "named.cache._default";
    };
    zone "0.0.127.in-addr.arpa" in {
	type master;
	database infoblox_zdb;
	masterfile-format raw;
	file "azd/db.0.0.127.in-addr.arpa._default";
    };
    zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" in {
	type master;
	database infoblox_zdb;
	masterfile-format raw;
	file "azd/db.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa._default";
    };
    zone "lv426.ca" in { # lv426.ca
	type master;

Enter <return> for next page or q<return> to cancel the command.

	database infoblox_zdb;
	infoblox-multi-master automatic;
	masterfile-format raw;
	file "azd/db.lv426.ca._default";
	notify yes;
    };
};

# Zone OID composite: 4637

Re: DNS Views for Split-Tunnel VPN

Adviser
Posts: 213
10702     1

The config appears correct based on what I can tell from a quick glance.  I see that you're connecting to the appliance in question so it SHOULD be giving you AUTHORITATIVE answers to your questions.  Your previous post is showing something interesting though as you're getting non-authoritative responses and that shouldn't be happening if everything is "live" in memory (meaning the current config file is actually active and not just pre-staged).

 

Can you re-run your tests but instead of using NSLOOKUP (which is actually an unreliable test tool), please use "dig" (which you can do on any Unix/Linux/Mac system or on Windows if you still the BIND tools.  You can also use 'dig' from the Infoblox CLI.

 

If you can capture the results from DIG and they are NOT correct, that will help narrow down where the issue is.  If dig works but NSLOOKUP doesn't, then we know it's a client configuration issue.

Re: DNS Views for Split-Tunnel VPN

Authority
Posts: 24
10702     1

You mentioned getting non-authoritative responses. From what I can tell, that happens only when I do an lookup on google.com, which I would expect to be non-authoritative. Unless I'm not understanding some output.

 

I usually use nslookup (or even just "host") because the output is smaller, but for troubleshooting dig makes more sense. 

 

Here's the output from the host getting the default view:

 

cjones@ubuntu01:~$ dig foo.lv426.ca

; <<>> DiG 9.10.3-P4-Ubuntu <<>> foo.lv426.ca
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27538
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;foo.lv426.ca.			IN	A

;; ANSWER SECTION:
foo.lv426.ca.		28800	IN	A	192.168.64.11

;; Query time: 0 msec
;; SERVER: 192.168.64.101#53(192.168.64.101)
;; WHEN: Tue Sep 13 08:11:24 PDT 2016
;; MSG SIZE  rcvd: 57

cjones@ubuntu01:~$ dig bar.lv426.ca

; <<>> DiG 9.10.3-P4-Ubuntu <<>> bar.lv426.ca
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56465
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bar.lv426.ca.			IN	A

;; ANSWER SECTION:
bar.lv426.ca.		28800	IN	A	192.168.64.22

;; Query time: 0 msec
;; SERVER: 192.168.64.101#53(192.168.64.101)
;; WHEN: Tue Sep 13 08:11:28 PDT 2016
;; MSG SIZE  rcvd: 57

cjones@ubuntu01:~$ dig google.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33117
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		71	IN	A	64.233.189.101
google.com.		71	IN	A	64.233.189.102
google.com.		71	IN	A	64.233.189.100
google.com.		71	IN	A	64.233.189.113
google.com.		71	IN	A	64.233.189.138
google.com.		71	IN	A	64.233.189.139

;; Query time: 0 msec
;; SERVER: 192.168.64.101#53(192.168.64.101)
;; WHEN: Tue Sep 13 08:11:34 PDT 2016
;; MSG SIZE  rcvd: 135

And here is the output from the host that gets the vpn view:

cjones@ubuntu02:~$ dig foo.lv426.ca

; <<>> DiG 9.10.3-P4-Ubuntu <<>> foo.lv426.ca
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64287
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;foo.lv426.ca.			IN	A

;; ANSWER SECTION:
foo.lv426.ca.		28800	IN	A	111.111.111.111

;; Query time: 0 msec
;; SERVER: 192.168.64.101#53(192.168.64.101)
;; WHEN: Tue Sep 13 08:11:03 PDT 2016
;; MSG SIZE  rcvd: 57

cjones@ubuntu02:~$ dig bar.lv426.ca

; <<>> DiG 9.10.3-P4-Ubuntu <<>> bar.lv426.ca
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1625
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bar.lv426.ca.			IN	A

;; AUTHORITY SECTION:
lv426.ca.		900	IN	SOA	infoblox01.lv426.ca. please_set_email.absolutely.nowhere. 6 10800 3600 2419200 900

;; Query time: 0 msec
;; SERVER: 192.168.64.101#53(192.168.64.101)
;; WHEN: Tue Sep 13 08:11:09 PDT 2016
;; MSG SIZE  rcvd: 123

cjones@ubuntu02:~$ dig google.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13150
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		88	IN	A	64.233.189.102
google.com.		88	IN	A	64.233.189.100
google.com.		88	IN	A	64.233.189.113
google.com.		88	IN	A	64.233.189.138
google.com.		88	IN	A	64.233.189.139
google.com.		88	IN	A	64.233.189.101

;; Query time: 22 msec
;; SERVER: 192.168.64.101#53(192.168.64.101)
;; WHEN: Tue Sep 13 08:11:17 PDT 2016
;; MSG SIZE  rcvd: 135

Re: DNS Views for Split-Tunnel VPN

Authority
Posts: 24
10702     1

Also, if you think I should kill the loopback stuff, let me know and I'll gather output after doing JUST the forwarder configuration instead. 

Re: DNS Views for Split-Tunnel VPN

Adviser
Posts: 213
10702     1

What are the IP addresses of the clients where you performed the dig command?

 

ubuntu01 and ubuntu02?

 

If unbuntu02 is 192.168.64.202, then everything is working exactly as it should.  That client should be getting results only from the VPN view.  That means foo has an answer and bar does not.

 

Unbuntu01 would then get an answer from the "default" view and would receive results (as shown) for both foo and bar.

 

Now, if you're thinking that "bar" in the VPN view should resolve to the value in the "default" view, that's NOT going to work.  Since the VPN view has a zone of lv426.ca, EVERYTHING not included is an automatic NXDOMAIN.  To "fix" that, you'd need to define a zone of "foo.lv426.ca" and anything else that falls under lv426 would then forward accordingly.  This can be easy to configure if you're only worried about a few records resolving differently.  If this is going to be something more complex, you'll need another solution (which may mean using DNS Traffic Control -- a.k.a. DTC).

 

Re: DNS Views for Split-Tunnel VPN

Authority
Posts: 24
10702     1

Yes, ubuntu02 is .202. And yes I agree the views aspect is certainly working correctly. 

 

You hit the nail on the head as far as what I'm actually trying to do. Basically infoblox saying:

 

"I don't have bar.lv426.ca in the vpn view, let me forward that to the default view"

 

Your "fix" makes sense to me, I'm just not sure I understand what to actually configure. Within the vpn view I'd create a ZONE called foo.lv426.ca instead of an A record within an lv426.ca zone?  Am I understanding that correctly?

Re: DNS Views for Split-Tunnel VPN

Adviser
Posts: 213
10702     1
Yes, you are understanding correctly. Basically, you’d be defining an “apex” A record. This is common with MSFT and situations like this.


// this gets added in your named.conf file when you create the zone in the UI
zone “foo.lv426.ca” IN {
… usual chatter here
};


Then your zone data looks like…

A record 111.111.111.111


Then a request for “bar.lv426.ca” in the VPN view will get forwarded to whatever destination you’ve configured at the view level. You will likely just target your loopback IP (1.1.1.1) and use the “match destination” and change that from ANY on the VPN view to !1.1.1.1.


This can be fun troubleshooting so make sure to spend a little time reviewing logs while you test. You should see messages showing you that this is working IF you are logging queries (just be careful with that if you are forwarding syslog messages…there’s a performance hit).

Re: DNS Views for Split-Tunnel VPN

Authority
Posts: 24
10702     1

So, that was actually really easy. Here's the views config:

# vpn
view "1" {  # vpn
    match-clients { key DHCP_UPDATER1; !all_dns_views_updater_keys; 192.168.64.202; };
    match-destinations { any; };
    forwarders { 192.168.64.101; 192.168.64.102; };
    lame-ttl 600;
    max-cache-ttl 604800;
    max-ncache-ttl 10800;
    dnssec-enable yes;
    dnssec-validation yes;
    dnssec-accept-expired no;
	filter-aaaa-on-v4 no;
    zone "." in {
        type hint;
        file "named.cache.1";
    };
    zone "0.0.127.in-addr.arpa" in {
	type master;
	database infoblox_zdb;
	masterfile-format raw;
	file "azd/db.0.0.127.in-addr.arpa.1";
    };
    zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" in {
	type master;
	database infoblox_zdb;
	masterfile-format raw;
	file "azd/db.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.1";
    };
    zone "foo.lv426.ca" in { # foo.lv426.ca
	type master;
	database infoblox_zdb;
	infoblox-multi-master automatic;
	masterfile-format raw;
	file "azd/db.foo.lv426.ca.1";
	notify yes;
    };
};
# default
view "_default" {  # default
    match-clients { key DHCP_UPDATER_default; !all_dns_views_updater_keys; any; };
    match-destinations { any; };
    lame-ttl 600;
    max-cache-ttl 604800;
    max-ncache-ttl 10800;
    dnssec-enable yes;
    dnssec-validation yes;
    dnssec-accept-expired no;
	filter-aaaa-on-v4 no;
    zone "." in {
        type hint;
        file "named.cache._default";
    };
    zone "0.0.127.in-addr.arpa" in {
	type master;
	database infoblox_zdb;
	masterfile-format raw;
	file "azd/db.0.0.127.in-addr.arpa._default";
    };
    zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" in {
	type master;
	database infoblox_zdb;
	masterfile-format raw;
	file "azd/db.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa._default";
    };
    zone "lv426.ca" in { # lv426.ca
	type master;
	database infoblox_zdb;
	infoblox-multi-master automatic;
	masterfile-format raw;
	file "azd/db.lv426.ca._default";
	notify yes;
    };
};

Here's the dig output from ubuntu01 (default view only):

cjones@ubuntu01:~$ dig foo.lv426.ca

; <<>> DiG 9.10.3-P4-Ubuntu <<>> foo.lv426.ca
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59921
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;foo.lv426.ca.			IN	A

;; ANSWER SECTION:
foo.lv426.ca.		28800	IN	A	192.168.64.11

;; Query time: 0 msec
;; SERVER: 192.168.64.101#53(192.168.64.101)
;; WHEN: Tue Sep 13 12:17:05 PDT 2016
;; MSG SIZE  rcvd: 57

cjones@ubuntu01:~$ dig bar.lv426.ca

; <<>> DiG 9.10.3-P4-Ubuntu <<>> bar.lv426.ca
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14559
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bar.lv426.ca.			IN	A

;; ANSWER SECTION:
bar.lv426.ca.		28800	IN	A	192.168.64.22

;; Query time: 0 msec
;; SERVER: 192.168.64.101#53(192.168.64.101)
;; WHEN: Tue Sep 13 12:17:09 PDT 2016
;; MSG SIZE  rcvd: 57

And here's the output from dig on ubuntu02 (getting the vpn view):

cjones@ubuntu02:~$ dig foo.lv426.ca

; <<>> DiG 9.10.3-P4-Ubuntu <<>> foo.lv426.ca
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33383
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;foo.lv426.ca.			IN	A

;; ANSWER SECTION:
foo.lv426.ca.		28800	IN	A	111.111.111.111

;; Query time: 0 msec
;; SERVER: 192.168.64.101#53(192.168.64.101)
;; WHEN: Tue Sep 13 12:17:18 PDT 2016
;; MSG SIZE  rcvd: 57

cjones@ubuntu02:~$ dig bar.lv426.ca

; <<>> DiG 9.10.3-P4-Ubuntu <<>> bar.lv426.ca
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52525
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bar.lv426.ca.			IN	A

;; ANSWER SECTION:
bar.lv426.ca.		28614	IN	A	192.168.64.22

;; Query time: 0 msec
;; SERVER: 192.168.64.101#53(192.168.64.101)
;; WHEN: Tue Sep 13 12:17:21 PDT 2016
;; MSG SIZE  rcvd: 57

I actually dumped all the loopback info as it was apparently not necessary to make this work. I just added the IPs of infoblox01 and infoblox02 as forwarders and it "just worked". 

 

I do agree that this is a bit of an unscalable hack, however it's only about 10 addresses we need this for so I think it's manageable for this particular use case. 

 

I think when it comes to actual implementation, I'm going to do it like this:

  1. create the view making sure it's at the bottom of the list
  2. set up the forwarders for the view
  3. add all of the necessary records as "apex" A records
  4. move the vpn view to the top of the list to "enable" it. 

I'm also going to keep doing some more testing but for now I'm pretty happy with these results!

 

Thank you SO much for your assistance! 

Re: DNS Views for Split-Tunnel VPN

Adviser
Posts: 213
10702     1

Glad I could help.  Yes, for a smaller subset of records, this should work fine for you.  If you start getting past that scale, I highly recommend using the DNS Traffic Control license...you'll be able to dispense with views at that point (supposing you are using them only for this anyway).

 

BTW, I have to give credit to one of the guys on my team (Ross) for a name he uses for this configuration.  He calls this a "pin-point zone" configuration.  No different from what you are doing but it adds a "name" to the method.

Showing results for 
Search instead for 
Do you mean 

Recommended for You