После изменяющихся сетей поиск DNS перестал работать к доменам, которые были локальны

Я недавно обновил от 16,04 до 17,10, и некоторым доменным именам теперь не удается решить в systemd-resolved, даже при том, что мой домашний сервер DNS разрешает доменные имена очень хорошо.

Мой домен рабочего места *.cs.bham.ac.uk (Информатика в uni), и те домены твердость, прекрасная, когда я работаю. Но когда я иду домой, те домены прекращают решать. Место, где я теперь, не имеет никаких отношений ни к чему .bham.ac.uk.

bgeron@tinker ~> systemd-resolve git.cs.bham.ac.uk
git.cs.bham.ac.uk: resolve call failed: No appropriate name servers or networks for name found
bgeron@tinker ~> host git.cs.bham.ac.uk
Host git.cs.bham.ac.uk not found: 2(SERVFAIL)
bgeron@tinker ~> host git.cs.bham.ac.uk 192.168.1.254
Using domain server:
Name: 192.168.1.254
Address: 192.168.1.254#53
Aliases: 

git.cs.bham.ac.uk has address 147.188.203.99
bgeron@tinker ~> systemd-resolve --status
Global
          DNS Domain: lan
                      adf.bham.ac.uk
                      bham.ac.uk
                      cs.bham.ac.uk
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 4 (docker0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 3 (wlp4s0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.1.254
          DNS Domain: lan

Link 2 (enp0s31f6)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Я понятия не имею, почему те домены DNS перечислены там. Это похоже на устаревший кэш некоторых видов. Выполнение systemd-resolve --flush-caches поскольку корень, кажется, не оказывает влияния.

Содержание /etc/resolv.conf:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53
search lan adf.bham.ac.uk bham.ac.uk cs.bham.ac.uk

Когда я удаляю search строка, затем поиски работают снова. Но очевидно это не постоянное решение.

Я полагаю, что в значительной степени просто использую ванильный NetworkManager. У меня есть настроенное устройство PAN Bluetooth, но не активированный.

В прошлом в uni была проблема с локальными именами хостов, не решая: Я верю *.cs.bham.ac.uk решил бы (как определено хостом (1)), но нет *.bham.ac.uk. Я не могу вспомнить что systemd-resolve сказал бы для тех ситуаций. Для фиксации его я уничтожил /etc/nsswitch.conf и вставленный в следующее содержание, которое я нашел онлайн где-нибудь:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat

hosts:          dns [!UNAVAIL=return] files
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Некоторые записи в журнале в моем журнале, который может или не может быть связан:

• wpa_supplicant: не Мог считать интерфейс p2p-dev-wlp4s0 флаги: Никакое такое устройство
• Мой драйвер GPU испускает некоторые предупреждения.

Еще:

Nov 05 22:39:59 tinker systemd[1]: Starting Network Name Resolution...
-- Subject: Unit systemd-resolved.service has begun start-up
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- Unit systemd-resolved.service has begun starting up.
Nov 05 22:39:59 tinker systemd-resolved[11818]: Positive Trust Anchors:
Nov 05 22:39:59 tinker systemd-resolved[11818]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
Nov 05 22:39:59 tinker systemd-resolved[11818]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Nov 05 22:39:59 tinker systemd-resolved[11818]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 168.192.in-addr.arpa d.f.ip6.arpa corp home internal intranet lan local private test
Nov 05 22:39:59 tinker systemd-resolved[11818]: Using system hostname 'tinker'.
Nov 05 22:39:59 tinker systemd[1]: Started Network Name Resolution.
-- Subject: Unit systemd-resolved.service has finished start-up
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- Unit systemd-resolved.service has finished starting up.
-- 
-- The start-up result is done.
Nov 05 22:50:52 tinker systemd-resolved[11818]: Flushed all caches.

Любые идеи очень приветствовались бы!

Разъяснение редактирования: Попытка разрешить любые из тех имен хостов не приводит ни к какому сетевому трафику, она сразу дает отрицательный результат.