Archive for the ‘DNS’ Category

Poorman’s Addblocker – oder wenn einen der laute Lüfter am Rechner stört

11 Januar 2018

Wenn man mehrere Browserinstanzen geöffnet hat und beim Surfen viele verschiedene Tabs geöffnet hat, dann steigert sich unweigerlich die Prozessorlast. Im Normalfall nicht von den eigentlichen Seiten, sondern von den Millionen Werbeeinblendungen. Aus diesem Grund setze ich von Zeit zu Zeit häufig auftauchende Adware-Adressen auf 127.0.0.1 und lasse sie quasi ins Leere laufen.

Die Vorgehensweise benötigt Adminrechte. Um die aktuellen DNS-Anfragen einsehen zu können, hilft einem mal wieder Powershell. Seit Windows 8 gibt es das Cmdlet Get-DnsClientCache. Allerdings liefert Get-DnsClientCache im Zweifel zu viele Daten zurück. Deshalb muss die Abrage etwas modifiziert werden:

Get-DnsClientCache|where type -ne 12|where Data -ne "127.0.0.1"|where Data -ne $null

Bei “type –ne 12” werden die PTR-Records aus dem Ergebnis gestrichen, weil diese keinen Sinn machen. Danach werden noch alle leeren Einträge gefiltert. Diese werden mit der Zeit immer mehr, je mehr man Adressen gegen 127.0.0.1 laufen lässt.

Man geht also in seinen Browser, ruft eine Seite auf, wo man analysieren möchte und führt dann obige Zeile aus.

Ein Ergebnis stellt sich dann so dar:

Entry                     RecordName                Record Status    Section TimeTo Data   Data
                                                    Type                     Live   Length
—–                     ———-                —— ——    ——- —— —— —-
safebrowsing.googleapi… safebrowsing.googleapi… A      Success   Answer     166      4 216.58.207.74
www.gstatic.com           www.gstatic.com           A      Success   Answer      80      4 216.58.214.99

Sieht scheiße aus aber entscheidend ist die Spalte Entry, dort stehen die DNS-Namen welche auf die bei Data angegebene IP-Adresse aufgelöst werden. Setzt man also diese DNS-Namen auf 127.0.0.1 findet keine Kommunikation nach extern mehr statt.

Um die Auswahl etwas komfortabler zu gestalten, benutzen wir Out-GridView:

Get-DnsClientCache|where type -ne 12|where Data -ne "127.0.0.1"|where Data -ne $null |Out-GridView -PassThru -OutVariable Selected | select -Property @{N="HOSTSExclusion";E={"127.0.0.1`t$($_.Entry)"}} | Select -ExpandProperty HostsExclusion| Set-Clipboard

Man wählt einfach die gewünschten Einträge aus und erhält diese in $Selected zur Weiterverarbeitung zurück. Noch besser, es wird gleich ein passender Eintrag in die Windowszwischenablage mit den ausgewählten Daten gelegt. Nun braucht man nur noch

notepad $env:windir\system32\drivers\etc\hosts

aufrufen und kann dort die Daten von der Zwischenablage am Ende einfügen und speichern. Man könnte die Daten auch gleich direkt in die HOSTS-Datei schreiben aber manche Virenscanner reagieren darauf allergisch, dann also doch besser die Zwischenablage benutzen.

Ein Problem stellt sich aber noch. Wie kann man feststellen, dass eine DNS-Adresse tatsächlich eine Werbeadresse ist? Tja, da ist leider Handarbeit angesagt. In der Regel erhält man beim Aufruf so einer Adresse im Browser nur eine leere Seite oder die Homepage einer Werbe- oder Addagentur. Dieser Aufruf hilft nach der Auswahl eine Entscheidung zu treffen:

$selected| select -ExpandProperty Entry| foreach {start microsoft-edge:http://$_}

Dabei werden alle bei Out-GridView ausgewählten Seiten automatisch im Edge geöffnet, damit man kurz den Inhalt gegenprüfen kann. Hier das gleiche für Chrome:

$selected| select -ExpandProperty Entry| foreach {start chrome $_}

Raspberry Pi kennt kein nslookup

16 Februar 2016

Wer an seinem Raspberry Pi mit Raspbian Jessie auf Probleme mit einem DNS-Server stößt, der möchte diese als eingefleischter Windowsbenutzer mit nslookup lösen:

mypi:~ $ nslookup
bash: nslookup: command not found

Aber standardmäßig ist kein nslookup installiert. Wobei die Profis unter Linux benutzen sowieso dig:

mypi:~ $ dig mydomain.net SPF
bash: dig: command not found

OK, dahinter muss System stecken. Also muss das betreffende Programm installiert werden:

mypi:~ $ sudo apt-get install nslookup
Reading package lists… Done
Building dependency tree
Reading state information… Done

E: Unable to locate package nslookup

Jetzt muss man wissen, dass nslookup zusammen mit dig und nsupdate in einem Paket mit Namen dnsutils steckt: https://packages.debian.org/de/jessie/dnsutils. Also einfach dieses installiert:

mypi:~ $ sudo apt-get install dnsutils

Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages were automatically installed and are no longer required:
libc-ares2 libv8-3.14.5
Use ‘apt-get autoremove’ to remove them.
Suggested packages:
rblcheck
The following NEW packages will be installed:
dnsutils
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 112 kB of archives.
After this operation, 324 kB of additional disk space will be used.
Err http://mirrordirector.raspbian.org/raspbian/ jessie/main dnsutils armhf 1:9.9.5.dfsg-9+deb8u3 404 Not Found [IP: 5.153.225.207 80]
E: Failed to fetch http://mirrordirector. raspbian.org/raspbian/pool/main/b/bind9/dnsutils_9.9.5.dfsg-9+deb8u3_armhf .deb 404 Not Found [IP: 5.153.225.207 80]
E: Unable to fetch some archives, maybe run apt-get update or try with – -fix-missing?

Na super, da ist man auf der richtigen Spur aber es klappt nicht. Die Lösung ist aber zum Glück einfach, man muss vorher seine Installation mit aktuellen Paketupdates vorsorgen:

mypi:~ $ sudo apt-get update

Danach hat die Installation mittels sudo apt-get install dnsutils geklappt und dig und nslookup stehen zur Verfügung.

SBS2003 Server machte nach Internetproviderumstellung Probleme mit DNS-Namensauflösungsanfragen

2 August 2014

Nachdem bei einem Kunden der Internetprovider gewechselt wurde, kam es zu massiven Problemen bei den Clientrechnern. Bei Zugriffen, vor allem auf kompliziertere oder mittels HTTPS verschlüsselten Seiten wie bahn.de, ebay.de, mobile.de usw. gab es teilweise ewige Verzögerungen und am Ende sogar Timeouts, so dass die Seiten nicht korrekt dargestellt wurden.

Der SBS hat bekanntlich noch zwei Netzwerkkarten. Davon wird eine für den lokalen Netzwerkverkehr verwendet und die zweite ist das Gateway nach außen. Der neue Internetprovider hatte ein Gerät installiert, wo ein anderer IP-Adressbereich hinterlegt war. Demzufolge musste beim SBS in den Netzwerkkarteneinstellungen die neue IP-Adresse für die Kommunikation mit dem externen Router hinterlegt werden. Damit fingen die Probleme an.

Am SBS-Server war ein gewohnt schneller Zugriff auf alle Seiten möglich. Allerdings war auf den Clientrechnern eben obige Aussetzer zu beobachten. Auch ein Test mit Googles-DNS-Server-Adresse 8.8.8.8 auf dem Client brachte die übliche Geschwindigkeit. Was tun? Zunächst mittels Ping und NSlookUp versucht der Sache auf die schliche zu kommen. Nach vielen Tests und einigem hin- und her hatte es sich herausgestellt, dass am SBS noch ein DNS-Forward eingestellt werden sollte.

Mittels

dnscmd /info

kann man verschiedene Infos zum DNS abfragen:


  Aging Configuration:
        ScavengingInterval           = 0
        DefaultAgingState            = 0
        DefaultRefreshInterval       = 168
        DefaultNoRefreshInterval     = 168
  ServerAddresses:
Addr Count = 2
                Addr[0] => 192.168.60.1
                Addr[1] => 192.168.10.2
  ListenAddresses:
Addr Count = 1
                Addr[0] => 192.168.60.1
  Forwarders:
Addr Count = 1
                Addr[0] => 192.168.1.1
        forward timeout  = 5
        slave            = 0
Command completed successfully.

Hier sieht man sehr schön, dass zwar die IP-Adresse der zweiten Netzwerkkarte Addr[1] passend zum neuen Router gesetzt wurde aber die Adresse Addr[0] des Forwarders noch auf den alten IP-Bereich eingestellt ist. Wichtig dabei ist nun auch der Timeout=5, was 5 Sekunden entspricht.

Wenn man es weiß, ist nun die Sache schnell erledigt:

dnscmd . /ResetForwarders 192.168.10.1 /TimeOut 5 /Slave

Damit wurde Addr[0] des Forwarders auf die korrekte Adresse.

Interessant an der Geschichte ist vor allem, dass Seiten mit Subdomains massive Probleme bekamen. Ist irgendwie logisch denn für jede Subdomainanfrage kam der Timeout mit 5 Sekunden zu tragen.

So führte ein einfacher Aufruf von ebay.de und das klicken auf Einloggen zu zig Domainabfragen, hier einige davon:

www.ebay.de
secureir.ebaystatic.com
ir.ebaystatic.com
securepics.ebaystatic.com
srx.de.ebayrtm.com
cors.api.paypal.com
thumbs2.ebaystatic.com
thumbs3.ebaystatic.com
thumbs4.ebaystatic.com
p.ebaystatic.com
www.paypalobjects.com
b.stats.ebay.com
314797b0qxk.stats.ebay.com
signin.ebay.de
phx.stats.paypal.com
src.ebay-us.com
sofe.ebay.de
rover.ebay.de
rtm.ebaystatic.com
pics.ebaystatic.com
secureir.ebaystatic.com
pages.ebay.de
i.ebayimg.com

Was für eine Auflistung! Über 20 DNS-Abfragen werden benötigt um die Start- und dann die Loginseite aufzurufen. Pech, wenn man sowas unterwegs in einem Edge- oder noch besser GPRS-Handynetz macht, wo jede Anfrage ca. 200 Millisekunden und mehr dauert…

xn--bcher-kva.de oder was hat das mit Bücher.de zu tun? Die Geschichte von Punycode bzw. IDN, also Internationale Domain Namen.

1 März 2014

Seit einigen Jahren ist es bereits möglich Domainnamen mit Umlauten wie äöü zu erhalten. Fast jeder hat sich seither damit aber zurückgehalten, weil viele Programme damit nicht umgehen können.

Aber in letzter Zeit scheinen es mehr Domains zu werden und wenn es nur darum geht, diese zusätzlich zu benutzen, um am Ende wieder auf die Hauptdomain weiterzuleiten. Wer zum heutigen Tag, als dieser Blogeintrag geschrieben wurde, www.bücher.de eingibt, der landet bei www.buecher.de. Soweit ist alles paletti.

Wer nun aber hin und wieder irgendwelche LOG-Dateien auswertet oder untersucht, bzw. mysteriöse Problemfälle zu ergründen versucht, der stolpert irgendwann über das Kürzel xn--.

Die Erklärung dafür ist recht simpel. Die komplette Internetinfrastruktur stammt aus der 8 bzw. noch 7-Bit Computersteinzeit. Als man die DNS-Infrastruktur aufbaute, gab es bekanntlich ja nur die USA und die kennen nun mal nur A-Z und die Zahlen von 0-9. Als man Ende der 80iger Jahre Unicode einführte, war es aber bereits zu spät alle DNS-Systeme umzustellen und keiner wusste, ob Unicode sich jemals durchsetzen würde, denn schließlich verschlang es Unmengen an Bytes.

Wenn man heute das Internet nochmal neu entwickeln könnte, würde man natürlich von Anbeginn Unicode verwenden. Aber dafür ist es zu spät. Also haben clevere Leute sich mit einem Kniff beholfen. Es entstand der sogenannte Punycode der im RFC3492 spezifiziert wurde, ein Algorithmus, welcher dafür sorgt dass zwischen ASCII und Unicode Zeichen umgesetzt werden können, ohne dass Informationen verloren gehen. Damit man weiß, dass es sich um einen Punycode behandelten Buchstaben handelt, wird einfach ein Marker davor gesetzt. Der Marker ist eben dieses Kürzel xn--. In RFC3490 als ACE prefix bezeichnet. Da dieses Kürzel sonst nicht verwendet wird und vorkam, konnte man immer eindeutig sagen, wann die ASCII-Zeichen in Unicode gewandelt werden müssen. RFC3490 betitelt mit “Internationalizing of Domain Names for Applications” führte zu der Abkürzung IDNA. Da das RFC 2003 veröffentlicht wurde, sprach man später von IDNA2003. Im Jahr 2008 entdeckte man auf einmal, dass es auch Sprachen gibt, welche von rechts nach links geschrieben werden und es gab noch andere Ungereimtheiten. Diese wurden in RFC5890 behandelt, welches dann als IDNA2008 bezeichnet wurde.

So also zurück wieder zu www.bücher.de. Wer nun wissen möchte, wie bücher.de konvertiert aussieht, der kann ganz einfach Onlinedienste dafür verwenden, z. B. http://www.charset.org/punycode.php?encoded=xn--bcher-kva.de&decode=Punycode+to+normal+text. Bei

Bücher.de

kommt also

xn--bcher-kva.de

bei raus. Interessant ist auch die Variante mit Subdomain http://www.charset.org/punycode.php?decoded=www.b%C3%BCcher.de&encode=Normal+text+to+Punycode#results:

www.bücher.de

wird zu

http://www.xn--bcher-kva.de

Es wird also einfach das www. davor beibehalten.

Zu welchen Verwicklungen diese Dinge führen können, werden wir in nächster Zeit im einen oder anderen Blogbeitrag wieder finden.

Erklärungen und Erläuterungen zu DNS

2 März 2013

Ein wichtiges Thema, die Namensauflösung mittels DNS. Diese Seite bietet viele gute kurze Erklärungen zum Thema: http://support.simpledns.com/KB/browse.aspx.

Es dreht sich zwar vieles um deren Produkt “Simple DNS Plus”, allerdings werden viele allgemein wichtige Themen angesprochen, wie z. B. DynDNS, DNSSEC, SIP und richtige SPF Konfiguration bei E-Mailservern uvm.