10
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.
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.
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
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.
Das 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.
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3414860484
Url: https://administrator.de/contentid/3414860484
Ausgedruckt am: 18.11.2024 um 17:11 Uhr
10 Kommentare
Neuester Kommentar
Hallo Uwe,
ich kann das für ein RB5009 (ROS 7.4) bestätigen.
DNS direkt auf dem Mikrotik:
DNS auf PiHole (hinter dem Mikrotik):
Deine Vermutung bestätigt auch der Cache:
DNS-Cache nach erster Anfrage:
DNS-Cache nach zweiter Anfrage nach 7 Minuten:
Vielleicht ist's ein Spar-Feature...
Viele Grüße, commodity
ich kann das für ein RB5009 (ROS 7.4) bestätigen.
DNS direkt auf dem Mikrotik:
DNS auf PiHole (hinter dem Mikrotik):
Deine Vermutung bestätigt auch der Cache:
DNS-Cache nach erster Anfrage:
Vielleicht ist's ein Spar-Feature...
Viele Grüße, commodity
2
Hi @commodity .
Vielen Dank für das Nachstellen 👍. Werde ich dann doch mal ein Ticket aufmachen.
Grüße Uwe
Vielen Dank für das Nachstellen 👍. Werde ich dann doch mal ein Ticket aufmachen.
Grüße Uwe
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
Also mal ein Ticket aufmachen und denen Bescheid geben das sie doch die niedrigste TTL für so ein zurückgeliefertes RRSET einsetzen sollten.
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.
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.
1Resource 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
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.
3
Bei der latest Stable 7.4 sieht es scheinbar etwas differenzierter aus:
Abfrage via Mikrotik (RB2011) Caching DNS:
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
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.
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.
1Auftreten 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!!
1
- Zwischenmeldung -
Positive Rückmeldung vom Support 👍
Melde mich hier wieder sobald es eine Beta/Release mit einem Patch für das Problem gibt.
Grüße Uwe
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.Grüße Uwe
1
+1 - und wieder die Welt ein Stückchen verbessert 
Viele Grüße, commodity
Viele Grüße, commodity
