On 05/02/14 20:09, Toke Høiland-Jørgensen wrote:
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?).
That's straightforward. Dnsmasq gets a query for
62.75.115.213.in-addr.arpa, sends it upstream, gets an answer which
isn't signed, and determines that it's insecure, then returns the
answer. The last line is as it is because a PTR RR for
62.75.115.213.in-addr.arpa has been parsed into the triple
(213.115.75.62, static-213-115-75-62.sme.bredbandsbolaget.se,
reverse-mapping)
for storage in the dnsmasq cache, which is not a general RR cache, but a
cache of domain-names against IP addresses, with some extensions for
CNAMEs, and now more extensions for DNSKEYs DSs and RRSIGs.
Cheers,
Simon.
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
