☰

このドメインの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を使用しています。グーグル、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をcurlすると

<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 ツリーにあるドメイン名に対してのみ可能です。グローバル DNS ツリーに存在しない (または、存在するが、あなたの名前が存在しないか、あなたのものではない) 「.int」サフィックスを使用しています。これは、ACME で「ドメイン検証」できるものではありません。

したがって、この名前に対して ACME で証明書を生成することはできません。申し訳ありません。

選択肢は次のとおりです:

  • 独自の「内部」CA をインスタンス化し、そのルート証明書をすべての関連マシンで信頼し、それを使用して証明書を生成します。これは、たとえば、MS AD 証明書サービスです。CA のインスタンス化とサポートには多少の作業が必要になりますが、「.int」を引き続き使用できます。
  • グローバルに登録されたドメインのサブドメインを使用します。つまり、「.int」サフィックスを「.int.example.com」などに変更します。ここで、example.com は購入して委任したドメインです。次に、たとえば、リバース プロキシを設定し、すべての「内部」名をグローバル DNS のそのプロキシのパブリック アドレスにポイントして、「内部」ホストに ACME を使用できるようにします。

長年のネットワーク エンジニアの経験を経て、私はこの 2 番目の選択肢に行き着きました。たとえインターネットから物理的に切り離されていても、それらを「外部の世界」に接続しないことがわかっていても、内部サービスには「.int」、「.local」、「.lan」などの「分離されたプライベート内部」名を決して使用しません。私は常に、所有するグローバル ドメイン名から派生したものを使用します。これにより、多くの作業が省けました。また、これらの「分離された」名前が使用されているネットワークに遭遇すると、ほとんどの場合、グローバル名を使用していた場合には必要のない、わかりにくい問題を解決するために、いくつかの厄介な工夫がされています。

関連情報