I just bought domain and use it. It also allows me to setup TLS via Let’s Encrypt without need to adding root cert everywhere. IMHO perfect solution, and not that expensive or troublesome. I have also 100% guarantee, that there will be no conflicts.
Only drawback some people may raise is the risk of domain name enumeration, where a would be attacker could enumerate all devices and services on your network just by looking at public DNS.
Only drawback some people may raise is the risk of domain name enumeration, where a would be attacker could enumerate all devices and services on your network just by looking at public DNS.
How? Just do local DNS resolution on the network using that domian. For example, you might have a public DNS entry for foobar.com, but you might have DNS for me.foobar.com, bazz.foobar.com, etc on your local network. So requests for those on your local network are serviced by your local network, and you have no mention of them in the public DNS. Am I missing something?
That requires you to have a split-horizon DNS configuration. It’s pretty easy if you’re running your own DNS resolver but most ISP-provided consumer routers don’t support it and so you’ll also need to be running your own DHCP server. You might be able to put an SOA record in that points to a LAN IP but that will only work for devices running their own caching resolver.
I have to have that anyway because my modem/router does not support connecting to the WAN IP from the LAN. I can specify the DNS server I want to use through the modem, which i have avoided up to now because i’ve had trouble with dnsmasq (and/or the wifi drivers for the EEEPC laptopserver it’s running from. Especially from the iphone, but sporadically from the rest of the network too. I’ve actively intended to fix that soon for about a year now.
The context here is let’s encrypt TLS. If you don’t resolve the name externally, how do you pass ACME validation? Plus there’s the certificate transparency log.
You can do ACME validation via DNS as well, so you get the ease of using an externally valid SSL certs but can restrict internal domains with split-horizon DNS
No, thinking about it more I think you’re correct, you’d be subject to DNS enumeration either from your DNS provider or the certificate transparency logs, at least for the existing of the domains themselves. The information about which IPs are pointing to which domain would remain within the internal network though.
The exception here could be to use a wildcard certificate which let’s encrypt just started supporting last year.
That’s not true. dnsmasq in openwrt is configured to route foo.lan to whichever device advertised their name as foo with DHCP (or the ipv6 equivalent).
Got it. I meant that if you did start using it, it wouldn’t work anyway so you’d have to set it up correctly. So you can’t use (or avoid) made up TLDs without DNS configuration.
I guess I’m just being particular about the language but the OP to me communicated there’s a way to use a made up TLD without configuring DNS and that you should avoid doing so which doesn’t make sense.
After a short period of initial experimentation, all current ARPA-Internet hosts will select some domain other than ARPA for their future use. The use of ARPA as a top level domain will eventually cease.” – RFC920
Personally I like to prevent hostname collisions even on disparate networks, just in case I ever link them with a VPN. Usually I use something like home.$DOMAIN where $DOMAIN is a personal use/development domain (and sometimes I’ll make DNS entries if appropriate), but you could just as easily do something like foo.home.arpa if you don’t need to use a real domain.
If you have a DNS server with a home.arpa or foo.home.arpa zone you can also address these over VPN as if they were real domains, without opening up your firewall.
I use home.lan, and I further divide that into ip4.home.lan and ip6.home.lan. For example, my NAS is storage-01.ip4.home.lan and storage-01.ip6.home.lan. It’s pretty easy with Unbound. Here’s a few sample entries in my /usr/local/etc/unbound/zones/home.lan config file (that gets included by /usr/local/etc/unbound/unbound.conf):
server:
local-zone: "home.lan" static
local-data: "arm64-01.ip6.home.lan. IN AAAA 2001:470:e1e1:1::15"
local-data: "arm64-02.ip6.home.lan. IN AAAA 2001:470:e1e1:1:2e0:4cff:fe20:30c5"
local-data: "arm64-01.ip4.home.lan. IN A 192.168.99.15"
local-data: "arm64-02.ip4.home.lan. IN A 192.168.99.210"
I use home.arpa (with multiple subdomains, like services.home.arpa etc) at home due to reasons. Before that I used different top domains per subnet, until I realized that .office is a real top domain and that it broke things like Office365.
The only problem this far is that isc-kea doesn’t support using different subdomains for different subnets like I use them. isc-dhcpd do support this, but I had issues with isc-dhcpd (not starting, not listening to all interfaces…) so I had to setup kea in a rush.
Unfortunately the Fritz!Box does not allow you to modify the domain away from “fritz.box.”, which is extra problematic since “box.” is a real TLD… Maybe owned by AVM though, didn’t check.
A DNS view in Bind lets you answer different questions depending on the source IP range. Using this and matching against private network ranges you can use whatever domain root you want. You can resolve local machines, services and even resolve an external domain like google.com with a custom IP.
Let’s say you have a website in your house. Externally it’s 1.2.3.4. Inside it’s 10.0.0.1. The view handles both questions with two answers from two db files. Let’s say you have a website outside your house. Externally and internally it’s 1.2.3.4. The view handles both questions with the same answer, just in two db files. The view matches IPs and you tell it a database file to answer with. Just type up the bind database file with whatever you want. The databases can have whatever you want in it. Whatever answers you want coming from external or internal sources.
I just bought domain and use it. It also allows me to setup TLS via Let’s Encrypt without need to adding root cert everywhere. IMHO perfect solution, and not that expensive or troublesome. I have also 100% guarantee, that there will be no conflicts.
Only drawback some people may raise is the risk of domain name enumeration, where a would be attacker could enumerate all devices and services on your network just by looking at public DNS.
That said, I don’t think that’s really a problem.
How? Just do local DNS resolution on the network using that domian. For example, you might have a public DNS entry for foobar.com, but you might have DNS for me.foobar.com, bazz.foobar.com, etc on your local network. So requests for those on your local network are serviced by your local network, and you have no mention of them in the public DNS. Am I missing something?
That requires you to have a split-horizon DNS configuration. It’s pretty easy if you’re running your own DNS resolver but most ISP-provided consumer routers don’t support it and so you’ll also need to be running your own DHCP server. You might be able to put an SOA record in that points to a LAN IP but that will only work for devices running their own caching resolver.
I have to have that anyway because my modem/router does not support connecting to the WAN IP from the LAN. I can specify the DNS server I want to use through the modem, which i have avoided up to now because i’ve had trouble with dnsmasq (and/or the wifi drivers for the EEEPC laptopserver it’s running from. Especially from the iphone, but sporadically from the rest of the network too. I’ve actively intended to fix that soon for about a year now.
I use a combination of split-horizon and hidden-primary DNS. No need for private IP ranges to be public.
The context here is let’s encrypt TLS. If you don’t resolve the name externally, how do you pass ACME validation? Plus there’s the certificate transparency log.
You can do ACME validation via DNS as well, so you get the ease of using an externally valid SSL certs but can restrict internal domains with split-horizon DNS
https://letsencrypt.org/docs/challenge-types/
But that just moves the enumeration from foo.bar to _acme-challenge.foo.bar, right? Or an I missing something?
No, thinking about it more I think you’re correct, you’d be subject to DNS enumeration either from your DNS provider or the certificate transparency logs, at least for the existing of the domains themselves. The information about which IPs are pointing to which domain would remain within the internal network though.
The exception here could be to use a wildcard certificate which let’s encrypt just started supporting last year.
I use .lan only because it was the default in openwrt, but I like that this exists.
You should avoid that and other made-up TLDs unless you’ve configured your DNS server/root with a
.lantop-level domain zone file.Confused by this comment. Wouldn’t they have to do that to even use any made up TLD like .lan?
I believe openwrt just uses that as the default name, but doesn’t do any DNS setup to handle it.
That’s not true. dnsmasq in openwrt is configured to route foo.lan to whichever device advertised their name as foo with DHCP (or the ipv6 equivalent).
Got it. I meant that if you did start using it, it wouldn’t work anyway so you’d have to set it up correctly. So you can’t use (or avoid) made up TLDs without DNS configuration.
I guess I’m just being particular about the language but the OP to me communicated there’s a way to use a made up TLD without configuring DNS and that you should avoid doing so which doesn’t make sense.
Is this a bug in openwrt that could be fixed with a submitted patch?
This reminds me of this other recent story: https://lobste.rs/s/0ihysv/tlds_putting_fun_top_dns
That quote is from October 1984. Things change.
Personally I like to prevent hostname collisions even on disparate networks, just in case I ever link them with a VPN. Usually I use something like
home.$DOMAINwhere$DOMAINis a personal use/development domain (and sometimes I’ll make DNS entries if appropriate), but you could just as easily do something likefoo.home.arpaif you don’t need to use a real domain.If you have a DNS server with a
home.arpaorfoo.home.arpazone you can also address these over VPN as if they were real domains, without opening up your firewall.I use home.lan, and I further divide that into ip4.home.lan and ip6.home.lan. For example, my NAS is storage-01.ip4.home.lan and storage-01.ip6.home.lan. It’s pretty easy with Unbound. Here’s a few sample entries in my
/usr/local/etc/unbound/zones/home.lanconfig file (that gets included by/usr/local/etc/unbound/unbound.conf):I use
home.arpa(with multiple subdomains, likeservices.home.arpaetc) at home due to reasons. Before that I used different top domains per subnet, until I realized that.officeis a real top domain and that it broke things like Office365.The only problem this far is that isc-kea doesn’t support using different subdomains for different subnets like I use them. isc-dhcpd do support this, but I had issues with isc-dhcpd (not starting, not listening to all interfaces…) so I had to setup kea in a rush.
Unfortunately the Fritz!Box does not allow you to modify the domain away from “fritz.box.”, which is extra problematic since “box.” is a real TLD… Maybe owned by AVM though, didn’t check.
A DNS view in Bind lets you answer different questions depending on the source IP range. Using this and matching against private network ranges you can use whatever domain root you want. You can resolve local machines, services and even resolve an external domain like google.com with a custom IP.
Let’s say you have a website in your house. Externally it’s 1.2.3.4. Inside it’s 10.0.0.1. The view handles both questions with two answers from two db files. Let’s say you have a website outside your house. Externally and internally it’s 1.2.3.4. The view handles both questions with the same answer, just in two db files. The view matches IPs and you tell it a database file to answer with. Just type up the bind database file with whatever you want. The databases can have whatever you want in it. Whatever answers you want coming from external or internal sources.