[HN Gopher] Proposed top-level domain string for private use: "....
___________________________________________________________________
Proposed top-level domain string for private use: ".internal"
Author : zacwest
Score : 283 points
Date : 2024-01-27 03:45 UTC (19 hours ago)
(HTM) web link (www.icann.org)
(TXT) w3m dump (www.icann.org)
| NoZebra120vClip wrote:
| Other currently reserved TLDs:
|
| https://en.wikipedia.org/wiki/Top-level_domain#Reserved_doma...
| gnabgib wrote:
| .example (for examples), .invalid (invalid domains), .localhost
| (avoids conflict with localhost hostname), .test (for tests),
| .local (link-local names), .onion (for Tor)
| jchw wrote:
| Also good to reserve localhost since some system resolvers
| will actually resolve any subdomain of localhost as
| 127.0.0.1. (I think systemd-resolved does, but I know for
| sure glibc NSS with the nss-myhostname module does.)
| tommiegannert wrote:
| That's the speced behavior of localhost:
|
| > The domain "localhost." and any names falling within
| ".localhost." are special in the following ways:
|
| > 4. [---] Instead, caching DNS servers SHOULD, for all
| such address queries, generate an immediate positive
| response giving the IP loopback address
|
| https://datatracker.ietf.org/doc/html/rfc6761#section-6.3
| globular-toast wrote:
| I haven't figured out how to get unbound to do this. It's
| easy to configure dnsmasq to do it, though
| address=/localhost/127.0.0.1
| address=/localhost/::1
|
| I do this on my network because not every system resolver
| does it itself (annoyingly).
| jchw wrote:
| I actually did not know this was specified by a standard.
| That does indeed make it perplexing that not all
| resolvers do it.
| NoZebra120vClip wrote:
| Couple things here:
|
| The GP describes resolver software, which corresponds to
| item 6.3.3, not a caching server. This does specify the
| same behavior.
|
| In RFC terminology, "MUST" > "SHOULD" > "MAY", so there
| is some wiggle room there.
|
| 6.3.2 permits Chromium and other apps to hardcode
| localhost names as such, instead of using a resolver.
|
| A very popular vector for adware/malware is to take over
| the system resolver, or replace the DNS client
| configuration, so this is one reason Chromium jealously
| guards 127.0.0.0/8
| webstrand wrote:
| what about .localdomain? I haven't been able to find anything
| standards-wise about it.
| AndyMcConachie wrote:
| The IANA link is probably better.
|
| https://www.iana.org/assignments/special-use-domain-names/sp...
| vmurthy wrote:
| From the article
|
| "ICANN has picked the TLD string that it will recommend for safe
| use behind corporate firewalls on the basis that it will never,
| ever be delegated.
|
| The string is .internal, and the choice is now open for public
| comment"
|
| Saved you a click :)
| gnabgib wrote:
| ICANN: [Proposed Top-Level Domain String for Private
| Use](https://www.icann.org/en/public-
| comment/proceeding/proposed-...) "The Internet Assigned Numbers
| Authority (IANA) has made a provisional determination that
| ".INTERNAL" should be reserved for private-use and internal
| network applications(...)"
|
| ... possibly a better link.
| Terr_ wrote:
| At last (or at least soon) I can stop using the special reserved
| example.com for things. :p
|
| https://en.wikipedia.org/wiki/Example.com
| p1mrx wrote:
| Eh, .internal is fine, but it's 8 characters to type. I'll
| probably keep using .lan until someone else takes it.
| ahmedfromtunis wrote:
| You still can provide your input on the matter till march; so
| it's not too late (yet): https://www.icann.org/en/public-
| comment/proceeding/proposed-...
| p1mrx wrote:
| The problem is that .internal is the bureaucratically correct
| answer, and not all internal networks are LANs.
|
| Maybe they can reserve both .interNAL and its convenient
| abbreviation, which just happens to be written backwards
| because it's DNS.
| ChrisArchitect wrote:
| Ha, excellent
| p1mrx wrote:
| Submitted to ICANN; everybody keep yelling .interNAL
| until it happens!
| pxtail wrote:
| Answer is simple and straightforward - nothing like this is
| going to happen because short abbreviations and any
| potential short alternatives can be sold and sweet sweet
| money can be extracted
| junon wrote:
| Not all use cases for .internal involve a LAN though.
| deng wrote:
| Wait, so all the '.io' domains are actually registered by
| people operating in the British Indian Ocean Territory?
|
| Seriously, .lan is just a convention. For all I care they
| could come up with any three-letter thingy, as long as
| there's a mutual understanding that no global DNS will ever
| resolve it.
| p1mrx wrote:
| Per my other comment, we could define LAN to be the
| abbreviation for interNAL, because INT was already taken.
| LeoPanthera wrote:
| Also worth noting that "home.arpa" is already reserved and
| specifically designed for residential use. It will never conflict
| with anything.
| Mountain_Skies wrote:
| And is nine characters long, which is cumbersome for those
| using it in an IOT context where data entry is often not
| straightforward.
| fastball wrote:
| Huh?
| Filligree wrote:
| Typing it on your TV with a laggy UI where you can only
| select letters using arrow keys. Which only work half the
| time, and also it isn't QWERTY.
| globular-toast wrote:
| It's so sad this is still necessary. We've had service
| discovery via avahi/zeroconf for years. Why does it seem
| like uPNP has been and gone? It shouldn't be necessary to
| type hostnames any more.
| loktarogar wrote:
| so, exactly the same as .internal
| eqvinox wrote:
| You didn't quite count that right with the dots ;)
| scraplab wrote:
| I use this, mostly for the .arpa vibes.
| sph wrote:
| I avoid it for the same reason. The ARPANET branch of the US
| Department of Defense feels anything but home to me.
| yrro wrote:
| Would it relax you to know that it has been retconned into
| "Address Routing Paramater Area"?
| ahoka wrote:
| I use it and it's very confusing for my guests.
| matt3210 wrote:
| .local already does this
| CountSessine wrote:
| .local is used by mdns so your .local machines can conflict
| with discoverable devices and services. I guess they wanted
| something that wouldn't conflict?
| miles wrote:
| > .local already does this
|
| Best to avoid it for that purpose:
|
| 1. "Using '.local' as a private top-level domain conflicts with
| Multicast DNS and may cause problems for users."
| https://www.rfc-editor.org/rfc/rfc6762#appendix-G
|
| 2. ".local has since been designated for use in link-local
| networking, in applications of multicast DNS (mDNS) and zero-
| configuration networking (zeroconf) so that DNS service may be
| established without local installations of conventional DNS
| infrastructure on local area networks."
| https://en.wikipedia.org/wiki/.local
|
| 3. "PSA: Don't use domain.local"
| https://old.reddit.com/r/sysadmin/comments/a9sfks/psa_dont_u...
|
| 4. "Why using .local as your domain name extension is a BAD
| idea!" https://community.veeam.com/blogs-and-podcasts-57/why-
| using-...
| axytol wrote:
| That's a good list of reasons, however it seems the biggest
| concern is if you run a dedicated DNS service on your
| network.
|
| For a simple home network setup, as long as naming conflicts
| can be managed, it looks like mDNS is quite handy.
|
| On a side note, I find .local to be best suited for the
| purpose, since from the language perspective it's easier on
| international users than .localhost
|
| The newly proposed .internal comes close, but .local still
| looks more semantically flexible or maybe this is a cognitive
| bias of mine.
| Brian_K_White wrote:
| Only to the same extent that .test and .example do, which is to
| say it does not.
| dang wrote:
| Url changed from https://domainincite.com/29381-icann-picks-the-
| domain-it-wil..., which points to this.
| amne wrote:
| .intranet ?
| rickette wrote:
| host.docker.internal
| w-ll wrote:
| since ".dev" was hijacked ive been using ".lan" and ".lab"
| mongol wrote:
| I also use .lan
| INTPenis wrote:
| This makes me think of some AD best practices I read a long time
| ago. One of the practices was to never use made up local TLDs
| like .internal or .local because some day they might be real and
| get picked up by someone.
|
| Essentially you should always use a domain you control both
| outside and inside, like a regular gTLD or ccTLD.
|
| Pretty much every single company I've worked for with AD has
| broken this rule.
| NoZebra120vClip wrote:
| The last time I set up DNS at home, I decided to use a
| fictitious and undelegated subdomain under my ISP's domain
| name. This structure did not create any "extra" problems in the
| short term.
|
| But I suppose that I still ran the risk that the subdomain
| could "become real", or draw attention from security admins, or
| I would change ISPs.
| justusthane wrote:
| > draw attention from security admins
|
| How? I'm not saying this is great practice -- there are
| certainly better options -- but no one outside your network
| will ever know about it. It also won't matter if you switch
| ISPs.
| justsomehnguy wrote:
| It's not a problem (well, most of the time), but you would
| see the requests for 'internal' resources in DNS (ie your
| machine is not on your network but tries to resolve the
| internal DNS records) and in certificate checks even for
| non-public PKIs
| blowski wrote:
| I saw a successful attack on a .dev domain doing exactly this.
| Links on PCs worked correctly, but phones showed a scam site,
| so emailed links were attacked.
|
| It was hard to fix because they couldn't get the spoofed
| domain, and there were so many copies of bad links everywhere.
| gerwim wrote:
| Another fun fact about .dev which I recently found out while
| working on a side project:
|
| You NEED to use https when visiting any .dev domain. Google
| has put it on the HSTS preload list.
|
| It took me a while to find out why my browser kept
| redirecting me to https when I wanted to use http (local
| development). Curl worked fine...
| chopin wrote:
| Pretty much the first I do on any fresh server is to
| disable http, no matter what it is used for.
|
| IMHO http has no use in the modern world.
| traceroute66 wrote:
| > Google has put it on the HSTS preload list.
|
| Just for the record, anybody can add their own domain to
| HSTS via the submission site[1].
|
| [1] https://hstspreload.org/
| malinens wrote:
| We used .dev before google registered it so we migrated to
| another paid domain so we don't need to pay huge amount per
| year to google
| maxcoder4 wrote:
| To this day this story still blows my mind:
|
| >Register a TLD which is informal standard for development
| websites and environments (.dev)
|
| >Charge an excessive amount of money for it
|
| >To make sure you ruin everyone's day, put it on a HSTS
| preload list
|
| >Refuse to elaborate
| enormousness wrote:
| >Sell your domain business and force your customers to
| migrate.
| blooalien wrote:
| ... to a provider that doesn't even offer all the same
| services.
| dijit wrote:
| oh. its worse. the original request for the TLD was only
| granted because in the application Google specifically
| mentioned that it should be reserved due to its unofficial
| use by developers and that if anyone else got it then they
| might put real domains on it.
|
| You cant make it up.
| progbits wrote:
| I specifically use some .dev domains because of HSTS. Some
| of us don't cling to http and I prefer an error rather than
| transparent fallback to unsafe protocol if I screw up the
| config.
|
| The first point is valid but that is mostly ICANN's fault,
| they should have proposed it as reserved instead of selling
| it.
| yrro wrote:
| > informal standard
|
| FAFO, as they say.
| deltaburnt wrote:
| Just my person experience, but I got my relatively uncommon
| name on .dev for $12/yr so I'm pretty happy with that. While
| the situation worked in my favor, I agree .dev probably
| should have been the official internal only TLD.
| argiope wrote:
| I understand that .home.arpa is the standard TLD for home
| networks as per RFC-8375
|
| https://www.rfc-editor.org/rfc/rfc8375
| badgersnake wrote:
| I tried to use that on my Turris Omnia and it broke a lot of
| things. I ended up using .lan
| voltagex_ wrote:
| What broke?
| INTPenis wrote:
| I never heard of home.arpa so I'm also curious what broke.
|
| The only thing I can imagine would be if you accidentally
| created a root for .arpa.
| keeperofdakeys wrote:
| The ".local" domain specifically is a bad choice as many
| platforms use MDNS instead of DNS for looking up those names.
| Leading to issues resolving names on some client devices. It's
| also very common due to Microsoft suggesting it as best
| practise in the early days of AD.
| rzzzt wrote:
| I'm wondering about one thing, now that I've read a few "may
| cause issues" and "is used for mDNS" replies: what the F is
| mDNS actually doing in the background?
|
| Is it really going to assign "lancelot.roundtable.local" to
| my washing machine on a whim, which leaves the microwave
| unresolvable?
|
| Can't I instruct the mDNS server running on my machine to
| respond to a particular name ending in .local?
|
| Can't eg. dnsmasq insert itself into a conversation on
| 224.0.0.251 saying "Let me answer this question" for certain
| queries?
| jt2190 wrote:
| If you've set up x.local in your DNS for your dryer but
| your laptop uses mDNS, it's possible that your lapatop's
| mDNS will get a response from your microwave that it's
| reachable at x.local. The solution (not an expert, please
| check this) is to set up the dryer in DNS as x.domain-thar-
| you-own or x.home.arpa
| hgomersall wrote:
| I'm a little fuzzy on this, but my understanding is that
| for mDNS to be reliable it is required that all .local
| hosts implement mDNS to allow for conflict resolution.
| HackerThemAll wrote:
| Thank Apple for this half-baked bullsh*t.
| MissTake wrote:
| How so?
| lioeters wrote:
| Maybe because of this?
|
| > mDNS implementations
|
| > RFC 6762 was authored by Apple Inc. employees Stuart
| Cheshire and Marc Krochmal, and Apple's Bonjour zeroconf
| networking software implements mDNS. That service will
| automatically resolve the private IP addresses of link-
| local Macintosh computers running MacOS and mobile
| devices running iOS if .local is appended to their
| hostnames. In addition, Bonjour devices will use those
| .local hostnames when advertising services to DNS Service
| Discovery clients.
|
| > Most Linux distributions also incorporate and are
| configured to use zeroconf.
|
| > ..The connection of Macintosh and Linux computers or
| zeroconf peripherals to Windows networks can be
| problematic if those networks include name servers that
| use .local as a search domain for internal devices.
|
| https://en.wikipedia.org/wiki/.local
| thinkmassive wrote:
| Kinda weird to blame the people who made an RFC, instead
| of the industry leader who recommended using .local
| completely on their own, without support from the wider
| industry. This is explained in the next couple
| paragraphs, where you stopped copying.
| lioeters wrote:
| You're right, the confusion about the use of .local
| domain seems to be more due to Microsoft going back-and-
| forth about it.
|
| > At one time, Microsoft at least suggested the use of
| .local as a pseudo-TLD for small private networks with
| internal DNS servers.
|
| > ..However, more recent articles have cautioned or
| advised against such use of the .local TLD.
|
| > Microsoft TechNet article 708159[7] suggested .local
|
| > ..but later recommended against it.
|
| > The Microsoft Learn article "Selecting the Forest Root
| Domain"[8] cautioned against using .local
|
| > By default, a freshly installed Windows Server 2016
| Essentials also adds .local as the default dns-prefix
| when a user doesn't select the advanced option, resulting
| in a domain with .local extension.
| nullindividual wrote:
| mDNS was announced after the Windows 2000 RTM date, so it
| would be unfair to blame Microsoft with regards to mDNS
| functionality.
|
| Not that Microsoft should have made that recommendation,
| but hindsight and all that.
| irusensei wrote:
| No. Fuck MS for encouraging their MVPs to use a reserved
| domain.
| Hendrikto wrote:
| > made up local TLDs like .internal or .local
|
| .local actually exists. It is used for mDNS.
| apexalpha wrote:
| TIL, woops!
|
| I use this for all my internal domains, haha. I guess this is
| why we need a proper tld like this.
| baobun wrote:
| The following TLDs are fine and reserved:
| .test .example
| .invalid .localhost
|
| RFC2606 (https://datatracker.ietf.org/doc/html/rfc2606)
| wolverine876 wrote:
| Not really: https://news.ycombinator.com/item?id=39154082
| rmccue wrote:
| You could consider making them real mDNS domains then, and
| using mDNS to resolve them to your desired IPs.
| baobun wrote:
| The following TLDs are fine and reserved:
| .test .example .invalid
| .localhost
|
| RFC2606 (https://datatracker.ietf.org/doc/html/rfc2606)
| deng wrote:
| Yes, but who would want .test, .example or .invalid as an
| internal domain? Also, they are too long (yes, that matters).
|
| What I've seen lately is '.int' for internal usage. While
| this is a valid TLD, it is only for international
| organizations, and it is not possible for "normal" people to
| reserve a domain with that TLD, so unless your company is
| called "WHO" or similar, you shouldn't have any problems...
| ocdtrekkie wrote:
| People thought .dev was safe until it wasn't. Bear in mind
| they can still do something like "enroll all of .int in
| HSTS preload" (like was done for .dev), and suddenly your
| browsers will permanently refuse to load any of your
| internal sites.
| yrro wrote:
| No one competent would ever have thought dev. was safe.
| It's quite simple: if you don't own the domain, or it
| hasn't been reserved (e.g., home.arpa.), don't use it!
| patmorgan23 wrote:
| .Corp exist and is reserved for private use.
| codetrotter wrote:
| Test is best used in temporary setups that you use for
| testing things.
|
| Example is best used in documentation only.
|
| Invalid is weird and confusing.
|
| Localhost as a TLD should still be on the machine itself.
| Keeping in mind that 127.0.0.1 is not the only loopback
| address at your disposal - you have the whole /8. You could
| bind different services on different loopback ip addresses
| and then assign host names in the .localhost tld to those.
|
| So for example you could run different Wordpress instances
| locally on your machine on ips 127.87.80.2, 127.87.80.3, and
| 127.87.80.4, so that each can run on port 80 without
| colliding with one another, and without resorting to having
| non-80/non-443 ports.
|
| Then have corresponding entries in /etc/hosts
|
| 127.87.80.2 dogblog.localhost
|
| 127.87.80.3 cooking.localhost
|
| 127.87.80.4 travel.localhost
|
| And use those domains to access each of those from your
| browser. Then you don't even need to keep all services behind
| the same Nginx instance for example, as you otherwise would
| do if you had different domain names but was using 127.0.0.1
| and port 80 for all of them.
|
| Whereas having the localhost tld refer to hosts elsewhere on
| a physical network.. that's about equally as weird and
| confusing as "invalid".
| pwdisswordfishc wrote:
| > Keeping in mind that 127.0.0.1 is not the only loopback
| address at your disposal - you have the whole /8.
|
| Tell that to Google Chrome developers, who are so arrogant
| they think they know better than the operating system, and
| force-resolve *.localhost. to 127.0.0.1
| loloquwowndueo wrote:
| Then use a non-brain dead browser :)
| yrro wrote:
| Looks like someone might have been trying to prepare the
| ground for a hijack of 127.0.0.0/8...
| bluejekyll wrote:
| 'The ".localhost" TLD has traditionally been statically
| defined in host DNS implementations as having an A record
| pointing to the loop back IP address and is reserved for
| such use. Any other use would conflict with widely
| deployed code which assumes this use.'
|
| Reading that sentence implies a single loop back address.
| I appreciate that IPv6 "fixed" this confusion by having a
| single loop back address of ::1. While you are correct
| that IPv4 reserved the entire /8 in practice the
| expectation is generally that 127.0.0.1 is the loopback
| address, and using other addresses in the 127/8 space
| tends to lead to unexpected issues across many pieces of
| software. The intention of the .localhost domain is to
| ensure that DNS resolutions never resolves to something
| external, for security reasons.
|
| See also, RFC 5735: "... This is ordinarily implemented
| using only 127.0.0.1/32 for loopback." --
| https://datatracker.ietf.org/doc/html/rfc5735
| CranberryDefuse wrote:
| They are reserved for Testing, & Documentation Examples.
|
| You should not used them in production.
| layer8 wrote:
| The only one of those appropriate for accessing actual hosts
| would be .test, and obviously using .test for non-testing
| purposes would also not be appropriate.
| patmorgan23 wrote:
| .domain, .lan, .home, .host, and .Corp
|
| Are all options as well.
| globular-toast wrote:
| My work used .local which means mDNS and service discovery etc
| doesn't work. Very annoying. What are they teaching these
| network admins? Why don't they even know what a domain name is
| for?
| mtillman wrote:
| Similar issue with modern devs that don't know what a page of
| memory is.
| londons_explore wrote:
| Or don't even know the bandgap of the transistors the
| computer is running off.
| ahoka wrote:
| Yeah, developers nowadays don't know their Pauli
| exclusion principle.
| HackerThemAll wrote:
| or a database.
| HackerThemAll wrote:
| Thank Apple for designing the protocol the Apple way, that is
| being not interoperable with the world.
| JonathonW wrote:
| Yes, the classic not-interoperable approach of publishing
| the protocol as Standards Track RFCs with the IETF.
| p_l wrote:
| The timeline was IIRC
|
| 1. MS made recommendations to use .local
|
| 2. Apple networks started to use Bonjour and used .local,
| breaking on networks that used .local already
|
| 3. RFC was submitted
|
| 4. MS recommended against using .local or any domain you
| do not own fully
| Uvix wrote:
| Even if they know now, that doesn't mean they knew when
| setting up the AD domain back in 2000.
| patmorgan23 wrote:
| Microsoft's recommendation in the early 2000's was to use
| .local
| maccard wrote:
| > Essentially you should always use a domain you control both
| outside and inside, like a regular gTLD or ccTLD.
|
| Yep. We use two domains - everything on A is "public" and
| everything on "B" is internal. The root of "B" is a static page
| on AWS that is gated behind our VPN so it serves as a quick
| "can you hit our infra at all" check when troubleshooting, and
| catches the people who are convinced they've enabled their VPN.
|
| One thing to note here that we haven't solved (We've only got
| two "infra" people, we're a small company) is how you handle an
| internal portal to an external service. If our public domain is
| maccard.com and private is maccard.dev, where does internal-
| admin.maccard.com _actually_ live? Our solve for this is we
| have an internal.maccard.com for this very specific use case,
| but I'd much rather it was admin.live.maccard.dev
| justusthane wrote:
| We just use the same domain internally and externally with
| split DNS. Works fine.
| justsomehnguy wrote:
| Until it doesn't.
|
| And having a website on the domain.tld adds shenanigans.
|
| One of many examples I had is when Outlook loses connection
| to Exchange (eg S2S VPN is down) it starts autodiscovery
| process, hits domain.tld (because users have
| email@domain.tld, duh) and complains to user with a scary
| messages (which are also blocks the process until the users
| hit _something_ ). Which is totally understandable, because
| the website is on some public hosting, so CN in the cert is
| from the public host at best and != domain.tld.
|
| Using corp.domain.tld or even techdomain.tld solves this
| totally and also let you use public certs (LE in the
| current era) even on the 'local' side of the network.
| maccard wrote:
| We have enough issues with DNS that adding split DNS into
| the mix is a ball ache I don't want to contend with.
|
| We actually have the DNS for our private domain set
| publicly, and all the actual work happens on a load
| balancer which is on the network. We're fully remote so
| this avoids the "my communal WiFi provider seems to have
| issues with the VPN" (which is what we had when we used
| split DNS)
| noAnswer wrote:
| I buried split DNS (and (for the most part) private CAs
| for that matter) with ACME DNS-01.
| johannes1234321 wrote:
| Aside from all technical issues the biggest problem I have
| seen with such an approach is that is really hard for
| employees to remember what is external and what internal
| that way. Distinct domains help there
| NewJazz wrote:
| We use split DNS and the admins can't even do it right,
| they keep fucking it up and configuring one DNS view but
| not the other, so when I'm on VPN I randomly can't use
| certain domain names.
|
| Also as another commenter mentioned, it is impossible to
| tell based on the name if it is an internal or external
| resource
|
| I'm curious what split DNS offers that a separate internal
| zone wouldn't.
| solatic wrote:
| Devil's advocate: using an Internet-public domain for internal
| purposes will publicly expose your internal hostnames if you
| enable DNSSEC on the Internet-public domain. This is a problem
| if you're required to enable DNSSEC, e.g. for FedRAMP
| compliance.
|
| The number of cases where this is actually a legitimate
| concern, IMO, is extremely small, and I'm personally of the
| opinion that using Internet-public domains for internal
| purposes is generally fine. But it's still important to point
| out that the number of cases is not zero.
| akdev1l wrote:
| You can use a public domain but a local/private DNS server
| INTPenis wrote:
| I believe the advice about using a TLD you control outside
| and inside is mostly to prevent takeover on the outside that
| could affect the inside.
|
| But you can still have completely separate DNS for the
| inside. Using a shared DB for both would probably be
| recommended to avoid conflicts.
| eqvinox wrote:
| > expose your internal hostnames if you enable DNSSEC
|
| Zone content enumeration in DNSsec was fixed by NSEC3 records
| (RFC5155, March 2008)
| tptacek wrote:
| No it wasn't! NSEC3 is crackable the same way a 1990s Unix
| password file is. This was such a big problem that two
| competing approaches were introduced to defeat it:
| "whitelies", which I perceive as the "best practices
| standard" answer, requires servers to operate as online
| signers (they should have been all along) so they can
| generate dynamic chaff records to foil enumeration, and
| NSEC5.
| eqvinox wrote:
| Hmm. Interesting. I wasn't aware of that, thanks! ...
| also, https://github.com/CyberCX-STA/NSEC-3-Walker ...
| tptacek wrote:
| Every security auditor in ever regs regime will flag zone
| transfers.
| tambourine_man wrote:
| This happened with the .dev situation. I switched to .d ever
| since. I've read somewhere that new TLDs are required to be at
| least 2 letters so I guess I'm safe this way.
| patmorgan23 wrote:
| You can use .lan, . domain, .home, .host or .Corp as they are
| all reserved TLDs
| tambourine_man wrote:
| .d is easier to type.
| ehPReth wrote:
| they aren't reserved that I can see?
| https://www.iana.org/assignments/special-use-domain-
| names/sp...
|
| Where did you see that? would be interesting to have
| reference for a couple people
| chaz6 wrote:
| I joke that I would use .icannsux because there is just no way
| they would assign it.
| lifthrasiir wrote:
| `.sucks` _is_ a real TLD though, so you can register
| `icann.sucks` today!
| mdaniel wrote:
| https://www.hover.com/domains/results?utf8=%E2%9C%93&q=ican
| n... alleges it is $219,999.99 and renews at $2599.99/yr
| due to "This is a tiered price domain."
|
| Also, yeah, they almost had me with those .99 figures :-/
| INTPenis wrote:
| Hah that's a funny idea that you'd be relatively safer if you
| used something outrageous like godsavethequeen or
| crappymcfartlegs. But you never know what promotional TLDs
| are created in the future. Or how free the process might
| become, as remembering names becomes less and less important
| to a majority of internet users.
| irusensei wrote:
| The .local bullshit gate so much headache. When I was working
| on Ubuntu based POS systems we had to make sure avahi or any
| kind of mDNS wouldn't be installed. It became a running joke
| "we got another MS MVP here" every time we had issues with a
| client with a .local domain.
| drbawb wrote:
| >Pretty much every single company I've worked for with AD has
| broken this rule.
|
| It's a lot better now. Ever since companies started moving from
| on-prem Exchange to O365 in droves I've noticed that most orgs
| I work with (painfully) updated their domain so their user
| principals align w/ their O365 mailbox.
|
| There's only one customer I have that still uses a ".local"
| domain for AD, and they got bought out last year. (By an org
| that uses a real FQDN.)
| sokoloff wrote:
| I worked for Merrill Lynch around 2000 and they used other
| people's public _IP addresses_ on their (theoretically)
| internal network.
|
| Naturally, this went terribly as soon any of their sites had
| their own connection to the internet.
| carterschonwald wrote:
| I've been told that this is still a problem at large
| organizations in that industry.
| wolverine876 wrote:
| Why not use the designated private IP ranges? There are more
| than enough addresses there, unless it's some crazy
| application with millions of instances each needing an IP.
| But then use IPv6?
| yencabulator wrote:
| I've sold IT stuff to a city that had some expensive
| consultants configure their ActiveDirectory as
| <name_of_city>.ad, as in the ccTLD of Andorra.
| bitcurious wrote:
| We had a bunch of .dev urls break thanks to google and our lack
| of foresight.
| loupol wrote:
| I think I would have preferred .intra (Unless it's already used
| somehow ?).
|
| Just 5 letters is less annoying to type repeatedly than
| .internal, while still conveying the overall purpose relatively
| well.
|
| It might just be my laziness talking though.
| steve_adams_86 wrote:
| I liked this idea at first, but the more I think about it the
| less I'm sure it works. Intra seems like a word which denotes
| physical boundaries to be within. It prefixes words like
| intramural, intramuscular, and intracellular. It's used for
| intranet as well, and while this usage of the prefix works, it
| has more broad use-cases than that. On the other hand, internal
| seems very clear and direct, and might suit a more digital,
| organizational context with less of a physical or spatial
| aspect to it.
|
| Also, since intra is typically used as a prefix, it seems
| strange to use it bare. People familiar with intranets will
| probably make (or assume) the connection, but others might find
| it unclear while "internal" would likely not be.
|
| Even so, I do prefer .intra for selfish reasons.
| deng wrote:
| You are not alone. Typing matters, 'internal' is just too long.
| I'd much prefer if they for instance would reserve '.lan' for
| internal usage.
| Terretta wrote:
| so, for example, an entirely internal zero trust network
| across all locations, should be .lan and not .internal?
|
| .lan is so "back to office"
| josho wrote:
| Isn't it possible to setup a default search domain. So most
| places you could just type something like https://site/ and
| your dns config knows to look for https://site.internal/
| hannob wrote:
| Counterpoint: .internal is much easier to understrand, .intra
| sounds like a reference to "intranet" as opposed to "internet".
| That's terminology networking people would use, but .internal
| is likely something both non-tech and tech people would
| intuitively understand.
| DiabloD3 wrote:
| I use .localnet to go with the name of localhost, as this has
| been suggested by ... one of the RFCs, but I can't remember
| which.
|
| If .localnet ever becomes a real TLD, well, I'm pretty sure the
| entire global infra is going to collapse and not necessarily be
| my problem.
|
| Edit: And to be clear, I'm doing this for my house, not some
| enterprise setup; using real actual FQDN for internal services at
| a company, especially one that is multi-site/cloud, is still the
| best advice.
| erik_seaberg wrote:
| I've seen localhost.localdomain often but I'm not sure whether
| it's actually reserved.
| mezzode wrote:
| As others have mentioned there already is the ".home.arpa" TLD
| but I definitely think ".internal" is a step up in terms of
| clarity. That said, for my internal network I just put things
| under a subdomain of a domain I own so I can use HTTPS with a
| proper SSL cert
| MaxBarraclough wrote:
| That seems like a great way to go - get it signed the normal
| way and TLS will 'just work', no messing about configuring
| trust on your devices.
|
| Will this be possible with _.internal_ ?
| ahoka wrote:
| You can use a proper certificate with any domain you like.
| eqvinox wrote:
| except not with .home.arpa .internal .lan or whatever else,
| since you don't have "domain ownership"
| eqvinox wrote:
| > I just put things under a subdomain of a domain I own
|
| Yup, same here. Great in combination with ACME DNS-01 so your
| DNS server can request all those certificates and then push
| them out to your devices. (Otherwise the hostnames need to be
| externally accessible, which means either exposing the internal
| devices, or mucking around with split-view DNS. The former is a
| terrible idea, the latter is also DNS server complexity and
| worse than doing DNS-01 IMHO.)
| mdaniel wrote:
| IMHO if you are already doing some process of "push
| certificates out to devices," you'll likely be much happier
| with getting a wildcard cert using DNS-01 and change that
| update process from "all devices all the time according to
| their schedule" over to "all devices but once every 80 days"
|
| I do appreciate the threat model of one device getting owned
| leaks all your certs but security is always a trade-off
| between security and convenience. It also lowers the load
| upon the LE servers, for what that's worth
| eqvinox wrote:
| Not sure everything updating at the same time is more
| "convenient" than staggered failures. For one, if multiple
| things break at the same time, it's easier to lock yourself
| out of things in more complicated ways. Also it's generally
| the first refresh that breaks, and everything at once only
| helps when you freshly roll out certs to a whole bunch of
| devices... if you add things incrementally (e.g. either
| because you finally get around to it, or you just bought
| something new) it makes no difference if it's all in the
| same cycle. Except now you have a wildcard cert floating
| around...
| lifthrasiir wrote:
| Another possibility is `.zz`, which technically can be a ccTLD
| but it's a user-assigned ISO 3166-1 alpha-2 code, and its last
| position makes extremely impossible for it to be repurposed as a
| valid code even in that setting. In comparison, some user-
| assigned codes like `XZ` are often used for temporary country
| codes so `.xz` would be less appropriate.
|
| It seems that ICANN did consider this choice among others, but
| reject for the lack of meaningfulness:
|
| > The qualitative assessment on the latter properties was
| performed in the six United Nations languages (Arabic, Chinese,
| English, French, Russian and Spanish). [...] Many candidate
| strings were deemed unsuitable due to their lack of
| meaningfulness. [...] In this evaluation, only two candidates
| emerged as broadly meeting the assessment criteria across the
| assessed languages. These were "INTERNAL" and "PRIVATE". Some
| weaknesses were identified for both of these candidates. [...]
|
| I wonder if this means that they only scored the highest among
| others and _all_ candidate strings were indeed unsuitable, but
| that they had to pick one anyway. I 'm not even sure that
| laypersons can relate `.internal` with the stuff for "internal"
| uses.
| unclet wrote:
| I opposite to use the `.zz`. Instead, I think this should be
| assigned as new TLD domain for all people live in any country,
| because it is a reserved ISO 3166-1 alpha-2 code, and will not
| be assigned to any country. It's the best convenient TLD for
| human on the earth.
| matrss wrote:
| I consider .xyz to be a good TLD for that purpose already,
| but .zz would be nice too.
| fmajid wrote:
| This may generate confusion with the .int gTLD used for
| international organizations like UN agencies.
| denkmoon wrote:
| .lan thanks.
| 1vuio0pswjnm7 wrote:
| Personally I use the HOSTS file instead of DNS.
|
| Alternatively I use a map file loaded into the memory of a
| loopback-bound forward proxy. No DNS.
|
| I also use loopback-bound authoritative DNS to a limited extent
| as it provides wildcards.
|
| There are ways to avoid using DNS.
|
| Most web developers do not understand DNS, or at least dislike
| it, and some get annoyed by the HOSTS file. Quite funny. But I'm
| not a developer. DNS is something I understand well enough, I
| like it, and, in addition, the HOSTS file is useful for me. But
| sometimes it's most useful for me to avoid DNS.
| sedatk wrote:
| How do you synchronize hosts file between clients?
| rzzzt wrote:
| You can set up a server listening to port 53 that will return
| the corresponding entry from a "hosts file" if you query it
| for an A record. To avoid the file growing uncomfortably big,
| it can be split up amongst hierarchically arranged servers.
| alex_suzuki wrote:
| How would you call this hypothetical system? It's almost
| like a distributed system for looking up names.
| rzzzt wrote:
| An RFC might have been submitted for this already, let me
| check!
| 1vuio0pswjnm7 wrote:
| While I have no need to lookup an address in local computer A's
| HOSTS file from local computer B as this is not how I use the
| HOSTS file, in the event that I did want computer B to look up
| addresses in computer A's HOSTS file, it seems there are many
| possible options. I could not even come close to listing all of
| them. (The discussion here is computers on a local network. Is
| there a need for a "distributed hierarchical system".)
|
| pdns_recursor can serve /etc/hosts
|
| https://docs.powerdns.com/recursor/settings.html
|
| unbound can serve "local data"
|
| https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound...
|
| dnsd from busybox can serve a HOSTS file (exec
| 2>/dev/null;while read a b c ;do echo "$b $a";done <
| /etc/hosts|busybox dnsd -c /dev/stdin -p1153 -i 10.21.66.4)
|
| tinydns would work too echo . > data
| while read a b c;do echo =$b:$a:1;done < /etc/hosts >> data
| tinydns-data ROOT=. IP=10.21.66.4 GID=0 UID=0 tinydns
|
| Or just transfer the file instead;
|
| rsync/mrsync could be used to keep computer A and computer B's
| HOSTS files the same
|
| Or ssh to transfer the HOSTS file from A to B.
| echo cat /etc/hosts |ssh -T computerB "cat > /etc/hosts"
|
| Or use ssh to query computer A's HOSTS file from computer B
| echo getent hosts name|ssh -T computerB
|
| Or some small httpd, e.g., darkhttpd httpd
| /etc --port 1153 --addr 10.21.66.4 tnftp -4o'|grep name'
| http://10.21.66.4:1153/hosts
|
| It goes on and on.
|
| But I'm not interested in using the HOSTS file in this way on
| the local network. I'm more interested in IP addresses than
| "domain names". I am not a fan of web browsers; I make HTTP
| requests from the shell command prompt and from shell scripts.
| For example, I like to create shortcuts for certain IP
| addresses so I do not have to type them, e.g., when using
| netcat. For me, the HOSTS file works perfectly for that
| purpose. I use this functionality every day.
|
| Not every computer on my local network has the same ability to
| lookup names and IP addresses. Most have zero access to DNS
| data. No lookups. Some may only be able to lookup a few remote
| addresses. I might put those in the computer's HOSTS file.
| 1vuio0pswjnm7 wrote:
| There is a fear or hatred of /etc/hosts amongst web
| developers. A regurgitated origin story about DNS and a
| perpetuated myth about the HOSTS file, having to do with
| constantly dynamic IP addresses. But the truth is that the
| conditions of the internet have changed. As someone who uses
| static, stored DNS data, and as such possesses a large chunk
| of historical DNS data, I have proof that, for the websites I
| may visit, most IP addresses do not change frequently.
|
| Domain names are overrated. Web marketing hype. For example,
| no one uses a domain name to log into their router. But no
| one at home is getting internet access without typing an IP
| address at least once to set up a router. If I want to type a
| short, memorable name instead of an IP number to reach a
| computer on the local network I can make an entry in
| /etc/hosts. Using computers that have no /etc/hosts and no
| control over DNS sucks. Let web developers use those
| computers.
|
| How many times have I seen developers copy entire portions of
| RFC 1035 into their code as a "comment". Too many to count.
| They will always struggle to understand it.
| hyperman1 wrote:
| I'd revently ran into this, after using .local for a long time,
| and installing something with mdns. Nslookup gave the correct ip,
| but ping got confused.
|
| A quick google did not deliver a decent reserved domain, but
| multiple people suggested .home
| dkpk wrote:
| Stumbled across this thread from 2020 -
| https://news.ycombinator.com/item?id=24606723
| tracker1 wrote:
| I think imternal, .lan, .inside should all be reserved and
| established to never allow registration with OCANN.
| greatgib wrote:
| So sad that a big tech company stole the dot dev thanks to the
| ICANN greediness...
| nbadg wrote:
| It would be nice to see this paired with more widespread support
| for the Name Constraints TLS extension, which would in theory
| allow internal CAs to be restricted to issuing certificates for
| .internal domains. That would open up a lot of very interesting
| applications in terms of streamlining HTTPS on local networks,
| for example, ACME on openWRT routers.
| 8organicbits wrote:
| Absolutely. We're getting closer, but it's hard to measure what
| actually supports it as bettertls (the caniuse equivalent in
| this space) doesn't track it.
|
| https://github.com/Netflix/bettertls/issues/19
| teleclimber wrote:
| Note there was a W3C community group that explored the "HTTPS
| on local networks" question. It's closed now but they wrote
| use cases and proposals:
|
| https://www.w3.org/community/httpslocal/
| https://httpslocal.github.io/proposals/
| https://httpslocal.github.io/usecases/
|
| I wish some of this work would continue as well.
| tensility wrote:
| After reading through the threads, I still think that '.lan' is a
| better non-reserved suffix to use for this than '.internal';
| however, my opinion rarely has significant weight in the grand
| scheme of things.
| dubcanada wrote:
| Do you have a reason why you think '.lan' is better then
| '.internal' besides being shorter? I am curious why.
| surfingdino wrote:
| lan = LAN or Local Area Network
| TkTech wrote:
| And when you're using it to connect to devices not physically
| on your LAN, like servers reached via tailscale? `.internal`
| implies your internal network, however it may be setup, `.lan`
| implies your "local" area network.
| gmuslera wrote:
| What about ssl? will that work with i.e. letsencrypt?
| dubcanada wrote:
| I suspect you'd need to generate your own, unless they intend
| on allowing people to register them. It's hard to provide a SSL
| for the 100,000 different "tv.internal".
| crote wrote:
| It shouldn't. There is no way to prove ownership of a domain,
| because _everyone_ owns it. Both a genuine company and their
| attacker have the right to use the .internal TLD, so both
| should be granted a certificate. This makes it completely
| trivial for the attacker to MitM the company 's TLS
| connections.
|
| The only option to somewhat-securely run TLS would be to have
| the company run their own internal CA, and trust its root
| certificate on all internal clients.
| 8organicbits wrote:
| The server authentication story is fairly weak. Multiple
| companies may use the same .internal domain name and none of them
| can get a TLS certificate from a public certificate authority.
| This means they'll each need to operate a private CA if they want
| to authenticate connections to the server (and encrypt with
| HTTPS). A major problem with this approach is that computers
| (especially laptops) travel between networks and can end up
| trusting more than one private CA. This means that you can have
| multiple servers using the same domain name, but operated by
| different orgs, and each appears valid to the end user. Session
| cookies and other data can leak when this happens.
|
| I think the right solution is that we should require domain
| registration (google.internal, microsoft.internal, etc.) to avoid
| these conflicts. A public CA may be able to verify ownership,
| avoiding the need for private CAs.
|
| I built a service [1] that does this and is compatible with Let's
| Encrypt. The trick is that I only allow users to set ACME-DNS01
| TXT records, not A/AAAA/CNAME records. So you'll still need to
| run internal DNS for those.
|
| [1] https://www.getlocalcert.net/
| crote wrote:
| What's the benefit over just buying a regular domain for my
| internal stuff? The result would be about the same, and I
| wouldn't be dependent on you never going out of business.
| 8organicbits wrote:
| Even with a TLD, going out of business is a concern. Take
| Freenom as an example, they had rampant abuse and ran into
| funding issues. People who previously used that service for
| free internal domains have been looking for a new home.
|
| What's different is that the public suffixes I operate cannot
| publicly host content, which should protect the service from
| the abuse concerns that plagued Freenom and other free public
| suffixes. That reduces cost and should keep the site running.
|
| I recommend buying your own domain if you don't mind the
| cost. A free solution for domains with TLS on internal
| networks is valuable to many.
| icedchai wrote:
| I use a subdomain of "int" for all internal hosts:
| host.int.example.com. My internal machines have int.example.com
| and example.com in the search path.
| throwawaaarrgh wrote:
| If it doesn't get accepted I'll use .arpanet because nobody's
| registering that
| VoodooJuJu wrote:
| Why did this take so long?
| traceroute66 wrote:
| .corp, .home and .mail should also be perfectly viable for
| private use after ICANN eventualy decided to cease all processing
| of applications for those TLDs. "Whereas, on 30
| July 2014, the ICANN Board New gTLD Program Committee adopted the
| Name Collision Management Framework. In the Framework, .CORP,
| .HOME, and .MAIL were noted as high-risk strings whose delegation
| should be deferred indefinitely".[1]
|
| [1] https://www.icann.org/en/board-activities-and-
| meetings/mater...
| lolinder wrote:
| Deferred indefinitely is not quite the same thing as reserved
| for private use. For home use cases it's probably good enough,
| but a corporation will want more assurance than "the current
| ICANN has stopped processing applications for this TLD."
| przemub wrote:
| Yeah, with Google getting .dev we can't count on ICANN being
| reasonable.
| reactordev wrote:
| Actually, if history is any indicator, we can't trust _any_
| of these companies with this. Remember the org tld private
| equity fiasco? ICANN only did something after public outcry
| and EFF interest.
| NewJazz wrote:
| ICANN persisted with their antics until the California
| attorney general announced an inquiry into the deal. Only
| then did ICANN change their plans.
| yencabulator wrote:
| I trust ICANN to be the opposite of reasonable if they can
| make money off of it.
| fl0ki wrote:
| This is exactly how a committee would design it if none of the
| participants had actually used an internal domain.
|
| For example, in Google, https://go/foo had "go" as technically a
| TLD, and the memorable suffix that followed was already part of
| the path and not the domain name. It made it easy to type or
| include anywhere, including chats, posters, presentation slides,
| etc.
|
| If they were to follow this proposal instead, you'd be typing or
| including https://go.internal/foo , which while more explicit
| largely defeats the point of the short URL.
| dogleash wrote:
| https://en.wikipedia.org/wiki/Search_domain
| nullindividual wrote:
| Are you sure go wasn't just the hostname?
|
| This was very common in Windows shops back in the NT and even
| post-NT4 days to leverage the hostname as the URL
| (http://exchange, http://sharepoint, and so on).
| jmgao wrote:
| I'm pretty sure it was go.corp.google.com, with corp.google.com
| configured as one of the search domains.
| fl0ki wrote:
| I think it was both, because I think it also worked even when
| it wasn't a search domain. Can anyone still at Google check?
| eqvinox wrote:
| "foo.int/ernal" lookalike attacks in 3... 2... 1...
|
| (to be fair, you generally can't get an .int domain registered.
| "int is considered to have the strictest application policies of
| all TLDs, as it implies that the holder is a subject of
| international law.")
|
| ... now that I think about it, "foo.in/ternal" makes so much more
| sense ...
| GTP wrote:
| But you could do that with any domain, what's special in this
| case?
| eqvinox wrote:
| > what's special in this case
|
| There's an existing TLD that is a string prefix of the new
| TLD.
|
| Apart from lookalike attacks I'm also wondering if this will
| do weird things while you type in an address, e.g. if you try
| to type "foo.internal" and pause for a second after
| "foo.int"... your application may run off and do lookups or
| even prefetches.
| lodovic wrote:
| Please allow self-signed certificates for ".internal" by default
| yencabulator wrote:
| If all self-signed certs are allowed by default, then the
| crypto means nothing at all -- that's not good.
| rzzzt wrote:
| Crypto is/could be still fine, it will still make it harder
| for others to see the contents of the conversation that is
| going on between the two machines.
|
| What you are losing is the modicum of confidence that a
| website is the real deal because another party (that browser
| and OS manufacturers trust) took the time to, at the very
| least, verify ownership of the domain.
| yencabulator wrote:
| Automatically trusting any cert raises the bar for
| attackers from passive snooping to MITM. On a home
| LAN/wifi, MITM is pretty much as likely as passive
| listening. At the very least you need TOFU (trust-on-first-
| use) for any kind of real attack prevention.
| caymanjim wrote:
| Didn't .local start out this way until it was co-opted by Apple
| for some network abomination? Any new private domain is just
| going to get co-opted by something else soon enough. Browser
| authors and network service authors are going to start using it
| for random, incompatible purposes and break everything.
|
| If you need DNS, register and use a real domain name. Everything
| else is going to be a hack. Anyone tech-savvy enough to know what
| an internal, unroutable TLD is, and have a use for one, is going
| to be just as comfortable and capable of managing a real domain.
|
| I support the idea of something like .internal, but I'm certain
| it will be made useless for its intended purpose in short order.
| josho wrote:
| I can see one benefit to this approach.
|
| Messing up your .internal configuration won't result in leaking
| queries to the public.
|
| And maybe secondarily this may encourage tool development for
| supporting internal names and make it easier for setting up
| informal or per department configurations.
| Arch-TK wrote:
| I just use i.slow.network as my internal domain. Most things
| support search domains to avoid having to type too much.
| whycome wrote:
| I can't find it now, but wasn't there a story about microsoft
| using a 'dummy' url in some internal documents that later became
| real?
| miles wrote:
| Yes:
|
| Microsoft Buys Corp.com So Bad Guys Can't
| https://krebsonsecurity.com/2020/04/microsoft-buys-corp-com-...
___________________________________________________________________
(page generated 2024-01-27 23:02 UTC)