Waarom MagicDNS apparaten wel oplost, maar geen kantoorhostnamen

MagicDNS geeft elk apparaat in een tailnet een naam die is afgeleid van de machinenaam en het DNS-domein van het tailnet. Die naam wordt door Tailscale aangemaakt en wordt beantwoord langs het resolverpad van Tailscale. Een kantoorhostnaam zoals files.office.example hoort bij een zone die Tailscale nooit heeft geschreven, dus het hernoemen van een apparaat kan die niet aanmaken. De twee naamruimten bestaan naast elkaar; ze hebben alleen verschillende eigenaren.

Dat mechanisme zit achter een zeer veelvoorkomende melding: de Tailscale-host antwoordt, en de fileserver geeft nog steeds een resolutiefout terug.

Twee naamruimten, twee eigenaren

Een apparaatnaam wordt gegenereerd uit de eigen hostnaam van de machine, botsingen worden door Tailscale opgelost, en het resultaat leeft onder het tailnet-domein. Een kantoorzone wordt onderhouden door wie de kantooresolver beheert, met records die door een beheerder of via dynamische registratie worden aangemaakt. Korte namen verbergen het verschil: files kan een uitbreiding van een zoekachtervoegsel zijn die door de kantoor-DNS wordt beantwoord, een tailnet-apparaat, of helemaal niets. Een query op de volledige naam laat zien welk systeem werkelijk antwoordde.

Het wijzigen van de machinenaam van de subnetrouter doet niets voor de kantoorzone. Het hernoemt één Tailscale-apparaat en laat het record op de kantoorserver ongemoeid, daarom komen hernoemen en opnieuw proberen nooit samen.

Richt de kantoorzone op haar resolver

Het gesplitste DNS van Tailscale stuurt query’s voor gekozen domeinen naar een naamserver die je opgeeft, en al het andere volgt het resterende beleid. Voeg het domein toe dat de kantooresolver werkelijk bedient, niet het zoekachtervoegsel dat je toevallig typt. Een zoekachtervoegsel vertelt de client wat er moet worden toegevoegd; het vertelt de resolver niet waar die moet kijken. Die twee instellingen lijken in een console op elkaar en gedragen zich volledig anders.

Een beperkte naamserver moet autoritatief zijn voor het domein dat eraan is gekoppeld, anders is het antwoord een verwijzing in plaats van een adres.

Bereikbaarheid komt vóór resolutie

De client moet die naamserver ook bereiken. Voor een resolver op een privé-LAN moet de subnetroute worden aangekondigd en geaccepteerd, het toegangsbeleid moet de query toestaan, en er moet een retourpad bestaan. Een correct DNS-adres in de beheerconsole bewijst alleen dat de configuratie is opgeslagen. Als pakketten de resolver niet kunnen bereiken, is het symptoom een time-out, die er anders uitziet dan een autoritatief antwoord dat zo’n record niet bestaat.

Dat verschil is diagnostisch. Een time-out wijst op routing of beleid, terwijl een onmiddellijk negatief antwoord op het record of de zone wijst. Lees welke je krijgt voordat je een DNS-instelling wijzigt.

Scheid de naamfout van de dienstfout

Als de resource op haar privéadres reageert maar niet op hostnaam, blijft het onderzoek bij DNS. Als geen van beide werkt, herstel dan eerst routing of de dienst, want een naam die naar een onbereikbaar adres resolvet is geen vooruitgang. Vraag de volledige naam op en noteer welke server antwoordde. Op macOS volgen sommige opdrachtregelprogramma’s een ander pad dan gewone toepassingen, dus een terminal dig en een browser kunnen het over dezelfde naam oneens zijn.

Herhaal de test met een geselecteerde exit-node als dat de normale modus voor het apparaat is. De DNS-afhandeling van een exit-node verschilt van de configuratie zonder exit-node, en testen in slechts één modus kan de fout missen die gebruikers werkelijk zien.

Noteer de zone, het adres van de resolver en de route die de query draagt. Die drie verklaren de meeste MagicDNS-verrassingen zonder nog een ronde hernoemen.