AdguardTeam
IPv4/IPv6 and ECS check showing Cloudflare without minilization as NS (in some cases)
Hi,
today I made some checks concerning ECS and NS servers responding and found out, that in some cases, it's somehow responding different from that what I thought.
Would be nice to understand that behaviour and I don't know if it is correct?
If you try:
nslookup -type=TXT whoami.ds.akahelp.net
nslookup -type=TXT whoami.ipv4.akahelp.net
nslookup -type=TXT whoami.ipv6.akahelp.net
and/or:
dig +short TXT whoami.ds.akahelp.net
dig +short TXT whoami.ipv4.akahelp.net
dig +short TXT whoami.ipv6.akahelp.net
Then you can see, that when using the ipv6.akahelp.net domain it resolves only a ns which is at Cloudflare and with no minilization.
In comparison with other DNS providers (for example NextDNS) everything looks (in my undestanding) fine and ok - even when I lookup/dig to ipv6.akahelp.net
Is this 'normal' behaviour?
Could you please show the responses, I don't quite understand what's the problem yet.
Hello there, I'm using AdGuard DNS with private server and found the same issue. I'd like to give some more insight into this issue:
For my testing I'm using the dnslookup tool from @ameshkov (version 1.11.1).
On Windows I'm using the cmd and set the RRTYPE to TXT:
SET RRTYPE=TXT
After that I make a DNS query to "whoami.ipv6.akahelp.net" using DoH from my private AdGuard DNS server
.\dnslookup.exe whoami.ipv6.akahelp.net https://d.adguard-dns.com/dns-query/<privateServerID>
The dnslookup result is always either an answer containing an Cloudflare ip or a REFUSED anwser.
Answer with Cloudflare IP:
dnslookup result (elapsed 2.1156055s):
;; opcode: QUERY, status: NOERROR, id: 14731
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;whoami.ipv6.akahelp.net. IN TXT
;; ANSWER SECTION:
whoami.ipv6.akahelp.net. 60 IN TXT "ns" "2400:cb00:932:1024::ac45:7166"
Answer with status REFUSED:
dnslookup result (elapsed 2.112319s):
;; opcode: QUERY, status: REFUSED, id: 36346
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;whoami.ipv6.akahelp.net. IN TXT
In both cases the resolution takes more than 2 seconds, which seems to be caused by AdGuards timeout value of 2 seconds until it uses the fallback. We know that AdGuard DNS uses Cloudflare as a fallback so I guess AdGuard DNS is somehow not able to resolve "whoami.ipv6.akahelp.net" while "whoami.ipv4.akahelp.net" seems to be no problem.
If you are not familiar with Akamai's DNS Resolver Information Tool (WhoAmI), please have a look at their blog article: Akamai Blog - WhoAmI Tool
In short: The TXT record of the answer returns a record labeled as "ns" which contains the unicast IP address of the requesting recursive resolver. If the recursive resolver sends ECS information along the query, two additional records labeld "ip" and "ecs" will be returned as well.
If we do the same with e.g. NextDNS, the answer will look like this:
dnslookup result (elapsed 100.396ms):
;; opcode: QUERY, status: NOERROR, id: 49842
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;whoami.ipv6.akahelp.net. IN TXT
;; ANSWER SECTION:
whoami.ipv6.akahelp.net. 300 IN TXT "ecs" "2.58.100.0/24/24"
whoami.ipv6.akahelp.net. 300 IN TXT "ns" "2a01:4f8:c0c:fa3f::1"
whoami.ipv6.akahelp.net. 300 IN TXT "ip" "2a01:4f8:c0c:fa3f::1"
From my testing the issue with resolving "whoami.ipv6.akahelp.net" only happens on AdGuard DNS, regardless whether I'm using private DNS Server or public DNS Server (e.g. https://unfiltered.adguard-dns.com/dns-query).
The question is, why AdGuard DNS cannot resolve "whoami.ipv6.akahelp.net" and always runs into these 2 second timeouts and if the answer is not refused, why is always Cloudflare the resolving server and not AdGuard itself?
Maybe this is also related to issue 777 which I'm also having some problems with. It seems that there are some problems that only affect the Akamai network somehow.
If you need any more information, please let me know.
Ah, now I got it, interesting.
Could you please also show what you see here? https://d.adguard-dns.com/info.txt
Hi there and thank you for your fast reply :)
My output for https://d.adguard-dns.com/info.txt is: fra-22
Thank you! I see the issue with IPv6 on one of the servers in Frankfurt, we'll figure it out soon
Awesome! I can already see a change. It looks like it is fixed now:
dnslookup result (elapsed 188.454ms):
;; opcode: QUERY, status: NOERROR, id: 37050
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;whoami.ipv6.akahelp.net. IN TXT
;; ANSWER SECTION:
whoami.ipv6.akahelp.net. 60 IN TXT "ip" "2a02:6ea0:c731::14"
whoami.ipv6.akahelp.net. 60 IN TXT "ns" "2a02:6ea0:c731::14"
whoami.ipv6.akahelp.net. 60 IN TXT "ecs" "217.229.153.0/24/24"
AdGuard DNS seems to resolve now correctly. I will also check whether issue 777 is also solved. This will take some time as this issue is not always reproducible. I will keep you updated.
Thank you again for your awesome support! :-)
@m-rue
I will also check whether issue 777 is also solved.
Did you check it?
For me the issue #777 is still present.
Otherwise thank your for your input - I already mentioned your point somewhere else - but at this time they said it isn't correlated to the issue.
Looks like dnscheck.tools doesn't show Google/Cloudflare anymore - is this also because of this issue here?
Hi @pictosun, yes I checked and unfortunately, the issue 777 is still present for me as well.
I have also seen that dnscheck.tools looks good now. No more Cloudflare/Google server visible. This is indeed since they fixed issue#792. But I've also found some new problems, e.g. my private AdGuardDNS Server cannot resolve most TXT records anymore. Using DoH I get an error 500 back. This is not the case with "whoami.ipv6.akahelp.net" but with most other domains I checked. I didn't have the time to further investigate so far but I will eventually create new issues for my new findings.