5

I am using bind 9.9.2 as a DNSSEC validating recursive resolver in an Internet DMZ. I want to point to my internal DNS servers as stub zones (ideally) or anything except slave zones (to avoid very large zone transfers). We use a routable ip space for our Internal addressing. Sorry if I am using an IP space that you own in my example, but 167.x.x.x is the first zone I found that fits my issue.

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; }
}

When queries hit the DNS server, they attempt at being validated, and fail because 167.in-addr.arpa HAS an RRSIG record, but sub zones do not (and should not!). Google dns is used in this example, but in reality it would be my recursive resolver.

    @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

Is there a way to bypass DNSSEC validation for specific zones? Any zone that I host internally, I do not want DNSSEC validation performed on. I have only see this interfere w/ certain reverse zones where the top level has DS/RRSIG records.

Thanks.

Starsky
  • 103
  • 1
  • 8

2 Answers2

2

I haven't figured out a good way to do this with bind, but can be done with the caching resolver "unboud". The option for unbound is domain-insecure:. Using bind the best I could come up with is signing your zone and doing dnssec-lookaside 16.172.in-addr.arpa dlv.examle.org or something of that nature.

Richard Salts
  • 755
  • 3
  • 17
1

What you are seeing is the DNSSEC records that prove that there is no delegation to 255.167.in-addr.arpa from 167.in-addr.arpa -- as the Google DNS servers see it.

Set up 255.167.in-addr.arpa as an authoritative zone on your own recursive resolver; it will return answers with the AA bit set, regardless of whether a delegation exists. In fact the RFCs prohibit it from returning the AD flag for authoritative data.

LHMathies
  • 113
  • 4
  • > In fact the RFCs prohibit it from returning the AD flag for authoritative data. really? i cannot find this section of DNSEC-related IETF RFCs. – John Greene Apr 24 '22 at 15:57