Mastodon webhosting Archives - HermanRonk.nl

Plesk backup DNS (Slave-DNS-Manager)

Sinds kort heb ik de hosting van een aantal sites opnieuw ingeregeld. Hiervoor heb ik deze keer na jarenlang Directadmin gebruikt te hebben nu een keer voor Plesk gekozen. Tot op heden heb ik nog geen moment spijt gehad van mijn keuze en heb ik eigenlijk alles vrijwel direct werkend gekregen zoals ik dat wilde.

DNS was echter een van de dingen die op de Plesk server zelf goed werkte, maar het koppelen van de secundaire DNS server wilde niet helemaal werken zoals het hoort. Helaas bood het forum ook geen oplossing, maar na het nodige zoekwerk is het dan uiteindelijk toch gelukt :).

Mijn secundaire DNS server draait bij DigitalOcean in Canada (een deel van de sites worden veel in de VS en Canada gebruikt) en is een droplet van het goedkoopste type (grofweg $5 per maand). De machine hoeft ook niet schokkend veel te doen dus dat moet prima uit komen.

Qua OS heb ik afgeweken van mijn normale voorkeur voor Ubuntu, maar om voor mij nog steeds onduidelijke redenen heb ik het daar nooit op werkend gekregen. In dit geval heb ik de collectie CentOS 7 servers maar uitgebreid van 2 naar 3..

In plesk:

In Plesk maak ik gebruik van de “Slave-DNS-Manager” extension die je via de extension manager kan installeren.

Slave DNS Manager extension page

De configuratie in Plesk is verder niet heel complex, je opent de extension via de extension manager en drukt op de knop om een nieuwe slave toe te voegen:

Add slave to config

Op deze pagina staat ook een stukje voorbeeld configuratie, kopieer deze in een losse file, we gaan niet de hele config gebruiken, maar nemen er een paar stukjes uit over. De invoervelden wijzen verder voor zich.

Slave DNS Manager config example

Op de secundaire DNS server:

  • yum update
  • yum install bind bind-utils
  • systemctl stop named
  • vi /etc/named.conf

in /etc/named.conf maken we een aantal aanpassingen, een deel van de info kan je overnemen uit de voorbeeldconfiguratie uit de Slave DNS Manager uit Plesk en een deel moet je even zelf invoeren.

acl “trusted” {
**IP Adres Primaire DNS**;
**IP Adres lokale server**;
127.0.0.1;
};

options {
listen-on port 53 { 127.0.0.1; **IP Lokale server**; };
listen-on-v6 port 53 { ::1; **IPv6 Lokale server**; };
directory “/var/named”;
dump-file “/var/named/data/cache_dump.db”;
statistics-file “/var/named/data/named_stats.txt”;
memstatistics-file “/var/named/data/named_mem_stats.txt”;
allow-new-zones yes;
allow-transfer {trusted;};
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
auth-nxdomain no;

/* Path to ISC DLV key */
bindkeys-file “/etc/named.iscdlv.key”;

managed-keys-directory “/var/named/dynamic”;

pid-file “/run/named/named.pid”;
session-keyfile “/run/named/session.key”;
};

/*RNDC Key uit Primaire (Plesk) server*/
key “rndc-key-***” {
algorithm hmac-md5;
secret “****”;
};

controls {
inet * port 953 allow { ** IP Adressen primaire en lokale server, gescheiden door een ;**} keys { “rndc-key-***”; };
};

logging {
channel default_debug {
file “data/named.run”;
severity dynamic;
};
};
zone “.” IN {
type hint;
file “named.ca”;
};

 

include “/etc/named.rfc1912.zones”;
include “/etc/named.root.key”;

  • mkdir /var/named/
  • chown named:named /var/named/ -R
  • chmod 0770 /var/named -R
  • systemctl start name
  • reboot

Dit zou normaal voldoende moeten zijn, maar ik bleef authenticatie fouten krijgen vanuit de primaire DNS server (Plesk), deze server heb ik daarna nog een keer herstart en dat heeft uiteindelijk de problemen verholpen.

Ik heb me hier dan enkel gericht op het werkend maken van de slave DNS server, de vervolgstappen omvatten uiteraard het beveiligen van de server maar dat is buiten de scope van deze post.

Let’s encrypt

Sinds gisteren is Let’s Encrypt in public beta en daarmee dus ook voor iedereen beschikbaar. Nou zal dat niet iedereen direct wat zeggen, maar ik denk dat dit een ontwikkeling is die een grote verandering op het internet met zich mee zal brengen. Nou betreft het wel een verandering die voor 90% van de mensen niet zullen merken, maar dat maakt het niet minder belangrijk.

letsencrypt-logo_0

Wat veel mensen niet beseffen is dat verkeer van en naar een website in principe voor alle “hops” tussen jouw pc en de server vrij in te zien is. Voor banken zijn we al wel gewent aan het feit dat er een groen slotje bij de domeinnaam moet staan, maar bij veel andere websites denken we daar niet over na. Het gebruik van encryptie lost dat probleem op, het verkeer tussen de client en de server is met certificaten beveiligd en voor de tussenliggende systemen niet in te zien.

Het probleem is echter dat de certificaten hiervoor geld kosten, alhoewel ze niet heel duur zijn (12 euro per jaar grofweg) wordt het voor veel content niet echt als noodzakelijk gezien om de bezoeken te beveiligen. De complexiteit van het onderhouden van deze certificaten is echter een groter probleem. Niet alleen is het veel handwerk om een certificaat goed op je eigen server te installeren, maar het is ook nog eens iets wat je niet moet vergeten bij te houden (wederom handmatig).

Let’s encrypt brengt hier verandering in, niet alleen zijn de certificaten gratis, maar er wordt een tool meegeleverd die de hele aanvraag en implementatie voor je uitvoerd. Daarbij zorgt de tool ook voor een tijdige vervanging van de certifcaten wanneer de einddatum in de buurt komt (een “le” certificaat is 90 dagen geldig).

Het draaien van de tool geeft een wizard die er grofweg zo uit ziet:

Certificaat Aanvraag

En de rest gaat eigenlijk vanzelf, je kan nog even aangeven of de site zowel via HTTP als HTTPS bereikbaar moet zijn of enkel via HTTPS en dat was het dan.

Wanneer we dan controleren of het certificaat goed geïmplementeerd is zien we dat ook dat helemaal in orde is:

Certificaat Controle

Het mooie aan de automatische implementatie is ook dat er eigenlijk niets in de weg staat om dit ook bij shared hosting oplossingen te implementeren. Het gehele traject kan volledig geautomatiseerd worden en een gebruiker hoeft er dus helemaal niets aan te doen. Wat misschien wel nog een blokkade kan zijn is dat voor een groot aantal providers een aardig stukje omzet kan wegvallen doordat ze nu geen tussenpartij meer hoeven te zijn tussen de grote certificaat verstrekkers en de “consument”.

Voor het testen van dit soort zaken gebruik ik overigens meestal een VM bij Digital Ocean, het grote voordeel is dat je deze per uur betaald, wat een root voordeel is voor het even snel testen van nieuwe dingen. De bovenstaande link is overigens een referral link, die levert je 10 dollar aan start tegoed op (1 maand voor een server met 1 core en 1 GB ram). Mocht je mij geen extra tegoed gunnen kan je natuurlijk altijd zelf even het adres invullen als je een account wil :). De gebruikte testomgeving heb ik gebouwd op Ubuntu 15.10 met Apache, PHP en MySQL.