Re: [tor-relays] Let's increase the amount of exit relays doing DNSSEC validation
Respectfully, I disagree. https://lists.torproject.org/pipermail/tor-relays/2015-October/007904.html Thank you for the thought however.
Hi All, Is there anyone who uses Bind9? I'll setup DNSSEC on all Exits but I would like to validate the config. I have done this on 41781FDC57238DAB955DF6D6E8400CEC5ACBE706 options { directory "/var/cache/bind"; dnssec-enable yes; dnssec-validation yes; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { ::1; }; listen-on { 127.0.0.1; }; allow-recursion { 127.0.0.1; ::1; }; }; include "/etc/bind/bind.keys"; When I do a dig +dnssec . | grep ";; flags:" I get ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 this looks as if its working. There is no forwarding. Paul
On 2018-04-11 04:10, Paul Templeton wrote:
When I do a dig +dnssec . | grep ";; flags:" I get ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 this looks as if its working.
Just to be safe, you could also check the rest of the dig output and /etc/resolv.conf (or relevant resolver configuration on your system) to make sure your BIND is being used. The flags look fine, though. Kind regards, Alexander -- PGP Key: https://dietrich.cx/pgp | 0x52FA4EE1722D54EB
Thanx Alexander
Just to be safe, you could also check the rest of the dig output and /etc/resolv.conf (or relevant resolver configuration on your system) to make sure your BIND is being used. The flags look fine, though.
resolv.conf only has 127.0.0.1 and Dig responds from 127.0.0.1 - Caching works as well. I'll update the rest of my exits now. Thanx All Paul
On 12.04.18 13:05, Alexander Dietrich wrote:
Just to be safe, you could also check the rest of the dig output and /etc/resolv.conf (or relevant resolver configuration on your system) to make sure your BIND is being used.
I have seen hosters where /etc/resolv.conf is overwritten whenever the system reboots, and in these cases I used the following: # Add this to /etc/tor/torrc ServerDNSResolvConfFile /etc/tor/resolv.conf # /etc/tor/resolv.conf nameserver 127.0.0.1 # IPv6 alternative #nameserver ::1 -Ralph
Great initiative! Personally I would also see some sort of "DANE" for Tor-relays in the future too, but that is a request for another thread. / Jonathan
On 12.04.18 13:05, Alexander Dietrich wrote:
Just to be safe, you could also check the rest of the dig output and /etc/resolv.conf (or relevant resolver configuration on your system) to make sure your BIND is being used. I have seen hosters where /etc/resolv.conf is overwritten whenever the system reboots, and in these cases I used the following:
# Add this to /etc/tor/torrc ServerDNSResolvConfFile /etc/tor/resolv.conf
# /etc/tor/resolv.conf nameserver 127.0.0.1 # IPv6 alternative #nameserver ::1
-Ralph
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
as a quick and easy test you can always try to resolve a hostname with known invalid DNSSEC records: www.dnssec-failed.org -- https://mastodon.social/@nusenu twitter: @nusenu_
Dhalgren Tor:
Respectfully, I disagree.
https://lists.torproject.org/pipermail/tor-relays/2015-October/007904.html wrote:
Spent a few minutes activating the DNSSEC trust-anchor for 'unbound'.
Ran 'dig' on a few signed domains and observed that queries that took under 50 milliseconds without went to 2000 milliseconds with.
My attitude toward DNSSEC has deteriorated steadily over time and this finishes it off for me. It's simply not worth the cost. Many serious folk have commented in detail on what a horror show it is.
Disabled it on the exit.
Without DNSSEC, 'unbound' has been reporting:
server stats for thread 0: 1296326 queries, 454942 answers from cache, 841384 recursions, 0 prefetch server stats for thread 0: requestlist max 112 avg 28.1553 exceeded 0 jostled 0 histogram of recursion processing times [25%]=0.00737672 median[50%]=0.0492239 [75%]=0.144125
I'll do some comparisons over some weeks or months and come back to this once I have some more data to show. -- https://mastodon.social/@nusenu twitter: @nusenu_
participants (6)
-
Alexander Dietrich -
Dhalgren Tor -
Jonathan Sélea -
nusenu -
Paul Templeton -
Ralph Seichter