All domains that UTN own should use cloudflare. CloudFlare is a free service that helps both optimize the access to web server by caching pages, but also protect the website against threats. It does this by interrupting a client from accessing the actual server if it might be a threat, it will challenge the user if in doubt of a malicious bot, and then serve the page from cache if possible.
CloudFlare keeps excessive data on requests, so it’s interesting to take a look once in a while.
It also hides the server ip address which adds an extra protection against attacks. Important!: Don’t make the server ip address public e.g. write them on this webpage. Only give it to trusted people.
Next to almost all DNS posts there is a cloud that can be orange or gray. This is the cloudflare proxy. If the cloud is orange the traffic to that domain goes through cloudflare and gets protected. If it is gray, cloudflare wont protect it and will just let traffic through.
All records should be proxied through cloudflare (orange) so that they are protected. Note! Mutlilevel-domains should not be proxied since the SSL certificate does not handle those kinds of domains.
When a record is proxied through cloudflare, you can not use SSH on that record (ssh moore.utn.se). Instead you must SSH to the ip directly (ssh XXX.XXX.XXX.XXX)
The DNS records have been organized in a specific structure, making managing the DNS easier. The structure is as follows:
Cloudflare provides some handy features for dealing with SSL/TLS certificates. One of these features is that Cloudflare can create a and serve a ssl certificate for us.
All domains should use the option Full(strict). This option means that traffic between users and cloudflare AND the traffic between cloudflare and our servers will be end-to-end encrypted. One of the requirements for this is that the servers has a trusted certificate. Again cloudflare provides a solution for this called origin certificates. The origin certificte is generated by cloudflare and must then be placed on the servers.
The current origin certificates are valid for 15 years and expire 18/6 2035.
The origin certificates creates a certificate and a private key. The certificate is placed in /etc/ssl/certs and the private key in /etc/ssl/private.
KEEP THEM SERCRET!.
When using a multi-level domain name (e.g. anmalan.rally.utn.se), the certificate provided by cloudflare is not valid since it only covers one level of subdomains (e.g. rally.utn.se). This will cause errors when the browser tries to load a website. Instead use a one level domain name e.g. anmalan-rally.utn.se
Cloudflare has a feature called page rules. With these rules you can apply different rules to different websites. One of these rules are to redirect a website. Redirects should not be deleted since they previous were the main website which were then switched. During the time before the switch the original URL will exist on many places. If someone then goes to the original URL they wont get where they wanted and will become confused.
The current redirects can be found under the Page Rules tab.
SPF records are essential when dealing with email since they increase the validity of the emails sent from the union.
SPF records tell email services which servers are allowed to send emails on behalf of the domain.
Most SPF records for UTN look like this:
v=spf1 a:babbage.utn.se a:pay.utn.se a:turing.utn.se include:_spf.google.com ~all
Make sure you check the SPF entry using a tool like MxToolbox.
Alongside SPF records, DKIM records exists as well. They are also essential in when dealing with email.
DKIM signs all emails on a domain with a key.
The same key is also put in the DNS for that domain.
This way, email providers can validate if the email acctually was sent from that domain.
The DKIM keys are created in GSuite under apps -> gmail -> authenticate email.
When addin a DKIM to a subdomain, the name of the TXT entry must be (optional_prefix)._domainkey.subdomain
DMARC is also important when dealing with email. DMARC defines a policy for what to do with untrusted email and generates a daily report with the delivered and undelivered mail. DMARC is added to the DNS as a TXT Record and can be configured in many ways. DMARC can be added to a subdomain but can also just be added to the primary domain (utn.se).
The current configuration for DMARC is to let suspicious mail be delivered.