subdomein gebruiken voor site & email

[Koesper]

Even een sanity check, want ik krijg het niet voorelkaar.

Is het mogelijk om een een subdomein te gebruiken voor zowel:
een website: http://sub.domein.nl
en gelijktijdig hiervoor ook mailadressen te gebruiken:
[e-mail]

ik loop namelijk tegen een probleem aan met de DNS instellingen.
hier een versimpelde versie, hoop dat het zo klopt

name	type	value	opmerking	werkt
@	MX	10 mx.domein.nl.	mail afhandeling voor [e-mail]	werkt
@	A	123.123.123.123	website voor domain.nl	werkt
sub	MX	10 mx.domein.nl.	mail afhandeling voor [e-mail]	werkt
sub	CNAME	10 mx.domein.nl.	website voor sub.domein.nl	mag niet

dat laaste record mag ik niet toevoegen, omdat er niet meerdere CNAME/MX/A records mogen zijn voor een bepaalde naam.

Zie ik hier nou iets over het hoofd?
http://sub.domein.nl en [e-mail] gelijktijdig gebruiken is toch mogelijk?

[Paul]

Ik mis sowieso een A-record voor "mx"

Is die "10" bij de CNAME een typfout? CNAMEs doen niet aan gewichten en dergelijke, dat moet "sub CNAME mx" of "sub CNAME mx.domein.nl." (let op de punt) zijn.

Ik lees online inderdaad ook dat een MX-record inderdaad niet mag voor iets dat al een CNAME heeft (of andersom). Beste optie is denk ik van "sub" een A-record te maken en (als je maar één A-record wil) de MX-records van "@" en "sub" daar naartoe te laten wijzen.

[ Voor 34% gewijzigd door Paul op 07-09-2018 14:50 ]

[Thralas]

Koesper schreef op vrijdag 7 september 2018 @ 14:39:
dat laaste record mag ik niet toevoegen, omdat er niet meerdere CNAME/MX/A records mogen zijn voor een bepaalde naam.

Zie ik hier nou iets over het hoofd?

Ja, je mag géén CNAME gebruiken als er ook een ander record is. In jouw geval is dat een MX record.

http://sub.domein.nl en [e-mail] gelijktijdig gebruiken is toch mogelijk?

Ja, maak een A(/AAAA) record aan ipv. CNAME.

[Paul]

Staat blijkbaar in RFC 1034 6.3.2:

If a CNAME RR is present at a node, no other data should be present

Wat ik persoonlijk overigens een VEEL te brede definitie vind. Geen A of AAAA, prima. Maar MX vind ik al twijfelachtig, en TXT al helemaal. We hebben verschillende record-types met een reden.

Nu lijkt het er op dat je het MX-records naar dezelfde naam wil wijzen als de CNAME, dus in dat geval zou ik de MX-records op "MX" zetten.

[g00gle]

Dit is alles wat je moet doen om mail te ontvangen op je subdomein kwa DNS instellingen:


prio 10 is goed trouwens voor je MX record.

[Koesper]

Thanks allen!
Inderdaad @Paul, zitten wat copypaste foutjes in mn laatste regel

Ah, dat plaatje van @g00gle is idd behulpzaam!

Allright, ik ga weer even verder puzzelen!

Jullie zijn alledrie onderdeel van 'het beste antwoord', dus ik kan er niet slechts 1 markeren.
thanks again!

[Thralas]

Paul schreef op vrijdag 7 september 2018 @ 14:59:
Staat blijkbaar in RFC 1034 6.3.2:
[...]

Wat ik persoonlijk overigens een VEEL te brede definitie vind. Geen A of AAAA, prima. Maar MX vind ik al twijfelachtig, en TXT al helemaal. We hebben verschillende record-types met een reden.

Volgens mij zie je dan juist de betekenis van een CNAME over het hoofd: een zuivere alias.

Die definitie gaat stuk als je andere records toestaat. De naam is gelijk, niet de-naam-is-gelijk-behalve-voor-een-TXT-record.

[TECHcrime]

Wanneer een CNAME gebruikt wordt, mag er geen andere record type gebruikt worden.

https://www.ietf.org/rfc/rfc1912.txt

2.4 CNAME records

A CNAME record is not allowed to coexist with any other data. In
other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
can't also have an MX record for suzy.podunk.edu, or an A record, or
even a TXT record. Especially do not try to combine CNAMEs and NS
records like this!:


podunk.xx. IN NS ns1
IN NS ns2
IN CNAME mary
mary IN A 1.2.3.4


This is often attempted by inexperienced administrators as an obvious
way to allow your domain name to also be a host. However, DNS
servers like BIND will see the CNAME and refuse to add any other
resources for that name. Since no other records are allowed to
coexist with a CNAME, the NS entries are ignored. Therefore all the
hosts in the podunk.xx domain are ignored as well!

If you want to have your domain also be a host, do the following:

podunk.xx. IN NS ns1
IN NS ns2
IN A 1.2.3.4
mary IN A 1.2.3.4

Don't go overboard with CNAMEs. Use them when renaming hosts, but
plan to get rid of them (and inform your users). However CNAMEs are
useful (and encouraged) for generalized names for servers -- `ftp'
for your ftp server, `www' for your Web server, `gopher' for your
Gopher server, `news' for your Usenet news server, etc.

Don't forget to delete the CNAMEs associated with a host if you
delete the host it is an alias for. Such "stale CNAMEs" are a waste
of resources.

Don't use CNAMEs in combination with RRs which point to other names
like MX, CNAME, PTR and NS. (PTR is an exception if you want to
implement classless in-addr delegation.) For example, this is
strongly discouraged:

podunk.xx. IN MX mailhost
mailhost IN CNAME mary
mary IN A 1.2.3.4


[RFC 1034] in section 3.6.2 says this should not be done, and [RFC
974] explicitly states that MX records shall not point to an alias
defined by a CNAME. This results in unnecessary indirection in
accessing the data, and DNS resolvers and servers need to work more
to get the answer. If you really want to do this, you can accomplish
the same thing by using a preprocessor such as m4 on your host files.

Also, having chained records such as CNAMEs pointing to CNAMEs may
make administration issues easier, but is known to tickle bugs in
some resolvers that fail to check loops correctly. As a result some
hosts may not be able to resolve such names.

Having NS records pointing to a CNAME is bad and may conflict badly
with current BIND servers. In fact, current BIND implementations
will ignore such records, possibly leading to a lame delegation.
There is a certain amount of security checking done in BIND to
prevent spoofing DNS NS records. Also, older BIND servers reportedly
will get caught in an infinite query loop trying to figure out the
address for the aliased nameserver, causing a continuous stream of
DNS requests to be sent.

[Paul]

Thralas schreef op vrijdag 7 september 2018 @ 16:09:

Google mail toestaan? Pech. Andere certificaatleverancier? Pech. Andere mailserver? Pech...

In 99% van de gevallen wordt een CNAME gebruikt om naar een ander A-record te wijzen. Dat de website op dezelfde host staat wil niet zeggen dat de rest gelijk is. In dat opzicht vind ik het dus inderdaad te breed. Leuk dat het origineel zo verzonnen is, maar zo wordt het (in mijn ervaring dan, die van jullie kan uiteraard verschillen) niet gebruikt. Zou je misbruik kunnen noemen, maar aan de andere kant is de technologie er natuurlijk om de mens te dienen, niet andersom.

Uiteraard is de oplossing simpel: er een A-record van maken, maar dat gaat wel voorbij aan waarom men er een CNAME van zou willen maken.

[ Voor 9% gewijzigd door Paul op 07-09-2018 16:26 ]

[Verwijderd]

Volgens mij moet het (toch) gewoon als volgt zijn(?);

name	type	value	opmerking
@	MX	10 mx.domein.nl.	mail afhandeling voor [e-mail]
@	A	123.123.123.123	website voor domain.nl
mx	A	123.123.123.123	Noodzakelijke A record voor mx.domain.nl
sub	MX	10 mx.domein.nl.	mail afhandeling voor [e-mail]
sub	A	123.123.123.123	A record voor sub.domain.nl zodat website/homepage bereikbaar is.

Volgens mij is het dan ook verstandig even SPF, DMARC en domainkey records toe te voegen zodat je Google en Outlook/Hotmail ook nog een beetje te vriend houdt. Als je ook IPv6 tot je beschikking hebt, kun je deze toevoegen met AAAA-Records en i.p.v. het bovengenoemde ip-adres het IPv6 adres erbij zetten.

[ Voor 16% gewijzigd door Verwijderd op 08-09-2018 01:31 ]