DNS Workflow Improvement

[Vigilans]

Config Initialization

Currently, many of DNS configs are applied for global scope, but sometimes user may want to apply a certain strategy for only a specific client.

For example, one may expect to enforce some domains to only use ipv6 address, which could be done by specifying matchers for these domains to a DNS client and set only this client's queryStrategy to UseIpv6, while keeping other clients to their own strategies.

V2Ray actually provides a similar workflow for two configs: clientIP and fallback (disableFallback and skipFallback). What's not intuitive for fallback config is that it introduces two flag switches with different name.

Current V2Ray introduces even more flag switches in a DNS config:

v2ray-core/app/dns/dns.go

Lines 29 to 35 in 1490ce6

	type DNS struct {
	sync.Mutex
	tag string
	disableCache bool
	disableFallback bool
	disableFallbackIfMatch bool
	ipOption *dns.IPOption

We may refactor the DNS config workflow in this hierarchy design:

1. The central DNS object only takes care of the management of static hosts and DNS clients, and all of its client configs will be forwarded so that
2. Each Client object will hold their distinct configs, and json configs specified in dns scope is just used as global default config if not overridden in client's own json configs.

So DNS and Client struct will look like this:

type DNS struct {
	sync.Mutex

	hosts   *StaticHosts
	clients []*Client
        fakedns *Client

	domainMatcher strmatcher.IndexMatcher
	matcherInfos  []DomainMatcherInfo
}

type Client struct {
	tag      string
	server   Server
	clientIP net.IP

	queryStrategy    dns.IPOption
	fallbackStrategy FallbackStrategy
	cacheStrategy    CacheStrategy
}

So:

• Each Client could have their own inbound tag during routing decision, or just use the same tag globally configured by DNS object.
• Each Client could have their own clientIP
• Each Client could have their own queryStrategy, so some clients may be used to return only ipv4/ipv6 addresses for certain domains.
• Each Client has their fallbackStrategy set separately. The fallbackStrategy may be enabled, disabled or disabledIfAnyMatch. The old global dns.disableFallback and dns.disableFallbackIfMatch will be properly handled for backward compatibility.
• Each Client has their own cacheStrategy (currently only enabled or disabled)

[Vigilans]

Resolution Loop

When sending DNS requests with DNS server address to be a domain, during route pick the domain may trigger a new round of DNS request, and the request may be handled by a DNS server with domain address, causing infinite resolution loop.

Inspired by how FakeDNS deals with v2ray configs in PostProcessingStage:

v2ray-core/infra/conf/v4/lint.go

Lines 16 to 23 in 1490ce6

	func PostProcessConfigureFile(conf *Config) error {
	for k, v := range configureFilePostProcessingStages {
	if err := v.Process(conf); err != nil {
	return newError("Rejected by Postprocessing Stage ", k).AtError().Base(err)
	}
	}
	return nil
	}

We could collect all domains used in dns config and outbound config, and create a new domain list out of these domains, which could be lately referenced by DNS clients.

• List name could be builtin:, v2ray:, or whatever.
• DNS servers and outbound servers could be retrieved using builtin:dns and builtin:outbound.

The servers list could then be matched and handled by DNS clients with address to be simple IP address (e.g. a simple UDP DNS), or localhost. If in json config no DNS client specified to handle this list, it will be implicitly delegated to localhost.

BTW, localhost has already implicitly managed a list geosite:private for local domains, and the creation of this list could also be moved to the ConfigureFilePostProcessingStage.

[Vigilans]

FakeDNS Workflow

Currently FakeDNS involves two important flows:

• Whether a user of dns.Client expects FakeDNS to work in a name lookup.
• How FakeDNS participates in name lookup among a list of working servers.

The current implementation of first flow is counter-intuitive because it places FakeDNS on a global-scope influence. Therefore, for freedom outbound and routing decision, they have to take the burden to disable FakeDNS manually:

v2ray-core/features/routing/dns/context.go

Lines 35 to 40 in 1490ce6

	if c, ok := ctx.dnsClient.(dns.ClientWithIPOption); ok {
	ipOption = c.GetIPOption()
	c.SetFakeDNSOption(false) // Skip FakeDNS.
	} else {
	newError("ctx.dnsClient doesn't implement ClientWithIPOption").AtDebug().WriteToLog()
	}

Considering SetFakeDNSOption modifies a member of DNS object, it is actually an ill pattern because each DNS.Lookup is coupled together with a global state in DNS object.

To improve this workflow, we may regard FakeDNS as a capability of DNS that should be manually enabled rather than manually to disable. That is:

• For a normal dns.Client, Lookup, LookupIPv4, LookupIPv6 will perform a normal DNS lookup without FakeDNS participating in.
• Provide a new interface ClientWithFakeDNS providing a method AsFakeDNSClient() (dns.Client, error), which will convert current dns.Client to a new dns.Client with FakeDNS enabled.
• For this new dns.Client, its Lookup, LookupIPv4 and LookupIPv6 will use FakeDNS to provide lookup results.

---

(Draft)

For the second workflow, it would require many extra efforts for fakedns to work together with other name servers, like descriptions in #789, and because freedom and routing will not use fakedns, it makes the interpretation of matching rules more difficult.

So, instead of integrating fakedns with normal name servers, why not just extract fakedns as an individual config inside dns, and participate in client selection when needed?

The json configuration will look like this:

{
    "servers": [
        {
            "address": "223.5.5.5",
            "domains": [
                "geosite:cn"
            ],
            "expectIPs": [
                "geoip:cn"
            ]
        },
        "8.8.8.8"
    ],
    "fakedns": {
        "priority": "some-priority-strategy",
        "domains": [
            "some-domain-matching-rules"
        ],
        "...": "..."
    }
}

Therefore:

• During freedom outbound and routing decision, the DNS will work as servers field indicates.
• For DNS outbound, the fakedns field will participate in name resolution according to a certain prority strategy.

[Vigilans]

Lookup Flow (Draft)

One logic during Lookup that seems not so making sense:

v2ray-core/app/dns/dns.go

Lines 304 to 308 in 1490ce6

	if len(clients) == 0 {
	clients = append(clients, s.clients[0])
	clientNames = append(clientNames, s.clients[0].Name())
	newError("domain ", domain, " will use the first DNS: ", clientNames).AtDebug().WriteToLog()
	}

During DNS client selection, if the final selected clients are zero, it is because no server is matched and fallback round-robin query is disabled. Fallback is disabled to prevent DNS leak according to discussion I found, but use first DNS here actually works as a new fallback. Maybe it should be better to just return empty response if all clients are filtered?

[Vigilans]

@Loyalsoldier

[Loyalsoldier]

Please file a PR :)

[Loyalsoldier]

@kslr @xiaokangwang @AkinoKaede @nekohasekai