DNS Bug in neuer LCOS 8.6?

Forum zu den aktuellen LANCOM Wireless Accesspoint Serien

Moderator: Lancom-Systems Moderatoren

Benutzeravatar
LoUiS
Site Admin
Site Admin
Beiträge: 5052
Registriert: 07 Nov 2004, 18:29
Wohnort: Aix la Chapelle

Beitrag von LoUiS »

Hi,

ist der DNS-Server denn eingeschaltet?
Hier funktioniert das auf einigen APs problemlos.


Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
Rougu
Beiträge: 115
Registriert: 18 Sep 2007, 18:57
Wohnort: EU

Beitrag von Rougu »

Hi,

wohl wahr! Mit eingeschaltetem DNS-SERVER funktioniert es, zumindestens so halb. Die forward resolution ist jetzt ok, aber reverse nicht:

[code]
> ping -n 10.1.4.1

[DNS] 2012/04/15 07:07:24,213
DNS Rx (intern): Src-IP 10.1.8.1
Query Request: STD PTR for 1.4.1.10.in-addr.arpa
DnsGetPTR: request not resolved, trying to get route name
DnsGetPTR: no route to forward request => not forwarded

*
56 Byte Packet from 10.1.4.1 seq.no=0 time=0.836 ms
56 Byte Packet from 10.1.4.1 seq.no=1 time=0.887 ms
56 Byte Packet from 10.1.4.1 seq.no=2 time=0.883 ms
[/code]

10.1.4.1 ist hier der interne NS im INTRANET, wohin eine Route sicher vorhanden ist.

Zweite Prüfung zu public IP: Das funktioniert nicht, wenn alle Interfaces mit Routing-Tag <>0 arbeiten und Default-Routen nur für die erforderlichen Routing-Tags gesetzt sind. Nur wenn eine Default-Route für Routing-Tag 0 gesetzt ist, gelingt die Reverse-Auflösung nach extern:

[code]
> ping -n 88.198.177.34

[DNS] 2012/04/15 07:30:30,928
DNS Rx (intern): Src-IP 10.1.8.1
Query Request: STD PTR for 34.177.198.88.in-addr.arpa
DnsGetPTR: request not resolved, trying to get route name
[b]DnsGetPTR: forwarding request to default route
[/b]Forward to locally configured DNS server


[DNS] 2012/04/15 07:30:31,000
DNS Rx (LAN-1, INTRANET): Src-IP 10.1.4.1
Query Response:
STD PTR 34.177.198.88.in-addr.arpa resolved to lancom-forum.de (TTL = 3600)
lancom-forum.de
56 Byte Packet from 88.198.177.34 seq.no=0 time=31.996 ms
56 Byte Packet from 88.198.177.34 seq.no=1 time=32.026 ms
56 Byte Packet from 88.198.177.34 seq.no=2 time=31.748 ms
56 Byte Packet from 88.198.177.34 seq.no=3 time=32.351 ms
[/code]

Reverse-Auflösungen von IP-Adressen im INTRANET gelingen weiter nicht (no route).
Wo geht die Bindung des PTR-Requests an das Quellinterface verloren?

Dieser Quickfix schafft zunächst einmal Erleichterung, aber sauber ist das natürlich noch nicht. Der DNS-Server sollte ausgeschaltet sein, wenn nur ein DNS-Client gewünscht ist. Er prüft alles doppelt, erst gegen die leere interne Tabelle, dann gegen die Forwarder.

Gruß,
Rougu
Benutzeravatar
REPTILE
Beiträge: 687
Registriert: 30 Jan 2005, 17:31

Beitrag von REPTILE »

Das ist aber ja keine Lösung des Problems sondern nur der Symtome.....

Hatte eigendlich nicht vor 80 Geräte umzukonfigurieren.....
Benutzeravatar
langewiesche
Beiträge: 1255
Registriert: 27 Apr 2005, 11:28
Wohnort: Gevelsberg / Sprockhoevel im Ruhrgebiet
Kontaktdaten:

Beitrag von langewiesche »

kommt du denn remote dran es ist ja ein einzeiler den dns "wieder" an zu machen via script oder auf die fix firmware warten ...
Es gruesst Lars
--
Zwischen einen NAT-Router hinter einen Nat-Router und vor einen NAT-Router passt immer noch ein NAT-Router
tom_tav
Beiträge: 75
Registriert: 15 Dez 2006, 00:43

Beitrag von tom_tav »

Dürfte noch immer Probleme geben, auch mit RC:

Folgende Config, lief mit 8.5 lange Zeit reibungslos:

DMZ mit Routeradresse X (1722)

In der DMZ steht ein NS, der ein paar (VPN) Domains fürs Intranet&DMZ als forwarder auf den Router X eingetragen hat

Im Router sind diese Domains auch als forwarder auf die NS Server in den VPNs eingetragen (doppeltes Forwarding da die DMZ Server keinen Zugriff auf die VPNs haben sollen)

Seit kurz nach dem Upgrade (vorher waren die noch im NS gecached) funktioniert dieses forwarding nicht mehr.

Gehe ich jedoch mit nslookup oder dig auf den Router X findet die Auflösung weiterhin korrekt statt, nur das forwarding auf meinen NS geht nicht mehr.


Die NS Konfiguration stimmt, trage ich im NS statt Router X die VPN NS ein (+ im Lancom eine entsprechende FW Regel damit ich auf die Server zugreifen kann) funktioniert alles tadellos
Benutzeravatar
REPTILE
Beiträge: 687
Registriert: 30 Jan 2005, 17:31

Beitrag von REPTILE »

Kommt da jetzt in absehbarer Zeit ein Bugfix noch? Oder ist Lancom das egal das die aktuelle Version nicht wirklich nutzbar ist?
Benutzeravatar
LoUiS
Site Admin
Site Admin
Beiträge: 5052
Registriert: 07 Nov 2004, 18:29
Wohnort: Aix la Chapelle

Beitrag von LoUiS »

Hi,

es gibt zu diesem Fehler einen Workaround, mit dem man IMHO leben kann, bis die naechste LCOS Version freigegeben wird. Die Freigabe des neuen LCOS wird vmtl. in Kuerze erfolgen.


Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
Benutzeravatar
gunter22
Beiträge: 57
Registriert: 01 Apr 2006, 10:13
Wohnort: Castrop-Rauxel
Kontaktdaten:

Beitrag von gunter22 »

Der Workaround funktioniert hier auf einem 1722 nicht. Auch die neue 8.62 zeigt hier leider keine Besserung, also nach läuft hier nach wie vor die ältere Version.
Unterwegs mit LANCOM 1781 VA 8.84.0166
T-DSL 6000 von Telekom und 100 MB von Unity
Benutzeravatar
LoUiS
Site Admin
Site Admin
Beiträge: 5052
Registriert: 07 Nov 2004, 18:29
Wohnort: Aix la Chapelle

Beitrag von LoUiS »

Hi,

ich denke dann hast Du vmtl. ein anderes Verhalten.
Das in diesem Thread besprochene Verhalten im DNS ist mit dem LCOS 8.62 definitiv behoben.


Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
Antworten