Tag Archives: DNS

Blocking the piratebay

In a previous post it became clear that censorship in The Netherlands has started. Due to the nature of the Internet and how it has been implemented in most lands, it means there is no central point of control to stop all to an IP-address. This means every network owner needs to take action, but how do they do it?

In the case of thepiratebay.org it looks like it has been done by manipulating DNS-answers. The first attempt is just using the DNS-resolver from the internet access provider and the second is an attempt using Google public resolvers.

$ dig thepiratebay.org
; < <>> DiG 9.8.1 < <>> thepiratebay.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 6811
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;thepiratebay.org.		IN	A
thepiratebay.org.	10	IN	A
thepiratebay.org.	10	IN	TXT	"Forged by XS4ALL for Stichting B.R.E.I.N."
;; Query time: 19 msec
;; WHEN: Sat Feb  4 08:15:35 2012
;; MSG SIZE  rcvd: 104
$ dig thepiratebay.org @
; <<>> DiG 9.8.1 < <>> thepiratebay.org @
;; global options: +cmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 4847
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;thepiratebay.org.		IN	A
thepiratebay.org.	2596	IN	A
;; Query time: 26 msec
;; WHEN: Sat Feb  4 08:16:16 2012
;; MSG SIZE  rcvd: 50

By just changing DNS resolvers on the client or internet router the censorship can be bypassed for now. The question remaining is how long this is going to stand when the first article is published by a big computer magazine on how to bypass it. Or when sites also get an .onion to bypass DNS completely.

Debian Wheezy and GNOME 3.2

The migration of GNOME toward version 3.0 in Debian earlier this year wasn’t very successful in the beginning, but a lot of bugs where solved during the summer. GNOME 3.0 made it into Wheezy during the release of 3.2 and maybe for the better. Now only a few months after the release of GNOME 3.2 almost all packages have been uploaded to experimental or unstable, and most of them even already migrated to testing.

But what brings GNOME 3.2? A lot of people are unhappy and some of these points are valid and need to be fixed. Others can be discussed if they are true. One thing that changed in 3.2 is how GNOME interacts with your address book and your instant messaging accounts. Connections to instant messaging networks are automatically being started when you log in. This also reflects in the search screen when you type in a friends name and you direct see his connection status.

GNOME Online Accounts is another example of making things simpler for the user. Currently it only works for Google, but I really hope current proposals with querying the right SRV-records in DNS are also going to be part of GNOME in a future release. For now GNOME Online Accounts setups up multiple Google services up like Mail, Calendar, Chat, Documents and Contacts with a single authentication token. Different services don’t have to maintain and store the credentials in GNOME Keyring or in still in there own way. Hopefully there will come a solution for Liferea which still stores te users password plain-text in the configuration file.

Other third-party applications like Simple Scan, Shotwell and Deja-Dup are slowly making there way into becoming part of GNOME. I can’t wait to see what is going to happen with the GNOME 3.4 release as both Epiphany and Evolution are going to have some major work done to them. A switch to Webkit 2 and ending the usage of GtkHTML in Evolution. Hopefully after this Epiphany can replace Firefox completely on my desktop.

It is good to see the progress GNOME is making into becoming an interface for cloud services by simplifying the configuration for users, but also separating data from applications more and more. I can’t wait to see how GNOME Document is going to evolve, but two other things still open is a good solution for RSS-feeds and chat-logs as Empathy is still storing them on disk and isn’t able to use logs stored by Google for example.

In the end I’m happy with GNOME 3.2 in Debian Testing right now and Debian on my workstation is back to it’s weekly testing upgrade schedule as most parts are working. I even think that I will continue to do this during the 3.4 release as most of the GNOME dust has settled. Maybe I make an exception for both AbiWord and Gnumeric when they switch to GTK3 and hopefully also better OpenDocument support.

When do other banks start to publish SPF records?

In the past a lot of phishing was going towards customers of the Dutch bank Postbank. It continued for years and when the bank finally merged with ING the phishing attacks adopted the new name quickly. In both cases the bank was publishing closed SPF resource records in DNS so third party systems could determine of an e-mail really came from Postbank or ING. And with a few rules for SpamAssassin for example most of the phishing can be stopped.

The last months phishing attacks for both Rabobank and ABN Amro increased a lot. Most phishing e-mails from Rabobank are being caught by the bayesian filter for now, but for ABN Amro aren’t always detected. This makes me wonder why those banks don’t publish SPF resource records in DNS? Is it really that difficult? Or is the cost for fraude smaller, then for a denied e-mail?

IPv6 voor mailverkeer

Afgelopen woensdag was het World IPv6 Day en in navolging daarvan werden een aantal maildomeinen voorzien een AAAA-record in DNS naast het gebruikelijke A-records. Hiermee wordt zowel een IPv6 als IPv4 adres geadverteerd om mail op af te leveren. Als eerste zijn de spamtrap-domeinen om gegaan afgelopen woensdag en afgelopen zaterdag zijn enkele andere kleine domeinen omgezet. Nu de time-to-live op de oude records is verlopen komt vandaag langzaam de e-mailstroom over IPv6 op gang.

Voorlopig lijken spammers IPv6 links te laten liggen, maar hoe lang dat zo zal blijven is de vraag. Hiermee komt ook gelijk de vraag of een DNSBL voor mail over IPv6 opzetten nog wel zinvol is. Een computer met IPv6 Privacy Extensions enabled wisselt om de zoveel uur van IPv6-adres en zou dus eigenlijk eigenlijk afdwingen om op network-niveau te gaan blacklisten en misschien ook wel om te gaan whitelisten en greylisten. Hiermee komt eigenlijk ook de vraag hoe valide Spamhaus nog is en wat voor impact dit gaat hebben op de Bayesian filtering opstelling die nu zijn werk doet.

World IPv6 Day

Of de wereld vergaat op de dag dat we door IPv4-adressen zijn of zo goed als blijft de vraag, maar de uitrol van IPv6 wil eigenlijk ook niet echt starten helaas. Vooral de thuisgebruikers zitten redelijk vast aan IPv4-only en dat is te merken, want steeds meer servers to server verbindingen kunnen redelijk goed op IPv4 en IPv6 plaats vinden. Oa de protocollen DNS en SMTP zijn daar zeer geschikt voor en eindgebruikers merken er weinig van als er problemen zouden optreden.

Voor de mensen met IPv6 op hun desktop is 8 juni 2011 de grote testdag aangezien het dan World IPv6 Day is. Een dag lang sites die connectiviteit testen doen door AAAA-records te publiceren in DNS en te kijken waar er mogelijk problemen zitten in de connectiviteit. Of er daadwerkelijk ook echt grote problemen zullen ontstaan blijft de vraag en voorlopig is de lijst van deelnemers al erg groen of terecht rood.

Voorlopig is deze blog nu ook via IPv6 bereikbaar en hoogstwaarschijnlijk zal dat ook zo blijven of er moeten serieuze issues zijn. Daarbij de komende paar dagen ook een aardige widget erbij om te tonen hoe je verbinding maakt, maar het nerd-gehalte is te hoog om die een permanente plek te geven.

Eerste stapjes in ENUM

Tijdens de upgrade van een Fritz!Box naar de laatste versie van de firmware verdween de optie uit de interface om ENUM te gebruiken bij het bellen. Hierbij kwam de vraag of ENUM daadwerkelijk wel gebruikt wordt en begon de zoektocht naar resource records in DNS. En hier komt de uitdaging, want hoe controleer je welke records er allemaal zijn behalve ze allemaal op te vragen?

Maar wat is ENUM nu precies en waarom is het zo belangrijk voor de prijsbewuste Hollander? Waar vroeger alles over een koperdraad ging, gaat tegenwoordig steeds meer over het hippe VoIP, want dat zou kosten besparen. Helaas is dat voornamelijk voor de telefonie-aanbieder en niet voor de klant, want nog steeds worden dezelfde tarieven gerekend als in het tijdperk dat dedicated circuits in het telefonienetwerk werden opgezet voor elk telefoniegesprek. Met VoIP kunnen meer gesprekken over minder lijnen en in kleinere centrales en op meer centrale plaatsen.

Zeker in het tijdperk van Internet waarbij steeds meer mensen met elkaar kunnen communiceren voor een vast tarief wordt het probleem duidelijk. Waarom zou je nog betalen voor het gebruik van telefonienetwerk als je het ook over Internet kan sturen? Dit is waar huiscentrales in beeld komen die telefonieverkeer met behulp van ENUM direct over Internet kunnen sturen naar de ontvanger in plaats van via het dure telefonienetwerk waar je betaalt per minuut, seconde of tik en alles daar tussen. Dit alles door de juiste resource records op te nemen in DNS en bij zowel de verzender als ontvanger de juiste apparatuur te hebben.

Maar hoe verifieer je welke records er allemaal zijn? Het eigenlijke antwoord is door gewoon DNS te bevragen, natuurlijk wel in alle redelijkheid, en kijken welke entries allemaal bestaan. Dit is natuurlijk niet netjes, maar het is helaas voorlopig de enige manier. Een collega gaf aan dat zijn telefoonnummers waren opgenomen voor ENUM en na enig zoeken kwamen we tot een nare verrassing. Want naast het toplevel domein e164.arpa waarin ENUM is geregeld blijken er ook andere aanbieders te zijn zoals e164.org. Helaas zijn er maar weinig partijen die die alternatieve aanbieders bevragen voor telefoniegegevens en of het verstandig is om ze te vertrouwen en gebruiken laat ik even in het midden.

Terug bij af, want alternatieve diensten zijn leuk, maar of ze ooit mainstream zullen worden blijft de vraag. Na enige verder zoek, want records om te valideren dat een resolver werkt met ENUM lijken er niet te zijn, kwam ik op een voorbeeld van een Engelse aanbieder. Een query met dig leverde het volgende op en brengt ENUM al een stapje dichterbij.

$ dig naptr
; < <>> DiG 9.7.3 < <>> naptr
;; global options: +cmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 50865
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; ANSWER SECTION: 60 IN	NAPTR	10 6 "u" "E2U+sip" "!^.*$!sip:9876543@sip.bol.bg!" . 60 IN	NAPTR	10 7 "u" "E2U+loc:geo" "!^.*$!geo:42.6911,23.3254!" . 60 IN	NAPTR	10 5 "u" "E2U+ft:ftp" "!^.*$!ftp:ftp.bol.bg!" . 60 IN	NAPTR	10 3 "u" "E2U+web:http" "!^.*$!http:www.bol.bg!" . 60 IN	NAPTR	10 4 "u" "E2U+mailto" "!^.*$!mailto:info@bol.bg!" .
;; Query time: 1010 msec
;; WHEN: Mon May 16 22:12:32 2011
;; MSG SIZE  rcvd: 327

Nu we een goede verificatie van records in DNS hebben gevonden wordt het dus tijd om oa de netnummers van Nederlandse steden te gaan scannen in DNS. Er zit gelukkig voldoende structuur in de nummering en is grotendeels openbaar door de uitgifte door Opta. Want los van de kosten zit er ook een privacy-aspect aan vast, want direct communiceren met een andere centrale over bv TLS verkleint de kans op meeluisteren cq meekijken van overheid en telefonie-aanbieders.

RFC 5006 ondersteuning

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)
nameserver fd00::21f:3fff:fe30:4ff0
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?

Google Public DNS

Diensten in de cloud zijn leuk natuurlijk, maar soms doen ze dingen die je echt niet wilt. Dit kan zowel bewust als onbewust gebeuren. Bij OpenDNS.com zagen mensen al leuke dingen met het automatisch corrigeren van bepaalde fouten. Maar ook de vraag komt gelijk waarom we vanuit Europa onze DNS zouden uit besteden aan een Amerikaans-bedrijf. Er zijn bepaalde juridische problemen waar de mensen achter EDRI in het verleden al een paar keer antwoord op hebben gegeven.

Vandaag was het de beurt aan Google Public DNS, want de beheerders van het Franse topleveldomein merkte op dat het arpa-domein niet kon worden geresolved via Google Public DNS. Nu lijkt dit op zich geen probleem, want de dienst is bedoelt voor oa thuisgebruikers. De vraag komt wel wat er nog meer niet goed werkt en of dit op zet is of niet. Daarbij komt de vraag wat je allemaal wel en niet moet outsourcen naar een cloud. Zeker met protocollen zoals DNS die juist zijn ontwikkelt om te blijven werken in de meest vreemde situaties.

DNS meldingen in logfiles

Nu DNSSEC langzaam zijn intrede doet wordt het ook tijd om strikter naar de fouten te kijken die opdoemen in logfiles. De meldingen die oa voor DNS worden gegenereerd zullen voor DNSSEC ook voor de nodige problemen zorgen. Het is misschien nu de tijd om dingen structureel te gaan oplossen.

In een logfile staat de volgende melding en wat er uit is op te maken is dat de nameserver op IP-adres de verbinding niet aanneemt. Ook is af te lezen dat er een verzoek wordt gedaan voor de nameserver records voor domein cordaidke.org.

Feb 1 22:35:43 ns-cache2 named[9352]: connection refused resolving 'cordaidke.org/NS/IN':

Dus laten we beginnen om te kijken waar dingen fout gaan. De eerste stap is om te kijken of alle nameservers goed werken, zodat we deze kunnen gaan gebruiken bij het onderzoek. De nameserver records voor een domein komen ook uit de bovenliggende zone in de vorm van glue records. Er is dus altijd achter te komen wat de officiële nameserver records zijn.

$ dig +short cordaidke.org ns

Nu duidelijk is welke officiële nameservers er zijn bevragen we eerst dns1.thebook.com of deze op de hoogte is van de nameserver records voor domein cordaidke.org. Hiervoor komt net hetzelfde antwoord als ook via de org-zone is verkregen mbv de glue records. Nu we hetzelfde doen met dns2.thebook.com dan krijgen we helaas geen antwoord, maar wel een bevestiging dat de nameserver niet kon worden bereikt.

$ dig +short cordaidke.org ns @dns1.thebook.com.
$ dig +short cordaidke.org ns @dns2.thebook.com.
;; connection timed out; no servers could be reached

Sommige mensen op deze wereld plaatsen RFC1918 adressen in DNS om zo een soort splitbrain/view te bouwen voor hun DNS-infra. En het mag duidelijk zijn waarom RFC1918 adressen nooit gerouteerd zullen worden op Internet. Een snelle controle laat dan ook zien dat het geldig IP-adres lijkt, maar bij het kijken of de machine ook daadwerkelijk reageert levert een negatief beeld op.

$ dig +short dns2.thebook.com a
$ ping -c 4 dns2.thebook.com
PING dns2.thebook.com ( 56(84) bytes of data.

--- dns2.thebook.com ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3023ms

De reden waarom geen verbinding kan worden gezocht kunnen er vele zijn, maar om uit te sluiten dat het aan je huidige verbinding ligt is het verstandig om vanaf een andere locatie ook een soort gelijke test uit te voeren. Bij dit incident lijken er routering problemen te zijn in het netwerk van The Planet, maar mocht het aanblijven dan kan het verstandig zijn om contact op te nemen met de tech-c van de betreffende zone.

DNSSEC voorbereidingen

Z’n kleine acht maanden geleden deed DNSSEC zijn intrede op bepaalde virtuele machines en daar volgde een post van. Nu z’n kleine acht maanden verder heeft DNSSEC met DLV op sommige resolvers zijn intrede gedaan. Helaas heeft de huidige opstelling nog geen ondersteuning voor NSEC3, omdat BIND 9.5.1-P3 wordt gebruikt. Hopelijk gaat dat in de komende maanden veranderen door de overgang naar de BIND 9.6 of 9.7-serie en net op tijd voordat de root-zone wordt getekend.

De volgende stap die recentelijk is ingezet is om zonefiles structureel op fouten te controleren. Door zones beter en strikter te gaan controleren zouden deze zometeen minder problemen moet geven als deze gesigned moeten worden. De checks die BIND uitvoert gaan dus stelselmatig van warn naar fail, om zo RFCs beter na te leven. Een MX-record die naar een CNAME verwijst zou dus niet meer bij de signer uit moeten komen bijvoorbeeld.

Hiermee komt ook het genereren van de sleutels in beeld, maar ook de key rollover en het periodiek ondertekenen van zones. Er staat de komende tijd nog voldoende op de agenda en ook om over te schrijven.