Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Microsoft-Subdomain wird nicht aufgeloest
4 views
Skip to first unread message
Sebastian Suchanek
Nov 25, 2023, 5:25:39 PM11/25/23
to
Hallo zusammen,
das folgende Problem ist mir aufgefallen, als ich über meinen
Server eine Mail an loca...@domain.tld schicken wollte.
Domain.tld hat als eingetragenen MX
"domain-tld.mail.protection.outlook.com" - und diese (Sub)domain
kann der Bind, der ebenfalls auf der Kiste läuft, nicht
auflösen. Entsprechende Versuche enden reproduzierbar in einem
SERVFAIL. Bind hat die Version 9.11.5 aus einem Debian Buster,
ziemlich "out of the box", der als rekursiver Resolver angelegt
ist, also keine Forwarder eingetragen sind. Der Bind
funktioniert aber grundsätzlich, andere Domains werden
problemlos aufgelöst.
Auch wenn ich auf der gleichen Kiste nslookup dagegen z.B.
8.8.8.8 nach der o.g. Domain befragen lasse, erhalte ich
sinnvolle Antworten.
Was läuft da schief und wie kann ich es reparieren?
(Google war mir bislang auch nicht besonders hold - ich finde
zwar diverse Fundstellen von Fragestellern, die das gleiche
Problem haben, aber bislang keine wirkliche Lösungen...)
TIA,
Sebastian
das folgende Problem ist mir aufgefallen, als ich über meinen
Server eine Mail an loca...@domain.tld schicken wollte.
Domain.tld hat als eingetragenen MX
"domain-tld.mail.protection.outlook.com" - und diese (Sub)domain
kann der Bind, der ebenfalls auf der Kiste läuft, nicht
auflösen. Entsprechende Versuche enden reproduzierbar in einem
SERVFAIL. Bind hat die Version 9.11.5 aus einem Debian Buster,
ziemlich "out of the box", der als rekursiver Resolver angelegt
ist, also keine Forwarder eingetragen sind. Der Bind
funktioniert aber grundsätzlich, andere Domains werden
problemlos aufgelöst.
Auch wenn ich auf der gleichen Kiste nslookup dagegen z.B.
8.8.8.8 nach der o.g. Domain befragen lasse, erhalte ich
sinnvolle Antworten.
Was läuft da schief und wie kann ich es reparieren?
(Google war mir bislang auch nicht besonders hold - ich finde
zwar diverse Fundstellen von Fragestellern, die das gleiche
Problem haben, aber bislang keine wirkliche Lösungen...)
TIA,
Sebastian
Tim Ritberg
Nov 25, 2023, 5:47:09 PM11/25/23
to
Am 25.11.23 um 23:25 schrieb Sebastian Suchanek:
Schon mal den Cache geleert?
Tim
> Hallo zusammen,
>
> das folgende Problem ist mir aufgefallen, als ich über meinen
> Server eine Mail an loca...@domain.tld schicken wollte.
>
> Domain.tld hat als eingetragenen MX
> "domain-tld.mail.protection.outlook.com" - und diese (Sub)domain
> kann der Bind, der ebenfalls auf der Kiste läuft, nicht
> auflösen. Entsprechende Versuche enden reproduzierbar in einem
> SERVFAIL. Bind hat die Version 9.11.5 aus einem Debian Buster,
> ziemlich "out of the box", der als rekursiver Resolver angelegt
> ist, also keine Forwarder eingetragen sind. Der Bind
> funktioniert aber grundsätzlich, andere Domains werden
> problemlos aufgelöst.
Und wo holt sich dein Bind seine Antworten her?
>
> das folgende Problem ist mir aufgefallen, als ich über meinen
> Server eine Mail an loca...@domain.tld schicken wollte.
>
> Domain.tld hat als eingetragenen MX
> "domain-tld.mail.protection.outlook.com" - und diese (Sub)domain
> kann der Bind, der ebenfalls auf der Kiste läuft, nicht
> auflösen. Entsprechende Versuche enden reproduzierbar in einem
> SERVFAIL. Bind hat die Version 9.11.5 aus einem Debian Buster,
> ziemlich "out of the box", der als rekursiver Resolver angelegt
> ist, also keine Forwarder eingetragen sind. Der Bind
> funktioniert aber grundsätzlich, andere Domains werden
> problemlos aufgelöst.
Schon mal den Cache geleert?
Tim
Thomas Hochstein
Nov 26, 2023, 4:00:03 AM11/26/23
to
Sebastian Suchanek schrieb:
> Domain.tld hat als eingetragenen MX
> "domain-tld.mail.protection.outlook.com" - und diese (Sub)domain
> kann der Bind, der ebenfalls auf der Kiste läuft, nicht
> auflösen. Entsprechende Versuche enden reproduzierbar in einem
> SERVFAIL. [...]
"domain-tld.mail.protection.outlook.com" zuständig sind, (für Dich)
erreichbar?
Klappt eine direkte Anfrage dort?
> (Google war mir bislang auch nicht besonders hold - ich finde
> zwar diverse Fundstellen von Fragestellern, die das gleiche
> Problem haben, aber bislang keine wirkliche Lösungen...)
Ich kenne das Problem selbst nicht.
Denkbar erscheint mir
- dass die Nameserver(farmen) ab und an mal ausfallen,
- dass sie Anfragen begrenzen (rate limiting) und Du da aus irgendwelchen
Gründen hineinläufst,
- dass sie bestimmte Bereiche für Anfragen blockieren und Deine IP
dazugehört.
Letztlich ist das bislang alles reine Spekulation.
> Domain.tld hat als eingetragenen MX
> "domain-tld.mail.protection.outlook.com" - und diese (Sub)domain
> kann der Bind, der ebenfalls auf der Kiste läuft, nicht
> auflösen. Entsprechende Versuche enden reproduzierbar in einem
>
> Was läuft da schief und wie kann ich es reparieren?
Ist der / sind die Nameserver, die für
> Was läuft da schief und wie kann ich es reparieren?
"domain-tld.mail.protection.outlook.com" zuständig sind, (für Dich)
erreichbar?
Klappt eine direkte Anfrage dort?
> (Google war mir bislang auch nicht besonders hold - ich finde
> zwar diverse Fundstellen von Fragestellern, die das gleiche
> Problem haben, aber bislang keine wirkliche Lösungen...)
Denkbar erscheint mir
- dass die Nameserver(farmen) ab und an mal ausfallen,
- dass sie Anfragen begrenzen (rate limiting) und Du da aus irgendwelchen
Gründen hineinläufst,
- dass sie bestimmte Bereiche für Anfragen blockieren und Deine IP
dazugehört.
Letztlich ist das bislang alles reine Spekulation.
Thomas Hochstein
Nov 26, 2023, 4:30:03 AM11/26/23
to
Tim Ritberg schrieb:
> Am 25.11.23 um 23:25 schrieb Sebastian Suchanek:
Für ".com" von den Rootservern.
Für outlook. com von ns1-38.azure-dns.com, ns2-38.azure-dns.net,
ns3-38.azure-dns.org, ns4-38.azure-dns.info, nse21.o365filtering.com,
nse12.o365filtering.com, nse13.o365filtering.com oder
nse24.o365filtering.com.
Für protection.outlook.com und mail.protection.outlook.com von
ns1-proddns.glbdns.o365filtering.com oder
ns2-proddns.glbdns.o365filtering.com.
Wenn beide letztegenannten nicht funktionieren, dann gibt's eben keine
Daten.
> Am 25.11.23 um 23:25 schrieb Sebastian Suchanek:
>> Bind hat die Version 9.11.5 aus einem Debian Buster,
>> ziemlich "out of the box", der als rekursiver Resolver angelegt
>> ist, also keine Forwarder eingetragen sind.
>
>> ziemlich "out of the box", der als rekursiver Resolver angelegt
>> ist, also keine Forwarder eingetragen sind.
>
> Und wo holt sich dein Bind seine Antworten her?
Das schrieb er doch:
Für ".com" von den Rootservern.
Für outlook. com von ns1-38.azure-dns.com, ns2-38.azure-dns.net,
ns3-38.azure-dns.org, ns4-38.azure-dns.info, nse21.o365filtering.com,
nse12.o365filtering.com, nse13.o365filtering.com oder
nse24.o365filtering.com.
Für protection.outlook.com und mail.protection.outlook.com von
ns1-proddns.glbdns.o365filtering.com oder
ns2-proddns.glbdns.o365filtering.com.
Wenn beide letztegenannten nicht funktionieren, dann gibt's eben keine
Daten.
Marco Moock
Nov 26, 2023, 5:10:15 AM11/26/23
to
Am 25.11.2023 um 23:25:19 Uhr schrieb Sebastian Suchanek:
> Auch wenn ich auf der gleichen Kiste nslookup dagegen z.B.
> 8.8.8.8 nach der o.g. Domain befragen lasse, erhalte ich
> sinnvolle Antworten.
>
> Was läuft da schief und wie kann ich es reparieren?
Es KÖNNTE sein, dass die wie bei CDN auch anhand der Absender-IP
> Auch wenn ich auf der gleichen Kiste nslookup dagegen z.B.
> 8.8.8.8 nach der o.g. Domain befragen lasse, erhalte ich
> sinnvolle Antworten.
>
> Was läuft da schief und wie kann ich es reparieren?
verschiedene IPs zurückgeben, um das über den geografisch nächsten
DNS-Server abzuwickeln.
Prüfe mal deinen Cache und leere den.
Ebenso mal
dig mx example.org +trace teste und gucken, was faul ist.
Sebastian Suchanek
Dec 3, 2023, 3:47:14 PM12/3/23
to
Am 26.11.2023 um 11:10 schrieb Marco Moock:
> Am 25.11.2023 um 23:25:19 Uhr schrieb Sebastian Suchanek:
>
>> Auch wenn ich auf der gleichen Kiste nslookup dagegen z.B.
>> 8.8.8.8 nach der o.g. Domain befragen lasse, erhalte ich
>> sinnvolle Antworten.
>>
>> Was läuft da schief und wie kann ich es reparieren?
>
> Es KÖNNTE sein, dass die wie bei CDN auch anhand der Absender-IP
> verschiedene IPs zurückgeben, um das über den geografisch nächsten
> DNS-Server abzuwickeln.
>
> Prüfe mal deinen Cache und leere den.
Geleert habe ich den Cache, das hat aber keine Veränderung erbracht.
> Am 25.11.2023 um 23:25:19 Uhr schrieb Sebastian Suchanek:
>
>> Auch wenn ich auf der gleichen Kiste nslookup dagegen z.B.
>> 8.8.8.8 nach der o.g. Domain befragen lasse, erhalte ich
>> sinnvolle Antworten.
>>
>> Was läuft da schief und wie kann ich es reparieren?
>
> Es KÖNNTE sein, dass die wie bei CDN auch anhand der Absender-IP
> verschiedene IPs zurückgeben, um das über den geografisch nächsten
> DNS-Server abzuwickeln.
>
> Prüfe mal deinen Cache und leere den.
| # dig domain.tld +trace
|
| ; <<>> DiG 9.11.5-P4-5.1+deb10u9-Debian <<>> mx domain.tld +trace
| ;; global options: +cmd
| ;; Received 28 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms
|
| #
So richtig schlau werde ich daraus aber ehrlich gesagt nicht. (Und ja,
statt "domain.tld" habe ich natürlich die richtige Originaldomain
verwendet.)
Tschüs,
Sebastian
Sebastian Suchanek
Dec 3, 2023, 3:47:14 PM12/3/23
to
Am 26.11.2023 um 09:49 schrieb Thomas Hochstein:
> Sebastian Suchanek schrieb:
>
>> Domain.tld hat als eingetragenen MX
>> "domain-tld.mail.protection.outlook.com" - und diese (Sub)domain
>> kann der Bind, der ebenfalls auf der Kiste läuft, nicht
>> auflösen. Entsprechende Versuche enden reproduzierbar in einem
>> SERVFAIL. [...]
>>
>> Was läuft da schief und wie kann ich es reparieren?
>
> Ist der / sind die Nameserver, die für
> "domain-tld.mail.protection.outlook.com" zuständig sind, (für Dich)
> erreichbar?
>
> Klappt eine direkte Anfrage dort?
ns1-proddns.glbdns.o365filtering.com und
> Sebastian Suchanek schrieb:
>
>> Domain.tld hat als eingetragenen MX
>> "domain-tld.mail.protection.outlook.com" - und diese (Sub)domain
>> kann der Bind, der ebenfalls auf der Kiste läuft, nicht
>> auflösen. Entsprechende Versuche enden reproduzierbar in einem
>> SERVFAIL. [...]
>>
>> Was läuft da schief und wie kann ich es reparieren?
>
> Ist der / sind die Nameserver, die für
> "domain-tld.mail.protection.outlook.com" zuständig sind, (für Dich)
> erreichbar?
>
> Klappt eine direkte Anfrage dort?
ns2-proddns.glbdns.o365filtering.com
lösen auf jeweils zwei IPs auf, mit allen vier IPs erhalte ich mit
nslookup von meinem Server aus gültige Antworten.
Allerdings habe ich beim Herumprobieren und "Herumstöbern" in Microsofts
DNS-Einträgen festgestellt, dass einige Antworten spürbar länger
brauchen. Ich will also nicht grundsätzlich ausschließen, dass da eine
wackelige Verbindung mit gelegentlichen Timeouts im Spiel sind.
Allerdings kommt der SERVFAIL bei der nslookup-Abfrage der
Originaldomain via meinem eigenen Bind immer sehr schnell.
>> (Google war mir bislang auch nicht besonders hold - ich finde
>> zwar diverse Fundstellen von Fragestellern, die das gleiche
>> Problem haben, aber bislang keine wirkliche Lösungen...)
>
> Ich kenne das Problem selbst nicht.
>
> Denkbar erscheint mir
>
> - dass die Nameserver(farmen) ab und an mal ausfallen,
gleichzeitig und permanent ausfallen.
> - dass sie Anfragen begrenzen (rate limiting) und Du da aus irgendwelchen
> Gründen hineinläufst,
ist, mit allgemeinen Standards (hier DNS) bisweilen sehr eigenwillig
umzugehen.
Aber wenn es so wäre: wie herausfinden?
Spricht nslookup mit den Micrsoft-DNS-Servern eigentlich exakt gleich
(Protokoll, Port...), wie es der Bind versucht, oder gibt es in der
Kommunikation zwischen DNS-Servern noch irgendwelche Sonderlocken?
> - dass sie bestimmte Bereiche für Anfragen blockieren und Deine IP
> dazugehört.
Auch solche Schlechtigkeiten traue ich Microsoft grundsätzlich zu, aber
dann dürfte ja auch die direkte nslookup-Anfrage an deren authoritative
Nameserver keine Resultate erbringen.
Tschüs,
Sebastian
Tim Ritberg
Dec 3, 2023, 3:52:53 PM12/3/23
to
Am 03.12.23 um 21:47 schrieb Sebastian Suchanek:
> | ;; Received 28 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms
> |
> | #
Das sieht mir nach systemd aus...
Tim
> | ;; Received 28 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms
> |
> | #
Tim
Marco Moock
Dec 4, 2023, 2:16:50 AM12/4/23
to
Am 03.12.2023 um 21:47:06 Uhr schrieb Sebastian Suchanek:
> | # dig domain.tld +trace
> |
> | ; <<>> DiG 9.11.5-P4-5.1+deb10u9-Debian <<>> mx domain.tld +trace
> | ;; global options: +cmd
> | ;; Received 28 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms
> |
> | #
>
> So richtig schlau werde ich daraus aber ehrlich gesagt nicht. (Und
> ja, statt "domain.tld" habe ich natürlich die richtige Originaldomain
> verwendet.)
Poste mal die gesamte Ausgabe hier.
> | # dig domain.tld +trace
> |
> | ; <<>> DiG 9.11.5-P4-5.1+deb10u9-Debian <<>> mx domain.tld +trace
> | ;; global options: +cmd
> | ;; Received 28 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms
> |
> | #
>
> So richtig schlau werde ich daraus aber ehrlich gesagt nicht. (Und
> ja, statt "domain.tld" habe ich natürlich die richtige Originaldomain
> verwendet.)
Marco Moock
Dec 4, 2023, 2:17:16 AM12/4/23
to
solange der funktioniert.
Sebastian Suchanek
Dec 4, 2023, 2:51:57 AM12/4/23
to
Tschüs,
Sebastian
Marco Moock
Dec 4, 2023, 3:25:33 AM12/4/23
to
Am 04.12.2023 um 08:47:21 Uhr schrieb Sebastian Suchanek:
> Das war die gesamte Ausgabe.
Dann ist was faul.
> Das war die gesamte Ausgabe.
Mache dann mal
dig domain.tld +trace @IP-vom-Resolver
Sebastian Suchanek
Dec 4, 2023, 6:32:16 AM12/4/23
to
Am 04.12.2023 um 09:25 schrieb Marco Moock:
> Am 04.12.2023 um 08:47:21 Uhr schrieb Sebastian Suchanek:
>
>> Das war die gesamte Ausgabe.
>
> Dann ist was faul.
Der Vollständigkeit halber: dieses Problem scheint von meinem
> Am 04.12.2023 um 08:47:21 Uhr schrieb Sebastian Suchanek:
>
>> Das war die gesamte Ausgabe.
>
> Dann ist was faul.
ursprünglichen Problem unabhängig zu sein, ich habe 'mal die Gegenprobe
mit einer meiner eigenen Domains gemacht:
nslookup funktioniert problemlos...
| # nslookup -type=mx suchanek.de
| Server: 127.0.0.53
| Address: 127.0.0.53#53
|
| Non-authoritative answer:
| suchanek.de mail exchanger = 10 smarthost-mta.de.
|
| Authoritative answers can be found from:
|
| #
...dig trace hingegen nicht:
| # dig mx suchanek.de +trace
|
| ; <<>> DiG 9.11.5-P4-5.1+deb10u9-Debian <<>> mx suchanek.de +trace
| ;; global options: +cmd
| ;; Received 28 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms
|
| #
| ;; Received 28 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms
|
| #
> Mache dann mal
>
> dig domain.tld +trace @IP-vom-Resolver
Bitteschön: (Es soll ja der lokal laufende Bind verwendet werden, daher
>
> dig domain.tld +trace @IP-vom-Resolver
127.0.0.1 - und sorry fü die vermutlich zerschossenen Zeilenumbrüche...)
| # dig mx domain.tld +trace @127.0.0.1
|
| ; <<>> DiG 9.11.5-P4-5.1+deb10u9-Debian <<>> mx domain.tld +trace
@127.0.0.1
| ; <<>> DiG 9.11.5-P4-5.1+deb10u9-Debian <<>> mx domain.tld +trace
| ;; global options: +cmd
| . 424157 IN NS a.root-servers.net.
| . 424157 IN NS l.root-servers.net.
| . 424157 IN NS e.root-servers.net.
| . 424157 IN NS h.root-servers.net.
| . 424157 IN NS i.root-servers.net.
| . 424157 IN NS f.root-servers.net.
| . 424157 IN NS g.root-servers.net.
| . 424157 IN NS d.root-servers.net.
| . 424157 IN NS c.root-servers.net.
| . 424157 IN NS b.root-servers.net.
| . 424157 IN NS m.root-servers.net.
| . 424157 IN NS j.root-servers.net.
| . 424157 IN NS k.root-servers.net.
| . 424157 IN RRSIG NS 8 0 518400
20231216050000 20231203040000 46780 .
d8VH9L+uoVzTqJe5UiH7q+5+2oFXuqZu9rejDyHMhtKXczSfRZOW/JKN
wnXiAm0Zs9zViyjHeygSSwRQi4Yii7m7NYMqLpGyYB7ToNQ+xJaV9v2C
vMMva32F9tRKka3VghmQxtHvIIaulTS1grIYTaXKSOqJQcbqlJ/t7lOi
Lp1lC3xIbBFAgIz2g9+PfI8dSdJKeGa8icG1mXyjPSioakP7Z6SpM5YU
TqyrwTflSPcKM9VopARDY71+nuzomyypMlKRXNd/OAybqQVPf4wL0PGs
+3d0828ZAJ4+0Y8D1Pz8LCHzM6f/6cuTyc7L66oDVKK21RIN+kbs5IsC AKuUug==
| ;; Received 1125 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
|
| com. 172800 IN NS a.gtld-servers.net.
| com. 172800 IN NS b.gtld-servers.net.
| com. 172800 IN NS c.gtld-servers.net.
| com. 172800 IN NS d.gtld-servers.net.
| com. 172800 IN NS e.gtld-servers.net.
| com. 172800 IN NS f.gtld-servers.net.
| com. 172800 IN NS g.gtld-servers.net.
| com. 172800 IN NS h.gtld-servers.net.
| com. 172800 IN NS i.gtld-servers.net.
| com. 172800 IN NS j.gtld-servers.net.
| com. 172800 IN NS k.gtld-servers.net.
| com. 172800 IN NS l.gtld-servers.net.
| com. 172800 IN NS m.gtld-servers.net.
| com. 86400 IN DS 30909 8 2
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
| com. 86400 IN RRSIG DS 8 1 86400
20231217050000 20231204040000 46780 .
vBcxsxhQK2yh/zsElT2QWiwJ3vxrY6I4vIhWmZsOJuJyJ3CAfi/+4HwN
M2dbZkQZcwNh5wlEV10fkZvYAvgvt8qvgYGAV/jxThyfqS+I206XKe9x
bz6+iTw9IubTBNSR3fx2dDCCuCNN8ZWgdmu1EeYzSvDFVuYGetoOik4K
hBAIBbl7whUbrh/CuUPzGgRA+O/Iuc7rGKEezq7Ujh75UT6dOPVFLCun
NNB9zaZkV7cJdqq0lZI5I9QLwkJq1/iIHiK2FB4pn/VVO79GravS3A0V
b2s6DsUCsrNJtxqoymywRWXQyVlhV5sHG3RMazsrGX9LhYOXBcm1c/nC J2sO8Q==
| ;; Received 1171 bytes from 198.97.190.53#53(h.root-servers.net) in 4 ms
|
| domain.tld. 172800 IN NS ns1018.ui-dns.de.
| domain.tld. 172800 IN NS ns1018.ui-dns.biz.
| domain.tld. 172800 IN NS ns1018.ui-dns.org.
| domain.tld. 172800 IN NS ns1018.ui-dns.com.
| CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 -
CK0Q2D6NI4I7EQH8NA30NS61O48UL8G5 NS SOA RRSIG DNSKEY NSEC3PARAM
| CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400
20231208052821 20231201041821 63246 com.
BRDgjHm5rmt3yE1ehqmGH/pZTHEOQE6SSi7Ixcrv+eT4WEQxhSzQmOt2
lp0M+r29vhnlyYdmI3TIZ7uOdurUpII/yboJbKL4U9aDOlw776VGEhqu
RlnLtM7OFALwdwtKM0IxrVm2kIsBDOLDIgwEY+sxmV0S5zpUVLQuZe1m
/Zkhqq8/+37kF/Z98RVfdGnOmDYKoOk3mztKjeQ9+L7zOA==
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 13 2 86400
20231208052821 20231201041821 46171 com.
O3mTbNY/Tv8tBAvRIAzdaICXn23oceEPfZkx1AOp5jdk9+HfsQ7ZgPhG
DTT0mdf2RDf8Z79/dBg68PoJEc+t1Q==
| PUJTCKKOOPDR3PFHBCC15PAL3KK5ANB2.com. 86400 IN NSEC3 1 1 0 -
PUJTGDAMBVKMNKFQU8GNUBTE5I0QDG19 NS DS RRSIG
| PUJTCKKOOPDR3PFHBCC15PAL3KK5ANB2.com. 86400 IN RRSIG NSEC3 8 2 86400
20231208062349 20231201051349 63246 com.
Ga+UZ4GWv4mSuUV/e4LZfwaWXbQ8oXzTS64cd4ao+LGvMsjmffV1Rvtm
Zk6U5Hhe79q41us6PTeTgB3gPMYKUA0uaoNDZyokw1jEJ1VllxG+cnze
dL5ILorrrxjsU3s2AVS9AFD6gHxBCpK60UAB3+o+x99SGGr9O10yddgk
hKRxO0UnbZxvGeWDcwQRn4Nzm1rBq4z+2etP1UZyOYEG+g==
| PUJTCKKOOPDR3PFHBCC15PAL3KK5ANB2.com. 86400 IN RRSIG NSEC3 13 2 86400
20231208062349 20231201051349 46171 com.
pLR1xeViqAJQuybrrDbfhJaLsCZGVaZoL3+Fk2lg1kxpZLDVz7fB5XKc
UXairvUM6tYwUqZmTvMEE/9j28qX1Q==
| ;; Received 951 bytes from 192.54.112.30#53(h.gtld-servers.net) in 4 ms
|
| domain.tld. 3600 IN MX 0
domain-tld.mail.protection.outlook.com.
| ;; Received 92 bytes from
2001:8d8:fe:53:0:d9a0:5212:100#53(ns1018.ui-dns.com) in 5 ms
|
| #
Und das Ganze nochmal für den angegeben MX:
| # dig domain-tld.mail.protection.outlook.com +trace @127.0.0.1
|
| ; <<>> DiG 9.11.5-P4-5.1+deb10u9-Debian <<>>
domain-tld.mail.protection.outlook.com +trace @127.0.0.1
| ;; global options: +cmd
| . 424117 IN NS l.root-servers.net.
| . 424117 IN NS h.root-servers.net.
| . 424117 IN NS d.root-servers.net.
| . 424117 IN NS a.root-servers.net.
| . 424117 IN NS b.root-servers.net.
| . 424117 IN NS j.root-servers.net.
| . 424117 IN NS m.root-servers.net.
| . 424117 IN NS e.root-servers.net.
| . 424117 IN NS k.root-servers.net.
| . 424117 IN NS f.root-servers.net.
| . 424117 IN NS g.root-servers.net.
| . 424117 IN NS c.root-servers.net.
| . 424117 IN NS i.root-servers.net.
| . 424117 IN RRSIG NS 8 0 518400
20231216050000 20231203040000 46780 .
d8VH9L+uoVzTqJe5UiH7q+5+2oFXuqZu9rejDyHMhtKXczSfRZOW/JKN
wnXiAm0Zs9zViyjHeygSSwRQi4Yii7m7NYMqLpGyYB7ToNQ+xJaV9v2C
vMMva32F9tRKka3VghmQxtHvIIaulTS1grIYTaXKSOqJQcbqlJ/t7lOi
Lp1lC3xIbBFAgIz2g9+PfI8dSdJKeGa8icG1mXyjPSioakP7Z6SpM5YU
TqyrwTflSPcKM9VopARDY71+nuzomyypMlKRXNd/OAybqQVPf4wL0PGs
+3d0828ZAJ4+0Y8D1Pz8LCHzM6f/6cuTyc7L66oDVKK21RIN+kbs5IsC AKuUug==
| ;; Received 1125 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
|
| com. 172800 IN NS a.gtld-servers.net.
| com. 172800 IN NS b.gtld-servers.net.
| com. 172800 IN NS c.gtld-servers.net.
| com. 172800 IN NS d.gtld-servers.net.
| com. 172800 IN NS e.gtld-servers.net.
| com. 172800 IN NS f.gtld-servers.net.
| com. 172800 IN NS g.gtld-servers.net.
| com. 172800 IN NS h.gtld-servers.net.
| com. 172800 IN NS i.gtld-servers.net.
| com. 172800 IN NS j.gtld-servers.net.
| com. 172800 IN NS k.gtld-servers.net.
| com. 172800 IN NS l.gtld-servers.net.
| com. 172800 IN NS m.gtld-servers.net.
| com. 86400 IN DS 30909 8 2
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
| com. 86400 IN RRSIG DS 8 1 86400
20231217050000 20231204040000 46780 .
vBcxsxhQK2yh/zsElT2QWiwJ3vxrY6I4vIhWmZsOJuJyJ3CAfi/+4HwN
M2dbZkQZcwNh5wlEV10fkZvYAvgvt8qvgYGAV/jxThyfqS+I206XKe9x
bz6+iTw9IubTBNSR3fx2dDCCuCNN8ZWgdmu1EeYzSvDFVuYGetoOik4K
hBAIBbl7whUbrh/CuUPzGgRA+O/Iuc7rGKEezq7Ujh75UT6dOPVFLCun
NNB9zaZkV7cJdqq0lZI5I9QLwkJq1/iIHiK2FB4pn/VVO79GravS3A0V
b2s6DsUCsrNJtxqoymywRWXQyVlhV5sHG3RMazsrGX9LhYOXBcm1c/nC J2sO8Q==
| ;; Received 1199 bytes from 199.7.91.13#53(d.root-servers.net) in 4 ms
|
| outlook.com. 172800 IN NS nse12.o365filtering.com.
| outlook.com. 172800 IN NS nse13.o365filtering.com.
| outlook.com. 172800 IN NS nse21.o365filtering.com.
| outlook.com. 172800 IN NS nse24.o365filtering.com.
| outlook.com. 172800 IN NS ns4-38.azure-dns.info.
| outlook.com. 172800 IN NS ns3-38.azure-dns.org.
| outlook.com. 172800 IN NS ns2-38.azure-dns.net.
| outlook.com. 172800 IN NS ns1-38.azure-dns.com.
| CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 -
CK0Q2D6NI4I7EQH8NA30NS61O48UL8G5 NS SOA RRSIG DNSKEY NSEC3PARAM
| CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400
20231208052821 20231201041821 63246 com.
BRDgjHm5rmt3yE1ehqmGH/pZTHEOQE6SSi7Ixcrv+eT4WEQxhSzQmOt2
lp0M+r29vhnlyYdmI3TIZ7uOdurUpII/yboJbKL4U9aDOlw776VGEhqu
RlnLtM7OFALwdwtKM0IxrVm2kIsBDOLDIgwEY+sxmV0S5zpUVLQuZe1m
/Zkhqq8/+37kF/Z98RVfdGnOmDYKoOk3mztKjeQ9+L7zOA==
| CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 13 2 86400
20231208052821 20231201041821 46171 com.
O3mTbNY/Tv8tBAvRIAzdaICXn23oceEPfZkx1AOp5jdk9+HfsQ7ZgPhG
DTT0mdf2RDf8Z79/dBg68PoJEc+t1Q==
| 4N822AIM85H3A7LSD1MKIE0P53LE55KD.com. 86400 IN NSEC3 1 1 0 -
4N829O36838VOEDEBI5NBD1TRPRNHRGU NS DS RRSIG
| 4N822AIM85H3A7LSD1MKIE0P53LE55KD.com. 86400 IN RRSIG NSEC3 8 2 86400
20231208071714 20231201060714 63246 com.
qdw7cCM/7NeUbxTu9nS1l/yW3Q7sLVLLRIt1i4tXzGq7Yua7uH9f1OpM
UxeapzbPLCzBABt+zghrrEepn6Fqol4OQmoJ6/GlwJbhJxDvF5KUs1z1
AsdVutCqNG4fZl25GIh/5qRLaDOMsCFDU1R0QR/y7sDM9wAeEvPIkcZ/
Q6D1PbqzGMVN0cWFblCsdpHPORezOL9HKo9SYQHBF2q0Ug==
| 4N822AIM85H3A7LSD1MKIE0P53LE55KD.com. 86400 IN RRSIG NSEC3 13 2 86400
20231208071714 20231201060714 46171 com.
zuZpqkGuXd2W8jMMN6f4JWcktX0Fsfrszr2GuRWgAaqrRSiQQ32TXyk2
edBbUZD94YtIqsYkW1H2JlQk/2PxvQ==
| ;; Received 1151 bytes from 192.52.178.30#53(k.gtld-servers.net) in 16 ms
|
| mail.protection.outlook.com. 1800 IN NS
ns1-proddns.glbdns.o365filtering.com.
| mail.protection.outlook.com. 1800 IN NS
ns2-proddns.glbdns.o365filtering.com.
| ;; Received 141 bytes from 104.47.38.8#53(nse12.o365filtering.com) in
88 ms
|
| ;; expected opt record in response
| ;; Received 12 bytes from
104.47.34.49#53(ns2-proddns.glbdns.o365filtering.com) in 26 ms
|
| #
Tschüs,
Sebastian
Marco Moock
Dec 4, 2023, 6:40:37 AM12/4/23
to
Am 04.12.2023 um 12:29:04 Uhr schrieb Sebastian Suchanek:
> Bitteschön: (Es soll ja der lokal laufende Bind verwendet werden,
> daher 127.0.0.1 - und sorry fü die vermutlich zerschossenen
> Zeilenumbrüche...)
Dann werfe systemd-resolve runter, denn dann kann der BIND genutzt
> Bitteschön: (Es soll ja der lokal laufende Bind verwendet werden,
> daher 127.0.0.1 - und sorry fü die vermutlich zerschossenen
> Zeilenumbrüche...)
werden und es laufen nicht 2 Caches, die sich je nach Konfiguration
bezüglich der Listen-Optionen gegenseitig stören.
Trage ::1 statisch in die resolv.conf ein, nachdem systemd-resolve
entfernt wurde.
Eigentlich müsste ja die Antwort auf den A-Query (IPv4) kommen.
Sebastian Suchanek
Dec 10, 2023, 10:31:44 AM12/10/23
to
Thus spoke Marco Moock:
systemd-resolved ist jetzt deaktiviert. Den Bind-Cache habe
ich auch gleich noch 'mal ge-"flush"-t, und jetzt scheint es
tatsächlich zu funktionieren. Mal abwarten, ob das so
bleibt...
>> [...]
in mein Posting zu kopieren.
> Eigentlich müsste ja die Antwort auf den A-Query (IPv4)
> kommen.
Sollte man meinen, ja. Allerdings bleibt dieses Verhalten
auch jetzt noch, nachdem nslookup für die fragliche Subdomain
gültige Antworten liefert.
Tschüs,
Sebastian
> Am 04.12.2023 um 12:29:04 Uhr schrieb Sebastian Suchanek:
>
>> Bitteschön: (Es soll ja der lokal laufende Bind verwendet
>> werden, daher 127.0.0.1 - und sorry fü die vermutlich
>> zerschossenen Zeilenumbrüche...)
>
> Dann werfe systemd-resolve runter, denn dann kann der BIND
> genutzt werden und es laufen nicht 2 Caches, die sich je
> nach Konfiguration bezüglich der Listen-Optionen
> gegenseitig stören. Trage ::1 statisch in die resolv.conf
> ein, nachdem systemd-resolve entfernt wurde.
Ich habe mir erlaubt, 127.0.0.1 einzutragen ;-), aber
>
>> Bitteschön: (Es soll ja der lokal laufende Bind verwendet
>> werden, daher 127.0.0.1 - und sorry fü die vermutlich
>> zerschossenen Zeilenumbrüche...)
>
> Dann werfe systemd-resolve runter, denn dann kann der BIND
> genutzt werden und es laufen nicht 2 Caches, die sich je
> nach Konfiguration bezüglich der Listen-Optionen
> gegenseitig stören. Trage ::1 statisch in die resolv.conf
> ein, nachdem systemd-resolve entfernt wurde.
systemd-resolved ist jetzt deaktiviert. Den Bind-Cache habe
ich auch gleich noch 'mal ge-"flush"-t, und jetzt scheint es
tatsächlich zu funktionieren. Mal abwarten, ob das so
bleibt...
>> [...]
>> | ;; expected opt record in response
>> | ;; Received 12 bytes from 104.47.34.49#53(ns2-proddns.glbdns.o365filtering.com) in 26 ms
>
> Fehlt da noch was?
Nein - also nicht in dem Sinn, das ich vergessen hätte, etwas
>> | ;; Received 12 bytes from 104.47.34.49#53(ns2-proddns.glbdns.o365filtering.com) in 26 ms
>
> Fehlt da noch was?
in mein Posting zu kopieren.
> Eigentlich müsste ja die Antwort auf den A-Query (IPv4)
> kommen.
auch jetzt noch, nachdem nslookup für die fragliche Subdomain
gültige Antworten liefert.
Tschüs,
Sebastian
Marco Moock
Dec 10, 2023, 10:42:08 AM12/10/23
to
Am 10.12.2023 um 16:31:25 Uhr schrieb Sebastian Suchanek:
> Sollte man meinen, ja. Allerdings bleibt dieses Verhalten
> auch jetzt noch, nachdem nslookup für die fragliche Subdomain
> gültige Antworten liefert.
Neustart machen, Caches vorher leeren und dann nochmal alles testen und
> Sollte man meinen, ja. Allerdings bleibt dieses Verhalten
> auch jetzt noch, nachdem nslookup für die fragliche Subdomain
> gültige Antworten liefert.
schauen, was den gewünschten Record bringt und was nicht.
0 new messages