Uncategorized (8)

How to easily enable automatic DNSSEC in BIND9

I find most of DNSSEC howto’s unnecessarilly complicated and inefficient. Here I am going to desribe how to enable DNSSEC in BIND9 using its native automatic signing that doesn’t require any extra scripting.

This manual requires the zone to be dynamic – it will not work with static zone.

Step 1 – create the zone keys

Create a new directory in named / bind config folder, for example /etc/bind/dnssec and change its owner to user who is running bind daemon.

Enter the folder and execute these 2 commands to create zone and record signing keypairs:

dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE example.org
dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE example.org

Step 2 – configure zone

Now edit the zone configuration file and add 2 lines with key-directory and auto-dnssec, example of whole zone config follows:

    zone "bena.rocks" {
        type master;
        notify yes;
        file "/etc/bind/db.bena.rocks.conf";
        key-directory "/etc/bind/dnssec";
        auto-dnssec maintain;

Now run named-checkconf && rndc reload. It’s almost done.

Step 3 – enable signing

Finally tell BIND to load the keys and sign your zone:

rndc loadkeys example.org
rndc sign example.org

Unless anything goes wrong (bind logs are your friend) you just enabled automatic zone signing, you can check your zone – it should contain signed records now. All new records will be automatically signed too.

Letsencrypt kung-fu

Let’s encrypt CLI client is by far the most shittiest software ever invented, there is probably no doubt about it, but sadly, it’s the only interface that is supported, and unless you want to pay money for SSL certificate you need to live with that.

First of all – yes, their client (without asking or telling you) WILL run sudo and WILL use root and most likely WILL install garbage on your server that you don’t want to have there. If you never used letsencrypt client before, run it on testing VM first, before it desecrates your favorite web server with random garbage you don’t want there.

The letsencrypt client is written for dumb people, and it is based on undocumented black magic that I will try to uncover here a bit. The client basically works with a component called “certbot” which is a software that run on your server and does something to prove that you really own the domains for which you want to generate your SSL certificate. Because letsencrypt staff doesn’t want to bother you with technicalities they created this crap of a software to deal with them for you, in their own way, like it or not. It uses so called ACME (Automatic Certificate Management Environment) protocol to verify that you are owner. This thing is not a rocket science, and in a nutshell all it does is publish some data used to prove your ownership through your webserver, usually located on webroot/.well_known, their counter-party server will try to locate these by accessing your.domain/.well_known and in order to make it possible to verify your domain without modifications to your webserver, all you need to do is to create a central webroot and then make a symlink from all domain webroots to this one (just ln -s /var/www/letsencryptshite/.well_known /var/www/your.uber.tld/.well_known).

Once you do that, always pass these 2 parameters to their “software”:

--webroot --webroot-path /var/www/letsencrypt_shite

I also strongly recommend you to maintain a comma separated list of all domains for which you want to get your certificate and store it somewhere like /etc/letsencrypt/domains because you will need to provide this list very often.

Now a little cheat sheet:

Renewing all domains

This can even be in your cron

./letsencrypt-auto renew --webroot --webroot-path /var/www/letsencrypt_shite

You may need to restart / reload your web server after doing this, since the certificate will be overwritten, and Apache seems to be caching it somehow.

Adding or remove a domain and regenerate certificate

Modify your /etc/letsencrypt/domains list and run

./certbot-auto certonly --webroot --webroot-path /var/www/letsencrypt_shite/ --agree-tos --expand -d `cat /etc/letsencrypt/domains`

Common locations:

/etc/letsencrypt – root of this thing’s config

/etc/letsencrypt/live – symlinks to current certificates, that’s where you can find chains for your domains

Example apache config that uses letsencrypt cert

<VirtualHost *:80>
    ServerName bena.rocks
    DocumentRoot /var/www/bena.rocks

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/insw.cz/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/insw.cz/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/insw.cz/chain.pem
    ServerName bena.rocks
    DocumentRoot /var/www/bena.rocks


Why SPF doesn’t solve anything in regards of e-mail spoofing

If you ever thought that having an SPF record would effectively prevent anyone from spoofing a delivery of e-mail from your domain, you were terribly wrong. It wouldn’t. This whole “sender policy framework” is built on top of flawed ancient SMTP protocol that never was designed with slightest security in mind.

Majority of all e-mail clients will display value stored in “From” of e-mail header as a sender of your e-mail. That is exactly the “sender” that SPF doesn’t check. SPF is checking the “envelope sender” which is something entirely else, and sadly, almost never displayed anywhere in e-mail clients.

Basically, delivering an e-mail on behalf of anyone that would pass SPF is as easy as spoofing the From in the mail header and sending this from a mail server that has its own IP in its own SPF record.

This 3rd domain would be a part of “envelope sender” which is however not visible anywhere in the mail client (unless you open original source) and SPF check would check against this domain. The spoofed domain that would be visible in mail client wouldn’t be checked anywhere though and most of users would be easily tricked by this.

There are ways to make this harder to do, such as implementing DMARC policies or DKIM, but again, most of regular users would easily be tricked. Nobody cares if e-mail was digitally signed or not, unless you explicitly tell them to do that.

As of now there is only one working protection when it comes to e-mails and that is: DO NOT TRUST THEM. Whatever e-mail you received, from whoever, may be a fake. Even GPG signature could be a fake if someone steals the private key of victim somehow. So yes, if someone is asking you for money in e-mail, or whatever else, better call them, or meet them in person. It can save you lot of troubles.

systemd cheat sheet

Services overview and unit files

# Show running units

# Show status of OS
systemctl status

# List all units
systemctl list-units

# Display failed units:
systemctl --failed

The available unit files can be seen in /usr/lib/systemd/system/ and /etc/systemd/system/

Start / stop

systemctl start unit
# samples
systemctl start apache2.service

# stop
systemctl stop apache2.service

# restart
systemctl restart unit

# reload
systemctl reload unit

# Check whether a unit is already enabled or not:
systemctl is-enabled unit

# Show the status of a unit, including whether it is running or not:
systemctl status unit

Checking status

By default it should be possible to view the output of every unit using journal – journalctl

# Display logs of unit
journalctl -u unit

Enable / disable service

# Enable a unit to be started on bootup:
systemctl enable unit

# Disable a unit to not start during bootup:
systemctl disable unit

# Mask a unit to make it impossible to start it:
systemctl mask unit

# Unmask a unit:
systemctl unmask unit

Power management

# Reboot
systemctl reboot

# Shut down and power-off the system:
systemctl poweroff

# Suspend the system:
systemctl suspend

# Put the system into hibernation:
systemctl hibernate

# Put the system into hybrid-sleep state (or suspend-to-both):
systemctl hybrid-sleep

Modifying system

  • /usr/lib/systemd/system/: units provided by installed packages
  • /etc/systemd/system/: units installed by the system administrator

When you modify the unit file, you always need to run:

systemctl daemon-reload

See https://wiki.archlinux.org/index.php/systemd for more information

New blog

Heya, I have decided to move from blogger to my own blog for couple of reasons. The biggest one was that blogger doesn’t support custom code formatters and I often need that when I am posting source codes.

I also got my own domain now 🙂

The contents of previous blog were imported back here and I will post new stuff here only.

Thank you for using my blog, I hope you will find it useful!

How to encrypt whole filesystem on Gentoo using LUKS

I struggled for days following outdated and incorrect gentoo wiki: https://wiki.gentoo.org/wiki/DM-Crypt_LUKS

Finally I figured out how to do that so I will share it here for future reference. This guide however may not work on future gentoo versions.

Note that primary difference between suggestions on Gentoo wiki is that disk is encrypted with -d – option which is necessary for it to work with dracut and genkernel generated initramfs which always use that option to open it.


In this guide I have 1 physical disk with 2 partitions:
/dev/sda1 for /boot
/dev/sda2 for LVM with 2 LV’s
* root – /
* swap

Step 1:

Create an image of whole current filesystem for backup purpose

Step 2:

Before you reboot, prepare your initramfs so that it’s ready to work with luks, I am using dracut, there is high chance you won’t boot after encrypting so prepare it for debugging as well:

dracut -a crypt –install “bash vim”

Step 3:

Create an image of your root fs (boot from livecd)

dd if=<device> of=original_fs.iso

Store it on external disk.

Step 4:

Create a keyfile you will need to decrypt the filesystem, you can store this file on /boot partition, it will be encrypted with password:

openssl rand -base64 48 | gpg –symmetric –cipher-algo aes –armor > key.gpg

Step 5:

Encrypt sda2, this will wipe all data on it:

gpg -qd /boot/key.gpg | cryptsetup luksFormat -d – /dev/sda2

Step 6:

Mount the device and setup LV disks

gpg -qd /boot/key.gpg | cryptsetup luksOpen -d - /dev/sda2 encrypted
pvcreate /dev/mapper/encrypted
vgcreate vg /dev/mapper/encrypted
lvcreate vg -n root -L <size>
lvcreate vg -n swap -L <size>

Restore the fs:

dd if=original_fs.iso of=/dev/mapper/vg-root 

Step 7:

Mount fs

mount /dev/vg/root /mnt 

Now update /etc/fstab to contain proper stuff

Step 8:

Update /etc/default/grub and add kernel parameters:

rd.luks.uuid=<UUID of /dev/sda2> rd.luks.key=key.gpg:/dev/sda1:/dev/sda2

Now reboot and pray. It may fail, if you wait about 5 minutes, dracut might fall into recovery console which you can use to investigate what is wrong, try to mount the device by hand.

Package managers for UNIX cheat sheet


Update the manifests

apt-get update

Update the packages

apt-get upgrade

or sometimes this is also needed to resolve very complex dependency issues

apt-get dist-upgrade

Install new package

apt-get install foo

Remove a package

apt-get remove foo


apt-get purge foo # this will remove the configuration files (some)


Update the manifest

emerge --sync

Update the packages

emerge --update --deep --with-bdeps=y @world

Rebuild all packages

emerge -e @world

Install new package

emerge foo

Remove package

emerge -C systemd

Install binary package

You need to have some binary package server

emerge --getbinpkgonly evolution

Howto install xen server on X10SLL-F board

I recently got a new server board from Super micro. It’s quite a nice board except for few issues. One of them was that I figured out that citrix xen server is officially unsupported on this board. Well, why?

The installer which is written in python crashes during startup as it tries to launch some command that dumps serial port information. This command returns non 0 RC and whole installer crashes and that is a reason for it not to work.

There is however super easy work around. The hardware itself is supported by XEN, so from technical point of view there is nothing else that this bug in python installer preventing xen from running there. All you need to do is this super nasty trick:

Install XEN on a supported hardware, it can even be a virtual box if you don’t have spare server. Then put the disk with fully installed OS into server. It should boot up just fine.