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

[Alex Xu]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20140326/be2c7424/attachment.sig>