Hacker News Reader

Hacker News

Comment by BillinghamJ | Hacker News Reader

Parent Full thread

BillinghamJ

Serve the internal IPs from public hostname DNS records?

Internal DNS I think is largely not a good thing and I'd be happy to see it go.

View on HN

As a sysadmin I disagree strongly.

Being able to host my own authoritative servers for my domains inside my org is a fantastic feature of DNS.

It lets me do things like split-horizon, which lets me deal with clients coming from different origins that may reach certain servers with or without NAT.

I'm also not keen on putting all my records on public name servers, for everyone to discover.

You could run your own DNS server. As long as you can get the relevant TLS cert, it doesn't even need to be public. You just would need to accept DOH connections

First thing that comes to mind with this idea is that Active Directory is going to be around for a long while yet.

Second, my network filters DNS rebinding, expect from plex.com. I guess I could ad my domain to it, but that's an extra point of failure.

Could you develop ? You think you should answer with internal IPs with external DNS records and everything is addressed at the routing level ?

The DNS zone would be public and tied to a real domain. So both private and public clients would be able to query Eg:

  ci.myorg-int.com -> 10.11.12.13

One advantage of such method is that it is possible to re-use the public CA infrastructure to provision services with TLS certificated. It also means that services can easily be migrated to public IPs once they are secured on the endpoint.

The downside is that now all the internal services are discoverable using DNS scanning techniques. It means that competitors can see what services the organisation is using. Or attackers can better prepare themselves for infiltration.

Another downside of DoH is that it's not possible to filter out DNS rebinding attacks. For example and attacker can trick your browser in requesting a resource from xxx.somedomain.com that points to 10.11.12.13. If the CI is vulnerable to CSRF then the attacker can use the browser to exfiltrate information or do some actions on the CI.

> Another downside of DoH is that it's not possible to filter out DNS rebinding attacks.

Your web server should be configured to not serve content just by IP and require Host header to be a domain you control. (like using server_name in nginx) Otherwise they can just point to 10.11.12.13 directly anyway.

Sure, the web server SHOULD... but what if it is misconfigured? Or doesn't have an option to properly validate the Host header?

This is an internal client using an internal IP address to communicate with an internal service... just so happens that a malicious user made the internal client talk to it maliciously.

DNS rebinding attacks being stopped by the resolver are a great place to start and something we can do. Bypassing that protection in the name of resolving using DoH just means you've made things less secure.

I agree. I think DoH should be put on the edge of the network, using something like dnscrypt-proxy.

I don't think it should be put in the browser. It would actually made my setup less private, since I use DoH over tor.

Though configuring the http servers (like printers or whatever) and/or putting them behind a proxy on a sparate network, if they are sensitive/not configurable, should be done too.

> Your web server should be configured

I think you underestimate the number of things on your network that run unconfigurable web servers.

DNSMASQ lets you luckily whitelist certain domains from dns rebinding protection (like Plex, which relies on resolving to internal IPs). I'm still not comfortable exposing internal network details to the internet however.

Reply on news.ycombinator.com