☰

проверьте, существует ли запись DNS для этого домена

tag-icon • tag-icon nginx cert-manager
проверьте, существует ли запись DNS для этого домена

У меня есть следующий файл манифеста Ingress:

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

Я работаю с VMware с Vsphere. У меня нет домена типаwww.google.com, просто DNS-имя k8s-cluster и домен .int (внутри моей компании). Когда я пытаюсь сгенерировать сертификат, я получаю эту ошибку: "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"

Может ли эта проблема возникнуть из-за того, что k8s-cluster.int находится внутри интрасети? Если я завью 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>

Итак, я думаю, что DNS работает.

решение1

Вы пытались использовать ACME, это то, что использует Let's Encrypt. Протокол ACME по сути является автоматизированной проверкой домена DNS и выдает вам сертификаты "проверенного домена". Он проверяет, действительно ли записи DNS с запрошенными именами указывают на запрашивающий сервер (или находятся под контролем запрашивающего сервера), что "доказывает", что серверу разрешено иметь такой сертификат.

Это означает, что проверка домена возможна только для доменных имен, которые находятся в глобальном дереве DNS. Вы используете суффикс ".int", которого нет в глобальном дереве DNS (или он есть, но ваше имя не существует или принадлежит вам). Это не то, что можно было бы "проверить доменом" с помощью ACME.

Поэтому вы не можете сгенерировать сертификаты с ACME для этого имени. Извините.

Ваши варианты:

  • создайте свой собственный "внутренний" CA, сделайте его корневые сертификаты доверенными на каждой задействованной машине, а затем сгенерируйте сертификаты с его помощью. Это может быть, например, MS AD Certification Services. Это потребует некоторой работы по созданию и поддержке CA, но вы сможете продолжать использовать ".int";
  • используйте поддомен глобально зарегистрированного домена, т. е. измените свой суффикс ".int" на что-то вроде ".int.example.com", где example.com — ваш купленный и делегированный домен. Затем вы можете, например, настроить обратный прокси-сервер и указать все ваши "внутренние" имена на публичный адрес этого прокси-сервера в глобальном DNS, чтобы иметь возможность использовать ACME для ваших "внутренних" хостов.

После многих лет опыта работы сетевым инженером я остановился на втором варианте. Я никогда не использую «отдельные частные внутренние» имена, такие как «.int», «.local», «.lan» и т. д. для внутренних служб, даже если я знаю, что не собираюсь подключать их к «внешнему миру», даже если они физически отключены от Интернета. Я всегда использую что-то, что происходит от моих собственных глобальных доменных имен. Это сэкономило мне много работы. И когда я иногда встречаю сеть, где используются эти «отдельные» имена, почти всегда есть какие-то грязные причуды для решения неясных проблем, которые были бы не нужны, если бы они использовали глобальные имена.

Связанный контент