Home / server / Questions / 1048678
In Process
DobreMihaela
Asked: 2021-01-06 07:51:11 +0800 CST

check that a DNS record exists for this domain

  • 772

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.

nginx cert-manager

1 Answers

  1. 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.

    • 2