Două locații, o zonă DNS privată: ale cui sunt înregistrările?

Adăugați un host în locația verde, acesta se rezolvă pentru utilizatorii verzi, iar biroul galben primește în continuare NXDOMAIN. Nu este o defecțiune VPN și nici un resolver stricat; este o lacună de proprietate în zona privată. Două liste de înregistrări editate independent nu devin o singură zonă doar pentru că locațiile se pot atinge reciproc. Soluția este un plan de publicare, nu încă o regulă de firewall.

Simptomul numește proprietarul lipsă

Fiecare locație are probabil o suprascriere locală, o intrare Pi-hole sau o linie dnsmasq adăugată de cineva când era nevoie de un nume. Înregistrarea verde există doar pe resolverul verde, așa că un client din locația galbenă întreabă propriul resolver și primește un "nu există acest nume" adevărat. Un răspuns învechit arată altfel: hostul s-a mutat, o locație și-a actualizat copia, iar cealaltă returnează în continuare adresa veche.

Niciunul dintre modele nu se remediază pentru mult timp printr-o golire a cache-ului. Cache-ul unui resolver care redirecționează este o copie a unui răspuns primit cândva, nu o autoritate care publică nume noi, așa că un cache care funcționează azi nu spune nimic despre hostul de mâine. Documentația BIND descrie rolurile primar, secundar, recursiv și de redirecționare separat exact din acest motiv.

Așadar întrebarea de proiectare este îngustă și are răspuns: cine poate crea o înregistrare și cum ajunge acea înregistrare la fiecare resolver care trebuie să răspundă pentru ea?

Opțiunea A: o zonă autoritativă cu secundare

Rulați un primar pentru internal.example.com și lăsați secundarele acceptate să obțină zona în fiecare locație. Resolverul recursiv al fiecărei locații întreabă secundarul său local, așa că răspunsurile vin dintr-o sursă autoritativă și nu dintr-un cache, iar o modificare făcută o dată este transferată în loc să fie rescrisă.

Această aranjare cere decizii explicite, ușor de amânat și scumpe de omis. Cine poate edita zona? Ce servere au voie să o transfere și prin ce adrese? Ce ar trebui să vadă clienții cât timp tunelul dintre locații este căzut? Un secundar continuă să răspundă din ultima sa copie, ceea ce este de obicei comportamentul dorit, dar trebuie să fie o alegere declarată, nu o surpriză în timpul unei căderi.

Limitați transferurile de zonă la secundarele cunoscute după adresă și folosiți semnături de tranzacție acolo unde implementarea le acceptă. Un transfer deschis este o copie a spațiului intern de nume pentru oricine ajunge la port.

Costul este coordonarea: o singură cale de editare, o singură revizuire a modificărilor și o înțelegere comună a cine este de gardă când o înregistrare este greșită.

Opțiunea B: un subdomeniu pentru fiecare locație

Delegați green.internal.example.com locației verzi și yellow.internal.example.com locației galbene. Fiecare locație devine autoritativă pentru propriile nume, iar zona părinte poartă doar înregistrările de delegare. Disputa pe un singur fișier dispare, iar o echipă locală poate adăuga un host fără să aștepte o modificare centrală.

Delegarea trebuie să existe în zona părinte, cu înregistrări NS care indică serverele autoritative ale locației. Un transfer condiționat pentru subdomeniu este o alternativă validă când o delegare completă nu este practică, dar este o setare a resolverului și nu un fapt publicat, așa că fiecare resolver are nevoie de aceeași regulă.

Costul se mută în loc să dispară: zona părinte are în continuare nevoie de un proprietar, iar crearea unei locații noi este acum o modificare în două locuri în loc de unul.

Faceți fiecare resolver să urmeze alegerea

Oferiți clienților resolverul aprobat și domeniul de căutare prin configurația lor acceptată și asigurați-vă că resolverul are o rută VPN permisă către orice server DNS la distanță pe care trebuie să îl întrebe. Aplicațiile au nevoie și de rute către adresele private pe care le returnează acele răspunsuri, deoarece un nume corect fără cale rămâne o conexiune întreruptă.

Dacă Pi-hole asigură rezolvarea locală, notați ce înregistrări deține și ce interogări redirecționează. Două liste Pi-hole editate independent încă nu se replică. În Pi-hole v6, liniile dnsmasq personalizate se stabilesc prin opțiuni de pe partea hostului, cum ar fi TOML, CLI sau variabile de mediu, și nu sunt expuse prin API; încărcarea fișierelor din /etc/dnsmasq.d/ este o opțiune separată, dezactivată implicit.

Apoi testați din ambele părți cu un nume care ar trebui să fie vizibil peste tot:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

Răspunsul SOA vă spune dacă resolverul galben se consideră autoritativ, interoghează un secundar sau doar redirecționează. Sunt proiectări diferite cu moduri de eșec diferite, iar răspunsul identifică de obicei care a fost implementată efectiv.

Încheiați cu trei cazuri de acceptare: un nume din fiecare locație, o înregistrare modificată în decurs de o oră și legătura dintre locații indisponibilă. O proiectare care trece doar primul are un plan de publicare pe hârtie și o suprascriere locală în producție.