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

Simon Kelley simon at thekelleys.org.uk
Wed Feb 5 14:51:33 EST 2014


On 05/02/14 17:10, Toke Høiland-Jørgensen wrote:
> Toke Høiland-Jørgensen <toke at toke.dk> writes:
>
>> Can add it to my bufferbloat OBS :)
>
> Right, so packages available for Arch, Debian 7 and Ubuntu 12.04, 12.10
> and 13.10 are available from here:
> https://build.opensuse.org/project/repositories/home:tohojo:dnsmasq
>
> For some reason, signature verification is failing for me on the Arch
> repo.

Same CPU architecture as the working systems, or different?
>
>
> Also, installed it on my workstation, and it seems to do *something* at
> least. Running with --log-queries I get output like this:
>
> dnsmasq[19525]: dnssec-query[DNSKEY] tohojo.dk to 127.0.0.1
> dnsmasq[19525]: dnssec-query[DNSKEY] tohojo.dk to 127.0.0.1
> dnsmasq[19525]: dnssec-query[DS] tohojo.dk to 127.0.0.1
> dnsmasq[19525]: dnssec-query[DS] tohojo.dk to 127.0.0.1
> dnsmasq[19525]: reply tohojo.dk is DS keytag 49471
> dnsmasq[19525]: reply tohojo.dk is DNSKEY keytag 30141
> dnsmasq[19525]: reply tohojo.dk is DNSKEY keytag 49471
> dnsmasq[19525]: validation result is SECURE
>
> (I'm still running BIND on localhost on a different port which is why
> it's forwarded to there...)
>
> And sometimes there's also lines saying
>
> dnsmasq[19525]: validation result is INSECURE
>
> but mostly from in-addr.arpa and other places that I wouldn't expect to
> be verified.
>
> Finally there's a bunch of queries that don't say anything about dnssec
> anywhere.
>
That's expected for 1) queries answered from local configuration 
(/etc/hosts etc) 2) queries answered with data from DHCP (this is 
probably not relevant) 3) queries answered from the cache. The 
verification result is stored in the cache and not repeated.

The log gives the source of the data, so these should be identifiable.

> Oh, and --dnssec-debug doesn't seem to do anything.

It does two things, the results of which are not externally obvious.

1) It sets the cd (checking disabled) bit in upstream queries, so that 
it's possible to check that invalid data is identified, rather than just 
getting a SERVFAIL from the upstream server.

2) It suppresses SERVFAIL as the reply to queries whose answer doesn't 
verify, for similar reasons.


Cheers,

Simon.


>
> -Toke
>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>




More information about the Cerowrt-devel mailing list