Simon Kelley 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