Дзве пляцоўкі, адна прыватная зона DNS: каму належаць запісы?

Вы дадаяце хост на зялёнай пляцоўцы, ён развязваецца для зялёных карыстальнікаў, а жоўты офіс усё яшчэ атрымлівае NXDOMAIN. Гэта не збой VPN і не зламаны рэзалвер; гэта прабел ва ўласнасці ўнутры прыватнай зоны. Два незалежна рэдагаваныя спісы запісаў не становяцца адной зонай толькі таму, што пляцоўкі могуць дасягаць адна адну. Рашэнне — план публікацыі, а не яшчэ адно правіла міжсеткавага экрана.

Сімптом называе адсутнага ўладальніка

Верагодна, на кожнай пляцоўцы ёсць лакальнае пераазначэнне, запіс Pi-hole або радок dnsmasq, які хтосьці дадаў, калі спатрэбілася імя. Зялёны запіс існуе толькі на зялёным рэзалверы, таму кліент на жоўтай пляцоўцы пытае свой рэзалвер і атрымлівае праўдзівае "такога імя няма". Састарэлы адказ выглядае інакш: хост пераехаў, адна пляцоўка абнавіла сваю копію, а другая ўсё яшчэ вяртае стары адрас.

Ні адзін з узораў не выпраўляецца чысткай кэша надоўга. Кэш перанакіроўвальнага рэзалвера — гэта копія адказу, які ён некалі атрымаў, а не паўнамоцтвы, што публікуюць новыя імёны, таму кэш, які працуе сёння, нічога не кажа пра заўтрашні хост. Дакументацыя BIND апісвае ролі першаснага, другаснага, рэкурсіўнага і перанакіроўвальнага асобна менавіта з гэтай прычыны.

Такім чынам, пытанне праектавання вузкае і такое, на якое можна адказаць: хто можа ствараць запіс, і як гэты запіс дасягае кожнага рэзалвера, які павінен на яго адказаць?

Варыянт A: адна аўтарытэтная зона з другаснымі серверамі

Запусціце першасны сервер для internal.example.com і дазвольце падтрымліваным другасным серверам атрымліваць зону на кожнай пляцоўцы. Рэкурсіўны рэзалвер кожнай пляцоўкі запытвае свой лакальны другасны, таму адказы прыходзяць з аўтарытэтнай крыніцы, а не з кэша, і змена, зробленая аднойчы, перадаецца, а не перадрукоўваецца.

Такая схема патрабуе яўных рашэнняў, якія лёгка адкласці і дорага прапусціць. Хто можа рэдагаваць зону? Якім серверам дазволена перадаваць яе і праз якія адрасы? Што павінны бачыць кліенты, пакуль тунель паміж пляцоўкамі не працуе? Другасны працягвае адказваць са сваёй апошняй копіі, што звычайна і ёсць жаданыя паводзіны, але гэта мусіць быць абвешчаны выбар, а не нечаканасць падчас перапынку.

Абмяжуйце перадачы зоны вядомымі другаснымі серверамі па адрасе і выкарыстоўвайце подпісы транзакцый там, дзе рэалізацыя іх падтрымлівае. Адкрытая перадача — гэта копія вашай унутранай прасторы імёнаў для любога, хто можа дасягнуць порта.

Кошт — гэта каардынацыя: адзін шлях рэдагавання, адзін агляд змен і сумеснае разуменне таго, хто чаргуе, калі запіс няправільны.

Варыянт B: паддамен для кожнай пляцоўкі

Дэлегуйце green.internal.example.com зялёнай пляцоўцы, а yellow.internal.example.com — жоўтай. Кожная пляцоўка робіцца аўтарытэтнай для сваіх імёнаў, а бацькоўская зона нясе толькі запісы дэлегацыі. Спрэчкі вакол аднаго файла знікаюць, і лакальная каманда можа дадаць хост, не чакаючы цэнтральнай змены.

Дэлегацыя мусіць існаваць у бацькоўскай зоне, з запісамі NS, якія паказваюць на аўтарытэтныя серверы пляцоўкі. Умоўная перадача для паддамена — слушная альтэрнатыва, калі поўная дэлегацыя непрактычная, але гэта налада рэзалвера, а не апублікаваны факт, таму кожнаму рэзалверу патрэбна тое ж правіла.

Кошт перамяшчаецца, а не знікае: бацькоўскай зоне ўсё яшчэ патрэбен уладальнік, а стварэнне новай пляцоўкі цяпер змена ў двух месцах замест аднаго.

Няхай кожны рэзалвер ідзе за выбарам

Дайце кліентам зацверджаны рэзалвер і пошукавы дамен праз іх падтрымліваную канфігурацыю і пераканайцеся, што рэзалвер мае дазволены маршрут 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 паказвае, ці жоўты рэзалвер лічыць сябе аўтарытэтным, ці запытвае другасны, ці проста перанакіроўвае. Гэта розныя схемы з рознымі рэжымамі адмоваў, і адказ звычайна вызначае, якую з іх вы насамрэч разгарнулі.

Скончыце трыма крытэрыямі прыёмкі: імя з кожнай пляцоўкі, запіс, зменены на працягу гадзіны, і недаступная сувязь паміж пляцоўкамі. Схема, якая праходзіць толькі першы, мае план публікацыі на паперы і лакальнае пераазначэнне ў практыцы.