Project

General

Profile

Issue #2816

order of DNS entries is reversed in /etc/resolv.conf

Added by Hans van den Bogert about 2 years ago. Updated about 2 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
libcharon
Affected version:
5.6.2
Resolution:

Description

If a VPN server sends the following DNS servers in the given order:

- 8.8.4.4
- 8.8.8.8
- 1.1.1.1

It's appearance in /etc/resolv.conf will be the following:

- 1.1.1.1
- 8.8.8.8
- 8.8.4.4

It is not uncommon that the last entry is a fallback DNS server whereas the first 2 servers are the "company" hosted DNS servers. However with the reversed entries in /etc/resolv.conf, the intended fallback entry is now the primary DNS server.

It is caused by the fact the resolv plugin prepends the DNS server for every received DNS server to /etc/resolv.conf.

History

#1 Updated by Tobias Brunner about 2 years ago

  • Status changed from New to Feedback

It is not uncommon that the last entry is a fallback DNS server whereas the first 2 servers are the "company" hosted DNS servers.

What's the point of that? Doesn't the system itself have a fallback DNS server anyway?

It is caused by the fact the resolv plugin prepends the DNS server for every received DNS server to /etc/resolv.conf.

Yeah, I don't think that's not gonna change anytime soon.

#2 Updated by Hans van den Bogert about 2 years ago

What's the point of that? Doesn't the system itself have a fallback DNS server anyway?

Well no, most OSs and their IPSec client do not fallback to normal interface's corresponding DNS server as long as the VPN connection is alive.

Yeah, I don't think that's not gonna change anytime soon.

Why not? It's rather counter-intuitive at the least. Is it a lack of manpower or willingness? I'm willing to look into this.

#3 Updated by Tobias Brunner about 2 years ago

What's the point of that? Doesn't the system itself have a fallback DNS server anyway?

Well no, most OSs and their IPSec client do not fallback to normal interface's corresponding DNS server as long as the VPN connection is alive.

True, but some resolvers might even query all of them (I also never really understood associating DNS servers with interfaces, like e.g. systemd-resolved does, wouldn't it be necessary to resolve a hostname first, before being able to do a route lookup and to learn which interface should be used?). Also, assigning such a fallback doesn't really make sense unless you are willing to use it in the first place (I'm assuming you are already assigning redundant DNS servers so is it really necessary to add another fallback that might then not even be useful, e.g. to resolve internal hostnames?).

Yeah, I don't think that's not gonna change anytime soon.

Why not? It's rather counter-intuitive at the least. Is it a lack of manpower or willingness?

The attribute handler interface just provides single DNS servers (they could even be from different IKE_SAs). So to order them we e.g. had to parse resolv.conf and add additional servers after others we already added, so that gets quite a bit more complicated. Also, if resolvconf is installed (i.e. if resolv.conf is not modified by strongSwan directly) we don't have much control over the order because each DNS server is added to its own snippet. Although it might be possible to control the order via interface name of each snippet, which is currently just a prefix - lo.inet.ipsec. by default - followed by the DNS server address (maybe via a global counter that's just increased for each server and added between prefix and server address, which might not even be necessary anymore, and is stored in the refcount handler).

I'm willing to look into this.

Please go ahead, see contributions.

Also available in: Atom PDF