Intranet NameServer for Public Domain

Question

I have registered a domain name domain.co and have a intranet DNS server (BIND) which is serving the queries. I want this domain and dns to be discoverable by anyone in the network without making any changes on their system.

So, I have another domain example.com where I have added A records pointing ns1.example.com -> 10.10.0.1 and ns2.example.com -> 10.11.0.1

Now I have changed the name servers of domain.co (to ns1.example.com , ns2.example.com)

But when I try to resolve the domain name I get server fault. [Note: the DNS have propagated already]

$ dig stage.domain.co

; <<>> DiG 9.9.5-3-Ubuntu <<>> stage.domain.co
;; global options: +cmd
;; connection timed out; no servers could be reached

But dig stage.domain.co @ns1.example.com returns properly.

$ dig stage.domain.co @ns1.example.com

; <<>> DiG 9.9.5-3-Ubuntu <<>> stage.domain.co @ns1.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17613
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;stage.domain.co.       IN  A

;; ANSWER SECTION:
stage.domain.co.    86400   IN  A   10.11.8.35

It works if I update /etc/resolv.conf to point to my dns server and everything works. What I want to achieve is it work normally without any change in the resolv.conf machines in my network can directly query my intranet dns server.

Why does it throws server-fault when directly querying for the domain name? Is it because its intranet ip ? I want those to be resolvable to my intranet machines only.

EDIT : Figured out the reason, as falcon suggested, local systems do not recursive resolve the dns rather query provider provided recursive dns resolvers ( like google dns/open dns) and they will not be able to access the intranet nameserver, hence it fails. It works when a local recursive dns resolver is deployed and used as dns source.

At this point I recommend reading a book on DNS, or hiring a professional to help you. As Falcon said, you should not be trying to define RFC1918 glue records at the registrar level. Beyond this, you mention not wanting to use internal DNS servers for your internal domains, and it requires a good understanding of DNS, UDP, and network design to accomplish something like that securely. — Andrew B, Aug 09 '14 at 16:45
Hi, I am already running internal DNS server. I just had that as a background to my question( updating my question to remove that since I assume its confusing). What I just want that my dns servers are directly resolvable from my network machines without directly pointing to my dns machine. — kingster, Aug 09 '14 at 21:18
Your `resolv.conf` needs to list IP addresses for servers. So your new name servers simply have to have the same IP as the old ones. Their names are somewhat irrelevant at that level. I suppose you ~might~ be able to put host-names instead of IP addresses in `resolv.conf` if those host were also listed in `/etc/hosts`, but I think that's a really bad practice. — ericx, Aug 09 '14 at 22:46

Falcon Momot · Accepted Answer · 2014-08-09T16:51:05.910

No, you should not add RFC1918 IP addresses to public glue records. There are a few reasons for this:

If your internal hosts use a DNS server outside the LAN where the RFC1918-addressed authoritative nameservers are, a SERVFAIL will result for obvious reasons
It adds garbage to the set of glue records
It will have unintended consequences if a resolver in a different LAN can in fact contact a DNS server on the specified RFC1918 address and a malicious one is there
It provides probably undesired visibility into your network

You can really do one of two things.

The typical solution is to set up conditional forwarders on the DNS servers used in your intranet (and do not set glue records with the registrar). You should be running one anyway so you can take advantage of caching.

The other solution is to use a pair of publicly-routed IP addresses and host DNS servers on them, but use an ACL such that only hosts from your LAN are allowed to query them, and ensure they are only reachable from your intranet. This method would be appropriate in an IPv6 environment, but is awkward in IPv4.

It's worth noting as well that most computers are not recursive DNS resolvers; only recursive DNS resolvers look at the glue records or the root. Unless the computer is running a DNS daemon (like bind), chances are it isn't a recursive resolver, and just sends its query to a configured DNS server. That's why this system doesn't work like you think it does.

Thanks, I got that RFC1918 point, thats why I had added ns records via A address at example.com. So It looks like domain.co -> ns1.example.com -> private ip. Thats why when I run dig stage.domain.co @ns1.example.com it properly responds. But otherwise it fails — kingster, Aug 09 '14 at 21:14
Probably the last thing that you mentioned is what is happening. Thats why it works when I manually point the dns server to use, otherwise it doesnt work. — kingster, Aug 09 '14 at 21:25
Yes, that is exactly what is happening. You should never set names that resolve to even one RFC1918 or non-internet-routeable IP in NS records in the same delegation tree as the public `.`. — Falcon Momot, Aug 09 '14 at 21:48

Intranet NameServer for Public Domain

1 Answers1