BIND 9.4.1 реализовал автоматические пустые обратные зоны для частного адресного пространства, чтобы предотвратить обратную утечку DNS. Это избавляет администратора от необходимости определять эти пустые зоны и сокращает количество "нестандартных" конфигураций, которые будут вызывать утечку обратных запросов DNS к Серверы блэкхолинга IANA.
Каков формат по умолчанию синтезированных ответов из автоматической пустой обратной зоны? Формат полностью не описан в документации. (только несколько параметров по умолчанию)
Если параметры по умолчанию для пустых зон не были изменены, ANY
запрос должен вернуть следующее:
# dig @localhost 254.169.IN-ADDR.ARPA ANY
; <<>> DiG 9.8.4-P2 <<>> @localhost 254.169.IN-ADDR.ARPA ANY
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9411
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;254.169.IN-ADDR.ARPA. IN ANY
;; ANSWER SECTION:
254.169.IN-ADDR.ARPA. 86400 IN SOA 254.169.IN-ADDR.ARPA. . 0 28800 7200 604800 86400
254.169.IN-ADDR.ARPA. 0 IN NS 254.169.IN-ADDR.ARPA.
;; AUTHORITY SECTION:
254.169.IN-ADDR.ARPA. 86400 IN SOA 254.169.IN-ADDR.ARPA. . 0 28800 7200 604800 86400
aa
) установлен флаг. Без рекурсии.NS
запись указывает на вершину зоны, которая не имеет A
запись.NS
запись.MNAME
Поле SOA (главный сервер) идентично названию пустой зоны. Это поведение изменено empty-server
вариант.RNAME
Поле SOA (контакт) содержит одну точку (.
). Это поведение изменено empty-contact
вариант.NXDOMAIN
.Исходя из вышеизложенного, самый надежный способ отпечатка синтезированной пустой зоны - это поиск aa
флаг и проверьте, NS
запись указывает на вершину зоны с отсутствующим A
запись. Имейте в виду, что вы не можете проверить наличие NXDOMAIN
ответ, потому что другие типы записей присутствуют с тем же именем; ты получишь NOERROR
ответ без раздела ANSWER при запросе A
запись.
Обычно можно с уверенностью предположить, что ответы с "официальными" полями SOA (MNAME
из prisoner.iana.org.
, RNAME
из hostmaster.root-servers.org.
) просочились на корневые серверы имен, но в зависимости от сканирования, которое вы выполняете в своей сети, этого не всегда может быть достаточно.