Onderwerp: Domein niet meteen resolvbaar, klopt dit?

Ik vraag me af of dit in cpanel anders is dan met Directadmin.
Als ik in DA een nieuw account aan maak met een domeinnaam en daarna via SSH inlog en een nslookup op die domeinnaam doe, resulteert het antwoord meteen gewoon op het ip van de lokale server.

Nu blijkt dit op een cpanel server niet zo te zijn. Is dat normaal?
Account is aangemaakt, ook al eens weggehaald en opnieuw aangemaakt, nameserver opnieuw gestart.
De nsswitch.conf staat op "files dns"
De resolv.conf zit er als volgt uit:
search hosterbedrijf.nl
nameserver 127.0.0.1
nameserver xx.xx.xx.xx
nameserver xx.xx.xx.xx

De laatste beide naamservers zijn de naamservers van het colobedrijf. Ook dit is exact hetzelde als bij de DA servers.

Maar de nslookup doet dus dit:
nslookup klantdomein.nl
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
Name: klantdomein.nl
Address: 212.xx.xx.xx

Het gaat hier om een verhuizing van een domein, en het antwoord geeft dus al dagenlang het ip adres aan van de oude hoster, in plaats van het lokale ip adres.

Is dit normaal bij Cpanel servers of wat kan hier fout zijn?

Wat staat er in /etc/nsswitch.conf ?

Oorspronkelijk geplaatst door Blacky

De nsswitch.conf staat op "files dns"

Of bedoel je nog een andere instelling?

Volgens mij staat de zone niet goed in je nameserver, hij geeft namelijk een non-authoritive answer.

Non-authoritative answer:
Name: klantdomein.nl
Address: 212.xx.xx.xx

Dat non-authorative is toch normaal als je het antwoord van je eigen non-authoritive (caching) nameserver krijgt?

De verhuizing van het domein is overigens wel gelukt, alleen vind ik het vreemd dat hij hem lokaal niet meteen resolved, voordat hij ook bij externe authoritive nameservers bekend is.

Maar even just to be sure, dit is wat Cpanel aangemaakt heeft, ik zag er zo vlug niets fouts in:

; cPanel first:11.25.0-CURRENT_40255 latest:11.25.0-NIGHTLY_40200 Cpanel::ZoneFile::VERSION:1.3 mtime:1257452063 hostname:server.hoster.nl
; Zone file for klantdomein.nl
$TTL 14400
h2oreclame.nl. 86400 IN SOA ns1.hoster.nl. postmaster.hoster.nl. (
2009110505 ;Serial Number
14400 ;refresh
3600 ;retry
1209600 ;expire
86400 ;minimum
)
klantdomein.nl. 86400 IN NS ns1.hoster.nl.
klantdomein.nl. 86400 IN NS ns2.hoster.nl.
klantdomein.nl. 14400 IN A 85.xx.xx.xx
localhost 14400 IN A 127.0.0.1
klantdomein.nl. 14400 IN MX 0 klantdomein.nl.
mail 14400 IN CNAME klantdomein.nl.
www 14400 IN CNAME klantdomein.nl.
ftp 14400 IN CNAME klantdomein.nl.
cpanel 14400 IN A 85.xx.xx.xx
whm 14400 IN A 85.xx.xx.xx
webmail 14400 IN A 85.xx.xx.xx
webdisk 14400 IN A 85.xx.xx.xx
klantdomein.nl. 14400 IN TXT "v=spf1 a mx ?all"

Zo staan eigenlijk alle zone files en die werken allemaal prima. Het is alleen dat als je zo'n account net aanmaakt, dat ie lokaal niet te resolven is. Misschien heeft dat iets te maken met de nieuwe Bind 9 named.conf want daar kom ik niet echt wijs uit tot nog toe met al die internal en external view dingens.

view "localhost_resolver" {
/* This view sets up named to be a localhost resolver ( caching only nameserver ).
* If all you want is a caching-only nameserver, then you need only define this view:
*/
match-clients { 127.0.0.0/24; };
match-destinations { localhost; };
recursion yes;

zone "." IN {
type hint;
file "/var/named/named.ca";
};

/* these are zones that contain definitions for all the localhost
* names and addresses, as recommended in RFC1912 - these names should
* ONLY be served to localhost clients:
*/
include "/var/named/named.rfc1912.zones";
};

view "internal" {
/* This view will contain zones you want to serve only to "internal" clients
that connect via your directly attached LAN interfaces - "localnets" .
*/
match-clients { localnets; };
match-destinations { localnets; };
recursion yes;

zone "." IN {
type hint;
file "/var/named/named.ca";
};

// include "/var/named/named.rfc1912.zones";
// you should not serve your rfc1912 names to non-localhost clients.

// These are your "authoritative" internal zones, and would probably
// also be included in the "localhost_resolver" view above :

zone "klantdomein.nl" {
type master;
file "/var/named/klantdomein.nl.db";
};

Dat bestand is nog groter maar dit is volgens mij het view deel voor interne lookups.
Ohja, het draait op Centos 5.3.

Je view "localhost_resolver" bevat die zone niet, enkel een hint file. Je nameserver zal dus voor requests die vanaf die machine zelf komen de request toch opzoeken via externe servers.

Als ik hier een dig naar die naam doe (die trouwens nog in de SOA record staat die je gepost hebt), dan krijg ik iig wel een 85.x.x.x antwoord terug. Verder kan ik trouwens wel geen verbinding maken met de ns2.

Je view "localhost_resolver" bevat die zone niet, enkel een hint file.

De localhost view heeft toch die verwijzing naar de zone file er in staan?

zone "klantdomein.nl" {
type master;
file "/var/named/klantdomein.nl.db";
};

Of bedoel je de zone file naar de lokale naamserver? Dus echt naar 127.0.0.1?
Is het te fixen dat het lokaal in het vervolg bij nieuwe domeinen dan wel meteen resolved? Ik neem aan van wel, maar wat zou ik dan moeten doen?

Dat van de SOA klopt, domein staat er nog in, maar kan ik niet meer wijzigen. Is niet zo erg. Dat het domein over is en van buiten te benaderen klopt, maar het gaat mij om het feit dat ik hem voordien niet via ssh kon resolven, daar ben ik niet zo blij mee ook al is het mijn server niet. Ik moet er vaak aan werken en dan zie ik toch graag of alles goed gaat enzo.

Bedankt voor de tip omtrent de ns2. Gaat goed komen, foutje van mij.

Nee, die zone staat in het "internal" view, die de locale subnets matched. In je "localhost_resolver" staat die zone niet in.

Persoonlijk vind ik het trouwens ook niet aangewezen om de server zichzelf als DNS server te laten gebruiken, zeker niet als je de klant domeinen zou toevoegen aan je localhost_resolver, omdat dit misbruikt kan worden.

Aha, ik zie het nu, ik miste een haakje en dacht daarom dat ie nog binnen de localhost_resolver viel.

Als het veiliger is, zoals het nu is, hoef ik het niet aan te passen. Ik vraag me alleen af of dit normaal is bij Cpanel installaties, aangezien het bij DirectAdmin installaties duidelijk anders werkt en domeinen wel meteen resolvbaar zijn na het aanmaken.