Icann kiest .internal als nieuw topleveldomeinnaam voor interne netwerken

De Icann heeft .internal als nieuw topleveldomeinnaam verkozen voor interne netwerken. De organisatie vraagt nu om feedback op deze beslissing te geven. Het is nog niet duidelijk wanneer de domeinnaam in gebruik genomen gaat worden.

Met deze ontwikkeling kunnen gebruikers uiteindelijk bijvoorbeeld toegang tot hun router krijgen door naar .internal te navigeren. Een dergelijk tld zou hoe dan ook niet in het publiekelijke dns verschijnen. In een document detailleert de domeinnaamorganisatie dat het publiek zoals gebruikelijk de kans heeft om te reageren op de keuze, waarna Icann definitief besluit of de domeinnaam in gebruik genomen gaat worden.

Een aparte commissie van de Icann, het Security and Stability Advisory Committee, overweegt sinds 2020 wat de nieuwe extensie voor interne netwerken zou moeten worden, zo detailleert The Register. De commissie overwoog 35 verschillende tld's, waaronder .domain, .private en .internal. Ze wees de eerstgenoemde topleveldomeinnaam af omdat de term niet goed zou signaleren dat het om een privéverbinding gaat. De naam .private wees ze af omdat de naam 'onbedoeld de implicatie van een verhoogde mate van privacy zou kunnen wekken' en omdat de term vertaald naar andere talen conflicterende betekenissen had.

Reacties (153)

[Vorkie]

Wat is er mis met .local?

[Dreamvoid]

.local is gereserveerd voor het veelgebruikte mDNS protocol, dat mag niet voor DNS gebruikt worden.

https://en.m.wikipedia.org/wiki/.local

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 15:03]

[Yariva]

Exact de reden waarom ik thuis onlangs alles heb omgezet van .local naar .internal. Windows bakken vonden het allemaal nog wel prima maar een aantal Linux bakken konden .local niet resolven en hielden zich (terecht) aan de standaard.

[Dreamvoid]

mDNS werd pas in 2013 gestandaardiseerd, dus er zijn nog netwerken (en netwerk admins ) die ooit .local hadden geconfigureerd voor DNS, en sindsdien niet meer zijn geupdate.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 15:03]

[Yariva]

Ja zeker eens. Tot kort gooide ik ook alles nog op .local en ik heb zelf de nodige AD's destijds opgezet met Server 2012 (en volgens mij ben ik dan zelfs een laat bloeier in vergelijking met andere Tweakers ). Altijd, ook vanuit studie, was het advies om .local te gebruiken. Dat was simpelweg de "onofficiële" standaard.

[Blokker_1999]

Dan heb je eigenlijk lesgevers gehad die beter hadden moeten weten. Er bestaan namelijk 4 gereserveerde TLDs die je intern kan en mag gebruiken, maar .local valt daar niet onder. Deze zijn:
.example
.localhost
.test
.invalid

Tijdens je studie had je dus gewoon .test of .example moeten gebruiken. En ga je in productie in een bedrijf, zorg dan dat je een domeinnaam neemt waarvan je ook gewoon eigenaar bent.

[GoBieN-Be]

De externe domeinnaam van de website/e-mail ook gebruiken als domein in Active Directory is een valide keuze, maar zeker ook 1 met gevolgen. Je creëert dan een Split-DNS situatie.

Een andere domeinnaam dan je website/e-mail gebruiken voor interne Active Directory is zeker een goed idee, maar zorg dat je zeker die domeinnaam in eigendom hebt en controle over de DNS records.

In Microsoft documentatie gebruiken ze soms de TLD CORP, maar dat lijkt me ook geen goed idee eigenlijk. Als .internal officieel een TLD wordt die niet publiekelijk kan resolven dan lijkt me dat een goede optie.

[OruBLMsFrl]

Eens met wat je zegt, tegenover "Je creëert dan een Split-DNS situatie." wil ik wel aanvullen:
- "je bespaart je medewerkers het leren vertrouwen van twee verschillende domeinnamen uit"
- "kun je makkelijk publiek en daarmee universeel geldige certificaten voor aanvragen"

Hoe meer domeinnamen je moet vertrouwen, hoe meer kans op phishing. Straks krijg je vast weer een phishing golf over wat jaren met <uwbedrijf>.internal.com als je anders <uwbedrijf>.internal en <uwbedrijf>.com gebruikt of anders wel <uwbedrijf>.internal.corp en zo meer. Echt maar één officiële domeinnaam hebben en die zowel extern als intern gebruiken maakt de kans op misbruik lager, maar inderdaad, daar heb je wel iets extra DNS beheer aan.
Als je domein nooit publiek actief gecontroleerd kan worden qua DNS records of publieke e-mailadressen, dan zullen SSL authorities vermoedelijk ook geen of minimaal niet eenvoudig en veilig .internal SSL certificaten kunnen uitgeven.

[GoBieN-Be]

Klopt volledig wat je zegt. Daarom gebruiken wij meestal dezelfde domeinnaam intern en extern.
Bijkomend probleem is wel dat websites met gewoon https://domein.tld niet werken omdat het root altijd verwijst naar de DC. Dus als je eigen website www redirect naar root is dat een probleem.

[Memori]

Daar had best .lan aan toegevoegd mogen worden (door Icann) als je het mij vraagt. Lekker kort en duidelijk.

[Tweak3D]

ik gebruik alktijd .lan, en dat levert dan gefronste wenkbrauwen op.. eigenlijk kan alles als het maar niet op het internet te vinden is. Ik vindt/vondt .local maar niks

[erikmeuk3]

Het is maar wat je als gebruiken ziet.
.example is voor voorbeelden in documenten.
.invalid daar zou niets op moeten reageren.

Er zijn er wel meer, zoals .alt

[Powermage]

een traditionele AD dateerd idd vaak wel ruim van voor 2013.

[Blokker_1999]

Alleen is .local nooit gestandariseerd geweest voor intern gebruik. Er zijn andere TLDs zoals .test die dat wel zijn en waarvan recursive DNS servers weten dat ze die niet moeten gaan vragen aan de root DNS servers, maar .local valt daar niet onder en staat dan ook in de top van meest gevraagde .TLDs aan de rootservers.

[mati1983]

Dit

Daarnaast vind ik zelf, maar wellicht meer een taalkundige discussie, dat 'local' verwijst naar iets, jaja komt ie, 'lokaals', oftewel localhost. Een pc in hetzelfde netwerk, hoeft geenszins lokaal te zijn. Met 'internal' verwijs je mijns inziens veel duidelijker naar iets binnen je eigen netwerk. Binnen je eigen gecontroleerde stadsmuren.

[Dreamvoid]

Local Area Network is toch wel een ingeburgerde term, en ik neem aan dat als mDNS niet al bestond sinds 2013, ICANN ook graag .local had gebruikt hiervoor.

[mati1983]

Ja, maar de toevoeging 'area network' maakt daarin wel een wereld van verschil. Althans, in mijn beleving/lezing van de term.

[Anoniem: 1990104]

Local Area Network is binnen Tweakers een ingeburgerde term, maar het gaat hier ook om de gebruikers van een dergelijke site. En daarvan weet denk ik 99% niet wat een local area network is, aangezien het niet een alledaagse term is buiten mensen die voor hun werk met technologie bezig zijn.

[karma4]

"Internal" is denk een goede keuze voor logische duiding.
Ik zet wel met de vraag wat dan internal voor technische dan wel functionele scope moet hebben.
Ik houd het even op een functionele voor een organisatie. De spraakverwarring is als het technisch internal in een datacenter (could) betreft. Dan gaat het onverwacht over organisaties heen.


De lokale printer was en is een vreselijke spraakverwarring. Lokaal bij jou in de buurt of lokaal naast die cloud machine is een behoorlijk verschil.

Ik zit nog met het dom volgen van voorbeelden. "corp.com" is zo'n prachtig voorbeeld van iets wat intern wel goed ging totdat het ook ineens extern ging.

[xFeverr]

Dat is localhost toch? Niet persé intern netwerk?

[Jelmer]

.local Is jaren lang als defacto standaard door consultants en beheerders gebruikt als tld voor de interne Active Directory.

[Halfscherp]

Terwijl Microsoft in hun documentatie met klem adviseert om ook intern alleen TLDs te gebruiken die je zelf bezit

[vtsalf]

Dat doet Microsoft gelukkig nu wel ja, maar ze hebben zelf vroeger jaren aangeraden om .local te gebruiken als interne TLD.

Zie het installatiescherm van Small Business Server 2003:

https://uploads-eu-west-1...729-b08c-d094776373b5.png

Tekst van de image:

“We recommend using the extension .local for the full DNS name for your internal domain. Because .local is not registered for use on the Internet, your internal domain and your public Internet domain (such as .com or .net) remain separate. This is more secure and avoids name resolution issues.”

[Dreamvoid]

Dat doet Microsoft gelukkig nu wel ja, maar ze hebben zelf vroeger jaren aangeraden om .local te gebruiken als interne TLD.

Klopt, tot 2013 hebben ze dit gedaan (voordat mDNS een standaard werd en die TLD off-limits werd). Microsoft adviseert al behoorlijk lang om dat niet meer te doen, zeker sinds Windows 10 in 2017 mDNS standaard ging gebruiken, maar veel Windows admins die pre-2013 hun certificaties haalden hebben die memo gemist.

[Powermage]

Veel AD netwerken bestaan ook gewoonweg langer dan 2013, nu is een AD renamen al niet t meest handige klusje, en helemaal niet als je er nog een Exchange in hebt zitten...

Overigens kan een TLD en subdomein voor je AD gebruiken die je bezig ook weer onverwachte zaken geven in je communicatie, dus an sich is een "niet bestaande AD" voor de meeste zaken meer dan prima.

Al met al genoeg redenen om t maar door te laten lopen en vanzelf een keer te laten uitsterven.

[Tirinium]

Dat is niet alleen Microsoft, dat is een verbond van alle grote netwerk vendoren en dat geld al meer dan 30 jaar.

[The Lord]

Er zat af en toe wat documentatie van Microsoft tussen (meeste is gecorrigeerd voor zover ik weet) waar het wel degelijk, gemotiveerd, in staat/stond.

Maar volgens mij nooit in de 'stap voor stap' architectuur ontwerp documentatie.

[Dreamvoid]

Bovendien gebruikt Windows vanaf 2017 standaard mDNS, dus .local kan je sowieso niet meer gebruiken in je DNS.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 15:03]

[Anoniem: 1576590]

Halfscherp scheeef:

Terwijl Microsoft in hun documentatie met klem adviseert om ook intern alleen TLDs te gebruiken die je zelf bezit

Terecht, want .local maar ook .internal domeinnamen zijn niet gegarandeerd wereldwijd uniek (voor zover het publieke DNS-systeem betrouwbaar is).

Unieke domeinnamen zijn belangrijk om in elk geval de volgende redenen:

• Steeds meer mensen werken thuis (of sowieso buiten de deur). Als een VPN het niet (goed) doet, kun je op een andere server uitkomen met toevallig of opzettelijk dezelfde domeinnaam.
• X.509 aka https servercertificaten zijn zinloos (of bieden een vals gevoel van veiligheid) als domeinnamen niet uniek zijn.
• Een toenemend gebruik van DoT en DoH.

Een voorbeeld van wat er fout kan gaan is dat, als je een AVM Fritz!Box router hebt, je deze kunt benaderen met https://fritz.box (tenzij je zelf een certificaat + private key geïnstalleerd hebt, geeft dat een certificaatfoutmelding).

Uit dit artikel:

Verwirrend: Internet-Domain fritz.box zeigt NFT-Galerie statt Router-Verwaltung
Bereits vor einer Woche haben Unbekannte die Domain "fritz.box" für sich registriert. Ihr Vorhaben ist unklar, Fritz-Besitzer sollten sich vorsehen.
26.01.2024 16:15 Uhr [Security] Von Dr. Christopher Kunz

Oftewel, als je een andere DNS-provider dan die FritzBox hebt ingesteld, krijg je niet de inlogpagina van jouw router te zien.

Vergelijkbaar stom is wat IBM Aspera file transfer deed (doet?): een global DNS-lookup voor local.connectme.us dat (nog steeds) 127.0.0.1 oplevert. "Dankzij" een hardcoded private key in elke client geeft ook dit certificaat natuurlijk totale schijnveiligheid.

Als ik me niet vergis doet KPN iets vergelijkbaars in hun thuisrouters.

Aanvulling 10:20: zojuist zie ik in https://crt.sh/?q=connectme.us dat het laatste certificaat geldig was tot 2021-10-20, dus hopelijk is IBM gestopt met deze flauwe kul.

[Reactie gewijzigd door Anoniem: 1576590 op 23 juli 2024 15:03]

[Llopigat]

Nouja AD is toch alleen on prem dus wat je ook gebruikt, je kan alles gewoon afvangen in je eigen DNS. DoH is wel een ding maar legacy AD gebruikt dat niet.

Maar het is wel beter om het te doen natuurlijk ja.

Hier thuis gebruik ik een verzonnen TLD trouwens maar zakelijk zou ik dat niet doen.

[Reactie gewijzigd door Llopigat op 23 juli 2024 15:03]

[Tweak3D]

Waarom niet .. ik zou bijna durveb zeggen verzin wat, gebruik wat voor jou relevant is. .tld of.andrs whatever. het is je interne dns, iets wat jij configureert.
Wijk lekker af, maar wees consequent.

[BvdW1978]

Microsoft heeft hier sinds de release van Active Directory conflicterende aanbevelingen over gedaan. Vroeger was het advies .local (wat dus nogal lomp was van ze, maar er was destijds nu eenmaal geen wereld buiten MS), tegenwoordig adviseren ze een TLD die in eigen bezit is. En uiteindelijk zou dat nu dus .internal moeten worden. In mijn huidige werkkring schop ik al een tijdje aan tegen de noodzaak om .local te vervangen want steeds meer mdns op het netwerk en vage "problemen" daardoor. Nu komt er dus ook een van hogerhand formeel aanbevolen alternatief voor in de plaats. Blij mee.

[Cyberpuppy]

Nu nog effe implementeren en dan zijn we voor de lunch weer thuis

[BvdW1978]

Dat is best een dingetje inderdaad, maar als je nooit begint gaat er ook niets veranderen.

[Cyberpuppy]

Probleem bij de meeste systeembeheerders is dat dit soort zaken pas prioriteit kunnen/mogen krijgen als het pijn begint te doen. Voor die tijd zijn er andere dringende brandjes die weer geblust moeten worden.

[Tweak3D]

That's the spirit

[Glashelder]

Wellicht ligt het aan mij, maar in 2013 .local implementeren in een standaard is ook wel beetje een struisvogel methode. Eigenlijk is het ronduit dom te noemen.

Bekend was dat die TLD vreselijk veel intern werd gebruikt.

[BvdW1978]

De standaard is formeel nog in draft. Er is dus nog steeds invloed mogelijk.

[_Thanatos_]

Veel consumentensoftware- en devices gebruiken het ook, of stellen het voor als default. Zoals Home Assistant, om een (voor mij) recent voorbeeld te noemen.

[Sine]

Dat is dan weer mDNS

[JayPe]

mDNS, ik zie hier hier in dit draadje voorbij komen. Ik lees erover op Wikipedia, wordt niet veel (praktisch) wijzer)
Ik gebruik een PiHole en heb daar voor een aantal apparaten gegevens ingevuld bij local DNS. Is dat wat het is?

[Dreamvoid]

mDNS is een protocol waar er geen centrale adminstratie is van hostname -> IP adres, maar waar alle devices hun eigen hostname adverteren op de local link (multicast, oftewel, niet routeerbaar naar buiten, dus alleen voor simpele lokale netwerkjes). Simpelweg gezegd:
- eens in de zoveel tijd sturen hosts een multicast rond "ik ben server.local" (voor de passieve luisteraars)
- als een andere host wil verbinden naar server.local gooit hij een multicast request "wie is server.local", en de juiste server antwoordt met "yo dat ben ik, hier is mijn IP adres"
Is een erg handige manier om binnen een simpel lokaal netwerk met hostnames te werken, zonder een heel DNS circus op te tuigen

mDNS staat standaard aan op Android, Windows en Apple devices, en op veel Linux distros ook ("avahi").

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 15:03]

[JayPe]

Dat verklaard. Ik heb een aantal ESP8266 dingetjes in m'n netwerk hangen, die doen dat (mDNS) (denk ik) dus niet,. dat zijn precies de devices welke ik handmatig in de local DNS van m'n Pi-Hole heb gezet zodat ik (of beter: ESPHome / Home assistant) ze kan vinden op hostname.

[CodeCaster]

Omdat die niet is gespecificeerd als "lokaal"/intern, en er 10.000 requests per seconde uitkomen op de root-DNS-infrastructuur voor .local-domeinen, als één van de genoemde issues in https://itp.cdn.icann.org...ac-reports/sac-113-en.pdf

Zodra .internal wordt geformaliseerd en geïmplementeerd, kan een lokale DNS-server (standaard) geconfigureerd worden om een verzoek voor een .internal-record niet verder dan zichzelf of een bepaalde relay te sturen.

[Reactie gewijzigd door CodeCaster op 23 juli 2024 15:03]

[TD-er]

Dat is dan ook wel een fout van de diverse DNS services/servers online, zoals in gebruik bij internet providers.
Ik neem aan dat gewone gebruikers niet rechtstreeks de root DNS servers benaderen om te kijken waar ze moeten zijn voor het resolven van TLDs, maar dat gewoon bij de DNS van de provider doen of een eigen gekozen DNS server zoals 8.8.8.8 en 8.8.4.4 van Google, 208.67.222.222 en 208.67.220.220 van OpenDNS of een van de diverse andere opties.
Die zouden .local er al uit moeten filteren zodat deze niet verder opgezocht gaat worden anders dan via mDNS.

[CodeCaster]

Dat is geen fout. Als het niet in de RFC's staat, moet je niet willekeurig uitzonderingen gaan maken.

[TD-er]

Als het niet in de RFC's staat ben ik het daar mee eens, maar gezien de overige reacties ging ik er even gemakshalve vanuit dat het wel zo benoemd zou zijn aangezien het specifiek voor mDNS bedoeld is en dat is iets wat niet routeerbaar zou moeten zijn voorbij je router naar het publieke internet.

[Dreamvoid]

Moderne OSsen als Android herkennen .local direct al en sturen uberhaupt geen DNS verzoek uit voor die TLD.

[CyBeR]

Dat is dan ook wel een fout van de diverse DNS services/servers online, zoals in gebruik bij internet providers.
Ik neem aan dat gewone gebruikers niet rechtstreeks de root DNS servers benaderen om te kijken waar ze moeten zijn voor het resolven van TLDs, maar dat gewoon bij de DNS van de provider doen of een eigen gekozen DNS server zoals 8.8.8.8 en 8.8.4.4 van Google, 208.67.222.222 en 208.67.220.220 van OpenDNS of een van de diverse andere opties.
Die zouden .local er al uit moeten filteren zodat deze niet verder opgezocht gaat worden anders dan via mDNS.

Dat doen ze allicht ook (neem ik aan) maar de duizenden eigen resolvers die mensen en bedrijven opzetten (of vaak onderdeel zijn van routers) doen dat over het algemeen niet tenzij ze default zo ingesteld zijn.

[_Thanatos_]

Zodra .internal wordt geformaliseerd en geïmplementeerd, kan een lokale DNS-server (standaard) geconfigureerd worden

Waarom kan dat truukje niet op .local worden toegepast?

[Dreamvoid]

Omdat .local niet in DNS kan worden gebruikt, het wordt nl. al gebruik voor mDNS protocol.

[.oisyn]

Dat is geenszins antwoord op zijn vraag. Sterker nog, jouw antwoord doet suggereren dat de situatie al zo moet zijn dat .local requests niet geforward zouden moeten worden door DNS servers. Toch doen ze het. Waarom?

.edit: oh wacht, ik snap de verwarring, een deel van de quote is weggevallen.

Zodra .internal wordt geformaliseerd en geïmplementeerd, kan een lokale DNS-server (standaard) geconfigureerd worden om een verzoek voor een .internal-record niet verder dan zichzelf of een bepaalde relay te sturen.

Het gaat @_Thanatos_ volgens mij juist om dat laatste stuk. En ik ben ook benieuwd.

[Reactie gewijzigd door .oisyn op 23 juli 2024 15:03]

[CyBeR]

.local kun je niet in DNS gebruiken omdat de resolver library op de client (als die mDNS ondersteunt) die al afvangt en via mDNS opvraagt ipv via gewone DNS.

Dwz je kunt best een .local domein in DNS zetten; niemand die je tegenhoudt. Alleen werkt het dan gewoon het grootste deel van de tijd niet.

[.oisyn]

Misschien denk ik nou heel krom hoor en ben ik de enige die de vraag zo interpreteert, maar het ging erom dat 10.000 requests per seconde bij de DNS root server infrastructuur aankomen voor .local queries. De vraag is dus: waarom worden die dan niet op een lager niveau al eruitgefilterd?

[Reactie gewijzigd door .oisyn op 23 juli 2024 15:03]

[CyBeR]

Misschien denk ik nou heel krom hoor en ben ik de enige die de vraag zo interpreteert, maar het ging erom dat 10.000 requests per seconde bij de DNS root server infrastructuur aankomen voor .local queries. De vraag is dus: waarom worden die dan niet op een lager niveau al eruitgefilterd?

Omdat niet alles beheerd wordt door mensen die weten wat ze doen.

Er is niks wat je verhindert om .local in DNS te gebruiken, en als je het aan een DNS-server vraagt zal die gewoon antwoord geven. De reden dat je .local niet kunt gebruiken op die manier is niet omdat DNS je tegenhoudt, maar omdat je vraag op moderne end-user devices helemaal niet bij DNS uitkomt.

Maar er zijn ook miljoenen clients die dat niet doen, en waarschijnlijk ook miljoenen DNS resolvers die .local niet filteren. En als een client die .local niet herkent, een resolver gebruikt die .local niet filtert, dan komt zo'n verzoek vanzelf uit bij de root servers.

[Reactie gewijzigd door CyBeR op 23 juli 2024 15:03]

[.oisyn]

En dan nu nogmaals de quote van @CodeCaster

Zodra .internal wordt geformaliseerd en geïmplementeerd, kan een lokale DNS-server (standaard) geconfigureerd worden om een verzoek voor een .internal-record niet verder dan zichzelf of een bepaalde relay te sturen.

En de vraag van @_Thanatos_

Waarom kan dat truukje niet op .local worden toegepast?

Ergo, waarom can ICANN niet gewoon definieren dat .local niet gedelegeerd wordt?

[CyBeR]

Ergo, waarom can ICANN niet gewoon definieren dat .local niet gedelegeerd wordt?

Dat kan wel. Waarom ze dat niet doen, geen idee. Waarschijnlijk omdat de standaard die over .local gaat niet bij hen vandaan komt maar bij de IETF, en omdat er nog beheerders zijn die .local wél in DNS gebruiken (en dus moeilijk moeten doen op clients maar dat is hun eigen probleem.)

[_Thanatos_]

Precies. Waarom zou een DNS server .local forwarden als dat klaarblijkelijk niet wenselijk is?

[Karimpje]

En hoe zit het met .loc dan want dat gebruikte ik eigenlijk al sinds pfff mensenheugenis.

[SpoekGTi]

of met .lan

[Ruuddie]

.lan is meer een technische term, dat zal eindgebruikers niet zo veel zeggen.
.internal is normaal Engels, waardoor eindgebruikers eerder zullen snappen dat server.internal een intern systeem is.

[_Thanatos_]

Als je het over die boeg wil gooien, dan is .internal ook niet handig, juist omdát het Engels is. De meeste mensen in de wereld spreken die taal immers niet.

[Horatius]

Tja dat is toch ook wel een beetje kortzichtig. Je moet iets kiezen en als mensen niet weten wat local is dan ook niet internal en zeker "lan".
Ook is Engels de meest gesproken taal en zal dit aandeel voor gebruikers hiervan nog hoger liggen.

https://www.berlitz.com/blog/most-spoken-languages-world

[Reactie gewijzigd door Horatius op 23 juli 2024 15:03]

[Memori]

Lan is hier in Nederland toch ook gewoon ingeburgerd. Uiteraard niet door de digibeten, maar zelfs mijn ouders weten wat "lannen" is. In sterkere mate is Wifi ingeburgerd. Dus ik beargumenteer dat taal er niets mee te maken heeft. Zolang het maar gemakkelijk uit te spreken is in de taal die je spreekt, en zolang dat het geval is, zou ".lan" dus gewoon kunnen.

[Luchtbakker]

Als je het over die boeg wil gooien, dan is .internal ook niet handig, juist omdát het Engels is. De meeste mensen in de wereld spreken die taal immers niet.

Van Sysadmins mag je wel verwachten dat ze Engels kunnen. Nagenoeg alle documentatie en technische certificeringen worden veelal in het engels geleverd.

[joker1977]

Met die redenering kun je geen enkele taal gebruiken, toch ? Er is geen enkele taal in de wereld die door de meerderheid van de mensen wordt gesproken.

Als je dan gaat voor de grootste taal is de keus van Engels een logische, het is tenslotte de taal waar in absolute aantallen de meeste mensen mee bekend zijn.

[DeMolT.]

Als je puur kijkt naar moedertaal, dan klopt dat, maar meer mensen spreken Engels (1,4miljard vs 1,1miljard).

Bron: https://www.linguise.com/...er-wereld-voor-vertaling/

[Anoniem: 1576590]

Gewoon .局域网 dus, dat wordt door de grootste groep mensen gesproken.

Uh... dat kan niet, dat wordt dan (volgens deze site):

.xn--cjst5hr31b

Domeinnamen moeten uit ASCII letters en cijfers en '-' bestaan, met '.' als scheidingsteken.

[BeosBeing]

Uh... dat kan niet, dat wordt dan ... .xn--cjst5hr31b

Domeinnamen moeten uit ASCII letters en cijfers en '-' bestaan, met '.' als scheidingsteken.

En dit dan?

.test is a reserved top-level domain intended for usage in software testing. It is guaranteed to never be registered into the Internet.

Along with .test, there are 11 other reserved test domains: .测试, .परीक्षा, .испытание, .테스트, .טעסט, .測試, .آزمایشی, .பரிட்சை, .δοκιμή, .إختبار, and .テスト.
Quote van https://en.m.wikipedia.org/wiki/.test referentie: https://www.iana.org/domains/root/db

Ik kan ze ook niet allemaal thuisbrengen. Eerste lijkt Chinees of Japans. Tweede is denk ik Thais, derde is Cyrillisch (Bulgaars, Oekraïns, Russisch, ...) vijfde is Georgisch, zesde lijkt weer Chinees of Japans, zevende en elfde lijken Arabisch, tiende is Grieks.

[Anoniem: 1576590]

Als je IANA root DB even blijft drukken op zo'n non-ASCII naam, bijvoorbeeld .ευ, zie je https://www.iana.org/domains/root/db/xn--qxa6a.html.

Oftewel, de Unicode karakters "ευ" kun je omzetten in de punycode karakterreeks "xn--qxa6a.html" (en vice versa).

Omdat ook de ö niet in de ASCII set voorkomt, is, van de Unicode TLD ".vermögensberater", de punycode variant daarvan ".xn--vermgensberater-ctb".

Het kenmerk van een ASCII karakter is dat het altijd binnen één byte past (7 bits op precies te zijn, het hoogste bit is 0). Voor Unicode karakters heb je, per karakter, 2 of meer bytes opslag nodig.

Standaard DNS servers werken niet met unicode. Ook niet met alle ASCII-karakters trouwens, '_' (underscore) wordt soms gedoogd - maar dat is onterecht.

[BeosBeing]

Oftewel, de Unicode karakters "ευ" kun je omzetten in de punycode karakterreeks "xn--qxa6a.html" (en vice versa).

Raar systeem

Omdat ook de ö niet in de ASCII set voorkomt, is, van de Unicode TLD ".vermögensberater", de punycode variant daarvan ".xn--vermgensberater-ctb".

Vreemd, vermögensberater wordt in Duitstalinge landen als men niet beschikt over een typmachine of ander systeem met ö geschreven als vermoegensberater. De vader van de oprichter van vliegtuigfabriek Boeing heette Wilhelm Wilhelm Böing.

Het kenmerk van een ASCII karakter is dat het altijd binnen één byte past (7 bits op precies te zijn, het hoogste bit is 0). Voor Unicode karakters heb je, per karakter, 2 of meer bytes opslag nodig.

Ja, en ... ASCII is a jaren verouderd en vervangen door UTF.

Standaard DNS servers werken niet met unicode. Ook niet met alle ASCII-karakters trouwens, '_' (underscore) wordt soms gedoogd - maar dat is onterecht.

Dus eigenlijk een subset van ASCII, leven we op internet nog in de middeleeuwen?

[Anoniem: 1576590]

Door BeosBeing:

Dus eigenlijk een subset van ASCII, leven we op internet nog in de middeleeuwen?

Nee, maar DNS standaarden zijn wel oud.

En het "fijne" internet, waarop veel te veel mensen blij zijn met DV (Domain Validated) certificaten, helpt het mogelijk nog een klein beetje tegen phishing dat domeinnamen niet uit UTF maar uit ASCII letters, cijfers, het minnetje en de punt moeten zijn opgebouwd - anders zou het wel heel erg lastig worden om (nagenoeg) identiek getoonde doch van elkaar verschillende karakters van elkaar te kunnen onderscheiden.

Bijv. in Firefox (voor Windows) kun je, via about:config, network.IDN_show_punycode op true zetten om te voorkómen dat je in IDN-phishing trapt (ik kom in de praktijk zelden sites tegen die IDN's gebruiken).

Meer info vind je hier.

[BeosBeing]

Nee, maar DNS standaarden zijn wel oud.

Mogfen bijgewerkt worden.

En het "fijne" internet, waarop veel te veel mensen blij zijn met DV (Domain Validated) certificaten, helpt het mogelijk nog een klein beetje tegen phishing dat domeinnamen niet uit UTF maar uit ASCII letters, cijfers, het minnetje en de punt moeten zijn opgebouwd - anders zou het wel heel erg lastig worden om (nagenoeg) identiek getoonde doch van elkaar verschillende karakters van elkaar te kunnen onderscheiden.

Ja, ik ken het probleem

[Anoniem: 1576590]

martijn.vw schreef:

Wat schattig dat je hier serieus op in ging

Aan de andere kant vermoed ik dat veel aardbewoners er niet bepaald gelukkig mee zijn dat een noord-Amerikaanse club (met o.a. American Standards for Information Interchange) de lakens uitdeelt op internet.

Mocht het op een oorlog rond Taiwan uitdraaien, zou het mij niet verbazen als een groot deel van de wereld haar krachten bundelt en internet effectief in stukken gehakt gaat worden - met grote chaos als gevolg.

Internet is allang niet meer het intrigerende speeltje van een stel wetenschappers (met notabene aanvankelijk vooral Amerikaanse militaire roots).

[i7x]

Vroeger was Icann Amerikaans, maar sinds een aantal jaartjes is het een internationaal clubje. En natuurlijk staat het iedereen vrij hun eigen internet te ontwikkelen indien ze niet tevreden zijn met het origineel. Het zal vooral nadelig zijn voor hun, gok ik. Ik zal zelf i.i.g. Chinese of Iraanse websites niet echt gaan missen in de praktijk.

[Reactie gewijzigd door i7x op 23 juli 2024 15:03]

[CyBeR]

Carl Icahn is nog steeds Amerikaans.

ICANN is internationaal.

[latka]

Tsja, ik heb hier intern alles op .int gezet (kort voor internal) net zoals .com kort is voor .company en .gov voor .government. Ik vind het eigenlijk niet logisch om dan nu .internal te kiezen terwijl .int meer voor de hand ligt.

[Horrorist618]

Dat komt omdat .int al bestaat en is kort voor international.
Een voorbeeld van een website die deze TLD gebruikt: https://www.esa.int/

.com staat trouwens voor commercial, niet zozeer company.

[Reactie gewijzigd door Horrorist618 op 23 juli 2024 15:03]

[latka]

Wow, die kende ik niet. Aan de andere kant begrijp ik dat er 168 domeinen op zitten, dus de kans dat dit botst met mijn eigen domein is nihil. Ik zal op termijn eens migreren.

[TD-er]

Ik las 'm al gelijk als Ian, dus met hoofdletter I.
Dat zal ook wel een reden zijn om die optie dus niet te gebruiken.

[Tweak3D]

psies. of .thuis voor thuis en .zaak voor op de zaak of .whatever voor iets anders.
ik vindt alleen nog wel vreemd om server.topleveldomeinnaam te gebruiken ipv bv server.domeinnaam.topleveldomeinnaam. bv server.thuis t.o.v. server.domein.thuis

[rdfeij]

Dat local niet perse nog lokaal is in deze tijd van uitgebreide en complexe netwerken.

[readefries]

Geen idee, die gebruik ik ook altijd al. Geen idee of daar een standaard oid achter zit

[jaenster]

ik gebruik zelf altijd .invalid, aangezien ze die niet gaan gebruiken.

[vtsalf]

Hier een hele goede blogpost van Veeam waarom het slecht is om .local te gebruiken (veel medetweakers hebben het al over mDNS gehad, maar er zitten nog wat meer services in hun maag met de .local extensie).

https://community.veeam.c...ension-is-a-bad-idea-4828

[Reactie gewijzigd door vtsalf op 23 juli 2024 15:03]

[MacFreek]

Zie appendix G van RFC 6762:

Appendix G. Private DNS Namespaces

The special treatment of names ending in ".local." has been implemented in Macintosh computers since the days of Mac OS 9, and continues today in Mac OS X and iOS. There are also implementations for Microsoft Windows [B4W], Linux, and other platforms.

Some network operators setting up private internal networks ("intranets") have used unregistered top-level domains, and some may have used the ".local" top-level domain. Using ".local" as a private top-level domain conflicts with Multicast DNS and may cause problems for users. Clients can be configured to send both Multicast and Unicast DNS queries in parallel for these names, and this does allow names to be looked up both ways, but this results in additional network traffic and additional delays in name resolution, as well as potentially creating user confusion when it is not clear whether any given result was received via link-local multicast from a peer on the same link, or from the configured unicast name server. Because of this, we recommend against using ".local" as a private Unicast DNS top-level domain. 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:

.intranet.
.internal.
.private.
.corp.
.home.
.lan.

[wiert.tweakers]

Toevoeging: directe link https://datatracker.ietf.org/doc/html/rfc6762#appendix-G

[3dmaster]

Aan het gebruik van .local herken ik altijd de typische windowsbeheerder. Als Linux engineer is er niks vervelender dan netwerken waar .local wordt gebruikt. Het breekt namelijk mDNS.

Hardnekkig fenomeen.

[Vorkie]

Apple, Google en andere spelers gebruiken het inderdaad o.a. voor mDNS, dus wat is er mis met .local? Dat hoort bij mDNS.

Voor (AD) domeinen kan je een sub gebruiken van je publieke domein, zoals int.domein.nl of ad.domein.nl

.lan is ook een veel gebruikte, net zoals .wan in de grotere netwerken.

Het is trouwens gewoon een “standaard” bij bijvoorbeeld routers van providers etc…. Die stomme .local.

[Dreamvoid]

Windows gebruikt sinds 2015 ook mDNS, dus is .local ook praktisch niet meer te gebruiken voor DNS.

[Cyberpuppy]

In de praktijk worden de servers wel geupgrade, maar neem je je bestaande AD en DNS mee. En veel domeinen gaan op die manier al bijna 20 jaar mee.

[3dmaster]

Volgens mij mis je precies mijn punt. Er is niks mis met mDNS, in tegendeel, maar met beheerders die het gebruiken voor hun interne (AD) DNS.

[Anoniem: 1576590]

3dmaster schreef:

Er is niks mis met mDNS, in tegendeel, [...]

mDNS conflicteert met Zero Trust.

De meeste dingen die handig zijn voor betrouwbare mensen zijn ook handig voor onbetrouwbare soortgenoten.

[Reactie gewijzigd door Anoniem: 1576590 op 23 juli 2024 15:03]

[Glashelder]

Feitelijk breekt mDNS een praktijk die al sinds de eerste versies van AD gebruikelijk was. Van vèr voor mDNS verzonnen werd.

Het is dan wat krom AD beheerders de schuld te geven.

[Martinspire]

Als ik even kijk op wikipedia dan is het helaas niet zo'n goed idee meer.

The domain name .local is a special-use domain name reserved by the Internet Engineering Task Force (IETF) so that it may not be installed as a top-level domain in the Domain Name System (DNS) of the Internet. As such it is similar to the other special domain names, such as .localhost.

The Internet Engineering Task Force (IETF) reserves the use of the domain name label .local as a special-use domain name for hostnames in local area networks that can be resolved via the Multicast DNS name resolution protocol.[2] Any DNS query for a name ending with the label local must be sent to the mDNS IPv4 link-local multicast address 224.0.0.251, or its IPv6 equivalent ff02::fb.

Dus tenzij je deel uitmaakt van die IETF of dat je je een systeem met 224.0.0.251 hebt lopen, is het niet meer de "standaard". Verder geeft het wellicht onterecht het idee dat het alleen lokaal is, terwijl er nog steeds data over het lijntje gaat.

[g4wx3]

gemiste kans voor intranet
of als local niet gaat, iets zoals localnet had ik ook leuker gevonden
of de woordspeling interlan ipv internal
of doen ze niets geks meer zoals foutcode i'm a teapot?

waarom niet verschillende namen reserveren?

[frickY]

Sinds mDNS gemeengoed werd werkt dat niet meer best.
Om die reden ooit eens een switch van .local naar .dev gemaakt voor interne test-servers.. dat was ook maar kort leuk.

[-Casper]

Ik mis denk ik wat cruciale info. Als het alleen om lokaal gebruik gaat dan heb je toch alle vrijheid om zelf te bepalen welk TLD je gebruikt? Zolang je lokale DNS dit maar resolved naar je lokale device?

[hcQd]

In principe wel, maar nu er geen beperking meer is welke tld's je kunt registreren kun je later conflicten krijgen. Zo gebruikt avm fritz.box om makkelijk bij de router te komen, maar recent is .box een officiële tld.

[Reactie gewijzigd door hcQd op 23 juli 2024 15:03]

[DutchCrownNL]

Daarover gesproken, het domein fritz.box is inmiddels al geregistreerd en niet door AVM.
Gelukkig zijn ze bij AVM wel zo slim geweest om die alsnog naar de router zelf te routeren, tenzij je andere dns servers gebruikt uiteraard.

[Anoniem: 1576590]

Door DutchCrownNL:

Daarover gesproken, het domein fritz.box is inmiddels al geregistreerd en niet door AVM. Gelukkig zijn ze bij AVM wel zo slim geweest om die alsnog naar de router zelf te routeren, tenzij je andere dns servers gebruikt uiteraard.

Probleem: dat heb je niet altijd zelf in de hand. Als ik op mijn smartphone even slecht WiFi-bereik heb, valt deze terug op 5G of 4G - met DNS-servers van mijn telco.

Zoals ik hier aanhaalde krijg je een site met NFT's, maar voor hetzelfde geld had die site geleken op de inlogpagina van jouw Fritz!Box en had je daar jouw adminwachtwoord op ingevuld.

Als die site dan bijv. liegt "wrong password" en jouw browser doorstuurt naar 192.168.178.1 of het externe IP-adres van jouw router, hoef je dit mogelijk niet eens op te merken (waarbij een, eventueel tweede, certificaatwaarschuwing dan juist zou kunnen helpen).

Aanvulling 11:48: als je beheer vanaf internet hebt uitgezet en een externe partij jouw adminwachtwoord kent, kun je CSRF-aanvallen niet bij voorbaat uitsluiten (d.w.z. de externe partij laat jouw browser als zijnde jou, op jouw LAN, inloggen als admin en instellingen wijzigen).

[Reactie gewijzigd door Anoniem: 1576590 op 23 juli 2024 15:03]

[DutchCrownNL]

Goede toevoeging, zo had ik hem nog niet bekeken

Door ErikvanStraten:

Probleem: dat heb je niet altijd zelf in de hand. Als ik op mijn smartphone even slecht WiFi-bereik heb, valt deze terug op 5G of 4G - met DNS-servers van mijn telco.

…

Als die site dan bijv. liegt "wrong password" en jouw browser doorstuurt naar 192.168.178.1 of het externe IP-adres van jouw router, hoef je dit mogelijk niet eens op te merken (waarbij een, eventueel tweede, certificaatwaarschuwing dan juist zou kunnen helpen).

Aanvulling 11:48: als je beheer vanaf internet hebt uitgezet en een externe partij jouw adminwachtwoord kent, kun je CSRF-aanvallen niet bij voorbaat uitsluiten (d.w.z. de externe partij laat jouw browser als zijnde jou, op jouw LAN, inloggen als admin en instellingen wijzigen).

[vrilly]

Op mijn telefoon kon ik gelijk Firefox resetten omdat er geen manier is HSTS eruit te schoppen als je een keer op de foute fritz.box komt :'L
Gelijk alles op .internal overzetten voor mijn homelab

[Anoniem: 1990104]

Tja, of dom genoeg geweest om een domein niet te registreren wat een integraal deel is van hun software.
Mocht die site ooit actief gebruikt gaan worden, dan kunnen AVM users er nu niet bij omdat ze een fout hebben gemaakt in hun processen. Of als een man genaamd fritz een .box domein heeft gekocht, die er nu achterkomt dat zijn fritzbox (die hij heeft gekocht omdat hij uiteraard zelf fritz heet) er voor zorgt dat hij niet naar zijn eigen domein kan.

Natuurlijk is het nu vrijwel geen probleem, met een ongebruikte en vrij obscure domeinnaam, maar het tekent wel dat de fout van het bedrijf nu wordt opgelost door een hack waar de gebruiker potentieel last van kan hebben. Ben benieuwd of een meer gehaat bedrijf met een dergelijke actie ook 'slim' werd genoemd

[Arunia]

Totdat extern .whatever gebruikt wordt en je die niet kunt bereiken. Kans is klein zolang je geen .nl, .com of whatever gebruikt hiervoor.
Mijn vorige werkgever had .naambedrijf.net gebruikt hiervoor omdat zij weten dat naambedrijf.net nergens gebruikt gaat worden.

[snowleopard2]

Als het domein netjes registreert weet je zeker dat niemand deze kan misbruiken, en je kan zelfs DNS01 gebruiken voor interne TLS certificaten met Letsencrypt, zijn geen A records voor nodig alleen r/w toegang tot TXT records om te bewijzen dat het domein echt van jou is

[Reactie gewijzigd door snowleopard2 op 23 juli 2024 15:03]

[TheBrones]

Hier moet je uiteraard wel enorm mee uitkijken gezien je hiermee publiekelijk details over je infrastructuur lekt. https://crt.sh/ achterliggende uitleg: https://certificate.transparency.dev/howctworks/

[GertMenkel]

Ja, maar aan de andere kant kun je dat oplossen door bijvoorbeeld wildcard-certificaten te gebruiken. Als je een certificaat voor *.naambedrijf.net aanvraagt en dat op alle servers zet (iets meer risico op misbruik natuurlijk, is een afweging), lek je geen details naar buiten.

Alternatief kun je ook een interne CA gebruiken, natuurlijk, eventueel met een interne ACME-server, dan heb je het CT-probleem niet, maar moet je wel een CA-certificaat provisionen naar al je apparaten.

[Dreamvoid]

Zolang je lokale DNS dit maar resolved naar je lokale device?

Probleem is dat er geen garantie is dat devices/applicaties ook die locale DNS gebruiken.

[Anoniem: 1777010]

Nee, want bijvoorbeeld .dev (wat ik altijd gebruikte) heeft verplicht https en daar reageert Google Chrome heel slecht op als je http://local.dev probeert te bereiken.

[Reactie gewijzigd door Anoniem: 1777010 op 23 juli 2024 15:03]

[Anoniem: 1990104]

Heeft dat niet meer te maken met het feit dat local.dev gewoon een publieke site is. Jij hebt dus iets toegewezen aan een domein wat ook een domein is wat via het internet te bereiken is, dan zijn conflicten vrijwel niet te vermijden.

[digibaro]

Ik pas zelf de .lan toe als top level domein voor het interne netwerk. Nog geen issues mee ondervonden, maar zal het wel op termijn omzetten naar .internal. Is .local niet voor automatische toewijzing bedoeld en auto detectie?

[GertMenkel]

"nog geen issues", sleutelwoord "nog". Dit idee hadden mensen ook met allerlei andere TLD's. Een heel stel mensen gebruikten ook .dev, en toen was dat ineens een echte TLD geworden.

.local is voor mDNS/Bonjour. Sommige apparatuur probeert .local alleen met mDNS op te zoeken, waardoor je DNS-servers niet worden geraadpleegd en je allerlei rare problemen kunt krijgen. Die kun je beter niet gebruiken.

Als je intern TLD's gebruikt, is het belangrijk TLD's te pakken die nooit publieke TLD's worden. Voorheen had je .example, .invalid, .home.arpa, enzovoorts. Technisch gezien zijn die voor specifieke doeleinden bedoeld, maar in de praktijk kun je met de meeste van die TLD's gewoon aan de gang. Nu .internal is vastgesteld voor intern gebruik, is dat wellicht de beste optie.

Een andere optie is natuurlijk het gebruik van een echt domein (bijvoorbeeld server1.digibaro.nl, router.digibaro.nl...) omdat je kan verzekeren dat je zelfgemaakte subdomeinen nooit in conflict zullen raken met dingen die op het internet worden opgezocht, zolang je je domein ieder jaar netjes vernieuwt natuurlijk. Dit is wat je eigenlijk zou moeten doen, maar apart veel mensen lijken geen zin te hebben in het spenderen van vijf euro per jaar om een domein vast te houden.

[downtime]

Dit is wat je eigenlijk zou moeten doen, maar apart veel mensen lijken geen zin te hebben in het spenderen van vijf euro per jaar om een domein vast te houden.

Ik weet niet of € 5 per jaar het issue is. Ik ken niemand die zich in een bedrijfsomgeving druk maakt over € 5. Maar in een bedrijf is € 5 uitgeven vaak moeilijker dan je denkt omdat de gemiddelde medewerker niet over een bedrijfscreditcard beschikt en je dus met inkopers en procedures te maken krijgt. En dat is een veel grotere barriere dan die paar euro’s.

[Anoniem: 1576590]

Maar als HR werkenbijorganisatie.nl wil registreren, is dat nooit een probleem.

[digibaro]

Ik heb meerdere publieke domeinen, maar heb er voor gekozen om internet netwerken van een lokale naam te voorzien.

[purge]

Zelf gebruik ik al een tijdje home.arpa voor thuisgebruik naast een 'internal.example.com', zodat ik hier ook eenvoudig certificaten voor kan aanmaken via letsencrypt.
.internal is wel een stuk netter dan home.arpa.

[kipjr]

Beetje verwarrend, aangezien je ook al .home.arpa hebt (RFC 8375)

Is deze dan bedoeld voor intern niet-thuisgebruik?

[I_IBlackI_I]

.home.arpa is voor

non-unique use in residential home networks

. .internal zou juist bij grotere bedrijven gebruikt kunnen worden.

[HollowGamer]

Waar staat .arpa voor? En waarom niet gewoon enkel .home?

Ik ben niet meer zo blij met deze partij, zeker nu Google allemaal vage extensies heeft als .zip, .exe, .dev, etc.

Overigens gebruik ik zelf nu .test, vaak wil ik lokaal sites testen of benaderen, want .internal is dacht ik ook gereserveerd en .local is al voor mDNS, etc.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 15:03]

[Dreamvoid]

.home is denk ik te goed bruikbaar voor websites over onroerend goed.

.arpa is het TLD van ARPA, een Amerikaanse overheidsinstantie. Hun TLD wordt in sommige andere protocols ook gebruikt (zoals de ipv4only.arpa hostname voor NAT64 prefix discovery, en inaddr.arpa voor rDNS). Veel mensen vinden .home.arpa te verwarrend, en hebben liever iets meer intuitief, zoals .lan of .internal.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 15:03]

[ApexAlpha]

.home is denk ik te goed bruikbaar voor websites over onroerend goed.

.home is ook (semi-)gereserveerd door ICANN en zal niet uitgegeven worden.

[ultimasnake]

Waarom zou een TLD het benaderen van je router makkelijker maken dan het ip-adres? Ieder device zal moeten luisteren naar een uniek TLD om te voorkomen dat 2 devices binnen dezelfde omgeving dezelfde naam krijgen dus zal deze toch achterop geplaatst moeten worden

(Natuurlijk kan je het ip-adres veranderen van de modem/router maar dan heb je ook geen makkelijker TLD nodig om hem te vinden als tweaker).


Hoe registreren deze devices zich eigenlijk als tld device? We kunnen geen vaste ip’s gaan bepalen per type device?

[Haribo112]

Bedrijven gebruiken interne domeinen voor zaken als DNS en Active Directory. Vaak wordt hiervoor het .local TLD misbruikt. Dat lijkt een logische keuze maar kan verschillende diensten, zoals Apple Bonjour, in de war schoppen. Daarom gaat ICANN nu vaststellen dat .internal hiervoor gebruikt moet worden.

[jongetje]

Dit is dan ook niet voor je thuisnetwerkje bedoelt maar voor bedrijven die een domein hebben en om je interne servers (en diensten) te benaderen.

Ik snap niet wat je bedoelt met "Hoe registreren deze devices zich als tld device" DNS werkt juist andersom, in de DNS server registreer je welke TLD bij welk ip-adres (of CNAME, MX record etc.) hoort.

[ultimasnake]

Nu ik het document van de ICANN lees sluit ik me helemaal bij je aan. Tweakers beschrijft dit echter als "Met deze ontwikkeling kunnen gebruikers uiteindelijk bijvoorbeeld toegang tot hun router krijgen door naar .internal te navigeren." wat volledig klinkt als een thuis-scenario waar jij als gebruiker even naar je ziggo router wilt gaan. Als ik denk aan een bedrijfsomgeving van hebben we het meestal over beheerders, administratoren etc dus daar zat mijn verwarring.

De werking van DNS is mij duidelijk maar schepte in dit geval door het thuis scenario wat verwarring, want als thuis gebruiker beheer je niet je eigen DNS en hoe kan je "router.local" benaderen als de router z'n ip niet bekend is etc dus dacht ik aan een soort "automatisch" proces?..

[Bor]

Ieder device zal moeten luisteren naar een uniek TLD om te voorkomen dat 2 devices binnen dezelfde omgeving dezelfde naam krijgen dus zal deze toch achterop geplaatst moeten worden

Nee dat is niet hoe het werkt. Je plaatst natuurlijk nog iets voor de tld.
router.local
pc.local
tv.local

Ander alternatief is om nog verder onder te verdelen.

Router.local is natuurlijk voor veel mensen makkelijker te onthouden van 192.168.0.254 (als voorbeeld).

[Dreamvoid]

.local kan je niet gebruiken voor DNS, veel apparaten (oa Android) resolven dat domein niet omdat het gebruikt wordt voor mDNS (wat op vrijwel elk LAN gebruikt wordt).

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 15:03]

[faxityy]

Nu je het zegt je, lijkt inderdaad te kloppen. Home-assistant OS komt out of the box met homeassistant.local:8123.
Valt me nu pas op dat die op Android niet bereikbaar is maar op iPhone en Windows wel gewoon.
Vind het alleszins super handig.

[koos147]

ik heb veel van jullie reacties gelezen maar kom er nog altijd niet uit.

ik draai zelf een mydomain.local (sinds 2004) waarbij de dns (uiteraard op de private subnets) perfect werkt.
heb hier forwarders staan naar andere .local domeinen die ook zonder enige moeite werken.

Het gebruik van een publiek tld in een intern netwerk is juist waar ik de meeste problemen mee heb gehad. (je publieke en lokale dns houden 2 aparte administraties bij)
tevens moet je allemaal vreemde truukjes uithalen om te zorgen dat interne gebruikers mijnbedrijf.nl kunnen blijven gebruiken.

Mdns is later gekomen en had dus inprincippe zich moeten aanpassen ipv een bestaande (onofficiele dus kennelijk) standaard aan te passen.
Dat gezegd hebbende.... zowel windows als linux servers (intern azure verschillende tunnels / firewalls) hebben bij mij nog nooit problemen gegeven met .local dus ben heel benieuwd wat er mis had moeten gaan?

[Terrestrial]

Mijn interne domain.tld is gelijk aan mijn externe domain.tld, ik heb dat eigenlijk nooit aangepast omdat het mij wel beviel en ik er geen problemen mee had. Intern verwijst alles netjes naar de interne IP's en extern heb ik de nodige hostnames naar mijn public IP of cloudflare verwezen.

[XenoniaN]

hé bah wat een lange naam. .lan ftw!

[Anoniem: 1990104]

Maar wie is Ian en wat heeft hij te maken met het interne netwerk van mijn bedrijf?

[JDx]

affairs.internal

[Anoniem: 1576590]

Gek genoeg resolvt http://stamps.post.nl niet maar wel:

• http://post.nl
• http://stamps.nl.post

Meer info.

Edits: sorry, ik haalde ze nog door elkaar ook

[Reactie gewijzigd door Anoniem: 1576590 op 23 juli 2024 15:03]

[beerse]

.local en .internal en liefst ook de vertaalde versies daarvan zouden allemaal de 'niet icann' status kunnen krijgen. Dat de dns-servers die zelf allemaal lokale tld verwerkern.

Volgens mij zijn er al meerdere organisaties die dergelijke tld-s gekaapt hebben voor intern gebruik.

En voor de thuis-router leverancies zoals AVM: Geef ons de vrijheid om op die manier een eigen intern dns-domein op te zetten en zet dat niet vast op dingen als fritz.box.