I'm running unbound locally on 127.0.0.1 and a DNS TCP proxy (ttdnsd) on
127.0.0.2. The setup is a simple forward-zone; I ask unbound and unbound
asks ttdnsd:
forward-zone:
name: "."
forward-addr: 127.0.0.2
Now I'm trying to get dnssec working but I've run in to some problems.
The auto-trust-anchor-file (root.key in this case) has been successfully
updated but:
$ dig com. SOA +dnssec @127.0.0.1
doesn't set the AD flags in the response. Instead I get the following in
my logfile:
"validation failure <com. SOA IN>: key for validation com. is marked as
invalid because of a previous validation failure <com. SOA IN>:
signatures from unknown keys from 127.0.0.2 for DS com. while building
chain of trust".
Querying ttdnsd with:
$ dig com. SOA +dnssec @127.0.0.2
Gives me a SOA and RRSIG record back (but no AD).
I'm guessing this is because ttdnsd doesn't support validating dnssec
queries.
Since I trust the local instance of ttdnsd - is there any way to "skip"
that part of the validation chain and transparently "tunnel" through it?
I'm running unbound locally on 127.0.0.1 and a DNS TCP proxy (ttdnsd) on
127.0.0.2. The setup is a simple forward-zone; I ask unbound and unbound
asks ttdnsd:
forward-zone:
name: "."
forward-addr: 127.0.0.2
Now I'm trying to get dnssec working but I've run in to some problems.
The auto-trust-anchor-file (root.key in this case) has been successfully
updated but:
$ dig com. SOA +dnssec @127.0.0.1
doesn't set the AD flags in the response. Instead I get the following in
my logfile:
"validation failure <com. SOA IN>: key for validation com. is marked as
invalid because of a previous validation failure <com. SOA IN>:
signatures from unknown keys from 127.0.0.2 for DS com. while building
chain of trust".
Querying ttdnsd with:
$ dig com. SOA +dnssec @127.0.0.2
Gives me a SOA and RRSIG record back (but no AD).
I'm guessing this is because ttdnsd doesn't support validating dnssec
queries.
It need not support validation, but it has to support dnssec: pass
through RRSIGs and be able to fetch DNSSEC types, such as the DS record.
What does dig com. DS +dnssec @127.0.0.2 say? I have the sneaky
suspicion that it does not properly fetch the DS record from the parent
servers on that zonecut, but provides the data from the child-side of
that zonecut (there is then no DS record there and it is all signed with
the wrong keys).
Since I trust the local instance of ttdnsd - is there any way to "skip"
that part of the validation chain and transparently "tunnel" through it?
Why are you doing this? unbound can do queries using just tcp per default, so you
do not need to use ttdnsd. I assume you're trying to proxy dns to an anonymiser
network like tor?
Try this unbound patch, and set unbound to use tcp only in unbound.conf using
do-udp:no and do-tcp:yes.
I've sent this to the tor people before, but they haven't gotten back to me
with test results. If we have positive results, we might be able to convince
Wouter to make the below patch a runtime option.
I don't know about his config - but we plan that ttdnsd will ask Tor for
answers that Tor can answer - those answers are the most safe to use
over Tor. Then the other queries will go upstream and out to an upstream
server such as 8.8.8.8 or wherever.
ttdnsd is just a transport relay for dns over tcp with no real knowledge of
DNS(SEC). It would be much better to use a DNSSEC aware nameserver, so avoid
needing to rely on Tor Nodes or directory servers. Not to say the least about
trustig google(!!!) of all places with anonymity.
As far as I know, no one will ever add the first mode to unbound and the
second one is untested. That is why people use ttdnsd. If unbounded
becomes Tor aware, I'd be happy to never use ttdnsd again.
I have no idea about what "first" and "second" mode you are talking about.
Now I'm trying to get dnssec working but I've run in to some problems.
Why are you doing this? unbound can do queries using just tcp per default, so you
do not need to use ttdnsd. I assume you're trying to proxy dns to an anonymiser
network like tor?
Try this unbound patch, and set unbound to use tcp only in unbound.conf using
do-udp:no and do-tcp:yes.
That should be do-udp:yes. The patch disabled the activation of udp for outgoing
queries but the do-udp:yes allows udp for incoming (localhost) queries.
I'm running unbound locally on 127.0.0.1 and a DNS TCP proxy (ttdnsd) on
127.0.0.2. The setup is a simple forward-zone; I ask unbound and unbound
asks ttdnsd:
forward-zone:
name: "."
forward-addr: 127.0.0.2
Now I'm trying to get dnssec working but I've run in to some problems.
Why are you doing this? unbound can do queries using just tcp per
default, so you
do not need to use ttdnsd. I assume you're trying to proxy dns to an
anonymiser
network like tor?
Indeed, I am trying to set up a sane DNS resolution strategy for tor.
Try this unbound patch, and set unbound to use tcp only in unbound.conf
using
do-udp:no and do-tcp:yes.
I've tried your patch (using yes/yes as suggested in a later mail). It
seems to be working just fine. Unbound is resolving all types over tcp
through tor, with and without dnssec. Perfect!
I was initially using ttdnsd as a fallback for resolving non A/PTR
records, since those can't be resolved using tor's built in mechanism.
The later provides good anonymity, but is susceptible to spoofing by
exits, exits ISP's, et al..
I'm tempted to drop ttdnsd. It has served me well (thanks Jake), but
it's always nice to get rid of complexity. But, before doing so I have
to ponder what it's implications will be on anonymity. It's not obvious
to me that using unbound tcp over tor is any more or less anonymous than
using the tor resolution.
That might be a discussion best suited for another (tor) mailing list
though.
Indeed, I am trying to set up a sane DNS resolution strategy for tor.
Try this unbound patch, and set unbound to use tcp only in unbound.conf
using
do-udp:no and do-tcp:yes.
I've tried your patch (using yes/yes as suggested in a later mail). It
seems to be working just fine. Unbound is resolving all types over tcp
through tor, with and without dnssec. Perfect!
Excellent.
I'm tempted to drop ttdnsd. It has served me well (thanks Jake), but
it's always nice to get rid of complexity. But, before doing so I have
to ponder what it's implications will be on anonymity. It's not obvious
to me that using unbound tcp over tor is any more or less anonymous than
using the tor resolution.
That might be a discussion best suited for another (tor) mailing list
though.
Note that unbound's behaviour can be easilly changed using its python
module. For instance, TTLs could be changed randomly or capped, to
improve anonymity. But indeed, take it up with the tor people.
The easiest integration would be to configure unbound with a forwarder for
127.0.0.1 XXX where XXX would lead into a tor virtual circuit to google's
8.8.8.8 open resolver (that supports dnssec). tor could frequently change
the exit node without unbound needing to know its routing changed.
Wouter: could the patch be stuck into a configurable option?
Are you sure 8.8.8.8 supports DNSSEC ? Because than I would have
expected this to work:
$ cat /etc/resolv.conf
nameserver 8.8.8.8
$ ./unbound-host -h | grep Version # with ldns-1.6.10 and only one
configure option: --disable-gost
Version 1.4.12
$ ./unbound-host -r -d -vy '. DS 19036 8 2
49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5' cz -t DS
[1311679359] libunbound[32251:0] notice: init module 0: validator
[1311679359] libunbound[32251:0] notice: init module 1: iterator
[1311679359] libunbound[32251:0] info: resolving cz. DS IN
[1311679359] libunbound[32251:0] info: response for cz. DS IN
[1311679359] libunbound[32251:0] info: reply from <.> 8.8.8.8#53
[1311679359] libunbound[32251:0] info: query response was nodata ANSWER
[1311679359] libunbound[32251:0] info: prime trust anchor
[1311679359] libunbound[32251:0] info: resolving . DNSKEY IN
[1311679359] libunbound[32251:0] info: response for . DNSKEY IN
[1311679359] libunbound[32251:0] info: reply from <.> 8.8.8.8#53
[1311679359] libunbound[32251:0] info: query response was ANSWER
[1311679359] libunbound[32251:0] info: validate keys with anchor(DS):
sec_status_secure
[1311679359] libunbound[32251:0] info: Successfully primed trust anchor
. DNSKEY IN
[1311679359] libunbound[32251:0] info: resolving cz. DS IN
[1311679359] libunbound[32251:0] info: NSEC3s for the referral did not
prove no DS.
[1311679359] libunbound[32251:0] info: resolving cz. DS IN
[1311679359] libunbound[32251:0] info: response for cz. DS IN
[1311679359] libunbound[32251:0] info: reply from <.> 8.8.8.8#53
[1311679359] libunbound[32251:0] info: query response was nodata ANSWER
[1311679359] libunbound[32251:0] info: NSEC3s for the referral did not
prove no DS.
[1311679359] libunbound[32251:0] info: resolving cz. DS IN
[1311679359] libunbound[32251:0] info: response for cz. DS IN
[1311679359] libunbound[32251:0] info: reply from <.> 8.8.8.8#53
[1311679359] libunbound[32251:0] info: query response was nodata ANSWER
[1311679359] libunbound[32251:0] info: NSEC3s for the referral did not
prove no DS.
[1311679359] libunbound[32251:0] info: resolving cz. DS IN
[1311679359] libunbound[32251:0] info: response for cz. DS IN
[1311679359] libunbound[32251:0] info: reply from <.> 8.8.8.8#53
[1311679359] libunbound[32251:0] info: query response was nodata ANSWER
[1311679359] libunbound[32251:0] info: NSEC3s for the referral did not
prove no DS.
[1311679359] libunbound[32251:0] info: resolving cz. DS IN
[1311679359] libunbound[32251:0] info: response for cz. DS IN
[1311679359] libunbound[32251:0] info: reply from <.> 8.8.8.8#53
[1311679359] libunbound[32251:0] info: query response was nodata ANSWER
[1311679359] libunbound[32251:0] info: NSEC3s for the referral did not
prove no DS.
[1311679359] libunbound[32251:0] info: resolving cz. DS IN
[1311679360] libunbound[32251:0] info: response for cz. DS IN
[1311679360] libunbound[32251:0] info: reply from <.> 8.8.8.8#53
[1311679360] libunbound[32251:0] info: query response was nodata ANSWER
[1311679360] libunbound[32251:0] info: NSEC3s for the referral did not
prove no DS.
[1311679360] libunbound[32251:0] info: Could not establish a chain of
trust to keys for cz. DNSKEY IN
cz has no DS record (BOGUS (security failure))
validation failure <cz. DS IN>: no signatures with algorithm RSASHA256
from 8.8.8.8 for DS cz. while building chain of trust
note unbound-host uses configuration from /etc/unbound/unbound.conf and not the system
resolver.
You're right, google does not yet fully support all DNSSEC records. It does support
returning RRSIGs and DNSKEYs but it does not seem to support DS records yet.
Are you sure 8.8.8.8 supports DNSSEC ? Because than I would have
expected this to work:
$ cat /etc/resolv.conf
nameserver 8.8.8.8
$ ./unbound-host -h | grep Version # with ldns-1.6.10 and only one
configure option: --disable-gost
Version 1.4.12
note unbound-host uses configuration from /etc/unbound/unbound.conf
and not the system
resolver.
That is why I had use the -r as an argument to the unbound-host command.
You're right, google does not yet fully support all DNSSEC records. It
does support
returning RRSIGs and DNSKEYs but it does not seem to support DS
records yet.
I guess it doesn't know it needs to talk to the nameservers of the
parentzone to get the DS ?
