Paano Gumagana ang Domain at DNS: Gabay para sa Hindi Developer

Ang domain ang pangalang tinitipa ng mga tao para marating ang site mo, gaya ng example.com, at ang DNS (Domain Name System) ang direktoryo ng internet na nagsasalin sa pangalang iyon tungo sa kinaroroonan ng site mo. Nirerentahan mo ang domain mula sa registrar, tapos nagdaragdag ka ng DNS record na nagsasabing "nandoon ang website" at "dito pupunta ang email." Ang pagkonekta ng custom domain sa app ay halos pagdaragdag lang ng tamang record sa tamang lugar at paghihintay na magkabisa ito.

Bakit mahalaga ito kapag gumagawa gamit ang AI

Kayang isulat at i-host ng AI app builder ang app mo, pero nasa labas nito ang domain mo, kadalasan sa ibang kumpanya, sa control panel na puno ng hindi pamilyar na uri ng record. Dito madalas natitigil ang launch: handa na ang app, pero may error ang domain, o biglang humihinto sa paggana ang email pagkatapos ng pagbabago sa DNS.

Malaki ang naitutulong ng kaunting pag-unawa. Malalaman mo kung aling record ang hinihingi ng host mo, kung bakit hindi pa ito gumagana, at paano iwasang masira ang mga bagay (tulad ng email) na umaasa na sa domain mo.

Isang halimbawa mula sa araw-araw

Isipin ang contacts list ng telepono mo.

Hindi mo kailangang tandaan ang numero ng kaibigan mo; tina-tap mo ang pangalan niya at hahanapin ito ng telepono. Ganito rin ang ginagawa ng DNS sa internet: tina-type mo ang example.com, at hahanapin ng DNS ang numero (ang IP address) ng server na kokonektahan.

• Ang domain ang pangalan ng contact.
• Ang registrar ang kumpanyang opisyal na nagtatala na sa iyo ang pangalan.
• Ang DNS record ang mga detalyeng naka-save sa ilalim ng pangalan: numero ng telepono, email address, at address.
• Ang nameserver ang opisyal na contacts book para sa pangalang iyon.
• Ang caching ay ang telepono mong nagtatandang ng numero sa loob ng ilang panahon. Kapag nagpalit ng numero ang kaibigan mo, may ilang telepono na tatawag pa rin sa lumang numero hanggang ma-refresh ang naka-save na kopya. Iyan ang DNS "propagation."

Ang mga bahagi ng domain name

Kunin ang app.example.com:

Hindi mo tuluyang binibili ang domain; ipinapa-rehistro mo ito sa isang panahon (karaniwan isang taon o higit pa) at nire-renew. Kapag hinayaan mong mag-expire, maaaring ipa-rehistro ito ng iba.

Paano gumagana ang DNS lookup

Kapag may nagta-type ng app.example.com:

1. Magtatanong ang browser sa isang DNS resolver, kadalasan na pinapatakbo ng internet provider nila o ng pampublikong serbisyo, para sa address.
2. Kung may sariwang cached na sagot ang resolver, agad itong sasagot.
3. Kung wala, bababa ito sa hierarchy: itinuturo ng root server ito sa .com server, na itinuturo naman ito sa nameserver ng domain mo.
4. Ibinabalik ng nameserver mo ang record na itinakda mo, gaya ng CNAME sa host mo o A record na may IP address.
5. Ica-cache ng resolver ang sagot sa TTL (time to live) ng record at ibibigay ito sa browser, na kokonekta sa server.

Kadalasang nangyayari ang lahat ng ito sa loob ng millisecond.

Mga uri ng DNS record na talagang gagamitin mo

May ilang panuntunang sulit malaman:

• Hindi maaaring magbahagi ng pangalan ang CNAME sa ibang record. Kaya hindi maaaring ilagay ang karaniwang CNAME sa root domain, na laging may NS at iba pang record. Maraming DNS provider ang nag-aalok ng workaround na tinatawag na ALIAS, ANAME, o CNAME flattening.
• Maraming trabaho sa email ang TXT record. Inililista ng SPF kung sino ang maaaring magpadala ng mail para sa domain mo; naglalathala ang DKIM ng key para mapatunayan ang signature; sinasabi ng DMARC sa tumatanggap kung ano ang gagawin sa mail na pumalya sa mga check na iyon.
• Mas mataas ang priority ng mas mababang MX number. Ang mail ay unang sinusubukan sa pinakamababa.

Propagation at TTL

Parang dahan-dahang kumakalat ang mga pagbabago sa buong internet ang "propagation." Ang totoo, caching ang nangyayari: itinatago ng resolver ang kopya ng bawat sagot sa loob ng TTL nito, at magtatanong lang ulit kapag nag-expire na ito. Kaya:

• Ang bagong record na hindi pa nahahanap nang madalas ay kadalasang gumagana sa loob ng ilang minuto.
• Ang pagbabago sa umiiral na record ay tumatagal hanggang sa lumang TTL bago makita kahit saan.
• Ang pagpalit ng nameserver ay maaaring tumagal ng isa o dalawang araw, dahil mas matagal itong naka-cache sa antas ng TLD.

May kapaki-pakinabang na trick: bago ang nakaplanong pagbabago, ibaba muna ang TTL ng record (halimbawa sa ilang minuto), hintaying lumipas ang lumang TTL, saka gawin ang pagbabago.

Halimbawang kongkreto: pagkonekta ng booking app sa domain mo

May sarili kang domain na yoursalon.com. Ginagamit na ito ng kasalukuyan mong website at ng Google Workspace email. Gumawa ka ng booking app at gusto mo itong nasa book.yoursalon.com.

1. Hanapin kung saan pinamamahalaan ang DNS mo. Maaaring ang registrar mo ito o hiwalay na DNS provider. Sasabihin ng NS record mo.
2. Magdagdag ng CNAME para sa book na nakaturo sa target na ibibigay ng app host mo.
3. Magdagdag ng anumang TXT record na hinihingi ng host para patunayan ang pagmamay-ari, kung gumagamit ito nito.
4. Huwag galawin ang MX at email TXT record. Patuloy na gagana ang email dahil hindi mo ito ginalaw.
5. I-verify sa host mo kapag na-update na ang DNS. Saka mag-iisyu ang host ng HTTPS certificate para sa book.yoursalon.com.
6. Subukan sa telepono gamit ang mobile data, dahil iba ang resolver at cache nito sa home Wi-Fi mo.

Kung ang app ang gusto mong ilagay sa mismong yoursalon.com, kakailanganin mo ng A record o ang ALIAS/flattening feature ng DNS provider mo, at papalitan mo ang kasalukuyang website doon. Para sa iba pang hakbang, tingnan ang how to connect a custom domain.

Mga karaniwang pagkakamali at maling akala

• "Iisa lang ang domain at hosting." Ang domain ang pangalan; ang hosting ang lugar kung saan tumatakbo ang app. Ang DNS ang nag-uugnay sa dalawa.
• Paggamit ng A record kapag CNAME ang hinihingi ng host (o kabaligtaran). Sundin nang eksakto ang tagubilin ng host.
• Typo sa target. Isang maling karakter sa target ng CNAME at papalya ang verification.
• Pagpalit ng nameserver nang hindi kinokopya ang record. Ang paglipat ng DNS sa bagong provider nang hindi muling ginagawa ang MX at TXT record ay klasikong paraan para masira ang email.
• Pag-proxy kapag hindi dapat. May ilang DNS provider, gaya ng Cloudflare, na nagpo-proxy ng trapiko. Kailangan ng ilang host na naka-"DNS only" ang record para makapag-isyu sila ng certificate.
• Pagbura sa TXT record na "hindi kilala." Kadalasan itong verification o email security record na may umaasa.
• Hinahayaang mag-expire ang domain. I-on ang auto-renew at panatilihing napapanahon ang card para sa bayad.

Ano ang hihilingin sa AI builder mo

Nasa labas ng code mo ang DNS, kaya mas tungkol ito sa kung ano ang dapat itanong:

• "Ano ang eksaktong DNS record na kailangan ko para sa app.mydomain.com? Uri, pangalan, at value."
• "Makakaapekto ba ito sa email ko?"
• "May error ang domain ko pagkatapos kong idagdag ang record. Ano ang dapat kong suriin?"
• "Ilagay ang tamang canonical URL at redirect para hindi magpakita ang www at non-www ng parehong site."
• "I-set up ang pagpapadala ng email mula sa domain ko. Anong SPF, DKIM, at DMARC record ang kakailanganin ko?" Tingnan ang how to send emails from your app.

Mga custom domain sa Mythex

Bawat nailathalang app sa Mythex ay may address na yourname.mythex.app. Sa Pro, puwede mong gamitin ang sarili mong domain: bumili ng isa sa loob ng Mythex (hiwalay na sinisingil ang registration, at pinamamahalaan para sa iyo ang DNS ng mga binili), o ikonekta ang domain na pagmamay-ari mo na sa pamamagitan ng pagdaragdag ng CNAME mula sa subdomain tulad ng app.example.com papunta sa address ng app mo na yourname.mythex.app, saka i-click ang Verify. Awtomatikong ibinibigay ang HTTPS. Kung nasa Cloudflare ang DNS mo, itakda ang record na "DNS only." Inirerekomenda ang mga subdomain; ang root domain ay nakadepende sa suporta ng DNS provider mo sa ALIAS o flattening. Ginagabayan ka ng custom domain docs sa bawat hakbang, at ipinapakita ng pricing kung ano ang kasama sa Pro.

Mga tanong