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

[Toke Høiland-Jørgensen]

Simon Kelley <simon at thekelleys.org.uk> writes:

> Same CPU architecture as the working systems, or different?

Sorry, I meant that the package signatures for the OBS Arch packages are
failing, not the DNSSEC signatures...

> 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.

Well turning log-queries back on, this is the first one (seems to be the
second query performed):

dnsmasq[8595]: query[PTR] 62.75.115.213.in-addr.arpa from 127.0.0.1
dnsmasq[8595]: forwarded 62.75.115.213.in-addr.arpa to 127.0.0.1
dnsmasq[8595]: validation result is INSECURE
dnsmasq[8595]: reply 213.115.75.62 is static-213-115-75-62.sme.bredbandsbolaget.se

Don't see anything preceded by dnssec-query for any in-addr.arpa queries
before that (assuming the cache is not stored between restarts?).

> 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.

Right; I was assuming it would increase the log output, similar to dig
+trace or something...

-Toke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140205/4df85f8f/attachment.sig>