I have a domain (lets say
example.org) that hosts different public online services on different subdomains (for example
www.example.org). I am also using a subdomain of that domain (
*.in.example.org) internally to address private systems. The private zone
in.example.org is managed by an internal Bind DNS server with a private IP (lets say
192.168.2.30). Until recently, I have been using Google’s Cloud DNS, where I always had the following NS record created for the
in.example.org. NS 192.168.2.30
That allowed me to resolve any internal service IP from any machine in any network without having to manually change my DNS server to
192.168.2.30 - I could just leave it on the public server, which had the zone delegation set up.
But here comes the problem: Cloudflare does not allow me to set up NS records that point to IP addresses. I have tried to create an A record for
ns.example.org that points to my internal DNS servers IP, and then delegate the in.example.org zone to
ns.example.org, but that always results in SERVFAILs. Is a setup like this not possible with Cloudflare or am I missing something?
I think in this case, Cloudflare is actually abiding by the spec -
NS records should point to a domain name, not an IP address.
A <domain-name> which specifies a host which should be authoritative for the specified class and domain.
The NS RR states that the named host should be expected to have a zone
starting at owner name of the specified class. Note that the class may
not indicate the protocol family which should be used to communicate
with the host, although it is typically a strong hint. For example,
hosts which are name servers for either Internet (IN) or Hesiod (HS)
class information are normally queried using IN class protocols.
However, what would stop you from making an A record (unproxied, grey cloud) for
internal.ns.example.org that points to
220.127.116.11 and then pointing the
NS record to
That’s just a guess off the top of my head, might be a glaring issue with that idea but I don’t see why it wouldn’t work.
You are correct, I had actually never looked into the specs before because IPs always seemed to work for me. Your workaround was also one of the first things I have tried - these are the records I defined on Cloudflare:
ns1-in.example.org. A 192.168.2.30
in.example.org. NS ns1-in.example.org
But when I then execute an
nslookup test.in.example.org clarissa.ns.cloudflare.com, I don’t get a result back. If I do an
nslookup test.in.example.org 192.168.2.30, the IP is returned just fine. Is there something else I’m missing?
I think it’d just be
nslookup test.in.example.org - asking
clarissa.ns.cloudflare.com to find
test.in.example.org means it’d be trying to ask
ns1-in.example.org where to find
test.in.example.org - which it can’t talk to since it’s an internal IP address.
Letting it figure out on it’s own which nameserver to query should (hopefully) tell your client to go ask
ns1-in.example.org - which is
192.168.2.30 - where to find
At least that’s how I’d interpret it - but Cloudflare’s nameservers aren’t a recursive DNS resolver like 18.104.22.168/22.214.171.124 and only answer for Cloudflare zones so my thinking might be off.
Correct… even if test.in.example.org was on a public DNS server other than clarissa.ns.cloudflare.com it wouldn’t’ answer because it isn’t recursive. In the resolution process at the .in.example.org point a recursive resolver would be given
ns1-in.example.org as the authoritative NS and the recursive resolver would then as it.
In this example unless the recursive resolver was on the private network (e.g. a Windows DNS server on the LAN) the lookup would fail.
I do this exact use case for one of our internal zones which is a subdomain of a public zone. Previously the public zone was split horizon, but when the split horizon was not needed we still had the internal only subdomain, so went this route. The internal recursive servers have no knowledge about the private authoritative servers for the subdomain (no forwarders etc). The Cloudflare records look like this:
example.com IN NS mother.ns.cloudflare.com
example.com IN NS father.ns.cloudflare.com
ad.example.com IN NS dc1.ad.example.com
ad.example.com IN NS dc2.ad.example.com
;Glue needed for those records.
dc1.ad.example.com IN A 10.0.0.1
dc2.ad.example.com IN A 10.0.0.2
The recursive needs to be able to query 10.0.0.1/2 or this will not work. The assumption is that if these are Private NS IP addresses the client is using Private resolvers anyway, so generally not going to be an issue.
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.