Posts by douzer

Ah, jetzt stehts auch auf status.netcup.de

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.

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.

Quote from mainziman

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 .....

Quote from mainziman

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 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.

# 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"

Quote from mainziman

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.

Quote from killerbees19

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

Quote from mainziman

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 ....

Quote from mainziman

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 ....

Quote from Valkyrie

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.