Wêrom’t MagicDNS apparaten oplost, mar gjin kantoarhostnammen

MagicDNS jout elk apparaat yn in tailnet in namme dy’t ôflaat is fan de masjinnamme en it DNS-domein fan it tailnet. Dy namme wurdt troch Tailscale makke en der wurdt antwurde lâns it oplosserpaad fan Tailscale. In kantoarhostnamme lykas files.office.example heart by in sône dy’t Tailscale nea skreau, dat it omneamen fan in apparaat kin it net meitsje. De twa nammeromten besteane njonken elkoar; se hawwe gewoan ferskillende eigners.

Dat meganisme sit efter in tige gewoane klacht: de Tailscale-host antwurdet, en de triemtsjinner jout noch altyd in oplossingsflater werom.

Twa nammeromten, twa eigners

In apparaatnamme wurdt generearre út ’e eigen hostnamme fan ’e masine, botsingen wurde troch Tailscale oplost, en it resultaat libbet ûnder it tailnet-domein. In kantoarsône wurdt ûnderhâlden troch wa’t de kantoaroplosser draait, mei records dy’t troch in behearder of troch dynamyske registraasje makke wurde. Koarte nammen ferbergje it ferskil: files kin in útwreiding fan in sykstafsel wêze dêr’t de kantoar-DNS op antwurdet, in tailnet-apparaat, of hielendal neat. It folsleine namme opfreegje lit sjen hokker systeem eins antwurde.

It feroarjen fan ’e masjinnamme fan ’e subnet-rûter docht neat foar de kantoarsône. It neamt ien Tailscale-apparaat om en lit it record op ’e kantoartsjinner ûnoanroerd, dêrom komt omneame-en-opnij besykje nea by elkoar.

Rjochtsje de kantoarsône op har oplosser

It splitste DNS fan Tailscale stjoert fragen foar keazen domeinen nei in namtsjinner dy’t jo opjouwe, en al it oare folget it oerbliuwende belied. Foegje it domein ta dat de kantoaroplosser echt betsjinnet, net it sykstafsel dat jo tafallich yntypje. In sykstafsel fertelt de klient wat der taheakke wurde moat; it fertelt de oplosser net wêr’t er sjen moat. Dy twa ynstellings lykje yn in konsole opinoar en gedrage har folslein oars.

In beheinde namtsjinner moat autoritatyf wêze foar it domein dat dermei ferbûn is, oars sil it antwurd in ferwizing wêze ynstee fan in adres.

Berikberens komt foar oplossing

De klient moat ek dy namtsjinner berikke. Foar in oplosser op in privee LAN moat de subnet-rûte oankundige en akseptearre wurde, it tagongsbelied moat de fraach tastean, en der moat in werompaad wêze. In korekt DNS-adres yn ’e behearspaneel bewiist allinnich dat de konfiguraasje bewarre is. As pakketten de oplosser net berikke kinne, is it symptoom in tiidferrin, dat der oars útsjocht as in autoritatyf antwurd dat sa’n record net bestiet.

Dat ferskil is diagnostysk. In tiidferrin wiist op rûtering of belied, wylst in fuortendaliks negatyf antwurd op it record of de sône wiist. Lês hokker fan beide jo krije foardat jo in DNS-ynstelling feroarje.

Skied de namflater fan de tsjinstflater

As de boarne op syn privee adres antwurdet mar net op hostnamme, bliuwt it ûndersyk by DNS. As gjin fan beide wurket, reparearje dan earst rûtering of de tsjinst, want in namme dy’t nei in ûnberikber adres oplost, is gjin foarútgong. Freegje de folsleine namme op en notearje hokker tsjinner antwurde. Op macOS nimme guon kommandorigel-ark in oar paad as gewoane applikaasjes, dat in terminal dig en in browser it oer deselde namme net iens wêze kinne.

Werhelje de test mei in útgongsknooppunt keazen as dat de normale modus foar it apparaat is. De DNS-ôfhanneling fan in útgongsknooppunt ferskilt fan ’e konfiguraasje sûnder útgongsknooppunt, en testen yn mar ien modus kin de flater misse dy’t brûkers echt sjogge.

Notearje de sône, it adres fan ’e oplosser en de rûte dy’t de fraach draacht. Dy trije ferklearje de measte MagicDNS-ferrassings sûnder noch in ronde omneamen.