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

[Dave Taht <dave.taht@gmail.com>]

Got the right time?

I have no idea how to deal with the time headache still, besides adding
an un-validating-resolver to ntpdate, and sanity checks in dnsmasq  like
(if system time is < my build time, don't do dnssec) - but the latter
is imperfect.

http://www.bufferbloat.net/issues/113

On Sun, Feb 9, 2014 at 4:48 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Simon Kelley <simon@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?
>
>
>
> 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?
>
>> 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/
>
> -Toke
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html