Есть ли способ изменить частный DNS сервера EC2?
Я хочу иметь возможность связываться между своими серверами с помощью чего-то вроде myserver.example.com, а не ip-1.1.1.1-uswest-aws-internal. Я новичок в роли системного администратора, а также в работе с сетями. Я попытался поиграть с наборами опций DHCP в VPC, но не смог заставить его работать.
Чтобы прояснить, чего я пытаюсь достичь ... Я настраиваю Jenkins, который будет запускать подчиненные устройства на многочисленных серверах. Я хотел иметь возможность использовать свои собственные назначенные адреса вместо произвольных, чтобы было понятнее, что это зависит от того, на какой машине выполняется задание.
Я также уверен, что это упростит и другие межсерверные коммуникации в будущем. Как я уже сказал, я плохо знаком с системным администратором, поэтому, если мне не хватает более простого метода, дайте мне знать.
Если вы хотите получить доступ к своим серверам по my-dns-name, вам необходимо настроить собственный DNS-сервер.
По умолчанию AWS VPC обрабатывает DHCP за вас и поставляется с DNS-сервером Amazon.
Вы можете прочитать о вариантах предоставления собственного DNS-сервера здесь: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html
Имя опции DHCP: серверы доменных имен
IP-адреса до четырех серверов доменных имен или AmazonProvidedDNS. Набор опций DHCP по умолчанию указывает AmazonProvidedDNS.
Имя опции DHCP: доменное имя
Если вы используете AmazonProvidedDNS в регионе Восток США (Северная Вирджиния), укажите compute-1.amazonaws.com. Если вы используете AmazonProvidedDNS в другом регионе, укажите region.compute.amazonaws.com. В противном случае укажите доменное имя (например, MyCompany.com).
Если вы хотите использовать для связи полное доменное имя (myserver.example.com), вы можете сделать это без собственного DNS-сервера, ваши домены уже общедоступны.
Вы можете общаться с IP-адресами, частными или общедоступными, вы можете изменять частные IP-адреса на уровне ОС, изменять имена хостов на уровне ОС и использовать / etc / hosts для создания своего рода бедного DNS.
Возможно, вы всегда захотите изучить ElasticIP, Elastic Network Interface и Elastic Load Balancers, которые работают в том же пространстве, что и ваш вопрос.
Все зависит от того, чего вы пытаетесь достичь и как вы хотите это сделать!
Вы не можете его изменить, если не развернете собственные серверы имен, но вы можете легко ссылка с другим именем, создав CNAME запись, которая даст желаемый эффект.
В зоне DNS "example.com", будь то на маршруте 53 или размещенном у другого поставщика услуг хостинга DNS, вы должны иметь возможность создавать CNAME записи:
myserver IN CNAME ip-1.1.1.1-uswest-aws-internal.
Когда машина пытается разрешить "myserver.example.com", DNS-серверы "example.com", по сути, сообщают ей, что вместо этого она должна искать "реальное" внутреннее имя хоста ("cанонический название"). Если компьютер находится внутри вашего развертывания EC2, он попросит преобразователь DNS EC2 найти это, а преобразователь EC2, в свою очередь, вернет внутренний IP-адрес ... что приведет к желаемому поведению - вы можете доступ к вашим внутренним машинам по желаемым именам хостов.
Если система за пределами вашего развертывания EC2 ищет это имя хоста, она завершится ошибкой, что является правильным поведением, поскольку машина недоступна извне (если у нее только частный IP-адрес).
И наоборот, если у вас есть машина с общедоступным IP-адресом и соответствующим общедоступным именем хоста, например ec2-x-x-x-x.us-west-2.compute.amazonaws.com используя это имя хоста как CNAME target будет делать то же самое. При запросе изнутри ваш При развертывании EC2 результатом будет внутренний IP-адрес с помощью некоторой магии DNS, которую EC2 делает прозрачно ... или извне он вернет внешний общедоступный IP-адрес.
https://stackoverflow.com/a/19148569/1695906
Уточнение:
Существует два типа поведения DNS-сервера: «авторитетные» серверы будут отвечать на запрос любого хоста о любой записи ресурса, для которой они являются полномочными ... и рекурсивные «преобразователи», которые запрашивают глобальный DNS от имени своих авторизованных клиентов. . DNS-сервер также может выполнять обе функции.
Ваши экземпляры EC2 (по умолчанию) используют серверы резолвера AWS для поиска любого имени хоста внутри и снаружи, к которому ваши экземпляры пытаются получить доступ, и возвращают IP-адрес ... но резолвер AWS также является авторитетным для ".internal" псевдо-домен, поэтому, когда экземпляры пытаются найти хосты ".internal", возвращается правильный внутренний IP-адрес.
Теперь предположим, что вы настроили внутренние имена хостов в качестве целей CNAME на внешних DNS-серверах «example.com», а затем попытались выполнить внутренний поиск «myserver.example.com» ... распознаватель AWS сверяется с глобальной иерархией DNS и в конечном итоге запрашивает один из официальных серверов имен для myserver.example.com. По сути, в ответе будет сказано: «Все, что я знаю, это то, что для поиска myserver.example.com вам нужно найти ip-1.1.1.1-uswest-aws-internal» ... резолвер AWS понимает, что ему не нужно обращаться к Внешний объект, чтобы ответить на этот новый вопрос, поскольку он является авторитетным для поддельного внутреннего домена, просто отвечает правильным ответом, который ему уже известен.
Внешнему "example.com" не нужно или пытаться проверять цель CNAME, поскольку это не его работа.
Теперь, если CNAME относится к внешнему имени хоста, процесс будет таким же, и результат будет таким же, потому что резолвер AWS (который обрабатывает все запросы DNS, сделанные вашими внутренними компьютерами) не пытается на самом деле найти истинный и правильный IP-адрес от DNS-серверов, которые являются полномочными для домена compute.amazonaws.com ... вместо этого он еще раз полагает, из-за его конструкции, что он уже знает IP-адрес вашего внешнего имени хоста ... но ответом снова будет ваш внутренний частный IP-адрес.
Резолвер AWS, о котором я говорю выше, представляет собой виртуальную сущность, которая только доступны для ваших экземпляров. Содержащаяся в нем информация о сопоставлении публичного имени хоста с частным IP-адресом доступна только вашим экземплярам, когда они запрашивают его. Это не доступно извне.
Если вы предоставите внутреннее имя хоста в качестве цели CNAME, внешние запросы получат «внутренний» ответ, что для них будет тупиком. Если вы предоставите внешние имена хостов в качестве цели CNAME, они получат общедоступный IP-адрес, потому что обнаружение CNAME направит их на общедоступные полномочные DNS-серверы, а не на частный внутренний преобразователь, к которому могут получить доступ только ваши экземпляры.
На самом деле все это очень просто на практике, хотя здесь не так просто объяснить, потому что сначала необходимо понять очень многие основы DNS ... но в конечном итоге это работает, потому что DNS-серверы "example.com" просто не работают. их не волнует, настроите ли вы для них CNAME, которую они понимают. Это не их проблема - понять это - бремя лежит на преобразователе, который ищет ответ, чтобы окончательно понять промежуточный ответ, появляющийся в CNAME.
У меня была точно такая же проблема. Хотя мои домены управляются за пределами Amazon, я использовал Amazon Route 53 для создания частного размещенного имени и добавил запись CNAME, указав ее на частное DNS-имя AWS экземпляра. Проблема заключалась в том, что, хотя это решило проблемы для поддоменов, это не сработало для корневого «example.com», поскольку это нарушает правила CNAME.
С тех пор я удалил запись CNAME и заменил ее двумя A-записями (example.com и * .example.com), указывающими на мой общедоступный IP-адрес. Я использовал общедоступный эластичный IP-адрес, так как в моем случае он всегда будет одинаковым, но ваша ситуация может отличаться. Вы должны иметь возможность использовать свой частный IP-адрес, но я не проверял это.
Я должен отметить, что мои серверы были на базе Windows, хотя это не должно иметь значения. Я обнаружил, что использование NSLOOKUP example.com в командной строке полезно для отслеживания изменений, как это предлагается в других сообщениях здесь. Я также считал жизненно важным, чтобы любые вносимые вами изменения имели очень низкое значение TTL, чтобы изменения применялись как можно быстрее ... Наименьшая предустановка Amazon Route 53 - 60 секунд, но может быть и ниже. Я уверен, что установка А-рекорда была одной из первых вещей, которые я пробовал, но он не получил немедленного распространения, поэтому я часами ходил по тупикам.
Вы можете легко добиться этого с помощью частной зоны хостинга на маршруте 53. http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html