Вопросы Теги

Перенаправление облачного DNS не разрешается в других сетях общего VPC

Наша установка:

У нас есть главный проект A и два других проекта, B и C . В проекте A у нас есть общий VPC с сетями A , B и C (в зависимости от того, для какого проекта они предназначены служить). VPC для B совместно используется из проекта A в проект B , а VPC для C совместно используется из проекта A для проекта C . Сети связаны друг с другом.

В рамках проекта A у нас есть частная облачная зона DNS, которая пересылается на два DNS-сервера. Один из этих серверов находится в проекте A и сети A , а один из них находится в проекте B в сети B .Мы выбрали все сети ( A , B и C ) для включения в эту зону DNS.

Наша проблема:

Cloud DNS похоже, не распространяется должным образом в этих сетях. Экспериментируя, мы обнаружили, что экземпляры могут разрешать записи, которые находятся на DNS-сервере в той же сети, но не в другой сети. например:

Экземпляр в сети A сможет разрешить домен из сети A DNS-сервера, но не из сети B DNS-сервера , и наоборот. Однако, если вы явно определяете DNS-сервер, он работает должным образом.

Например, пусть 10.0.0.1 имеет запись A для foo.com и 10.0.1.1 имеет запись A для bar.com . Они размещены в сети A и сети B соответственно:

На экземпляре из сети A :

  • Выполняется nslookup foo.com разрешится.
  • Запуск nslookup bar.com приведет к вернуть СЕРВИС .
  • Запуск nslookup bar.com 10.0.1.1 разрешится.

Аналогично, использование экземпляра в сети B

  • Выполнение nslookup bar.com разрешит
  • Запуск nslookup foo.com вернет SERVFAIL
  • Запуск nslookup foo.com 10.0.0.1 разрешит

И сеть C :

  • Запуск nslookup foo.com вернет SERVFAIL
  • Запуск nslookup bar.com вернет SERVFAIL
  • Running nslookup foo.com 10.0.0.1 разрешит
  • Запуск nslookup bar.com 10.0.1.1 разрешит

Я не уверен, почему это поведение такое, как оно есть.

Что было опробовано / подтверждено

  • Мы убедились, что все сети могут обмениваться данными через TCP / UDP порт 53, и что оба сервера имен видны из всех сетей.
  • Мы попытались добавить политики (что дало аналогичный результат , только ошибки возвращали NXDOMAIN , а не SERVFAIL )
  • Мы изучили пиринг DNS, который здесь не применим

. Любая помощь здесь будет оценена. Мне известно, что частные зоны в Cloud DNS все еще являются бета-функцией, но эта настройка в настоящее время должна быть возможна согласно документации.

0
задан 16 April 2019 в 11:47
2 ответа

Судя по вашему описанию, сети A, B и C связаны друг с другом. В документации о пиринговых зонах говорится, что «когда две сети являются одноранговыми, они не передают автоматически информацию DNS». Это могло бы объяснить, почему DNS могут разрешать имена только экземплярам в одном VPC ehn с помощью пересылки Cloud DNS; и, с другой стороны, DNS должны быть напрямую запрошены для разрешения, когда они установлены в одноранговых VPC.

Я вижу там документацию по использованию пиринговых зон с перенаправлением DNS одновременно, так что вы можете захотеть чтобы попробовать, добавив оба домена foo.com и bar.com на оба DNS-сервера.

0
ответ дан 5 December 2019 в 03:27

На той же странице также объясняется, что существует бета-версия DNS Peering, посредством которой потребительская сеть может пересылать DNS-запросы в сеть-источник.

Если я правильно понимаю, это будет означают наличие настройки DNS в производственной сети A , и пусть сети B и C перенаправляют свои соответствующие запросы на A . 1231] Но что, если B и C имеют разные частные зоны (что не должно быть так далеко от реальных)? Означает ли это, что обе настройки будут установлены на A , чтобы записи для соответствующих VPC управлялись однозначно из проекта A .

Я бы тоже хотел попробовать, более того, потому что на Кроме того, у меня есть локальная сеть VPN (назовем ее D ), и следующим шагом будет установка сервера условной пересылки на локальную DNS.

Не уверен, что B и C смогут разрешать D запросы через проект A .

0
ответ дан 5 December 2019 в 03:27

Теги

Похожие вопросы