களப் பெயர் முறைமை

நெட்வொர்க்கில் ஒரு கம்ப்யூட்டரின் எண்களாலான முகவரிக்கு கூடுதலான முறையில் மனிதன் புரிந்து கொள்ளத்தக்க வகையில் ஒரு பெயரைப் பயன்படுத்தும் நடைமுறை என்பது TCP/IP க்கும் முந்தைய காலத்திற்கு செல்கிறது. இந்த நடைமுறை ARPAநெட் சகாப்தம் வரை பின்சென்றது. அப்போது அது வேறுபட்ட முறைமையில் பயன்படுத்தப்பட்டது. DNS 1983 ஆண்டில் TCP/IP க்கு சற்று தள்ளி கண்டுபிடிக்கப்பட்டது. முந்தைய முறைமையில், நெட்வொர்க்கின் ஒவ்வொரு கம்ப்யூட்டரும் SRI (இப்போது SRI இன்டர்னேஷனல்)^[2][3][4] இல் இருக்கும் ஒரு கம்ப்யூட்டரில் இருந்து HOSTS.TXT என்கிற ஒரு கோப்பினை பெற்றது. இந்த HOSTS.TXT கோப்பு எண்களாலான முகவரிகளை பெயர்களுடன் மேப் செய்தது. நவீன ஆபரேடிங் சிஸ்டம்களிலும் ஒரு ஹோஸ்ட்ஸ் கோப்பு இருந்து கொண்டு தான் இருக்கிறது, இயல்பாக அமைக்கப்பட்டதாகவோ அல்லது அமைவுகள் வழி அமைப்பதாகவோ, இது பயனர்களை DNS இல் சோதிக்க வேண்டிய அவசியமின்றி ஒரு ஐபி முகவரியை (உ-ம். 208.77.188.166) ஒரு ஹோஸ்ட்பெயருக்கு (உ-ம். www.example.net) பயன்படுத்துவதற்குரியதாக குறிப்பிடுவதற்கு பயனர்களை அனுமதிக்கிறது. ஒரு ஹோஸ்ட்ஸ் கோப்பு அடிப்படையிலான கம்ப்யூட்டர்கள் அதற்கென உள்ள மரபான குறைபாடுகளைக் கொண்டிருக்கின்றன, ஏனென்றால் ஒரு கம்ப்யூட்டரின் முகவரி மாறுகிற ஒவ்வொரு சமயமும், அதனுடன் தொடர்பு கொள்ள முயலும் கம்ப்யூட்டர்களில் இருக்கும் அதன் ஹோஸ்ட்ஸ் கோப்பு தன்னை புதுப்பித்துக் கொள்ள வேண்டியது அவசியம் இருப்பது அறியத்தக்கதே.

நெட்வொர்க்கின் வளர்ச்சியானது ஹோஸ்ட் முகவரியிலான மாற்றத்தை ஒரே ஒரு இடத்தில் மட்டும் பதிவு செய்யக் கூடிய ஒரு மேம்பட்ட முறைமையை கோரியது. மற்ற ஹோஸ்ட்கள் மாற்றம் குறித்து ஒரு அறிவிப்பு முறைமை மூலம் அவ்வப்போது அறிந்து கொள்ளும், இவ்வாறாக அனைத்து ஹோஸ்ட்களின் பெயர்கள் மற்றும் அவற்றுடன் இணைந்த ஐபி முகவரிகளின் அணுகத்தக்க உலகளாவிய நெட்வொர்க் முழுமை பெறுகிறது.

ஜோன் போஸ்டல் கேட்டுக் கொண்டதற்கிணங்க, பால் மோகபெட்ரிஸ் 1983 இல் டொமைன் பெயர் முறைமையைக் கண்டுபிடித்து அதன் முதல் செயலாக்கத்தை எழுதினார். ஆரம்ப வரன்முறைகள் ஆர்எப்சி 882 மற்றும் ஆர்எப்சி 883 இல் தோன்றின, நவம்பர் 1987 இல் இவை ஆர்எப்சி 1034^[5] மற்றும் ஆர்எப்சி 1035^[6] மேம்படுத்தல்களால் இடம்பெயர்த்தப்பட்டன. பல்வேறு கூடுதல் ரெக்வஸ்ட் ஃபார் கமெண்ட்ஸ் மைய DNS புரோட்டோகால்களுக்கு பல்வேறு நீட்டிப்புகளை முன்மொழிந்திருக்கின்றன.

1984 ஆம் ஆண்டில், நான்கு பெர்க்லி மாணவர்கள் - டக்ளஸ் டெர்ரி, மார்க் பெயிண்டர், டேவிட் ரிக்கிள் மற்றும் சோங்க்னியன் ஸோ - முதலாவது யூனிக்ஸ் செயலாக்கத்தை எழுதினர், இது அதன்பின் ரால்ப் கேம்பல் மூலம் பராமரிக்கப்பட்டது. 1985 ஆம் ஆண்டில் DEC இன் கெவின் டன்லாப் குறிப்பிடத்தகுந்த முறையில் DNS செயலாக்கத்தை திருத்தி எழுதினார், அதனை BIND-பெர்க்லி இன்டர்னெட் பெயர் டொமைன் என்றும் பெயர் மாற்றினார். அது முதல் மைக் கரேல்ஸ், பில் அல்குவிஸ்ட் மற்றும் பால் விக்சி ஆகியோர் BIND ஐ பராமரித்து வந்திருக்கின்றனர். 1990களின் ஆரம்பத்தில் BIND விண்டோஸ் NT தளத்திற்கு போர்ட் செய்யப்பட்டது.

BIND பரவலாக விநியோகிக்கப்பட்டது, குறிப்பாக யூனிக்ஸ் முறைமைகளில், இது தான் இன்டர்னெட்டில் ஆதிக்கம் செலுத்தும் DNS மென்பொருளாக இருக்கிறது.^[7] அதிகமான பயன்பாடு, மற்றும் அதன் ஓபன்-சோர்ஸ் குறியீட்டின் விளைவால் வந்த அதிக ஆராய்ச்சி, அதேபோல் கூடுதல் நுட்பமான தாக்குதல் முறைகள் பெருகியது ஆகிய காரணங்களால் BIND இல் பல பாதுகாப்பு பிழைகள் கண்டறியப்பட்டன. இதன் விளைவாக ஏராளமான மாற்று பெயர்செர்வர்கள் மற்றும் ரிசால்வர் நிரல்கள் உருவாகின. BIND கூட ஆரம்பத்தில் இருந்து பதிப்பு 9 இல் மறு உருவாக்கம் கண்டது, இது மற்ற நவீன இன்டர்னெட் மென்பொருளுடன் ஒப்பிடத்தக்க ஒரு பாதுகாப்பு பதிவேட்டைக் கொண்டிருக்கிறது.

டொமைன் பெயர் வெளி

டொமைன் பெயர் வெளி டொமென் பெயர்களின் ஒரு மரத்தின் கிளைபரவல் அமைப்பைக் கொண்டிருக்கிறது. மரத்தின் ஒவ்வொரு கணு அல்லது இலையும் ஜீரோ அல்லது கூடுதலான ஆதார பதிவேடு களைக் கொண்டுள்ளன, இவை டொமைன் பெயர் தொடர்பான விவரங்களைக் கொண்டிருக்கின்றன. இந்த மரமானது வேர் மண்டலத்தில் தொடங்கும் மண்டலங்களாக துணைப் பிரிவு கொள்கிறது. அதிகாரமுற்ற பெயர்செர்வரால் அதிகாரப்பூர்வமான முறையில் சேவை பெறும் இணைப்புற்ற கணுக்களின் ஒரு தொகுப்பை ஒரு DNS மண்டலம் கொண்டிருக்கிறது. (ஒற்றை பெயர்செர்வர் ஒன்று பல மண்டலங்களை ஹோஸ்ட் செய்ய முடியும் என்பதை கவனத்தில் கொள்ளவும்.)

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

ஒரு டொமைன் பெயரின் பகுதிகள்

ஒரு டொமைன் பெயர் பொதுவாக இரண்டு அல்லது அதற்கு கூடுதலான பகுதிகளைக் (தொழில்நுட்ப மொழியில் லேபல்கள் ) கொண்டிருக்கும், இவை மரபுவழியாக புள்ளிகள் மூலம் பிரிக்கப்பட்டிருக்கும், example.com என்பதில் இருப்பதைப் போன்று.

• வலது கடைசியில் இருக்கும் லேபல் உயர்நிலை டொமைனைக் குறிக்கிறது (உதாரணமாக www.example.com என்னும் முகவரியில் com என்பது உயர் நிலை டொமைன் ஆகும்).
• இடது பக்கத்தில் இருக்கும் ஒவ்வொரு லேபலும் ஒரு துணைப்பிரிவை, அல்லது தனக்கு மேலிருக்கும் டொமைனின் சப்டொமைனை குறிக்கிறது. கவனத்திற்கு: சப்டொமைன் ஒப்புமை சார்பை வெளிப்படுத்துகிறதே அன்றி, முற்றுமுதலான சார்பை அல்ல. உதாரணமாக: example.com என்பது com டொமைனின் ஒரு சப்டொமைன், www.example.com என்பது example.com டொமைனின் ஒரு சப்டொமைன் ஆகும். கருத்தளவில், இந்த துணைப்பிரிவுகள் 127 நிலைகள் வரை கீழ் செல்லலாம். ஒவ்வொரு லேபலும் 63 எண்ணெண்களைக் கொண்டிருக்க முடியும். மொத்த டொமைன் பெயரும் மொத்த நீளமாக 253 எண்ணெண்களுக்கு அதிகமாகக் கொண்டிருக்க முடியாது.^[8] நடைமுறையில், சில டொமைன் ரெஜிஸ்ட்ரிக்கள் குறைவான வரம்புகளைக் கொண்டிருக்கலாம்.
• ஒரு ஹோஸ்ட்பெயர் என்பது ஒன்று அல்லது அதற்கு கூடுதலாக தொடர்புபட்ட ஐபி முகவரிகளைக் கொண்ட ஒரு டொமைன் பெயரைக் குறிப்பிடுகிறது (உ-ம்., 'www.example.com' மற்றும் 'example.com' டொமைன்கள் இரண்டுமே ஹோஸ்ட்பெயர்கள் தான், அதே சமயம் 'com' டொமைன் இல்லை).

DNS செர்வர்கள்

டொமைன் பெயர் முறைமையானது கிளையன்ட்-செர்வர் மாதிரியைப் பயன்படுத்தும் ஒரு பகிர்ந்தளித்த தரவுத்தள முறைமையைப் பயன்படுத்துகிறது. இந்த தரவுத்தளத்தின் முனையங்கள் பெயர் செர்வர்கள். ஒவ்வொரு டொமைன் அல்லது சப்-டொமைனும் ஒன்று அல்லது கூடுதலான அதிகாரமுற்ற DNS செர்வர்களைக் கொண்டுள்ளது, இவை அந்த டொமைன் மற்றும் அதன் கீழ் ஏதேனும் டொமைன்கள் இருந்தால் அவற்றின் பெயர் செர்வர்கள் போன்ற விவரங்களை வெளியிடுகின்றன. இந்த அடுக்குவரிசையின் உச்சியில் இருப்பது வேர் பெயர்செர்வர்கள்: ஒரு உயர்-நிலை டொமைன் பெயரை (TLD) தேடும் போது (தீர்க்கும் போது ) குவெரி செய்ய வேண்டிய செர்வர்கள்.

DNS ரிஸால்வர்கள்

DNS இன் கிளையன்ட் பக்கம் ஒரு DNS ரிஸால்வர் என்று அழைக்கப்படுகிறது. குவெரிக்களுக்கு துவக்கமளித்து வரிசைப்படுத்தி இறுதியில் அவை கோரப்படும் ஆதாரத்திற்கான முழுமையான தீர்வினை (மொழிபெயர்ப்பு), அதாவது ஒரு டொமைன் பெயரை ஐபி முகவரியாக மொழி பெயர்ப்பதை, வழங்குவதற்கு இது தான் பொறுப்பானதாகும்.

ஒரு DNS குவெரி சுழல்நிலையற்ற குவெரியாகவோ (non-recursive) அல்லது சுழல்நிலை (recursive) குவெரியாகவோ இருக்கலாம்:

• ஒரு சுழல்நிலையற்ற குவெரி என்பதில் தான் அதிகாரம்படைத்ததாய் இருக்கும் ஒரு டொமைனுக்கான பதிவை DNS செர்வர் வழங்குகிறது, அல்லது மற்ற செர்வர்களை குவெரி செய்யாமல் பகுதியான முடிவினை வழங்குகிறது.
• ஒரு சுழல்நிலை குவெரி என்பதில் அவசியப்படுகிற சமயத்தில் மற்ற பெயர் செர்வர்களையும் குவெரி செய்து DNS குவெரிக்கு முழுமையாகப் பதிலளிக்கும் (அல்லது ஒரு பிழை அளிக்கும்). DNS செர்வர்கள் சுழல்நிலை குவெரிக்களை ஆதரிக்க வேண்டும் என்கிற கட்டாயமில்லை.

ரிஸால்வர், அல்லது ரிஸால்வரின் சார்பாக சுழல்நிலையாக செயல்படும் DNS செர்வர், குவெரி ஹெடர்களில் இருக்கும் பிட்களைப் பயன்படுத்தி சுழல் சேவை பயன்பாட்டை பேசித் தீர்க்கிறது.

அவசியமான தகவல்களைக் காண பல்வேறு பெயர் செர்வர்களின் வழியே தேடி அலசுவதற்கு ரிஸால்விங் பொதுவாக வழிவகை கொண்டிருக்கிறது. ஆயினும், சில ரிஸால்வர்கள் வெகு எளிமையான செயல்பாட்டைக் கொண்டுள்ளன, இவை ஒரே ஒரு பெயர் செர்வருடன் மட்டும் தான் பரிவர்த்தனை செய்ய முடியும். இந்த எளிய ரிஸால்வர்கள் ("ஸ்டப் ரிஸால்வர்கள்" என்று அழைக்கப்படுகின்றன) தங்களுக்கு தகவல் தேடித் தரும் வேலையைச் செய்வதற்கு ஒரு சுழல்நிலை பெயர் செர்வரைச் சார்ந்திருக்கின்றன.

முகவரி தீர்வு வகைமுறை

ஒரு டொமைன் பெயர் பல்வேறு பெயர் பாகங்களைக் கொண்டிருக்கலாம் (உ-ம்., ahost.ofasubnet.ofabiggernet.inadomain.example ). நடைமுறையில் முழு ஹோஸ்ட் பெயர்கள் பல சமயங்களில் மூன்று பிரிவுகளை மட்டுமே கொண்டிருக்கும்: ahost.inadomain.example , அநேக சமயங்களில் www.inadomain.example . குவெரி நோக்கத்திற்கு, மென்பொருளானது பெயரை பிரிவு பிரிவாக, வலமிருந்து இடதாகப் பொருள் புரிகிறது. பாதையின் ஒவ்வொரு அடியிலும், நிரலானது உரிய DNS செர்வரில் குவெரி செய்து அது ஆலோசிக்க வேண்டிய அடுத்த செர்வருக்குரிய கைகாட்டலைப் பெறுகிறது.

ஆரம்பத்தில் திட்டமிடப்பட்டது போல், இந்த நிகழ்முறையானது மிக எளிமையானது:

1. வேர் செர்வர்களின் அறியப்பட்ட முகவரிகள் ஒரு வேர் குறிப்புகள் கோப்பில் இருக்கும் நிலையில் லோக்கல் கம்ப்யூட்டரானது முன்கூட்டிய-உள்ளமைவு செய்யப்படுகிறது, இந்த கோப்பானது லோக்கல் நிர்வாகி மூலம் ஒரு நம்பகமான ஆதாரத்தால் அவ்வப்போது புதுப்பிக்கப்பட வேண்டும், காலப் போக்கில் நிகழ்கிற மாற்றங்களுக்கு அடியொற்றி புதுப்பிக்கப்படுவதாய் இருக்க வேண்டும்.
2. கீழமைந்த அடுத்த நிலையிலுள்ள அதிகாரமுற்ற செர்வரைக் கண்டறிய வேர் செர்வர்களில் ஒன்று குவெரி செய்யப்படுகிறது (எனவே நமது எளிய ஹோஸ்ட் பெயர் சந்தர்ப்பத்தில், example உயர் நிலை டொமைன் குறித்த விரிவான விவரமறிந்த ஒரு செர்வரின் முகவரி ஒரு வேர் செர்வரிடம் கோரப்படும்).
3. இரண்டாம்-நிலை டொமைன் (நமது உதாரணத்தில் inadomain.example ) குறித்த விரிவான விவரங்களுடனான ஒரு DNS செர்வரின் முகவரிக்கு இந்த இரண்டாவது செர்வர் குவெரி செய்யப்படுகிறது.
4. பெயரின் கீழே முன்னேறி செல்ல முந்தைய படி மீண்டும் செய்யப்படுகிறது, அடுத்த DNS செர்வரின் முகவரியை உருவாக்குவதற்கு பதிலாக இறுதி முகவரியை கொண்டு வரும் இறுதிப் படி வரும் வரை இந்த நிகழ்முறை மீண்டும் மீண்டும் நிகழ்த்தப்படும்.

www.wikipedia.org என்கிற உண்மையான ஹோஸ்டுக்கு இந்த நிகழ்முறை செயல்படும் விதத்தை இந்த படம் விளக்குகிறது.

இந்த எளிமையான வடிவத்தில் இந்த நிகழ்முறை ஒரு சிக்கல் கொண்டுள்ளது: இது வேர் செர்வர்களில் ஒரு பெரும் செயல்பாட்டுச் சுமையை அளிக்கிறது, ஒரு முகவரிக்கான ஒவ்வொரு தேடலும் அவற்றில் ஒன்றை குவெரி செய்வதன் மூலமாக துவங்குவதன் மூலம். ஒட்டுமொத்த முறைமையின் செயல்பாட்டுக்கும் இது முக்கியமான பிரச்சினையாக ஆகிறது, ஏனென்றால் இத்தகைய கனமான பயன்பாடு அன்றாடம் செய்யப்படும் டிரில்லியன்கணக்கான குவெரிக்களுக்கு ஒரு கடக்கமுடியாத தடையை ஏற்படுத்தி விடும். நடைமுறையில் இந்த பிரச்சினையை தீர்ப்பதற்கு இடைமாற்று செய்தல் பயன்படுத்தப்படுகிறது, இதனால், உண்மையில் வேர் பெயர்செர்வர்கள் மொத்த போக்குவரத்தில் வெகு கொஞ்சத்தைதான் கையாளுகின்றன.

சுற்று சார்புகள் மற்றும் ஒட்டு பதிவேடுகள்

ஒதுக்கீடுகளில் உள்ள பெயர் செர்வர்கள் ஐபி முகவரிகளை விடவும் பெயர் வரிசையில் தான் பட்டியலிடப்படுகின்றன. இதன் அர்த்தமானது, ரிஸால்விங் பெயர் செர்வரானது அது குறிப்பிட்டுக் காட்டும் செர்வரின் ஐபி முகவரியைக் கண்டறிவதற்கான இன்னொரு DNS கோரிக்கையை வழங்கியாக வேண்டும் என்பது. குறிப்பிடப்படும் பெயர்செர்வரே அது அதிகாரமுற்றதாய் இருக்கும் டொமைனின் கீழ் இருக்குமானால் இது ஒரு சுற்று சார்பினை கொண்டுவரும் என்பதால், ஒதுக்கீட்டை வழங்கும் பெயர்செர்வரே அடுத்த பெயர்செர்வரின் ஐபி முகவரியையும் வழங்குவதற்கான அவசியம் அவ்வப்போது ஏற்படலாம். இந்த பதிவேடு ஒட்டு பதிவேடு என அழைக்கப்படுகிறது.

உதாரணமாக en.wikipedia.org என்னும் சப்டொமைன் இன்னும் நிறைய சப்டொமைன்களைக் (something.en.wikipedia.org என்பது போன்று) கொண்டிருப்பதாகவும் இவற்றுக்கான அதிகாரமுற்ற பெயர் செர்வர் ns1.something.en.wikipedia.org இல் தங்கியிருப்பதாகவும் எடுத்துக் கொள்வோம். இவ்வாறாக something.en.wikipedia.org ஐ தேடும் ஒரு கம்ப்யூட்டர் முதலில் ns1.something.en.wikipedia.org ஐத் தேடித் தீர்க்க வேண்டும். ns1 என்பதும் something.en.wikipedia.org இன் சப்டொமைனாக தான் இருக்கிறது என்பதால், ns1.something.en.wikipedia.org ஐ தீர்ப்பதற்கு something.en.wikipedia.org ஐ தீர்ப்பது அவசியமாகிறது, இது தான் நாம் மேலே குறிப்பிட்ட சுற்று சார்பு என்பதாகும். இந்த சார்பானது en.wikipedia.org இன் பெயர்செர்வரில் உள்ள ஒட்டு பதிவேடு மூலம் உடைக்கப்படுகிறது, அது ns1.something.en.wikipedia.org இன் ஐபி முகவரியை கேட்பவருக்கு நேரடியாக வழங்கி, ns1.something.en.wikipedia.org இருப்பிடத்தை கண்டறிவதன் மூலம் இந்த நிகழ்முறை முன் செல்ல வகை செய்கிறது.

இடைமாற்று மற்றும் ஆயுள் நேரம்

DNS போன்ற ஒரு கம்ப்யூட்டரின் மூலம் உருவாக்கப்படும் பெரும் எண்ணிக்கையிலான கோரிக்கைகளின் காரணமாக, வடிவமைப்பாளர்கள் தனித்தனி DNS செர்வர்களின் சுமையை குறைப்பதற்கான ஒரு வகைமுறையை வழங்க விரும்பினார்கள். இந்த நோக்கத்தோடு, DNS தீர்வு நிகழ்முறையானது ஒரு வெற்றிகரமான மறுமொழிக்கு பிந்தைய சற்று காலத்திற்கு இடைமாற்று செய்வதற்கு (அதாவது ஒரு DNS குவெரியின் முடிவுகளை லோக்கல் கம்ப்யூட்டரில் பதிவு செய்து வைத்துக் கொண்டு அடுத்து குவெரிகள் சமயத்தில் அதனைப் பயன்படுத்திக் கொள்வது) அனுமதிக்கிறது. ஒரு ரிஸால்வர் ஒரு DNS மறுமொழியை எவ்வளவு நேரம் இடைமாற்று செய்கிறது (அதாவது எவ்வளவு நேரம் ஒரு DNS மறுமொழி செல்லுபடியாகும் நிலை யில் தொடர்கிறது என்பது) என்பது ஆயுள் நேரம் (TTL) என்கிற ஒரு மதிப்பால் தீர்மானிக்கப்படுகிறது. இந்த TTL மறுமொழியை கையாளும் DNS செர்வரின் நிர்வாகியால் அமைக்கப்படுகிறது. இந்த செல்லுபடி காலம் என்பது வெறும் சில விநாடிகளில் இருந்து நாட்கள் அல்லது மாதங்கள் வரை கூட வேறுபடலாம்.

இடைமாற்று நேரம்

இந்த பகிர்ந்தளிக்கப்பட்ட மற்றும் இடைமாற்று கட்டுமானத்தின் குறிப்பிடத்தக்க விளைவாக, DNS பதிவேடுகளிலான மாற்றங்கள் எப்போதும் உடனடியாகவும் உலகளாவிய வகையிலும் நிகழ்பெற்று விடுவதில்லை. இது ஒரு உதாரணம் மூலம் சிறப்பாய் விளக்கப்படுகிறது: www.wikipedia.org ஹோஸ்டுக்கு ஒரு நிர்வாகி 6 மணி நேரம் TTL அமைவு செய்திருக்கிறார், பின் www.wikipedia.org தீர்க்கக் கூடிய ஐபி முகவரியை பிற்பகல் 12:01 மணிக்கு மாற்றுகிறார் என்றால், பழைய ஐபி முகவரிக்கான மறுமொழி பகல் 12:00 மணிக்கு இடைமாற்று செய்யப்பட்டிருக்கும் ஒரு நபரின் கம்ப்யூட்டர் மீண்டும் DNS செர்வரை மாலை 6:00 மணி வரை ஆலோசிக்காது என்பதை நிர்வாகி கருத்தில் கொள்ள வேண்டும். இந்த உதாரணத்தில் பிற்பகல் 12:௦01 மணியிலிருந்து மாலை 6:00 மணி வரையான காலத்தையே இடைமாற்று நேரம் என்கிறோம், ஒரு DNS பதிவேட்டுக்கு நீங்கள் மாற்றம் செய்யும் நேரத்தில் இருந்து துவங்கி TTL காலாவதியாக குறிப்பிடப்பட்டுள்ள அதிகப்பட்ச கால அவகாசத்துடன் முடிவடைகிற ஒரு காலம் என்று சிறப்பாக வரையறுக்கலாம். DNS மாற்றங்களின் போது கொள்ள வேண்டிய முக்கியமான போக்குவரத்து கருதலுக்கு இது அடிப்படையாக இட்டுச் செல்கிறது: ஒவ்வொருவரும் நீங்கள் பார்த்துக் கொண்டிருக்கும் அதே விஷயத்தை பார்த்துக் கொண்டிருக்க அவசியமில்லை . TTL எவ்வாறு அமைவு செய்யப்படலாம் என்பதற்கான அடிப்படை விதிகளை வெளிப்படுத்த RFC 1912 உதவுகிறது.

"பரவுதல்" என்கிற பதம், இந்த பொருளில் பரவலாக பயன்படுத்தப்படும் போதிலும், இடைமாற்றின் விளைவுகளை நன்றாக விவரிப்பதில்லை என்பதை கவனத்தில் கொள்ளவும். குறிப்பாக, நீங்கள் ஒரு DNS மாற்றம் செய்யும்போது, இது எப்படியோ மற்ற பிற DNS செர்வர்களுக்கு பரவி விடுகிறது (பதிலாக, மற்ற DNS செர்வர்கள் அவசியப்படும்போது உங்களுடையதை சோதிக்கின்றன) என்றும், மற்றும் இந்த பதிவேடு இடைமாற்றில் இருக்கும் கால அவகாசத்தின் கட்டுப்பாடு உங்களிடம் இல்லை (உங்களது டொமைனில் இருக்கும் அனைத்து DNS பதிவேடுகளுக்கான TTL மதிப்புகளையும் நீங்கள் கட்டுப்படுத்துகிறீர்கள், உங்களது NS பதிவேடுகள் மற்றும் உங்களது டொமைன் பெயரைப் பயன்படுத்தக் கூடிய எந்த அதிகாரமுற்ற DNS செர்வர்களையும் தவிர) என்றும் இது சூசகம் செய்கிறது.

சில ரிஸால்வர்கள் TTL மதிப்புகளை கீழழுத்தி செயல்பட முடியும், ஏனெனில் புரோட்டோகால் 68 ஆண்டுகள் வரையான இடைமாற்று அல்லது இடைமாற்றே இல்லாத நிலையை ஆதரிக்கிறது. எதிர்மறை இடைமாற்று செய்தல் (பதிவேடுகள் இன்றி இருப்பது) என்பது ஒரு மண்டலத்திற்கு அதிகாரமுற்ற பெயர் செர்வர்களால் தீர்மானிக்கப்படுகிறது, கோரிய வகையில் எந்த தரவும் இல்லாததை தெரிவிக்கும் சமயத்தில் இவை ஸ்டார்ட் ஆஃப் அதாரிட்டி (SOA) பதிவேட்டைக் கட்டாயம் கொண்டிருக்க வேண்டும். SOA பதிவேட்டின் MINIMUM புலம் மற்றும் SOA இனுடைய TTL ம் கூட எதிர்மறை மறுமொழிக்கான TTL ஐ நிறுவ பயன்படுத்தப்படுகின்றன. RFC 2308

ஒரு DNS மாற்றம் நீங்கள் செய்யும்போது பலரும் புதிரான 48 மணி நேர அல்லது 72 மணி நேர பரவுதல் நேரத்தை தவறாகக் குறிப்பிடுகிறார்கள். ஒருவரின் டொமைனைப் பயன்படுத்தி (இருந்தால்) ஒரு டொமைனுக்கான NS பதிவேடுகளை அல்லது அதிகாரமுற்ற DNS செர்வர்களின் ஹோஸ்ட்பெயர்களுக்கான ஐபி முகவரிகளை ஒருவர் மாற்றும் சமயத்தில், அனைத்து DNS செர்வர்களும் புதிய தகவலை பயன்படுத்துவதற்கு முன்னதாக ஒரு நெடிய கால அவகாசம் இருக்கக் கூடும். இதற்குக் காரணம் அந்த பதிவேடுகள் மண்டல பெற்றோர் DNS செர்வர்களால் (உதாரணமாக, உங்களது டொமைன் example.com என்றால் .com DNS செர்வர்கள்) கையாளப்படுகின்றன, இவை பொதுவாக 48 மணி நேரங்களுக்கு பதிவேடுகளை இடைமாற்று செய்கின்றன. ஆயினும், அவற்றை இடைமாற்று செய்திராத எந்த DNS செர்வர்களுக்கும் அந்த DNS மாற்றங்கள் உடனடியாக கிடைக்கத்தக்கதாய் இருக்கும். NS பதிவேடுகள் மற்றும் அதிகாரமுற்ற DNS செர்வர் பெயர்கள் தவிர்த்து உங்களது டொமைனில் செய்யப்படும் எந்த DNS மாற்றங்களும் ஏறக்குறைய உடனுக்குடன் பிரதிபலிக்கப்படுவதாக இருக்க முடியும், நீங்கள் அவ்வாறிருக்க தெரிவு செய்யும் பட்சத்தில் (காலத்திற்கு முன்பே ஒருமுறை அல்லது இருமுறையாக TTL ஐக் குறைத்து விட்டு, மாற்றம் செய்வதற்கு முன்னதாக பழைய TTL காலாவதியாகும் வரை காத்திருப்பதன் மூலம்).

ரிவர்ஸ் லுக்அப்

கொடுக்கப்பட்ட ஐபி முகவரியுடன் இணைப்புற்ற பெயரைக் கண்டறிய ஒரு DNS குவெரியைச் செயல்படுத்துவதையே "ரிவர்ஸ் லுக்அப்" என்கிற பிரயோகம் குறிப்பிடுகிறது.

DNS ஐபி முகவரிகளை சிறப்பு டொமைன்களுக்கு உள்ளே PTR பதிவேடுகளாக சேமிக்கிறது. IPv4 க்கு டொமைன் in-addr.arpa. IPv6 க்கு, ரிவர்ஸ் லுக்அப் டொமைன் ip6.arpa.

ஒரு ரிவர்ஸ் லுக்அப் மேற்கொள்ளும்போது, DNS கிளையன்டானது முகவரியை DNS க்குள் பயன்படுத்தப்படும் ஒரு வடிவமைப்புக்குள் மாற்றுகிறது, பின் வழக்கம் போல் ஒதுக்கீட்டு சங்கிலியை பின்பற்றுகிறது. உதாரணமாக, the IPv4 முகவரி '208.80.152.2' 2.152.80.208.in-addr.arpa என மாறுகிறது. வேர் செர்வர்களை குவெரி செய்வதன் மூலம் DNS ரிஸால்வர் துவங்குகிறது, இவை 208.in-addr.arpa மண்டலத்திற்கு ARIN செர்வர்களை பாயிண்ட் செய்கின்றன. அங்கிருந்து 152.80.208.in-addr.arpa க்கு விக்கிமீடியா செர்வர்கள் ஒதுக்கப்படுகின்றன, அத்துடன் 2.152.80.208.in-addr.arpa க்கு விக்கிமீடியா பெயர்செர்வரை குவெரி செய்வதன் மூலம் PTR லுக்அப் நிறைவு பெறுகிறது, இது ஒரு அதிகாரமுற்ற மறுமொழியில் முடிகிறது.

கிளையன்ட் லுக்அப்

பயனர்கள் பொதுவாக நேரடியாக ஒரு DNS ரிஸால்வருடன் தொடர்பு கொள்வதில்லை. பதிலாக வெப் பிரவுசர்கள், மின்னஞ்சல் கிளையன்டுகள், மற்றும் பிற இன்டர்னெட் பயன்பாடுகள் போன்ற பயன்பாட்டு நிரல்களில் DNS தீர்வு வெளிப்படையானதாக நிகழும். டொமைன் லுக்அப் அவசியமாய் இருக்கும் ஒரு கோரிக்கையை ஒரு பயன்பாடு எழுப்பும்போது, இத்தகைய நிரல்கள் லோக்கல் ஆபரேடிங் சிஸ்டத்தில் இருக்கும் DNS ரிஸால்வருக்கு ஒரு தீர்வு கோரிக்கையை அனுப்புகின்றன, அது அவசியமான தகவல்தொடர்புகளைக் கையாளுகிறது.

DNS ரிஸால்வர் பரவலாக சமீபத்திய லுக்அப்கள் அடங்கிய ஒரு இடைமாற்று (மேலே காணவும்) கொண்டிருக்கும். இடைமாற்று கோரிக்கைக்கான பதிலை அளிக்க முடிந்தால், ரிஸால்வர் இடைமாற்றில் இருக்கும் மதிப்பினை கோரிக்கை செய்த நிரலுக்கு அனுப்பும். இடைமாற்று பதிலைக் கொண்டிருக்கவில்லை என்றால், ரிஸால்வரானது கோரிக்கையை ஒன்று அல்லது கூடுதலான ஒதுக்கப்பட்ட DNS செர்வர்களுக்கு அனுப்பும். அநேகமான வீட்டு பயனர்கள் விஷயத்தில், கம்ப்யூட்டர் தொடர்பு கொள்ளும் இன்டர்னெட் சேவை வழங்குநர் தான் பொதுவாக இந்த DNS செர்வரை வழங்கும்: இத்தகையதொரு பயனர் ஒன்று செர்வரின் முகவரியை கைகொண்டு உள்ளமைவு செய்திருப்பார் அல்லது DHCP அதனை அமைவு செய்ய அனுமதித்திருப்பார்; எப்படியிருந்தாலும், கம்ப்யூட்டர் நிர்வாகிகள் கம்ப்யூட்டர்கள் தங்கள் சொந்த DNS செர்வர்களைப் பயன்படுத்தும் வகையில் உள்ளமைவு செய்திருக்குமிடத்தில், அவர்களது DNS செர்வர்கள் அந்த அமைப்பின் தனியாகப் பராமரிக்கப்படும் பெயர்செர்வர்களுக்கு பாயிண்ட் செய்கின்றன. எது நடப்பினும், இவ்வாறாக குவெரி செய்யப்பட்ட பெயர் செர்வரானது மேலே கூறப்பட்ட நிகழ்முறையை பின்பற்றும், அது வெற்றிகரமாக ஒரு முடிவினைக் கண்டறிகிற அல்லது கண்டறியா வரை. அதன்பின் தான் முடிவைக் கண்டறிந்த அனுமானத்துடன் தனது முடிவுகளை அது DNS ரிஸால்வருக்கு திருப்பியனுப்புகிறது, ரிஸால்வர் அந்த முடிவுகளை தனது வருங்கால பயன்பாட்டுக்கு உடனே இடைமாற்றில் சேமித்துக் கொள்கிறது, பின் முடிவினை கோரிக்கையை துவக்கிய மென்பொருளுக்கு திருப்பி கொடுக்கிறது.

முறிந்த ரிஸால்வர்கள்

ரிஸால்வர்கள் DNS புரோட்டோகாலின் விதிமுறைகளை மீறும் சமயத்தில் கூடுதலான சிக்கல் நிலை எழுகிறது. ஏராளமான பெரிய ISP க்களில் விதிமுறைகளை மீறுவதற்குரிய உள்ளமைவுகளை தங்கள் DNS செர்வர்களில் கொண்டுள்ளன (ஒரு முழு இணக்கமுற்ற ரிஸால்வரைக் காட்டிலும் குறைவாக செலவு வைக்கும் வன்பொருளைக் கொண்டு இயங்க அனுமதிக்கும் வகையில்), TTLக்களை மதிக்காது போவது, அல்லது ஒரு டொமைன் பெயரின் பெயர் செர்வர்களில் ஒன்று மறுமொழியளிக்கவில்லை என்பதால் அந்த டொமைன் பெயர் உபயோகத்தில் இல்லை எனக் காட்டுவது போன்றவை இதில் அடங்கும்.^[9]

சிக்கலின் இறுதி நிலையாக, சில பயன்பாடுகளும் (வெப் பிரவுசர்கள் போன்றவை) தங்களது சொந்த DNS இடைமாற்றினைக் கொண்டிருக்கின்றன, DNS ரிஸால்வர் லைப்ரரியின் பயன்பாட்டு அளவையே குறைக்கும் பொருட்டு. DNS பிரச்சினைகளில் பிழை நீக்குவதில் இந்த நடைமுறை கூடுதல் சிக்கலை அளிக்கலாம், ஏனென்றால் இது தரவின் இளமையையும் மற்றும்/அல்லது எந்த தரவு எந்த இடைமாற்றில் இருந்து வருகிறது என்பதையும் மங்கச் செய்து விடுகிறது. இந்த இடைமாற்றுகள் பொதுவாக வெகு குறைந்த இடைமாற்று நேரங்களை - ஒரு நிமிடம் என்கிற அளவில் - பயன்படுத்துகின்றன. இன்டர்னெட் எக்ஸ்புளோரர் ஒரு குறிப்பிடத்தக்க விதிவிலக்கை வழங்குகிறது: recent^[update] பதிப்புகள் DNS பதிவேடுகளை அரை மணி நேரத்திற்கு இடைமாற்று செய்கின்றன.^[10]

மற்ற பயன்பாடுகள்

மேலே கூறிய முறைமையானது ஓரளவுக்கு எளிமைப்படுத்தப்பட்ட சூழலை வழங்குகிறது. டொமைன் பெயர் முறைமையானது பிற பல செயல்பாடுகளையும் அடக்கியது:

• ஹோஸ்ட்பெயர்களும் ஐபி முகவரிகளும் ஒன்றுக்கு-ஒன்று அடிப்படையில் பொருத்தம் கொண்டிருக்க அவசியமில்லை. பல ஹோஸ்ட்பெயர்கள் ஒற்றை ஐபி முகவரிக்கு அணுகுவதாயிருக்கலாம்: வர்சுவல் ஹோஸ்டிங்குடன் இணைந்து, இது ஒற்றை கம்ப்யூட்டர் பல இணைய தளங்களுக்கு சேவை செய்ய அனுமதிக்கிறது. இதற்கு பதிலாக ஒரு ஒற்றை ஹோஸ்ட்பெயரும் பல ஐபி முகவரிகளுக்கு பொருத்தமடைவதாயும் அமையலாம்: இது பிழை பொறுப்பதற்கும் சுமை பகிர்வுக்கும் வசதியளிக்கும், அத்துடன் ஒரு தளத்தின் உருரீதியான இருப்பிடம் நகர்வது தெரியாமல் நகர்த்தப்படவும் இது அனுமதிக்கிறது.
• பெயர்களை ஐபி முகவரிகளாக மொழி பெயர்ப்பது தவிரவும் DNS பல பயன்களைக் கொண்டிருக்கிறது. உதாரணமாக, அஞ்சல் கொண்டு செல்லும் முகவர்கள் ஒரு குறிப்பிட்ட முகவரிக்கான மின்னஞ்சலை எங்கே வழங்க வேண்டும் என்பதைக் கண்டறிய DNS ஐப் பயன்படுத்துகின்றன. MX பதிவேடுகள் வழங்கும் டொமைனில் இருந்து மெயில் எக்ஸ்சேஞ்சருக்கு மேப்பிங் செய்வதற்கான வசதி பிழை பொறுப்பது மற்றும் சுமை பகிர்வின் இன்னுமொரு அடுக்கை ஐபி முகவரி மேப்பிங்கிற்கு பெயரின் உச்சியில் வழங்க வகை செய்கிறது.

• மின்னஞ்சல் பிளாக்லிஸ்டுகள்: பிளாக்லிஸ்டு செய்யப்பட்ட மின்னஞ்சல் ஹோஸ்டுகளின் ஐபி முகவரிகளை திறம்பட சேமிக்கவும் பகிர்ந்து கொள்ளவும் DNS பயன்படுத்தப்படுகிறது. பொதுவான வழிமுறை என்பது, சம்பந்தப்பட்ட ஹோஸ்டின் ஐபி முகவரியை உயர்நிலை டொமைன் பெயரின் சப்டொமைனுக்குள் போட்டு வைப்பது, அத்துடன் அந்த பெயரை ஒரு நேர்மறை அல்லது எதிர்மறை காட்டுவதற்கு வெவ்வேறு பதிவேடுகளுக்குத் தீர்ப்பது. blacklist.com பயன்படுத்தி ஒரு கருதுகோள் உதாரணம்,
  • 102.3.4.5 பிளாக்லிஸ்ட் செய்யப்படுகிறது => 5.4.3.102.blacklist.com ஐ உருவாக்கி 127.0.0.1 க்கு தீர்க்கிறது
  • 102.3.4.6 பிளாக்லிஸ்ட் செய்யப்படவில்லை => 6.4.3.102.blacklist.com காணப்படவில்லை, அல்லது 127.0.0.2 க்கு இயல்பமைவு
  • அதன்பின் தங்களுடன் இணைக்கும் ஒரு குறிப்பிட்ட ஹோஸ்ட் பிளாக்லிஸ்டில் இருக்கிறதா என்பதைக் காண மின்னஞ்சல் செர்வர்கள் DNS வகைமுறை மூலம் blacklist.com ஐ குவெரி செய்யும். இன்று இத்தகைய ஏராளமான பிளாக்லிஸ்டுகள், இலவசமாகவோ அல்லது சந்தா அடிப்படையிலோ, மின்னஞ்சல் நிர்வாகிகள் அல்லது வைரஸ் தடுப்பு மென்பொருளால் பயன்படுத்தப்படுவதற்கென கிடைக்கத்தக்கதாய் இருக்கின்றன.

• மென்பொருள் புதுப்பிப்புகள்: பல வைரஸ்-எதிர்ப்பு மற்றும் வர்த்தக மென்பொருட்கள் இப்போது சமீபத்திய மென்பொருள் புதுப்பிப்புகளுக்கான பதிப்பு எண்களை சேமிக்க DNS முறைமையைப் பயன்படுத்துகின்றன, இதனால் கிளையன்ட் கம்ப்யூட்டர்கள் ஒவ்வொரு முறையும் புதுப்பிப்பு செர்வர்களுடன் இணைப்பு கொள்ள அவசியமில்லை. இந்த வகை பயன்பாடுகளுக்கு, பொதுவாக DNS பதிவேடுகளின் இடைமாற்று நேரம் என்பது குறைவானதாய் இருக்கிறது.

• ஸென்டர் பாலிசி ஃபிரேம்ஒர்க் மற்றும் டொமைன்கீஸ் ஆகியவை எல்லாம், தங்களின் சொந்த பதிவேட்டு வகைகளை உருவாக்குவதற்கு பதிலாக, இன்னொரு DNS பதிவேட்டு வகையான TXT பதிவேட்டின் அனுகூலத்தைப் பயன்படுத்திக் கொள்ளும் வகையில் வடிவமைக்கப்பட்டவை.
• கம்ப்யூட்டர் பழுதடைந்து விடும் சூழ்நிலைக்கு மாற்று அளிப்பதற்காக, ஒவ்வொரு டொமைனுக்கும் பல DNS செர்வர்கள் பொதுவாக அடைக்கலம் அளிக்கின்றன, உயர் நிலையில், பதிமூன்று மிகவும் சக்தி வாய்ந்த வேர் செர்வர்கள் இருக்கின்றன, இவற்றில் பலவற்றின் கூடுதல் "நகல்கள்" உலகெங்கும் Anycast வழியாக பகிர்ந்தளிக்கப்பட்டிருக்கும்.
• டைனமிக் DNS (DDNS என்றும் குறிப்பிடப்படுகிறது) கிளையன்டுகளுக்கு DNS இல் இருக்கும் அவர்களின் ஐபி முகவரியை நகர்வுநிலை காரணமாக அது மாறிய பிறகு புதுப்பிக்கும் திறனை வழங்குகிறது, உ.ம்.

கோரிக்கைகளுக்கு சேவையாற்ற DNS பிரதானமாக போர்ட் எண் 53 ^[11] இல் யூசர் டேட்டாகிராம் புரோட்டோகால் (UDP) பயன்படுத்துகிறது. DNS குவெரிகள் கிளையன்டிடம் இருந்தான ஒற்றை UDP கோரிக்கையையும் அதனைத் தொடர்ந்து செர்வரில் இருந்தான ஒற்றை UDP மறுமொழியையும் கொண்டிருக்கும். மறுமொழி தரவின் அளவு 512 பைட்டுகளுக்கு அதிகமாக இருக்கும்போது, அல்லது மண்டல இடமாற்றங்கள் போன்ற பணிகளுக்கு டிரான்ஸ்மிசன் கன்ட்ரோல் புரோட்டோகால் (TCP) பயன்படுத்தப்படுகிறது. HP-UX போன்ற சில ஆபரேடிங் சிஸ்டம்கள், UDP போதுமாக இருக்கும் இடங்களிலும் கூட அனைத்து குவெரிகளுக்கும் TCP ஐ பயன்படுத்தக் கூடிய ரிஸால்வர் செயலாக்கங்கள் கொண்டிருப்பதற்கு பெயர்பெற்றவை.

ஆதார பதிவேடு (RR) என்பது டொமைன் பெயர் முறைமையில் உள்ள அடிப்படை தரவு உறுப்பு ஆகும். ஒவ்வொரு பதிவேடும் ஒரு வகை (A, MX, போன்றவை), காலாவதி நேர வரம்பு, வகுப்பு, மற்றும் சில குறிப்பிட்ட-வகைக்குரிய தரவு கொண்டிருக்கும். ஒரே வகையின் ஆதார பதிவேடுகள் ஒரு ஆதார பதிவேடு தொகுப்பை வரையறை செய்கின்றன. ஒரு பயன்பாட்டிற்கு ரிஸால்வரால் அனுப்பப்படும் ஒரு தொகுப்பில் ஆதார பதிவேடுகளின் வரிசை என்பது வரையறை செய்யப்படாதது, ஆனால் சுமை சமநிலையை சாதிக்கும் வகையிலான ரவுண்ட்-ராபின் வரிசைப்படுத்தலை பல சமயங்களில் செர்வர்கள் செயலாக்குகின்றன. ஆயினும், DNSSEC முழுமையான ஆதார பதிவேடு தொகுப்புகள் ஒரு சட்டவரிசையான ஒழுங்கிலிருக்கும் நிலையில் வேலை செய்கிறது.

ஒரு ஐபி நெட்வொர்க்கில் அனுப்பப்படும்போது, அனைத்து பதிவேடுகளும் RFC 1035 இல் குறிப்பிடப்பட்ட பொதுவான வடிவமைப்பை பயன்படுத்துகின்றன, இவை கீழே காட்டப்பட்டுள்ளன.

NAME என்பது மர அமைப்பிலுள்ள முனையத்தின் முழுத் தகுதியுற்ற டொமைன் பெயராகும். ஒயர் மீது, பெயரானது லேபல் கம்ப்ரஷன் முறை கொண்டு குறுக்கப்பட முடியும், இதில் பாக்கெட்டில் முன்பு குறிப்பிடப்பட்ட டொமைன் பெயர்களின் முனைகளை நடப்பு டொமைன் பெயரின் முனைகளுக்கு பதிலாக பிரதியீடு செய்யலாம்.

TYPE என்பது பதிவேட்டு வகை. தரவின் வடிவமைப்பை அது சுட்டிக்காட்டுவதோடு பயன்படுத்தப்பட இருக்கும் நோக்கத்தைக் குறித்த ஒரு குறிப்பையும் அளிக்கிறது. உதாரணமாக, ஒரு டொமைன் பெயரில் இருந்து ஒரு IPv4 முகவரியாக மாற்றுவதற்கு ஒரு A பதிவேடு பயன்படுத்தப்படுகிறது, NS பதிவேடு ஒரு DNS மண்டலத்திலான லுக்அப்களுக்கு எந்த பெயர் செர்வர்கள் பதிலளிக்கலாம் என்பதைப் பட்டியலிடுகிறது, MX பதிவேடு ஒரு மின்னஞ்சல் முகவரியில் குறிப்பிடப்பட்ட ஒரு டொமைனுக்கான மெயில் கையாள பயன்படும் மெயில் செர்வரைக் குறிப்பிடுகிறது (DNS பதிவேட்டு வகைகளின் பட்டியல் என்பதையும் காணவும்).

RDATA என்பது வகை-குறிப்பான பொருத்தமுடைய தரவு ஆகும், முகவரி பதிவேடுகளுக்கான ஐபி முகவரி, அல்லது MX பதிவேடுகளுக்கான முன்னுரிமை மற்றும் ஹோஸ்ட்பெயர் போன்றவை. நன்கறிந்த பதிவேட்டு வகைகள் RDATA புலத்தில் லேபல் கம்ப்ரஷனை பயன்படுத்தக் கூடும், ஆனால் "அறியப்படாத" பதிவேட்டு வகைகள் (RFC 3597) பயன்படுத்தக் கூடாது.

இன்டர்னெட் ஹோஸ்ட்பெயர்கள், செர்வர்கள், அல்லது ஐபி முகவரிகளை அடக்கிய பொதுவான DNS பதிவேடுகளுக்கு, ஒரு பதிவேட்டின் CLASS IN க்கு (இன்டர்னெட் என்பதற்கு)அமைக்கப்படுகிறது. இது தவிர CH (கயோஸ்) மற்றும் HS (ஹெஸியாட்) வகுப்புகளும் இருக்கின்றன. ஒவ்வொரு வகுப்பும் DNS மண்டலங்களின் வெவ்வேறு ஒதுக்கீடுகளுக்கான சாத்தியத்துடன் உள்ள ஒரு முழுமையான சுயாதீனமான மர அமைப்பாக இருக்கும்.

ஒரு மண்டல கோப்பில் வரையறுக்கப்படும் ஆதார பதிவேடுகள் தவிர, மற்ற DNS முனையங்களுடனான (ஒயர் மீது ) தொடர்பில் மட்டும் பயன்படுத்தப்படுகிற பல்வேறு கோரிக்கை வகைகளையும் டொமைன் பெயர் முறைமை வரையறை செய்கிறது, மண்டல இடமாற்றங்கள் (AXFR/IXFR) செய்யும் சமயம், அல்லது EDNS (OPT)க்காக போன்ற சமயங்களில்.

குழுக்குறி DNS பதிவேடுகள்

'*' என்கிற ஆஸ்டெரிஸ்க் லேபல் உடன் துவங்கக் கூடிய குழுக்குறி டொமைன் பெயர் களை டொமைன் பெயர் முறைமை ஆதரிக்கிறது, உதாரணமாக, *.example.^[5][12] குழுக்குறி டொமைன் பெயர்களுக்குரிய DNS பதிவேடுகள் ஒரு ஒற்றை DNS மண்டலத்துக்குள் ஆதார பதிவேடுகளை உருவாக்குவதற்கான விதிகளை குறிப்பிடுகின்றன, எந்த குறிப்பிட்ட வழித்தோன்றல்களும் உட்பட குவெரி பெயரின் பொருத்தமுறும் பாகங்களின் மொத்த லேபல்களையும் பிரதியீடு செய்கின்றன.உதாரணமாக, x.example என்னும் DNS மண்டலத்தில், பின்வரும் உள்ளமைவானது x.example இன் அனைத்து சப்-டொமைன்களும் (சப்டொமைன்களின் சப்டொமைன்கள் உள்பட) a.x.example என்னும் மெயில் எக்ஸ்சேஞ்சரைப் பயன்படுத்துவதாகக் குறிப்பிடுகிறது. a.x.example க்கான பதிவேடுகள் மெயில் எக்ஸ்சேஞ்சரைக் குறிப்பிட அவசியமாகின்றன. இந்த டொமைன் பெயர் மற்றும் இதன் சப்டொமைன்களை குழுக்குறி பொருத்தங்களில் இருந்து விலக்கும் விளைவை இது கொண்டிருக்கிறது என்பதால், a.x.example இன் அனைத்து சப்டொமைன்களும் ஒரு தனியான குழுக்குறி கூற்றில் வரையறுக்கப்பட்டிருக்க வேண்டும்.

X.EXAMPLE. MX 10 A.X.EXAMPLE.

• .X.EXAMPLE. MX 10 A.X.EXAMPLE.
• .A.X.EXAMPLE. MX 10 A.X.EXAMPLE.

A.X.EXAMPLE. MX 10 A.X.EXAMPLE.A.X.EXAMPLE. AAAA 2001:db8::1

குழுக்குறி பதிவேடுகளின் பாத்திரம் RFC 4592 இல் மேம்படுத்தப்பட்டது, ஏனென்றால் RFC 1034 இன் மூல வரையறையானது முழுமையற்றதாய் இருந்தது, செயலாக்குபவர்களால் தவறாகப் புரிந்து கொள்ள இட்டுச் சென்றது.^[12]

EDNS என்பது DNS புரோட்டோகாலின் ஒரு நீட்டிப்பாகும், UDP வழியே அனுப்பப்படும்போது DNS மறுமொழிகள் அதிகப்பட்ச அளவாக 512 பைட்டுகள் இருக்க வேண்டும் என்கிற அவசியப்பாட்டை இது கைவிடுகிறது. கோரிக்கை வெளி மற்றும் மறுமொழி குறியீடுகளின் வெளியை விரிவுபடுத்துவதற்கான ஆதரவை இது சேர்க்கிறது. இது RFC 2671 இல் விவரிக்கப்பட்டுள்ளது.

தொழில்நுட்பரீதியாக டொமைன் பெயர்கள் தாங்கள் பயன்படுதும் எழுத்துக்களில் எந்த கட்டுப்பாடுகளும் கொண்டிருக்கவில்லை, அவை non-ASCII எழுத்துக்களைக் கூட கொண்டிருக்க முடியும் என்றாலும், இது ஹோஸ்ட் பெயர்கள் விஷயத்தில் உண்மையில்லை.^[13] ஹோஸ்ட் பெயர்கள் என்பவை மின்னஞ்சல் மற்றும் வெப் பிரவுசிங் போன்ற விஷயங்களுக்கு அநேகம் பேர் பார்ப்பதும் பயன்படுத்துகிற பெயர்கள் ஆகும். LDH என்று அறியப்படும் ASCII எழுத்துகளின் ஒரு சிறிய தொகுப்புக்கு ஹோஸ்ட் பெயர்கள் கட்டுப்படுத்தப்பட்டுள்ளன, தலைப்பெழுத்தில் மற்றும் சிறிய எழுத்தில் A-Z வரையான எழுத்துகள் (L etters), 0-9 வரை எண்கள் (D igits), ஹைபன் (H yphen), மற்றும் LDH லேபல்களை பிரிக்கும் புள்ளி ஆகியவை; விவரங்களுக்கு RFC 3696 பிரிவு 2 ஐக் காணலாம். பல மொழிகளின் பெயர்கள் மற்றும் வார்த்தைகளை பூர்வீக மொழியில் குறிப்பிடுவதை இது தடுத்தது. ICANN ப்யூனிகோடு-அடிப்படையிலான IDNA முறைமைக்கு ஒப்புதலளித்துள்ளது, இது யூனிகோடு வார்த்தைகளை செல்லுபடியாகும் DNS எழுத்து தொகுப்பாக மாற்றுகிறது, இது இந்த பிரச்சினைக்கு ஒரு மாற்றாக முயற்சிக்கப்படுகிறது. சில பதிவகங்கள் IDNA ஐ தழுவியுள்ளன.

DNS ஆரம்பத்தில் பாதுகாப்பை மனதில் வைத்து உருவாக்கப்பட்டதல்ல, இதனால் இது ஏராளமான பாதுகாப்பு பிரச்சினைகளைக் கொண்டுள்ளது.

ஏமாறச் செய்யும் ஓட்டையில் ஒரு வகை DNS இடைமாற்று விஷமாகல் என்பது, இதில் ஒரு DNS சர்வர் தான் நம்பகமான விவரங்களைப் பெற்றுள்ளதாக நம்ப வைக்கப்படுகிறது, ஆனால் உண்மையில் அவ்வாறு இருக்காது.

DNS மறுமொழிகள் மரபுவழியாக ரகசியக்குறியீடு முறையில் கையொப்பமிடப்படுவன அல்ல, இது பல தாக்குதல் சாத்தியங்களுக்கு இட்டுச் செல்கிறது; டொமைன் பெயர் முறைமை பாதுகாப்பு நீட்டிப்புகள் (DNSSEC) ரகசியக் குறியீடு முறையில் கையொப்பமிட்ட மறுமொழிகளுக்கு ஆதரவளிக்கும் வகையில் DNS ஐ திருத்துகிறது. மண்டல மாற்ற விவரங்களையும் பாதுகாப்பதற்கு ஆதரவளிக்கும் பல்வேறு நீட்டிப்புகளும் கூட உள்ளன.

குறியீடு செய்யப்பட்டும் கூட, ஒரு வைரஸ் மூலம் (அல்லது இந்த விஷயத்தில் அதிருப்தியுடனான ஒரு பணியாளர் மூலமும் கூட) ஒரு DNS செர்வரின் பாதுகாப்பு சமரசத்திற்குள்ளாகலாம், இது அந்த செர்வரின் ஐபி முகவரிகளை ஒரு நீளமான TTL உடனான ஒரு தீங்கான முகவரிக்கு மறுசெலுத்தம் செய்ய காரணமாகலாம். பிஸியான DNS செர்வர்கள் மோசமான ஐபி தரவை இடைமாற்றில் கொண்டிருக்குமானால் இது மில்லியன்கணக்கான இணைய பயனர்களை பாதிக்கும் வகையில் நீண்ட பாதிப்பை ஏற்படுத்தக் கூடும். இது அந்த நீண்ட TTL (68 ஆண்டுகள் வரை) கோருவது போல் பாதிக்கப்பட்ட அனைத்து DNS இடைமாற்றுகளையும் ஆள் உட்கார்ந்து வெளியேற்ற வேண்டியிருப்பதை அவசியமாக்கலாம்.

சில டொமைன் பெயர்கள் அதனையொத்த டொமைன் பெயர்களை ஒட்டி ஏமாற்றுவதாக இருக்கும். உதாரணமாக, "paypal.com" மற்றும் "paypa1.com" என்பவை வெவ்வேறு பெயர்கள், ஆனால் பயனரின் எழுத்துரு வடிவத்தின் காரணத்தால் அவர் எழுத்து l க்கும் எண்ணிக்கை 1 க்கும் இடையில் வித்தியாசம் காண முடியாமல் போகலாம்.சர்வதேசமயப்பட்ட டொமைன் பெயர்களை ஆதரிக்கும் முறைமைகளில் இந்த பிரச்சினை இன்னும் கூடுதலான சிக்கலாய் இருக்கும்,ஏனென்றால் ISO 10646 இன் பார்வையில் வெவ்வேறாய் இருக்கும் பல எழுத்து வடிவங்கள்,சாதாரண கம்ப்யூட்டர் திரைகளில் ஒரேமாதிரி காட்சியளிக்கும். இந்த ஓட்டையானது பல சமயங்களில் பிஷிங் எனப்படும் இணையதள மாறாட்ட மோசடிக்கு ஏதுவாகி விடுகிறது.

DNS முடிவுகளை சரிபார்க்க உதவ ஃபார்வர்டு கன்ஃபர்ம்டு ரிவர்ஸ் DNS போன்ற நுட்பங்கள் பயன்படுத்தப்படலாம்.

ஒரு டொமைன் பெயரை பயன்படுத்துவதற்கான உரிமையானது இன்டர்னெட்டில் பெயர் மற்றும் எண்ணிக்கை முறைமைகளை ஒழுங்குபடுத்துவதற்கு பொறுப்பான அமைப்பான இன்டர்னெட் கார்பரேஷன் ஃபார் அசைன்டு நேம்ஸ் அன் நம்பர்ஸ் (ICANN) மூலம் அங்கீகரிக்கப்பட்ட டொமைன் பெயர் பதிவாளர்களால் ஒதுக்கப்படுகிறது. ICANN தவிர, ஒவ்வொரு உயர்-நிலை டொமைனும் (TLD) பதிவகத்தை செயல்படுத்தும் ஒரு நிர்வாக அமைப்பு மூலம் பராமரிக்கப்படவும் தொழில்நுட்ப சேவையாற்றப்படவும் செய்கிறது. ஒரு பதிவகம், தான் நிர்வகிக்கும் TLD க்குள்ளாக பதிவு செய்யப்பட்டுள்ள பெயர்களின் தரவுத்தளத்தை பராமரிப்பதற்கு பொறுப்பானதாகும். உரிய TLD இல் பெயர்களை ஒதுக்கும் அங்கீகாரம் பெற்றிருக்கும் ஒவ்வொரு டொமைன் பெயர் பதிவாளரிடமிருந்தும் வரும் பதிவு விவரங்களை பதிவகம் பெறுகிறது, அத்துடன் இது அந்த விவரங்களை ஹூஇஸ் புரோட்டோகால் என்னும் ஒரு சிறப்பு சேவையின் உதவியுடன் வெளியிடுகிறது.

ஒரு பயனருக்கு ஒரு டொமைன் பெயர் ஒதுக்குவதற்கும் பெயர் செர்வர்களின் ஒரு வழக்கமான தொகுப்பினை வழங்குவதற்கும் பொதுவாக பதிவகங்களும் பதிவாளர்களும் ஒரு வருடாந்திர கட்டணத்தை சேவைக்கென வசூலிக்கிறார்கள். இந்த பரிவர்த்தனை பல சமயங்களில் டொமைன் பெயர் விற்பனை அல்லது குத்தகை என குறிப்பிடப்படுகிறது, பதிவு செய்யும் பயனர் சில சமயங்களில் "உரிமையாளர்" என அழைக்கப்படுகிறார், ஆனால் உண்மையில் இத்தகைய பெயர்களுக்கான சட்டப்பூர்வ உறவுமுறை எதுவும் இந்த பரிவர்த்தனையுடன் தொடர்புபட்டிருக்கவில்லை, வெறுமனே டொமைன் பெயரைப் பயன்படுத்துவதற்கான பிரத்யேக உரிமை மட்டுமே வழங்கப்பட்டுள்ளது. சற்று சரியாக சொல்வதானால், அங்கீகாரம் பெற்ற பயனர்கள் "பதிவு செய்தவர்கள்" அல்லது "டொமைன் வைத்திருப்பவர்கள்" என அறியப்படுகிறார்கள்.

உலகிலுள்ள TLD பதிவகங்கள் மற்றும் டொமைன் பெயர் பதிவாளர்களின் ஒரு முழுமையான பட்டியலை ICANN வெளியிடுகிறது. ஒரு டொமைன் பெயரை பதிவு செய்துள்ளவர் குறித்த விவரங்களை ஒருவர் பல டொமைன் பதிவகங்கள் கொண்டிருக்கும் ஹூஇஸ் தரவுத்தளத்தில் தேடுவதன் மூலம் பெற முடியும்.

240 க்கும் அதிகமான நாட்டு குறியீடு உயர்-நிலை டொமைன்கள் (ccTLD) அநேகமானவற்றிற்கு, டொமைன் பதிவகங்கள் தான் அதிகாரப்பூர்வ ஹூஇஸ் விவரங்களை (பதிவு செய்தவர், பெயர் செர்வர்கள், காலாவதியாகும் காலங்கள், மற்றவை.) கொண்டிருக்கின்றன. உதாரணமாக DENIC, Germany NIC, .DE டொமைன் பெயருக்கான அதிகாரப்பூர்வ ஹூஇஸ் கொண்டிருக்கிறது. ஏறத்தாழ 2001 ஆம் ஆண்டிலிருந்து, அநேக gTLD பதிவகங்கள் (.ORG, .BIZ, .INFO) இந்த "வல்லிய" (thick) பதிவக அணுகுமுறை என்று அழைக்கப்படுவதை பின்பற்றுகின்றன, அதாவது அதிகாரப்பூர்வ ஹூஇஸ் விவரங்களை பதிவாளர்களுக்கு பதிலாக மத்திய பதிவகங்களில் பராமரிப்பது.

COM மற்றும் NET டொமைன் பெயர்களுக்கு ஒரு "மெல்லிய" (thin) பதிவகம் பயன்படுத்தப்படுகிறது: டொமைன் பதிவகம் (உ-ம் வெரிசைன்) தான் ஒரு அடிப்படை ஹூஇஸ் (பதிவு செய்தவர் மற்றும் பெயர் செர்வர்கள் போன்றவை) கொண்டிருக்கும். விரிவான ஹூஇஸ் விவரங்களை (பதிவு செய்தவர், பெயர் செர்வர்கள், காலாவதி நாட்கள், மற்றவை) ஒருவர் பதிவாளர்களிடம் காண முடியும்.

பல சமயங்களில் நெட்வொர்க் தகவல் மையங்கள் (NIC) என்று அழைக்கப்படுவதான சில டொமைன் பெயர் பதிவகங்களும் இறுதிப் பயனாளர்களுக்கான பதிவாளர்களாக செயல்படுகின்றன. COM, NET, ORG, INFO மற்றும் பிற டொமைன்களுக்கானவை போன்ற பெரிய பொதுவான வகை உயர்-நிலை டொமைன் பதிவகங்கள் நூற்றுக்கணக்கான டொமைன் பெயர் பதிவாளர்களை (பட்டியல்களை ICANN அல்லது VeriSign இல் காணலாம்) கொண்ட பதிவகம்-பதிவாளர் மாதிரியைப் பயன்படுத்துகின்றன. இந்த நிர்வாக வழிமுறையில், பதிவகமானது டொமைன் பெயர் தரவுத்தளத்தையும் பதிவாளர்களுடனான உறவினை மட்டுமே நிர்வகிக்கிறது. பதிவு செய்பவர்கள் (ஒரு டொமைன் பெயரைப் பயன்படுத்துபவர்கள்) பதிவாளரின் வாடிக்கையாளர்கள், சில சமயங்களில் மறுவிற்பனை செய்பவர்களின் கூடுதலான அடுக்குகள் வழி வருபவர்களாகவும் இருக்கலாம்.

ஒரு டொமைன் பெயரை பதிவு செய்து உருவாக்கப்பட்ட புதிய பெயர் வெளி மீது அதிகாரத்தை பராமரிப்பதான நிகழ்முறையில், ஒரு டொமைனுடன் தொடர்புடைய பல முக்கிய விவரங்களை பதிவாளர்கள் பயன்படுத்துகிறார்கள்:

• நிர்வாக தொடர்பு . பதிவு செய்பவர் பொதுவாக டொமைன் பெயரை நிர்வகிக்க ஒரு நிர்வாக தொடர்பை நியமிக்கிறார். பொதுவாக நிர்வாகத் தொடர்பின் கைவசம் தான் ஒரு டொமைன் மீதான மிக உயர்ந்த கட்டுப்பாடு இருக்கும். நிர்வாகத் தொடர்புகளுக்கு ஒதுக்கப்படும் நிர்வாக செயல்பாடுகளில் அனைத்து வர்த்தக விவரங்களையும் - அதாவது டொமைன் பெயரை அதிகாரப்பூர்வமாக பதிவு செய்தவரின் பெயர், அஞ்சல் முகவரி மற்றும்

தொடர்பு விவரங்கள் - நிர்வகிப்பது மற்றும் ஒரு டொமைன் பெயரை பயன்படுத்துவதற்கான உரிமையை தொடர்ந்து தக்கவைத்துக் கொள்வது தொடர்பான டொமைன் பதிவக அவசியப்பாடுகளை பூர்த்தி செய்யும் கடமைப்பாடு கொண்டிருப்பது ஆகியவை அடக்கம். அதுதவிர தொழில்நுட்ப மற்றும் பில்லிங் செயல்பாடுகளுக்கென கூடுதல் தொடர்பு விவரங்களையும் நிர்வாகத் தொடர்பு நிறுவுகிறது.

• தொழில்நுட்பத் தொடர்பு . தொழில்நுட்பத் தொடர்பு ஒரு டொமைன் பெயரின் பெயர் செர்வர்களை நிர்வகிக்கிறது. ஒரு தொழில்நுட்பத் தொடர்பின் செயல்பாடுகளில், டொமைன் பதிவகத்தின் அவசியப்பாடுகளைப் பூர்த்தி செய்கிற வகையில் டொமைன் பெயர் அமைவுகள் நிறுவப்பட்டிருப்பதை உறுதி செய்வது, டொமைன் மண்டல பதிவுகளை பராமரிப்பது, மற்றும் பெயர் செர்வர்களின் தொடர்ந்த செயல்பாட்டுத்தன்மையை அளிப்பது (இது டொமைன் பெயர் அணுகல்தன்மைக்கு இட்டுச் செல்கிறது) ஆகியவை அடங்கும்.
• பில்லிங் தொடர்பு . டொமைன் பெயர் பதிவாளரிடம் இருந்தான பில்லிங் இன்வாய்ஸ்களைப் பெறுவதற்கும் பொருத்தமான கட்டணங்களை செலுத்துவதற்கும் பொறுப்பான தரப்பு.
• பெயர் செர்வர்கள் . அநேக பதிவாளர்கள் பதிவு சேவையின் பாகமாக இரண்டு அல்லது கூடுதலான பெயர் செர்வர்களை வழங்குகின்றனர். ஆனாலும் ஒரு டொமைனின் வளஆதார பதிவேடுகளை ஹோஸ்ட் செய்வதற்கு அதன் சொந்த அதிகாரமுற்ற பெயர் செர்வர்களை, பதிவு செய்யும் ஒருவர் குறிப்பிட்டுக் கூற முடியும். பதிவாளரின் கொள்கைகள் தான் செர்வர்களின் எண்ணிக்கை மற்றும் அவசியமான செர்வர் தகவல் வகையை கட்டுப்படுத்துகின்றன. சில வழங்குநர்கள் ஒரு ஹோஸ்ட்பெயர் மற்றும் அதற்குரிய ஐபி முகவரி அல்லது வெறும் ஹோஸ்ட்பெயரைக் கோருகிறார்கள் - அது புதிய டொமைனிலோ அல்லது வேறெங்கும் இருந்து கொண்டோ தீர்க்கத்தக்கதாய் அமைய வேண்டும். வழமையான அவசியப்பாடுகளின் அடிப்படையில் (RFC 1034), பொதுவாக குறைந்தது இரண்டு செர்வர்கள் அவசியம்.

டொமைன் பெயர்களில் நிர்வாக அதிகாரம் தவறாக பயன்படுத்தப்படுவதாக பல சமயங்களில் விமர்சகர்கள் புகார் கூறுகிறார்கள். குறிப்பாய் குறிப்பிடத்தக்கது வெரிசைன் சைட் ஃபைன்டர் அமைப்பு அனைத்து பதிவு செய்யாத .காம் மற்றும் .நெட் டொமைன்களை ஒரு வெரிசைன் இணையப்பக்கத்திற்கு வழிதிருப்பியதாகும். உதாரணமாக, சைட்ஃபைன்டர்^[14] குறித்த தொழில்நுட்ப பிரச்சினைகளைப் புகார் தெரிவிப்பதற்காக வெரிசைன் உடன் ஏற்பாடு செய்யப்பட்டிருந்த பொது சந்திப்பு ஒன்றில், IETF மற்றும் பிற தொழில்நுட்ப அமைப்புகளில் அங்கம் வகிக்கும் ஏராளமான பேர், இன்டர்னெட்டின் உள்கட்டமைப்பின் ஒரு முக்கிய பாகத்தின் அடிப்படை நடத்தையை வெரிசைன் எவ்வாறு மாற்றிக் கொண்டிருக்கிறது, அதிலும் பயனர்களின் சம்மதம் இல்லாமலேயே என்பது தங்களை அதிர்ச்சியில் ஆழ்த்தியதாக விளக்கினர். சைட்ஃபைன்டர், முதலில், ஒவ்வொரு இன்டர்னெட் தேடலையும் ஒரு இணையத்தளத்திற்கானதாக அனுமானித்தது, அத்துடன் பிழையான டொமைன் பெயர்களுக்கான தேடல்களை, பயனரை வெரிசைன் தேடல் தளத்திற்கு அழைத்துச் செல்வதன் மூலம், காசாக்கியது. துரதிர்ஷ்டவசமாக, மின்னஞ்சலின் பல செயலாக்கங்கள் போன்ற பிற பயன்பாடுகள், ஒரு டொமைன் பெயர் தேடலுக்கு மறுமொழியில்லை என்பதை அந்த டொமைன் இருக்கவில்லை என்பதன் அடையாளமாக எடுத்துக் கொண்டு, அளித்த செய்தி விநியோகிக்க முடியாதது என்று கருதின. ஆனால் வெரிசைன் ஆரம்ப செயலாக்கமோ மெயில் சேவையின் இந்த அனுமானத்தை உடைத்தது, ஏனென்றால் இது எப்போதும் ஒரு பிழையான டொமைன் பெயரை சைட்ஃபைன்டருடையதற்கு தீர்த்து விடுகிறது. மின்னஞ்சலைப் பொறுத்தவரை சைட்ஃபைன்டரின் நடத்தையை வெரிசைன் பின்னாளில் மாற்றிக் கொண்டது என்றாலும், வெரிசைனின் நடவடிக்கைகள் அது மாலுமியாக இருக்கும் இன்டர்னெட் உள்கட்டமைப்பு பாகத்தின் நலனை விட தன் சொந்த நிதி நிலனைத் தான் அதிகம் கருதுவதாக இருப்பதாக தொடர்ந்து பரவலான எதிர்ப்பு இருந்து கொண்டு தான் இருந்தது.

பரவலான விமர்சனங்கள் வந்த போதும் கூட, இன்டர்னெட் கார்பரேஷன் ஃபார் அசைன்டு நேம்ஸ் அன் நம்பர்ஸ் (ICANN) வேர் பெயர் செர்வர்களை நிர்வகிப்பதற்கான ஒப்பந்தத்தை திரும்பப் பெற்றுக் கொள்ளப் போவதாக அச்சுறுத்திய பிறகு தான் வெரிசைன் தயக்கத்துடன் அதனை அகற்றியது. பரிமாறிக் கொள்ளப்பட்ட கடிதங்கள், குழு அறிக்கைகள், மற்றும் ICANN முடிவுகளின்^[15] விரிவான தொகுதி ஒன்றை ICANN வெளியிட்டது.

அத்துடன் ICANN மீது அமெரிக்காவின் அரசியல்ரீதியான செல்வாக்கு தொடர்பாகவும் குறிப்பிடத்தகுந்த அளவில் அமைதியின்மை நிலவுகிறது. ஒரு .xxx உயர்-நிலை டொமைனை உருவாக்கும் முயற்சியில் இது ஒரு குறிப்பிடத்தக்க பிரச்சினையாக இருக்கிறது, எந்த ஒற்றை நாட்டின் கட்டுப்பாட்டையும் தாண்டிய மாற்று DNS வேர்களில் பெரும் கவனத்தை தூண்டியிருக்கிறது.^[16]

இது தவிர, டொமைன் பெயரில் "முந்திக் கொள்வது" குறித்த ஏராளமான குற்றச்சாட்டுகளும் எழுந்திருக்கின்றன, ஹூயிஸ் குவெரிக்களை பெறும் பதிவாளர்கள் தானியங்கு முறையில் அந்த டொமைன் பெயரை தங்களுக்கே பதிவு செய்து கொள்வது. சமீபத்தில், நெட்வொர்க் சொல்யூஷன்ஸ் நிறுவனம் இந்த குற்றச்சாட்டில் சிக்கியிருக்கிறது.^[17]

டொமைன் பெயரில் உண்மை சட்டம்

அமெரிக்காவில், 2003 ஆம் ஆண்டின் டொமைன் பெயரில் உண்மை சட்டம் (Truth in Domain Names Act) 2003 ஆம் ஆண்டின் பாதுகாப்பு சட்டத்துடன் (PROTECT Act) இணைந்து, பார்வையாளர்களை இன்டர்னெட் ஆபாசத் தளங்களை பார்வையிடச் செய்வதற்கு கவரும் நோக்கத்துடன் தவறாக வழிநடத்தக் கூடிய டொமைன் பெயர் பயன்பாட்டை தடை செய்கிறது.

டொமைன் பெயர் முறைமையானது இன்டர்னெட் இன்ஜினியரிங் டாஸ்க் ஃபோர்ஸ் (இன்டர்னெட் நிர்ணயங்கள்) மூலம் வெளியிடப்படுகிற ரெக்வஸ்ட் ஃபார் கமெண்ட்ஸ் (RFC) ஆவணங்கள் மூலம் வரையறை செய்யப்படுகின்றன. DNS புரோட்டோகாலை வரையறை செய்யும் RFC க்களின் பட்டியல் ஒன்று கீழே வழங்கப்பட்டுள்ளது.

• RFC 920, டொமைன் அவசியப்பாடுகள் - குறிப்பிடப்பட்ட மூல உயர்-நிலை டொமைன்கள்
• RFC 1032, டொமைன் நிர்வாகிகள் வழிகாட்டி
• RFC 1033, டொமைன் நிர்வாகிகள் செயல்பாடுகள் வழிகாட்டி
• RFC 1034, டொமைன் பெயர்கள் - கருத்துருக்களும் வசதிகளும்
• RFC 1035, டொமைன் பெயர்கள் - அமலாக்கம் மற்றும் நிர்ணய தரவு
• RFC 1101, நெட்வொர்க் பெயர்கள் மற்றும் பிற வகைகளுக்கான DNS குறியீடுகள்
• RFC 1123, இன்டர்னெட் ஹோஸ்ட்களுக்கான அவசியப்பாடுகள்-பயன்பாடு மற்றும் ஆதரவு
• RFC 1178, உங்களது கம்ப்யூட்டருக்கு ஒரு பெயரைத் தேர்வு செய்வது (FYI 5)
• RFC 1183, புதிய DNS RR வரையறைகள்
• RFC 1591, டொமைன் பெயர் முறைமை கட்டமைப்பு மற்றும் ஒதுக்கீடு (தகவல்வகையானது)
• RFC 1912, பொதுவான DNS செயல்பாட்டு மற்றும் உள்ளமைவு பிழைகள்
• RFC 1995, DNS இல் மிகுப்பு மண்டல இடமாற்றம்
• RFC 1996, மண்டல மாற்றங்களின் உடனடியான அறிவிப்புக்கான ஒரு வகைமுறை (DNS NOTIFY)
• RFC 2100, ஹோஸ்ட்களின் பெயரிடுமுறை (தகவல்வகையானது)
• RFC 2136, டொமைன் பெயர் முறைமையில் அவ்வப்போதான புதுப்பிப்புகள் (DNS UPDATE)
• RFC 2181, DNS நிர்ணய தரவிற்கான விளக்கங்கள்
• RFC 2182, செகண்டரி DNS செர்வர்களின் தேர்வு மற்றும் செயல்பாடு
• RFC 2308, DNS குவெரிகளின் எதிர்மறை இடைமாற்று (DNS NCACHE)
• RFC 2317, வகுப்பற்ற IN-ADDR.ARPA ஒதுக்கீடு (BCP 20)
• RFC 2671, DNS க்கான நீட்டிப்பு வகைமுறைகள் (EDNS0)
• RFC 2672, நான்-டெர்மினல் DNS பெயர் வழிமாற்றம்
• RFC 3225, DNSSEC இன் ரிஸால்வர் ஆதரவை சுட்டிக்காட்டுதல்
• RFC 3226, DNSSEC மற்றும் IPv6 A6 உணரத்தக்க செர்வர்/ரிஸால்வர் செய்தி அளவு அவசியப்பாடுகள்
• RFC 3597, அறியப்படாத DNS ஆதார பதிவேட்டு (RR)வகைகளை கையாளுதல்
• RFC 3696, பெயர்களின் பரிசோதனை மற்றும் உருமாற்றத்திற்கான பயன்பாட்டு தொழில்நுட்பங்கள் (தகவல்வகையானது)
• RFC 4343, டொமைன் பெயர் முறைமை (DNS) எழுத்து தலைப்பாக்கம் உணராநிலை விளக்கம்
• RFC 4592, டொமைன் பெயர் முறைமையில் குழுக் குறிகளின் பாத்திரம்
• RFC 4892, ஒரு பெயர் செர்வர் பிரதியை அடையாளம் காண்பதற்கான ஒரு வகைமுறைக்கான அவசியப்பாடுகள் (தகவல்வகையானது)
• RFC 5001, DNS பெயர் செர்வர் ஐடன்டிஃபையர் (NSID) தேர்வு
• RFC 5395, டொமைன் பெயர் முறைமை (DNS) IANA கருதல்கள் (BCP 42)

பாதுகாப்பு

• RFC 4033, DNS பாதுகாப்பு அறிமுகம் மற்றும் அவசியப்பாடுகள்
• RFC 4034, DNS பாதுகாப்பு நீட்டிப்புகளுக்கான ஆதார பதிவேடுகள்
• RFC 4035, DNS பாதுகாப்பு நீட்டிப்புகளுக்கான புரோட்டோகால் திருத்தங்கள்

• DNS காம்ப்ளெக்சிட்டி, பால் விக்ஸி, ACM க்யூ
• ஓபன் சோர்ஸ் கைடு - ராக்கெட் விஞ்ஞானிகளுக்கான DNS, கூடுதல் வாசிப்புக்கான ஒரு ஆன்-லைன் தொழில்நுட்ப புத்தகம்
• சில DNS கருவிகளின் ஒரு பட்டியல் பரணிடப்பட்டது 2006-09-02 at the வந்தவழி இயந்திரம்
• CircleID - DNS தொடர்பான அனைத்து தலைப்புகள் மற்றும் இன்டர்னெட் புரோட்டோகால்களுக்கான திறந்த செய்திகள் மற்றும் கருத்து மையம்