Gisteravond werd DNSSEC ingevoerd voor de root-zone, maar vlak voor de invoering kwam nog een foutje in BIND 9.7.1 naar boven. Dit mocht helaas de pret niet drukken en wat sommige voorspelden met het einde van de wereld is ook niet uitgekomen en zijn de eerste ccTLD en non-ccTLD opgenomen met een DS resource record.
De tijd is dus gekomen om te kijken om van DLV af te gaan stappen en kijken of de resolving correct blijft werken. De tijd is dus ook gekomen dat SIDN binnenkort DNSSEC gaat ondersteunen, want de belofte was om dit een maand na de root-zone te gaan ondersteunen.
Helaas werken sommige oplossingen niet correct zoals de resolver in de Fritz!Box. Bij het opvragen van de nameservers van de root-zone met het verzoek om DNSSEC te gebruiken besluit de firmware om op slot te gaan voor een paar minuten. Er is een bugreport naar AVM gegaan en hopelijk komt er binnenkort een update.
De vraag die ook al bij IPv6 kwam is hoe lang het nog gaat duren voordat het mainstream gebruikt kan worden. Want veel verouderde oplossingen worden nog steeds verkocht en zolang is het nog niet geleden dat oa SpeedTouch-modems alleen maar A en CNAME records konden verwerken.
Als een eerstejaars ben ik sinds jaren weer in de autocommit grap van database getrapt. Om een of andere reden bleven de tupels netjes in de tabel zitten. Dit terwijl de query direct met psql uitgevoerd wel netjes zijn werk deed. Dus maar eens in de documentatie van psycopg2 gedoken om te zien wat er mis was met de volgende Python-code.
1
2
3
4
5
| curr = conn.cursor()
try:
curr.execute("""delete from tabel where x > 2""")
except Exception, e:
exit(1) |
Het antwoord was helaas snel gevonden en deed me terug denken aan de eerste stappen op Oracle. Een dikke 15 jaar geleden, dat wel. De bijgewerkte code hieronder vertelt eigenlijk wel het verhaal.
1
2
3
4
5
6
7
| curr = conn.cursor()
try:
curr.execute("""delete from tabel where x > 2""")
conn.commit()
except Exception, e:
conn.rollback()
exit(1) |
Ik heb me laten misleiden door de autocommit bij andere modules binnen PHP en Perl als een eerstejaars. Want daar stopt autocommit op het moment dat je een transactie start, maar hier moet alles worden gecommit. Dit doet met denken of er dirty read/write bugs zijn te vinden in sommige applicaties die autocommit doen.
Sinds enige tijd doe ik mee aan de IPv6-pilot van XS4ALL om gebruik te kunnen maken van IPv6 zonder dit via een extra tunnel te doen. In een recente update, versie 54.04.81-17599, voor oa de Fritz!Box 7270 van AVM is de ondersteuning voor RFC 5006 goed aangepakt. Helaas staat deze optie standaard uit, maar wel begrijpelijk om potentiële problemen te voorkomen met minder goed werkende netwerk hardware. Gelukkig zijn zowel MacOS X als vele Linux distributies klaar voor RFC 5006.
De vraag alleen is wat heb je aan RFC 5006? Het ligt eigenlijk in de provisioning van de nameservers die kunnen worden gebruikt als resolver. Met de komst van IPv6 is een DHCP-server eigenlijk niet meer nodig en blijft de vraag over hoe je sommige configuratie-items gaat zetten. En hoewel RFC 5006 een smerige hack lijkt is het eigenlijk wel netjes, want er zijn voorzieningen om bepaalde uitgiften te laten ondertekenen in IPv6. Hiermee gebruikt de client alleen gegevens met het juiste signature en is het eigenlijk veiliger dan vele DHCP-oplossingen die nu binnen bedrijven staan, maar een daadwerkelijke bruikbare oplossing laat nog op zich wachten.
Het aan de praat krijgen op bv Debian of Ubuntu is vrij simpel met de volgende opdracht.
$ sudo apt-get install rdnssd resolvconf
Als je nu reboot en kijkt in /etc/resolv.conf krijg je bv het volgende te zien:
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver fd00::21f:3fff:fe30:4ff0
nameserver 192.168.178.1
search fritz.box
Wat nu nog overblijft is NTP wat met behulp van NTP-broadcasting gedaan zou kunnen worden, maar hier kleven wel nadelen aan. Want hoe kan je de broadcaster vertrouwen dat hij de juiste tijd geeft? Hoor ik hier een oplossing in DNSSEC?
Bij het lezen van idee #25103 op de Ubuntu Brainstorm-site kwam de vraag hoever Debian dit nu heeft opgelost. Zeker aangezien Debian de moederdistributie van Ubuntu is en ze enige tijd geleden al waren overgegaan op een GeoDNS oplossing voor sommige sites.
Een brand, een zware verstoring en een update van OpenOffice.org heeft ervoor gezorgd dat model van security.debian.org anders moest. Het moest van een enkele server naar een schaalbare oplossing gaan zonder daar de gebruikers mee op te zadelen. Dit is gelukt aangezien security.debian.org nu mbv GeoDNS en HTTP-polling voor iedereen bereikbaar is gemaakt door een bereikbare mirrorserver in de buurt van het gebruiker aan te bieden.
Voor de algemene repository is de urgentie wat minder groot, omdat de gebruiker zelf kan kiezen in welk land de mirrorservers moeten worden benaderd. De vraag blijft of deze manier blijft schalen, want er zal altijd wel ergens een server onbereikbaar zijn door werkzaamheden. De Nederlandse mirror is daar geen uitzondering van, maar voor gratis hosting moet je iets over hebben. En waarom zou een andere server dit werk niet “transparant” kunnen overnemen?
Een klein project loopt nu om te testen of te kijken wat de meest ideale manier is om dit ook voor de normale mirrors van de repository te doen. Gelijk komt hier het probleem naar voren dat niet alle mirrors alle architecturen aanbieden, maar iedereen met een i386 of amd64 installatie zou overal zijn packages moeten kunnen krijgen. De aanpassing aan sources.list zoals hieronder is vrij simpel.
deb http://cdn.debian.net/debian/ testing main
deb-src http://cdn.debian.net/debian/ testing main
deb http://security.debian.org/ testing/updates main
deb-src http://security.debian.org/ testing/updates main
Nu al enige tijd staat cdn.debian.net in mijn configuratie voor APT en ik moet zeggen dat ik voorlopig tevreden ben. Hopelijk wordt dit project verder uitgewerkt en opgenomen in zeg Debian 7.0, maar dan moet 6.0 wel eerst uitkomen natuurlijk.
Er is veel te doen over HTTP versus HTTPS en met de “gratis” SSL-offloaders in de systemen van Sun Microsystems met de UltraSPARC T1, T2 en T2+ processor wordt het interessant om af te stappen van HTTP. Gelukkig hebben oa Intel-processoren optimalisatie voor oa AES en is met de juiste aanpassing aan het besturingssysteem en middleware zoals Apache mogelijk om SSL-verkeer sneller te laten afhandelen.
Nu kan je in de webapplicatie inbouwen dat dit moet gebeuren, maar als je massaal HTTP-verkeer naar HTTPS wilt migreren is het verstandiger om dit af te dwingen in de webserver. Zo ook voor een webmail-applicatie in dit geval waarbij de configuratie fouten kan opleveren en programmeurs snel fouten kunnen maken.
Door de volgende regels in de .htaccess-file te zetten in de documentroot van de website zal Apache tegen de webbrowser vertellen dat dit moet worden aangeleverd via HTTPS. Elke webbrowser die de HTTP statuscodes begrijpt zal dit vlekkeloos uitvoeren.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
Aan deze oplossing zit wel een performance penalty verbonden. De initiale opbouw naar de website kan iets langer duren door de redirect naar de HTTPS-site, maar de grootste penalty zal zitten in de .htaccess-file. Bij productie websites is het dan ook verstandig om dit op te nemen in de virtual host configuratie binnen Apache zelf en de ondersteuning voor .htaccess-files uit te zetten. Hierdoor hoeft we webserver minder de documentroot voor de website af te zoeken naar oa de .htaccess-file.
Recente reacties