I have been hanging in the webrtc conference room here, of late, generally running the latest google-chrome betas.
https://appear.in/bufferbloat On Sun, Feb 9, 2014 at 12:59 PM, Simon Kelley <[email protected]> wrote: > 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 -- 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
