Etherpad – kollaboratives Schreiben von Text

  1. User für Etherpad anlegen
  2. Node.js installieren
  3. installieren
  4.–%29 SSL aktivieren
  5. Admin Konto anlegen

  1. it clone git://
  2. Change into the new directory containing the cloned source code cd etherpad-lite

Now, run bin/ and open in your browser


How to disable SSH host key checking


Remote login using the SSH protocol is a frequent activity in today’s internet world. With the SSH protocol, the onus is on the SSH client to verify the identity of the host to which it is connecting. The host identify is established by its SSH host key. Typically, the host key is auto-created during initial SSH installation setup.

By default, the SSH client verifies the host key against a local file containing known, trustworthy machines. This provides protection against possible Man-In-The-Middle attacks. However, there are situations in which you want to bypass this verification step. This article explains how to disable host key checking using OpenSSH, a popular Free and Open-Source implementation of SSH.

When you login to a remote host for the first time, the remote host’s host key is most likely unknown to the SSH client. The default behavior is to ask the user to confirm the fingerprint of the host key.

If your answer is yes, the SSH client continues login, and stores the host key locally in the file~/.ssh/known_hosts. You only need to validate the host key the first time around: in subsequent logins, you will not be prompted to confirm it again.

Yet, from time to time, when you try to remote login to the same host from the same origin, you may be refused with the following warning message:

There are multiple possible reasons why the remote host key changed. A Man-in-the-Middle attack is only one possible reason. Other possible reasons include:

  • OpenSSH was re-installed on the remote host but, for whatever reason, the original host key was not restored.
  • The remote host was replaced legitimately by another machine.

If you are sure that this is harmless, you can use either 1 of 2 methods below to trick openSSH to let you login. But be warned that you have become vulnerable to man-in-the-middle attacks.

The first method is to remove the remote host from the ~/.ssh/known_hosts file. Note that the warning message already tells you the line number in the known_hosts file that corresponds to the target remote host. The offending line in the above example is line 3(„Offending key in /home/peter/.ssh/known_hosts:3“)

You can use the following one liner to remove that one line (line 3) from the file.

Note that with the above method, you will be prompted to confirm the host key fingerprint when you run ssh to login.

The second method uses two openSSH parameters:

    • StrictHostKeyCheckin, and
    • UserKnownHostsFile.

This method tricks SSH by configuring it to use an empty known_hosts file, and NOT to ask you to confirm the remote host identity key.

The UserKnownHostsFile parameter specifies the database file to use for storing the user host keys (default is ~/.ssh/known_hosts).

The /dev/null file is a special system device file that discards anything and everything written to it, and when used as the input file, returns End Of File immediately.

By configuring the null device file as the host key database, SSH is fooled into thinking that the SSH client has never connected to any SSH server before, and so will never run into a mismatched host key.

The parameter StrictHostKeyChecking specifies if SSH will automatically add new host keys to the host key database file. By setting it to no, the host key is automatically added, without user confirmation, for all first-time connection. Because of the null key database file, all connection is viewed as the first-time for any SSH server host. Therefore, the host key is automatically added to the host key database with no user confirmation. Writing the key to the /dev/null file discards the key and reports success.

Please refer to this excellent article about host keys and key checking.

By specifying the above 2 SSH options on the command line, you can bypass host key checking for that particular SSH login. If you want to bypass host key checking on a permanent basis, you need to specify those same options in the SSH configuration file.

You can edit the global SSH configuration file (/etc/ssh/ssh_config) if you want to make the changes permanent for all users.

If you want to target a particular user, modify the user-specific SSH configuration file (~/.ssh/config). The instructions below apply to both files.

Suppose you want to bypass key checking for a particular subnet (

Add the following lines to the beginning of the SSH configuration file.

Note that the configuration file should have a line like Host * followed by one or more parameter-value pairs. Host *means that it will match any host. Essentially, the parameters following Host *are the general defaults. Because the first matched value for each SSH parameter is used, you want to add the host-specific or subnet-specific parameters to the beginning of the file.

As a final word of caution, unless you know what you are doing, it is probably best to bypass key checking on a case by case basis, rather than making blanket permanent changes to the SSH configuration files.

If you make it this far in the article, you may find the following more recent ssh articles interesting:

Allow root ssh login with public key authentication
How to auto fill in ssh client parameters
One-liner to shutdown remote host
X11 Forwarding over SSH

How sendmail works


Outbound email :

1. MUA passes the email to sendmail , which creates in the /var/spool/mqueue (mail queue) directory two files that hold the message while sendmail processes it.
2. To create a unique filename for a particular piece of email, sendmail generates a random string and uses that string in filenames pertaining to the email.
3. The sendmail daemon stores the body of the message in a file named df (data file) followed by the generated string.
4. It stores the headers and other information in a file named qf (queue file) followed by the generated string.
5. If a delivery error occurs, sendmail creates a temporary copy of the message that it stores in a file whose name starts with tf (temporary file) and logs errors in a file whose name starts xf .
6. Once an email has been sent successfully, sendmail removes all files pertaining to that email from /var/spool/mqueue .

Incoming email :

1. By default, the MDA stores incoming messages in users‘ files in the mail spool directory, /var/spool/mail , in mbox format. Within this directory, each user has a mail file named with the user’s username. Mail remains in these files until it is collected, typically by an MUA. Once an MUA collects the mail from the mail spool, the MUA stores the mail as directed by the user, usually in the user ’s home directory hierarchy.

mbox versus maildir :

1. The mbox format stores all messages for a user in a single file. To prevent corruption, the file must be locked while a process is adding messages to or deleting messages from the file; you cannot delete a message at the same time the MTA is adding messages. A competing format, maildir , stores each message in a separate file. This format does not use locks, allowing an MUA to read and delete messages at the same time as new mail is delivered. In addition, the maildir format is better able to handle larger mailboxes

Mail logs :

# cat/var/log/maillog

Mar 3 16:25:33 MACHINENAME sendmail[7225]: i23GPXvm007224:
to=, ctladdr=
(0/0), delay=00:00:00, xdelay=00:00:00, mailer=local, pri=30514,
dsn=2.0.0, stat=Sent

Each log entry starts with a timestamp, the name of the system sending the email, the name of the mail server ( sendmail ), and a unique identification number. The address of the recipient follows the to= label and the address of the sender follows ctladdr= . Additional fields provide the name of the mailer and the time it took to send the message. If a message is sent correctly, the stat= label is followed by Sent .

Aliases and Forwarding :

Three files can forward email: .forward (page 634), aliases (discussed next ), and virtusertable (page 640). Table 20-1 on page 640 compares the three files.
Table 20-1. Comparison of forwarding techniques

.forward aliases virtusertable

Controlled by non root user root root

Forwards email
addressed to „non root user“ „Any real or virtual user on the local system“ „Any real or virtual user on any domain recognized by sendmail“

Order of precedence Third Second First


Most of the time when you send email, it goes to a specific person; the recipient, user@system , maps to a specific, real user on the specified system. Sometimes you may want email to go to a class of users and not to a specific recipient. Examples of classes of users include postmaster , webmaster , root , and tech_support . Different users may receive this email at different times or the email may be answered by a group of users. You can use the /etc/aliases file to map inbound addresses to local users, files, commands, and remote addresses.

Each line in /etc/aliases contains the name of a local pseudouser, followed by a colon , whitespace, and a comma-separated list of destinations. The default installation includes a number of aliases that redirect messages for certain pseudousers to root . These have the form

system: root

Sending messages to the root account is a good way of making them easy to review. However, because root ’s email is rarely checked, you may want to send copies to a real user. The following line forwards mail sent to abuse on the local system to root and alex :

abuse: root, alex

You can create simple mailing lists with this type of alias. For example, the following alias sends copies of all email sent to admin on the local system to several users, including Zach, who is on a different system:

admin: sam, helen, mark,

You can direct email to a file by specifying an absolute pathname in place of a destination address. The following alias, which is quite popular among less conscientious system administrators, redirects email sent to complaints to /dev/null where they disappear:

complaints: /dev/null

You can also send email to standard input of a command by preceding the command with a pipe character ( | ). This technique is commonly used with mailing list software such as Mailman. For each list it maintains, Mailman has entries, such as the following entry for mylist , in the aliases file:

mylist: „|/usr/lib/mailman/mail/mailman post mylist“


After you edit /etc/aliases , you must either run newaliases as root or restart sendmail to recreate the aliases.db file that sendmail reads.


You can use praliases to list aliases currently loaded by sendmail :

# /usr/sbin/praliases| head-5


Systemwide aliases are useful in many cases, but non root users cannot make or change them. Sometimes you may want to forward your own mail: Maybe you want mail from several systems to go to one address or perhaps you just want to forward your mail while you are working at another office for a week. The ~/.forward file allows ordinary users to forward their email.

Lines in a .forward file are the same as the right column of the aliases file explained previously: Destinations are listed one per line and can be a local user, a remote email address, a filename, or a command preceded by a pipe character ( | ).

Mail that you forward does not go to your local mailbox. If you want to forward mail and keep a copy in your local mailbox, you must specify your local username preceded by a backslash to prevent an infinite loop. The following example sends Sam’s email to himself on the local system and on the system at :

$ cat ~sam/.forward

Related Programs


The sendmail package includes several programs. The primary program, sendmail , reads from standard input and sends an email to the recipient specified by its argument. You can use sendmail from the command line to check that the mail delivery system is working and to email the output of scripts.


The mailq utility displays the status of the outgoing mail queue and normally reports there are no messages in the queue. Messages in the queue usually indicate a problem with the local or remote sendmail configuration or a network problem.

# /usr/bin/mailq
/var/spool/mqueue is empty
Total requests: 0


The mailstats utility reports on the number and sizes of messages sendmail has sent and received since the date it displays on the first line:

# /usr/sbin/mailstats
Statistics from Sat Dec 24 16:02:34 2005
M msgsfr bytes_from msgsto bytes_to msgsrej msgsdis Mailer
0 0 0K 17181 103904K 0 0 prog
4 368386 4216614K 136456 1568314K 20616 0 esmtp
9 226151 26101362K 479025 12776528K 4590 0 local
T 594537 30317976K 632662 14448746K 25206 0
C 694638 499700 146185

In the preceding output, each mailer is identified by the first column, which displays the mailer number, and by the last column, which displays the name of the mailer. The second through fifth columns display the number and total sizes of messages sent and received by the mailer. The sixth and seventh columns display the number of messages rejected and discarded respectively. The row that starts with T lists the column totals, and the row that starts with C lists the number of TCP connections.

Setting Up a Backup Server

You can set up a backup mail server to hold email when the primary mail server experiences problems. For maximum coverage, the backup server should be on a different connection to the Internet from the primary server.

Setting up a backup server is easy. Just remove the leading dnl from the following line in the backup mail server’s file:

dnl FEATURE(‚relay_based_on_MX‘)dnl

DNS MX records (page 726) specify where email for a domain should be sent. You can have multiple MX records for a domain, each pointing to a different mail server. When a domain has multiple MX records, each record usually has a different priority; the priority is specified by a two-digit number, where lower numbers specify higher priorities.

When attempting to deliver email, an MTA first tries to deliver email to the highest-priority server. If that delivery attempt fails, it tries to deliver to a lower-priority server. If you activate the relay_based_on_MX feature and point a low-priority MX record at a secondary mail server, the mail server will accept email for the domain. The mail server will then forward email to the server identified by the highest-priority MX record for the domain when that server becomes available.

Other Files in /etc/mail :

The /etc/mail directory holds most of the files that control sendmail . This section discusses three of those files: mailertable , access , and virtusertable .
mailertable : Forwards Email from One Domain to Another

When you run a mail server, you may want to send mail destined for one domain to a different location. The sendmail daemon uses the /etc/mail/mailertable file for this purpose. Each line in mailertable holds the name of a domain and a destination mailer separated by whitespace; when sendmail receives email for the specified domain, it forwards it to the mailer specified on the same line. Red Hat enables this feature by default: Put an entry in the mailertable file and restart sendmail to use it.

The following line in mailertable forwards email sent to to the mailer at :

$ cat /etc/mail/mailertable smtp:[]

The square brackets in the example instruct sendmail not to use MX records but rather to send email directly to the SMTP server. Without the brackets, email could enter an infinite loop.

A period in front of a domain name acts as a wildcard and causes the name to match any domain that ends in the specified name. For example, matches , , and so on.

The sendmail init script regenerates mailertable.db from mailertable each time you run it, as when you restart sendmail .
access : Sets Up a Relay Host

On a LAN, you may want to set up a single server to process outbound mail, keeping local mail inside the network. A system that processes outbound mail for other systems is called a relay host . The /etc/mail/access file specifies which systems the local server relays email for. As configured by Red Hat, this file lists only the local system:

$ cat /etc/mail/access

# by default we allow relaying from localhost…
localhost.localdomain RELAY
localhost RELAY RELAY

You can add systems to the list in access by adding an IP address followed by whitespace and the word RELAY . The following line adds the 192.168. subnet to the list of hosts that the local system relays mail for:

192.168. RELAY

The sendmail init script regenerates access.db from access each time you run it, as when you restart sendmail .
virtusertable : Serves Email to Multiple Domains

When the DNS MX records are set up properly, a single system can serve email to multiple domains. On a system that serves mail to many domains, you need a way to sort the incoming mail so that it goes to the right places. The virtusertable file can forward inbound email addressed to different domains ( aliases cannot do this).

As sendmail is configured by Red Hat, virtusertable is enabled. You need to put forwarding instructions in the /etc/mail/virtusertable file and restart sendmail to serve the specified domains. The virtusertable file is similar to the aliases file (page 633), except the left column contains full email addresses, not just local ones. Each line in virtusertable starts with the address that the email was sent to, followed by whitespace and the address sendmail will forward the email to. As with aliases , the destination can be a local user, an email address, a file, or a pipe symbol ( | ), followed by a command.

The following line from virtusertable forwards mail addressed to to zcs , a local user: zcs

You can also forward email for a user to a remote email address:

You can forward all email destined for a domain to another domain without specifying each user individually. To forward email for every user at to , specify as the first address on the line. When sendmail forwards email, it replaces the %1 in the destination address with the name of the recipient. The next line forwards all email addressed to to , keeping the original recipients‘ names :

Finally you can specify that email intended for a specific user should be rejected by using the error namespace in the destination. The next example bounces email addressed to with the message 5.7.0:550 Invalid address : error:5.7.0:550 Invalid address

Regex Klammerpaar

Easy done:


Technically that’s using lookaheads and lookbehinds. See Lookahead and Lookbehind Zero-Width Assertions. The pattern consists of:

  • is preceded by a [ that is not captured (lookbehind);
  • a non-greedy captured group. It’s non-greedy to stop at the first ]; and
  • is followed by a ] that is not captured (lookahead).
Veröffentlicht unter Linux

Kompletten Netzwerk-Traffic durch SSH tunneln

I’ve recently been visiting China and have been caught out by their Firewall.  This hasn’t be too bad but Google Mail and Google Drive is really slow or intermittent.  Also you can’t access YouTube or the BBC IPlayer.   The final straw for me was for some reason they have blocked the Ubuntu Dropbox repository – so you can’t install Dropbox either.

I don’t have VPN account but we do have some servers.  Therefore, I decided to route all the network traffic through one of our server.

I tried various options and final settled on sshuttle because I needed to route everything and not just Firefox. Sshuttle is a transparent proxy server that forwards over a SSH connection and sets up a proxy by running Python scripts on the remote server.  I’m assuming your are running Ubuntu on both the client and the remote server.  You will need administrative privileges on the client.

sudo apt-get install sshuttle

To route all traffic through sshuttle (except DNS):

sshuttle -r username@sshserver:port 0/0

You will then need to enter your password on your client and then the password for the remote machine.  To help debug run sshuttle in verbose mode with the -v flag.  The -r flag is  the remote host (and username).   The port 0/0 is short for that represents the subnets to route over the VPN.  The usage of 0/0 routes all the traffic except DNS requests to the remote server.  If you need to tunnel your DNS too then add the -H flag.

The project website is

Happy Tunnelling.

Erstellen Einer Zertifikatsignieranforderung (CSR) – Apache 2.x


Diese Anleitung zeigt Ihnen, wie Sie eine Zertifikatsignieranforderung (CSR) für Ihren Apache Web-Server generieren. Wenn Sie die CSR generiert haben, kopieren Sie sie in das CSR-Feld auf der Seite für die SSL-Zertifikatanfrage.

So erstellen Sie eine Zertifikatsignieranforderung für Apache 2.x

  1. Melden Sie sich beim Terminal Ihres Servers (SSH) an.
  2. Geben Sie nach der Eingabeaufforderung Folgendes ein:
    openssl req -new -newkey rsa:2048 -nodes -keyout IhreDomain.key -out IhreDomain.csr

    Ersetzen Sie IhreDomain mit dem zu sichernden Domainnamen. Wenn Ihr Domainname also z. B. lautet, schreiben Sie coolexample.key und coolexample.csr.

  3. Geben Sie die geforderten Daten ein:
    • Common Name: Der voll qualifizierte Domainname (URL), den Sie sichern.
      Wenn Sie ein Wildcard-Zertifikat anfordern, fügen Sie links vor dem Common Name an der gewünschten Stelle ein Sternzeichen (*) ein, also z. B. *
    • Organisation: Der rechtlich verbindliche Name Ihres Unternehmens. Wenn Sie als Einzelperson agieren, geben Sie den Namen des Zertifikatanforderers ein.
    • Organisationseinheit: Falls zutreffend, geben Sie hier den fiktiven Geschäftsnamen (Firmierung) ein.
    • Stadt oder Ort: Name des Ortes, an dem Ihr Unternehmen seine Hauptniederlassung hat. Nicht abkürzen.
    • Bundesland oder Kanton: Name des Bundeslandes bzw. des Kantons, in dem Ihre Organisation ansässig ist. Nicht abkürzen.
    • Land: Der aus zwei Buchstaben bestehende Ländercode im ISO-Format desjenigen Landes, in dem Ihre Organisation rechtmäßig registriert ist.

      Wenn Sie für diesen SSL kein Passwort eingeben möchten, können Sie das entsprechende Feld leer lassen. Es ergeben sich dadurch aber zusätzliche Risiken.

  4. Öffnen Sie die CSR in einem Text-Editor und kopieren sie den gesamten Text.
  5. Fügen Sie die vollständige CSR in das SSL-Anforderungsformular in Ihrem Konto ein.
Veröffentlicht unter Linux

Tutorial: Ein eigenes TLS/SSL-Zertifikat bei StartSSL beantragen


Bei dem israelischen Anbieter StartSSL kann man sich kostenlos ein eigenes TLS/SSL-Zertifikat beantragen.

Die Laufzeit für das kostenlose TLS/SSL-Zertifikat beträgt dabei 1 Jahr. Nach dem Jahr kann man sich aber wieder ein neues holen oder das bestehende verlängern lassen.

Da die Geschichte zwar relativ einfach klingt in der Praxis aber etwas unübersichtlich ist möchte ich im Rahmen eines Tutorials an dieser Stelle einmal zeigen was man genau machen muss.

1. aufrufen


 2. Im Menü auf “Control Panel” klicken


3. Wenn man ein neuer User bei StartSSL ist dann auf “Sign-up” klicken. Dort alle Daten wahrheitsgemäß und vollständig ausfüllen und das Formular abschicken. Wenige Augenblicke danach bekommt man eine E-Mail. In dieser E-Mail befindet sich ein Authentification-Code. Diesen Authentification-Code muss man dann bei StartSSL auf der Webseite eingeben. Danach kann man sich einen neuen privaten Schlüssel erzeugen lassen. Hier am besten die höchste Einstellung also 2048 Bit wählen. Wenn der private Schlüssel erzeugt wurde dann kann man ihn im Browser installieren. Gleichzeitig sollte man sich davon auch ein Backup machen. Das ist ganz wichtig denn wenn man sich kein Backup macht dann kann man bis zum Ablauf des privaten Schlüssels nicht mehr auf sein StartSSL-Konto zugreifen.

Wenn man ein bestehender User bei StartSSL ist dann auf “Authenticate” klicken. An dieser Stelle wird überprüft ob der private Schlüssel der beim Sign-up bei StartSSL erstellt worden ist vorhanden ist. Wenn nicht dann muss man den privaten Schlüssel aus seinem Backup importieren. Hat man kein Backup seines privaten Schlüssels angelegt dann hat man ein Problem. Laut FAQ muss man in diesem Fall warten bis der private Schlüssel abgelaufen ist. Oder: man registriert sich mit einer neuen E-Mail einen neuen Account und kontaktiert dann am besten StartSSL und schildert den Fall.


4. Im Control Panel den Reiter “Validations Wizard” aufrufen. Dort zunächst “Domain Name Validation” auswählen.


Im sich daraufhin öffnenden Fenster den Domain-Namen und die Domain-Endung eingeben für die man ein TLS/SSL-Zertifikat erstellt haben möchte.


Auf der Folgeseite kann man zwischen 3 E-Mail-Adressen wählen an die man eine E-Mail erhalten möchte um nachzuweisen dass man der Inhaber der jeweiligen Domain ist. Diese E-Mail sollte man vorher unbedingt schon eingerichtet haben eh man StartSSL seine Entscheidung mitteilt. Denn unmittelbar danach wird einem ein Bestätigungscode an diese E-Mail-Adresse geschickt.


Der Bestätigungscode muss dann in das Feld für den “Verification Code” eingetragen werden,


Im Anschluss wird einem mitgeteilt man hat jetzt noch 30 Tage Zeit seine TLS/SSL-Zertifikate zu generieren.


5. Also weiter gehts und auf “Certificate Wizard” klicken. Dort als Certificate Target “SSL/TLS Certificate” auswählen.


Den Schritt “Generate Private Key” mit einem Klick auf “Skip” überspringen. Es ist immer besser wenn man den auf seinem Server und nicht online generiert.


Auf der darauf folgenden Seite wird man nun gebeten die Certificate Request einzugeben.


Die kann man wie folgt generieren:

root@server:~# openssl genrsa -out 2048
root@server:~# openssl req -new -key -out

Nun kann man die erzeugte .csr-Datei mit vi öffnen und den gesamten Inhalt bei StartSSL in das leere Textfeld einfügen.

root@server:~# vi

Nach dem Absenden bestätigt StartSSL einem noch einmal den Erhalt der Datei.


Im nächsten Schritt “Add Domain” gibt man “www” (ohne Anführungsstriche) ein und klickt auf “Continue”.


Dann erfolgt noch einmal eine Abfrage die man mit einem Klick auf “Continue” bestätigen kann. Auf der nächsten Seite bekommt man man seine “ssl.crt” angezeigt. Die kann man mit vi abspeichern.

root@server:~# vi ssl.crt

Außerdem kann man das Intermediate und das Root CA Zertifikat downloaden.


Mit den im Laufe des Tutorials 4 erstellten Dateien

  • ca.pem
  • ssl.crt

kann man nun zum Beispiel HTTPS im Apache2 einrichten. Ein einfacher VirtualHost würde in diesem Fall in etwa so aussehen:

<VirtualHost *:443>
    ServerAlias *
    DocumentRoot "/var/www"
    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/ssl.crt
    SSLCertificateKeyFile /etc/apache2/ssl/
    SSLCertificateChainFile /etc/apache2/ssl/
    SSLCACertificateFile /etc/apache2/ssl/ca.pem
    Options -Indexes
Veröffentlicht unter Linux

Webseite mit wget herunterladen

The options are:

  • –recursive: download the entire Web site.
  • –domains don’t follow links outside
  • –no-parent: don’t follow links outside the directory tutorials/html/.
  • –page-requisites: get all the elements that compose the page (images, CSS and so on).
  • –html-extension: save files with the .html extension.
  • –convert-links: convert links so that they work locally, off-line.
  • –restrict-file-names=windows: modify filenames so that they will work in Windows as well.
  • –no-clobber: don’t overwrite any existing files (used in case the download is interrupted and resumed).
Veröffentlicht unter Linux | Verschlagwortet mit

Schlüsselverwaltung DNSSEC

KSK – Double signature

Man ist immer vom Parent abhängig. Man kann nicht beeinflussen, wann der Parent den DS Record ändert. Der KSK wird nur für eine Signatur verwendet (über das DNSKEY RRset). Beides, der Schlüssel und die Signatur werden zusammen übertragen. Die Herausforderung ist es, dass dem KSK vertraut wird. Dies wird durch den DS record in der Parent-Zone sichergestellt.

KSK muss 1x jährlich erneuert werden.

  1. Einige Tage vor Ablauf des alten Schlüssels einen neuen KSK erzeugen und in Zone einfügen. Alle DNSKEY Records werden von jedem aktiven KSK signiert.
  2. Abwarten bis Schlüssel bei allen validierenden Resolvern angekommen ist (Propagation Delay von paar Minuten und TTL DNSKEY) -> also insgesamt 70 Minuten.
  3. Jetzt kann man den alten DS-Record in der Parent-Zone ( durch den neuen DS-Record ersetzen
  4. Abwarten bis der neue DS-Record bei allen validierenden Resolvern angekommen ist (Propagation Delay von mehreren Stunden und TTL DS-Record) -> ca. 12 Stunden
  5. Der alte KSK kann zusammen mit seinen Signaturen aus der Zone entfernt werden.
Schritt Beschreibung Command
Schritt 1 Die Zone wurde mit KSK1 und ZSK1 signiert
Schritt 2 Herausfinden der TTL des DS Record in der Parent-Zone des KSK1 (3h bei
Schritt 3 Generieren des neuen Schlüssel der hinzugefügt wird, KSK2
Schritt 4 Re-Sign der Zone mit KSK1, KSK2 und ZSK1
Schritt 5 Das neue DS-Record Set an den Owner der Parent Zone geben. Der Owner der Parent-Zone muss das bestehende DS Set mit dem neuen ersetzen. (Das neue Set besteht aus den zwei neuen Hash-Werten SHA1 und SHA256)
Schritt 6 Nachdem der Parent den Record geupdatet hat, muss man den DS_TTL Wert lang warten.
Schritt 7 Den alten KSK kann man entfernen. Nachdem die Zeit in DS_TTL abgelaufen ist, kann man die Zone mit KSK2 und ZSK1 resignen.


ZSK – Pre-Publish (beste von 3 verschiedenen Methoden)

Dieses Verfahren bietet den Vorteil, dass nicht gleichzeitig mit mehreren Schlüsseln signiert werden muss, wodurch die Größe der Zonendaten deutlich erhöhen würde. Zudem ist dieses Verfahren besser für Notfall-Schlüsselwechsel geeignet, da ggf. bereits ein neuer Key veröffentlicht ist, mit dem sofort signiert werden kann.

Der Trick dieser Methode ist, dass der neue DNSKEY vor der aktiven Nutzung im DNSKEY-Set der Zone hinzugefügt wird. Wenn garantiert werden kann, dass alle DNS-Resolver sowohl den neuen wie auch den alten DNSKEY im Cache haben, wird der aktive ZSK zum signieren geändert. Der alte DNSKEY wird erst aus der Zone entfernt, nachdem Signaturen vom alten ZSK aus den Caches abgelaufen sind.

  1. Einige Tage vor Ablauf des alten Schlüssels einen neuen ZSK erzeugen und in die Zone einfügen.
  2. DNSKEY RRset mit dem aktuellen KSK neu signieren. Achtung: Der neue ZSK wird noch nicht zum signieren verwendet.
  3. Abwarten bis jeder validierende Resolver den neuen ZSK hat. (Propagation Delay 15 Min + TTL DNSKEY 1h) = 75 Minuten.
  4. Zone mit dem neuen ZSK neu signieren. Der alte ZSK wird nicht mehr zum Signieren der Zone verwendet, bleibt aber noch in der Zone.
  5. Der alte ZSK muss so lange in der Zone bleiben, wie RRSig Records von diesem noch im Umlauf sind. TTLsig von 24h + paar Minuten für Resign und Propagation Delay
  6. Alten ZSK entfernen und Zone mit KSK und neuem ZSK signieren.
Schritt Beschreibung Command
Schritt 1 Die Zone wurde mit KSK1 und ZSK1 signiert.
Schritt 2 Generieren des neuen Schlüssels, ZSK2
Schritt 3 Herausfinden des TTL-Werts des DNSKEY RRset in der Zone (DNSKEY_TTL) und der größten TTL in der Zone (MaxZone_TTL)
Schritt 4 Hinzufügen des neuen Schlüssels ZSK2 zur Zone. Anschließend die Zone mit KSK1 und ZSK1 signieren. Achtung: ZSK2 wird noch nicht zum Signieren der Zone verwendet!
Schritt 5 Nach dem re-signing muss die Zeit des DNSKEY_TTL abgewartet werden.
Schritt 6 Nachdem die Zeit von DNSKEY_TTL abgelaufen ist, kann die Zone mit ZSK2 neu signiert werden. Achtung: ZSK1 wird nicht zum Signieren der Zone verwendet!
Schritt 7 Warten der Zeit von MaxZone_TTL
Schritt 8 ZSK1 entfernen und Zone mit KSK1 und ZSK2 neu signieren.


Veröffentlicht unter DNSSEC