30.07.2012

6895

Sporadische EMail Versandprobleme nach DNS Änderung

Das uns betreuende IT-Unternehmen hat im DNS die Rekursion und Weiterleitung deaktivert. Jetzt erhalten wir manchmal beim EMail-Versand die Fehlermeldung #554 5.7.1 Relay access denied # zurück.

Konfiguration:
Windows AD Server (Windows 2008R2)
Exchange 2010 / Zustellung über MX (Windows 2008R2)
Clientanbindung über Outlook 2010

Beide Server sind über je eine öffentliche IP erreichbar und untereinander über ein internes Netzwerk verbunden.

Das betreunende Unternehmen hat aus Sicherheitsgründen auf dem 1. Server im DNS Dienst die Rekursion und Weiterleitung deaktivert. Der DNS Dienst ist außerdem nur für die interne Netzwerkkarte aktiv.

Seit dieser Änderung bekommen wir allerdings bei einigen Mails die Fehlermeldung #554 5.7.1 Relay access denied# zurück.

Wenn man die Mails danach neu sendet werden diese meistens ohne Fehlermeldung zugestellt!?!

Leider ist unser dortiger Ansprechpartner für unbestimmte Zeit 'erkrankt' und die anderen Mitarbeiter fühlen sich für unser Problem nicht zuständig! (Wir suchen schon nach einem zuverlässigeren Partner...)

Andere Ratschläge von Google und Co. konnten das Problem nicht lösen bzw. sind alle Einstellungen im Exchange m.E. richtig gesetzt und wurden auch nicht angefasst.

Ich kann aber auch ehrlich gesagt nicht nachvollziehen wie und ob die DNS Änderung überhaupt mit dem Fehler zusammenhängt.

Jemand eine Idee wo der Fehler liegt?

Viele Grüße
Chris

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 188832

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

Ausgedruckt am: 22.11.2024 um 01:11 Uhr

12 Kommentare

Neuester Kommentar

Hallo,

Zitat von @Christian:
Windows AD Server (Windows 2008R2)

Server1

Exchange 2010 / Zustellung über MX (Windows 2008R2)

Server2

Beide Server sind über je eine öffentliche IP erreichbar

Du willst uns sagen das Server1 sowie Server2 jeweils direkt im Internet hängen und somit eine Öffentliche IP haben?

und untereinander über ein internes Netzwerk verbunden.

Wie sollen wir uns das jetzt vorstellen? Patchkabel verbindet die Zwei Server auch noch? VPN? Oder was?

Der DNS Dienst ist außerdem nur für die interne Netzwerkkarte aktiv.

Sollen wir jetzt daraus ableiten das dein DC1 (Dein Server1) mehr als eine Netzwerkkarte hat? Trifft diese Vermutung dann auf Server2 (Dein Exchange) auch zu?

Andere Ratschläge von Google und Co. konnten das Problem nicht lösen

Google ist gross. Sollen wir jetzt alles noch mal durchkauen was du schon gesucht / gefunden / gelesen hast?

richtig gesetzt und wurden auch nicht angefasst.

Dann sollte es ja keinen Fehler geben, oder?

Ich kann aber auch ehrlich gesagt nicht nachvollziehen wie und ob die DNS Änderung überhaupt mit dem Fehler zusammenhängt.

Erkläre uns doch erstmal wie deine Server zusammenhängen. beides DC? Beides DNS? Nur Server1 DC und DNS? IPconfig /all vom Server2 und vom Server1 würde hier auch helfen sowie evtl. ein Route /Print von beiden. Gibt es noch andere Server / DNS / DC usw.? Wird direkt per DNS oder per Smarthost von euch aus gesendet?

Jemand eine Idee wo der Fehler liegt?

DNS?

Wir sind hier Blind und Taub. Wir kennen auch dein Netzwerk nicht. Wir können mit dem Begriff Server viel anstellen, allerdings ob es dann deiner gegebenheit vor Ort entspricht ...

Gruß,
Peter

Hallo Peter,

sorry. Da war ich mal wieder viel zu schnell und habe wichtige Daten ausgelassen.

Zu den Servern:

1)
Windows 2008R2
DC & DNS-Server

Ethernet-Adapter LAN-Verbindung 1:

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Citrix PV Ethernet Adapter #2
Physikalische Adresse . . . . . . : D6-0C-31-00-54-3C
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 10.0.9.136(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.0.0.0
Standardgateway . . . . . . . . . :
DHCPv6-IAID . . . . . . . . . . . : 310025775
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-16-5A-E2-38-A6-80-92-51-EA-77
DNS-Server . . . . . . . . . . . : ::1
127.0.0.1
NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter LAN-Verbindung 2:

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Citrix PV Ethernet Adapter
Physikalische Adresse . . . . . . : 0E-4B-16-1F-4A-84
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 85.197.XXX.XXX(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 85.197.XXX.XXX
DHCPv6-IAID . . . . . . . . . . . : 245792914
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-16-5A-E2-38-A6-80-92-51-EA-77
DNS-Server . . . . . . . . . . . : ::1
8.8.8.8
8.8.4.4

2)
Windows 2008R2
Exchange 2010

Ethernet-Adapter LAN-Verbindung 1:

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Citrix PV Ethernet Adapter #2
Physikalische Adresse . . . . . . : 1E-27-7C-54-0B-A9
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 10.0.9.135(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.0.0.0
Standardgateway . . . . . . . . . :
DHCPv6-IAID . . . . . . . . . . . : 310008781
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-16-58-37-07-7A-77-5F-42-CE-16
DNS-Server . . . . . . . . . . . : 10.0.9.136
NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter LAN-Verbindung 2:

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Citrix PV Ethernet Adapter
Physikalische Adresse . . . . . . : 4A-DA-39-90-FC-5D
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 85.197.XXX.XXX(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 85.197.XXX.XXX
DNS-Server . . . . . . . . . . . : 8.8.8.8
8.8.4.4
NetBIOS über TCP/IP . . . . . . . : Aktiviert

Es handelt sich um virtuelle Server mit je zwei Netzwerkkarten, wovon eine eine öffentliche ist und die andere an einem virtuellen Switch gebunden ist. Alle Netzwerkadressen sind fest eingestellt.
Am virtuellen Switch hängen noch 8 Windows 7 Clients der jeweiligen Anwender.

Der Exchange versendet die Mails direkt; kein Smarthost.

Ich habe mich bei Google durch viele Beiträge zum Fehlercode #554 gelesen.
Dort war auch die Rede von SMTP Authentification. Die entsprechenden Einstellungen sind aber m.E. im Exchange richtig gesetzt, zumindest war der Verbindungstest erfolgreich.

Es hat ja auch bis zur Änderung durch den Dienstleister alles problemlos funktioniert.
Ich möchte nur auf dem DNS Server die Rekursion nicht wieder aktivieren, weil das wohl doch ein ziemliches Sicherheitsrisiko ist.

Internetverbindung funktioniert auf beiden Server durchgehend. Auch Namensauflösung ist kein Problem.
Der Exchange Verbindungstest und der Outlook Autokonfigurationstest sind beide ohne Fehler durchgelaufen. (Sowohl von intern als auch von extern)

Es ist auch merkwürdig, dass der Fehler nicht immer auftritt sondern nur manchmal und oft durch mehrmaliges ausprobieren die Mail doch zugestellt wird.

Ich habe auch gerade mehrer EMails über ein iPhone gesendet. Dort ist der Fehler auch (nur) bei einer Mail aufgetreten.

Ich hoffe die Angaben helfen weiter, ansonsten bitte weitere Infos anfordern.

Vielen Dank und Gruß
Chris

Hi

Darf man Fragen aus welchem Grund der Dc direkt am Internet hängt ? Auch die direkte Anbindung des Exchange ist mehr als fragwürdig.

LG

Zitat von @Christian:

Seit dieser Änderung bekommen wir allerdings bei einigen Mails die Fehlermeldung #554 5.7.1 Relay access denied#
zurück.

Welcher (Relay-) Server meldet das denn? Unten schreibst du, der Exchange stellt die Mails direkt zu, d.h., es gibt keinen Relay Server. Also unterbindet dein Exchange die Weiterleitung.

Dies kann geschehen, wenn du aus einem "verbotenen" Nummernkreis sendest.

Könnte es sein, dass deine Windows/Outlook Clients mit deinem Exchange ab und an mal über dessen öffentliche IP Adresse kommunizieren?

Mit welchen Einträgen steht der Exchange im DNS? Hat er vielleicht sogar die öffentliche und die private Adresse unter demselben Namen stehen? Oder einen fehlerhaften CNAME (Alias) Eintrag?

Zitat von @catachan:

Darf man Fragen aus welchem Grund der Dc direkt am Internet hängt ?

Vermutlich, damit er ins Internet kommt, oder?
Aber woraus schliesst du, dass er "direkt" dran hängt?

Ich lese das so:
"Standardgateway . . . . . . . . . : 85.197.XXX.XXX"

Und da vermute ich einen Router und hoffentlich eine Firewall ;-

Auch die direkte Anbindung des Exchange ist mehr als fragwürdig.

Warum?

Wo gehört denn deiner Meinung nach ein MTA hin?

Zitat von @lexa-lexa:

Und da vermute ich einen Router und hoffentlich eine Firewall ;-

Deine Vermutung ist richtig. Dazwischen ist natürlich der Router und die Firwall des RZ Betreibers.

Welcher (Relay-) Server meldet das denn? Unten schreibst du, der Exchange stellt die Mails direkt zu, d.h., es gibt keinen Relay
Server. Also unterbindet dein Exchange die Weiterleitung.

Die Fehlermeldung wird jeweils von der Gegenseite (also dem Empfänger Server) generiert. Das ist soweit ich das beurteilen kann auch schon jeweils der Mail-Server der für die jeweilige Empfänger EMail-Adresse verantwortlich ist.
Die Mail wurde also von unserem Exchange angenommen und weitergeleitet.

Dies kann geschehen, wenn du aus einem "verbotenen" Nummernkreis sendest.

Könnte es sein, dass deine Windows/Outlook Clients mit deinem Exchange ab und an mal über dessen öffentliche IP Adresse kommunizieren?

Ja das kommt vor. Wobei allerdings auch Nutzer aus dem gleichem (privat/intern) Netz die Fehlermeldung bekommen.

Mit welchen Einträgen steht der Exchange im DNS? Hat er vielleicht sogar die öffentliche und die private Adresse unter
demselben Namen stehen? Oder einen fehlerhaften CNAME (Alias) Eintrag?

Im DNS steht nur die öffentliche Adresse und auch der CNAME Eintrag ist richtig.

Hallo,

Zitat von @Christian:
Die Fehlermeldung wird jeweils von der Gegenseite (also dem Empfänger Server) generiert.

Dir ist dann schon klar das wenn es nicht dein Exchange ist der dir den Relay Denied gibt das die Mail damit schon am anderen Server (ausserhalb deiner Kontrolle) angeklopft hat, oder? Passiert dies auch wenn du per Smarthost versendest?

Schau dir mal genau die Headerzeilen an. Du kannst dir aber auch dein SMTP Protokoll deines Exchange mal genauer ansehen.

Ja das kommt vor. Wobei allerdings auch Nutzer aus dem gleichem (privat/intern) Netz die Fehlermeldung bekommen.

Wie sind denn eure Clienst eingerichtet? Auch mit 2 Netzwerkkarten? Was haben die als DNS eingetragen?

Im DNS steht nur die öffentliche Adresse und auch der CNAME Eintrag ist richtig.

Und auf welchen Namen lösen deine Clients den Exchange auf? Auf die Öffentliche IP oder was? Notfalls mal ein Netzwerksniffer mitlaufen lassen.

Und warum haben beide Server 2 Netzwerkkarten? Gibt es da besondere Anforderungen zu?

Gruß,
Peter

Dazwischen ist natürlich der Router und die Firwall des RZ Betreibers.

"Firwall des RZ Betreibers" klingt komisch. Erwartet hätte ich einen Firewall in euren Räumen. Du sprachst davon, dass die Server virtualisiert sind, wahrscheinlich mit XEN. Ich kann mir den Aufbau deines Netzes momentan nicht endgültig vorstellen. Acht Windows 7 Clients am virtuellen Switch? Verstehe ich auch nicht wirklich, es sei denn, sie sind auch virtualisiert. Ansonsten wäre sie an einem physischen Switch.

Die Fehlermeldung wird jeweils von der Gegenseite (also dem Empfänger Server) generiert.

Manche Mails werden nicht angenommen, aber irgendwann später klappt das dann doch. Da sich zwischendurch das DNS nicht ändert, kann es eigentlich auch nicht dafür verantwortlich sein. Vielleicht Greylisting oder DNSBL?

Du schriebst:

Das betreuende Unternehmen hat aus Sicherheitsgründen auf dem 1. Server im DNS Dienst die Rekursion und Weiterleitung deaktivert.
Der DNS Dienst ist außerdem nur für die interne Netzwerkkarte aktiv.

Mit "erste Server" meinst du den Windows Server, ja?
Diese Sicherheitsgründe verstehe ich nicht. Warum sollten Rekursion und vor allem Weiterleitung ein Sicherheitsproblem sein?

Noch dazu, wenn das DNS nur intern läuft, was ebenfalls keinen Sinn macht, wenn dort die öffentliche IP des Exchange hinterlegt ist. Wo sind denn die MX Einträge für deinen Exchange bzw. deine Domäne hinterlegt? Hierüber erfahren andere MTAs, wohin Mails an deine Domäne abgeliefert werden sollen.

Und: War das vor der Umstellung auch so? Ich meine, war der DNS-Server jemails öffentlich erreichbar?

Wenn dein Mail-Server direkt im Netz steht und als MTA fungiert, musst du dafür sorgen, dass das DNS stimmig ist inkl. MX Eintrag:

C:\Users\lexa>nslookup
Standardserver: example-dns.de.lan
Address: 192.168.66.2

$ set type=mx
$ freenet.de
Server: example-dns.de.lan
Address: 192.168.66.2

Nicht autorisierende Antwort:
freenet.de MX preference = 1, mail exchanger = mx.freenet.de

mx.freenet.de internet address = 195.4.92.211
mx.freenet.de internet address = 195.4.92.212
[...]

$ quit

(Beispiel ist gekürzt)
Statt Freenet fragst du natürlich deine Domäne ab.

> Könnte es sein, dass deine Windows/Outlook Clients mit deinem Exchange ab und an mal über dessen öffentliche
IP Adresse kommunizieren?

Ja das kommt vor.

Ist das gewollt? Wie kommen sie überhaupt dorthin? Vertreter-Laptops?

Im DNS steht nur die öffentliche Adresse und auch der CNAME Eintrag ist richtig.

Wozu? Wie sollen ihn die Outlook Clients dann erreichen?
Die sollten ihn eigentlich über die interne 10.x.y.z ansprechen.

Ich mach hier mal 'nen break. Mir fehlen ein paar Meter Film bzw. Topologie. Zu meinem Verständnis:

1. Windows Server mit zwei IPs, eine private (10.0.9.136), eine öffentlich 85.197.x.x mit Default-GW, mit DNS Rolle aber nur auf der privaten IP Adresse aktiv
2. Windows/Exchange Server mit zwei IPs, eine private (10.0.9.135), eine öffentlich 85.197.x.y mit Default-GW, als DNS fungiert [1.]
3. Default-GW (Router) mit zwei IPs, eine private (10.0.9.254), eine öffentlich 85.197.x.z
4. Windows Client mit Outlook, eine private IP Adresse (10.0.9.100), als DNS fungiert der unter [1.] genannte

Stimmt das bis hier hin?

Dann weiter:

Ein E-Mail geht vom Client 10.0.9.100 an Exchange, dessen Name über den DNS Server aufgelöst wird. Der Client erfährt auf diesem Weg aber nur die öffentliche IP 85.197.x.y.

An dieser Stelle wäre Schluss, da der Server nicht erreichbar ist. Es sei denn, der Client hat einen Internet Zugang (Default-GW) und erreicht den Exchange über seine öffentliche IP Adresse. Dann liefert er seine Mail über die öffentliche IP des Exchange ein...?

Das erfährst du (hoffentlich) im Mail-Header der angelehnten Mails. Vielleicht hat er dort mal seine Class-C Adresse verwendet?

Zitat von @lexa-lexa:

"Firwall des RZ Betreibers" klingt komisch. Erwartet hätte ich einen Firewall in euren Räumen. Du sprachst
davon, dass die Server virtualisiert sind, wahrscheinlich mit XEN. Ich kann mir den Aufbau deines Netzes momentan nicht
endgültig vorstellen. Acht Windows 7 Clients am virtuellen Switch? Verstehe ich auch nicht wirklich, es sei denn, sie sind
auch virtualisiert. Ansonsten wäre sie an einem physischen Switch.

Ja, auch die Windows 7 Clients sind mit XEN virtualisiert.

> Die Fehlermeldung wird jeweils von der Gegenseite (also dem Empfänger Server) generiert.

Manche Mails werden nicht angenommen, aber irgendwann später klappt das dann doch. Da sich zwischendurch das DNS nicht
ändert, kann es eigentlich auch nicht dafür verantwortlich sein. Vielleicht Greylisting oder DNSBL?

Haben wir überprüft aber unser Exchange taucht in keiner Liste auf.

Du schriebst:

> Das betreuende Unternehmen hat aus Sicherheitsgründen auf dem 1. Server im DNS Dienst die Rekursion und Weiterleitung
deaktivert.
> Der DNS Dienst ist außerdem nur für die interne Netzwerkkarte aktiv.

Mit "erste Server" meinst du den Windows Server, ja?
Diese Sicherheitsgründe verstehe ich nicht. Warum sollten Rekursion und vor allem Weiterleitung ein Sicherheitsproblem sein?

Das kann ich leider nicht bewerten. Ich bin in der Hardware Welt zuhause. Wir haben uns da auf das Urteil des Dienstleisters verlassen.
Angeblich können mit der Konfiguration dann über unseren DNS-Server DDoS Atacken auf andere Server gestartet werden.

Noch dazu, wenn das DNS nur intern läuft, was ebenfalls keinen Sinn macht, wenn dort die öffentliche IP des Exchange
hinterlegt ist. Wo sind denn die MX Einträge für deinen Exchange bzw. deine Domäne hinterlegt? Hierüber
erfahren andere MTAs, wohin Mails an deine Domäne abgeliefert werden sollen.

Und: War das vor der Umstellung auch so? Ich meine, war der DNS-Server jemails öffentlich erreichbar?

Nein, immer nur intern. Wobei dann wohl die erste Fragestellung falsch verstanden habe.
Die öffentlichen IP-Adressen des Exchange hat der RZ Bertreiber eintragen lassen.
Unser DNS-Server bedient nur die interne Seite und kennt daher nur die interne IP des Exchange.

Wenn dein Mail-Server direkt im Netz steht und als MTA fungiert, musst du dafür sorgen, dass das DNS stimmig ist inkl. MX
Eintrag:

C:\Users\lexa>nslookup
Standardserver: example-dns.de.lan
Address: 192.168.66.2

$ set type=mx
$ freenet.de
Server: example-dns.de.lan
Address: 192.168.66.2

Nicht autorisierende Antwort:
freenet.de MX preference = 1, mail exchanger = mx.freenet.de

mx.freenet.de internet address = 195.4.92.211
mx.freenet.de internet address = 195.4.92.212
[...]

$ quit

(Beispiel ist gekürzt)
Statt Freenet fragst du natürlich deine Domäne ab.

Alles korrekt gesetzt.

> > Könnte es sein, dass deine Windows/Outlook Clients mit deinem Exchange ab und an mal über dessen
öffentliche
> IP Adresse kommunizieren?
>
> Ja das kommt vor.

Ist das gewollt? Wie kommen sie überhaupt dorthin? Vertreter-Laptops?

ja das ist gewollt. Es gibt iPhone Nutzer und MA in einer Niederlassung ohne VPN Tunnel.

> Im DNS steht nur die öffentliche Adresse und auch der CNAME Eintrag ist richtig.

Wozu? Wie sollen ihn die Outlook Clients dann erreichen?
Die sollten ihn eigentlich über die interne 10.x.y.z ansprechen.

Ich mach hier mal 'nen break. Mir fehlen ein paar Meter Film bzw. Topologie. Zu meinem Verständnis:

1. Windows Server mit zwei IPs, eine private (10.0.9.136), eine öffentlich 85.197.x.x mit Default-GW, mit DNS Rolle aber nur
auf der privaten IP Adresse aktiv
2. Windows/Exchange Server mit zwei IPs, eine private (10.0.9.135), eine öffentlich 85.197.x.y mit Default-GW, als DNS
fungiert [1.]
3. Default-GW (Router) mit zwei IPs, eine private (10.0.9.254), eine öffentlich 85.197.x.z
4. Windows Client mit Outlook, eine private IP Adresse (10.0.9.100), als DNS fungiert der unter [1.] genannte

Stimmt das bis hier hin?

Ja.

Dann weiter:

Ein E-Mail geht vom Client 10.0.9.100 an Exchange, dessen Name über den DNS Server aufgelöst wird. Der Client
erfährt auf diesem Weg aber nur die öffentliche IP 85.197.x.y.

Nicht ganz. Siehe oben.

An dieser Stelle wäre Schluss, da der Server nicht erreichbar ist. Es sei denn, der Client hat einen Internet Zugang
(Default-GW) und erreicht den Exchange über seine öffentliche IP Adresse. Dann liefert er seine Mail über die
öffentliche IP des Exchange ein...?

Das erfährst du (hoffentlich) im Mail-Header der angelehnten Mails. Vielleicht hat er dort mal seine Class-C Adresse
verwendet?

Schon mal Danke für die bisherige Unterstüzung. Ich werde mir jetzt nochmal die Protokolle ansehen und schauen ob ich damit weiterkommen.

Ansonsten werde ich nochmal unseren Dienstleister kontaktieren und ihn zur DNS Änderung löchern.
Bis dahin hat ja eigentlich immer alles problemlos funktioniert.

Ansonsten werde ich nochmal unseren Dienstleister kontaktieren und ihn zur DNS Änderung löchern.

Okay.
Vergiss die Mail-Header nicht bzw. das SMTP Log.
Viel Erfolg.

Hallo.

Also ich habe mir die Logs und Mail Header angesehen. Sieht aber alles gut aus.

Dann habe ich die Rekursion und Weiterleitung auf dem DNS Server wieder aktiviert und seitdem sind die sporadischen Fehlermeldungen verschwunden.

Es tauchen jetzt allerdings im Abstand von mehreren Minuten im DNS Log Einträge mit folgendem Schema auf:

5501: Der DNS-Server hat ein fehlerhaftes Paket von 96.7.49.193 festgestellt. Die Paketverarbeitung überschreitet die Länge des Paketes. Die Ereignisdaten enthalten das DNS-Paket.

Ich habe zur Sicherheit nochmal überprüft ob der DNS Dienst über die öffentliche Seite erreichbar ist, aber da ist alles dicht.

Vielen Dank allen Helfenden!

Grüße
Chris

Die Anfrage wird sicher von deinen Clients erzeugt (Windows Update?). Für tiefere Analyse könnte man das DNS Logging entsprechend aktivieren.

Die IP gehört zu Akamei und die wiederum arbeiten mit Microsoft bzw. umgekehrt zusammen - MS nutzt Dienste von Akamei.

5001 muss nicht zwingend ein Fehler sein. Der DNS Server erhält eine Antwort, die auf mind. 2 Pakete verteilt ist. Erwartet hat er ein einziges Paket. Die Show geht aber trotzdem weiter.

Wenn du experimentierfreudig bist, kannst du folgenden RegHack anwenden:

http://dominik.strassernet.at/fehlercode-5501-dns

$ dnscmd /config /EnableEDNSProbes 0

Dann DNS Server restarten.

Die Änderung lässt sich mittels regedit einfach rückgängig machen, so dass es in deinem kleinen Netz keine irreparablen Nebeneffekte geben dürfte. Es könnten aber statt dessen 5004-Fehler kommen