Categories
Internet, Unix en security

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.

Categories
Internet, Unix en security

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 70.84.207.245 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': 70.84.207.245#53

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
dns1.thebook.com.
dns2.thebook.com.

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.
dns2.thebook.com.
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
70.84.207.245
$ ping -c 4 dns2.thebook.com
PING dns2.thebook.com (70.84.207.245) 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.

Categories
Internet, Unix en security Privacy & veiligheid

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.

Categories
Internet, Unix en security

RFC 4408, vaarwel

RFC 4408, gaat over Sender Policy Framework voor wie hem niet direct herkende, is redelijk onmogelijk aan het worden. In de afgelopen jaren zijn veel records in DNS gezet als TXT resource record en later is er zelfs een eigen SPF resource record gekomen. Helaas gebruiken nog veel mensen de TXT variant, omdat mensen de records in DNS hebben gezet zonder te beseffen wat ze doen en ze ook niet te onderhouden.

Daarbij zijn er maar echt weinig partijen die ook daadwerkelijk zeggen dat hun record een -all geven om zo aan te geven dat de ontvanger de e-mail kan weigeren als het het niet matched tegen de regels in DNS. Misschien de bekendste partijen in Nederland zijn wel Postbank die door phishing aanvallen is gedwongen tot deze actie en de Belastingdienst. Buiten Nederlands blijven er alleen een paar open source communities over en het Duitse GMX, maar grotere partijen zoals Google en Microsoft blijven het alleen afdwingen voor inkomende berichten.

Sinds gisteravond 00h00 is er dus een einde gekomen aan een experiment dat sinds november 2006 liep. Er zal geen Received-SPF header meer worden toegevoegd door de mailservers. Hierdoor zullen e-mails gemiddeld 160 bytes kleiner worden en er zal per server een policy-server minder draaien. Alleen SpamAssassin blijft nog controleren wat ook zonder deze header kan en hiermee staan de SPF-checks bijna geheel op de automatisch-pilot door hun status binnen het SpamAssassin-project. Kortom, vaarwel RFC 4408 en gerelateerde RFCs.

Categories
Internet, Unix en security

Chaining CNAMEs en GRC

Mijnheer Gibson heeft weer wat leuks en ook iets ook heel onverstandigs online staan. Een changing CNAME met veel schakels, heel veel schakels, heel heel heel veel schakels. En er blijken voldoende thuisrouters niet tegen te kunnen zoals ook bij Security.nl naar voren kwam. Ook komt hier gelijk wat anders naars naar voren.

Maar eerst over het probleem zelf en ja het is een probleem. Het is misschien ook wel iets waar Bert Hubert van PowerDNS naar hinten tijdens Hacking at Random. Er zitten nog veel fouten in de resolvers die moeten worden opgelost en dit bleek ook tijdens een test in Zweden met DNSSEC waarbij veel thuisrouters omvielen terwijl ze hoorden te blijven werken. Het onderstaande dus met zorg gebruiken.

$ dig vu4juskpieril.dns.grc.com.

< <>> DiG 9.6.1-P2 < <>> vu4juskpieril.dns.grc.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: SERVFAIL, id: 14245
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;vu4juskpieril.dns.grc.com. IN A

;; ANSWER SECTION:
vu4juskpieril.dns.grc.com. 59 IN CNAME 1gmwga5hrrwca.dns.grc.com.
1gmwga5hrrwca.dns.grc.com. 59 IN CNAME wyxhcj5oe4pnj.dns.grc.com.
wyxhcj5oe4pnj.dns.grc.com. 59 IN CNAME 4t3bqsavrixij.dns.grc.com.
4t3bqsavrixij.dns.grc.com. 59 IN CNAME dhykkk0tjnzwd.dns.grc.com.
dhykkk0tjnzwd.dns.grc.com. 59 IN CNAME w2zci5lhiezqe.dns.grc.com.
w2zci5lhiezqe.dns.grc.com. 59 IN CNAME aupbutbnfy1jn.dns.grc.com.
aupbutbnfy1jn.dns.grc.com. 59 IN CNAME tfriugiykoa5f.dns.grc.com.
tfriugiykoa5f.dns.grc.com. 59 IN CNAME bjdvr3qbhor5e.dns.grc.com.
bjdvr3qbhor5e.dns.grc.com. 59 IN CNAME m0iyvioma2ywe.dns.grc.com.

;; Query time: 2597 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Sun Dec 20 11:27:02 2009
;; MSG SIZE rcvd: 295

Er wordt een vraag uitgezet bij resolver en deze moet bijna oneindig bezig blijven om met een antwoord te komen. Of de resolver blijft “eeuwig” bezig, of stopt met werken door een gebrek aan geheugen bv, of omdat het niet op te lossen en geeft een timeout, of geeft alleen het eerst antwoord. Voorlopig lijken BIND en PowerDNS goed te werken en ook de firmware voor routers van AVM aka Fritz!Box.

Als je mensen wilt pesten dan is de bekende 1×1 pixel image in je e-mail, webpagina, etc wel een aardige optie. Zeker omdat dan ineens veel software alles moet gaan werken zoals virusscanner, spamfilters, contentfilters, etc, etc. Hier ligt ook een groot probleem en waarom ik geen voorstander ben van dit soort toepassingen. Het maakt het probleem eigenlijk veel groter dan het eigenlijk is, want vaak zijn die applicaties even slecht geschreven of maken gebruik van dezelfde bibliotheken als normale applicaties.