OPNsense: DNS - Adressen vom ISP (PPPoE / WAN)?

[Uwe@Home]

Hallo,

kann man die DNS-Adressen, die vom ISP zugewiesen wurden, irgendwo einsehen?
Hier findet man sie nicht:

System => Gateways => Single
System => Settings => General
Interfaces => Overview => WAN interface (wan, pppoe0)
Interfaces => Point-to-Point => Log File

Warum?

Seit dem letzten Update (auf OPNsense 23.1.9-amd64) hab´ ich massive Probleme mit der Telefonie.
Die Telefonanlage ist eine Fritz!Box (7590), die im LAN hängt.
ISP / Telefonie - Anbieter ist die Telekom (Business-Tarif wg. statischer IPv4).

Es gibt eine weitere Fritz!Box (7590), die sich um die Telefonie via SipGate (SIP-Port 5160 statt 5060) kümmert.
Die Telefonie via SipGate funktioniert einwandfrei.

Via Telekom geht wieder mal gar nichts.
(Outbound NAT für statisches Port-Mapping und Port-Forward von 217.0.0.0/13:5060 auf TK-Anlage sind angelegt).

Die Telekom verwendet diverse (Sicherheits-)Mechanismen, die auf DNS basieren.
Deshalb muss man zwingend die DNS-Server der Telekom in der TK-Anlage verwenden.

Hier gibt es zwar eine Liste von DNS-Servern, davon antwortet aber innerhalb von Sek. nur ein einziger:
https://de.ccm.net/faq/1431-dns-server-deutscher-internetanbieter#dns-deutsche-telekom-ag

Ich würde jetzt gerne wissen, welche DNS-Server während der Einwahl mitgeteilt worden sind.

OPNsense ist so konfiguriert, dass bestimmte DNS-Server (also nicht die der Telekom) verwendet werden
([ ] Allow DNS server list to be overridden by DHCP/PPP on WAN). Das soll auch so bleiben.

Grüße, Uwe

[JeGr]

> Ich würde jetzt gerne wissen, welche DNS-Server während der Einwahl mitgeteilt worden sind.

Da du diese nicht übernimmst bei der Einwahl via PPPoE oder DHCP stehen diese später nirgendwo mehr. Man könnte sie höchstens in einem Log (ggf. mit erhöhter Verbosity) finden direkt nach der Einwahl aber das ist nur eine Vermutung. Wenn du gezielte DNS Server hast von der Telekom die du nutzen willst ohne deren DNSe bei der Einwahl zu übernehmen, könntest du nur einen Domain Override konfigurieren und dort eben dann die Telekom DNSe hinterlegen. Oder für die TK Anlage bspw. definieren, dass diese per DHCP die DNSe der Telekom bekommt, damit die VoIP Sachen aufgelöst werden können.

Cheers
\jens

[Strunzdesign]

Hallo Uwe,

ich habe gestern ein ähnliches Problem hier bei mir lösen müssen. Vielleicht hilft es Dir ja.

Auch ich bin bei der Telekom (allerdings ohne statische IPv4-Adresse) und erhalte die Telekom-DNS-Server per PPP zugewiesen. Im Gegensatz zu Dir habe ich besagte Option allerdings nicht angekreuzt, und lasse die Adressen der zugewiesenen DNS-Server immer brav in die /etc/resolv.conf schreiben.

Jetzt benutze ich aber Unbound als DNS-Server und habe bis gestern die DNS-Server der Telekom gar nicht mehr benutzt. Das lief an sich super, hat aber an meinem Asterisk im LAN immer wieder zu VoIP-Problemen mit der Telekom geführt (Stichwörter: NAPTR, SRV, sich ändernde IP-Adressen des Registrars und Proxys, INVITEs abgelehnt wegen fehlender Proxy-Auth). Ich brauchte also ein Setup, welches quasi immer Unbound benutzt, aber für VoIP zur Telekom eine Ausnahme macht und die von der Telekom geadelten Einträge aus der /etc/resolv.conf benutzt.

Ich habe dazu als Dienst "Dnsmasq-DNS" aktiviert, diesem den unbenutzten UDP-Port 52 zugewiesen, und dann den Dnsmasq-Dienst quasi zugenagelt und nur noch für localhost erreichbar gemacht. Im Unbound konnte ich dann eine Ausnahmeregel unter "Query Forwarding" einrichten, welche alle Anfragen betreffs der Domains "tel.t-online.de" und "sip-trunk.telekom.de" an 127.0.0.1:52 deligiert.

Damit erhoffe ich mir jetzt Ruhe in Bezug auf den ewigen Ärger mit den von Dir genannten DNS-basierten Sicherheitsfeatures der Telekom. Bis jetzt siehts gut aus, und die Dnsmasq-Logs zeigen mir auch, dass immer schön (nur) Namensauflösungen aus *.tel.t-online.de stattfinden.

Hoffe Das hilft Dir! Viele Grüße,
Florian

[Uwe@Home]

Hallo Florian,

Ich habe dazu als Dienst "Dnsmasq-DNS" aktiviert, diesem den unbenutzten UDP-Port 52 zugewiesen, und dann den Dnsmasq-Dienst quasi zugenagelt und nur noch für localhost erreichbar gemacht. Im Unbound konnte ich dann eine Ausnahmeregel unter "Query Forwarding" einrichten, welche alle Anfragen betreffs der Domains "tel.t-online.de" und "sip-trunk.telekom.de" an 127.0.0.1:52 deligiert.

Klingt gut - die Resolver werden dann durch Dnsmasq-DNS in die resolv.conf übernommen und in Unbound stehen die DNS-Server für alle anderen Systeme - richtig?

Viele Grüße, Uwe

[Strunzdesign]

Schönen Guten Abend,

ja Uwe, Du hast fast Alles korrekt wiedergegeben. Nur, der Eintrag in die /etc/resolv.conf erfolgt meines Kenntnisstandes nach durch den PPP-Daemon (ggf. ist da noch ein Wrapper drum). Im zweiten Schritt steht es nun jedem Resolver frei, Einträge aus der lokalen /etc/resolv.conf zu benutzen. Unbound soll dies nicht tun (man will ja nicht über die DNS-Server des Providers gehen) aber DNSmasq tut dies.

Da meine Systeme im LAN als DNS-Server auf den UDP-Port des Unbound-Servers zeigen (Port 53) findet die Namensauflösungen generell ohne Zugriff auf /etc/resolv.conf statt. Nur für SIP-basierte Telefonie brauche ich eine Ausnahme, was ich mit der Delegation in Richtung des lokalen DNSmasq löse.

Theoretisch kannst Du auch Deine Fritzbox direkt auf den DNSmasq leiten. Dann kannst Du Die die Weiterleitung wie in Unbound sparen, musst allerdings den DNSmasq-Port an der Firewall öffnen und dafür sorgen, dass die Fritzbox auch den UDP-Port des DNSmasq erhält und diese Adresse zur Namensauflösung nutzt.

Viele Grüße,
Florian

[Strunzdesign]

Hallo nochmals,

hier ist noch ein kleiner Knackpunkt, über den ich gerade gestolpert bin. Es gibt unter

System -> Einstellungen -> Allgemein

den Punkt "DNS-Server Einstellungen", wobei der Unterpunkt "Verwenden Sie den lokalen DNS-Dienst nicht als Nameserver für dieses System" vielleicht angekreuzt werden muss.

Ohne diese Option zeigt bei mir die /etc/resolv.conf als ersten Eintrag "nameserver 127.0.0.1". Damit greift jedoch der DNSmasq abermals wieder auf Unbound zu... und die Katze beißt sich in den Schwanz.

Nun... dennoch scheint es zu funktionieren. Vielleicht wird die Loop erkannt und unterbrochen, sodass die anderen Einträge aus der /etc/resolv.conf (stammen von der Telekom ) doch noch greifen.

Weiterhin würde die oben genannte Option bewirken, dass die OPNsense selbst (alle Dinge auf der OPNsense) nicht mehr über Unbound auflösen würde. Das wäre blöd. Da es "anscheinend" trotzdem funktioniert (oder nur scheinbar?)... vielleicht hat ja Jemand Einblick was bei dieser "Loop" passiert und wieso es bei mir doch zu klappen scheint.

Viele Grüße,
Florian