Skip to content

Getting Started with DNS

DNS Provider Used

When using the ExternalDNS component, keep in mind that it has already been configured to work with the DNS provider the platform runs on. For instance, if you are using Azure DNS, it will automatically use the Azure DNS API to manage DNS records, if you are using Netic on-premises, it will automatically use the TidyDNS API to manage DNS records, etc.

To make your application accessible via a public domain name, you need to add an annotation to your Kubernetes resources. This component will then automatically create the necessary DNS records to point to your application's external endpoint.

This component can create DNS records for the following resource types:

  • Services: For a Service of type LoadBalancer, you must add an annotation to specify the desired hostname.
  • Ingresses: Hostnames are automatically picked up from the spec.rules section of your Ingress resources.
  • Custom Resources: It also supports common custom resources like HTTPProxy from Contour.

Here are a few basic examples of how to configure resources for ExternalDNS:

Service Example:

apiVersion: v1
kind: Service
metadata:
  name: my-web-app
  annotations:
    external-dns.alpha.kubernetes.io/hostname: webapp.example.com
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: my-web-app

In this example, ExternalDNS would create an A record webapp.example.com pointing to the external IP of the my-web-app LoadBalancer Service.

Ingress Example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-api-ingress

spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-api-service
            port:
              number: 80

For this Ingress, ExternalDNS would create an A record api.example.com (or CNAME if target annotation is used or the Ingress controller exposes a hostname) pointing to the external endpoint of your Ingress controller.

HTTPProxy with cert-manager Example:

This example demonstrates a more advanced use case where ExternalDNS works alongside cert-manager to automate TLS certificate management for a domain exposed via an HTTPProxy resource (from Project Contour).

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: my-secure-app
  annotations:
    # This annotation tells cert-manager to issue a certificate for the FQDN
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  virtualhost:
    fqdn: secure-app.example.com
    tls:
      secretName: secure-app-tls
  routes:
  - services:
    - name: my-app-service
      port: 80

In this scenario, the components work together to fully automate DNS and TLS:

  1. You create an HTTPProxy resource, defining your desired hostname in spec.virtualhost.fqdn.
  2. The cert-manager.io/cluster-issuer annotation tells cert-manager to get a TLS certificate for that hostname.
  3. This component automatically sees the hostname from your HTTPProxy and creates the required A record pointing to your application.
  4. This component (through the external-dns plugin of cert-manager) also handles the temporary TXT records that cert-manager needs to confirm domain ownership, allowing the certificate to be issued automatically.