DNSTT

همهٔ قابلیت‌های هیدیفای

DNSTT ترافیک شما را درون پرسش‌ها و پاسخ‌های DNS جابه‌جا می‌کند. کلاینت برای نام‌هایی زیر دامنه‌ای که در اختیار شماست، از طریق resolverهای عمومی DNS پرسش می‌فرستد و سرور DNSTT شما به آن‌ها پاسخ می‌دهد. این یک outbound است: "type": "dnstt" در فهرست outbounds. کلاینت بر پایهٔ VayDNS، یک انشعاب از DNSTT، ساخته شده و با سرورهای اصلی DNSTT هم کار می‌کند.

چرا از آن استفاده کنیم

• در شبکه‌هایی کار می‌کند که تقریباً همه‌چیز در آن‌ها مسدود است ولی DNS از طریق resolverهای عمومی یا محلی هنوز کار می‌کند.
• resolverهای کارا را خودش از یک فهرست داخلی پیدا می‌کند و به خاطر می‌سپارد کدام‌ها کار کرده‌اند.

کند است: هر پرسش فقط مقدار کمی داده می‌برد و resolverها تعداد پرسش‌ها را محدود می‌کنند. وقتی چیز دیگری عبور نمی‌کند از آن استفاده کنید، نه به‌عنوان اتصال روزمره.

چطور از فیلترینگ عبور می‌کند

فیلتر فقط پرسش‌های DNS به یک resolver را می‌بیند، برای نام‌هایی زیر دامنهٔ شما. resolver آن‌ها را به سرور شما می‌فرستد، چون سرور شما مرجع آن دامنه است. داده‌های درون پرسش‌ها با پروتکل Noise رمز می‌شوند، پس نه resolver و نه فیلتر نمی‌توانند آن‌ها را بخوانند. پرسش‌ها به resolver می‌توانند از طریق DNS over HTTPS (DoH) یا DNS over TLS (DoT) هم بروند، با اثرانگشت TLS یک مرورگر (utls).

وقتی DNS به همهٔ resolverهای بیرونی مسدود یا دست‌کاری شود، یا resolverهای در دسترس پرسش‌های بلند یا غیرعادی را دور بریزند، کمکی نمی‌کند.

چطور کار می‌کند

• پیدا کردن resolverها. پس از شروع، خروجی هر resolver در resolvers را بررسی می‌کند، تا ۱۰۰ تا هم‌زمان. هر بررسی یک پرسش DNS معمولی می‌فرستد (pretest-domain، pretest-record-type)، سپس ظرف ۵ ثانیه یک تونل واقعی از طریق آن resolver باز می‌کند. هر resolver که قبول شود به مجموعه اضافه می‌شود، و وقتی بیش از ۱۰ تا در استفاده باشند، دیگر چیزی اضافه نمی‌شود. خروجی به محض قبول شدن اولین resolver آماده است.
• سابقه. هر resolver امتیازی از ۱۰- تا ۱۰ می‌گیرد که در فایل کش ذخیره می‌شود. در فهرست داخلی و در موارد خود شما، resolverهای با امتیاز بهتر زودتر بررسی می‌شوند.
• تونل. به‌طور پیش‌فرض یک تونل پرسش‌هایش را میان همهٔ resolverهای مجموعه پخش می‌کند. با single-resolver هر resolver تونل خودش را دارد و هر اتصال یکی را تصادفی برمی‌دارد؛ تونلی که خراب شود بسته و دوباره ساخته می‌شود. با smart_pool پرسش‌ها به یک مجموعهٔ resolver محلی می‌روند که آن‌ها را میان resolverهای کارا پخش می‌کند، برای resolverی که محدودیت نرخ اعمال می‌کند آهسته‌تر می‌فرستد و resolverی را که پاسخ نمی‌دهد کنار می‌گذارد (مجموعهٔ هوشمند resolver را ببینید).
• درون تونل. داده‌ها برای اطمینان روی KCP، برای رمزنگاری روی Noise و روی smux می‌روند تا اتصال‌های زیادی یک تونل را به اشتراک بگذارند.
• مقصد. این خروجی تعیین نمی‌کند اتصال به کجا برود. همهٔ اتصال‌ها به سرور DNSTT شما می‌رسند و سرور آن‌ها را به تنها سرویسی که برایش تنظیم شده می‌فرستد، معمولاً یک سرور SOCKS یا SSH. برای استفاده، خروجی همان نوع را با detour جلوی آن بگذارید.

فقط TCP. UDP پشتیبانی نمی‌شود.

پیکربندی

سرور DNSTT به یک سرور SOCKS می‌فرستد، پس یک خروجی socks از درون خروجی dnstt اجرا می‌شود. نشانی سرور در socks استفاده نمی‌شود، چون سرور DNSTT مقصد اتصال را تعیین می‌کند.

{
  "outbounds": [
    {
      "type": "dnstt",
      "tag": "dnstt-out",
      "domain": "t.example.com",
      "pubkey": "<server public key, hex>",
      "resolvers": ["auto", "8.8.8.8:53", "https://dns.google/dns-query"]
    },
    {
      "type": "socks",
      "tag": "proxy",
      "server": "127.0.0.1",
      "server_port": 1080,
      "detour": "dnstt-out"
    }
  ]
}

فیلد	نوع	پیش‌فرض	معنی
domain	string	الزامی	دامنهٔ تونل که سرور DNSTT شما مرجع آن است.
pubkey	string	الزامی	کلید عمومی Noise سرور، به صورت hex.
resolvers	list of strings	الزامی	resolverهای مورد استفاده. "1.1.1.1:53" یعنی DNS ساده روی UDP، "https://..." یعنی DoH، "dot://host:853" یعنی DoT. "auto" (یا رشتهٔ خالی) فهرست داخلی حدود ۵۸٬۰۰۰ resolver عمومی را اضافه می‌کند. دست‌کم یکی لازم است.
pretest-domain	string	"www.google.com"	نامی که برای بررسی پاسخ‌گویی resolver پرسیده می‌شود.
pretest-record-type	string	"a"	نوع رکورد آن پرسش: a، aaaa، cname، mx، ns، ptr، soa، srv یا txt.
record-type	string	"txt"	نوع رکورد پاسخ‌هایی که داده را از سرور برمی‌گردانند: txt، cname، a، aaaa، mx، ns یا srv. باید با سرور یکی باشد. مقدار دیگر از TXT استفاده می‌کند. هر نوع رکورد سابقهٔ ذخیره‌شدهٔ resolverهای خودش را دارد.
utls	string	""	اثرانگشت TLS برای DoH و DoT، مثلاً "Chrome"، "Firefox"، "iOS" یا "random". خالی یعنی TLS خود Go.
single-resolver	bool	false	یک تونل برای هر resolver، به‌جای یک تونل روی همهٔ آن‌ها.
smart_pool	bool یا object	false؛ با چند resolver خودبه‌خود روشن	پرسش‌ها را از مجموعهٔ resolver خود خروجی بفرست، همان‌طور که بالا گفته شد: true، یا یک شیء با load_balance، deadline، per_attempt، probe_interval، down_after و duplicate (مجموعهٔ هوشمند resolver را ببینید). یک تونل روی یک resolver کار می‌کند، پس با بیش از یکی مجموعه روشن است، این فیلد هر چه باشد.
dnstt-compat	bool	false	قالب سیمی اصلی DNSTT، برای سرور اصلی DNSTT.
clientid-size	int	2	اندازهٔ شناسهٔ کلاینت به بایت. با dnstt-compat نادیده گرفته می‌شود و ۸ است. باید با سرور یکی باشد.
max-qname-len	int	101 (با dnstt-compat، 253)	بیشترین طول نام پرسش.
max-num-labels	int	0 (بی‌حد)	بیشترین تعداد برچسب داده در نام پرسش.
rps	number	0 (بی‌حد)	بیشترین تعداد پرسش در ثانیه.
mtu	int	محاسبه‌شده	اندازهٔ بسته درون تونل. اگر تنظیم نشود، از دامنه و دو حد بالا محاسبه می‌شود.
idle-timeout	duration	60s (با dnstt-compat، 2m)	اگر این مدت پاسخی نیاید، نشست بسته می‌شود.
keepalive	duration	10s	فاصلهٔ پیام‌های زنده نگه‌داشتن.
open-stream-timeout	duration	10s	بیشترین زمان برای باز کردن یک اتصال درون تونل.
max-streams	int	0 (بی‌حد)	بیشترین تعداد اتصال هم‌زمان در یک تونل.
reconnect-min	duration	1s	کمترین انتظار پیش از اتصال دوبارهٔ تونل.
reconnect-max	duration	30s	بیشترین انتظار پیش از اتصال دوبارهٔ تونل.
session-check-interval	duration	20s	هر چند وقت تونل زنده بودن نشستش را بررسی می‌کند.
handshake-timeout	duration	15s	بیشترین زمان دست‌دهی Noise.
udp-timeout	duration	500ms	برای resolverهای UDP ساده: مدت انتظار برای هر پاسخ.
udp-workers	int	100؛ با smart_pool: 300	برای resolverهای UDP ساده: تعداد پرسش‌های هم‌زمان در جریان. با smart_pool، به سوی مجموعه، هر worker یک سوکت نگه می‌دارد.
udp-shared-socket	bool	false	برای resolverهای UDP ساده: همهٔ پرسش‌ها از یک سوکت، به‌جای یک سوکت برای هر پرسش.
udp-accept-errors	bool	false	برای resolverهای UDP ساده: پاسخ‌های دارای کد خطا را بپذیر و دور نریز.
tunnel-per-resolver	int		منسوخ است و نادیده گرفته می‌شود.

سوکت‌هایی که پرسش‌های DNS را می‌فرستند تنظیم‌های سوکت خروجی، مثل bind_interface و routing_mark، و محافظت سوکت سیستم‌عامل را می‌گیرند. پس روی VPN پرسش‌ها دوباره به داخل تونل برنمی‌گردند. detour پشتیبانی نمی‌شود: پرسش‌ها مستقیم بیرون می‌روند و لاگ هشدار می‌دهد.

dnstt-compat و clientid-size قالب سیمی را تغییر می‌دهند، پس باید با سرور شما یکی باشند.

همچنین ببینید

• مجموعهٔ هوشمند resolver
• پایش

---

اخرین بروزرسانی: 26 فوریهٔ 2026

نظرات