LINUX.ORG.RU

История изменений

Исправление nbw, (текущая версия) :

Пример взят отсюда

В жопу примеры, книжку прочти. Какую - сам знаешь, наверное.

        IN      A       192.168.1.10;
<...>
@       IN      A       192.168.1.10

Эти две записи тупо дублируют друг друга. И точка с запятой в конце строки смотрится странно - в файле зоны она означает начало комментария.

@       IN      A       192.168.1.10
ns      IN      A       192.168.1.10
Первая запись указывает на адрес хоста, находящегося «в корне» зоны, вторая - адрес сервера имён. Ничего странного.

А PTR запись - только одну!

А ты сколько хотел? Один IP-адрес может резольвится только в один хостнейм, другое сложно представить.

Логичнее для сервака было бы вернуть именно example.com, а не ns.example.com.

Из какой логики это следует?

Вообще, на сколько это критично?

При делегировании домена регистратор может проверять корректность записи обратной зоны для полномочного сервера имён этой зоны. А может и не проверять. В общем, не критично (насколько мне известно; могу ошибаться).

Исходная версия nbw, :

Пример взят отсюда

В жопу примеры, книжку прочти. Какую - сам знаешь, наверное.

        IN      A       192.168.1.10;
<...>
@       IN      A       192.168.1.10

Эти две записи тупо дублируют друг друга. И точка с запятой в конце строки смотрится странно - в файле зоны она означает начало комментария.

@       IN      A       192.168.1.10
ns      IN      A       192.168.1.10
Первая запись указывает на адрес хоста, находящегося «в корне» зоны, вторая - адрес сервера имён. Ничего странного.

А PTR запись - только одну!

А ты сколько хотел? Один IP-адрес может резольвится только в один хостнейм, другое сложно представить.

Логичнее для сервака было бы вернуть именно example.com, а не ns.example.com.

Из какой логики это следует?

Вообще, на сколько это критично?

При делегировании домена регистратор может проверять корректность записи обратной зоны для полномочного сервера имён этой зоны. А может и не проверять. В общем, не критично.