While reading about DNS servers and BIND9, I came across the concept of Caching-Only DNS servers. I’m not going to go into great detail about how DNS works, but simply put, a Caching-Only DNS, well, caches DNS query results for the domain name being queried. The results are stored for a period of time known as the time-to-live, or TTL, which is specified on the name servers of the particular queried domain. Most computers and routers query the ISP’s DNS servers each time by default.

To really get a good understanding of how DNS works, I’ve found the following quite helpful:
– DNS and BIND (you can pickup a used copy for fairly cheap, or even get the previous version for even less!)
– DNS & BIND Cookbook (supplement to the above; has many great examples and configurations for various DNS setups)
– Otherwise there are many good resources online; I’ve used StackOverflow to help guide me in the right direction and many other web pages for help and information.

What you are going to need:
– A Computer to host the Caching-Only DNS server (I’ll be deploying this in a VM as there is no need for a powerful computer to run a small DNS server)
– A Linux distribution (I’ll be using Ubuntu Server 8.04)
– Some basic Linux knowledge as well as networking knowledge


Last time we covered a very basic setup. Multiple people have contacted me so far requesting an explanation on how to move towards a slightly more sophisticated authentication setup. Usually involving a php script to authenticate against. Maybe you want to use an existing mySQL or mariaDB database to set up users and channels? Fear not, this is not that complicated to start out with.

Server side configuration

Starting from this example, we set up a basic rtmp section:

rtmp {
  server {
    listen 1935;
	ping 30s;
	notify_method get;
	application stream {
	  live on;
	  on_publish http://yourdomain.com/rtmp_auth.php;
	  record off;


Most people who stream enjoy using services such as Twitch.tv or Ustream to deliver video to viewers, and that works well enough. But sometimes you want some more control over your stream, or you want other people to be able to stream to you, or you want to stream to multiple places, or any number of things that requires you to have access to an actual RTMP stream from an RTMP server. This guide will cover the very basics of setting up a simple RTMP server on a Linux computer. Don’t worry, it’s not too complicated, but having familiarity with Linux will certainly help.

A couple things you can do with your own RTMP server that you might be interested in:

Alright, so how do you do these kinds of things?


Wenn man in der Datei ~alice/.ssh/authorized_keys den mit ssh_keygen erzeugten Public-Key des Users bob einfügt und bob ist in der Gruppe, zu der die Datei ~alice/.ssh/authorized_keys gehört (typischerweise auch alice), dann darf die Datei ~alice/.ssh/authorized_keys keine Gruppen-Schreibrechte haben, sonst kann sich bob nicht passwortlos als alice anmelden. Das ergibt Sinn, man muss aber erst einmal drauf kommen. Am Besten setzt man die Rechte der authorized_keys-Dateien eh auf 600 (chmod 600 ~/.ssh/authorized_keys oder chmod go-rwx ~/.ssh/authorized_keys).

Wofür man solches wissen muss? Angenommen, einer Gruppe von Usern soll erlaubt werden, ein ganz konkretes Programm auch als User alice und nicht nur in der Gruppe alice ausführen zu dürfen, dann lässt sich dafür das viel (und oft aus falschen Gründen) gescholtene sudo nutzen, indem in /etc/sudoers mittels sudo visudo

%alice ALL=(alice) NOPASSWD:/home/alice/bin/asalice.sh

eingetragen wird. Damit wird dafür gesorgt, dass Mitglieder der Gruppe alice (%alice) das Programm ~alice/bin/asalice.sh mit

sudo -u alice /home/alice/bin/asalice.sh

ausführen dürfen. Dabei muss natürlich darauf geachtet werden, dass in asalice.sh keine Sicherheitslöcher beispielsweise durch less entstehen. (! in less ermöglicht beliebige Shell-Kommandos – dann als User alice).


Sie sind immer wieder in den Nachrichten. Häufig leicht zu knacken und die Top 10 besteht sehr oft aus „123456“.

Gut, „immer wieder“ ist gerade überzogen, aber zumindest einmal jährlich werden von IT-Security-News-Outlets wie „Netzpiloten“ oder „t3n“ die meistgewählten Passwörter gekürt. Unter den erwarteten Beiträgen wie „123456“, „password“ oder „letmein“ spiegelt sich darin ein kleines Problem wider:
Der Sinn von Passwörtern wird oft nicht von den Nutzern wiedergegeben.

Passwörter sollen nicht nur eure Facebook-Accounts schützen, sondern auch euer System, euren Zugang zum Online-Banking und generell alles, was mit Geld zu tun hat, sollte unbedingt mit einem starken Passwort gesichert werden.

Was ist ein starkes Passwort?

Das Konzept „Passwort“ in sich ist zu unsicher.
Eigentlich sollte man gar aufhören, von „Passwörtern“ zu reden.