Simon Kelley <[email protected]> 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
signature.asc
Description: PGP signature
_______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
