dnscrypt-proxy -

ناشناس DNSCrypt به اعتقاد من از نظر تئوری توسط همه سرورهای DNS كه از DNSCrypt پشتیبانی می كنند پشتیبانی می شود. اما در واقع ، دو سرور DNS که من آزمایش کرده ام ، Quad99 و Cleanbrowsing- امنیت ، بر اساس نتایج حاصل از اجرای وضعیت systemctl روی سرویس dnscrypt-proxy ، درخواست های ناشناس DNScrypt را نمی پذیرند.

من معتقدم این مسئله مربوط به موارد زیر است: [19659002] "… و بله ، اگر بسته ها در حین آزمایش قطعه رها شوند ، ناشناس ماندن غیرفعال خواهد شد." https://github.com/DNSCrypt/dnscrypt-proxy/issues/1251 مندرجات 19659002] با این حال مسئله dnsdist متعادل کننده بار که باعث موارد فوق شد در اواخر ماه مارس مشخص شد: https://github.com/DNSCrypt/dnscrypt-proxy/issues/1255 اما به نظر نمی رسد که Quad9 و Cleanbrowsing این مشکل را برطرف کرده باشد یا هنوز اصلاح موجود نیست.

حدس می زنم در یادداشت های انتشار نیز به این نکته اشاره شده است:

– نسخه های فعلی متعادل کننده بار `dnsdist` (احتمالاً توسط quad9 ، cleanbrowsing ، qualityology ، freetsa.org ، ffmuc.net ، opennic-bongobow ، sth استفاده می شود) -dnscrypt-se ، ams-dnscrypt-nl و موارد دیگر) مانع دریافت پرس و جوهای بیش از 1500 بایت از طریق U می شود DP راه حل های موقت برای بهبود قابلیت اطمینان با این حلال ها برای DNSCrypt معمولی معرفی شده اند. متأسفانه ، DNS ناشناس تا زمانی که مشکل از سمت سرور برطرف نشود ، قابل اعتماد نیست. نویسندگان `dnsdist` از آن آگاه هستند و در حال رفع مشکل هستند. – گزینه جدید در بخش "[anonymized_dns]": "skip_incompatibil" ، برای نادیده گرفتن حلال های سازگار با DNS ناشناس به جای استفاده از آنها بدون رله.

با این حال ، من می دانم که آیا دلیلی برای محدودیت 1500 بایت وجود داشته است: https://blog.benjojo.co.uk/post/with-is-ethernet-mtu-1500 برگزیده شده19659002] من در حال حاضر از Adguard DNS استفاده می کنم – که به نظر می رسد از DNS ناشناس پشتیبانی می کند.

مگر اینکه من باشم از دست دادن چیزی – این یک مسئله مهم است و به کاربران توصیه می شود که وضعیت dnscrypt-proxy را هنگام راه اندازی (systemctl) بررسی کنند – در صورتی که این مورد از اهمیت زیادی برای آنها برخوردار باشد ، حتماً DNS ناشناس را بیمه می کنند.