Systemd-resolved ignoruje DNS běžící na routeru

kamen

Systemd-resolved ignoruje DNS běžící na routeru
« kdy: 27. 10. 2018, 11:07:09 »
Proc SystemD-resolved ignoruje DNS cache bezici na routeru?

Ve sve domaci siti mam na routeru napojenem na Internet DNS split horizon (ruzne DNS response podle toho z jake site se hlasite).

Az do Ubuntu 16.04 LTS vse fungovalo jak by bezny negr ocekaval. Dnsmasq bezici na Network-manager managed klientech pouzil routerem nabizeny DNS server a vsichni byli stastni.

Po upgrade na Ubuntu 18.04 vse vypadatlo vicemene funkcne az na dulezity detail. Nejaky Systemd-resolved na portu localhost:53 (asi nahrada stareho dobreho Dnsmasq), uplne ignoruje DNS nastaveni prijate v DHCP odpovedi.

Prozatim jsem to poresil editaci /etc/resolv.conf a fixnim nastavenim serveru. Ale proc proboha ten novy proces uplne ignoruje zavedena pravidla?!

Napada vas nekoho jak to opravit, tak aby vse fungovalo jak ma?

[odpovedi zrusit DNS horizon nejsou resenim protoze nenaplnuji muj zakaznicky pozadavek]



« Poslední změna: 28. 10. 2018, 23:00:15 od Petr Krčmář »


Sten

systemd-resolved se chová správně, pokud používá jen resolv.conf. Jestli DNSMasq používal něco jiného, choval se nestandardně a musel jste to tak mít nastavené. Řešení je doinstalovat resolvconf, který aktualizuje resolv.conf z DHCP.

Lol Phirae

Ignoruj zcestné odpovědi Lennartova fanklubu a tu sračku vypni.

Kód: [Vybrat]
sudo systemctl mask systemd-resolved

kamen

pokud používá jen resolv.conf.

Vy mi asi nerozumite. Ten proces uplne ignoruje to co mu DHCP odpoved posle jako nejblizsi/preferovany DNS server pro danou sit.
Zkusil bych to nejak zadebugovat, ale neni zrejme, kde tento proces loguje. V /var/log/syslog nic neni a neni zrejme jak ho prepnout do 'verbose' rezimu.

Rekneme ze lokalni sit je 192.168.123.0/24 a DNS pro tu sit je 192.168.123.1. Na te lokalni siti je pocitac co ma jmeno SuperCooolServer.

Ten proces pak uplne ignoruje dotazovani na ten 192.168.123.1  (vypozorovano z logu toho routeru, ze tam zadny takovy dotaz nedojde).

Kdyz dam 'host SuperCooolServer' tak to vrati servfail (coz muze byt cokoliv). Ale s jistotou je to odpoved od toho procesu co nasloucha na localhost:53 (tedy Systemd-resolved), protoze dnsmasq na routeru by napraskal jakoukoliv aktivitu (pro ladeni jsem si zapnul max. verbosity).

Me jde vlastne jen o to, jak spravne ten proces nastavit, protoze je mi jasne, ze pokud chci Ubuntu 18.04 tak mi proste nic jineho nezbyva nez strpet tento novej proces. Kdyby byla lepsi distribuce s KDE Neon co to nema, tak bych klidne zvazil s klientama prejit jinam. Jen to Ubuntu LTS je takova jakasi jistota (prosim zadny flame, je to proste ma preference).




kamen

Ignoruj zcestné odpovědi Lennartova fanklubu a tu sračku vypni.

Kód: [Vybrat]
sudo systemctl mask systemd-resolved

To zni dobre, nebude to mit vliv na jinou funkcionalitu? Myslim tim, ze jedine co po lokalni DNNS cache na localhost:53 chci je DNS preklad. Ciste pragrmaticky: Neni mozne ze ten SystemD-resolved ma jeste nejakou dalsi funkcionalitu, pro kterou by se mi neco jineho pokazilo? (treba zavislost nejake desktop funkce na prezentic toho procesu?)


Co jste v konfiguraci toho Ubuntu měnil? Normálně totiž systemd-resolved DNS servery dodané přes DHCP používá. Nevypnul jste si náhodou v konfiguraci systemd-network v sekci [DHCP] volbu UseDNS?

Lol Phirae

To zni dobre, nebude to mit vliv na jinou funkcionalitu? Myslim tim, ze jedine co po lokalni DNNS cache na localhost:53 chci je DNS preklad.

Ne, na funkci rostlináře to nemá vliv.  ;D Ten Lennartův paskvil dělá totéž, co např. onen dnsmasq + NM (tzn. lokální kešující stub resolver), zato - jak je u Lennartwaru zvykem - neskonale hůře a s tou "výhodou", že konfigurace probíhá naprosto zcestně na X různých místech, z čehož ve výsledku vyleze nefungující paskvil.

kamen

Co jste v konfiguraci toho Ubuntu měnil? Normálně totiž systemd-resolved DNS servery dodané přes DHCP používá. Nevypnul jste si náhodou v konfiguraci systemd-network v sekci [DHCP] volbu UseDNS?

Zasadne nemenim nic co je deafault. Takze na klientech nic. Protoze zatim mi vse fungovalo. I na tom Ubuntu 16.04 jsem mel vse default.

Jedine co je v otm prostredi jinak nez by bezny negr mel, je ten DNS split horizon. Proste mam na lokalni siti servery, ktere maji z venku jinou IP nez na vnitrni siti. Toto je proste zakaznicky pozadavek, zcela v souladu s internetovymi protokoly.

Lze treba pouzit reseni DNS resolveru (resp. lokalni DNS cache) z toho Ubuntu 16.04? (aniz bych prisel o nejakou speficickou funkci, ktera je predpokladana novym 18.04 LTS)

Osobne nechapu duvod proc se to muselo zmenit. V od zacatku co jsem na Ubuntu to az po tu 16.04 fungovlo bajcne, aniz bych o nejakem DNS musel vedet (vcetne bonjour/avahi a vsemoznych service discoveries).




Důvody, proč se to měnilo, jsou např. ve zdejší zprávičce Ubuntu 16.10 bude mít systemd-resolved jako lokální DNS.

Než se pokoušet ohnout systém tak, abyste tam používal stejné programy, jako v 16.04, bylo by lepší zjistit, co máte špatně a to opravit. Protože je také dost možné, že tam pracně zprovozníte dnsmasq, a zjistíte, že se to chová úplně stejně, protože chyba byla někde úplně jinde.

Tu volbu UseDNS tedy máte zapnutou (a nebo je ponechána výchozí hodnota, která je také zapnuto)? V logu něco zajímavého není? Když zkusíte lokálně DHCP klienta, dostane od DHCP serveru správnou odpověď, včetně DNS serveru? Konfigurační soubory systemd-resolv a systemd-network sem dát můžete?

Lol Phirae

Důvody, proč se to měnilo, jsou např. ve zdejší zprávičce Ubuntu 16.10 bude mít systemd-resolved jako lokální DNS.

Ano, tam žádný validní důvod není (viz můj komentář pod odkazovaným blábolem).

kamen

Tu volbu UseDNS tedy máte zapnutou
..
V logu něco zajímavého není?
..
Když zkusíte lokálně DHCP klienta,
..
dostane od DHCP serveru správnou odpověď, včetně DNS serveru?

Nic jsem nemenil. Uz jsem to psal vyse. Vse je default. Vlastne ani nevim kde bych to mel menit.

Soubor "systemd-resolv" jsem nikde nenasel, ale zkusil jsem najit nejblizsi shodu a odhaduji ze jste asi myslel "/etc/systemd/resolved.conf"

Kód: [Vybrat]
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details

[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes

A to stejne pro "systemd-network" jsem vyhodnotil jako "/etc/systemd/systemd-network.conf".
Kód: [Vybrat]
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See systemd-system.conf(5) for details.

[Manager]
#LogLevel=info
#LogTarget=journal-or-kmsg
#LogColor=yes
#LogLocation=no
#DumpCore=yes
#ShowStatus=yes
#CrashChangeVT=no
#CrashShell=no
#CrashReboot=no
#CtrlAltDelBurstAction=reboot-force
#CPUAffinity=1 2
#JoinControllers=cpu,cpuacct net_cls,net_prio
#RuntimeWatchdogSec=0
#ShutdownWatchdogSec=10min
#CapabilityBoundingSet=
#SystemCallArchitectures=
#TimerSlackNSec=
#DefaultTimerAccuracySec=1min
#DefaultStandardOutput=journal
#DefaultStandardError=inherit
#DefaultTimeoutStartSec=90s
#DefaultTimeoutStopSec=90s
#DefaultRestartSec=100ms
#DefaultStartLimitIntervalSec=10s
#DefaultStartLimitBurst=5
#DefaultEnvironment=
#DefaultCPUAccounting=no
#DefaultIOAccounting=no
#DefaultIPAccounting=no
#DefaultBlockIOAccounting=no
#DefaultMemoryAccounting=no
#DefaultTasksAccounting=yes
#DefaultTasksMax=
#DefaultLimitCPU=
#DefaultLimitFSIZE=
#DefaultLimitDATA=
#DefaultLimitSTACK=
#DefaultLimitCORE=
#DefaultLimitRSS=
#DefaultLimitNOFILE=
#DefaultLimitAS=
#DefaultLimitNPROC=
#DefaultLimitMEMLOCK=
#DefaultLimitLOCKS=
#DefaultLimitSIGPENDING=
#DefaultLimitMSGQUEUE=
#DefaultLimitNICE=
#DefaultLimitRTPRIO=
#DefaultLimitRTTIME=
#IPAddressAllow=
#IPAddressDeny=

Dhclient jsemu musel zabit a kdyz jsem ho pak spustil 'dhclient wlp2s0 -v' tak jsem dostal nasledujici odpoved (mac jsem zmenil):
Kód: [Vybrat]
Listening on LPF/wlp2s0/ab:cd:ef:01:23:45
Sending on   LPF/wlp2s0/ab:cd:ef:01:23:45
Sending on   Socket/fallback
DHCPREQUEST of 192.168.123.201 on wlp2s0 to 255.255.255.255 port 67 (xid=0x100bfd07)
DHCPACK of 192.168.123.201 from 192.168.123.1
bound to 192.168.123.201 -- renewal in 19489 seconds.


I kdyz ten DNS tu neni videt, starsi klienti co prekladaji pres DNS z toho routeru s prekladem nemaji problem. Vlastne vsechny domaci klienti na ruznych platformach (iPhone, Samsung Android, Windows 10, Ubuntu 16.04, Ubuntu 14.04, Windows 7 a Windows 8.1) s tim nemaji jediny problem. Jen to nove Ubuntu 18.04.

kamen

Důvody, proč se to měnilo, jsou např. ve zdejší zprávičce Ubuntu 16.10 bude mít systemd-resolved jako lokální DNS.

Je to vzhledem k memu nefunkcnimu Ubuntu 18.04 diky novemu SystemD-resolved off topic, ale uplne nechapu ty duvody. Neberte si to prosim osobne, pokud mate k systemd nejake preference (me osobne je jedno, pokud nebude veci kazit) - naplni-li existujici pozadavky, neprinese-li nove zavislosti a bude mit stejne nebo lepsi kvalitativni a kvantitativni parametry, s chuti ho budu pouzivat.

Cituji z odkazovane zpravicky a opravdu nevidim duvod proc zavadet neco noveho:

Citace
Nevýhodou je záznam v /etc/resolv.conf  jen nameserver 127.0.0.1, z čehož se nedá usoudit, jaké servery se používají.

Nyni mam v /etc/resolv.conf take 127.0.0.1. Tak nevim, nevidim zmenu.

Citace
Na serveru Ubuntu nepoužívá žádný lokální DNS, záznamy z /etc/resolv.conf  jsou přímo používány programy přes glibc. To má nevýhodu prodlev, pokud je první server pomalý.

Toto preci resi Dnsmasq. Staci "apt install dnsmaq" na serveru; a nebo lepe se zamyslet nad architekturou  a poskytnout serveru lokalni rychlou DNS cache.

Citace
V novém Ubuntu 16.10 bude na všech variantách nasazen systemd-resolved, který je malý,

Dnsmasq mi bezi ve vsech routerech s LEDE, dokonce i na tech ultra levnych. Je ultramaly.

Citace
podporuje DNSSEC (od verze 230),

Dnsmasq v Ubuntu 16.04 umel DNSSEC (vlastne uz nekdy od Ubuntu 14.10 Dnsmasq 2.69 to umel).

Citace
nezávisí na D-Bus jako dnsmasq

Dnsmasq lze uspesne provozovat bez DBUS, ale krome routerovych distribuci jako je LEDE/OpenWRT atp. nechapu proc by to melo vadit. Dbus je nahodou prakticka vec.

Jak vidite vyse, neni tam zadny platny argument nebo tvrzeni podporujici vasi argumentaci.




Co vypíše následující příkaz?

Kód: [Vybrat]
cat /var/lib/NetworkManager/dhclient-*.lease

V tom souboru by měly být poslední údaje získané DHCP klientem z netplanu. Případně co vypíše příkaz

Kód: [Vybrat]
netplan ip leases

Asi bude nutné jako poslední parametr přidat jméno síťového rozhraní.

Lol Phirae

Jojo, není nad to jednoduchou funkční konfiguraci znefunkčnít a namísto toho implementovat další Lennartovinu rozšířenou o monstrózní shit typu Netplan s konfigurací v YAMLu.

ByCzech

  • *****
  • 1 848
    • Zobrazit profil
    • E-mail
Mě vždycky fascinuje, že když se vyskytne problém související se SystemD, který před SystemD neexistoval, tak jeho obhajci začnou radit jak je špatné cokoli jiného okolo a že je třeba to "opravit" tam, jakoby pracovali s nějakým podivným axiomem "SystemD a jeho komponenty jsou dokonalé, chyby jsou ve všem okolo". A pokud se to okolo nepřizpůsobí, vymyslí se do SystemD nová komponenta, která tu nepřizpůsobivou věc má nahradit, bohužel to dělá tak, že rozbije hromadu dalších věcí.

Řešením je prostě tu komponentu jak radil Lol zakázat. Nikdo se o ni neprosil, takže pokud nevíte o tom, že by jste ji potřeboval, úplně normálně ji vypněte, s vysokou pravděpodobností budou věci fungovat zase normálně jako roky před tim.

SystemD není něco bez čeho se nedá žít, takže pokud zlobí,  nemám problém di věci zkonfigurovat bez něj.