1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice

Welcome To SNBForums

SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.

If you'd like to post a question, simply register and have at it!

While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!

Issue with resolving DNS for a large result set

Discussion in 'Asuswrt-Merlin' started by viperk1, Nov 15, 2019.

Tags:
  1. viperk1

    viperk1 New Around Here

    Joined:
    Nov 15, 2019
    Messages:
    6
    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
    [email protected]:/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:
    [email protected]:~$ 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

    [email protected]:/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:
    [email protected]:/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
    [email protected]:/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
    [email protected]:~$ 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: Nov 15, 2019
  2. ColinTaylor

    ColinTaylor Part of the Furniture

    Joined:
    Mar 31, 2014
    Messages:
    9,790
    Location:
    UK
    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: Nov 15, 2019
  3. viperk1

    viperk1 New Around Here

    Joined:
    Nov 15, 2019
    Messages:
    6
    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).
     
  4. viperk1

    viperk1 New Around Here

    Joined:
    Nov 15, 2019
    Messages:
    6
    Unfortunately, the behaviour is the same with my ISP DNS.

    [email protected]:~$ 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


    [email protected]:/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.
     
  5. viperk1

    viperk1 New Around Here

    Joined:
    Nov 15, 2019
    Messages:
    6
    I tried again with OpenDNS servers and it works!!! Guess this is my workaround for now until firmware behaviour (or DNS provider behaviour) changes.

    [email protected]:/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
     
  6. RMerlin

    RMerlin Super Moderator

    Joined:
    Apr 14, 2012
    Messages:
    31,532
    Location:
    Canada
    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: Nov 15, 2019
  7. viperk1

    viperk1 New Around Here

    Joined:
    Nov 15, 2019
    Messages:
    6
    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.
     
  8. RMerlin

    RMerlin Super Moderator

    Joined:
    Apr 14, 2012
    Messages:
    31,532
    Location:
    Canada
    This is a resolver issue. It works on newer router models, but fails on older ones (see my updated reply).
     
  9. viperk1

    viperk1 New Around Here

    Joined:
    Nov 15, 2019
    Messages:
    6
    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.
     
  10. RMerlin

    RMerlin Super Moderator

    Joined:
    Apr 14, 2012
    Messages:
    31,532
    Location:
    Canada
    It only affects resolution done on the router itself, it doesn't impact your network clients.
     
  11. sfx2000

    sfx2000 Part of the Furniture

    Joined:
    Aug 11, 2011
    Messages:
    14,288
    Location:
    San Diego, CA
    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