[BIND9]Update komt niet goed door. Bug?

Pagina: 1
Acties:

  • axis
  • Registratie: Juni 2000
  • Laatst online: 26-01-2023
Denk dat NOS het beste forum is, zo niet, alvast mijn excuses..

Ik heb een probleempje met een BIND9. Althans, nu is het symptoom oplost, maar nu moet ik een verklaring zien te vinden, of de oorzaak zien te vinden.. (En de klant is ook erg nieuwsgierig naar de oorzaak)

Momenteel heb ik 2 nameservers in gebruik, beiden Bind 9.3.2-P1-1 uit de Debian testing apt repository, en dat draait geweldig. Dit is pas het eerste probleempje dat ik met Bind heb.
Deze 2 nameservers zijn beiden enkel slaves, er draait 1 MS DNS server (Win2k3) in een afgeschermd netwerk die authoritive is voor de ca. 600 domeinen, en waar we alle wijzigingen op maken. Nog wel althans.

(Ik zal de gebruikte ip-adressen voor de privacy even allemaal met 123.123 laten beginnen, en het domein met domain.nl aanduiden)

Ok, nu komen we bij het probleem: Ik heb een site, die na een migratie naar een ander ip niet helemaal over lijkt te zijn, maar lijkt te loadbalancen. De ene keer de nieuwe site, andere keer de oude site.

Ik doe een nslookup, en wat blijkt:
code:
1
2
3
axis@scanner:~$ host www.domain.nl
www.domain.nl has address 123.123.225.45
www.domain.nl has address 123.123.35.233

Euh? Ik weet toch zeker dat ik niet 2 hosts records heb aangemaakt (die .45 is de nieuwe server). Ik kijk op de MS DNS server, en daar zie ik maar 1 www host record. Als ik een query doe naar de MS DNS server, krijg ik alleen maar het nieuwe ip, zoals het hoort.

Voor de zekerheid nog maar eens met de hand het serienummer ophogen. Ik zie dat de slaves een notify krijgen, en een nieuwe versie ophalen.

Maar nog steeds een tweede record voor www, maar wel het goede serienummer!:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
$ORIGIN .
$TTL 3600       ; 1 hour
domain.nl     IN SOA  ns1.provider.nl. systeembeheer.provider.nl. (
                                2006091518 ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
$TTL 86400      ; 1 day
                        NS      ns1.provider.nl.
                        NS      ns2.provider.nl.
                        A       123.123.225.45
                        A       123.123.35.233
                        MX      10 mail.provider.nl.
                        MX      30 etrn.provider.nl.
$ORIGIN domain.nl.
*                       A       123.123.225.45
                        A       123.123.35.233
ftp                     CNAME   ftp9.provider.nl.
localhost               A       127.0.0.1
mail                    CNAME   mail.provider.nl.
www                     A       123.123.225.45
                        A       123.123.35.233

Nu breekt mijn klomp. Dan herstart ik Bind (/etc/init.d/bind9 restart), nog geen verschil.. Serienummer ophogen, notify, geen verschil. DNS lookup geeft nog steeds 2 ip's.

Nu gooi ik de zone file op m'n slave weg, en herstart bind (zie dat ie de zone weer gaat transferren), en plots is het extra record weg. Naja..

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$ORIGIN .
$TTL 3600       ; 1 hour
domain.nl     IN SOA  ns1.provider.nl. systeembeheer.provider.nl. (
                                2006091518 ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
$TTL 86400      ; 1 day
                        NS      ns1.provider.nl.
                        NS      ns2.provider.nl.
                        A       123.123.225.45
                        MX      10 mail.provider.nl.
                        MX      30 etrn.provider.nl.
$ORIGIN domain.nl.
*                       A       123.123.225.45
localhost               A       127.0.0.1
mail                    CNAME   mail.provider.nl.
www                     A       123.123.225.45


Iemand enig idee wat hier aan de hand zou kunnen zijn? Weet iemand of dit een 'confirmed bug' is? Google is mijn grootste vriend, maar hier weet ik ook niet meer zo goed waar ik op moet zoeken. Iemand suggesties?

Two advices for network troubleshooting.. learn to draw diagrams in Visio, and THINK IN LAYERS!


Verwijderd

Doe eens je configuratie files van die bind machines en een beschrijving van je MS-DNS configuratie.

  • axis
  • Registratie: Juni 2000
  • Laatst online: 26-01-2023
Verwijderd schreef op vrijdag 15 september 2006 @ 16:25:
Doe eens je configuratie files van die bind machines en een beschrijving van je MS-DNS configuratie.
config file van bind machine (heb de 3 config files samen gevoegd die bedian standaard split)
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
acl "local_net" {
        localhost;
        123.123.225.0/25;
};

acl "slaves" {
        123.123.35.220;
};
options {
        directory "/etc/bind";
        version "surely you must be joking";
        auth-nxdomain no;
        recursion yes;
        allow-recursion {
                local_net;
        };
        allow-transfer {
                slaves;
        };
};

// 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";
};

// customer zones...

zone "domain.nl" {
        type slave;
        file "slaves/db.domain.nl";
        masters {
                123.123.35.105;
        };
};

De MS DNS machine is dus die .35.105.. Valt niet veel over te vertellen, een standaard windows server 2003 std, met een 600 zones.. SP1 is geinstalleerd, en patches worden automatisch 's nachts geinstalleerd indien beschikbaar. Ik heb echter, hoe graag ik die windows doos ook verdenk, niet het vermoeden dat daar het probleem ligt, ook aangezien die in ieder geval goed reageerde.. Had eigenlijk met dig een AFXR moeten testen.. Naja, dat kan ik alsnog doen als blijkt dat het probleem nog een keer op treedt.

Two advices for network troubleshooting.. learn to draw diagrams in Visio, and THINK IN LAYERS!


  • Sendy
  • Registratie: September 2001
  • Niet online
Hoeveel tijd heb je gewacht na de eerste update? Ik las daarnet iets over stale RRs. (Zoek naar "bind stale records".) Records waarvoor de TTL verlopen is worden eens per uur opgeruimt. Het zou kunnen zijn dat het zo'n stale record was.

Ik heb dit nog nooit gezien met een bind primary server; misschien zit er iets in de Windows DNS server dat dit toestaat?

  • axis
  • Registratie: Juni 2000
  • Laatst online: 26-01-2023
Oorzaak gevonden!

Het is een oud topic, maar ik wil toch even op mezelf reageren, ook voor de zoekende medemensch, die tegen hetzelfde probleem aan loopt.

Aangezien ik het probleem nu ook weer had met een BIND 9.3.3 machine (in base FreeBSD 6.2), ben ik er weer eens opnieuw ingedoken. Tijdens het tikken van een post voor de bind usenet-groep, ging er opeens een lampje branden: de IXFR, de incrementele filetransfer.

De sniffer aangezwengeld, en inderdaad na elke wijziging op de windows machine, stuurt deze de bind een notify naar de slaves. Deze haalt de SOA op, ziet dat er een wijziging is, en geeft een IXFR commando. De windows doos geeft de wijzigingen terug, en BIND voegt de wijzigingen toe aan de bestaande records, in plaats van dat ie ze overschrijft. Lijkt me dat BIND of MS-DNS zich niet aan een of andere RFC houdt, maar goed.

Ik heb nu in BIND aangegeven dat ie geen IXFR's moet doen met:
code:
1
2
3
options {
        request-ixfr no;
};

En nu werkt alles als een zonnetje.

Two advices for network troubleshooting.. learn to draw diagrams in Visio, and THINK IN LAYERS!