Linux mint systemd-resolve cached CNAME maar geen A

[valkenier]

De titel is misschien wat vaag, maar ik heb het volgende op Linux mint 19.

ik draai een edgerouter-lite met daarop een paar static DNS host-names, die verwijzen naar het interne IP-adres van mijn server(s). De ER-lite is de DNS server/forwarder voor het LAN. Dus een nslookup krijgt antwoord van van de ER-lite. De bedoeling is dus dat bijvoorbeeld www.domein.nl intern verwijst naar 192.168.2.2 (mijn server). In de externe DNS records staat een CNAME voor www.domein.nl naar domein.dynu.com ivm een dynamisch extern IP-adres.

nu doe ik een nslookup www.domein.nl
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: www.domein.nl
Address: 192.168.2.2
www.domein.nl canonical name = domein.dynu.com.

Systemd-resolve krijgt dus van de ER-lite zowel het interne IP als het CNAME record (waarschijnlijk omdat er ook een IPv6 (AAAA) wordt opgevraagd? Ik heb echter geen IPv6 op mijn verbinding, dus dat is niet geconfigureerd, en dan wordt uitgeweken naar CNAME, vermoed ik)

doe ik direct daarna nog een 2e keer nslookup www.domein.nl dan krijg ik:
nslookup www.domein.nl
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
www.domein.nl canonical name = domein.dynu.com.
Name: domein.dynu.com
Address: 82.*.*.*

HUH? Dus blijkbaar wordt de eerste keer door systemd-resolve keurig de ER als dns geraadpleegd en komt hij terug met het interne IP en de CNAME. Dat belandt in de cache van systemd-resolve, en bij een 2e keer opvragen is het interne IP adres vergeten, en krijg ik alleen het CNAME record uit de cache, waar dan het externe IP bij wordt gezocht. En dat gaat niet lekker, omdat bepaalde poorten niet open staan naar het web en NAT-loopback daarvoor dus niet werkt.
Na enige tijd is www.domein.nl weer uit de cache verdwenen en ik krijg ik weer de oorspronkelijke respons.

Ik zou dit kunnen tackelen door een static DNS host op de router aan te maken die alleen intern wordt gebruikt, maar op de server draaien ook Let's encrypt certificaten, en die werken dan niet meer.

Lang verhaal, maar ik verbaas mij over het Cache gedrag van systemd-resolve wat wel het CNAME record vasthoudt, maar niet het A record. Dat geeft gedoe. Het lijkt op deze bug, maar die zou zijn gefixed.

Als iemand weet hoe ik systemd-resolve zover krijg mijn interne IP te cachen, zou dat geweldig zijn. Of is dit nog steeds een bug?
systemd version = 229-4ubuntu21.4


Edit:
Ik heb het met een workaround op de router weer een beetje aan de praat, maar vind het een beetje een hack.
1. Ik heb in de DNS hosts-wizard op de edgerouter een dummy.domein.nl aangemaakt wat niet in de externe DNS records bestaat en verwijst naar het interne IP. De overige verwijzingen heb ik hier verwijderd.
2. via de CLI van de edgerouter

code:

set service dns forwarding options cname=mail.domein.nl,dummy.domein.nl
commit
save

niet super fraai, maar zo blijft het tenminste werken. Ik had geen zin om op meerdere PCs in de hosts file te gaan klooien. Overigens is de genoemde bug wel gefixed, maar nog niet in de versie van systemd die meekomt met mint 19.

[Voor 12% gewijzigd door valkenier op 03-10-2018 18:41]

[foxgamer2019]

Heb heel veel problemen met systemd-resolved en ook met systemd-networkd overigens.

Vooral bij het eerste gaan DNS requests niet altijd goed of heel langzaam. Fijn overigens dat het is gefixed, heb je een link naar bug rapport?

[valkenier]

@foxgamer2019 Ik ben er nog wat mee aan het stoeien geweest, want het zat me toch niet lekker.

Kort samengevat had ik het volgende:
1. systemd-resolve doet standaard een lookup van IPv4 en IPv6 voor een record, prima anno 2018
2. mijn edgerouter had echter alleen IPv4 geconfigureerd voor de domeinen die ik intern wilde benaderen, en kopte daarom het IPv6 request door naar 1.1.1.1. Daar werd geen AAA record gevonden, want dat is niet geconfigureerd. Echter wel een CNAME record naar domein.dynu.com, en dat wordt vervolgens teruggeven als antwoord voor IPv6, dat schijnt by design te zijn.
3. systemd-resolve kreeg dus op zijn DNS-requestz owel een intern IP terug in A, maar ook een CNAME voor een extern IP, wat weer werd geresolved, naar mijn eterne IPv4. Dat hoort niet omdat je voor een domein niet tegelijkertijd een CNAME en A/AAAA record mag hebben.
4.In combinatie met denk ik genoemde bug wordt alleen het CNAME record onthouden.

Een samenloop van omstandigheden dus, waarbij de schuld misschien maar voor een deel bij systemd-resolve ligt, maar vooral in het feit dat van intern een IPv4 wordt teruggeven en vanuit extern via IPv6 een CNAME record. Waarbij systemd-resolve dan alleen het CNAME record vasthoud. Uiteindelijk heb ik mijn vorige workaround (vorige post) er weer uit gegooid, omdat ik nog steeds heel af en toe de externe CNAME terugkreeg. Ik heb nu middels de CLI in de edgerouter het zo opgelost:

code:

configure
set system static-host-mapping hostname mail inet 192.168.2.2
set system static-host-mapping hostname mail inet ::
set system static-host-mapping hostname mail alias mail.domein.nl
commit
save

In de GUI van de edgerouter wordt dit wel zichtbaar, maar daar kun je het nu niet meer editen, want daar mag je alleen IPv4 adressen invoeren Maar goed via de CLI lukt het prima..

link:
bugreport systemd https://github.com/systemd/systemd/issues/9833

[mithras]

Werkt deze oplossing ook voor jou? mDNS functioneert niet op LAN domainname

Dat lag bij mij ook aan systemd-resolve en de stub file.

[CyBeR]

valkenier schreef op donderdag 4 oktober 2018 @ 13:33:

4.In combinatie met denk ik genoemde bug wordt alleen het CNAME record onthouden.

Een samenloop van omstandigheden dus, waarbij de schuld misschien maar voor een deel bij systemd-resolve ligt, maar vooral in het feit dat van intern een IPv4 wordt teruggeven en vanuit extern via IPv6 een CNAME record. Waarbij systemd-resolve dan alleen het CNAME record vasthoud.

Dat is geen bug, dat is correct gedrag. CNAMEs en andere records mogen niet tegelijk bestaan, m.a.w de CNAME gaat altijd voor.

Als er ergens een bug is, is dat in de ER's resolver want die zou zowel de A als de AAAA query moeten afvangen bij een dergelijke instelling.

bugreport systemd https://github.com/systemd/systemd/issues/9833

Dat is een andere bug.

[Voor 6% gewijzigd door CyBeR op 10-10-2018 07:16]