Onderwerp: Eigen naamserver maakt me compleet gek

Beste WHT'ers.

Sorry ik heb al een tigtal onderwerpen hier op WHT hierover gelezen maar ik krijg het maar niet spits.
Ik zal zoveel mogelijk informatie geven.
We hebben een domein met whitelisting bij Transip, ik noem het even mijndomein.nl

Bij een andere colo hebben we een server met Centos 5 en DA hangen, noem ik effe colohoster.com.
Wij willen onze eigen naamservers draaien onder de naam ns1.mijndomein.nl en ns2.mijndomein.nl.

Het ip voor ns1.mijndomein.nl daar hebben we het ip van de server zelf voor genomen.
Het tweede ip hebben we van de colohoster gekregen.

Dat tweede ip is te pingen, is via een tracert te bereiken, maar een SIDN check geeft een query time-out en vindt dat ie niet te bereiken is.

Dit is onze named.conf:

Code:

// generated by named-bootconf.pl

options {
        directory "/var/named";
        /*
         * If there is a firewall between you and nameservers you want
         * to talk to, you might need to uncomment the query-source
         * directive below.  Previous versions of BIND always asked
         * questions using port 53, but BIND 8.1 uses an unprivileged
         * port by default.
         */
        query-source address * port 53;
};

//
// a caching only nameserver config
//
controls {
        inet 127.0.0.1 allow { localhost; } keys { rndckey; };

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

zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "named.local";
        allow-update { none; };
};

include "/etc/rndc.key";

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

En dit is die named.local

Code:

TTL    86400
@       IN      SOA     localhost. root.localhost.  (
                                      2008041504 ; Serial
                                      28800      ; Refresh
                                      14400      ; Retry
                                      3600000    ; Expire
                                      86400 )    ; Minimum
              IN      NS      localhost.

1       IN      PTR     localhost.

Verder heb ik hier nog de zonefile van het domein zoals deze door DA gemaakt is en later nog aangepast door onze colohoster om voor een betere werking te zorgen:
Dus de mijndomein.nl.db

Code:

$TTL 14400
@       IN      SOA     ns1.mijndomein.nl.      root.mijndomein.nl.nl. (
                                                2008041504
                                                14400
                                                3600
                                                1209600
                                                86400 )

mijndomein.nl.  14400   IN      NS      ns1.mijndomein.nl.
mijndomein.nl.  14400   IN      NS      ns2.mijndomein.nl.

ftp     14400   IN      A       194.126.174.35
mijndomein.nl.  14400   IN      A       194.126.174.35
localhost       14400   IN      A       127.0.0.1
mail    14400   IN      A       194.126.174.35
ns1     14400   IN      A       194.126.174.35
ns1.mijndomein.nl.      14400   IN      A       194.126.174.35
ns2     14400   IN      A       194.126.174.179
ns2.mijndomein.nl.      14400   IN      A       194.126.174.179
pop     14400   IN      A       194.126.174.35
www     14400   IN      A       194.126.174.35

mijndomein.nl.  14400   IN      MX      10 mail

194.126.174.35  14400   IN      PTR     mijndomein.nl.

mijndomein.nl.  14400   IN      TXT     "v=spf1 a mx ip4:194.126.174.35 ?all"

Waar gaat het hier fout?
Uit de ip adressen zal men wel kunnen herleiden wat het echte domein is maar dat maakt niet uit.

Misschien te simpel, maar wordt op NS2 toevallig poortje 53 niet geblokkeerd?

Misschien inderdaad wel zo simpel, dat ip kregen we van onze colohoster en het blijkt inderdaad geblokkeerd te zijn op poort 53.
We hebben contact met hem opgenomen en gaan het daarna opnieuw proberen, thanks!

uhm zoals ik het hier lees, draait je nameserver op één server (met twee ip's). Of poort 53 dus dicht staat op een van je ip's (lijkt me onwaarschijnlijk) kan je dus zelf checken.

Ja het klopt, het is 1 server met twee ip's en ik krijg voor dat tweede ip wat op eth0:0 staat die poort 53 niet open.
Toch staat de firewall geheel open op dit moment.
Dat is mijn iptables output:
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Dan hier nog eens de output van mijn iptables file in de /etc/sysconfig directory.
-A RH-Firewall-1-INPUT -p udp -m udp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 53 -j ACCEPT

Lijkt me dus echt wel op accept te staan, het eerste ip is ook gewoon via poort 53 telnet bereikbaar.
Alleen met dat tweede lukt me dat niet.
Enig idee?

Probeer eens of het functioneerd als je het volgende typed: /etc/init.d/iptables stop
Verder mocht je een firewall willen gebruiken kun je ook eens kijken naar APF (evt. in samenwerking met BFD)

Oorspronkelijk geplaatst door Blacky

Lijkt me dus echt wel op accept te staan, het eerste ip is ook gewoon via poort 53 telnet bereikbaar.
Alleen met dat tweede lukt me dat niet.
Enig idee?

Als het niet lukt met het 2e kan het inderdaad zijn dat het geblokkeerd wordt, maar werkt alleen 53 niet of werkt niets op het 2e IP? (Test eens even om iets op 2e IP te zetten, mocht dit ook niet werken denk ik toch dat het IP niet klopt oid)

Het is echt een vaag probleem wat ik daar heb. Nu heb ik dus gewoon DA eens herstart, dan komt ook dat tweede ip weer tevoorschijn, staat ook in de iplst of hoe heet dat bestand.

Nu probeer ik er weer naar te telnetten vanaf die host, krijg ik het volgende te zien:
telnet 194.126.174.179 25
Trying 194.126.174.179...
telnet: relocation error: telnet: symbol krb5int_labeled_fopen, version krb5support_0_MIT not defined in file libkrb5support.so.0 with link time reference

Dat is dus telnetten naar poort 25. Hetzelfde gebeurt nu echter op dat ip met .35 op het einde. Grappig genoeg kan ik vanaf mijn eigen pc thuis wel telnetten naar dat ip met .35 op het einde. Alleen die met 179 op het eind blijft de problemen geven.

Er staat overigens geen ifcfg-eth0:0 bestand in /etc/sysconfig/network-scripts, maar voor zover ik begrepen had zou dat niet hoeven met directadmin.
Heb dat daarstraks wel even geprobeerd maar maakt geen verschil.

Het iptables stop commando werkte wel, maar gaf geen verschil, als ik het dan wil starten komt ie met een foutmelding.
'pplying iptables firewall rules: iptables-restore v1.3.5: iptables-restore: unable to initializetable 'filter

Error occurred at line: 3
Try `iptables-restore -h' or 'iptables-restore --help' for more information.
[FAILED]
Dus hij start niet eens, maarja, lijkt me ook dat als iptables het probleem zou zijn, dat je dan van buitenaf ook niet op dat .35 ip zou kunnen connecten.
Blijft raar dat het wel te pingen is.

Ik heb even een tracert gedaan naar beide IPs. Hieronder het resultaat.

1 <1 ms <1 ms <1 ms 192.168.2.1
2 * 15 ms 14 ms 82-169-63-254.ip.telfort.nl [82.169.63.254]
3 15 ms 15 ms 14 ms 172.26.43.33
4 16 ms 15 ms 15 ms 172.26.44.2
5 15 ms 14 ms 14 ms 195-241-4-177.ip.tiscali.nl [195.241.4.177]
6 * * 28 ms vpn494-telfort.bcsw1.asd-nh.net.tiscali.nl [195.241.4.178]
7 15 ms 14 ms 14 ms 195-241-3-42.ip.tiscali.nl [195.241.3.42]
8 15 ms 15 ms 15 ms 89.30.132.6
9 15 ms 16 ms 16 ms Hosted-at-web.profithost.net [194.126.174.179]

1 1 ms <1 ms <1 ms 192.168.2.1
2 14 ms 14 ms 16 ms 82-169-63-254.ip.telfort.nl [82.169.63.254]
3 15 ms 14 ms 15 ms 172.26.43.33
4 15 ms 14 ms 15 ms 172.26.44.2
5 15 ms 14 ms 14 ms 195-241-4-177.ip.tiscali.nl [195.241.4.177]
6 15 ms 14 ms 15 ms vpn494-telfort.bcsw1.asd-nh.net.tiscali.nl [195.241.4.178]
7 15 ms 15 ms 14 ms 195-241-3-42.ip.tiscali.nl [195.241.3.42]
8 15 ms 15 ms 17 ms 89.30.132.6
9 17 ms 15 ms 15 ms colocation-customers.rbs2e.r3.easyracks.nl [194.126.174.35]

Het lijkt erop dat het IP nog door iemand anders in gebruik is, dit aangezien het een andere RDNS heeft.

Ja dat idee had ik ook, dan ga ik nog eens met de colohoster babbelen.
Thanks!

Oorspronkelijk geplaatst door daveww

I\Het lijkt erop dat het IP nog door iemand anders in gebruik is, dit aangezien het een andere RDNS heeft.

Wat een rare conclussie....

Nja ik weet het niet, maar we hebben nu een ander ip gekregen wat compleet vrij zou zijn en nu komt ie wel door de SIDN check heen.
Zit nu alleen nog met een door sysconfig aangemaakte iptables firewall die niet wenst te werken en nog wat andere dingetjes, maar dat komt nog wel.
Doen nu effe een server reboot en dan zien wat ie dan doet.