Scheint zu stimmen: https://web.archive.org/web/2023052806…wiki/Nameserver
Ja, das sind die offiziellen Resolver von netcup. Verwendet werden dürfen sie in jedem Fall, jedenfalls aus den netcup-Netzwerk. Ob sie derzeit empfehlenswert sind weiss ich nicht. Vielleicht wird es mal wieder Zeit es zu probieren. Jedenfalls waren sie vor ein oder zwei Jahren nicht besonders empfehlenswert. Aber laut netcup wurde/wird daran gearbeitet. Ich würde also empfehlen, zumindest noch einen weiteren Resolver dazuzunehmen, für alle Fälle.
Zumindest für die Nürnberger Sever sind auch diese gut zu erreichen. Netcup hängt ja direkt am N-IX: https://www.n-ix.net/mehrwertdienste/
Also einer der IPv6-DNS-Server ist schonmal nicht zu erreichen:
```
# dig @2a03:4000:8000::fce6 netcup.de
;; communications error to 2a03:4000:8000::fce6#53: timed out
;; communications error to 2a03:4000:8000::fce6#53: timed out
;; communications error to 2a03:4000:8000::fce6#53: timed out
; <<>> DiG 9.18.24-1-Debian <<>> @2a03:4000:8000::fce6 netcup.de
; (1 server found)
;; global options: +cmd
;; no servers could be reached
```
Zusammen mit den Tatsachen, dass kein IPv6-Nameserver automatisch (per DHCP) konfiguriert wird und irgendwie der Eintrag über die Nameserver-Einstellungen aus dem offiziellen Wiki getilgt wurde, frage ich mich ob netcup vielleicht gar nicht will dass wir IPv6 verwenden?
wofür benötigst die einen IPv6 Nameserver? Man kann IPv6 auch über einen IPv4 DNS Server auflösen.
Ich will IPv4 irgendwann mal abschalten. Dann sind Dienste nur noch per IPv6 erreichbar.
heavenly : Bezüglich der Geschwindigkeit gibt es keinerlei Einschränkung, wenn man dnscrypt-proxy verwendet (sofern man nicht direkt DNS-Anfragen an die "üblichen Verdächtigen" senden mag). Mithilfe der Konfigurationsoptionen ipv4_servers und ipv6_servers (u. a.) lässt sich die gewünschte Steuerung problemlos realisieren.
Also einer der IPv6-DNS-Server ist schonmal nicht zu erreichen:
Also bei mir antworten
2a03:4000:0:1::e1e6 und
2a03:4000:8000::fce6 ganz brav auf Anfragen.
dig @2a03:4000:8000::fce6 netcup.de
; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> @2a03:4000:8000::fce6 netcup.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19635
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;netcup.de. IN A
;; ANSWER SECTION:
netcup.de. 228 IN A 46.38.224.30
;; Query time: 4 msec
;; SERVER: 2a03:4000:8000::fce6#53(2a03:4000:8000::fce6) (UDP)
;; WHEN: Thu Mar 21 07:23:10 CET 2024
;; MSG SIZE rcvd: 54Ich bin eigentlich auch gerade dabei, einen neuen Server zu konfigurieren und etwas perplex, dass das Netcup-Wiki hierzu scheinbar alle Informationen entfernt hat.
Früher habe ich die Anleitung aus dem Wiki benutzt, um eine statische IPv6-Adresse zu konfigurieren, heute gibt es nur noch eine Anleitung für ein zusätzliches IPv6-Subnetz.
Was ist denn die "offizielle" Konfiguration diesbezüglich? Wenn ich v4 und v6 statisch konfigurieren möchte, müsste ich ja vermutlich zwangsweise irgendwelche DNS-Server angeben. Oder soll/muss v4 auf DHCP bleiben? Einfach irgendwelche öffentlichen DNS-Server nutzen?
Ich bin eigentlich auch gerade dabei, einen neuen Server zu konfigurieren und etwas perplex, dass das Netcup-Wiki hierzu scheinbar alle Informationen entfernt hat.
Früher habe ich die Anleitung aus dem Wiki benutzt, um eine statische IPv6-Adresse zu konfigurieren, heute gibt es nur noch eine Anleitung für ein zusätzliches IPv6-Subnetz.
Was ist denn die "offizielle" Konfiguration diesbezüglich? Wenn ich v4 und v6 statisch konfigurieren möchte, müsste ich ja vermutlich zwangsweise irgendwelche DNS-Server angeben. Oder soll/muss v4 auf DHCP bleiben? Einfach irgendwelche öffentlichen DNS-Server nutzen?
Wenn du netcup DNS-Server/Resolver suchst, in den fertigen Images sieht das bei mir auf dem VPS ARM G11 in der /etc/resolv.conf so aus:
nameserver 46.38.225.230
nameserver 46.38.252.230
nameserver 2a03:4000:0:1::e1e6Die Frage ist, wie stabil die mittlerweile laufen. Ich habe es erst mal so gelassen und bisher nichts Auffallendes bemerkt. Sollte es da wieder größere Aussetzer geben, nehme ich meine zwei kleinen DNS-Server und installiere mir noch ein Unbound dazu auf den Server.
Was ist denn die "offizielle" Konfiguration diesbezüglich? Wenn ich v4 und v6 statisch konfigurieren möchte, müsste ich ja vermutlich zwangsweise irgendwelche DNS-Server angeben. Oder soll/muss v4 auf DHCP bleiben? Einfach irgendwelche öffentlichen DNS-Server nutzen?
Ich sehe da zwei naheliegende Möglichkeiten, wenn dnscrypt-proxy o. ä. wie oben erwähnt keine Alternative ist:
Wenn du netcup DNS-Server/Resolver suchst, in den fertigen Images sieht das bei mir auf dem VPS ARM G11 in der /etc/resolv.conf so aus:
Werden die per DHCP verteilt? Wenn ja, hab ich ja keine Garantie dafür, dass die DNS-Server in 2 Jahren überhaupt noch laufen, wenn ich das bei mir statisch hinterlege. Und natürlich wäre ich bei einem Ausfall dann vermutlich selbst schuld, da die ja nirgendwo offiziell dokumentiert sind.
Man bekommt so das Gefühl vermittelt, dass eigene Images nicht verwendet werden sollen.
Ticket aufmachen
Ja, hab ich mir auch schon überlegt.
Also nachdem ich gerade per Google nach "netcup resolver" gesucht und einen Forenbeitrag aus 2016 gefunden habe, wo die beiden IP4 Adressen jedenfalls schon mal drinstehen, scheinen die IPs der DNS-Server zumindest relativ langlebig zu sein.
Werden die per DHCP verteilt? Wenn ja, hab ich ja keine Garantie dafür, dass die DNS-Server in 2 Jahren überhaupt noch laufen, wenn ich das bei mir statisch hinterlege. Und natürlich wäre ich bei einem Ausfall dann vermutlich selbst schuld, da die ja nirgendwo offiziell dokumentiert sind.
Man bekommt so das Gefühl vermittelt, dass eigene Images nicht verwendet werden sollen.
Ja, hab ich mir auch schon überlegt.
Also nachdem ich gerade per Google nach "netcup resolver" gesucht und einen Forenbeitrag aus 2016 gefunden habe, wo die beiden IP4 Adressen jedenfalls schon mal drinstehen, scheinen die IPs der DNS-Server zumindest relativ langlebig zu sein.
Ich nutze die im DHCP-Lease des Installers geholten DNS-Server für meine statische Konfiguration seit 2015. Weggelaufen sind die mir noch nicht. 
Wäre natürlich trotzdem deutlich kundenfreundlicher, wenn die auch irgendwo dokumentiert wären 
Wäre natürlich trotzdem deutlich kundenfreundlicher, wenn die auch irgendwo dokumentiert wären
Ja, definitiv. Andererseits, besonders stabil waren sie zumindest vor einigen Jahren nicht. Ist jetzt sicher seit mehreren Jahren mein erster Server, der die wieder nutzt. Und auch das nur auf Bewährung 
.
Ja, definitiv. Andererseits, besonders stabil waren sie zumindest vor einigen Jahren nicht. Ist jetzt sicher seit mehreren Jahren mein erster Server, der die wieder nutzt. Und auch das nur auf Bewährung
Leider bewähren sich die netcup Resolver irgendwie nur zum Teil?!? 
Also auf dem oben erwähnten VPS 2000 ARM G11 habe ich keinen konkreten Grund zur Klage, auch auf meinem VPS 1000 G11 nicht. Aber auf den neuen Servern aus der BW24 (VPS 500 G11) und vom BF24 (RS 1000 G11), beide Standort Nürnberg (sagt man 
) habe ich jetzt genau die selben Probleme wie damals (tm) auf meinen ersten Servern mit Keyhelp. Eine Seite des Panels lädt mit einiger Verspätung. Ich weiss leider nicht, was genau da auf der Seite abgeht, ist halt kein Open Source 
. Damals habe ich lange gesucht nach einer Lösung und sie dann an zunächst nicht vermuteter Stelle gefunden, bei den netcup Resolvern. Da gab es in den Logs einige Meldungen von wegen "degraded". Hatte ich mir erst nicht viel dabei gedacht, immerhin liefen die anderen Server mit den selben Resolvern ganz normal und flüssig, nur zwei zickten rum. Obwohl das aus meiner Sicht eher dagegen sprach, dass die Resolver schuld waren, habe ich einfach mal testweise Google, Cloudflare & Co als Resolverein gesetzt. Und die Probleme waren sofort komplett weg.
Damals war das mit systemd-resolved konfiguriert, mittlerweile kommen die Resolver im Debian 12 minimal Image m.E. per DHCP und stehen direkt in der /etc/resolv.conf, die auch eine (immutable) Datei ist und kein Symlink wie früher. Der Effekt ist aber eins zu eins der selbe. Die älteren Server haben kein Problem mit den netcup Resolvern, die neuen aber exakt die selben Probleme wie damals. Nur dass die Statusabfragen und -anzeigen für die von Keyhelp verwalteten Dienste (HTTP, HTTPS, FTP, SSH, SMTP, POP3, IMAP, MariaDB) mittlerweile direkt im Dashboard angesiedelt sind. Diesmal ist also das Dashboard extrem langsam und wird erst mit Verzögerung von mehreren Sekunden angezeigt. Allerdings nur auf den neuen Servern. Und auch diesmal behebt der Austausch der Resolver das Problem sofort und vollständig.
Ansonsten wäre die Theorie aus meiner Sicht schnell fertig: Resolver haben eine Macke und sind eher langsam, gelegentlich auch bis zum Timeout der Verbindung. Für die Statusabfrage werden sie wahrscheinlich - aus welchen Gründen auch immer - häufiger gebraucht als auf den meisten anderen Seiten des Panels, deswegen die lange Verzögerung.
Austauch gegen andere, schnellere Resolver behebt das Problem. Ja, sogar schon das Tauschen der Reihenfolge der beiden IPv4 Resolver in der /etc/resolv.conf hilft. Auch den Teil kann ich mir leicht erklären: Alle neu ausgelieferten Server, die aus irgendwelchem netcup Images aufgebaut wurden, haben die Resolver in der selben Reihenfolge in der /etc/resolv.conf. Somit hat der erste deutlich mehr Arbeit als der zweite und ist überlastet. Durch den Tausch der Reihenfolge benutze ich den weniger ausgelasteten zweiten Server - im Gegensatz zu den meisten anderen Kunden.
Tja, aber ... Warum aber ist das nur bei den beiden neuen Servern ein Problem und nicht bei allen? Das ist so nicht zu erklären bzw es fehlt mir noch das entscheidende Puzzle-Teil. Eventuell das Subnetz der IP?
Immerhin sehe ich beim neuen Server gelegentlich so etwas:
~# dig amazon.de A
;; communications error to 46.38.225.230#53: timed outIm zweiten Versuch klappt es dann wohl und das Ergebnis wird korrekt ausgegeben. Wenn das jetzt z.B. einmal von 10 Queries passiert und die Seite verursacht ziemlich viele Queries, dann wird es eben langsam.
Leider hatte ich das jetzt auch bei einem neuen Server, sogar zweimal bei einer Query, also erst der dritte Versuch erfolgreich. Was bleibt noch als Erklärung? Liegt es an der abgefragten Domain? Dass es also bei manchen Domains länger braucht als bei anderen und beim einen Server grundsätzlich etwas länger? Keine Ahnung, irgendwie geht mir auch langsam die Lust aus. Da mache ich jetzt heute schon wieder mehrere Stunden dran rum. Andere Resolver nehmen (oder jedenfalls nicht den 46.38.225.230) , die Sache abhaken und zu den x-Files packen? Darauf wird es dann wohl hinauslaufen. Wird Zeit, meine eigenen Resolver vernünftig abzusichern, damit ich sie sicher benutzen kann. Mal sehen über Weihnachten.
Immerhin sehe ich beim neuen Server gelegentlich so etwas:
Ich kann bestätigen, dass 46.38.225.230 gerade echt schlecht performt:
dig google.com @46.38.225.230
;; communications error to 46.38.225.230#53: timed out
; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> google.com @46.38.225.230
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60731
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 295 IN A 142.250.186.174
;; Query time: 4300 msec
;; SERVER: 46.38.225.230#53(46.38.225.230) (UDP)
;; WHEN: Thu Dec 12 13:32:51 CET 2024
;; MSG SIZE rcvd: 55Erst ein Timeout und dann über 4 Sekunden. Und dabei ist's egal von welchem Server ich aus teste. Im Rettungssystem sieht's genau so aus.
