15/03/13 13:25
Goeie middag.
Ik zit met een probleem te stoeien waar ik zelf zo niet uit kom.
Voor een multisite installatie gebruiken we een A record met * om alles door te sturen naar een vast IP adres.
Apache regelt het vanaf daar zelf.
Echter nu hebben we nog een A record die backoffice heet die doorgestuurd is naar een ander IP adres.
Maar een dag later wijst backoffice nog steeds naar het * adres.
Iemand tips waar ik verder zou kunnen kijken?
We maken gebruik van DirectAdmin.
Alvast bedankt.
15/03/13 14:05
Kan je je bind zone file eens plakken of op een pastebin zetten?
15/03/13 14:21
Is het mogelijk om de domeinnaam te geven en aan te geven waar je het hebt ingesteld? Dan kunnen we even kijken of alles goed ingesteld lijkt of er iets over het hoofd is gezien.
Tools die handig zjn voor ISPs vind je natuurlijk bij Tools 4 ISP.
16/03/13 11:22
16/03/13 19:58
Bedankt voor jullie reacties.
Dit is een lijst van de records, copy pasta uit DA:
- * A 195.216.246.10
- backoffice A 195.216.246.126
- ftp A 195.216.246.10
- localhost A 127.0.0.1
- mail A 195.216.246.25
- ns1.verenigingensoftware.nl. A 195.216.246.25
- smtp A 195.216.246.25
- spam A 10.0.0.255
- verenigingensoftware.nl. A 195.216.246.10
- www A 195.216.246.10
- verenigingensoftware.nl. NS ns1.verenigingensoftware.nl.
- verenigingensoftware.nl. NS ns2.verenigingensoftware.com.
- mail MX 10
- spam MX 20
- _domainkey TXT "o=~"
- verenigingensoftware.nl. TXT "v=spf1 a mx ip4:195.216.246.25 ~all"
- x._domainkey TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzPUK fLK0ZyiuOitpPDjw8JCQ3MOs+ybnbjZSmULxzyrE3Fybda9B0H 8ENX9YrUMIVn3IIPKcUvv8MLIwBXVPsz1
- vQ5IRJUO30rmVMHoXAGbsIqWcAtmHNADCMq2zP5VktfslmbgMI DlmoBlFKuAwZ3Mo727wV2Ykj39NtKK5+k1L51DEbdu/Qh3ovwkZUtt7CvLeNmDOB0ON3num81wMWmjh9v4zCVwsmpCL5W F/XCdPX
- mD4PC7nmim+SnJnSHy6BpZugBC9wGlWrSCFwziStAHbephkpXQ 81VaER1bL7lFne4zh8vCXDF1zb8IEmabnWlUHth5umzU8UUKxI y+9IQIDAQAB"
- localhost AAAA ::1
16/03/13 20:09
En wat staat er letterlijk in je zone bestand op die server (iets als /etc/bind/verenigingensoftware.nl.db of in /var/named/ dacht ik)?
Tools die handig zjn voor ISPs vind je natuurlijk bij Tools 4 ISP.
16/03/13 21:17
Op dit moment (zat 21:10 .. 21:16 ) is je tweede ns onbereikbaarOorspronkelijk geplaatst door MortyDot
(PING 195.216.246.42 (195.216.246.42): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
)
Dat heeft nog niet met je probleem te maken, maar hoort niet.
Verder heeft je backup MX een private IP, en dat is ook niet zinvol in een publieke zone.
In deze data zie ik nog niks mis waarom backoffice niet een eigen A record zou geven. Mark17 heeft een goede tip om te kijken in de uiteindelijke zone. Waarschijnlijk staat daar iets anders dan dat je hier gepost hebt.
16/03/13 21:54
Bedankt voor julie reacties.
@mark, ah is goed, onder in deze reactie.
@Visser, klopt van het MX record. Een ideale manier 75% van je spam tegen te gaan, een ongebruikte MX record als laatste plaatsen naar een niet gebruikt IP. Spammers pakken 3van4 maal het MX record met het hoogste MX getal :-). Wat je noemt over de tweede nameserver hoort inderdaad niet, is aangepast.
Code:$TTL 14400 @ IN SOA ns1.verenigingensoftware.nl. hostmaster.verenigingensoftware.nl. ( 2013031400 14400 3600 1209600 86400 ) verenigingensoftware.nl. 14400 IN NS ns1.verenigingensoftware.nl. verenigingensoftware.nl. 14400 IN NS ns2.verenigingensoftware.com. * 14400 IN A 195.216.246.10 backoffice 14400 IN A 195.216.246.126 ftp 14400 IN A 195.216.246.10 localhost 14400 IN A 127.0.0.1 mail 14400 IN A 195.216.246.25 ns1.verenigingensoftware.nl. 14400 IN A 195.216.246.25 smtp 14400 IN A 195.216.246.25 spam 14400 IN A 10.0.0.255 verenigingensoftware.nl. 14400 IN A 195.216.246.10 www 14400 IN A 195.216.246.10 verenigingensoftware.nl. 14400 IN MX 10 mail verenigingensoftware.nl. 14400 IN MX 20 spam _domainkey 14400 IN TXT "o=~" verenigingensoftware.nl. 14400 IN TXT "v=spf1 a mx ip4:195.216.246.25 ~all" x._domainkey 14400 IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzPUKfLK0ZyiuOitpPDjw8JCQ3MOs+ybnbjZSmULxzyrE3Fybda9B0H8ENX9YrUMIVn3IIPKcUvv8MLIwBXVPsz1" "vQ5IRJUO30rmVMHoXAGbsIqWcAtmHNADCMq2zP5VktfslmbgMIDlmoBlFKuAwZ3Mo727wV2Ykj39NtKK5+k1L51DEbdu/Qh3ovwkZUtt7CvLeNmDOB0ON3num81wMWmjh9v4zCVwsmpCL5WF/XCdPX" "mD4PC7nmim+SnJnSHy6BpZugBC9wGlWrSCFwziStAHbephkpXQ81VaER1bL7lFne4zh8vCXDF1zb8IEmabnWlUHth5umzU8UUKxIy+9IQIDAQAB" ) localhost 14400 IN AAAA ::1
16/03/13 22:11
Hmm, ik zie hier eigenlijk niks mis aan, maar ook als ik de NS'en direct query krijg ik voor backoffice het wildcard antwoord.
Probeer eens de serial op te hogen (2013031600 ) , en op de primary ook het bind proces te herstarten (rndc reload is meestal voldoende vanaf de commandline ) ?
16/03/13 22:22
18/03/13 10:08
Iedereen bedankt voor de reacties in het weekend :-)
@Visser, done. Idd, dat dacht ik ook. Rare is dat mail. en smtp. wel normaal resolven....
@Arieh, done, geen meldingen
18/03/13 10:39
De SOA's zijn ook niet gelijk:
213.189.2.42 - 2013031400
195.216.246.25 - 2013031600
18/03/13 12:56
Dat is toch wel gek.
Ik zou eerst heel goed in de named config kijken in welke file de zonedata echt verwacht worden, en dan die file bekijken.
(Je hebt al gekeken, maar ik weet niet of dat misschien via DA ging).
Ik zou de zonefile dan even met een heel basale editor bekijken. Ik vraag me nu af of er misschien onzichtbare karakters voor of achter de naam staan (tab/space), of ongebruikelijke UTF-8 karakters. Vergezocht misschien, maar inmiddels moeten we wat verder dan normaal ook zoeken.
Verder zou ik een testrecord direct in de zonefile zetten (backofficetest bijvoorbeeld) en kijken of die wel een niet-wildcard antwoord wil geven,
Dan zou ik bind toch maar echt herstarten (/etc/init.d/named , waarschijnlijk) in plaats van rndc reload .
En natuurlijk in de bind logfiles kijken, en eventueel het log niveau even hoger zetten.
Testen kun je (van buitenaf) doen met :
dig A backoffice.verenigingensoftware.nl. @195.216.246.25
dig A backofficetest.verenigingensoftware.nl. @195.216.246.25
(en ook op de andere ns)
En zoals dennis0162 al zei, de serial op de SOA is niet gelijk. Dat betekent dat je 2e DNS niet synchroniseert met de master.
20/03/13 18:43
Het verhaal gaat verder....
Als ik backofficetest als extra A record toevoeg, dan doet deze het wel, maar de backoffice test nog steeds niet...
Dus beide verwijderd, en backoffice weer toegevoegd, weer geen restultaat...
lol, waarom doen andere records het wel maar puur de term backoffice niet?
Mis ik iets hier?
20/03/13 18:52
Kijk eens of die naam bv in /etc/hosts met het verkeerde IP staat op de DNS server ?
Ik snap niet meteen waarom bind daar last van zou hebben, maar kijk toch maar ...
Verder, toevoegen en testen zou ik nu dus in bind config files doen, om echt zeker te weten wat daar in zit.
Likes: 
Quote