check that a DNS record exists for this domain

Question

I have the following ingress manifest file:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  namespace: fsm
  name: fsm
  labels:
    app: fsm
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    cert-manager.io/issuer: "letsencrypt-staging"
spec:
    tls:
    - hosts: 
      - k8s-cluster.int
      secretName: quickstart-example-tls
    rules:    
    - host: k8s-cluster.int
      http:
        paths:
          - path: /fsm(/|$)(.*)
            backend:
              serviceName: fsm
              servicePort: 8081

I am working with VMware with Vsphere. I don't have a domain like www.google.com, just a DNS name which is k8s-cluster and the domain .int (inside my company). When I am trying to generate the certificate I receive this error: "msg"="error waiting for authorization" "error"="acme: authorization error for k8s-cluster.int: 400 urn:ietf:params:acme:error:dns: DNS problem: NXDOMAIN looking up A for k8s-cluster.int - check that a DNS record exists for this domain" "dnsName"="k8s-cluster.int" "resource_kind"="Challenge" "resource_name"="quickstart-example-tls-w7vj9-4141989927-3312743172" "resource_namespace"="fsm" "resource_version"="v1" "type"="HTTP-01"

Can this problem appear because k8s-cluster.int is inside a intranet? If I curl k8s-cluster.int

<html>
<head><title>308 Permanent Redirect</title></head>
<body>
<center><h1>308 Permanent Redirect</h1></center>
<hr><center>nginx/1.19.1</center>
</body>
</html>

So, I think that the DNS works.

Nikita Kipriyanov · Answer 1 · 2021-01-05T20:04:57.083

You tried to use ACME, it is what Let's Encrypt use. The ACME protocol is basically an automated DNS domain validation and it gives you a "domain validated" certificates. It checks if DNS records with requested names really point to requesting server (or are under control of requesting server), which "proves" that server is permitted to have such certificate.

This means the domain validation is possible only for domain names that are in the global DNS tree. You use a ".int" suffix which doesn't exists in the global DNS tree (or it exists, but your name doesn't exist or belong to you). It isn't what could be "domain validated" with ACME.

So you can't generate certificates with ACME for this name. Sorry.

Your options are:

instantiate your own "internal" CA, have its root certificates trusted on every involved machine and then generate certificates with it. This might be, for example, MS AD Certification Services. This will require some work for instantiation and support of the CA, but you'll be able to continue use ".int";
use a subdomain of globally registered domain, i.e. change your ".int" suffix into something like ".int.example.com", where example.com is your bought and delegated domain. Then you might, for example, to setup some reverse proxy and point all your "internal" names to the public address of that proxy in the global DNS, to be able to use ACME for your "internal" hosts.

After many years of network engineer experience I ended up with this second alternative. I never use "detached private internal" names like ".int", ".local", ".lan" etc. for internal services, even if I know I am not going to connect them with "outside world", even if they are physically disconnected from the Internet. I always use something that descend from my owned global domain names. This saved me much work. And when I sometimes meet a network where these "detached" names are used, almost always there are some dirty quirks to solve obscure problems, which weren't be needed if they were using global names.

int. exists in the global DNS. It is one of the original top level domains (also com, net, org, gov, mil, us). It is also the most difficult to actually register as you must be an organization defined in an international treaty (e.g. the [United Nations](https://www.un.int/)). I had an email in the .int domain back in the 1990s and I kind of miss having it. — Michael Hampton, Jul 08 '21 at 02:27
O.K., I've failed in that. However, the topic starter is certainly not eglible to have such a domain. This is just additional argument to not to invent domain names and always use only (subdomains of) properly registered and owned ones. — Nikita Kipriyanov, Jul 08 '21 at 06:39
The answer is still quite worthy so I did upvote it, but you might also want to edit the bits that suggest that int is not a valid domain name. — Michael Hampton, Jul 08 '21 at 14:32

check that a DNS record exists for this domain

1 Answers1