Kategorien
Microblog

RT @bortzmeyer: New port allocated for DNS over TL…

RT @bortzmeyer: New port allocated for DNS over TLS: on your network, expect packets from/to port 853. #DNS #privacy #

Kategorien
Blog

Einen eigenen DynDNS-Service betreiben

DynDNS ist eine praktische Sache: der heimischen Internetverbindung wird ein Name zugewiesen, und wenn die IP-Adresse wechselt, dann kann der automatisch aktualisiert werden. Die meisten handelsüblichen Router können das — aber nicht allein, sondern es wird immer ein spezieller DNS-Server benötigt.

Da gab es mit dyndns.org lange Zeit einen gut funktionierenden kostenlosen Dienst, aber der nennt sich inzwischen dyn.com und will verhältnismäßig viel Geld haben (es gibt zwar immernoch eine kostenlose Variante, aber die muss regelmäßig per Klick auf bunt blinkende Mails wieder freigeschaltet werden). Der Wechsel zu irgendeinem der Konkurrenten verbessert die Lage mutmaßlich immer nur vorübergehend. Außerdem möchte zumindest ich meine Infrastruktur so viel wie möglich selbst betreiben.

Die Aufgabe ist also, einen Eintrag im DNS zu ändern. Eigentlich gibt es einen Prima Standard um DNS-Zonen zu aktualisieren, nämlich das Dynamic DNS Update Protocol, wie es in RFC 2136 und RFC 2137 beschrieben ist. Das können die aktuellen DNS-Server ohne zusätzliche Software, und es ist auch schön kryptographisch abgesichert, aber keiner der handelsüblichen Router kann das (diesem Muster werden wir später nochmal begegnen).

Da muss es doch was von GNU geben. Und tatsächlich: genau diese Aufgabe übernimmt GnuDIP. Das wird zwar seit mehr als 10 Jahren nicht mehr weiterentwickelt, funktioniert aber stabil (Ok, die Webseite sieht sehr altbacken aus und möchte gern ein Java-Applet zur Bestimmung der IP-Adresse verwenden — und was ich davon halte ist ja bekannt).

Im Folgenden richten wir unter der Beispieldomain steinhobelgruen.de eine dynamische Domain dyn.steinhobelgruen.de ein.

Installation

Als Basis nehmen wir einen Debian GNU/Linux-Server mit bind9 als DNS-Server und MySQL als Datenbakserver und gehen (zumindest für den mittleren Teil) grob nach dieser Anleitung vor. Leider hat Debian das gnudip-Paket irgendwann aus der Distribution entfernt, wir machen also eine richtig klassische /usr/local-Installation.

Wir laden das Paket runter, entpacken es und „installieren“ die Software:

wget http://gnudip2.sourceforge.net/gnudip-www/src/gnudip-2.3.5.tar.gz
tar zxvf gnudip-2.3.5.tar.gz
mv gnudip-2.3.5/gnudip /usr/local

Dann legen wir die Datenbank an, dazu passen wir in der Datei gnudip-2.3.5/gnudip.mysql eventuell noch Datenbankname und Passwort an und rufen dann MySQL auf:

mysql -uroot -p  < gnudip-2.3.5/gnudip.mysql

In der GnuDIP-Konfiguration unter /usr/local/gnudip/etc/gnudip.conf müssen wir dasselbe Datenbankpasswort  konfigurieren.

Die mitgelieferten cgi-Skripten konfigurieren wir auf dem Webserver; dazu fügen wir die folgenden Zeilen in der Konfiguration des Webservers ein (eventuell in einem bestimmten Virtual Host):

[...]
Alias /gnudip/html/ /usr/local/gnudip/html/

<Location /gnudip/html/>
Options Indexes
ReadmeName .README
HeaderName .HEADER
RemoveHandler .pl
RemoveType .pl
AddType text/plain .pl
</Location>
ScriptAlias /gnudip/cgi-bin/ /usr/local/gnudip/cgi-bin/

DNS Server konfigurieren

Erstmal richten wir einen Schlüssel für DNS-Updates ein. Dazu brauchen wir das dnssec-keygen-Tool aus dem Debian-Paket dnsutils.

dnssec-keygen -a hmac-sha512 -b 512 -n HOST gnudip

Der Aufruf erzeugt zwei Dateien, die zum Beispiel Kgnudip.+165+23314.key und Kgnudip.+165+23314.private heißen.

Wenn der DNS-Server eine Domain dynamisch aktualisieren soll, dann braucht er ein Verzeichnis, in dem er Schreibrechte hat. Wir legen also eins an:

mkdir /etc/bind/dyndns
chown bind:bind /etc/bind/dyndns

In das neue Verzeichnis legen wir eine fast leere DNS-Zonendatei dyn.steinhobelgruen.de:

$ORIGIN dyn.steinhobelgruen.de.
$TTL 86400
@ IN SOA nyx.wazong.de. hostmaster (
      0 ; Serial
   3600 ; Refresh
   1800 ; Retry
 604800 ; Expire
  600 ) ; Negative Cache TTL
@ IN NS nyx.wazong.de.
@ IN MX 0 nyx.wazong.de.
@ IN A 188.40.53.18

Die neue Zone deligieren wir in der Zone steinhobelgruen.de an unseren Nameserver:

$ORIGIN steinhobelgruen.de.
[...]
dyn IN NS nyx.wazong.de.

Den vorhin erzeugten Schlüssel aus der …private-Datei kopieren wir folgendermaßen in die named-Konfiguration  aufgenommen (in einer neuen Datei /etc/bind/gnudip.key ) …

key gnudip-key {
 algorithm hmac-sha512;
 // the TSIG key
 secret "u+/X3NGp1aQxvJedO/8j2xHDxtNgBaSOMgAYMo/OtpbUJXh02Fwfi8+u+yNq/zkIp36m2vY85pw8pgKMk5XSAw==";
 };

… und in der /etc/bind/named.conf.local legen wir die dynamische Zone an und erlauben die Aktualisierung mit dem Schlüssel:

[...]
// include definition of GnuDIP update key
 include "/etc/bind/gnudip.key";
// define GnuDIP dynamic DNS zone
 zone "dyn.steinhobelgruen.de" in {
 type master;
 file "/etc/bind/dyndns/dyn.steinhobelgruen.de";
 allow-query { any; };
 update-policy { grant gnudip-key subdomain dyn.steinhobelgruen.de; };
 };

Wenn alles passt können wir Bind neu starten (bzw. die Konfiguration neu laden).

/etc/init.d/bind9 reload

Die Teile Verbinden

Der Private Schlüssel kommt zur GnuDIP-Installation nach /usr/local/gnudip/etc/ und wird in /usr/local/gnudip/etc/gnudip.conf eingetragen:

[...]
nsupdate = -k /usr/local/gnudip/etc/Kgnudip.+165+23314.private
[...]

Nach dieser Einrichtung sollten wir direkt auf dem Webinterface einen Admin-Benutzer und die Domain anlegen. Danach können wir weitere Benutzer anlegen oder sogar Selbstregistrierung einschalten.

GnuDIP Web Interface

Router anbinden

An dieser Stelle ist GnuDIP jetzt zu sicher um praktisch zu sein: es definiert nämlich ein eigenes Protokoll für die Aktualisierung der Einträge über HTTP, in der das Passwort zusammen mit einem Salt und einem Zeitstempel in einem MD5-Hash und base64-codiert übertragen wird. Genau so sollte so etwas eigentlich auch gemacht werden, aber keiner der handelsüblichen Router kann das.

Grrrrr! Was können die denn überhaupt?

Nun ja, das ist unterschiedlich. Da ich so eine gerade hier habe, werden wir als Beispiel eine Fritz!Box anbinden. Die unterstützt als DynDNS-Anbieter „Benutzerdefiniert“ und kann dann eine selbstgewählte Update-URL eintragen. Was sie dabei übertragen kann steht in dieser Dokumentation bei AVM. Also habe ich in GnuDIP eine zusätzliche und vereinfachte Update-URL eingebaut, die dazu passt.

Um die bei Euch zu installieren, müsst Ihr dieses Archiv mit zwei Dateien herunterladen, sie auspacken und zu Eurer GnuDIP-Installation dazu kopieren.

Damit ergibt sich als neue Update-URL:

https://steinhobelgruen.de/gnudip/cgi-bin/simpleupdt.cgi?user=<username>&pass=<pass>&domn=<domain>&addr=<ipaddr>&reqc=0 (und zwar genau so mit allen Platzhaltern). Die restlichen Parameter werden wie gewohnt konfiguriert (Achtung! Die Domain muss mit dem Benutzernamen anfangen!)

Benutzerdefinierter Service

Durch die Änderung werden jetzt Benutzername und Passwort im Klartext über’s Netz geschickt. Das gleiche Problem hat aber auch die Benutzeroberfläche, so dass auf dem Server vielleicht sowieso besser TLS (https) benutzt werden sollte.

Und siehe da: es funktioniert:

dentaku@nyx:~$ host dentaku.dyn.steinhobelgruen.de
dentaku.dyn.steinhobelgruen.de has address 78.42.203.144
dentaku@nyx:~$

(P.S.: gebt Euch keine Mühe, die Beispieldomain gibt es wirklich, aber die Schlüssel hier im Blogbeitrag sind natürlich nicht die echten — ach ja, und alle Domain- und Hostnamen werden bei Euch andere sein, wenn Ihr der Anleitung folgt)

Kategorien
Blog

CloudFlare, fix your DNS

Ich habe den Feed von Very Important Pixels abonniert. Eine Menge andere Leute haben das auch getan — offensichtlich so viele, dass die Macher sich entschlossen haben, ein Content Delivery Network vorzuschalten. Vielleicht hat es auch andere Gründe, jedenfalls läuft die Seite über CloudFlare. Das ist durch eine DNS-Abfrage leicht nachzuprüfen:

dentaku@nyx:~$ host www.veryimportantpixels.com
www.veryimportantpixels.com is an alias for
    www.veryimportantpixels.com.cdn.cloudflare.net.
www.veryimportantpixels.com.cdn.cloudflare.net is an alias for
    cf-protected-www.veryimportantpixels.com.cdn.cloudflare.net.
cf-protected-www.veryimportantpixels.com.cdn.cloudflare.net has address 108.162.199.82
cf-protected-www.veryimportantpixels.com.cdn.cloudflare.net has address 108.162.198.82
dentaku@nyx:~$

Leider scheint CloudFlare seinen DNS-Server nicht ganz im Griff zu haben, deshalb sehe ich jetzt in meinem Syslog bei jeder Aktualisierung meines Feedreaders (also vier mal in der Stunde) mehrere solche Einträge:

nyx named[4191]: DNS format error from 213.133.99.99#53
    resolving www.veryimportantpixels.com.cdn.cloudflare.net/AAAA
    for client 127.0.0.1#60013:
    unrelated AAAA cf-protected-www.veryimportantpixels.com.cdn.cloudflare.net
    in cf-protected.veryimportantpixels.com.cdn.cloudflare.net authority section

Das nervt etwas.

Kategorien
Blog

LSRDNSBL

Jetzt ist es passiert: heute hat der Bundestag das Leistungsschutzrecht für Presseverleger verabschiedet. Damit ist es zwar noch nicht Gesetz, aber das könnte durchaus noch in dieser Legislaturperiode passieren. Die rechtlichen Unsicherheiten der aktuell beschlossenen Fassung sind groß. Da ist es eine nachvollziehbare Reaktion, auf die Befürworter des Leistungsschutzrechts nicht (mehr) verlinken zu wollen.

Dafür gibt es auch schon einige technische Lösungen, allen voran das WordPress-Plugin von D64. Wenn ich aber in den Sourcecode der verschiedenen Lösungen gucke, dann sehe ich entweder eine mitgelieferte Liste oder (wie bei D64) den Zugriff auf einen zentralen Server. Wenn der ausfällt, dann hängt z.B. ein Blog, auf dem ein solches Plugin aktiv ist.

Eine DNS Blacklist ist eine im Bereich der eMail-Spambekämpfung gut erprobte Methode zur Skalierung solcher Abfragen, deshalb habe ich jetzt aus der bestehenden Liste (von D64) eine solche erstellt — und bin dabei gleich noch einen Schritt weiter gegangen. Das neue Recht gilt nämlich eigentlich natürlich für alle Presseverlage, deshalb habe ich gleich eine mehrstufige Kategorisierung eingebaut.

Die Abfrage erfolgt über domain.tld.lsrbl.wazong.de und liefert die folgenden Antworten:

  • Stufe 1: kein Presseverlag
    dentaku@nyx:~$ host wazong.de.lsrbl.wazong.de
    wazong.de.lsrbl.wazong.de has address 127.0.0.0
  • Stufe 2: Presseverlag aber kein Befürworter des Leistungsschutzrechts (diese Liste ist noch im Aufbau)
    dentaku@nyx:~$ host spiegel.de.lsrbl.wazong.de
    spiegel.de.lsrbl.wazong.de has address 127.0.0.1
  • Stufe 3: Presseverlag und Befürworter des Leistungsschutzrechts
    dentaku@nyx:~$ host focus.de.lsrbl.wazong.de
    focus.de.lsrbl.wazong.de has address 127.0.0.2

    Subdomains sind auch unterstützt:

    dentaku@nyx:~$ host sonderaktion.sport.bild.de.lsrbl.wazong.de
    sonderaktion.sport.bild.de.lsrbl.wazong.de has address 127.0.0.2
  • Als Stufe 4 sind Presseverlage vorgesehen, die unangenehm mit Durchsetzung des Leistungsschutzrechts aufgefallen sind. Die ist im Moment noch leer.

Macht damit, was Ihr wollt und könnt. Viel Spaß!

(Teaserbild: CC-BY-SA von Digitale Gesellschaft)

Update 02.03.2013:

Nach Input von @moeffju habe ich die Rückgabewerte von 0.0.0.x auf 127.0.0.x geändert.

Kategorien
Blog

a.de

Wie gerade überall zu lesen ist werden sich die Domainrichtlinien der deNIC am 23.10.2009 ändern. Von da an werden auch ein- und zweibuchstabige Domainnamen sowie reine Zahlendomains möglich sein. Außerdem fallen einige weitere Einschränkungen (bisher waren z.B. Autokennzeichen als Domain verboten).

Ich dachte erst daran, am sicher einsetztenden Run auf die zweibuchstabigen Domains Teilzunehmen (z.B. tr.de), aber nach dem klugen Gedanken, den ich bei Zellmi gelesen habe:

Wer jetzt diesbezüglich auch schon ein Kribbeln verspürt, sollte daran denken, dass die Durchsetzungswilligkeit des Markenrechts bei Markeninhabern nicht zu unterschätzen ist.

bin ich mir da jetzt nicht mehr so sicher…

(Wenigstens stimmt dann in Zukunft mein bisher falsches Beispiel in dem Artikel.)

Kategorien
Blog

1&1 nochmal

Drei Wochen nach der Lösung des kleinen Mailproblems mit 1&1 hat sich jetzt ein „ZyanKlee“ mit einem Kommentar und einem verlinkten Blogartikel gemeldet. Das ist deshalb bemerkenswert, weil er beim Kommentieren von einem Rechner aus dem 1&1-Netz kam.

Er kommentiert hier:

Auf meinem Blog habe ich die Gründe für die Änderungen von 1&1 mal zusammen gefasst. Ich denke, man kann 1&1 keinen Vorwurf machen, wenn sie von anderen Admins erwarten, dass diese die MailServer und DNS-Zonen entsprechend der gültigen RFC konfigurieren, oder?

…und schreibt in seinem Blogartikel:

In vielen Fällen konnte der 1&1-Support den Leuten weiterhelfen: SPF korrekt(!) konfigurieren und / oder den MX record der Absender-Domain auf einen A record zeigen lassen – niemals auf einen CNAME.

Dass die Konfiguration mit dem MX-Record, der auf einen CNAME-Record zeigt, falsch ist, darüber besteht kein Zweifel.

Leider zeigte sich der 1&1-Support mir gegenüber überhaupt nicht hilfreich, und die (ja neu eingeführten) Anforderungen an die DNS-Einstellungen waren auch nicht Dokumentiert. Man hätte ja auch das konkrete Problem in die Fehlermeldung schreiben können, so wie diese Seite es verspricht (auf genau der Seite hat 1&1 übrigens inzwischen die DNS-Anforderungen gut verständlich dokumentiert — das war vor drei Wochen noch nicht so, aber besser spät als nie).

Dann schreibt er weiter:

Mailserver die CNAMEs als MX records akzeptieren verhalten sich nicht RFC-konform und sollten korrigiert oder korrekt konfiguriert werden.

… und das halte ich für falsch. Der Abschnitt 2.3.5 in RFC5321, der Formvorschriften für einen „Domain Name“ macht, impliziert IMHO nicht, dass deren Einhaltung beim Empfang einer Mail zu überprüfen ist; es handelt sich hierbei vielmehr um eine reine Antispam-Maßnahme (mit derselben Argumentation müsste man sonst auch alle Mails mit von Outlook oder Exchange verkorkstem Header-Encoding verwerfen).

Einer der Grundsätze, auf denen die Internetprotokolle aufbauen lautet schließlich „be conservative in what you send, be liberal in what you receive„. Das wird leider viel zu oft vergessen.

Kategorien
Blog

421 invalid sender domain, possibly misconfigured

Vom 6. Juli an erhielt unser Mailserver in der Arbeit für alle Mails, deren Mail Exchanger mx*.schlund.de oder mx*.kundenserver.de ist, die Fehlermeldung „421 unable to verify sender domain“. Diese Mailserver gehören alle zu 1&1.

Ein Wenig Suche im Web brachte mich auf diese Hilfseite:

  • E-Mails müssen den in RFC 2822 definierten Standards genügen. >> http://www.rfc-editor.org/rfc/rfc2822.txt
  • Die E-Mail darf nicht direkt an unsere MX-Server aus Dialup-Netzen heraus zugestellt werden.
  • Ein Reverse DNS-Eintrag (FQDN) des einliefernden Servers muss vorhanden sein. >> http://de.wikipedia.org/wiki/Reverse_DNS
  • Ein sinnvolles und plausibles HELO/EHLO (Format des Anfangs einer E-Mail im Versandprotokoll) im Sinne von RFC 2821 muss gesendet werden. >> http://www.rfc-editor.org/rfc/rfc2821.txt
  • Wir prüfen auf Wunsch des Kunden die >>  SPF Records. Die Absenderadressen von weitergeleiteten E-Mails müssen daher mittels >>  SRS umgeschrieben werden.
  • Der einliefernde Server darf kein Open Proxy sein, das heisst, er muss gegen unberechtigten Zugriff geschützt sein.
  • Im Fehlerfall geben wir immer eine aussagekräftige Fehlermeldung im SMTP-Dialog zurück. Bitte verfolgen Sie im Zweifelsfall Ihr Log zurück bis zum ersten Auftreten eines Fehlers.
  • Wir prüfen verschiedene etablierte RBLs (Blacklistdatenbanken). Sollte eine davon einen Treffer enthalten, gibt der SMTP-Dialog weitere Auskunft.

Nach meinem Dafürhalten sollte die Domain soweit in Ordnung sein:

desenberg:~# host 217.110.66.114
 Name: desenberg.advanced-solutions.de
 Address: 217.110.66.114
desenberg:~# host desenberg.advanced-solutions.de
 desenberg.advanced-solutions.de A       217.110.66.114
desenberg:~# host -t mx as-gmbh.com
 as-gmbh.com             MX      0 desenberg.advanced-solutions.de

SPF kommt für die Domain nicht zum Einsatz, und alle anderen Sachen (RFC-Formate, kein offenes Relay, keine Einwahlsadresse,…) sind natürlich auch erfüllt. Ich konnte mir die Ablehnung also nicht erklären.

Nach Frage auf twitter sprang mir @Miss_1and1 (die hat sich inzwischen umbenannt) zur Seite, verriet mir eine Support-eMail-Adresse, an die ich schrieb, und das Problem verschwand (wörtlich! Im Moment des Abschickens der Mail an den Support gingen andere Mails auch raus).

Seit vorgestern ist das Problem wieder da (wenn auch diesmal mit einer leicht anderen Fehlermeldung):

"421 invalid sender domain, possibly misconfigured"

Hat irgendjemand einen Tipp, was an den DNS-Einträgen zu beachten ist, damit 1&1 die für „gültig“ hält? Oder spielt 1&1 da nur an seiner Konfiguration rum? Hier stehen inzwischen über 70 Mails an Kunden und Geschäftspartner in 31 verschiedenen Domains in der Warteschlange.

Kategorien
Blog

Achtung! TLD != IP-Adresse

Der Stern schreibt:

Es ist eine kleine Revolution im Internet: Künftig können Internet-Adressen frei gewählte Endungen bekommen. Neben den bisher üblichen Namen kann es künftig auch Städte- oder Firmen-Namen geben.

[…]

Im Hintergrund der Freigabe steht die Sorge, das nach dem bisherigen System in den kommenden fünf Jahren die Adressnamen hätten knapp können. Im vergangenen Jahr sollen nur noch 17 Prozent der ursprünglich vorhandenen vier Milliarden Adressen verfügbar gewesen sein.

Da, liebe Leute, habt Ihr was verwechselt. Die 2^32 Dingsis, die da knapp werden, das sind die IPv4-Adressen, nicht die Namen (ist ja auch logisch, man kann ja mit a1.de, a2.de, a3.de, …, a5000000000.de locker mehr als 4 Milliarden Adressnamen erzeugen — und das nur unterhalb der .de-Domain).

Kategorien
Blog

Namensauflösung, ääääh…

Kann mir das hier einer erklären?

Schizophrenie
Der Standard-DNS-Server weiß von dem Rechner, der Resolver findet ihn trotzdem nicht. Wo liegt auf WiXP das Gegenstück zur /etc/nsswitch.conf? Windows bringt mich noch ins Grab!