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 <[email protected]> wrote: > Simon Kelley <[email protected]> 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 > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel > -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
