PDA

Bekijk Volledige Versie : Reverse DNS, SMTP Banner en MX records


JasperB
11/02/12, 15:49
Ik ben bezig met het inrichten van een nieuwe Directadmin omgeving op een VPS met één ip nummer en meerdere domeinen.

In tegenstelling tot mijn andere directadmin installatie wil ik nu alle DNS zaken kunnen beheren vanuit directadmin en niet via Transip. Ik heb daarom directadmin zo ingericht dat ik ns1.mijndomein.nl gebruik en ns1.transip.nl + ns2.transip.eu als nameservers. Master + slave config dus.

Dit lijkt goed te werken, syncronisatie verloopt ook ok. Subdomeinen werken ook. SIDN geeft wel aan dat de data niet consistent is terwijl alles hetzelfde lijkt te zijn en de gegevens daadwerkelijk wel syncen. Lijkt er op dat er iets verkeerd gaat bij SIDN en niet bij mij. SOA + TTL + TTL Minimum is gelijk, nummers zijn gelijk etc.

Dit is dus niet echt het probleem, waar ik mee zit is de mailbezorging en de hogere spam score in verband met een verkeerde reverse dns voor mijn mailserver / mx record.

Ik heb maar één ip nummer en kan dus geen reverse dns instellen voor mail en nameserver. Het is of mail, NS of hostname van de server.

Bovenstaand verhaal zorgt er dus voor dat ik nu in de spam folders terecht kom omdat mijn mx record via reverse dns resolven naar ns1.mijndomein.nl i.p.v. webserver.mijndomein.nl of mijn mail record mail.mijndomein.nl. Als ik mail verstuur van mijndomein2.nl ipv mijndomein1.nl zie je ook dat de mailserver van mijndomein1.nl gebruikt wordt. Dit zal denk ik ook zorgen voor een hogere spam score?

MXToolbox.com geeft aan dat mijn smtp banner reverse dns onjuist is (ns1.mijndomein.nl) en niet de hostname (webserver.mijndomein.nl)

Hoe ga ik hier mee om? Moet ik perse 2 euro per maand bij leggen voor een extra ip nummer? Zodat ik twee reverse entries kan aanmaken met twee A records?
Wat is best practice voor reverse dns en een mailserver? Hij lijkt te beantwoorden met zijn hostname en niet met het mx record. Ik zou dus reverse dns moeten aanpassen naar de server name.

Ik gebruik nu een smtp server van xs4all of upc om mail te versturen via deze directadmin configuratie, maar dit is natuurlijk niet gebruiksvriendelijk te noemen aangezien gebruikers dit niet altijd snappen. Iemand een advies/oplossing hoe ik dit kan inrichten? Of zit ik vast aan een extra ip nummer?

Er is in directadmin een mogelijkheid om reverse dns in te stellen + ptr records aan te maken. Of eventueel CNAMES te misbruiken. Maar ik denk niet dat ik hier wat aan heb?
Rubra
11/02/12, 16:28
De reverse dns instellingen kan je doen bij de eigenaar van de ip adressen. Trans ip dus.

Je zal moeten beslissen welke hostname je daar opgeeft. Waarschijnlijk is het het makkelijkste om de naam van je smtp server te gebruiken en dan gewoon op dat zelfde ip een cname voor je nameserver erop te zetten.
Arieh
11/02/12, 19:30
Het is inderdaad verstandig om de reverse dns van het ip waarvan je mailed te matchen met de hostname/fqdn. Als je naar het IP telnet op poort 25 zie je dat je mailserver de hostname stuurt. Als die hostname dus overeenkomt met de rdns scoor je inderdaad vaak lager/beter wat betreft spam. Wat die hostname precies is maakt niet uit, dat mag gerust mail.domain zijn of server.domain.

De nameserver hoeft zover ik weet niet dezelfde rdns te hebben als de nameserver zelf, 't gaat er immers om dat een nameserver als authoriteit staat geregistreerd op ip/domein, daar is geen score of check of wat dan ook van toepassing. Bij een dns check van sidn wordt volgens mij alleen gelet op of de rdns (PTR) van het ip dat de nameserver gebruikt, in ieder geval overeenkomt met de (A) dns, in dit geval gewoon de hostname. Niet alle rdns van mn nameservers komen overeen met de nameserver zelf en heb er nooit een warning over gezien.

Verder lijkt het me sterk dat er iets mis gaat bij SIDN, maar als er ergens nog iets niet goed staat zou je ook even een domein kunnen geven zodat we mee kunnen kijken.

De PTR records (=rdns) zijn inderdaad aan te maken in DA, echter nemen de meeste datacenters dat beheer voor eigen rekening en moet je het inderdaad zoals Rubra zegt bij je provider instellen.
dreamhost_nl
11/02/12, 19:40
lndien je server als FQDN servernaam.domeinnaam.xxx heeft, dient de rDNS van het (enige) IP-adres van je server ook servernaam.domeinnaam.xxx te hebben. Simpeler kan niet.
JasperB
11/02/12, 23:16
Dank voor jullie feedback. Heb nu inderdaad de fqdn van mijn server naam als mijn reverse gezet en krijg nu minder errors.

Wel geeft sidn op de Dns check (google sign dns check) op jasperbosch.nl en bedofflowers.nl nog een SOA configuratie fout aan, maar ik kan geen fouten ontdekken. Jullie?

Mijn mail komt helaas ook nog niet aan, maar ik geef het nog even tot morgen.. Kan wel verzenden en dan op een upc.nl adres ontvangen. Als ik reply komt hij echter niet meer aan (op bovenstaande domeinen)

Zie dit in mijn mail logs:

incomplete transaction (RSET)
JasperB
11/02/12, 23:39
Nog even verder mijn log nagekeken en ik zie afgezien van een paar incomplete transaction logs allemaal netjes dat hij mail doet verzenden maar niets binnenkrijgt. Zal nog wel dns zijn welke nog uit sync is..

Als iemand het nog wil nakijken voor bovenstaande domeinen.. graag! SIDN Dns geeft dus SOA error
The-BosS
11/02/12, 23:55
Als iemand het nog wil nakijken voor bovenstaande domeinen.. graag! SIDN Dns geeft dus SOA error


WARNING: Your SOA REFRESH interval is: 100. That is not so ok

Duidelijke omschrijving van het probleem lijkt me ;)
JasperB
11/02/12, 23:58
Dat is het niet, deze heb ik tijdelijk zo laag mogelijk gezet om de transfer te versoepelen. Bovendien zou dit geen reden mogen zijn waarom ik geen mail ontvang.. en wel kan versturen.

Dit zegt SIDN terwijl allebei de records gelijk zijn.


2 verschillende SOA records gevonden. H
et SOA record is niet op alle name servers gelijk. Dit duidt normaal gesproken op een configuratiefout.

Dit komt nog voorbij in mijn mail log van exim



2012-02-11 23:53:22 1RwLoo-0000e3-65 Completed
2012-02-11 23:54:03 H=dnscheck.pingdom.com [83.140.19.133] incomplete transaction (RSET) from <> for hostmaster@jasperbosch.nl
2012-02-11 23:57:32 H=sidn-www2.colo.bit.nl [213.136.31.93] incomplete transaction (RSET) from <> for hostmaster@jasperbosch.nl


Al gegoogled.. maar niets kunnen vinden over deze error. Slaap er wel een nachtje over en hopen dat alles morgen weer werkt..!
Arieh
12/02/12, 01:55
De records zijn misschien wel gesynct, maar publiekelijk nog niet. Je eigen nameserver zegt 86400, t.ip nog 100. Bij de NSes van t.ip zit altijd een flinke vertraging in de wijzigingen weet ik ook uit ervaring.

Wat de RSET error betreft, daar weet ik zo ook niet iets op. Als ik 'm zo even google kan ie met meerdere oorzaken samen gaan, is dit het enige wat ie zegt?
JasperB
12/02/12, 09:28
De records zijn misschien wel gesynct, maar publiekelijk nog niet. Je eigen nameserver zegt 86400, t.ip nog 100. Bij de NSes van t.ip zit altijd een flinke vertraging in de wijzigingen weet ik ook uit ervaring.

Wat de RSET error betreft, daar weet ik zo ook niet iets op. Als ik 'm zo even google kan ie met meerdere oorzaken samen gaan, is dit het enige wat ie zegt?

Hoe kom je aan die 86400? Is dat een TTL of SOA record? Moet ik handmatig wat gaan aanpassen om dit op te lossen?

ik ontvang nog steeds geen mail als ik deze verstuur vanaf xs4all.nl. Als ik me echter aanmeld op een willekeurige nieuwsbrief onlin dan krijg ik daar wel mail van. Het lijkt er op dat xs4all.nl hem niet wil afleveren? Mogelijk omdat mijn dns nog niet goed is?
dennis0162
12/02/12, 15:54
Het kan zijn dat het bij XS4all nog in de cache zit en het even duurt.
The-BosS
12/02/12, 16:09
Ik zie dat je dns probleem ondertussen opgelost is, op 1 warning na die eigenlijk niet erg is:

Too few IPv6 name servers (1).

Only one IPv6 name server was found for the zone. You should always have at least two IPv6 name servers for a zone to be able to handle transient connectivity problems.

Het was dus gewoon even afwachten (zoals gewoonlijk met dns) totdat iedereen zijn cache geupdate was.
JasperB
12/02/12, 16:13
Opgelost inderdaad! Super! Wel klote dat je met dit soort dingen wel afhankelijk bent van derde en providers die bijna 2! dagen nodig hebben om geen oude cache te raadplegen.

Topic mag dicht :)
dreamhost_nl
13/02/12, 15:22
Wellicht een idee om buiten deze derde partij om te gaan werken dan? ;)
dennis0162
13/02/12, 16:55
Wellicht een idee om buiten deze derde partij om te gaan werken dan? ;)

TS probeert volgens mij naar XS4all mailadressen te mailen en niet via XS4all.