DNS Mysterium: Zwei identische Anfragen, zwei verschiedene Ergebnisse

[alex0801]

Hallo zusammen,

ich quäle mich gerade mit dem Thema DNS und FritzBox herum:

Ich habe im internen Netz einen kleinen Linux-Server der mit meinem vRoot kommunizieren soll. Hat bis gestern, als ich den vRoot auf einen neuen Host und damit auch auf eine neue IP umgezogen hab prima geklappt.

Während so ziemlich alle meine Endgeräte (PC auf Arbeit, Smartphone unterwegs, ...) die DNS Änderung mitbekommen haben, verhält sich die FB seltsam:

vRoot IP Alt (aber noch erreichbar): 78.46.150.75
vRoot IP Neu: 78.46.184.70

Betroffene Domains: www.root1.de / root1.de

auf dem lokalen Linux-Server:

ping root1.de --> löst auf zu neuer IP
ping www.root1.de --> löst auf zu neuer alter IP

NSCD unter Linux restarten/leeren hat nix gebraucht, genauso wie ein Reboot. Hat auch keine Änderung hervor gerufen.

Jetzt kommt das seltsame:

~$ host -v www.root1.de
Trying "www.root1.de"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20302
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.root1.de. IN A

;; ANSWER SECTION:
www.root1.de. 14794 IN CNAME new.root1.de.
new.root1.de. 14794 IN A 78.46.150.75

Received 64 bytes from 192.168.200.1#53 in 1 ms
Trying "new.root1.de"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4925
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;new.root1.de. IN AAAA

;; ANSWER SECTION:
new.root1.de. 85742 IN CNAME server.root1.de.

;; AUTHORITY SECTION:
root1.de. 2942 IN SOA ns1.first-ns.de. postmaster.robot.first-ns.de. 2015083109 14400 1800 604800 86400

Received 117 bytes from 192.168.200.1#53 in 1 ms
Trying "new.root1.de"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11270
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;new.root1.de. IN MX

;; ANSWER SECTION:
new.root1.de. 85742 IN CNAME server.root1.de.

;; AUTHORITY SECTION:
root1.de. 2942 IN SOA ns1.first-ns.de. postmaster.robot.first-ns.de. 2015083109 14400 1800 604800 86400

Received 117 bytes from 192.168.200.1#53 in 1 ms

Wird also zur alten IP aufgelöst (nicht von dem new.root1.de irritieren lassen. Das ist uralt und stammt von einem noch älteren serverumzug. Da gab es diese FB noch nicht). Abgefragt wurde der DNS unter 192.168.200.1 Port 53 --> Das ist die Fritzbox.

Okay, mal "dig" probieren:

~$ dig @192.168.200.1 www.root1.de

; <<>> DiG 9.9.5-9+deb8u2-Debian <<>> @192.168.200.1 www.root1.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21895
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.root1.de. IN A

;; ANSWER SECTION:
www.root1.de. 85391 IN CNAME server.root1.de.
server.root1.de. 85391 IN A 78.46.184.70

;; Query time: 1 msec
;; SERVER: 192.168.200.1#53(192.168.200.1)
;; WHEN: Tue Sep 01 08:34:52 CEST 2015
;; MSG SIZE rcvd: 67

Huch? Zwei Anfragen selber Natur an den selben DNS und zwei verschiedene Antworten?

Hab testweise auch schon versucht in der FB in den Interneteinstellungen statt des 1&1 DNS den Google DNS einzutragen. Macht keinen Unterschied. Auch ein Neu-Verbinden sowie ein Neustart der FB ändert nichts.

Was mach ich falsch? Wieso liefert die FB zwei unterschiedliche Ergebnisse?

- Alex

 

[HabNeFritzbox]

Liegt wohl an deinem DNS Server, oder evt. Lokal am Gerät noch alten Eintrag gecacht.

Ohne www hast auch noch nen AAAA Record mit drinnen.

C:\>nslookup root1.de
Name: root1.de
Addresses: 2a01:4f8:c17:135::2
78.46.184.70

C:\>nslookup www.root1.de
Name: server.root1.de
Address: 78.46.184.70
Aliases: www.root1.de

C:\>nslookup www.root1.de 8.8.8.8
Server: google-public-dns-a.google.com
Address: 8.8.8.8

Name: server.root1.de
Address: 78.46.184.70
Aliases: www.root1.de

C:\>nslookup root1.de 8.8.8.8
Server: google-public-dns-a.google.com
Address: 8.8.8.8

Name: root1.de
Addresses: 2a01:4f8:c17:135::2
78.46.184.70

 

[alex0801]

Liegt wohl an deinem DNS Server, oder evt. Lokal am Gerät noch alten Eintrag gecacht.

Der DNS liefert passende Einträge. Das hab ich

a) in den Nameservereinträgen direkt im DNS
b) mit unterschiedlichen Nameservern
c) mit unterschiedlichen Geräten und
d) unterschiedlichen Internetzugängen getestet.

Was nicht passt ist, dass Geräte hinter der Fritzbox (vornehmlich der lokale Linux-Server) wie oben gezeigt mal den alten und mal den neuen Eintrag auflösen.

Im Linux selbst habe ich ebenfalls alles versucht:

* Reboot
* NameServiceCacheDaemon neu gestartet
* NSCD "geleert"
* Testweise von FB-DNS auf Google-DNS umgestellt und wieder zurückgestellt (um neue Einträge im Cache zu forcieren) ...

Sowohl das "host" als auch das "dig" Kommando befragen den DNS. In beiden Fällen wurde die FB befragt und dennoch gibt es unterschiedliche Ergebnisse von der FB.

Aktuell scheint's nun zu funktionieren.
Kann mir nur so erklären, dass einer der beiden DNS den die FB verwendet noch keinen neuen Stand hatte und die eine Abfrage beim einen, und die andere beim anderen DNS gelandet ist.

 

[PeterPawn]

Kann mir nur so erklären, dass einer der beiden DNS den die FB verwendet noch keinen neuen Stand hatte und die eine Abfrage beim einen, und die andere beim anderen DNS gelandet ist.

Die Box verwendet meines Wissens nur einen einzelnen DNS-Server für Abfragen (der, den sie im GUI entsprechend markiert). Der zweite Server wird nur bei einem Timeout des ersten ebenfalls zu Rate gezogen, nicht bei einer "NXDOMAIN"-Antwort ... deshalb ist auf diesem Wege auch kein "split DNS" (ein Server für extern, einer für intern) möglich.

 

[alex0801]

Hatte ich befürchtet. Mach ja das Standard-Linux auch so.

Dann habe ich aber keine Erklärung mehr warum zwei offensichtlich identische Abfragen an die FB reproduzierbar zwei unterschiedliche Ergebnisse liefert.

Die Ursache der Falsch-Antwort war wohl ein DNS des Providers der nicht ganz up2date war, es jetzt aber ist. Denn reproduzieren kann ich's mittlerweile - wie im letzten Post erwähnt - nicht mehr.

 

[HabNeFritzbox]

Falls DNS verwaltest der Domain mach für www einfach CNAME auf Domain. Damit erledigt sich dann auch fehlender AAAA bei www.

 

[alex0801]

Fehlenden AAAA hab ich eben nachgerüstet. Hatte ich in meiner Umzugseile vergessen.

 

[sf3978]

Dann habe ich aber keine Erklärung mehr warum zwei offensichtlich identische Abfragen an die FB reproduzierbar zwei unterschiedliche Ergebnisse liefert.

M. W. sind die Abfragen mit host und dig nicht identisch. dig fragt zu erst auch den DNS-Server aus der resolv.conf (des PCs auf dem Du dig ausführst). Das kannst Du z. B. mit:

sudo tcpdump -vvveni any port 53

feststellen.

 

[alex0801]

Blöd wenn in der resolv.conf einzig und allein die FB drin steht. Somit landen beide Anfragen doch wieder am selben DNS (nämlich die FB).

Einen Dump habe ich nicht gemacht, da in beiden Varianten auch in der Ausgabe zu lesen war welche DNS die Frage beantwortet hat (jedesmal die FB).

In die Anfrage wurde ja auch rausgedruckt. Und die war identisch.

 

[sf3978]

Blöd wenn in der resolv.conf einzig und allein die FB drin steht. Somit landen beide Anfragen doch wieder am selben DNS (nämlich die FB).

Das muss nicht der Fall sein, denn Du weißt ja nicht welchen dns-cache dig nutzt und ob Du diesen cache gelöscht hast.

..., da in beiden Varianten auch in der Ausgabe zu lesen war welche DNS die Frage beantwortet hat (jedesmal die FB).

Die Ausgabe von dig zeigt nur welcher DNS-Server bei der Ausführung von dig angegeben war, aber nicht den DNS-Server von dem auch die Namensauflösung kommt.

 

[alex0801]

Das muss nicht der Fall sein, denn Du weißt ja nicht welchen dns-cache dig nutzt und ob Du diesen cache gelöscht hast.

Welchen Cache, der auch einen Rechnerneustart übersteht (außer den NameServiceCacheDaemon den ich testweise wie gesagt gestopped, neugestartet und dessen cache geleert hatte) sollte den Dig noch benutzen?


Tante Google weiß entweder nichts genaueres dazu, oder sie hat meine Frage nicht verstanden.

 

[sf3978]

Tante Google weiß entweder nichts genaueres dazu, oder sie hat meine Frage nicht verstanden.

Die Anfragen wären identisch gewesen, wenn Du den Eintrag in der resolv.conf für dig nicht zugänglich gemacht hättest. Es ist schon ein Unterschied, ob dig (und host) die 192.168.200.1 nur direkt abfragen kann, oder zusätzlich auch "indirekt" (als 1. Abfrage) über die resolv.conf abfragt.

 

[alex0801]

Die Anfragen wären identisch gewesen, wenn Du den Eintrag in der resolv.conf für dig nicht zugänglich gemacht hättest. Es ist schon ein Unterschied, ob dig (und host) die 192.168.200.1 nur direkt abfragen kann, oder zusätzlich auch "indirekt" (als 1. Abfrage) über die resolv.conf abfragt.

Kannst du das genauer erklären?

Ich seh den Unterschied nämlich nicht:


Fall "resolv.conf für dig zugänglich"

dig schaut in resolv.conf, findet 192.168.200.1 (FB) und frägt da nach

Fall "resolv.conf für dig nicht zugänglich"

dig kann nicht in resolv.conf schauen und nimmt den angegebenen NS 192.168.200.1 (FB) und frägt da nach

In beiden Fällen landet die Anfrage (sofern kein ominöser unbekannter Cache dazwischen funkt) beim FB-eingebauten DNS, der ggf. selbst cached und beim Provider bzw. dem eingestellten DNS nachfrägt wenn er es selbst nicht weiß.

 

[sf3978]

Ich seh den Unterschied nämlich nicht:

Dann hast Du evtl. die Ausgaben von tcpdump nicht verglichen.

 

[alex0801]

So, tcpdump mal gemacht:

Host frägt den AAAA Eintrag an, dig nur den A. Das ist der Unterschied der aktuell noch auffällt.

 

[sf3978]

Host frägt den AAAA Eintrag an, ...

Nicht wenn Du z. B. für host "-t A" benutzt.