Зошто MagicDNS ги решава уредите, но не и имињата на канцелариските домаќини

MagicDNS му дава на секој уред во tailnet име изведено од името на неговата машина и од DNS доменот на tailnet. Тоа име го создава Tailscale и се одговара по патеката на решавачот на Tailscale. Канцелариско име на домаќин како files.office.example припаѓа на зона што Tailscale никогаш не ја запишал, затоа преименувањето на уред не може да го создаде. Двата именски простори постојат заедно; едноставно имаат различни сопственици.

Тој механизам стои зад многу честа пријава: домаќинот на Tailscale одговара, а датотечниот сервер сѐ уште враќа грешка при решавање.

Два именски простори, двајца сопственици

Името на уредот се генерира од сопственото име на домаќинот на машината, судирите ги решава Tailscale, а резултатот живее под доменот на tailnet. Канцелариската зона ја одржува оној што го води канцеларискиот решавач, а записите ги создава администратор или динамична регистрација. Кратките имиња ја кријат разликата: files може да биде проширување на суфикс за пребарување на кој одговара канцеларискиот DNS, уред во tailnet или воопшто ништо. Барањето на целото име покажува кој систем навистина одговорил.

Менувањето на името на машината на рутерот за подмрежа не прави ништо за канцелариската зона. Тоа преименува еден уред на Tailscale и го остава записот на канцеларискиот сервер недопрен, затоа преименувањето и повторното обидување никогаш не се среќаваат.

Насочете ја канцелариската зона кон нејзиниот решавач

Поделениот DNS на Tailscale праќа барања за избраните домени до имеен сервер што ќе го наведете, а сѐ друго ја следи преостанатата политика. Додадете го доменот што канцеларискиот решавач навистина го опслужува, а не суфиксот за пребарување што случајно го внесувате. Суфиксот за пребарување му кажува на клиентот што да додаде; тој не му кажува на решавачот каде да гледа. Овие две поставки изгледаат слично во конзола и се однесуваат сосема различно.

Ограничен имеен сервер мора да биде авторитативен за доменот поврзан со него, инаку одговорот ќе биде упатување наместо адреса.

Достапноста доаѓа пред решавањето

Клиентот исто така мора да стигне до тој имеен сервер. За решавач на приватна LAN, рутата за подмрежата мора да биде објавена и прифатена, политиката за пристап мора да го дозволи барањето, и мора да постои повратна патека. Точна DNS адреса во административната конзола докажува само дека конфигурацијата е зачувана. Ако пакетите не можат да стигнат до решавачот, симптомот е истекување на времето, што изгледа поинаку од авторитативен одговор дека таков запис не постои.

Таа разлика е дијагностичка. Истекувањето на времето укажува на рутирање или политика, додека непосредниот негативен одговор укажува на записот или зоната. Прочитајте кој од двата го добивате пред да смените која било DNS поставка.

Одвојте го неуспехот на името од неуспехот на услугата

Ако ресурсот одговара на неговата приватна адреса, но не по име на домаќин, истрагата останува на DNS. Ако ниту едно не работи, прво поправете го рутирањето или услугата, бидејќи име што се решава на недостапна адреса не е напредок. Побарајте го целото име и забележете кој сервер одговорил. На macOS некои алатки за командна линија тргнуваат по поинаква патека од обичните апликации, па терминал dig и прелистувач можат да не се согласат околу истото име.

Повторете го тестот со избран излезен јазол ако тоа е нормалниот режим за уредот. Ракувањето со DNS на излезниот јазол се разликува од конфигурацијата без излезен јазол, и тестирањето само во еден режим може да го пропушти неуспехот што корисниците навистина го гледаат.

Забележете ја зоната, адресата на решавачот и рутата што го носи барањето. Овие три објаснуваат повеќето изненадувања со MagicDNS без уште еден круг преименување.