What's new

Unbound - Authoritative Recursive Caching DNS Server

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
First I would like to thank the amazing job everyone is doing. Thanks to you all and Martineau script unbound is running perfectly for a week now.

So much so I would like to use unbound as my private dns on my android devides, but I am not sure on how to proceed.
I wonder if there is a way for unbound to listen to the port 853 on WAN, and since I have the asuscomm DDNS setup with Let's encrypt ssl certificate I should set /jffs/.le/example.asuscomm.com/example.asuscomm.com.cer and /jffs/.le/example.asuscomm.com/example.asuscomm.com.key as either ssl_certificate/tls-service-pem and ssl_certificate_key/tls-service-key.

I found these 2 posts but I am not sure if they are up to date.
Nginx Verification Command
Code:
/opt/etc/init.d/S80nginx test
nginx: the configuration file /opt/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /opt/etc/nginx/nginx.conf test is successful

Code:
load_module /opt/lib/nginx/ngx_stream_module.so;
user  nobody;
worker_processes  1;
events { }
stream {
    upstream dns-servers {
        server    127.0.0.1:53535;

    }

    server {
        listen 1.2.3.4:853 ssl;
        proxy_pass dns-servers;

        ssl_certificate      /opt/etc/nginx/ssl/dot-server.crt;
        ssl_certificate_key  /opt/etc/nginx/ssl/dot-server.key;
   
        ssl_protocols       TLSv1.2 TLSv1.3;
        ssl_ciphers         ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256;
        ssl_prefer_server_ciphers       on;

        ssl_session_timeout             1d;
        ssl_session_tickets             off;
        ssl_handshake_timeout    10s;
        ssl_session_cache        shared:DoT:10m;
    }
}
I need you to see if it's working. I don't know where to check.


Apparently, after version 1.6.7, unbound does its own DNS-over-TLS scenario
https://dnsprivacy.org/wiki/display/DP/Using+Unbound+as+a+DNS+Privacy+server
Code:
# listen on all interfaces on port 853, answer queries from the local subnet.
        interface: 0.0.0.0@853
        interface: ::0@853

        tls-service-key: "<path_to_private_key>"
        tls-service-pem: "<path_to_certifcate_file>"
        tls-port: 853
        incoming-num-tcp: 1000 # Number of simultaneous incoming TCP connections per thread to allow
        # Listen on UDP but still issues queries upstream over UDP.
        # Only available in 1.6.7 and later
        udp-upstream-without-downstream: yes
        qname-minimisation: yes
 
First I would like to thank the amazing job everyone is doing. Thanks to you all and Martineau script unbound is running perfectly for a week now.

So much so I would like to use unbound as my private dns on my android devides, but I am not sure on how to proceed.
I wonder if there is a way for unbound to listen to the port 853 on WAN, and since I have the asuscomm DDNS setup with Let's encrypt ssl certificate I should set /jffs/.le/example.asuscomm.com/example.asuscomm.com.cer and /jffs/.le/example.asuscomm.com/example.asuscomm.com.key as either ssl_certificate/tls-service-pem and ssl_certificate_key/tls-service-key.

I found these 2 posts but I am not sure if they are up to date.
From what I notice, he is already working with certificates. It's a good start. I paused the attempt with the unbound in TLS mode. I will return this proposal.
 
From what I notice, he is already working with certificates. It's a good start. I paused the attempt with the unbound in TLS mode. I will return this proposal.

So I am "almost" able to make it work. My android device is able to connect to the private DNS using my asus DDNS FQDN but only when I am connect to my LAN as soon I change to the mobile data it can no longer connect. It might be because I did something wrong when creating the iptables rules or forgot to set something so I count on your help with that.

I have a AC86U with asus merlin 384.17 and Skynet and unbound installed with amtm. I will describe what I have changed bellow, and I have a few question:
  1. Is there a way to listen only to the WAN interface instead of all? i.e. 0.0.0.0
  2. Is that a good security practice or is it better just leave listening to al?
  3. How to correctly open port 853 on iptables?
  4. Why all my local domain get DNS_PROBE_FINISHED_NXDOMAIN when I have the private DNS activated(I am connected to my local lan)?

The changes I made to the unbound.conf generated by unbound_manager was adding the "tls-port", additional interface 0.0.0.0:53, commented out the self-signed tls-cert-bundle and use tls-service-key and tls-service-pem using the files Lets Encrypt create to my asus DDNS. You could just replace the self-signed with the tls-cert-bundle that Lets Encrypt generate if you want to keep the file short.

Code:
#tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"  # v1.01 as per @dave14305 minimal config
# Enable DoT to be used
tls-port: 853
interface: 0.0.0.0@853
tls-service-key: "/etc/key.pem" # I look through all the source code to see how the system copy the files from lets encrypt but could not find how. I just know that this file is the same as /jffs/.le/example.asuscomm.com/example.asuscomm.com.key because I diff them.
tls-service-pem: "/etc/cert.pem" # I look through all the source code to see how the system copy the files from lets encrypt but could not find how. I just know that this file is the same as /jffs/.le/example.asuscomm.com/fulchain.pem because I diff them.
#tls-cert-bundle: "/etc/server.pem" #You could use this file if you want to keep the config file as short as possible. This is the only one I could find on the source code and is basically key.pem + cert.pem

And these are the change I made to iptables:
Code:
iptables -I INPUT -p tcp --destination-port 853 -j ACCEPT
ptables -I INPUT -p udp --destination-port 853 -j ACCEPT

iptables -S | grep 853
-A INPUT -p udp -m udp --dport 853 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 853 -j ACCEPT
-A FORWARD -i br0 -p tcp -m tcp --dport 853 -j DNSFILTER_DOT
 
How to correctly open port 853 on iptables?
I don't know the 100% safe way to open the firewall, but you need to be sure to insert your ACCEPT rules before the last DROP or logdrop in the INPUT chain. Look at iptables -S INPUT and see if your rules are before or after that final drop command.

EDIT: now I see you did use -I INPUT so it would insert at the top of the chain. No idea then.
 
It seems that they are.
Code:
iptables -S INPUT
-P INPUT ACCEPT
-A INPUT -p udp -m udp --dport 853 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 853 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -i eth0 -p igmp -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j INPUT_PING
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j logdrop
-A INPUT ! -i br0 -j PTCSRVWAN
-A INPUT -i br0 -j PTCSRVLAN
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -m state --state NEW -j OVPN
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -p icmp -j INPUT_ICMP
-A INPUT -j logdrop

Also, I just did a test with getdnsapi.net when using options "return_call_reporting" I get "status": GETDNS_RESPSTATUS_ALL_TIMEOUT, and when using "dnssec_return_status" and got the answer "status":GETDNS_RESPSTATUS_GOOD
 
Last edited:
It seems that they are.
Code:
iptables -S INPUT
-P INPUT ACCEPT
-A INPUT -p udp -m udp --dport 853 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 853 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -i eth0 -p igmp -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j INPUT_PING
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j logdrop
-A INPUT ! -i br0 -j PTCSRVWAN
-A INPUT -i br0 -j PTCSRVLAN
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -m state --state NEW -j OVPN
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -p icmp -j INPUT_ICMP
-A INPUT -j logdrop

Also, I just did a test with getdnsapi.net when using options "return_call_reporting" I get "status": GETDNS_RESPSTATUS_ALL_TIMEOUT, and when using "dnssec_return_status" and got the answer "status":GETDNS_RESPSTATUS_GOOD
Very good. The problem now is external listening, DDNS. With Unbound it's solved. How did you generate your certificates?
 
I use the option "Free Certificate from Let's Encrypt" Under Wan > DDNS and I used asus ddns. After checking almost everything on the merlin github I don't know how is done, but I know that the lets encrypt fullchain.pem is copied as /etc/cert.pem, the domain.key -> /etc/key.pem and /etc/server.pem can be used as tsl-cert-bundle.
@rgnldo Any idea on how to fix the external listening problem?
 
Without the Unbound TLS environment enabled, can you access?
I am not usre how to test the accessibility of the port 853. I know that the DDNS is accessible because I have a openvpn server running on my router and I use the ddns on all my ovpn config files.
As you can see on my "iptables -S INPUT" output I have a similar rule "-A INPUT -p udp -m udp --dport 1194 -j ACCEPT" to the port my ovpn server uses.

I am sorry if I didn't help much, I am a noob in network and scripting language.

One thing I notice is that the port 853 does not show up on the PREROUTING chain.
 
Do you see any hits on your rule if you run this:
Code:
iptables -nvL INPUT
Also make sure your unbound.conf access-control: is open to all IP space for the WAN.
 
Do you see any hits on your rule if you run this:
Code:
iptables -nvL INPUT
Apparently yes but only on TCP, assuming this means that there was some traffic on that port " 3497 373K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:853"

Code:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination        
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:853
 3497  373K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:853
 1467  120K ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:1194
  539 19404 ACCEPT     2    --  eth0   *       0.0.0.0/0            0.0.0.0/0          
20444 1713K INPUT_PING  icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
  20M   17G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
 4138  178K logdrop    all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
3515K  772M PTCSRVWAN  all  --  !br0   *       0.0.0.0/0            0.0.0.0/0          
 686K   99M PTCSRVLAN  all  --  br0    *       0.0.0.0/0            0.0.0.0/0          
 686K   99M ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW
3510K  770M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0            state NEW
 5274 1322K OVPN       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW
    1   383 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68
    0     0 INPUT_ICMP  icmp --  *      *       0.0.0.0/0            0.0.0.0/0          
 5273 1322K logdrop    all  --  *      *       0.0.0.0/0            0.0.0.0/0
 
Apparently yes but only on TCP, assuming this means that there was some traffic on that port " 3497 373K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:853"

Code:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination       
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:853
 3497  373K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:853
 1467  120K ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:1194
  539 19404 ACCEPT     2    --  eth0   *       0.0.0.0/0            0.0.0.0/0         
20444 1713K INPUT_PING  icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
  20M   17G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
 4138  178K logdrop    all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
3515K  772M PTCSRVWAN  all  --  !br0   *       0.0.0.0/0            0.0.0.0/0         
 686K   99M PTCSRVLAN  all  --  br0    *       0.0.0.0/0            0.0.0.0/0         
 686K   99M ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW
3510K  770M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0            state NEW
 5274 1322K OVPN       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW
    1   383 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68
    0     0 INPUT_ICMP  icmp --  *      *       0.0.0.0/0            0.0.0.0/0         
 5273 1322K logdrop    all  --  *      *       0.0.0.0/0            0.0.0.0/0
Also make sure your unbound.conf access-control: 0.0.0.0/0 allow
 
This is where I also suggest running Skynet to block known malware IPs from reaching your open ports.
 
@dave14305 @rgnldo Is there a way to set unbound to listen only the WAN interface on the 853 instead of 0.0.0.0@853? Would that be better?

Also make sure your unbound.conf access-control: 0.0.0.0/0 allow
Good catch I will check that.
This is where I also suggest running Skynet to block known malware IPs from reaching your open ports.

I already have Skynet installed. Is there any special setting I should do to protect the specific 853 port?
 
Is there a way to set unbound to listen only the WAN interface on the 853 instead of 0.0.0.0@853? Would that be better?
It would be better, but does your WAN IP change often? You would need to trigger an unbound.conf update from ddns-start script I think. Complicated.
 
It would be better, but does your WAN IP change often? You would need to trigger an unbound.conf update from ddns-start script I think. Complicated.
If that help to improve my router security I would be willing to do it and submit a PR to Martineau script.
I am just not sure what is the DDNS workflow on the firmware, I try to find the ddns-start but I couldn't.

Should the config look something like this? Also, is there any special settings on skynet before opening the port 853?
Code:
interface: WAN_IP@853
access-control: WAN_IP/32 allow
 
If that help to improve my router security I would be willing to do it and submit a PR to Martineau script.
I am just not sure what is the DDNS workflow on the firmware, I try to find the ddns-start but I couldn't.

Should the config look something like this? Also, is there any special settings on skynet before opening the port 853?
Code:
interface: WAN_IP@853
access-control: WAN_IP/32 allow
access-control: would still need to be 0.0.0.0/0 allow unless you can identify the range of possible WAN IPs when your Android phone is on cellular networking.

https://github.com/RMerl/asuswrt-merlin.ng/wiki/User-scripts#ddns-start
This explains the /jffs/scripts/ddns-start script you would need to create. But it would take some fancy sed commands to replace the WAN IP in unbound.conf with $1 in the ddns-start script. Quite possible, but takes some work to do reliably. Martineau is very good at swapping values in the unbound.conf script.

Does the DoT connection work yet from the WAN? Once it does, you could enable logging to see the source IPs from the Internet to determine if they fall within a more specific IP range.

Skynet will block bad IPs regardless of port, so no special configuration required.
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top