Обход DNSSEC для локальных зон-заглушек
Я использую bind 9.9.2 в качестве проверяющего рекурсивного распознавателя DNSSEC в DMZ Интернета. Я хочу указать на мои внутренние DNS-серверы как зоны-заглушки (в идеале) или что-либо, кроме подчиненных зон (чтобы избежать очень больших передач зон). Мы используем маршрутизируемое пространство IP для нашей внутренней адресации. Извините, если я использую IP-пространство, которым вы владеете в моем примере, но 167.xxx - первая найденная зона, которая подходит для моей проблемы.
НАПРИМЕР
dnssec-enable yes;
dnssec-validation yes;
dnssec-accept-expired no;
zone "16.172.in-addr.arpa" {
type stub;
masters { 167.255.1.53; }
}
zone "myzone.com" in {
type stub;
masters { 167.255.1.53; }
}
Когда запросы попадают на DNS-сервер, они пытаются пройти проверку и терпят неудачу, потому что 167.in-addr.arpa имеет запись RRSIG, а подзоны - нет (и не должны!). В этом примере используется Google DNS, но на самом деле это мой рекурсивный преобразователь.
@8.8.8.8 -x 167.255.1.53 +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17488
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;53.1.255.167.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
167.in-addr.arpa. 1800 IN SOA z.arin.net. dns-ops.arin.net. 2013100713 1800 900 691200 10800
167.in-addr.arpa. 1800 IN RRSIG SOA 5 3 86400 20131017160124 20131007160124 812 167.in-addr.arpa. Lcl8sCps7LapnAj4n403KXx7A3GO7+2z/9Q2R2mwkh9FL26iDx7GlU4+ NufGd92IEJCdBu9IgcZP4I9QcKi8DI28og27WrfKd5moSl/STj02GliS qPTfNiewmTTIDw5++IlhITbp+CoJuZCRCdDbyWKmd5NSLcbskAwbCVlO vVA=
167.in-addr.arpa. 10800 IN NSEC 1.167.in-addr.arpa. NS SOA TXT RRSIG NSEC DNSKEY
167.in-addr.arpa. 10800 IN RRSIG NSEC 5 3 10800 20131017160124 20131007160124 812 167.in-addr.arpa. XALsd59i+XGvCIzjhTUFXcr11/M8prcaaPQ5yFSbvP9TzqjJ3wpizvH6 202MdrIWbsT1Dndri49lHKAXgBQ5OOsUmOh+eoRYR5okxRO4VLc5Tkze Gh0fQLcwGXPuv9A4SFNIrNyi3XU4Qvq0cViKXIuEGTa3C+zMPuvc0her oKk=
254.167.in-addr.arpa. 10800 IN NSEC 26.167.in-addr.arpa. NS RRSIG NSEC
254.167.in-addr.arpa. 10800 IN RRSIG NSEC 5 4 10800 20131017160124 20131007160124 812 167.in-addr.arpa. xnsLBTnPhdyABdvqtEHPxa6Y6NASfYAWfW1yYlNliTyV8TFeNOqewjwj nY43CWD77ftFDDQTLFEOPpV5vwmnUGYTRztK+kB5UrlflhPgiqYiBaBD RQaFQ8DIKaof8/snusZjK7aNmfe09t9gRcaX/pXn3liKz7m/ggxZi0f9 xo0=
;; Query time: 31 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Oct 7 16:52:59 2013
;; MSG SIZE rcvd: 722
Есть ли способ обойти проверку DNSSEC для определенных зон? В любой зоне, в которой я размещаюсь, я не хочу выполнять проверку DNSSEC. Я только вижу, что это мешает с некоторыми обратными зонами, где на верхнем уровне есть записи DS/RRSIG.
Благодарю.
2 ответа
Я не нашел хороший способ сделать это с помощью bind, но это можно сделать с помощью решателя кэширования unboud. Вариант для несвязанного domain-insecure:
, Используя связывание лучшее, что я мог придумать, подписав вашу зону и делая dnssec-lookaside 16.172.in-addr.arpa dlv.examle.org
или что-то в этом роде.
То, что вы видите, - это записи DNSSEC, которые доказывают, что нет делегирования 255.167.in-addr.arpa
от 167.in-addr.arpa
DNS-серверы Google видят это.
Настроить 255.167.in-addr.arpa
как авторитетная зона на вашем собственном рекурсивном резольвере; он будет возвращать ответы с установленным битом AA независимо от того, существует ли делегирование. Фактически RFC запрещают ему возвращать флаг AD для достоверных данных.