Posts Tagged DNS
For 1&1 users who are trying to change their DNS settings and finding them unmodifiable.
- Go into the 1&1 control panel
- Go to the Administration page
- Click on “Manage Domains”.
- Choose one of the domains in the Domain Overview list.
- Click on the down arrow on the DNS Settings option.
- Click on “Edit DNS” when the menu drops down. Now you should be on the DNS Settings screen.
If, Under Basic DNS Settings does it say “1&1 name server (unmodifiable)” -or- Under Advanced DNS Settings does it say “IP Address (A-Record) 1&1 IP Address (Unmodifiable)” ?
You won’t be able to modify any of these DNS settings if you’ve ever used the WebsiteBuilder tool on that domain. Simply go to your account and delete the WebsiteBuilder service from your account. You should now be able to edit the DNS settings.
In my first post about Ubuntu, Apache, VirtualHosts, and SSL I covered generating self-signed certificates and implementing them for Apache VirtualHosts. What I didn’t cover was — if you implemented this without a correct base configuration — you’d end up with some unexpected results if you tried to visit your base domain over SSL.
It’s simple to resolve this. First, edit /etc/apache2/ports.conf and modify as follows:
# If you add NameVirtualHost *:443 here, you will also have to change # the VirtualHost statement in /etc/apache2/sites-available/default-ssl # to # Server Name Indication for SSL named virtual hosts is currently not # supported by MSIE on Windows XP. + NameVirtualHost *:443 Listen 443
If you were reading closely, you know what to do next. Modify sites-available/default-ssl file and change the
directive as follows:
Now, restart apache:
Your base SSL domain will now display the expected DocumentRoot, but the certificate will contain the URL
localhost.localdomain. To fix this run, as root:
make-ssl-cert generate-default-snakeoil --force-overwrite
— From /usr/share/doc/apache2.2-common/README.Debian.gz
If you install the ssl-cert package, a self-signed certificate will be
automatically created using the hostname currently configured on your computer.
You can recreate that certificate (e.g. after you have changed /etc/hosts or
DNS to give the correct hostname) as user root with:
make-ssl-cert generate-default-snakeoil –force-overwrite
Questions, comments, and feedback regarding this guide and welcome!
If you have a Synology DiskStation and already have a hostname (for your website, blog, or other) you can set up your DiskStation on a dedicated subdomain easily — even if you have a dedicated IP address.
First, determine what subdomain you’re going to assign to your device, based on the domain name you already have. For example, you might own example.com and want ds.example.com to point to your DiskStation. That’s perfectly fine — it’s your choice.
Next, get yourself a free dynamic IP hostname at a service like DynDNS. They provide Dynamic DNS hosts for free, and it only takes a few minutes to sign up. It doesn’t matter what domain you pick, but you only get one. For the purpose of this guide, I’ll say that I signed up for example.dyndns.org. If you are using the Synology Dynamic DNS service, you have this already. Continue.
Once you’re signed up and activated your domain, you need to set up automatic updating. You can do this through the DiskStation itself under Control Panel > DDNS, or with a router that supports Dynamic IP updating (most routers).
Now your client will keep your hostname up to date automatically, even if your IP address changes.
The next step is to assign your new DynDNS hostname to a DNS CNAME record. You want to add a CNAME record for ds.example.com that points to example.dyndns.org. Specific instructions will vary by your DNS registrar, so consult them if you’re not sure exactly how to add the record. Keep in mind it may take up to 24+ hours for the DNS record to propagate, so if it doesn’t work right away, try again later.
Once the DNS zone has propagated, you should be able to access your DiskStation at your new hostname ds.example.com, and the DynDNS client will keep your hostname updated.
If you want to create an SSL cert for HTTPS access, create it for ds.example.com using the instructions found here: https://mikebeach.org/2012/11/13/startssl-ssl-certificate-on-synology-nas-using-subdomain
Questions, comments, and feedback about this are welcome.
Google has added support for DomainKeys Identified Mail (DKIM) in Google Apps. This adds one additional layer of authentication to prevent forged or spoofed mail which could appear to come from your domain. This is an excellent compliment to having DNS SPF records.
Spammers can forge the From address on mail messages so that the spam appears to come from a user in your domain. To help prevent this sort of abuse, Google Apps enables you to add a digital “signature” to the header of mail messages sent from your domain. Recipients can check the domain signature to verify that the message really comes from your domain and that it has not been changed along the way. (If your domain has an SPF record, recipients can also verify that the message came from an authorized mail server.)
Set up consists of generating the key and adding it to your DNS records as a TXT entry.
To activate DKIM authentication for your domain email, sign into your Google Apps dashboard and go to Advanced tools. You should see a heading Authenticate email.
For more information, see Google Apps Administrator Help > Authenticate email with a domain key.
Sender Policy Framework (SPF) is a DNS record that’s used to authenticate who is allowed to send mail appearing to come from a specific domain. It is used to help prevent email spamming and spoofing, and works by making available a list of what domains, mailservers, and IP addresses are authorized to send mail from a domain, and what to do with mail that does not match those rules.
SPF is a DNS text record, and is added to your DNS records for the domain that matches the part after the @ sign in the email address. For example, for @example.com, the SPF TXT record should be added to the example.com domain.
I’m not going to cover every possible SPF setup, simply the ones I use most often and the rationale behind them. You can check the documentation links below my examples if you want to build more elaborate or specific SPF records.
In the below examples, substitute
with your web server’s IP address in dotted-quad format without a space. E.g.
IP:10.1.2.3. You can also specify a CIDR range such as
Allow from the domains IP, it’s listed mailservers, and a specific IP. Soft-fail all others (Messages that return a SOFTFAIL are accepted but tagged). The recommended configuration for most dedicated/VPS web server environments. Used when you send/receive mail at your domain, and software on your domain may send mail out as you, but no other mail server or mail exchanger will send mail as you. Users of shared hosting environments will probably want to ask their web hosting provider for the recommended SPF record to use.
v=spf1 a mx ip4: ~all
Include Google’s SPF records, if you use Google Apps as your domains mail. Add
include:_spf.google.com, similar in rationale to the above, but used if you use Google Apps for email, and your software on your web server may also send mail as you.
v=spf1 a mx ip4: include:_spf.google.com ~all
Fail all mail. Used only if you send no mail. Example: a parked domain or a domain that is not used in email at all.
In all the examples above except for the last, I denote soft-fail (
~all) instead of fail (
-all). This is because you may inadvertently make a mistake or misconfiguration, and soft-failing will not prevent mail from being delivered, it will simply flag it in the email headers. You can also specify neutral (
?all) as an alternative.
Here’s an example email header from Gmail which includes the SPF record’s lookup result. I’ve edited the email address and IP, of course.
Received-SPF: pass (google.com: domain of firstname.lastname@example.org designates IP as permitted sender) client-ip=IP; Authentication-Results: mx.google.com; spf=pass (google.com: domain of email@example.com designates IP as permitted sender) firstname.lastname@example.org
By this example, you can see the SPF record matched and was passed.
SPF records are a good tool for many reasons. They give mail servers the ability to authenticate your email to your domain, which helps keep it out of recipient’s spam folders, and they help prevent others from spoofing your domain in email, which could cause serious trouble.
Also, SPF records do not decide whether or not to accept mail for delivery — they only serve as an authentication mechanism for who is allowed to send mail appearing to come from that domain.
- SPF Project Overview
- The SPF Setup Wizard (Wizard to build SPF records quickly and easily)
- MediaTemple – HOWTO: SPF – All Purpose (Pre-built SPF records for MediaTemple customers)
- Wikipedia – Sender Policy Framework
- SPF Record Testing Tools
- SPF Records – Google Apps Help
Questions, comments, or feedback about the above SPF records or how they’ve been explained? Please share your thoughts in the comments below! Thank you.