DNS Wildcards nutzen in Firewall - leichte Verwirrung

[backslash]

Hi firefox_i,

es gibt natürlich auch noch die Möglichkeit, daß mehrere Domains auf die gleiche IP auflösen und der Client gar nicht die strato-Domain anfragt, sondern eine andere, die auf die gleiche IP aufgelöst wird...

Gruß
Backslash

[firefox_i]

Ich hab jetzt für den SYSLOG Server mal die Filter anders gesetzt.

Also so leid es mir tut.....
für mich sehen die bisherigen Logs so aus:

- der Client (die QNAP) hat einen Job der alle 15 Minuten läuft
- alle 15 Minuten erfolgt die DNS Auflösung für api.hidrive.strato.com mit der korrekten IP

- um 00:05 startet ein SYNC Job, der ebenfalls auf STRATO Hidrive erfolgt
- um 00:05:58 blockt die Firewall die IP Adresse die um 00:00:01 per DNS zu api.hidrive.strato.com aufgelöst wurde
- wenige ms später erfolgt eine DNS Anfrage des Clients (QNAP) auf api.hidrive.strato.com, die IP ist noch dieselbe und alles ist schick.....



Also für mich sieht das doch so aus, als ob irgendjemand was vergisst....


Von einem Windows Rechner aus scheint die TTL 600 Sekunden zu sein:

Code: Alles auswählen

nslookup -type=ns api.hidrive.strato.com 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

strato.com
        primary name server = ns-strato.ui-dns.de
        responsible mail addr = dnsadmin.ionos.com
        serial  = 2026070893
        refresh = 3600 (1 hour)
        retry   = 7200 (2 hours)
        expire  = 604800 (7 days)
        default TTL = 600 (10 mins)

Wenn ich per SSH auf den Client gehe kommr kurz nach Ablauf der TTL:

Code: Alles auswählen

dig api.hidrive.strato.com

; <<>> DiG 9.10.1-P2 <<>> api.hidrive.strato.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16325
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;api.hidrive.strato.com.                IN      A

;; ANSWER SECTION:
api.hidrive.strato.com. 500     IN      A       85.214.3.77

;; Query time: 6 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Thu Aug 13 20:00:54 CEST 2026
;; MSG SIZE  rcvd: 67

Sieht nach 500 Sekunden TTL aus

Spannend, dass da die TTL sich ändert.....

S.

[firefox_i]

Nachtrag:
Klar....kaum filtere ich die Logs anders, kommt dieses Problem nimmer.....

Ich hab aber auch die Prüfung der SMART Werte in der NAS mal nch den "Problemzeitpunkt" verschoben.....
Ich stells mal zurück und schau heute Nacht nochmal.


Was mir aufgefallen ist:
Heute nNacht war es eine andere IP die geblockt wurde.
Die gehört zu einer QNAP Domöne.

Spannend: Ich sehe im SYSLOG die Namensauflösung:

Code: Alles auswählen

<157>1 2026-08-13T23:15:03.016536+02:00 XXXX PACKET_INFO - - - PACKET_INFO: DNS for QNAP_IP {YY}, TID: 0x0edf: connector.myqnapcloud.com STD CNAME resolved to qcloud-pr-backend-390510218.us-east-1.elb.amazonaws.com
<157>1 2026-08-13T23:15:03.016536+02:00 XXXX PACKET_INFO - - - PACKET_INFO: DNS for QNAP_IP {YY}, TID: 0x0edf: qcloud-pr-backend-390510218.us-east-1.elb.amazonaws.com STD A resolved to 32.195.127.255

Und dann:

Code: Alles auswählen

<153>1 2026-08-14T00:05:58.444275+02:00 XXXX PACKET_ALERT - - - PACKET_ALERT: Dst: 50.17.100.128:443, Src: QNAP_IP:40046 {YY} (TCP): port filter

Die TTL die der DNS zurückgibt sind 60 Sekunden (!)

Dass dann bei einem Zugriff knapp 50 Minuten danach die FW sagt "nöööö" ist mir einleuchtend...

Doch ne Wechselwirkung zwischen der DNS TTL (nach der die FW die Erlaubnis meines Erachtens nach entzieht, weil abgelaufen) und einem Fehlverhalten der QNAP, die trotz abgelaufener TTL weiter munter die IP verwendet?

S.

[backslash]

Hi firefox_i,

Spannend: Ich sehe im SYSLOG die Namensauflösung: (...)

irgendwie passen die Namensauflösung und das das Block der Firewall nicht zusammen - das sind unterschiedliche Adressen...
Aber die gehören beide zu amazon:

Code: Alles auswählen

PS C:\> ping -a 50.17.100.128

Ping wird ausgeführt für ec2-50-17-100-128.compute-1.amazonaws.com [50.17.100.128] mit 32 Bytes Daten:
STRG-C
PS C:\> ping -a 32.195.127.255

Ping wird ausgeführt für ec2-32-195-127-255.compute-1.amazonaws.com [32.195.127.255] mit 32 Bytes Daten:
STRG-C

interessant ist:

Code: Alles auswählen

PS C:\> ping connector.myqnapcloud.com

Ping wird ausgeführt für qcloud-pr-backend-390510218.us-east-1.elb.amazonaws.com [50.17.100.128] mit 32 Bytes Daten:
STRG-C
PS C:\> ping connector.myqnapcloud.com

Ping wird ausgeführt für qcloud-pr-backend-390510218.us-east-1.elb.amazonaws.com [18.209.86.1] mit 32 Bytes Daten:
STRG-C

Da ist ein Loadbalancer hinter der Domain und der Client bekommt regelmässig neue Adressen - die er aber scheinbar nicht immer richtig nutzt...

Doch ne Wechselwirkung zwischen der DNS TTL (nach der die FW die Erlaubnis meines Erachtens nach entzieht, weil abgelaufen) und einem Fehlverhalten der QNAP, die trotz abgelaufener TTL weiter munter die IP verwendet?

es wird wahrscheinlicher...

Gruß
Backslash

[firefox_i]

Hi,
ja dass da ein CDN dahnter hängt ist klar.

Sorry ich hab die falsche Zeile aus den log kopiert...da wurde definitiv die IP aufgelöst und zurückgegeben, die später dann geblockt wurde.

Ist in der Sache ja auch aus Sicht des LC erstmal richitg, denn nach +über 30 Minuten ist eine IP deren TTL nunmal nur 60 Sekunden beträgt nimmer valide und darf - oder muss sogar -geblockt werden.

Wie gesagt: mir drängt sich da immer mehr der Verdacht auf, dass der Client da Quatsch macht.....

Bin gespannt wann das mit der Strato Domäne wieder passiert....

Und vor allem: ob sich WIN2022 Server da korrekter verhalten, denn das ist alles ein Testlauf, um WIN2022 Server nur auf bestimmte Domänen zugreifen zu lassen (ein DC braucht nunmal NTP bzw. ein Managementsever für den Virenscanner zugang zu den Signaturen...)

[backslash]

Hi firefox_i,

du könntest die DNS-Minimum-Cache-Time auf z.B. eine Stunde einstellen...

Gruß
Backslash

[firefox_i]

Naja, das deckt zwar den Effekt zu, aber manipuliere ungern TTls.

Von daher...ich hab ja primär erstmal kein Thema, denn wenn die FW blockt, kommt direkt danach eine DNS Anfrage und dann läufts ja wieder....mit den 2 Einträgen im SYSLOG kann ich leben....ging mir da ehe rnur um die Ursachenforschung