BEST DEAL

Showing posts with label record. Show all posts
Showing posts with label record. Show all posts

Wednesday, 21 December 2016

SOA record and SPF record

What is a SOA Record?

An SOA record is a Start of Authority. Every domain must have a Start of Authority record at the cutover point where the domain is delegated from its parent domain. For example if the domain mycompany.com is delegated to DNSimple’s DNS servers, we must include an SOA record for the name mycompany.com in our authoritative DNS records. We add this record automatically for every domain that is added to DNSimple and we show this record to you as a System Record in your domain’s Manage page.
Here is an example of the content from an SOA record:
ns1.dnsimple.com admin.dnsimple.com 2013022001 86400 7200 604800 300
The SOA record includes the following details:
  • The primary name server for the domain, which is ns1.dnsimple.com or the first name server in the vanity name server list for vanity name servers.
  • The responsible party for the domain, which is admin.dnsimple.com.
  • A timestamp that changes whenever you update your domain.
  • The number of seconds before the zone should be refreshed.
  • The number of seconds before a failed refresh should be retried.
  • The upper limit in seconds before a zone is considered no longer authoritative.
  • The negative result TTL (for example, how long a resolver should consider a negative result for a subdomain to be valid before retrying).
For the moment, these values cannot be configured by you.

SPF Records

Table of Contents


What is an SPF Record?

An SPF record is a Sender Policy Framework record and is used to indicate to mail exchanges which hosts are authorized to send mail for a domain . It is defined in RFC 4408 and clarified by RFC 7208.

SPF Record Format

SPF records are typically defined using the TXT record type. There is also an SPF record type, however it is deprecated and thus you should always have at least the TXT record definition present, even if you use the SPF type.
SPF records are defined as a single string of text. Here is an example record:
v=spf1 a mx ip4:69.64.153.131 include:_spf.google.com ~all
The SPF record always starts with the v= element. This indicates the SPF version that is used. Right now the version should always be spf1 as this is the most common version of SPF that is understood by mail exchanges.
Following the version indicator are one or more terms. These define the rules for which hosts are allowed to send mail from the domain or provide additional information for processing the SPF record. Terms are made up of mechanisms and modifiers. The following mechanisms are defined:
  • all
  • include
  • a
  • mx
  • ip4
  • ip6
  • exists
The `ptr` type is also defined but should not be used.
There are currently two modifiers defined:
  • redirect
  • exp

SPF Mechanisms

The following mechanisms define what IP addresses are allowed to send mail from the domain:
  • a
  • mx
  • ip4
  • ip6
  • exists
A mail server will compare the IP address of the sender against the IP addresses defined in the mechanisms. If the IP address matches one of the mechanisms in the SPF record then follow the result handling rule. The default handling rule is + or pass.
The include mechanism allows you to authorize hosts outside of your administration by specifying their SPF records.
The all mechanism matches any address. This is usually used as the last mechanism which defines how to handle any sender IP that did not match the previous mechanisms.
All mechanisms may specify qualifiers for how to handle a match. As previously mentioned, the default handling rule is pass, which is the same as the + qualifier. Other qualifiers that may be specified include - for fail, ~ for soft fail, and ? for neutral. If a mechanism matches and specifies - (fail) then

SPF Modifiers

Modifiers are name/value pairs (separated by an = sign) that provide additional information. Modifiers should appear at the end of the SPF record. A modifier may not appear more than once and unrecognized modifiers are ignored.
The redirect modifier is used to point to another SPF record to use for processing. This is used when you have multiple domains and want to apply the same SPF content across those multiple domains. Redirects should only be used if you control both domains, otherwise an include is used.
The exp modifier is used to provide an explanation in case of a - (fail) qualifier is present on a mechanism that is matched.
Note that we currently do not support modifiers in our SPF editing UI, but you may always add them if you are managing your SPF TXT record directly.

SPF Record Limitations

Each fully-qualified name may have at maximum one SPF record, defined as a TXT record or as an SPF record type.
Although the SPF record type is deprecated, it is still supported by DNSimple name servers at this time. In the future we may discontinue serving SPF records, so you should always have a TXT record whose content that is the same as the record using the SPF type.
There are various limitations to the number of items and lookups permitted in an SPF record:
  • SPF records may have more than 10 mechanisms that require DNS lookups. These are the includeamxptr, and exists mechanisms.
  • When evaluating the mx mechanism, the number of MX records queried is included in the overall limit of DNS lookups. Additionally, each mx mechanism must not result in querying more than 10 address records.
  • The ptr mechanism is also included in the overall limit and each ptr must not result in querying more than 10 address records.

Tips for SPF Records

Since you may only have one SPF record per fully-qualified name, if you need to add additional modifiers you should add them to your existing SPF record if it is present.
SPF records are most often specified on your naked domain name. If you find that you need to exceed the number of modifiers allowed in a single SPF record, then you may need to send some of your messages from subdomains below your naked domain. For example, if a third-party SaaS sends mail on your behalf, you may need to send email from something.yourdomain.com for that provider. This is especially true if you have multiple SaaS providers that send email on your behalf.
If you would like to test your SPF records for compliance with the RFCs, you may want to use one of the tools listed on the openspf.org website.

Difference between A,CNAME and Alias record

What is a CNAME record?

CNAME stands for Canonical Name. CNAME records can be used to alias one name to another.
For example, if you have a server where you keep all of your documents online, it might normally be accessed through docs.example.com. You may also want to access it through documents.example.com. One way to make this possible is to add a CNAME record that points documents.example.com to docs.example.com. When someone visits documents.example.comthey will see the exact same content as docs.example.com.
To use CNAME records, select CNAME from the Add Record drop down in the advanced editor. Then enter the hostname you would like to alias from and the fully-qualified domain name you would like to alias to. You may also enter @ in the Alias for field to represent the domain itself.
For example, if the domain were example.com and you wanted www.example.com to point to example.com you could put www in the name field and @ in the alias for field.


What is an ALIAS record?

An ALIAS record is a virtual record type that we created to provide CNAME-like behavior on apex domains.
For example, if your domain is example.com and you want it to point to a host name like myapp.herokuapp.com, then you cannot use a CNAME record, but you can use an ALIAS record. The ALIAS record will automatically resolve your domain to one or more A records at resolution time and thus resolvers see your domain simply as if it had A records.

How does it work?

The DNSimple name servers are currently based on an open source Erlang DNS server that we developed along with the help of others in the DNS community. The erl-dns server provides a mechanism for plugging in custom handlers (here is a sample custom handler) and we use that extension mechanism for providing an ALIAS handler. Each time a request hits the DNSimple name servers for either an A or AAAA record type the custom handler is invoked and attempts to resolve the ALIAS into its appropriate IPv4 or IPv6 address, respectively. It does this by asking a resolver to resolve the domain. At the moment we are running PowerDNS’s resolver running locally on each system for this purpose.
If the resolution succeeds then the handler extracts the A and AAAA records and returns them to the erl-dns server process, which then goes on its merry way. It also sticks the result in an in-memory cache (you’ll see why in a second).
If the resolution fails, for example due to a timeout, then the cached response is returned, if one exists. We have the request timeout set quite low (500 milliseconds) and we may even move it lower in the future. If there is no response in the cache then the request is retried again, up to a maximum number of retries. If the request ultimately fails then we return an empty result set.
To support secondary DNS servers, especially ones that connect to us and pull zones using AXFR, we must resolve the ALIAS in a different way. Currently we resolve it as part of the secondary DNS setup process initially and then run a scheduled job to update the ALIAS record at secondary name servers by resolving them again, removing the old records and writing the new records to our zone transfer database, and then finally sending a NOTIFY message to the appropriate secondary name servers.
The actual implementation is handled by a small Go application which our Rails application calls, either from within Rails execution or in an aynchrnonous job, to handle the resolution. The Go application currently calls to Google’s public resolvers to resolve the ALIAS record.
When creating an ALIAS record you will notice than additional TXT field is created, this field is optional and it can be used for debugging purposes.

What is an A record?

An A record maps a domain name to the IP address (IPv4) of the computer hosting the domain. Simply put, an A record is used to find the IP address of a computer connected to the internet from a name.
The A in A record stands for Address. Whenever you visit a web site, send an email, connect to Twitter or Facebook or do almost anything on the Internet, the address you enter is a series of words connected with dots.
For example, to access the DNSimple website you enter www.dnsimple.com. At our name server there is an A record that points to the IP address 208.93.64.253. This means that a request from your browser to www.dnsimple.com is directed to the server with IP address 208.93.64.253.
A Records are the simplest type of DNS records, yet one of the primary records used in DNS servers.
You can actually do quite a bit more with A records, including using multiple A records for the same domain in order to provide redundancy. Additionally, multiple names could point to the same address, in which case each would have its own A record pointing to the that same IP address.

Querying A records

You can use dig to determine the A record associated to a domain name. The result is contained in the ANSWER section and it contains the fully-qualified domain name (FQDN), the remaining time-to-live (TTL) and the IP address.
$ dig A api.dnsimple.com

; <<>> DiG 9.8.3-P1 <<>> A api.dnsimple.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5792
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;api.dnsimple.com.  IN A

;; ANSWER SECTION:
api.dnsimple.com. 59 IN A 208.93.64.253

;; Query time: 80 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Jul 31 22:21:31 2016
;; MSG SIZE  rcvd: 50

A record structure

In DNSimple we represent A record with the following information:
NameThe host name for the record, without the domain name. This is generally referred as “subdomain”. We automatically append the domain name.
TTLThe time-to-leave in seconds. This is the amount of time the record is allowed to be cached by a resolver.
AddressThe IPv4 address the A record points to.
A record in the DNSimple record editor

Managing A records

You can create, update and delete A records for your domain using the DNSimple record editor.