On 09/02/14 12:48, Toke Høiland-Jørgensen 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?
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
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
