Scope associated resolvers to a zone

[kontaxis]

Some of the use cases in this draft are:

• names that are only resolvable in the local context (or split-horizon situations)
• (local) policies such as malware prevention

It would be useful if the OS-configured resolver could specify that:

• DoH resolver x.y.z.w should used for .company-domain.com. (split-horizon)
• DoH resolver k.l.m.n must not be used for .company-domain.com. (to avoid leaking names)
• DoH resolver a.b.c.d. can be used for everything

DoH servers from HTTPS

{ "associated-resolvers":
    [
        { "resolver": "https://x.y.z.w/dns-query{?dns}",
           "+zones": [ "company-domain.com", "company-domain.net" ]
        },
        { "resolver": "https://k.l.m.n/a/b/c/dns-query{?dns}",
           "-zones": [ "company-domain.com", "company-domain.net". ]
        },
        { "resolver": "https://a.b.c.d/a/b/c/dns-query{?dns}",
        },
    ]
}

DoH servers from DNS

$ORIGIN resolver-associated-doh.arpa.   
 IN TXT "https://x.y.z.w/dns-query{?dns} +zones:company-domain.com,company-domain.net" 
 IN TXT "https://k.l.m.n/a/b/c/dns-query{?dns} -zones:company-domain.com,company-domain.net"
 IN TXT "https://a.b.c.d/a/b/c/dns-query{?dns}"

Thoughts?

[bemasc]

• Terminology: I find the term "OS-configured" confusing here.
• Process: This would be a significant change, worthy of discussion on the mailing list.
• Substance: I'm not convinced that the syntax you've sketched achieves the goal you've proposed. The precise semantics of "+" and "-" are unclear. I suspect there's a more elegant solution, perhaps a decision tree represented as a JSON tree.

[kontaxis]

By "OS-configured resolver" I mean the resolver the device has today as part of its system-wide network configuration for the particular interface. (Received over DHCP or manually set by a human operator)
I'm open to using a better term of course.

The idea is that "+" forms a whitelist and "-" forms a blacklist.
If either is present then all names must be matched against the list.
If both are present then the blacklist takes precedence. (I just thought of that)
If a match is found then depending on the type of list the corresponding action is taken: use this resolver or move on to the next (or fail if there is no next)

[bemasc]

Feel free to propose this to the mailing list. However, I don't recall any mention of a use case that would motivate this design. In particular, neither of the two use cases requires this kind of client-side server selection. These use cases are typically served by a single customized recursive resolver that has hardcoded answers (or blocks) for some queries. To motivate this design, you would need to explain why the traditional approach is insufficient or undesirable.

Personally, I don't see much value in splitting one server into multiple servers, and then transferring the logic of which server to use to the client.