Bind9 DNS liefert falsche IP

  • Hallo Leute,

    ich habe ein ganz komischen Phänomen.
    Habe einen RPi3 als Server aufgesetzt und lasse darüber Dienste DHCP und DNS laufen.
    Nun habe ich das Problem, dass manchmal Adressen falsch aufgelöst werden.

    Das komisch eist, sie werden nur beim PING falsch aufgelöst, bei NSLOOKUP passt alles.


    Anbei mal ein paar Details.

    PING

    Code
    C:\Users\TA>ping pi-srv.angl.loc
    
    
    Ping wird ausgeführt für pi-srv.angl.loc [62.138.238.45] mit 32 Bytes Daten:
    Antwort von 62.138.238.45: Bytes=32 Zeit=33ms TTL=248
    Antwort von 62.138.238.45: Bytes=32 Zeit=32ms TTL=248


    NSLOOKUP

    Code
    C:\Users\TA>nslookup pi-srv.angl.loc
    Server:  UnKnown
    Address:  192.168.170.2
    
    
    Name:    ns1.angl.loc
    Address:  192.168.170.2
    Aliases:  pi-srv.angl.loc

    ip lookup zone


    reverse lookup

  • Hi,

    prinzipiell muss die Antwort vom Ping nicht falsch sein, sie sendet hier zunächst mal die Externe-IP, was nicht bedeutet, die IP sei falsch, nur dass deine Konfiguration des DNS-Servers dann nicht ganz korrekt ist.

    Wie schaut deine Konfigurationsdatei "named.conf.options" aus?

    Edit: habe gerade gesehen, dass du offensichtlich einen Windows-Client verwendest. Dazu bitte nochmal die Ausgabe von ipconfig /all - Ping löst den Hostname / FQDN anders auf, nämlich u.U. in der Hosts-Datei in Windows, statt die Auflösung wie bei nslookup über den konfigurierten DNS-Server auszuführen.

    “Don’t comment bad code - rewrite it.”

    Brian Kernighan

    Einmal editiert, zuletzt von sls (27. April 2017 um 20:31)

  • Danke für die schnelle Antowrt

    named.conf.options


    ipconfig /all


    Ich ergreif gleich mal die Gelegenheit und frage ob ich gröbere Fehler in meiner Config habe? (z.B. unnötige oder Sinfreie Zeilen)

    Einmal editiert, zuletzt von DerT (27. April 2017 um 21:01)

  • Du hast zwei mal das selbe gepastet. Bitte nochmal angleichen. An hand welcher Anleitung hast du DNS/DHCP konfiguriert? So ganz richtig scheint's nicht zu sein, da er schon bei nslookup leicht auf die Nase fällt.

    Andere Frage, warum trägst du bei den forwarders deinen Router ein? Als forwarder werden ja eig. nur Nameserver im Internet eingetragen, an welche der lokale Resolver seine Anfragen weiterleitet, wenn er sie selbst nicht beantworten (auflösen) kann. Für lokale Anfragen ist dein DNS-Server zuständig.

    “Don’t comment bad code - rewrite it.”

    Brian Kernighan


  • Du hast zwei mal das selbe gepastet. Bitte nochmal angleichen. An hand welcher Anleitung hast du DNS/DHCP konfiguriert? So ganz richtig scheint's nicht zu sein, da er schon bei nslookup leicht auf die Nase fällt.

    Andere Frage, warum trägst du bei den forwarders deinen Router ein? Als forwarder werden ja eig. nur Nameserver im Internet eingetragen, an welche der lokale Resolver seine Anfragen weiterleitet, wenn er sie selbst nicht beantworten (auflösen) kann. Für lokale Anfragen ist dein DNS-Server zuständig.

    Habe diese Anleitung benutzt und etwas abgeändert
    Anleitung

    Wenn du die Frage so stellt kling es Logisch :)
    Der Router macht ja im Endeffekt nichts anderes als einen Forward nach drausen.
    Hatte da einen kleinen Denkfehler, wollte vermeiden dasss meine DNS-Auflösung versagt wenn der PI aus ist.
    Aber wie gesagt Denkfehler, daich das ja Abfangen muss indem ich eine Sec.DNS im DHCP festlege.

  • Richtig, zum einen würde ich hier direkt den DNS-Server vom Provider eintragen als den Weg über den Router zu gehen welchen diesen Request wieder weiterreicht, zum anderen sinnlos da im Fallback-Fall der Pi eh tot ist.

    Was sagt nur "nslookup" am Windows-Client?

    Probier mal ipconfig /flushdns und anschließend ipconfig /registerdns

    Damit werden alle bisherigen DNS-Cache-Einträge gelöscht und anschließend der vom DHCP-Server mitgeteilte DNS-Server erzwungen.

    “Don’t comment bad code - rewrite it.”

    Brian Kernighan

  • Hi

    NSLOOKUP vor ipconfig /flushdns ipconfig /registerdns

    Code
    C:\Users\TA>nslookup
    Standardserver:  UnKnown
    Address:  192.168.170.2

    Habe ich einen Fehler oder warum ist der Standardserver: UnKnown?

    Nach einem /flushdns und /registerdns funktioniert der Ping
    Hoffe das bleibt erstmal so. Danke

    Habe den Router rausgenommen


  • Hi

    NSLOOKUP vor ipconfig /flushdns ipconfig /registerdns

    Code
    C:\Users\TA>nslookup
    Standardserver:  UnKnown
    Address:  192.168.170.2

    Habe ich einen Fehler oder warum ist der Standardserver: UnKnown?

    Das ist mit nichten korrekt. In deiner Reverse Lookup Zone fehlt ein Eintrag:

    IN NS ns1.angl.loc. ; #1 192.168.2.2

    Der Punkt hinter der FQDN ist übrigens wichtig, er signalisiert "hey, hier ist die TLD, danach musst du nicht mehr weiter auflösen". Sieh dazu nochmal dein Tutorial an, dort stehen diese auch.

    Bind hat eine extrem pingelige Syntax. Du kannst diese mittels: "named-checkconf /etc/bind/named.conf" überprüfen. Fehler in der Konfigurationsdatei werden dann mitgeteilt. Eine andere Option wäre tail -f /var/log/syslog und sehen, ob Bind hier Fehler wirft.

    “Don’t comment bad code - rewrite it.”

    Brian Kernighan

    Einmal editiert, zuletzt von sls (27. April 2017 um 21:53)

  • Danke nochmal für die Antworten.

    Sagen dir folgende Fehler etwas?

    Code
    Apr 28 13:01:09 pi-srv named[23966]: error (insecurity proof failed) resolving 'stack.imgur.com.cdn.cloudflare.net/A/IN': 208.67.220.220#53
    Apr 28 13:01:09 pi-srv named[23966]: validating @0x72605d98: stack.imgur.com.cdn.cloudflare.net A: got insecure response; parent indicates it should be secure
    Apr 28 13:01:09 pi-srv named[23966]: error (insecurity proof failed) resolving 'stack.imgur.com.cdn.cloudflare.net/A/IN': 208.67.222.222#53

    Habe schon herausgefunden dass es mit DNSSEC zutun hat und habe es bei meinem DNS deaktiviert.
    DNSSEC dient ja der Verifizierung einer DNS-Anfrage.
    Was ich nicht rausgefunden habe ist woher der Fehler kommt und ob es Kritisch ist es zu deaktivieren.

    Danke
    Gruß
    T

    Einmal editiert, zuletzt von DerT (28. April 2017 um 13:07)


  • Danke nochmal für die Antworten.

    Sagen dir folgende Fehler etwas?

    Code
    Apr 28 13:01:09 pi-srv named[23966]: error (insecurity proof failed) resolving 'stack.imgur.com.cdn.cloudflare.net/A/IN': 208.67.220.220#53
    Apr 28 13:01:09 pi-srv named[23966]: validating @0x72605d98: stack.imgur.com.cdn.cloudflare.net A: got insecure response; parent indicates it should be secure
    Apr 28 13:01:09 pi-srv named[23966]: error (insecurity proof failed) resolving 'stack.imgur.com.cdn.cloudflare.net/A/IN': 208.67.222.222#53

    Habe schon herausgefunden dass es mit DNSSEC zutun hat und habe es bei meinem DNS deaktiviert.
    DNSSEC dient ja der Verifizierung einer DNS-Anfrage.
    Was ich nicht rausgefunden habe ist woher der Fehler kommt und ob es Kritisch ist es zu deaktivieren.

    Wenn du das deaktivierst, wird nicht mehr verifiziert ob deine forwarders DNSsec sprechen und somit validiert, ob die Antwort tatsächlich stimmt, oder die IP-Adresse nicht zur FQDN passt und vice versa, und du dann auf einer fremden Seite landest. Die Entscheidung muss man selber treffen. Dass bei der Übermittlung von DNSsec etwas schief läuft, kann auch noch andere technische Ursachen haben und muss nicht per se auf etwas zwielichtiges hindeuten.

    Eine Idee wäre zu schauen, ob dir das selbe mit den nameservern von google (8.8.8.8, 8.8.4.4) passiert und die OpenDNS Server herausnehmen oder im Log nochmal gegenprüfen.

    Eine weitere gute Idee wäre, hier die gesamte Ausgabe von /etc/bind/named.conf.options zu posten, das oben kann doch nicht alles sein, oder?

    Mfg,

    sls

    “Don’t comment bad code - rewrite it.”

    Brian Kernighan

  • Hallo,

    viel mehr steht nicht drin.


    Habe nun nochmal mit den Google DNS Diensten getestet und es kommen keine Fehler.
    Ich lasse DNSSEC mal an.

    Hier noch die namend.conf.local


    Gruß
    T

  • Na gut, ob man jetzt noch ACLs konfigurieren möchte, kann man selbst überlegen (also welches Subnetz bspw. Anfragen an deinen DNS-Server stellen darf etc.). Nutzt du daheim auch IPv6? Andernfalls würde der Eintrag listen-on-v6 { any }; keinen Sinn machen und sollte evtl. auf "none" gesetzt werden.

    Sofern deine Fragen beantwortet sind, sollte das ja bis hierhin ausreichen. Falls weiteres Interesse besteht, kann ich dir dazu folgendes Tutorial empfehlen: https://www.digitalocean.com/community/tuto…on-ubuntu-16-04

    Das etwas ausführlicher und nicht nur darauf beschränkt, die Funktionalität zu gewährleisten, sondern auch zu erläutern, warum man was tut und welche Auswirkungen das haben kann.

    Mfg,

    sls

    “Don’t comment bad code - rewrite it.”

    Brian Kernighan

  • Vielen Dank
    Damit sollten alle Fragen beantwortet sein.

    Selten in einem Forum so gute Hilfe bekommen.

    Danke und ein schönes Wochenende


    Gruß
    T

    Gesendet von meinem D6603 mit Tapatalk

  • Hi,

    mein problem ist wieder da.

    Was kann noch die Ursache dafür sein?

    Code
    Ping wird ausgeführt für TA-PC.angl.loc [62.138.238.45] mit 32 Bytes Daten:
    Antwort von 62.138.238.45: Bytes=32 Zeit=177ms TTL=248
    Antwort von 62.138.238.45: Bytes=32 Zeit=184ms TTL=248
    
    
    Ping-Statistik für 62.138.238.45:
       Pakete: Gesendet = 2, Empfangen = 2, Verloren = 0
       (0% Verlust),
    Ca. Zeitangaben in Millisek.:
       Minimum = 177ms, Maximum = 184ms, Mittelwert = 180ms

    Mir ist auch aufgefallen dass die gleiche IP kommt wenn ich meine Domain anpinge.

    Code
    Ping wird ausgeführt für angl.loc [62.138.238.45] mit 32 Bytes Daten:
    Antwort von 62.138.238.45: Bytes=32 Zeit=177ms TTL=248
    Antwort von 62.138.238.45: Bytes=32 Zeit=184ms TTL=248
    
    
    Ping-Statistik für 62.138.238.45:
       Pakete: Gesendet = 2, Empfangen = 2, Verloren = 0
       (0% Verlust),
    Ca. Zeitangaben in Millisek.:
       Minimum = 177ms, Maximum = 184ms, Mittelwert = 180ms

    EDIT:
    Vergiss es, habe den Fehler gefunden.
    Mein DNS war tot.

    Dass heißt ja dann die IP von oben kommt von meinem Fritzbox DNS Server oder?

    Gruß
    T

    Einmal editiert, zuletzt von DerT (29. April 2017 um 21:27)

  • Hi,

    wie löst nslookup am Windows-Client denn mittlerweile auf? Bitte Ausgabe posten.

    Auf dem PI läuft auch der DHCP-Server? Wie ist dieser Konfiguriert, bitte Angaben darüber mitteilen. Das DNS-Suffix für die domain angl.loc. ist in der ipconfig /all Ausgabe nicht enthalten.

    Auch von der überarbeiteten Reverse-Lookup-Zone nochmal die Angaben mitteilen.

    Edit: mehrere DNS-Server in einem Subnetz ist die eine Sache, aber mehrere DHCP-Server sollte man meiden.

    “Don’t comment bad code - rewrite it.”

    Brian Kernighan

    Einmal editiert, zuletzt von sls (29. April 2017 um 21:26)

  • Hi,

    NSLookup ausgabe

    Code
    C:\Users\TA>nslookup pi-srv.angl.loc
    Server:  ns1.angl.loc
    Address:  192.168.170.2
    
    
    Name:    ns1.angl.loc
    Address:  192.168.170.2
    Aliases:  pi-srv.angl.loc


    Zitat

    Auf dem PI läuft auch der DHCP-Server?


    Ja es Läuft auch ein DHCP Server auf dem PI. Der DHCP der Fritzbox ist deaktiviert.

    DHCPD.CONF


    Die Syntax der Reservierten IPs ist komplett identisch.

    Reverse Lookup Zone

  • Bestand das Problem schon bevor der PI als DNS/DHCP-Server eingesetzt wurde?

    Eine Möglichkeit wäre jetzt, den DNS-Server vom Router mal komplett heraus zu nehmen und zu deaktivieren (192.168.170.1). DNS-Cache von BIND inklusive deiner Windows-Büchse zu löschen und nochmal zu pingen. Dann auch mal testen, ob andere Rechner im Netz das gleiche Problem haben (Testweise Linux-Kisten / gemixt)

    Was mich noch etwas stört ist der CNAME für pi-srv. Ja, man kann einen DNS-Server auf einen anderen Hostname umbiegen, was nicht schön ist, aber "gehen soll". Man muss aber immer davon ausgehen, dass nicht jedes Betriebssystem das verkraftet. Ich kenne mich mit Windows leider nicht so gut aus, weiß aber, dass die Auflösung hier (bspw. über die Hosts-Datei) etwas anders funktioniert als unter Linux.

    Falls alles nichts hilft, wäre mein Vorschlag noch, die CNAMEs temporär herauszunehmen.

    PS: führe mal bitte auf dem DNS-Server (Pi) "curl http://ipinfo.io/ip" aus (oder auf whatismyip.com gehen), stimmt die dabei entstandene IP mit der überein, die dir aus den Ping-Anfragen antwortet?

    “Don’t comment bad code - rewrite it.”

    Brian Kernighan

    Einmal editiert, zuletzt von sls (29. April 2017 um 22:31)

  • Zitat

    Bestand das Problem schon bevor der PI als DNS/DHCP-Server eingesetzt wurde?


    Kann ich dir leider nicht sagen da ich da nicht mit Namen, sondern nur mit IPs gearbeitet habe.

    Zitat

    Eine Möglichkeit wäre jetzt, den DNS-Server vom Router mal komplett heraus zu nehmen und zu deaktivieren (192.168.170.1). DNS-Cache von BIND inklusive deiner Windows-Büchse zu löschen und nochmal zu pingen. Dann auch mal testen, ob andere Rechner im Netz das gleiche Problem haben (Testweise Linux-Kisten / gemixt)


    Hab das Problem nun mal mit meiner Maschine nachgestellt.
    Es tritt auf sobald ein externer DNS versucht den Namen aufzulösen. Dabei ist es egal ob es Meine Fritzbox ist (welche ja die Anfrage nur weitergibt) oder ein DNS-Server von Google (8.8.8.8). Sobald ich den DNS-Dienst auf dem Pi wieder starte und einen /flushdns mache ist alles in Ordnung.

    Meine Linux Maschine sagt "unknown host" sobald der pi aus ist.

    Zitat

    Was mich noch etwas stört ist der CNAME für pi-srv. Ja, man kann einen DNS-Server auf einen anderen Hostname umbiegen, was nicht schön ist, aber "gehen soll". Man muss aber immer davon ausgehen, dass nicht jedes Betriebssystem das verkraftet. Ich kenne mich mit Windows leider nicht so gut aus, weiß aber, dass die Auflösung hier (bspw. über die Hosts-Datei) etwas anders funktioniert als unter Linux.

    Das Problem tritt aber auch bei anderen Geräten auf, die keinen CNAME haben.


    Zitat

    PS: führe mal bitte auf dem DNS-Server (Pi) "curl http://ipinfo.io/ip" aus (oder auf whatismyip.com gehen), stimmt die dabei entstandene IP mit der überein, die dir aus den Ping-Anfragen antwortet?


    Nein.
    Dabei kommt folgendes raus

    Code
    pi@pi-srv:~ $ curl ipinfo.io/ip
    62.156.31.72


    Gruß

    T

  • Hab das Problem nun mal mit meiner Maschine nachgestellt.
    Es tritt auf sobald ein externer DNS versucht den Namen aufzulösen. Dabei ist es egal ob es Meine Fritzbox ist (welche ja die Anfrage nur weitergibt) oder ein DNS-Server von Google (8.8.8.8). Sobald ich den DNS-Dienst auf dem Pi wieder starte und einen /flushdns mache ist alles in Ordnung.

    Meine Linux Maschine sagt "unknown host" sobald der pi aus ist.

    Nein, die Fritzbox gibt die (interne) Anfrage nicht weiter bzw. sollte sie nicht, genauso wenig wie der Pi-DNS-Server sie weiterreichen sollte, da er dein local resolver ist. Er erkennt, dass die Anfrage zu einem record im eigenen zone file matcht, kann er selbst nicht auflösen, reicht (forwarding) er die Anfrage an den externen DNS-Server weiter.


    Zitat


    Das Problem tritt aber auch bei anderen Geräten auf, die keinen CNAME haben.

    Logisch tritt es auch bei allen anderen Clients auf, da der CNAME ja für den pi-srv (ns1) gesetzt wurde, an welchen ja auch die Anfragen aller Clients (im besten Fall) gesendet werden. Ich gebe dir in sofern recht, als dass ich das Phänomen nicht für Linux kenne, was nicht heißt, dass es dort nicht auch zu Problemen führen kann.


    Zitat

    Nein.
    Dabei kommt folgendes raus

    pi@pi-srv:~ $ curl http://ipinfo.io/ip
    62.156.31.72

    Für mich klingt das so, als wenn dein lokaler DNS nicht weiß was er mit der Anfrage anfangen soll und schubst diese zum externen DNS weiter. Das Problem liegt dann in deinen Zonendateien.

    Nochmal EDIT: sehe ich das denn richtig, dass es mit dem Pi grundlegend funktioniert, aber sobald deine fritzbox mitwurschtelt am DNS, es zu Problemen kommt? Falls ja, vergiss die Fritzbox, und löse das Problem lieber anders. Dass dir ein Pi wegraucht ist relativ, lieber über einen zweiten oder meinetwegen eine VM als sekundäres DNS nachdenken. Die Fritzbox kann mit exotischen Zonen-File-Konstrukten nichts anfangen. Geht eine Anfrage z.B. ICMP an "ns1.angl.loc" wird deine fritzbox diese nicht beantworten können, weil sie selber den CNAME nicht kennt.

    Mfg

    “Don’t comment bad code - rewrite it.”

    Brian Kernighan

    Einmal editiert, zuletzt von sls (29. April 2017 um 23:44)

  • Zitat


    Logisch tritt es auch bei allen anderen Clients auf, da der CNAME ja für den pi-srv (ns1) gesetzt wurde, an welchen ja auch die Anfragen aller Clients (im besten Fall) gesendet werden. Ich gebe dir in sofern recht, als dass ich das Phänomen nicht für Linux kenne, was nicht heißt, dass es dort nicht auch zu Problemen führen kann.


    Ach so meintest du dass.

    Okay, werde den CNAME rausnehmen.

    Zitat

    Nochmal EDIT: sehe ich das denn richtig, dass es mit dem Pi grundlegend funktioniert, aber sobald deine fritzbox mitwurschtelt am DNS, es zu Problemen kommt? Falls ja, vergiss die Fritzbox, und löse das Problem lieber anders. Dass dir ein Pi wegraucht ist relativ, lieber über einen zweiten oder meinetwegen eine VM als sekundäres DNS nachdenken. Die Fritzbox kann mit exotischen Zonen-File-Konstrukten nichts anfangen. Geht eine Anfrage z.B. ICMP an "ns1.angl.loc" wird deine fritzbox diese nicht beantworten können, weil sie selber den CNAME nicht kennt.


    Nicht ganz.
    Mit dem Pi funktioniert es und sobald ein anderer DNS mitspielt, also der Pi aus ist und mein PC auf einen Sec.DNS zugreift, kommen die falschen IPs.
    Dabei ist egal ob der Sec.DNS meine FritzBox oder GoogleDNS oder OpenDNS ist.

    Gruß
    T

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!