add dns link share

[hiddify-com]

I suggest to make a protocol for easy share of the dns link

dnstt://?domain=&mtu=&clientid-size=&record-type=&keepalive=&idle-timeout=&dnstt-compat=&max-qname-len=&open-stream-timeout=

[hiddify-com]

In hiddify for defining the application layer, we use

socks://user:pass@:#SOCKS -> dnstt://....

[hiddify-com]

This is our data model in Hiddify

if resolver contains "auto" we try to search all available dns and give a score to each dns store the valid ones
for verification of a dns is reachable we first use simple record-type dns query to the domain, if it works we then try for dnstt

type DnsttOptions struct {
	Resolvers         []string `json:"resolvers,omitempty"`
	TunnelPerResolver int      `json:"tunnel-per-resolver,omitempty"`

	PublicKey string `json:"pubkey,omitempty"`
	Domain    string `json:"domain,omitempty"`

	RecordType        string `json:"record-type,omitempty"`
	UTLSClientHelloID string `json:"utls,omitempty"`


	DnsttCompat  bool     `json:"dnstt-compat,omitempty"`
	ClientIDSize *int     `json:"clientid-size,omitempty"`
	MaxQnameLen  *int     `json:"max-qname-len,omitempty"`
	MaxNumLabels *int     `json:"max-num-labels,omitempty"`
	RPS          *float64 `json:"rps,omitempty"`

	MTU *int `json:"mtu,omitempty"`

	IdleTimeout          *badoption.Duration `json:"idle-timeout,omitempty"`
	KeepAlive            *badoption.Duration `json:"keepalive,omitempty"`
	OpenStreamTimeout    *badoption.Duration `json:"open-stream-timeout,omitempty"`
	MaxStreams           *int                `json:"max-streams,omitempty"`
	ReconnectMinDelay    *badoption.Duration `json:"reconnect-min,omitempty"`
	ReconnectMaxDelay    *badoption.Duration `json:"reconnect-max,omitempty"`
	SessionCheckInterval *badoption.Duration `json:"session-check-interval,omitempty"`
	HandshakeTimeout     *badoption.Duration `json:"handshake-timeout,omitempty"`

	UdpAcceptErrors bool                `json:"udp-accept-errors,omitempty"`
	UdpSharedSocket bool                `json:"udp-shared-socket,omitempty"`
	UdpTimeout      *badoption.Duration `json:"udp-timeout,omitempty"`
	UdpWorkers      *int                `json:"udp-workers,omitempty"`
}

[crazydi4mond]

@hiddify-com Don't you think this feature fits DNSTM more than the underlying transport like VayDNS?

We already have this feature in DNSTM and were planning to support those links in DNSTC. And are planning to add VayDNS support for those links.

[hiddify-com]

If you have already implemented this, that is definitely a good option.
However, personally I am not a big fan of base64-JSON-encoded links, since the main goal of shareable links is to allow users to easily read and edit the configuration.

By the way, the most important point here is that the protocol should be defined by DNSTT so that we can have a single standardized link format that works across different clients/servers.

[hiddify-com]

Suggestion

Base

dnstt://record-type:pubkey@domain.com?mtu=&clientid-size=&keepalive=&idle-timeout=&dnstt-compat=&max-qname-len=&open-stream-timeout=

Options

1

dnstt://......&backend=socks/ssh&buser=xxx&bpass=yyy&bkey=zzz

Examples:

dnstt://txt:213455@t.example.com?clientid-size=2&max-qname-len=110&backend=socks

dnstt://txt:213455@t.example.com?clientid-size=2&max-qname-len=110&backend=socks&user=xxx&pass=yyy

dnstt://txt:213455@t.example.com?clientid-size=2&max-qname-len=110&backend=ssh&user=xxx&pass=yyy&key=zzz

2

xraylink -> dnstt://....

socks://user:pass@ -> dnstt://txt:213455@t.example.com?clientid-size=2&max-qname-len=110

[crazydi4mond]

We're going to implement this in DNSTM since the share URL encodes both transport and backend configuration — backend details like SSH credentials or SOCKS/Shadowsocks method are out of scope for a transport project like VayDNS or DNSTT.

Refined URL Structure

Based on the existing dnst:// share links in DNSTM and your proposal, here is our refined format. We use dnst:// instead of dnstt:// as the scheme, since VayDNS differs significantly from DNSTT and there are other transports like Slipstream and MasterDNS — having a separate scheme per transport (dnstt://, vaydns://, slipstream://, ...) would fragment the ecosystem. Instead, the transport type is the first element in the URL:

dnst://[transport]@[domain]/[backend]?tag=[tag]&[t.transport-params]&[b.backend-params]

• Scheme: dnst://
• Authority (transport@domain): transport type and tunnel domain — always the same structure regardless of transport
• Path (/backend): backend type
• tag: tunnel name (no prefix — it's a top-level identifier, not transport or backend specific)
• Query params: t. prefix for transport params, b. prefix for backend params

Examples

VayDNS

# VayDNS + SOCKS (minimal)
dnst://vaydns@t.example.com/socks?tag=my-tunnel&t.pubkey=ab3f...c8&t.record-type=txt

# VayDNS + SOCKS (tuned)
dnst://vaydns@t.example.com/socks?tag=my-tunnel&t.pubkey=ab3f...c8&t.record-type=txt&t.clientid-size=2&t.keepalive=10s&t.idle-timeout=60s

# VayDNS + SOCKS with auth
dnst://vaydns@t.example.com/socks?tag=my-tunnel&t.pubkey=ab3f...c8&t.record-type=txt&b.user=foo&b.password=bar

# VayDNS + SSH
dnst://vaydns@t.example.com/ssh?tag=my-tunnel&t.pubkey=ab3f...c8&t.record-type=txt&b.user=tunnel&b.password=secret

# VayDNS + dnstt-compat mode
dnst://vaydns@t.example.com/socks?tag=my-tunnel&t.pubkey=ab3f...c8&t.record-type=txt&t.dnstt-compat=true

DNSTT

# DNSTT + SOCKS
dnst://dnstt@t.example.com/socks?tag=my-tunnel&t.pubkey=ab3f...c8&t.record-type=txt

# DNSTT + SSH with password
dnst://dnstt@t.example.com/ssh?tag=my-tunnel&t.pubkey=ab3f...c8&t.record-type=txt&b.user=tunnel&b.password=secret

Slipstream

# Slipstream + SOCKS (without cert)
dnst://slipstream@a.example.com/socks?tag=my-tunnel

# Slipstream + SOCKS (with cert, base64url-encoded DER)
dnst://slipstream@a.example.com/socks?tag=my-tunnel&t.cert=MIIBkTCB...

# Slipstream + Shadowsocks
dnst://slipstream@a.example.com/shadowsocks?tag=my-tunnel&t.cert=MIIBkTCB...&b.method=aes-256-gcm&b.password=secret

MasterDNS (planned for DNSTM)

# MasterDNS + SOCKS
dnst://masterdns@v.example.com/socks?tag=my-tunnel&t.key=abcdef1234&t.encryption=5

Base64 JSON format

The JSON structure used for encoding:

{
  "tag": "tunnel-name",
  "transport": {
    "type": "vaydns|dnstt|slipstream|masterdns",
    "domain": "t.example.com",
    "pubkey": "ab3f...c8",              // dnstt, vaydns
    "cert": "-----BEGIN CERTIFICATE...", // slipstream (PEM)
    "key": "abcdef1234",                // masterdns (symmetric)
    "encryption": 5,                     // masterdns (method id)
    "record_type": "txt",               // dnstt, vaydns
    "dnstt_compat": false,              // vaydns
    "clientid_size": 2,                 // vaydns
    "idle_timeout": "60s",              // vaydns
    "keepalive": "10s"                  // vaydns
  },
  "backend": {
    "type": "socks|ssh|shadowsocks",
    "user": "username",                 // socks, ssh
    "password": "secret",              // socks, ssh, shadowsocks
    "key": "-----BEGIN RSA PRIVATE...", // ssh (PEM)
    "method": "aes-256-gcm"            // shadowsocks
  }
}

Fields are omitted when not applicable to the transport/backend type. The JSON is then encoded as base64url (RFC 4648) and prefixed with dnst://:

We suggest all client applications support both the human-readable format above and a base64-encoded JSON format:

dnst://eyJ2IjoxLCJ0YWci...

The client can distinguish between the two by checking whether the content after dnst:// contains @ (human-readable) or not (base64 JSON).

The base64 format is important for two reasons:

1. Practical: some transports like Slipstream require embedding TLS certificates which are too large for a readable URL. SSH private keys have the same problem.
2. Safety: in heavily surveilled environments, human-readable URLs expose domain names and server configuration in plaintext. When share links are sent via SMS or messengers that are monitored (e.g. in Iran), base64 encoding helps avoid automated detection and keyword filtering, keeping domains and servers safe.

A note on dropping t./b. prefixes

Removing the prefixes would result in shorter, cleaner URLs:

dnst://vaydns@t.example.com/socks?tag=my-tunnel&pubkey=ab3f...c8&record-type=txt&clientid-size=2

Most transport and backend params have distinct names so this works today. However there is at least one known collision: key is used by both SSH backend (private key) and MasterDNS transport (encryption key). As more transports and backends are added, further collisions are likely. The t./b. prefixes avoid this entirely at the cost of 2 extra characters per param.

Adoption as a standard

It would be great if @anonvector also adopts this structure in SlipNet and SlipGate. If slipnet, Hiddify, and DNSTM all support this format, we can define it as a new standard for DNS-based tunnel configuration sharing, replacing the current fragmented approaches where each project has its own way of exchanging connection configs.

Please let us know what you think. We're quite flexible on the details here. The goal is to define a standard that we can all adopt and make life easier for end users.

[hiddify-com]

Two points:

User:pass field should be used in a more related way

The transport can be in the first part
Dnstt://
vaydns://
masterdns://
slip://

Tag should be after#

I think we can use a better integration

I will propose the idea soon

[hiddify-com]

Let’s start from the original SOCKS/SSH link formats:

socks://user:pass@server:port#TAG
ssh://user:pass@server:port/?key=xyz#TAG

With DNS tunneling, however, the server:port concept becomes irrelevant, since the connection is established over a domain using DNS queries.

shadowsocks protocol: https://shadowsocks.org/doc/sip002.html
⸻

Refined Proposal

For DNS-based transports such as dnstt, vaydns, masterdns, slipdns, a more consistent and extensible format would be:

transport+socks://user:pass@domain/?dns-parameters#tag
transport+ssh://user:pass@domain/?dns-parameters#tag

This keeps the familiar proxy scheme while clearly indicating the transport layer.

⸻

Examples

dnstt+socks://t.example.com/?pubkey=ab3f...c8#my-tunnel
dnstt+ssh://user:pass@t.example.com/?pubkey=ab3f...c8#my-tunnel

vaydns:

vaydns+socks://t.example.com/?pubkey=ab3f...c8&record-type=txt&clientid-size=2#my-tunnel
vaydns+ssh://user:pass@t.example.com/?pubkey=ab3f...c8&record-type=txt&clientid-size=2#my-tunnel

masterdns:

masterdns+socks://t.example.com/?mkey=abcdef1234&encryption=5#my-tunnel
masterdns+ssh://user:pass@t.example.com/?pk=optional_sshkey&mkey=abcdef1234&encryption=5#my-tunnel

slipstream

slipstream+socks://t.example.com/#my-tunnel
slipstream+ssh://user:pass@t.example.com/?pk=optional_sshkey&cert=MIIBkTCB...#my-tunnel
slipstream+ss://method:pass@t.example.com/?cert=MIIBkTCB...#my-tunnel

https://shadowsocks.org/doc/sip002.html
⸻

for masterdns and ssh common key param we can use different naming for each
like mkey pk....

Benefits of this format
• Keeps compatibility with existing URI structure
• Clearly separates transport layer (dnstt) from proxy protocol (socks / ssh)
• Avoids ambiguity around server:port
• Easy to parse using standard URL parsers
• Extensible for future DNS transports and parameters
• Clean and user-friendly for sharing (single link)

[anonvector]

Between the two proposals, I’m in favor of dnst://. A unified scheme is cleaner and more practical especially on Android where a single intent filter can handle everything instead of registering one for every transport × backend combination with compound schemes.

SlipNet will support dnst:// for both import and export. Users will be able to import dnst:// links from DNSTM, Hiddify, or any other tool whether in human readable form or base64 encoded JSON. For DNS tunnel profiles, SlipNet will also provide an option to export as dnst://, making it easy to share configurations with users on other clients.

That said, SlipNet will keep slipnet:// and slipnet-enc:// as its primary formats, for two main reasons:

• Feature gap: SlipNet profiles include capabilities that a shared standard cannot represent, such as encrypted/locked configs, device binding, expiration dates, hidden resolvers, and 50+ app-specific fields.
• Protocol coverage: SlipNet supports more than just DNS tunneling (e.g., SSH, SOCKS5, NaiveProxy, DoH, Snowflake). The dnst:// scheme only covers a subset of what our profiles contain.

I’d suggest that every client supports importing dnst:// and optionally exporting it for DNS tunnel profiles, while keeping its own format as the primary option for full featured configurations. This way, a server admin can generate a single dnst:// link and be confident it works across clients without forcing any client to strip down its native configuration format.

[hiddify-com]

@anonvector

No one can provide a clickable link with the schema dnst:// that opens directly in the app. Therefore, I don't think this is a significant issue. Additionally, we currently have many different schemas in use.

I believe the link schema should follow a standard format similar to VLESS or SS links, rather than inventing new mechanisms.

[anonvector]

@hiddify-com VLESS itself handles multiple transports (ws, grpc, tcp, quic) within a single vless:// scheme using query params not separate schemes per transport. By that logic, dnst:// with transport as a URL component is actually closer to the VLESS pattern than vaydns+socks:// is.

Regarding clickable links; QR codes scanned with the system camera use Android intent filters to decide which app to open, so the scheme does matter. With compound schemes, each transport×backend combination needs to be registered separately in every client app. It's not a dealbreaker but a unified scheme avoids that entirely.

I'm fine with either format the key point is that we align on a single approach.

[crazydi4mond]

There are really four separate decisions in this thread, so let me address them one by one.

1. Unified dnst:// scheme vs. compound transport+backend:// schemes

I think a unified dnst:// scheme is the better choice, for a few reasons:

• VLESS precedent: VLESS — which @hiddify-com cited as a convention to follow — uses a single vless:// scheme with the transport (ws, grpc, tcp, quic) as a query param, not vless+ws:// or vless+grpc://. So the "follow VLESS conventions" argument actually supports dnst:// more than compound schemes.
• Android intent filters (@anonvector's point): a single dnst:// filter is much simpler than registering one per transport×backend combination. As we add more transports and backends, that combinatorial explosion forces every client to keep updating its intent filter list — a real maintenance burden.
• Gaps in transport+backend://: even setting the above aside, the compound form has some practical issues:
  • SSH backend: it's not clear how to express private-key auth vs. password auth consistently. Using user:password@ for password auth and user@ + a pk param for key-based auth feels inconsistent.
  • Shadowsocks backend (the recommended backend for Slipstream via SIP003): SS doesn't have a user field, and its password and method would have to live in query params anyway. So backend credentials end up being expressed differently depending on the backend type.
  • Future-proofing: as new backends are added, they may bring their own params that don't fit cleanly into the userinfo slot. The standard should be flexible enough to handle that without growing more special cases.
  • Custom and non-standard backends: DNSTM already supports a custom backend type for pointing tunnels at arbitrary TCP services, and future backends like VLESS are plausible. A compound scheme would need every combination (dnstt+custom://, dnstt+vless://, ...) pre-registered in each client, while a unified dnst:// scheme lets clients parse the URL and handle unknown backends gracefully.

2. Tag in the fragment (#tag)

I agree with @hiddify-com here — fragments are exactly the right place for an identifier that doesn't affect the resource being addressed. Let's adopt #tag at the end of the link.

3. Param structure (t./b. prefixes)

I'm not a fan of the t./b. prefixes either. Looking more closely at VLESS, it actually flattens all params (protocol, transport, TLS layer, etc.) into a single query string with no prefixes or grouping — disambiguation comes from context (e.g. path is the WS path when type=ws and the h2 path when type=http).

I think we can adopt the same pattern for dnst://: drop the t./b. prefixes entirely and rely on the transport and backend in the URL structure to disambiguate. For the few cases where param names would actually collide across layers, we can either:

• Share the name when it's semantically the same — e.g. password works for SSH, SOCKS, and Shadowsocks
• Pick distinct names where it isn't — e.g. mkey for the MasterDNS encryption key vs. pk for the SSH private key

4. Human-readable + base64 JSON

I still think we should support both human-readable and base64-encoded JSON forms, and I'm glad to see @anonvector also supports this. The base64 form is needed for cases where embedded certificates or SSH keys would make the URL impractical, and it also helps avoid keyword-based detection when configs are shared in heavily surveilled environments.

---

To give us all a single source of truth instead of each project documenting this differently, I've started a dedicated repo for the spec: net2share/dnst-url-spec. It currently has a draft SPEC.md and EXAMPLES.md reflecting the structure described above. Please take a look and let me know if there's anything else we should change or clarify before we lock it in. If you spot issues or have suggestions, feel free to open an issue or PR there, the goal is for DNSTM, DNSTC, Hiddify, SlipGate, SlipNet, and any future clients to all reference the same standard.

[masterking32]

درود،
من جدیدا روی مود فارسی را پاس بدارین خاصی هستم و این حرکت دوستان Xray که چینی صحبت میکنن و بقیه رو وادار میکنن ترجمه کنن رو خیلی باهاش حال کردم، پس فارسی صحبت میکنم چون احساس میکنم همه هم ایرانی هستید.

خب مورد اول اینکه MasterDnsVPN دو نوع پروتکل داره یکی Socks5 و دیگری TCP
روی TCP هر چیزی رو فورواد میکنه مثلا VLESS/VMESS، ShadowSocks و ... ساپورت میکنه
روی ساکس هم که طبیعتا ساکسه!

چیزهایی که اجباری هستند همون دامنه و کلید و نوع رمزنگاری هست.
چیز هایی که کاربر عموما اصلاح و دستگاری میکنه

ARQ_WINDOW_SIZE, MIN_UPLOAD_MTU, MIN_DOWNLOAD_MTU, MAX_UPLOAD_MTU, MAX_DOWNLOAD_MTU, RX_TX_WORKERS, TUNNEL_PROCESS_WORKERS

ولی خب کاربر حرفه ای تر طبیعتا شاید نیاز باشه کل تنظیمات رو ویرایش کنه که البته توی لینک حداقلی میشه فقط موارد اصلی رو لحاظ کرد.
اما لیست کامل آرگومان ها برای نسخه فعلی اینه:

  -arq-control-initial-rto-seconds value
        Override ARQ_CONTROL_INITIAL_RTO_SECONDS from config file (default 1)
  -arq-control-max-rto-seconds value
        Override ARQ_CONTROL_MAX_RTO_SECONDS from config file (default 8)
  -arq-control-packet-ttl-seconds value
        Override ARQ_CONTROL_PACKET_TTL_SECONDS from config file (default 900)
  -arq-data-nack-initial-delay-seconds value
        Override ARQ_DATA_NACK_INITIAL_DELAY_SECONDS from config file (default 0.4)
  -arq-data-nack-max-gap value
        Override ARQ_DATA_NACK_MAX_GAP from config file
  -arq-data-nack-repeat-seconds value
        Override ARQ_DATA_NACK_REPEAT_SECONDS from config file (default 1)
  -arq-data-packet-ttl-seconds value
        Override ARQ_DATA_PACKET_TTL_SECONDS from config file (default 1800)
  -arq-inactivity-timeout-seconds value
        Override ARQ_INACTIVITY_TIMEOUT_SECONDS from config file (default 1800)
  -arq-initial-rto-seconds value
        Override ARQ_INITIAL_RTO_SECONDS from config file (default 1)
  -arq-max-control-retries value
        Override ARQ_MAX_CONTROL_RETRIES from config file (default 80)
  -arq-max-data-retries value
        Override ARQ_MAX_DATA_RETRIES from config file (default 800)
  -arq-max-rto-seconds value
        Override ARQ_MAX_RTO_SECONDS from config file (default 8)
  -arq-terminal-ack-wait-timeout-seconds value
        Override ARQ_TERMINAL_ACK_WAIT_TIMEOUT_SECONDS from config file (default 60)
  -arq-terminal-drain-timeout-seconds value
        Override ARQ_TERMINAL_DRAIN_TIMEOUT_SECONDS from config file (default 90)
  -arq-window-size value
        Override ARQ_WINDOW_SIZE from config file (default 2000)
  -auto-disable-timeout-servers
        Override AUTO_DISABLE_TIMEOUT_SERVERS from config file (default true)
  -auto-disable-timeout-window-seconds value
        Override AUTO_DISABLE_TIMEOUT_WINDOW_SECONDS from config file (default 180)
  -base-encode-data
        Override BASE_ENCODE_DATA from config file
  -client-cancelled-setup-retention-seconds value
        Override CLIENT_CANCELLED_SETUP_RETENTION_SECONDS from config file (default 120)
  -client-terminal-stream-retention-seconds value
        Override CLIENT_TERMINAL_STREAM_RETENTION_SECONDS from config file (default 45)
  -compression-min-size value
        Override COMPRESSION_MIN_SIZE from config file (default 100)
  -config string
        Path to client configuration file (default "client_config.toml")
  -data-encryption-method value
        Override DATA_ENCRYPTION_METHOD from config file (default 1)
  -dispatcher-idle-poll-interval-seconds value
        Override DISPATCHER_IDLE_POLL_INTERVAL_SECONDS from config file (default 0.02)
  -dns-response-fragment-timeout-seconds value
        Override DNS_RESPONSE_FRAGMENT_TIMEOUT_SECONDS from config file (default 10)
  -domains value
        Override DOMAINS from config file (comma-separated)
  -download-compression-type value
        Override DOWNLOAD_COMPRESSION_TYPE from config file
  -encryption-key value
        Override ENCRYPTION_KEY from config file
  -listen-ip value
        Override LISTEN_IP from config file (default 127.0.0.1)
  -listen-port value
        Override LISTEN_PORT from config file (default 18000)
  -local-dns-cache-flush-interval-seconds value
        Override LOCAL_DNS_CACHE_FLUSH_INTERVAL_SECONDS from config file (default 60)
  -local-dns-cache-max-records value
        Override LOCAL_DNS_CACHE_MAX_RECORDS from config file (default 5000)
  -local-dns-cache-persist-to-file
        Override LOCAL_DNS_CACHE_PERSIST_TO_FILE from config file (default true)
  -local-dns-cache-ttl-seconds value
        Override LOCAL_DNS_CACHE_TTL_SECONDS from config file (default 28800)
  -local-dns-enabled
        Override LOCAL_DNS_ENABLED from config file
  -local-dns-ip value
        Override LOCAL_DNS_IP from config file (default 127.0.0.1)
  -local-dns-pending-timeout-seconds value
        Override LOCAL_DNS_PENDING_TIMEOUT_SECONDS from config file (default 300)
  -local-dns-port value
        Override LOCAL_DNS_PORT from config file (default 53)
  -log string
        Path to log file (optional)
  -log-level value
        Override LOG_LEVEL from config file (default INFO)
  -max-download-mtu value
        Override MAX_DOWNLOAD_MTU from config file (default 140)
  -max-packets-per-batch value
        Override MAX_PACKETS_PER_BATCH from config file (default 8)
  -max-upload-mtu value
        Override MAX_UPLOAD_MTU from config file (default 64)
  -min-download-mtu value
        Override MIN_DOWNLOAD_MTU from config file (default 100)
  -min-upload-mtu value
        Override MIN_UPLOAD_MTU from config file (default 40)
  -mtu-added-server-log-format value
        Override MTU_ADDED_SERVER_LOG_FORMAT from config file (default Resolver {IP} added back at {TIME} (UP {UP_MTU}, DOWN {DOWN_MTU}))
  -mtu-removed-server-log-format value
        Override MTU_REMOVED_SERVER_LOG_FORMAT from config file (default Resolver {IP} removed at {TIME} due to {CAUSE})
  -mtu-servers-file-format value
        Override MTU_SERVERS_FILE_FORMAT from config file (default {IP} - UP: {UP_MTU} DOWN: {DOWN-MTU})
  -mtu-servers-file-name value
        Override MTU_SERVERS_FILE_NAME from config file (default masterdnsvpn_success_test_{time}.log)
  -mtu-test-parallelism value
        Override MTU_TEST_PARALLELISM from config file (default 16)
  -mtu-test-retries value
        Override MTU_TEST_RETRIES from config file (default 2)
  -mtu-test-timeout value
        Override MTU_TEST_TIMEOUT from config file (default 4)
  -mtu-using-section-separator-text value
        Override MTU_USING_SECTION_SEPARATOR_TEXT from config file
  -packet-duplication-count value
        Override PACKET_DUPLICATION_COUNT from config file (default 5)
  -ping-aggressive-interval-seconds value
        Override PING_AGGRESSIVE_INTERVAL_SECONDS from config file (default 0.3)
  -ping-cold-interval-seconds value
        Override PING_COLD_INTERVAL_SECONDS from config file (default 30)
  -ping-cold-threshold-seconds value
        Override PING_COLD_THRESHOLD_SECONDS from config file (default 20)
  -ping-cool-threshold-seconds value
        Override PING_COOL_THRESHOLD_SECONDS from config file (default 10)
  -ping-cooldown-interval-seconds value
        Override PING_COOLDOWN_INTERVAL_SECONDS from config file (default 3)
  -ping-lazy-interval-seconds value
        Override PING_LAZY_INTERVAL_SECONDS from config file (default 1)
  -ping-warm-threshold-seconds value
        Override PING_WARM_THRESHOLD_SECONDS from config file (default 5)
  -protocol-type value
        Override PROTOCOL_TYPE from config file (default SOCKS5)
  -recheck-inactive-servers-enabled
        Override RECHECK_INACTIVE_SERVERS_ENABLED from config file (default true)
  -resolver-balancing-strategy value
        Override RESOLVER_BALANCING_STRATEGY from config file
  -resolvers string
        Path to resolver file override (optional)
  -rx-channel-size value
        Override RX_CHANNEL_SIZE from config file (default 4096)
  -rx-tx-workers value
        Override RX_TX_WORKERS from config file (default 6)
  -save-mtu-servers-to-file
        Override SAVE_MTU_SERVERS_TO_FILE from config file
  -session-init-busy-retry-interval-seconds value
        Override SESSION_INIT_BUSY_RETRY_INTERVAL_SECONDS from config file (default 60)
  -session-init-racing-count value
        Override SESSION_INIT_RACING_COUNT from config file (default 3)
  -session-init-retry-base-seconds value
        Override SESSION_INIT_RETRY_BASE_SECONDS from config file (default 1)
  -session-init-retry-linear-after value
        Override SESSION_INIT_RETRY_LINEAR_AFTER from config file (default 5)
  -session-init-retry-max-seconds value
        Override SESSION_INIT_RETRY_MAX_SECONDS from config file (default 60)
  -session-init-retry-step-seconds value
        Override SESSION_INIT_RETRY_STEP_SECONDS from config file (default 1)
  -setup-packet-duplication-count value
        Override SETUP_PACKET_DUPLICATION_COUNT from config file (default 5)
  -socks-udp-associate-read-timeout-seconds value
        Override SOCKS_UDP_ASSOCIATE_READ_TIMEOUT_SECONDS from config file (default 30)
  -socks5-auth
        Override SOCKS5_AUTH from config file
  -socks5-pass value
        Override SOCKS5_PASS from config file (default master_dns_vpn)
  -socks5-user value
        Override SOCKS5_USER from config file (default master_dns_vpn)
  -stream-resolver-failover-cooldown value
        Override STREAM_RESOLVER_FAILOVER_COOLDOWN from config file (default 1)
  -stream-resolver-failover-resend-threshold value
        Override STREAM_RESOLVER_FAILOVER_RESEND_THRESHOLD from config file (default 2)
  -tunnel-packet-timeout-seconds value
        Override TUNNEL_PACKET_TIMEOUT_SECONDS from config file (default 8)
  -tunnel-process-workers value
        Override TUNNEL_PROCESS_WORKERS from config file (default 4)
  -tunnel-reader-workers value
        Override TUNNEL_READER_WORKERS from config file
  -tunnel-writer-workers value
        Override TUNNEL_WRITER_WORKERS from config file
  -upload-compression-type value
        Override UPLOAD_COMPRESSION_TYPE from config file
  -version
        Print version and exit

که البته داخل فایل TOML هم میشه داشتشون.
بازم شما هر ساختاری رو خواستید و تایید کردید اوکیه نمیدونم حالا نیاز هست ما چیزیو تغییر بدیم یا نه ولی خب اگر لازمه اضافه میشه و تغییرات رو اعمال میکنیم، یا اگر مثلا میخواید ما هم پشتیبانی از فایل JSON کنار همون TOML رو هم انجام بدیم، یا حتی یه آرگومان JSON رو پشتیبانی کنیم،
دوستان هر چیزی رو اوکی بودید منم اوکیم کلا.

در کل من به شخصه بیشتر حال میکنم اینجوری باشه
masterdnsvpn://encryption@domain:port/?protocol=socks5&encryption_method=1
یا همون Base64
masterdnsvpn://encryption@domain:port/?d=BASE64
چون عملا خیلی از پروژه ها ربطی دیگه به dnstt ندارن! Dnstt ساختار خودش رو داره، شاید ایده اولیه همه که دیتا رو از توی DNS رد کنن ثابت باشه ولی اینکه واقعا همون ساختار و .... رو داشته باشن بنظرم باحال نیست ...

درکل نظر جمع هرچی هست من بهش احترام میزارم، هرجوری هم ساختار رو خواستید و پیاده کردید اگر نیاز ما خودمون داخل پروژه پارسر داشته باشیم هم اوکیه من طبق چیزی که توافق میکنین اضافه میکنم.