Resolvers rcode processing - Specify a resolver based on rcode.

[cbuijs]

It would be nice on the resolvers section, to specify what happens per rcode returned on an answer. Responding a bit like how resolvers are used in other sections. When nothing is specified, the current way of working stays in place by passing the answer + rcode as it.

To illustrate:

[resolvers.doh-google]
protocol = "doh"
address = "https://dns.google:443/dns-query"
bootstrap-address = "8.8.8.8"
servfail-resolver = "nxdomain"
# nxdomain-resolver = "whatever-resolver"
# refused-resolver = "whatever-resolver"
# etc ...

[groups.nxdomain]
type = "static-responder"
rcode = 3

Not sure if a "noerror-resolver" is needed, but why not. :-)

Another one that would might be handy is a timeout-resolver when a timeout happens. So another resolver could be chained based on that event.

Case here is that sometimes when using an internal dns-server, a servfail triggers a unwanted failover in a fail-over group in front, and this would help to control that and provide more flexibility how to deal with it when a host of resolvers are used. Also it is a more direct way to chain other resolvers based on rcode responses.

See also #96.

[cbuijs]

Ping! Friendly Reminder.

[folbricht]

If I understand it correctly the goal is to be able to "retry" certain queries if the response to the first attempt was something other than NOERROR. I think the best way to do that would be a new element (group) that by default just passes queries through and is able to, based on rcode, retry against other resolvers. Something like this:

[groups.rcode-retry]
type = "rcode-retry"
resolver = ["cloudflare-dot"] # default for the first try
retry = {
  3 = "static-responder",  # turn NXDOMAIN into a fixed response
  2 = "google-dot", # try different upstream resolver on SERVFAIL
}

That could be quite useful and is more flexible than supporting these directly on every resolver. What do you think?

[cbuijs]

Makes complete sense, I like it a lot.