DNS అంటే ఏమిటి? VPS యజమాని గైడ్

DNS అంటే ఏమిటి? మీ domain ఇంకా మీ VPS కు ఎందుకు చేరడం లేదు?

DNS (domain name system) అనేది example.com వంటి పేరును 203.0.113.10 వంటి IP (internet protocol) address గా మార్చుతుంది. Browser ఒక పేరుకు నేరుగా connect కాలేదు. అది address కు connect అవుతుంది. అందువల్ల ప్రతి page load ముందు DNS question మరియు answer జరుగుతాయి. మీరు ఇప్పుడే ఒక domain ను, అలాగే మీ స్వంత VPS ను కొనుగోలు చేసి ఉంటే, ఏదీ load కాకపోవడానికి రెండు కారణాల్లో ఒకటి ఉంటుంది: పేరు మీ server address కు connect చేసే record ఇంకా లేదు, లేదా record ఉన్నప్పటికీ మార్గంలోని ఏదో భాగం ఇప్పటికీ పాత answer ను అందిస్తోంది.

ఈ రెండు పరిస్థితులు సాధారణమే. వాటిలో ఏదీ ఏదో విరిగిపోయిందని అర్థం కాదు. దిగువ sections లో మీరు ఎదుర్కొనే క్రమంలో అంశాలను పరిశీలిస్తాం. ఎక్కువ సమయం వృథా చేసే అంశంతో ప్రారంభిస్తాం: మీ records ను వాస్తవంగా ఏ control panel నిర్వహిస్తోంది?

ఇక్కడ ప్రతి check కోసం dig ఉపయోగించబడుతుంది. ఇది కొత్త Ubuntu లేదా Debian machine లో default గా install అయి ఉండదు.

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

Registrar, nameservers, DNS host: దేనిలో మార్పు చేయాలి

ఈ మూడు పదాలు వేర్వేరు బాధ్యతలను సూచిస్తాయి. వీటిని కలిపి చూడటం వల్ల చేసిన మార్పు ప్రభావం చూపకపోవడం చాలా సాధారణం.

• registrar అంటే మీరు domain కొనుగోలు చేసిన సంస్థ. దాని ముఖ్యమైన పని delegation. మీ TLD (top-level domain, అంటే .com భాగం) ను నిర్వహించే registryకి, మీ domain కు ఏ nameservers authoritative గా ఉన్నాయో అది తెలియజేస్తుంది.
• authoritative nameservers మీ zone కు సంబంధించిన అసలు records ను కలిగి ఉంటాయి. Zone అంటే మీ domain మరియు దాని కింద ఉన్న పేర్లు.
• DNS host అంటే ఆ nameservers ను నిర్వహించే సంస్థ లేదా వ్యవస్థ. అది registrar కావచ్చు, వేరే provider కావచ్చు లేదా మీరు నిర్వహించే server పై నడుస్తున్న bind9 కావచ్చు.

మీరు domain ను registrar వద్ద కొనుగోలు చేస్తారు. DNS host వద్ద records ను మార్చుతారు. మీ domain ను మరో provider యొక్క nameservers కు మార్చినట్లయితే, registrar యొక్క DNS panel లో ఇప్పటికీ ఒక zone కనిపిస్తుంది. మీరు చేసిన మార్పులను అది ఇప్పటికీ save చేస్తుంది. కానీ internet లోని ఏ వ్యవస్థ కూడా ఆ zone ను ప్రశ్నించదు. ఆ records నిజమైనవే. అయితే వాటిని ఎవరూ ఉపయోగించరు.

ప్రపంచం ఏ nameservers ను ప్రశ్నిస్తుందో తెలుసుకోండి:

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

మొదటి command ప్రస్తుతం ఆ domain కు సమాధానమిస్తున్న nameservers ను చూపిస్తుంది. రెండవది root servers నుండి ప్రారంభమయ్యే chain ను అనుసరించి, TLD servers అందించే referral ను చూపిస్తుంది. ఇదే మీ registrar నియంత్రించే delegation. ఆ nameservers పేర్లు మీకు తెలియని provider కు చెందినవిగా ఉంటే, మీరు ఉపయోగించాల్సిన panel ఆ provider వద్ద ఉంటుంది.

ఒక lookup ఎలా ప్రయాణిస్తుంది

ఇందులో నాలుగు పక్షాలు పాల్గొంటాయి. ప్రతి పక్షం తాను తెలుసుకున్న సమాచారానికి ఒక copy ను ఉంచుతుంది.

1. మీ machine పై ఉన్న stub resolver. ఇది searching చేయదు. Configured చేసిన ఒక server ను అడిగి, వచ్చిన reply ను నమ్ముతుంది. Ubuntu లో /etc/resolv.conf సాధారణంగా /run/systemd/resolve/stub-resolv.conf కు symlink గా ఉంటుంది. ఇది స్థానికంగా స్వంత cache తో నడిచే systemd-resolved అయిన 127.0.0.53 ను సూచిస్తుంది.
2. recursive resolver. ఇది మీ ISP (internet service provider) నిర్వహించే resolver కావచ్చు. 1.1.1.1 వంటి public resolver కావచ్చు. మీరు స్వయంగా నడిపేది కావచ్చు. Answer ను కనుగొనే అసలు పనిని ఇది చేస్తుంది.
3. root మరియు TLD servers. Recursive resolver ఒక root server ను అడుగుతుంది. ఆ root server కు మీ address తెలియదు. కానీ .com servers కు referral ను పంపుతుంది. ఆ servers మీ nameservers కు referral ను పంపుతాయి.
4. authoritative nameserver. ఇది మరెవరినీ అడగదు. మీ zone నుంచి answer ఇచ్చి, అది authoritative అని గుర్తిస్తుంది.

dig +trace example.com ఈ ప్రక్రియను మీకు చూపిస్తుంది. ఎందుకంటే ఇది root నుంచే ప్రారంభమై, cache ను అడగకుండా ప్రతి referral ను print చేస్తుంది. Delegation మరియు zone పరస్పరం సరిపోతున్నాయా చూడటానికి ఇదే వేగవంతమైన మార్గం.

సర్వర్‌ను నడిపేటప్పుడు ముఖ్యమైన DNS records

• A: name ను IPv4 address కు అనుసంధానిస్తుంది. example.com. A 203.0.113.10. ఇది మీ domain ను మీ VPS కు point చేసే record.
• AAAA: name ను IPv6 address కు, ఉదాహరణకు 2001:db8::10 కు, అనుసంధానిస్తుంది. మీ service నిజంగా ఆ address పై listen చేస్తున్నప్పుడు మాత్రమే దీన్ని publish చేయండి. IPv6 network లలోని clients ముందుగా AAAA answer ను ప్రయత్నిస్తాయి. ఏ service స్పందించని address ను ఇవ్వడం వల్ల ప్రతి visit కు ఆలస్యం ఏర్పడుతుంది.
• CNAME: ఒక name నుంచి మరొక name కు alias. www.example.com. CNAME example.com., www ను సందర్శించే visitors ను bare domain resolve అయ్యే స్థానానికి పంపుతుంది. apex (bare example.com) వద్ద CNAME ఉండదు. కారణం, apex వద్ద దాని స్వంత SOA (start of authority) మరియు NS records ఉండాలి. అలాగే CNAME అదే name తో మరే ఇతర record తోనూ ఉండకూడదు. Providers ALIAS, ANAME లేదా CNAME flattening వంటి పేర్లతో ప్రత్యామ్నాయాలను అందిస్తాయి.
• MX: domain కు సంబంధించిన mail ఎక్కడ deliver చేయాలో సూచిస్తుంది. ఇందులో hostname మరియు preference number ఉంటాయి. తక్కువ number ను ముందుగా ప్రయత్నిస్తారు. MX, address record కలిగిన name ను సూచించాలి. CNAME ను సూచించడం చెల్లదు. కొన్ని sending servers దాన్ని reject చేస్తాయి.
• TXT: proof మరియు policy కోసం ఉపయోగించే free text. Mail authentication records (SPF, DKIM, DMARC) ఇక్కడ ఉంటాయి. wildcard certificate ను issue చేసే ACME (automatic certificate management environment) token కూడా ఇక్కడే ఉంటుంది.
• NS: zone కు ఏ nameservers సేవలందిస్తున్నాయో సూచిస్తుంది. ప్రపంచం ఎక్కడ query చేయాలో నిర్ణయించే copy parent zone లో ఉంటుంది. అది మీ registrar delegation నుంచి వస్తుంది, మీ స్వంత zone లోని copy నుంచి కాదు.

Record types కంటే రెండు వివరాలే ఎక్కువ గందరగోళానికి కారణమవుతాయి. Dot తో ముగిసే name absolute అవుతుంది. అందువల్ల www.example.com. అంటే అదే, అంతకుమించి ఏదీ కాదు. చాలా panels relative name ను ఆశించి, domain ను మీ కోసం చివర జతచేస్తాయి. కాబట్టి name box లో www.example.com టైప్ చేస్తే www.example.com.example.com లభిస్తుంది. ఇది ఎవరికీ resolve కాదు. మరో విషయం @. దాదాపు ప్రతి panel లో ఇది apex ను సూచిస్తుంది: subdomain లేకుండా ఉన్న domain ను.

మీ VPS కు A రికార్డ్‌ను చూపించండి

మొదట మీ సర్వర్ కోసం ఇంటర్నెట్‌కు కనిపించే చిరునామాను పొందండి:

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

తర్వాత మీ DNS హోస్ట్ వద్ద ఒక రికార్డ్ సృష్టించండి: రకం A, పేరు @, విలువగా ఆ చిరునామా, TTL (time to live) 300. www కోసం రెండవ రికార్డ్‌ను జోడించండి. అదే చిరునామాతో మరో A రికార్డ్‌ను ఉపయోగించవచ్చు లేదా apex ను సూచించే CNAME రికార్డ్‌ను ఉపయోగించవచ్చు.

ఇప్పుడు అది resolve అవుతోందని నిర్ధారించండి. సాధ్యమైనప్పుడు సర్వర్‌ నుంచే కాకుండా మీ laptop నుంచి పరీక్షించండి:

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

మొదటి కమాండ్ మీ machine యొక్క సాధారణ మార్గాన్ని, cacheలతో సహా, ఉపయోగిస్తుంది. రెండవ కమాండ్ మీ local cache ను దాటి public recursive resolver ను అడుగుతుంది. మూడవ కమాండ్ మీ authoritative nameserver ను నేరుగా అడుగుతుంది. అందువల్ల మార్గంలో ఎక్కడా cache లేకుండా ప్రస్తుత నిజమైన సమాధానాన్ని అందిస్తుంది. మూడవ కమాండ్ మీ చిరునామాను చూపించి, మొదటి కమాండ్ చూపించకపోతే, మీ DNS సరిగ్గా configure అయింది. మీరు పాత సమాధానం యొక్క cached copy తొలగే వరకు వేచి ఉండాలి.

పేరు పరిష్కారం పనిచేస్తోంది, కానీ లోడ్ కావడం లేదు

పేరు పరిష్కారం విజయవంతమైతే DNS పనిచేస్తోందని నిర్ధారించవచ్చు. కానీ మీ web server గురించి దాంతో ఏమీ నిర్ధారించలేం. dig సరైన address ను చూపించిన తర్వాత, connection ను పరీక్షించండి:

curl -I http://example.com

curl: (6) Could not resolve host: example.com DNS సమస్య. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused DNS సమస్య కాదు: పేరు పరిష్కరించబడింది, packet చేరుకుంది. కాబట్టి ఆ port పై ఏదీ listening లో లేకపోవడమే సమస్య. ఒక request కొంతసేపు నిలిచిపోయి, చివరికి timeout అయితే, packet ను firewall నిశ్శబ్దంగా drop చేసిందని సాధారణంగా అర్థం; connection ను refuse చేయలేదు. ఇక్కడితో DNS సంబంధిత పరిశీలన ముగుస్తుంది. తరువాత ports మరియు listening sockets, అలాగే మీ VPS లోని ufw firewall rules ముఖ్యమవుతాయి. Connection పూర్తయిన తర్వాత, page load లో మిగిలిన పని HTTP తన విధంగా నిర్వహిస్తుంది.

బ్రౌజర్‌లో ఇప్పటికీ పాత host ఎందుకు కనిపిస్తోంది

ఏదీ స్వయంచాలకంగా వ్యాప్తి చెందదు. మీరు చేసిన మార్పును ఏ server కూడా ఇతరులకు బయటకు పంపదు. మీరు save చేసిన వెంటనే authoritative nameserver కొత్త విలువను కలిగి ఉంటుంది. అయితే మునుపటి సమాధానం యొక్క ప్రతి cached copy తన స్వంత timer ముగిసే వరకు చెల్లుబాటులో ఉంటుంది. ఆ timer ను TTL అంటారు. ఇది record పంపిణీ చేసినప్పుడు దానితో ఉన్న seconds విలువ.

ప్రజలు ఊహించిన దానికంటే ఎక్కువ ప్రదేశాల్లో copies ఉంటాయి: browser యొక్క స్వంత short cache, machine పై ఉన్న stub resolver, ఆ network ఉపయోగించే recursive resolver, అలాగే client పై VPN install చేసిన resolver. ప్రతి component తాను అందుకున్న TTL వరకు తన copy ని ఉంచుతుంది. రెండు networks లో ఉన్న ఇద్దరు వ్యక్తులకు గంటలపాటు రెండు వేర్వేరు సమాధానాలు కనిపించవచ్చు. అయినా రెండు machines కూడా సరిగానే పనిచేస్తుంటాయి.

Caching resolver వద్ద countdown ను పరిశీలించండి:

dig @1.1.1.1 example.com +noall +answer

దీన్ని కొన్ని seconds విరామంతో రెండుసార్లు run చేయండి. Answer లోని TTL తగ్గుతుంది. అది zero కు చేరినప్పుడు resolver record ను తొలగించి, మీ nameserver ను మళ్లీ అడుగుతుంది.

దాదాపు ఎవరూ పరిగణనలోకి తీసుకోని మరో cache ఉంది: negative answers. ఒక పేరు ఉనికిలో లేదని resolver కు తెలియజేసినప్పుడు, అది ఆ NXDOMAIN ను కూడా cache చేస్తుంది. ఈ వ్యవధి మీ zone యొక్క SOA record లోని చివరి field ద్వారా నిర్ణయించబడుతుంది.

dig example.com SOA +short

ఆ line లోని చివరి number negative TTL. ఇది తరచుగా 3600 ఉంటుంది. కాబట్టి staging.example.com ను మీరు create చేయడానికి ముందు lookup చేస్తే, create చేసిన తర్వాత కూడా ఆ record ఒక పూర్తి గంటపాటు మీకు కనిపించకపోవచ్చు. ముందుగా record ను create చేసి, తరువాత query చేయండి.

Nameserverలను మార్చడం, record ను మార్చడం కంటే నెమ్మదిగా జరుగుతుంది. దీనికి కారణం సాంకేతికంగా స్పష్టంగా ఉంటుంది. .com zone లోని delegation records 172800 seconds TTL తో serve అవుతాయి. ఇది two days కు సమానం. అందువల్ల మీ పాత nameservers ను cache చేసిన resolver, ఆ వ్యవధి వరకు వాటినే అడుగుతూ ఉండవచ్చు. “allow up to 48 hours” అనే సూచనకు కారణం ఇదే. ఇది nameserver మార్పులకు వర్తిస్తుంది, సాధారణ record edits కు కాదు.

దానితో పోరాడటానికి బదులుగా TTL ఆధారంగా migration ను ప్రణాళిక చేయండి:

1. Record యొక్క TTL ను 300 కు తగ్గించి save చేయండి.
2. పాత TTL కంటే ఎక్కువసేపు వేచి ఉండండి. అప్పుడు పాత విలువను కలిగి ఉన్న ప్రతి cached copy expire అవుతుంది.
3. Address ను మార్చండి.
4. Traffic మారిన తర్వాత TTL ను మళ్లీ 3600 లేదా అంతకంటే ఎక్కువకు పెంచండి. తక్కువ TTL ఉంటే ప్రతి resolver మీ nameservers ను చాలా తరచుగా అడుగుతుంది.

మీ స్వంత machine లో ఉన్న cache ను clear చేయడానికి:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics hit మరియు miss counters తో కూడిన cache section ను print చేస్తుంది. అందువల్ల flush చేసిన వెంటనే చేసే తదుపరి lookup miss గా కనిపిస్తుంది. Browsers ప్రత్యేకమైన cache ను ఉంచుతాయి. అంటే system cache ఖాళీ అయిన తర్వాత కూడా Chrome పాత answer ను ఉపయోగించవచ్చు. ఆ cache ను chrome://net-internals/#dns వద్ద clear చేయండి. /etc/hosts ను కూడా తనిఖీ చేయండి. అక్కడ మిగిలిన line ఉంటే, ఆ machine పై DNS కంటే దానికే ప్రాధాన్యం లభిస్తుంది. getent hosts example.com system నిజంగా ఉపయోగించే answer ను చూపుతుంది; ఇందులో /etc/hosts కూడా ఉంటుంది.

Wildcard certificates TXT record ద్వారా నిరూపించబడతాయి

CA (certificate authority) ఒక certificate జారీ చేయడానికి ముందు, ఆ name పై మీ నియంత్రణను తనిఖీ చేస్తుంది. HTTP-01 challenge ద్వారా port 80 పై అదే hostname కోసం ఒక file అందించబడుతుంది. ఇది ఒకే name కోసం బాగా పనిచేస్తుంది. Wildcard certificate *.example.com ను కవర్ చేస్తుంది. ఇది CA file ను fetch చేయలేని, ముందే నిర్దేశించలేని అనేక hostnames సమూహం. అందువల్ల Let's Encrypt wildcard certificates ను DNS-01 challenge ద్వారా మాత్రమే జారీ చేస్తుంది. మీరు _acme-challenge.example.com వద్ద CA ఇచ్చిన token ఉన్న TXT record ను publish చేయాలి. ఆ zone పై మీ నియంత్రణే దీనికి ఆధారం.

దీంతో certificate renewal లో మీ DNS host కూడా భాగమవుతుంది. ప్రతి renewal సమయంలో Certbot మీ ప్రమేయం లేకుండా ఆ TXT record ను create చేసి delete చేయాలి. అందుకు మీ provider కోసం API మరియు దానికి సరిపడే plugin అవసరం. Validation విఫలమైనప్పుడు సాధారణంగా DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com అనే message కనిపిస్తుంది. అంటే record కనిపించకముందే CA దాన్ని అడిగిందని అర్థం. Record save కాలేకపోయి ఉండవచ్చు లేదా negative answer ఇంకా cache అయి ఉండవచ్చు. పూర్తి విధానం DNS-01 challenge తో wildcard certificates పై guide లో ఉంది.

VPN మీ resolver ను స్వాధీనం చేసుకున్నప్పుడు

VPN (virtual private network) client కనెక్ట్ అయి ఉన్నప్పుడు సాధారణంగా system resolver ను భర్తీ చేస్తుంది. ఎందుకంటే lookups ను local network కు పంపితే, మీరు సందర్శించే ప్రతి site పేరు ఆ network కు తెలుస్తుంది. ఇది సరైన ప్రవర్తనే. అయితే ఇది రెండు విధాలుగా విఫలమవుతుంది.

Tunnel ప్రారంభమైన తర్వాత names resolve కాకపోయినా addresses పనిచేస్తే, client install చేసిన resolver ను tunnel లోపల నుంచి చేరుకోలేము. ping 1.1.1.1 విజయవంతమవుతుంది, curl https://example.com curl: (6) Could not resolve host: example.com ను తిరిగి ఇస్తుంది. మరోవైపు, tunnel ప్రారంభమైనా lookups మీరు కనెక్ట్ అయి ఉన్న network కు వెళ్లుతూనే ఉంటే, మీ traffic tunnel ద్వారా వెళ్తుంది. కానీ local resolver మీరు అడిగే ప్రతి name ను ఇప్పటికీ చూస్తుంది.

resolvectl status

ఇది ప్రతి link కోసం ఉపయోగంలో ఉన్న resolver ను చూపిస్తుంది. అందువల్ల tunnel ఏ resolver ను install చేసిందో, అది మీరు ఉద్దేశించిన resolver అవునో కాదో చూడవచ్చు. WireGuard tunnel client config లోని DNS = line నుంచి దీన్ని సెట్ చేస్తుంది. WireGuard resolver ను స్వాధీనం చేసుకున్నప్పుడు DNS ను సరిచేయడం లో systemd-resolved మరియు resolvconf సందర్భాలను వివరంగా చూడవచ్చు.

ప్రత్యుత్తర కోడ్‌లు, ప్రతి కోడ్ తెలిపే విషయం

• NXDOMAIN: పేరు ఉనికిలో లేదని authoritative server చెబుతోంది. స్పెల్లింగ్‌ను తనిఖీ చేయండి, domain suffix రెండుసార్లు నమోదు కాలేదో చూడండి, అలాగే మీ delegation సూచించే zone నే మీరు సవరించారో నిర్ధారించండి.
• NOERROR ఖాళీ ANSWER SECTIONతో వస్తే: పేరు ఉనికిలో ఉంది, కానీ మీరు అడిగిన రకానికి సంబంధించిన record లేదు. A మాత్రమే ఉన్నప్పుడు AAAA కోసం అడిగితే ఇదే ఫలితం వస్తుంది.
• SERVFAIL: resolver ప్రయత్నించినా సమాధానం ఇవ్వలేకపోయింది. సాధారణంగా దీనికి రెండు కారణాలు ఉంటాయి: authoritative servers ఎప్పుడూ reply ఇవ్వకపోవడం, లేదా DNSSEC (domain name system security extensions) validation విఫలమవడం. validation ను నిలిపివేసే dig @1.1.1.1 example.com A +cdతో పరీక్షించండి. దాన్ని ఉపయోగించినప్పుడు +cd మరియు SERVFAILతో సమాధానం వస్తే, సమస్య signatures లో ఉందని అర్థం. nameserver మార్చిన తర్వాత parent వద్ద పాత DS (delegation signer) record ఇంకా publish అవుతున్నప్పుడు ఇది జరుగుతుంది.
• REFUSED: మీరు అడిగిన server ఆ ప్రశ్నకు సమాధానం ఇవ్వదు. సాధారణంగా, అది serve చేయని domain కోసం digను authoritative server కు సూచించినప్పుడు ఇలా జరుగుతుంది.
• ;; connection timed out; no servers could be reached: dig ఏ resolver ను చేరుకోలేకపోయింది. ఇది మీ వైపు ఉన్న network లేదా resolver సమస్య. కాబట్టి domain దీనికి కారణం కాదు.

ping: example.com: Temporary failure in name resolution అనేది dig బదులుగా glibc నివేదించే ఇదే తరగతి వైఫల్యం.

మీ స్వంత VPSలో nameserverలను నడపాలా?

మీరు నడపవచ్చు. bind9, knot లేదా nsd మీ server నుంచే మీ zoneను అందిస్తాయి. ఏ control panel కంటే ఇవి DNS గురించి మీకు ఎక్కువగా నేర్పుతాయి. అయితే అభ్యంతరాలు ఆచరణాత్మకమైనవి. ఒక domainకు కనీసం రెండు nameserverలు వేర్వేరు networkలలో ఉండాలి. అందువల్ల ఒకే VPSపై ఆధారపడితే, mailతో సహా ఆ domainలోని ప్రతి serviceకు అది ఒకే వైఫల్య కేంద్రంగా మారుతుంది. తాము అందిస్తున్న domain పేరులోనే ఉన్న nameserverలకు registrar వద్ద glue recordలు అవసరం. ఆ recordలో parent zoneలో నిల్వ చేసిన ns1.example.com చిరునామా ఉంటుంది. లేకపోతే lookup ప్రారంభించడానికి మార్గం ఉండదు. Resolver మీ nameserverను చేరుకోలేకపోతే, అది మీ websiteకు fallback కాదు. ఆ వినియోగదారుకు మొత్తం domain కనిపించదు. చాలా మందికి API కలిగిన hosted DNS తక్కువ-ప్రమాదకరమైన ఎంపిక. మీ స్వంత machineల కోసం VPSలో caching resolver నడపడం వేరే పని. దానికి అవసరమైన బాధ్యత కూడా చాలా తక్కువ.

FAQ

నా DNS మార్పు ఇంకా propagate ఎందుకు కాలేదు?

ఏదీ propagate కాదు. మీరు విలువను save చేసిన వెంటనే authoritative nameservers కొత్త విలువను ఉంచుతాయి. ఇప్పటికే ప్రశ్న పంపిన ప్రతి resolver, తనకు లభించిన TTL ముగిసే వరకు cached copy ను ఉపయోగిస్తుంది. dig @ns1.your-dns-host.net example.com A +short తో authoritative server ను నేరుగా అడగండి. అది కొత్త address ను తిరిగి ఇస్తే, మార్పు అమలులో ఉంది. మిగిలింది caching మాత్రమే. మీరు records కు బదులుగా nameservers మార్చితే, ఎక్కువ సమయం పడుతుందని భావించండి. TLD delegations రెండు రోజుల TTL తో అందించబడతాయి.

నా domain ప్రస్తుతం ఏ nameservers ను ఉపయోగిస్తుందో ఎలా తెలుసుకోవాలి?

dig example.com NS +short ప్రస్తుతం ఆ domain కు సమాధానం ఇస్తున్న nameservers ను చూపిస్తుంది. dig +trace example.com root నుంచి వచ్చే referral chain ను చూపిస్తుంది. ఇందులో TLD servers అందించే delegation కూడా ఉంటుంది. ఆ names పేర్లు మీరు panel లో సవరించిన provider కు చెందినవి కాకపోతే, సమస్య అదే. Delegation లో పేర్కొన్న provider వద్ద records ను సవరించండి. లేదా మీకు కావలసిన ప్రదేశాన్ని చూపించేలా registrar వద్ద delegation ను మార్చండి.

నా domain resolve అవుతోంది, కానీ site ఇంకా load కావడం లేదు. ఇప్పుడు ఏమి చేయాలి?

dig example.com A +short మీ server address ను తిరిగి ఇచ్చిన వెంటనే DNS పని పూర్తవుతుంది. ఆ తర్వాత సమస్య connection లో ఉంటుంది. curl -I http://example.com, Connection refused ను తిరిగి ఇస్తే, ఆ port పై ఏదీ listening చేయడం లేదని అర్థం. మీ web server నడుస్తోందో, public address కు bind అయిందో తనిఖీ చేయండి. తరువాత server లోని firewall ను, అలాగే provider control panel లోని ప్రత్యేక network firewall ను తనిఖీ చేయండి.

నా root domain పై CNAME ఎందుకు పెట్టలేను?

CNAME ఒక name మరొక name కు alias అని చెబుతుంది. CNAME ఉన్న name వద్ద ఇతర records ఉండకూడదు. మీ root domain zone గా ఉండటానికి SOA మరియు NS records కలిగి ఉండాలి. అందువల్ల అది CNAME కూడా కాలేదు. Root వద్ద address ను ఉంచే A record ను ఉపయోగించండి. లేదా ALIAS, ANAME లేదా CNAME flattening పేర్లతో అందించే provider feature ను ఉపయోగించండి. ఇది ఒక name ను నిల్వ చేసి, ఆ name ప్రస్తుతం resolve అయ్యే address తో queries కు సమాధానం ఇస్తుంది.