DNS nameserver order in /etc/resolv.conf

[dolfs]

Pardon me if this has been brought up before. I did a quick search but did not find it...

I noticed that my Meteobridge was producing a fair amount of DNS network traffic my outside DNS server (8.8.8.. However, I have a local caching DNS server and my DHCP server is setup to deliver that one first. So in the /etc/resolv.conf I would expect the local to be listed first and 8.8.8.8 second. Logging into the Meteobridge (running on TP-LINK) I see that 8.8.8.8 id listed first, in contravention of what the DHCP server delivers. Checking in my Mac and a RaspBerry pi running Raspbian shows it to be correct there.

I can't help but think that MeteoBridge changes the order on purpose, but this defaults the purpose of my local DNS server. Bug? On purpose? If yes on the latter, how do I prevent this?

[admin]

You can configure static ip and give dns server ip manually. Otherwise it takes dns as your dhcp server provides this.

[dolfs]

I understand I could configure a static IP and static DNS server. The purpose of DHCP, of course, is to not have to do this for each device, but rather do it only once in the server setup. As per DHCP spec. the order of name servers is relevant and as described in my post, MB puts them /etc/resolv.conf in reverse order. No idea whether this is on purpose, or a bug in the code somewhere, but it is definitely not adhering to the spec.

If I had to follow your advice for all my various "gadgets" (any not a computer), I would have to maintain 8+ configurations in the various devices, and any change on my situation, rather than solvable by editing the DHCP configuration, would require each of the devices to be updated manually. Possibly, but hardly desirable.

In my case, I have high bandwidth, high speed Internet, so in the end this is merely an observation on my end and not an actual problem. For more rural users in different bandwidth/cost situations this would be different and they would likely want to see i fixed.

For what it is worth, this is perhaps a problem in OpenWRT as the file /tmp/resolv.conf.auto, produced by the MB acting as a DHCP client and based upon info from my DHCP server, is linked to /etc/resolv.conf and thus indicates that it is the DHCP client that messes with the order.

[Mattk]

DHCP is not used all that much in the real IT world, yes DHCP can be useful for limited individual use but for serious systems (apart from the generic type desktop/PC environment) then it's generally not a consideration. My suggestion would be to allocate your MB (and especially MB Pro's) with a fixed IP.

[dolfs]

Of course the vast majority of MB users are not deploying it on a serious IT world infrastructure. I also disagree with your assessment. I have long worked in this world and, in particular where wireless is used, DHCP is in wide use. DHCP can also be used (as I do) with a pre-allocation (static-mapping) of IP addresses. This way you effectively get a static IP, yet have centralized management. It does have the stated problem with name servers.

I'd also point out that in scenarios such as the one described, the first listed name server is often a local name server, capable of resolving local DNS, whereas the second is not (external, so cannot). Getting the order wrong prevents any use of HTTP requests to services on a local network by name because the external service cannot resolve and due to the way DNS works, there is no fallback to the second server. The ordering is meant to only fall back to the external server if the first one fails (on a network level, not on a lookup level). This is, not at all, unusual in the real IT world.