[Dnsmasq-discuss] DNSSEC validation causes SIGSEGV by strcpy from 0x0

Nicholas Weaver nweaver at gmail.com
Wed Mar 26 14:37:17 UTC 2014


On Mar 26, 2014, at 5:27 AM, Simon Kelley <simon at thekelleys.org.uk> wrote:

> Signed PGP part
> On 25/03/14 23:03, Alex Xu wrote:
> 
> >>
> >
> > Poor wording on my part. I meant that `dig isc.org @74.82.42.42
> > +dnssec` returns no results, but `dig isc.org rrsig @74.82.42.42`
> > does.
> >
> 
> That's no good as an upstream server: you need the RRSIGs in the
> answer, which is what a DNS server with DNSSEC support does.
> (Otherwise, every query which got an answer without RRSIGS would need
> another query to see if they exist or not, that would be very slow.)#

Also, that fallback itself doesn't actually work on a lot of resolvers!  (Notably OpenDNS, but also the server Alex Xu is using)  E.g:

> dig RRSIG com @74.82.42.42
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9312
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;com.                           IN      RRSIG

;; ANSWER SECTION:
com.                    86400   IN      RRSIG   DNSKEY 8 1 {crypto-goop}
com.                    86400   IN      RRSIG   NS 8 1 {crypto-goop}
com.                    900     IN      RRSIG   SOA 8 1 {crypto-goop}
com.                    86400   IN      RRSIG   NSEC3PARAM 8 1 {crypto-goop}


Notably absent is the RRSIG for the DS for com, without which you can't actually validate all that data.  Bind does properly also include the DS record (this is our local bind copy)

> dig RRSIG com @192.150.186.8
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.8.3-P1 <<>> RRSIG com @192.150.186.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10620
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 13, ADDITIONAL: 15

;; QUESTION SECTION:
;com.                           IN      RRSIG

;; ANSWER SECTION:
com.                    172756  IN      RRSIG   NS 8 1 {crypto-goop}
com.                    86356   IN      RRSIG   NSEC3PARAM 8 1 {crypto-goop}
com.                    86356   IN      RRSIG   DNSKEY 8 1 {crypto-goop}
com.                    856     IN      RRSIG   SOA 8 1 {crypto-goop}
com.                    26324   IN      RRSIG   DS 8 1 {crypto-goop}


Overall, my thought is "try to get RRSIG records from the recursive resolver" is not a happy fallback: the number of cases where this work is actually pretty small, since a resolver which properly includes the DS record is going to support the request for DNSSEC records.  

Especially for the NAT case, the far better fallback is do an iterative fetch, starting with the root and working down, when the recursive resolver is noncooperative.

--
Nicholas Weaver                  it is a tale, told by an idiot,
nweaver at icsi.berkeley.edu                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20140326/cdd2631e/attachment.sig>


More information about the Dnsmasq-discuss mailing list