Authority Problem mit Bind9

[mathiasr]

Hallo,

ich habe ein Problem mit Bind9: Eine Abfrage von mydomain.tld wird nicht als authority gekennzeichnet, eine Abfrage von subdomain.mydomain.tld hingegen arbeitet einwandfrei.

Code: Select all

ns1:~# dig @ns1.mydomain.tld mydomain.tld any

; <<>> DiG 9.2.1 <<>> @ns1.mydomain.tld mydomain.tld any
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29806
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;mydomain.tld.                  IN      ANY

;; ANSWER SECTION:
mydomain.tld.           86400   IN      SOA     ns1.mydomain.tld. hostmaster.mydomain.tld. 2002010101 28800 7200 604800 39600
mydomain.tld.           86400   IN      NS      ns2.mydomain.tld.
mydomain.tld.           86400   IN      NS      ns1.mydomain.tld.
mydomain.tld.           3600    IN      A       81.169.154.116
mydomain.tld.           86400   IN      MX      20 backup.mydomain.tld.
mydomain.tld.           86400   IN      MX      10 mail.mydomain.tld.

;; ADDITIONAL SECTION:
ns1.mydomain.tld.       86400   IN      A       81.169.154.116
ns2.mydomain.tld.       86400   IN      A       83.151.27.175
mail.mydomain.tld.      86400   IN      A       81.169.154.116
backup.mydomain.tld.    86400   IN      A       83.151.27.175

;; Query time: 180 msec
;; SERVER: 81.169.154.116#53(ns1.mydomain.tld)
;; WHEN: Fri Mar  4 12:54:22 2005
;; MSG SIZE  rcvd: 237

ns1:~# dig @ns1.mydomain.tld subdomain.mydomain.tld any

; <<>> DiG 9.2.1 <<>> @ns1.mydomain.tld subdomain.mydomain.tld any
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40422
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;subdomain.mydomain.tld.                IN      ANY

;; ANSWER SECTION:
subdomain.mydomain.tld. 3600    IN      A       81.169.154.116

;; AUTHORITY SECTION:
mydomain.tld.           86400   IN      NS      ns2.mydomain.tld.
mydomain.tld.           86400   IN      NS      ns1.mydomain.tld.

;; ADDITIONAL SECTION:
ns1.mydomain.tld.       86400   IN      A       81.169.154.116
ns2.mydomain.tld.       86400   IN      A       83.151.27.175

;; Query time: 69 msec
;; SERVER: 81.169.154.116#53(ns1.mydomain.tld)
;; WHEN: Fri Mar  4 13:03:55 2005
;; MSG SIZE  rcvd: 124

Setze ich Bind8 ein erhalte ich die korrekte Antwort:

Code: Select all

ns1:~# dig @ns2.mydomain.tld mydomain.tld any

; <<>> DiG 9.2.1 <<>> @mr8.de mydomain.tld any
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40073
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 2, ADDITIONAL: 4

;; QUESTION SECTION:
;mydomain.tld.                  IN      ANY

;; ANSWER SECTION:
mydomain.tld.           86400   IN      MX      10 mail.mydomain.tld.
mydomain.tld.           86400   IN      MX      20 backup.mydomain.tld.
mydomain.tld.           3600    IN      A       81.169.154.116
mydomain.tld.           86400   IN      NS      ns1.mydomain.tld.
mydomain.tld.           86400   IN      NS      ns2.mydomain.tld.
mydomain.tld.           86400   IN      SOA     ns1.mydomain.tld. hostmaster.mydomain.tld. 2002010101 28800 7200 604800 39600

;; AUTHORITY SECTION:
mydomain.tld.           86400   IN      NS      ns1.mydomain.tld.
mydomain.tld.           86400   IN      NS      ns2.mydomain.tld.

;; ADDITIONAL SECTION:
mail.mydomain.tld.      86400   IN      A       81.169.154.116
backup.mydomain.tld.    86400   IN      A       83.151.27.175
ns1.mydomain.tld.       86400   IN      A       81.169.154.116
ns2.mydomain.tld.       86400   IN      A       83.151.27.175

;; Query time: 12 msec
;; SERVER: 83.151.27.175#53(ns2.mydomain.tld)
;; WHEN: Fri Mar  4 13:55:18 2005
;; MSG SIZE  rcvd: 265

Hier noch die Konfiguration:
named.conf

Code: Select all

options {
	directory "/var/cache/bind";


	auth-nxdomain no;    # conform to RFC1035

};

// prime the server with knowledge of the root servers
zone "." {
	type hint;
	file "/etc/bind/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
	type master;
	file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
	type master;
	file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
	type master;
	file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
	type master;
	file "/etc/bind/db.255";
};

// add entries for other zones below here

zone "mydomain.tld" {
	type master;
	file "/etc/bind/db.default";
};

db.default

Code: Select all

$TTL 86400
@ IN SOA	ns1.mydomain.tld.	hostmaster.mydomain.tld. (
2002010101 ; serial
8H	; refresh
2H	; retry
1W	; expiry
11h)	; minimum

		IN NS	ns1
		IN NS	ns2

@	3600	IN A	81.169.154.116

		IN MX	10 mail
		IN MX	20 backup

mail	IN A	81.169.154.116
backup	IN A	83.151.27.175
ns1	IN A	81.169.154.116
ns2	IN A	83.151.27.175
*	3600	IN A	81.169.154.116

Schon ein frisch installierter Bind9 (Debian 3.0 stable) liefert auf dig@localhost localhost any keine authority Antwort., ein Bind8 hingegen schon.

Wie kommt man diesem Effekt bei?

[[tom]]

So wie es aussieht, liegt ein Fehler vor (thx @ wgot ;-))

Code: Select all

# dig @ns1.mydomain.tld mydomain.tld any
dig: Couldn't find server 'ns1.mydomain.tld': Name or service not known

Warum muss man eigentlich JEDEM sagen, dass NS Probleme nicht mit gefakten Namen gelöst werden? Steht doch in jedem 2. NS Thread. :roll:


[TOM]

[mathiasr]

Das ist definitiv nicht das Problem. Entweder verweist man in der /etc/resolv.conf auf 127.0.0.1 oder trägt die Namen ns1... und ns2... in der /etc/hosts ein.

Der Effekt lässt sich ja, wie erwähnt, sogar mit

Code: Select all

ns1:~# dig @localhost localhost any

; <<>> DiG 9.2.1 <<>> @localhost localhost any
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13873
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;localhost.                     IN      ANY

;; ANSWER SECTION:
localhost.              604800  IN      SOA     localhost. root.localhost. 1 604800 86400 2419200 604800
localhost.              604800  IN      NS      localhost.
localhost.              604800  IN      A       127.0.0.1

;; ADDITIONAL SECTION:
localhost.              604800  IN      A       127.0.0.1

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(localhost)
;; WHEN: Sat Mar  5 06:19:18 2005
;; MSG SIZE  rcvd: 114

Nur wie ist der Fehler im BIND9 zu finden? Was hast Du denn geändert, damit es klappt?

[[tom]]

Frag mal nach A - nicht nach ANY.

Es hat sich auch da Antwortverhalten bei Rekursion und Cached Zones von 8 auf 9 geändert.


[TOM]

[mathiasr]

Aber warum wird bei Subdomains die "korrekte" Antwort incl. AUTHORITY geliefert (auch bei any), bei der Domain selbst hingegen nicht? Dieses inkonsistente Verhalten kann doch wohl nicht beabsichtigt sein.

[[tom]]

Weil Du ja auch nicht authorativ für die Zone (Domain) bist, sondern die Registry (z. B. DENIC). Die delegieren das ja lediglich auf Deinen NS. Du bist dann nur für alles unter Deiner Zone authorativ.


[TOM]

[mathiasr]

Dieser Erklärungsanzsatz klingt zwar logisch, hat aber Schönheitsfehler:

• Bei dig @localhost localhost any ist der Server authoritativ.

• Die Antwort ist abweichend von alten BIND-Versionen sowie MS. Sofern der Server sekundär ist (oder umgekehrt) liefern primärer und sekundärer Server verschiedene Antworten.

• Die Antwort ist abweichend von anderen Antworten zur selben Zone (z.B. in soa) und sollte doch diese zusammenfassen.

• Wie bringt man DENIC dazu, nicht nach type any zu fragen und dabei soa zu vermissen Auszug aus DENIC-Meldung)

  Code: Select all

  Query about xyz.de for record types ANY
  ...
  ns.xyz.com.: NOT AUTHORITATIVE for the zone xyz.de
  == END ==
  

  (Dieser Fehler tritt aber nicht jedes mal bei der DENIC auf, meist geht danach ein Update durch.)

Daher glaube ich nicht unbedingt, das dieses Verhalten beabsichtigt ist. Zumindest darf ich jetzt aber davon ausgehen, dass es nicht auf einen Konfigurationsfehler meinerseits zurückgeht, sondern im Bind9 selbst verursacht wird.

Inter-nette Grüße - Mathias

[[tom]]

Du bringst mich ins Schwitzen - und dazu, in diversen RFC's und DENIC Dokus zu lesen. ;-)

Das Antowrtverhalten von BIND 8 auf BIND 9 hat sich geändert. Das ist auch in den Changelogs vom ISC nachzulesen. Wann ein aa Flag gesetzt wird oder nicht ist von mehreren Faktoren abhängig. Interessant sind in diesem Zusammenhang RFC 1034, RFC 3655 und die BIND Doku.

Ob ein Nameserver sich als authorativ für eine Zone fühlt oder nicht, kann an dem Flag aa erkannt werden (aa = authorativ answer). Diese kommt prinzipiell, wenn die Zonendaten lokal vorliegen und korrekt delegiert wurde. Bei Deinem localhost Beispiel ist dieses Flag gesetzt.

Die Antwort unter AUTHORITY gibt die Anzahl der Antworten aus der AUTHORITY SECTION wieder. Was in dieser Section landet, ist durch die oben genannten RFC's festgelegt und einer der Unterschiede zwischen BIND 8 und BIND 9. Nach viel lesen hab ich diesen Hinweis auch gefunden. ;-)

... Sofern der Server sekundär ist (oder umgekehrt) liefern primärer und sekundärer Server verschiedene Antworten.

Das wage ich zu bezweifeln, sofern keine Fehlkonfiguration vorliegt.

Wie bringt man DENIC dazu, nicht nach type any zu fragen und dabei soa zu vermissen Auszug aus DENIC-Meldung)

Code: Select all

Query about xyz.de for record types ANY
...
ns.xyz.com.: NOT AUTHORITATIVE for the zone xyz.de
== END ==

Was meinst Du mit "und dabei soa zu vermissen"?

DENIC fragt immer nach demTyp ANY - das kannst Du nicht ändern. Die Prüfung erfolgt über die NS, die bei DENIC eingetragen sind und dem aa Flag. Die von Dir zitierte Fehlermeldung bedeutet, dass bei DENIC ein Nameserver als NS eingetragen ist, der nicht authorativ ist, also keinen SOA für die Zone hat. Du kannst das z. B. bequem mit

Code: Select all

host -C example.com

testen.

BTW: Wenn Du Nameserver abfragst, solltest Du für die Abfrage +norec setzen, da Deine Nameserver Rekursion erlauben (Flag ra). Damit stellst Du sicher, dass Du wirklich vom richtigen Nameserver die Antwort erhältst.

[TOM]