Ano ang DNS? Gabay para sa may-ari ng VPS

Ano ang DNS, at bakit hindi pa tumuturo ang iyong domain sa VPS

Ginagawang IP (internet protocol) address ng DNS (domain name system) ang isang pangalan gaya ng example.com, tulad ng 203.0.113.10. Hindi direktang kumokonekta ang browser sa pangalan. Kumokonekta ito sa address, kaya nagsisimula ang bawat page load sa isang DNS question at answer. Kung kakabili mo lang ng domain at ng sarili mong VPS, at walang naglo-load, isa sa dalawang bagay ang totoo: wala pang record na nag-uugnay sa pangalan sa address ng iyong server, o may record na ngunit may bahagi pa rin sa path na nagbibigay ng mas lumang answer.

Normal ang dalawang sitwasyon, at hindi nangangahulugang may sira. Tatalakayin ng mga seksyon sa ibaba ang mga bahagi ayon sa pagkakasunod na makikita mo ang mga ito, simula sa pinakamaraming oras na nasasayang: aling control panel ang aktuwal na naglalaman ng iyong mga record.

Ginagamit ng bawat check dito ang dig, na hindi naka-install bilang default sa bagong Ubuntu o Debian machine.

sudo apt update && sudo apt install -y bind9-dnsutils

Registrar, nameserver, DNS host: alin ang dapat mong i-edit

Magkakaiba ang tungkulin ng tatlong terminong ito. Ang pagkakapalit-palit sa mga ito ang pinakakaraniwang dahilan kung bakit walang epekto ang isang edit.

• Ang registrar ay kumpanyang binilhan mo ng domain. Ang kritikal nitong tungkulin ay delegation: sinasabi nito sa registry na nagpapatakbo ng iyong TLD (top-level domain, ang bahaging .com) kung aling mga nameserver ang authoritative para sa iyong domain.
• Ang authoritative nameserver ang naglalaman ng aktuwal na records para sa iyong zone. Ang zone ay ang iyong domain at ang mga pangalan sa ilalim nito.
• Ang DNS host ay ang nagpapatakbo sa mga nameserver na iyon. Maaari itong ang registrar, isang hiwalay na provider, o bind9 na tumatakbo sa server na pagmamay-ari mo.

Sa registrar ka bumibili. Sa DNS host ka nag-e-edit. Kung inilipat mo ang domain mo sa nameserver ng ibang provider, makikita pa rin sa sariling DNS panel ng registrar ang isang zone, mase-save pa rin nito ang mga edit mo, at walang sinuman sa internet ang nagtatanong sa zone na iyon. Totoo ang mga record. Hindi lang talaga ginagamit ang mga ito.

Alamin kung saan nagtatanong ang internet:

dig example.com NS +short
dig +trace example.com

Ang unang command ay nagpi-print ng mga nameserver na sumasagot para sa domain sa kasalukuyan. Ang pangalawa ay sumusunod sa chain mula sa root server at nagpi-print ng referral na ibinibigay ng TLD server, na siyang delegation na kinokontrol ng registrar mo. Kung hindi mo kilala ang mga pangalang iyon at kabilang ang mga ito sa isang provider, ang panel na kailangan mong gamitin ay pagmamay-ari ng provider na iyon.

Paano dumadaan ang isang lookup

Apat na party ang sangkot, at bawat isa ay nagtatago ng kopya ng impormasyong nalaman nito.

1. Ang stub resolver sa iyong machine. Hindi ito naghahanap. Humihingi ito sa isang naka-configure na server at pinagkakatiwalaan ang reply. Sa Ubuntu, ang /etc/resolv.conf ay karaniwang symlink papunta sa /run/systemd/resolve/stub-resolv.conf at tinutukoy ang 127.0.0.53, na systemd-resolved na lokal na tumatakbo at may sarili nitong cache.
2. Ang recursive resolver. Ito ang resolver na pinapatakbo ng iyong ISP (internet service provider), o ng public resolver gaya ng 1.1.1.1, o ng resolver na ikaw mismo ang nagpapatakbo. Ito ang aktuwal na naghahanap ng sagot.
3. Ang root at TLD servers. Humihingi ang recursive resolver sa isang root server. Hindi nito alam ang iyong address, pero nagbibigay ito ng referral sa mga server ng .com. Ang mga server na iyon naman ay nagbibigay ng referral sa iyong nameservers.
4. Ang authoritative nameserver. Wala itong hinihingan. Sumasagot ito mula sa iyong zone at minamarkahan ang sagot bilang authoritative.

Ipinapakita sa iyo ng dig +trace example.com ang prosesong ito dahil nagsisimula ito mismo sa root at ipinapakita ang bawat referral sa halip na humingi sa cache. Ito ang pinakamabilis na paraan upang makita kung nagtutugma ang delegation at ang zone.

Mga DNS record na mahalaga kapag nagpapatakbo ka ng server

• A: isang name na tumutukoy sa IPv4 address. example.com. A 203.0.113.10. Ito ang record na nagtuturo sa domain mo papunta sa VPS mo.
• AAAA: isang name na tumutukoy sa IPv6 address, gaya ng 2001:db8::10. I-publish lang ito kapag talagang nakikinig ang serbisyo mo sa address na iyon. Inuuna ng mga client sa IPv6 network ang AAAA answer, kaya ang address na walang serbisyong sumasagot ay nagdaragdag ng delay sa bawat pagbisita.
• CNAME: isang alias mula sa isang name papunta sa ibang name. Ipinapadala ng www.example.com. CNAME example.com. ang mga bisita ng www sa kung saan man nagre-resolve ang bare domain. Hindi maaaring ilagay ang CNAME sa apex (ang bare example.com), dahil kailangang may sarili itong SOA (start of authority) at NS records, at hindi maaaring makihati ang CNAME ng name sa iba pang record. Nag-aalok ang mga provider ng workaround na tinatawag na ALIAS, ANAME, o CNAME flattening.
• MX: kung saan ihahatid ang mail para sa domain. Naglalaman ito ng hostname at preference number, at unang susubukan ang may pinakamababang number. Dapat tumukoy ang MX sa isang name na may address record. Invalid ang pagturo nito sa CNAME, at maaaring i-reject ito ng ilang sending server.
• TXT: libreng text na ginagamit para sa proof at policy. Dito inilalagay ang mail authentication records (SPF, DKIM, DMARC), pati ang ACME (automatic certificate management environment) token na nag-i-issue ng wildcard certificate.
• NS: kung aling nameserver ang nagsisilbi sa zone. Ang copy na nagpapasya kung saan nagtatanong ang buong internet ay nasa parent zone at nagmumula sa delegation ng registrar mo, hindi sa copy na nasa sarili mong zone.

Dalawang detalye ang nagdudulot ng mas maraming kalituhan kaysa sa mismong record types. Absolute ang isang name na nagtatapos sa tuldok, kaya ang www.example.com. ay eksaktong ganoon lamang. Karamihan ng panel ay umaasang relative name at sila na ang nag-a-append ng domain para sa iyo, kaya kapag inilagay mo ang www.example.com sa name box, magiging www.example.com.example.com ito, na walang mare-resolve na kahit sino. Ang isa pang detalye ay @, na sa halos lahat ng panel ay nangangahulugang apex: ang domain mismo, na walang subdomain.

Ituro ang A record sa iyong VPS

Una, kunin ang address na nakikita ng internet para sa iyong server:

curl -4 https://ifconfig.me
ip -brief -4 address show

Pagkatapos, gumawa ng isang record sa iyong DNS host: type na A, name na @, value na address na iyon, at TTL (time to live) na 300. Magdagdag ng pangalawang record para sa www, alinman sa isa pang A na may parehong address o isang CNAME na tumuturo sa apex.

Ngayon, patunayan na nare-resolve ito. Mas mainam na gawin ito mula sa iyong laptop at hindi mula sa server mismo:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

Ginagamit ng una ang normal na path ng iyong machine, kasama ang mga cache. Nilalampasan ng pangalawa ang local cache at nagtatanong sa isang public recursive resolver. Direktang nagtatanong ang pangatlo sa iyong authoritative nameserver, kaya ang sagot nito ang kasalukuyang tama at walang cache sa anumang bahagi ng path. Kapag ibinalik ng ikatlong command ang iyong address ngunit hindi ito ibinalik ng una, tama ang configuration ng iyong DNS at naghihintay ka lang na mapalitan ang naka-cache na lumang sagot.

Hindi naglo-load matapos ang name resolving

Pinatutunayan ng name resolving na gumagana ang DNS. Wala itong pinatutunayan tungkol sa web server mo. Kapag naibalik na ng dig ang tamang address, subukan ang connection:

curl -I http://example.com

Problema sa DNS ang curl: (6) Could not resolve host: example.com. Hindi problema sa DNS ang curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused: na-resolve ang pangalan at nakarating ang packet, kaya ang isyu ay walang nakikinig sa port na iyon. Ang request na naghihintay nang matagal at sa huli ay nagti-time out ay karaniwang nangangahulugang tahimik na ibinagsak ng firewall ang packet sa halip na tanggihan ito. Dito nagtatapos ang usapin tungkol sa DNS, at pumapasok naman ang mga port at listening socket pati ang mga ufw firewall rule sa iyong VPS. Kapag nakumpleto na ang connection, ang natitirang pag-load ng page ay ang HTTP na nagsasagawa ng trabaho nito.

Bakit lumalabas pa rin sa browser ang lumang host

Walang awtomatikong nagpapalaganap ng pagbabago. Walang server na nagtutulak ng pagbabago palabas patungo sa iba. Hawak ng authoritative nameserver mo ang bagong value kaagad kapag sine-save mo ito, at mananatiling valid ang bawat naka-cache na kopya ng dating sagot hanggang sa mag-expire ang sarili nitong timer. Ang timer na iyon ang TTL, na nasa segundo, na dala ng record noong ipinamahagi ito.

Mas maraming lugar ang pinaglalagyan ng mga kopya kaysa sa karaniwang inaakala: ang maikling cache mismo ng browser, ang stub resolver sa machine, ang recursive resolver na ginagamit ng network na iyon, at anumang resolver na ini-install ng VPN sa client. Pinananatili ng bawat isa ang kopya nito nang hanggang sa TTL na natanggap nito. Maaaring magpakita ng magkaibang sagot ang dalawang tao sa dalawang network sa loob ng ilang oras, at parehong gumagana nang tama ang kanilang mga machine.

Bantayan ang countdown sa isang caching resolver:

dig @1.1.1.1 example.com +noall +answer

Patakbuhin ito nang dalawang beses, na may pagitan na ilang segundo. Bumababa ang TTL sa sagot. Kapag umabot ito sa zero, itinatapon ng resolver ang record at muling nagtatanong sa nameserver mo.

May isa pang cache na halos walang kumokonsidera: ang mga negative answer. Kapag sinabihan ang resolver na hindi umiiral ang isang pangalan, kino-cache rin nito ang NXDOMAIN na iyon sa panahong itinakda ng huling field ng SOA record ng zone mo.

dig example.com SOA +short

Ang huling numero sa linyang iyon ang negative TTL, na kadalasang 3600. Kaya kung titingnan mo ang staging.example.com bago mo ito gawin, maaaring maitago sa iyo ang record nang isang buong oras matapos mo itong likhain. Gawin muna ang record, saka ito i-query.

Mas mabagal ang pagpapalit ng nameserver kaysa sa pagpapalit ng record, at mekanikal ang dahilan. Ang delegation records sa .com zone ay inihahatid na may TTL na 172800 segundo, o dalawang araw, kaya maaaring patuloy na magtanong sa lumang nameserver ang isang resolver na naka-cache ng mga lumang nameserver sa loob ng panahong iyon. Dito nagmumula ang payong “maglaan ng hanggang 48 oras.” Nalalapat ito sa pagpapalit ng nameserver, hindi sa karaniwang pag-edit ng record.

Planuhin ang migration batay sa TTL sa halip na labanan ito:

1. Ibaba ang TTL ng record sa 300 at i-save ito.
2. Maghintay nang mas matagal kaysa sa lumang TTL upang mag-expire ang bawat naka-cache na kopyang may lumang value.
3. Palitan ang address.
4. Kapag nailipat na ang traffic, itaas muli ang TTL sa 3600 o mas mataas, dahil mas madalas magtatanong sa nameserver mo ang bawat resolver kapag mababa ang TTL.

Para i-clear ang hawak ng sarili mong machine:

resolvectl flush-caches
resolvectl statistics

Ipinapakita ng resolvectl statistics ang isang cache section na may hit at miss counters, kaya kaagad pagkatapos ng flush, lalabas bilang miss ang susunod na lookup. May hiwalay na cache ang mga browser, kaya maaari pa ring gumamit ang Chrome ng lumang sagot kahit walang laman na ang system cache. I-clear ang cache na iyon sa chrome://net-internals/#dns. Suriin din ang /etc/hosts, dahil maaaring mauna sa DNS ang natitirang linya roon sa machine na iyon at sa machine na iyon lamang. Ipinapakita ng getent hosts example.com ang sagot na aktuwal na gagamitin ng system, kasama ang /etc/hosts.

Pinatutunayan ang wildcard certificates gamit ang TXT record

Sinusuri ng CA (certificate authority) kung kontrolado mo ang isang pangalan bago ito mag-isyu ng certificate. Nagse-serve ang HTTP-01 challenge ng file sa port 80 sa eksaktong hostname na iyon, kaya angkop ito para sa isang pangalan. Sumasaklaw ang wildcard certificate sa *.example.com, isang walang-takdang set ng mga hostname na hindi maaaring pagkuhanan ng file ng CA, kaya nag-iisyu ang Let's Encrypt ng wildcard certificates gamit lamang ang DNS-01 challenge. Nagpa-publish ka ng TXT record sa _acme-challenge.example.com na naglalaman ng token na ibinigay ng CA, at ang kontrol sa zone ang nagsisilbing patunay.

Dahil dito, nagiging bahagi ng certificate renewal ang iyong DNS host. Kailangang awtomatikong gumawa at mag-delete ng Certbot ng TXT record sa bawat renewal, kaya kailangan nito ng API at katugmang plugin para sa iyong provider. Kapag nabigo ang validation, ang karaniwang mensahe ay DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com, na nangangahulugang nagtanong ang CA bago naging visible ang record: maaaring hindi ito na-save, o naka-cache pa ang negatibong sagot. Makikita ang buong procedure sa gabay sa wildcard certificates gamit ang DNS-01 challenge.

Kapag inaangkin ng VPN ang resolver mo

Karaniwang pinapalitan ng VPN (virtual private network) client ang system resolver habang nakakonekta ito, dahil kung sa local network ipapadala ang mga lookup, malalaman ng network na iyon ang pangalan ng bawat site na binibisita mo. Tamang behavior ito, pero maaari itong mag-fail sa dalawang paraan.

Kung umangat ang tunnel at hindi na nagre-resolve ang mga pangalan habang gumagana pa rin ang mga address, hindi maaabot mula sa loob ng tunnel ang resolver na ini-install ng client. Nagtagumpay ang ping 1.1.1.1 at nagbalik ang curl https://example.com ng curl: (6) Could not resolve host: example.com. Kung umangat naman ang tunnel at napupunta pa rin ang mga lookup sa network na kinokonektahan mo, naka-tunnel ang traffic mo habang patuloy na nakikita ng local resolver ang bawat pangalan na nire-request mo.

resolvectl status

Ipinapakita nito ang resolver na ginagamit sa bawat link, kaya makikita mo kung alin ang ini-install ng tunnel at kung ito ang resolver na dapat gamitin. Itinatakda ito ng WireGuard tunnel mula sa linyang DNS = sa client config, at detalyadong tinatalakay ng pag-aayos ng DNS kapag inaangkin ng WireGuard ang resolver ang mga kaso ng systemd-resolved at resolvconf.

Mga reply code at kung ano ang ipinapahiwatig ng bawat isa

• NXDOMAIN: Isinasaad ng authoritative server na hindi umiiral ang pangalan. Suriin ang spelling, tingnan kung nadoble ang domain suffix, at tiyaking ang zone na in-edit mo ay siyang tinutukoy ng delegation.
• NOERROR na may walang laman na ANSWER SECTION: Umiiral ang pangalan, pero wala itong record ng type na hiniling mo. Kapag humingi ka ng AAAA at A lamang ang umiiral, eksaktong ito ang resulta.
• SERVFAIL: Sinubukan ng resolver ngunit hindi ito nakagawa ng sagot. Karaniwang sanhi nito ang authoritative servers na hindi kailanman sumasagot at ang pag-fail ng validation ng DNSSEC (domain name system security extensions). Mag-test gamit ang dig @1.1.1.1 example.com A +cd, na nagdi-disable ng validation. Kung may sagot na may +cd at SERVFAIL kapag wala nito, mga signature ang problema. Nangyayari ito matapos ilipat ang nameserver kapag ang parent ay nagpa-publish pa rin ng lumang DS (delegation signer) record.
• REFUSED: Hindi sasagutin ng server na tinanong mo ang query na iyon. Karaniwan itong nangyayari kapag itinuro mo ang dig sa isang authoritative server para sa domain na hindi nito sini-serve.
• ;; connection timed out; no servers could be reached: Hindi nakarating ang dig sa isang resolver. Network o resolver problem ito sa panig mo, kaya hindi ang domain ang dapat sisihin.

Ang ping: example.com: Temporary failure in name resolution ay parehong uri ng failure na iniuulat ng glibc sa halip na ng dig.

Dapat ka bang magpatakbo ng nameserver sa sarili mong VPS?

Maaari mo itong gawin. Ang bind9, knot, o nsd ay magsisilbi sa iyong zone mula sa server, at mas matututuhan mo ang tungkol sa DNS kaysa sa anumang panel. Praktikal ang mga pagtutol dito. Dapat may hindi bababa sa dalawang nameserver ang isang domain sa magkahiwalay na network, kaya nagiging iisang failure point ang isang VPS para sa lahat ng serbisyo ng domain, pati mail. Ang mga nameserver na ipinangalan sa mismong domain na kanilang sine-serve ay nangangailangan ng glue record sa registrar. Ito ang address ng ns1.example.com na naka-store sa parent zone, dahil kung wala ito, walang panimulang punto ang lookup. Kapag hindi maabot ng resolver ang iyong nameserver, hindi ito awtomatikong lilipat sa website mo. Mawawala ang buong domain para sa user na iyon. Para sa karamihan, mas mababa ang panganib ng hosted DNS na may API. Ibang gawain ang pagpapatakbo ng caching resolver sa iyong VPS para sa sarili mong mga machine, at mas maliit na commitment ito.

FAQ

Bakit hindi pa nagpo-propagate ang pagbabago ko sa DNS?

Walang nagpo-propagate. Hawak ng authoritative nameservers ang bagong value sa sandaling i-save mo ito, at pinananatili ng bawat resolver na nagtanong na ang naka-cache nitong kopya hanggang lumipas ang TTL na natanggap nito. Direktang tanungin ang authoritative server gamit ang dig @ns1.your-dns-host.net example.com A +short. Kung ibinalik nito ang bagong address, live na ang pagbabago at caching na lang ang natitirang dahilan. Kung nameservers ang binago mo sa halip na records, asahang mas matagal ito dahil ibinibigay ang TLD delegations na may two day TTL.

Paano ko malalaman kung aling nameservers ang aktuwal na ginagamit ng domain ko?

Ipinapakita ng dig example.com NS +short ang mga nameserver na kasalukuyang sumasagot para sa domain, at ipinapakita ng dig +trace example.com ang referral chain mula sa root, kasama ang delegation na ibinibigay ng TLD servers. Kung hindi ang mga pangalang iyon ang provider na ang panel ay ine-edit mo, iyon ang problema. I-edit ang records sa provider na nakalista sa delegation, o baguhin ang delegation sa registrar mo para tumuro ito sa gusto mong provider.

Nari-resolve ang domain ko pero hindi pa rin naglo-load ang site. Ano ang dapat kong gawin?

Tapos na ang DNS kapag ibinalik ng dig example.com A +short ang address ng server mo. Pagkatapos nito, connection na ang problema. Kapag nagbalik ang curl -I http://example.com ng Connection refused, nangangahulugan itong walang nakikinig sa port na iyon. Tiyaking tumatakbo ang web server mo at naka-bind ito sa public address. Pagkatapos, suriin ang firewall sa server at ang hiwalay na network firewall sa control panel ng provider mo.

Bakit hindi ako makapaglagay ng CNAME sa root domain ko?

Sinasabi ng CNAME na alias ang isang name para sa isa pang name, at hindi maaaring magkaroon ng ibang record ang name na may CNAME. Kailangang may SOA at NS records ang root domain mo upang umiral bilang zone, kaya hindi rin ito maaaring maging CNAME. Gumamit ng A record na naglalaman ng address sa root, o gamitin ang feature ng provider na tinatawag na ALIAS, ANAME, o CNAME flattening. Ini-store nito ang isang name at sinasagot ang mga query gamit ang address na kasalukuyang nari-resolve ng name na iyon.