[BIND9] Geen caching ofzo? - Linux en overige clients

woensdag 13 oktober 2004 22:12

Acties:

Verwijderd

Topicstarter

Even een overview: ik heb een server (router/http/ftp/smb/noemhetmaarop/dns). Ik heb deze altijd als caching-only gedraaid. Maar toen had ik er ook een dhcp-server opgezet, en ik wou ook graag zorgen dat de hostnames van computers op mijn netwerkje geresolved werden, zonder /etc/hosts om inconsistentie te vermijden.

Dat heb ik gerealiseerd door bekende computers een vast IP te geven in dhcp. Deze computers krijgen dus ook een A record in mijn dns zone. Hier de dhcp config, gevolgd door de dns config met zone files:

dhcpd.conf

code:

subnet 192.168.0.0 netmask 255.255.255.0 {
        range 192.168.0.10 192.168.0.15;

        option domain-name-servers 192.168.0.1;
        option nntp-server ntp2.theinternetone.net;
        option domain-name "jupiter";
        option routers 192.168.0.1;
        option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.0.255;
        option netbios-name-servers 192.168.0.1;
        one-lease-per-client on;

        default-lease-time 86400;
        max-lease-time 86400;

        option ip-forwarding off;
}

# Clients enzo
host Callisto {
        hardware ethernet 00:50:04:21:6a:ce;
        fixed-address 192.168.0.2;
}

host Ganymede {
        hardware ethernet 00:02:44:4c:28:a1;
        fixed-address 192.168.0.3;
}

named.conf:

code:

options {
        directory "/var/named";

        forward first;
        forwarders {
                194.109.9.99;
                212.142.28.68;
                62.108.1.69;
        };
};

zone "." {
        type hint;
        file "root.hints";
};

zone "0.0.127.in-addr.arpa" {
        type master;
        file "pz/127.0.0";
};

zone "jupiter" {
        type master;
        notify no;
        file "pz/jupiter";
};

zone "0.168.192.in-addr.arpa" {
        type master;
        notify no;
        file "pz/192.168.0";
};

De onderste twee forwarders zijn Chello nameservers; de bovenste is een XS4all nameserver, omdat ik dacht dat het ook aan Chello zou kunnen liggen. Jupiter is de naam van mijn netwerk.

/var/named/pz/127.0.0:

code:

$TTL 3D
@               IN      SOA     europa.jupiter. aap.europa.jupiter. (
                                1       ; Serial
                                8H      ; Refresh
                                2H      ; Retry
                                4W      ; Expire
                                1D      ; Minimum TTL
                                )
                        NS      europa.jupiter.
1                       PTR     localhost.

/var/named/pz/192.168.0:

code:

$TTL 3D
@       IN      SOA     europa.jupiter. aap.europa.jupiter. (
                        199802151       ; Serial
                        8H              ; Refresh
                        2H              ; Retry
                        4W              ; Expire
                        1D              ; Minimum TTL
                        )
                NS      europa.jupiter.

1               PTR     europa.jupiter.
2               PTR     callisto.jupiter.
3               PTR     ganymede.jupiter.

code:

$TTL 3D
@       IN      SOA     europa.jupiter. aap.europa.jupiter. (
                        200410051       ; Serial
                        8H              ; Refresh
                        2H              ; Retry
                        4W              ; Expire
                        1D              ; Minimum
                        )
;
                NS      europa
                NS      europa.jupiter.
                MX      5 europa
;
localhost       A       127.0.0.1

europa          A       192.168.0.1
                TXT     "Server"

callisto        A       192.168.0.2
ganymede        A       192.168.0.3

Ik snap de inhoud van de config files, ik heb deze namelijk aan de hand van de DNS-howto op tldp.org http://www.tldp.org/HOWTO/DNS-HOWTO.html in elkaar gezet.

Het probleem
Als ik surf gaat resolven ontzettend sloom, moet-ie bij iedere site zo'n 30 seconden resolven en zie ik soms in de statusbar dingen als: Resolving host google.nl... Transferring data from google.nl... Resolving host google.nl...

Hosts die ik 3 minuten geleden nog geresolved heb kent ie al niet meer

Hier wat gespeeld met host en time:

code:

Callisto:~# time host -vv www.frikadel.nl
Default domain: Jupiter
Search domains: Jupiter
Timeout per retry: 5 secs
Number of retries: 2
Number of addresses: 1
192.168.0.1
Options set: INIT RECURSE DEFNAMES
Options clr: DEBUG AAONLY USEVC PRIMARY IGNTC STAYOPEN DNSRCH

Query about www.frikadel.nl for record types A
Trying www.frikadel.nl ...
Nameserver not responding
www.frikadel.nl A record not found, try again

real    0m15.002s
user    0m0.000s
sys     0m0.003s

code:

Callisto:~# time host -vv www.frikadel.nl
Default domain: Jupiter
Search domains: Jupiter
Timeout per retry: 5 secs
Number of retries: 2
Number of addresses: 1
192.168.0.1
Options set: INIT RECURSE DEFNAMES
Options clr: DEBUG AAONLY USEVC PRIMARY IGNTC STAYOPEN DNSRCH

Query about www.frikadel.nl for record types A
Trying www.frikadel.nl ...
Query done, 1 answer, status: no error
The following answer is not authoritative:
www.frikadel.nl         1778    IN      A       194.109.6.189
Authority information:
nl                      164443  IN      NS      NS.DOMAIN-REGISTRY.nl
Finding addresses for NS.DOMAIN-REGISTRY.nl ...
nl                      164443  IN      NS      NS2.NIC.FR
Finding addresses for NS2.NIC.FR ...
nl                      164443  IN      NS      NS2.DOMAIN-REGISTRY.nl
Finding addresses for NS2.DOMAIN-REGISTRY.nl ...
Query done, 1 answer, status: no error
nl                      164443  IN      NS      NS5.DOMAIN-REGISTRY.nl
Finding addresses for NS5.DOMAIN-REGISTRY.nl ...
nl                      164443  IN      NS      NS6.DOMAIN-REGISTRY.nl
Finding addresses for NS6.DOMAIN-REGISTRY.nl ...
Query done, 1 answer, status: no error
nl                      164443  IN      NS      SLAVE.STH.NETNOD.SE
Finding addresses for SLAVE.STH.NETNOD.SE ...
nl                      164443  IN      NS      SUNIC.SUNET.SE
Finding addresses for SUNIC.SUNET.SE ...
Query done, 1 answer, status: no error
nl                      164443  IN      NS      NS-EXT.ISC.ORG
Finding addresses for NS-EXT.ISC.ORG ...
nl                      164443  IN      NS      NS.RIPE.NET
Finding addresses for NS.RIPE.NET ...

real    3m46.500s
user    0m0.003s
sys     0m0.003s

Euh jah.. ik weet niet echt wat ik er nog meer voor info bij moet doen, dus hier laat ik het voorlopig even bij.

PS: Ik weet niet zeker of dit topic hier goed staat, het kan uiteraard ook in NT op zijn plaats zijn.

donderdag 14 oktober 2004 02:07

Acties:

Coen Rosdorff

Maak je wel gebruik van je eigen lokale dns-server?

Check eens met host -a www.frikadel.nl 127.0.0.1

En dan nog wat:
Je hebt de resolver van xs4all als forwarder staan. Die kan je alleen gebruiken vanaf het netwerk van xs4all. Een time-out op een forwarder kan een flinke delay geven. Gebruik alleen de resolvers van je eigen provider als forwarder. Of als die .... zijn helemaal geen forwarder.

donderdag 14 oktober 2004 02:26

Acties:

raphidae

...antichrist...

Ik zou niet eens forwarders gebruiken. Gewoon al die forwarders eruit flikkeren en recursion aanzetten voor jouw adressen (of 'any' als ie alleen intern bereikbaar is).

Die extra stap voor het forwarden weegt in veel gevallen niet op tegen het voordeel van de cache van de forwarder, plus je bent met forwarders gebonden aan de minimum TTL die daarop in effect is.

Verder zou ik eens named met '-d 8' (debug level 8 ) runnen, dan kan je in je syslog (local4) (of logfile natuurlijk) precies alle stapjes zien wat ie doet, wat ie verzend en wat ie ontvangt.

succes.

[ Voor 10% gewijzigd door raphidae op 14-10-2004 02:28 ]

Every morning is the dawn of a new error.

donderdag 14 oktober 2004 02:45

Acties:

Verwijderd

Topicstarter

Hmm.. zonder die forwarders duurt het resolven iig nog maar 1 seconde... Ik zal hier eens een week mee werken en als ik dan nog rariteiten tegen kom zal ik met het debug level aan de slag gaan

danku!

donderdag 14 oktober 2004 02:53

Acties:

Verwijderd

little_soundman schreef op 14 oktober 2004 @ 02:07:
Je hebt de resolver van xs4all als forwarder staan. Die kan je alleen gebruiken vanaf het netwerk van xs4all.

Xs4all moet zijn nameservers voor derden openstellen, anders kunnen ze hun eigen domein(en) niet beheren. Om iedereen een loer te draaien heeft men het volgende veranderd:

code:

[mietje@boaz mietje]$ dig xs4all.nl ns +noall +answer +additional

; <<>> DiG 9.1.3 <<>> xs4all.nl ns +noall +answer +additional
;; global options:  printcmd
xs4all.nl.      172800  IN  NS  ns.xs4all.nl.
xs4all.nl.      172800  IN  NS  ns2.xs4all.nl.
xs4all.nl.      172800  IN  NS  ns.ripe.net.
ns.xs4all.nl.       172800  IN  A   194.109.6.67
ns2.xs4all.nl.      172800  IN  A   194.109.9.100
;; Query time: 48 msec
;; SERVER: 194.109.6.67#53(194.109.6.67)
;; WHEN: Thu Oct 14 02:58:39 2004
;; MSG SIZE  rcvd: 119

[mietje@boaz mietje]$ host resolver.xs4all.nl
resolver.xs4all.nl. has address 194.109.6.66
resolver.xs4all.nl. has address 194.109.9.99
resolver.xs4all.nl. has address 194.109.104.104

donderdag 14 oktober 2004 02:57

Acties:

Coen Rosdorff

Een seconde is nog lang.
40ms komt al meer in de buurt

Een goede forwarder kan trouwens erg veel tijd schelen. De resolver van een middelgrote tot grote provider kan je 90% van de queries rechtstreeks geven. Is altijd sneller dan zelf recursive opzoeken. Na de eerste request staat het in je eigen cache, dus dan is er verder geen winst.

donderdag 14 oktober 2004 03:04

Acties:

Coen Rosdorff

Verwijderd schreef op 14 oktober 2004 @ 02:53:
[...]

Xs4all moet zijn nameservers voor derden openstellen, anders kunnen ze hun eigen domein(en) niet beheren. Om iedereen een loer te draaien heeft men het volgende veranderd:

Je gaat wel erg kort door de bocht. Je authoritive nameservers moet je open hebben voor requests van buitenaf. Anders stort het hele dns systeem in

De recursive servers hoef je echter niet voor derden op te stellen.
XS4ALL heeft begin dit jaar (eindelijk) de authoritive en de recursive servers gescheiden. Een foute verhuizing heeft nu voor de xs4all klanten geen nare gevolgen meer. Vroeger werden er wel eens authoritive answers verstrekt voor domeinen waarvoor xs4all helemaal geen authorive answers meer zou moeten verstrekken. Met de splitsing is dat opgelost.

Dat daarnaast nu mooi de load verdeeld over 2 clusters is ook mooi. De recursive servers kunnen zich helemaal richten op cachen, terwijl de authoritive servers lekker kunnen vertellen aan de wereld wat ze weten.

Omdat de dns servers van xs4all erg betrouwbaar zijn werden ze door zeer veel mensen van buitenaf gebruikt. Aangezien je servers niet onberperkt kan belasten gaat dat op een gegeven moment wringen....

donderdag 14 oktober 2004 03:15

Acties:

Verwijderd

little_soundman schreef op 14 oktober 2004 @ 03:04:
Omdat de dns servers van xs4all erg betrouwbaar zijn werden ze door zeer veel mensen van buitenaf gebruikt. Aangezien je servers niet onberperkt kan belasten gaat dat op een gegeven moment wringen....

Je verhaal klopt helemaal maar de implicatie verzwijg je, xs4all kan maar zeer moeilijk voorkomen dat mensen van buiten haar authoritative nameservers gebruiken. De IP + 1 truuk houdt wellicht het gros van die mensen buiten de deur, maar iedereen die weet hoe hij het ip van een authoritative nameserver moet vinden kan gewoon zijn gang gaan. (Dat geldt overigens voor iedere ISP.)

donderdag 14 oktober 2004 03:37

Acties:

Coen Rosdorff

Verwijderd schreef op 14 oktober 2004 @ 03:15:
Je verhaal klopt helemaal maar de implicatie verzwijg je, xs4all kan maar zeer moeilijk voorkomen dat mensen van buiten haar authoritative nameservers gebruiken. De IP + 1 truuk houdt wellicht het gros van die mensen buiten de deur, maar iedereen die weet hoe hij het ip van een authoritative nameserver moet vinden kan gewoon zijn gang gaan. (Dat geldt overigens voor iedere ISP.)

Dat is geen implicatie!!! Dat is precies de bedoeling.
Zonder requests van buitenaf op de authoritive server toe te staan werken alle domeinen die xs4all host niet meer.....

Verschil met vroeger is alleen dat de authoritive servers geen recursive requests meer afhandelen. Je kan ze dus best instellen van buitenaf, maar als je iets vraagt waar hij niet authoritive voor is, dan krijg je gewoon geen antwoord. De recursive servers kan je van buitenaf helemaal niet benaderen.
Het heeft dus 0,0 zin om als niet xs4all gebruiker de nieuwe of de oude servers te gebruiken.

Pagina: 1

Reageer