Зашто корен домена не може бити ЦНАМЕ - и друге ситнице о ДНС-у

Овај пост ће користити горе питање да истражи DNS, dig, Aевиденција, CNAMEевиденција и ALIAS/ANAMEзаписа из перспективе почетника. Па кренимо.

Прво, неке дефиниције

  • Систем назива домена (ДНС): свеукупни систем за претварање људског имена имена домена (екампле.цом) у ИП адресу (93.184.216.34). ИП адреса је сервера, обично веб сервера, где се чувају датотеке потребне за приказ веб странице.
  • ДНС сервер (познат и као сервер имена или сервер имена): користи ДНС софтвер за чување информација о адресама домена. Постоји неколико нивоа - они који припадају сваком ИСП-у, роот (укупно 13 широм света), домен највишег нивоа (ТЛД, нпр. '.Цом') и ДНС сервери на нивоу домена.
  • Име домена : домен (пример) у комбинацији са доменом домена (.цом). Термин „домен“ се често користи синонимно са именом домена, мада се они разликују. Када купујете „домену“ од регистратора или препродавца, купујете права на одређено име домена (екампле.цом) и све поддомене које желите да направите (ми-сите.екампле.цом, маил.екампле.цом, итд.).

Ток упита на високом нивоу

Проток на високом нивоу онога што се дешава када у прегледач унесете „екампле.цом“ може се поједноставити да би се уклонили скокови на ИСП, Роот и ТЛД ДНС сервере као што је приказано испод:

Домен обично има два или више сервера имена који садрже записе који се односе на име домена (екампле.цом).

Могу се чувати многе врсте записа, од којих већина може имати више уноса по типу:

  • A: Записи адреса који мапирају име домена у ИП адресу
  • CNAME: Цаноницал Наме Рецорд. Користи се за замјену имена једног домена (или имена поддомена) на другом. Ово ћемо детаљније размотрити касније.
  • MX: Маил еКсцханге записи који поручују агентима за доставу е-поште где треба да испоруче вашу е-пошту
  • TXT: флексибилни текстуални записи за чување низова за разне намене
  • SOA: сингулар Запис о покретању овлашћења чува се на највишем нивоу домена. Садржи специфичне потребне информације о домену, на пример његов примарни сервер имена
  • NS: Сервери имена повезани са доменом

Када ваш уређај пошаље упит који долази до сервера имена, сервер у чвору записа домене тражи Aзапис и повезану сачувану ИП адресу (екампле.цом: 93.184.216.34). То се затим враћа на уређај да би се користило за слање захтева исправном веб серверу за преузимање тражене веб странице или ресурса.

Коришћење „копања“

dig( гропер информација о домену ) је алатка наредбене линије за постављање упита ДНС серверима. Ова наредба се обично користи за решавање проблема или као и сада за разумевање више о подешавању система.

$ dig example.comрезултира дугим одзивом одштампаним на терминалу, овде задати задани излаз, од којег смо заинтересовани ANSWER SECTION.

;; ANSWER SECTION: example.com. 72703 IN A 93.184.216.34

И ето, видимо да то example.comдаје Aзапис о 93.184.216.34. Понекад ће домени имати више Aзаписа, ако више веб сервера може да пружи потребне информације.

Има више! Ако покушамо неке друге примере, ускоро ћемо видети да се појави још један заједнички рекорд: CNAME.

$ dig www.skyscanner.net:

;; ANSWER SECTION: www.skyscanner.net. 169 IN CNAME www.skyscanner.net.edgekey.net. www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net. e11316.a.akamaiedge.net. 20 IN A 23.217.6.192
www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.
e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

Коришћење +shortзаставе омогућава нам да јасно видимо формирану путању:

$ dig www.skyscanner.net +short

www.skyscanner.net.edgekey.net. e11316.a.akamaiedge.net. 23.217.6.192

ЦНАМЕ

CNAMEЗапис омогућава домен који се користи као псеудоним за другог канонског (Труе) домена.

Када ДНС сервер врати CNAMEзапис, неће га вратити клијенту. Уместо тога, поново ће потражити враћено име домена и заузврат вратити AИП адресу записа. Овај ланац може да настави више CNAMEнивоа дубоко, али онда трпи мање погођене перформансе из више прегледа пре него што се одржи кеширање.

Једноставан пример за то може бити ако имате сервер на којем чувате све своје фотографије. Можете му нормално приступити путем photos.example.com. Међутим, можда бисте желели и да дозволи приступ путем photographs.example.com. Један од начина да се ово могуће је додати CNAMEподатак да бодова photographsу photos. То значи да ће им се, када неко посети photographs.example.com, дати исти садржај као photos.example.com.

Користећи упит $ dig photographs.example.comвидели бисмо:

photographs.example.com IN CNAME photos.example.com photos.example.com IN A xx.xxx.x.xxx

Важно је напоменути да CNAMEје то део са десне стране. На левој страни налази се надимак или назив.

Још једна уобичајена употреба је за wwwподдомен. Куповином example.comвероватно желите да и корисници који уносе текст www.example.comвиде исти садржај.

Овде вреди напоменути да example.comсе може назвати врхом, кореном или голим именом домена.

Једна од могућности била би постављање другог Aзаписа, указујући на исту ИП адресу као и за example.com. Ово је потпуно валидно и јесте оно што стварно example.comради, али не мери се добро. Шта се дешава ако треба да ажурирате ИП адресу на коју example.comупућује? Такође ћете га морати ажурирати за wwwподдомен и све друге које можете користити.

Ако би се CNAMEзапис користио за псеудоним www.example.comда би указао на њега, example.comтада би само коријенски домен морао бити ажуриран, као што сви други чворови воде на њега.

ЦНАМЕ ограничења

У време када су написани ДНС стандарди, постављена су нека правила која регулишу њихову употребу. РФЦ 1912 и РФЦ 2181 утврђују да:

  • SOAа NSзаписи су обавезни да буду присутни на основном домену
  • CNAMEзаписи може постојати само као појединачне евиденције и не може се комбиновати са било којим другим записи ресурса (ДНССЕЦ SIG, NXTи KEY RRевиденција изузети)

Ово искључује CNAMEупотребу на основном домену, јер би та два правила била у супротности.

Овде је важно да је ово уговорно ограничење, а не техничко. Могуће је користити а CNAMEу корену, али то може резултирати неочекиваним грешкама, јер крши очекивани уговор о понашању.

Пример за то говори Цлоудфларе, описујући проблеме на које су наишли са Мицрософт Екцханге серверима поште пошто су користили а CNAMEна свом коренском домену:

Домене обично одређују сервере који рукују њиховом е-поштом путем онога што је познато као МКС запис. Проблем је био у томе што су Екцханге сервери ... могли да преузму ЦНАМЕ у основном запису, а затим не поштују правилно ЦНАМЕ постављен у МКС запису. Не можете заиста кривити Екцханге. Они су функционисали под претпоставкама утврђеним у ДНС спецификацији.

Here you see the downside that can appear in several server softwares or libraries. Because a standard is in place for a CNAME to be the only record at a node, no other records are looked for. All other records will be silently ignored, without warning or error messages. Even if an MX record was set to receive email, the MX will be ignored as if it doesn’t exist because the CNAME is evaluated first. The same is true if there were an A record: the CNAME would take precedence and the A record would not be read.

The modern internet

So why is this a problem? Why would you ever want to use a CNAME for your root domain anyway? Surely that is the end of the path when looking for the IP address of the web server hosting your content?

In the modern internet landscape, that is no longer the case. The world is very different from when the DNS standards were written.

You may choose to use a Platform as a Service (PaaS) provider like Heroku and store content on their web servers. You control the content, but not the infrastructure, and the PaaS provider does the heavy lifting of the network maintenance. They typically provide you with a URL (my-app.herokuapp.com) that is a subdomain of their root domain, and you can view the IP addresses for the web server(s) your content is on. But these are entirely under the PaaS provider’s control, and will change without warning.

The scale and frequency of backend changes made by the PaaS provider can make it hard to maintain your root domain A record pointing at a single IP address. Ideally you would wish to do this:

example.com IN CNAME my-app.herokuapp.com.www.example.com IN CNAME my-app.herokuapp.com.example.com IN CNAME my-app.herokuapp.com. www.example.com IN CNAME my-app.herokuapp.com.

to allow Heroku (or your chosen host provider) to manage updating the A record that the CNAME points to without any changes made on your side. However, as we now know, this breaks the DNS specification, so is a very bad idea.

It is possible to simply implement a 301/302 redirect from example.com to www.example.com. However, that instruction takes place either on the web server (so still having the problem of needing to use a fixed A record in DNS to point to that web server), or a custom DNS provider redirect (that suffers complications with HTTPS).

This also has the side effect of changing the domain that you see in the URL bar, which you may not want. This method is intended for when your website has permanently moved, or when you’re trying to preserve SEO rankings, rather than solving our problem of pointing to a complex changing backend in a scaleable way.

The solution

Several DNS providers have now developed custom solutions to work around this problem, including:

  • ALIAS at DNSimple
  • ANAME at DNS Made Easy
  • ANAME at easyDNS
  • CNAME (virtual) at CloudFlare

These are all virtual record types that provide CNAME like behaviour, with none of the downsides. The exact implementation can differ, but at a high level when the DNS server sees one of these virtual record types, it acts as a DNS resolver. It follows the chain created by the alias until it resolves at an A record (or records) and returns these A records to the DNS server. This ‘flattens’ the CNAME chain into the A record(s) returned, and is indistinguishable to the sent query. The query sees only a pure A record, which doesn’t break the DNS specification, and doesn’t have any of the disadvantages of a CNAME.

Ови виртуелни записи могу се налазити уз остале записе у корену, без икаквог страха од нежељеног понашања. У зависности од добављачеве методе ДНС резолуције при праћењу CNAMEланца, они такође могу имати користи од перформанси кеширања претходних претрага.

За ДНСимпле подешавање, тада бисмо конфигурисали као доле. Ово решење има све предности удруживања имена домена и ниједан ризик од коришћења на основном нивоу.

example.com IN ALIAS my-app.herokuapp.com.www.example.com IN CNAME my-app.herokuapp.com.

Хвала за читање! ?

Као и увек, отворен за било какве исправке или додатне тачке.

Ресурси

  • Шта је ДНС сервер
  • Поставите ДНС сервер имена
  • ДНСимпле странице за подршку и АЛИАС блог
  • Подршка за Цлоудфларе и ЦНАМЕ блог
  • dig Како да
  • Неколико сјајних постова за преливање стака или СтацкЕкцханге
  • Добро написани уноси на Википедији
  • Нетлифи блог „На ввв или не на ввв“