Wie angekündigt habe ich nun meinen Apachen in den Ruhestand geschickt… Damit ist nun also ebenfalls mein Webserver auf FreeBSD und ebenfalls auf NGINX.
Siehe auch: HTTP/3 und QUIC
Fragen? Einfach melden.
Autor: Sebastian van de Meer (Seite 22 von 50)
Auf fast jedem Unix ähnlichen System haben Benutzer nicht das Recht das komplette System herunterfahren oder neustarten zu können. Macht ja nur Sinn… Nutzt man dieses System aber als Desktop könnte es in gewissen Fällen ebenfalls nicht dumm sein, wenn Benutzer nicht in der Lage sind das System zu rebooten und einen shutdown abzusetzten. In den Meisten Fällen ist man dann wohl doch alleine auf seinem System und es ist eher eine Einschränkung wenn man sich erst als privilegierter Benutzer anmelden muss um seinen Comupter/Laptop abschalten zu können.
Dafür wurden nun verschiedenste Dienste entwickelt um dieses so einfach wie möglich zu erledigen. Das wohl bekannteste und verbreitetste ist consolekit / policykit / polkit. Dieses System ermöglicht es bestimmte Rechte basierend auf Benutzer oder Gruppen zu verteilen. Die gängigen Logonmanager sowie Displaymanager haben in der Regel bereits die Möglichkeit eingebaut um sich damit auszutauschen. Der normale Linux Benutzer wird damit wohl kaum noch in Berührung kommen.
Am einfachsten schaut man sich als Benutzer einmal in einem xterminal an welche Möglichkeiten einem geboten werden:
$ pkaction
Schon gibt es eine Liste der aktuell konfigurierbaren „Berechtigungen“. Ob shutdown und reboot dabei ist sagt einem:
$ pkaction | grep -E 'stop|restart' org.freedesktop.consolekit.system.restart org.freedesktop.consolekit.system.restart-multiple-users org.freedesktop.consolekit.system.stop org.freedesktop.consolekit.system.stop-multiple-users
Ob der eigene Benutzer es bereits darf sagt einem:
$ pkaction --action-id org.freedesktop.consolekit.system.restart --verbose org.freedesktop.consolekit.system.restart: description: Restart the system message: System policy prevents restarting the system vendor: vendor_url: icon: implicit any: no implicit inactive: no implicit active: yes
Implicit active ist hier der spannende Eintrag… Dieser ergibt sich für mich aus der von mir angelegten Regel 05-shutreboot.rules unter /usr/local/etc/polkit-1/rules.d diese schaut wie folgt aus:
polkit.addRule(function (action, subject) {
if (action.id == "org.freedesktop.consolekit.system.restart" ||
action.id == "org.freedesktop.consolekit.system.stop"
&& subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
Die Regel besagt das org.freedesktop.consolekit.system.stop sowie restart das Ergebnis YES zurückgeben soll, wenn der Benutzer in der Gruppe wheel ist. ist diese Regel eingetragen, und man ist sich sicher das alles klappen müsste, es dennoch nicht funktioniert sind ein beliebter Fehler die Rechte vom Ordner. Hier könnte folgendes helfen:
$ chown polkitd:wheel /usr/local/etc/polkit-1
In diesem Sinne…
Siehe auch: FreeBSD auf dem Desktop
Fragen? Einfach melden.
Ich nutze privat das SmartHome-System der Telekom mit der QIVICON Home Base. Die alte Version 1.0 war funktional in Ordnung, aber langsam. Kein WLAN, kein ZigBee ohne USB-Stick, und je mehr Geräte dranhingen desto zäher wurde die Oberfläche. Die neuen HomeMatic IP Geräte von eQ-3 haben den Rest gegeben. Die Home Base 1.0 war damit überfordert.
Die Home Base 2.0
Das Endergebnis vorweg: Die 2.0 ist besser. Kamerastreams laufen flüssig, keine Verbindungsabbrüche mehr zu den Sensoren, die App reagiert spürbar schneller. Soweit die gute Nachricht.
Der Migrationsprozess
Die offizielle Wechselanleitung der Telekom sieht so aus:
1. Alle Geräte auf der Home Base 1.0 löschen 2. Reset der Home Base 1.0 3. Alte abklemmen, neue anklemmen 4. Neue Home Base registrieren und aktivieren 5. Alle Geräte neu einrichten
Punkt 1 und 5 sind das Problem. Jedes Gerät einzeln löschen, über eine App die alle paar Klicks die Verbindung verliert und einen gefühlten Delay von ein bis zwei Sekunden auf jede Aktion hat. Manche Geräte wollen vor dem Löschen eine physische Bestätigung am Gerät selbst. Also knapp eine Stunde durch die Wohnung rennen und Knöpfe drücken. Bei Unterputz-Schaltern besonders viel Freude.
Was bei mir schiefging
Nach dem Löschen aller Geräte und dem Reset der alten Home Base wollte die App keine Verbindung mehr herstellen. Logisch, die alte Base war ja zurückgesetzt. Im QIVICON-Webportal gab es einen Button „Exchange Gateway“ der in der Anleitung nicht vorkam. Seriennummer der neuen Base eingeben, fertig. Die Aktivierung, die laut Anleitung nötig sein soll, war es nicht. In der Anleitung steht man solle die Fehlermeldung bei der Aktivierung ignorieren. Fehlermeldung ignorieren als offizieller Schritt.
Nach dem Gateway-Tausch passierte etwas Unerwartetes: Die neue Home Base hatte meine komplette Konfiguration und alle Geräte. Die ich vorher gelöscht hatte. Die Geräte kannten aber den Funkschlüssel der alten Base und weigerten sich mit der neuen zu reden. Das Ergebnis war ein Dauerbeschuss des Funkmoduls mit ungültigem Traffic. Die Base war alle paar Sekunden überlastet.
Zum Löschen der Geräte brauchte man das Funkmodul. Also hatte man immer ein paar Sekunden Zeit bevor es wieder abschmierte. Ein Neustart der Home Base dauerte 15 Minuten. Das ganze Löschen und Neu-Anlernen hat knapp drei Stunden gedauert, inklusive Geräte die vor dem Neu-Anlernen einen eigenen Factory-Reset brauchten.
Fazit
Die Hardware ist ein klares Upgrade. Der Migrationsprozess ist eine Katastrophe. Ein Gateway-Tausch sollte eine Sache von Minuten sein, nicht von Stunden. Das Telekom SmartHome hat den Vorteil verschiedene Hersteller kombinieren zu können. Das ist nach wie vor der Grund warum ich dabei bleibe. Die Bilder zeigen die alte und neue Home Base, innen und aussen.
Siehe auch: Telekom SmartHome im Test: Erfahrungen mit QIVICON und Home Base, Telekom SmartHome: Firmware-Updates für HomeMatic-Geräte über die CCU2, Magenta SmartHome Lüften: Lösung für Android-Probleme gefunden
Fragen? Einfach melden.
Ihr erinnert euch doch sicher noch an meinen Bla zum BSI und nextcloud, oder? ==> Die Jungs vom BSI und nextcloud
Inzwischen ist der Scanner wohl für jeden einfach nutzbar… So wie man es von Qualys oder ähnlichem kennt. Einfach mal hier klicken: https://scan.nextcloud.com/ und fröhlich scannen.
Solche Scanner haben ja auch schon irgendwie etwas für sich, oder? Ein A+ sollte wohl für den Moment jeder ohne weitere Probleme erreichen können!
So long…
Siehe auch: MTA-STS einrichten
Fragen? Einfach melden.
Nextcloud hat sie die Mühe gemacht und mal nach owncloud und nextcloud Installationen gesucht. Dabei haben sie direkt mal geprüft wie sicher oder unsicher die wohl sind. Das hat seinen Weg zum BSI gefunden und die haben dann die abuse Adressen aller Netzbetreiber „gefüttert“.
Erstmal keine schlechte Idee. Natürlich will nextcloud was damit erreichen, das BSI macht auch brav mit super… Solange wir alle IPv4 machen läuft diese Version auch!
Oh ja, die abuse Mail:
Sehr geehrte Damen und Herren, ownCloud und Nextcloud sind Software-Lsungen zum Betrieb selbst gehosteter Cloud-Instanzen zur Synchronisation und zum Austausch von Daten. Das Unternehmen Nextcloud GmbH hat offen aus dem Internet erreichbare Installationen von ownCloud und Nextcloud geprft. Dabei wurden zahlreiche Cloud-Instanzen identifiziert, die mit veralteten Software-Versionen laufen, welche verschiedene Sicherheitslcken aufweisen. Angreifer knnen diese Schwachstellen ausnutzen, um unter anderem unberechtigt auf die in der Cloud gespeicherten Daten zuzugreifen. Dabei knnen die Angreifer ggf. sensible Informationen wie z.B. persnliche Dokumente, Fotos oder Kundendaten von Unternehmen aussphen und diese anschlieend im Internet verffentlichen oder fr kriminelle Zwecke wie Erpressungen nutzen. Andere Schwachstellen ermglichen Angreifern die Ausfhrung beliebigen Programmcodes auf dem Cloud-Server. Dies kann ggf. zu einer vollstndigen Kompromittierung des Systems und dessen Missbrauch fr weitere kriminelle Aktivitten fhren. Die Nextcloud GmbH hat CERT-Bund ihre Ergebnisse der Prfungen zur Untersttzung bei der Benachrichtigung betroffener Server- Betreiber bereitgestellt. Nachfolgend senden wir Ihnen eine Liste betroffener Systeme in Ihrem Netzbereich. Der Zeitstempel (Zeitzone UTC) gibt an, wann die verwundbare Cloud-Installation identifiziert wurde. Weiterhin sind fr jedes System eine Risikoeinstufung sowie eine eindeutige ID (UUID) angegeben. Die Nextcloud GmbH stellt unter folgender URL detaillierte Informationen zu den bei der jeweiligen Cloud-Instanz erkannten Schwachstellen und deren Behebung zur Verfgung: https://scan.nextcloud.com/results/[UUID] Der Parameter [UUID] muss dabei durch die zu der jeweiligen Instanz angegebene UUID ersetzt werden. Beispiel: https://scan.nextcloud.com/results/12345678-1234-1234-1234-12345678 Wir mchten Sie bitten, den Sachverhalt zu prfen und Manahmen zur Aktualisierung der Cloud-Installationen auf den betroffenen Systemen zu ergreifen bzw. Ihre Kunden entsprechend zu informieren. Fr alle auf den betroffenen Systemen identifizierten Schwachstellen stehen entsprechende Sicherheitsupdates der Hersteller zur Verfgung. Bei Rckfragen zu den durchgefhrten Prfungen der Cloud-Instanzen wenden Sie sich bitte direkt an die Nextcloud GmbH unter <cloud-security-scan@nextcloud.com>. Diese E-Mail ist mittels PGP digital signiert. Informationen zu dem verwendeten Schlssel finden Sie unter <https://reports.cert-bund.de>. Bitte beachten Sie: Dies ist eine automatisch generierte Nachricht. An die Absenderadresse kann nicht geantwortet werden. Bei Rckfragen zu dieser Benachrichtigung wenden Sie sich bitte unter Beibehaltung der Ticketnummer in der Betreffzeile an <certbund@bsi.bund.de>. ====================================================================== Betroffene Systeme in Ihrem Netzbereich: Format: ASN | IP | Timestamp (UTC) | UUID | Severity | Port | Hostname 12345 | 1.2.3.4 | 2017-02-06 19:53:17 | 1ae3f7da-3367-4012-9382-7912dd4bd163 | high | 80 | cloud.domain.de 12345 | 1.2.3.5 | 2017-02-06 19:53:17 | 2e0a45fa-1568-458f-898e-2a888b44c9c6 | medium | 80 | cloud.wurst.com 12345 | 1.2.3.6 | 2017-02-06 19:53:17 | 32288a95-d396-4c9b-8998-d1968dc30ad7 | low | 80 | cloud.alalaa.de 12345 | 1.2.3.7 | 2017-02-06 19:53:17 | ecfd4e62-b1b5-4c7d-b888-3f19ca3ca7ff | high | 443 | cloud.butani.cn 12345 | 1.2.3.8 | 2017-02-06 19:53:17 | 52ff7f71-c004-4a36-9975-2b5a99f280d6 | high | 80 | cloud.bima.org 12345 | 1.2.3.9 | 2017-02-06 19:53:17 | e388d8c5-4124-4af3-b052-57f77469783a | high | 80 | cloud.2083a.net 12345 | 1.2.3.10 | 2017-02-06 19:53:17 | 5cad0785-a6eb-47ca-aeec-6c4252928d13 | low | 443 | cloud.lutzola.nl 12345 | 1.2.3.11 | 2017-02-06 19:53:17 | 7da5d2dc-8556-4699-9ea4-7814c6afb8c0 | high | 80 | cloud.weglaa.wu 12345 | 1.2.3.12 | 2017-02-06 19:53:17 | adac575f-6a42-487d-a8c3-1b789ebafe39 | medium | 80 | cloud.breck.aa [.....] Mit freundlichen Gren / Kind regards Team CERT-Bund Bundesamt fr Sicherheit in der Informationstechnik (BSI) Federal Office for Information Security Referat CK22 - CERT-Bund Godesberger Allee 185-189, D-53175 Bonn, Germany
Fragen? Einfach melden.
Auf meinem Smartphone werkelt inzwischen LinageOS. Funktioniert auch ganz prima. Heute am Morgen kommt die Meldung hoch: „Es gibt ein Update“. Ich drück natürlich auf: „Gib ihm!“
Das Gerät macht irgendwas und startet dann im TWRP neu. An der Stelle hätte ich nun damit gerechnet, dass es beginnt das Update zu installieren. Tut er aber leider nicht :-/ Ich starte also neu, wieder kommt er im TWRP hoch. Egal was ich mache, bleibt so.
Nicht falsch verstehen, ich beschwere mich nicht darüber. Ich habe mich ja dafür entschieden ein solch instabiles System zu nutzen..
Wie auch immer. Folgendes hat mir geholfen.
Im TWRP den Terminal Emulator starten und folgende Befehl absetzten:
dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/fota dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/misc
Reboot und gut!
Fragen? Einfach melden.
Ich: tuuuuut…… tuuuuuut
Hotline: Bla gdata Hotline bla
Ich: Pffffhhhh
Hotline: *laala* (mucke)
Ich: Pffffhhhh
Hotline: Willkommen an der Hotline, mein Name ist Mann, was kann ich für sie tun?
Ich: Sie brauchen sicher meinen Benutzernamen, oder?
Das scheint da so etwas wie die Kundennummer in anderen Unternehmen zu sein….
Hotline: Oh ja, den nehme ich gerne.
Ich: Konrad-5-Julius-Heinrich-97- [Hotlinemann unterbricht mich]
Hotline: Konrad ausgeschrieben?
Ich: Öhm ähh ne also öh der Buchstabe?!?
Hotline: OK
Ich: Kundenummer…
Hotline: und was kann ich nun für sie tun?
Ich: Wir testen gerade die Amavis Integration eurer G DATA Business Lösung und das läuft nicht ganz rund.
Hotline: uhhaaa ohh
Ich: Warum uhaaa ohh?
Hotline: Öhm (hehe) also ähh, da bekommen wir eher weniger Anfragen. Wird nicht so oft benutzt.
Ich: Na aber ihr verkauft das ja.
Hotline: Ja aber ähh gut.
Dann wurden Version und OS abgefragt und ein Ticket angelegt. Ich sollte mal Auszüge aus dem Maillog senden. irgendwie habe ich das Gefühl als wenn das gerade nix wird.
Für Spaß auch mal die Logfiles:
Feb 7 08:27:54 mx amavis[27217]: (21323-04-4) (!)run_command: child process [27217]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb 7 08:27:54 mx amavis[21323]: (21323-04-4) (!!)collect_results from [27217] (/usr/bin/gdmailscannerc): exit 3 Feb 7 08:27:54 mx amavis[21323]: (21323-04-4) (!)checking with spam scanner GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158.
Feb 7 08:27:54 mx amavis[21323]: (21323-04-4) (!!)TROUBLE in check_mail: spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159.
Feb 7 08:27:54 mx amavis[21323]: (21323-04-4) (!)PRESERVING EVIDENCE in /var/lib/amavis/tmp/amavis-20170207T082744-21323-gFK_Ofar
Feb 7 08:27:54 mx postfix/smtp[27003]: EFA15C0A13: to=<type@domain.de>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=4, delay=85234, delays=85181/42/0/10, dsn=4.5.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error in processing, id=21323-04-4, spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159. (in reply to end of DATA command)) Feb 7 08:27:54 mx amavis[27219]: (21323-04-5) (!)run_command: child process [27219]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb 7 08:27:54 mx amavis[21323]: (21323-04-5) (!)run_av (GDAVCLIENTC SCANNER.) FAILED - unexpected , output=""
Feb 7 08:27:54 mx amavis[21323]: (21323-04-5) (!)GDAVCLIENTC SCANNER. av-scanner FAILED: CODE(0x2cc4260) unexpected , output="" at (eval 97) line 905.
Feb 7 08:27:54 mx amavis[21323]: (21323-04-5) (!)WARN: all primary virus scanners failed, considering backups Feb 7 08:27:54 mx amavis[27221]: (20783-09-4) (!)run_command: child process [27221]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb 7 08:27:54 mx amavis[20783]: (20783-09-4) (!!)collect_results from [27221] (/usr/bin/gdmailscannerc): exit 3 Feb 7 08:27:54 mx amavis[20783]: (20783-09-4) (!)checking with spam scanner GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158.
Feb 7 08:27:54 mx amavis[20783]: (20783-09-4) (!!)TROUBLE in check_mail: spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159.
Feb 7 08:27:54 mx amavis[20783]: (20783-09-4) (!)PRESERVING EVIDENCE in /var/lib/amavis/tmp/amavis-20170207T082744-20783-75UHo67I
Feb 7 08:27:54 mx postfix/smtp[27159]: D74F7C00F4: to=<type@domain.de>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=4, delay=342238, delays=342185/42/0/10, dsn=4.5.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error in processing, id=20783-09-4, spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159. (in reply to end of DATA command)) Feb 7 08:27:55 mx amavis[20783]: (20783-09-5) Passed CLEAN {RelayedInbound}, SPAM_DISC [1.2.3.4]:44419 [1.2.3.4] <type@domain.de> -> <type@domain.de>, Queue-ID: 6D65CC0A33, Message-ID: <62734015.3835.1486452455492.JavaMail@domain.de>, mail_id: lsOZOYNAIa3o, Hits: 0, size: 44774, queued_as: 57B04C0A40, 471 ms
Feb 7 09:55:25 mx amavis[22893]: (22893-07) Passed CLEAN {RelayedInbound}, SPAM_DISC [1.2.32.4]:36945 [1.5.7.98] <type@domain.de> -> <type@domain.de>, Queue-ID: E7592C0071, Message-ID: <20170207085513.B8A52340881@domain.de>, mail_id: 3lhpfBFnyuAI, Hits: 0, size: 4172, queued_as: 1F499C00F7, 10166 ms Feb 7 09:55:25 mx amavis[20843]: (20843-14) (!)run_av (GDAVCLIENTC SCANNER.) FAILED - unexpected , output="SKIP"
Feb 7 09:55:25 mx amavis[20843]: (20843-14) (!)GDAVCLIENTC SCANNER. av-scanner FAILED: CODE(0x2cc4260) unexpected , output="SKIP" at (eval 97) line 905.
Feb 7 09:55:25 mx amavis[20843]: (20843-14) (!)WARN: all primary virus scanners failed, considering backups
Fragen? Einfach melden.
Postfix kann eingehende Mails anhand von DNS-basierten Blocklisten ablehnen. Zwei Typen sind relevant: DNSRBL (IP-basiert) prüft ob die sendende IP-Adresse auf einer Blockliste steht. RHSBL (Domain-basiert) prüft ob die Absenderdomain gelistet ist. Beides passiert in Echtzeit während der SMTP-Sitzung, noch bevor die Mail angenommen wird.
Öffentliche Listen
Es gibt dutzende öffentliche Blocklisten. Nicht alle sind gleich zuverlässig. Diese hier laufen bei mir seit Jahren ohne nennenswerte False Positives:
# /etc/postfix/main.cf (Auszug) smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client b.barracudacentral.org, reject_rbl_client ix.dnsbl.manitu.net, permit
zen.spamhaus.org ist die Kombiliste von Spamhaus (SBL + XBL + PBL). ix.dnsbl.manitu.net wird in Deutschland gepflegt und erwischt deutschsprachigen Spam den internationale Listen übersehen.
Eigene Listen
Zusätzlich betreibe ich eigene Blocklisten unter kernel-error.de. Die werden teils von Hand gepflegt, teils automatisch aus einem Honeypot-Postfach befüllt. Einträge bleiben mindestens sechs Monate drin:
# Eigene Listen (RHSBL + RBL) reject_rhsbl_sender abuse.rhsbl.kernel-error.de, reject_rhsbl_sender postmaster.rhsbl.kernel-error.de, reject_rhsbl_sender spam.rhsbl.kernel-error.de, reject_rbl_client spam.rbl.kernel-error.de,
Die RHSBL-Listen prüfen die Absenderdomain: abuse listet Domains ohne funktionierende abuse-Adresse, postmaster solche ohne postmaster-Adresse, spam bekannte Spam-Domains. Die RBL-Liste prüft die IP-Adresse des sendenden Servers.
Warnung
Das sind meine privaten Listen. Ich pflege sie nach meiner persönlichen Einschätzung. Wer sie produktiv einsetzt, macht das auf eigene Verantwortung. Es wird zu False Positives kommen, weil meine Kriterien nicht mit den eigenen übereinstimmen müssen. Für den eigenen Mailserver sind sie ein nützlicher Baustein neben den öffentlichen Listen. Für fremde Mailserver würde ich sie nicht empfehlen.
Wer seinen Postfix weiter absichern will: Die HELO-Prüfung fängt einen erstaunlichen Anteil an Spam ab, bevor die RBL-Abfrage überhaupt nötig wird. Fragen? Einfach melden.
Zum Spaß hatte ich mir einen VPS in Japan geklickt. Was damit anfangen? Einen weiteren DNS-Server aufsetzen natürlich. Gute Idee? Nicht wirklich. Der Server steht am anderen Ende der Welt, hat höhere Antwortzeiten und der Resolver wählt zufällig, welchen DNS er fragt. Sporadisch deutlich langsamere Antworten also. Aber für den Spieltrieb war das OK.
FreeBSD 10, BIND 9.11, als Slave für drei Zonen (kernel-error.org, .com, .de). System gepatcht, BIND installiert, DNSSEC-Validierung getestet (TCP, UDP, größer 512 Bytes), alles sauber. Als Slave eingebunden, nochmal getestet, dann bei den übergeordneten Zonen eintragen lassen.
Das Problem
Die Zonen .org und .com haben den neuen Nameserver anstandslos aufgenommen. Die .de-Zone (DENIC) meckerte: DNS-Timeout bei IPv6. Nur bei IPv6. Per dig und drill lief alles einwandfrei:
dig @2001:310:6000:f::1fc7:1 +edns +norec +bufsize=4096 kernel-error.com IN MX +short 10 smtp.kernel-error.de. dig @2001:310:6000:f::1fc7:1 +tcp +edns +norec +bufsize=4096 kernel-error.com IN MX +short 10 smtp.kernel-error.de.
BIND macht keinen Unterschied zwischen IPv4 und IPv6. Alles beantwortet, alles sauber. Auch tcpdump zeigte nichts Auffälliges. PF deaktiviert, kein Unterschied. Provider filtert nicht (nur Switch, iptables und ebtables auf der Infrastruktur, klingt spartanisch). DNSViz meldete ebenfalls einen Fehler, genau wie DENIC.
Die Fehlermeldung der DENIC-API:
ERROR: 223 Timeout after switching from UDP to TCP - switch to TCP due to timeout (target) (ns3.kernel-error.com./2001:310:6000:f:0:0:1fc7:1:53)
Der Query-Log
Query-Log aktiviert. Man sieht die Anfragen der DENIC (2a02:568:201:214::1:15) ankommen und beantwortet werden. UDP, TCP, EDNS, DNSSEC-Queries, alles da:
30-Jan-2017 18:30:04.669 client 2a02:568:201:214::1:15#38145: query: ns3.kernel-error.com IN A -E(0)DC 30-Jan-2017 18:30:04.670 client 2a02:568:201:214::1:15#41589: query: ns3.kernel-error.com IN AAAA -E(0)DC 30-Jan-2017 18:30:04.938 client 2a02:568:201:214::1:15#20703: query: kernel-error.de IN SOA - 30-Jan-2017 18:30:05.510 client 2a02:568:201:214::1:15#58465: query: kernel-error.de IN NS -T 30-Jan-2017 18:30:05.889 client 2a02:568:201:214::1:15#47548: query: kernel-error.de IN SOA -E(0)D 30-Jan-2017 18:30:05.896 client 2a02:568:201:214::1:15#55493: query: kernel-error.de IN DNSKEY -E(0)D 30-Jan-2017 18:30:06.416 client 2a02:568:201:214::1:15#37170: query: kernel-error.de IN DNSKEY -E(0)TD
Die Auflösung
Während ich einem Kollegen das Problem demonstrieren wollte, lief das DENIC-Update plötzlich einfach durch. Keine Änderung meinerseits. Die Antwort von DENIC kam dann auch:
Unsere Kollegen können derzeit nicht genau sagen woran es hängt. Jedoch sind unsere Verbindungen nach Korea zeitweise leicht beeinträchtigt, evtl. wurde die Nast-Prüfung genau in dem Moment durchgeführt.
Vermutlich lag es an der Antwortzeit von 200–300 ms, die zusammen mit einem Routing-Problem auf der DENIC-Seite gerade so in einen Timeout lief. Offiziell geklärt wurde es nie. Ein leicht ungutes Gefühl bleibt.
Die tcpdump-Mitschnitte von damals liegen hier: dns.tar.gz. Wer sich für DNSSEC-Grundlagen interessiert: DNSSEC einrichten mit BIND. Fragen? Einfach melden.
Wenn wir schon dabei sind hier Dinge umzustellen, ns2.kernel-error.org hat eine neue IPv6 Adresse bekommen (IPv4 bleibt).
Alt: 2001:41d0:2:c3b4::66
Neu: 2001:41d0:302:2100::6401
In den Zonen passt schon alles, fehlt nur noch der Glue-Record. Der sollte aber auch bald da sein.
Fragen? Einfach melden.