DNS என்றால் என்ன? உங்கள் VPS-க்கு domain-ஐ இணைப்பது எப்படி

DNS என்றால் என்ன, உங்கள் domain ஏன் இன்னும் உங்கள் VPS-ஐ அடையவில்லை

DNS (domain name system) என்பது example.com போன்ற ஒரு பெயரை 203.0.113.10 போன்ற ஒரு IP (internet protocol) முகவரியாக மாற்றுகிறது. ஒரு browser-ஆல் நேரடியாக ஒரு பெயருடன் இணைய முடியாது. அது ஒரு முகவரியுடன் மட்டுமே இணையும், எனவே ஒவ்வொரு பக்கமும் ஏற்றப்படும்போது DNS வினவலும் (question) அதற்குரிய பதிலும் (answer) முதலில் நிகழும். நீங்கள் ஒரு domain-ஐயும், சொந்தமான VPS-ஐயும் புதிதாக வாங்கியிருந்து, எதுவும் இயங்கவில்லை என்றால், இரண்டு காரணங்களில் ஒன்று உண்மையாக இருக்கலாம்: உங்கள் பெயரையும் server முகவரியையும் இணைக்கும் record இன்னும் உருவாக்கப்படவில்லை, அல்லது ஒரு record இருந்தாலும், வழியில் உள்ள ஏதோ ஒன்று பழைய பதிலை இன்னும் வழங்கி வருகிறது.

இந்த இரண்டு சூழல்களும் இயல்பானவை, எதிலும் எந்தப் பாதிப்பும் இல்லை. கீழே உள்ள பகுதிகள், நீங்கள் எதிர்கொள்ளும் வரிசையில் இந்தச் சிக்கல்களை விளக்குகின்றன. அதிக நேரத்தை வீணடிக்கும் சிக்கலான, எந்த control panel-ல் உங்கள் records உள்ளன என்பதைக் கண்டறிவதில் இருந்து தொடங்குவோம்.

இங்குள்ள ஒவ்வொரு சோதனையும் dig-ஐப் பயன்படுத்துகிறது. இது புதிய Ubuntu அல்லது Debian கணினிகளில் இயல்பாக நிறுவப்பட்டிருக்காது.

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-க்கான உண்மையான பதிவுகளைக் கொண்டிருக்கும். Zone என்பது உங்கள் domain மற்றும் அதன் கீழ் உள்ள பெயர்களைக் குறிக்கும்.
• DNS host என்பது அந்த nameservers-ஐ இயக்கும் நிறுவனம். இது registrar-ஆக இருக்கலாம், தனிப்பட்ட provider-ஆக இருக்கலாம், அல்லது நீங்கள் சொந்தமாக வைத்திருக்கும் server-ல் இயங்கும் bind9 ஆகவும் இருக்கலாம்.

நீங்கள் registrar-இடம் domain வாங்குகிறீர்கள். ஆனால், DNS host-இடம் மாற்றங்களைச் செய்கிறீர்கள். உங்கள் domain-ஐ மற்றொரு provider-ன் nameservers-க்கு மாற்றியிருந்தால், registrar-ன் சொந்த DNS panel-ல் zone இன்னும் காட்டப்படலாம், நீங்கள் செய்யும் மாற்றங்களை அது சேமிக்கலாம், ஆனால் இணையத்தில் யாரும் அந்த zone-ஐ அணுக மாட்டார்கள். அந்தப் பதிவுகள் உண்மையானவைதான், ஆனால் அவை ஒருபோதும் பயன்படுத்தப்படுவதில்லை.

இணையம் எங்கே வினவுகிறது என்பதைக் கண்டறியவும்:

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

முதல் கட்டளை, இன்று அந்த domain-க்கு பதிலளிக்கும் nameservers-ஐக் காட்டும். இரண்டாவது கட்டளை, root servers-ல் தொடங்கி TLD servers வழங்கும் referral வரை உள்ள சங்கிலியைப் பின்பற்றி, உங்கள் registrar கட்டுப்படுத்தும் delegation-ஐக் காட்டும். அந்தப் பெயர்கள் உங்களுக்குத் தெரியாத ஒரு provider-க்குச் சொந்தமானவை என்றால், அந்த provider-ன் panel-ல்தான் நீங்கள் மாற்றங்களைச் செய்ய வேண்டும்.

ஒரு lookup எவ்வாறு செயல்படுகிறது

இதில் நான்கு தரப்பினர் ஈடுபட்டுள்ளனர், ஒவ்வொருவரும் தாங்கள் அறிந்துகொண்ட தகவலை நகல் எடுத்து வைத்துக்கொள்கிறார்கள்.

1. உங்கள் கணினியில் உள்ள stub resolver. இது எந்த தேடலையும் செய்வதில்லை. இது கட்டமைக்கப்பட்ட ஒரு server-ஐ அணுகி, அது தரும் பதிலை அப்படியே நம்புகிறது. Ubuntu-வில், /etc/resolv.conf என்பது பொதுவாக /run/systemd/resolve/stub-resolv.conf-க்கு ஒரு symlink ஆகும். இது 127.0.0.53-ஐக் குறிப்பிடுகிறது; இது உள்ளூர் cache-உடன் இயங்கும் systemd-resolved ஆகும்.
2. recursive resolver. இது உங்கள் ISP (internet service provider) மூலம் இயக்கப்படும் resolver, அல்லது 1.1.1.1 போன்ற பொதுவான சேவை, அல்லது நீங்களே இயக்கும் ஒன்றாக இருக்கலாம். விடையைக் கண்டறியும் உண்மையான வேலையை இதுவே செய்கிறது.
3. root மற்றும் TLD servers. recursive resolver ஒரு root server-ஐ அணுகுகிறது. அதற்கு உங்கள் முகவரி தெரியாது, ஆனால் அது .com server-களுக்கான referral-ஐ வழங்கும். அவை உங்கள் nameserver-களுக்கான referral-ஐ வழங்கும்.
4. authoritative nameserver. இது யாரிடமும் கேட்பதில்லை. இது உங்கள் zone-லிருந்து விடையளித்து, அந்தப் பதிலை authoritative எனக் குறிக்கும்.

dig +trace example.com இது எவ்வாறு நடக்கிறது என்பதைக் காட்டுகிறது. ஏனெனில் இது root-லிருந்து தொடங்கி, cache-ஐ அணுகுவதற்குப் பதிலாக ஒவ்வொரு referral-ஐயும் அச்சிடுகிறது. delegation மற்றும் zone ஆகியவை ஒத்துப்போகிறதா என்பதைச் சரிபார்க்க இதுவே மிக வேகமான வழியாகும்.

சர்வரை இயக்கும்போது கவனிக்க வேண்டிய DNS பதிவுகள்

• A: ஒரு பெயரை IPv4 முகவரியுடன் இணைக்கும் பதிவு. example.com. A 203.0.113.10. உங்கள் டொமைனை VPS-உடன் இணைக்க இந்தப் பதிவு பயன்படுகிறது.
• AAAA: ஒரு பெயரை IPv6 முகவரியுடன் இணைக்கும் பதிவு, உதாரணமாக 2001:db8::10. உங்கள் சேவை அந்த முகவரியில் இயங்கினால் மட்டுமே இதைப் பதிவிடவும். IPv6 நெட்வொர்க்கில் உள்ள வாடிக்கையாளர்கள் முதலில் AAAA பதிவையே சோதிப்பார்கள்; எனவே, பதிலளிக்காத முகவரியைக் கொடுத்தால் ஒவ்வொரு முறையும் இணைப்பு தாமதமாகும்.
• CNAME: ஒரு பெயரை மற்றொரு பெயருக்கு மாற்றும் alias. www.example.com. CNAME example.com., www-க்கு வரும் பயனர்களை அந்த டொமைன் எங்கு சுட்டிக்காட்டுகிறதோ அங்கு அனுப்பும். CNAME-ஐ apex-ல் (வெற்று டொமைன் example.com) வைக்க முடியாது, ஏனெனில் apex-ல் கட்டாயம் SOA (start of authority) மற்றும் NS பதிவுகள் இருக்க வேண்டும்; CNAME-ஐ மற்ற எந்தப் பதிவுகளுடனும் ஒரே பெயரில் வைத்திருக்க அனுமதி இல்லை. சேவை வழங்குநர்கள் இதற்கு மாற்றாக ALIAS, ANAME அல்லது CNAME flattening போன்ற வசதிகளை வழங்குகிறார்கள்.
• MX: டொமைனுக்கான மின்னஞ்சல்கள் எங்கு செல்ல வேண்டும் என்பதை இது தீர்மானிக்கிறது. இதில் hostname மற்றும் முன்னுரிமை எண் (preference number) இருக்கும்; குறைந்த எண் கொண்ட முகவரிக்கே முன்னுரிமை அளிக்கப்படும். MX பதிவு, முகவரிப் பதிவு (address record) கொண்ட ஒரு பெயரை மட்டுமே சுட்டிக்காட்ட வேண்டும். CNAME-ஐ சுட்டிக்காட்டுவது தவறானது, அவ்வாறு செய்தால் சில மின்னஞ்சல் சேவையகங்கள் அதை நிராகரித்துவிடும்.
• TXT: சரிபார்ப்பு மற்றும் கொள்கைகளுக்காகப் பயன்படுத்தப்படும் கட்டற்ற உரை (free text). மின்னஞ்சல் அங்கீகாரப் பதிவுகள் (SPF, DKIM, DMARC) மற்றும் wildcard certificate-ஐப் பெற உதவும் ACME (automatic certificate management environment) டோக்கன்கள் இதில் சேமிக்கப்படும்.
• NS: அந்த zone-ஐ நிர்வகிக்கும் nameservers-களை இது குறிக்கும். உலகம் எங்கு வினவ வேண்டும் என்பதைத் தீர்மானிக்கும் நகல், உங்கள் டொமைன் பதிவாளரின் (registrar) delegation மூலம் parent zone-ல் இருக்கும்; உங்கள் zone-க்குள் இருக்கும் நகல் அல்ல.

பதிவு வகைகளை விட இரண்டு நுணுக்கங்கள் அதிகக் குழப்பத்தை ஏற்படுத்துகின்றன. ஒரு புள்ளியில் (dot) முடியும் பெயர் முழுமையானது (absolute), எனவே www.example.com. என்பது அந்தப் பெயரை மட்டுமே குறிக்கும். பெரும்பாலான கட்டுப்பாட்டுப் பலகைகள் (panels) சார்புப் பெயரை (relative name) எதிர்பார்க்கின்றன, அவை தானாகவே டொமைனைச் சேர்த்துக்கொள்ளும். எனவே, பெயர் பெட்டியில் www.example.com என்று உள்ளிட்டால், அது www.example.com.example.com என்று மாறிவிடும், இது யாருக்கும் வேலை செய்யாது. மற்றொரு நுணுக்கம் @, இது பெரும்பாலான பலகைகளில் apex-ஐக் குறிக்கும்: அதாவது, எந்த subdomain-ம் இல்லாமல் டொமைன் பெயரை மட்டும் குறிக்கும்.

உங்கள் VPS-க்கு A record-ஐ சுட்டிக்காட்டுதல்

முதலில் உங்கள் server-க்கு இணையம் காட்டும் முகவரியைப் பெறவும்:

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

பின்பு உங்கள் DNS host-ல் ஒரு record-ஐ உருவாக்கவும்: type A, name @, value அந்த முகவரி, TTL (time to live) 300. www-க்கு இரண்டாவது record-ஐச் சேர்க்கவும்; இது அதே முகவரியைக் கொண்ட மற்றொரு A ஆகவோ அல்லது apex-ஐச் சுட்டிக்காட்டும் CNAME ஆகவோ இருக்கலாம்.

இப்போது அது resolve ஆவதை உறுதிப்படுத்தவும்; இதை server-லிருந்து செய்யாமல் உங்கள் 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

முதல் கட்டளை உங்கள் கணினியின் சாதாரண பாதையைப் பயன்படுத்துகிறது, இதில் caches-ம் அடங்கும். இரண்டாவது கட்டளை உங்கள் local cache-ஐத் தவிர்த்துவிட்டு, ஒரு public recursive resolver-ஐக் கேட்கிறது. மூன்றாவது கட்டளை உங்கள் authoritative nameserver-ஐ நேரடியாகக் கேட்கிறது, எனவே அதன் பதில் எந்த cache-ம் இல்லாமல் தற்போதைய உண்மையான நிலையைக் குறிக்கும். மூன்றாவது கட்டளை உங்கள் முகவரியைத் தந்து, முதல் கட்டளை தராதபோது, உங்கள் DNS சரியாக உள்ளமைக்கப்பட்டுள்ளது என்று பொருள்; நீங்கள் பழைய பதிலின் cached நகலுக்காகக் காத்திருக்கிறீர்கள்.

பெயர் தீர்வு (Name resolving) வேலை செய்யவில்லை

பெயர் தீர்வு சரியாக நடப்பது DNS வேலை செய்கிறது என்பதை உறுதிப்படுத்துகிறது. இது உங்கள் web server-ஐப் பற்றி எதையும் நிரூபிக்காது. dig சரியான முகவரியைத் தந்தவுடன், இணைப்பைச் சோதிக்கவும்:

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 சிக்கல் அல்ல: பெயர் தீர்க்கப்பட்டு, பாக்கெட் சென்றடைந்துவிட்டது. எனவே, அந்த port-ல் எந்தச் சேவையும் இயங்கவில்லை என்பதே சிக்கல். ஒரு கோரிக்கை (request) நீண்ட நேரம் காத்திருந்து பிறகு time out ஆனால், firewall அந்தப் பாக்கெட்டை நிராகரிக்காமல் அமைதியாகத் தடுத்துள்ளது என்று பொருள். இங்கிருந்து DNS-ன் பங்கு முடிந்து, ports மற்றும் listening sockets மற்றும் உங்கள் VPS-ல் உள்ள ufw firewall விதிகள் ஆகியவற்றின் பங்கு தொடங்குகிறது. இணைப்பு வெற்றிகரமாக முடிந்த பிறகு, பக்கத்தின் மீதமுள்ள பகுதிகள் HTTP தனது வேலையைச் செய்வதன் மூலம் ஏற்றப்படும்.

Why the browser still shows the old host

Nothing propagates. No server pushes your change outward to anyone. Your authoritative nameserver holds the new value the instant you save it, and every cached copy of the previous answer stays valid until its own timer expires. That timer is the TTL, in seconds, that the record carried when it was handed out.

Copies live in more places than people expect: the browser's own short cache, the stub resolver on the machine, the recursive resolver used by that network, and any resolver a VPN installed on the client. Each keeps its copy for up to the TTL it received. Two people on two networks can see two different answers for hours, and both machines are behaving correctly.

Watch the countdown against a caching resolver:

dig @1.1.1.1 example.com +noall +answer

Run it twice, a few seconds apart. The TTL in the answer goes down. When it reaches zero, the resolver throws the record away and asks your nameserver again.

There is a second cache that almost nobody accounts for: negative answers. When a resolver is told a name does not exist, it caches that NXDOMAIN as well, for the time set by the last field of your zone's SOA record.

dig example.com SOA +short

The final number on that line is the negative TTL, often 3600. So looking up staging.example.com before you create it can hide the record from you for a full hour after you create it. Create the record first, then query it.

Changing nameservers is slower than changing a record, and the reason is mechanical. The delegation records in the .com zone are served with a TTL of 172800 seconds, which is two days, so a resolver that cached your old nameservers can keep asking them for that long. This is where the advice to "allow up to 48 hours" comes from. It applies to nameserver changes, not to ordinary record edits.

Plan a migration around the TTL instead of fighting it:

1. Lower the record's TTL to 300 and save it.
2. Wait longer than the old TTL, so that every cached copy carrying the old value has expired.
3. Change the address.
4. Once traffic has moved, raise the TTL back to 3600 or higher, because a low TTL means every resolver asks your nameservers far more often.

To clear what your own machine is holding:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics prints a cache section with hit and miss counters, so right after a flush the next lookup shows up as a miss. Browsers keep a separate cache, which means Chrome can still use an old answer after the system cache is empty. Clear that one at chrome://net-internals/#dns. Check /etc/hosts too, because a leftover line there beats DNS on that machine and only on that machine. getent hosts example.com shows the answer the system will really use, /etc/hosts included.

Wildcard certificates, TXT record மூலம் உறுதி செய்யப்படுகின்றன

ஒரு CA (certificate authority), certificate-ஐ வழங்குவதற்கு முன்பு அந்த domain-ன் மீதான கட்டுப்பாட்டைச் சரிபார்க்கும். HTTP-01 challenge என்பது குறிப்பிட்ட hostname-ல் port 80 வழியாக ஒரு கோப்பை வழங்குவதன் மூலம் செயல்படுகிறது; இது ஒரு தனிப்பட்ட பெயருக்குச் சரியாக வேலை செய்யும். Wildcard certificate என்பது *.example.com-ஐ உள்ளடக்கியது, இது CA-ஆல் கோப்புகளைப் பெற முடியாத பல hostnames-களைக் குறிக்கும். எனவே, Let's Encrypt ஆனது DNS-01 challenge மூலம் மட்டுமே wildcard-களை வழங்குகிறது. நீங்கள் CA வழங்கும் token-ஐ _acme-challenge.example.com-ல் ஒரு TXT record-ஆகப் பதிவேற்ற வேண்டும்; அந்த zone-ன் மீதான உங்கள் கட்டுப்பாடே இதற்கான ஆதாரமாகும்.

இது உங்கள் DNS host-ஐ certificate புதுப்பித்தலின் ஒரு பகுதியாக மாற்றுகிறது. Certbot ஒவ்வொரு முறையும் உங்கள் தலையீடு இன்றி அந்த TXT record-ஐ உருவாக்கி நீக்க வேண்டும்; எனவே, இதற்கு உங்கள் provider-க்கான API மற்றும் அதற்கேற்ற plugin தேவை. சரிபார்ப்பு தோல்வியடையும் போது, பொதுவாக DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com என்ற செய்தி வரும். இதன் பொருள், அந்த record தெரிவதற்கு முன்பே CA சரிபார்க்க முயன்றுள்ளது என்று அர்த்தம்: ஒன்று அது சேமிக்கப்படவில்லை, அல்லது பழைய negative பதில் இன்னும் cache-ல் உள்ளது. முழுமையான செயல்முறை DNS-01 challenge மூலம் wildcard certificates பெறுவதற்கான வழிகாட்டி-ல் உள்ளது.

VPN உங்கள் resolver-ஐக் கையகப்படுத்தும்போது

ஒரு VPN (virtual private network) client இணைக்கப்பட்டிருக்கும்போது, அது வழக்கமாக system resolver-ஐ மாற்றியமைக்கும். ஏனெனில், உள்ளூர் network-க்கு lookup-களை அனுப்பினால், நீங்கள் பார்க்கும் ஒவ்வொரு தளத்தின் பெயரும் அந்த network-க்குத் தெரிந்துவிடும். இது சரியான செயல்பாடாகும், ஆனால் இது இரண்டு வழிகளில் தோல்வியடையலாம்.

Tunnel இணைக்கப்பட்ட பிறகு, IP addresses வேலை செய்தாலும் பெயர்களை resolve செய்ய முடியாவிட்டால், client நிறுவிய resolver அந்த tunnel-க்குள் இருந்து அணுக முடியாததாக உள்ளது என்று அர்த்தம். ping 1.1.1.1 வெற்றிகரமாக இயங்கும், ஆனால் curl https://example.com கட்டளை curl: (6) Could not resolve host: example.com-ஐத் திருப்பித் தரும். மாறாக, tunnel இணைக்கப்பட்ட பிறகும் lookup-கள் நீங்கள் இருக்கும் உள்ளூர் network-க்கே சென்றால், உங்கள் traffic tunnel செய்யப்படுகிறது, ஆனால் உள்ளூர் resolver நீங்கள் கேட்கும் ஒவ்வொரு பெயரையும் தொடர்ந்து கவனித்துக் கொண்டிருக்கிறது.

resolvectl status

இது ஒவ்வொரு link-க்கும் பயன்பாட்டில் உள்ள resolver-ஐக் காட்டும். இதன் மூலம், tunnel எந்த resolver-ஐ நிறுவியுள்ளது என்பதையும், அது நீங்கள் எதிர்பார்த்ததுதானா என்பதையும் கண்டறியலாம். ஒரு WireGuard tunnel, client config-ல் உள்ள DNS = வரியிலிருந்து இதை அமைக்கிறது. WireGuard resolver-ஐக் கையகப்படுத்தும்போது DNS-ஐச் சரிசெய்தல் பகுதியில் systemd-resolved மற்றும் resolvconf தொடர்பான விவரங்கள் விளக்கப்பட்டுள்ளன.

பதில் குறியீடுகள் மற்றும் அவை உணர்த்துபவை

• NXDOMAIN: அந்தப் பெயர் இல்லை என்று ஒரு authoritative server குறிப்பிடுகிறது. எழுத்துப் பிழைகளைச் சரிபார்க்கவும், domain suffix இரண்டு முறை உள்ளதா என்று பார்க்கவும், உங்கள் delegation எதைச் சுட்டிக்காட்டுகிறதோ அந்த zone-ஐத்தான் திருத்தியுள்ளீர்களா என்பதையும் உறுதிப்படுத்தவும்.
• NOERROR மற்றும் காலியான ANSWER SECTION: பெயர் உள்ளது, ஆனால் நீங்கள் கேட்ட வகைக்கான பதிவு (record) அங்கு இல்லை. A மட்டும் இருக்கும்போது AAAA-ஐக் கேட்டால் இதுதான் கிடைக்கும்.
• SERVFAIL: resolver முயற்சி செய்தும் பதில் கிடைக்கவில்லை. இதற்கு இரண்டு பொதுவான காரணங்கள் உள்ளன: authoritative servers பதில் அளிக்காமல் இருப்பது மற்றும் DNSSEC (domain name system security extensions) சரிபார்ப்பு தோல்வியடைவது. dig @1.1.1.1 example.com A +cd கட்டளையைப் பயன்படுத்திச் சோதிக்கவும், இது சரிபார்ப்பை முடக்கும். இதைச் சேர்க்காமல் +cd மற்றும் SERVFAIL கிடைத்து, சேர்த்த பிறகு பதில் கிடைத்தால், signatures-ல் சிக்கல் உள்ளது என்று பொருள். nameserver மாற்றப்பட்ட பிறகு, parent இன்னும் பழைய DS (delegation signer) பதிவை வைத்திருக்கும்போது இது நிகழும்.
• REFUSED: நீங்கள் கேட்ட server அந்தப் பதிலைத் தர மறுக்கிறது. பொதுவாக, அந்த domain-க்குச் சம்பந்தமில்லாத ஒரு authoritative server-ஐ நோக்கி dig-ஐச் சுட்டிக்காட்டியிருப்பதே இதற்குக் காரணம்.
• ;; connection timed out; no servers could be reached: dig ஒரு resolver-ஐ அடையவில்லை. இது உங்கள் தரப்பில் உள்ள network அல்லது resolver சிக்கல், எனவே domain-ல் எந்தப் பிரச்சினையும் இல்லை.

ping: example.com: Temporary failure in name resolution என்பது dig-க்கு பதிலாக glibc மூலம் தெரிவிக்கப்படும் அதே வகை தோல்வியாகும்.

உங்கள் சொந்த VPS-ல் nameservers-ஐ இயக்க வேண்டுமா?

நீங்கள் இயக்கலாம். bind9, knot அல்லது nsd ஆகியவற்றை பயன்படுத்தி உங்கள் server-லிருந்து zone-ஐ வழங்க முடியும். இது எந்தவொரு panel-ஐ விடவும் DNS பற்றி உங்களுக்கு அதிக புரிதலைத் தரும். ஆனால் நடைமுறை ரீதியாக சில சிக்கல்கள் உள்ளன. ஒரு domain-க்கு குறைந்தது இரண்டு வெவ்வேறு network-களில் nameservers இருக்க வேண்டும். எனவே, ஒரே ஒரு VPS-ஐ மட்டும் பயன்படுத்தினால், அது மின்னஞ்சல் உட்பட அந்த domain-ன் அனைத்து சேவைகளுக்கும் ஒரு ஒற்றை தோல்விப் புள்ளியாக (single point of failure) மாறிவிடும். ஒரு domain-க்குள்ளேயே nameservers-க்கு பெயரிடும்போது, registrar-இடம் glue records தேவைப்படும். இது parent zone-ல் சேமிக்கப்பட்டுள்ள ns1.example.com-ன் முகவரியாகும்; இல்லையெனில், lookup செயல்முறை தொடங்குவதற்கு வழி இருக்காது. ஒரு resolver உங்கள் nameserver-ஐ அடைய முடியாவிட்டால், அது உங்கள் website-க்கு மாறாது; அந்த பயனருக்கு உங்கள் domain முழுவதுமே கிடைக்காமல் போய்விடும். பெரும்பாலானோருக்கு API வசதி கொண்ட Hosted DNS-ஐ பயன்படுத்துவதே குறைந்த ஆபத்துள்ள தேர்வாகும். உங்கள் சொந்த இயந்திரங்களுக்காக VPS-ல் caching resolver-ஐ இயக்குவது என்பது முற்றிலும் மாறுபட்ட பணி, அது மிகக் குறைந்த பொறுப்பையே உள்ளடக்கியது.

FAQ

எனது DNS மாற்றம் ஏன் இன்னும் பரவவில்லை (propagate)?

எதுவும் பரவுவதில்லை. நீங்கள் மாற்றத்தைச் சேமித்த கணமே உங்கள் authoritative nameservers புதிய மதிப்பைக் கொண்டிருக்கும். ஏற்கனவே வினவிய ஒவ்வொரு resolver-ம், தான் பெற்ற TTL முடியும் வரை அதன் cached நகலை வைத்திருக்கும். dig @ns1.your-dns-host.net example.com A +short மூலம் authoritative server-ஐ நேரடியாக வினவவும். அது புதிய முகவரியைத் தந்தால், மாற்றம் நேரலையில் உள்ளது என்று பொருள்; மீதமுள்ளவை அனைத்தும் 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-ம் அடங்கும். அந்தப் பெயர்கள் நீங்கள் திருத்திக் கொண்டிருக்கும் panel-ஐச் சேர்ந்தவை அல்ல என்றால், அதுதான் உங்கள் பிழை. delegation-ல் குறிப்பிடப்பட்டுள்ள provider-இடம் records-ஐத் திருத்தவும், அல்லது நீங்கள் விரும்பும் இடத்திற்குச் சுட்டிக்காட்ட உங்கள் registrar-இடம் delegation-ஐ மாற்றவும்.

எனது domain resolve ஆகிறது, ஆனால் தளம் இன்னும் ஏற்றப்படவில்லை. அடுத்து என்ன செய்வது?

dig example.com A +short உங்கள் server-ன் முகவரியைத் திருப்பித் தந்தவுடன் DNS பணி முடிந்துவிட்டது. அதன் பிறகு, சிக்கல் இணைப்பில் உள்ளது. curl -I http://example.com என்பது Connection refused என்று திரும்பினால், அந்த port-ல் எந்தச் சேவையும் இயங்கவில்லை என்று பொருள். நேரம் முடிவடையும் வரை (timeout) ஒரு கோரிக்கை காத்திருந்தால், firewall அந்த packet-ஐத் தடுத்துவிட்டது என்று பொருள். உங்கள் web server இயங்குகிறதா மற்றும் public முகவரியுடன் இணைந்துள்ளதா என்பதைச் சரிபார்க்கவும்; பின்னர் server-ல் உள்ள firewall மற்றும் உங்கள் provider-ன் control panel-ல் உள்ள network firewall ஆகியவற்றைச் சரிபார்க்கவும்.

எனது root domain-ல் ஏன் CNAME-ஐ வைக்க முடியாது?

ஒரு CNAME என்பது ஒரு பெயர் மற்றொரு பெயருக்கான மாற்றுப் பெயர் (alias) என்று கூறுகிறது; CNAME உள்ள ஒரு பெயரில் வேறு எந்த record-ம் இருக்க அனுமதி இல்லை. உங்கள் root domain ஒரு zone-ஆக இருக்க வேண்டுமானால், அதில் SOA மற்றும் NS records இருக்க வேண்டும், எனவே அது CNAME-ஆக இருக்க முடியாது. root-ல் முகவரியைக் கொண்ட A record-ஐப் பயன்படுத்தவும், அல்லது ALIAS, ANAME அல்லது CNAME flattening என விற்கப்படும் provider வசதியைப் பயன்படுத்தவும்; இது ஒரு பெயரைச் சேமித்து, அந்தப் பெயர் தற்போது எந்த முகவரிக்கு resolve ஆகிறதோ, அந்த முகவரியுடன் வினவல்களுக்குப் பதிலளிக்கும்.