Using bind with Tor/i2p and other DarkNet Domains

If you look at privoxy's forwarding feature, one line there:

forward-socks4a .onion  127.0.0.1:9050 .

is responsible for forwarding all traffic to .onion websites through Tor. The tor page describes an iptables-level solution to redirect DNS requests over Tor but, in some cases, it may be desirable to just use .onion request with Tor instead of making all DNS queries through Tor.

In order to do that, bind allows you to configure a forwarder zone (perhaps one of the few cases where it is justified).

From /etc/bind/named.conf.local:

zone "onion" {
        type forward;
        forwarders { 127.0.0.2; };
        forward only;
};

This would make any .onion requests to the IP address 127.0.0.2 on port 53. Thus, we configure Tor, to listen on that address and port for DNS querries:

From /etc/tor/torrc:

DNSPort 53
DNSListenAddress 127.0.0.2

The result will be that bind will resolve all .onion queries through Tor, and anything else through "clearnet".

The same procedure can be repeated for any DarkNet relays, proxying DNS on loopbacks: 127.0.0.1, 127.0.0.2, 127.0.0.3, etc…

Turn EDNS Off

Described in RFC2671, it is intended as a set of extensions to DNS that allows passing UDP packets larger than 512 bytes between EDNS-enabled nameservers.

Many public DNS servers do not implement EDNS - excluding root servers, which just increases DNS traffic over the network needlessly. Misconfigured firewalls or cheap routers may have issues with the increased UDP packet length.

The result is that log-files get jammed with messages such as 1):

success resolving 'isc.org/ANY' (in 'isc.org'?) after reducing the advertised EDNS UDP packet size to 512 octets

and causes bind to fall-back to ''512'' byte packets (RFC1035).

Security-wise, as the RFC2671 puts it: Requestor-side specification of the maximum buffer size may open a new DNS denial of service attack if responders can be made to send messages which are too large for intermediate gateways to forward, thus leading to potential ICMP storms between gateways and responders.

To disable EDNS, you need to add the following two lines:

server ::/0 { edns no; };        
server 0.0.0.0/0 { edns no; }; 

to the named.conf configuration file - note that it is not to be placed in the options block, but separately, like a zone.

Updating Dynamic Dns Zone Files

Zone files that are declared dynamic with a journal attached such as zones that are dynamically updated cannot be edited directly without shutting down bind - however, a better solution is to first pause dynamic updates by issuing the command:

rndc freeze zone.tld

then making any changes necessary to the zone file (remembering to update the serial), and once the changes are done, unpausing the zone updates by issuing the command:

rndc thaw zone.tld

When issuing the last command, isc-bind will reload the zone files, check the serial number and flush the journal file (.jnl) if necessary.

Updating Records without Restarting Bind

nsupdate can be used to add or remove zones without having to manually edit the zone files. This can be particularly useful in case a hostname has changed and you would like to receive the DDNS update from DHCPd. Provided that you have bind configured with an authentication key (located at /etc/bind/rndc.key) and that the key is allowed to update the zone then the following procedure can be used to remove entries.

In order to remove a PTR record such as:

12    PTR    myhost.home.

the following invocation of nsupdate,

nsupdate -v -k /etc/bind/rndc.key
> server 192.168.1.1
> zone 1.168.192.in-addr.arpa.
> update delete 12.1.168.192.in-addr.arpa. ptr myhost.home.
> send
> quit

will:

  1. set the server to be updated to 192.168.1.1,
  2. specify that the zone to be updated will be 1.168.192.in-addr.arpa. (the reverse of 192.168.1.1),
  3. send a request to delete the reverse entry for myhost.home with the address 192.168.1.12 whose full qualified reverse address is 12.1.168.192.in-addr.arpa.

In order to remove an A record:

myhost.home    A    192.168.1.12

he following invocation of nsupdate,

nsupdate -v -k /etc/bind/rndc.key
> server 192.168.1.1
> zone home
> update delete myhost.home a
> send
> quit

will:

  1. set the server to be updated to 192.168.1.1,
  2. set the zone to be updated to home,
  3. send a request to delete the A record of myhost.home.

After updating the zone, the command:

rndc reload

can be used to make bind reload the zones.

1)
not a joke, ISC, "the authors of BIND" do not have it configured properly

fuss/bind.txt · Last modified: 2017/12/27 22:37 by office

Access website using Tor Access website using i2p


For the copyright, license, warranty and privacy terms for the usage of this website please see the license, privacy and plagiarism pages.