Назад | Перейти на главную страницу

Разъяснение RFC 2606 и 6761 относительно зарезервированных доменов

Я читаю https://tools.ietf.org/html/rfc2606 и https://tools.ietf.org/html/rfc6761, но я до сих пор не понимаю некоторых подробностей. Почему https://tools.ietf.org/html/rfc2606 не говорит явно, какой код ответа мы должны вернуть для зарезервированного домена? Это цель https://tools.ietf.org/html/rfc6761 добавить дополнительные детали?

В https://tools.ietf.org/html/rfc6761, они говорят:

Вместо этого кеширующие DNS-серверы ДОЛЖНЫ по умолчанию немедленно генерировать отрицательные ответы на все такие запросы.

Отрицательный результат - это NXDOMAIN или ОТКАЗАНО? или все зависит от разработчика? В начале того же RFC написано:

Чтобы это специальное "гарантированно несуществующее" имя могло иметь какое-либо использование, оно должно быть определено так, чтобы оно возвращало NXDOMAIN.

Это применимо здесь? Мне непонятно, почему они используют термин «отрицательный ответ». Кроме того, реализован ли этот RFC в реальном мире? похоже, что dig все еще запрашивает корневые серверы для этих зарезервированных доменов.

NXDOMAIN - отрицательный ответ. ОТКАЗАНО - это отказ в предоставлении услуги и здесь не применяется.

В NXDOMAIN и отрицательные отзывы используются взаимозаменяемо, так как вот как они определены в RFC 2308, 2 и разъяснено в RFC 8020; RFC 6761 стандартизирует Особые доменные имена, а не коды ответов DNS.

Также стоит отметить, что это относится не ко всем зарезервированным доменам, а более конкретно

  • в in-addr.arpa. домены для RFC 1918 частные адреса, т.е. 10.in-addr.arpa. для 10./8, 168.192.in-addr.arpa. для 192.168./16 и все 172.16./12 как указано в RFC 6761, 6.1
  • и TLD test. (6.2), localhost. (6.3) & invalid. (6.4),
  • но не к example., example.com., example.net. & example.org. с этим следует обращаться как обычно (6.5). (Например. example.com. IN A 93.184.216.34).

Кроме того, реализован ли этот RFC в реальном мире?

если ты dig -x 192.168.1.1, вы должны получить NXDOMAIN для 1.1.168.192.in-addr.arpa. IN PTR из любого рекурсивный сервер имен, но авторитетный сервер для частная сеть может ответить, что когда-либо применимо на местном уровне.

Это реализовано, например, в BIND пользователем

  1. named.conf.local:

    // Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

  2. /etc/bind/zones.rfc1918:

    zone "10.in-addr.arpa"      { type master; file "/etc/bind/db.empty"; };
zone "16.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
. . .

  3. /etc/bind/db.empty:

    ; BIND reverse data file for empty rfc1918 zone
;
; DO NOT EDIT THIS FILE - it is used for multiple zones.
; Instead, copy it, edit named.conf, and use that copy.
;
$TTL    86400
@       IN      SOA     localhost. root.localhost. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          86400 )       ; Negative Cache TTL
;
@       IN      NS      localhost.

Это гарантирует NXDOMAIN ответы на рекурсивные серверы имен вместо использования корневых серверов из

zone "." {
        type hint;
        file "/usr/share/dns/root.hints";
};