What's new
  • 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!

RT-AC68U 380.61 Issue with local DNS when DNSSec is turned on

swg0101

Occasional Visitor
Whenever DNSSec is enabled in LAN -> DHCP Server -> Enable DNSSec support, DNSmasq seems to not want to listen on 127.0.0.1. This breaks any local router name resolution since /etc/resolv.conf is set to use 127.0.0.1. As soon as that option is disabled, or the "dnssec" parameter is removed from the /etc/dnsmasq.conf file, local name resolution starts working again. Regardless of whether dnssec is enabled, dnsmasq listens on br0 just fine and name resolution from WLAN/LAN devices works flawlessly.
Has anyone experienced this issue? I was not able to use entware until disabling DNSSec since this breaks DNS on the router with no DNS resolution.
 
Works for me.

Code:
admin@Stargate88:/tmp/home/root# nslookup camelot.lostrealm.lan
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain

Name:      camelot.lostrealm.lan
Address 1: 192.168.10.100 Camelot.lostrealm.lan

admin@Stargate88:/tmp/home/root# nslookup www.ibm.com
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain

Name:      www.ibm.com
Address 1: 184.84.34.194 a184-84-34-194.deploy.static.akamaitechnologies.com
 
Weird, now I tried it again and it works. Will watch it I guess...
Anyways, I do notice that in the conf file there is a line:
servers-file=/tmp/resolv.dnsmasq
and inside the file there are DNS6 servers pushed by the ISP (Comcast):

server=2001:558:feed::1
server=2001:558:feed::2

even though the option was set to not "connect to DNS servers automatically" and Google's 8.8.8.8 and 8.8.4.4 was used instead.

I ended up having to do this to plug the leak... Any ideas?

#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh

pc_replace "servers-file=/tmp/resolv.dnsmasq" "" $CONFIG
 
Looks like it stopped working again - what's weird though is that the dig command from bind-tools works just fine, but the built-in tools don't.
A tcpdump on interface lo shows that no query was actually sent when I do the nslookup, but this works fine for dig (although with some delay).
I wonder if there is some kind of firewall problem perhaps that's blocking the request...

swg0101@RT:/tmp/home/root# nslookup o1.com
Server: 127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain

nslookup: can't resolve 'o1.com'
swg0101@RT:/tmp/home/root# dig o1.com

; <<>> DiG 9.9.8-P4 <<>> o1.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38016
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;o1.com. IN A

;; ANSWER SECTION:
o1.com. 599 IN A 66.81.32.30

;; Query time: 80 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 16 20:13:45 UTC 2016
;; MSG SIZE rcvd: 51

swg0101@RT:/tmp/home/root# ping o1.com
ping: bad address 'o1.com'
 
I wonder if wred (supposedly the URL filtering function for AiProtection) is causing DNS to lock up locally, as it looks like there are tons of requests to the local DNS that does not appear to be replied to.

Code:
swg0101@RT:/tmp/home/root# lsof -nPi | grep wred
wred      1276 swg0101    6u  IPv4 451481      0t0  UDP 127.0.0.1:44386->127.0.0.1:53
wred      1276 swg0101   12u  IPv4 451483      0t0  UDP 127.0.0.1:56632->127.0.0.1:53
wred      1276 swg0101   13u  IPv4 451477      0t0  UDP 127.0.0.1:49235->127.0.0.1:53
wred      1276 swg0101   14u  IPv4 451480      0t0  UDP 127.0.0.1:60242->127.0.0.1:53
wred      1276 swg0101   15u  IPv4 451478      0t0  UDP 127.0.0.1:45685->127.0.0.1:53
wred      1276 swg0101   16u  IPv4 451479      0t0  UDP 127.0.0.1:39469->127.0.0.1:53
wred      1276 swg0101   17u  IPv4 451476      0t0  UDP 127.0.0.1:56781->127.0.0.1:53
wred      1276 swg0101   18u  IPv4 451482      0t0  UDP 127.0.0.1:40090->127.0.0.1:53
wred      1277 swg0101    6u  IPv4 451481      0t0  UDP 127.0.0.1:44386->127.0.0.1:53
wred      1277 swg0101   12u  IPv4 451483      0t0  UDP 127.0.0.1:56632->127.0.0.1:53
wred      1277 swg0101   13u  IPv4 451477      0t0  UDP 127.0.0.1:49235->127.0.0.1:53
wred      1277 swg0101   14u  IPv4 451480      0t0  UDP 127.0.0.1:60242->127.0.0.1:53
wred      1277 swg0101   15u  IPv4 451478      0t0  UDP 127.0.0.1:45685->127.0.0.1:53
wred      1277 swg0101   16u  IPv4 451479      0t0  UDP 127.0.0.1:39469->127.0.0.1:53
wred      1277 swg0101   17u  IPv4 451476      0t0  UDP 127.0.0.1:56781->127.0.0.1:53
wred      1277 swg0101   18u  IPv4 451482      0t0  UDP 127.0.0.1:40090->127.0.0.1:53
wred      1278 swg0101    6u  IPv4 451481      0t0  UDP 127.0.0.1:44386->127.0.0.1:53
wred      1278 swg0101   12u  IPv4 451483      0t0  UDP 127.0.0.1:56632->127.0.0.1:53
wred      1278 swg0101   13u  IPv4 451477      0t0  UDP 127.0.0.1:49235->127.0.0.1:53
wred      1278 swg0101   14u  IPv4 451480      0t0  UDP 127.0.0.1:60242->127.0.0.1:53
wred      1278 swg0101   15u  IPv4 451478      0t0  UDP 127.0.0.1:45685->127.0.0.1:53
wred      1278 swg0101   16u  IPv4 451479      0t0  UDP 127.0.0.1:39469->127.0.0.1:53
wred      1278 swg0101   17u  IPv4 451476      0t0  UDP 127.0.0.1:56781->127.0.0.1:53
wred      1278 swg0101   18u  IPv4 451482      0t0  UDP 127.0.0.1:40090->127.0.0.1:53
wred      1281 swg0101    6u  IPv4 451481      0t0  UDP 127.0.0.1:44386->127.0.0.1:53
wred      1281 swg0101   12u  IPv4 451483      0t0  UDP 127.0.0.1:56632->127.0.0.1:53
wred      1281 swg0101   13u  IPv4 451477      0t0  UDP 127.0.0.1:49235->127.0.0.1:53
wred      1281 swg0101   14u  IPv4 451480      0t0  UDP 127.0.0.1:60242->127.0.0.1:53
wred      1281 swg0101   15u  IPv4 451478      0t0  UDP 127.0.0.1:45685->127.0.0.1:53
wred      1281 swg0101   16u  IPv4 451479      0t0  UDP 127.0.0.1:39469->127.0.0.1:53
wred      1281 swg0101   17u  IPv4 451476      0t0  UDP 127.0.0.1:56781->127.0.0.1:53
wred      1281 swg0101   18u  IPv4 451482      0t0  UDP 127.0.0.1:40090->127.0.0.1:53
wred      1282 swg0101    6u  IPv4 451481      0t0  UDP 127.0.0.1:44386->127.0.0.1:53
wred      1282 swg0101   12u  IPv4 451483      0t0  UDP 127.0.0.1:56632->127.0.0.1:53
wred      1282 swg0101   13u  IPv4 451477      0t0  UDP 127.0.0.1:49235->127.0.0.1:53
wred      1282 swg0101   14u  IPv4 451480      0t0  UDP 127.0.0.1:60242->127.0.0.1:53
wred      1282 swg0101   15u  IPv4 451478      0t0  UDP 127.0.0.1:45685->127.0.0.1:53
wred      1282 swg0101   16u  IPv4 451479      0t0  UDP 127.0.0.1:39469->127.0.0.1:53
wred      1282 swg0101   17u  IPv4 451476      0t0  UDP 127.0.0.1:56781->127.0.0.1:53
wred      1282 swg0101   18u  IPv4 451482      0t0  UDP 127.0.0.1:40090->127.0.0.1:53
wred      1283 swg0101    6u  IPv4 451481      0t0  UDP 127.0.0.1:44386->127.0.0.1:53
wred      1283 swg0101   12u  IPv4 451483      0t0  UDP 127.0.0.1:56632->127.0.0.1:53
wred      1283 swg0101   13u  IPv4 451477      0t0  UDP 127.0.0.1:49235->127.0.0.1:53
wred      1283 swg0101   14u  IPv4 451480      0t0  UDP 127.0.0.1:60242->127.0.0.1:53
wred      1283 swg0101   15u  IPv4 451478      0t0  UDP 127.0.0.1:45685->127.0.0.1:53
wred      1283 swg0101   16u  IPv4 451479      0t0  UDP 127.0.0.1:39469->127.0.0.1:53
wred      1283 swg0101   17u  IPv4 451476      0t0  UDP 127.0.0.1:56781->127.0.0.1:53
wred      1283 swg0101   18u  IPv4 451482      0t0  UDP 127.0.0.1:40090->127.0.0.1:53
wred      1284 swg0101    6u  IPv4 451481      0t0  UDP 127.0.0.1:44386->127.0.0.1:53
wred      1284 swg0101   12u  IPv4 451483      0t0  UDP 127.0.0.1:56632->127.0.0.1:53
wred      1284 swg0101   13u  IPv4 451477      0t0  UDP 127.0.0.1:49235->127.0.0.1:53
wred      1284 swg0101   14u  IPv4 451480      0t0  UDP 127.0.0.1:60242->127.0.0.1:53
wred      1284 swg0101   15u  IPv4 451478      0t0  UDP 127.0.0.1:45685->127.0.0.1:53
wred      1284 swg0101   16u  IPv4 451479      0t0  UDP 127.0.0.1:39469->127.0.0.1:53
wred      1284 swg0101   17u  IPv4 451476      0t0  UDP 127.0.0.1:56781->127.0.0.1:53
wred      1284 swg0101   18u  IPv4 451482      0t0  UDP 127.0.0.1:40090->127.0.0.1:53
wred      1285 swg0101    6u  IPv4 451481      0t0  UDP 127.0.0.1:44386->127.0.0.1:53
wred      1285 swg0101   12u  IPv4 451483      0t0  UDP 127.0.0.1:56632->127.0.0.1:53
wred      1285 swg0101   13u  IPv4 451477      0t0  UDP 127.0.0.1:49235->127.0.0.1:53
wred      1285 swg0101   14u  IPv4 451480      0t0  UDP 127.0.0.1:60242->127.0.0.1:53
wred      1285 swg0101   15u  IPv4 451478      0t0  UDP 127.0.0.1:45685->127.0.0.1:53
wred      1285 swg0101   16u  IPv4 451479      0t0  UDP 127.0.0.1:39469->127.0.0.1:53
wred      1285 swg0101   17u  IPv4 451476      0t0  UDP 127.0.0.1:56781->127.0.0.1:53
wred      1285 swg0101   18u  IPv4 451482      0t0  UDP 127.0.0.1:40090->127.0.0.1:53
wred      1286 swg0101    6u  IPv4 451481      0t0  UDP 127.0.0.1:44386->127.0.0.1:53
wred      1286 swg0101   12u  IPv4 451483      0t0  UDP 127.0.0.1:56632->127.0.0.1:53
wred      1286 swg0101   13u  IPv4 451477      0t0  UDP 127.0.0.1:49235->127.0.0.1:53
wred      1286 swg0101   14u  IPv4 451480      0t0  UDP 127.0.0.1:60242->127.0.0.1:53
wred      1286 swg0101   15u  IPv4 451478      0t0  UDP 127.0.0.1:45685->127.0.0.1:53
wred      1286 swg0101   16u  IPv4 451479      0t0  UDP 127.0.0.1:39469->127.0.0.1:53
wred      1286 swg0101   17u  IPv4 451476      0t0  UDP 127.0.0.1:56781->127.0.0.1:53
wred      1286 swg0101   18u  IPv4 451482      0t0  UDP 127.0.0.1:40090->127.0.0.1:53
wred      1287 swg0101    6u  IPv4 451481      0t0  UDP 127.0.0.1:44386->127.0.0.1:53
wred      1287 swg0101   12u  IPv4 451483      0t0  UDP 127.0.0.1:56632->127.0.0.1:53
wred      1287 swg0101   13u  IPv4 451477      0t0  UDP 127.0.0.1:49235->127.0.0.1:53
wred      1287 swg0101   14u  IPv4 451480      0t0  UDP 127.0.0.1:60242->127.0.0.1:53
wred      1287 swg0101   15u  IPv4 451478      0t0  UDP 127.0.0.1:45685->127.0.0.1:53
wred      1287 swg0101   16u  IPv4 451479      0t0  UDP 127.0.0.1:39469->127.0.0.1:53
wred      1287 swg0101   17u  IPv4 451476      0t0  UDP 127.0.0.1:56781->127.0.0.1:53
wred      1287 swg0101   18u  IPv4 451482      0t0  UDP 127.0.0.1:40090->127.0.0.1:53
wred      1288 swg0101    6u  IPv4 451481      0t0  UDP 127.0.0.1:44386->127.0.0.1:53
wred      1288 swg0101   12u  IPv4 451483      0t0  UDP 127.0.0.1:56632->127.0.0.1:53
wred      1288 swg0101   13u  IPv4 451477      0t0  UDP 127.0.0.1:49235->127.0.0.1:53
wred      1288 swg0101   14u  IPv4 451480      0t0  UDP 127.0.0.1:60242->127.0.0.1:53
wred      1288 swg0101   15u  IPv4 451478      0t0  UDP 127.0.0.1:45685->127.0.0.1:53
wred      1288 swg0101   16u  IPv4 451479      0t0  UDP 127.0.0.1:39469->127.0.0.1:53
wred      1288 swg0101   17u  IPv4 451476      0t0  UDP 127.0.0.1:56781->127.0.0.1:53
wred      1288 swg0101   18u  IPv4 451482      0t0  UDP 127.0.0.1:40090->127.0.0.1:53

When I do a tcpdump -nni lo, I would see queries for rgom10-en.url.trendmicro.com when local DNS lookups are working, but when 127.0.0.1 stops responding to requests, it looks like that tcpdump no longer shows rgom10-en.url.trendmicro.com DNS queries. Probably will continue to poke around there...
 
I think I figured the problem out. The problem is with Trend Micro's URL filtering service. If I do a killall wred, then DNS lookup locally works again after a couple seconds. Running wred -B again will cause DNS to lock up after a couple minutes. There are a couple issues on hand here (this is using the 380.62 beta on my RT-AC68U):

1. The wred process makes a DNS query to rgom10-en.url.trendmicro.com for every URL visited (this could easily go up to hundreds if you look at tcpdump).
2. The A record that rgom10-en.url.trendmicro.com translates to, a151.g.akamai.net, only has a TTL of 20 seconds (this means the upstream DNS gets DoSed with these concurrent queries before dnsmasq can locally cache them for 20 seconds before the next DoS batch goes out again).
3. Google DNS (my upstream DNS @ 8.8.8.8, 8.8.4.4) throttles the rate at which DNS can be requested, and some of the requests may not receive a response if the outgoing rate is too fast. This may cause wred to lock up waiting for the DNS query to return.
4. wred makes a HTTP connection to rgom10-en.url.trendmicro.com at port 80 for every URL visited. The connection requests a URL status, waits for a response, and then closes the connection (the connection is not reused). The number of connections can easily go up to hundreds at a time.
5. Every single time a connection is closed, the connection is placed in the TIME_WAIT state.
6. The maximum number of connections allowed in the TIME_WAIT state is default 4096 (/proc/sys/net/ipv4/tcp_max_tw_buckets).
7. The number of seconds before a connection times out in the TIME_WAIT state is 2 minutes (120 seconds - /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait).
8. The number of connections cause the time wait bucket table to overflow (see /tmp/syslog.log):
Code:
Sep 18 11:35:03 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:08 kernel: net_ratelimit: 259 callbacks suppressed
Sep 18 11:35:08 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:38 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:38 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:38 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:38 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:38 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:38 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:38 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:38 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:38 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:47 kernel: net_ratelimit: 35 callbacks suppressed
Sep 18 11:35:47 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:47 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:47 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:47 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:47 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:47 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:47 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:47 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:47 kernel: TCP: time wait bucket table overflow
Sep 18 11:35:48 kernel: TCP: time wait bucket table overflow

To workaround this issue, I did the following (theoretically Trend Micro should really plan these connections more carefully):


/jffs/scripts/dnsmasq.postconf:
Code:
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh

pc_replace "servers-file=/tmp/resolv.dnsmasq" "" $CONFIG
echo '65535' > /proc/sys/net/ipv4/tcp_max_tw_buckets

The script changes the maximum time wait buckets every time dnsmasq is started / restarted, and also stops the router from leaking DNS to my ISP's pushed IPv6 servers.

Add the following lines to /jffs/configs/hosts.add:
184.25.56.254 rgom10-en.url.trendmicro.com
184.25.56.255 rgom10-en.url.trendmicro.com

The 184.25.56.x range is the range closest to me, but you can do a nslookup to see where Akamai sends you. The DNS responses will be different depending on the geolocation you are in.

Asuswrt UI -> Tools -> Other Settings -> TCP Timeout: time_wait -> 15 -> Save.

service restart_dnsmasq

killall wred
, wait 5 seconds.

wred -B

Verify that the TIME_WAIT entries are low using the command (assuming the 184.25.56.x range):
cat /proc/net/ip_conntrack | grep 184.25.56. | grep TIME_WAIT | wc -l
16

Local DNS should start working again after this. Hopefully this helps someone that might be having a similar issue. :)
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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