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