மனிதர் இல்லாமல் AI முகவர்கள் டொமைன்களை எப்படி வாங்குகின்றன? (2026)

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

ஏப்ரல் 15, 2026 அன்று, அந்த வடிகட்டி எல்லா இடங்களிலும் கட்டாயம் என்ற நிலை முடிவுக்கு வந்தது. Cloudflare தனது Registrar API-ஐ பொது பீட்டாவாக அறிமுகப்படுத்தியது. அதைப் பற்றிய தொழில்துறைச் செய்தி சுருக்கமாகச் சொன்னதுபோல், Cloudflare "அந்தப் பரிவர்த்தனையை முகவர் அடுக்கிற்கு மாற்றியது" — அதாவது, படிவத்தை அழுத்தும் ஒரு மனிதருக்குப் பதிலாக மென்பொருள் கொள்முதலைத் தொடங்கும் கட்டமைப்பு அடுக்கு. விசைப்பலகையின் முன் ஒரு மனிதர் இருப்பார் என்ற ஊகத்தால் முழுத் தானியக்கத்தை எதிர்த்துவந்த பதிவு, DNS மற்றும் வேறு சில பணிகள், அந்த ஊகத்தை அமைதியாகக் கைவிட்டன.

இந்தக் கட்டுரை அந்த மாற்றத்தை மட்டும் விரிவாகப் பார்க்கிறது: தொழில்நுட்ப ரீதியாக என்ன மாறியது, உங்கள் சார்பாக ஒரு டொமைனைப் பதிவுசெய்யும்போது AI முகவர் உண்மையில் என்ன செய்கிறது, மேலும் — "மனிதர் தேவையில்லை" என்ற கூற்றைச் சந்தேகத்துடன் அணுகுவது நியாயமானதே என்பதால் — அது பாதுகாப்பாக இருக்க இன்னும் என்னென்ன நிபந்தனைகள் அவசியம். இன்று எந்தெந்த தளங்கள் இதை வழங்குகின்றன என்ற ஒப்பீட்டுக்கு AI முகவர் சார்ந்த டொமைன் தளங்கள்: 2026 வழிகாட்டி மற்றும் Cloudflare vs Name.com vs Namefi கட்டுரைகளைப் பாருங்கள். ஒரு ரெஜிஸ்ட்ராரை முகவர் பயன்படுத்தக்கூடியதாக மாற்றும் அடிப்படை அம்சங்களை அறிய, AI முகவர்களை மையமாகக் கொண்ட டொமைன் ரெஜிஸ்ட்ரார் என்றால் என்ன? என்பதைக் காணுங்கள்.

தொழில்நுட்ப ரீதியாக என்ன மாறியது?

டொமைன் துறை ஏப்ரல் 2026-இல் தனது விதிகளைப் புதிதாக எழுதவில்லை. ரெஜிஸ்ட்ரார்கள் பல தசாப்தங்களாக EPP உள்ளிட்ட நிரலாக்க API-களைக் கொண்டிருந்தன — அந்த API-களை யார் எளிதில் புரிந்துகொண்டு பயன்படுத்த முடியும் என்பதுதான் மாறியது.

பாரம்பரிய ரெஜிஸ்ட்ரார் செக்-அவுட், ஒருவர் பக்கத்தை வாசித்து, அட்டை விவரங்களை நிரப்பி, கொள்முதல் முடிவதற்கு முன் தாம் பாட் அல்ல என்பதை நிரூபிப்பார் என்ற மூன்று ஊகங்களின் மீது கட்டப்பட்டுள்ளது; அவை ஒவ்வொன்றும் ஒரு முகவருக்குத் தடையாகும். CAPTCHA மனிதர் அல்லாதவற்றைத் தடுப்பதற்காகவே உருவாக்கப்பட்டது. எனவே, அது தவறான பயன்பாட்டைத் தடுக்கும் அதே திறனுடன், ஒரு மனிதரின் அறிவுறுத்தலின்படி சட்டபூர்வமாகச் செயல்படும் முகவரையும் தடுக்கிறது. Cloudflare-ன் பீட்டாவை அடிப்படையாகக் கொண்டு உருவாக்கப்பட்ட மூன்றாம் தரப்பு MCP பயிற்சி, பழைய மாதிரியை நேரடியாக இப்படிச் சொன்னது: "டொமைன் ரெஜிஸ்ட்ரார்கள் மனிதர்களுக்காக உருவாக்கப்பட்டவை: CAPTCHA-கள், டாஷ்போர்டுகள், படிவங்கள், கிரெடிட் கார்டு புலங்கள். முகவர்களுக்கு ஏற்றவை என்று சொல்ல முடியாது."

அந்தப் பழைய மாதிரிக்குப் பதிலாக மூன்று அம்சங்கள் வந்தன. அவை ஒன்றுடன் ஒன்று போட்டியிடுவதில்லை; அடுக்குகளாக இணைந்து செயல்படுகின்றன:

• அங்கீகரிக்கப்பட்ட REST API-கள்: திரையில் காட்டப்படும் செக்-அவுட் பக்கத்திற்குப் பதிலாக ஒரு HTTP அழைப்பிலேயே கொள்முதலை முடிக்க உதவுகின்றன. Cloudflare-ன் பீட்டா தேடல், கிடைப்புநிலைச் சோதனை, பதிவு ஆகியவற்றை இவ்வாறு கையாள்கிறது. அறிமுகம் குறித்த செய்தியின்படி, சாதாரண டொமைன்களின் பதிவு "சில விநாடிகளுக்குள் ஒத்திசைவாக" முடிகிறது.
• MCP (Model Context Protocol): இதன் சொந்த ஆவணங்கள் விவரிப்பதுபோல், இது "AI பயன்பாடுகளை வெளிப்புற அமைப்புகளுடன் இணைப்பதற்கான ஒரு திறந்த மூலத் தரநிலை". தனிப்பயன் ஒருங்கிணைப்புக் குறியீடு வழங்கப்பட்ட முகவருக்கும், ரெஜிஸ்ட்ராரின் கருவிகளை (search, register, set_dns_record) தானாகக் கண்டறிந்து Claude, Cursor அல்லது வேறு இணக்கமான கிளையன்டிலிருந்து நேரடியாக அழைக்கக்கூடிய முகவருக்கும் இடையிலான வேறுபாடு இதுதான். Cloudflare தனது Registrar API-ஐ இந்த அடுக்குடன் இணைத்தது. அதன் சொந்த விளக்கத்தின்படி, "Cursor, Claude Code அல்லது MCP-க்கு இணக்கமான எந்தச் சூழலிலும் செயல்படும் முகவர், தனியான ஒருங்கிணைப்புப் படி இல்லாமலேயே Registrar முனைப்புள்ளிகளைக் கண்டறிந்து அழைக்க முடியும்."
• llms.txt மூலம் கண்டறிதல்: இது ஒரு எளிய உரைக் கோப்பு மரபு. "ஊகச் செயலாக்க நேரத்தில் ஒரு இணையதளத்தை LLM-கள் பயன்படுத்த உதவும் தகவலை வழங்க /llms.txt கோப்பைப் பயன்படுத்துவதைத் தரப்படுத்துவதற்கான முன்மொழிவு" என்று இது விவரிக்கப்படுகிறது. இதனால், ஒரு ரெஜிஸ்ட்ராரை முன்பு பார்த்திராத முகவர்கூட, மனிதர் API ஆவணங்களை உரையாடலில் ஒட்டாமலேயே அந்த ரெஜிஸ்ட்ரார் என்ன செய்ய முடியும் என்பதைக் கண்டறியலாம்.

இந்த மூன்று அம்சங்களில் எதுவும் தனித்தனியாகப் புதியது அல்ல; MCP 2024-இன் இறுதியில் வெளியானது, llms.txt அதே ஆண்டில் முன்மொழியப்பட்டது. ஒரு பிரதான ரெஜிஸ்ட்ரார் இந்த மூன்றையும் நேரடி கொள்முதல் செயல்முறையுடன் இணைத்ததுதான் புதியது — அதனால்தான் "AI முகவர்கள் டொமைன்களைப் பதிவுசெய்கின்றன" என்பது ஒரு பொழுதுபோக்கு முயற்சியாக இல்லாமல் செய்தித் தலைப்பாக மாறியது.

முகவர் உண்மையில் என்ன செய்கிறது?

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

1. தேடல். முகவர், தேவையான பெயர் அல்லது அதன் விவரிப்புடன் ரெஜிஸ்ட்ராரின் தேடல் முனைப்புள்ளியை — அல்லது அதற்கு இணையான MCP கருவியை — அழைத்து, கிடைக்கும் மற்றும் ஏற்கெனவே எடுக்கப்பட்ட பெயர் மாற்றுகளின் பட்டியலைப் பெறுகிறது.
2. கிடைப்புநிலையையும் விலையையும் சரிபார்த்தல். குறிப்பிட்ட பெயருக்கான தற்போதைய கிடைப்புநிலையையும் துல்லியமான விலையையும் முகவர் கேட்கிறது — பதிவுக் கட்டணம், ஏதேனும் பிரீமியம் கூடுதல் விலை, பொருந்தினால் ICANN பரிவர்த்தனைக் கட்டணம் ஆகியவை இதில் அடங்கும். தேர்ந்தெடுக்கப்பட்ட TLD பட்டியல் இங்கு முக்கியம்: Cloudflare உட்பட முகவர்களை மையமாகக் கொண்ட பல பீட்டா சேவைகள், அறிமுக நேரத்தில் முழுப் பட்டியலுக்குப் பதிலாகப் பிரபலமான TLD-களின் ஒரு பகுதியை மட்டுமே ஆதரிக்கின்றன.
3. அடையாளச் சரிபார்ப்பும் அதிகாரமளித்தலும். உள்நுழைவுப் பக்கத்தின் பின்னால் சேமிக்கப்பட்ட அட்டைக்குப் பதிலாக, ரெஜிஸ்ட்ரார் நிரலாக்க முறையில் சரிபார்க்கக்கூடிய சான்றுகளை முகவர் சமர்ப்பிக்கிறது — நிதியளிக்கப்பட்ட கணக்குடன் இணைக்கப்பட்ட API விசை அல்லது பணப்பைக் கையொப்பம் போன்றவை.
4. பதிவுசெய்தல். முகவர் பதிவு முனைப்புள்ளியை அழைக்கிறது. 2004-இல் முன்மொழியப்பட்ட தரநிலை என்ற நிலையை எட்டியதிலிருந்து ரெஜிஸ்ட்ரார்கள் பதிவக நிறுவனங்களுடன் தொடர்புகொள்ளப் பயன்படுத்திவரும் Extensible Provisioning Protocol ஆன EPP வழியாக, ரெஜிஸ்ட்ரார் கோரிக்கையை டொமைனின் பதிவக நிறுவனத்திற்கு அனுப்புகிறது. பதிவக நிறுவனம் பதிவை உருவாக்கியதும், பொதுவாகச் சில விநாடிகளுக்குள் API உறுதிப்படுத்தலைத் திருப்பி அனுப்புகிறது.
5. DNS-ஐ அமைத்தல். பெயர் பாதுகாப்பாகப் பதிவானதும், முகவர் பெயர் சேவையகங்களை அல்லது தனிப்பட்ட DNS பதிவுகளை அமைக்கிறது — சேவையகத்தைச் சுட்டும் A பதிவு, ஹோஸ்டிங் தளத்தைச் சுட்டும் CNAME பதிவு போன்றவை. பெரும்பாலும் பெயரைப் பதிவுசெய்த அதே உரையாடலின் அடுத்த அழைப்பாகவே இது நடக்கும்.
6. மனிதருக்கு உறுதிப்படுத்தல் அளித்தல். சிறப்பாக வடிவமைக்கப்பட்ட முகவர் செயல்முறையில், அட்டை அறிக்கையைப் பார்த்த பிறகே கொள்முதல் குறித்து மனிதர் அறிந்துகொள்ள மாட்டார். அதற்குப் பதிலாக, வாங்கிய பெயர், விலை, டொமைன் எதைச் சுட்டுமாறு அமைக்கப்பட்டது ஆகிய விவரங்களை முகவர் உடனே தெரிவிக்கும்.

ஆறாவது படி தோற்றத்தைவிட அதிகப் பொறுப்பை ஏற்கிறது — அடுத்த பகுதி அதைப் பற்றித்தான் பேசுகிறது.

பாதுகாப்பு வரம்புகள்: "மனிதர் தேவையில்லை" என்றாலும் மனிதர் அமைத்த கொள்கை தேவை

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

நடைமுறையில் மூன்று பாதுகாப்பு வரம்புகளே பெரும்பாலான ஆபத்தைக் கட்டுப்படுத்துகின்றன:

• வெறும் அட்டை எண்ணாக இல்லாத கட்டண அங்கீகாரம். முன்பணம் செலுத்திய அல்லது விலைப்பட்டியல் அடிப்படையிலான கணக்கு மீதிக்கெதிராகக் கட்டணம் வசூலிக்கப்படும் API விசை, மொத்த இழப்பு வாய்ப்புக்கு இயல்பாகவே உச்சவரம்பு வைக்கிறது — நிதியளிக்கப்பட்ட தொகையைவிட முகவரால் அதிகம் செலவிட முடியாது. பணப்பைக் கையொப்பமிட்ட பரிவர்த்தனை ஒவ்வொரு கொள்முதலுக்கும் தனித்தனியாக அங்கீகரிக்கப்படுகிறது; அதை மீண்டும் பயன்படுத்த முடியாது. இயல்பான உச்சவரம்பே இல்லாத சேமிக்கப்பட்ட கிரெடிட் கார்டுடன் ஒப்பிடும்போது, இவை இரண்டுமே முற்றிலும் வேறுபட்ட ஆபத்து வடிவத்தைக் கொண்டவை.
• செலவு வரம்புகளும் உறுதிப்படுத்தல் எல்லைகளும், முகவர் செயல்படத் தொடங்குவதற்கு முன்பே மனிதரால் அமைக்கப்பட வேண்டும். "சிறப்பாக வடிவமைக்கப்பட்ட முகவர் செயல்முறை" பதிவு முனைப்புள்ளியை அழைத்த பிறகு அல்ல, அதற்கு முன்பே டொமைன் பெயரையும் விலையையும் பயனரிடம் உறுதிப்படுத்த வேண்டும் என்பது Cloudflare-ன் வழிகாட்டல். API இதற்கு ஆதரவளிக்கிறது; ஆனால் கட்டாயப்படுத்துவதில்லை.
• சட்ட ஆபத்திற்குப் பொறுப்பானவர் யார் என்பதில் தெளிவு. ஒரு முகவர் பெயரைப் பதிவுசெய்வதால், அந்த டொமைனுக்குப் பதிவில் ஒரு பதிவாளர் இருக்க வேண்டும் என்ற சட்ட உண்மை மறைவதில்லை. முகவர் கட்டுப்பாட்டிலுள்ள டொமைன்கள் குறித்த ஒரு கருத்துக் கட்டுரை, ஆபத்தை நேரடியாக இப்படிச் சொல்கிறது: அதன் சான்றுகளைப் பயன்படுத்திப் பதிவுசெய்யப்படுவதை யாரும் கண்காணிக்கவில்லை என்றால், "ஒரு வர்த்தகமுத்திரையுடன் முரண்படும் டொமைனை முகவர் பதிவுசெய்தால், UDRP புகாருக்குப் பதிலளிக்க எந்த மனிதரும் இருக்கமாட்டார்." செக்-அவுட் பக்கத்தை நீக்குவது UDRP நடைமுறையையோ, புதுப்பித்தல் காலக்கெடுவையோ, WHOIS பதிவையோ நீக்குவதில்லை — அவற்றைக் கண்காணிக்கும் வசதியை யாரோ ஒருவர் திட்டமிட்டு உருவாக்க வேண்டும்.

சற்றுச் சிந்திக்க வேண்டிய விஷயம்: ஒரு டொமைனைப் பதிவுசெய்யக்கூடிய முகவரால், ஒவ்வொரு பரிவர்த்தனையையும் யாரும் மதிப்பாய்வு செய்யாமலேயே பணத்தைச் செலவிட்டு, பெயர்களின் தொகுப்பையும் உருவாக்க முடியும். இதே திறன்தான் அதை பயனுள்ளதாகவும் மாற்றுகிறது; கொள்கை அடுக்கு விருப்பத்தேர்வு அல்ல என்பதற்கான காரணமும் இதுதான்.

இன்று இதை வழங்குபவர்கள் யார்? மறுவிற்பனையாளர் கோட்பாடு என்ன?

Cloudflare-ன் பீட்டா இந்த மாற்றத்தில் மிக அதிகம் பேசப்பட்ட எடுத்துக்காட்டு; ஆனால் அது மட்டுமே அல்ல. 2025-இன் நடுப்பகுதியிலிருந்து, அதே MCP மற்றும் OpenAPI அணுகுமுறையை மையமாகக் கொண்டு Name.com ஒத்த API ஒன்றை உருவாக்கியது. Namefi, MCP சேவையகத்துடன் கணக்கு உருவாக்குவதையே தவிர்க்கும் பணப்பைக் கையொப்பமிட்ட செக்-அவுட்டையும் இயக்குகிறது. விலை மாதிரி, TLD ஆதரவு, கட்டணத்திற்கு ஏற்கெனவே கணக்கு தேவையா போன்ற ஒவ்வொரு அம்சத்தின் வேறுபாடுகளையும் Cloudflare vs Name.com vs Namefi: முகவர்களை மையமாகக் கொண்ட ரெஜிஸ்ட்ரார்கள் கட்டுரை விளக்குகிறது. பெரிய நுகர்வோர் ரெஜிஸ்ட்ரார்கள் இந்த வகையின் எந்த இடத்தில் நின்றுவிடுகின்றன என்பதையும் உள்ளடக்கிய முழுச் சந்தை விவரங்களுக்கு AI முகவர் சார்ந்த டொமைன் தளங்கள்: 2026 வழிகாட்டி கட்டுரையைப் பாருங்கள்.

எந்த ஒரு தனித் தளத்தையும்விடப் புதியது, இந்தத் திறனைப் பெற்ற பிறகு முகவர்கள் அதை எதற்குப் பயன்படுத்தத் தொடங்கியுள்ளன என்பதே. 2026-இன் நடுப்பகுதியில் CircleID நடத்திய டொமைன் துறை ஆய்வு இதை இவ்வாறு கூறியது: "AI முகவர்கள், மனிதத் தலையீடு இல்லாமல் கிடைப்புநிலையைச் சரிபார்த்து, பெயர்களைப் பதிவுசெய்து, DNS-ஐ அமைக்கும் டொமைன் மறுவிற்பனையாளர்களாக அதிகரித்த அளவில் செயல்படுகின்றன." "மறுவிற்பனையாளர்" என்பது திட்டமிட்ட சொல் தேர்வு. தனக்கென அங்கீகாரம் வைத்திராமல், ஒரு ரெஜிஸ்ட்ராரின் அங்கீகாரத்தின் கீழ் டொமைன்களை விற்கும் அல்லது ஒதுக்கும் தரப்பைக் குறிக்கும் ஏற்கெனவே நிலைபெற்ற பங்கு அது. முகவர்களைப் புதிய வகையாக அல்லாமல் அதிகாரப்பூர்வமற்ற மறுவிற்பனையாளர்களாகக் குறிப்பிடுவது, இயக்குபவர் மனிதர் இல்லை என்றாலும் செயல்முறை பழக்கமானதே என்பதைக் காட்டுகிறது: வேறொருவரின் சார்பாக, பெருமளவில் தேடுதல், விலையிடுதல், பதிவுசெய்தல், அமைத்தல். அந்தப் போக்கு உண்மையில் எவ்வளவு தூரம் சென்றுள்ளது, எவ்வளவு இன்னும் அறிவிப்பு நிலையிலேயே உள்ளது என்பதை முகவர் சார்ந்த டொமைன் மேலாண்மையின் நிலை, 2026 கட்டுரையில் தொடர்ந்து கண்காணிக்கிறோம். மறுவிற்பனையாளர் பாணியில் செயல்படும் முகவர் அழைக்கக்கூடிய கருவிக்கான ஒரு நேரடி எடுத்துக்காட்டு Namefi-ன் சொந்த MCP சேவையகம்.

அடிக்கடி கேட்கப்படும் கேள்விகள்

ஏப்ரல் 15, 2026 அன்று துல்லியமாக என்ன மாறியது?

டொமைன் தேடல், கிடைப்புநிலை மற்றும் விலைச் சோதனைகள், பதிவு ஆகியவற்றை உள்ளடக்கிய Registrar API-ஐ Cloudflare பொது பீட்டாவாக அறிமுகப்படுத்தி, Cursor மற்றும் Claude Code போன்ற கருவிகளில் முகவர்கள் ஏற்கெனவே பயன்படுத்திவந்த Cloudflare MCP சேவையகத்துடன் இணைத்தது. முகவர் அழைக்கக்கூடிய முதல் ரெஜிஸ்ட்ரார் API இது அல்ல — Name.com-ன் API 2025-இன் நடுப்பகுதியில் அறிமுகமானது; Namefi-ன் API ஏற்கெனவே இயங்கிக்கொண்டிருந்தது. இருப்பினும், பரிச்சயமான ஒரு பெரிய ரெஜிஸ்ட்ரார், உலாவி செக்-அவுட் வழியாக மட்டுமல்லாமல் முகவர் மூலமாகவே முழுக் கொள்முதலையும் முடிக்கச் செய்த எடுத்துக்காட்டுகளில் இதுதான் மிகப் பரவலாகப் பேசப்பட்டது.

AI முகவர் பதிவுசெய்யும் ஒவ்வொரு டொமைனுக்கும் என் அனுமதி தேவையா?

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

ஒவ்வொரு பரிவர்த்தனையையும் கண்காணிக்காமல் AI முகவர் டொமைன்களை வாங்க அனுமதிப்பது உண்மையிலேயே பாதுகாப்பானதா?

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

AI முகவர் ஒரு டொமைனைப் பதிவுசெய்தால் அதற்குச் சட்டபூர்வமாகப் பொறுப்பானவர் யார்?

அந்த டொமைனுக்குப் பதிவில் இன்னும் ஒரு பதிவாளர் இருக்கிறார் — AI மாதிரி அல்ல, ஒரு நபர் அல்லது அமைப்பு. வர்த்தகமுத்திரைத் தகராறு, UDRP புகார் அல்லது புதுப்பித்தல் காலக்கெடு போன்றவற்றை எதிர்கொள்ள வேண்டியவர் அந்தப் பதிவாளரே. கொள்முதல் படியிலிருந்து மனிதரை நீக்குவது, உரிமைப் பதிவிலிருந்து அவரை நீக்குவதில்லை; கண்காணிப்பை நீங்கள் அமைக்காவிட்டால், அந்த ஆபத்துகளை யாரும் கவனிக்காமல் போகலாம் என்பதே அதன் பொருள்.

AI முகவர்கள் அதிகாரப்பூர்வமாக அங்கீகரிக்கப்பட்ட டொமைன் மறுவிற்பனையாளர்களாக மாறுகின்றனவா?

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

இது எந்த TLD-க்கும் செயல்படுமா, அல்லது பிரபலமானவற்றுக்கு மட்டுமா?

அது தளத்தைப் பொறுத்தது — முழுமையான ஆதரவு உள்ளது என்று ஊகிப்பதற்குப் பதிலாக நேரடியாகச் சரிபார்ப்பது நல்லது. Cloudflare-ன் பீட்டா, அதன் சொந்த ஆவணங்கள் குறிப்பிடும் பிரபலமான TLD-களின் தேர்ந்தெடுக்கப்பட்ட தொகுப்புடன் தொடங்கியது; முழுப் பட்டியலுடன் அல்ல. பீட்டா முதிர்ச்சியடையும்போது ஆதரவு பொதுவாக விரிவடையும். எனவே, குறிப்பிட்ட நீட்சியைச் சார்ந்து செயல்படுவதற்கு முன், அந்தத் தளத்தின் தற்போதைய ஆவணங்களில் TLD ஆதரவைச் சரிபாருங்கள்.

செக்-அவுட் பக்கம் இல்லாமல், உங்கள் சொந்த முகவரைக் கொண்டு அடுத்த டொமைனைப் பதிவுசெய்யுங்கள்

இந்தக் கட்டுரை விவரிக்கும் அதே வகையான முகவர்களை மையமாகக் கொண்ட கொள்முதல் வழியை Namefi இயக்குகிறது: உங்கள் முகவர் நேரடியாக இணையும் MCP சேவையகம், ஆவணப்படுத்தப்பட்ட REST API, கணக்கு உருவாக்குவதை முழுமையாகத் தவிர்க்கும் பணப்பைக் கையொப்பமிட்ட செக்-அவுட் — மேலும் டொமைனே உங்கள் முகவரின் பணப்பை வைத்திருக்கக்கூடிய சொத்தாக இருக்க வேண்டுமெனில் டோக்கனைஸ் செய்யப்பட்ட உரிமையும் கிடைக்கும். உங்கள் செலவுக் கொள்கையை ஒருமுறை அமைத்துவிட்டு, இந்தக் கட்டுரையில் விவரிக்கப்பட்டபடி தேடல், விலைச் சோதனை, பதிவு ஆகியவற்றை முகவர் கையாள அனுமதியுங்கள்.

Namefi-இல் ஒரு டொமைனைத் தேடிப் பதிவுசெய்யுங்கள்.

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

• Cloudflare வலைப்பதிவு — Registrar API பீட்டா அறிவிப்பு (அறிமுகத் தேதி, ஆதரிக்கப்படும் செயல்பாடுகள், அடக்க விலையிடல், MCP ஒருங்கிணைப்பு, மனித ஒப்புதல் குறித்த வழிகாட்டல்)
• webhosting.today — AI முகவர்கள் இப்போது டொமைன்களைப் பதிவுசெய்யலாம்; மனிதர் தேவையில்லை (Cloudflare பீட்டாவை "முகவர் அடுக்கு" மாற்றமாக விவரிக்கும் தொழில்துறைப் பார்வை, ஏப்ரல் 2026)
• dev.to — மனிதர் இல்லாமல் உங்கள் AI முகவரைக் கொண்டு டொமைன் பெயரைப் பதிவுசெய்வது எப்படி? (பழைய செக்-அவுட் பக்க மாதிரியையும் முகவர் அழைக்கக்கூடிய பதிவையும் ஒப்பிடும் மூன்றாம் தரப்பு MCP பயிற்சி)
• dev.to — AI முகவர்கள் தங்களுடைய சொந்த டொமைன் பெயர்களை எப்படி வாங்கலாம், இது ஏன் முக்கியம்? (முகவர் கட்டுப்பாட்டிலுள்ள டொமைன்களையும் சட்ட ஆபத்திலுள்ள இடைவெளியையும் பற்றிய கருத்துக் கட்டுரை)
• CircleID — 2026-இன் டொமைன் உலகம்: AI, பாதுகாப்பு, சந்தை முதிர்ச்சி மற்றும் புதிய gTLD எல்லை (முகவர்களை மறுவிற்பனையாளர்களாகப் பார்க்கும் ஆய்வு, ஏப்ரல் 2026)
• modelcontextprotocol.io — Model Context Protocol (MCP) என்றால் என்ன? (நெறிமுறை மேலோட்டம்)
• llmstxt.org — /llms.txt கோப்பு முன்மொழிவு (விவரக்குறிப்பும் காரண விளக்கமும்)
• Wikipedia — Extensible Provisioning Protocol (முன்மொழியப்பட்ட தரநிலை, மார்ச் 2004)
• Namefi — namefi.io/llms.txt (Namefi-ன் சொந்த MCP சேவையகம், REST API மற்றும் பணப்பை செக்-அவுட் குறிப்பு)