Systemd ile çözülen neden yerel DNS sunucumu kullanmıyor?


13

Bazı yerel dns kayıtlarını barındırmak için yerel bir BIND9 sunucusu kullanıyorum. Bir yerel etki alanı adı için kazmaya çalışırken açıkça kazmak yerel BIND9 sunucumu kullanmak için söylemezseniz bulamıyorum.

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 ve systemd çözümlü kullanılır. Bu / etc / resolved'imin içeriği

# 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

Ve systemd-resol --status çıktısı

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 Sunucuları bölümü 192.168.1.7'yi ana DNS sunucusu (yerel BIND9 örneğim) olarak doğru bir şekilde yapılandırmış gibi görünüyor. Neden kullanılmadığını anlayamıyorum ...?


systemdGoogle DNS'yi yedek olarak nasıl kullandığına dair bir şey hatırlıyorum ...
William Edwards

Ne systemd-resolve heimdal.lan.seanlatıyor?
Bigon

Yanıtlar:


8

Bu nedenle, yönetilecek kablolu eth0 arayüzümü değiştirmek benim için bu sorunu çözdü.

İfetdown öğesini /etc/NetworkManager/NetworkManager.conf içinde yönetilen = true olarak değiştirme

[ifupdown]
managed=true

Ardından NetworkManager'ı yeniden başlatın

sudo systemctl restart NetworkManager

Bundan sonra kusursuz çalışır ..

Bu% 100 değildi. Çözücüyü öldürmek için bu değişiklikleri de uyguladım

sudo service resolvconf disable-updates
sudo update-rc.d resolvconf disable
sudo service resolvconf stop

Konuyla ilgili bu blog yayınına çok teşekkürler: https://ohthehugemanatee.org/blog/2018/01/25/my-war-on-systemd-resolved/

Bu işleri dua edelim .. Bu tüm systemd-çözmek iş çok çirkin.


Geç comment ama systemd-networkdilgili başka bir şey olmadığını kontrol etmek olurdu eth0ya enXcihaz vardır *.network`/ lib / systemd / ağda / dosyayı` bakın info systemd-networkdve info systemd.networkveinfo resolved.conf
jmunsch

5

Benim tahminim, systemd-resolvedhizmetinizin doğru yapılandırılmış olması, ancak hiçbir zaman isteği görmemesi. Etki .localalanı mDNS çalıştıran sistemler tarafından özel olarak ele alınır . avahi-daemonmDNS / DNS-SD hizmetleri (Apple ürünlerinde "Bonjour" olarak da bilinir) sağlayan, ad çözümlemesi sırasında DNS'den öncelikli olacak şekilde yapılandırılabilir; Ubuntu bunu yapıyor gibi görünüyor.

Aralarından seçim yapabileceğiniz birkaç seçenek vardır:

  1. .localAlan adınızı farklı (muhtemelen .internalveya .lan) bir adla yeniden adlandırın . Bu pratik yapmak için en kolay olabilir, çünkü DNS sunucunuzdaki birkaç şeyi değiştirmeniz yeterlidir ve Avahi ile en iyi şekilde çalışır. Bu yöntemi tavsiye ederim.

  2. Senin Alter /etc/nsswitch.confdosyasını koyarak dnsönünde girişini mdnsgirdileri.

  3. .localDüzenleme /etc/avahi/avahi-daemon.confve değiştirme (veya ekleme) ile domain-name=.something( [server]bölümde bulunur) mDNS etki alanını başka bir şeye değiştirmek için yapılandırmayı değiştirin . Bunu, birlikte çalışabilmeleri için mDNS kullanan her bilgisayarda yapmanız gerekir.


Burada gerçek alan adını gizlediğimi söylediğim için üzgünüm. Bu bir .local alan adı değildir. Üst etki alanı aslında .se. Bununla birlikte, ipucunu takip edeceğim ve nsswitch'in içeriğini kontrol edeceğim. Herhangi bir karışıklık için özür dilerim
Civing

0

Bu bir yorum olarak daha iyi, ama yeterli itibar değil gibi görünüyor ....

Civing'in kendi kendine cevabı en çok istediğim şeydi.

Ben de eklemek zorunda dns=noneiçin [main]bölümüne /etc/NetworkManager/NetworkManager.confşu şekilde görünür, böylece:

[main]
plugins=ifupdown,keyfile
dns=none

14.04'ten xubuntu 18.04'e güncelledim ve ondan daha eski bir LAN var, yıllar boyunca birçok küçük ayar yapıldı. Bu yüzden DNS'imin istediğimi yapmasını istiyorum (evet, ikinci baskıdan başlayarak yıllar boyunca Cricket Lius'un kitabının birçok kopyasını satın aldım).

Bir yana, daha önce dosyayı görmek istediğim DNS çözümleme bilgisini ekliyordum /etc/resolvconf/resolv.conf.d/head.

Özetle, bir kez kök olarak çalışan bir /etc/resolv.conf vardı:

cat /etc/resolv.conf >> /etc/resolvconf/resolv.conf.d/head

Ama şimdi, sadece /etc/resolv.conf dosyasını doğrudan düzenliyorum ve koyuluyor. Systemd / resolvconf kullanan LAN'ımın ziyaretçileri SOOL. Onlar yok.

Okuma man 8 resolvconfyardımcı oldu. Çok. Ben yaptım değil ifup programı onları bulabiliriz nesneleri koymak için yönergeleri izleyin. Çoğunlukla GUI'de yükseltme sırasında yapılanlar tarafından zaten göz ardı edilen bir üst yapı olduğu için. Bu daha büyük bir sorun gibi görünüyor (WTF, Ubuntu?).

Yani bu çirkin ve ağ kontrol paneli GUI'sine (uzun zaman önce) girmiş olduğum şeyin yeni yükseltilen sistem tarafından uyulmadığı sorunu hala var, ama bu nasıl farklı bir soru olduğunu anladığımda onu sor.


0

Benim için, yakın zamanda kurulmuş bir 18.04 çalıştırarak, @Civing tarafından belirtilen ilk değişikliği yaptım:

[ifupdown]
managed=true

daha sonra, /etc/resolv.conf dosyasının her zaman stub-resolv.conf'u işaret ettiğini ve uygun LAN DNS sunucusuyla makul bir resolv.conf oluşturulduğunu fark ederek, sembolik bağlantıyı değiştirdi:

/etc/resolv.conf -> /run/systemd/resolve/resolv.conf

ve sonra yerel tüm ana bilgisayar adları ping yoluyla çözüldü.

Bunun ne kadar süre çalışmaya devam edeceği görülmeye devam ediyor.

Başlangıçta yüklediğimde, kablosuz ağ kurulumu başarısız oldu ve kurulumun /etc/resolv.conf dosyasının bu başlangıç ​​durumunda bırakılıp bırakılmadığını merak edemiyorum.

Dolayısıyla bir öneri, neyin çözüldüğüne bakmakta; zaten çalışma temeliniz olabilir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.