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

[Dave Taht]

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 <simon at thekelleys.org.uk> wrote:
> On 09/02/14 12:48, Toke Høiland-Jørgensen wrote:
>>
>> Simon Kelley<simon at 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?
>
>
> 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
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

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