Panix.com டொமைன் கடத்தல்: நியூயார்க்கின் மிகப் பழைய ISP-ஐ மோசடியாகப் பரிமாற்றிய சம்பவம்

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

ஒரு சேவையகத்தை hack செய்து அல்ல. திருடப்பட்ட கிரெடிட் கார்டு விவரங்களைக் கொண்டு தொடங்கப்பட்ட reseller கணக்கின் வழியாக அங்கீகரிக்கப்படாத பரிமாற்றக் கோரிக்கை சமர்ப்பிக்கப்பட்டது. டொமைன் நகர்த்தப்படுவதற்கு முன் Panix-க்கு அறிவிப்பு வரவில்லை; ஆனால் அதன் அப்போதைய ரெஜிஸ்ட்ராரான Dotster-க்கு registry அறிவிப்பு வந்திருந்தும், ஐந்து நாள் பரிமாற்றக் காலக்கெடுவுக்குள் அது எந்த நடவடிக்கையும் எடுக்கவில்லை.

ஒரு server exploit அல்லாமல், தோல்வியடைந்த அடையாளச் சரிபார்ப்பும் ரெஜிஸ்ட்ராரின் செயல்பாடுகளும் நியூயார்க்கின் மிகப் பழைய ISP-யை எவ்வாறு கடத்தின — மேலும் இந்தச் சம்பவம் ஏன் பரிமாற்றப் பாதுகாப்பில் ஒரு முக்கிய case study ஆனது — என்பதே இந்தக் கதை.

தனது முழு வணிகத்தையும் ஒரே டொமைனில் கொண்டிருந்த முன்னோடி ISP

Panix — Public Access Networks Corporation — ஒரு சிறிய நிறுவனம் அல்ல. 1989-ல் தொடங்கப்பட்ட அது, Wikipedia-வின் கூற்றுப்படி, The World மற்றும் NetCom-க்கு அடுத்தபடியாக உலகின் மூன்றாவது மிகப் பழைய ISP ஆகும். நியூயார்க் நகரின் ஆரம்பகால வணிக இணையத்தில் அது ஒரு நிலையான அங்கமாக இருந்தது: shell கணக்குகள், மின்னஞ்சல், web hosting, dial-up மற்றும் பின்னர் ஆயிரக்கணக்கான நியூயார்க் மக்களை இணையத்துடன் இணைத்த broadband இணைப்புகள்.

அன்றும் இன்றும் கிட்டத்தட்ட ஒவ்வொரு இணைய வணிகத்தையும் போலவே, Panix-ன் அடையாளமே அதன் டொமைனாக இருந்தது. வாடிக்கையாளர் அஞ்சல் பெட்டிகள் @panix.com என்று முடிந்தன. இணையச் சேவையகங்கள் www.panix.com முகவரியில் பதிலளித்தன. நிறுவனம் முழுவதும் — அதன் brand, அதை அணுகும் திறன், வாடிக்கையாளரின் மின்னஞ்சலை உண்மையில் வந்து சேரச் செய்த அமைப்பு — ஒரே பெயருடன் இணைக்கப்பட்ட DNS பதிவுகளைச் சார்ந்திருந்தது. அந்தப் பெயரின் கட்டுப்பாட்டை இழந்தால், marketing asset ஒன்றை மட்டும் இழப்பதில்லை. வணிகத்தின் நரம்பு மண்டலத்தையே இழக்கிறீர்கள்.

அதுதான் நடந்தது.

2005 ஜனவரி: மோசடிப் பரிமாற்றம்

சட்டரீதியான பதிவு, சம்பவ நாள் குறித்து துல்லியமாக உள்ளது. Davis Wright Tremaine சட்ட நிறுவனம் அப்போது சுருக்கியபடி, ஜனவரி 14, 2005, வெள்ளிக்கிழமை, நியூயார்க்கைச் சேர்ந்த அதே பெயருடைய இணையச் சேவை வழங்குநருக்குச் சொந்தமான "panix.com" டொமைன் பெயர் அங்கீகாரமின்றி மூன்றாம் தரப்புக்கு மாற்றப்பட்டபோது முக்கியத்துவம் வாய்ந்த ஒரு கடத்தல் நடந்தது.

அந்த வார இறுதியின் அதிகாலை நேரத்திற்குள் விளைவுகள் நேரலையில் தெரிந்தன. சம்பவம் நடந்துகொண்டிருந்தபோதே செய்தி வெளியிட்ட The Register, திசைமாற்றத்தை இன்னமும் ஒரு கொள்ளை வரைபடத்தைப் போலப் படிக்கக்கூடிய ஒரே வாக்கியத்தில் விவரித்தது: panix.com-ன் ownership ஆஸ்திரேலியாவில் உள்ள ஒரு நிறுவனத்துக்கு மாற்றப்பட்டது, அதன் உண்மையான DNS பதிவுகள் ஐக்கிய இராச்சியத்தில் உள்ள ஒரு நிறுவனத்துக்கு மாற்றப்பட்டன, மேலும் Panix.com-ன் மின்னஞ்சல் கனடாவில் உள்ள மற்றொரு நிறுவனத்துக்கு திசைமாற்றப்பட்டது.

இந்தச் செய்தி ஜனவரி 16 அன்று பரந்த தொழில்நுட்பச் சமூகத்திடம் பரவிய Slashdot, விஷயத்தை நேரடியாகக் கூறியது: நியூயார்க்கின் மிகப் பழைய வணிக இணையச் சேவை வழங்குநரான Panix-ன் 'panix.com' டொமைன் பெயர் யார் என்று தெரியாத நபர்களால் கடத்தப்பட்டது.

தனக்கோ தனது ரெஜிஸ்ட்ராருக்கோ அறிவிப்பு வரவில்லை என்று Panix அப்போது கூறியது. ICANN பின்னர் வெளியிட்ட முறையான காலவரிசை அந்த எல்லையைத் தெளிவுபடுத்தியது: Panix-க்கு அறிவிப்பு வரவில்லை; ஆனால் ஜனவரி 9 அன்று Dotster-க்கு registry அறிவிப்பு வந்தது, ஐந்து நாட்களுக்குப் பிறகு பரிமாற்றம் தானாக அங்கீகரிக்கப்படுவதற்கு முன் அது நடவடிக்கை எடுக்கவில்லை. சட்டப்பூர்வ உரிமையாளருக்கு இந்தச் சம்பவம் தெரியாமல் இருந்தது; ஆனால் பரிமாற்றப் பாதையில் இருந்த ஒவ்வொரு அமைப்புக்கும் தெரியாமல் இல்லை.

இடையூறு: இணையமும் மின்னஞ்சலும் பல நாட்கள் செயலிழந்தன

கடத்தப்பட்ட டொமைன் என்பது சுத்தமான on/off switch அல்ல — அது மெதுவான, குழப்பமான சரிவு; அதன் மிக மோசமான சேதம் மின்னஞ்சலுக்கே ஏற்படுகிறது.

ஒரு டொமைனின் DNS-ஐ நீங்கள் கட்டுப்படுத்தினால், அதன் மின்னஞ்சல் எங்கு வழங்கப்பட வேண்டும் என்பதை மாற்றலாம். இந்தச் சம்பவத்தில், Fibranet payment fraud-ஐ சந்தேகித்து டொமைனை lock செய்து park செய்ததாகவும், default configuration மின்னஞ்சலை Fibranet-ன் U.K. mail server-க்கு அனுப்பியதாகவும் சம்பவத்திற்குப் பிந்தைய SSAC அறிக்கை கண்டறிந்தது. Panix வாடிக்கையாளர்கள் சுமார் இரண்டு நாட்களுக்கு மின்னஞ்சல் அணுகலை இழந்தனர்; ஆனால் தவறாகத் திசைமாற்றப்பட்ட அஞ்சல் படிக்கப்பட்டதற்கோ வேறு விதமாகத் தவறாகப் பயன்படுத்தப்பட்டதற்கோ ஆதாரம் இல்லை என்று Panix தெரிவித்தது. கணக்கு lock செய்யப்பட்ட பிறகு தாக்குதலாளரால் DNS-ஐத் தொடர்ந்து மாற்றவும் முடியவில்லை.

கடத்தலின்போது தவறான இடத்துக்கு அனுப்பப்படும் மின்னஞ்சல் தாமதமாகலாம், திரும்ப அனுப்பப்படலாம், கைவிடப்படலாம் அல்லது அது செல்லக்கூடாத ஓர் அமைப்பிடம் வெளிப்படலாம். இந்தச் சம்பவத்தில் ஆவணப்படுத்தப்பட்ட பாதிப்பு மின்னஞ்சல் சேவையையும் செய்திகளையும் இழந்ததே; செய்திகளின் உள்ளடக்கத்தைத் தாக்குதலாளர் அணுகியது உறுதிப்படுத்தப்படவில்லை.

வாடிக்கையாளர்களால் எதுவும் செய்ய முடியவில்லை. பிரச்சினை Panix-ன் இயந்திரங்களில் இல்லை; அவை சரியாக இயங்கின. அங்கீகரிக்கப்படாத ரெஜிஸ்ட்ரார் பரிமாற்றம், தாக்குதலாளர் கட்டுப்படுத்திய கணக்குக்கு டொமைனின் delegation மற்றும் DNS தரவை மாற்றும் திறனை அளித்து, web மற்றும் mail traffic-ஐ வெவ்வேறு அமைப்புகளுக்கு அனுப்பியது. panix.com எந்த முகவரியில் resolve ஆக வேண்டும் என்பதையே DNS வெளியிட்டது; அந்தப் பதிவின் சட்டப்பூர்வ உரிமையாளர் யார் என்று DNS தானாகக் கூறவில்லை.

அது எப்படி நடந்தது: அங்கீகாரமும் செயல்முறையும் தோல்வியடைந்தன

ஒரு மோசமான வார இறுதியைக் கடந்த landmark case ஆக Panix-ஐ மாற்றிய பகுதி இதுதான்: Panix-ன் சேவையகங்களுக்குள் யாரும் ஊடுருவவில்லை. பரிமாற்றத்தைக் கோரியவருக்கு அந்த டொமைனை மாற்ற அங்கீகாரம் இருந்ததா என்பதைப் பெறும் ரெஜிஸ்ட்ராரும் reseller-உம் நிறுவத் தவறினர்.

இந்தப் பரிமாற்றம் இடைத்தரகர்களின் ஒரு சங்கிலி வழியாக நடந்தது. Panix-ன் டொமைன் வாஷிங்டனின் Vancouver-ல் உள்ள Dotster ரெஜிஸ்ட்ராரிடம் பதிவு செய்யப்பட்டிருந்தது. மோசடிப் பரிமாற்றம் U.K.-ஐச் சேர்ந்த reseller நிறுவனமான Fibranet Services Ltd.-ன் கணக்கு வழியாகத் தொடங்கப்பட்டு, அது ஆஸ்திரேலியாவின் பெரிய ரெஜிஸ்ட்ராரான Melbourne IT-க்கு சமர்ப்பிக்கப்பட்டது. InfoWorld தெரிவித்தபடி, Melbourne IT Ltd. செய்த பிழை, திருடப்பட்ட கிரெடிட் கார்டுகளைப் பயன்படுத்திய மோசடிக்காரர்கள் Panix.com-ன் கட்டுப்பாட்டைப் பெற அனுமதித்தது — பரிமாற்றத்துக்குப் பயன்படுத்தப்பட்ட கணக்கு மோசடியானது; திருடப்பட்ட கிரெடிட் கார்டுகளைக் கொண்டு அமைக்கப்பட்டது.

ஐந்து நாட்களுக்குள் விடுவிக்கும் ரெஜிஸ்ட்ரார் கோரிக்கையை மறுக்காவிட்டால் தானாக அங்கீகரிக்கப்படும் விதி பரிமாற்றக் கொள்கையில் இருந்தது. ஆனால் அப்போது சமீபத்தில் மாற்றப்பட்ட Transfer Policy இந்தச் சம்பவத்தை ஏற்படுத்தவில்லை என்று ICANN-ன் முறையான ஆய்வு முடிவுசெய்தது: பழைய கொள்கையின்கீழும் புதிய கொள்கையின்கீழும் இதே துஷ்பிரயோகம் வெற்றி பெற்றிருக்கக்கூடும். பரிமாற்றத்தைத் தொடங்குவதற்கு முன் பதிவாளரின் வெளிப்படையான அங்கீகாரத்தை Melbourne IT மற்றும் Fibranet பெறாததே தீர்மானகரமான தோல்வி.

தோல்விகளை ஒன்றன்மீது ஒன்றாக அடுக்கினால் நிலைமை கடுமையாகத் தெரிகிறது. பெறும் ரெஜிஸ்ட்ரார் தனது reseller வழியாக மோசடிக் கோரிக்கையை ஏற்று, அங்கீகாரத்தைச் சரிபார்க்கத் தவறியது. விடுவிக்கும் ரெஜிஸ்ட்ராருக்கு registry அறிவிப்பு வந்தும் அது தலையிடவில்லை. எச்சரிக்கை எழுப்புவதற்கு உதவியிருக்கக்கூடிய அறிவிப்பை Panix பெறவில்லை. ஐந்து நாள் timer பரிமாற்றத்தை நிறைவுசெய்தது; ஆனால் கோரிக்கை செயல்முறைக்குள் நுழைவதற்கு முன் சரிபார்க்கப்பட்டிருக்க வேண்டிய அங்கீகாரத்துக்கு அது மாற்றாக இருக்கவில்லை.

மீட்பும், அது தூண்டிய கொள்கைச் சீர்திருத்தங்களும்

மனிதர்கள் தலையிட்ட பிறகு மீட்பு வேகமாக நடந்தது — அதுவே இந்தச் செயல்முறைக்கு எதிரான மற்றொரு குற்றச்சாட்டு; ஏனெனில் பரிமாற்றம் முதலில் அங்கீகரிக்கப்பட்டிருக்கவே கூடாது என்பதை அது நிரூபித்தது.

ஞாயிற்றுக்கிழமைக்குள், ஆஸ்திரேலிய domain hosting / registration நிறுவனமான Melbourne IT-யிடம் park செய்யப்பட்டிருந்த Panix.com டொமைனை Panix மீட்டது; அதை அதன் இயல்பான இருப்பிடமான Dotster-க்கு மீண்டும் சுட்டிக்காட்டியது. பதிவு மற்றும் .com delegation தரவை விரைவாகச் சரிசெய்ய முடிந்தது; ஆனால் உலகளாவிய சீராக்கம் உடனடியாக நடக்கவில்லை, ஏனெனில் ஒவ்வொரு resolver-உம் மீட்டெடுக்கப்பட்ட தரவைப் பார்க்கும் முன் cache செய்யப்பட்ட DNS பதில்கள் காலாவதியாக வேண்டியிருந்தது. அக்கால The Register செய்தி, புதுப்பிக்கப்பட்ட அமைப்புகளை "root servers" என்று குறிப்பிட்டது; ஆனால் panix.com என்பது second-level பெயர்: DNS root, .com-ஐ delegate செய்கிறது; .com-ன் authoritative layer தான் panix.com-க்கான delegation-ஐ வெளியிடுகிறது.

Melbourne IT தனது பங்கை மறைக்கவில்லை. இரண்டு நாட்களுக்குப் பிறகு The Register, கடந்த வார இறுதியில் நடந்த டொமைன் பெயர் கடத்தலில் தனது பங்கு இருந்ததை ஆஸ்திரேலிய டொமைன் ரெஜிஸ்ட்ரார் ஒருவர் ஒப்புக்கொண்டார் என்று தெரிவித்தது. பரிமாற்றச் செயல்முறையில் செய்யப்படாத ஒரு verification step-தான் தோல்விக்குக் காரணம் என்று கண்டறிந்த அது, இந்தப் பிழையை அனுமதித்த loophole மூடப்பட்டதாக உறுதியளித்தது.

பரிமாற்றப் பாதுகாப்பு குறித்த பரந்த விவாதத்தில் Panix ஒரு textbook எடுத்துக்காட்டானது. கோரிக்கையாளர்தான் உண்மையான பதிவாளர் என்பதை உறுதிப்படுத்தாமல் ரெஜிஸ்ட்ரார்கள் பரிமாற்றங்களை ஏற்றுக்கொள்வது போன்ற தோல்விகளை ஆய்வு செய்து, ICANN-ன் Security and Stability Advisory Committee 2005-ல் Domain Name Hijacking: Incidents, Threats, Risks, and Remedial Actions என்ற அறிக்கையை வெளியிட்டது. பல முக்கியக் கட்டுப்பாடுகள் இந்தச் சம்பவத்தால் புதிதாக உருவாக்கப்படாமல், ஏற்கெனவே இருந்தன அல்லது அப்போது நடைமுறைப்படுத்தப்பட்டுக் கொண்டிருந்தன:

• ரெஜிஸ்ட்ரார் பூட்டுகள். clientTransferProhibited நிலையில் உள்ள டொமைன், பூட்டு நீக்கப்படும் வரை ரெஜிஸ்ட்ரார்களுக்கு இடையிலான பரிமாற்றத்தை மறுக்கும். ரெஜிஸ்ட்ரார் பூட்டு முறைகள் Panix-க்கு முன்பே இருந்தன; பல ரெஜிஸ்ட்ரார்கள் அவற்றை ஏற்கெனவே default ஆகப் பயன்படுத்தினர். மதிப்புமிக்க பெயரைப் பரிமாற்றத்துக்கு திறந்துவைப்பதால் ஏற்படும் விலையை Panix எடுத்துக்காட்டியது.
• Auth codes (EPP transfer codes). மற்ற gTLD-களுக்கான EPP-யில் AuthInfo ஏற்கெனவே இருந்தது; தாக்குதலுக்கு முன்பே Verisign-ன் .com மற்றும் .net EPP deployment தயாராகிக் கொண்டிருந்தது. அதன் பரந்த பயன்பாடு, பரிமாற்றத்தைக் கோரியவர் ரெஜிஸ்ட்ரார் வழங்கிய ரகசியத்தை வைத்திருந்தார் என்பதற்கான சான்றை வலுப்படுத்தியது.
• Operational escalation மற்றும் verification. ரெஜிஸ்ட்ரார்களுக்கும் பதிவகங்களுக்கும் இடையே வெளிப்படையான அங்கீகாரம், நம்பகமான அறிவிப்புகள், அவசரகாலத் தொடர்புகள் மற்றும் விரைவான மீட்பு நடைமுறைகள் ஆகியவற்றை SSAC அறிக்கை வலியுறுத்தியது.

Panix கடத்தல் இந்த முறைகளை உருவாக்கவில்லை; பரிமாற்றக் கொள்கையையும் அது தனியாக மாற்றி எழுதவில்லை. ஏற்கெனவே கொள்கை எதிர்பார்த்த கட்டுப்பாடுகளை அமல்படுத்தி செயல்பாட்டில் பயன்படுத்த வேண்டியதற்கான தெளிவான எடுத்துக்காட்டாக அது மாறியது.

Transfer lock-களும் சரிபார்ப்பும் கற்பிக்கும் பாடங்கள்

தேதிகளையும் ரெஜிஸ்ட்ரார் பெயர்களையும் நீக்கிப் பார்த்தால், Panix சில நிலையான பாடங்களை விட்டுச் செல்கிறது.

1. ஒரு பரிமாற்றம் தொடங்குவதற்கு முன் வெளிப்படையான அங்கீகாரம் சரிபார்க்கப்பட வேண்டும். விடுவிக்கும் ரெஜிஸ்ட்ராருக்கான ஐந்து நாள் காலக்கெடு, பெறும் ரெஜிஸ்ட்ரார் அல்லது reseller அடையாளச் சரிபார்ப்பைத் தவிர்ப்பதற்கான அனுமதி அல்ல. புதிய கொள்கை அல்ல, அந்தத் தோல்விதான் Panix சம்பவத்தைச் சாத்தியமாக்கியது என்று ICANN முடிவுசெய்தது.
2. பரிமாற்றச் சங்கிலியின் ஒவ்வொரு தரப்புக்கும் பாதுகாப்புப் பங்கு உண்டு. பெறும் தரப்பு கோரிக்கையாளரை authenticate செய்ய வேண்டும்; விடுவிக்கும் ரெஜிஸ்ட்ரார் பதிவக அறிவிப்புகள் மீது நடவடிக்கை எடுக்க வேண்டும்; பதிவாளருக்கு அணுகக்கூடிய, கண்காணிக்கப்படும் தொடர்பு வழி தேவை. ஒரு தரப்பின் மௌனம் மற்றொரு தரப்பின் verification கடமையை நீக்கிவிடக் கூடாது.
3. Transfer lock-ஐப் பாதுகாப்பின் ஓர் அடுக்காகப் பயன்படுத்துங்கள். அந்த நிலை நீக்கப்படும் வரை சாதாரண ரெஜிஸ்ட்ரார்களுக்கு இடையிலான transfer request-களை clientTransferProhibited தடுக்க முடியும்; ஆனால் ரெஜிஸ்ட்ரார் பிழை, கணக்குக் கைப்பற்றல், கொள்கைச் செயல்முறைகள், நீதிமன்ற உத்தரவுகள் அல்லது அங்கீகரிக்கப்படாத lock removal ஆகியவற்றுக்கு எதிரான முழுமையான உத்தரவாதம் அது அல்ல. கிடைக்கும் வசதியும் விலையும் ரெஜிஸ்ட்ராரைப் பொறுத்தது. முக்கியப் பெயர்களுக்கு lock-ஐப் பயன்படுத்தி, வலுவான கணக்குப் பாதுகாப்பு, கண்காணிக்கப்படும் தொடர்புகள் மற்றும் escalation நடைமுறைகளுடன் அதை இணைக்கவும்.
4. டொமைன் கட்டுப்பாட்டை முக்கிய உட்கட்டமைப்பாகக் கருதுங்கள். Panix-ன் சேவையகங்கள் ஒருபோதும் compromise ஆகவில்லை; இருந்தும் பதிவு மற்றும் delegation மாற்றப்பட்டதால் web மற்றும் மின்னஞ்சல் சேவைகள் பாதிக்கப்பட்டன. Server security மட்டுமே அணுகலைப் பாதுகாக்கும் என்று கருதாமல், ரெஜிஸ்ட்ரார் அணுகல், பதிவகத்தை எதிர்கொள்ளும் workflows, DNS configuration, mail மற்றும் servers ஆகியவற்றைத் தனித்தனி அடுக்குகளாகப் பாதுகாக்கவும்.
5. அறிவிப்புகளைக் கண்காணியுங்கள்; ஆனால் அவற்றை மட்டுமே சார்ந்திருக்காதீர்கள். Panix-க்கு அறிவிப்பு வரவில்லை; Dotster-க்கு வந்தும் அது நடவடிக்கை எடுக்கவில்லை. கண்காணிக்கப்படும் தொடர்புகளையும் escalation பாதைகளையும் பராமரித்து, transfer locks மற்றும் வலுவான requester verification உடன் அவற்றை இணைக்கவும்.

Namefi கோணம்

Panix கடத்தல் அடிப்படையில் ஓர் அங்கீகாரத் தோல்வி. பதிவாளரின் வெளிப்படையான ஒப்புதலைப் பெறாமலேயே reseller-உம் பெறும் ரெஜிஸ்ட்ராரும் மோசடிக் கோரிக்கையை ஏற்றன; அறிவிப்பு வந்த பிறகும் விடுவிக்கும் ரெஜிஸ்ட்ரார் அதை நிறுத்தவில்லை.

ஆதரிக்கப்படும் டொமைன்களுக்கு Namefi, on-chain token-control மற்றும் transfer layer ஒன்றை வழங்குகிறது. அதனால் token custody மற்றும் token-transfer authorization-ஐ audit செய்ய முடியும்; ஆனால் token என்பது நிபந்தனையற்ற சட்டப்பூர்வ உரிமைப் பத்திரமோ ரெஜிஸ்ட்ரார் மற்றும் பதிவகப் பதிவுகளுக்கான மாற்றோ அல்ல. அடிப்படையான DNS டொமைனின் அங்கீகரிக்கப்படாத பரிமாற்றத்தை வழக்கமான ரெஜிஸ்ட்ரார் அல்லது பதிவகம் ஒன்று செயல்படுத்துவதை அது மட்டும் தடுக்காது. எனவே ரெஜிஸ்ட்ரார் பூட்டுகள், சரிபார்க்கப்பட்ட தொடர்புகள் மற்றும் அவசர மீட்பு நடைமுறைகள் தொடர்ந்து அவசியம்.

ஒரே தொழில்நுட்பம் transfer policy-ஐச் சரிசெய்கிறது என்ற கூற்றைவிட இந்தப் பாடம் குறுகியதும் வலிமையானதும் ஆகும்: அதிக மதிப்புள்ள டொமைன்களுக்கு, தனித்தனியாக audit செய்யக்கூடிய token state-உம் பெயரை நகர்த்தவோ வேறு முகவரிக்குத் திருப்பவோ முடியும் ஒவ்வொரு செயல்பாட்டு அடுக்கிலும் சரியாக அமல்படுத்தப்பட்ட கட்டுப்பாடுகளும் இரண்டும் பயன் தருகின்றன.

ஆதாரங்களும் மேலதிக வாசிப்பும்

• ICANN — Panix பரிமாற்றச் சம்பவத்தின் முறையான ஆய்வு
• The Register — டொமைன் கடத்தலிலிருந்து மீண்ட Panix
• The Register — Panix.com கடத்தல்: பொறுப்பை ஏற்ற ஆஸ்திரேலிய நிறுவனம்
• Davis Wright Tremaine — டொமைன் பெயர் கடத்தலுக்கு எதிரான பாதுகாப்பு
• InfoWorld — Panix டொமைன் கடத்தலுக்குப் பொறுப்பேற்ற ஆஸ்திரேலிய நிறுவனம்
• Slashdot — நியூயார்க்கின் மிகப் பழைய ISP-ன் டொமைன் கடத்தப்பட்டது
• Wikipedia — Panix (ISP)
• Wikipedia — டொமைன் கடத்தல்
• ICANN SSAC — Domain Name Hijacking: Incidents, Threats, Risks, and Remedial Actions (2005)
• ICANN — Transfer Policy
• NANOG mailing list archive — panix.com பரிமாற்றம் மற்றும் ICANN தீர்வுகள் குறித்த விவாதம்