Hi,
On Sat, Jan 9, 2016 at 7:25 PM, Simon Kelley
Post by Simon KelleyNo that one slipped though the net. Thinking about that some
more, there are likely fundamental problems with doing ant DNSSEC
on servers handling subdomains, since the chain-of-trust isn't
going to wor k.
EG. you run dnsmasq with
server=/example.com/<ip-of-server>
This is likely because that server knows about stuff under
example.com which is not known about by the "global" DNS server
which dnsmasq is forwarding to. Even if the example.com server is
signing DNSSEC, it's highly unlikely that dnsmasq will be able to
validate its output, since the chain-of-trust won't reach to it.
If you're going to the trouble of getting the DS record for
example.com signed by the .com administrators, then you may as
well have them serve the delegation as well, and make example.com
globally visible.
It therefore makes sense to turn off DNSSEC validation for any
domains handled by such servers.
The next stage would be to turn it back on if there's a
trust-anchor supplied for the domain. That would allow DNS
servers for private domains to work with DNSSEC. Doing that is
predicated on making the dnsmasq validation code work with
non-root trust anchors. I don't think it does at the moment.
So, that's a plan.
1) disable validation when forwarding to servers for a domain.
and longer term
2) make non-root trust anchors work and turn it back on is one
is provided.
Comments?
It would be solving the .onion problem without the security issue
of disabling dnsseccheckunsigned.
But there are already non IANA TLDs using DNSSEC out there, like
opennic, see [0].
Right now I can make use of that, e.g. with their .free TLD: * dig
trust-anchor=free,<output from earlier step> *
server=/free/5.9.49.12
and make dnsmasq resolve e.g. reg.for.free with dnssec enabled
(next to all the IANA TLDs). Your plan would break that until 2)
is implemented.
Having that that, this example isn't a clear solution either. It
fishes out the .free DS record since it's the only way I could find
to tell dnsmasq about it (using the trust-anchor "domain" field).
Maybe "named" trust-anchors are the most flexible solution.
Something like this: * trust-anchor=iana,... *
trust-anchor=opennic,... * server=x.x.x.x/iana *
server=/free/x.x.x.x/opennic * server=/indy/x.x.x.x/opennic *
server=/onion/x.x.x.x/none
But whatever 2) will be, having 1) so we don't have to disable
dnsseccheckunsigned would be a first step.
Thanks, Andre
[0] http://wiki.opennicproject.org/dnssecroot
Your opennic example is interesting. The opennic nameservers provide
an alternative root, and delegate all the IANA TLDs (or at least all
the ones which existed before ICANN started whoring them out to
whoever would pay.....) The solution, therefore is to send all the
queries to opennic, they'll get the answers from the conventional TLDs
and return them just fine.
The clever bit is that opennic has signed the root zone with their own
key - they have to to be able to add .free and friends, since the
ICANN private key isn't available to them. The Opennic website doesn't
provide this key in easy to use form, as far as I can see, but we can
easily get it.
dig @5.9.49.12 dnskey .
will us the key (actually three keys, two zone-signing keys and a key
signing key - that's the one we're interested in - it has flags field
== 257.
; <<>> DiG 9.9.5-3ubuntu0.6-Ubuntu <<>> @5.9.49.12 dnskey .
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35573
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;. IN DNSKEY
;; ANSWER SECTION:
. 86400 IN DNSKEY 256 3 8
AwEAAbBeOAxco/hOn+ENrbiIW8s4YMZXRGmNAx58Oy8PQBWSf9G5JDyQ
owOLQLQlrVX7S2qmtF8OOUgX3inM+IUm6g+Nbjh1fYrdFYHMKD+T13fw
aYT6gUJJKtLrfjznDfZ3+ViRoywd4riLA/xMR1+B+2lZqdCW1mN9z+7J
gsBJs5tuKqUaLLj89fF+80DPicbQyKm/VFsXIFve2foM0YiK9+x0QYS7
yYkpgMRd2OyCfpCMf8dipYnVWwxGIBtT8FE10///M+OAedCLfWyScqWV
xHnf6G3fH0+Lxh5Kp+xa7szf80wO7xAoMcRWctCq8DoKQZJ41MJhlIVe Xq7ng21lKws=
. 86400 IN DNSKEY 257 3 8
AwEAAe2SqWzJDU5l8IiTdWIEi4gG0fNGXzX3ISbU1a6JAsUPFl7rCWDe
9f5J67xGSAkbwS2doYzvPL72AmI077wFapBtNFCgUT4KruO+f0j0pO74
QFM6dFlIRbVJBUuTReRcikiqP8e1wWvLXd4PknSkAi6k+TQpl48YOEYC
rf1jqWqPTJVZuJlMMdYyHSXndRhN5QF7+kP7FmulpDhLCNLFVHWCXXxH
td6AgF6OyuTMr1iQd44tBz2e8sNK9qJ9fsCvF2iRRUlePh1q2WKzC6DG
J5PJgeHKefSE515+hdyBWhGId2u7yOTNMxcbAOq17KOmf/fct1nvlqOM
cLZ55oKPy0t9nU/niQaYhU0P+F8rmdyCkK29ri4hbBHgOO7INw2ElYxA
B/uihgC+7ErTkQg5iZiIrGvAMXIeV0tXsB+QNgAFqAHpuNjiyaXBnNkN
YUKKcnHr54lJ2grXXSIgK/et2vPgeQK9TWNX7yiLwRcE6Nw8jK0ZdpfO
ujGgVnvVfOtJaTVkT2qyXp0M3FSQG8Se0C0x17Pvu9Jrs44P6cDwcA5n
QPMjEZOyHdk+LeYrk41qhWubVF3D1MeJdxwgL8ZtW8Rk5J55SlQZU8cm
bd8cklpiRYA/60G++wvatfKQs24zB/rlC0yXKWZ/IuRGN/p96Fes8O+s YAWFOHq/kA43fpg
J
. 86400 IN DNSKEY 256 3 8
AwEAAa50Y7yGoWrBHwj8apK12S1bu/esUB/2XdWlJAxi5Ab8xKAaHX2g
m9UR9OKfu2rzVLrtFgye85EFQqkYswZNYySNMLFuifaCPE9uJcK6ygDa
gc5IP1OjGD27KT+xMLPl6zWjCcmyxIwoZpFJKnZ9RxMWViApKMSdohOK
hLMED8dRDDy665aS8xgvZm8bCl8g0eRTrMAq9jVovQ53uADWhZt/fIQK
iNfrKWLk8WeHmjP+mIVEKL6bRzzYI+mB7sQAAYz/fePFBMsbqBBLkMsJ
gQQBdum/b25w6Jf8FDkwpkcBHHziR4DGxyc/d5yQIXZCyeG0IEkCD1sx 98VGerH5CR8=
;; Query time: 906 msec
;; SERVER: 5.9.49.12#53(5.9.49.12)
;; WHEN: Mon Jan 11 21:08:36 GMT 2016
;; MSG SIZE rcvd: 1109
The trust anchor we need is not the key, it's a DS record, which is
simply a SHA1 or SHA256 hash of the key in question - all the
information needed is on the RRset above, but it needs to be
reformated. The following pipeline does it for BIND-format config
dig @5.9.49.12 dnskey . | dnssec-dsfromkey -2 -f - .
The -2 flag tells dsfromkey to make the SHA256 hash
. IN DS 7372 8 2
14A2B8CAF58BFAAE0BD7C257488A341FCC542F9F88F0B678D620324CE7B55285
A quick re-format into dnsmasq config format gives us
trust-anchor=.,7372,8,2,14A2B8CAF58BFAAE0BD7C257488A341FCC542F9F88F0B678
D620324CE7B55285
Putting that in the config file and _just_ using 5.9.49.12 (and other
opennic servers) gives DNSSEC for all domains fine.
I didn't verify that key out-of-band in any way. In theory there could
be a man-in-the-middle intercepting DNS queries from my network, and
substituting his own key so that I set up trust to it. It would be
good for opennic to publish their key widely, so it can be checked
rather than trusting an insecure DNS query. Even a web page would help
- - it's much more difficult to substitute a key buried in HTML that one
in a DNS packet.
Assuming that I have the genuine opennic key, I'm now trusting
opennic. They can give me bad data for _any_ domain if they wish, by
providing an alternative chain-of-trust to the data. Of course the
same is true for 99% of the internet who blindly trust their ISPs
recursive resolver because they're no doing DNSEC validation.
If you trust opennic more that ICANN is an interesting question: ICANN
does elaborate key ceremonies and hold the private key in multiple
HSMs spread around the world. Opennic, as far as I can see, keeps it
in a mode 700 directory on their master nameserver machine. Presumably
the NSA could take it any time they wanted, but the same is probably
true for the ICANN private key. It will take more effort, but it's
worth more....
Cheers,
Simon.