make it possible to assign outbound on dns configuration

Start by reviewing the reproduced dns rules and servers configuration, then trace how DNS results are associated with routing and outbound selection. Done means a documented, reproducible configuration can select the outbound route based on the DNS server used or the returned address, with the provided poisoned-DNS scenario covered by tests.

Operating system

Linux

System version

ArchLinux

Installation type

Others

If you are using a graphical client, please provide the version of the client.

nekoray 4.0.beta3

Version

1.9.3

Description

The official DNS servers in my country return a known constant ip address for blocked websites. So, I wanted to write a config which assigns the route based on dns server used(or ip address returned by a specific dns server). I was able to seperate dns server used for resolving names but it doesn't seem to be possible to assign route used after resolving the name.

Reproduction

Here's the config mentioned on the above Description where $poisonedDnsServer always returns $blockedIP for blocked websites and $nonPoisonedDnsServer returns correct ip for any website.

dns: {
    "rules": [
        {
            "invert": true,
            "ip_cidr": [
                "$blockedIP"
            ],
            "server": "dns-poisoned"
        },
        {
            "ip_cidr": [
                "$poisonedDnsServer"
            ],
            "server": "dns-block"
        }
    ],
    "servers": [
        {
            "address": "$nonPoisonedDnsServer",
            "detour": "direct",
            "tag": "dns-remote"
        },
        {
            "address": "$poisonedDnsServer",
            "detour": "direct",
            "tag": "dns-poisoned"
        },
        {
            "address": "rcode://success",
            "tag": "dns-block"
        },
        {
            "address": "$poisonedDnsServer",
            "tag": "dns-local"
        }
    ]
}

Logs

No response

Supporter

• I am a sponsor

Integrity requirements

• I confirm that I have read the documentation, understand the meaning of all the configuration items I wrote, and did not pile up seemingly useful options or default values.
• I confirm that I have provided the server and client configuration files and process that can be reproduced locally, instead of a complicated client configuration file that has been stripped of sensitive data.
• I confirm that I have provided the simplest configuration that can be used to reproduce the error I reported, instead of depending on remote servers, TUN, graphical interface clients, or other closed-source software.
• I confirm that I have provided the complete configuration files and logs, rather than just providing parts I think are useful out of confidence in my own intelligence.