Ah, jetzt stehts auch auf status.netcup.de
Posts by douzer
-
-
Ist am SCP was kaputt? Hatte vorhin versucht einen meiner Server zu gestartet und hatte noch kurz Zugriff über die KVM Konsole und seitdem ist Feierabend.
Kann mich am SCP nicht mehr per Auto-Login anmelden, etc.
-
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.
QuoteEs 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.
-
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 .....
-
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
Code
Display More$ whois 2001:470:6f:15a::1 % IANA WHOIS server % for more information on IANA, visit http://www.iana.org % This query returned 1 object inet6num: 2001:400:0:0:0:0:0:0/23 organisation: ARIN status: ALLOCATED whois: whois.arin.net changed: 1999-07-01 source: IANA # whois.arin.net NetRange: 2001:470:: - 2001:470:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF CIDR: 2001:470::/32 NetName: HURRICANE-IPV6 NetHandle: NET6-2001-470-1 Parent: ARIN-001 (NET6-2001-400-0) NetType: Direct Allocation OriginAS: Organization: Hurricane Electric LLC (HURC) RegDate: 2001-03-22 Updated: 2012-02-24 Ref: https://rdap.arin.net/registry/ip/2001:470:: OrgName: Hurricane Electric LLC OrgId: HURC Address: 760 Mission Court City: Fremont StateProv: CA PostalCode: 94539 Country: US RegDate: Updated: 2018-02-09 Ref: https://rdap.arin.net/registry/entity/HURC ReferralServer: rwhois://rwhois.he.net:4321 OrgAbuseHandle: ABUSE1036-ARIN OrgAbuseName: Abuse Department OrgAbusePhone: +1-510-580-4100 OrgAbuseEmail: abuse@he.net OrgAbuseRef: https://rdap.arin.net/registry/entity/ABUSE1036-ARIN OrgTechHandle: ZH17-ARIN OrgTechName: Hurricane Electric OrgTechPhone: +1-510-580-4100 OrgTechEmail: hostmaster@he.net OrgTechRef: https://rdap.arin.net/registry/entity/ZH17-ARIN RAbuseHandle: ABUSE1036-ARIN RAbuseName: Abuse Department RAbusePhone: +1-510-580-4100 RAbuseEmail: abuse@he.net RAbuseRef: https://rdap.arin.net/registry/entity/ABUSE1036-ARIN RNOCHandle: ZH17-ARIN RNOCName: Hurricane Electric RNOCPhone: +1-510-580-4100 RNOCEmail: hostmaster@he.net RNOCRef: https://rdap.arin.net/registry/entity/ZH17-ARIN RTechHandle: ZH17-ARIN RTechName: Hurricane Electric RTechPhone: +1-510-580-4100 RTechEmail: hostmaster@he.net RTechRef: https://rdap.arin.net/registry/entity/ZH17-ARIN
whois auf einem aktuellen Debian, führt den Request gegen den Referal weiter.
Code
Display More# whois 2001:470:6f:15a::1 # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/resources/registry/whois/tou/ # # If you see inaccuracies in the results, please report at # https://www.arin.net/resources/registry/whois/inaccuracy_reporting/ # # Copyright 1997-2020, American Registry for Internet Numbers, Ltd. # NetRange: 2001:470:: - 2001:470:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF CIDR: 2001:470::/32 NetName: HURRICANE-IPV6 NetHandle: NET6-2001-470-1 Parent: ARIN-001 (NET6-2001-400-0) NetType: Direct Allocation OriginAS: Organization: Hurricane Electric LLC (HURC) RegDate: 2001-03-22 Updated: 2012-02-24 Ref: https://rdap.arin.net/registry/ip/2001:470:: OrgName: Hurricane Electric LLC OrgId: HURC Address: 760 Mission Court City: Fremont StateProv: CA PostalCode: 94539 Country: US RegDate: Updated: 2018-02-09 Ref: https://rdap.arin.net/registry/entity/HURC ReferralServer: rwhois://rwhois.he.net:4321 OrgAbuseHandle: ABUSE1036-ARIN OrgAbuseName: Abuse Department OrgAbusePhone: +1-510-580-4100 OrgAbuseEmail: abuse@he.net OrgAbuseRef: https://rdap.arin.net/registry/entity/ABUSE1036-ARIN OrgTechHandle: ZH17-ARIN OrgTechName: Hurricane Electric OrgTechPhone: +1-510-580-4100 OrgTechEmail: hostmaster@he.net OrgTechRef: https://rdap.arin.net/registry/entity/ZH17-ARIN RAbuseHandle: ABUSE1036-ARIN RAbuseName: Abuse Department RAbusePhone: +1-510-580-4100 RAbuseEmail: abuse@he.net RAbuseRef: https://rdap.arin.net/registry/entity/ABUSE1036-ARIN RNOCHandle: ZH17-ARIN RNOCName: Hurricane Electric RNOCPhone: +1-510-580-4100 RNOCEmail: hostmaster@he.net RNOCRef: https://rdap.arin.net/registry/entity/ZH17-ARIN RTechHandle: ZH17-ARIN RTechName: Hurricane Electric RTechPhone: +1-510-580-4100 RTechEmail: hostmaster@he.net RTechRef: https://rdap.arin.net/registry/entity/ZH17-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/resources/registry/whois/tou/ # # If you see inaccuracies in the results, please report at # https://www.arin.net/resources/registry/whois/inaccuracy_reporting/ # # Copyright 1997-2020, American Registry for Internet Numbers, Ltd. # Verweis auf rwhois.he.net:4321 gefunden. %rwhois V-1.5:0012b7:01 ops.he.net (HE-RWHOISd v:ec6e,m1:6333) network:ID;I:NET-2001:470:6F:15A::/64 network:Auth-Area:nets network:Class-Name:network network:Network-Name;I:NET-2001:470:6F:15A::/64 network:Parent;I:NET-2001:470:6F::/48 network:Parent;I:NET-2001:470::/32 network:IP-Network:2001:470:6f:15a::/64 network:Org-Contact;I:POC-TB-EMO2 network:Tech-Contact;I:POC-HE-NOC network:Abuse-Contact;I:POC-HE-ABUSE network:NOC-Contact;I:POC-HE-NOC network:Name-Server:dns00.ipv6help.de network:Name-Server:dns01.ipv6help.de network:Name-Server:dns02.ipv6help.de network:Name-Server:dns03.ipv6help.de network:Name-Server:dns04.ipv6help.de network:Created:20201127103821000 network:Updated:20201129023846000 contact:ID;I:POC-TB-EMO2 contact:Auth-Area:contacts contact:Class-Name:contact contact:Name:Private Customer - Hurricane Electric contact:Street-Address:Private Residence contact:City:Linz contact:Province:Upper Austria contact:Postal-Code:4020 contact:Country-Code:AT contact:Phone:+1-510-580-4100 contact:E-mail:hostmaster@he.net contact:Created:20201029024447000 contact:Updated:20201029024447000 contact:ID;I:POC-HE-NOC contact:Auth-Area:contacts contact:Class-Name:contact contact:Name:Network Operations Center contact:Company:Hurricane Electric contact:Street-Address:760 Mission Ct contact:City:Fremont contact:Province:CA contact:Postal-Code:94539 contact:Country-Code:US contact:Phone:+1-510-580-4100 contact:E-Mail:noc@he.net contact:Created:20100901200738000 contact:Updated:20100901200738000 contact:ID;I:POC-HE-ABUSE contact:Auth-Area:contacts contact:Class-Name:contact contact:Name:Abuse Department contact:Company:Hurricane Electric contact:Street-Address:760 Mission Ct contact:City:Fremont contact:Province:CA contact:Postal-Code:94539 contact:Country-Code:US contact:Phone:+1-510-580-4100 contact:E-Mail:abuse@he.net contact:Created:20100901200738000 contact:Updated:20100901200738000 contact:Comment:For email abuse (spam) only %ok
Soviel zum Thema, dass halt eben keine DNS Server im inet6num Objekt stehen - das zum Thema "am Hut haben"
-
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.
-
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
-
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 ....
-
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 ....
-
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.