Posts by gunnarh

Quote

"Inconsistent set of NS RRs (IP, NS host names)"

und Du denkst der Fehler trifft nicht zu, oder was konkret ist nun Deine Frage?

Dieser Inkonsistenz würde ich mal nachgehen, sie beseitigen, dann wird es auch mit der Delegation klappen. Tools wie dig sollten hierzu Deine Freunde sein.

Deine Frage betreffend Domain1.de oder Domain2.de verstehe ich nicht. Du konfigurierst einen Nameserver, ob der nun ns[1,2].domain1.de oder ns[1,2].domain2.de lautet bleibt Dir überlassen.

Es gibt kostenfreie nutzbare secondary Domain Server, z.B. von Hurricane Electric.

Wobei: DENIC kann nicht unterscheiden, ob die beiden IPs vom gleichen Host bedient werden. Sofern sie also zumindest aus unterschiedlichen Subnetzen stammen wird das in der Praxis vermutlich funktionieren.

Eventuell scheiterst Du ja an der Erstellung der in Deinem Fall nötigen Glue-Records?

Ich rate Dir Kapitel 2.1.2 und 2.1.3 der DENIC Doku durchzulesen: https://www.denic.de/fileadmin…cumentation/DENIC-23p.pdf

Nein, das hast du falsch verstanden.

Ich wiederhole mich daher:

Der Key-Signing-Key (Type 257 = KSK) hingegen signiert nur den DNSKEY-Eintrag des Zone-Signing-Keys und wird in der darüber liegenden Zone verankert.

Der Zone Signing Key (Type 256 = ZSK) signiert die ganze Zone, also jeden einzelnen Eintrag in der Zone.

Der ZSK wird vom KSK abgesichert, welcher wiederum in der .DE Zone verankert wird.

Der Hauptgrund dieser Best-Practice Vorgangsweise besteht darin, dass der Key-Rollover des ZSK bei diversen Nameserver-Implementierungen automatisch passiert bzw. man diesen i.d.R. eben gescriptet/automatisiert durchführt. Wohingegen der KSK ein statischer Key ist, der sich i.d.R. durch einen menschlichen, geplanten Eingriff ändert. Immerhin muss dazu dann ja eine API oder ein WebInterface "bedient werden", welcher den Key in der DE-Zone bei DENIC tauscht bzw. hier parallel zwei Keys als gültig hinterlegt und dann einen löscht (RollOver).

Nein, der 256er Key ist nicht bei DENIC zu hinterlegen.

Der Zone Signing Key (Type 256 = ZSK) signiert die ganze Zone, also jeden einzelnen Eintrag in der Zone.

Der Key-Signing-Key (Type 257 = KSK) hingegen signiert nur den DNSKEY-Eintrag des Zone-Signing-Keys und wird in der darüber liegenden Zone verankert.

Der derzeitige Zustand scheint mir korrekt zu sein.

Da ist in der DENIC Registry noch kein DNSKEY hinterlegt.

Du kannst das "live" prüfen ohne auf Nameserver-Updates warten zu müssen, indem Du mittels whois direkt Deine Domain abfrägst. Vergleiche mit einer DNSSEC registrierten Domain, bei Dir scheint da noch kein DNSKEY auf, bei bund.de beispielsweise schon.

Das Eintragen mittels NetCup-Webinterface in die DENIC-Registry sollte "live" funktionieren. Wirksam wird es dann (und somit mit DNSViz prüfbar) sobald die DE-Root-Server reloaden, wie oft das bei DE-Domains passiert weiß ich nicht auswändig (bei AT-Domains gibt es hierfür fixe Zeiten mit 2-Stunden Intervall).

Ja, ich betreibe eigene Nameserver und nutze DNSSEC - allerdings nicht mit einer DE-Domain, sondern mit ein paar .AT, .BIZ, .NET, .ORG Domains.

Woran konkret scheiterst Du denn?

Ganz grundsätzlich kann ich immer noch (obwohl mittlerweile ein paar Jahre alt) mein ausführliches HowTo aus dem Jahr 2015 empfehlen:

Sicherer E-Mail-Dienste-Anbieter (DNSSec & DANE)

Beispiele wie die WebOberfläche von NetCup beim Hinterlegen des KSK aussieht findest Du in meinem HowTo zwar nicht, aber im Kapitel 2.7 zeige ich das anhand von Screenshots mit zwei anderen Registraren. Die Vorgangsweise ist immer identisch - entweder man hinterlegt den PubKey oder den Hash davon (je nachdem wie der Provider bzw. die Registry das implementiert haben).

Wie das bei NetCup mit DE-Domains aussieht ist im NetCup-Wiki dokumentiert:

Domains CCP – netcup Wiki (netcup-wiki.de)

Dein Vorhaben erscheint (nicht nur mir, sondern wie KB19 ja bereits sagte) etwas abenteuerlich.

1. Deine Annahme du könntest Public-IPv4-Adressen oder Ranges eines Anbieters A so einfach bei einem anderen Anbieter B (Netcup) nutzen ist nicht so trivial umsetzbar. Dazu müssten die beiden Anbieter irgend eine Lösung bereitstellen, eine derartige Lösung kannst Du von einem (Massen-)hoster aber nicht erwarten. Welche Möglichkeit meint denn der Anbieter A der IPv4-Adressen hierfür offerieren zu können? Angenommen dieser würde sich hierzu bereiterklären bleibt immer noch die Frage ob Netcup Dir ebenfalls ein Angebot hierfür macht.

2. Das mittels Tunneling/VPN oder ähnlicher Technologien selbst zu lösen wäre theoretisch zwar möglich, bedarf aber jedenfalls auch Server bei beiden Anbietern - da stellt sich dann die Frage warum dein Proxy nicht gleich bei Anbieter A läuft.

3. Wie viele Proxy-Instanzen hast Du vor zu betreiben? Hast du dich schon mit einer Squid-Config die mehrere OUTGOING-IP-Adressen benutzt auseinandergesetzt? Bist du Dir sicher, dass das was du (vermutlich) erreichen möchtest so überhaupt realisiert werden kann? Nach welchem Regelwerk sollen denn die vielen outgoing IP-Adressen benutzt werden?

> es werden ca 22MB/s gelesen und 3MB/s geschrieben

Was liest da durchgängig? Irgend ein Job hängen geblieben?
Ergründe mal welcher Prozess das ist (z.B. mit iotop) und ob das einen plausiblen Grund hat.

Vom Support wurde mit hierzu noch mitgeteilt:

Quote

Unsere Entwicklungsabteilung ist informiert.

Ob und wann das Problem gelöst wird kann ich Ihnen jedoch momentan nicht sagen.

Für mich ist die Umstellung erledigt, wer eine .at Glue-Record-Änderung in nächster Zeit vor hat, sollte das evtl. vorab schon mal "probieren" solange der alte Server noch läuft, und nötigenfalls 1-2 Tage Zeit für eine allenfalls nötige Support-Ticket-Bearbeitung im geplanten Ablauf mit einkalkulieren.

Mir hat der Support den Eintrag soeben angepasst. Ich frage mal nach, ob das zugrunde liegende Problem auch einer Behebung zugeführt wird.

Danke eripek für deine Tests.

Mal sehen was mein geöffnetes Ticket beim Support für Erkenntnisse liefert. Dass da wohl irgend ein API/Script-Problem vorliegt scheint mir mittlerweile recht klar zu sein. Danke für den Tipp mit dem Workaround über den kurzfristigen Wechsel zu den Netcup Nameservern, wenn der Support keine kurzfristig andere Lösung hat werde ich das demnächst auch so versuchen.

Was Deinen Rant betreffend des Support angeht hast Du denke ich eine falsche Erwartungshaltung. Wenn Du zu einer Autovermietung gehst erwartest Du ja auch nicht, dass Dir diese bei Anmietung eines Fahrzeuges Fahrstunden gibt, um die Nutzung von Kupplung und Schaltgetriebe zu erlernen.

Der Bedarf ein fertiges Image zu nutzen ergibt sich offenbar deshalb, weil Du Dir damit erhoffst mit geringerer Expertise ans Ziel zu kommen.

Warum aber konkret willst du unbedingt LVM einsetzen? Welche Anforderungen sollen damit konkret bei euch gelöst werden?

Danke, nein - hilft mir nicht. Die Namensauflösung funktioniert dank Redundanz glücklicherweise ja noch.

Customer Control Panel, Domains => DNS,

ich betreibe meine Domain hitco.at seit Jahren mit drei Dual-Stack IPv4+IPv6 konfigurierten Nameservern.

Hierzu verwende ich Glue-Records.

Bedingt durch einen Systemwechsel änderte sich nun meine IPv4 Adresse des ns3.

Im Webinterface kann ich das zwar eingeben, und wird auch angenommen und im CCP angezeigt, es schlägt sich jedoch nicht in die Datenbank von nic.at durch. Der Zeitstempel des Whois-Records ändert sich, aber die IP-Adresse die im Whois aufscheint und nach einem Reload der nic.at Nameserver weiterhin als Glue-Record aufscheint ist die alte IP-Adresse 23.97.171.64 und nicht die neue 51.116.232.243

pasted-from-clipboard.png

Ein Mail an den Support blieb bislang noch ohne Reaktion.

Hat jemand von euch schon mal bei einer .at Domain die Glue-Records erfolgreich geändert?

Bevor nun Hinweise kommen, ich solle doch X-stunden warten: Das ist mir bewusst. Mir sind auch die Zeiten bekannt wann NIC.at ihre Nameserver reloaded. Der aktuelle Glue-Record schafft es aber nichteinmal in die NIC.at Whois-Datenbank, und das geht "live".

Als Workaround habe ich folgende Alternativen erfolglos versucht:

Versuch die ns3 IPv4 zu entfernen (leer zu lassen):

Fehler:
Die Nameserver konnten nicht aktualisiert werden. Domain update at registrar failed. Data management policy violation:
Frame contains no update operation

Versuch nur ns1 und ns2 anzugeben und ns3 vorläufig ganz wegzulassen (delete-Button):

Fehler:
Die Nameserver konnten nicht aktualisiert werden. Domain update at registrar failed. Command syntax error:
Parser error at line [0], column [1871]: Element \'{urn:ietf:params:xml:ns:domain-1.0}hostAddr\': This element is not expected. Expected is ( {urn:ietf:params:xml:ns:domain-1.0}hostAttr ).

Beide Fehlermeldungen erscheinen mir sachlich falsch. Ich vermute hier eher ein Problem mit der API die Netcup bei NIC.at benutzt.

Meine Nameserver antworten autoritativ mit allen drei Servern:

;; ANSWER SECTION:
hitco.at.               1200    IN      SOA     ns1.hitco.at. dns-admin.hitco.at. 2020102513 1200 600 2419200 1200

;; AUTHORITY SECTION:
hitco.at.               90000   IN      NS      ns3.hitco.at.
hitco.at.               90000   IN      NS      ns2.hitco.at.
hitco.at.               90000   IN      NS      ns1.hitco.at.

;; ADDITIONAL SECTION:
ns1.hitco.at.           1200    IN      A       37.120.174.149
ns2.hitco.at.           1200    IN      A       5.45.107.134
ns3.hitco.at.           1200    IN      A       51.116.232.243                           <<<<= Richtig
ns1.hitco.at.           1200    IN      AAAA    2a03:4000:6:71ec::cafe
ns2.hitco.at.           1200    IN      AAAA    2a03:4000:6:126c::affe
ns3.hitco.at.           1200    IN      AAAA    2001:470:1f0b:ee1::babe

Die nic.at Registry hat weiterhin die alte ns3-IPv4 gelistet:

domain:         hitco.at
registrar:      netcup GmbH ( https://nic.at/registrar/685 )
registrant:     GH11889873-NICAT
tech-c:         NG9618901-NICAT
nserver:        ns1.hitco.at
remarks:        2a03:4000:6:71ec::cafe
nserver:        ns1.hitco.at
remarks:        37.120.174.149
nserver:        ns2.hitco.at
remarks:        2a03:4000:6:126c::affe
nserver:        ns2.hitco.at
remarks:        5.45.107.134
nserver:        ns3.hitco.at
remarks:        2001:470:1f0b:ee1::babe
nserver:        ns3.hitco.at
remarks:        23.97.171.64                        <<<<= Falsch
changed:        20201025 14:15:23
DNSSEC:         Signed
DS key tag  1:  55255
algorithm   1:  8
digest type 1:  2
digest      1:  368431c5b526955803d14e4448d146bb99f3c5ee723cdd9e2b4c82c335c37284
source:         AT-DOM

Die nic.at Nameserver beinhalten weiterhin den falschen Glue-Record:

dig SOA hitco.at @d.ns.at.

...
;; AUTHORITY SECTION:
hitco.at.               10800   IN      NS      ns2.hitco.at.
hitco.at.               10800   IN      NS      ns1.hitco.at.
hitco.at.               10800   IN      NS      ns3.hitco.at.

;; ADDITIONAL SECTION:
ns3.hitco.at.           10800   IN      AAAA    2001:470:1f0b:ee1::babe
ns2.hitco.at.           10800   IN      AAAA    2a03:4000:6:126c::affe
ns1.hitco.at.           10800   IN      AAAA    2a03:4000:6:71ec::cafe
ns3.hitco.at.           10800   IN      A       23.97.171.64                            <<<<= Falsch
ns2.hitco.at.           10800   IN      A       5.45.107.134
ns1.hitco.at.           10800   IN      A       37.120.174.149

Let's Encrypt wechselt seine Intermediate-CA.

Wer seinen (SMTP-)Mailserver mit DANE / TLSA unter Verwendung der Let's Encrypt X3 CA gepinnt hat, sollte jetzt handeln und zumindest die R3-CA ergänzen:

https://community.letsencrypt.…ng-le-issuer-certs/134172

pasted-from-clipboard.png

Derzeit ist bei den meisten vermutlich nur die X3-CA in Verwendung, folgende TLSA-Records empfiehlt es sich zu ergänzen:

Falls jemand eine eigene CA mit ein paar S/MIME-Zertifikaten (für ein Team etc... Ende-zu-Ende verschlüsselter S/MIME Mail Austausch) erstellen möchte,

hatte da einen Anwendungsfall und habe daher was handliches gebastelt - vielleicht kann das ja jemand brauchen:

https://github.com/gunnarhaslinger/SMIME-OpenSSL-CA

Mein OwnCloud-Client nervt mich seit ein paar Wochen alle paar Minuten mit der Nachricht, dass mein OwnCloud 10.3.2 Server veraltet wäre und ich doch auf 10.4.1 upgraden soll. Das klappt allerdings nicht, weil 10.4 nicht mehr auf PHP7.0 lauffähig ist und ich mich bislang nicht überwinden konnte auf meiner Ubuntu 16.04 LTS Maschine eine neuere PHP-Version aus einem Fremd-Repo zu installieren.

Gut... Heute Regenwetter - dann mach ich das mal.

Eine Stunde später, PHP 7.4 mit allen Modulen die ich auch unter 7.0 genutzt habe läuft.

Ich will das OwnCloud-Update machen => und .... Fehlermeldung 7.4 wird nicht unterstütz.

Freilich könnte man die Systemanforderungen auch vorher lesen. Aber was solls... jetzt habe ich mir eine unstable Owncloud 10.5 Beta 2 draufgebügelt, auf PHP 7.3 downgraden tu ich mir jetzt auch nicht an wegen der paar Wochen bis OwnCloud 10.5 production stable ist.

Wie viele Stunden pro Monat soll diese Windows-VM denn eingeschaltet sein? Wenn da nur eine Banksoftware darauf läuft, dann ja eventuell nur wenige Stunden pro Monat?

Die Windows-10-VM wirst du bei Netcup soweit ich das beurteile leider nicht korrekt lizenzieren können. In der hauseigenen Cloud des Betriebssystemherstellers (Az...) ist das Windows-OS bereits in den Kosten für die VM-Laufzeit enthalten. Sofern die VM nur wenige Stunden pro Monat benötigt wird (z.b. nur 10% der Zeit des Monats läuft) und den Rest ausgeschaltet verbleibt, ist der Betrieb dort sogar günstiger als eine kleine VM hier den vollen Monat Laufzeit zu bezahlen. Und da bereits angesprochen wurde, dass es sinnvoll ist ein Windows hinter eine Firewall zu packen: Die VMs in der Cloud des Betriebssystemherstellers hängen standardmäßig hinter einem Load-Balancer der nur freigeschaltete Ports (z.B. RDP) weiterleitet. (Sorry dafür, dass ich hier ausnahmsweise nicht zu Netcup rate, aber Windows 10 und Netcup, das geht meiner Meinung nach rechtlich nicht sauber - daher sehe ich da, solange Netcup kein geeignetes Angebot ins Sortiment aufnimmt - keine andere Lösung).

Die Vorgehensweise einen "hidden DNS Master" zu betreiben ist - so wie du sie beschreibst - aus meiner Sicht korrekt. Sollte gültig sein. Wenn Du Bedenken hast, dann prüfe doch mal mit einem der vielen DNS-Zone-Checker Tools - ich verwende z.b. gerne den https://www.zonemaster.net/ Check.

Das Formular zum Hinterlegen deines DNSSEC Public-Keys findet sich direkt unterhalb der (von mir im Post darüber bereits gescreenshotteten) Nameserver-Einträge.