Я использую локальный сервер BIND9 для размещения некоторых локальных записей DNS. При попытке найти локальное доменное имя я не могу его найти, если явно не скажу dig использовать мой локальный сервер BIND9.
user@heimdal:~$ dig +short heimdal.lan.se
user@heimdal:~$ dig +short @192.168.1.7 heimdal.lan.se
192.168.1.2
Ubuntu 17.04 и systemd-resolved используются. Это содержимое моего / etc / resolved
# 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
И вывод из systemd-разрешения --status
Global
DNS Servers: 192.168.1.7
192.168.1.1
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
Раздел DNS-серверы, по-видимому, правильно настроил 192.168.1.7 в качестве основного DNS-сервера (мой локальный экземпляр BIND9). Я не могу понять, почему это не используется ...?
systemd
использует Google DNS в качестве запасного варианта ...systemd-resolve heimdal.lan.se
говорит?Ответы:
Таким образом, изменение моего проводного интерфейса eth0 для управления решило эту проблему для меня.
Изменение ifupdown на managed = true в /etc/NetworkManager/NetworkManager.conf
Затем перезапустите NetworkManager
После этого все работает без нареканий ..
Это не было 100%. Я также применил эти изменения, чтобы попытаться убить распознаватель
Большое спасибо за этот пост в блоге на эту тему: https://ohthehugemanatee.org/blog/2018/01/25/my-war-on-systemd-resolved/
Давайте помолимся, это работает .. Весь этот системно-разрешающий бизнес просто ужасен.
источник
systemd-networkd
связанный с ним другой вопрос - проверить, есть ли на устройствеeth0
илиenX
в*.network
файле `/ lib / systemd / network /` seeinfo systemd-networkd
andinfo systemd.network
andinfo resolved.conf
Я предполагаю, что ваш
systemd-resolved
сервис настроен правильно, но он никогда не увидит запрос..local
Домен специально обрабатываются с помощью систем , работающих под управлением MDNS .avahi-daemon
, который предоставляет службы mDNS / DNS-SD (также называемые «Bonjour» в продуктах Apple), может быть настроен на приоритет над DNS во время разрешения имен; похоже, что Ubuntu делает это.Есть несколько вариантов, которые вы можете выбрать:
Переименуйте свой
.local
домен во что-то другое (возможно,.internal
или.lan
). Это может быть проще всего сделать на практике, потому что вам просто нужно изменить пару вещей на вашем DNS-сервере, и это лучше всего работает с Avahi. Я бы порекомендовал этот метод.Измените ваш
/etc/nsswitch.conf
файл , поместивdns
запись передmdns
записями.Измените конфигурацию Avahi, чтобы изменить домен mDNS с
.local
чего-либо другого путем редактирования/etc/avahi/avahi-daemon.conf
и изменения (или добавления)domain-name=.something
(находится в[server]
разделе). Это необходимо сделать на каждом компьютере, использующем mDNS, чтобы они по-прежнему работали вместе.источник
Кажется, это будет лучше в качестве комментария, но недостаточно репутации ....
Самоотдача Кейвинга соответствовала тому, что я хотел.
Я также должен был добавить
dns=none
в[main]
раздел/etc/NetworkManager/NetworkManager.conf
, так что это выглядит так:Я только что обновил xubuntu 18.04, начиная с 14.04, и у меня есть локальная сеть, которая старше этой, со многими небольшими изменениями, накопленными за эти годы. Поэтому я хочу, чтобы мой DNS делал то, что я хочу (да, я приобрел много копий книги Крикета Лиуса за эти годы, начиная со второго издания).
Кроме того, я ранее добавлял информацию разрешения DNS, которую я хочу видеть в файл
/etc/resolvconf/resolv.conf.d/head
.В двух словах, когда-то у меня был рабочий /etc/resolv.conf от имени root:
Но сейчас я просто редактирую /etc/resolv.conf напрямую, и он остается на месте. Посетители моей локальной сети, которые используют systemd / resolvconf, являются SOOL. Их не существует.
Чтение
man 8 resolvconf
помогло. Много. Я не следовал инструкциям по размещению вещей там, где их могла найти программа ifup. Главным образом потому, что в графическом интерфейсе есть целая надстройка, которая уже игнорировалась тем, что было сделано во время обновления. Это кажется более серьезной проблемой (WTF, Ubuntu?).Так что это бесполезно, и есть еще проблема, что то, что я (давно) ввел в GUI панели управления сетью, не подчинялось недавно обновленной системе, но это совершенно другой вопрос, как только я выясню, как спроси это.
источник
Для меня, запустив недавно установленную 18.04, я сделал первое изменение, упомянутое @Civing:
затем, заметив, что /etc/resolv.conf всегда указывает stub-resolv.conf и что создается разумный resolv.conf с соответствующим DNS-сервером локальной сети, изменил символическую ссылку:
а затем локальные все имена хостов, разрешенные с помощью ping.
Еще неизвестно, как долго это продолжает работать.
Когда я первоначально установил, настройка беспроводной сети не удалась, и я не могу не задаться вопросом, оставила ли установка /etc/resolv.conf в этом начальном состоянии.
Итак, одно из предложений - посмотреть, что порождает решенное; у вас уже может быть рабочая база.
источник