TransWikia.com

Is there a security vulnerability in setting a public DNS entry to a private IP Address?

Information Security Asked by Will Pike on October 28, 2021

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]
    // .
    // .
    // .

}

One Answer

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.

Answered by Conor Mancone on October 28, 2021

Add your own answers!

Ask a Question

Get help from others!

© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP