☰

comprobar que existe un registro DNS para este dominio

tag-icon • tag-icon nginx cert-manager
comprobar que existe un registro DNS para este dominio

Tengo el siguiente archivo de manifiesto de ingreso:

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

Estoy trabajando con VMware con Vsphere. No tengo un dominio comowww.google.com, solo un nombre DNS que es k8s-cluster y el dominio .int (dentro de mi empresa). Cuando intento generar el certificado recibo este 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"

¿Puede aparecer este problema porque k8s-cluster.int está dentro de una intranet? Si hago 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>

Entonces creo que el DNS funciona.

Respuesta1

Intentaste usar ACME, es lo que usa Let's Encrypt. El protocolo ACME es básicamente una validación de dominio DNS automatizada y le proporciona certificados de "dominio validado". Comprueba si los registros DNS con nombres solicitados realmente apuntan al servidor solicitante (o están bajo el control del servidor solicitante), lo que "prueba" que el servidor tiene permiso para tener dicho certificado.

Esto significa que la validación del dominio sólo es posible para los nombres de dominio que se encuentran en el árbol DNS global. Utiliza un sufijo ".int" que no existe en el árbol DNS global (o existe, pero su nombre no existe ni le pertenece). No es lo que podría "validarse de dominio" con ACME.

Por lo tanto, no puede generar certificados con ACME para este nombre. Lo siento.

Tus opciones son:

  • cree una instancia de su propia CA "interna", haga que sus certificados raíz sean confiables en cada máquina involucrada y luego genere certificados con ella. Esto podría ser, por ejemplo, Servicios de certificación de MS AD. Esto requerirá algo de trabajo para la creación de instancias y el soporte de la CA, pero podrá seguir usando ".int";
  • utilice un subdominio de dominio registrado globalmente, es decir, cambie su sufijo ".int" por algo como ".int.example.com", donde ejemplo.com es su dominio comprado y delegado. Luego, podría, por ejemplo, configurar algún proxy inverso y señalar todos sus nombres "internos" a la dirección pública de ese proxy en el DNS global, para poder usar ACME para sus hosts "internos".

Después de muchos años de experiencia como ingeniero de redes, terminé con esta segunda alternativa. Nunca uso nombres "internos privados separados" como ".int", ".local", ".lan", etc. para servicios internos, incluso si sé que no los voy a conectar con el "mundo exterior", incluso si están físicamente desconectados de Internet. Siempre uso algo que desciende de los nombres de dominio globales de mi propiedad. Esto me ahorró mucho trabajo. Y cuando a veces me encuentro con una red donde se usan estos nombres "separados", casi siempre hay algunas peculiaridades sucias para resolver problemas oscuros, que no serían necesarios si estuvieran usando nombres globales.

información relacionada