Скажем, я владею example.com.
Затем я создаю A запись на test.example.com к 1.1.1.1.
Затем я создаю NS запись на test.example.com к ns1.anotherdnshost.com.
На другом хосте DNS я добавляю A запись для корня (test.example.com) к 2.2.2.2.
Когда клиент запрашивает test.example.com, который A запись будет возвращена? Что было бы более "доминирующим" A запись? Действительна ли такая установка?
Это несколько тонкий вопрос, поэтому позвольте мне объяснить по порядку.
В верный конфигурация, конечно, будет иметь только один из двух - либо NS или любые другие записи.
Когда вы добавляете NS-запись для test.example.com, ты делегировать все от test.example.com и ниже на другой сервер имен. Нормальное место для записи А для test.net-me.net будет на ns1.anotherdnshost.com.
Теперь ваш вопрос можно перефразировать - нормально ли иметь test.example.com А ...in the "parent" example.com zone ? The same question may be asked regardless of any records which may exist or not in theделегированная зона на другом хосте.
Отвечаю диалектично :) 1. Да, такие записи в «родительской» зоне - это нормально. Но 2. Поскольку test.example.com делегированный к ns1.anotherdnshost.com, записи для test.example.com и ниже, которые существуют (по любой причине) на любых серверах кроме ns1.anotherdnshost.com являются не авторитетный больше.
Сервер родительской зоны, когда он отвечает на test.example.com запрос, а) Должен отправить NS-запись, указывающую на ns1.anotherdnshost.com и б) Может или не может отправить запись для test.example.com в) даже если он отправляет запись, он не должен отметьте это как "авторитетный"ответ, г) даже если он лжет и помечает такой ответ как авторитетный, распознаватель, который получает такой ответ, поскольку он знает, что test.example.com является разложенный, следует учитывать только ответы с его авторитетного сервера - ns1.anotherdnshost.com).
Я тестировал такую конфигурацию с помощью bind9:
test.example.com A 1.1.1.1 не было бы вообще. Другое программное обеспечение DNS-серверов может вести себя иначе, но в любом случае должно подчиняться общим правилам, указанным выше.
это статья по теме Verisign помог мне разобраться в этой проблеме.
Мне жаль все бла бла бла
Это неверно, нет. Вероятно, он вернет 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.
Первый результат, когда сабля не настроена, показывать реферал.
[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
И с настроенной саблей:
^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-адрес для нового сервера имен).
test.example.com A 2.2.2.2 должен быть возвращен как авторитетный («доминантный»).
Эта настройка не нарушает RFC.
Рассуждения см. В моем более подробном ответе здесь.
Это неправильная установка, вы никогда не узнаете, куда вас перенаправят.
Когда вы определяете записи NS в своем домене, этот DNS становится авторитетом. Если кто-то запросит IP-адрес вашего домена, он проверит его кеш и, если записи нет, запросит DNS, указанный в ваших записях NS.
А что теперь произойдет, если вы создадите еще одну запись A (2.2.2.2) для своего домена в другом DNS? Тогда все клиенты, использующие этот DNS, получат ваш «новый» IP (2.2.2.2), а не настоящий.
Это полностью верно, но не так, как вы думаете.
После того, как вы делегировали поддомен другому набору серверов имен, они становятся авторитетными. Oни может вполне законно рекламировать A-запись для домена; действительно, это нормальная практика, см., например, dig google.com.
Я понятия не имею, что произойдет, если вы рекламируете запись A на делегирование DNS-серверы - я подозреваю, что ничего хорошего, поскольку все остальные вам справедливо советуют. Но рекламировать такую запись вполне допустимо на делегированный серверов, вероятно, поэтому вы не можете найти запрета в RFC.
Так что проблема не в существовании для домена записей A и NS; он пытается рекламировать обе эти записи с тех же серверов имён.