/etc/network/interfaces: "dns-nameservers" entries for bridge "br*" interfaces are ignored i.e. they are not listed in "/etc/resolv.conf" when invoking "ifup" command

/etc/resolvconf/interface-order is only supposed to determine the order in which interfaces are preferred as sources of DNS configuration, it should certainly not cause the DNS servers for an interface to be ignored completely. Please attach your full /etc/network/interfaces, as well as the contents of the /run/resolvconf directory (in particular, the /run/resolvconf/interface subdirectory).

In the attachment you will find the file "/etc/network/interfaces" and the directory "/run/resolvconf" before ("run-resolvconf-before.tgz") and after ("run-resolvconf-after.tgz") doing the "sudo ifup br0 br1".

Just FYI the files I attached previously in "interfaces-and-resolvconf.tgz" was done using my workaround mentioned above. For completeness I therefore attach as well my "/etc/resolvconf/interface-order" file.
If you like I can as well perform the steps above without applying my workaround.

Ok. So the crucial thing shown here is that in addition to the br interfaces, you have NetworkManager. NetworkManager sets 'nameserver 127.0.1.1', which by design will redirect DNS requests to a local dnsmasq proxy, with dnsmasq itself picking up the configured nameservers instead; and when set, resolvconf will truncate the dns server list (because 127.*.*.* is special), so you won't see these in /etc/resolv.conf.

The only thing I can't figure out is why changing the order of processing of the interfaces has any effect at all for you, since NetworkManager should still be processed and the 127.0.1.1 should still take precedence.

So the root problem is that dnsmasq doesn't have an interface that allows injecting of individual dns servers into its config, which means it can only interface with a single client at a time - in this case, NetworkManager, which doesn't know about network interfaces that are configured via ifupdown.

NetworkManager and ifupdown can coexist rather reasonably together, and have done so for quite a while, but they can't coexist very well when dnsmasq is used.

So there are several workarounds you could employ at the configuration level:
 - change /etc/NetworkManager/NetworkManager.conf to not use 'dns=dnsmasq'
 - if you aren't using any interfaces other than the bridges, disable use of NetworkManager altogether.

Regardless, it's a limitation of dnsmasq that it doesn't have a proper dbus interface for controlling dns servers.

Thank you for the detailed analysis - regarding:
... since NetworkManager should still be processed and the 127.0.1.1 should still take precedence ...
Actually for me it is important that the "127.0.1.1" does not take precedence but instead my local name-servers take precedence (because when my local network is up (br0 & br1) then the name-resolving should take place there first and not on "127.0.1.1" which points to the internet - otherwise the wrong servers are getting resolved).

I gather that you want to use the fact that the resolver happens to try one address after another, in the order that they are listed in resolv.conf, as a way of giving precedence of one domain name system (the service provided over the br* interfaces) over another domain name system (the one serving the Internet and accessible by the forwarder on your machine at 127.0.1.1). That's not how DNS or the resolver were meant to be used and hence that is not implemented by the default system configuration. Given your aims, it's up to you to configure /etc/resolvconf/interface-order so that br* is listed before lo*.

So why isnt br* already listed by default in the file /etc/resolvconf/interface-order ? There are many other entries for everything else. And presumably it should do no harm / detriment.

Should that not be the fix here?

br* bridge interfaces are a common class of network devices and are being used quite often.

Also: the suggested workaround didnt actually work for me. on 15.10 / wily

br matching was added to interface-order in Debian release 1.77, thus in wily which has resolvconf 1.77ubuntu1.

This problem is present in Ubuntu 16.04 Xenial Desktop build, as well

Quick workaround:

$ rm /run/resolvconf/interface/NetworkManager

Deleting /run/resolvconf/interface/NetworkManager and re-running ifdown/ifup will result in the /etc/network/interfaces dns-nameservers to be populated into /etc/resolv.conf (aka ../run/resolvconf/resolv.conf)

*Ubuntu 16.04*
The workaround by deleting /run/resolvconf/interface/NetworkManager did not work for me.
Removing dns=dnsmasq from /etc/NetworkManager/NetworkManager.conf did work.