Cognito自己的域名需要A记录答案

【问题标题】：Cognito own domain name required A RecordCognito自己的域名需要A记录
【发布时间】：2018-12-17 09:01:21
【问题描述】：

我正在尝试将自己的域名分配给 Cognito 的用户池，并面临一个问题，即似乎需要 A 记录。

就我而言，我已经在我的互联网域上注册了通配符，并尝试按照https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-add-custom-domain.html中提到的步骤进行操作

现在我可以创建一个 A 记录，但不知道该 A 记录应该指向哪里。欢迎任何提示或提示:) 如果可以在不使用 CloudFront 的情况下完成此操作，那就太好了。

我尝试了 CNAME 等，但如前所述，需要 A 记录。

【问题讨论】：

我遇到了同样的问题。我添加了一条记录以指向任何自定义 IP 地址，它现在可以工作了。

标签： amazon-web-services amazon-cognito aws-cognito

【解决方案1】：

与此处相关的不是域 root。它是位于低于您输入的级别的子域。

如果输入auth.example.com，则需要A记录 example.com
如果输入auth.qa.example.com，则需要A记录为qa.example.com
如果你输入foo.bar.qa.example.com你需要 bar.qa.example.com 的 A 记录

【讨论】：

这里的相关关注点是，如果您没有站点（例如.com），但您确实想使用 auth.example.com 作为 auth 域，那么该怎么做您将您的 example.com A-Record 指向？
@StevenEvers 遇到了这个问题，但幸运的是我能够将我的根指向一个随机的 A 记录。不知道为什么会这样。所以我有 dev.example.com 并且需要 auth.dev.example.com，我必须将 dev.example.com 指向某个地方。所以我只是将它指向与 example.com 相同的记录。

【解决方案2】：

您拥有的网络域。它的根必须在 DNS 中有一个有效的 A 记录。

简而言之，如果您的域是example.com，那么在您继续之前，需要为网站实际配置根目录 -- example.com。 A 记录的具体值与 Cognito 无关，因为这取决于您选择如何设置站点...但 Cognito 要求它存在。

【讨论】：

为什么有这个要求？我的网站位于www.mydomain.com，所以这很尴尬。为什么不让人们在根目录下没有网站的情况下设置自定义域？
@MattGibson 没有人说你需要一个根目录有内容的网站。当您在没有www 的情况下访问您的域时会发生什么？如果它是明智的，它应该在这种情况下工作。
嗯，我目前正在设置从 mydomain.com 到 www.mydomain.com 的重定向，所以希望这会奏效。但是，我仍然不明白使其成为特别是根域的要求背后的逻辑。我过去已经设置了 Auth0，没有必要这样做。如果它不用于任何用途，他们为什么需要它？
它被用于某事——某种验证——不清楚究竟是什么，但大概有一些内部过程需要看到这一点，或者他们正在防范某种潜在的当域配置不是通用配置时可能存在的域劫持向量。
啊，这很有道理。

【解决方案3】：

似乎尝试使用带有太多点的子域会导致此错误。

这行得通：

auth.example.com

这不是：

dev.auth.example.com

此外，如果您删除并重新添加相同的域名，这似乎会导致错误。更改为不同的域有效。

我向#awswishlist https://awswishlist.com/ 添加了修复此问题的请求

【讨论】：

嘿，有趣的是，这正是我试图使用的子域。 :)
我把这个翻了。我有 dev.example.com，*.dev.example.com 下的所有内容都是 *.example.com 的复制。所有开发记录都在另一个帐户的自己的托管区域中

【解决方案4】：

为了处理子域，我创建了一个 IP 为 127.0.0.1 的记录，它正在工作。

我想在 cognito 中添加 auth.dev.${domain_name}.com 作为自定义域，但我没有指向 dev.${domain_name}.com 的任何网站，因此为 dev.${domain_name}.com 创建了一条记录并指向 127.0.0.1 ip地址。

Reference

【讨论】：

我自己的答案的绝佳灵感。

【解决方案5】：

流行的答案正确地回答了问题。但在更高的层次上还有更多的东西。配置依赖中有一个循环：

Cognito 需要 auth.example.com A 记录，它需要 example.com A 记录。 example.com A 记录需要网站指向，而网站需要 Cognito。

要打破这个循环，

创建一个新的 Route 53 区域 auth.example.com 供 Cognito 独立于网站的 example.com 区域使用。这打破了依赖循环。
创建一个auth.example.com 一条指向占位符IP 地址的记录，例如127.0.0.1。这永远不会被实际使用。
现在您可以为每个环境的 Cognito 自定义域创建一条 A 记录，例如 dev.auth.example.com、stage.auth.example.com 或 prod.auth.example.com。

以下 Terraform 示例将所有这些放在一起，创建了一个 Cognito 自定义域名prod.auth.example.com:

# Pre-existing hosted zone created by Route53 Registrar
data "aws_route53_zone" "main" {
  name = "example.com"
}

# Create a new Route 53 zone auth.example.com
#
# Actually, Route 53 zone creation belongs in a separate Terraform
# module where it can be shared by multiple environments.

resource "aws_route53_zone" "auth" {
  name = "auth.example.com"
}

resource "aws_route53_record" "auth-ns" {
  zone_id = data.aws_route53_zone.main.zone_id
  name    = "auth.example.com"
  type    = "NS"
  ttl     = "30"
  records = aws_route53_zone.auth.name_servers
} As it is now,
# `terraform destroy` will destroy zone auth.example.com, leaving the other environments in the lurch.

# Only the name servers in the auth.example.com zone NS record know where
# to find auth.example.com. Add NS record in example.com pointing to the
# auth.example.com zone name servers. Now auth.example.com can
# be found through example.com.
resource "aws_route53_record" "auth-a" {
  zone_id = aws_route53_zone.auth.zone_id
  name    = "auth.example.com"
  type    = "A"
  ttl     = 300
  records = ["127.0.0.1"]  # Placeholder that is never used
}

# Route 53 zone auth.example.com setup done

module "acm" {
  source = "terraform-aws-modules/acm/aws"

  domain_name               = "prod.auth.example.com"
  zone_id                   = aws_route53_zone.auth.zone_id
  subject_alternative_names = []
  wait_for_validation       = true
}

resource "aws_cognito_user_pool" "this" {
  name = "prod-cognito"
}

resource "aws_cognito_user_pool_domain" "this" {
  depends_on      = [aws_route53_record.auth-a]
  domain          = "prod.auth.example.com"
  certificate_arn = module.acm.this_acm_certificate_arn
  user_pool_id    = aws_cognito_user_pool.this.id
}

resource "aws_route53_record" "subdomain-a" {
  zone_id = aws_route53_zone.auth.zone_id
  name    = "prod.auth.example.com"
  type    = "A"
  alias {
    evaluate_target_health = false
    name                   = aws_cognito_user_pool_domain.this.cloudfront_distribution_arn
    # Every CloudFront distribution's zone ID is Z2FDTNDATAQYW2
    zone_id = "Z2FDTNDATAQYW2"
  }
}

还有一些工作要做：您还需要使用aws_cognito_user_pool_client 创建应用程序客户端。我忽略了这一点，因为应用程序客户端与自定义域无关。

更新：我发现我可以更好地隔离通过为每个环境创建一个托管区域来创建环境，例如 dev-auth.example.com、stage-auth.example.com 和 auth.example.com。无需为更多的子域而烦恼在这些下面。

【讨论】：

【解决方案6】：

我正在使用

authdev.mycompany.com

并且必须在根域中创建一个 A 记录（使用弹性 ip）

mycompany.com.

【讨论】：

【解决方案7】：

我了解到您正在使用 Cognito 托管 UI 进行身份验证，并且您需要一个自定义域。

当您为 cognito 创建自定义域时，它将返回 Alias 目标（指向云端分发）。

然后根据您使用的是 Route53 还是 DNS 配置采取以下步骤：

DNS 配置

让您的 DNS 服务提供商将上一步中的别名目标添加为您的用户池自定义域的别名。
您的 DNS 提供商还需要为您的自定义域设置子域。

Route53

登录到 Route 53 控制台。系统可能会提示您输入 AWS 凭证。
如果您在 Route 53 中没有托管区域，请设置一个。否则，请跳过此步骤。
- 一个。选择创建托管区域。
- 乙。从域名列表中选择您的自定义域。
- c。对于 Comment，键入有关托管区域的可选评论。
- d.选择创建。
在托管区域页面上，选择您的托管区域的名称。
选择创建记录集。
为别名选项选择是。
在 Alias Target 中键入您在上一步中记下的别名目标名称。
选择创建。
使用别名目标在 Route 53 中添加子域。
- 一个。在托管区域页面上，选择您的托管区域的名称。
- 乙。选择创建记录集并输入以下值：
  - i.对于名称，键入您的首选子域名。例如，如果您尝试创建的子域是 auth.example.com，请输入 auth。
  - 二。对于类型，选择 A - IPv4 地址。
  - 三。为别名选项选择是。
  - 四。在 Alias Target 中键入您在上一步中记下的别名目标名称。
- c。选择创建。

参考：https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-add-custom-domain.html

【讨论】：