Обзор Google Cloud DNS

Недавно была новость про google dns.


И как было обещано — пишу обзор.
В рамках сервиса https://cloud.google.com
https://developers.google.com/cloud-dns/

Регистрируемся и создаем новый проект. Придумываем ему какое-ниб название.
https://console.developers.google.com/project

Заполняем биллинг для этого проекта конечно, там данные вашей карты.

Потом переходим в вкладку API и выбираем нужные сервисы.

Нас интересует именно DNS

Далее создаем Google Cloud SDK
https://developers.google.com/cloud/sdk/
После установки Cloud SDK, убедитесь, что она включает в себя необходимый компонент DNS.

$ gcloud components list

Если его нет, устанавливаем

$ gcloud components update dns

Далее разрешаем доступ к API с нашего гугл админ аккаунта

$ gcloud auth login

Проверяем все ли в порядке

$ gcloud auth list

Переходим к созданию управляемой DNS зоны.
С помощью SDK и аккаунта с доступом, мы сейчас уже можем управлять зоной.
Попробуем создать зону для конкретного домена

$ gcloud dns managed-zone create —description=»hostsuki.info zone» —dns_name=»hostsuki.info.» hostsukiinfo

Получится вот так

Creating {‘dnsName’: ‘hostsuki.info.’, ‘name’: ‘hostsukiinfo’,
‘description’: ‘hostsuki.info zone’} in learned-mind-567

Do you want to continue (Y/n)? y

{
«creationTime»: «2014-05-01T13:25:51.959Z»,
«description»: «hostsuki.info zone»,
«dnsName»: «hostsuki.info.»,
«id»: «6484789670514247209»,
«kind»: «dns#managedZone»,
«name»: «hostsukiinfo»,
«nameServers»: [
«ns-cloud-c1.googledomains.com.»,
«ns-cloud-c2.googledomains.com.»,
«ns-cloud-c3.googledomains.com.»,
«ns-cloud-c4.googledomains.com.»
]
}

Как же теперь изменить уже существующую зону ?
Давайте посмотрим, что google добавил для нас по умолчанию

$ gcloud dns records —zone=hostsukiinfo list

Видим

[
{
«kind»: «dns#resourceRecordSet»,
«name»: «hostsuki.info.»,
«rrdatas»: [
«ns-cloud-c1.googledomains.com.»,
«ns-cloud-c2.googledomains.com.»,
«ns-cloud-c3.googledomains.com.»,
«ns-cloud-c4.googledomains.com.»
],
«ttl»: 21600,
«type»: «NS»
},
{
«kind»: «dns#resourceRecordSet»,
«name»: «hostsuki.info.»,
«rrdatas»: [
«ns-cloud-c1.googledomains.com. dns-admin.google.com. 0 21600 3600 1209600 300»
],
«ttl»: 21600,
«type»: «SOA»
}
]

NS записи
ns-cloud-c1.googledomains.com
ns-cloud-c2.googledomains.com
ns-cloud-c3.googledomains.com
ns-cloud-c4.googledomains.com

И домен googledomains.com 🙂 В связи с новыми доменными зонами и что google тоже может продавать теперь домены. Думаю он будет использован в будущем под сервис продаж доменов 🙂

Описывать типы записей и SOA настройки я не буду, все есть.

Давайте отредактируем нашу

$ gcloud dns records —zone=hostsukiinfo edit

Прописываем для нашего домена нужную SOA

{
«additions»: [
{
«kind»: «dns#resourceRecordSet»,
«name»: «hostsuki.info.»,
«rrdatas»: [
«ns-cloud-c1.googledomains.com. koko@hekmatyar.ru. 2014050101 21600 3600 1209600 300»
],
«ttl»: 21600,
«type»: «SOA»
}
],
«deletions»: [
{
«kind»: «dns#resourceRecordSet»,
«name»: «hostsuki.info.»,
«rrdatas»: [
«ns-cloud-c1.googledomains.com. koko@hekmatyar.ru. 0 21600 3600 1209600 300»
],
«ttl»: 21600,
«type»: «SOA»
}
]
}

Можно так же создавать пакетами
https://developers.google.com/cloud-dns/what-is-cloud-dns#supported_record_types

Другие полезные Google Cloud DNS команды
Чтобы получить список всех ваших зон DNS в рамках проекта:

$ gcloud dns managed-zone list

Чтобы удалить зону из проекта:

$ gcloud dns managed-zone delete «zonename»

Чтобы получить список записей из определенной зоны:

$ gcloud dns records —zone=»zonename» list

Обзор сделан alice2k в мае 2014 года, с некоторыми советами из зарубежного блога. Полноценной статьи как поднять непотопляемый dns хостинг — пока что нет.

Как подключить CloudFlare?

Недавно понял, что у меня нету банальной статьи  — как настроить DNS зону.
Все таки в мире до сих пор полно людей, хоть и 2013 год, которые не разу не пользовались dns хостингом. Они не понимают различия между доменом и хостингом даже.

Итак.
Идем на сервис, регистрируемся.
Там нам необходимо заполнить рабочий email, ник для сообщества, и придумать сложный пароль.

Читать далее

Архитектура dns зоны

Давно не писал статей никаких. Решил поделиться опытом.
Методом разных проб и ошибок я пришел к выводу, что такая архитектура наилучший вариант.

Представим, что мы создаем хостинг.

Сначала мы придумываем бренд, описано в старых статьях раз, два.

Далее покупаем домены. Две штуки разных обязательно, а желательно 4. И желательно у четырех разных регистраторов, 4 разных учетных записи. И все 4 домена — 4 разных dns сервиса используют.

Если у нас случатся какие-то проблемы с доменами — 4шт отобрать, залочить, положить — довольно трудно.
Далее мы создаем поддомены с этих наших доменов.

Например начнем с ключевой отрасли — dns.
Создаем по ключевому поддомену с каждого нашего домена.
dns.default.ru dns.default.com dns.default.net dns.dedault.org

Направляем эти поддомены, через тип записи NS — еще на разные dns хостинги. Опять 4 разных учетки, 4 разных локации, 4 разных списка зоны. Это основа.

И уже там мы будем создавать поддомены *.dns.default.ru и направлять на наши сервера, ноды и прочее. Например *.noda1.dns.default.ru — чтобы клиентам уже было готово для использования самопальных, зависимых от их vds NS.

Если вы будете делать свой dns хостинг.
То как вы поняли, нужно 4 сервера надежных. И короче создавайте на своих dns серверах — аккаунты реселлеров!
И уже на каждый сервер или vds-ки с нод садите аккаунты реселлеров. Если вдруг проебется один из мусорных ресурсов, вредителям утечет только 1 аккаунт реселлера dns, только конкретный утекший сервер, а не весь доступ до всех dns серверов.
Точно так же можно придумать им имена архитектуры.

На счет технических доменов, для раздач кстати.
Как я уже говорил — исходные домены лучше не раздавать. Лучше зарегистрировать отдельный. Например defaultusers defaultfree какой-ниб, где default это наш придуманный бренд.

Разумеется его регать еще в отдельном аккаунте регистратора доменов. Садить на надежные dns, можно на свои 4шт например засадить, если у вас есть свой надежный dns хостинг. И вот с него начинаем раздавать поддомены.
*.s1.defaultfree.com
*.s2.defaultfree.com

и т.д. создаем записи на все наши сервера. И при заказе хостинга, настраиваем, чтобы на server1 — им присваивался username.s1.defaultfree.com какой-ниб. И сразу автоматически работало создание технического поддомена для пользователя.

Далее, какие еще ключевые поддомены можно создать, кроме dns? Нааример
backup.default.org
mysql.default.org

Так же направить эти поддомены, через «тип записи NS» на отдельные места, отдельные аккаунты. И уже поддомены *.mysql.default.org на разные сервера под sql, создавать там.

Плюс редиректы. Посмотрите все популярные поддомены у других хостеров. Входы в биллинги, входы на сервера. И налепите десятки редиректов. Если люди по ошибке, по памяти будут набирать другой поддомен схожий по смыслу — отредиректяся на ваш, который решили использовать непосредственно вы.

Зачем это нужно? Уменьшение dns зоны, была уже статья такая. Плюс если когда-ниб придется менять и переносить все это, то времени потратится очень мало, перенос корневого домена будет происходить очень быстро.

Еще можно сделать кучу партнерских аккаунтов доменов.
*.domains.default.org
И предоставить выбор клиентам где регистрировать домены. По честному описать что это партнерские аккаунты у тех, тех, тех регистраторов. Чем больше выбора, тем удобнее людям.

Можно сделать *.storage.default.org
Где получится, что *.amazon.storage.default.org или selectel.storage.default.org или clodo.storage.default.org или google.storage.default.org
И еще можно так: *.cdn.storage.default.org и повторить те стораджи, которые поддерживают cdn.

Разумеется в https сертификат тоже прописать всю эту архитектуру.

Так же можно сделать еще по поддомену на разные сервисы, типо тумблера или блоггера. Если вдруг все таки вся dns зона не будет работать, то напишите там в своих блогах о технических работах и состоянии.

плюс важно понимать, что домены — это ничто.
база клиентов — это все.
заобузили домены? локнули? купили новые, через сутки сделали рассылку — все дела.

Как-то один человек сказал, после истории с простоплеером.
«мда, из этого всего можно сделать выводы»

  • регнул домен на «левые» данные, будет готов с ними расстаться
  • береги whois с детства (так как пробить можно не только .ru, а скоро вообще будет единая база с разными уровнями доступа)
  • не орать на всех углах что ты сделал и как тебя звать

Статья написана alice2k в июле 2013 года, надеюсь многие будут делать себе так и не повторять ошибок прошлого.

DNS зона и кол-во записей

Есть у меня несколько доменов, где DNS зона разраслась настолько, что даже сервис pdd.yandex.ru уже начинает лагать. Там уже около 1000 записей. Поддомены всякие на разных ip, редиректы для быстрых ссылок, которые помнишь на память, на каждый сервер по своему самопальному поддомену для ns, всякие storage, ключи dkim, записи txt, cname, тестовые всякие поддомены, для мониторинга, статистики на каждый хостинг/сервер что я покупаю или юзаю и прочая поебень.

Почему pdd.yandex.ru ? Потому что своего dns хостинга у меня к сожалению нету. А поднимать его — мне лень, не охота выкидывать кучу денег(дешевый вариант будет УГ же) и не охота тратить время, чтобы следить за ним.
Поэтому я пользуюсь для хороших доменов, для хороших проектов стоящих сторонними dns хостингами. А мусор можно и на самопал какой-ниб садить.

Так вот. Я пришел к выводу.
Что идеально делать вот как.
Делать ключевые поддомены, и направлять их на NS записи.
Например hosting.domain.ru — все что связано с хостинг отраслью
hosting NS dns1.yandex.net
hosting NS dns2.yandex.net
и т.д.
т.е. придумать 5-10 ключевых поддоменов и направить их на 5-10 разных аккаунтов того же яндекса, клоудфларе, херокса, амазона, можно даже чужих хостеров где защита от ддоса имеется и так далее.
Так что продумывайте архитектуру не только для ssl сертификатов, и не только разные поддомены на разные сервера, а еще и dns чтобы были разные, отдельные.

Тем самым сама dns зона домена domain.ru — будет маленькая, а не 1000 записей, которые переносить и восстанавливать можно пол дня.
С недавних пор стал так делать — очень удобно.
И кстати получается, что даже выведя ключевой домен из строя, его dns. Такая система все равно проживет на автомате(кеш dns) довольно долго 😉 Проверено.

Совет написал alice2k в апреле 2013. Может кто-ниб скажет или посоветует еще что-ниб ?

Где можно купить вторичные NS ?

Что такое вторичный NS ?
Это когда у тебя нету DNS managerа, тебе лень его закупать или поддерживать. Ведь если ты установишь его на говно vds, то его легко заддосят и все дела.
Хотя конечно, купив панель DNS manager вы не будете ограничены кол-вом ip, сможете делать реселлеров и кучу кучу брендов/доменов короче. Но и поддерживать это нужно тоже. Например чтобы сделать качественно, нужно 4 DNS manager купить, 4 мощных сервера в 4 разных странах и ДЦ. На каждый сервер еще нужно много ip купить, чтобы каждому бренду выделять по ip или если вы реселлить собираетесь. Так что иногда это нахуй не нужно 😉
Иногда проще просто купить у любой сторонней фирме, которая уже создала dns систему.

Меня часто об этом спрашивают. Решил написать faq.
Если вы так хотите крепить свои домены, через свои брендовые ns. Например ns1.моя-супер-фирма.ру ns2.моя-супер-фирма.ру ns3.моя-супер-фирма.ру ns4.моя-супер-фирма.ру
То вам нужно просто купить NS2 NS3 NS4, в трех разных странах, у 3х разных контор.
А сайты ваши будут через ns1. Этот ns1 может быть разный. Например если у вас всего 1 сервер или vds, с всего 1 ip — это и есть ваш ns1.

Итак. Идем например к tel.ru, закупаем там вторичный NS. NS2, в Москве.



Потом добавляем туда наши домены. ISP manager панель вообще умеет все это автоматически делать.
Если у вас много серверов. И домены на разных серверах. То ставим этот наш ip с того сервера, с которого нужно.

Потом так же идем покупать NS3 и NS4. Например NS3 можно купить у ISPserver в Бельгии. А NS4 можно купить у mgnhost в Германии.
И так везде короче на NS2 NS3 NS4 дублируем.
Все. Получаем надежный NS сервис, на своем домене 😉

Статья написана alice2k, октябрь 2012, сейчас он еще не придумал лучше решения с вторичными NS.

Обзор сервиса cloudflare.com

обзор сервиса cloudflare

1. Регистрируемся на бесплатном сервисе https://www.cloudflare.com/sign-up

2. Добавляем наш домен в список https://www.cloudflare.com/my-websites.html

3. Проверяем dns записи, если какие-то не определились, дописываем. Потом выбираем Security — High, если нужна защита от досов, если нет, то можно оставить по-умолчанию. Пользуемся 😉

Внизу есть возможность выбрать русский язык, правда он не всегда правильный, местами корявый. Но кому это нужно, делайте. Почитайте еще обязательно faq, про плагин для wordpress и про настройку nginx, которые нужны для того, чтобы ip посетителей определялись нормально. Кстати, для особо абузных проектов, это даже плюс, в логах не будет не одного нормального ip, если изъятие.

Этот сервис спасет вас от школо-досов и левых абуз, плюс сэкономит вам трафик. На платных аккаунтов, еще вас ожидают куча сервисов. Это будет позже.