What domain name to use for your home network

https://www.ctrl.blog/entry/homenet-domain-name.html

by miles • 5 years ago

232 168 5 years ago

Do not use undelegated domain names like .lan, .home, .homenet, .network, nor should you make up your own domain name.

...why?

My DNS server, my rules, no? Why should I feel obligated to follow ICANN? Obviously, I'll need to make changes if someone ever registers the domain with ICANN (and I want to access the ICANN version), but other than that...

manicdee• 5 years ago

The issue here being: what happens when you have your proxy configured as "proxy.lan" but you make a typo when entering it in local DNS or in your browser settings? That DNS request for "proxy.lan" will now go all the way out to the root servers for every page load, multiple times.

Not so important for you with your 200 tabs open, but quite important to the people maintaining the root servers who see a significant percentage of all queries being for bogus domains that don't exist.

prox• 5 years ago

Does this happen often? How do they mitigate this?

rualca3• 5 years ago

(...) but quite important to the people maintaining the root servers who see a significant percentage of all queries being for bogus domains that don't exist.

I get the boys out rule sentiment, but isn't resolving domain names, even those that don't exist, the whole purpose of root servers?

I mean, your suggestion reads like asking not to type URLs wrong because a significant percentage of requests are 404s.

Shank• 5 years ago

What if you make a typo on .home.arpa? e.g., .home.arps? How is that any different?

peanut-walrus• 5 years ago

If you want to be a polite DNS resolver operator, root servers from B to G allow zone transfer, so you can just host the root zone locally. This way none of the typos or other bogus requests will leave your network.

traceroute663• 5 years ago

My DNS server, my rules, no?

That's the same line taken by network admins who think they know better than using RFC1918 IP ranges for their LAN.

sokoloff• 5 years ago

Worked at a company which did this (dating back to when they probably figured they’d never need to connect to the net).

As a satellite office and an acquisition, we played all kinds of games to try to figure out whether we should send a given IP address out to the Internet or to corporate. Apple’s IP range was entirely overlapping and of course the corporate networking group just threw up their hands and said “send it to us; the internet is not a business critical function.”

This was in the early 2000s, not the early 90s.

Wowfunhappy3• 5 years ago

I'm not suggesting this would be intelligent for anything larger than your own home network!

geofft2• 5 years ago

Does every single network client on your network use your DNS server for name resolution? No DNS-over-HTTPS? No widgets configured to talk to public DNS servers?

Also, does your DNS server correctly filter "out"-of-bailiwick responses for .lan etc. zones that are actually perfectly well in-bailiwick because they're from the actual delegated-by-the-real-root-servers nameservers, they're just not from your private server that you've configured? If not, I can execute a cache-poisoning attack against you.

tialaramex• 5 years ago

On your network, sure.

But you seem to be on our network with all of us and so here you need to obey our rules or things won't go so well for you.

renewiltord• 5 years ago

Oh yeah? What are you going to do? Complain that you can’t run the root nameservers and try to blackhole my traffic but fail since I am DHCP configured by my ISP?

Sounds like a toothless threat.

minimaul2• 5 years ago

For what it's worth, this does work. For now.

The main issue is if it gets sold later, or assigned by RFC. As an example, more than one company I've worked for used .dev as a TLD for their dev environments, with local DNS to override it. Once google bought .dev, this meant that:

- we couldn't access anything Google put on .dev

- suddenly, all of our test sites had HTTPS forced, because .dev was HSTS preloaded by Google

The point here is that an unexpected change that you might not be aware is coming can break your setup in ways that are awkward to resolve - eg HSTS preloading means that you can no longer access non HTTPS endpoints unless you do it by IP and that leads to a frustrating afternoon - and it's inevitably always when you don't want it.

Like it or not, ICANN operates the DNS space. There's a proper way to get your own piece of this space, and you can run home or business networks under your own piece and you have a guarantee that no one will break you - because it's yours.

(edited for formatting)

minimaul2• 5 years ago

And as an extra point - can you actually guarantee that all your DNS lookups hit your DNS server first?

That's harder than it sounds, with more and more apps implementing their own DNS over HTTPS clients - Firefox does it for instance, so does Chrome.

paranoidrobot• 5 years ago

Try using something under .local and see how much fun you have.

That's what a former employer had set up for their internal environments.

Worked great until mDNS came along and Apple devices insisted that .local had to go through mDNS rather than our DNS servers.

The Mac users had a constant stream of complaints because of it: "I can't connect to the printer", "Shared drives don't work", "I can't access the CI environment in Safari/Chrome/whatever"

globular-toast• 5 years ago

Place I worked at set up the network using .local around 2010 when mDNS was already common. Turns out the admin had seen/heard of .local and thought that's what it was for. A little knowledge is a dangerous thing...

d2wa12• 5 years ago

As long as you properly configure your server to not bother the root servers, then sure. Do what you want. But you need to set up the TLD zone in addition to your domain zone. It’s extra work.

nucleardog• 5 years ago

I'm with ya.

I use `.zz`.

It's short, easy to type, and in order for that to be assigned out, we'd need an entirely new country to be created (one that decided the other bazillion free CCTLDs are not to their liking). And like you say, I only run into a problem if I decide I want to access things from said country.

Would I do this in any professional setting? Absolutely not. For my own stuff at home? The risk is pretty minimal and the work involved in updating if I ever have to is not too bad.

DHCP automatically registers everything under <hostname>.zz, and I cname well-known things from <thing>.svc.zz to the appropriate hostname so I can hit, e.g., `blueiris.svc.zz` or `homeassistant.svc.zz`.

For SSL I just run my own CA.

Symbiote• 5 years ago

You can use ZZ freely, as it's an ISO 3166 code reserved for private use. AA, QM to QZ and XA to XZ are also reserved.

unraveller• 5 years ago

I briefly considered their advice and am now using the-com-remote-home8080-amail.local.fu why? because it Further Upsets authoritarians.

To pick your own free TLD just run a nameserver check against the TLD on [1] and watch out for TLDs that hit root servers

[1] https://dns.google/resolve?micro.soft&type=NS

dmd• 5 years ago

In similar news, do not use "dev.host", because someone owns it[0] and can and will do increasingly hilarious things to your traffic.

[0] me

adjkant• 5 years ago

Good boy: https://dev.host/~shmup/thot/2017/IMG_3091.JPG

traceroute663• 5 years ago

The blog post misses the (controversial if you're one of the ex-applicants) decision by ICANN to ban .corp, .home and .mail from ever appearing on the internet. So you've got those options too.

Or in ICANN management-speak: "Whereas, the Board considered that the applicants were not aware before the application window that the strings .CORP, .HOME, and .MAIL would be identified as high-risk, and that the delegations of such high-risk strings would be deferred indefinitely." [1]

[1]https://features.icann.org/addressing-new-gtld-program-appli...

zamadatix• 5 years ago

"to be not assigned" is generally less safe than "assigned for local use". E.g. 1.1.1.0/24 was first held back too see if bogus traffic would decreased then a ssigned for research purposes then assigned for cloudflare DNS causing a lot of grief for corporate networks that used 1.1.1.1 or 1.1.1.2 for network clustering or portal gateways instead of ones explicitly assigned for internal use.

traceroute663• 5 years ago

"to be not assigned" is generally less safe than "assigned for local use"

Normally I would agree. But in this case, 5 years (2018-2013), a $185,000 refund, high-profile media coverage and an explicit "deferred indefinitely" statement later ? I don't think any of us will see .CORP, .HOME and .MAIL on the internet in our lifetimes !

twobitshifter• 5 years ago

It actually mentioned .home as something not to use (along with .lan and.homenetwork)

CRConrad4• 5 years ago

Maybe the GP meant "missed" as in "was wrong about".

[EDIT:] (I'm not saying it is; just that GP may think so.) [/EDIT]

3np• 5 years ago

For non-TLDs, example.com is also good.

https://en.wikipedia.org/wiki/Example.com

vbezhenar• 5 years ago

IMO the best approach is to register somedomain.com and use its subdomains. It’s guaranteed not to interfere with anything, you can get LE certificate, you can make it available from the Internet if necessary.

lysp• 5 years ago

That's what I do, local.domain.com.

I also have a wildcard le cert for *.local.domain.com.

indigodaddy• 5 years ago

Or even better perhaps, home.domain.com.

fsckboy2• 5 years ago

somedomain.com is not guaranteed not to interfere!

example.com is guaranteed not to interfere (and example.org)

http://www.iana.org/domains/reserved

thundermuffin2• 5 years ago

I believe you took their post too literally; they mean to go register some domain you would like to have (such as ilovemycoolhouse.com or bearinabigblue.house) and use it, because the only way it will ever interfere with something is if you cause it to.

awill• 5 years ago

in case it isn't obvious, OP is saying to use YOUR domain, not the domain 'somedomain.com'

relax88• 5 years ago

This is definitely the correct answer if you own a domain that you can use for your home network.

It has none of the downsides/gotchas from a technology point of view. Just have to make sure to renew your domain registration!

q-rews• 5 years ago

I’ve been doing that since the beginning of my career, I don’t know what’s so hard about this.

flemhans2• 5 years ago

What if it's an office building?

geofft2• 5 years ago

Buy a real domain name and use that. It is probably cheaper than a single square foot of office space.

(This can either be your normal domain name that you already have, using split DNS to make more things resolve on the internal network, or an entirely separate domain name, whichever is operationally easier for you.)

flemhans2• 5 years ago

But homes could do that too.

I bet many homes have more money for domain names than some shops/offices.

Just wondering why they didn't call it 'localnet' or some other unused synonym for local.

jitl• 5 years ago

I use cozy.systems

johnchristopher• 5 years ago

What about .localhost? Asking for a friend.

d2wa12• 5 years ago

That is actually another special-use domain name that is supposed to be resolved by the local stub resolver to 127.0.0.1 and ::1. It’s not suitable for use on your local network, however.

pwdisswordfish87• 5 years ago

It’s supposed to be resolved to a loopback address. Chrome forces it to 127.0.0.1, because Google knows better than you. Obviously. <https://bugs.chromium.org/p/chromium/issues/detail?id=489973>

francislavoie• 5 years ago

Works great for things you run on the same machine, less-so for LAN.

WalterBright• 5 years ago

"pennygetyourownwifi" works for me.

davemtl• 5 years ago

I use a sub-domain of a domain I registered. For example, I use in.[myname].ca.

rootusrootus2• 5 years ago

I just use a real domain name, so I can easily obtain LE certs. Only the internal DNS server will actually return internal addresses.

sigjuice2• 5 years ago

A real domain name is the way to go. The convenience of using LE wildcard certificates is huge.

However, running split-horizon DNS is not straightforward, at least in a home setting. I don't see a huge problem with putting a couple of internal addresses in external DNS servers.

  lexicon cloudflare --auth-token $(gopass cloudflare) create my-real-domain.xyz A --name my-rpi --content 192.168.1.201

jeroenhd2• 5 years ago

You don't necessarily need a split-horizon DNS. You only need a few records for the LE wildcard certificate to renew. In fact, DNS-01 only seems to require a single TXT record to resolve.

In theory you could set up a small home server or dev machine script that pulls in a wildcard certificate and let all the real A/AAAA queries go to your LAN DNS server (or resolve through mDNS!). A record that doesn't resolve in global DNS won't usually cause much trouble in local DNS either.

Putting internal IP addresses in your DNS could pose problems for (small) companies using this trick (because it allows hackers to map out your network) and it could cause confusion (when systems reverse-lookup domains and suddenly a spoofed 10.0.0.1 address is shown as myfunkyservice.sigjuice.xyz in the log files). The issues are minor and unlikely to be a problem, but they're there to serve as footguns years down the line.

rootusrootus2• 5 years ago

I have simple requirements, so I just have a few normal records for the external DNS (primarily for LE to use, but also to make it easier for me to find my way back into my home network when I'm out and about). For internal addresses, I just use overrides in Pi-Hole.

I 100% agree that the whole reason for this setup is my LE cert. For whatever reason, some of my internal services with self-signed certs are not usable with Chrome, and some are. I don't know what pushes Chrome over the edge so it won't let you override. So I set up an internal reverse proxy with nginx to front-end all my internal services, then I only have to worry about keeping the LE cert installed in one spot.

denton-scratch• 5 years ago

Split horizon:

I run DNSMasq on port 53, to serve DHCP and local DNS queries. DNSMasq forwards queries it can't answer (queries for "real" domains) to Unbound on port 1053.

It's not split horizon, because Unbound only serves the LAN - I don't serve DNS to the world - and because Unbound isn't an authoritative nameserver. But it's not that hard to make DNSMasq serve zones, and it's not hard to make DNSMasq serve those zones only to queries from the intarwebs, and serve the DHCP 'zone' to local queries.

And anyway, I guess you could use something ugly like BIND instead of Unbound, if you need an industrial-grade authoritative DNS server facing the internet.

SilverRed2• 5 years ago

This is a no brainer for any serious setup. We use our main domain to add subdomains which point to local services.

swiley• 5 years ago

I just set static IPs for important things and put them in my domain. There's also MDNS although most of the MDNS responders are pretty fat for what they do. I tried hacking some basic MDNS stuff into busybox a few years ago but never cleaned it up and sent a patch.

karmanyaahm• 5 years ago

I use homenet.<my lastname>.tld

j1elo• 5 years ago

Your time is better spent ensuring all your devices support mDNS resolution

Heh. I starred this Android feature request and kind of regret it because it's been a continuous stream of "+1" emails (but I want to stay subscribed in case some meaningful conversation happens at last):

https://issuetracker.google.com/issues/140786115

(A login is required; any Google account will do)

CRConrad4• 5 years ago

Starred (not +1'd).

yrro• 5 years ago

I wonder which Android will support first, MDNS or DHCPv6?

xcskier56• 5 years ago

This is a complete tangent, but does anyone else really hate white text on black background? After reading only a few lines my eyes hurt and I have ghosting where the lines were when I look away. Websites like this one are basically unusable for me

thrownaway810• 5 years ago

I think it’s a device issue for you. My device sees it as black text on a white background.

frosted-flakes• 5 years ago

Turn off dark mode in your system settings if you don't want dark mode. It's black-on-white in light mode.

jeroenhd2• 5 years ago

Honestly, just spend the five bucks a year and reserve a real domain name with auto renew. You don't need to make it publicly resolvable, but you'll be 100% sure all of your internal service names won't ever conflict with anything used in the real world. If you pick the right registrar, you can easily get your hands on a wildcard DNS cert as well through Let's Encrypt, so you can protect your internal services with HTTPS!

You don't suddenly want to be restricted to HTTPS only (i.e. when Google bought .dev). There's also the minor risk of someone eventually buying your domain and causing all kinds of funky hell, like setting proxies to your internal network (through WPAD) and the names of local services (printer, router, etc.) being queried to a real DNS server because your computer sometimes appends the domain name to TLD-less queries. I've seen it happen that someone set something like example.com as their local domain (including in the DHCP config) who then saw constant slowdowns as their browser tried to resolve http://local-service/ as http://local-service.example.com/, going out to the internet every time, and not caching the error response.

bb883• 5 years ago

I'm not saying your wrong, but frankly, it's 2021, and it should be a lot easier than this to set up hosts internally for home use. We've largely had the internet broadly for the last 25 years, and the average person should not have to be an expert on wildcard certs/DNS/zeroconf if they want to just have a server running locally.

In fact, that's part of the reason things have gone to the cloud, because what should be local internet style appliances (think of a media server that you just plug in and works with your stereo/tv) can't find each other easily -- all because you can't resolve a freakin name on the local DNS without setting up bonjour or your own DNS server.

milofeynman• 5 years ago

You could just create your own cert and add it to all of your devices, I suppose

nine_k3• 5 years ago

Give your local box a static IP from a LAN range, give it a name in .local or .lan domain, and you're likely fine.

The more interesting stuff begins when you want several boxes, and also your laptops, phones, tablets, etc to form a reasonable LAN, while accessing the internet. Bonus points for remote access to your LAN from outside it using your laptop or phone. Etc, etc.

nine_k3• 5 years ago

No, things have gone to the cloud because it's a source of recurring revenue.

Is it damn hard to have a cable modem + router box and a WiFi access point in your home? Likely it's a no-brainer; each of them is at least as complex as a DNS server. Incentives matter.

SilverRed2• 5 years ago

DNS was not the reason for the cloud. The devices you talk of exist and DNS is not an issue. Some central discovery server can point you in the right direction if you do not want to set up your own dns. The problem is these products suck really bad. The hardware makers do not get top grade software developers and they do not support their devices for long enough so you get the recent issue with the home cloud nas product that exposed everyones data to the internet and an attacker remotely wiped them all.

I would much rather pay google $1/month to hold my data fairly securely than have to trust WD/Seagate/whoever to secure it.

And for IoT bits the problem is solved, Apple Home allows local only IoT devices and if you have an ipad or apple tv in your network you can always reach your iot devices without having to care about DNS. You might complain that this is a centralized cloud service but thats not far off what DNS is. You have to ask someone where your network is.

ASalazarMX2• 5 years ago

Mixing LAN and Internet scopes makes me uneasy. In my LANs the local domain is <location_name>.local, because .local is one of the reserved top domain names, and it shouldn't be resolvable outside the LAN.

https://tools.ietf.org/id/draft-chapin-rfc2606bis-00.html#rf...

d2wa12• 5 years ago

Read the article. Don’t use .local (except for mDNS.)

rualca3• 5 years ago

Honestly, just spend the five bucks a year and reserve a real domain name with auto renew.

It really doesn't make much sense to propose as a solution to a potential configuration problem subscribing to a service with the goal of never using it.

It wouldn't be far-fetched to suggest reserving a subdomain of a domain you already own and use for that specific purpose, but paying for a subscription just to configure your internal DNS doesn't sound reasonable at all.

charles_f• 5 years ago

This would still forward your unresolved to public DNS, exposing your internal infra, which as I understand it is one of the things this article is looking at preventing

tedk-42• 5 years ago

'exposing your internal infra'

I've worked in gov places where they care about this detail. It's quite a sad 'security by hiding' mentality.

Oh no someone knows my current IP is 192.168.0.100 <scared/>

cm2187• 5 years ago

Lots of DNS servers won’t let you resolve to local IPs. Google’s public DNS does. So I do that but I have to set all my machines to use those DNS.

Fiahil• 5 years ago

If you pick the right registrar, you can easily get your hands on a wildcard DNS cert as well through Let's Encrypt.

I, sadly, went for Namecheap, and they don't integrate with let's encrypt :(

I know I could use the http challenge solver, but I would have to expose a publicly-available endpoint and I would prefer to avoid that !

treesknees• 5 years ago

You can change your DNS provider without changing the registrar.

gyrgtyn• 5 years ago

five bucks for the first year, then considerably more to renew

ill0gicity• 5 years ago

My solution was to use a single domain for everything, with different locations broken out under their own subdomains. My colocated rack is "fmt2". VPSs are under normal IATA 3-letter codes. Homes, not just mine, are under "<STREET_NUMBER><STREET_NAME_INITIAL>". Internal services available for all homes are under "int". And so on. There are a bunch of reserved names under each to provide consistent access to per-location devices and services... "network" for a jump-off point to other devices, "edge<N>" for internet-connected routers, "sw<N>" for switches, "svc<N>" for per-location services (Wireguard, DNS, DHCP, NTP, LDAP, RADIUS, BIRD, HTTP/HTTPS, Home Assistant, Home Bridge), "ap<N>" for access points, "print<N>" for document printers, "fdm<N>" for 3D printers, ad nauseum. It's worked great to keep things organized. It also simplifies certificates since I can use wildcards.

philsnow• 5 years ago

I had set up some minecraft servers in my k8s homelab behind a proxy that routes clients to the right server depending on the domain name they're connecting to.

Everything inside the k8s homelab uses subdomains of k.myvanitydomain.com. The minecraft proxy is at mc.k.myvanitydomain.com. So, to connect to the "valinor" minecraft server, it's just valinor.mc.k.myvanitydomain.com. Dead simple (to me).

I tried explaining that to my kids and suddenly I knew what it was like for whoever explained to me the whole /ls/<chubby_cell>/borg/<borg_cell>/bns/<mdb_user>/<job_name>/<index> setup from google prod

SavantIdiot2• 5 years ago

Weird, my Linksys WRT1900AC applies `.home` to its local DNS, but this article says not to?

d2wa12• 5 years ago

Don’t use the .home domain. It was mistakenly recommended in RFC 7788. But that RFC was updated by RFC 8375 recommending the home.arpa domain.

(RFCs are published by the IETF who manages the .arpa TLD. That’s one of the few TLDs not managed by ICANN for historical reasons. The .home TLD falls under ICANN’s root domain, so the RFC shouldn’t have assigned it.)

SavantIdiot2• 5 years ago

Ah, thanks. Oddly, it is the default and the current firmware won't let me change it.

theteapot2• 5 years ago

What's wrong with .localdomain? Or is that for something else??

d2wa12• 5 years ago

It’s an unassigned top-level domain. So, don’t use it.

Some Linux distributions erroneously resolve it to 127.0.0.1, but there’s no RFC or consensus around this TLD.

theteapot2• 5 years ago

Jeez, all this time :/. Thanks.

scolby33• 5 years ago

I truly do not understand why this problem has gone on for so long. It's clear that many people think `.home.arpa` is ugly. It boggles my mind that the IETF and ICANN can't come up with some agreement to get `.home` or something similar codified like RFC 7788 tried to do. This just seems like a fight between giant bureaucracies while meanwhile the users suffer and bad decisions like assigning `.dev` are made. I get that there are rules around this sort of critical infrastructure and its management, but come ON. /rant

With the rant ended: can anyone explain to me why all the relevant organizations can't get together and assign a TLD for this purpose that doesn't end in `.arpa`?

pwdisswordfish87• 5 years ago

Delegating .dev was fine. Sick of hearing about this. As the meme goes, "well, well, well, if it isn't the consequences of my own actions." Everyone who got burned by .dev got what they deserve and needs to grow up already, take responsibility for themselves, and get over it.

labawi2• 5 years ago

Delegating .dev was not fine. Does everything need to be for rent?

The name system is a unique non-renewable resource. And it's not like ICANN gave people a lot of choice for unregistered domains.

By your logic, I suppose .onion was not fine either, till cca 2015 when it got special-use status? And all the name system alternatives should be abolished, because we need to rent their TLDs to some uninterested party?

lttlrck• 5 years ago

No mention of .internal

https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-in...

(Though maybe it's not a great name for this particular application, it seems to make a lot of sense for enterprise level infrastructure)

reaperducer• 5 years ago

I tried to get my company's IT department to put my latest project on a .internal domain. They wouldn't go for it, even though it can and will only be used by people internally.

They bound it to a sub domain of the company's main web site claiming that Microsoft (maybe something with Active Directory? Or Azure?) doesn't support any domains that you don't actually own.

I wouldn't be surprised if this is false because the people in charge of the domains think GoDaddy is awesome. Would love to hear an HN expert tell me if they're full of crap or not.

xorcist• 5 years ago

While it is certainly possible that a Microsoft-managed network places additional restrictions on what addresses are used, there are several good reasons to not to create unique "snowflake" situations for individual applications.

There might be silent assumptions everywhere what domain addresses answer to, in log collection, in monitoring, in address management tools. Simple things like domain search strings becomes harder. Any non trivial enterprise is going to have a ton of these (semi-)automated tools that your address will end up in.

It also carries the risk of complicating future work. The company might merge with another company. Or imagine a mandate where all communication will need to switch to TLS, only to discover there are addresses used under other domains internally.

rdpintqogeogsaa• 5 years ago

That's an Internet Draft, not a standard or even at least a published RFC. An Internet Draft cannot be used Internet-Drafts as reference material or cited as anything other than "work in progress."

There are some more reserved domains in RFC 6761 (https://datatracker.ietf.org/doc/html/rfc6761) though:

- .test (Application software SHOULD NOT recognize test names as special, and SHOULD use test names as they would other domain names. [...] Caching DNS servers SHOULD recognize test names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve test names. Instead, caching DNS servers SHOULD, by default, generate immediate negative responses for all such queries.)

- .localhost (Users are free to use localhost names as they would any other domain names. Users may assume that IPv4 and IPv6 address queries for localhost names will always resolve to the respective IP loopback address.)

- .invalid (Users are free to use "invalid" names as they would any other domain names. Users MAY assume that queries for "invalid" names will always return NXDOMAIN responses. Name resolution APIs and libraries SHOULD recognize "invalid" names as special and SHOULD always return immediate negative responses. Name resolution APIs SHOULD NOT send queries for "invalid" names to their configured caching DNS server(s).)

- .example, .example.com, .example.net (Users SHOULD understand that example names are reserved for use in documentation.)

Unfortunately, none of these address the same needs as .internal would.

nybble41• 5 years ago

Users may assume that IPv4 and IPv6 address queries for localhost names will always resolve to the respective IP loopback address.

Is the RFC assuming that there is only one loopback address for each protocol? That may be true for IPv6, but in IPv4 the entire 127.0.0.0/8 range is reserved for loopback. You can bind services to addresses anywhere in that range ("ip addr add 127.0.0.100/8 dev lo; nc -l 127.0.0.100 1234") which can only be accessed through that specific loopback address. So is this saying that .localhost domains must always resolve to some loopback address in IPv4 queries, or to 127.0.0.1 in particular?

There was a proposal to do something similar for IPv6 (using a 1::/32 prefix[0]) but it doesn't seem to have advanced much since 2013.

[0] https://tools.ietf.org/id/draft-smith-v6ops-larger-ipv6-loop...

livinginfear3• 5 years ago

What method are people using to configure this oin their own network? The router supplied by my ISP doesn't support using a custom DNS server like a pihole, unfortunately. I don't consider using /etc/hosts a longterm worthwhile solution. I'd love to find another useful way of setting this up.

nine_k3• 5 years ago

I was lucky enough to ask my ISP to set their box to bridge mode and have my request granted, then attached my own router.

livinginfear3• 5 years ago

I just looked, and my router does indeed support bridged mode. That might be my answer. Thanks for pointing this out!

jannes2• 5 years ago

Does your router support disabling DHCP? You can just run your own DHCP server in that case.

KozmoNau7• 5 years ago

That's what I do, even though I run my own router. The pi-hole acts as both DNS and DHCP.

It sets the DNS domain correctly via DHCP, unlike a lot of routers.

livinginfear3• 5 years ago

It does. I might go with this option. It seems like it'll be easier than running the router in bridged mode, and adding another physical router.

aussieguy1234• 5 years ago

An interesting trick I discovered is that you can make a public domain point to a local IP.

So I could make foo.mylocal.com point to 127.0.0.1 or the printer, or anything else really.

pininja• 5 years ago

For those curious about the (spoiler) .arpa domain, here’s an RFC https://www.rfc-editor.org/rfc/rfc3172

ComputerGuru• 5 years ago

I think it’s safe to assume that the one gtld ICANN will never sign off on - even if they sell .home, .lan, and everything else - is .icann

So if they won’t give us a tld to use, just use that :)

nsgi• 5 years ago

What if they start using it?

d2wa12• 5 years ago

.dev comes to mind.

pwdisswordfish87• 5 years ago

Do not use undelegated domain names like .lan

OpenWRT: *glances aside nervously*

citrin_ru• 5 years ago

.lan should be OK, it has no it’s own RFC, but it is a reserved domain nevertheless: https://datatracker.ietf.org/doc/html/rfc6762#appendix-G

pwdisswordfish87• 5 years ago

We do not recommend use of unregistered top-level
domains at all, but should network operators decide to do this, the
following top-level domains have been used on private internal
networks without the problems caused by trying to reuse ".local." for
this purpose:

This is hardly ‘reserved’. It just describes existing practice without in any way designating it as safe, recommended or future-proof.

8fingerlouie• 5 years ago

I use NextDNS, so in the configuration for my LAN devices i have rewrites that maps host.somewhere.com to 192.168.x.x. The external DNS maintains a single host record for VPN access, and since NextDNS also handles external requests, i have to set different hostnames for internal/external access.

It's (probably not) optimal, but it works. It was pretty much the same approach i used with PiHole/AdGuard Home.

Edit: To allow multiple hostnames i use a wildcard certificate from LetsEncrypt, though once i'm connected through VPN it doesn't matter much as it will resolve the internal hostname just fine.

cookiengineer• 5 years ago

I have to chime in here now and call the article what it is: wrong at least in regards to misinformation about ".local".

DNS clients may defer the resolution of .local spTLDs to the system’s mDNS resolvers instead of its DNS resolver.

This is not true. First off: You can always misconfigure your DNS resolver, but usually they can be used in parallel. Multicast DNS usually is only used when your router is too stupid to manage the hostname; and if multicast DNS is active on every host, then it's a setting that fixes even that broken router.

Also, "hostname.local" will never conflict with DNS based service discovery [1] of resolving a host via multicast DNS. And even if so, you can just use one of the other reserved multicast addresses and be done with it.

As long as you don't use e.g. "._tcp." or "._udp." inside your hostname, you never have domain name conflicts.

I think there's also a huge misconception about what DNS-based service discovery is.

In DNS-SD, there are questions to a service identifier with a PTR inside, and the response contains A,AAAA,SRV and TXT entries to describe everything you need to know to make a connection to the correct host, ip, port and version of the service.

Airprint, airplay, airscan and others additionally use their service name as a prefix in regards to the IANA-registered service names [2] so printers, scanners and other Multicast-DNS compatible hardware never conflicts with the existing network.

/ragecomment

Personally, I would actually embrace the use of .local, because it allows you to build a self-discovery service that is unrelated to DHCP and unrelated to ARP mechanisms, and works peer-to-peer; as long as the IPs are in the same NAT or, with IPv6/UDP6, have at least one discoverable scope.

In DNS-SD, you literally just have to be able to reach other IPs, and you have a working handshake mechanism to discover other devices without having to know their hostnames, IPs, or anything. It's pretty amazing once you realize its network automation potential.

Source: Me, building a web browser that uses peer-to-peer TLS encryption on "username._stealth._tcp.tholian.network" and "username._stealth._tcp.tholian.local" [3]

[1] https://www.ietf.org/rfc/rfc6763.txt

[2] http://dns-sd.org/ServiceTypes.html

[3] https://github.com/tholian-network/stealth

sko-• 5 years ago

This still won't fix the bat-shit-stupid idea of browser developers to just forward anything they think is not resolvable (and often even if it IS a valid local FQDN) to the next best search engine...

Joker_vD• 5 years ago

IIRC all browsers try to perform name resolution if you append "/" at the end of your input in the address bar. After that fails they redirect to a search engine, but not before.

d2wa12• 5 years ago

Well, browsers do a very sensible thing of attempting to anything that is a valid domain names. For everything else, including undelegated (and therefore unresolvable) top-level domains get passed on as search queries. Forwarding as much traffic to search engines is how they make money, after all. If you don’t like it, stick to valid domains.

r1ch• 5 years ago

For all the things saying not to use it, I've not run in to any issues with .local. It's reserved so it won't be delegated on the internet, it makes sense as a word and mDNS continues to work correctly. So far I haven't seen any devices that try to resolve over mDNS instead of DNS.

NDizzle• 5 years ago

There is a .casa TLD that you can use. It’s inexpensive to register, too.

KaiserPro2• 5 years ago

This isn't networking advice, but its what I've done either professionally and for home in some limited cases.

For fee paying networks, the "router" will most likley be in charge of some sort of DNS. If thats the case its made canonical for a subdomain that one owns. If you're lazy, just plain split horizon. However limit it strictly to DHCP. As soon as you start re-writing public services, you're sunk.

Side note, its a really good time to start putting in location data into subdomains. using option 60(might not be this, its been a while) you can work out what switch the request came from and add a different subdomain based on that you can make subdomains like server01.rack3.datacenter.country.company.com. this allows you to make search params to create local services. ie "time" would first check rack3, then datacenter, then country, then company.

KaiserPro2• 5 years ago

also my home domain name is "phartiphuckballs.com"

SeaWhales1000• 5 years ago

For us laymen, why would you need/want a domain name for a home network?

d2wa12• 5 years ago

So you don't need to memorize and hard-code IP addresses for your network services.

* router.home.arpa * nas.home.arpa * printer.home.arpa * htpc.home.arpa

filomeno2• 5 years ago

Yes, but that can be achieved by using a hostname alone (router, nas, printer, htpc...). What does the domain bring?

crmrc114• 5 years ago

Just tossing this out there- apple only claimed .local in rfc as of 2013. There are plenty of 'legacy' production environments that I support that still use .local without issue with mac clients. Its possible there would be a collision- but in practice the pain point is not enough concern for many with the limited subset of apple devices on their corporate networks.

Still pissed that apple was straight up allowed to usurp that tld instead of something like .mdns.local or .autoconf

Also, please dont use .com/net/org for local networks. All you are going to do is punish yourself when you go to setup you AD domain. However if you want to setup a subdomain that you are willing to make the AD server authoritative for you may end up with less pain. If you have to use your own domain keep in mind that if you go to setup AD in your home/lab/small biz you will need to add records for your webserver/mailserver etc since AD will want to be the authoritative dns server for its domain. There are ways around this, but I digress. Using a public tld can cause pain, just be aware of that.

atsmyles• 5 years ago

I use .lan and will continue to do so. .home.arpa is fine for 1 lan, but if you want to connect to multiple lans, it no longer works well. Add to the fact the amount of typing. .lan should be reserved so that people can use it for addressing multiple local area networks. We already have .local for mDNS which is perfect for the single lan setup. If they won't do it de jure, then users like myself will make this standard de facto.

otterpro• 5 years ago

Can't we use .test and .example as well? They are reserved for testing locally, and although it sounds weird, ie nas.test, it will work.

* [rfc6761](https://datatracker.ietf.org/doc/html/rfc6761)

What domain name to use for your home network

Related Stories