Internal and External DNS from Different Servers, Same Zone
Solution 1
What you'll want to do is create a DNS zone for testing.webdomain.com on your internal DNS server. This way the webdomain.com DNS isn't hosted by your internal server, but is instead hosted by dotster.
When someone queries for www.webdomain.com the request will be forwarded to dotster for the lookup (since your local DNS server isn't authoritative for that zone), while requests for testing.webdomain.com will be handled by your internal DNS server.
Solution 2
You need Split-view DNS. For your border machines, use an external resolver. For your test environment, use a separate, internal resolver. The internal resolver will have your testing entry in DNS and answers from one view; but the outside world will see a different "view" of your zone, that omits the test environment.
Other SF entries that may be of interest:
I only have time today to skim your extended post, so here's a first glance:
options {
directory "/etc/bind";
listen-on { // why are these lines needed?
10.0.1.5; // the way it is set up, only your loopback
127.0.0.1; // and your LAN clients will be able to
// get answers; the outside world can't see boo
// because there's no interface/port pair
// to contact. I would just get rid of this and
}; // not worry about what interfaces are being bound to
// BTW, that listen-on line is why your outside queries are failing.
auth-nxdomain no;
allow-query { any; };
recursion no;
version "0";
};
Also, the external match-clients statement
view "external" {
match-clients { !localnets; any; };
can be made into
view "external" {
match-clients { any; };
because when you add to match-clients, it's already assuming that there's nothing to match to begin with; negating an ACL really won't add much (because it never "existed" in that view to begin with, so there's no reason to cancel it out).
I'm sure that I've probably missed some things, but these are the most obvious culprits.
Solution 3
It seems your zone definition is not correct. It misses the IP address for the name server declared as "webdomain.com".
I suggest you change the zone definition as
$TTL 604800
@ IN SOA webdomain.com. email.webdomain.com. (
4 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS webdomain.com.
webdomain.com. IN A 10.0.1.5
test IN A 10.0.1.20
then restart the server (e.g. /etc/init.d/bind9 restart
).
Since the zone could not be loaded, due to the error, the domain could not be resolved.
Solution 4
On your Windows DNS server setup a new ZONE for testing.webdomain.com. When you add the first host leave the name field blank and put in the IP address you want internal users to resolve to.
This server will be authoritative for that zone, so any requests will get directed to that IP so it won't conflict with your external resolution.
I use this at all my sites for mail.corpdns.com (because users never remember to use the internal server name when trying to access webmail, etc.).
I suspect this can be done in Linux/Bind as well, but I don't know the steps.
Related videos on Youtube
Shane
I am a web application developer who lives in Bowling Green, KY and works in Nashville, TN.
Updated on September 17, 2022Comments
-
Shane almost 2 years
I am either having trouble understanding how DNS works, or I am having trouble configuring my DNS correctly (either one isn't good). I am currently working with a domain, I'll call it webdomain.com, and I need to allow all of our internal users to get out to dotster to get our public DNS entries just like the rest of the world. Then, on top of that, I want to be able to supply just a few override DNS entries for testing servers and equipment that is not available publically. As an example:
- public.webdomain.com - should get this from dotster
outside.webdomain.com - should get this from dotster as well
testing.webdomain.com - should get this from my internal dns controller
The problem that I seem to be running into at every turn is that if I have an internal DNS controller that contains a zone for webdomain.com then I can get my specified internal entries but never get anything from the public DNS server. This holds true regardless of the type of DNS server I use also--I have tried both a Linux Bind9 and a Windows 2008 Domain Controller.
I guess my big question is: am I being unreasonable to think that a system should be able to check my specified internal DNS and in the case where a requested entry doesn't exist it should fail over to the specified public dns server -OR- is this just not the way DNS works and I am lost in the sauce?
It seems like it should be as simple as telling my internal DNS server to forward any requests that it can't fulfill to dotster, but that doesn't seem to work. Could this be a firewall issue?
Thanks in advance
EXTENDED
OK, so I did a bunch of research and have been plugging at this for a few hours. I have this in my named.conf and I am STILL seeing the same result. Internal calls are fed, but anything external (in the zone controlled domain) is just dumped. Any assistance would be great! Also, this is an Ubuntu 9.04 OS I am working with.
Code removed because it was wrong.
THE CORRECT WAY -- ADDED AFTER QUESTION CLOSED
Well, thanks to the folks here on serverfault I now have this working perfectly on my server and in a much more succinct fashion. Here is how you do it. From a base install of bind9 edit your named.conf.local file and add in a zone for EACH subdomain that you want to redirect:
/etc/bind/named.conf
// WEBDOMAIN.COM ENTRIES zone "test.webdomain.com" { type master; file "/etc/bind/zones/test.webdomain.com"; }; zone "alpha.webdomain.com" { type master; file "/etc/bind/zones/alpha.webdomain.com"; }; zone "beta.webdomain.com" { type master; file "/etc/bind/zones/beta.webdomain.com"; }; // INTERNETSITE.COM ENTRIES zone "internal.internetsite.com" { type master; file "/etc/bind/zones/internal.internetsite.com"; }; zone "dev.internetsite.com" { type master; file "/etc/bind/zones/dev.internetsite.com"; };
Edit your /etc/bind/named.conf.options file and add any forwarders you want to use into the correct location:
/etc/bind/named.conf.options
options { directory "/var/cache/bind"; forwarders { 208.67.222.222; 208.67.220.220; 8.8.8.8; 8.8.4.4; }; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; };
Create a new folder called zones at /etc/bind/zones/ and add a new file for EACH of the zones you created above that match the 'file' attribute above. Using test.webdomain.com as an example:
/etc/bind/zones/test.webdomain.com
$TTL 604800 @ IN SOA test.webdomain.com. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS test.webdomain.com. test.webdomain.com. IN A 10.0.1.20
Where 10.0.1.20 is the A record ip address that you want this (sub)domain to forward to. By doing it this way the record for test.webdomain.com is authoritative for only the subdomain and the global DNS will supply any other subdomains or root domains as usual.
-
Déjà vu over 13 yearsJust a stupid question: is your resolv.conf file set to your bind server?
-
Shane over 13 years@ring0 - Yes, I have my internal ip as well as 127.0.0.1 set as nameservers in the resolv.conf file.
-
Avery Payne over 13 yearsDon't ever use YOURSELF as a resolver. That defeats the purpose, and can lead to other nastiness. Remove the loopback (127.x) entry.
-
voretaq7 over 13 yearsThis would be my preferred solution as it lets you override other hosts under
webdomain.com
-- mrdenny's solution below also works & is simpler to implement, but you can only override hosts undertesting.webdomain.com
-
Shane over 13 years@voretaq7 - Thanks a ton for the suggestion, I have looked up split views and seem to be having trouble getting it to work still. If you have a sec could you take a look at the extended question?
-
Avery Payne over 13 yearsHe's doing something akin to split-view by using two different DNS servers - one you control in-house, and on that is public. The difference is that you could make it work provided you point all of your internal LAN clients to the internal DNS server only (to prevent mix-ups with answers coming from the outside, which will NOT have your hidden-from-view hostnames)
-
Avery Payne over 13 years+1 for the simple solution
-
Shane over 13 yearsI finally got a chance to get back to this, and I made the suggested adjustments above but to no avail. I restarted the bind server, force-killed my browser, flushed my DNS cache and still external domains (of the same zone) are denied. Could you possibly suggest some other modifications I could attempt -OR- if I am just completely wrong could you suggest some working code to start from? I hate going to all of this trouble to forward 4-5 internal domains, but I guess this is the best/only way.
-
Shane over 13 yearsI tried this approach as well, but I am havinga similar issue. I completely re-rolled my bind server to start from scratch, and in my named.conf.local I set up a zone for test.webdomain.com and a corresponding zone file. When I test it I am able to get to external DNS but I can't get the bind server to ever serve up the single zone that I have loaded. frustration
-
Shane over 13 yearsGreat, I'll switch back to my windows DNS server and give it a go. I am a linux guy at heart, but if I can get this fixed I'll use anything (even if it doesn't have a penguin on it).
-
Shane over 13 yearsYou know, I kept staring at that specific entry and thinking that it didn't feel right, I just wasn't sure exactly what to do with it. I'll give it a try!
-
Déjà vu over 13 years@Shane I didn't find a problem within the named.conf, so the zone was my last option :-)
-
Shane over 13 yearsWell, this was the fix. I had a typo in my zone file but after finding that error it was all working just perfectly. Thanks mrdenny. As soon as I am allowed I will award you with the bounty as well!
-
BillThor over 13 years
named-checkconf
andnamed-checkzone
are useful to verify your configuration. The-p
option is useful to dump a clear interpretation of your configuration, especially if you use include files. -
Déjà vu over 13 years@Shane I thought the fix was from my answer...
-
Ryan Ferretti over 13 years@Shane glad you've got it fixed and working correctly.