I'm copying an interesting idea from a closed bug report about turning off resolv.conf management. The idea was to allow an external script to serve as a DNS configuration backend. This would let us get rid of support for various backends like resolvconf and netconfig in NetworkManager source code. It would make creation of simple backends a lot easier, too.

From closed bug report:

https://bugzilla.gnome.org/show_bug.cgi?id=690404#c6 (Dan Winship):

the dns= key will become a string instead of a list of strings; this is
backward-compatible, because there is currently only one valid value for it
anyway.

The values are:

  (unset) or "dns=auto": the same thing as the default behavior now,
    which is: use resolvconf if built with resolvconf support, or
    netconfig if built with netconfig support, or else modify
    /etc/resolv.conf directly

  "dns=dnsmasq": same as now: send the real DNS configuration to dnsmasq,
    and then do resolvconf/netconfig/direct modification as above, but
    using 127.0.0.1 as the only nameserver.

  "dns=none": don't modify resolv.conf at all, by any means

  "dns=/path/to/script": run that script, with details of the current DNS
    configuration passed in via environment variables, and don't do
    anything else

This is simple, and lets you do anything (via a script), and is
backwards-compatible, and doesn't cause any existential angst about "well
should we still call resolvconf if the previous script did X". The fact that
the script needs to magically know whether to call netconfig or resolvconf is
not a problem, because such scripts are expected to be just for the machine
that they're on, to implement arbitrary one-off requests like "I want the VPN
nameservers after the local ones not vice versa" (bug 673793), not to be
portable means of implementing generically useful behavior (which would be
implemented as additional built-in plugins if they were needed).