DNS ni nini na jinsi ya kusanidi domain kwenye VPS

DNS ni nini, na kwa nini domain yako bado haifiki kwenye VPS yako

DNS (domain name system) hubadilisha jina kama example.com kuwa anwani ya IP (internet protocol) kama 203.0.113.10. Kivinjari hakiwezi kuunganishwa na jina. Huunganishwa na anwani, kwa hivyo kila upakiaji wa ukurasa huanza na swali la DNS na jibu lake. Ikiwa umenunua domain na VPS yako mwenyewe, na hakuna kinachopakia, moja ya mambo haya mawili ni kweli: hakuna rekodi inayounganisha jina hilo na anwani ya seva yako bado, au rekodi ipo lakini kuna kitu kwenye njia hiyo bado kinatoa jibu la zamani.

Hali zote mbili ni za kawaida, na hakuna inayomaanisha kuwa kuna kitu kimeharibika. Sehemu zilizo hapa chini zinachukua hatua kwa mpangilio utakaokutana nao, kuanzia na ile inayopoteza muda mwingi: ni paneli ipi ya udhibiti inayoshikilia rekodi zako.

Kila ukaguzi hapa unatumia dig, ambayo haijawekwa kwa chaguo-msingi kwenye mashine mpya ya Ubuntu au Debian.

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

Msajili, nameservers, DNS host: ni ipi unayopaswa kuhariri

Majina haya matatu yanaelezea kazi tofauti. Kuchanganya majukumu haya ndiyo sababu kuu inayofanya mabadiliko yako kutokuwa na matokeo yoyote.

• Msajili (registrar) ni kampuni uliyoinunulia domain. Kazi yake muhimu ni delegation: inaiambia registry inayoendesha TLD yako (sehemu ya .com) ni nameservers zipi zenye mamlaka (authoritative) kwa domain yako.
• Nameservers zenye mamlaka (authoritative nameservers) ndizo zinazohifadhi rekodi halisi za zone yako. Zone ni domain yako na majina yote yaliyo chini yake.
• DNS host ni yeyote anayeendesha nameservers hizo. Inaweza kuwa msajili, mtoa huduma mwingine, au bind9 inayofanya kazi kwenye seva unayomiliki.

Unanunua domain kwa msajili. Unafanya uhariri kwenye DNS host. Ikiwa ulihamishia domain yako kwenye nameservers za mtoa huduma mwingine, paneli ya DNS ya msajili bado itakuonyesha zone, bado itahifadhi mabadiliko yako, lakini hakuna mtu kwenye Internet atakayeuliza zone hiyo swali lolote. Rekodi hizo ni halisi. Hazitumiwi kamwe.

Tambua mahali ambapo ulimwengu unauliza maswali:

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

Amri ya kwanza inachapisha nameservers zinazojibu maombi ya domain hiyo leo. Ya pili inafuatilia mnyororo kuanzia kwenye root servers na kuchapisha referral inayotolewa na TLD servers, ambayo ndiyo delegation inayodhibitiwa na msajili wako. Ikiwa majina hayo ni ya mtoa huduma usiyemtambua, basi mtoa huduma huyo ndiye anayemiliki paneli unayohitaji.

Jinsi utafutaji mmoja unavyofanyika

Kuna pande nne zinazohusika, na kila moja huhifadhi nakala ya kile inachojifunza.

1. Stub resolver kwenye mashine yako. Haifanyi utafutaji wowote. Inauliza seva moja iliyosanidiwa na kuamini jibu lake. Kwenye Ubuntu, /etc/resolv.conf kwa kawaida ni symlink ya /run/systemd/resolve/stub-resolv.conf na inataja 127.0.0.53, ambayo ni systemd-resolved inayofanya kazi ndani ya mashine ikiwa na cache yake yenyewe.
2. Recursive resolver. Hii ni resolver inayotumiwa na ISP (internet service provider) yako, au ya umma kama 1.1.1.1, au unayoiendesha wewe mwenyewe. Hii ndiyo inayofanya kazi halisi ya kutafuta jibu.
3. Root na TLD servers. Recursive resolver huuliza root server, ambayo haijui anwani yako lakini inajibu kwa kutoa rejeleo (referral) kwa seva za .com. Seva hizo hujibu kwa kutoa rejeleo kwa nameservers zako.
4. Authoritative nameserver. Haiulizi mtu yeyote. Inajibu kutoka kwenye zone yako na kuweka alama kuwa jibu hilo ni la mamlaka (authoritative).

dig +trace example.com inakuonyesha mchakato huu ukitokea, kwa sababu inaanza kwenye root yenyewe na kuchapisha kila rejeleo badala ya kuuliza cache. Hiyo ndiyo njia ya haraka zaidi ya kuona kama delegation na zone zinalingana.

Rekodi za DNS zinazohitajika unapoendesha seva

• A: jina kuelekea anwani ya IPv4. example.com. A 203.0.113.10. Hii ndiyo rekodi inayoelekeza domain yako kwenye VPS yako.
• AAAA: jina kuelekea anwani ya IPv6, kama vile 2001:db8::10. Ichapishe tu wakati huduma yako inasikiliza kikamilifu kwenye anwani hiyo. Wateja kwenye mitandao ya IPv6 hujaribu jibu la AAAA kwanza, kwa hivyo anwani ambayo haina jibu lolote huongeza muda wa kusubiri katika kila ziara.
• CNAME: jina mbadala kutoka jina moja kwenda jingine. www.example.com. CNAME example.com. huwapeleka wageni wa www kwenye anwani yoyote ile ambayo domain kuu inatatua. CNAME haiwezi kuwepo kwenye apex (domain tupu ya example.com), kwa sababu apex lazima ibebe rekodi zake za SOA (start of authority) na NS, na CNAME hairuhusiwi kushiriki jina na rekodi nyingine yoyote. Watoa huduma hutoa njia mbadala chini ya majina kama ALIAS, ANAME au CNAME flattening.
• MX: mahali ambapo barua pepe za domain hiyo hupelekwa. Hubeba hostname na namba ya upendeleo, na namba ndogo hujaribiwa kwanza. MX lazima ielekeze kwenye jina lenye rekodi ya anwani. Kuelekeza MX kwenye CNAME si sahihi, na baadhi ya seva zinazotuma barua pepe zitakataa hilo.
• TXT: maandishi huru, yanayotumiwa kwa uthibitisho na sera. Rekodi za uthibitishaji wa barua pepe (SPF, DKIM, DMARC) huwekwa hapa, kama ilivyo token ya ACME (automatic certificate management environment) inayotoa cheti cha wildcard.
• NS: ni seva zipi za majina (nameservers) zinazohudumia zone hiyo. Nakala inayoamua mahali ambapo dunia huuliza ipo kwenye zone ya mzazi na inatoka kwenye delegation ya msajili wako, si nakala iliyo ndani ya zone yako mwenyewe.

Maelezo mawili husababisha mkanganyiko zaidi kuliko aina za rekodi zenyewe. Jina linaloishia na nukta ni kamili, kwa hivyo www.example.com. inamaanisha hivyo hasa na si vinginevyo. Paneli nyingi hutegemea jina la jamaa (relative name) na kukuongezea domain yenyewe, kwa hivyo kuandika www.example.com kwenye kisanduku cha jina hukupa www.example.com.example.com, ambayo haitatuliwi kwa mtu yeyote. Maelezo mengine ni @, ambayo katika karibu kila paneli inamaanisha apex: domain yenyewe, bila subdomain yoyote.

Elekeza A record kwenye VPS yako

Kwanza pata anwani ya IP ambayo mtandao unaiona kwa seva yako:

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

Kisha tengeneza record moja kwa mtoa huduma wako wa DNS: aina A, jina @, thamani iwe anwani hiyo, TTL (time to live) 300. Ongeza record ya pili kwa ajili ya www, iwe ni A nyingine yenye anwani ileile au CNAME inayoelekeza kwenye apex.

Sasa thibitisha kuwa inatatua (resolves), ikiwezekana kutoka kwenye laptop yako badala ya seva yenyewe:

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

Amri ya kwanza inatumia njia ya kawaida ya mashine yako, ikiwemo cache. Ya pili inaruka cache ya ndani na kuuliza recursive resolver ya umma. Ya tatu inauliza authoritative nameserver yako moja kwa moja, kwa hivyo jibu lake ni ukweli wa sasa bila cache yoyote njiani. Amri ya tatu ikirudisha anwani yako na ya kwanza isipofanya hivyo, DNS yako imesanidiwa kwa usahihi na unasubiri nakala ya zamani iliyohifadhiwa kwenye cache.

Kutatua tatizo la kutopakia (Resolving)

Kutatua jina la kikoa (name resolving) kunathibitisha kuwa DNS inafanya kazi. Hakuthibitishi chochote kuhusu seva yako ya wavuti. Mara tu dig itakaporejesha anwani sahihi, jaribu muunganisho:

curl -I http://example.com

curl: (6) Could not resolve host: example.com ni tatizo la DNS. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused si tatizo la DNS: jina lilitatuliwa na pakiti ilifika, kwa hivyo tatizo ni kwamba hakuna kilichokuwa kikisikiliza kwenye port hiyo. Ombi linalokwama na kisha kuisha muda wake (timeout) kwa kawaida humaanisha kuwa firewall imedondosha pakiti kimya kimya badala ya kuikataa. Hapo ndipo DNS huacha kuwa mada husika, na ports na listening sockets pamoja na sheria za ufw firewall kwenye VPS yako huchukua nafasi. Baada ya muunganisho kukamilika, sehemu iliyobaki ya upakiaji wa ukurasa ni HTTP ikifanya kazi yake.

Kwa nini kivinjari bado kinaonyesha host ya zamani

Hakuna kitu kinachosambaa (propagate). Hakuna seva inayotuma mabadiliko yako nje kwa mtu yeyote. Nameserver yako yenye mamlaka inashikilia thamani mpya mara tu unapoihifadhi, na kila nakala iliyohifadhiwa (cached) ya jibu la awali inabaki kuwa halali hadi kipima muda chake kitakapomalizika. Kipima muda hicho ni TTL, kwa sekunde, ambacho rekodi ilikuwa nacho ilipotolewa.

Nakala huishi katika maeneo mengi kuliko watu wanavyotarajia: cache fupi ya kivinjari chenyewe, stub resolver kwenye mashine, recursive resolver inayotumiwa na mtandao huo, na resolver yoyote iliyowekwa na VPN kwenye mteja. Kila moja huhifadhi nakala yake hadi kufikia TTL iliyopokea. Watu wawili kwenye mitandao miwili wanaweza kuona majibu mawili tofauti kwa saa kadhaa, na mashine zote mbili zinafanya kazi kwa usahihi.

Fuatilia hesabu ya kurudi nyuma (countdown) dhidi ya caching resolver:

dig @1.1.1.1 example.com +noall +answer

Iendeshe mara mbili, kwa sekunde chache kati ya kila jaribio. TTL katika jibu hupungua. Inapofika sifuri, resolver hutupa rekodi hiyo na kuuliza nameserver yako tena.

Kuna cache ya pili ambayo karibu hakuna mtu anayezingatia: majibu hasi (negative answers). Resolver inapoambiwa kuwa jina halipo, huhifadhi NXDOMAIN hiyo pia, kwa muda uliowekwa na sehemu ya mwisho ya rekodi ya SOA ya zone yako.

dig example.com SOA +short

Namba ya mwisho kwenye mstari huo ni negative TTL, mara nyingi huwa 3600. Kwa hiyo, kutafuta staging.example.com kabla ya kuitengeneza kunaweza kuficha rekodi hiyo kwako kwa saa nzima baada ya kuitengeneza. Tengeneza rekodi kwanza, kisha uifanyie query.

Kubadilisha nameservers ni polepole zaidi kuliko kubadilisha rekodi, na sababu yake ni ya kiufundi. Rekodi za delegation katika zone ya .com hutolewa na TTL ya 172800 sekunde, ambayo ni siku mbili, kwa hivyo resolver iliyohifadhi nameservers zako za zamani inaweza kuendelea kuziuliza kwa muda huo wote. Hapa ndipo ushauri wa "ruhusu hadi saa 48" unapotoka. Inahusu mabadiliko ya nameserver, si mabadiliko ya kawaida ya rekodi.

Panga uhamiaji kulingana na TTL badala ya kuipambana:

1. Punguza TTL ya rekodi hadi 300 na uihifadhi.
2. Subiri muda mrefu zaidi ya TTL ya zamani, ili kila nakala iliyohifadhiwa yenye thamani ya zamani iwe imekwisha muda wake.
3. Badilisha anwani.
4. Trafiki ikishahama, ongeza TTL kurudi 3600 au zaidi, kwa sababu TTL ya chini inamaanisha kila resolver huuliza nameservers zako mara nyingi zaidi.

Ili kufuta kile ambacho mashine yako inashikilia:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics huchapisha sehemu ya cache yenye vihesabio vya hit na miss, kwa hivyo mara tu baada ya kufuta (flush), utafutaji unaofuata huonekana kama miss. Vivinjari huweka cache tofauti, ambayo inamaanisha Chrome bado inaweza kutumia jibu la zamani baada ya cache ya mfumo kuwa tupu. Futa hiyo kwenye chrome://net-internals/#dns. Angalia /etc/hosts pia, kwa sababu mstari ulioachwa hapo hupita DNS kwenye mashine hiyo na kwenye mashine hiyo pekee. getent hosts example.com huonyesha jibu ambalo mfumo utatumia kweli, /etc/hosts ikiwa imejumuishwa.

Vyeti vya wildcard vinathibitishwa kwa kutumia TXT record

Mamlaka ya utoaji vyeti (CA) hukagua umiliki wa jina kabla ya kutoa cheti. Changamoto ya HTTP-01 hutumia faili kupitia port 80 kwenye hostname husika, jambo ambalo hufanya kazi vizuri kwa jina moja. Cheti cha wildcard hufunika *.example.com, mkusanyiko wa hostnames ambao CA haiwezi kupata faili kutoka kwake, kwa hivyo Let's Encrypt hutoa vyeti vya wildcard kupitia changamoto ya DNS-01 pekee. Unachapisha TXT record kwenye _acme-challenge.example.com iliyo na token uliyopewa na CA, na udhibiti wa zone hiyo ndio uthibitisho.

Hii hufanya mtoa huduma wako wa DNS kuwa sehemu ya mchakato wa kusasisha cheti. Certbot lazima itengeneze na kufuta TXT record hiyo kila wakati wa kusasisha bila wewe kuingilia kati, kwa hivyo inahitaji API na plugin inayolingana na mtoa huduma wako. Uthibitishaji unapofeli, ujumbe wa kawaida ni DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com, ambao humaanisha kuwa CA iliuliza kabla ya record kuonekana: aidha haikuhifadhiwa, au jibu hasi lilikuwa bado limehifadhiwa kwenye cache. Utaratibu kamili unapatikana katika mwongozo wa vyeti vya wildcard kwa kutumia changamoto ya DNS-01.

Wakati VPN inapochukua udhibiti wa resolver yako

Mteja wa VPN (virtual private network) kwa kawaida hubadilisha resolver ya mfumo wakati imeunganishwa, kwa sababu kutuma maombi ya utafutaji kwenye mtandao wa ndani kungeufahamisha mtandao huo majina ya kila tovuti unayotembelea. Hiyo ni tabia sahihi, na inashindwa katika pande mbili.

Ikiwa tunnel inafunguka na majina yanaacha kutatuliwa wakati anwani bado zinafanya kazi, resolver iliyowekwa na mteja haipatikani kutoka ndani ya tunnel. ping 1.1.1.1 inafanikiwa na curl https://example.com inarudisha curl: (6) Could not resolve host: example.com. Ikiwa badala yake tunnel inafunguka na utafutaji bado unaenda kwenye mtandao uliopo, trafiki yako inapitishwa kwenye tunnel wakati resolver ya ndani inaendelea kuona kila jina unaloulizia.

resolvectl status

Hiyo huchapisha resolver inayotumika kwa kila link, ili uweze kuona ni ipi tunnel iliyoweka na kama ndiyo uliyokusudia. WireGuard tunnel huweka hili kutoka kwa mstari wa DNS = katika usanidi wa mteja, na kurekebisha DNS wakati WireGuard inapochukua udhibiti wa resolver inashughulikia kesi za systemd-resolved na resolvconf kwa kina.

Misimbo ya majibu, na maana ya kila moja

• NXDOMAIN: seva yenye mamlaka inasema kuwa jina hilo halipo. Hakikisha tahajia ni sahihi, angalia kama kuna kiambishi cha domain kilichorudiwa mara mbili, na uhakikishe kuwa umehariri zone ambayo delegation yako inaelekeza.
• NOERROR ikiwa na ANSWER SECTION tupu: jina lipo, lakini halina rekodi ya aina uliyoiomba. Kuomba AAAA wakati ni A pekee iliyopo husababisha hali hii.
• SERVFAIL: resolver ilijaribu lakini haikuweza kutoa jibu. Sababu mbili za kawaida ni seva zenye mamlaka zisizojibu kabisa, na kufeli kwa uthibitishaji wa DNSSEC (domain name system security extensions). Jaribu kwa kutumia dig @1.1.1.1 example.com A +cd, ambayo huzima uthibitishaji. Jibu linalopatikana kwa +cd na SERVFAIL bila kutumia flag hiyo inamaanisha sahihi (signatures) ndizo tatizo, jambo linalotokea baada ya kuhamisha nameserver ambapo mzazi bado anachapisha rekodi ya zamani ya DS (delegation signer).
• REFUSED: seva uliyoiuliza haitajibu swali hilo, kwa kawaida kwa sababu umeelekeza dig kwenye seva yenye mamlaka kwa domain ambayo haihudumii.
• ;; connection timed out; no servers could be reached: dig haikufika kwenye resolver. Hilo ni tatizo la mtandao au resolver kwa upande wako, kwa hivyo domain yenyewe si chanzo cha tatizo.

ping: example.com: Temporary failure in name resolution ni aina hiyo hiyo ya kufeli inayoripotiwa na glibc badala ya dig.

Je, unapaswa kuendesha nameservers kwenye VPS yako mwenyewe?

Unaweza. bind9, knot au nsd itahudumia zone yako kutoka kwenye seva hiyo, na inakufundisha zaidi kuhusu DNS kuliko paneli yoyote. Pingamizi zake ni za kivitendo. Domain inapaswa kuwa na angalau nameservers mbili kwenye mitandao tofauti, kwa hivyo VPS moja inakuwa sehemu ya kufeli kwa kila huduma kwenye domain hiyo, ikiwemo barua pepe. Nameservers zilizopewa majina ndani ya domain wanayohudumia zinahitaji glue records kwa msajili, ambayo ni anwani ya ns1.example.com iliyohifadhiwa kwenye parent zone, kwa sababu vinginevyo utafutaji hauna njia ya kuanza. Wakati resolver haiwezi kufikia nameserver yako, hairejei kwenye tovuti yako: domain nzima hupotea kwa mtumiaji huyo. DNS inayohudumiwa na mtoa huduma (hosted DNS) yenye API ndiyo chaguo lenye hatari ndogo kwa watu wengi. Kuendesha caching resolver kwenye VPS yako kwa ajili ya mashine zako mwenyewe ni kazi tofauti, na ni jukumu dogo zaidi.

FAQ

Kwa nini mabadiliko yangu ya DNS hayajaonekana bado?

Hakuna kinachosambaa. Seva zako za mamlaka (authoritative nameservers) huhifadhi thamani mpya mara tu unapoiokoa, na kila resolver iliyouliza awali huendelea kutumia nakala yake iliyohifadhiwa (cached) hadi muda wa TTL uliopokelewa utakapokwisha. Uliza seva ya mamlaka moja kwa moja kwa kutumia dig @ns1.your-dns-host.net example.com A +short. Ikiwa itarejesha anwani mpya, mabadiliko yameshafanyika na kilichobaki ni suala la caching tu. Ikiwa ulibadilisha nameservers badala ya rekodi, tarajia kuchukua muda mrefu zaidi, kwa sababu delegation za TLD hutolewa zikiwa na TTL ya siku mbili.

Ninawezaje kujua ni nameservers zipi ambazo domain yangu inatumia kwa sasa?

dig example.com NS +short huchapisha nameservers zinazojibu kwa ajili ya domain hiyo sasa, na dig +trace example.com huonyesha mnyororo wa rufaa (referral chain) kutoka kwenye root, ikijumuisha delegation inayotolewa na seva za TLD. Ikiwa majina hayo si ya mtoa huduma ambaye unahariri paneli yake, hapo ndipo kuna hitilafu yako. Aidha hariri rekodi kwenye mtoa huduma aliyetajwa kwenye delegation, au badilisha delegation kwenye registrar yako ili ielekeze unapotaka.

Domain yangu inatatua (resolves) lakini tovuti haifunguki. Nifanye nini?

Kazi ya DNS huisha mara tu dig example.com A +short inaporejesha anwani ya seva yako. Baada ya hapo, tatizo ni muunganisho. curl -I http://example.com ikirejesha Connection refused inamaanisha hakuna huduma inayosikiliza (listening) kwenye port hiyo. Ombi linalokwama hadi muda wa timeout kuisha inamaanisha firewall imedondosha pakiti hiyo. Hakikisha seva yako ya web inafanya kazi na imefungwa (bound) kwenye anwani ya umma, kisha kagua firewall kwenye seva na firewall ya mtandao iliyo tofauti kwenye paneli ya kudhibiti ya mtoa huduma wako.

Kwa nini siwezi kuweka CNAME kwenye root domain yangu?

CNAME inasema kuwa jina ni mbadala (alias) wa jina lingine, na jina lenye CNAME haliruhusiwi kuwa na rekodi nyingine yoyote. Root domain yako lazima iwe na rekodi za SOA na NS ili iweze kuwepo kama zone, kwa hivyo haiwezi kuwa CNAME pia. Tumia rekodi ya A iliyo na anwani kwenye root, au tumia kipengele cha mtoa huduma kinachouzwa kama ALIAS, ANAME au CNAME flattening, ambacho huhifadhi jina na kujibu maombi kwa anwani ambayo jina hilo inatatua kwa sasa.