DNS Settings#

Tip: You can change these settings directly in the bgscan application instead of editing the TOML file manually.

Navigate to Settings → DNS Settings in the main menu to configure these options interactively using the TUI inspector.

Configuration file: settings/dns_settings.toml

This file has two sections. The resolver section controls plain DNS resolver testing. The dns_tunneling section controls how DNS tunnel scans are orchestrated — tunnel protocol-specific settings (DNSTT, VayDNS, Slipstream) are stored in separate config files under assets/dns-tunneling/.

Quick Reference#

Resolver#

Each target IP is treated as a resolver. The probe queries domain through it and keeps the target if the response code is in accepted_rcodes.

Workers#

[resolver]
workers = 150

Concurrent queries in flight. The effective default depends on platform and resource tier. UDP queries are cheap, so this scales further than the HTTP probe, but a high rate against a single upstream network will be noticed.

Protocol#

[resolver]
protocol = "udp"

Transport used for queries: udp, tcp, or dot. Parsing is case-insensitive; unknown values default to udp.

Domain#

[resolver]
domain = "example.com"

Domain queried through each resolver. It must be a bare domain with no scheme, port, or path. Pick a name that resolves reliably worldwide, otherwise honest resolvers will look broken.

Port#

[resolver]
port = 53

Port the resolver listens on. Use 853 with protocol = "dot".

Check Types#

[resolver]
check_types = ["TXT"]

Record types tried in order. The probe stops at the first type that returns an accepted rcode and records that type in the result. Add more types when a resolver may answer for one and refuse another.

Supported record types: A, AAAA, CNAME, NS, MX, TXT, SRV, NULL, CAA.

EDNS Buffer Size#

[resolver]
edns_buffer_size = 1232

UDP payload size advertised in the OPT record. 0 disables EDNS0.

Timeout#

[resolver]
timeout = 2000

Per-query timeout in milliseconds.

Tries#

[resolver]
tries = 1

Attempts per record type. Retries only cover network errors. Once any DNS response arrives, even with a rejected rcode, the probe moves on to the next record type without retrying.

Random Subdomain#

[resolver]
random_subdomain = true

Prepends a random 10-character label to domain for each probe. This defeats resolver caches and forces a real recursive lookup, so latency reflects the resolver doing work rather than serving a cached answer.

Accepted RCodes#

[resolver]
accepted_rcodes = ["NOERROR", "NXDOMAIN", "SERVFAIL"]

Response codes counted as a live resolver.

With random_subdomain enabled, NXDOMAIN is a normal answer for a made-up label, which is why it is accepted by default.

Output Prefix#

[resolver]
output_prefix = "dns_"

Filename prefix for resolver results. Files land in result/dns_resolver/.

DPI Check#

[resolver.dpi]
enabled = true
timeout = 2000
tries = 1

The DPI (Deep Packet Inspection) check runs before the real queries. The probe asks the resolver for a random .invalid name, which cannot exist. A resolver that answers NOERROR is fabricating results, so the target is dropped. Any other rcode counts as honest. The outcome is stored per result as passed or skipped.

timeout is in milliseconds (range 100-10000). tries ranges from 1-10. Keep the DPI timeout well below the main timeout so dead targets are discarded quickly.

DNS Tunneling#

The dns_tunneling section controls how tunnel scans are orchestrated. It does not contain tunnel protocol settings — those are stored in separate per-config TOML files under assets/dns-tunneling/.

Workers#

[dns_tunneling]
workers = 16

Concurrent tunnel test workers. Each worker runs its own tunnel probe and holds a local port, so this is far more expensive than the resolver probe. The effective default depends on platform and resource tier.

Tries#

[dns_tunneling]
tries = 1

Retry attempts per target.

Timeout#

[dns_tunneling]
timeout = 10000

Time budget for bringing up the tunnel and validating it, in milliseconds. Tunnel tests need more time than plain DNS queries.

Check DNS Resolver#

[dns_tunneling]
check_dns_resolver = true

When true, a resolver pre-scan runs before the tunnel test. Only resolvers that pass the resolver scan are tested as tunnel candidates. This avoids wasting tunnel probes on resolvers that cannot even answer basic DNS queries.

Adaptive Resolver#

[dns_tunneling]
adaptive_resolver = true

When true, the resolver settings (transport, port, domain) are automatically overridden to match the selected tunnel configuration. For example, if a DNSTT config uses resolver_type = "tcp" on port 853, the resolver pre-scan will use the same transport and port. This ensures the resolver pre-scan tests the same path the tunnel will use.

When false, the resolver pre-scan uses the settings from the [resolver] section as-is.

Output Prefix#

[dns_tunneling]
output_prefix = "dns_tun_"

Filename prefix for tunnel result files. Files land in result/dnstt/, result/vaydns/, or result/slipstream/ depending on the protocol.

Tunnel Configurations#

DNS tunnel protocols (DNSTT, VayDNS, Slipstream) are configured through separate TOML files stored under assets/dns-tunneling/:

assets/dns-tunneling/
├── dnstt/
│   ├── my-dnstt-config.toml
│   └── ...
├── vaydns/
│   ├── my-vaydns-config.toml
│   └── ...
└── slipstream/
    ├── my-slipstream-config.toml
    └── ...

These configs are created and managed through the TUI at Main Menu → DNS Tunneling. Each config has a name, a protocol type, and protocol-specific fields. See DNS Tunneling for detailed configuration of each protocol.

Related Files#

• general_settings.toml — Global scan control and pipeline mode
• icmp_settings.toml — ICMP scan configuration
• tcp_settings.toml — TCP port scan configuration
• http_settings.toml — HTTP/HTTPS/HTTP3 probe configuration
• xray_settings.toml — Xray outbound validation
• writer_settings.toml — Result output configuration
• DNS Tunneling — Tunnel protocol configuration