Две локации, една приватна DNS зона: чии се записите?

Додавате домаќин на зелената локација, тој се разрешува за зелените корисници, а жолтата канцеларија уште добива NXDOMAIN. Тоа не е дефект на VPN и не е расипан resolver; тоа е празнина во сопственоста во приватната зона. Две независно уредувани списоци на записи не стануваат една зона само затоа што локациите можат да се достигнат. Решението е план за објавување, а не уште едно правило за огнен ѕид.

Симптомот го именува отсутниот сопственик

Секоја локација веројатно има локално пребришување, запис во Pi-hole или линија во dnsmasq што некој ја додал кога било потребно име. Зелениот запис постои само на зелениот resolver, па клиент во жолтата локација го прашува својот resolver и добива вистинит „нема такво име“. Застарениот одговор изгледа поинаку: домаќинот се преселил, едната локација ја ажурирала својата копија, а другата уште го враќа стариот адрес.

Ниту едната шема не се поправа долго со чистење на кешот. Кешот на препраќачки resolver е копија од одговор што некогаш го добил, не авторитет што објавува нови имиња, па кешот што работи денес не кажува ништо за утрешниот домаќин. Документацијата на BIND ги опишува улогите примарен, секундарен, рекурзивен и препраќачки одделно токму поради оваа причина.

Значи, прашањето за дизајнот е тесно и одговорливо: кој смее да создаде запис и како тој запис стигнува до секој resolver што мора да одговори за него?

Опција A: една авторитативна зона со секундарни

Стартувајте примарен за internal.example.com и дозволете поддржаните секундарни да ја добијат зоната на секоја локација. Рекурзивниот resolver на секоја локација го прашува својот локален секундарен, па одговорите доаѓаат од авторитативен извор, а не од кеш, и промена направена еднаш се пренесува наместо повторно да се пишува.

Таквиот распоред бара експлицитни одлуки што лесно се одложуваат и скапо се прескокнуваат. Кој смее да ја уредува зоната? Кои сервери смеат да ја пренесуваат и преку кои адреси? Што треба да видат клиентите додека тунелот меѓу локациите е исклучен? Секундарниот продолжува да одговара од својата последна копија, што обично е саканото однесување, но тоа мора да биде изјавена одлука, а не изненадување за време на прекин.

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

Цената е координација: една патека за уредување, еден преглед на промени и заедничко разбирање за тоа кој е на должност кога записот е погрешен.

Опција B: поддомен за секоја локација

Делегирајте green.internal.example.com на зелената локација и yellow.internal.example.com на жолтата. Секоја локација станува авторитативна за своите имиња, а родителската зона ги носи само записите за делегирање. Спорот за една датотека исчезнува и локалниот тим може да додаде домаќин без да чека централна промена.

Делегирањето мора да постои во родителската зона, со NS записи што укажуваат на авторитативните сервери на локацијата. Условно препраќање за поддоменот е валидна алтернатива кога целосното делегирање е непрактично, но тоа е поставка на resolver, а не објавен факт, па секој resolver има потреба од истото правило.

Цената се поместува наместо да исчезне: родителската зона уште има потреба од сопственик, а создавањето нова локација сега е промена на две места наместо на едно.

Нека секој resolver ја следи одлуката

Дајте им на клиентите одобрениот resolver и доменот за пребарување преку нивната поддржана конфигурација и проверете дали resolver има дозволена VPN рута до секој оддалечен DNS сервер што треба да го праша. Апликациите исто така имаат потреба од рути до приватните адреси што ги враќаат тие одговори, бидејќи точно име без патека е уште прекината врска.

Ако Pi-hole обезбедува локално разрешување, запишете кои записи ги поседува и кои барања ги препраќа. Две независно уредувани списоци на Pi-hole уште не се реплицираат. Во Pi-hole v6 прилагодените линии на dnsmasq се поставуваат преку опции од страната на домаќинот како TOML, CLI или променливи на околината и не се изложуваат преку API; вчитувањето датотеки од /etc/dnsmasq.d/ е одделна опција што е исклучена по молчење.

Потоа тестирајте од двете страни со име што треба да биде видливо насекаде:

$ 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

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

Завршете со три случаи на прифаќање: едно име од секоја локација, еден запис променет во рок од еден час и недостапна врска меѓу локациите. Дизајн што го поминува само првиот има план за објавување на хартија и локално пребришување во продукцијата.