colinardo
Goto Top

Mikrotik RB4011 (RouterOS 6 und 7) - DNS Proxy Problem bei der Abfrage von TXT Records

Servus Kollegen.

Mir ist gerade beim Entwickeln eines SPF-Tools ein DNS-Problem mit einem Mikrotik Router (RB4011) auf die Füße gefallen.
Ich habe das Problem auch schon direkt im Mikrotik Forum eingestellt:

Mikrotik RouterOS 6.49.6 strange issue when requesting TXT records from integrated DNS proxy

Es geht um die Abfrage von TXT Records direkt vom DNS-Proxy des Mikrotik.

back-to-topDas Problem:


So lange man TXT Records einer Domain abfragt die noch nicht im Cache des Mikrotik liegen ist alles OK, es werden alle Records vollständig zurückgegeben.
Sind diese Einträge nun ein paar Minuten im Cache und man fragt erneut die selbe Domain und deren TXT Records ab sind diese unvollständig, es fehlen also diverse Einträge!

Um das nachzustellen habe ich anschließend direkt die Cloudflare Server angefragt um zu zeigen das hier bei der Anfrage vom Mikrotik Einträge fehlen.
Als DNS Forwarder ist im Mikrotik ebenfalls der Cloudflare Server eingetragen.

screenshot

Für mich sieht das irgendwie danach aus als würde der Mikrotik die beiden Einträge mit der 24h TTL (86400s) als Ablauf für den Cache es ganzen RRSETs heranziehen und dabei die Einträge mit den 5 Minuten (300s) nach 5 Minuten ablaufen lassen aber den Cache dann bei einer erneuten Abfrage nicht wieder aktualisieren.

Könnte sein das das auch andere Recordtypen betrifft. Habe ich aber noch nicht getestet. Muss mich jetzt gerade etwas anderem widmen.

Falls das mal jemand nachstellen möchte, wäre ich dankbar über eure Rückmeldungen.

Grüße Uwe

Content-Key: 3414860484

Url: https://administrator.de/contentid/3414860484

Ausgedruckt am: 28.03.2024 um 12:03 Uhr

Mitglied: commodity
Lösung commodity 22.07.2022 aktualisiert um 20:31:27 Uhr
Goto Top
Hallo Uwe,

ich kann das für ein RB5009 (ROS 7.4) bestätigen.

DNS direkt auf dem Mikrotik:
screenshot 2022-07-22 201546

DNS auf PiHole (hinter dem Mikrotik):
screenshot 2022-07-22 202420

Deine Vermutung bestätigt auch der Cache:
DNS-Cache nach erster Anfrage:
screenshot 2022-07-22 201350
DNS-Cache nach zweiter Anfrage nach 7 Minuten:
screenshot 2022-07-22 201604

Vielleicht ist's ein Spar-Feature...

Viele Grüße, commodity
Mitglied: colinardo
colinardo 22.07.2022 aktualisiert um 23:10:12 Uhr
Goto Top
Hi @commodity .
Vielen Dank für das Nachstellen 👍. Werde ich dann doch mal ein Ticket aufmachen.

Grüße Uwe
Mitglied: colinardo
Lösung colinardo 22.07.2022 aktualisiert um 22:45:08 Uhr
Goto Top
OK das mit den unterschiedlichen TTLs für ein RRSET sollte es eigentlich nicht mehr geben obwohl technisch möglich.
Die RFC sagt dazu folgendes

5.2. TTLs of RRs in an RRSet

Resource Records also have a time to live (TTL). It is possible for the RRs in an RRSet to have different TTLs. No uses for this have been found that cannot be better accomplished in other ways. This can, however, cause partial replies (not marked "truncated") from a caching server, where the TTLs for some but not all the RRs in the RRSet have expired.

Consequently the use of differing TTLs in an RRSet is hereby deprecated, the TTLs of all RRs in an RRSet must be the same.

Should a client receive a response containing RRs from an RRSet with differing TTLs, it should treat this as an error. If the RRSet concerned is from a non-authoritative source for this data, the client should simply ignore the RRSet, and if the values were required, seek to acquire them from an authoritative source. Clients that are configured to send all queries to one, or more, particular servers should treat those servers as authoritative for this purpose.
Should an authoritative source send such a malformed RRSet, the client should treat the RRs for all purposes as if all TTLs in the RRSet had been set to the value of the lowest TTL in the RRSet. In no case may a server send an RRSet with TTLs not all equal.

Also mal ein Ticket aufmachen und denen Bescheid geben das sie doch die niedrigste TTL für so ein zurückgeliefertes RRSET einsetzen sollten.
Mitglied: commodity
commodity 22.07.2022 um 23:00:23 Uhr
Goto Top
Resource Records also have a time to live (TTL).
Interessant. Und mit Deinem Ansatz auch leicht lösbar. Obgleich der "Fehler" hier ja wohl bei GMX liegt. Aber damit muss ein Router natürlich klar kommen... Schafft der PiHole ja offenbar auch.

Viele Grüße, commodity
Mitglied: colinardo
colinardo 22.07.2022 aktualisiert um 23:19:25 Uhr
Goto Top
Jepp, als Fallback auf jedenfall wünschenswert, denn fehlende Records sind gar nicht schön. Anfrage ist auf dem Weg, jetzt heißt es abwarten und Tee trinken.
Mitglied: aqui
aqui 23.07.2022 aktualisiert um 18:29:38 Uhr
Goto Top
Bei der latest Stable 7.4 sieht es scheinbar etwas differenzierter aus:

Abfrage via Mikrotik (RB2011) Caching DNS:
root@notebook:/home/user# dig TXT gmx.net @10.99.1.254

; <<>> DiG 9.16.1-Ubuntu <<>> TXT gmx.net @10.99.1.254
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49524
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gmx.net.			IN	TXT

;; ANSWER SECTION:
gmx.net.		151	IN	TXT	"google-site-verification=J0NZ2F6kdhXzsguHSKZTm3CWujnrImftkDG3zhz14g0"  
gmx.net.		151	IN	TXT	"v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:74.208.4.192/26 ip4:82.165.159.0/24 ip4:217.72.207.0/27 ip4:82.165.229.31 ip4:82.165.230.21 -all"  
gmx.net.		151	IN	TXT	"Trustpilot-Verification-kqvVskCm6JQ9Vg1qAmahpBSJ5tvZORbriFyVIk4E"  
gmx.net.		151	IN	TXT	"facebook-domain-verification=scdn4fwr0on3j97l5py9vp9raerciu"  
gmx.net.		86251	IN	TXT	"179gjz475x3lvxbtsv2mn24vc1l1q9tb"  
gmx.net.		86251	IN	TXT	"vxxrjnnhhz1vd8r51zps6swntc43k2j1"  

;; Query time: 0 msec
;; SERVER: 10.99.1.254#53(10.99.1.254)
;; WHEN: Sa Jul 23 12:34:49 CEST 2022
;; MSG SIZE  rcvd: 567 
Mitglied: colinardo
colinardo 23.07.2022 aktualisiert um 15:04:32 Uhr
Goto Top
Zitat von @aqui:

Bei der latest Stable 7.4 sieht es scheinbar etwas differenzierter aus:
Hast du nach der ersten Anfrage an den MK auch mindestens 5 Minuten gewartet und dann erst erneut abgefragt? Auftreten wird das nämlich erst wenn die Records mit den 300 Sekunden im Cache des MK abgelaufen sind. In deinem Bild waren ja noch 150 Sekunden auf den TTLs, du musst also noch länger warten.
Hier im Test mit der 7.4 in einer VM tritt es nämlich genau so auf wie bei der 6.49.6.

Was ich gerade beobachten konnte war im Cache-Fenster des Mikrotik in der Winbox. Kurz vor dem Ablauf der RR mit den 300s TTL, ging der Zähler auf 00:00:00, und sprang dann ein paar mal wieder auf 00:00:02, oder 00:00:01 hoch, bevor sie dann ganz aus dem Cache verschwanden. Das Verhalten ist aber definitiv nicht RFC konform und sie sollten bei solche einem Szenario die niedrigste TTL für alle zurückgelieferten RRs anwenden damit das wieder zuverlässig arbeitet. Unbound, bind & Co. machen es ja auch korrekt.

Warten wir die Reaktion von MK ab. Ich melde mich dann hier nochmal sobald ich Rückmeldung für das SUP-Ticket erhalte.
Mitglied: aqui
aqui 23.07.2022 aktualisiert um 18:25:24 Uhr
Goto Top
Auftreten wird das nämlich erst wenn die Records mit den 300 Sekunden im Cache des MK abgelaufen sind
Aha... OK das hab ich nicht gemacht...sorry. Wird nachgeholt.
Und jepp...damit ist es auch unter 7.4 reproduzierbar!!
dig1
7 Minuten später...
dig2
Mitglied: colinardo
colinardo 27.07.2022, aktualisiert am 10.09.2022 um 11:13:13 Uhr
Goto Top
- Zwischenmeldung -
Positive Rückmeldung vom Support 👍
Hello,

Thank you for your report. 
I managed to reproduce such behavior and we are looking forward to fixing it in the further RouterOS releases.

Best regards,
Artūrs C.
Melde mich hier wieder sobald es eine Beta/Release mit einem Patch für das Problem gibt.

Grüße Uwe
Mitglied: commodity
commodity 27.07.2022 um 18:13:11 Uhr
Goto Top
+1 - und wieder die Welt ein Stückchen verbessert face-wink

Viele Grüße, commodity