[bind] Geforward domein timed out maar werkt handmatig wel

[eborn]

Ik heb thuis de volgende constructie:

- Mijn eigen Bind DNS server draait een paar lokale domeinen
- Mijn werk draait op hun eigen interne netwerk een nameserver voor hun domein
- Alle andere requests gaan direct naar de DNS van mijn provider.

Punt 1 en 3 werken zonder problemen. Het gaat echter mis bij punt twee. Ik heb hiervoor een aparte sectie in de config aangemaakt:

code:

zone "domein-van-mijn-werk.nl" {
        type forward;
        forward only;
        forwarders { 10.2.0.2; };
};

De server op 10.2.0.2 kan ik via de VPN bereiken. De VPN staat ook altijd aan.

Als ik een handmatige query doe, bijvoorbeeld:

$ host www.domein-van-mijn-werk.nl @10.2.0.2

dan krijg ik netjes een response. Als ik via tcpdump kijk naar het verkeer dan komen er twee pakketjes langs: één van mijn server naar 10.2.0.2 met het verzoek en één van 10.2.0.2 met de reactie. Dat werkt dus naar behoren.

Toets ik nu echter (na het flushen van de DNS cache) in:

$ host www.domein-van-mijn-werk.nl

dan zie ik weer een pakketje naar 10.2.0.2 gaan met een verzoek. Alleen krijg ik deze keer geen reactie. Totaal worden er drie UDP pakketjes verstuurd, waarna host een timeout geeft. Echter: meestal vlak na het eindigen van host zie ik een 4e pakketje langskomen waarop wel direct een reactie van de server volgt. Een volgende query werkt dus opeens wel, omdat de gegevens goed in de cache terecht komen.

De vraag is nu: waarom!? Wat zou de reden kunnen zijn dat de UDP's eerst niet aankomen en vervolgens wel? Zover ik weet is er de afgelopen periode niets veranderd, maar goed, dat denk je altijd als je zo'n probleem tegenkomt. Heeft iemand een idee of ervaring met dit probleem?

[Broer]

Grappig, ik heb het nagespeeld, met een domain op 't werk bij ons, dat ook via het internet normaal niet bereikbaar is.

Met nslookup zie ik niets vreemds, gewoon een request en een reply terugkomen.

Als ik host gebruik, dan krijg ik als ik direct de nameserver raadpleeg maar een bericht terug, maar als ik het via mijn eigen nameserver doe, dan worden er ook requests naar de andere nameservers gestuurd die voor dat domain gedefinieerd staan voor die zone.
dus

$ host ns1.<domain.com> ns1.werk.nl

geeft ook een bericht
en

$ host ns1.<domain.com>

geeft een paar berichten via tcpdump.
Maar het zijn wel berichten van mijn nameserver naar de andere nameservers. Het is niet zo dat ik daar iets van terug krijg.

Ik zie dus niet hetzelfde gedrag als bij jouw, ik krijg wel direct een antwoord, maar in de tcpdump output zie ik dus wel meerdere berichten.

Misschien gaan de query's met de timeouts dus naar andere nameservers.

[eborn]

TCPdump geeft de volgende gegevens:

code:

--> Hier doe ik $ host www.domein.nl
192.168.0.1.39382 > 10.2.0.2.domain:  54787+ [1au] A? www.domein.nl. OPT  UDPsize=2048 (46) (DF)
192.168.0.1.39382 > 10.2.0.2.domain:  61499+ [1au] A? www.domein.nl. OPT  UDPsize=2048 (46) (DF)
192.168.0.1.39382 > 10.2.0.2.domain:  57023+ [1au] A? www.domein.nl. OPT  UDPsize=2048 (46) (DF)
--> Hier blijft host een paar seconden stil staan en geeft vervolgens een timeout
192.168.0.1.39382 > 10.2.0.2.domain:  32341+ A? www.domein.nl. (35) (DF)
10.2.0.2.domain > 192.168.0.1.39382:  32341* 1/0/0 A 10.2.0.1 (51)

De resultaten komen dus binnen nadat host is gestopt. De volgende aanroep van host doet dus niets en geeft direct de juiste gegevens.

Er gaat verder geen enkel DNS verkeer over de lijn. Dit verkeer gaat over tun0, mijn tunnel met het werk. Op eth1 (mijn adsl verbinding) is geen DNS verkeer te zien. Hij stuurt het dus wel naar de juiste server, maar het komt niet goed aan lijkt het.

Doe ik vervolgens de $ host www.domein.nl 10.2.0.2 (dus direct naar die DNS server)

code:

192.168.0.1.39394 > 10.2.0.2.domain:  59661+ A? www.domein.nl. (35) (DF)
10.2.0.2.domain > 192.168.0.1.39394:  59661* 1/0/0 A 10.2.0.1 (51)

Meer kan ik er echt niet van maken. Ik snap er zelf geen fluit van. Op zich is het niet zo'n ramp. Ik krijg gewoon de eerste keer een wat langere timeout. Maar ik wil graag begrijpen waarom het mis loopt

[ Voor 8% gewijzigd door eborn op 11-08-2003 22:56 ]

[Broer]

Zet het debug level van je DNS server eens op zijn hoogst, dan zul je waarschijnlijk zien dat BIND deze extra berichten verzorgt, en niet het commando host.

Wil niet zeggen dat ik nu snap wat er aan de hand is hoor

[igmar]

eborn schreef op 11 August 2003 @ 15:23:

code:

zone "domein-van-mijn-werk.nl" {
        type forward;
        forward only;
        forwarders { 10.2.0.2; };
};

De server op 10.2.0.2 kan ik via de VPN bereiken. De VPN staat ook altijd aan.

De vraag is nu: waarom!? Wat zou de reden kunnen zijn dat de UDP's eerst niet aankomen en vervolgens wel? Zover ik weet is er de afgelopen periode niets veranderd, maar goed, dat denk je altijd als je zo'n probleem tegenkomt. Heeft iemand een idee of ervaring met dit probleem?

De meest waarschijnlijke reden is dat named een query doet vanaf het IP wat niet over de VPN tunnel gaat. Ik heb dat probleem opgelost met een query-source address x.x.x.x port 53, waarbij x.x.x.x het internet IP van de machine is.

Op die manier gaan de pakketten of geNAT naar buiten, of over de VPN tunnel, afhankelijk van het destination adres van het pakketje.

[eborn]

igmar schreef op 12 August 2003 @ 09:19:
De meest waarschijnlijke reden is dat named een query doet vanaf het IP wat niet over de VPN tunnel gaat. Ik heb dat probleem opgelost met een query-source address x.x.x.x port 53, waarbij x.x.x.x het internet IP van de machine is.

Op die manier gaan de pakketten of geNAT naar buiten, of over de VPN tunnel, afhankelijk van het destination adres van het pakketje.

De pakketjes komen vanaf 192.168.0.1 (mijn server-adres). Ze worden verstuurd naar 10.2.0.2 (de dns van mijn werk). Tussen 10.2.0.x en 192.168.0.1 zit een directe route. Ik kan dus geheel bij hun subnet en zij kunnen in het geheel bij mijn netwerk.

[eborn]

Broer schreef op 12 August 2003 @ 05:59:
Zet het debug level van je DNS server eens op zijn hoogst, dan zul je waarschijnlijk zien dat BIND deze extra berichten verzorgt, en niet het commando host.

Dat klopt, want host is op dat moment al terminated

Wil niet zeggen dat ik nu snap wat er aan de hand is hoor

Helaas