15 ms·

Proposed top-level domain string for private use: ".internal"

• NoZebra120vClip 3y ago
  Other currently reserved TLDs: https://en.wikipedia.org/wiki/Top-level_domain#Reserved_domains https://en.wikipedia.org/wiki/Top-level_domain#Reserved_doma...
  • gnabgib 3y ago
    .example (for examples), .invalid (invalid domains), .localhost (avoids conflict with localhost hostname), .test (for tests), .local (link-local names), .onion (for Tor)
    • jchw 3y ago
      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 3y ago
        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 https://datatracker.ietf.org/doc/html/rfc6761#section-6.3
        • globular-toast 3y ago
          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 3y ago
          I actually did not know this was specified by a standard. That does indeed make it perplexing that not all resolvers do it.
        • NoZebra120vClip 3y ago
          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 3y ago
      what about .localdomain? I haven't been able to find anything standards-wise about it.
  • AndyMcConachie 3y ago
    The IANA link is probably better. https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml https://www.iana.org/assignments/special-use-domain-names/sp...
• vmurthy 3y ago
  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 :)
  • deleted 3y ago
    [deleted]
• gnabgib 3y ago
  ICANN: [Proposed Top-Level Domain String for Private Use](https://www.icann.org/en/public-comment/proceeding/proposed-top-level-domain-string-for-private-use-24-01-2024 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_ 3y ago
  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 https://en.wikipedia.org/wiki/Example.com
• p1mrx 3y ago
  Eh, .internal is fine, but it's 8 characters to type. I'll probably keep using .lan until someone else takes it.
  • ahmedfromtunis 3y ago
    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-top-level-domain-string-for-private-use-24-01-2024 https://www.icann.org/en/public-comment/proceeding/proposed-...
    • p1mrx 3y ago
      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 3y ago
        Ha, excellent
        • p1mrx 3y ago
          Submitted to ICANN; everybody keep yelling .interNAL until it happens!
      • pxtail 3y ago
        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 3y ago
    Not all use cases for .internal involve a LAN though.
• LeoPanthera 3y ago
  Also worth noting that "home.arpa" is already reserved and specifically designed for residential use. It will never conflict with anything.
  • Mountain_Skies 3y ago
    And is nine characters long, which is cumbersome for those using it in an IOT context where data entry is often not straightforward.
    • fastball 3y ago
      Huh?
      • Filligree 3y ago
        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 3y ago
          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 3y ago
      so, exactly the same as .internal
      • eqvinox 3y ago
        You didn't quite count that right with the dots ;)
  • scraplab 3y ago
    I use this, mostly for the .arpa vibes.
• matt3210 3y ago
  .local already does this
  • CountSessine 3y ago
    .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?
  • Brian_K_White 3y ago
    Only to the same extent that .test and .example do, which is to say it does not.
  • miles 3y ago
    > .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 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 https://en.wikipedia.org/wiki/.local 3. "PSA: Don't use domain.local" https://old.reddit.com/r/sysadmin/comments/a9sfks/psa_dont_use_domainlocal/ 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-local-as-your-domain-name-extension-is-a-bad-idea-4828 https://community.veeam.com/blogs-and-podcasts-57/why-using-...
    • axytol 3y ago
      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.
• dang 3y ago
  Url changed from https://domainincite.com/29381-icann-picks-the-domain-it-will-never-ever-release https://domainincite.com/29381-icann-picks-the-domain-it-wil..., which points to this.
• amne 3y ago
  .intranet ?
• INTPenis 3y ago
  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 3y ago
    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 3y ago
      > 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 3y ago
        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 3y ago
    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.
    • 3y ago
• rickette 3y ago
  host.docker.internal
• w-ll 3y ago
  since ".dev" was hijacked ive been using ".lan" and ".lab"
  • mongol 3y ago
    I also use .lan
  • 8organicbits 3y ago
    To be fair, .dev TLD seems to imply developer or development. .internal is a broader name and even if .dev was an option it probably wouldn't be selected.
• loupol 3y ago
  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 3y ago
    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 3y ago
    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 3y ago
      so, for example, an entirely internal zero trust network across all locations, should be .lan and not .internal? .lan is so "back to office"
      • rubatuga 3y ago
        zero trust means no distinction between LAN and WAN, what do you mean?
    • josho 3y ago
      Isn’t it possible to setup a default search domain. So most places you could just type something like https://site/ https://site/ and your dns config knows to look for https://site.internal/ https://site.internal/
• DiabloD3 3y ago
  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 3y ago
    I’ve seen localhost.localdomain often but I’m not sure whether it’s actually reserved.
• mezzode 3y ago
  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 3y ago
    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 ?
    • 8organicbits 3y ago
      The TLS cert will either be self-signed or you'll need to run a private CA. A public CA won't issue you a cert as you can't own any .internal domain.
  • ahoka 3y ago
    You can use a proper certificate with any domain you like.
    • eqvinox 3y ago
      except not with .home.arpa .internal .lan or whatever else, since you don't have "domain ownership"
  • eqvinox 3y ago
    > 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.)
    • 3y ago
• fmajid 3y ago
  This may generate confusion with the .int gTLD used for international organizations like UN agencies.
• lifthrasiir 3y ago
  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 3y ago
    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 3y ago
      I consider .xyz to be a good TLD for that purpose already, but .zz would be nice too.
    • deleted 3y ago
      [deleted]
    • lifthrasiir 3y ago
      There is not much to gain from having a new two-letter gTLD instead of existing all-purpose three-letter TLDs (say, `.com`, `.ooo` or `.xyz`). Especially given that every TLD needs a registry, and `.zz` would be a particularly extra-special gTLD that needs a special procedure to select the registry. Better to make it a reserved TLD if it is ever going to be used.
• denkmoon 3y ago
  .lan thanks.
• 1vuio0pswjnm7 3y ago
  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 3y ago
    How do you synchronize hosts file between clients?
    • deleted 3y ago
      [deleted]
    • rzzzt 3y ago
      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 3y ago
        How would you call this hypothetical system? It’s almost like a distributed system for looking up names.
        • rzzzt 3y ago
          An RFC might have been submitted for this already, let me check!
  • 1vuio0pswjnm7 3y ago
    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 https://docs.powerdns.com/recursor/settings.html unbound can serve "local data" https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html 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.
• hyperman1 3y ago
  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 3y ago
  Stumbled across this thread from 2020 - https://news.ycombinator.com/item?id=24606723 https://news.ycombinator.com/item?id=24606723
• tracker1 3y ago
  I think imternal, .lan, .inside should all be reserved and established to never allow registration with OCANN.
• throwawaaarrgh 3y ago
  If it doesn't get accepted I'll use .arpanet because nobody's registering that
• greatgib 3y ago
  So sad that a big tech company stole the dot dev thanks to the ICANN greediness...
• nbadg 3y ago
  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 3y ago
    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 https://github.com/Netflix/bettertls/issues/19
    • teleclimber 3y ago
      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://www.w3.org/community/httpslocal/ https://httpslocal.github.io/proposals/ https://httpslocal.github.io/proposals/ https://httpslocal.github.io/usecases/ https://httpslocal.github.io/usecases/ I wish some of this work would continue as well.
  • deleted 3y ago
    [deleted]
• deleted 3y ago
  [deleted]
• tensility 3y ago
  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 3y ago
    Do you have a reason why you think '.lan' is better then '.internal' besides being shorter? I am curious why.
    • surfingdino 3y ago
      lan = LAN or Local Area Network
    • m463 3y ago
      It is already in use many places. Isn't it the default domain name for OpenWRT? Just like the default ip addresses are 192.168.*
  • TkTech 3y ago
    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 3y ago
  What about ssl? will that work with i.e. letsencrypt?
  • dubcanada 3y ago
    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 3y ago
    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 3y ago
  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/ https://www.getlocalcert.net/
  • crote 3y ago
    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 3y ago
      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 3y ago
  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.
• VoodooJuJu 3y ago
  Why did this take so long?
• traceroute66 3y ago
  .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/materials/approved-board-resolutions-regular-meeting-of-the-icann-board-04-02-2018-en#2.c https://www.icann.org/en/board-activities-and-meetings/mater...
  • lolinder 3y ago
    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 3y ago
      Yeah, with Google getting .dev we can't count on ICANN being reasonable.
      • reactordev 3y ago
        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 3y ago
          ICANN persisted with their antics until the California attorney general announced an inquiry into the deal. Only then did ICANN change their plans.
      • yencabulator 3y ago
        I trust ICANN to be the opposite of reasonable if they can make money off of it.
• fl0ki 3y ago
  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 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 https://go.internal/foo , which while more explicit largely defeats the point of the short URL.
  • dogleash 3y ago
    https://en.wikipedia.org/wiki/Search_domain https://en.wikipedia.org/wiki/Search_domain
  • nullindividual 3y ago
    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://exchange, http://sharepoint http://sharepoint, and so on).
  • jmgao 3y ago
    I'm pretty sure it was go.corp.google.com, with corp.google.com configured as one of the search domains.
    • fl0ki 3y ago
      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 3y ago
  "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 3y ago
    But you could do that with any domain, what's special in this case?
    • eqvinox 3y ago
      > 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.
      • lifthrasiir 3y ago
        That happens pretty regularly anyway, e.g. `example.com` vs. `example.co/m` or `example.net` vs. `example.ne/t` (and both `.co` and `.ne` allow SLD registrations).
• lodovic 3y ago
  Please allow self-signed certificates for ".internal" by default
  • yencabulator 3y ago
    If all self-signed certs are allowed by default, then the crypto means nothing at all -- that's not good.
    • rzzzt 3y ago
      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 3y ago
        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.
        • lodovic 3y ago
          The reality is that most people have unencrypted communication with their home appliances because the certificate isn't trusted.
    • lodovic 3y ago
      So rather no crypto at all?
      • 8organicbits 3y ago
        The problem is ownership and trust roots. If you don't uniquely own a domain name then you can't get a TLS cert for it from a public CA. Private CAS still work, but are challenging. I've been exploring private-use-only domain registration at https://www.getlocalcert.net/ https://www.getlocalcert.net/, which is compatible with LetsEncrypt.
• caymanjim 3y ago
  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 3y ago
    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.
  • snakeyjake 3y ago
    Zeroconf is only considered an abomination by folks who view any naming system other than DNS to be an abomination. Domain names are not slaved to DNS, they predate DNS by over a decade, and there is room for more than one naming system. If DNS has to surrender one of their precious, precious, TLDs (lord knows there are soooo few to choose from) which, again, existed BEFORE DNS was even a twinkle in Paul Mockapetris' eye, so be it.
• Arch-TK 3y ago
  I just use i.slow.network as my internal domain. Most things support search domains to avoid having to type too much.
• whycome 3y ago
  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 3y ago
    Yes: Microsoft Buys Corp.com So Bad Guys Can’t https://krebsonsecurity.com/2020/04/microsoft-buys-corp-com-so-bad-guys-cant/ https://krebsonsecurity.com/2020/04/microsoft-buys-corp-com-...
• kaliszad 3y ago
  If you have a customer and DNS seems to work strangely, have a look if you don't have a so called single-label domain for Active Directory, such as host1.internal or crusty.internal if you have more creative admins or even worse, db.local. On Windows, the name resolution on single-label domains behaves a bit differently, using NetBIOS resolution which can prevent you from e.g. adding a new host to the domain from a different subnet - you might see this as DNS failure. Of course, it is not DNS's fault, if it wasn't asked in the first place. Here are some more details: https://support.microsoft.com/en-us/help/300684/deployment-and-operation-of-active-directory-domains-that-are-configur https://support.microsoft.com/en-us/help/300684/deployment-a... and https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.NetLogon::Netlogon_AllowSingleLabelDnsDomain https://admx.help/?Category=Windows_10_2016&Policy=Microsoft... which does the DNS resolution even for these less than ideal domains.
• deleted 3y ago
  [deleted]
• dingi 3y ago
  That's too long. I just bastardize an existing tld on local network like home.net. Some browsers don't even allow made up names. Internal is too long to type.
• m3drano 3y ago
  it seems to cover the whole RFC 1918 (IPv4) and 4193 (IPv6), so not only 192.168.0.0/16 like some media indicated.
• DavideNL 3y ago
  So as others have mentioned there already is the ".home.arpa" TLD; Would the only difference then be the name ".internal" or is there another difference/advantage versus ".home.arpa"?