Субдомен и с записи и с допустимые записи NS?
Это неверно, нет. Вероятно, он вернет 1.1.1.1, поскольку он будет возвращен первым сервером, который разрешает, но «правильным» значением должно быть то, какой сервер имен зарегистрирован как первичный в записи SOA. Но то, что будет возвращено, может зависеть от того, какая версия программного обеспечения сервера имен запущена. См. Ниже, он просто перенаправит его на следующий сервер имен, и 1.1.1.1 никогда не будет отображаться.
Теперь правильно перечислять другие записи NS в вашей зоне, но другие NS должны быть серверами имен с идентичными зонами. Однако вы можете указать свои субдомены на альтернативные серверы имен.
Таким образом, example.com вашим регистратором указывает на ns1.example.com и ns2.example.com с IP-адресами 1.2.3.4 и 2.3.4.5 от сервера имен регистратора (клей).
Тогда у вас будет зона, в которой SOA выберет ns1 или ns2 в качестве основной, а затем у вас будут две записи NS, указывающие на ns1.example.com и ns2.example.com с записями A для этого домена (и mx, txt, cname и т. д.).
И NS1, и NS2.example.com должны иметь идентичные зоны, и они должны автоматически реплицироваться друг в друга.
Теперь можно взять test.example.com и указать это для ns1.somethingelse.com и ns2.somethingelse.com, но НЕТ записей A для test.example.com на серверах имен ns1 и ns2.example.com, кроме ns1 и ns2.example.com, должны автоматически отправлять IP-адреса для ns1 и ns2 .somethingelse.com, если на нем есть клей. (Этого не произойдет, если TLD отличается, например .com и .org)
Я надеюсь, что все это имело смысл, я могу уточнить больше, если что-то из этого сбивает с толку.
Вот тест того, что происходит:
О shadowrpg. Сервер имён net:
$ttl 38400
@ IN SOA shell2.reganw.com. root.shell2.reganw.com. (
1298345653
10800
3600
604800
38400 )
@ IN NS shell2.reganw.com.
test.shadowrpg.net. IN A 127.0.0.1
test.shadowrpg.net. IN NS saber.reganw.com.
На сервере имён test.shadowrpg.net (saber):
$ttl 38400
@ IN SOA saber.reganw.com. root.shell2.reganw.com. (
1298345653
10800
3600
604800
38400 )
@ IN NS saber.reganw.com.
test.shadowrpg.net. IN A 127.0.0.2
test.shadowrpg.net. IN NS saber.reganw.com.
Первый результат, когда saber не настроен, для отображения ссылки.
[regan@gamma ~]$ dig +trace test.shadowrpg.net
; <<>> DiG 9.7.3-P1-RedHat-9.7.3-2.P1.fc13 <<>> +trace test.shadowrpg.net
;; global options: +cmd
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET. (snip)
;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 2 ms
net. 172800 IN NS a.gtld-servers.net.
net. 172800 IN NS m.gtld-servers.net. (snip)
;; Received 493 bytes from 199.7.83.42#53(199.7.83.42) in 55 ms
shadowrpg.net. 172800 IN NS ns1.reganw.com.
shadowrpg.net. 172800 IN NS ns2.reganw.com.
shadowrpg.net. 172800 IN NS ns3.reganw.com.
;; Received 232 bytes from 192.35.51.30#53(192.35.51.30) in 54 ms
test.shadowrpg.net. 38400 IN NS saber.reganw.com.
;; Received 110 bytes from 209.161.6.3#53(209.161.6.3) in 2123 ms
test.shadowrpg.net. 38400 IN NS saber.reganw.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 110 bytes from 173.45.238.245#53(173.45.238.245) in 81 ms
test.shadowrpg.net. 38400 IN NS saber.reganw.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 110 bytes from 173.45.238.245#53(173.45.238.245) in 82 ms
test.shadowrpg.net. 38400 IN NS saber.reganw.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 110 bytes from 173.45.238.245#53(173.45.238.245) in 112 ms
И с настроенным saber:
^C[regan@gamma ~]$ dig +trace test.shadowrpg.net
; <<>> DiG 9.7.3-P1-RedHat-9.7.3-2.P1.fc13 <<>> +trace test.shadowrpg.net
;; global options: +cmd
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET. (snip)
;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 2 ms
net. 172800 IN NS m.gtld-servers.net.
net. 172800 IN NS a.gtld-servers.net. (snip)
;; Received 493 bytes from 198.41.0.4#53(198.41.0.4) in 129 ms
shadowrpg.net. 172800 IN NS ns1.reganw.com.
shadowrpg.net. 172800 IN NS ns2.reganw.com.
shadowrpg.net. 172800 IN NS ns3.reganw.com.
;; Received 232 bytes from 192.12.94.30#53(192.12.94.30) in 165 ms
test.shadowrpg.net. 38400 IN NS saber.reganw.com.
;; Received 110 bytes from 209.161.6.3#53(209.161.6.3) in 38 ms
test.shadowrpg.net. 38400 IN A 127.0.0.2
test.shadowrpg.net. 38400 IN NS saber.reganw.com.
;; Received 126 bytes from 173.45.238.245#53(173.45.238.245) in 80 ms
[regan@gamma ~]$
Итак, как только вы добавите запись NS, она ссылается на нее и игнорирует любые запросы к себе. Теперь, если вы добавите запись A для сервера имен, она будет передаваться с записью NS в качестве связующего звена (так что преобразователю не нужно затем искать IP-адрес для нового сервера имен).
Это неверная настройка, вы никогда не узнаете, куда вы будете перенаправлены.
Когда вы определяете записи NS в своем домене, этот DNS становится авторитетом. Если кто-то запросит IP-адрес вашего домена, он проверит его кеш, и, если записи нет, он запросит DNS, указанный в ваших записях NS.
И что теперь произойдет, если вы создадите еще одну запись A (2.2.2.2) к вашему домену в другом DNS? Тогда все клиенты, использующие этот DNS, получат ваш «новый» IP (2.2.2.2), а не настоящий.
test.example.com Должен быть возвращен объект 2.2.2.2 , поскольку он является авторитетным ("доминирующим").
Эта установка не нарушает RFC.
Рассуждения см. В моем более подробном ответе здесь.
Это полностью верно, но не так, как вы думаете.
После того, как вы делегировали поддомен другому набору серверов имен, они становятся авторитетными. Они могут вполне законно рекламировать A-запись для домена; действительно, это нормальная практика, см., например, dig google.com .
Я понятия не имею, что произойдет, если вы объявите A-запись на делегирующих серверах имен - Я подозреваю, ничего хорошего, поскольку все остальные справедливо советуют вам. Но рекламировать такую запись вполне допустимо на делегированных серверах, поэтому, вероятно, вы не можете найти запрета в RFC.
Так что проблема не в существовании как A, так и NS записи для домена; Это'
Эта проблема довольно тонкая, поэтому позвольте мне объяснить ее по одному.
Правильная конфигурация , конечно же, должна иметь только одну из двух - либо NS , либо любые другие записи.
Когда вы добавляете NS-запись для test.example.com , вы делегируете все с test.example.com и ниже на другой сервер имен. Обычное место для записи A для test.net-me.net было бы на ns1.anotherdnshost.com .
Теперь ваш вопрос можно перефразировать - можно ли иметь test.example.com A ... в «родительской» зоне example.com? Тот же вопрос может быть задан независимо от того, существуют ли какие-либо записи в делегированной зоне на другом хосте.
Мой ответ будет диалектическим: ) 1. Да, такие записи в «родительской» зоне - это нормально. Но 2. Поскольку test.example.com делегировал на ns1.anotherdnshost.com , записи для test.example.com и ниже, что происходит существовать (по любой причине) на любых серверах, кроме ns1.anotherdnshost.com , больше не являются официальными .
Сервер родительской зоны, когда он отвечает на запрос test.example.com , а) Должен отправлять NS-запись, указывающую на ns1.anotherdnshost.com , и б) Может или не может отправить запись A для test.example.com , которая у него есть, c) даже если она отправляет запись, она не должна помечать ее как " авторитетный "ответ, d) даже если он лжет и помечает такой ответ как авторитетный, распознавателю, который получает такой ответ, поскольку он знает, что test.example.com делагирован , должен учитывать только ответы от его авторитетного сервера - ns1.anotherdnshost.com ).
Я тестировал такую конфигурацию с помощью bind9:
- named, ни named-checkzone не жалуется на такую зону - очевидно эта зона считается правильной.
- Когда я запрашиваю родительский сервер для test.example.com, он возвращает только NS-записи, например, если
test.example.com A 1.1.1.1вообще не существует .
Другое программное обеспечение DNS-серверов может вести себя иначе, но в любом случае должно подчиняться общим правилам, приведенным выше.
Эта статья Verisign по теме помогла мне разобраться в этой проблеме.
Прошу прощения за всю эту бла-бла-бла