Я использую bind 9.9.2 в качестве проверяющего рекурсивного преобразователя DNSSEC в демилитаризованной зоне Интернета. Я хочу указать на свои внутренние DNS-серверы как на зоны-заглушки (в идеале) или что-то еще, кроме подчиненных зон (чтобы избежать передачи очень больших зон). Мы используем маршрутизируемое пространство IP для нашей внутренней адресации. Извините, если в моем примере я использую принадлежащее вам IP-пространство, но 167.x.x.x - это первая зона, которую я обнаружил, которая соответствует моей проблеме.
НАПРИМЕР
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.
Спасибо.
Я не нашел хорошего способа сделать это с помощью bind, но это можно сделать с помощью кэширующего преобразователя unboud. Вариант для несвязанного domain-insecure:
. Используя bind как можно лучше, я подписал вашу зону и сделал 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 для авторитетных данных.