Wie fast jeder andere Router auch können Cisco-Router als DNS-Proxy fungieren. Das bedeutet, Clients im LAN nutzen die IP-Adresse des Cisco-Routers als DNS-Server-Adresse und der Cisco-Router leitet die Anfrage an den DNS-Server des Internet Service Providers weiter. Hieraus ergeben sich zwei Vorteile:
- Viele Antworten können aus dem Cache des DNS-Proxy auf dem Router beantwortet werden, was die Antwortzeiten und den Traffic reduziert.
- Die DNS-Server-Adressen der DNS-Server des ISP können dynamisch über DHCP oder PPP vom ISP „gelernt“ werden. Sollte der ISP die Adressen ändern, ist auf Kundenseite keine Änderung erforderlich
Konfiguration
Die Konfiguration ist simpel und erfordert nur wenige Konfigurationszeilen. Zuerst ist der DNS-Server auf dem Router zu aktivieren:
ciscorouter(config)# ip dns server ciscorouter(config)# ip domain-lookup
Nun muss der Router noch die IP-Adressen der DNS-Server mitgeteilt bekommen. Wie oben beschrieben ist eine dynamische Zuteilung empfehlenswert, aber zur Not tut’s auch eine statische Konfiguration, hier am Beispiel der Google DNS-Server:
ciscorouter(config)# ip name-server 8.8.8.8 ciscorouter(config)# ip name-server 8.8.4.4
Auch die dynamische Zuteilung ist einfach zu konfigurieren. In diesem Beispiel wird über Dialer 1 eine PPP(oE)-Verbindung aufgebaut:
ciscorouter(config)# interface Dialer1 ciscorouter(config-if)# ppp ipcp dns request
Die letzte Zeile in obigem Block bewirkt, dass der Cisco-Router die DNS-Server-Adressen bei der Einwahl erfragt und zur Namensauflösung nutzt.
Prinzipiell ist unser DNS-Proxy damit bereits funktionsfähig und kann zur Namensauflösung genutzt werden. Allerdings hat man sich mit dieser Konfiguration ein neues Problem geschaffen: Der DNS-Proxy „lauscht“ nun auf allen Interfaces des Cisco-Routers – auch auf dem WAN-/DSL-Interface (hier: Dem Dialer1)! Somit kann jeder andere aus dem Internet heraus den eigenen Cisco-Router als DNS-Proxy nutzen. Auch wenn das auf den ersten Blick eher unkritisch erscheint, so kann dies spätestens dann zu größeren Problemen führen, wenn kriminelle Gestalten den Router als Werkzeug für DNS Amplification Attacks nutzen. Daher ist es dringend empfehlenswert, den DNS-Proxy auf dem WAN-Interface zu deaktivieren.
Auf den ersten Blick hat Cisco dies nicht vorgesehen; es gibt keine Möglichkeit, den DNS-Server auf einem Interface einzeln zu deaktivieren. Allerdings gibt es die Möglichkeit, via Split DNS auf einem Interface eine abweichende DNS-Konfiguration anzuwenden. Dies lässt sich zur Lösung unseres Problems ausnutzen:
ciscorouter(config)# interface Dialer1 ciscorouter(config-if)# ip dns view-group dvl_secure-dns-proxy
Diese Zeile bewirkt, dass auf dem Interface Dialer1 eine abweichende DNS-Konfiguration gilt, die über eine View-List genauer zu spezifizieren ist. Solange die hier zugeordnete View-List nicht existiert, ist der DNS-Proxy auf dem Interface bereits deaktiviert, somit ist unser Ziel eigentlich schon erreicht. Allerdings ist die Konfiguration nicht „sauber“ und man kann nicht sicher sagen, dass zukünftige IOS-Versionen sich identisch verhalten, daher sollte man eine passende View-List anlegen:
ciscorouter(config)# ip dns view-list dvl_secure-dns-proxy ciscorouter(cfg-dns-view-list)# view default 1 ciscorouter(cfg-dns-view-list-member)# restrict authenticated
Diese bewirkt, dass die reguläre DNS-Konfiguration auf dem Interface nur dann angewandt wird, wenn der Client authentifiziert ist — was niemals der Fall ist. Ansonsten ist der DNS-Proxy inaktiv.
Wichtig: Es zählt dabei das Ingress-Interface der Anfrage – nicht die IP-Adresse des Interfaces, an die die Anfrage gerichtet war! Oder anders ausgedrückt: Wenn auf dem WAN-Interface eine solche Konfiguration implementiert ist, kann aus dem Internet heraus auch über die Adresse des LAN-Interfaces keine DNS-Auflösung mehr ausgelöst werden. Insbesondere in Konfigurationen ohne NAT ist dieses Verhalten wichtig.
Kontrolle
Prüfen lässt sich dies bei aktiviertem DNS-View-Debugging auf dem Cisco-Router.
Via dig fragt ein Client den DNS-Proxy des Cisco-Routers nach einer Namensauflösung, erhält aber keine Antwort:
user@host:~> dig www.heise.de @1.2.3.4 ; <<>> DiG 9.7.3 <<>> www.heise.de @1.2.3.4 ;; global options: +cmd ;; connection timed out; no servers could be reached user@host:~>
Auf dem Cisco sieht man zeitgleich einen Hinweis:
ciscorouter# debug ip dns view DNS View debugging is on ciscorouter# term mon *Feb 10 11:07:23.930 MET: DNS_VIEW: No DNS View is usable for client 1.2.3.4/59586, querying A 'www.heise.de' ciscorouter#
Somit haben wir nun das Ziel erreicht: Auf dem WAN-Interface (aus dem Internet) kann der DNS-Proxy nicht mehr angesprochen werden.
Update 2014-06-20
Alle IOS-Versionen bis hoch zu den aktuellen weisen leider einen Fehler auf: Der konfigurierte DNS View wirkt sich nur auf UDP-basierte Namensanfragen aus, nicht jedoch auf TCP-basierte (bei dig zu prüfen mit der Option +tcp). Ein entsprechendes Ticket bei Cisco wurde eröffnet.
Update 2014-08-14
Cisco hat hierfür nun den Bug-Report CSCuq37275 erstellt.
Update 2017-07-06
Cisco hat den Bug in mehreren IOS-Versionen behoben (siehe Bug-Report CSCuq37275).
Neuer Bug: Leider funktioniert „restrict authenticated“ in IOS-XE offenbar generell nicht. In Klärung. Workaround: Über eine DNS Name-List alles ablehnen, Beispiel:
ciscorouter(config)# ip dns view-list dvl_secure-dns-proxy ciscorouter(cfg-dns-view-list)# view default 1 ciscorouter(cfg-dns-view-list-member)# restrict name-group 1 ciscorouter(cfg-dns-view-list-member)# ip dns name-list 1 deny .*
Update 2017-08-18
Cisco hat den neuen Bug bestätigt und mit Bug-Report CSCvf54983 dokumentiert („conditions“ ist allerdings falsch beschrieben).
Cisco wird den Bug allerdings nicht beheben, sondern den Befehl „restrict authenticated“ statt dessen komplett entfernen. Der Workaround wird also für IOS-XE zur Dauerlösung.
Kurze Frage. Ist es möglich manuell einen statischen Cache-Eintrag zu erzeugen, sodass der Router für eine bestimmte Internetadresse z.B. eine interne IP zurückgibt?
Ja, via „ip host…“ sollte es möglich sein, DNS Records hinzuzufügen.
Kurze Anmerkung am Rande:
Das Verhindern von Zugriffen aus dem Internet auf den DNS-Dienst des Routers ist doch ein bisschen einfacher mit einer zweizeiligen ACL erledigt:
ip access-list extended OUTSIDE-IN
deny udp any any eq 53
permit ip any any
int Di1
ip access-group OUTSIDE-IN in
Die ACL ist natürlich gleich noch für andere Sachen nützlich. Konfiguriert man auf dem Router auch ntp, so ist z.B. auch dieser Dienst direkt zum Internet hin offen und möchte vermutlich auch gesperrt werden für Zugriffe von dort.
Uiuiui, da hast du aber etwas ganz grundlegend falsch verstanden.
Mit deiner ACL blockst du jeglichen Verkehr, der über den Dialer an deinem Router ankommt und als Zielport den Port 53 hat. Das sind in dem Fall nicht nur Anfragen an die Router-IP, also die des Dialers 1, sondern auch Antworten auf DNS Anfragen des Routers, die von Port 53 ausgehen und somit auf Port 53 beantwortet werden, sowie jeglicher Verkehr mit Zielport 53 von allen Geräten im LAN. Somit blockst du DNS komplett, solange die Anfragen von Port 53 ausgehen.
Dass DNS auch via TCP laufen kann, ignorierst du hingegen komplett und lässt das Scheunentor dort komplett offen.
Ganz ganz übel, niemals so machen! Man kann DNS auch mit ACLs absichern, ja, aber der Aufwand ist deutlich höher als das, was du hier vorschlägst.
Jup, die TCP-Zeile fehlt natürlich noch, das stimmt.
Den Traffic zum TCP+UDP-Port 53 deines Routers darfst Du aber getrost blocken. Der DNS-Client im Router benutzt ja nicht den Port 53 als Sourceport, sondern irgendwelche high ports (dns source port randomiziation, sieh‘ gerne selbst nach mittels „debug ip packet $ACL detail“). Wenn Du also nicht selbst einen Dienst auf Port 53 betreibst, den Du erreichbar haben willst, dann filtere den Zugriff raus. Der Router darf auch beim dynamischen NAT der Clients im LAN keine privileged Ports als source-Ports verwenden, so dass also auch hier Port 53 als Source nie vorkommen wird.
Bei NTP ist es ein bisschen schwieriger, weil hier tatsächlich 123 sowohl source- als auch destination-Port ist. Das lässt sich nur lösen, indem man die Zeitserver manuell im Router einträgt und dann NTP-Verkehr ausschließlich von deren Adressen durchlässt. Die NTP-Anfragen von NAT-Clients werden davon wiederum nicht beeinträchtigt, da diese per NAT wieder mit high source Ports rausgehen.
Folgende ACL am Dialer funktioniert also einwandfrei, ohne irgendeine Funktion zu beeinträchtigen:
ip access-list extended OUTSIDE-IN
permit udp host $NTP-SERVER1 eq ntp any
permit udp host $NTP-SERVER2 eq ntp any
deny udp any any eq domain
deny tcp any any eq domain
deny udp any any eq ntp
permit ip any any
Damit kann niemand von draußen Deinen Router als NTP- oder DNS-Server ansprechen. Und ich halte da simmer noch für einfacher, als die Sache mit den views.
Hallo zusammen! ich habe ein Prob mit meinem neu erstandenen Cisco RV 180. Vll. kann mir hier jemand helfen? Ich bekomme das LAN-interne DNS nicht gebacken. Der RV-180 hängt hinter einer Fritzbox, die I-net via Kabel bekommt. (Ich trenne mein Home-Office von privat) In den WAN Einstellungen des cisco habe ich die Adresse der Firtzbox als primären DNS Server eingetragen, sonst nichts. In den LAN – Einstellungen habe ich die Adresse des cisco als primären DNS Server eingetragen und DNS proxy aktiviert. (bei deaktivieren geht in Richtung i-net gar nix mehr).
Problem: Bis auf eine Ausnahme (die ist meine NAS, die mit Openmediavault läuft), kommen alle pings mit Fehler zurück. Lediglich die Windows Maschinen bringen pings zurück, die aussehen, wie IPV6 Adressen, aber m.E. vom Netbios zurückgegeben werden.
Meine konkreten Frage nun:
1. Ich würde gerne auf die Shell vom cisco, um den DNS Server zu aktivieren, wie in diesem Artikel beschrieben. Im Grafik UI hab ich nirgendwo eine Möglichkeit gefunden, das zu tun. Wie komm ich auf die Shell des cisco?
2. Gibt es dieses Feld vll. doch im Grafik UI? Wenn ja, wer kann mir sagen wo?
3. Kennt jemand dieses Problem?
Ganz vielen Dank!
Im Artikel hier geht es um IOS-basierte Geräte. Der RV 180 hat laut Datenblatt kein CLI und ist damit kein IOS-basierter Router.
Hallo Jens, danke für die schnelle Antwort. Hast Du dennoch eine Idee, wo die Ursache meines Problems liegen könnte?
Prinzipiell klingt deine Beschreibung soweit OK. Da ich den Router aber nicht kenne, kann ich da nichts weiter zu sagen. Du kannst nur versuchen, mittels dig bzw. nslookup zu testen, welche Komponente nicht korrekt auf DNS Queries antwortet.
Hallo Jens,
die Befehlszeile ist nicht ganz klar:
ciscorouter(config)# ppp ipcp dns request
sie müsste lauten
ciscorouter(config-if)# ppp ipcp dns request
Stimmt – danke! 🙂