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

Simon Kelley simon at thekelleys.org.uk
Wed Mar 26 20:25:37 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26/03/14 14:42, Alex Xu wrote:
> On 26/03/14 10:37 AM, Nicholas Weaver wrote:
>> 
>> 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.
>> 
> 
> I don't think this is a good idea. Dnsmasq is supposed to be a
> simple cache and lightweight; it defeats the purpose of dnsmasq to
> have it do recursive resolution.
> 
> I don't know what response type would be appropriate here.
> Probably SERVFAIL with a message sent to syslog.
> 

What happens depends in the setting of the --dnssec-check-unsigned flag.

If that's not set, then, as far as dnsmasq is concerned, this is just
unsigned data, and it returns the answer, without the AD bit set,
since it's not secure.

If --dnssec-check-unsigned is set, then the unsigned answer must be
supported by a signed DS record somewhere asserting that this part of
the DNS tree is not signed. Since for records which are signed, that
won't exist, then validation fails, and dnsmasq returns SERVFAIL.

Cheers,


Simon.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMzN8EACgkQKPyGmiibgrfcpwCfaWNwY/ReMXrLAgumd6kUzv4f
JawAoJHrt/AnM10c7TAtIt6RDT0W0EKh
=ifQ0
-----END PGP SIGNATURE-----



More information about the Dnsmasq-discuss mailing list