Warum schlagen DNS-Abfragen fehl, wenn der erste Nameserver nicht rekursiv ist?

Ich habe eine Linux-Box (Ubuntu Server 11.10) in einer Windows Active Directory-Domäne und bin mit ebenfalls-open der Domäne beigetreten . Die resolv.confDatei sieht folgendermaßen aus:

domain mydomain.com
nameserver 192.168.1.1
nameserver 8.8.8.8
nameserver 8.8.4.4

Wo 192.168.1.1ist der Windows-DNS-Server für die Windows-Domäne? 8.8.8.8und 8.8.4.4sind die öffentlichen DNS-Server von Google, die wir unseren ISP-Servern vorgezogen haben.

Dieses Setup funktionierte ordnungsgemäß, bis wir beschlossen, die Rekursion auf dem Windows-DNS-Server aufgrund einiger Änderungen an unserem Netzwerkdesign zu deaktivieren. Ich dachte, das wird gut gehen, da wir es so konfiguriert haben, dass es als nächstes die Server von Google verwendet, aber es scheint nicht:

mydomain\myuser@linux-server:~$ dig google.com

; <<>> DiG 9.7.3 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55321
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;google.com.                    IN      A

;; AUTHORITY SECTION:
.                       3600    IN      NS      c.root-servers.net.
.                       3600    IN      NS      d.root-servers.net.
.                       3600    IN      NS      e.root-servers.net.
.                       3600    IN      NS      f.root-servers.net.
.                       3600    IN      NS      g.root-servers.net.
.                       3600    IN      NS      h.root-servers.net.
.                       3600    IN      NS      i.root-servers.net.
.                       3600    IN      NS      j.root-servers.net.
.                       3600    IN      NS      k.root-servers.net.
.                       3600    IN      NS      l.root-servers.net.
.                       3600    IN      NS      m.root-servers.net.
.                       3600    IN      NS      a.root-servers.net.
.                       3600    IN      NS      b.root-servers.net.

;; ADDITIONAL SECTION:
c.root-servers.net.     3600    IN      A       192.33.4.12
d.root-servers.net.     3600    IN      A       128.8.10.90
e.root-servers.net.     3600    IN      A       192.203.230.10
f.root-servers.net.     3600    IN      A       192.5.5.241

;; Query time: 4 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Jan  8 14:02:22 2014
;; MSG SIZE  rcvd: 507

Ebenfalls:

mydomain\myuser@linux-server:~$ ping google.com
ping: unknown host google.com

Außerdem habe ich fehlgeschlagene Squid-Proxy-Verbindungen (die ich mit der Option dns_nameservers in der Squid-Konfiguration gelöst und den internen DNS-Server vernachlässigt habe).

Warum schlagen DNS-Anforderungen fehl, wenn die Rekursion vom ersten Nameserver abgelehnt wird? Sollte der Computer nicht den nächsten Server versuchen? Und was kann ich tun, wenn dies das erwartete (entworfene) Verhalten war?

EDIT: NSLOOKUP gab andere (Erfolgs-) Ergebnisse:

mydomain\myuser@linux-server:~$ nslookup google.com
;; Got recursion not available from 192.168.1.1, trying next server
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   google.com
Address: 173.194.67.102
Name:   google.com
Address: 173.194.67.138
Name:   google.com
Address: 173.194.67.100
Name:   google.com
Address: 173.194.67.113
Name:   google.com
Address: 173.194.67.139
Name:   google.com
Address: 173.194.67.101

Ist das also anwendungsabhängig? Kann ich dafür sorgen, dass der nächste Server, wenn der erste die Rekursion ablehnt, für alle Anwendungen, die eine Namensauflösung anfordern, transparent funktioniert, oder dass die Namensauflösung in der Verantwortung des Programms selbst liegt? (oder fehlt mir etwas ?!) ...

EDIT: Ebenfalls erwähnenswert mydomain.comist eine registrierte und öffentliche Adresse im Internet und gehört nicht uns. Es ist, als hätten wir eine interne Domain mit dem Namen eingerichtet apple.com, und ich versichere Ihnen, dass ich nicht für Apple arbeite, zumindest noch nicht ;-).

Ich fürchte, die Antwort wird "es kommt darauf an" sein.

Soweit diges sich handelt, handelt es sich im Grunde genommen um ein Tool zum Debuggen von DNS-Informationen. Auf diese Weise werden Ihnen die Informationen angezeigt, die Sie von dem von Ihnen angeforderten Nameserver erhalten. es geht nicht weiter und stellt weitere Fragen.

Bei anderen Programmen hängt dies vom Programm ab. Die meisten werden wahrscheinlich die Funktionen des Betriebssystems zur Namensauflösung verwenden (siehe man getnameinfo). Andere mögen es nicht. Dies bedeutet, dass beim Auflisten eines nicht rekursiven Nameservers einige Fehler auftreten, die nur schwer zu finden sind.

Mit anderen Worten, es ist eine schlechte Idee, einen nicht rekursiven Nameserver in Ihrer Resolver-Liste zu belassen.

Wenn Sie nicht möchten, dass der Windows-Server rekursiv ist, würde ich empfehlen, einen separaten Server als Resolver einzurichten und diesen den Windows-Server nach den internen Domänen fragen zu lassen.