Никакая запись SOA — каковы последствия?
Вероятно, необходимо добавить правило подмены к iptables для упрощения пакетов передачи от частной сети узла до WAN/Интернета.
Принятие Вас имеет единственный Облачный Контроллер и единственный Контроллер Узла; топология реализовала что-то близко к следующему:
ИНТЕРНЕТ <-> eth0[CloudController]eth1 <-> [Переключатель] <-> eth0[NodeController]........... 192.168.1.100...................... 10.0.0.1..................... 10.0.0.2
Попробуйте что-то вроде этого на Облачном Контроллере:
$ sudo/sbin/iptables-t туземная ПОДМЕНА-A POSTROUTING-s 10.0.0.0/24-o eth0-j
Это принимает Ваши Облачные Контроллеры, общедоступный интерфейс является eth0, и что Облачные Контроллеры, частный интерфейс направления является eth1, в 10.0.0.0 сетях которого Контроллер Узла является также участником.
Если это работает, сделайте правило постоянным (можно даже просто записать это в/etc/rc.local),
Удачи!
SLR -
На самом деле существует запись SOA , но это не то, чего вы ожидаете. Давайте посмотрим на раздел АВТОРИТЕТ ... имейте в виду, что ns1.nservers.co.uk. никоим образом не связан с nic.uk. серверов имен, которые являются полномочными для co.uk. .
$ dig @ns1.nservers.co.uk. +norecurse +noall +authority vancemillerkitchensuk.co.uk SOA
co.uk. 3600 IN SOA win-k7rk0hedad1. hostmaster. 6 900 600 86400 3600
$ dig @ns1.nservers.co.uk. +norecurse +short co.uk SOA
win-k7rk0hedad1. hostmaster. 6 900 600 86400 3600
Это выдает их фактическую конфигурацию: для них определена единственная зона co.uk . Это упрощает их настройку, поскольку им нужно поддерживать только один файл. Причина, по которой вы не получаете раздел ответа на запрос SOA , заключается в том, что это не истинный верх зоны. Имейте в виду, что это ужасная конфигурация: вы никогда не должны притворяться авторитетными для доменов, которыми вы не являетесь. Не копируйте это .
Записи SOA являются обязательными. Вы должны вставить что-то в тот раздел АВТОРИТЕТ, где это требуется RFC, если вы ожидаете, что остальная часть Интернета будет хорошо с вами играть. Очевидно, что они на самом деле не являются авторитетными для co.uk , но это, по крайней мере, говорит другим серверам имен, каким должен быть отрицательный TTL.
Записи SOA в значительной степени регулируют идентификацию и частоту обновления ваших DNS-серверов. Если ваш DNS-сервер является единственным авторитетным DNS-сервером для домена (или вы контролируете все полномочия и любите ручные действия), вы можете опустить запись SOA практически без последствий. Единственное влияние может заключаться в том, что некоторого кэширования ответов не произойдет.
В итоге: DNS может прекрасно работать без SOA, SOA просто регулирует обновления вторичных серверов и кэширование. Так что не иметь записи SOA - это действительно плохая идея.
Запись SOA в вершине каждой зоны на дочерних серверах имен является обязательной в соответствии со спецификацией DNS, см. §6.1 RFC 2181:
Полномочные серверы для зоны перечислены в NS. записи о происхождении зоны, которые вместе с началом Запись авторитета (SOA) является обязательной записью в каждой зоне. Такой сервер является авторитетным для всех записей ресурсов в зоне. которые не находятся в другой зоне.
Зона, не имеющая SOA, не соответствует требованиям DNS. Серверы имён отклонят его во время загрузки:
$ cat example.com
example.com. 1 NS a.example.
example.com. 1 NS b.example.
$ named-checkzone example.com example.com
zone example.com/IN: has 0 SOA records
zone example.com/IN: not loaded due to errors.
Возможно, вы сможете найти настройку, в которой это работает, но зачем рисковать?
Помимо обязательности согласно спецификации, в записи SOA есть как минимум 3 элемента, которые необходимы клиентам (все остальные элементы в основном полезны только для администратора серверов имен, если его набор серверов имен использует обновления AXFR/IXFR/DNS для обновите себя):
RNAMEобычно является адресом электронной почты ответственного за зону, с которым вы можете связаться в случае возникновения проблем; к сожалению, в настоящее время вы можете не получить там ответа или в любом случае это может быть даже недействительный существующий почтовый ящик, поэтому теоретически полезно, на практике не уверенMNAME, согласно §4.3 RFC 2616. требуется для обновлений DNS:
4.3. Если у запрашивающей стороны есть разумные основания полагать, что все серверы зоны будут одинаково доступны, то он должен попытаться сначала попробовать первичный главный сервер (как указано в поле MNAME SOA, если он соответствует некоторому NS NSDNAME), чтобы избежать ненужной переадресации внутри. подчиненные серверы.(Обратите внимание, что первичный мастер в некоторых случаях не будет доступен для всех запрашивающих из-за брандмауэров или разделения сети.)
- SOA
MINIMUMбыл переопределен в течение года, чтобы теперь быть «отрицательным TTL». ", количество времени, в течение которого кэш может хранить полученный ответNXDOMAIN(поскольку ответNXDOMAINне возвращает записей в разделе ответов для каждого определения, там не будет никаких TTL найти). См. §5 RFC 2308:
Как и у обычных ответов, у отрицательных ответов есть время жизни (TTL). В виде в разделе ответов нет записи, к которой этот TTL можно отнести применяется, TTL должен быть перенесен другим способом. Это делается включая запись SOA из зоны в разделе полномочий ответ. Когда авторитетный сервер создает эту запись, его TTL берется из минимума поля SOA.MINIMUM и TTL SOA. Этот TTL уменьшается аналогично обычному кэшированному ответу и при достижении нуля (0) указывает, что кэшированный отрицательный ответ НЕ ДОЛЖЕН использоваться снова.
Надлежащее кэширование ответов NXDOMAIN важно для производительности, как указано в RFC 8020 «NXDOMAIN: действительно ничего нет внизу»: если имя вызывает NXDOMAIN ответить, то рекурсивный сервер имен может во время кэширования записи немедленно ответить для всех имен «ниже» запрошенного, поскольку он знает, что ни одно имя не может существовать ниже, в соответствии со схемой DNS, предусматривающей наличие всех имен в дереве. .
Кроме того, несколько реестров проверяют конфигурацию, прежде чем разрешить делегирование.Это не относится к Великобритании, но относится, например, к DENIC (.DE). См. §2.1.4 в https://www.denic.de/fileadmin/public/documentation/DENIC-23p_EN.pdf, в котором описывается тест SOA.
Это также проверяют различные инструменты. См. Zonemaster на https://zonemaster.net/ и объяснение его теста на SOA на https://github.com/zonemaster/zonemaster/blob/master/docs/specifications/tests. /Delegation-TP/delegation06.md