Posts by douzer

Hallo [netcup] Lars S.

ok, das wäre in meinem Fall kein Problem gewesen, die fehlerhaften Zonen zu belegen.

Es hatten aber einige Kunden, hier im Forum über unterschiedliche Effekte berichtet. Bei mir, z.B. wurde im CCP nichts als ungültig markiert und die im Ticket angemerkte Zone hatte eigentlich keine Änderungen in den letzten Wochen, dennoch wurde sie, Sonntag Abend, ich vermute jetzt mal aus der Support Antwort, durch Änderungen, welche nicht durch mich durchgeführt wurden, zu 100% beschädigt.

Quote

Es ist allerdings auch möglich, dass DNSSEC nicht korrekt arbeitet, wenn ungültige DNS-Records hinzugefügt werden. In dem Fall wird dies neben dem jeweiligen Record dargestellt. Dann kann keine DNSSEC-Signatur erfolgen. In dem Fall wird unser System aber automatisiert DNSSEC deaktivieren, damit die Auflösung eben nicht beeinträchtigt wird, und unser Hostmaster-Team wird informiert.

In meinem Fall, war die komplette Zone nicht mehr erreichbar. Im CCP war kein Hinweis, auf einen ungültigen DNS-Record. Es wurde auch, mindestens in den letzten vier Wochen, kein Record, der Zone hinzugefügt - bitte übermittelt mir, die Ticketnummer ist ja bekannt, den Record und die Ursache, die das Problem Sonntag Abend verursacht hat - DNSSec wurde hier nicht automatisiert deaktiviert und ich würde bitte gerne darüber informiert, wenn an meinen DNS Records, ohne mich, Änderungen durchgeführt werden! - dann brauch ich ja kein DNSSec mehr, wenn hier irgendwer nach belieben Records ändert !?! - man betrachte die Serial.

Bitte teile uns doch mit, was ungültige DNS-Records denn sein können, welche plötzlich komplette Zonen unbrauchbar machen.

Hi,

ok, dann nehm ich das mal als Bestätigung, dass das bekannte Problem gefixt ist und hab den SMIMEA Record wieder gesetzt.

Das Monitoring prüft die Records und wenns wieder kaputt ist, dann kann ich im Notfallticket auf diesen Thread verweisen?

Update: root-dns.netcup.net liefert jetzt für die Domain auch nichts mehr aus.

Update 2: Testweise Records angelegt, bzw. wieder gelöscht um die Replikation zu triggern - ohne Erfolg. Als ich jedoch den SMIMEA Record gelöscht habe, haben 5 Minuten später alle Nameserver wieder ausgeliefert.

[netcup] Felix P. das scheint ein generelles Problem eurer DNS Infrastruktur zu sein. Wieso wird hier nicht offiziell darüber informiert? Wieso steht dies nicht auf http://www.netcup-status.de ? Wieso deaktiviert ihr SMIMEA Records nicht generell, natürlich mit einer Info an alle betroffenen Kunden?

Bin mal gespannt, was der Support auf das Ticket von vorhin antwortet.

Weiteres Update second-dns.netcup.net & third-dns.netcup.net liefern für die Domain nun gar nichts mehr aus, das kann doch so nicht wahr sein!

So, bei mir hat es jetzt auch zugeschlagen - wieso auch immer, ist eine Subdomain, soviel hab ich bisher gefunden, DNSSec invalid.

"second-dns.netcup.net serial (2020111568) differs from root-dns.netcup.net serial (2020121369)"

Das zu Auswertung. Also zum einen scheint hier die Replikation nicht mehr zu funktionieren, bzw. Murks repliziert zu werden.

In der Zone ist auch ein SMIMEA Record hinterlegt.

Update: Nach deaktivieren von DNSSec werden die Records sofort wieder ausgeliefert.

netcup : Das kann doch jetzt langsam echt kein Zustand mehr sein. Wieso steht auf der Statusseite hierzu nichts?

Den Willen ntp.org zu unterstützen, finde ich lobenswert, aber ...

Dass der Pool für DE aber nur von ehrenamtlichen betrieben wird, sehe ich jedoch nicht ganz so - der relevante Teil, welche von NTPs beim Pool verwendet werden, sind Server von Service Providern, welches alle dedicated Server sind - was ein NTP auch sein sollte.

Auch sehe ich den Nutzen nicht darin, Unmengen von virtuellen Servern, dem Pool hinzuzufügen, sondern die physikalischen Ressourcen der ISPs eine genauere Zeit liefern zu lassen.

Erkläre das "flappging" hier mal bitte genauer - https://www.ntppool.org/zone/de

Die Genauigkeit erhöht sich, durch die Anzahl von Servern nämlich nicht zwingend.

Das einzige, was bei einem Reverse Lookup interessiert, ist der korrespondierende ip6.arpa - alles andere ist, wie einige vorhin schon geschrieben haben, Goodwill was ein Registrant einträgt - technisch interessieren nur die nserver Records im ip6.arpa.

mainziman wrote:

wo zum Henker siehst da was von inet6num?

Machst die Augen auf, Zeile 6 ist dein Freund - aber alles lesen, ist nicht so deine Sache, stimmt's

Wie bei nem BSD IPv6 zu konfigurieren ist, hat mit diesem Kontext nichts zu tun. Also keine Nebelkerzen werfen .....

mainziman wrote:

auf des wärst jetzt nicht gekommen ...

Nein, natürlich nicht. Dafür hab ich zum Glück dich, dass du mir über solche technischen Schwierigkeiten hinweg hilfts.

Aber mal zum Thema ohne dieses getrolle.

Unterschiedliche whois Clients verhalten sich hier unterschiedlich.

whois auf dem Mac folgt keinem Referal

whois auf einem aktuellen Debian, führt den Request gegen den Referal weiter.

Soviel zum Thema, dass halt eben keine DNS Server im inet6num Objekt stehen - das zum Thema "am Hut haben"

mainziman wrote:

hier passt es

whois 2001:470:6f:15a::1

bzw.

dig 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.5.1.0.f.6.0.0.0.7.4.0.1.0.0.2.ip6.arpa +trace ANY

Zeig mal bitte den gesamten Output, wo dort ein DNS Server steht (vom whois, nicht vim dig gegen den ip6.arpa) - ohne Output ist das immer so ein sinnfreies und zeitraubendes stochern im Dunkeln.

killerbees19 wrote:

Tethering?

Bzw. wer sagt, dass die SIM-Karte in einem Smartphone steckt?

Dann lässt sich das bestimmt entsprechend buchen.

Aber dass jedem Endgerät ein /64 zugeteilt werden soll, ist völliger Unsinn

mainziman wrote:

weil ein /64 die kleinste Einheit ist; und genaugenommen f. eine RFC-konformität

die Mglkt. von RFC 4941 gegeben sein muss;

und da fangt der Fisch so richtig an zu stinken, mit IPv4 hat der ISP mit einer IP alle

Heizflossen in AT angebunden, mit IPv6 brauchts dafür aber ein schlappes /40-Prefix'chen

Das stimmt für Delegationen an Routern, aber dein Mobiltelefon ist immer noch ein einfaches Endgerät, dem wohl eine Adresse reichen sollte.

Wenn du uns jetzt aber zeigst, dass du von deinem ISP kein eigenes Präfix bekommst, dann können wir drüber reden ....

mainziman wrote:

hätte auch der APIPA-Quark - dieser Unfug ist auf den Mist der IPv6-Pfuscher gewachsen - ebenfalls nie passieren dürfen ...

Da erklär doch jetzt mal bitte den Zusammenhang, mit entsprechenden Links, die das belegen ....

Valkyrie wrote:

Hab dann mal die Domain checken lassen, die man da eigentlich aufruft... Sagen wir mal so, die Fehler wundern mich jetzt nicht mehr

Vielleicht einfach mal den Dienstleister, fairerweise drauf hinweisen und auf die Antwort gespannt sein - so haben beide Seiten mal eine Chance

Unter den DNS Einstellungen den Type "NS" auswählen. Links Subdomain, recht Ziel.

Scheint sich vor ca. 30 Minuten in AS3356 stabilisiert zu haben.

Level3/CenturyLink scheint die Ursache zu sein.

Es scheint hier einiges aktuell betroffen zu sein. Cisco Duo meldete vorhin auch bereits Ausfälle, aufgrund eines großen ISPs.

douzer wrote:

Ich kann das nicht reproduzieren. Soeben auf meinem Mailserver geprüft und pro Apple Mail Client, einen TCP Sockel offen

Muß mich korrigieren, zwei pro Device.

DerRené wrote:

Zu viele Geräte/Verbindungen von deinem Heimnetz aus. Unterbinde doch mal an deinen Apple-Geräten testweise 24h* den Mailempfang im WLAN (oder, wie auch schon mehrfach vorgeschlagen, einen vernünftigen Mailclient auf den Applegeräten verwenden). ich kann mir gut vorstellen, dass sich Outlook und Thunderbird dann wieder erfolgreich verbinden können.

Ich kann das nicht reproduzieren. Soeben auf meinem Mailserver geprüft und pro Apple Mail Client, einen TCP Sockel offen

Olgsi wrote:

Ich glaube das Übel ist Outlook. Wenn ich es geschlossen lasse funktioniert alles. Stellt Outlook365 so viele Anfragen? Kann ich das reduzieren?

Würd für das sprechen, was ich bei Docvecot beobachte, dass Apple Mail keine Unmengen von Connections aufmacht.