* [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
@ 2014-02-04 16:20 Dave Taht
2014-02-05 7:13 ` Toke Høiland-Jørgensen
0 siblings, 1 reply; 36+ messages in thread
From: Dave Taht @ 2014-02-04 16:20 UTC (permalink / raw)
To: cerowrt-devel
One of the last big-ticket items that was on cerowrt's original
roadmap has been dnssec support.
An alpha of support for it just landed upstream and is available in dnsmasq's
testing directory...
http://www.thekelleys.org.uk/dnsmasq/test-releases/
I'm REALLY reluctant to just add it to the cerowrt build, but am
ceriously tempted to slide it in before cerowrt hits a stable release.
As dnsmasq is used heavily in ubuntu at least, it would make more
sense for those that
run that os to be trying this before committing it to cerowrt. I don't
know to what extent other OSes run dnsmasq.
is anyone up to producing a ppa or working with this on their
os-of-choice systems?
There are two new library requirements in dnsmasq that bloat it up
considerably, libnettle
and libgmp. Still, it's under a megabyte.
---------- Forwarded message ----------
From: Simon Kelley <simon@thekelleys.org.uk>
Date: Tue, Feb 4, 2014 at 10:29 AM
Subject: [Dnsmasq-discuss] Testers wanted: DNSSEC.
To: Dnsmasq-discuss@lists.thekelleys.org.uk
DNSSEC in dnsmasq is a long story. There have been requests for the
feature for at least five years, and work was started in earnest two
years ago, when Giovanni Bajo got much of the way on validation, and I
made the necessary changes to the cache code. That effort stalled
until this winter, when grant from Comcast
(http://techfund.comcast.com/index.php/home/root/comcast-news/summer-2013-project-support-update)
allowed me to work full-time to get things moving again.
The result is dnsmasq-2.69test5, in git and the website now, which is
ready for testers, the more the better. From the release notes:
DNSSEC validation and caching. Dnsmasq needs to be
compiled with this enabled, with
make dnsmasq COPTS=-DHAVE_DNSSEC
this add dependencies on the nettle crypto library and the
gmp maths library. It's possible to have these linked
statically with
make dnsmasq COPTS='-DHAVE_DNSSEC -DHAVE_DNSSEC_STATIC'
which bloats the dnsmasq binary to over a megabyte, but
saves the size of the shared libraries which are five
times that size.
To enable, DNSSEC, you will need a set of
trust-anchors. Now that the TLDs are signed, this can be
the keys for the root zone, and for convenience they are
included in trust-anchors.conf in the dnsmasq
distribution. You should of course check that these are
legitimate and up-to-date. So, adding
conf-file=/path/to/trust-anchors.conf
dnssec
to your config is all thats needed to get things
working. The upstream nameservers have to be DNSSEC-capable
too, of course. Many ISP nameservers aren't, but the
Google public nameservers (8.8.8.8 and 8.8.4.4) are.
When DNSSEC is configured, dnsmasq validates any queries
for domains which are signed. Query results which are
bogus are replaced with SERVFAIL replies, and results
which are correctly signed have the AD bit set. In
addition, and just as importantly, dnsmasq supplies
correct DNSSEC information to clients which are doing
their own validation, and caches DNSKEY, DS and RRSIG
records, which significantly improve the performance of
downstream validators. Setting --log-queries will shoow
DNSSEC in action.
I've been using this code in production here for 24 hours without
problems, so it's probably fine, but certainly alpha, and you're
advised to have a fallback path, just in case. It's pretty much
complete, except for NSEC3 validation. NXDOMAIN/NODATA replies for
zones which use this will be wrongly classed as INSECURE at the
moment.
So, please go for it, and report results here.
Cheers,
Simon.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-04 16:20 [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC Dave Taht
@ 2014-02-05 7:13 ` Toke Høiland-Jørgensen
2014-02-05 17:10 ` Toke Høiland-Jørgensen
0 siblings, 1 reply; 36+ messages in thread
From: Toke Høiland-Jørgensen @ 2014-02-05 7:13 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 499 bytes --]
Dave Taht <dave.taht@gmail.com> writes:
> As dnsmasq is used heavily in ubuntu at least, it would make more
> sense for those that run that os to be trying this before committing
> it to cerowrt. I don't know to what extent other OSes run dnsmasq.
I'm running it on my workstation backed by a DNSSEC-verifying BIND. Will
try the new version and get rid of BIND...
> is anyone up to producing a ppa or working with this on their
> os-of-choice systems?
Can add it to my bufferbloat OBS :)
-Toke
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-05 7:13 ` Toke Høiland-Jørgensen
@ 2014-02-05 17:10 ` Toke Høiland-Jørgensen
2014-02-05 19:51 ` Simon Kelley
0 siblings, 1 reply; 36+ messages in thread
From: Toke Høiland-Jørgensen @ 2014-02-05 17:10 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]
Toke Høiland-Jørgensen <toke@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.
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.
Oh, and --dnssec-debug doesn't seem to do anything.
-Toke
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-05 17:10 ` Toke Høiland-Jørgensen
@ 2014-02-05 19:51 ` Simon Kelley
2014-02-05 20:09 ` Toke Høiland-Jørgensen
0 siblings, 1 reply; 36+ messages in thread
From: Simon Kelley @ 2014-02-05 19:51 UTC (permalink / raw)
To: cerowrt-devel
On 05/02/14 17:10, Toke Høiland-Jørgensen wrote:
> Toke Høiland-Jørgensen <toke@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-05 19:51 ` Simon Kelley
@ 2014-02-05 20:09 ` Toke Høiland-Jørgensen
2014-02-05 22:26 ` Simon Kelley
0 siblings, 1 reply; 36+ messages in thread
From: Toke Høiland-Jørgensen @ 2014-02-05 20:09 UTC (permalink / raw)
To: Simon Kelley; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]
Simon Kelley <simon@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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-05 20:09 ` Toke Høiland-Jørgensen
@ 2014-02-05 22:26 ` Simon Kelley
2014-02-06 7:28 ` Toke Høiland-Jørgensen
0 siblings, 1 reply; 36+ messages in thread
From: Simon Kelley @ 2014-02-05 22:26 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: cerowrt-devel
On 05/02/14 20:09, Toke Høiland-Jørgensen wrote:
> Simon Kelley <simon@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?).
>
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-05 22:26 ` Simon Kelley
@ 2014-02-06 7:28 ` Toke Høiland-Jørgensen
2014-02-06 10:53 ` Simon Kelley
0 siblings, 1 reply; 36+ messages in thread
From: Toke Høiland-Jørgensen @ 2014-02-06 7:28 UTC (permalink / raw)
To: Simon Kelley; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 327 bytes --]
Simon Kelley <simon@thekelleys.org.uk> writes:
> 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.
Right, that's what I thought. So everything is working as it should? :)
-Toke
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-06 7:28 ` Toke Høiland-Jørgensen
@ 2014-02-06 10:53 ` Simon Kelley
2014-02-06 10:57 ` Toke Høiland-Jørgensen
0 siblings, 1 reply; 36+ messages in thread
From: Simon Kelley @ 2014-02-06 10:53 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: cerowrt-devel
On 06/02/14 07:28, Toke Høiland-Jørgensen wrote:
> Simon Kelley<simon@thekelleys.org.uk> writes:
>
>> 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.
>
> Right, that's what I thought. So everything is working as it should? :)
>
> -Toke
Everything is working as I would expect it to. If that's correct or not
depends on how well I've understood the standard, and is a a whole
different question :-)
Cheers,
Simon.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-06 10:53 ` Simon Kelley
@ 2014-02-06 10:57 ` Toke Høiland-Jørgensen
2014-02-06 11:27 ` Simon Kelley
0 siblings, 1 reply; 36+ messages in thread
From: Toke Høiland-Jørgensen @ 2014-02-06 10:57 UTC (permalink / raw)
To: Simon Kelley; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 282 bytes --]
Simon Kelley <simon@thekelleys.org.uk> writes:
> Everything is working as I would expect it to. If that's correct or
> not depends on how well I've understood the standard, and is a a whole
> different question
Right. Anything in particular I should be on the lookout for?
-Toke
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-06 10:57 ` Toke Høiland-Jørgensen
@ 2014-02-06 11:27 ` Simon Kelley
2014-02-06 12:35 ` Toke Høiland-Jørgensen
2014-02-06 13:42 ` Toke Høiland-Jørgensen
0 siblings, 2 replies; 36+ messages in thread
From: Simon Kelley @ 2014-02-06 11:27 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: cerowrt-devel
On 06/02/14 10:57, Toke Høiland-Jørgensen wrote:
> Simon Kelley<simon@thekelleys.org.uk> writes:
>
>> Everything is working as I would expect it to. If that's correct or
>> not depends on how well I've understood the standard, and is a a whole
>> different question
>
> Right. Anything in particular I should be on the lookout for?
>
> -Toke
If you send the dnsmasq process SIGUSR1, it will dump to the log a few
statistics (and a dump of the contents of the cache of you have
--log-queries set)
The stats includes memory use by DNSSEC, so keeping an eye on that would
be good, I'm twitchy about it, having spent 4 days finding a memory leak
just before this release.
Otherwise, just the usual stuff, crashes, infinite loops, wrong answers.
"internal error" log entries.
Cheers,
Simon.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-06 11:27 ` Simon Kelley
@ 2014-02-06 12:35 ` Toke Høiland-Jørgensen
2014-02-06 15:01 ` Simon Kelley
2014-02-06 13:42 ` Toke Høiland-Jørgensen
1 sibling, 1 reply; 36+ messages in thread
From: Toke Høiland-Jørgensen @ 2014-02-06 12:35 UTC (permalink / raw)
To: Simon Kelley; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]
Simon Kelley <simon@thekelleys.org.uk> writes:
> If you send the dnsmasq process SIGUSR1, it will dump to the log a few
> statistics (and a dump of the contents of the cache of you have
> --log-queries set)
Right; well after running for 16h, mostly idle:
dnsmasq[9057]: time 1391689421
dnsmasq[9057]: cache size 150, 3/876 cache insertions re-used unexpired cache entries.
dnsmasq[9057]: queries forwarded 455, queries answered locally 121527
dnsmasq[9057]: queries for authoritative zones 0
dnsmasq[9057]: DNSSEC memory in use 8016, max 20304, allocated 22176
dnsmasq[9057]: server 127.0.0.1#5333: queries sent 491, retried or failed 0
> The stats includes memory use by DNSSEC, so keeping an eye on that would be
> good, I'm twitchy about it, having spent 4 days finding a memory leak just
> before this release.
Will keep an eye on it :)
So, just to make sure I understand things: What kind of guarantees does
the DNSSEC support give? If an upstream server is injecting things into
DNS (for a signed zone of course), is dnsmasq guaranteed to discard the
reply? And can a malicious upstream server strip out DNSSEC results to
fool dnsmasq into accepting a bogus response?
-Toke
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-06 12:35 ` Toke Høiland-Jørgensen
@ 2014-02-06 15:01 ` Simon Kelley
2014-02-09 12:09 ` Toke Høiland-Jørgensen
0 siblings, 1 reply; 36+ messages in thread
From: Simon Kelley @ 2014-02-06 15:01 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: cerowrt-devel
On 06/02/14 12:35, Toke Høiland-Jørgensen wrote:
>
> So, just to make sure I understand things: What kind of guarantees does
> the DNSSEC support give? If an upstream server is injecting things into
> DNS (for a signed zone of course), is dnsmasq guaranteed to discard the
> reply? And can a malicious upstream server strip out DNSSEC results to
> fool dnsmasq into accepting a bogus response?
Yes, and yes, AFAICS.
There are four possible results of verification, given in RFC 4025 para 4.3
Quote:
Secure: An RRset for which the resolver is able to build a chain of
signed DNSKEY and DS RRs from a trusted security anchor to the
RRset. In this case, the RRset should be signed and is subject to
signature validation, as described above.
Insecure: An RRset for which the resolver knows that it has no chain
of signed DNSKEY and DS RRs from any trusted starting point to the
RRset. This can occur when the target RRset lies in an unsigned
zone or in a descendent of an unsigned zone. In this case, the
RRset may or may not be signed, but the resolver will not be able
to verify the signature.
Bogus: An RRset for which the resolver believes that it ought to be
able to establish a chain of trust but for which it is unable to
do so, either due to signatures that for some reason fail to
validate or due to missing data that the relevant DNSSEC RRs
indicate should be present. This case may indicate an attack but
may also indicate a configuration error or some form of data
corruption.
Indeterminate: An RRset for which the resolver is not able to
determine whether the RRset should be signed, as the resolver is
not able to obtain the necessary DNSSEC RRs. This can occur when
the security-aware resolver is not able to contact security-aware
name servers for the relevant zones.
Dnsmasq doesn't distriguish between Insecure and Indeterminate, both are
lumped together as "INSECURE". The reason it's done that way is that it
would cost extra work and round-trips upstream to make the distinction,
and, unless I've misunderstood, there are no differences in the external
behavior required for these two results.
bogus - return SERVFAIL in the answer
secure - set the AD bit
insecure and indeterminate - do neither of the above.
Cheers,
Simon.
>
> -Toke
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-06 15:01 ` Simon Kelley
@ 2014-02-09 12:09 ` Toke Høiland-Jørgensen
2014-02-09 12:23 ` Simon Kelley
0 siblings, 1 reply; 36+ messages in thread
From: Toke Høiland-Jørgensen @ 2014-02-09 12:09 UTC (permalink / raw)
To: Simon Kelley; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 2958 bytes --]
OK, so I've tried building dnsmasq on cerowrt, from git head. It seems
to have some trouble validating stuff:
Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: forwarded mail2.tohojo.dk to 213.80.98.2
Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: dnssec-query[DNSKEY] tohojo.dk to 213.80.98.2
Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: dnssec-query[DS] tohojo.dk to 213.80.98.2
Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: dnssec-query[DNSKEY] dk to 213.80.98.2
Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: dnssec-query[DS] dk to 213.80.98.2
Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: reply dk is BOGUS DS
Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: validation result is BOGUS
This is with dnssec-debug turned on.
I'm not entirely sure how to go about debugging this, but FWIW this
works:
$ dig +dnssec +sigchase mail2.tohojo.dk @213.80.98.2
...snip...
;; WE HAVE MATERIAL, WE NOW DO VALIDATION
;; VERIFYING DS RRset for dk. with DNSKEY:33655: success
;; OK We found DNSKEY (or more) to validate the RRset
;; Ok, find a Trusted Key in the DNSKEY RRset: 19036
;; VERIFYING DNSKEY RRset for . with DNSKEY:19036: success
;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS
Whereas going through the dnsmasq server fails:
$ dig +dnssec +sigchase mail2.tohojo.dk @10.42.8.1
...snip...
;; WE HAVE MATERIAL, WE NOW DO VALIDATION
;; VERIFYING DS RRset for tohojo.dk. with DNSKEY:61294: success
;; OK We found DNSKEY (or more) to validate the RRset
;; Now, we are going to validate this DNSKEY by the DS
;; OK a DS valids a DNSKEY in the RRset
;; Now verify that this DNSKEY validates the DNSKEY RRset
;; VERIFYING DNSKEY RRset for dk. with DNSKEY:26887: success
;; OK this DNSKEY (validated by the DS) validates the RRset of the DNSKEYs, thus the DNSKEY validates the RRset
;; Now, we want to validate the DS : recursive call
Launch a query to find a RRset of type DNSKEY for zone: .
;; DNSKEYset that signs the RRset to chase:
. 0 IN DNSKEY 256 3 8 AwEAAYRU41/8smgAvuSojEP4jaj5Yll7WPaUKpYvnz2pnX2VIvRn4jsy Jns80bloenG6X9ebJVy2CFtZQLKHP8DcKmIFotdgs2HolyocY1am/+33 4RtzusM2ojkhjn1FRGtuSE9s2TSz1ISv0yVnFyu+EP/ZkiWnDfWeVrJI SEWBEr4V
. 0 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=
. 0 IN DNSKEY 256 3 8 AwEAAb8sU6pbYMWRbkRnEuEZw9NSir707TkOcF+UL1XiK4NDJOvXRyX1 95Am5dQ7bRnnuySZ3daf37vvjUUhuIWUAQ4stht8nJfYxVQXDYjSpGH5 I6Hf/0CZEoNP6cNvrQ7AFmKkmv00xWExKQjbvnRPI4bqpMwtHVzn6Wyb BZ6kuqED
Launch a query to find a RRset of type RRSIG for zone: .
;; RRSIG for DNSKEY is missing to continue validation : FAILED
Not really sure what to make of this?
-Toke
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-09 12:09 ` Toke Høiland-Jørgensen
@ 2014-02-09 12:23 ` Simon Kelley
2014-02-09 12:48 ` Toke Høiland-Jørgensen
0 siblings, 1 reply; 36+ messages in thread
From: Simon Kelley @ 2014-02-09 12:23 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: cerowrt-devel
On 09/02/14 12:09, Toke Høiland-Jørgensen wrote:
>
> OK, so I've tried building dnsmasq on cerowrt, from git head. It seems
> to have some trouble validating stuff:
>
> Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: forwarded mail2.tohojo.dk to 213.80.98.2
> Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: dnssec-query[DNSKEY] tohojo.dk to 213.80.98.2
> Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: dnssec-query[DS] tohojo.dk to 213.80.98.2
> Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: dnssec-query[DNSKEY] dk to 213.80.98.2
> Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: dnssec-query[DS] dk to 213.80.98.2
> Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: reply dk is BOGUS DS
> Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: validation result is BOGUS
>
> This is with dnssec-debug turned on.
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.
>
> I'm not entirely sure how to go about debugging this, but FWIW this
> works:
>
> $ dig +dnssec +sigchase mail2.tohojo.dk @213.80.98.2
> ...snip...
> ;; WE HAVE MATERIAL, WE NOW DO VALIDATION
> ;; VERIFYING DS RRset for dk. with DNSKEY:33655: success
> ;; OK We found DNSKEY (or more) to validate the RRset
> ;; Ok, find a Trusted Key in the DNSKEY RRset: 19036
> ;; VERIFYING DNSKEY RRset for . with DNSKEY:19036: success
>
> ;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS
>
>
> Whereas going through the dnsmasq server fails:
> $ dig +dnssec +sigchase mail2.tohojo.dk @10.42.8.1
> ...snip...
> ;; WE HAVE MATERIAL, WE NOW DO VALIDATION
> ;; VERIFYING DS RRset for tohojo.dk. with DNSKEY:61294: success
> ;; OK We found DNSKEY (or more) to validate the RRset
> ;; Now, we are going to validate this DNSKEY by the DS
> ;; OK a DS valids a DNSKEY in the RRset
> ;; Now verify that this DNSKEY validates the DNSKEY RRset
> ;; VERIFYING DNSKEY RRset for dk. with DNSKEY:26887: success
> ;; OK this DNSKEY (validated by the DS) validates the RRset of the DNSKEYs, thus the DNSKEY validates the RRset
> ;; Now, we want to validate the DS : recursive call
>
>
> Launch a query to find a RRset of type DNSKEY for zone: .
>
> ;; DNSKEYset that signs the RRset to chase:
> . 0 IN DNSKEY 256 3 8 AwEAAYRU41/8smgAvuSojEP4jaj5Yll7WPaUKpYvnz2pnX2VIvRn4jsy Jns80bloenG6X9ebJVy2CFtZQLKHP8DcKmIFotdgs2HolyocY1am/+33 4RtzusM2ojkhjn1FRGtuSE9s2TSz1ISv0yVnFyu+EP/ZkiWnDfWeVrJI SEWBEr4V
> . 0 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=
> . 0 IN DNSKEY 256 3 8 AwEAAb8sU6pbYMWRbkRnEuEZw9NSir707TkOcF+UL1XiK4NDJOvXRyX1 95Am5dQ7bRnnuySZ3daf37vvjUUhuIWUAQ4stht8nJfYxVQXDYjSpGH5 I6Hf/0CZEoNP6cNvrQ7AFmKkmv00xWExKQjbvnRPI4bqpMwtHVzn6Wyb BZ6kuqED
>
>
>
> Launch a query to find a RRset of type RRSIG for zone: .
>
> ;; RRSIG for DNSKEY is missing to continue validation : FAILED
>
>
>
> Not really sure what to make of this?
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?
Cheers,
Simon.
>
> -Toke
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-09 12:23 ` Simon Kelley
@ 2014-02-09 12:48 ` Toke Høiland-Jørgensen
2014-02-09 18:04 ` Dave Taht
2014-02-09 20:59 ` Simon Kelley
0 siblings, 2 replies; 36+ messages in thread
From: Toke Høiland-Jørgensen @ 2014-02-09 12:48 UTC (permalink / raw)
To: Simon Kelley; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 4012 bytes --]
Simon Kelley <simon@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?
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?
> 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/
-Toke
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-09 12:48 ` Toke Høiland-Jørgensen
@ 2014-02-09 18:04 ` Dave Taht
2014-02-09 18:47 ` Toke Høiland-Jørgensen
2014-02-09 21:02 ` Simon Kelley
2014-02-09 20:59 ` Simon Kelley
1 sibling, 2 replies; 36+ messages in thread
From: Dave Taht @ 2014-02-09 18:04 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: cerowrt-devel
Got the right time?
I have no idea how to deal with the time headache still, besides adding
an un-validating-resolver to ntpdate, and sanity checks in dnsmasq like
(if system time is < my build time, don't do dnssec) - but the latter
is imperfect.
http://www.bufferbloat.net/issues/113
On Sun, Feb 9, 2014 at 4:48 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Simon Kelley <simon@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?
>
>
>
> 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?
>
>> 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/
>
> -Toke
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-09 18:04 ` Dave Taht
@ 2014-02-09 18:47 ` Toke Høiland-Jørgensen
2014-02-09 21:02 ` Simon Kelley
1 sibling, 0 replies; 36+ messages in thread
From: Toke Høiland-Jørgensen @ 2014-02-09 18:47 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 621 bytes --]
Dave Taht <dave.taht@gmail.com> writes:
> Got the right time?
Yeah, that was my thought as well. Checked that, though; the router does
seem to know what time it is.
> I have no idea how to deal with the time headache still, besides
> adding an un-validating-resolver to ntpdate, and sanity checks in
> dnsmasq like (if system time is < my build time, don't do dnssec) -
> but the latter is imperfect.
>
> http://www.bufferbloat.net/issues/113
So far I've been using the 'screw it' approach and just putting in an
ntp server by IP address for my own private builds. Would love to see
a better solution, though.
-Toke
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-09 18:04 ` Dave Taht
2014-02-09 18:47 ` Toke Høiland-Jørgensen
@ 2014-02-09 21:02 ` Simon Kelley
1 sibling, 0 replies; 36+ messages in thread
From: Simon Kelley @ 2014-02-09 21:02 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
On 09/02/14 18:04, Dave Taht wrote:
> Got the right time?
See my previous reply: the signature inception time for .dk I'm seeing
is quite recent, so there's not much slack to play with.
>
> I have no idea how to deal with the time headache still, besides adding
> an un-validating-resolver to ntpdate, and sanity checks in dnsmasq like
> (if system time is< my build time, don't do dnssec) - but the latter
> is imperfect.
>
> http://www.bufferbloat.net/issues/113
>
Cheers,
Simon.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-09 12:48 ` Toke Høiland-Jørgensen
2014-02-09 18:04 ` Dave Taht
@ 2014-02-09 20:59 ` Simon Kelley
2014-02-09 21:07 ` Dave Taht
2014-02-09 21:33 ` Toke Høiland-Jørgensen
1 sibling, 2 replies; 36+ messages in thread
From: Simon Kelley @ 2014-02-09 20:59 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: cerowrt-devel
On 09/02/14 12:48, Toke Høiland-Jørgensen wrote:
> Simon Kelley<simon@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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-09 20:59 ` Simon Kelley
@ 2014-02-09 21:07 ` Dave Taht
2014-02-09 21:16 ` Toke Høiland-Jørgensen
2014-02-09 21:33 ` Toke Høiland-Jørgensen
1 sibling, 1 reply; 36+ messages in thread
From: Dave Taht @ 2014-02-09 21:07 UTC (permalink / raw)
To: Simon Kelley; +Cc: cerowrt-devel
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@thekelleys.org.uk> wrote:
> On 09/02/14 12:48, Toke Høiland-Jørgensen wrote:
>>
>> Simon Kelley<simon@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-09 20:59 ` Simon Kelley
2014-02-09 21:07 ` Dave Taht
@ 2014-02-09 21:33 ` Toke Høiland-Jørgensen
2014-02-10 10:50 ` Simon Kelley
2014-02-10 11:39 ` Simon Kelley
1 sibling, 2 replies; 36+ messages in thread
From: Toke Høiland-Jørgensen @ 2014-02-09 21:33 UTC (permalink / raw)
To: Simon Kelley; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 2744 bytes --]
Simon Kelley <simon@thekelleys.org.uk> writes:
> 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?
The packages I've built are here:
http://archive.tohojo.dk/cerowrt/wndr/3.10.28-4-tohojo/packages/
They're packaged as libhogweed, libnettle, libgmp and dnsmasq-dhcpv6 --
dunno if they're installable without further ado on your box. But if so
you should be able to just download those four package files onto your
router (stick them in /tmp to avoid running out of flash) and calling
opkg to install them...
> 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_?
Double-checked the time, and yes, it is recent, including date. Reran
the queries, and dnsmasq still complains.
>
> Please clould you post the result of running
>
> dig @213.80.98.2 +dnssec ds dk
Seems to be the same:
;; ANSWER SECTION:
dk. 70561 IN DS 26887 8 2 A1AB8546B80E438A7DFE0EC559A7088EC5AED3C4E0D26B1B60ED3735 F853DFD7
dk. 70561 IN RRSIG DS 8 1 86400 20140216000000 20140208230000 33655 . MAKi0fADKyqZ3aQilK7pgilLZvZz7sYKjZsw4FVff/9RNEECtZf9FpbI CD76X860kq6Ctf+zTKH5xvev44hYsER+0IVmN2YiMeMrFlGALIhZVOXN f+MN2cUtIolOb518/lQXBMdmlYyC1Lo7GPTICIJ2w82poTTPRai3q/S9 2Qc=
Also, running it against the dnsmasq instance gives no output; dnsmasq
complains in the logs that validation failed. I.e:
$ dig @10.42.8.1 +dnssec ds dk
; <<>> DiG 9.9.2-P2 <<>> @10.42.8.1 +dnssec ds dk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53752
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dk. IN DS
;; Query time: 51 msec
;; SERVER: 10.42.8.1#53(10.42.8.1)
;; WHEN: Sun Feb 9 22:30:52 2014
;; MSG SIZE rcvd: 31
> 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.
Ah, right. Well it does try it without appending the domain first, so I
guess ndots is right (my man page says it defaults to 1). However, when
it fails (due to dnssec errors), it is retried with the domain appended;
which I thought was strange...
> 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.
Well if you want to support clients tracing the dnssec results I guess
not? :)
-Toke
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-09 21:33 ` Toke Høiland-Jørgensen
@ 2014-02-10 10:50 ` Simon Kelley
2014-02-10 11:39 ` Simon Kelley
1 sibling, 0 replies; 36+ messages in thread
From: Simon Kelley @ 2014-02-10 10:50 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: cerowrt-devel
On 09/02/14 21:33, Toke Høiland-Jørgensen wrote:
> Simon Kelley<simon@thekelleys.org.uk> writes:
>
>> 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?
>
> The packages I've built are here:
> http://archive.tohojo.dk/cerowrt/wndr/3.10.28-4-tohojo/packages/
>
> They're packaged as libhogweed, libnettle, libgmp and dnsmasq-dhcpv6 --
> dunno if they're installable without further ado on your box. But if so
> you should be able to just download those four package files onto your
> router (stick them in /tmp to avoid running out of flash) and calling
> opkg to install them...
>
>> 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_?
>
> Double-checked the time, and yes, it is recent, including date. Reran
> the queries, and dnsmasq still complains.
>
>>
>> Please clould you post the result of running
>>
>> dig @213.80.98.2 +dnssec ds dk
>
> Seems to be the same:
>
> ;; ANSWER SECTION:
> dk. 70561 IN DS 26887 8 2 A1AB8546B80E438A7DFE0EC559A7088EC5AED3C4E0D26B1B60ED3735 F853DFD7
> dk. 70561 IN RRSIG DS 8 1 86400 20140216000000 20140208230000 33655 . MAKi0fADKyqZ3aQilK7pgilLZvZz7sYKjZsw4FVff/9RNEECtZf9FpbI CD76X860kq6Ctf+zTKH5xvev44hYsER+0IVmN2YiMeMrFlGALIhZVOXN f+MN2cUtIolOb518/lQXBMdmlYyC1Lo7GPTICIJ2w82poTTPRai3q/S9 2Qc=
>
> Also, running it against the dnsmasq instance gives no output; dnsmasq
> complains in the logs that validation failed. I.e:
> $ dig @10.42.8.1 +dnssec ds dk
>
> ;<<>> DiG 9.9.2-P2<<>> @10.42.8.1 +dnssec ds dk
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53752
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;dk. IN DS
>
> ;; Query time: 51 msec
> ;; SERVER: 10.42.8.1#53(10.42.8.1)
> ;; WHEN: Sun Feb 9 22:30:52 2014
> ;; MSG SIZE rcvd: 31
>
>
OK. One more question is this a general failure with all TLDS failing,
or is it limited to .dk?
I'll fire up the 3800 and see what I can find.......
>
>> 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.
>
> Ah, right. Well it does try it without appending the domain first, so I
> guess ndots is right (my man page says it defaults to 1). However, when
> it fails (due to dnssec errors), it is retried with the domain appended;
> which I thought was strange...
>
>> 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.
>
> Well if you want to support clients tracing the dnssec results I guess
> not? :)
I've just pushed a fix into git that should sort this one.
Cheers,
Simon.
>
> -Toke
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-09 21:33 ` Toke Høiland-Jørgensen
2014-02-10 10:50 ` Simon Kelley
@ 2014-02-10 11:39 ` Simon Kelley
2014-02-10 12:59 ` Toke Høiland-Jørgensen
1 sibling, 1 reply; 36+ messages in thread
From: Simon Kelley @ 2014-02-10 11:39 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: cerowrt-devel
On 09/02/14 21:33, Toke Høiland-Jørgensen wrote:
> Simon Kelley<simon@thekelleys.org.uk> writes:
>
>> 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?
>
> The packages I've built are here:
> http://archive.tohojo.dk/cerowrt/wndr/3.10.28-4-tohojo/packages/
>
> They're packaged as libhogweed, libnettle, libgmp and dnsmasq-dhcpv6 --
> dunno if they're installable without further ado on your box. But if so
> you should be able to just download those four package files onto your
> router (stick them in /tmp to avoid running out of flash) and calling
> opkg to install them...
Great, thanks. I've done that and confirmed what you are seeing. At this
point I need to trace through the whole validation process in parallel
on working and broken platforms, to see where the two diverge.
(I've had to do this before. It was not fun, but it did produce
results.) I've installed gdb and can run dnsmasq under gdb, but the
binary is very thoroughly stripped, so I can't get any useful
information out. Best way to get a non-stripped dnsmasq binary on there?
Cheers,
Simon.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-10 11:39 ` Simon Kelley
@ 2014-02-10 12:59 ` Toke Høiland-Jørgensen
2014-02-10 16:45 ` Simon Kelley
0 siblings, 1 reply; 36+ messages in thread
From: Toke Høiland-Jørgensen @ 2014-02-10 12:59 UTC (permalink / raw)
To: Simon Kelley; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 641 bytes --]
Simon Kelley <simon@thekelleys.org.uk> writes:
> Great, thanks. I've done that and confirmed what you are seeing. At this point I
> need to trace through the whole validation process in parallel on working and
> broken platforms, to see where the two diverge.
> (I've had to do this before. It was not fun, but it did produce results.) I've
> installed gdb and can run dnsmasq under gdb, but the binary is very thoroughly
> stripped, so I can't get any useful information out. Best way to get a
> non-stripped dnsmasq binary on there?
I've rebuilt the packages non-stripped; same links as before (warning,
they're quite big now) :)
-Toke
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-10 12:59 ` Toke Høiland-Jørgensen
@ 2014-02-10 16:45 ` Simon Kelley
2014-02-10 16:59 ` Toke Høiland-Jørgensen
0 siblings, 1 reply; 36+ messages in thread
From: Simon Kelley @ 2014-02-10 16:45 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: cerowrt-devel
On 10/02/14 12:59, Toke Høiland-Jørgensen wrote:
> Simon Kelley<simon@thekelleys.org.uk> writes:
>
>> Great, thanks. I've done that and confirmed what you are seeing. At this point I
>> need to trace through the whole validation process in parallel on working and
>> broken platforms, to see where the two diverge.
>> (I've had to do this before. It was not fun, but it did produce results.) I've
>> installed gdb and can run dnsmasq under gdb, but the binary is very thoroughly
>> stripped, so I can't get any useful information out. Best way to get a
>> non-stripped dnsmasq binary on there?
>
> I've rebuilt the packages non-stripped; same links as before (warning,
> they're quite big now) :)
>
OK. Fix (I think), in git now. Please could you test? (A byte-order
problem, inevitably).
Cheers,
Simon.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-10 16:45 ` Simon Kelley
@ 2014-02-10 16:59 ` Toke Høiland-Jørgensen
2014-02-10 17:12 ` Simon Kelley
` (2 more replies)
0 siblings, 3 replies; 36+ messages in thread
From: Toke Høiland-Jørgensen @ 2014-02-10 16:59 UTC (permalink / raw)
To: Simon Kelley; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 8651 bytes --]
Simon Kelley <simon@thekelleys.org.uk> writes:
> OK. Fix (I think), in git now. Please could you test? (A byte-order problem,
> inevitably).
Yay, seems to work:
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: query[A] files.toke.dk from 10.42.0.7
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: forwarded files.toke.dk to 213.80.98.3
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: forwarded files.toke.dk to 213.80.98.2
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DNSKEY] toke.dk to 213.80.98.2
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DS] toke.dk to 213.80.98.2
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DNSKEY] dk to 213.80.98.2
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DS] dk to 213.80.98.2
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DS keytag 26887
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DNSKEY keytag 26887
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DNSKEY keytag 7665
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DNSKEY keytag 61294
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DNSKEY keytag 31369
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply toke.dk is DS keytag 65122
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply toke.dk is DNSKEY keytag 65122
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply toke.dk is DNSKEY keytag 22551
Mon Feb 10 17:55:47 2014 daemon.err dnsmasq[11296]: Unexpected missing data for DNSSEC validation
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: validation result is INSECURE
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply files.toke.dk is <CNAME>
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply web2.tohojo.dk is 144.76.141.113
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: query[AAAA] files.toke.dk from 10.42.0.7
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: cached files.toke.dk is <CNAME>
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: forwarded files.toke.dk to 213.80.98.2
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DNSKEY] tohojo.dk to 213.80.98.2
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DS] tohojo.dk to 213.80.98.2
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply tohojo.dk is DS keytag 49471
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply tohojo.dk is DNSKEY keytag 49471
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply tohojo.dk is DNSKEY keytag 30141
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: validation result is SECURE
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply files.toke.dk is <CNAME>
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply web2.tohojo.dk is 2a01:4f8:200:3141::102
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: query[MX] files.toke.dk from 10.42.0.7
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: forwarded files.toke.dk to 213.80.98.2
Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: validation result is SECURE
Dunno why it starts out insecure (?), but seems to get to the right
place.
Can also do sigchase:
$ dig +sigchase files.toke.dk @10.42.0.8
...snip...
Launch a query to find a RRset of type DS for zone: .
;; NO ANSWERS: no more
;; WARNING There is no DS for the zone: .
;; WE HAVE MATERIAL, WE NOW DO VALIDATION
;; VERIFYING DS RRset for dk. with DNSKEY:33655: success
;; OK We found DNSKEY (or more) to validate the RRset
;; Ok, find a Trusted Key in the DNSKEY RRset: 19036
;; VERIFYING DNSKEY RRset for . with DNSKEY:19036: success
;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS
But not +trace:
$ dig +trace +sigchase files.toke.dk @10.42.0.8
; <<>> DiG 9.9.2-P2 <<>> +trace +sigchase files.toke.dk @10.42.0.8
;; global options: +cmd
. 86891 IN NS d.root-servers.net.
. 86891 IN NS l.root-servers.net.
. 86891 IN NS h.root-servers.net.
. 86891 IN NS j.root-servers.net.
. 86891 IN NS b.root-servers.net.
. 86891 IN NS m.root-servers.net.
. 86891 IN NS k.root-servers.net.
. 86891 IN NS f.root-servers.net.
. 86891 IN NS e.root-servers.net.
. 86891 IN NS g.root-servers.net.
. 86891 IN NS a.root-servers.net.
. 86891 IN NS c.root-servers.net.
. 86891 IN NS i.root-servers.net.
. 325955 IN RRSIG NS 8 0 518400 20140215000000 20140207230000 33655 . cZOSrkiewfX+HdA2covOiYL+Z8xgBoCpJm4VZq083M51CvIFBipG1/BO JYYiRzmpQJN/l6FI5RBKmDVFq/RqkVineoIYrsIZL9RRcAF+phPO+kHU YU3ckdHZroDZCu1QUPd+Kr6Y8+9GBH8wYM++0Z6tLRA+iZXbNOadfZ9o euU=
dk. 172800 IN NS l.nic.dk.
dk. 172800 IN NS p.nic.dk.
dk. 172800 IN NS s.nic.dk.
dk. 172800 IN NS b.nic.dk.
dk. 172800 IN NS c.nic.dk.
dk. 172800 IN NS a.nic.dk.
dk. 86400 IN DS 26887 8 2 A1AB8546B80E438A7DFE0EC559A7088EC5AED3C4E0D26B1B60ED3735 F853DFD7
dk. 86400 IN RRSIG DS 8 1 86400 20140217000000 20140209230000 33655 . aK1OgJzktVeo2i83KdOig62wyqkxcQmbbQePi4T7zI4OhPzI5LMz9kbS W/V7bOgNBfYBjDJg4JEYIAC0esCrGPtbAsKQ7YrKiZikNAhlD/BgTvtD JQJxc+7f4xUa6Y7/9DBKmG8Du+DftF99RngT/hCgr9hZme9YkvtGaEyo CZI=
toke.dk. 86400 IN NS ns2.gratisdns.dk.
toke.dk. 86400 IN NS ns1.gratisdns.dk.
toke.dk. 86400 IN NS ns4.gratisdns.dk.
toke.dk. 86400 IN NS ns5.gratisdns.dk.
toke.dk. 86400 IN NS ns3.gratisdns.dk.
toke.dk. 86400 IN DS 65122 5 1 A6FEBBA66365D55C97F8671688AD52883AB582A6
toke.dk. 86400 IN RRSIG DS 8 2 86400 20140308183226 20140208200232 61294 dk. thrq3zR+toPNxDln/H/qWBJbjkNK8/NosI6oriQBPXzzcd6HzOdg7l67 kbmje94nwOysKIMCz/YiNjmnEfa7X0NorTZ+e3HOyTRG+NpyQoywgxvj TAFDGuu8hsussW+ohheb0efhX4/0YSamSsSBeAImPYWTdUQY10U0sXDq BCE=
files.toke.dk. 43200 IN CNAME web2.tohojo.dk.
files.toke.dk. 43200 IN RRSIG CNAME 5 3 43200 20140311112400 20140209112400 22551 toke.dk. ObiMhHqVUSxsje4979EzuiDoCt7z1r1Gl946gmY9ZDe7Es+7jg1l7m8/ vyVhPDRxqNxEAsTmFXF6mkwKkK60ag==
;; RRset to chase:
files.toke.dk. 43200 IN CNAME web2.tohojo.dk.
;; RRSIG of the RRset to chase:
files.toke.dk. 43200 IN RRSIG CNAME 5 3 43200 20140311112400 20140209112400 22551 toke.dk. ObiMhHqVUSxsje4979EzuiDoCt7z1r1Gl946gmY9ZDe7Es+7jg1l7m8/ vyVhPDRxqNxEAsTmFXF6mkwKkK60ag==
Launch a query to find a RRset of type DNSKEY for zone: toke.dk.
toke.dk. 43200 IN DNSKEY 256 3 5 AwEAAaYKHaUARHUtPhVTEC6vTc0SR142BVj1P/wtgCjacCkGDN5wB6Cm Y0xEwUl+NuT9btz0xQmDGOMJEKunK+HpOh0=
toke.dk. 43200 IN DNSKEY 257 3 5 AwEAAdV59e0KX1JymujkIbzikKCEVSExW3ixJ81hiboCHSvZv+LlMxlG sWT6uJrcEOENF+fZnDcl3u0WRgd3ctv9d40=
toke.dk. 43200 IN RRSIG DNSKEY 5 2 43200 20140311112400 20140209112400 22551 toke.dk. CzZARTabg0VR00Ksv0Uz+qRqRvl06fTTZHa0k17Ccg7JdrvsnZ5DgJKy dhM7j3Rb4LHfZbcoTXXABICCvSQnoQ==
toke.dk. 43200 IN RRSIG DNSKEY 5 2 43200 20140311112400 20140209112400 65122 toke.dk. Q9OqTdh4s3aGn9ExkTnYwPk8j+V9cTjEjLGXD8zY5l0HewORrqJT5Ebn R0YvK/xH/2XLnueAZ/q8khlSfjhFzA==
;; DNSKEYset that signs the RRset to chase:
toke.dk. 43200 IN DNSKEY 256 3 5 AwEAAaYKHaUARHUtPhVTEC6vTc0SR142BVj1P/wtgCjacCkGDN5wB6Cm Y0xEwUl+NuT9btz0xQmDGOMJEKunK+HpOh0=
toke.dk. 43200 IN DNSKEY 257 3 5 AwEAAdV59e0KX1JymujkIbzikKCEVSExW3ixJ81hiboCHSvZv+LlMxlG sWT6uJrcEOENF+fZnDcl3u0WRgd3ctv9d40=
;; RRSIG of the DNSKEYset that signs the RRset to chase:
toke.dk. 43200 IN RRSIG DNSKEY 5 2 43200 20140311112400 20140209112400 22551 toke.dk. CzZARTabg0VR00Ksv0Uz+qRqRvl06fTTZHa0k17Ccg7JdrvsnZ5DgJKy dhM7j3Rb4LHfZbcoTXXABICCvSQnoQ==
toke.dk. 43200 IN RRSIG DNSKEY 5 2 43200 20140311112400 20140209112400 65122 toke.dk. Q9OqTdh4s3aGn9ExkTnYwPk8j+V9cTjEjLGXD8zY5l0HewORrqJT5Ebn R0YvK/xH/2XLnueAZ/q8khlSfjhFzA==
;; DSset of the DNSKEYset
toke.dk. 86400 IN DS 65122 5 1 A6FEBBA66365D55C97F8671688AD52883AB582A6
;; RRSIG of the DSset of the DNSKEYset
toke.dk. 86400 IN RRSIG DS 8 2 86400 20140308183226 20140208200232 61294 dk. thrq3zR+toPNxDln/H/qWBJbjkNK8/NosI6oriQBPXzzcd6HzOdg7l67 kbmje94nwOysKIMCz/YiNjmnEfa7X0NorTZ+e3HOyTRG+NpyQoywgxvj TAFDGuu8hsussW+ohheb0efhX4/0YSamSsSBeAImPYWTdUQY10U0sXDq BCE=
;; WE HAVE MATERIAL, WE NOW DO VALIDATION
;; VERIFYING CNAME RRset for files.toke.dk. with DNSKEY:22551: success
;; OK We found DNSKEY (or more) to validate the RRset
;; Now, we are going to validate this DNSKEY by the DS
;; OK a DS valids a DNSKEY in the RRset
;; Now verify that this DNSKEY validates the DNSKEY RRset
;; VERIFYING DNSKEY RRset for toke.dk. with DNSKEY:65122: success
;; OK this DNSKEY (validated by the DS) validates the RRset of the DNSKEYs, thus the DNSKEY validates the RRset
;; Now, we want to validate the DS : recursive call
Launch a query to find a RRset of type DNSKEY for zone: dk.
;; NO ANSWERS: no more
;; DNSKEY is missing to continue validation: FAILED
-Toke
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-10 16:59 ` Toke Høiland-Jørgensen
@ 2014-02-10 17:12 ` Simon Kelley
2014-02-10 17:14 ` Dave Taht
2014-02-11 11:34 ` Simon Kelley
2 siblings, 0 replies; 36+ messages in thread
From: Simon Kelley @ 2014-02-10 17:12 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: cerowrt-devel
On 10/02/14 16:59, Toke Høiland-Jørgensen wrote:
> Simon Kelley<simon@thekelleys.org.uk> writes:
>
>> OK. Fix (I think), in git now. Please could you test? (A byte-order problem,
>> inevitably).
>
> Yay, seems to work:
>
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: query[A] files.toke.dk from 10.42.0.7
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: forwarded files.toke.dk to 213.80.98.3
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: forwarded files.toke.dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DNSKEY] toke.dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DS] toke.dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DNSKEY] dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DS] dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DS keytag 26887
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DNSKEY keytag 26887
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DNSKEY keytag 7665
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DNSKEY keytag 61294
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DNSKEY keytag 31369
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply toke.dk is DS keytag 65122
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply toke.dk is DNSKEY keytag 65122
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply toke.dk is DNSKEY keytag 22551
> Mon Feb 10 17:55:47 2014 daemon.err dnsmasq[11296]: Unexpected missing data for DNSSEC validation
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: validation result is INSECURE
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply files.toke.dk is<CNAME>
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply web2.tohojo.dk is 144.76.141.113
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: query[AAAA] files.toke.dk from 10.42.0.7
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: cached files.toke.dk is<CNAME>
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: forwarded files.toke.dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DNSKEY] tohojo.dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DS] tohojo.dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply tohojo.dk is DS keytag 49471
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply tohojo.dk is DNSKEY keytag 49471
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply tohojo.dk is DNSKEY keytag 30141
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: validation result is SECURE
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply files.toke.dk is<CNAME>
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply web2.tohojo.dk is 2a01:4f8:200:3141::102
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: query[MX] files.toke.dk from 10.42.0.7
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: forwarded files.toke.dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: validation result is SECURE
>
>
> Dunno why it starts out insecure (?), but seems to get to the right
> place.
I do. It's not a platform specific problem, and requires me to go away
and do some more thinking.....
Later.
Simon.
>
> Can also do sigchase:
>
> $ dig +sigchase files.toke.dk @10.42.0.8
> ...snip...
>
>
> Launch a query to find a RRset of type DS for zone: .
> ;; NO ANSWERS: no more
>
> ;; WARNING There is no DS for the zone: .
>
>
>
> ;; WE HAVE MATERIAL, WE NOW DO VALIDATION
> ;; VERIFYING DS RRset for dk. with DNSKEY:33655: success
> ;; OK We found DNSKEY (or more) to validate the RRset
> ;; Ok, find a Trusted Key in the DNSKEY RRset: 19036
> ;; VERIFYING DNSKEY RRset for . with DNSKEY:19036: success
>
> ;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS
>
>
>
> But not +trace:
>
> $ dig +trace +sigchase files.toke.dk @10.42.0.8
>
> ;<<>> DiG 9.9.2-P2<<>> +trace +sigchase files.toke.dk @10.42.0.8
> ;; global options: +cmd
> . 86891 IN NS d.root-servers.net.
> . 86891 IN NS l.root-servers.net.
> . 86891 IN NS h.root-servers.net.
> . 86891 IN NS j.root-servers.net.
> . 86891 IN NS b.root-servers.net.
> . 86891 IN NS m.root-servers.net.
> . 86891 IN NS k.root-servers.net.
> . 86891 IN NS f.root-servers.net.
> . 86891 IN NS e.root-servers.net.
> . 86891 IN NS g.root-servers.net.
> . 86891 IN NS a.root-servers.net.
> . 86891 IN NS c.root-servers.net.
> . 86891 IN NS i.root-servers.net.
> . 325955 IN RRSIG NS 8 0 518400 20140215000000 20140207230000 33655 . cZOSrkiewfX+HdA2covOiYL+Z8xgBoCpJm4VZq083M51CvIFBipG1/BO JYYiRzmpQJN/l6FI5RBKmDVFq/RqkVineoIYrsIZL9RRcAF+phPO+kHU YU3ckdHZroDZCu1QUPd+Kr6Y8+9GBH8wYM++0Z6tLRA+iZXbNOadfZ9o euU=
> dk. 172800 IN NS l.nic.dk.
> dk. 172800 IN NS p.nic.dk.
> dk. 172800 IN NS s.nic.dk.
> dk. 172800 IN NS b.nic.dk.
> dk. 172800 IN NS c.nic.dk.
> dk. 172800 IN NS a.nic.dk.
> dk. 86400 IN DS 26887 8 2 A1AB8546B80E438A7DFE0EC559A7088EC5AED3C4E0D26B1B60ED3735 F853DFD7
> dk. 86400 IN RRSIG DS 8 1 86400 20140217000000 20140209230000 33655 . aK1OgJzktVeo2i83KdOig62wyqkxcQmbbQePi4T7zI4OhPzI5LMz9kbS W/V7bOgNBfYBjDJg4JEYIAC0esCrGPtbAsKQ7YrKiZikNAhlD/BgTvtD JQJxc+7f4xUa6Y7/9DBKmG8Du+DftF99RngT/hCgr9hZme9YkvtGaEyo CZI=
> toke.dk. 86400 IN NS ns2.gratisdns.dk.
> toke.dk. 86400 IN NS ns1.gratisdns.dk.
> toke.dk. 86400 IN NS ns4.gratisdns.dk.
> toke.dk. 86400 IN NS ns5.gratisdns.dk.
> toke.dk. 86400 IN NS ns3.gratisdns.dk.
> toke.dk. 86400 IN DS 65122 5 1 A6FEBBA66365D55C97F8671688AD52883AB582A6
> toke.dk. 86400 IN RRSIG DS 8 2 86400 20140308183226 20140208200232 61294 dk. thrq3zR+toPNxDln/H/qWBJbjkNK8/NosI6oriQBPXzzcd6HzOdg7l67 kbmje94nwOysKIMCz/YiNjmnEfa7X0NorTZ+e3HOyTRG+NpyQoywgxvj TAFDGuu8hsussW+ohheb0efhX4/0YSamSsSBeAImPYWTdUQY10U0sXDq BCE=
> files.toke.dk. 43200 IN CNAME web2.tohojo.dk.
> files.toke.dk. 43200 IN RRSIG CNAME 5 3 43200 20140311112400 20140209112400 22551 toke.dk. ObiMhHqVUSxsje4979EzuiDoCt7z1r1Gl946gmY9ZDe7Es+7jg1l7m8/ vyVhPDRxqNxEAsTmFXF6mkwKkK60ag==
> ;; RRset to chase:
> files.toke.dk. 43200 IN CNAME web2.tohojo.dk.
>
>
> ;; RRSIG of the RRset to chase:
> files.toke.dk. 43200 IN RRSIG CNAME 5 3 43200 20140311112400 20140209112400 22551 toke.dk. ObiMhHqVUSxsje4979EzuiDoCt7z1r1Gl946gmY9ZDe7Es+7jg1l7m8/ vyVhPDRxqNxEAsTmFXF6mkwKkK60ag==
>
>
>
> Launch a query to find a RRset of type DNSKEY for zone: toke.dk.
> toke.dk. 43200 IN DNSKEY 256 3 5 AwEAAaYKHaUARHUtPhVTEC6vTc0SR142BVj1P/wtgCjacCkGDN5wB6Cm Y0xEwUl+NuT9btz0xQmDGOMJEKunK+HpOh0=
> toke.dk. 43200 IN DNSKEY 257 3 5 AwEAAdV59e0KX1JymujkIbzikKCEVSExW3ixJ81hiboCHSvZv+LlMxlG sWT6uJrcEOENF+fZnDcl3u0WRgd3ctv9d40=
> toke.dk. 43200 IN RRSIG DNSKEY 5 2 43200 20140311112400 20140209112400 22551 toke.dk. CzZARTabg0VR00Ksv0Uz+qRqRvl06fTTZHa0k17Ccg7JdrvsnZ5DgJKy dhM7j3Rb4LHfZbcoTXXABICCvSQnoQ==
> toke.dk. 43200 IN RRSIG DNSKEY 5 2 43200 20140311112400 20140209112400 65122 toke.dk. Q9OqTdh4s3aGn9ExkTnYwPk8j+V9cTjEjLGXD8zY5l0HewORrqJT5Ebn R0YvK/xH/2XLnueAZ/q8khlSfjhFzA==
>
> ;; DNSKEYset that signs the RRset to chase:
> toke.dk. 43200 IN DNSKEY 256 3 5 AwEAAaYKHaUARHUtPhVTEC6vTc0SR142BVj1P/wtgCjacCkGDN5wB6Cm Y0xEwUl+NuT9btz0xQmDGOMJEKunK+HpOh0=
> toke.dk. 43200 IN DNSKEY 257 3 5 AwEAAdV59e0KX1JymujkIbzikKCEVSExW3ixJ81hiboCHSvZv+LlMxlG sWT6uJrcEOENF+fZnDcl3u0WRgd3ctv9d40=
>
>
> ;; RRSIG of the DNSKEYset that signs the RRset to chase:
> toke.dk. 43200 IN RRSIG DNSKEY 5 2 43200 20140311112400 20140209112400 22551 toke.dk. CzZARTabg0VR00Ksv0Uz+qRqRvl06fTTZHa0k17Ccg7JdrvsnZ5DgJKy dhM7j3Rb4LHfZbcoTXXABICCvSQnoQ==
> toke.dk. 43200 IN RRSIG DNSKEY 5 2 43200 20140311112400 20140209112400 65122 toke.dk. Q9OqTdh4s3aGn9ExkTnYwPk8j+V9cTjEjLGXD8zY5l0HewORrqJT5Ebn R0YvK/xH/2XLnueAZ/q8khlSfjhFzA==
>
>
> ;; DSset of the DNSKEYset
> toke.dk. 86400 IN DS 65122 5 1 A6FEBBA66365D55C97F8671688AD52883AB582A6
>
>
> ;; RRSIG of the DSset of the DNSKEYset
> toke.dk. 86400 IN RRSIG DS 8 2 86400 20140308183226 20140208200232 61294 dk. thrq3zR+toPNxDln/H/qWBJbjkNK8/NosI6oriQBPXzzcd6HzOdg7l67 kbmje94nwOysKIMCz/YiNjmnEfa7X0NorTZ+e3HOyTRG+NpyQoywgxvj TAFDGuu8hsussW+ohheb0efhX4/0YSamSsSBeAImPYWTdUQY10U0sXDq BCE=
>
>
>
>
> ;; WE HAVE MATERIAL, WE NOW DO VALIDATION
> ;; VERIFYING CNAME RRset for files.toke.dk. with DNSKEY:22551: success
> ;; OK We found DNSKEY (or more) to validate the RRset
> ;; Now, we are going to validate this DNSKEY by the DS
> ;; OK a DS valids a DNSKEY in the RRset
> ;; Now verify that this DNSKEY validates the DNSKEY RRset
> ;; VERIFYING DNSKEY RRset for toke.dk. with DNSKEY:65122: success
> ;; OK this DNSKEY (validated by the DS) validates the RRset of the DNSKEYs, thus the DNSKEY validates the RRset
> ;; Now, we want to validate the DS : recursive call
>
>
> Launch a query to find a RRset of type DNSKEY for zone: dk.
> ;; NO ANSWERS: no more
>
> ;; DNSKEY is missing to continue validation: FAILED
>
>
> -Toke
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-10 16:59 ` Toke Høiland-Jørgensen
2014-02-10 17:12 ` Simon Kelley
@ 2014-02-10 17:14 ` Dave Taht
2014-02-10 21:47 ` Simon Kelley
2014-02-11 11:34 ` Simon Kelley
2 siblings, 1 reply; 36+ messages in thread
From: Dave Taht @ 2014-02-10 17:14 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: cerowrt-devel
Yea! I am under the impression that still missing functionality is nsec3?
Is the local-to-dnsmasq domain signable?
On Mon, Feb 10, 2014 at 8:59 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Simon Kelley <simon@thekelleys.org.uk> writes:
>
>> OK. Fix (I think), in git now. Please could you test? (A byte-order problem,
>> inevitably).
>
> Yay, seems to work:
>
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: query[A] files.toke.dk from 10.42.0.7
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: forwarded files.toke.dk to 213.80.98.3
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: forwarded files.toke.dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DNSKEY] toke.dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DS] toke.dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DNSKEY] dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DS] dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DS keytag 26887
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DNSKEY keytag 26887
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DNSKEY keytag 7665
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DNSKEY keytag 61294
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DNSKEY keytag 31369
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply toke.dk is DS keytag 65122
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply toke.dk is DNSKEY keytag 65122
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply toke.dk is DNSKEY keytag 22551
> Mon Feb 10 17:55:47 2014 daemon.err dnsmasq[11296]: Unexpected missing data for DNSSEC validation
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: validation result is INSECURE
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply files.toke.dk is <CNAME>
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply web2.tohojo.dk is 144.76.141.113
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: query[AAAA] files.toke.dk from 10.42.0.7
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: cached files.toke.dk is <CNAME>
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: forwarded files.toke.dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DNSKEY] tohojo.dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DS] tohojo.dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply tohojo.dk is DS keytag 49471
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply tohojo.dk is DNSKEY keytag 49471
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply tohojo.dk is DNSKEY keytag 30141
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: validation result is SECURE
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply files.toke.dk is <CNAME>
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply web2.tohojo.dk is 2a01:4f8:200:3141::102
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: query[MX] files.toke.dk from 10.42.0.7
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: forwarded files.toke.dk to 213.80.98.2
> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: validation result is SECURE
>
>
> Dunno why it starts out insecure (?), but seems to get to the right
> place.
>
> Can also do sigchase:
>
> $ dig +sigchase files.toke.dk @10.42.0.8
> ...snip...
>
>
> Launch a query to find a RRset of type DS for zone: .
> ;; NO ANSWERS: no more
>
> ;; WARNING There is no DS for the zone: .
>
>
>
> ;; WE HAVE MATERIAL, WE NOW DO VALIDATION
> ;; VERIFYING DS RRset for dk. with DNSKEY:33655: success
> ;; OK We found DNSKEY (or more) to validate the RRset
> ;; Ok, find a Trusted Key in the DNSKEY RRset: 19036
> ;; VERIFYING DNSKEY RRset for . with DNSKEY:19036: success
>
> ;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS
>
>
>
> But not +trace:
>
> $ dig +trace +sigchase files.toke.dk @10.42.0.8
>
> ; <<>> DiG 9.9.2-P2 <<>> +trace +sigchase files.toke.dk @10.42.0.8
> ;; global options: +cmd
> . 86891 IN NS d.root-servers.net.
> . 86891 IN NS l.root-servers.net.
> . 86891 IN NS h.root-servers.net.
> . 86891 IN NS j.root-servers.net.
> . 86891 IN NS b.root-servers.net.
> . 86891 IN NS m.root-servers.net.
> . 86891 IN NS k.root-servers.net.
> . 86891 IN NS f.root-servers.net.
> . 86891 IN NS e.root-servers.net.
> . 86891 IN NS g.root-servers.net.
> . 86891 IN NS a.root-servers.net.
> . 86891 IN NS c.root-servers.net.
> . 86891 IN NS i.root-servers.net.
> . 325955 IN RRSIG NS 8 0 518400 20140215000000 20140207230000 33655 . cZOSrkiewfX+HdA2covOiYL+Z8xgBoCpJm4VZq083M51CvIFBipG1/BO JYYiRzmpQJN/l6FI5RBKmDVFq/RqkVineoIYrsIZL9RRcAF+phPO+kHU YU3ckdHZroDZCu1QUPd+Kr6Y8+9GBH8wYM++0Z6tLRA+iZXbNOadfZ9o euU=
> dk. 172800 IN NS l.nic.dk.
> dk. 172800 IN NS p.nic.dk.
> dk. 172800 IN NS s.nic.dk.
> dk. 172800 IN NS b.nic.dk.
> dk. 172800 IN NS c.nic.dk.
> dk. 172800 IN NS a.nic.dk.
> dk. 86400 IN DS 26887 8 2 A1AB8546B80E438A7DFE0EC559A7088EC5AED3C4E0D26B1B60ED3735 F853DFD7
> dk. 86400 IN RRSIG DS 8 1 86400 20140217000000 20140209230000 33655 . aK1OgJzktVeo2i83KdOig62wyqkxcQmbbQePi4T7zI4OhPzI5LMz9kbS W/V7bOgNBfYBjDJg4JEYIAC0esCrGPtbAsKQ7YrKiZikNAhlD/BgTvtD JQJxc+7f4xUa6Y7/9DBKmG8Du+DftF99RngT/hCgr9hZme9YkvtGaEyo CZI=
> toke.dk. 86400 IN NS ns2.gratisdns.dk.
> toke.dk. 86400 IN NS ns1.gratisdns.dk.
> toke.dk. 86400 IN NS ns4.gratisdns.dk.
> toke.dk. 86400 IN NS ns5.gratisdns.dk.
> toke.dk. 86400 IN NS ns3.gratisdns.dk.
> toke.dk. 86400 IN DS 65122 5 1 A6FEBBA66365D55C97F8671688AD52883AB582A6
> toke.dk. 86400 IN RRSIG DS 8 2 86400 20140308183226 20140208200232 61294 dk. thrq3zR+toPNxDln/H/qWBJbjkNK8/NosI6oriQBPXzzcd6HzOdg7l67 kbmje94nwOysKIMCz/YiNjmnEfa7X0NorTZ+e3HOyTRG+NpyQoywgxvj TAFDGuu8hsussW+ohheb0efhX4/0YSamSsSBeAImPYWTdUQY10U0sXDq BCE=
> files.toke.dk. 43200 IN CNAME web2.tohojo.dk.
> files.toke.dk. 43200 IN RRSIG CNAME 5 3 43200 20140311112400 20140209112400 22551 toke.dk. ObiMhHqVUSxsje4979EzuiDoCt7z1r1Gl946gmY9ZDe7Es+7jg1l7m8/ vyVhPDRxqNxEAsTmFXF6mkwKkK60ag==
> ;; RRset to chase:
> files.toke.dk. 43200 IN CNAME web2.tohojo.dk.
>
>
> ;; RRSIG of the RRset to chase:
> files.toke.dk. 43200 IN RRSIG CNAME 5 3 43200 20140311112400 20140209112400 22551 toke.dk. ObiMhHqVUSxsje4979EzuiDoCt7z1r1Gl946gmY9ZDe7Es+7jg1l7m8/ vyVhPDRxqNxEAsTmFXF6mkwKkK60ag==
>
>
>
> Launch a query to find a RRset of type DNSKEY for zone: toke.dk.
> toke.dk. 43200 IN DNSKEY 256 3 5 AwEAAaYKHaUARHUtPhVTEC6vTc0SR142BVj1P/wtgCjacCkGDN5wB6Cm Y0xEwUl+NuT9btz0xQmDGOMJEKunK+HpOh0=
> toke.dk. 43200 IN DNSKEY 257 3 5 AwEAAdV59e0KX1JymujkIbzikKCEVSExW3ixJ81hiboCHSvZv+LlMxlG sWT6uJrcEOENF+fZnDcl3u0WRgd3ctv9d40=
> toke.dk. 43200 IN RRSIG DNSKEY 5 2 43200 20140311112400 20140209112400 22551 toke.dk. CzZARTabg0VR00Ksv0Uz+qRqRvl06fTTZHa0k17Ccg7JdrvsnZ5DgJKy dhM7j3Rb4LHfZbcoTXXABICCvSQnoQ==
> toke.dk. 43200 IN RRSIG DNSKEY 5 2 43200 20140311112400 20140209112400 65122 toke.dk. Q9OqTdh4s3aGn9ExkTnYwPk8j+V9cTjEjLGXD8zY5l0HewORrqJT5Ebn R0YvK/xH/2XLnueAZ/q8khlSfjhFzA==
>
> ;; DNSKEYset that signs the RRset to chase:
> toke.dk. 43200 IN DNSKEY 256 3 5 AwEAAaYKHaUARHUtPhVTEC6vTc0SR142BVj1P/wtgCjacCkGDN5wB6Cm Y0xEwUl+NuT9btz0xQmDGOMJEKunK+HpOh0=
> toke.dk. 43200 IN DNSKEY 257 3 5 AwEAAdV59e0KX1JymujkIbzikKCEVSExW3ixJ81hiboCHSvZv+LlMxlG sWT6uJrcEOENF+fZnDcl3u0WRgd3ctv9d40=
>
>
> ;; RRSIG of the DNSKEYset that signs the RRset to chase:
> toke.dk. 43200 IN RRSIG DNSKEY 5 2 43200 20140311112400 20140209112400 22551 toke.dk. CzZARTabg0VR00Ksv0Uz+qRqRvl06fTTZHa0k17Ccg7JdrvsnZ5DgJKy dhM7j3Rb4LHfZbcoTXXABICCvSQnoQ==
> toke.dk. 43200 IN RRSIG DNSKEY 5 2 43200 20140311112400 20140209112400 65122 toke.dk. Q9OqTdh4s3aGn9ExkTnYwPk8j+V9cTjEjLGXD8zY5l0HewORrqJT5Ebn R0YvK/xH/2XLnueAZ/q8khlSfjhFzA==
>
>
> ;; DSset of the DNSKEYset
> toke.dk. 86400 IN DS 65122 5 1 A6FEBBA66365D55C97F8671688AD52883AB582A6
>
>
> ;; RRSIG of the DSset of the DNSKEYset
> toke.dk. 86400 IN RRSIG DS 8 2 86400 20140308183226 20140208200232 61294 dk. thrq3zR+toPNxDln/H/qWBJbjkNK8/NosI6oriQBPXzzcd6HzOdg7l67 kbmje94nwOysKIMCz/YiNjmnEfa7X0NorTZ+e3HOyTRG+NpyQoywgxvj TAFDGuu8hsussW+ohheb0efhX4/0YSamSsSBeAImPYWTdUQY10U0sXDq BCE=
>
>
>
>
> ;; WE HAVE MATERIAL, WE NOW DO VALIDATION
> ;; VERIFYING CNAME RRset for files.toke.dk. with DNSKEY:22551: success
> ;; OK We found DNSKEY (or more) to validate the RRset
> ;; Now, we are going to validate this DNSKEY by the DS
> ;; OK a DS valids a DNSKEY in the RRset
> ;; Now verify that this DNSKEY validates the DNSKEY RRset
> ;; VERIFYING DNSKEY RRset for toke.dk. with DNSKEY:65122: success
> ;; OK this DNSKEY (validated by the DS) validates the RRset of the DNSKEYs, thus the DNSKEY validates the RRset
> ;; Now, we want to validate the DS : recursive call
>
>
> Launch a query to find a RRset of type DNSKEY for zone: dk.
> ;; NO ANSWERS: no more
>
> ;; DNSKEY is missing to continue validation: FAILED
>
>
> -Toke
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-10 17:14 ` Dave Taht
@ 2014-02-10 21:47 ` Simon Kelley
0 siblings, 0 replies; 36+ messages in thread
From: Simon Kelley @ 2014-02-10 21:47 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
On 10/02/14 17:14, Dave Taht wrote:
> Yea! I am under the impression that still missing functionality is nsec3?
The trace below reveals another problem, but that's fixed now.
NSEC3 remains to be done.
I'm still in a quandary about stripping DNSSEC information from upstream
answers when the question doesn't set the DO bit. Strictly that's a MUST
in the RFC, but my judgement is doing it is more likely to cause
problems ('cos it's difficult to do robustly),
I've just had doubts about trust anchors, see separate mail.
>
> Is the local-to-dnsmasq domain signable?
No.
Cheers,
Simon.
>
> On Mon, Feb 10, 2014 at 8:59 AM, Toke Høiland-Jørgensen<toke@toke.dk> wrote:
>> Simon Kelley<simon@thekelleys.org.uk> writes:
>>
>>> OK. Fix (I think), in git now. Please could you test? (A byte-order problem,
>>> inevitably).
>>
>> Yay, seems to work:
>>
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: query[A] files.toke.dk from 10.42.0.7
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: forwarded files.toke.dk to 213.80.98.3
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: forwarded files.toke.dk to 213.80.98.2
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DNSKEY] toke.dk to 213.80.98.2
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DS] toke.dk to 213.80.98.2
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DNSKEY] dk to 213.80.98.2
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DS] dk to 213.80.98.2
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DS keytag 26887
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DNSKEY keytag 26887
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DNSKEY keytag 7665
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DNSKEY keytag 61294
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply dk is DNSKEY keytag 31369
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply toke.dk is DS keytag 65122
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply toke.dk is DNSKEY keytag 65122
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply toke.dk is DNSKEY keytag 22551
>> Mon Feb 10 17:55:47 2014 daemon.err dnsmasq[11296]: Unexpected missing data for DNSSEC validation
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: validation result is INSECURE
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply files.toke.dk is<CNAME>
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply web2.tohojo.dk is 144.76.141.113
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: query[AAAA] files.toke.dk from 10.42.0.7
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: cached files.toke.dk is<CNAME>
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: forwarded files.toke.dk to 213.80.98.2
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DNSKEY] tohojo.dk to 213.80.98.2
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: dnssec-query[DS] tohojo.dk to 213.80.98.2
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply tohojo.dk is DS keytag 49471
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply tohojo.dk is DNSKEY keytag 49471
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply tohojo.dk is DNSKEY keytag 30141
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: validation result is SECURE
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply files.toke.dk is<CNAME>
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: reply web2.tohojo.dk is 2a01:4f8:200:3141::102
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: query[MX] files.toke.dk from 10.42.0.7
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: forwarded files.toke.dk to 213.80.98.2
>> Mon Feb 10 17:55:47 2014 daemon.info dnsmasq[11296]: validation result is SECURE
>>
>>
>> Dunno why it starts out insecure (?), but seems to get to the right
>> place.
>>
>> Can also do sigchase:
>>
>> $ dig +sigchase files.toke.dk @10.42.0.8
>> ...snip...
>>
>>
>> Launch a query to find a RRset of type DS for zone: .
>> ;; NO ANSWERS: no more
>>
>> ;; WARNING There is no DS for the zone: .
>>
>>
>>
>> ;; WE HAVE MATERIAL, WE NOW DO VALIDATION
>> ;; VERIFYING DS RRset for dk. with DNSKEY:33655: success
>> ;; OK We found DNSKEY (or more) to validate the RRset
>> ;; Ok, find a Trusted Key in the DNSKEY RRset: 19036
>> ;; VERIFYING DNSKEY RRset for . with DNSKEY:19036: success
>>
>> ;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS
>>
>>
>>
>> But not +trace:
>>
>> $ dig +trace +sigchase files.toke.dk @10.42.0.8
>>
>> ;<<>> DiG 9.9.2-P2<<>> +trace +sigchase files.toke.dk @10.42.0.8
>> ;; global options: +cmd
>> . 86891 IN NS d.root-servers.net.
>> . 86891 IN NS l.root-servers.net.
>> . 86891 IN NS h.root-servers.net.
>> . 86891 IN NS j.root-servers.net.
>> . 86891 IN NS b.root-servers.net.
>> . 86891 IN NS m.root-servers.net.
>> . 86891 IN NS k.root-servers.net.
>> . 86891 IN NS f.root-servers.net.
>> . 86891 IN NS e.root-servers.net.
>> . 86891 IN NS g.root-servers.net.
>> . 86891 IN NS a.root-servers.net.
>> . 86891 IN NS c.root-servers.net.
>> . 86891 IN NS i.root-servers.net.
>> . 325955 IN RRSIG NS 8 0 518400 20140215000000 20140207230000 33655 . cZOSrkiewfX+HdA2covOiYL+Z8xgBoCpJm4VZq083M51CvIFBipG1/BO JYYiRzmpQJN/l6FI5RBKmDVFq/RqkVineoIYrsIZL9RRcAF+phPO+kHU YU3ckdHZroDZCu1QUPd+Kr6Y8+9GBH8wYM++0Z6tLRA+iZXbNOadfZ9o euU=
>> dk. 172800 IN NS l.nic.dk.
>> dk. 172800 IN NS p.nic.dk.
>> dk. 172800 IN NS s.nic.dk.
>> dk. 172800 IN NS b.nic.dk.
>> dk. 172800 IN NS c.nic.dk.
>> dk. 172800 IN NS a.nic.dk.
>> dk. 86400 IN DS 26887 8 2 A1AB8546B80E438A7DFE0EC559A7088EC5AED3C4E0D26B1B60ED3735 F853DFD7
>> dk. 86400 IN RRSIG DS 8 1 86400 20140217000000 20140209230000 33655 . aK1OgJzktVeo2i83KdOig62wyqkxcQmbbQePi4T7zI4OhPzI5LMz9kbS W/V7bOgNBfYBjDJg4JEYIAC0esCrGPtbAsKQ7YrKiZikNAhlD/BgTvtD JQJxc+7f4xUa6Y7/9DBKmG8Du+DftF99RngT/hCgr9hZme9YkvtGaEyo CZI=
>> toke.dk. 86400 IN NS ns2.gratisdns.dk.
>> toke.dk. 86400 IN NS ns1.gratisdns.dk.
>> toke.dk. 86400 IN NS ns4.gratisdns.dk.
>> toke.dk. 86400 IN NS ns5.gratisdns.dk.
>> toke.dk. 86400 IN NS ns3.gratisdns.dk.
>> toke.dk. 86400 IN DS 65122 5 1 A6FEBBA66365D55C97F8671688AD52883AB582A6
>> toke.dk. 86400 IN RRSIG DS 8 2 86400 20140308183226 20140208200232 61294 dk. thrq3zR+toPNxDln/H/qWBJbjkNK8/NosI6oriQBPXzzcd6HzOdg7l67 kbmje94nwOysKIMCz/YiNjmnEfa7X0NorTZ+e3HOyTRG+NpyQoywgxvj TAFDGuu8hsussW+ohheb0efhX4/0YSamSsSBeAImPYWTdUQY10U0sXDq BCE=
>> files.toke.dk. 43200 IN CNAME web2.tohojo.dk.
>> files.toke.dk. 43200 IN RRSIG CNAME 5 3 43200 20140311112400 20140209112400 22551 toke.dk. ObiMhHqVUSxsje4979EzuiDoCt7z1r1Gl946gmY9ZDe7Es+7jg1l7m8/ vyVhPDRxqNxEAsTmFXF6mkwKkK60ag==
>> ;; RRset to chase:
>> files.toke.dk. 43200 IN CNAME web2.tohojo.dk.
>>
>>
>> ;; RRSIG of the RRset to chase:
>> files.toke.dk. 43200 IN RRSIG CNAME 5 3 43200 20140311112400 20140209112400 22551 toke.dk. ObiMhHqVUSxsje4979EzuiDoCt7z1r1Gl946gmY9ZDe7Es+7jg1l7m8/ vyVhPDRxqNxEAsTmFXF6mkwKkK60ag==
>>
>>
>>
>> Launch a query to find a RRset of type DNSKEY for zone: toke.dk.
>> toke.dk. 43200 IN DNSKEY 256 3 5 AwEAAaYKHaUARHUtPhVTEC6vTc0SR142BVj1P/wtgCjacCkGDN5wB6Cm Y0xEwUl+NuT9btz0xQmDGOMJEKunK+HpOh0=
>> toke.dk. 43200 IN DNSKEY 257 3 5 AwEAAdV59e0KX1JymujkIbzikKCEVSExW3ixJ81hiboCHSvZv+LlMxlG sWT6uJrcEOENF+fZnDcl3u0WRgd3ctv9d40=
>> toke.dk. 43200 IN RRSIG DNSKEY 5 2 43200 20140311112400 20140209112400 22551 toke.dk. CzZARTabg0VR00Ksv0Uz+qRqRvl06fTTZHa0k17Ccg7JdrvsnZ5DgJKy dhM7j3Rb4LHfZbcoTXXABICCvSQnoQ==
>> toke.dk. 43200 IN RRSIG DNSKEY 5 2 43200 20140311112400 20140209112400 65122 toke.dk. Q9OqTdh4s3aGn9ExkTnYwPk8j+V9cTjEjLGXD8zY5l0HewORrqJT5Ebn R0YvK/xH/2XLnueAZ/q8khlSfjhFzA==
>>
>> ;; DNSKEYset that signs the RRset to chase:
>> toke.dk. 43200 IN DNSKEY 256 3 5 AwEAAaYKHaUARHUtPhVTEC6vTc0SR142BVj1P/wtgCjacCkGDN5wB6Cm Y0xEwUl+NuT9btz0xQmDGOMJEKunK+HpOh0=
>> toke.dk. 43200 IN DNSKEY 257 3 5 AwEAAdV59e0KX1JymujkIbzikKCEVSExW3ixJ81hiboCHSvZv+LlMxlG sWT6uJrcEOENF+fZnDcl3u0WRgd3ctv9d40=
>>
>>
>> ;; RRSIG of the DNSKEYset that signs the RRset to chase:
>> toke.dk. 43200 IN RRSIG DNSKEY 5 2 43200 20140311112400 20140209112400 22551 toke.dk. CzZARTabg0VR00Ksv0Uz+qRqRvl06fTTZHa0k17Ccg7JdrvsnZ5DgJKy dhM7j3Rb4LHfZbcoTXXABICCvSQnoQ==
>> toke.dk. 43200 IN RRSIG DNSKEY 5 2 43200 20140311112400 20140209112400 65122 toke.dk. Q9OqTdh4s3aGn9ExkTnYwPk8j+V9cTjEjLGXD8zY5l0HewORrqJT5Ebn R0YvK/xH/2XLnueAZ/q8khlSfjhFzA==
>>
>>
>> ;; DSset of the DNSKEYset
>> toke.dk. 86400 IN DS 65122 5 1 A6FEBBA66365D55C97F8671688AD52883AB582A6
>>
>>
>> ;; RRSIG of the DSset of the DNSKEYset
>> toke.dk. 86400 IN RRSIG DS 8 2 86400 20140308183226 20140208200232 61294 dk. thrq3zR+toPNxDln/H/qWBJbjkNK8/NosI6oriQBPXzzcd6HzOdg7l67 kbmje94nwOysKIMCz/YiNjmnEfa7X0NorTZ+e3HOyTRG+NpyQoywgxvj TAFDGuu8hsussW+ohheb0efhX4/0YSamSsSBeAImPYWTdUQY10U0sXDq BCE=
>>
>>
>>
>>
>> ;; WE HAVE MATERIAL, WE NOW DO VALIDATION
>> ;; VERIFYING CNAME RRset for files.toke.dk. with DNSKEY:22551: success
>> ;; OK We found DNSKEY (or more) to validate the RRset
>> ;; Now, we are going to validate this DNSKEY by the DS
>> ;; OK a DS valids a DNSKEY in the RRset
>> ;; Now verify that this DNSKEY validates the DNSKEY RRset
>> ;; VERIFYING DNSKEY RRset for toke.dk. with DNSKEY:65122: success
>> ;; OK this DNSKEY (validated by the DS) validates the RRset of the DNSKEYs, thus the DNSKEY validates the RRset
>> ;; Now, we want to validate the DS : recursive call
>>
>>
>> Launch a query to find a RRset of type DNSKEY for zone: dk.
>> ;; NO ANSWERS: no more
>>
>> ;; DNSKEY is missing to continue validation: FAILED
>>
>>
>> -Toke
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>
>
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-10 16:59 ` Toke Høiland-Jørgensen
2014-02-10 17:12 ` Simon Kelley
2014-02-10 17:14 ` Dave Taht
@ 2014-02-11 11:34 ` Simon Kelley
2014-02-11 14:01 ` Toke Høiland-Jørgensen
2 siblings, 1 reply; 36+ messages in thread
From: Simon Kelley @ 2014-02-11 11:34 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: cerowrt-devel
I've just pushed a load of changes to git, and tagged 2.69test8
This has the big-endian platform fix, and a fix for the bug Toke found
after that was fixed. (A reply may need more than one DNSKEY to validate).
I've also completely changed the way the trust anchors are specified,
from DNSKEYS to DS records. If you're using the trust-anchors.conf file
I supply, this should be transparent, but if you explicitly configured
them, you'll need to change that configuration before the new binary
will start succesfully.
Cheers,
Simon.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-11 11:34 ` Simon Kelley
@ 2014-02-11 14:01 ` Toke Høiland-Jørgensen
2014-02-11 15:51 ` Simon Kelley
0 siblings, 1 reply; 36+ messages in thread
From: Toke Høiland-Jørgensen @ 2014-02-11 14:01 UTC (permalink / raw)
To: Simon Kelley; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 3998 bytes --]
Simon Kelley <simon@thekelleys.org.uk> writes:
> I've just pushed a load of changes to git, and tagged 2.69test8
Built and installed on my cerowrt box, and seems to work beautifully:
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: query[A] files.toke.dk from 10.42.0.7
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: forwarded files.toke.dk to 213.80.98.3
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: forwarded files.toke.dk to 213.80.98.2
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: dnssec-query[DNSKEY] toke.dk to 213.80.98.2
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: dnssec-query[DS] toke.dk to 213.80.98.2
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: dnssec-query[DNSKEY] dk to 213.80.98.2
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: dnssec-query[DS] dk to 213.80.98.2
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: dnssec-query[DNSKEY] . to 213.80.98.2
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: reply . is DNSKEY keytag 33655
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: reply . is DNSKEY keytag 19036
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: reply dk is DS keytag 26887
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: reply dk is DNSKEY keytag 61294
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: reply dk is DNSKEY keytag 31369
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: reply dk is DNSKEY keytag 26887
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: reply dk is DNSKEY keytag 7665
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: reply toke.dk is DS keytag 65122
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: reply toke.dk is DNSKEY keytag 22551
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: reply toke.dk is DNSKEY keytag 65122
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: dnssec-query[DNSKEY] tohojo.dk to 213.80.98.2
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: dnssec-query[DS] tohojo.dk to 213.80.98.2
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: reply tohojo.dk is DS keytag 49471
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: reply tohojo.dk is DNSKEY keytag 49471
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: reply tohojo.dk is DNSKEY keytag 30141
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: validation result is SECURE
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: reply files.toke.dk is <CNAME>
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: reply web2.tohojo.dk is 144.76.141.113
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: query[AAAA] files.toke.dk from 10.42.0.7
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: cached files.toke.dk is <CNAME>
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: forwarded files.toke.dk to 213.80.98.2
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: validation result is SECURE
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: reply files.toke.dk is <CNAME>
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: reply web2.tohojo.dk is 2a01:4f8:200:3141::102
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: query[MX] files.toke.dk from 10.42.0.7
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: forwarded files.toke.dk to 213.80.98.2
Tue Feb 11 14:44:38 2014 daemon.info dnsmasq[6162]: validation result is SECURE
As for client-side tests:
$ dig +sigchase files.toke.dk @10.42.0.8
...snip...
Launch a query to find a RRset of type DS for zone: .
;; NO ANSWERS: no more
;; WARNING There is no DS for the zone: .
;; WE HAVE MATERIAL, WE NOW DO VALIDATION
;; VERIFYING DS RRset for dk. with DNSKEY:33655: success
;; OK We found DNSKEY (or more) to validate the RRset
;; Ok, find a Trusted Key in the DNSKEY RRset: 19036
;; VERIFYING DNSKEY RRset for . with DNSKEY:19036: success
;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS
I've also updated the x86 builds on OBS:
https://build.opensuse.org/package/repositories/home:tohojo:dnsmasq/dnsmasq
-Toke
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-06 11:27 ` Simon Kelley
2014-02-06 12:35 ` Toke Høiland-Jørgensen
@ 2014-02-06 13:42 ` Toke Høiland-Jørgensen
2014-02-06 14:40 ` Simon Kelley
1 sibling, 1 reply; 36+ messages in thread
From: Toke Høiland-Jørgensen @ 2014-02-06 13:42 UTC (permalink / raw)
To: Simon Kelley; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]
Simon Kelley <simon@thekelleys.org.uk> writes:
> Otherwise, just the usual stuff, crashes, infinite loops, wrong answers.
> "internal error" log entries.
Right, another data point: got an invalid signature:
dnsmasq[21893]: query[A] www.tcpdump.org from 127.0.0.1
dnsmasq[21893]: forwarded www.tcpdump.org to 127.0.0.1
dnsmasq[21893]: validation result is BOGUS
dnsmasq[21893]: reply www.tcpdump.org is 69.4.231.52
dnsmasq[21893]: reply www.tcpdump.org is 132.213.238.6
Seems to be correct, though:
$ dig +trace +dnssec +sigchase www.tcpdump.org
...snip...
;; WE HAVE MATERIAL, WE NOW DO VALIDATION
;; VERIFYING A RRset for www.tcpdump.org. with DNSKEY:20163: RRSIG has expired
;; No DNSKEY is valid to check the RRSIG of the RRset: FAILED
Turning on dnssec-debug also "helps":
$ host www.tcpdump.org
www.tcpdump.org has address 69.4.231.52
www.tcpdump.org has address 132.213.238.6
www.tcpdump.org has RRSIG record A 5 3 60 20131226232352 20131126222352 20163 tcpdump.org. iyzWHZ5I6wkK6uZrmNg22SZnP2JKHN1LSE9Vo+PE3J1tbA9cPcVlas3v O8PtAGjzjP/TnGRaBSbni+Bwr6GJMRT1+S1Fw1aBCeTyioRmDPP0WS48 K6WULn5Mf35KNqzpHb+1YcvP2MeSp5oMVv3uFUjONlt7RqPHVTgfnR1L zy8=
www.tcpdump.org has IPv6 address 2607:f0d0:3001:62:1::52
www.tcpdump.org has IPv6 address 2001:4830:116e:2::6
www.tcpdump.org has RRSIG record AAAA 5 3 60 20131226232352 20131126222352 20163 tcpdump.org. L71XIeQLyVmZf4eXbBvefojm8qYhc/xAXR3S28pKBdeUgXl1DfePO8Il lUZhAXowKAw8H1529AglgW8HGAiJGwzoVefYz+GnZCg2N6AWoYM4gxve XwPtCDx51FAKkINkMX1XGqUIIX6Bq26RPcth0JSVCA+Fy+29ZxeitN36 sBk=
-Toke
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
2014-02-06 13:42 ` Toke Høiland-Jørgensen
@ 2014-02-06 14:40 ` Simon Kelley
0 siblings, 0 replies; 36+ messages in thread
From: Simon Kelley @ 2014-02-06 14:40 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: cerowrt-devel
On 06/02/14 13:42, Toke Høiland-Jørgensen wrote:
> Simon Kelley<simon@thekelleys.org.uk> writes:
>
>> Otherwise, just the usual stuff, crashes, infinite loops, wrong
>> answers. "internal error" log entries.
>
> Right, another data point: got an invalid signature:
>
> dnsmasq[21893]: query[A] www.tcpdump.org from 127.0.0.1
> dnsmasq[21893]: forwarded www.tcpdump.org to 127.0.0.1
> dnsmasq[21893]: validation result is BOGUS dnsmasq[21893]: reply
> www.tcpdump.org is 69.4.231.52 dnsmasq[21893]: reply www.tcpdump.org
> is 132.213.238.6
>
> Seems to be correct, though:
>
> $ dig +trace +dnssec +sigchase www.tcpdump.org ...snip...
>
> ;; WE HAVE MATERIAL, WE NOW DO VALIDATION ;; VERIFYING A RRset for
> www.tcpdump.org. with DNSKEY:20163: RRSIG has expired ;; No DNSKEY is
> valid to check the RRSIG of the RRset: FAILED
>
> Turning on dnssec-debug also "helps":
>
> $ host www.tcpdump.org www.tcpdump.org has address 69.4.231.52
> www.tcpdump.org has address 132.213.238.6 www.tcpdump.org has RRSIG
> record A 5 3 60 20131226232352 20131126222352 20163 tcpdump.org.
^^^^^^^^^^^^^^
> iyzWHZ5I6wkK6uZrmNg22SZnP2JKHN1LSE9Vo+PE3J1tbA9cPcVlas3v
> O8PtAGjzjP/TnGRaBSbni+Bwr6GJMRT1+S1Fw1aBCeTyioRmDPP0WS48
> K6WULn5Mf35KNqzpHb+1YcvP2MeSp5oMVv3uFUjONlt7RqPHVTgfnR1L zy8=
> www.tcpdump.org has IPv6 address 2607:f0d0:3001:62:1::52
> www.tcpdump.org has IPv6 address 2001:4830:116e:2::6 www.tcpdump.org
> has RRSIG record AAAA 5 3 60 20131226232352 20131126222352 20163
^^^^^^^^^^^^^^
> tcpdump.org. L71XIeQLyVmZf4eXbBvefojm8qYhc/xAXR3S28pKBdeUgXl1DfePO8Il
> lUZhAXowKAw8H1529AglgW8HGAiJGwzoVefYz+GnZCg2N6AWoYM4gxve
> XwPtCDx51FAKkINkMX1XGqUIIX6Bq26RPcth0JSVCA+Fy+29ZxeitN36 sBk=
>
In case it's not obvious, yes, the sig(s) have expired.
Cheers,
Simon.
>
> -Toke
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2014-02-11 16:25 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-04 16:20 [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC Dave Taht
2014-02-05 7:13 ` Toke Høiland-Jørgensen
2014-02-05 17:10 ` Toke Høiland-Jørgensen
2014-02-05 19:51 ` Simon Kelley
2014-02-05 20:09 ` Toke Høiland-Jørgensen
2014-02-05 22:26 ` Simon Kelley
2014-02-06 7:28 ` Toke Høiland-Jørgensen
2014-02-06 10:53 ` Simon Kelley
2014-02-06 10:57 ` Toke Høiland-Jørgensen
2014-02-06 11:27 ` Simon Kelley
2014-02-06 12:35 ` Toke Høiland-Jørgensen
2014-02-06 15:01 ` Simon Kelley
2014-02-09 12:09 ` Toke Høiland-Jørgensen
2014-02-09 12:23 ` Simon Kelley
2014-02-09 12:48 ` Toke Høiland-Jørgensen
2014-02-09 18:04 ` Dave Taht
2014-02-09 18:47 ` Toke Høiland-Jørgensen
2014-02-09 21:02 ` Simon Kelley
2014-02-09 20:59 ` Simon Kelley
2014-02-09 21:07 ` Dave Taht
2014-02-09 21:16 ` Toke Høiland-Jørgensen
2014-02-09 21:33 ` Toke Høiland-Jørgensen
2014-02-10 10:50 ` Simon Kelley
2014-02-10 11:39 ` Simon Kelley
2014-02-10 12:59 ` Toke Høiland-Jørgensen
2014-02-10 16:45 ` Simon Kelley
2014-02-10 16:59 ` Toke Høiland-Jørgensen
2014-02-10 17:12 ` Simon Kelley
2014-02-10 17:14 ` Dave Taht
2014-02-10 21:47 ` Simon Kelley
2014-02-11 11:34 ` Simon Kelley
2014-02-11 14:01 ` Toke Høiland-Jørgensen
2014-02-11 15:51 ` Simon Kelley
2014-02-11 16:25 ` Toke Høiland-Jørgensen
2014-02-06 13:42 ` Toke Høiland-Jørgensen
2014-02-06 14:40 ` Simon Kelley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox