My DNS has a set up for the domain base.com that consists of A and MX records. There are several other domains that are set up with CNAME records, pointing to base.com.
Do I need to set up anything special (like extra MX records) for the CNAME domains, or will the CNAME records also forward any MX requests.
Example:
Will an email sent to info#otherdomain.com be delivered correctly to the MX of base.com if these (and only these) DNS records are in place:
; A and MX set up for base.com
base.com. 3600 IN A 123.45.67.89
mail.base.com. 3600 A 123.45.67.89
base.com. 3600 IN MX 10 mail.base.com.
; CNAME set up for otherdomain.com
otherdomain.com. CNAME IN A base.com.
CNAME causes queries for all RR types (excluding CNAME itself) to be directed to the target name. That includes MX. So yes, the above zone data will cause queries for otherdomain.com.'s MX to resolve to mail.base.com..
Experiment with dig or your favorite DNS client. Not only will you confirm the result for sure, but you won't have to wait 4 hours for someone to answer your SO question before you get your answer!
Unfortunately, in this particular case, if your domain is really of the form otherdomain.com., you would not be able to configure a CNAME resource records for it. This is because domains that have CNAME records cannot have any other type of resource record at the same time. Yet if otherdomain.com. is directly below com. (or another gTLD), it is necessarily at the top of a zone and so it needs at least SOA and NS records.
Related
As you all may know, only one SPF record should be set up in the DNS records. My question however is if this also applies to other subdomains.
For example, I send emails through AWS and the given SPF record is"v=spf1 include:amazonses.com ~all" # noreply. But I also use Protonmail with the same domain and the SPF record given there is "v=spf1 include:_spf.protonmail.ch mx ~all" # root.
Not only is the subdomain different, but the protonmail record has a 'mx' in it too.
How am I exactly supposed to put this in my DNS?
You can quite happily have separate SPF policies for subdomains - the SPF at example.com can be different from one at mail.example.com. The contents of those records can be independent too, and there is no reason why the MX for mail.example.com can't be the same as for domain.com - in fact it is assumed to be unless you specify otherwise.
That said, it's not clear that you're needing subdomains at all, but simply to combine SPFs covering different sources for the same domain, for example the 2 examples you give could be combined as:
v=spf1 mx include:_spf.protonmail.ch include:amazonses.com ~all
The local part of the address (to the left of the #, like root#example.com or noreply#example.com) does not figure in SPF checks, so it's irrelevant.
If that's not what you meant, please expand your question.
i tried to search internet but not found answer.
On one domain name, in root and in a sub-domain name i have MX records pointing to the same mail server with same prios:
domain.com in MX 10 mail-1.com
abc.domain.com in MX 10 mail-1.com
Zone was released without any errors, and now from external DNS check when i DNS-reverse: abc.domain.com i get this result:
abc.domain.com IN MX 10 mx.abc.domain.com
Crazy, isnt it?
am i missing something here?
Maybe same MX servers cant be connected to # and sub-domain?
or maybe i should set different prios and it will work correctly?
or simplest: if MX is connected to root, there is no need to add it to sub-domain?
thanks for help!
MX record is a type of resource record in the Domain Name System that
specifies a mail server responsible for accepting email messages on
behalf of a recipient's domain
So answers to your points:
of course, mail servers can handle multiple different domains. I am certain that ASPMX.L.GOOGLE.COM is set as MX record for thousands of domains
priorities don't matter here, thyy are used in case you have multiple MX records for the same domain
you need MX for subdoman only if you intend to receive emails for something#sub.domain.com addresses
(Troubleshooting any issues/mismatch will be difficult without real domain name)
I want type domain.com at browser, then connect www.domain.com likes type google.com to connect www.google.com.
The information below is currently set.
domain.com. NS ns-1623.awsdns-10.co.uk.
ns-1461.awsdns-54.org.
ns-180.awsdns-22.com.
ns-880.awsdns-46.net.
domain.com. SOA ns-1461.awsdns-54.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
*.domain.com. A XXX.XXX.XXX.XXX
What should I do if you would like to do this?
You want to use DNS redirection with a CNAME entry/record. Check out this link.
Basically, you create a record that refers to some other A record (or, perhaps, another CNAME in some circumstances). You can set this up for any number of subdomains (www, www2, mail, home, etc.).
Let's say I have a server (DNS and other), myserver.com. Now I register a domain, mydomain.com, and set it's NS at the registrar to myserver.com - it is therefore the authoritative server, if there is any such thing.
In the authoritative records for mydomain.com, can I set the NS to ns.mydomain.com?
I have two domains set up like that, one works, the other one seems reluctant to propagate. So I'm wondering if there is something wrong with that - I mean how can you resolve the name of the NS when you need to resolve the name of the NS to resolve the name of the NS...
And, If yes, how come parallels plesk sets them automatically in this way?
Ps: there is an A record for ns.mydomain.com on that same server, pointing to the proper IP
There's a solution for this problem - it's called "glue records", i.e. A records hosted in the parent zone that contain the IP addresses of the name servers.
See http://en.wikipedia.org/wiki/Domain_Name_System#Circular_dependencies_and_glue_records
Why would you want to set the NS record for the "mydomain.com":
to "myserver.com" in the delegation record that goes into the parent zone (com.), but
to "ns.mydomain.com" at the zone apex (inside the mydomain.com. zone)
? This creates an inconsistency (two different DNS servers answer the same question with two different answers) without any apparent benefit. You should try to help the DNS system as a whole issue consistent answers.
Unless you have a good reason to make the DNS inconsistent, you should decide what the correct, canonical name for your nameserver is, and publish that name in the NS record both in the delegation and at the zone apex for "mydomain.com".
That being said, it will still work:
If a recursive resolver which does not yet know anything about "mydomain.com" asks about it, it will be told by the gTLD servers to go look at "myserver.com". The gTLD will also issue A and AAAA glue records to help find "myserver.com", but even if they don't, you have A and AAAA records for "myserver.com" in the "myserver.com" zone file (right?).
If a recursive resolver which wants to refresh its cache for the "mydomain.com" NS record, it may query the authoritative server it already knows about. This server will answer that the nameserver is "ns.mydomain.com", with a glue record. This is different from what it had in its cache before, but ultimately it will map to a server with the same IP address.
As for "parallels plesk", I know nothing about that.
I setup a couple of nameservers and updated my domain to use them, and as far as I can tell everything went fine and the nameservers have been updated, or so says every whois and dnstools type site ive used, (intodns, who.is etc are all saying the same thing: the new nameserrvers are in effect, and the site points to the new ip just fine). Problem is that The site is not showing up, and dig tells me that the old ip/nameservers are still effective.
In my DNS Records I have:
domain. A IN NS ns1.newnameserver
domain. A IN NS ns2.newnameserver
ns1 IN A newipaddress
ns2 IN A newipaddress
domain. IN A newipaddress
I'm very short on time and haven't found anything on the interweb, so any help would be much appreciated
The old IP address is probably being cached by the server you queried. First of all, check that BOTH your new authoritative nameservers are publishing the correct address by querying them directly with dig:
dig #ns1.newnameserver domain. a
dig #ns2.newnameserver domain. a
Assuming those queries give correct answers, dig some other servers that aren't:
dig domain. a # Use the system's default resolvers
dig #8.8.8.8 domain. a # Use Google's public resolver
dig #some.other.ip.address domain. a
If it gives the old answer, look at the TTL. That's the numeric field listed in the answer just after the name and before "IN". That's how many seconds you have to wait until the server you queried discards its cached data and will query the authoritative servers again.
Ask those same nameservers where they think "domain." is delegated:
dig domain. ns # Use the system's default resolvers
dig #8.8.8.8 domain. ns # Use Google's public resolver
dig #some.other.ip.address domain. ns
You want to see 2 NS reocrds for "domain.", one pointing to "ns1.newnamserver" and the other one to "ns2.newnameserver", but the resolvers likewise cache that information so they might still have the old nameservers. If so, look at the TTL on those NS records too. If the TTL on those records is longer than the TTL on the A records, those resolvers may still go to the old nameservers to get "domain."'s A records even when their currently cached copy expires... so you may need to wait for that TTL to expire first, and then for the TTL on the actual A record to expire again!
Another thing you can do is query some of the authoritative nameservers for the PARENT domain of your domain to see if they are indeed delegating it to "ns1.newnameserver" and "ns2.newnameserver". This will verify that the delegation in DNS matches what's in WHOIS.
dig com. ns # If your domain's parent domain is "com."
dig #<one-of-the-servers-that-resulted-from-that-query> domain. ns
Again, you want to see 2 NS reocrds for "domain.", one pointing to "ns1.newnamserver" and the other one to "ns2.newnameserver".
If the old nameservers are still running, either:
make sure they aren't, or
make sure they've also got the new zone data
Some people will still be talking to the old nameservers, and until they either stop answering or give the right answer, they won't learn the new nameservers from the parent zone.