1.1.1.1 fails to resolve nld.com.vn at the first attempt

After the first attempt, I tried clearing the DNS cache and retry and it could resolve the domain.
It also happens with cdn.tuoitre.vn on https://tuoitre.vn.

Here is the output from the diagnostic tool:

Here are the outputs from the commands (it refused the query with -class=chaos so I removed it):

nslookup nld.com.vn 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
Name:    nld.com.vn
Addresses:  123.30.151.98
          14.225.10.22

nslookup nld.com.vn 1.0.0.1
Server:  one.one.one.one
Address:  1.0.0.1

Non-authoritative answer:
Name:    nld.com.vn
Addresses:  123.30.151.98
          14.225.10.22

nslookup nld.com.vn 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    nld.com.vn
Addresses:  14.225.10.22
          123.30.151.98

nslookup -type=txt nld.com.vn 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

DNS request timed out.
    timeout was 2 seconds.
*** Request to one.one.one.one timed-out

nslookup -type=txt nld.com.vn 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

*** one.one.one.one can't find nld.com.vn: Server failed

nslookup -type=txt nld.com.vn 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
nld.com.vn      text =

        "google-site-verification=-7NfiRQyPK2WQ-H2GFRGa8M7kTKuweg-oWV8b8LZi0g"
nld.com.vn      text =

        "google-site-verification=wD_Y0LzT3O2ODZyqJvXFWkU6Pk-EmXOY_AMXnrPmDTA"
nld.com.vn      text =

        "google-site-verification=LH4ICnh1vJV5mcZLRIt8VD6up5b5qTKZKZ4JiUwRRaY"
nld.com.vn      text =

        "MS=ms94578217"
nld.com.vn      text =

        "v=spf1 include:spf.protection.outlook.com -all"

(root)  ??? unknown type 41 ???

nslookup -type=txt nld.com.vn 1.0.0.1
Server:  one.one.one.one
Address:  1.0.0.1

Non-authoritative answer:
nld.com.vn      text =

        "google-site-verification=-7NfiRQyPK2WQ-H2GFRGa8M7kTKuweg-oWV8b8LZi0g"
nld.com.vn      text =

        "google-site-verification=wD_Y0LzT3O2ODZyqJvXFWkU6Pk-EmXOY_AMXnrPmDTA"
nld.com.vn      text =

        "google-site-verification=LH4ICnh1vJV5mcZLRIt8VD6up5b5qTKZKZ4JiUwRRaY"
nld.com.vn      text =

        "MS=ms94578217"
nld.com.vn      text =

        "v=spf1 include:spf.protection.outlook.com -all"

(root)  ??? unknown type 41 ???

nslookup -type=txt whoami.cloudflare.com ns3.cloudflare.com
Server:  ns3.cloudflare.com
Address:  162.159.0.33

Non-authoritative answer:
whoami.cloudflare.com   text =

        "162.159.0.0"

(root)  ??? unknown type 41 ???

Here is the analysis: nld.com.vn | DNSViz

Also happens with kenh14.vn and kenh14cdn.com. Other resolvers work just fine.

The cdn.tuoitre.vn itself works just fine.

The actual problem is the CNAME to cdn-tuoitre.cdn.vccloud.vn.

DNS resolvers will be sending multiple DNS queries when you use CNAME, and in your case, it will be like:

  1. → Hello, where is cdn.tuoitre.vn?

  2. ← Try cdn-tuoitre.cdn.vccloud.vn!

  3. → Hello, where is cdn-tuoitre.cdn.vccloud.vn?

  4. ← It is <IP address(es)>!

Now, for all the domains you listed:

ALL of the mentioned domains share the same patterns, - they’re all using the three name servers:

ns6.synerfy.vn
ns7.synerfy.vn
ns8.synerfy.vn

I see quite a bit of both high latency, as well as packet loss, when going towards both ns7 and ns8, from multiple locations across the world.

For ns7 and ns8, I see consistent patterns that the very first query is timing out, just like you’re indicating.

ns6 (which is in the US) seems to be much more reliable across the world, although, it seems like there are some ISP’s in China, that has a little bit of packet loss towards it.

It therefore looks like (some of) synerfy.vn’s name servers (at least, the two in Vietnam) are highly unreliable, and the that the hit and miss with connectivity to ns7 and ns8 is causing this to happen.

So unless synerfy.vn is raising the quality of ns7 and ns8 somehow, I’m unfortunately afraid that you should actually expect to see such inconsistent results.

5 Likes

Thanks @DarkDeviL
I found an old thread. It appears to be the same issue.

You’re welcome! :slight_smile:

Extensive firewall / security systems, or geographical blocks as mentioned over there aren’t uncommon though.

That said, -

I am also thinking that it is the exact same issue.

My guess would be that the unreliability must have been way more consistent for specific countries/regions back then, since I suggested the geographical blocks.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.