In this part you'll define DNS records on a dedicated nameserver ns1.hdm-stuttgart.cloud. This one being connected to the global DNS system allows for publishing your records worldwide.

Figure 1067. Subdomain per group Slide presentation
  • Dedicated course related DNS server ns1.hdm-stuttgart.cloud.

  • One subdomain per group e.g. g3.sdi.hdm-stuttgart.cloud corresponding to Group 3.

  • Zone edits require a subdomain specific hmac secret key being provided as dnsupdate.sec file in your personal group entry below the SDI course:

    hmac-sha512:g3.key:I5sDDS3L1BU...

    Note

    The per zone secrets have been created using tsig-keygen.

  • Edits become globally visible. Mind the TTL setting: A higher value means you'll have to wait longer until updates become visible.


Figure 1068. Key file location Slide presentation

Key file available in your working group below 113475 Software defined Infrastructure.


Figure 1069. Querying DNS by zone transfer Slide presentation
$ export HMAC=hmac-sha512:g3.key:YXWSeh3l... 
$ dig @ns1.hdm-stuttgart.cloud -y $HMAC -t AXFR g3.sdi.hdm-stuttgart.cloud 
...
g3.sdi.hdm-stuttgart.cloud. 600	IN	SOA	ns1.hdm-stuttgart.cloud. ...
g3.sdi.hdm-stuttgart.cloud. 600	IN	NS	ns1.hdm-stuttgart.cloud.
g3.sdi.hdm-stuttgart.cloud. 600	IN	SOA	ns1.hdm-stuttgart.cloud. ...
g3.key.			0	ANY	TSIG	hmac-sha512. 1746433052 300 64 bak...
...

See AXFR for details.


Figure 1070. Creating an »A« record with TTL=10 Slide presentation
export HMAC=hmac-sha512:g3.key:YXWSeh3l... 

$ nsupdate -y $HMAC
> server ns1.hdm-stuttgart.cloud
> update add www.g3.sdi.hdm-stuttgart.cloud 10 A 141.62.75.114 
> send
> quit
$ dig +noall +answer @ns1.hdm-stuttgart.cloud www.g3.sdi.hdm-stuttgart.cloud
www.g3.sdi.hdm-stuttgart.cloud. 9 IN  A       141.62.75.114
$ dig  +noall +answer @8.8.8.8  www.g3.sdi.hdm-stuttgart.cloud
www.g3.sdi.hdm-stuttgart.cloud. 3 IN  A       141.62.75.114

Figure 1071. Modify by delete/create Slide presentation
$ nsupdate -y $HMAC
> server ns1.hdm-stuttgart.cloud
> update delete www.g3.sdi.hdm-stuttgart.cloud. 10 IN  A       141.62.75.114
> send
> quit
>
$ dig  +noall +answer @8.8.8.8  www.g3.sdi.hdm-stuttgart.cloud
$ 

Note

Examples at DNS Updates with nsupdate


Figure 1072. Mind record caching Slide presentation
goik>dig +noall +answer  www.g3.sdi.hdm-stuttgart.cloud
www.g3.sdi.hdm-stuttgart.cloud. 9 IN A	141.62.75.114
  • DNS record caching.

  • Another 9 seconds to go before DNS cache invalidation.


exercise No. 21

Enhancing your web server.

Q:

Enhance your web server from Improve your server's security! by:

  1. Provide a DNS »A« record e.g., for http://www.gXY.sdi.hdm-stuttgart.cloud pointing to your server's IP address.

  2. Provide another DNS »A« record for http://gXY.sdi.hdm-stuttgart.cloud pointing to your very same server's IP address.

  3. Follow How To Secure Nginx with Let's Encrypt on Debian 11 and configure TLS allowing for access by both https://www.gXY.sdi.hdm-stuttgart.cloud and https://gXY.sdi.hdm-stuttgart.cloud to your server:

    • Omit the firewall related steps: You already have a Hetzner firewall rule set in place.

    • Avoid becoming a Letsencrypt rate limit victim. Letsencrypt's staging environment is far more lenient with respect to e.g., a failed validation limit of 60 per hour versus 5.

      The certbot command offers two related --staging and --test-cert options relating to https://acme-staging-v02.api.letsencrypt.org/directory and https://acme-v02.api.letsencrypt.org/directory respectively.

      After successfully creating, installing and testing your Letsencrypt staging certificate you should then be able to re-create your certificate omitting the --staging option and get a valid certificate.

Figure 1073. Bind server ns1.hdm-stuttgart.cloud Slide presentation
  • Providing DNS info for sdi.hdm-stuttgart.cloud and sub-zones:

    • g1.sdi.hdm-stuttgart.cloud

    • g2.sdi.hdm-stuttgart.cloud

    • ...

  • Remote API for per-zone editing


Figure 1074. DNS provider Slide presentation
terraform {
  required_providers {
    dns = {
      source = "hashicorp/dns"
    }
    ...
}

Figure 1075. DNS provider configuration Slide presentation
provider "dns" {
  update {
    server        = "ns1.hdm-stuttgart.cloud"
    key_name      = "g12.key."  # Corresponding to your group e.g., Group 12
    key_algorithm = "hmac-sha512"
    key_secret    = var.dns_secret 
  }
}

This requires:

  • A corresponding variable "dns_secret" {...} declaration.

  • An e.g., export TF_VAR_dns_secret = "sVfw2a...vAUqw==" (non - versioned!) environment variable.


Figure 1076. Defining an A record Slide presentation
resource "dns_a_record_set" "helloRecord" {
  zone = "${var.dnsSubnetName}." # The dot matters!
  name = hcloud_server.helloServer.name
  addresses = [hcloud_server.helloServer.ipv4_address]
  ttl = 10
}

Likewise with dns_cname_record and other record types.


exercise No. 22

Creating DNS records

Q:

In this exercise we start from a domain gxy.sdi.hdm-stuttgart.cloud not yet containing any »A« or »CNAME« records. The aim is using Terraform to create:

  • An »A« record workhorse.gxy.sdi.hdm-stuttgart.cloud resolving to the (likely non-existent) server IP 1.2.3.4.

  • Another »A« record gxy.sdi.hdm-stuttgart.cloud resolving to 1.2.3.4 as well.

    Note

    This will later allow for https://gxy.sdi.hdm-stuttgart.cloud.

  • Two aliases www.gxy.sdi.hdm-stuttgart.cloud and mail.gxy.sdi.hdm-stuttgart.cloud both referencing workhorse.gxy.sdi.hdm-stuttgart.cloud.

Provide proper variables representing:

  • The base domain.

  • The server's canonical name.

  • The list of server alias names.

This way your Terraform configuration remains flexible. You may follow the subsequent steps each time testing your result:

dig +noall +answer @ns1.hdm-stuttgart.cloud -y $HMAC -t AXFR gxy.sdi.hdm-stuttgart.cloud
  1. Start from scratch: Remove resources from previous exercises and create a minimal configuration containing just an »A« record.

    Test this configuration.

  2. Add the two aliases.

    Test this configuration again.

  3. Define corresponding variables and re-factor any hard coded strings accordingly e.g.:

    # config.auto.tfvars
    serverIp      = "1.2.3.4"
    dnsZone       = "gxy.sdi.hdm-stuttgart.cloud"
    serverName    = "workhorse"
    serverAliases = ["www", "mail"]
  4. Your configuration may be prone to two different types of configuration errors:

    • Duplicate server alias names:

      ...
      serverAliases = ["www", "mail", "www"]
    • Server alias name matching server's common name:

      ...
      serverName    = "workhorse"
      serverAliases = ["workhorse", "mail"]

    Both will cause terraform apply DNS update failures. Add appropriate Custom Validation Rules to your variable definitions.

    Tip

exercise No. 23

Creating a host with corresponding DNS entries

Q:

Extend Solving the ~/.ssh/known_hosts quirk by adding DNS records like in Creating DNS records . The provider generated IP4 address shall be bound to workhorse within your given zone.

Use the server's common DNS name rather than its IP in the generated gen/known_hosts, bin/ssh and bin/scp files, e.g:

gen/known_hosts:
workhorse.gxy.sdi.hdm-stuttgart.cloud ssh-ed25519 AAAAC3N...at8e8JL3rr
bin/ssh:
#!/usr/bin/env bash

GEN_DIR=$(dirname "$0")/../gen

ssh -o UserKnownHostsFile="$GEN_DIR/known_hosts" devops@workhorse.gxy.sdi.hdm-stuttgart.cloud "$@"

#end

exercise No. 24

Creating a fixed number of servers

Q:

Write a Terraform configuration for deploying a configurable number of servers being defined by the following config.auto.tfvars:

dnsZone        = "gxy.sdi.hdm-stuttgart.cloud"
serverBaseName = "work"
serverCount    = 2

terraform apply shall create the following:

  • Two DNS entries:

    • work-1.gxy.sdi.hdm-stuttgart.cloud

    • work-2.gxy.sdi.hdm-stuttgart.cloud

  • Two corresponding servers each endowed with its own unique ssh host key pair.

  • Two corresponding sub directories work-1 and work-2 each containing its own bin/ssh and related gen/known_hosts file.