I found in DNS setting, there is a period after the record. I am wondering what's the reason for this?
For example test.test.com.
The 'dot' is the root of the DNS heirarchy and, on some systems, if you don't use it the DNS server thinks it's a record in the current zone and will append it, rather than treating it as an FQDN (Fully Qualified Domain Name)
G
Related
I'm working on a tool to generate SPF TXT records and I am trying to get a loop for scanning the domain for the relevant hosts A records. All I get is just a single entry when I supply the domain name as the domain to check. The other hosts in the domain don't return entries...
Any ideas on how to do this?
Did some research and it seems that you need to do a zone transfer to get the records, as allowing a random IP to access the whole domain has too many security vectors. So no real way to do what I was wanting... Sorry for wasting time!
Like many others, I have navigated the SPF/DKIM/DMARC world with some confusion.
About 4 weeks ago or so I finished setting everything (SPF/DKIM/DMARC) up correctly for a GoDaddy-hosted domain that uses Google's mailservers.
I set the _dmarc TXT record to take zero action with p=none and I used Postmark to monitor the results to see what was passing and failing over a week.
After a week or so I looked at the Postmark results and inserted the include: statements for the domains that I wanted to pass, but weren't. Then I waited another week to see the results. However, the results showed that the domains still weren't passing SPF or DKIM. Below is the SPF record, I've redacted parts of it that are revealing, but two of the domains are legit and still aren't passing.
v=spf1 include:_spf.google.com include:freshemail.io include:cherryroad.com ~all
Do I need to use the actual IP addresses in the include statements instead of the domains? Postmark lists these as well so that would be easy if so.
No, you shouldn't copy their IPs in there because they are subject to change, especially Google's.
If it's failing, presumably you have some results (usually in message headers) that tell you exactly which IP is failing, and you can track it down manually though those includes, do a reverse lookup on it, etc.
However, you're also using GoDaddy, which is mostly guaranteed not to work as they either block outbound SMTP or route it through their own servers, so you're very unlikely to get an SPF pass.
The issue was with SPF DNS lookup limits. I had no idea this was a thing and I'm amazed that this isn't mentioned anywhere on the documentation (whether that's Google's official documentation or otherwise) on setting up SPF/DKIM/DMARC, and didn't come up in Googling of this issue. This limit is designed to prevent denial of service attacks and infinite DNS loops.
For anyone else who sees this post
v=spf1 include:_spf.google.com include:freshemail.io include:cherryroad.com ~all
This SPF record actually has almost 15 DNS lookups, and the limit is 10 per domain. You can find out how many SPF DNS lookups your domain has with a service like AutoSPF or Easy DMARC
The solution, once you see your total DNS lookups, comes in four options:
Create subdomains and use those to diversify the records. For example using "email#business.mydomain.com" as the email for freshemail.io. Then on the SPF record for that subdomain, you would only have v=spf1 include:freshemail.io resulting in less than 10 DNS lookups for that domain.
As #Synchro mentioned, you don't want to use IPs because those can very well change, but the concept of using IPs instead of the domain names does essentially work because an IP address doesn't cost a DNS lookup. Check with the support/engineering of whatever service you're using, it's possible that they have an IP (or an IP range) that doesn't change often. You might be able to bring your DNS lookups under ten using this.
Note that Google takes up about 3 DNS Lookups, and you'll probably want to leave that one as the _spf.google.com value
Note that every SPF record also has a 255 character limit, so if you're using only IPs you'll need to break that up into a lot of SPF records probably
Use an SPF flattening or compressing service like AutoSPF. Essentially, these services employ method #2, but do some backend work every few hours to check and update the IP addresses associated with the domains. Then they provide you with a "compressed" record like v=spf1 include:_6359384.autospf.com ~all that references all of your records and results in far fewer DNS lookups.
Create your own method that acts kind of like #2 and #3, using GoDaddy's API and brew up something that performs updated lookups on a schedule/job and updates separate SPF records including all of the IPs.
I need to know about child nameserver, What is it and for what purpose can we use that ?
I have seen an option in whois.com about child name server which has to be pointed out to an ip address, I have tried to use as an subdomain, but I can use subdomain by another way, so basically what is use of that actually ?
Quoting from a source I found using Google:
"Child Name Servers are private labelled name servers which are registered with domain registry under your own domain name.
eg. ns1.domainname.com, ns2.domainname.com
Child Name Servers needs to be registered with registry and also it's A record needs to be pointed to IP address of DNS Server before they can be used as name servers with other domain names. Child Name Servers can be only registered by owner of the primary domain name."
You could use them for a number of reasons; e.g.
If the parent nameserver is run by a DNS provider, the child nameserver could allow you to host the names in the subdomain yourself ... and update them without relying on the DNS provider's (possibly clunky) APIs.
Within a large organization it could allow the management of different subdomains to be done by different groups.
You might do it if you wanted a subdomain to contain dynamic names.
I have seen an option in whois.com ...
I think you might be confused about the purpose of the WHOIS service. It is purely for documenting which people (notionally) control which domains. To implement a child domainserver, you just need an A record in the parent domainserver that points to the child.
A web designer friend of mine is moving a customer of hers to a new hosting provider but she wanted me to look at their email setup to make sure that nothing she was doing would affect their email. I did an assortment of MX record and dns record lookups and to me there seems to be something really strange with their mail setup. For example, there are two mx records where I'm used to seeing one (domain names and ip addresses are dummy's just to be safe): Pref: 10 hostname: mx.name.net ip address: 111.222.555.333 and the second Pref: 20 hostname: mx.ct.diffname.net ip address: 111.222.444.222 and neither "name" nor "diffnam" is their domain name. Then the dns entry for mail.theirdomain.net points to an address that's different from either the two addresses pointed to by the mx record.
I haven't setup a mail server in a while but I checked the last one I did and in the mx record the hostname was mail.domainname.org (and there was only one entry) and the address in the mx record was the same as the address in the mail.domainname.org dns entry.
I could understand if there were two MX records for either load balancing or fail-over in case the main server went down but the setup seems strange and the fact that the mail.domainname.com dns entry doesn't point to the same address as the mx record makes me think something is setup wrong in their email system. Does anyone have some insight into this?
mail.domainname.com has nothing to do with MX or SMTP; it's just a normal domain name.
It typically points to an HTTP server that serves webmail, which may or may not be the same as the SMTP server.
The point of having multiple MX records is in case one of them goes down.
In a DNS zone file, there are different entries that denote the type of service for which a canonical may be directed. One of these is the MX record which determines where services look for email SMTP access. The primary record is called the A record, which usually directs to the IP address(s) for web services and the primary domain.
Hope this helps!
Just want to see if I understand this correctly.
CNAME record specifies an alias, in the following form:
alias CNAME canonical-domain
Which means if something is trying to look up alias, it will find the CNAME record and start searching for canonical-domain instead.
A record directly maps a host to an IP
host A IP-addr
So if I have 2 domains eventually pointing to the same IP addr, one is a canonical domain and another is an alias domain, I would use an A record for the canonical domain->IP mapping, and a CNAME record for the alias->canonical mapping.
Why can't I just use 2 A records, one being canonical->IP mapping and the other being alias->IP mapping? Is it so that you only have to update the IP once if you ever need to change it? (Analogy would be CNAME is a softlink and A record is a file in a filesystem)
Why can't I just use 2 A records, one being canonical->IP mapping and
the other being alias->IP mapping?
You can - that's perfectly normal.
Is it so that you only have to update the IP once if you ever need to
change it?
Yes, that's right.
A common configuration is to have the canonical name being the server's real hostname, and then CNAME records for the sites hosted on that server pointing at that.
Note that you can't have a CNAME for a bare domain name (e.g. stackoverflow.com) . A CNAME record can't coexist with the NS and SOA records that are expected to exist at the apex of a zone.
(Analogy would be CNAME is a softlink and A record is a file in a
filesystem)
That's not an analogy I'd use.