2

Responses from our nameserver are intermittently missing RRSIG records despite being requested. All other associated records (such as A records) are returned OK. Consequently dnsssec validation fails. The example below is for paypal but I believe it is not an issue with their nameservers as when querying their nameservers directly I cannot reproduce the issue.

    $ dig +dnssec api.paypal.com @internalnameserver
    Wed May 11 17:35:22 BST 2016

    ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6 <<>> +dnssec api.paypal.com @internalnameserver
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9849
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;api.paypal.com.  IN A

;; ANSWER SECTION:
api.paypal.com.  47 INA
173.0.84.98
api.paypal.com.  47 INA
173.0.88.98
api.paypal.com.  47 INA
173.0.92.23

;; AUTHORITY SECTION:
paypal.com. 47IN
NSns4.p57.dynect.net.
paypal.com. 47IN
NSns3.p57.dynect.net.
paypal.com. 47IN
NSns2.p57.dynect.net.
paypal.com. 47IN
NSns1.p57.dynect.net.

;; ADDITIONAL SECTION:
ns1.p57.dynect.net.  83856 INA
208.78.70.57
ns2.p57.dynect.net.  83856 INA
204.13.250.57
ns3.p57.dynect.net.  83856 INA
208.78.71.57
ns4.p57.dynect.net.  83856 INA
204.13.251.57

;; Query time: 0 msec
;; SERVER: 172.16.0.2#53(172.16.0.2)
;; WHEN: Wed May 11 17:35:25 2016
;; MSG SIZE  rcvd: 241

RRSIG records are missing, however querying paypal NS directly and they are present:

$ dig +dnssec api.paypal.com @ns1.p57.dynect.net

; <<>> DiG 9.5.1-P3 <<>> +dnssec api.paypal.com @ns1.p57.dynect.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33378
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;api.paypal.com.            IN  A

;; ANSWER SECTION:
api.paypal.com.     300 IN  A   173.0.88.98
api.paypal.com.     300 IN  A   173.0.84.98
api.paypal.com.     300 IN  A   66.211.168.91
api.paypal.com.     300 IN  RRSIG   A 5 3 300 20160617044014 20160518034014 11811 paypal.com. SnkboXg/S1uV0IzYhcaCIrq+YtH+z5vtQcgw2O3GnNPM/oQbNWFmDClq Jj7gRgjKNHLy7zH8BHk1p7QBUCJuhQK3ud02dc5IDBSupMSusMp8tay9 eSG6AJEwkNsed0ztuacJiUw2qYETbgnLQyywOAF97Q68m8210tPXHCE2 2qY=

;; AUTHORITY SECTION:
paypal.com.     300 IN  NS  ns1.p57.dynect.net.
paypal.com.     300 IN  NS  ns2.p57.dynect.net.
paypal.com.     300 IN  NS  ns3.p57.dynect.net.
paypal.com.     300 IN  NS  ns4.p57.dynect.net.
paypal.com.     300 IN  RRSIG   NS 5 2 300 20160606184750 20160507180943 11811 paypal.com. rV5WaDBF1SXjx9jSA0iom5+08dMja2aZIb4bqQhm3egqDAWku4+YXcCd rET1pxVQngIYpIPIF7eHheVSuPNd6mC63/U/1/Ph20Xm70OKL0EDjoVa +KgRT71J1X7Whs4oQ6df4L+E8lb8GspeHVyEGfuE00pZRbKt2ZevXZcu ZIk=

;; Query time: 10 msec
;; SERVER: 208.78.70.57#53(208.78.70.57)
;; WHEN: Wed May 18 10:31:17 2016
;; MSG SIZE  rcvd: 517

10 minutes later and the RRSIG records can be be present again. This does appear to be an internal named caching issue as each 'iteration' of the records being present or not seems to coincide with the TTL being reached. - Once it gets or does not get the RRSIG records the response is cached OK for the lifetime of the TTL of the record.

Running bind 9.7.3

If anything is unclear or further information is needed please let me know.

2
  • "intermittent" usually suggests that one or more of your servers aren't serving the right data, and whether you get the right or the wrong answer depends on the RR.
    – Shadur
    May 18, 2016 at 11:44
  • 1
    @Shadur I am querying the same nameserver and it is still intermittent. May 18, 2016 at 12:54

1 Answer 1

4

This is a common non-problem with BIND, though admittedly confusing.

  • In recursive mode, BIND may return extra records that it is passively aware of, but will not actively attempt lookups for those records unless it is required to do so by the relevant standards.
  • When this behavior is encountered with a single DNS server (i.e. the inconsistency is observed from a single server, not from in front of a load balancer), the possibility of the missing RR(s) not being required should be considered. A simple test is to explicitly request a record you expected to be included, and repeat the original query. If the record is now included, then it was not required to perform the additional recursion to include that answer in the prior response. The inclusion of the extra record is purely informational.

In this particular case, it looks like you're expecting the RRSIG records to be presented to the stub resolver. Think about it though. How is that signature useful without also knowing the intermediate signatures?

Before we go chasing through the DNSSEC RFCs, let's do a quick review of what is easily available from Wikipedia:

https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Stub_resolvers

A stub resolver will simply forward a request to a recursive name server, and use the Authenticated Data (AD) bit in the response as a "hint to find out whether the recursive name server was able to validate signatures for all of the data in the Answer and Authority sections of the response."

A validating stub resolver can also potentially perform its own signature validation by setting the Checking Disabled (CD) bit in its query messages. A validating stub resolver uses the CD bit to perform its own recursive authentication. Using such a validating stub resolver gives the client end-to-end DNS security for domains implementing DNSSEC, even if the Internet Service Provider or the connection to them is not trusted.

Emphasis in bold is mine. Putting that together:

  • A non-validating stub resolver simply looks for the AD bit in its response and is trusting the recursive server to have performed the validation for it. It does nothing with the RRSIG record. Applications which want to perform an action based on that RRSIG should be requesting that record directly, and not relying upon its inclusion in the response.
  • A validating stub resolver has to perform its own recursion. This is the only way to validate that valid signatures are in place from the root servers on down to the RRSIG associated with the record in question.

Knowing all of this, we need to confirm what exactly dig is doing when the +dnssec flag is set. We can get that from the manpage:

   +[no]dnssec
       Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO)
       in the OPT record in the additional section of the query.

From this we can infer that dig is not operating as a validating stub resolver (which can be further confirmed with a packet capture if you prefer, as it would have to be performing its own recursion), and that the BIND server is not performing validation on its behalf as the response did not come back with the ad bit set in the OPT pseudo-section for the answer. (just do, an acknowledgement that it saw do in the original query)

2
  • This was eventually fixed through upgrade of hardware. Through tcpdumps I found that whenever it fails bind is not sending OPT UDPsize=4096. This extra pseudo record informs the nameserver that it can receive replies up to 4096 bytes (ie >512 byte boundry). Bind always excludes RRSIG data when this is not set ( kb.isc.org/article/AA-00708/0/… ). When using 'dig +dnssec' I still got the intermittent issue. Do you know why it would skip sending the OPT record despite setting +dnssec? Dec 12, 2016 at 12:06
  • Not off the top of my head, that's a question about BIND's internal behavior and you may want to consider asking it on the dns-ops mailing list. A few of their developers are regulars.
    – Andrew B
    Dec 12, 2016 at 12:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.