4

I recently set up a wireguard server-network configuration with a home server and client devices. I have one main domain that I hope to route everything through via subdomains (in this example, abc.example.com, def.example.com, etc.). I hope to use nginx to do this routing.

Is is possible/secure/recommended to register a private IP address (specifically of my home server within the wireguard network, i.e. 10.27.0.1/24) in a public DNS (e.g. google DNS), so that if you run ping abc.example.com you would get back 10.27.0.1? I found a few questions that answer a question that are close to this one (this one covers private IP for public DNS for MX records, this one talks about having A records without much mention of VPN), and the overall picture I get from these links is that it is possible, but not technically perfect since a hacker gets a small piece of info about your local network (wireguard network is 10.27.0.1/24...isn't this relatively a moot point given it's behind wireguard, assuming I have all of the usual safety checks in place (no remote ssh (root or otherwise) unless on wireguard network, fail2ban, no password authentication for ssh, etc.)?

This IP (10.27.0.1) would be only accessible through the wireguard network, so I don't think it would expose the services to the internet. I want to do this so that I don't have to setup local DNS entries on each device, as I don't believe this is possible on a phone, and it would be ideal to make one change [i.e. set the DNS entry to 10.27.0.1] and then have each device just running a simple DNS query for abc.example.com. This would also have the added benefit of only opening the wireguard port, and keeping the firewall closed for 80 + 443.

A corollary of this question is how best do you manage certs/ssl if this is possible? I managed to get certbot working by temporarily exposing port 80 on my server to acquire the certs for abc.example.com, and then closing 80 to only access the webserver via wireguard through the wireguard port + nginx. I can already see one downside to this method - having to manually open port 80 everytime certbot wants to get new certificates (I believe by default this is every 60 days). I understand that wireguard is approximately as secure as SSL/HTTPS, but for my personal OCD I would prefer to have the connection secured through https on top of wireguard. I'm somewhat iffy on the details of managing certs for wildcards, but could I do it with my main example.com (that is pointing to a internet facing site) and have it propagate to the subdomains, allowing it to be renewed through that? (this question seems to indicate so)

My goal long term is to expand this into a network that includes family/close friends as a type of 'intranet' for sharing photos and using other self-hosted services.

My nginx config file (abc.conf) looks something like this:

server {

  server_name abc.example.com;
  # DNS Entry of abc.example.com is 10.27.0.1, which is the local IP for the wireguard network
  # SHOULD NOT be accessible outside of wireguard network

  location / {
      proxy_pass http://127.0.0.1:8000; #Redirects to local service on port 8000
  }


    listen [::]:443 ssl; # managed by Certbot
    listen 443 ssl; # managed by Certbot

    // SSL Certs provided by certbot [removed manually]
    // .
    // .
    // .

}
7
  • 1
    One possible approach: split horizon DNS. Not saying you must do it, but it is one possibility.
    – Kate
    Jul 19, 2020 at 19:01
  • 1
    Publishing private IP addresses in the DNS is not recommended, because it yields to the DNS rebinding attack. Some nameservers will even refuse to load those zones (or just not answer for those records). See medium.com/@brannondorsey/… for example Jul 20, 2020 at 2:32
  • @PatrickMevzek: Allowing private IP address replies from public DNS causes the problem you mentioned, but it's a bit far from the original question. Jul 20, 2020 at 7:30
  • @PatrickMevzek DNS rebinding doesn't actually have anything to do with private IP addresses. In fact that article starts with a mention of using DNS rebinding to attack Blizzard. It just so happens that the author decided to focus on using DNS rebinding to attack local services, but again, DNS rebinding applies more generally. The underlying issue there is that the local services are poorly secured and vulnerable to many attacks. Therefore, I disagree with your comment. Jul 20, 2020 at 9:34
  • 1
    @PatrickMevzek Some people don't let you use special characters in passwords, but that doesn't mean that they have a good reason for it. The mistake isn't using private IP addresses in DNS - the mistake is assuming that private services don't need security. Jul 20, 2020 at 17:34

1 Answer 1

1

You can point a domain name to a private IP address. As a random example, the company I work for has a domain name local.example.com that points to 127.0.0.1. Not that the details matter much, but it uses this for providing MFA to command line tools - the local application will launch a browser window with our SSO/2FA provider, and the return URL for the login process is local.example.com, which (as mentioned) points to 127.0.0.1. Before starting this the command line tool temporarily starts up a web server that is only accessible locally (i.e. at 127.0.0.1), and so when the web browser redirects to local.example.com it is redirecting to a web server accessible only on the local machine, and the command line tool uses the web server to extract the necessary access tokens from the SSO provider.

What you're proposing to do is pretty much the same thing. While I've never attempted your particular use case, I see no reason why it shouldn't work. I don't believe there are any particular security concerns related to this.

As for how to automate your certificates with certbot, you could do it without opening up your service to the outside world, although it depends on the capabilities of the DNS host. There are two key points:

  1. The certbot command line tool has options that allow you to inject your own custom scripts into the renewal process
  2. certbot can also prove ownership for issuing certificates by having you create DNS entries for the domain, without needing to connect to a webservice.

Therefore, if your DNS host supports it (the larger ones do), you could imagine attempting this flow:

  1. Adjust certbot to use DNS validation. In essence, it will request that you create DNS records on your domain with certain values
  2. Use the API of your DNS provider to automatically create these entries
  3. Ask certbot to validate the records. It will then check for the DNS entries (and happily wait reasonable amounts of time for DNS propagation)
  4. Once the DNS propagates and is verified, certbot will give you your certs

Note that this process is not necessarily as involved as it sounds. Certbot already has plugins available for many DNS hosts, and you may find near-complete examples of this process online.

The other option would be to run a private DNS server on your local network, and update your network configuration (or the client machines) to point to it.

10
  • If you can register your private local.example.com in a Public DNS (I've never tried), what prevents me from coming along and registering my own local.example.com ? Conversely, if you have protected the domain, what prevents you or anyone else from cyber squatting common private names, local.host.com ... etc ? It seems like a public DNS would need to block private IPs to prevent madness? Jul 19, 2020 at 13:57
  • @user10216038 It's possible I'm misunderstanding what you are saying, but I own example.com, you don't, so there is no way you can come along and register your own local.example.com. Our internal tools point to local.example.com so it won't hurt me at all if you go register local.anotherexample.com, and of course if you created your own service on your local machine and went to local.example.com you would see your service instead of mine, but that only affects you, not me. There is no way for an outside attacker to inject themselves in this process. Jul 19, 2020 at 14:01
  • I wasn't thinking as an overt attack, more as a denial of service. If I register local.example.com as 127.0.0.17 on the same Public DNS, isn't there a conflict? I either can't do it (Cyber Squatting), or your DNS queries are now no longer returning 127.0.0.1? Jul 19, 2020 at 14:16
  • 4
    @user10216038 I think you're confusing "registering" a TLD, vs how DNS works. No, you can't "register" subdomains, and if you could, you couldn't register subdomains for top-level domains you don't own. What this means is: Twitter owns twitter.com because they registered it. That also means they own everything under it, foo.twitter.com, bar.twitter.com, .foo.bar.baz.twitter.com, etc. Nobody can register local.twitter.com or any other subdomain. The "registering" of subdomains is really just publishing new DNS records telling the world how to map foo.twitter.com to an IP address.
    – user229044
    Jul 19, 2020 at 23:37
  • 2
    @user10216038 And, only twitter can publish new DNS records on the public DNS for *.twitter.com. Obviously you can override that on your own computer, and on any DNS server you own. Businesses often do as one part of restricting which sites can be browsed from their network. They'll prevent something like *.facebook.com from resolving, or force it to resolve to some internal page that says "You can't access Facebook at work". But that's not the same as "squatting" on a subdomain of a TLD you don't own, and it doesn't affect anybody not using that businesses DNS server.
    – user229044
    Jul 19, 2020 at 23:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .