Problem DHCP/DNS

[Fraggle]

Hi Backslash,
danke für deine Unterstützung.

@all
die banale "Lösung" der Probleme: Neustart des Lancoms.
Ärgerlich dabei, besonders in virtualisierten Umgebungen in denen die User nicht Neustarten dürfen, ist die Dauer bis ein DNS-Eintrag wieder verfüfbar ist. Entweder man wartet bis die Lease time abläuft oder fässt jede Maschine manuell an.

[backslash]

Hi Fraggle,

die banale "Lösung" der Probleme: Neustart des Lancoms.
Ärgerlich dabei, besonders in virtualisierten Umgebungen in denen die User nicht Neustarten dürfen, ist die Dauer bis ein DNS-Eintrag wieder verfüfbar ist. Entweder man wartet bis die Lease time abläuft oder fässt jede Maschine manuell an.

das kann ich jetzt nicht nachvollziehen...
Die DHCP-Tabelle ist "Bootpersistent" - d.h. ein DHCP-Eintrag und die damit verbunden Namensauflösung überlebt einen normalen Reboot. Wenn du das Gerät allerdings abschaltest (bzw. einen Cold-Boot ausführst) ist die Information natürlich weg...
Außerdem wiederspicht dies deiner früheren Aussage, nach der die Hosts doch in der DHCP-tabelle standen. Aber sei's drum...

Gruß
Backslash

[roell.f]

Hallo roell.f

DNS-tabelle: DNS > Allgemein Stations-Namen

Ich glaube in dieser Liste kann man Namen nur manuell hinterlegen. Von der DHCP-Liste wird sie nicht gefüttert.

Gruß Erx

hallo erx,

das ist korrekt: sowohl die DHCP-tabelle als auch die DNS-tabelle lassen sich nur von hand konfigurieren.

die beiden tabellen sind auch vollkommen von einander getrennt. es gibt router (insbesondere aus dem consumer-segment), bei denen das anders ist. dort werden z.B. die vom DHCP gefundenen geräte angezeigt und man kann ihnen dann im web-GUI des routers feste IPs oder auch neue namen zuweisen.

ich selbst hätte mir zu verringerung des konfigurationsaufwands bzw. vermeidung von diskrepanzen in der konfiguration zweier DHCP- bzw. DNS-server gewünscht, dass die lancom DHCP- / DNS-server kompatibel zum ISC-DHCP bzw. ISC-DNS-server (bind) wären. in diesem fall könnte man die lancom seite als slaves konfigurieren, welche ihre aktualisierung von einem DHCP- / DNS-master beziehen. ich vermute allerdings, dass es nicht dazu kommen wird, weil es nur sehr bedingt zur produktphilosopie der lancom-produkte passt. wer sich diese redundanz wünscht, wird von lancom wahrscheinlich die empfehlung erhalten, die lancom DHCP- und DNS-server abzuschalten und statt dessen einen zweiten linux-server (physisch oder virtuell (VM)) mit ISC-DHCP und ISC-DNS (bind) aufzusetzen.

ich bin jedoch einen anderen weg gegangen und habe mir ein bash-skript geschrieben, welches meine ISC-DHCP- und ISC-DNS-konfigurationsdateien ausliest und daraus lancom lcs-dateien generiert. die lcs-dateien kann man dann bequem mit hilfe von LANconfig in den router importieren. allerdings liebäugele ich mit der anschaffung eines intel NUC, um darauf redundanz-VMs (DHCP, DNS, LDAP, etc.) unter vmware ESXi zu fahren.

beste grüße
frank

ps.
@fraggle: höre bitte auf backslash. er kann nur helfen, wenn man ihm die verlangte info zur verfügung stellt.

[GrandDixence]

allerdings liebäugele ich mit der anschaffung eines intel NUC, um darauf redundanz-VMs (DHCP, DNS, LDAP, etc.) unter vmware ESXi zu fahren.

Vielleicht genügt dazu bereits ein Raspberry Pi? Siehe:
fragen-zur-lancom-systems-routern-und-g ... ml#p106862

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

[roell.f]

allerdings liebäugele ich mit der anschaffung eines intel NUC, um darauf redundanz-VMs (DHCP, DNS, LDAP, etc.) unter vmware ESXi zu fahren.

Vielleicht genügt dazu bereits ein Raspberry Pi? Siehe:
fragen-zur-lancom-systems-routern-und-g ... ml#p106862

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

hallo GrandDixence,

deinen links bin ich gefolgt und sehe schon, dass du ein großer raspi-fan bist

für anschaffung und unterhalt (strom) gebe ich lieber etwas mehr geld aus und bekommen dafür mehr performanz. auch möchte ich in meinem hardware-zoo nicht allzu viele unterschiedliche tierchen pflegen. aber als einstieg z.b. für schüler (mit schmalem budget) oder auch kleine automatisierungsaufgaben (messen, regeln, steuern, etc.) halte ich den raspi für eine gute sache. die netzwerk-administration soll für mich ein nebenthema bleiben und statt dessen die entwicklung von produkten mit hohem software-anteil im vordergrund stehen.

beste grüße
frank

ps. bei der staumauer "Grande Dixence" wurde ja auch nicht gekleckert, sondern geklotzt

[Fraggle]

Da das Problem, welches ich hier vor längerer Zeit geschildert habe, wieder auftaucht,
hier nun die mehrfach gewünschten Traces.
WS-011 taucht übrigens in der DHCP-Tabelle auf. Eine DNS-Tabelle kann ich leider nicht finden.

1) DHCP-Lease vom Problembären WS-011

Code: Alles auswählen

[DHCP] 2022/09/17 18:56:11,669
DHCP Rx (LAN-1, INTRANET): 
DHCP Client Message (request) from 0.0.0.0: DHCPREQUEST
  Op    = 01       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 16642C9F | Secs  = 0000 | Flags = 0000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 06 61 d6 ae ea 66 00 00 00 00 00 00 00 00 00 00

Client-ID:       01:06:61:d6:ae:ea:66
Req.-IP:         192.168.45.42
Hostname:        WS-011
unknown option:  81 | Len =   9 | Para: 00 00 00 57 53 2d 30 31 31
Vendor-Class-ID: MSFT 5.0
Option List      1 3 6 15 31 33 43 44 46 47 119 121 249 252
 => Tx DHCPACK

[DHCP] 2022/09/17 18:56:11,669
DHCP Tx (LAN-1, INTRANET): 
DHCP Server Message (reply) to 192.168.45.42: DHCPACK
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 16642C9F | Secs  = 0000 | Flags = 0000
  CIAdr =          0.0.0.0 | YIAdr =    192.168.45.42
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 06 61 d6 ae ea 66 00 00 00 00 00 00 00 00 00 00
Server-ID:   192.168.45.251
Client-ID:   01:06:61:d6:ae:ea:66
Netmask:     255.255.255.0
Gateway:     192.168.45.251
DNS-Server:  192.168.45.251
Domain:      intern
Broadcast:   192.168.45.255
NBNS-Server: (none)
Leasetime:   30000

2) DHCP-Lease für auflösbare Station WS-008

Code: Alles auswählen

[DHCP] 2022/09/17 18:52:18,933
DHCP Rx (LAN-1, INTRANET): 
DHCP Client Message (request) from 0.0.0.0: DHCPREQUEST
  Op    = 01       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 8A15C4E5 | Secs  = 0000 | Flags = 0000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 9e f2 69 7b 56 00 00 00 00 00 00 00 00 00 00 00

Client-ID:       01:9e:f2:69:7b:56:00
Req.-IP:         192.168.45.2
Hostname:        WS-008
unknown option:  81 | Len =   9 | Para: 00 00 00 57 53 2d 30 30 38
Vendor-Class-ID: MSFT 5.0
Option List      1 3 6 15 31 33 43 44 46 47 119 121 249 252
 => Tx DHCPACK

[DHCP] 2022/09/17 18:52:18,934
DHCP Tx (LAN-1, INTRANET): 
DHCP Server Message (reply) to 192.168.45.2: DHCPACK
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 8A15C4E5 | Secs  = 0000 | Flags = 0000
  CIAdr =          0.0.0.0 | YIAdr =     192.168.45.2
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 9e f2 69 7b 56 00 00 00 00 00 00 00 00 00 00 00
Server-ID:   192.168.45.251
Client-ID:   01:9e:f2:69:7b:56:00
Netmask:     255.255.255.0
Gateway:     192.168.45.251
DNS-Server:  192.168.45.251
Domain:      intern
Broadcast:   192.168.45.255
NBNS-Server: (none)
Leasetime:   30000

3) Ping von Win-Station (DHCP) auf WS-011 löst auf

Code: Alles auswählen

[DNS] 2022/09/17 19:45:18,411
DNS Rx (INTRANET): Src-IP 192.168.45.59, RtgTag 0
Transaction ID: 0xf9b4
Flags: 0x0100 (Standard query, No error)
Queries
  ws-011.intern: type A, class IN

STD A for ws-011.intern
Not found in local DNS database, query to own domain => not forwarded

3a) Ping von Win-Station (DHCP) auf WS-011.intern löst nicht auf

Code: Alles auswählen

[DNS] 2022/09/17 20:44:57,222
DNS Rx (INTRANET): Src-IP 192.168.45.59, RtgTag 0
Transaction ID: 0x2800
Flags: 0x0100 (Standard query, No error)
Queries
  ws-011.intern: type A, class IN

STD A for ws-011.intern
Not found in local DNS database, query to own domain => not forwarded

4) Ping von unixoider Arbeitsstation (feste IP) auf WS-011 löst nicht auf

Code: Alles auswählen

[DNS] 2022/09/17 17:56:34,621
DNS Rx (INTRANET): Src-IP 192.168.45.173, RtgTag 0
Transaction ID: 0xc25f
Flags: 0x0100 (Standard query, No error)
Queries
  ws-011: type AAAA, class IN

STD AAAA for ws-011
not found in local DNS database, request without domain => refused
Request filtered

5) Ping auf WS-011.intern löst nicht auf

Code: Alles auswählen

[DNS] 2022/09/17 19:53:05,642
DNS Rx (INTRANET): Src-IP 192.168.45.173, RtgTag 0
Transaction ID: 0x965a
Flags: 0x0100 (Standard query, No error)
Queries
  ws-011.intern.intern: type AAAA, class IN

STD AAAA for ws-011.intern.intern
Not found in local DNS database, query to own domain => not forwarded

6) Ping von unixoider Station (DHCP) auf WS-011 löst nicht auf

Code: Alles auswählen

DNS] 2022/09/17 20:07:34,621
DNS Rx (INTRANET): Src-IP 192.168.45.93, RtgTag 0
Transaction ID: 0x8bf5
Flags: 0x0100 (Standard query, No error)
Queries
  ws-011.intern: type AAAA, class IN

STD AAAA for ws-011.intern
Not found in local DNS database, query to own domain => not forwarded

7) Ping auf WS-008

Code: Alles auswählen

[DNS] 2022/09/17 19:00:49,742
DNS Rx (INTRANET): Src-IP 192.168.45.173, RtgTag 0
Transaction ID: 0xbdda
Flags: 0x0100 (Standard query, No error)
Queries
  2.45.168.192.in-addr.arpa: type PTR, class IN

STD PTR for 2.45.168.192.in-addr.arpa
Name resolved to ws-008.intern

Irgendwie scheint Lancom mit A-records und AAAA-records zu tüdeln.
Übersehe ich etwas?
Vielleicht weiss auch jemand, wie ich mir die locale DNS database anzeigen lassen kann.

[GrandDixence]

In den Fällen 4) bis und mit 6) ist das Verhalten des LANCOM-Routers korrekt. In diesen Fällen ist das Problem beim fehlenden Verständnis vom Funktionsprinzip von DNS zu suchen.
https://en.wikipedia.org/wiki/List_of_DNS_record_types

In den Fällen 3) und 3a) interpretiere ich den Trace so, dass der LANCOM auf die DNS-Query keine DNS-Answer versendet hat. Ist mit Packet-Capture und Wireshark zu überprüfen.
viewtopic.php?f=14&t=17510&p=99340&hili ... ker#p99340

In den Fällen 3) und 3a) ist das Problem bei der mangelhaften Prüfmethodik zu suchen. nslookup oder dig einsetzen mit der IP-Angabe des LANCOM-Router. Zum Beispiel auf einem Linux-Rechner:

# dig A ws-011.intern @192.168.1.1
# nslookup -querytype=A ws-011.intern 192.168.1.1

Siehe auch:

# man nslookup
# man dig

Wurde auf dem Linuxrechner die Konfigurationsdatei /etc/resolv.conf korrekt konfiguriert? Diese Konfigurationsdatei darf nur eine Zeile:

search intern

enthalten. Zusätzlich muss eine Zeile:

nameserver 192.168.1.1

eingetragen werden mit der IP-Adresse des LANCOM-Routers, wenn auf dem Linuxrechner kein lokaler DNS-Forwarder betrieben wird (zum Beispiel: dnsmasq oder unbound horchend auf localhost). Das Betreiben eines lokalen DNS-Forwarder auf jedem Linuxrechner ist zu empfehlen.

Siehe auch:

# man resolv.conf

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

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

[Fraggle]

Danke für Deine Mühe, über das Problem nachzudenken.
Zielführend geht aber anders.

In den Fällen 4) bis und mit 6) ist das Verhalten des LANCOM-Routers korrekt. In diesen Fällen ist das Problem beim fehlenden Verständnis vom Funktionsprinzip von DNS zu suchen.
https://en.wikipedia.org/wiki/List_of_DNS_record_types

Sei dir versichert, daß ich mit der Funktionsweise des DNS seit 20 Jahren recht vertraut bin und den Unterschied zwischen A- und AAAA-records kenne. Korrekt seitens Lancom ist genau nix.

In den Fällen 3) und 3a) interpretiere ich den Trace so, dass der LANCOM auf die DNS-Query keine DNS-Answer versendet hat. Ist mit Packet-Capture und Wireshark zu überprüfen.
viewtopic.php?f=14&t=17510&p=99340&hili ... ker#p99340

Hör misch auf! Der Problembär WS-011 war 10 Monate korrekt auflösbar und aus heiterem Himmel nicht mehr. Da ist genau NIX mit Wireshark o.ä zu überprüfen. Der Trace läuft sowieso auf dem Lancom. Das Ding muss sowohl WS-011 als auch WS-011.intern (bei gegebener Domain.intern) IDENTISCH auflösen!

In den Fällen 3) und 3a) ist das Problem bei der mangelhaften Prüfmethodik zu suchen. nslookup oder dig einsetzen mit der IP-Angabe des LANCOM-Router. Zum Beispiel auf einem Linux-Rechner:

Danke Herr Oberlehrer. Prüfen der Namensauflösung braucht in Mininetzen weder nslookup noch dig. Ein stinkendes ping reicht. Denn die Anfragen kommen (siehe Trace) ja beim korrekten Adressaten an.

Wurde auf dem Linuxrechner die Konfigurationsdatei /etc/resolv.conf korrekt konfiguriert? Diese Konfigurationsdatei darf nur eine Zeile:

search intern

enthalten. Zusätzlich muss eine Zeile:

nameserver 192.168.1.1

eingetragen werden mit der IP-Adresse des LANCOM-Routers, wenn auf dem Linuxrechner kein lokaler DNS-Forwarder betrieben wird (zum Beispiel: dnsmasq oder unbound horchend auf localhost). Das Betreiben eines lokalen DNS-Forwarder auf jedem Linuxrechner ist zu empfehlen.

Siehe auch:

# man resolv.conf

Danke für Deine generöse Nachhilfe bzgl. resolv.conf. Hätte ich ja auch selbst drauf kommen können. Jede Station ist vom Quellrechner im Netz auflösbar. Nur eine plötzlich nicht mehr. Logischerweise kontrolliert man zuerst resolv.conf.
Bitte verschone mich und andere mit "rtfm-Tipps".

[mh1]

@Fraggle:
ich habe den Thread mit über dein DHCP/DNS Problem so verstanden, als hättest du ein Problem beschrieben und Tipps/Hilfen/Meinungen aus der Community erwartetet.
Deine eigentümliche Art uns zu zeigen, dass du beratungsresistent zu sein scheinst und ja sowieso seit über 20 Jahren mit der Thematik vertraut bist, verleitet allerdings nicht dazu, inhaltlich an dem Thread mitzuhelfen.
Zumindest ich persönlich werde mich nicht mit Hinweisen zur dargestellten Namensauflösung beteiligen.

Tu dir doch selbst einen Gefallen und überdenke deinen Auftritt, wenn du nach Hilfe fagst.


Übrigens:

(...)Bitte verschone mich und andere mit "rtfm-Tipps".

Hier in diesem Forum, gibt es einige Leute, die immer wieder durch wirklich hilfreiche Threads auffallen.
GrandDixence gehört dazu. Ich hoffe wirklich, dass er nicht auf dich hört. Denn ich will NICHT, dass er mich oder andere hier im Forum mit seinen Tipps verschont.