Hacker News Reader

Comment by jeroenhd | Hacker News Reader

The only proper way to do internal DNS is to register a domain. Even a free one will do.

The more people follow decent practices at home, the fewer businesses will accidentally break because on of the admins thought it'd be alright because it works for them at home. If you set your DNS domain correctly you can also save yourself some typing effort because DNS will automatically append the network name (so you can http://test instead of http://test.internal or http://test.hamu.co). As an added bonus, you can get valid TLS certificates for your internal network devices without messing with a certificate authority of your own!

View on HN

It's terrible that the spec doesn't reserve something like .localdomain that is unregisterable so that DNS servers can use it for internal use.

.test doesn't quite cut it.

You could propose this to be implemented, surely?

It's already being proposed by one of my colleagues. See: https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00

It does seem much, much more likely that .internal will be definitely reserved for this purpose than that it will ever be delegated as an actual real TLD. If you have to pick a fake TLD to use that isn't one of the 4 mentioned in RFC 2606 that has the best chance of actually being reserved for this purpose in the future, then .internal is it.

I do have a domain but I don't want to enter my private IP addresses on a public DNS. Hence I just have server.internal to point to the correct IP address on my local DNS server and have service1.server.com, service2.server.com, etc. all just CNAME to server.internal.

You can continue using /etc/resolv.conf to specify the private IP addresses even for a website that does actually exist. The point of registering the domain is to ensure that your computer/software can't ever accidentally hit anything you didn't intentionally configure that is actually under the control of someone else. You don't actually need to use publicly visible DNS to configure your internal network just because you used a real domain name.

You don't need to disclose anything on the public DNS. Just register the domain, then use it internally.

For example, if you buy "example.com", just set your public DNS (assuming your registrar provides one) to resolv it to 127.0.0.1, then add your internal hostnames and IP addresses to your internal DNS. If you do it that way, "my-server.example.com" will simply fail to resolve unless you're on your internal network and you don't have to worry about any issues with using the reserved *.internal domain.

I need to have the public DNS anyways so I find this way to be easier. I'd have to use CNAMEs anyways since the .internal addresses have to resolve to different IP addresses depending on the context.

Why would your A records change depending on context? Do you have separate networks where "server.localdomain" has different IPs? The typical way to solve that is to use different sub-domains for each one.

For example if you have a home network and a testing network, you could have one on home.example.com and the other at lab.example.com, in which case your servers would be server.home.example.com and server.lab.example.com. If you use DHCP on those networks, you simply set the domain and search-domain options and you can just enter "server/" on the devices that moves between them.

You only need to register example.com with a registrar, then you can use whatever subdomains you want wherever you want.

> Why would your A records change depending on context?

Good grief, usually it's because of a hairpin nat. People do that to themselves. They damage their own L3 networking and then decide that they need to damage also their entire DNS as a workaround.

It's a regular mind virus, because it's easy to implement split-horizon DNS but enormously expensive to remove it. People get used to it on one company and go and spread it on another company.

Just do a snat+dnat. These networking boxes are so expensive because they are meant to handle it, so let them do their job already. Or go IPv6 and get rid of DNAT altogether.

If you have a local DNS server, you can just have the service1.yourdomain.com only resolve there. Totally standard practice.

My local DNS server can't resolve certificate verifications so I need a public DNS server anyways.

> don't want to enter my private IP addresses on a public DNS

Why not?

Reply on news.ycombinator.com