Using ‘Use custom IP for EDNS’ may cause domain resolution to return REFUSED/使用“为EDNS使用自定义IP”时 可能导致域名解析返回 REFUSED

[bcseputetto]

Prerequisites

• I have checked the Wiki and Discussions and found no answer

• I have searched other issues and found no duplicates

• I want to report a bug and not ask a question or ask for help

• I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)

Platform (OS and CPU architecture)

Linux, AMD64 (aka x86_64)

Installation

GitHub releases or script from README

Setup

On one machine

AdGuard Home version

0.107.40

Action

使用“为EDNS使用自定义IP”时 可能导致域名解析返回 REFUSED
为了使开发人员更好地理解我暂时将AGH的界面语言更改到了英文

---

Using ‘Use custom IP for EDNS’ may cause domain name resolution to return REFUSED
To help developers understand better, I have temporarily changed the interface language of AGH to English.

ubuntu@tk2-410-46346:~$ sudo netstat -anp |grep :53 |grep LISTEN
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      2105045/AdGuardHome 
ubuntu@tk2-410-46346:~$ nslookup cl3-cdn.origin-apple.com.akadns.net
Server:         127.0.0.1
Address:        127.0.0.1#53

** server can't find cl3-cdn.origin-apple.com.akadns.net: REFUSED

ubuntu@tk2-410-46346:~$ nslookup cl3-cdn.origin-apple.com.akadns.net 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
cl3-cdn.origin-apple.com.akadns.net     canonical name = cl3-cdn-us.origin-apple.com.akadns.net.
cl3-cdn-us.origin-apple.com.akadns.net  canonical name = cl3.g.aaplimg.com.
Name:   cl3.g.aaplimg.com
Address: 17.253.69.199
Name:   cl3.g.aaplimg.com
Address: 17.253.69.209
Name:   cl3.g.aaplimg.com
Address: 2403:300:a0c:f000::201
Name:   cl3.g.aaplimg.com
Address: 2403:300:a0c:f100::202

ubuntu@tk2-410-46346:~$ nslookup cl3-cdn.origin-apple.com.akadns.net
Server:         127.0.0.1
Address:        127.0.0.1#53

** server can't find cl3-cdn.origin-apple.com.akadns.net: REFUSED

ubuntu@tk2-410-46346:~$ nslookup cl3-cdn.origin-apple.com.akadns.net
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
cl3-cdn.origin-apple.com.akadns.net     canonical name = cl3-cdn-us.origin-apple.com.akadns.net.
cl3-cdn-us.origin-apple.com.akadns.net  canonical name = cl3.g.aaplimg.com.
Name:   cl3.g.aaplimg.com
Address: 17.253.71.208
Name:   cl3.g.aaplimg.com
Address: 17.253.71.202

ubuntu@tk2-410-46346:~$ nslookup cl3-cdn.origin-apple.com.akadns.net
Server:         127.0.0.1
Address:        127.0.0.1#53

** server can't find cl3-cdn.origin-apple.com.akadns.net: REFUSED

Expected result

希望你们能修好它

---

I hope you can fix it.

Actual result

2023-10-23.231430.mp4

Additional information and/or screenshots

[bcseputetto]

我并没有彻底关闭“启用EDNS”客户端子网的功能，只是关闭了“为EDNS使用自定义IP”，似乎就正常了。我也不知道为何会这样。

---

I did not completely turn off the ‘Enable EDNS client subnet’ feature, I just turned off the ‘Use custom IP for EDNS’, and it seems to work normally. I don’t know why this is the case.

[bcseputetto]

我又测试了一下发现只有谷歌的DNS会对自定义IP的EDNS返回REFUSED，而cloudflare的不会
我感觉我的问题也许和 #3652 类似。但我没有彻底关闭EDNS功能，能否让谷歌公共DNS返回正确解析只取决于是否启用“为EDNS使用自定义IP”。并且不是所有域名都会返回REFUSED，例如两个issues里面都有提及的 akadns 似乎就会返回REFUSED

---

I have tested again and found that only Google’s DNS will return REFUSED for EDNS with custom IP, while Cloudflare’s will not.
I feel that my problem may be similar to #3652. But I did not completely turn off the EDNS function, whether Google Public DNS can return the correct resolution depends only on whether to enable ‘Use custom IP for EDNS
Not all domain will return REFUSED, for example, akadns mentioned in both issues seems to return REFUSED.

[agneevX]

I have tested again and found that only Google’s DNS will return REFUSED for EDNS with custom IP, while Cloudflare’s will not.

This goes for the only two public resolvers that explicitly support ECS from Akamai, Google Public DNS and OpenDNS.

Cloudflare (1.1.1.1) does not send ECS and their enterprise solution, Zero Trust sends ECS however does not support sending a subnet other than the one from where the request originates.

[ainar-g]

Thank you for the thorough report! You are correct in that it might be an issue more with the way Google chooses to respond to some queries. I'll merge this into #3652, if you don't mind. Please use the 👍 reaction on that issue to show your support for retries or some other solution for these cases.