[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