Pull to refresh

Comments 36

В избраное!
Кидать «сисадминам» которые не понимают что такое CNAME и куда его прописать, а от MX вообще впадают в ступор, но на ссылку на вики почему-то обежаются.

Увы, но мне лично несколько раз выпадала честь проводить ликбез на пальцах, по телефону, сисадминам достаточно крупных региональных организаций. (Часто они не в курсе как работает то что настроил их предшественник)


А так же видеть некоторых дипломированных(в отличии от меня) сетевых администраторов, с большим самомнением, но имеющих проблемы даже с настройкой статической маршрутизации...


P.S.: Сам я сисадмин веб-студии, и общаюсь обычно по выкладке сайтов и о том что бы при это не отвалилась почта и прочие.

Я думаю что, некоторые в силу другой специфики, а админят по совместительству, тут и постыдного ничего нет. Некоторые по блату или красивым дипломам...


Судя по профилю вы старше меня и сами думаю, видели достаточно кадров...


Впрочем и сам я человек без образования, с весьма странным набором навыков, скорее дилетанта широкого профиля чем профессионала. Работаю сисадмином, dev-ops'ом, программером, по чуть чуть...

URL Redirect — это не совсем DNS, это хак с отдельным сервером.
Лучше поднять у себя сервер, слушающий домен с www на 80 и 443 портах, и переадресовывающий 301 редиректом

Пример для nginx
# http -> https
server {
	server_name		example.org;
	listen			80;
	return 301 https://example.org$request_uri;
}
# www -> non-www
server {
	server_name     www.example.org;
	listen		80;
	listen      	443 ssl;
	
	ssl_certificate      		/etc/ssl/example.org.crt;
	ssl_certificate_key  		/etc/ssl/example.org.key;
	
	return 301 https://example.org$request_uri;
}
# main
server {
	server_name	example.org;
	listen      	443 ssl http2;
.....
}

Да, тут автор просто описывает типичный сценарий конкретно из Namecheap образца 2013 года :)
Или можно воспользоваться публичным сервисом редиректа, прописав 174.129.25.170 (http://wwwizer.com/naked-domain-redirect).
Удобно в случае если домен привязывается к Гугл Сайтам или Гугл Блогам, где привязать можно только поддомен.
Про CNAME более правильным примером были бы записи NS, без которых не может быть зона (домен второго уровня например). MX-то чёрт с ними.
Поэтому нельзя делать CNAME на корневом домене вроде petekeen.net, потому что обычно там нужны другие записи, например, MX.

Для этого продвинутые ДНС-хостеры (например zilore.com dnsimple.com) придумали ALIAS записи, которые позволяют добавить CNAME запись в корневой домен, а внутри она будет автоматически преобразована в А запись и поддерживаться в актуальном состоянии.
есть у меня один домен, лежит в Яндекс.ПДД, однажды. еще не зная, что CNAME для самого домена прописывать нельзя, я взял и прописал, и оно почему-то сохранилось, и работает до сих пор как-то :) не знаю, может потому, что домен в .net.ru., и система восприняла его как поддомен.
позже, с другим домен хотел сделать тоже самое, а интерфейс Яндекса уже ошибку выдаёт. писал тогда по этому поводу в техподдержку, и тогда-то мне и сказали, что нельзя
Оно в среднем работать-то будет. Но шаг вправо-влево и результат непредсказуем.
тоже так подумал, поэтому больше эту запись не трогаю, наверняка сохранить уже не даст
>> Заметьте, что MX-запись указывает на домен, а не на IP-адрес.
может на хост?
Да, вы правы. Я изменил на «имя», так ближе к оригиналу и тоже правильно :)
Статья, вроде, для начинающих. Все подробно разжевывается, при этом автор вдруг вводит термины «A-запись» и «NS-сервер» и начинает на их основе что-то объяснять. В итоге все остальное для новичка выглядит полной белибердой. Ибо что это за А-запись и где B,C,D...Z-записи и зачем нужен NS сервер если уже есть DNS сервер — так и остается для читателя тайной. Гугл, конечно, никто не отменял, но очень велика вероятность, что по запросу этих терминов он выведет на более последовательные статьи для начинающих.
Новичкам лучше рассказать про hosts файл, чтобы они не покупали себе домены, а поднимали веб сервер локально, через hosts делали виртуальные домены и там игрались.

Если же новички захотят поднять свой DNS сервер, могут попасть под уязвимость, когда можно послать небольшой запрос, а ответ на него будет уходить целевой жертве, причем весьма большим.
Таким образом, без всяких вирусов, без установки ботнета, просто получив список открытых (неправильно настроенных DNS серверов), можно через них быстро организовать кому-нибудь ddos.
DDOS — это, конечно, круто. Но я вот хотел уже разобраться с DNS, но на фразе
Причина в том, что DNS производит замену таким образом, что все записи того места, куда указывает CNAME, также валидны для CNAME. В нашем примере, записи у www.petekeen.net и web01.bugsplat.info будут совпадать.
Мой мозг завернулся в CNAME и перестал отвечать. Серьезно, я вообще не понял, о чем речь. И ведь все статьи такие: получаем адрес по имени, корневые сервера, иерахия, все понятно вроде, и тут херак, и MX запись на AAAA реестр
O_o

поддержал бы автора комментария, вроде немного знаю базы, но прочёл статью - и мало что прояснилось

CNAME - это тип доменного имени, так? А доменное имя - это "элиас" для ключа, он же IP-адрес - так?
Получается, cname - элиас для доменного имени? Элиас для элиаса?

"Каноническое имя связывает одно имя с другим" - одно доменное имя с другим? Каким образом и что это даёт?
Вот в примере выше было видно, что www.petekeen.net. - это cname для web01.bugsplat.info., a web01.bugsplat.info. - это, по факту, имя для А (он же ip-адрес), он же 192.241.250.244. Получается, что cname - элиас второго порядка для ip-aдреса?
И для чего такое можно применить?


Вот у нас еcть ip-адрес с доменным именем, который одновременно и узел, и хост - для чего ему можно применить cname?
Или опять же, есть доменное имя, к которому привязан ip-адрес, который является входящим для виртуальной сети с виртуальными хостами, которые имеют общий ip-адрес, но у каждого своё доменное имя - для них можно как-то применить cname?
Можно ли cname применить для "неявного" редиректа, аналога http 301 или чем может быть полезна эта сущность, привязанная поверх домена?
"Записи cname очень полезны" - почему? если их не будет - что будет?
п.с: никакого негатива, пытаюсь разобраться, для кого-то все эти знания - базовая теория, а кто-то плавает во всём этом и не понимает, зачем нам делать элиас на домен, который вроде как тоже элиас

*.stage 14400 IN CNAME stage

Все запросы ip xxx.stage, yyy.stage или bla-bla.stage будут получать ip хоста stage.
в некоторих случаях это очень удобно.

>>Часто нужно сделать редирект домена iskettlemanstillopen.com на www.iskettlemanstillopen.com.

Лучше делать наоборот.

Вообще, статья не очень удачная. То есть, она неплохо называет основные термины, но создаёт ошибочную иллюзию простоты системы DNS, тогда как она на самом деле фантастически непростая.

Например, там есть инструменты для организации загрузки операционных систем по сети, также там можно хранить данные авторизации, да вообще чего только нельзя хранить.
Логика работы DNS проста и понятна, то, как софт интерпретирует ресурсные записи, расположенные в DNS, к сложности самого протокола не имеет никакого отношения.

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

Самые ходовые А, АААА (А6), CNAME, PTR, SRV, MX, TXT.
Ну и «технические» NS, SOA

При этом софта, который использует специально оформленные TXT или SRV поля много-много больше и каждый ведёт себя по-разному (и не всегда логично).
Но сложность ли это DNS? Ничуть.

DNSSEC — уже сложнее, но он и куда бОльший функционал несёт, хотя тоже вполне прост и понятен в большинстве случаев.
Есть и перевод — http://www.books.ru/books/dns-i-bind-5-e-izdanie-552030/
Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются.

Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована.
И ни слова про смену IP-адреса при переезде и его зависимость от коряво настроенных DNS-серверов игнорирующих TTL.

И про glue records при использовании NS в рамках того же домена, что порой ещё больнее бывает при переезде NS.

Тоже не совсем понял этот момент в оригинале.
Most of the time DNS resolution will never touch the root servers because their IP addresses hardly ever change.


Добавил ваше замечание в пост. Спасибо!
Ага, и в оригинале тоже звучит неоднозначно — множественные формы как для корневых серверов, так и для IP адресов позволяют отнести понятие (большое TTL) как к IP адресам серверов, так и IP адресам в базе. Такой вот семантический прокол в документации — хорошо, что это не кредитный договор…
статья нужная. но для совсем новичков, которым свой dns поднимать не надо, а надо на самом простом уровне уметь понять где проблема при разрыве связности, она слишком уходит в ненужные детали. И потому становится слишком сложной, заумной и ненужной. А для админов, которым хоть как-то надо поднять хоть минимальный dns-сервер ее катострофически мало. нет ни слова ни про ns, ни про soa. Так что админу от статьи точно пользы нет, на основании этих данных сервер не поднять никак :(
Ну так это и не пошаговая инструкция для поднятия DNS-сервера.
Sign up to leave a comment.

Articles