What's new

Issue with resolving DNS for a large result set

  • 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!

viperk1

New Around Here
Hey guys, I've scoured the internet for the past week and have not been able to find anything about this.

Based on what I'm seeing, if there's ever a DNS query that has a response that's bigger than the UDP packet size which means a switch to TCP is required, the router has problems resolving the address. I've tried this on the stock ASUS firmware (3.0.0.4_384_81049-gbd61205), Tomato, and Merlin (384.13) and the behaviour seems the same.

For example, if I SSH into the router and try 'ping ca.secureconnect.me' I get
admin@RT-AC1900P-5F90:/tmp/home/root# ping ca.secureconnect.me
ping: bad address 'ca.secureconnect.me'


But this works perfectly fine on a machine connected to the router:
C:\Users\S>ping ca.secureconnect.me
Pinging ca.secureconnect.me [184.75.210.170] with 32 bytes of data:
Reply from 184.75.210.170: bytes=32 time=47ms TTL=51

Using nslookup on my linux box for the above hostname shows ";; Truncated, retrying in TCP mode" and then all the results. Eg:
s@tanuki:~$ nslookup ca.secureconnect.me
;; Truncated, retrying in TCP mode.
Server: 10.10.10.2
Address: 10.10.10.2#53
Non-authoritative answer:
Name: ca.secureconnect.me
Address: 162.254.132.98
...etc

admin@RT-AC1900P-5F90:/tmp/home/root# nslookup ca.secureconnect.me
Server: 127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain
nslookup: can't resolve 'ca.secureconnect.me'



Pinging/nslookup on a different hostname with a smaller DNS record works in all places and doesn't show any truncation message. Eg:
admin@RT-AC1900P-5F90:/tmp/home/root# ping cavan.secureconnect.me
PING cavan.secureconnect.me (107.181.189.38): 56 data bytes
64 bytes from 107.181.189.38: seq=0 ttl=45 time=99.841 ms
admin@RT-AC1900P-5F90:/tmp/home/root# nslookup cavan.secureconnect.me
Server: 127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain
Name: cavan.secureconnect.me
Address 1: 107.181.189.47
Address 2: 107.181.189.48
Address 3: 107.181.189.34
...etc


C:\Users\S>ping cavan.secureconnect.me
Pinging cavan.secureconnect.me [107.181.189.38] with 32 bytes of data:
Reply from 107.181.189.38: bytes=32 time=92ms TTL=44
s@tanuki:~$ nslookup cavan.secureconnect.me
Server: 10.10.10.2
Address: 10.10.10.2#53
Non-authoritative answer:
Name: cavan.secureconnect.me
Address: 107.181.189.35
...etc

Do other people see the same thing and is there any way to get resolution working for these cases?

If any more information is needed then please let me know!
Thanks so much!
 
Last edited:
What upstream DNS provider are you using? I'm seeing different results from different providers.

For example in response to the initial UDP request, my ISP's servers will set the "truncated" flag but also return the first 29 addresses. Whereas 1.1.1.1 and 8.8.8.8 just set the flag and don't return any records over UDP. Then again querying 9.9.9.9 just returns a SERVFAIL error for that particular domain.

So in my testing it looks like Busybox's nslookup command ignores the truncated flag and returns a "can't resolve" error if the upstream server is 1.1.1.1 or 8.8.8.8.
 
Last edited:
What upstream DNS provider are you using? I'm seeing different results from different providers.

For example in response to the initial UDP request, my ISP's servers will set the "truncated" flag but also return the first 29 addresses. Whereas 1.1.1.1 and 8.8.8.8 just set the flag and don't return any records over UDP. Then again querying 9.9.9.9 just returns a SERVFAIL error for that particular domain.

So in my testing it looks like Busybox's nslookup command ignores the truncated flag and returns a "can't resolve" error if the upstream server is 1.1.1.1 or 8.8.8.8.

Hmm, thanks for that insight! I've actually only tried with google and cloudflare since those are the only ones I've ever used. Let me check with my ISP ones. Strange that they act that way though. I wonder who is operating according to spec (or if both behaviours are allowed).
 
Unfortunately, the behaviour is the same with my ISP DNS.

s@tanuki:~$ nslookup ca.secureconnect.me 64.71.255.198
;; Truncated, retrying in TCP mode.
Server: 64.71.255.198
Address: 64.71.255.198#53
Non-authoritative answer:
Name: ca.secureconnect.me
Address: 162.253.131.66


admin@RT-AC1900P-5F90:/tmp/home/root# nslookup ca.secureconnect.me 64.71.255.198
Server: 64.71.255.198
Address 1: 64.71.255.198 dns.cs.net.rogers.com
nslookup: can't resolve 'ca.secureconnect.me'


Could your share the DNS server that worked for you? If it works on my end then at least that gives me an indication that SOME work and I can try to find a server local to me.
 
I tried again with OpenDNS servers and it works!!! Guess this is my workaround for now until firmware behaviour (or DNS provider behaviour) changes.

admin@RT-AC1900P-5F90:/tmp/home/root# nslookup ca.secureconnect.me 208.67.222.222
Server: 208.67.222.222
Address 1: 208.67.222.222 resolver1.opendns.com
Name: ca.secureconnect.me
Address 1: 184.75.214.122
Address 2: 184.75.215.34 184-75-215-34.amanah.com
Address 3: 184.75.215.58 184-75-215-58.amanah.com
...etc
 
It takes forever to resolve all entries for me, but it eventually does, with no error message.

The router's nslookup is only a very basic implementation provided by Busybox. And the resolver itself will vary between uclibc's implementation (pre-HND models) and glibc (RT-AX88U and RT-AC86U).

EDIT: confirmed, this is an issue in uclibc, not glibc or busybox/nslookup.
 
Last edited:
It takes forever to resolve all entries for me, but it eventually does, with no error message.

The router's nslookup is only a very basic implementation provided by Busybox.
Hi Merlin, so the command nslookup ca.secureconnect.me 1.1.1.1 works as expected for you? I'm stumped. Was that on the latest stable firmware? I'm running 384.13.
 
Hi Merlin, so the command nslookup ca.secureconnect.me 1.1.1.1 works as expected for you? I'm stumped. Was that on the latest stable firmware? I'm running 384.13.

This is a resolver issue. It works on newer router models, but fails on older ones (see my updated reply).
 
This is a resolver issue. It works on newer router models, but fails on older ones (see my updated reply).
Thanks so much! At least we've got to the bottom of this. So unless I upgrade to a new router, this is the behaviour I have to work with.
 
Thanks so much! At least we've got to the bottom of this. So unless I upgrade to a new router, this is the behaviour I have to work with.

It only affects resolution done on the router itself, it doesn't impact your network clients.
 
EDIT: confirmed, this is an issue in uclibc, not glibc or busybox/nslookup.

Yep, can confirm here as well - not busybox, it's the c-library that does the function call...

As @RMerlin mentions, it doesn't affect client lookups (unless that client has a c-lib that has the issue) - glibc should be fine, uClibc-ng 1.0.14 seems to be ok. Had some issues with musl, so might have to investigate a bit more
 

Similar threads

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