Estou usando a ligação 9.9.2 como um resolvedor recursivo de validação DNSSEC em uma DMZ da Internet. Eu quero apontar para meus servidores DNS internos como zonas de stub (idealmente) ou qualquer coisa, exceto as zonas escravas (para evitar transferências de zona muito grandes). Nós usamos um espaço ip roteável para nosso endereçamento interno. Desculpe se estou usando um espaço IP que você possui no meu exemplo, mas 167.x.x.x é a primeira zona que encontrei que se encaixa no meu problema.
E.G
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; }
}
Quando as consultas atingem o servidor DNS, elas tentam ser validadas e falham porque 167.in-addr.arpa possui um registro RRSIG, mas as subzonas não (e não devem!). O Google dns é usado neste exemplo, mas na realidade seria meu resolvedor recursivo.
@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
Existe uma maneira de contornar a validação do DNSSEC para zonas específicas? Qualquer zona que eu hospede internamente, não quero que a validação do DNSSEC seja executada. Eu só vejo isso interferir w / certas zonas inversas, onde o nível superior tem registros DS / RRSIG.
Obrigado.
Eu não descobri uma boa maneira de fazer isso com bind, mas pode ser feito com o resolvedor de cache "unboud". A opção para unbound é domain-insecure: . Usando bind o melhor que eu poderia fazer é assinar sua zona e fazer dnssec-lookaside 16.172.in-addr.arpa dlv.examle.org ou algo dessa natureza.
O que você está vendo são os registros do DNSSEC que comprovam que não há delegação para 255.167.in-addr.arpa de 167.in-addr.arpa - como os servidores DNS do Google o veem.
Configure 255.167.in-addr.arpa como uma zona autoritativa em seu próprio resolvedor recursivo; ele retornará respostas com o conjunto de bits AA, independentemente da existência de uma delegação. Na verdade, os RFCs proíbem que ele retorne o sinalizador AD para dados autoritativos.