Lancom-Reverse-DNS

[Danny]

Hallo,

vielleicht könnt Ihr mal an Euren Lancoms testen, wie die sich in diesem Fall verhalten.

Es geht um den internen DNS-Resolver, konkret um Reverse-DNS-Anfragen.
Da gibt es nach RFC 2317 den Fall für kleinere Netze, dass diese zweiteilig aufgelöst werden, ein CNAME und danach erst der PTR. Ich habe den Eindruck, dass der Lancom diese 2. Anfrage als ungültig(?) ansieht und nicht auflöst.

Z.B. eine PTR-Anfrage für 194.95.197.244 ergibt
244.197.95.194.in-addr.arpa CNAME 244.192-26.197.95.194.in-addr.arpa
244.192-26.197.95.194.in-addr.arpa PTR limes.ba-glauchau.de

Fragt man den Lancom direkt nach dem PTR für 194.95.197.244 gibt er diese beiden Antworten, so weit, so gut. Deswegen meistens kein Problem.
Fragt man aber nur nach dem PTR für 244.192-26.197.95.194.in-addr.arpa (weil man den CNAME z.B. noch im Cache hat), hier als Windows-Abfrage,

nslookup -type=ptr 244.192-26.197.95.194.in-addr.arpa <Lancom-IP>

bekomme ich bei meinem LCOS 10.80 immer als Antwort:
Non-existing domain

Als Vergleich kann man z.B. Google fragen:
nslookup -type=ptr 244.192-26.197.95.194.in-addr.arpa 8.8.8.8

Mir ist das durch Mailserver-Fehlfunktionen aufgefallen, da dort ja der Reverse-DNS eine Rolle spielt.

Könnt Ihr dieses nslookup bei Euch mal machen? Danke fürs Feedback!
Danny

[backslash]

Hi Danny,

"244.192-26.197.95.194.in-addr.arpa" ist für den DNS-Server des LANCOMs eine ungültige Anfrage....

bei ".in-addr.arpa" erwartet das LANCOMs eine "inverse" IP-Adresse vor dem ".in-addr.arpa", um zu ermitteln, wohin die Anfrage weitergeleitet werden soll, wenn es sie selbst nicht auflösen kann. Mit der schaut das LANCOM in die Routing-Tabelle und leitet die Anfrage an den DNS-Server weiter, der der Gegenstelle zugewiesen wurde, auf die die Route zeigt.

Was passiert, wenn du eine Weiterleiung für "*.in-addr.arpa" einrichtest?

Gruß
Backslasg

[sixty]

"244.192-26.197.95.194.in-addr.arpa" ist für den DNS-Server des LANCOMs eine ungültige Anfrage....

RFC 2317 hat Danny schon genannt, ergänzend könnte man noch hinzufügen, daß auch die Telekom diesen Mechanismus für die Delegation von /28 und /29 verwendet, wenn man keine festen Einträge wünscht.

[backslash]

Hi sixty,

der DNS-Forwarder im LANCOM ist kein vollwertiger DNS-Server - und RFC 2317 wird halt nicht unterstützt...

Gruß
Backslash

[Danny]

Danke für Eure Antworten!

Schade, dass LCOS das nicht kann, denn aus formaler Sicht sind das gültige DNS-Anfragen.
Aber es scheint tatsächlich so zu sein, dass in-addr.arpa-Abfragen scheinbar auf vier gültige Zahlen mit drei Punkten dazwischen gecheckt und sonst verworfen werden. Aber irgendwie inkonsequent, denn die (zweiteilige) Gesamtanfrage wird ja wie gesagt trotzdem korrekt beantwortet.

Jedenfalls habe ich ein schlechtes Gefühl, den Resolver als zentrale DNS-Basis einzusetzen, was sich beim Router, der sich per DSL einwählt, ja anbietet.

[backslash]

Hi Danny,

hast du denn mal probiert, eine Weiterleitung für "*.in-addr.arpa" einzurichten und dabei als Ziel den Namen deiner Internetverbindung anzugeben

Jedenfalls habe ich ein schlechtes Gefühl, den Resolver als zentrale DNS-Basis einzusetzen, was sich beim Router, der sich per DSL einwählt, ja anbietet.

Im LANCOM ist explizit kein Resolver! Es ist ein reiner Forwader, der nebenbei Anfragen für ihm bekannte Namen (z.B. von DHCP-Clients) selbst auflösen kann

Gruß
Backslash

[Danny]

Hallo backslash,

Danke für den Tipp, aber den Sinn der Weiterleitung verstehe ich nicht ganz, sämtliche Anfragen werden eh an den Provider-DNS geforwarded. Da kommt kein Routing ins Spiel, in-addr.arpa ist eine ganz normale Zone nach DNS-Spielregeln.
Der Provider-DNS (in meinem Fall Telekom) beantwortet sie auch richtig, wenn man ihn direkt befragt.
Es ist also ein Bug (Feature?) im Lancom-DNS. Die meisten in-addr.arpa-Anfragen beantwortet er ja richtig.

Ich lasse es auf sich beruhen, habe keinen Support, um das Verhalten bei Lancom zu melden.

Danny

[GrandDixence]

Jedenfalls habe ich ein schlechtes Gefühl, den Resolver als zentrale DNS-Basis einzusetzen, was sich beim Router, der sich per DSL einwählt, ja anbietet.

Dann stellt man einen Raspberry Pi neben dem LANCOM-Router hin und lässt über Unbound den ganzen DNS-Verkehr abwickeln. Siehe dazu:
fragen-zur-lancom-systems-routern-und-g ... ml#p102320

fragen-zur-lancom-systems-routern-und-g ... ml#p101750

[backslash]

Hi Danny,

Danke für den Tipp, aber den Sinn der Weiterleitung verstehe ich nicht ganz, sämtliche Anfragen werden eh an den Provider-DNS geforwarded. Da kommt kein Routing ins Spiel, in-addr.arpa ist eine ganz normale Zone nach DNS-Spielregeln.

nein, das ist eben *KEINE* normale Domain! und im LANCOIM ist eben *KEIN* vollwertiger DNS-Server.

Bei PTR-Anfragen an in-addr.arpa, wird die Route zu der darin codierten Adresse gesucht - und die muß für das LANCOM aus 4 Dezimalzahlen mit Punkten dazwischen bestehen.
Das LANCOM leitet die PTR-Anfragen den DNS-Server weiter, der der Gegenstelle zugewiesen wurde, auf die die Route zur Adresse in der PTR-Anfrage zeigt.
Da sie aber nicht erkannt wird, wird die Anfrage verworfen (nxdomain)

Die Einrichtung des Forwardings für "*.in-addr.arpa" dient dazu, das interne Verhalten explizit zu überschreiben...

versuch es doch einfach mal statt einfach zu sagen: ist nicht nötig, weil es eh nicht funktioniert

Gruß
Backslash

[sixty]

Viele Hersteller von Routern und vergleichbaren Geräten bauen große Teile ihrer Softwareumgebung auf frei nutzbare Open-Source-Projekte auf.
Bei Betriebssystemen ist das fast immer Linux, bei DNS oft BIND oder eine der leichtgewichtigen Alternativen.
Diese sind im Quelltext und für alle relevanten Systemarchitekturen verfügbar und durch den massenhaften Einsatz hinreichend gut erprobt.
Dadurch gibt es bei diesen Geräten konsistentes Verhalten, aber eben auch identische Anfälligkeit für Sicherheitsücken (CVE) in der Software oder den zugrundeliegenden Bibliotheken wie z.B. OpenSSL. LANCOM setzt das auch ein - im Betriebssystem LCOS-LX.

Allerdings hat LANCOM auch professionelle Geräte im Angebot, bei denen auf Nutzung dieser "Referenz" bewußt verzichtet und letztlich der ganze IP-Stack neu implementiert wird. Diese Geräte haben als Betriebssystem LCOS. Durch die alternative Implementation sind sie oft nicht von "gängigen" Programmierfehlern und CVEs betroffen und müssen dann auch nicht gepatch werden.

Ähnliche Konzepte gibt es z.B. in der Luft- und Raumfahrt, wo dann kritische Steuerrechner mit verschiedenem Code und Architektur gleiche Aufgaben (z.B. die Bahnberechnung) durchführen und am Schluß die Ergebnisse verglichen werden. Oft müssen dann mindestens "zwei aus drei" stimmen.

Diese alternative Implementation hat aber auch Nachteile. Einer ist, da0 natürlich andere Programmierfehler entstehen können, ein anderer, daß Spezifikationen, RFCs o.ä. manchmal doch nicht eindeutig sind bzw. Interpretationsspielraum lassen. Bei LCOS ist das z.B. im IPv6-Teil der Fall, de sich manchmal subtil anders verhält als die Linux-Referenzimplementation, aber eben wie hier z.B. auch im DNS.

[GrandDixence]

Ähnliche Konzepte gibt es z.B. in der Luft- und Raumfahrt, wo dann kritische Steuerrechner mit verschiedenem Code und Architektur gleiche Aufgaben (z.B. die Bahnberechnung) durchführen und am Schluß die Ergebnisse verglichen werden. Oft müssen dann mindestens "zwei aus drei" stimmen.

In der Raumfahrt wird heute gerne als Echtzeitbetriebssystem (RTOS) RTEMS eingesetzt.
https://arstechnica.com/features/2020/1 ... ne-before/

https://www.elektroniknet.de/embedded/s ... 83912.html

Und RTEMS basiert auf viel "zusammenkopierten" Open Source Code. Der TCP/IP-Stack von RTEMS stammt von FreeBSD. Wenn FreeBSD eine Sicherheitslücke im TCP/IP-Stack hat, hat auch RTEMS eine Sicherheitslücke in seinem TCP/IP-Stack.
https://freebsdfoundation.org/wp-conten ... System.pdf

Der "Super-Diversitätsansatz", dass kritische Steuerrechner (SIL-3 oder SIL-4 nach IEC 61508) mit verschiedenen Hardwarearchitekturen, verschiedenen Betriebssystemen und Programmcode aus verschiedenen Compilern und Programmiersprachen von unterschiedlichen Programmieren betrieben wird, hört sich in der Theorie gut an. Hat sich aber in der Praxis nicht durchgesetzt: Auf diese "Super-Diversität" verzichten die meisten Herstellern von kritischen Steuerrechnern. Vermutlich aus Kostenspargründen. Dann sind halt 3 kritische Steuerrechnern, mit der identischen Hardware, identischem (Echtzeit-)Betriebssystem und identischem Programmcode an Bord.

Für einfachere Aufgaben werden die kritischen Steuerrechnern häufig mit FPGA, oder nah verwandten Digitallogik-Hardware-Chips wie CPLD, betrieben. Solche Hardware-Chips werden mit einer Hardwarebeschreibungssprache wie VHDL programmiert. Hat den Vorteil, dass dieser Hardware-Chip bei Produktabkündigung relativ leicht durch ein Nachfolgeprodukt oder Konkurrenzprodukt ersetzt werden kann. Kritische Steuerrechner müssen in der Regel über ein oder mehrere Jahrzehnte lauffähig sein. In dieser Branche ist der lächerliche LANCOM-Support-Zeitraum von 5 Jahren (für Sicherheitsupdates und Ersatzteile) unangebracht.

Kritische Steuerrechner werden immer mehr und mehr mit IP-Netzwerken vernetzt, deshalb benötigen auch kritische Steuerrechner Sicherheitsupdates gegen bekannte Sicherheitslücken.

[sixty]

Der "Super-Diversitätsansatz" [...] hört sich in der Theorie gut an. Hat sich aber in der Praxis nicht durchgesetzt:

Musterbeispiel dafür ist der Absturz der ersten Ariane 5.
Wenn mehrere Rechner den gleichen, logisch fehlerhaften Code ausführen, kann auch das Ergebnis nur Mist sein

[GrandDixence]

Wenn mehrere Rechner den gleichen, logisch fehlerhaften Code ausführen, kann auch das Ergebnis nur Mist sein

Im Beispiel der Ariane 5 hätte ein 2 aus 3 - Steuerrechnersystem nach dem Super-Diversitätsansatz nur zu einer Sicherheitsabschaltung geführt, weil der korrekt arbeitende Rechner A nicht zum gleichen Rechenergebnis kam, wie der falsch rechnende Rechner B. Eine Sicherheitsabschaltung bei einer Rakete bedeutet vermutlich eine Triebwerkabschaltung (mit anschliessender Sprengung der Rakete) => Siehe Youtube-Video vom Raketenstart am 30.03.2025 der deutschen Firma "Isar Aerospace".

Auch der "Super-Diversitätsansatz" hätte nicht verhindert, dass der "Mars Climate Orbiter" wegen einem peinlichen Einheitenfehler in der Marsatmosphäre verglühte und damit 125 Millionen Dollar US-Steuergeldern zu nichte machte...
https://www.spiegel.de/wissenschaft/men ... 44777.html

[Danny]

Jedenfalls habe ich ein schlechtes Gefühl, den Resolver als zentrale DNS-Basis einzusetzen, was sich beim Router, der sich per DSL einwählt, ja anbietet.

Dann stellt man einen Raspberry Pi neben dem LANCOM-Router hin und lässt über Unbound den ganzen DNS-Verkehr abwickeln. Siehe dazu:
fragen-zur-lancom-systems-routern-und-g ... ml#p102320

fragen-zur-lancom-systems-routern-und-g ... ml#p101750

Danke!

[Danny]

Hi Danny,

Danke für den Tipp, aber den Sinn der Weiterleitung verstehe ich nicht ganz, sämtliche Anfragen werden eh an den Provider-DNS geforwarded. Da kommt kein Routing ins Spiel, in-addr.arpa ist eine ganz normale Zone nach DNS-Spielregeln.

nein, das ist eben *KEINE* normale Domain! und im LANCOIM ist eben *KEIN* vollwertiger DNS-Server.

Bei PTR-Anfragen an in-addr.arpa, wird die Route zu der darin codierten Adresse gesucht - und die muß für das LANCOM aus 4 Dezimalzahlen mit Punkten dazwischen bestehen.
Das LANCOM leitet die PTR-Anfragen den DNS-Server weiter, der der Gegenstelle zugewiesen wurde, auf die die Route zur Adresse in der PTR-Anfrage zeigt.
Da sie aber nicht erkannt wird, wird die Anfrage verworfen (nxdomain)

Die Einrichtung des Forwardings für "*.in-addr.arpa" dient dazu, das interne Verhalten explizit zu überschreiben...

versuch es doch einfach mal statt einfach zu sagen: ist nicht nötig, weil es eh nicht funktioniert

Gruß
Backslash

Danke auch Dir Backslash! in-addr.arpa ist, soviel ich weiß, eine ganze normale DNS-Zone, sprich, es wird Ebene für Ebene über NS-Records aufgelöst, da ist kein Routing im Spiel. Wenn Du da ein Lancom-Dokument oder RFC für mich hast, lese ich mich gern ein und lerne dazu. Da der Lancom kein Resolver ist (wie Du schon schreibst), forwarded er eh alle DNS-Anfragen an den Nameserver seines Vertrauens, egal ob PTR oder A.