Manage DNS
Learn how to add and manage DNS in Humanitec.

Introduction

DNS names provide a standard way to make services accessible on the public internet. In Kubernetes applications, DNS names are most often used with Ingress objects to map incoming requests to an external Load Balancer to workloads running inside the cluster.
In Humanitec, a DNS name is represented as a Resource of type dns. The DNS name for the resource might be known ahead of time (a static resource) or generated when it is first used (dynamic).
By default, Humanitec will automatically generate dynamic DNS name under the .newapp.io domain along with a valid SSL certificate. However, it is possible to configure different DNS names that will get picked up in different environments.

Dynamic DNS

A Dynamic Resource Definition can be used to define how new DNS names should be generated. In most cases, this involves creating a subdomain to an existing domain. Humanitec provides 2 drivers which can be used to dynamically generate DNS names as required on existing domains:
This driver assumes that a wildcard record exists in the appropriate zone file resolving all DNS requests on any subdomain to be directed to the cluster Load Balancer. The driver will generate new unique subdomains and requires a static wildcard TLS certificate.
By definition, this driver can only be used for environments in a single cluster.
This driver adds records to a Cloudflare Zonefile pointing at the Load Balancer for the relevant cluster. The driver will generate new unique subdomains and requires a static wildcard TLS certificate.
This driver can be used with environments running on different clusters.

Static DNS

A Static Resource Definition can be used to define static DNS names to be used for ingress.
As each workload that needs to be exposed requires a different DNS name the resource matching criteria used must exactly match the relevant workload. Note, due to a limitation in the UI it is not yet possible to define resource level matching criteria via the UI. It has to be done via the API.
Here is an example of the API call to create a Static Resource Definition where a workload called frontend-service in the production environment of the topic-share app will be exposed with the DNS name app.topicshare.com:
1
curl --request POST \
2
--header "Authorization: Bearer $HUMANITEC_TOKEN" \
3
--header "Content-Type: application/json" \
4
--data '{
5
"id": "fe-dns-name",
6
"type": "dns",
7
"data": {
8
"values": {
9
"name": "app.topicshare.com",
10
"tls_cn": "*.topicshare.com"
11
},
12
"secrets": {
13
"tls": {
14
"tls.crt": "...",
15
"tls.key": "..."
16
}
17
}
18
},
19
"criteria": [
20
{
21
"app_id": "topic-share",
22
"env_id": "production",
23
"res_id": "workloads.frontend-service"
24
}
25
]
26
}' \
27
https://api.humanitec.com/orgs/topicshare/resources/static
Copied!
Where $HUMANITEC_TOKEN is an appropriate authentication token. See the API Documentation for creating Static Resource Definitions for more details.
Last modified 1mo ago