Thanks for the ping suggestion. When I ping docmost.example.com, looks like Adguard is correctly catching it and routing it to an internal IP 192.168.1.80, which is exactly what I’ve told it to do. I tried to ping anothersub.example.com as well, and it was pinging my duckdns address and timing out. So when I ping, it looks like the packets get through but when I try to access it from a browser, it times out?
Comment on Need help getting domain to resolve over LAN
ashley@lemmy.ca 5 days ago
I’ll start from the beginning.
You’re hosting a service on your LAN, and using port forwarding to expose this service to the internet on your public ip.
The problem is accessing your public ip from your private network. There are two ways to solve this.
a) NAT Loopback, which is a setting or rule you may be able to enable or create on your router to forward packets destined for your public ip (the ones from your private network) to your private server
b) Split horizon DNS, which is actually what you’re doing. Where you set it up so in one network (in this case the internet) you get one result, and on another network (your LAN) you get a different result.
If I had to guess, what’s happening is your dns isn’t resolving properly, and when your computer is trying to reach out to your public ip. The thing with dns is it’s a bit finicky, there are many different places to set your dns server.
First, you should check if it’s resolving correctly. It’ll show you the ip it resolves to when you ping it. If it resolves to your public ip, make sure your dns settings aren’t being overridden by your operating system, and try clearing the cache
iAmTheTot@sh.itjust.works 5 days ago
ashley@lemmy.ca 5 days ago
Right. Can you access your npm server via the ip in your browser? Even if it’s not docmost that it returns?
If you can, it’s probably your browser using its own dns so you’ll have to change that to adguard as well.
NAT Loopback can be a bit finicky but once you set it up there’s no tinkering, it’ll just work forever. The only problem (which really doesn’t matter a bit with a document sharing platform) is that packets first have to go through the router. If your server and client are on the same network then they can communicate directly with each other instead.
EarMaster@lemmy.world 5 days ago
I also think it may be the browser not using the DNS provided by the router. This is often called Safe Browsing or Secure DNS in browser settings.
ashley@lemmy.ca 5 days ago
Yep, so if they’re able to access npm via the ip this is likely it.
litchralee@sh.itjust.works 5 days ago
I agree with this comment, and would suggest going with the first solution (NAT loopback, aka NAT hairpin) rather than split-horizon DNS. I say this even though I have a strong dislike of NAT (and would prefer to see networks using flat IPv6 addresses, but that’s a different topic).
Specifically, problems arise when using DNS split-horizon where the same hostname might resolve to two different results, depending on which DNS nameserver is used. This is distinct from some corporate-esque DNS nameservers that refuse to answer for external requests but provide an answer to internal queries. Whereas by having no “single source of truth” (SSOT) for what a hostname should resolve to, this will inevitably make future debugging harder. And that’s on top of debugging NAT issues.
Plus, DNS isn’t a security feature unto itself: successful resolution of internal hostnames shouldn’t increase security exposure, since a competent firewall would block access. Some might suggest that DNS queries can reveal internal addresses to an attacker, but that’s the same faulty argument that suggests ICMP pings should be blocked; it shouldn’t.
To be clear, ad-blocking DNS servers don’t suffer from the ails of split-horizon described above, because they’re intentionally declining to give a DNS response for ad-hosting hostnames, rather than giving a different response. But even if they did, one could argue the point of ad-blocking is to block adware, so we don’t really care if SSOT is diminished for those hostnames.