Safety tips for Mint 19 users.

[upuv]

Hello Everyone,

I've run into this issue a few times now with a few people that use Mint and more importantly Mint19. Mint 19 is a based on Ubuntu 18.04. There are a few issues that I have come across in my own installations and those of others. Thought I'd share some of the head scratcher moments my colleagues and myself have faced.

Some facts:
Mint 18.x is based of of Ubuntu 16,04
Mint 19 is based off of Ubuntu 18.04

Ubuntu has introduced some new things that can change your experience with Mint. And not necessarily for the better.

1. Ubuntu 18.04 now includes systemd.resolved and it replaces dnsmasq.
The DNS resolver built into systemd has included some extra functionality / changes that are meant to improved security. The completely undocumented feature of not resolving dotless domains. So what does this mean? Well in some environments when you join the network the network will provide a DNS via DHCP. If the network admin decided to declare a domain for the internal network something like. "starbucks". What will happen is your machine will NOT resolve DNS at all if it's on DHCP. If the domain were defined as "starbucks.shop". It would all of a sudden magically resolve DNS. Not ONLY systemd does this. All other resolvers out there do not follow this rule.

This is easily remedied permanently and restores past behaviour.
The file /etc/resolv.conf is actually a link to a systemd file. You can simply change it like so.

Code: Select all

sudo rm /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf 

This works because systemd also generates a resolv.conf based on information from DHCP. And this is what is being linked to. It will update for each network you join.


2. Ubuntu 18.04 upgraded libcurl to version 4.
This can be a nasty issue if you do not pay attention to your old /etc/apt/sources.d/* files. If you simply copy over you old 3rdparty source files you will likely break your system a little. Version 4 and version 3 of libcurl can NOT co-exist on a system. You old apt sources were most often based off of xenial or ubuntu 16.04. In that release libcurl was at version 3. Some bright spark decided that they needed to include a pre-release version of libcurl version 4 shared library. So they put libcurl.so.4 into the version 3 lib. This instantly means that there is now a file conflict between the two packages. Now if your old apt sources include xenial in them you might actually also be including a dependency on libcurl version 3.

A classic issue is virtualbox. If you run Virtualbox and you install it from Oracle via the repo you could easily make this mistake. The xenial dist of virtualbox depends on version 3. The bionic release depends on version 4.

Make sure you scan your apt sources to ensure that there are NO xenial references at all. They should all be bionic. But of course this will also depend on the actual source itself. You will have to investigate each one.

Do you have the issue? Performa this command.

Code: Select all

grep -l xenial /etc/apt/sources.list.d/*.list

If anything comes back you should investigate each apt source listed.

[gm10]

This is easily remedied permanently and restores past behaviour.

Maybe not call that a "safety tip" though.

Dotless domains are considered a problem for a reason, not the least of which is that your searches for them can end up on the Internet. See also e.g. https://www.iab.org/documents/correspon ... d-harmful/

systemd-resolved routes single label name lookups via LLMNR, alternatively you can set up a local search domain if you need to resolve via your local DNS server.

None of this is undocumented btw, it's explained in the respective man pages.

[upuv]

local search domains also do not work in a dotless domain structure with systemd.
The example I used "starbucks" illustrated that. Note this is exactly what happens in the US with a starbucks free wifi.

The document you refer to has not been updated since 2013. I have researched activity on it. And activity on the subject ceased in 2013.
I do understand the issue of dotless domains. Now this whole topic is probably going to be a HUGE issue with ICAN releasing so many top level domains. I'm already seeing issue with ISP's setting search domains for top levels they own.

For a person that uses a laptop with Ubuntu or Mint ( latest versions ) and you decide to use wifi hotspots you will run into this issue. Hotels, Airports and coffee shops often make use of dotless domains. All of a sudden you will have NO DNS resolution and it will drive you nuts.

Unfortunately LLMNR is not wide spread. It's this gap between LLMNR implementation in the field and not resolving dotless domains that results in broken name resolution.

Now the documentation on this issue in systemd is effectively non-existent. Last I looked there was ZERO mention of lack of resolution of dotless domains. I did raise a few defects on this. So I'm not sure if the doco was updated in 239. 238 definitely not documented. ( Unless it was patched. ) This is my major gripe on the topic. DO NOT CHANGE FUNCTIONALITY WITHOUT DOCUMENTING IT. It was a classic systemd I'll change the standard and not tell anyone issue all over again. And also there is NO logging of the dropped DNS request. ZIP. So you have no idea why it just stopped working. Even DEBUG shows ZIP. Which is even worse a crime than no documentation.

I'm not debating wether dotless domains are bad or not ( It's bad ). I'm simply stating you will end up in a situation where DNS resolution will break. DHCP is suppose to provide you a working resolver. ( Generally ) But your localhost silently decides not to use it. That's really bad.

And the primary reason I call it a safety tip. Is that if you read the above you will not end up doing something really stupid trying to fix it. When a working solution that is no worse that any operating system implementation is achieved via changing a link.

[gm10]

And the primary reason I call it a safety tip. Is that if you read the above you will not end up doing something really stupid trying to fix it.

Fair enough, that's as good a reason as any.

[blockhead47]

Thanks upuv.
Very informative information. This explains some of the DNS issues I saw after I upgraded to Mint 19.