Puncte:1

Registratorul de domenii permite @ CNAME pentru domeniul rădăcină, este de încredere?

drapel in

Din cauza unei lacune în cunoștințele mele, am configurat o mașină virtuală Windows pe Azure, apoi am mers la Namecheap și am înregistrat un domeniu. Undeva mi-a venit ideea să pun o înregistrare CNAME împotriva @ și a FQDN-ului și funcționează.

În înregistrările mele de nume există literalmente 2 intrări @ și www pentru CNAME față de FQDN-ul Azure VM. Totul funcționează dulce.

Ieri, tipul pentru care lucrez a mers să schimbe serverele de nume de pe domeniul planificat care nu era la Namecheap (folosisem un domeniu fals pe care l-am înregistrat la Namecheap) și nu a putut face ceea ce am făcut și am cheltuit câteva ore cercetându-l.

Astăzi, am folosit un instrument pentru a căuta site-ul și se pare că Namecheap folosește domeniul pe care l-am furnizat pentru a căuta adresa IP și introduce o înregistrare A împotriva acelui IP, dar nu apare pe pagina de management. Deci se face în fundal. Ieri am resetat VM-ul și IP-ul s-a schimbat și domeniul a fost restaurat în câteva minute.

Cât de normal este asta? Cât de stabil este acesta? Nu am un IP dedicat pe Azure.

Înțeleg acum că @ pe un domeniu non-www nu este normal (adică, de obicei, nu se poate plasa @ pe o înregistrare CNAME). Dar există gazde de domeniu reputate care oferă acest serviciu gratuit? Este ceva ce pot căuta? (Problema secundară este că Namecheap nu este dispus în prezent să transfere acest domeniu, deoarece se pare că domeniile .com.au sunt dificil de transferat).

Dacă acest lucru este rar, singurele mele opțiuni plătesc Azure pentru un IP static și folosesc înregistrări A?

Puncte:2
drapel gg

CNAME-urile de la rădăcină nu sunt cu adevărat acceptate de niciun standard, dar unii furnizori o fac, deoarece este destul de util. Problema, după cum ați observat, este că, deoarece nu este o soluție standardizată, implementările variază, cum ar fi, de exemplu, interogarea numelui în CNAME, rezolvarea acestuia și inserarea IP-ului ca înregistrare A.

Nu aș recomanda această practică, deoarece există motive reale pentru care înregistrarea rădăcină trebuie să fie o înregistrare A sau AAAA.

Modalitățile adecvate de a gestiona acest lucru este fie să vă puneți un cal și să plătiți pentru un IP static de la Azure, fie, alternativ, dacă ați găzduit multe dintre aceste site-uri, este să obțineți un singur IP static pentru un echilibrator de încărcare/proxy invers și să lăsați transmite solicitările către aplicațiile dvs. web dinamice.

Sau, puteți folosi Cloudflare, deoarece au reușit de fapt să creeze un CNAME compatibil cu RFC la implementarea rădăcină. https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/

Patrick Mevzek avatar
drapel cn
Noul standard va fi înregistrările `SVCB` și `HTTPS` care vor permite aceeași caracteristică decât CNAME, dar și la vârf. Sunt deja folosite de iOS și CloudFlare cel puțin.
drapel gg
Frumos, nu auzisem de asta!
user160357 avatar
drapel gb
Vă rugăm să explicați de ce, acest lucru nu este recomandat?
drapel gg
Din punct de vedere tehnic, ați putea avea un CNAME la rădăcină, dar conform standardului, nicio altă înregistrare cu același nume nu poate coexista cu un CNAME, ceea ce face imposibil să aveți un CNAME la rădăcină deoarece există alte înregistrări cu același nume care trebuie să coexiste cu înregistrarea rădăcină. Postarea de blog Cloudflare explică destul de bine.
Puncte:-1
drapel de

CNAME înseamnă doar alias. Este la fel de fiabil ca o înregistrare doar că mai multe domenii folosesc același ip. Cu toate acestea, dacă domeniul pentru care utilizați un CNAME expiră sau încetează să mai existe, atunci veți întâmpina aceeași problemă de a găsi unde se adresează domeniul dvs.

A înregistrează:

domeniul 1 ip

domeniul 2 ip

este la fel ca :

domeniul 1 ip

domeniul 2 domeniul 1

doar că în a 2-a situație dacă domeniul 1 se actualizează ip, la fel și domeniul 2, dar în prima ambele domenii trebuie să fie actualizate individual la modificările ip.

Patrick Mevzek avatar
drapel cn
Ați uitat de cazul de utilizare specific al apex-ului și de regula că `CNAME` NU poate coexista cu alte înregistrări, în timp ce apex are deja alte înregistrări (`NS` și `SOA` pentru început). Deci răspunsul tău poate fi vag ok în general, dar deloc pentru apex.
drapel de
Depinde și de software-ul/serviciul DNS utilizat. Unii vor permite altora nu. Totuși, ceea ce am vrut să explic este că, în general, o înregistrare CNAME sau A nu face nicio diferență indiferent de nivelul de domeniu. Acest lucru se datorează faptului că, indiferent dacă este un subdomeniu sau un nivel superior, există alte lucruri deasupra acestuia, cum ar fi .com în spate, în timp ce www.domain.com poate funcționa și de obicei utilizează un CNAME, este considerat totuși un subdomeniu.Dacă un server web are ambele domenii, va avea sens să CNAME domeniul principal al serverului în cazul în care înregistrarea A este actualizată dacă NS nu este același, ceea ce ar ajuta în cloudflare, dar nu este permis
Patrick Mevzek avatar
drapel cn
„Depinde și de software-ul/serviciul DNS folosit.” Nu, nu. Bineînțeles că poți publica orice prostie din zona ta... asta nu înseamnă că serverul de nume recursiv o va accepta. Așadar, chiar dacă găsiți un server de nume fals care vă permite să puneți un CNAME la vârf (și, de exemplu, legarea nu ar fi), aceasta nu înseamnă că va funcționa. Dimpotrivă.
Patrick Mevzek avatar
drapel cn
„În general, o înregistrare CNAME sau A nu face nicio diferență indiferent de nivelul domeniului.” În general poate, la vârf nu. Iar întrebarea era SPECIAL despre apex. Deci răspunsul ar trebui să fie mai întâi despre asta. Puteți extinde în general după, dar dacă nu răspundeți la punctul central al apexului, răspunsul dvs. este mai puțin relevant decât alții.
Patrick Mevzek avatar
drapel cn
`CNAME` a fost util acum 40 de zile, când nu exista niciun instrument pentru actualizări în masă. Astăzi, este în mare măsură irelevant și putem trăi fără el. Orice software bun de furnizare ar putea genera toate înregistrările „A”/“AAAA” necesare fără a se baza pe CNAME.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.