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 را بدون نام مطمئن کنید.