[Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.

[Simon Kelley]

On 09/02/14 12:48, Toke Høiland-Jørgensen wrote:
> Simon Kelley<simon at thekelleys.org.uk>  writes:
>
>> Hmm, that domain validates for me here. It probably makes sense to
>> turn dnssec-debug _off_. One of the things it does is to set the
>> Checking Disabled bit in queries upstream. I'm advised that this is
>> not a good thing to do, since it means the upstream nameserver can
>> return teh first data it finds, even if it doesn't resolve, whilst
>> without CD, the it will keep trying other authoritative servers to get
>> valid data. I don't understand the details, but that would seem
>> applicable here.
>
> Well, turning off dnssec-debug just means I have no name resolution for
> such domains:
>
> $ dig +dnssec +sigchase mail2.tohojo.dk @10.42.8.1                                                                                                         :(
> ;; NO ANSWERS: no more
> We want to prove the non-existence of a type of rdata 1 or of the zone:
> ;; nothing in authority section : impossible to validate the non-existence : FAILED
>
> ;; Impossible to verify the Non-existence, the NSEC RRset can't be validated: FAILED
>
> $ host mail2.tohojo.dk 10.42.8.1
> Using domain server:
> Name: 10.42.8.1
> Address: 10.42.8.1#53
> Aliases:
>
> Host mail2.tohojo.dk not found: 3(NXDOMAIN)
>
>
> And the dnsmasq logs:
>
> Sun Feb  9 13:45:22 2014 daemon.info dnsmasq[6698]: query[A] mail2.tohojo.dk from 10.42.8.106
> Sun Feb  9 13:45:22 2014 daemon.info dnsmasq[6698]: forwarded mail2.tohojo.dk to 213.80.98.3
> Sun Feb  9 13:45:22 2014 daemon.info dnsmasq[6698]: forwarded mail2.tohojo.dk to 213.80.98.2
> Sun Feb  9 13:45:22 2014 daemon.info dnsmasq[6698]: dnssec-query[DNSKEY] tohojo.dk to 213.80.98.2
> Sun Feb  9 13:45:22 2014 daemon.info dnsmasq[6698]: dnssec-query[DS] tohojo.dk to 213.80.98.2
> Sun Feb  9 13:45:22 2014 daemon.info dnsmasq[6698]: dnssec-query[DNSKEY] dk to 213.80.98.2
> Sun Feb  9 13:45:22 2014 daemon.info dnsmasq[6698]: dnssec-query[DS] dk to 213.80.98.2
> Sun Feb  9 13:45:22 2014 daemon.info dnsmasq[6698]: reply dk is BOGUS DS
> Sun Feb  9 13:45:22 2014 daemon.info dnsmasq[6698]: validation result is BOGUS
> Sun Feb  9 13:45:22 2014 daemon.info dnsmasq[6698]: reply mail2.tohojo.dk is 144.76.141.112
> Sun Feb  9 13:45:32 2014 daemon.info dnsmasq[6698]: query[A] mail2.tohojo.dk from 10.42.8.106
> Sun Feb  9 13:45:32 2014 daemon.info dnsmasq[6698]: forwarded mail2.tohojo.dk to 213.80.98.2
> Sun Feb  9 13:45:32 2014 daemon.info dnsmasq[6698]: dnssec-query[DNSKEY] tohojo.dk to 213.80.98.2
> Sun Feb  9 13:45:32 2014 daemon.info dnsmasq[6698]: dnssec-query[DS] tohojo.dk to 213.80.98.2
> Sun Feb  9 13:45:32 2014 daemon.info dnsmasq[6698]: dnssec-query[DNSKEY] dk to 213.80.98.2
> Sun Feb  9 13:45:32 2014 daemon.info dnsmasq[6698]: dnssec-query[DS] dk to 213.80.98.2
> Sun Feb  9 13:45:32 2014 daemon.info dnsmasq[6698]: reply dk is BOGUS DS
> Sun Feb  9 13:45:32 2014 daemon.info dnsmasq[6698]: validation result is BOGUS
> Sun Feb  9 13:45:32 2014 daemon.info dnsmasq[6698]: reply mail2.tohojo.dk is 144.76.141.112
>
> It works on my other machine that's not running on cerowrt; so perhaps
> it's something architecture-specific?

It's possible, indeed that's happened during testing.
Dave, could you talk me through getting the latest dnsmasq package on 
the 3800 you gave me?

Note that here, the inception time for the signature of the DS is 
20140208022128, UTC ie late yesterday. Are you sure your clock is 
correct, time and _date_?

Please clould you post the result of running

dig @213.80.98.2 +dnssec ds dk

just to check you're getting the same data. 213.80.98.2 won't talk to me.

>
>
>
> Interestingly, after failing a DNSSEC resolution, dnsmasq then tries to
> append the configured domain:
>
> Sun Feb  9 13:45:32 2014 daemon.info dnsmasq[6698]: query[A] mail2.tohojo.dk.karlstad.toke.dk from 10.42.8.106
> Sun Feb  9 13:45:32 2014 daemon.info dnsmasq[6698]: config mail2.tohojo.dk.karlstad.toke.dk is NXDOMAIN
>
> This is probably not desirable?

That's not dnsmasq, it's the resolver in 10.42.8.106, probably because 
/etc/resolv.conf has a search path configured and the wrong value for 
ndots. See man resolv.conf for details.

>
>> OK, you've got to the trust-anchor root keys which are hardwired in as
>> part of the dnsmasq configuration. As such, Dnsmasq assumes they are
>> valid and doesn't need RRSIGs to check their self-signing. As the
>> signatures aren't known, they are not supplied with a query for DNSKEY
>> of the root zone. That may be wrong. When providing trust anchors to
>> eg BIND) is it possible/normal to provide the SIGS too?
>
> I suppose it does (?). The file usually supplied with BIND is available here:
>
> http://ftp.isc.org/isc/bind9/keys/9.8/

OK, so they're not hardwiring them either. Maybe the special-case 
processing in dnsmasq that stops queries for DNSKEYS which are known 
locally is not the right thing to do.



Cheers,

Simon.


>
> -Toke