Handelsregister.de nicht aufrufbar
Hallo,
ist da ein 2-3 Jahre altes Problem wieder da?
Hatte damalig scheinbar mit IPv6 oder statischer IPv4 zu tun. (oder gesperrten Netzbereichen)
https://www.borncity.com/blog/2021/06/22/handelsregister-de-nicht-ber-al ...
C:\Users\rechner07>tracert handelsregister.de
Routenverfolgung zu handelsregister.de [93.184.141.237]
über maximal 30 Hops:
ist da ein 2-3 Jahre altes Problem wieder da?
Hatte damalig scheinbar mit IPv6 oder statischer IPv4 zu tun. (oder gesperrten Netzbereichen)
https://www.borncity.com/blog/2021/06/22/handelsregister-de-nicht-ber-al ...
C:\Users\rechner07>tracert handelsregister.de
Routenverfolgung zu handelsregister.de [93.184.141.237]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms 192.168.99.1
2 <1 ms <1 ms <1 ms 192.168.2.1
3 19 ms 27 ms 30 ms 62.156.244.35
4 20 ms 19 ms 19 ms 62.156.247.106
5 26 ms 26 ms 25 ms d-ed6-i.D.DE.NET.DTAG.DE [217.5.119.74]
6 27 ms 27 ms 27 ms 193.159.165.115
7 30 ms 30 ms 30 ms cr-han3-if1-1-20-1-0.x-win.dfn.de [188.1.145.209]
8 * 34 ms 34 ms cr-fra3-iflag6-0.x-win.dfn.de [188.1.145.197]
9 36 ms 36 ms 36 ms kr-ldshag3-0.x-win.dfn.de [188.1.238.226]
10 40 ms 40 ms 40 ms 193.174.255.25
11 * * * Zeitüberschreitung der Anforderung.
12 * * * Zeitüberschreitung der Anforderung.
13 * * * Zeitüberschreitung der Anforderung.
14 * * * Zeitüberschreitung der Anforderung.
15 * * * Zeitüberschreitung der Anforderung.
16 * *
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672546
Url: https://administrator.de/forum/handelsregister-de-nicht-aufrufbar-672546.html
Ausgedruckt am: 24.04.2025 um 13:04 Uhr
16 Kommentare
Neuester Kommentar
Moin,
bei mir und auch hier
https://onlineornot.com/website-down-checker?requestId=7ShX8f3TjKdGgGgFe ...
kein Problem beim Aufrufen der Webseite. Tracert sieht jedoch ähnlich aus
Gruß
Edit: getestet mit
Netcologne DSL
Telekom DSL
Telekom Mobil
Vodafone Mobil
klappt überall
bei mir und auch hier
https://onlineornot.com/website-down-checker?requestId=7ShX8f3TjKdGgGgFe ...
kein Problem beim Aufrufen der Webseite. Tracert sieht jedoch ähnlich aus
1 <1 ms <1 ms 1 ms fritz.box [10.0.0.1]
2 6 ms 5 ms 5 ms bras-vc5.netcologne.de [195.14.226.181]
3 6 ms 5 ms 5 ms 89.1.86.101
4 8 ms 6 ms 5 ms bdr-sto1-ae1.netcologne.de [81.173.192.114]
5 9 ms 8 ms 12 ms cr-fra3-iflag-18-680.x-win.dfn.de [80.81.192.222]
6 14 ms 13 ms 12 ms kr-ldshag3-0.x-win.dfn.de [188.1.238.226]
7 14 ms 13 ms 13 ms 193.174.255.25
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11Gruß
Edit: getestet mit
Netcologne DSL
Telekom DSL
Telekom Mobil
Vodafone Mobil
klappt überall
Das geht bei mir auch auf die Bretter.
Technischer Ansprechpartner laut WHOIS ist LVN10-RIPE. Da kannst du eine E-Mail hin schreiben und dich beschweren. Wenn du da auch nach den Feiertagen keine Antwort bekommst, kannst du das telefonisch an MB9075-RIPE esaklieren und mal nachfragen, der ist als Technischer Kontakt für LVN10 eingetragen.
es könnte sein das sie die hinter ihrer Firewall liegende Infrastruktur schützen wollen und den ICMP Echo in der Firewall blockiert haben.
EDIT:
im OP der 10. Ping bzw. hop ist scheinbar die backend Adresse von IT.NRW also ist sehr stark anzunehmen das dieser nicht antwortende tracert aka. ping gewollt ist
EDIT:
im OP der 10. Ping bzw. hop ist scheinbar die backend Adresse von IT.NRW also ist sehr stark anzunehmen das dieser nicht antwortende tracert aka. ping gewollt ist
1
und den ICMP Echo in der Firewall blockiert haben.
Das ist auch der Grund warum es zu den Timeouts / Zeitüberschreitungen kommt. Wäre das Winblows bordeigene Traceroute etwas intelligenter wie z.B. das unixoide Traceroute was man per Flag anweisen kann UDP Datagramme zu nutzen statt ICMP Echos (bzw. das per Default tut) würden die auch nicht in den Providerfiltern mit einem Timeout hängenbleiben.Es wäre also deutlich sinnvoller das Winblows eigene pathping zu verwenden dem man zur Not einen UDP oder TCP Port mitgibt (80 o. 443 z.B.) um solche Filter zu umgehen. Gewusst wie...
2
Zitat von @ManuManu2021:
Hallo,
ist da ein 2-3 Jahre altes Problem wieder da?
Hatte damalig scheinbar mit IPv6 oder statischer IPv4 zu tun. (oder gesperrten Netzbereichen)
Hallo,
ist da ein 2-3 Jahre altes Problem wieder da?
Hatte damalig scheinbar mit IPv6 oder statischer IPv4 zu tun. (oder gesperrten Netzbereichen)
Salut,
habe hier am Vodafone Kabel keine Probleme mit der Seite.
Grüße
ToWa
Ganz vergessen meine Senf auch dazuzugegeben:
Am 19.4 um 12.00 Uhr ging bei mir http://handelsregister.de auch ohne Probleme und geht immer noch ohne Probleme. Wird halt auf https://www.handelsregister.de/rp_web/welcome.xhtml umgeleitet. Vielleicht blockt Dein Malwareschutz die Umleitung.
lks
Am 19.4 um 12.00 Uhr ging bei mir http://handelsregister.de auch ohne Probleme und geht immer noch ohne Probleme. Wird halt auf https://www.handelsregister.de/rp_web/welcome.xhtml umgeleitet. Vielleicht blockt Dein Malwareschutz die Umleitung.
lks
Zitat von @Lochkartenstanzer:
Am 19.4 um 12.00 Uhr ging bei mir http://handeslregister.de auch ohne Probleme
Am 19.4 um 12.00 Uhr ging bei mir http://handeslregister.de auch ohne Probleme
Achtung Domain-Parking Typo
.1Zitat von @BiberMan:
Achtung Domain-Parking Typo handeslregister.
Zitat von @Lochkartenstanzer:
Am 19.4 um 12.00 Uhr ging bei mir http://handeslregister.de auch ohne Probleme
Am 19.4 um 12.00 Uhr ging bei mir http://handeslregister.de auch ohne Probleme
Achtung Domain-Parking Typo
handeslregister.Danke für den Hinweis. Ist korrigiert. War halt ein typischer lks-Bachstubendreher
lks
Im Watchguard Traffic Log ist kein DENY. (aktuell nur Std. Lizenz d.h. kein webblocker o.ä.)
Watchguard hat teshalber wegen dem Problem für den Test-PC: die DEFAULT ANY OUT Policy.
Im TRUSTED ETH stehen 8.8.8.8 und der lokale DC.
Vor der Watchguard ist BINTEC 192.168.2.254 für Interneteinwahl (und Panasonic v. Chr.)
Hab am User PC LAN-IP: 192.168.33.33 getestet. (Virenscanner wurde deaktiviert) (und am DC)
nächste schritte.
- somit also in der BINTEC BOX nach dem Log gucken. (folgt)
- ggf. temporär mit dynamischer IP probieren + feste IP wechseln
- IT NRW kontaktieren. (ripe...)
Watchguard hat teshalber wegen dem Problem für den Test-PC: die DEFAULT ANY OUT Policy.
Im TRUSTED ETH stehen 8.8.8.8 und der lokale DC.
Vor der Watchguard ist BINTEC 192.168.2.254 für Interneteinwahl (und Panasonic v. Chr.)
Hab am User PC LAN-IP: 192.168.33.33 getestet. (Virenscanner wurde deaktiviert) (und am DC)
nächste schritte.
- somit also in der BINTEC BOX nach dem Log gucken. (folgt)
- ggf. temporär mit dynamischer IP probieren + feste IP wechseln
- IT NRW kontaktieren. (ripe...)
2025-04-20 12:37:04 Allow 192.168.33.33 93.184.141.237 http/tcp 53621 80 Trusted TELEKOM Allowed 52 127 (Outgoing-00) proc_id="firewall" rc="100" msg_id="3000-0148" src_ip_nat="192.168.2.254" tcp_info="offset 8 S 62379406 win 61690"
2025-04-20 12:37:05 Allow 192.168.33.33 93.184.141.237 http/tcp 53622 80 Trusted TELEKOM Allowed 52 127 (Outgoing-00) proc_id="firewall" rc="100" msg_id="3000-0148" src_ip_nat="192.168.2.254" tcp_info="offset 8 S 2327413773 win 61690"
2025-04-20 12:37:06 Allow 192.168.33.33 93.184.141.237 http/tcp 53621 80 Trusted TELEKOM Allowed 52 127 (Outgoing-00) proc_id="firewall" rc="100" msg_id="3000-0148" src_ip_nat="192.168.2.254" tcp_info="offset 8 S 62379406 win 61690"
2025-04-20 12:37:06 Allow 192.168.33.33 93.184.141.237 http/tcp 53622 80 Trusted TELEKOM Allowed 52 127 (Outgoing-00) proc_id="firewall" rc="100" msg_id="3000-0148" src_ip_nat="192.168.2.254" tcp_info="offset 8 S 2327413773 win 61690"
2025-04-20 12:37:26 Allow 192.168.33.33 93.184.141.237 https/tcp 53637 443 Trusted TELEKOM Allowed 52 127 (Outgoing-00) proc_id="firewall" rc="100" msg_id="3000-0148" src_ip_nat="192.168.2.254" tcp_info="offset 8 S 54198519 win 61690"
2025-04-20 12:37:26 Allow 192.168.33.33 93.184.141.237 https/tcp 53639 443 Trusted TELEKOM Allowed 52 127 (Outgoing-00) proc_id="firewall" rc="100" msg_id="3000-0148" src_ip_nat="192.168.2.254" tcp_info="offset 8 S 268696273 win 61690"
2025-04-20 12:37:27 Allow 192.168.33.33 93.184.141.237 https/tcp 53637 443 Trusted TELEKOM Allowed 52 127 (Outgoing-00) proc_id="firewall" rc="100" msg_id="3000-0148" src_ip_nat="192.168.2.254" tcp_info="offset 8 S 54198519 win 61690"
2025-04-20 12:37:27 Allow 192.168.33.33 93.184.141.237 https/tcp 53639 443 Trusted TELEKOM Allowed 52 127 (Outgoing-00) proc_id="firewall" rc="100" msg_id="3000-0148" src_ip_nat="192.168.2.254" tcp_info="offset 8 S 268696273 win 61690"
2025-04-20 12:37:42 Allow 192.168.33.33 93.184.141.237 echo-request/icmp Trusted TELEKOM Allowed 60 127 (Ping-00) proc_id="firewall" rc="100" msg_id="3000-0148" src_ip_nat="192.168.2.254" type="8"
2025-04-20 12:37:47 Allow 192.168.33.33 93.184.141.237 echo-request/icmp Trusted TELEKOM Allowed 60 127 (Ping-00) proc_id="firewall" rc="100" msg_id="3000-0148" src_ip_nat="192.168.2.254" type="8"
2025-04-20 12:37:52 Allow 192.168.33.33 93.184.141.237 echo-request/icmp Trusted TELEKOM Allowed 60 127 (Ping-00) proc_id="firewall" rc="100" msg_id="3000-0148" src_ip_nat="192.168.2.254" type="8"
2025-04-20 12:37:57 Allow 192.168.33.33 93.184.141.237 echo-request/icmp Trusted TELEKOM Allowed 60 127 (Ping-00) proc_id="firewall" rc="100" msg_id="3000-0148" src_ip_nat="192.168.2.254" type="8" Im TRUSTED ETH stehen 8.8.8.8 und der lokale DC.
Hoffentlich nicht in der Reihenfolge?! 
Nichtmal mehr Dummies nutzen heute mehr Google Schnüffel DNS die deine Internet Profile offen an Dritte vermarkten. Verantwortungsvoller Datenschutz eines Admins sieht sicher anders aus. Ganz besonders in Firmennetzen."fremde" Nameserver wie der Google DNS haben in einer Produktivumgebung nichts zu suchen. Für Debugging und Tests kann man den zwar ausnahmsweise nutzen, aber ansonsten ist das nur ein Datenleck.
lks
ok danke ist korrigiert, war sekundär DNS.
Könnte sein, mal angenommen der lokale Virenscanner hätte VPN inkl. dann könnte man damit kurz mal testen.
Könnte sein, mal angenommen der lokale Virenscanner hätte VPN inkl. dann könnte man damit kurz mal testen.
Zitat von @LordGurke:
Technischer Ansprechpartner laut WHOIS ist LVN10-RIPE. Da kannst du eine E-Mail hin schreiben und dich beschweren. Wenn du da auch nach den Feiertagen keine Antwort bekommst, kannst du das telefonisch an MB9075-RIPE esaklieren und mal nachfragen, der ist als Technischer Kontakt für LVN10 eingetragen.
Technischer Ansprechpartner laut WHOIS ist LVN10-RIPE. Da kannst du eine E-Mail hin schreiben und dich beschweren. Wenn du da auch nach den Feiertagen keine Antwort bekommst, kannst du das telefonisch an MB9075-RIPE esaklieren und mal nachfragen, der ist als Technischer Kontakt für LVN10 eingetragen.
https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=MB9075-RIP ...
danke - wie hast du LVN10 gefunden. Hab ich auf dieser Seite nicht entdeckt:
https://webwhois.denic.de/?lang=de&query=handelsregister.de
Wie macht man den look-up, über die SuFu?
https://apps.db.ripe.net/db-web-ui/fulltextsearch
Anders gesagt:
Den technischen Ansprechpartner einer Domain kann man weiterhin nicht ermitteln.
Man kann nur den Verantwortlichen des Netzbereichs aka XXXXXXXX darüber finden nehme ich an.
Ich habe es an der IP festgemacht, denn da die Namensauflösung bei dir ja funktioniert, ist es kein Problem, was mit der Domain sondern mit Routing oder Firewalls zu tun hat.
Nachtrag, der Vollständigkeit halber: Wenn man den Zonemaster einer Domain erreichen will weil die nicht anständig auflöst, kann man einfach den passenden SOA ermitteln, indem man sich durch den DNS-Baum hangelt:
Der SOA ganz unten für handelsregister.de enthält als zweites Feld "webhosting.it.nrw.de." – hier muss der erste Punkt von links durch ein @ ersetzt werden, das ist dann die E-Mail-Adresse des Zonemasters.
Der kann aber im Zweifel nichts für Firewallregeln, ist eventuell sogar ein Dritt-Anbieter, deshalb wendet man sich primär bei Routing- oder Firewallproblemen an die Tech-Contacts aus der IP-Adresse.
$ dig +short www.handelsregister.de. ANY
93.184.141.237
93.184.141.239
$ whois -r -T inetnum 93.184.141.239
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See https://docs.db.ripe.net/terms-conditions.html
% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '93.184.141.0 - 93.184.143.255'
% Abuse contact for '93.184.141.0 - 93.184.143.255' is '*********@*********
inetnum: 93.184.141.0 - 93.184.143.255
netname: IT-NRW-NET
remarks: INFRA-AW
descr: Information und Technik NRW
country: DE
admin-c: LVN10-RIPE
tech-c: LVN10-RIPE
status: ASSIGNED PA
mnt-by: LDS_NRW-MNT
created: 2009-01-08T17:10:11Z
last-modified: 2025-03-28T09:50:06Z
source: RIPE
% This query was served by the RIPE Database Query Service version 1.117 (BUSA)Nachtrag, der Vollständigkeit halber: Wenn man den Zonemaster einer Domain erreichen will weil die nicht anständig auflöst, kann man einfach den passenden SOA ermitteln, indem man sich durch den DNS-Baum hangelt:
$ dig +trace -t SOA handelsregister.de.
; <<>> DiG 9.20.5 <<>> +trace -t SOA handelsregister.de.
;; global options: +cmd
. 518400 IN NS b.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS m.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS l.root-servers.net.
;; Received 1137 bytes from 2a02::xx#53(2a02::xx) in 0 ms
de. 172800 IN NS a.nic.de.
de. 172800 IN NS f.nic.de.
de. 172800 IN NS l.de.net.
de. 172800 IN NS n.de.net.
de. 172800 IN NS s.de.net.
de. 172800 IN NS z.nic.de.
;; Received 752 bytes from 2001:500:2d::d#53(d.root-servers.net) in 6 ms
handelsregister.de. 86400 IN NS a.it.nrw.
handelsregister.de. 86400 IN NS b.nrw.de.
handelsregister.de. 86400 IN NS c.nrw.de.
handelsregister.de. 86400 IN NS dns.globvill.de.
;; Received 695 bytes from 194.246.96.1#53(z.nic.de) in 3 ms
handelsregister.de. 14400 IN SOA a.it.nrw. webhosting.it.nrw.de. 2025032501 43200 7200 1814400 1200
;; Received 109 bytes from 212.20.191.2#53(dns.globvill.de) in 0 msDer SOA ganz unten für handelsregister.de enthält als zweites Feld "webhosting.it.nrw.de." – hier muss der erste Punkt von links durch ein @ ersetzt werden, das ist dann die E-Mail-Adresse des Zonemasters.
Der kann aber im Zweifel nichts für Firewallregeln, ist eventuell sogar ein Dritt-Anbieter, deshalb wendet man sich primär bei Routing- oder Firewallproblemen an die Tech-Contacts aus der IP-Adresse.
ok, danke für die Zonemaster Erläuterung, bzw. Tech-Contact von IPs.
Es funktioniert wieder - es wurde die feste öffentliche IP am dortigen Standort gewechselt.
(á la minute von der Hotline) Telekom VDSL Anschlüsse sind da ziemlich robust.
eher unwahrscheinliche Ursache: Der Standort hat kein Mailserver, alte IP: : The IP address xxx.xxx.xxxx is not currently listed as "poor" on the Barracuda Reputation System. Quelle: https://bgp.he.net/ip
Es funktioniert wieder - es wurde die feste öffentliche IP am dortigen Standort gewechselt.
(á la minute von der Hotline) Telekom VDSL Anschlüsse sind da ziemlich robust.
eher unwahrscheinliche Ursache: Der Standort hat kein Mailserver, alte IP: : The IP address xxx.xxx.xxxx is not currently listed as "poor" on the Barracuda Reputation System. Quelle: https://bgp.he.net/ip
