აირჩიე ერთი: example.com ან www.example.com, საიტი იმ ერთზე გაუშვი და მეორეზე ყველა მოთხოვნას მუდმივი გადამისამართებით უპასუხე. რომელს აირჩევ, ბევრად ნაკლებ მნიშვნელობას აქვს, ვიდრე იმას, რომ საერთოდ აირჩიო. საიტი, რომელიც ორივეზე გადამისამართების გარეშე პასუხობს, ქეშების, cookie-ების, ანალიტიკისა და საძიებო სისტემების თვალში ორი საიტია, და დღე, როცა ეს აშკარა ხდება, ჩვეულებრივ ის დღეა, როცა ვინმე ერთ ჰოსტზე შედის და მეორეზე გამოსულია.
ერთი ნამდვილი ტექნიკური განსხვავება არსებობს და ის გემოვნების საკითხი არ არის: www.example.com ჩვეულებრივი ქვედომენია და შეიძლება CNAME იყოს, ხოლო example.com ზონის apex-ია და არ შეიძლება. ყველაფერი დანარჩენი კამათში - რომელი ლამაზია, რომელი უფრო მოკლეა, რომელი უფრო "თანამედროვეა" - გემოვნებაა. ეს პოსტი განიხილავს შეზღუდვას, არჩევანს, ჩანაწერებს, გადამისამართებას, სერტიფიკატს და ოთხ გზას, რომლითაც გადამისამართება ფუჭდება.
რას ნიშნავს სინამდვილეში apex და www#
Apex, რომელსაც root-საც უწოდებენ, ან ტიტველ დომენს, ან ზონის apex-ს, არის სახელი, რომელიც დაარეგისტრირე, წინ არაფრით: example.com. ის განსაკუთრებულია, რადგან ზონის საკუთარი ადმინისტრაციული ჩანაწერები სწორედ იქ ცხოვრობს - SOA ჩანაწერი, რომელიც ამბობს, რომელი nameserver-ია ავტორიტეტული და როგორ ძველდება ზონა, და NS ჩანაწერები, რომლებიც nameserver-ებს ჩამოთვლის. ისინი ყოველთვის არსებობს და ისინი არიან ქვემოთ მოცემული შეზღუდვის წყარო.
www ქვედომენია, ყველა დანარჩენის მსგავსად. ის არანაირ განსაკუთრებულ სტატუსს არ ფლობს არც DNS-ში, არც HTTP-ში და არც რომელიმე ბრაუზერში. ეს კონვენციაა იმ ეპოქიდან, როცა ერთი ორგანიზაციის მანქანები იყო www, ftp, mail და news, და ის გადარჩა, რადგან სასარგებლო აღმოჩნდა: სახელი, რომელსაც წინ ლეიბლი უდგას, შეიძლება ნებისმიერ რამეზე მიუთითებდეს, სხვისი კუთვნილი სახელის ჩათვლით.
ბრაუზერები განსხვავებას მალავენ. Chrome, Safari და Edge ყველა მისამართის ზოლში www.-სა და https://-ს აჩრდილავენ, ამიტომ ვიზიტორების უმეტესობა არასოდეს ხედავს, რომელზეა. ეს არგუმენტია ესთეტიკაზე ტანჯვის წინააღმდეგ და არგუმენტი იმის სასარგებლოდ, რომ ორივე იმუშაოს - ხალხი მაინც იმას კრეფს, რაც ახსოვს.
რატომ არ შეიძლება CNAME apex-ზე#
CNAME ჩანაწერი ამბობს "ეს სახელი სხვა სახელის alias-ია, წადი და იქ მოძებნე". DNS სპეციფიკაცია მკაცრია: თუ სახელს CNAME აქვს, მას სხვა ტიპის არცერთი ჩანაწერი არ შეიძლება ჰქონდეს. ეს წესი არსებობს, რადგან resolver, რომელიც CNAME-ს პოულობს, ამ სახელის ძებნას მთლიანად წყვეტს და სამიზნიდან თავიდან იწყებს.
Apex-ს ყოველთვის აქვს SOA და NS ჩანაწერები. ამიტომ apex-ს CNAME არასოდეს შეიძლება ჰქონდეს. ავტორიტეტული სერვერები, რომლებიც მაინც იღებენ, ქმნიან ზონას, რომელიც ძნელად დიაგნოსტირებადი გზებით ფუჭდება: ფოსტა აღარ მიდის, რადგან MX ჩანაწერი alias-ის უკან უხილავია, ან თავად დელეგაცია ქრება.
ეს მნიშვნელოვანია, რადგან ბევრი ინფრასტრუქტურა მხოლოდ hostname-ს გაძლევს და არა მისამართს. Load balancer-ი, object-storage-ის ვებსაიტის endpoint-ი, platform-as-a-service და CDN-ების უმეტესობა გაძლევს რაღაცას d1a2b3c4.cloudfront.net-ის მსგავსს და ინარჩუნებს უფლებას, მის უკან მისამართები როცა უნდა, შეცვალოს. ქვედომენს შეუძლია ამაზე CNAME-ით მიუთითოს. apex-ს არ შეუძლია, ამიტომ მოვაჭრეებმა სამი შემოვლითი გზა გამოიგონეს:
- CNAME flattening - DNS პროვაიდერი apex-ზე ინახავს რაღაცას, რაც
CNAME-ს ჰგავს, თავად წყვეტს მას და მოთხოვნებს პასუხობს მიღებულიAდაAAAAჩანაწერებით. ამას Cloudflare აკეთებს. - ALIAS ან ANAME ჩანაწერები - იგივე იდეა სხვა სახელით, რომელსაც რამდენიმე მართული DNS პროვაიდერი გთავაზობს. იგივე ქცევა: alias შედის, მისამართები გამოდის.
- პროვაიდერის საკუთარი alias ჩანაწერები - Route 53-ის alias ჩანაწერის ტიპი, რომელიც პროვაიდერის საკუთარ რესურსებზე მიუთითებს და შიგნით წყდება.
სამივე შენი DNS ჰოსტის თვისებაა და არა DNS-ის. თუ ზონას პროვაიდერზე გადაიტან, რომელსაც ასეთი არ აქვს, apex, რომელიც მასზე იყო დამოკიდებული, გაფუჭდება. ეს ყველაზე ძლიერი პრაქტიკული არგუმენტია იმის სასარგებლოდ, რომ www კანონიკური ჰოსტი გახდეს: ის apex-ს ტოვებს მარტივ გადამისამართებად, რომლის მოწოდებაც სადმე შეიძლება, ხოლო ნამდვილ სახელს ათავისუფლებს, რომ CNAME იყოს.
თუ შენი საიტი ფიქსირებულ მისამართზე მუშაობს - სერვერი, VDS, პანელზე მდგარი container - არაფერი აქედან არ ეხება შენ. apex-ზე წერ A ჩანაწერს მისამართით და მორჩი. DNS ჩანაწერები ახსნილი თავად ჩანაწერის ტიპებს განიხილავს, ხოლო nameserver-ები თუ DNS ჩანაწერები - ვინ ინახავს ზონას საერთოდ.
კანონიკური ჰოსტის არჩევა#
არცერთი არჩევანი შენს საძიებო რეიტინგზე არ იმოქმედებს. Google იმდენჯერ თქვა, რამდენჯერაც რამეს ამბობს, რომ ორივე ეკვივალენტურია, სანამ ერთ-ერთი თანმიმდევრულად კანონიკურია. ნამდვილი განსხვავებები ესაა.
| კითხვა | Apex (example.com) | www.example.com |
|---|---|---|
| შეიძლება იყოს CNAME | არა | დიახ |
| Cookie-ს არეალი | იგზავნება ყველა ქვედომენზე, რომელიც იზიარებს | შემოიფარგლება www-ით |
| უფრო მოკლედ იკითხება | დიახ | არა |
| მოგვიანებით CDN-ზე გადასვლა | სჭირდება flattening ან მისამართი | შეცვალე ერთი ჩანაწერი |
Cookie-ს საკითხია ის, რომელიც მოგვიანებით გკბენს. cookie, რომელიც example.com-ზეა დაყენებული Domain ატრიბუტით, იგზავნება api.example.com-ზე, blog.example.com-ზე და ყველა სხვა ქვედომენზე, მათ შორის იმათზეც, რომლებსაც მესამე მხარეს გადასცემ. თუ ოდესმე ქვედომენზე ისეთ რამეს მასპინძლობ, რასაც სრულად არ აკონტროლებ, apex-ის session cookie იქაც მიდის. საიტის www-ზე გაშვება და apex-ის გადამისამართებად დატოვება ამ ზიანის რადიუსს მცირეს ინახავს.
მეორე მხარეს: apex უფრო მოკლეა, ის არის, რასაც ვიზიტის ბარათზე წერენ, და თუ შენი საიტი ყოველთვის ფიქსირებულ მისამართზე იცხოვრებს, CNAME-ის შეზღუდვა არასოდეს წამოიჭრება. პატარა მაღაზიისთვის, ბლოგისთვის ან ერთ სერვერზე მდგარი აპლიკაციისთვის apex სრულიად კარგი არჩევანია.
აირჩიე, ჩაიწერე და მერე კაპრიზით აღარ შეცვალო. კანონიკური ჰოსტის შეცვლა გაშვების შემდეგ ნიშნავს გადამისამართებას, რომელიც უსასრულოდ რჩება, ბმულებს გარეთ, რომლებიც ძველ ჰოსტზე მიუთითებს, და საძიებო ინდექსს, რომელსაც დასწევა კვირები სჭირდება.
ჩანაწერები, ორივე გზით#
ვთქვათ, შენი სერვერის მისამართია 203.0.113.10. ორივე ჰოსტი უნდა გადაწყდეს, სანამ სხვა რამე იმუშავებს, სერტიფიკატის ჩათვლით. არ არსებობს განლაგება, სადაც არაკანონიკური ჰოსტი გადაუწყვეტელი რჩება.
example.com. 300 IN A 203.0.113.10www.example.com. 300 IN CNAME example.com.example.com. 300 IN A 203.0.113.10www.example.com. 300 IN A 203.0.113.10ორივე ვარგისია. მეორეში www-ს შეგიძლია CNAME გახადო პლატფორმის hostname-ზე და apex დატოვო პატარა სერვერზე, რომლის ერთადერთი საქმე გადამისამართებაა - ეს განლაგებაა, რომელსაც დიდი საიტები საბოლოოდ მიიღებენ.
TTL ღირს, რომ გადაადგილებამდე გაითვალო და არა შემდეგ. 300 TTL ნიშნავს, რომ resolver პასუხს ხუთ წუთში ივიწყებს; 86400 - დღეში. დააყენე დაბალი ცვლილებამდე ერთი-ორი დღით ადრე და გაზარდე, როცა ახალი მისამართი დამტკიცდება. ეს იგივე დისციპლინაა, რომელიც აღწერილია WordPress-ის ახალ ჰოსტზე გადატანაში, და ეს არის განსხვავება გადართვას შორის, რომელიც წუთებში იზომება, და გადართვას შორის, რომელიც იზომება "ზოგიერთი მაინც ძველ საიტს ხედავს".
გადამისამართება ერთ ნახტომში, სწორი სტატუს კოდით#
გადამისამართება ვებ სერვერში ან reverse proxy-შია, აპლიკაციის წინ. გამოიყენე 301 Moved Permanently. ბრაუზერები და საძიებო სისტემები მას აქეშებენ, რაც სწორედ ისაა, რაც გინდა ჰოსტისთვის, რომელიც არასოდეს დაბრუნდება.
server { listen 443 ssl; server_name www.example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; return 301 https://example.com$request_uri;}$request_uri ატარებს გზასა და query string-ს, ამიტომ https://www.example.com/shop?page=2 ეშვება https://example.com/shop?page=2-ზე და არა მთავარ გვერდზე. გადამისამართება, რომელიც გზას ტოვებს, უარესია, ვიდრე გადამისამართების არქონა: ყველა deep link ინტერნეტის ყველა სხვა საიტიდან შენი წინა კარიბჭეზე მიდის და არა გვერდზე, რომელიც დაპირებული იყო.
Apache-ზე იგივე .htaccess-შია, რაც უმეტეს გაზიარებულ PHP ჰოსტინგზე გაქვს:
RewriteEngine OnRewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]ორი დეტალი განასხვავებს სწორ გადამისამართებას ნელისგან:
- ერთი ნახტომი და არა სამი.
http://wwwპირდაპირhttps://example.com/path-ზე უნდა წავიდეს და არაhttps://www-ზე, შემდეგ კიhttps://example.com-ზე. ყოველი დამატებითი ნახტომი სრული round trip-ია, TLS handshake-ის ჩათვლით იმათზე, რომლებიც უკვე დაშიფრულია. დაწერე წესები ისე, რომ პირველი პასუხი საბოლოო URL-ს ატარებდეს. - გადაამისამართე აპლიკაციის გაშვებამდე. PHP ან Node აპლიკაცია, რომელიც გადამისამართებას წყვეტს, უკვე გადაიხადა მონაცემთა ბაზის კავშირისა და session-ის ძიების ფასი. Proxy-ს ან ვებ სერვერს მიკროწამებში შეუძლია პასუხი.
თუ ამის გაკეთება მხოლოდ აპლიკაციას შეუძლია - მაგალითად, WordPress გადამისამართებს იმაზე, რაც მის siteurl და home პარამეტრებშია - დააყენე ისინი კანონიკურ ჰოსტზე და დაუშვი. უბრალოდ ნუ გექნება ერთდროულად სერვერიც და აპლიკაციაც გადამისამართებული, რადგან ციკლები ასე იწყება.
308 Permanent Redirect არსებობს და ტექნიკურად უფრო მკაცრია: ის მეთოდის შეცვლას კრძალავს, მაშინ როცა 301 ისტორიულად უშვებდა POST-ის GET-ად გადაქცევას. კანონიკური ჰოსტის გადამისამართებისთვის ჩვეულებრივ ვებსაიტზე 301 უსაფრთხო და მოსალოდნელი არჩევანია. 302 გამოიყენე მხოლოდ ტესტირებისას, რადგან არასწორად გაკეთებული 301 ბრაუზერებში ქეშირდება, რომლებსაც ვერ წვდები.
სერტიფიკატმა ორივე სახელი უნდა დაფაროს#
გადამისამართება https://www.example.com-დან მხოლოდ მას შემდეგ შეიძლება მოხდეს, რაც ბრაუზერმა TLS handshake დაასრულა რამესთან, რომელსაც www.example.com-ისთვის ვალიდური სერტიფიკატი აქვს. თუ სერტიფიკატი მხოლოდ apex-ს ფარავს, ვიზიტორი სრულ გვერდზე უსაფრთხოების გაფრთხილებას იღებს და შენს გადამისამართებამდე არასოდეს აღწევს. ეს ინტერნეტში ყველაზე გავრცელებული ნახევრად დასრულებული კონფიგურაციაა: apex მუშაობს, www სერტიფიკატის შეცდომას ისვრის და მფლობელმა არაფერი იცის, რადგან მას არასოდეს კრეფს.
ასე რომ, თანმიმდევრობაა: ორივე სახელი შენს სერვერზე გადაიწყვეტა, შემდეგ სერტიფიკატი ორივესთვის გაიცემა, შემდეგ კი გადამისამართება შედის.
Let's Encrypt http-01 გამოწვევის ვალიდაციისას გადამისამართებებს მიჰყვება, ამიტომ www-დან apex-ზე გადამისამართება ჩვეულებრივ გაცემას არ აბლოკავს. რაც აბლოკავს, სახელია, რომელიც სადღაც სხვაგან წყდება - ძველ ჰოსტზე დარჩენილი ჩანაწერი ან www, რომელიც არასოდეს შექმნილა. HTTPS და Let's Encrypt ახსნილი თავად ვალიდაციას განიხილავს.
RE:NODE-ზე app და web გეგმები მოიცავს reverse-proxy სლოტს: A ჩანაწერს მიუთითებ მასში ნაჩვენებ მისამართზე და სერტიფიკატი გაიცემა და ავტომატურად განახლდება 21-დღიან ფანჯარაში. დაამატე იქ ორივე სახელი და არა მხოლოდ ის, რომელსაც იყენებ. ჩვენ დომენებს არ ვარეგისტრირებთ და DNS ზონებს არ ვმასპინძლობთ, ამიტომ თავად ჩანაწერები იქმნება იქ, სადაც შენი ზონა ცხოვრობს - შენს რეგისტრატორთან ან იმ DNS პროვაიდერთან, რომელზეც შენი nameserver-ები მიუთითებს. დომენის მიბმა შენს სერვერზე შეიცავს ნაბიჯ-ნაბიჯ ინსტრუქციას.
დანარჩენის მითითება, რომელი ჰოსტია ნამდვილი#
გადამისამართება ვიზიტორებს ამუშავებს. რამდენიმე სხვა რამეს ცალკე უნდა უთხრა, და მათი გამოტოვებაა გზა იქამდე, რომ საძიებო ინდექსში ყოველი გვერდის ორი ვერსია გაქვს.
- Canonical link ელემენტები. ყოველ გვერდს უნდა ჰქონდეს საკუთარი კანონიკური URL არჩეულ ჰოსტზე. კონტენტის სისტემების უმეტესობა ამას ერთი site-URL პარამეტრიდან აგენერირებს, ამიტომ ამ პარამეტრის შესწორება ყველა გვერდს ასწორებს.
- Sitemap.
sitemap.xml-ში აბსოლუტური URL-ები კანონიკურ ჰოსტს უნდა იყენებდეს. Sitemap, რომელიც მეორეს ჩამოთვლის, პირდაპირი მითითებაა, რომ გადამისამართება დაასკანირონ. - შიდა ბმულები. ამჯობინე root-relative ბმულები (
/about), რომ არასწორ ჰოსტზე ვერ მიუთითებდნენ.http://www.-ზე მიბმული აბსოლუტური ბმულები ჩვეულებრივი წყაროა გადამისამართებისა ყოველ კლიკზე. - Search Console და ანალიტიკა. დაარეგისტრირე ორივე ჰოსტი, ან გამოიყენე domain property, რომელიც მთელ ზონას ფარავს, რომ ტრაფიკი დაინახო, რომელიც ჯერ კიდევ ძველზე მიდის.
- Open Graph და სტრუქტურირებული მონაცემები. სურათისა და გვერდის URL-ები მეტამონაცემებში აბსოლუტურია აუცილებლობით. თუ ისინი არაკანონიკურ ჰოსტზე მიუთითებს, ყოველი გაზიარება გადამისამართებით იტვირთება.
გადამისამართების ციკლები და დანარჩენი გზები, რომლებითაც ეს ფუჭდება#
Proxy ციკლი. შენი reverse proxy TLS-ს წყვეტს და აპლიკაციას უბრალო HTTP-ს გადასცემს. აპლიკაცია ხედავს http://-ს, წყვეტს, რომ ვიზიტორი უნდა განახლდეს, და გადამისამართებას https://-ზე გასცემს. Proxy ამასაც წყვეტს, უბრალო HTTP-ს ისევ გადასცემს და ბრაუზერი ოცი ნახტომის შემდეგ ERR_TOO_MANY_REDIRECTS-ით ნებდება. გამოსავალი ისაა, რომ აპლიკაციამ საკუთარი socket-ის ყურების ნაცვლად proxy-ის X-Forwarded-Proto header-ს ენდოს - WordPress-ში ეს ნიშნავს $_SERVER['HTTPS']-ის დაყენებას header-იდან wp-config.php-ში, Express-ში ეს app.set('trust proxy', 1)-ია, Laravel-ში კი trusted-proxies middleware. რას აკეთებს reverse proxy header-ს განმარტავს.
ორი წესთა ნაკრების ციკლი. ვებ სერვერი www-ს apex-ზე გადამისამართებს, ხოლო აპლიკაცია, რომელიც ჯერ კიდევ ძველი site URL-ითაა გამართული, apex-ს უკან www-ზე გადამისამართებს. თითოეული იზოლაციაში სწორია. გადაწყვიტე, რომელ ფენას ეკუთვნის გადამისამართება და მეორეში გამორთე.
HSTS ძალიან ადრე გამოყენებული. Strict-Transport-Security: max-age=31536000; includeSubDomains ბრაუზერს ეუბნება, რომ ამ ჰოსტსა და ყველაფერს მის ქვეშ უბრალო HTTP უარყოს ერთი წლით, და უკან წაღების საშუალება არ გაქვს. includeSubDomains დაამატე მხოლოდ მაშინ, როცა შენ კუთვნილ ყველა ქვედომენს მუშა სერტიფიკატი აქვს, და preload სიაში მხოლოდ მაშინ გაგზავნე, როცა დარწმუნებული ხარ, რადგან მისგან ამოღება თვეებს გრძელდება.
Mixed content გადატანის შემდეგ. გვერდები, რომლებიც სკრიპტებს ან სურათებს http://www.example.com-იდან იტვირთავს, მონაცემთა ბაზაში მყარად ჩაწერილი. სტანდარტული გამოსავალი კონტენტზე search-and-replace-ია; გააკეთე ის ჯერ ასლზე და დაწყებამდე გააკეთე backup, რომელიც რეალურად აღადგინე.
Cookie-ები, რომლებიც არ მიჰყვება. თუ session-ები www-ზე იყო დაყენებული და კანონიკურ ჰოსტს apex-ზე გადაიტან, ყველა ერთხელ გავა. უვნებელია, მაგრამ გააფრთხილე ხალხი, სანამ ბილეთს გახსნიან.
ქეშები და CDN-ები ჰოსტის მიხედვით. ქეში შენი საიტის წინ ორ ჰოსტს ცალკე გასაღებად თვლის. ცვლილების შემდეგ არაკანონიკური გასაღები ნამდვილი გვერდების ასლებს ინახავს, სანამ ვადა არ გავა. გაწმინდე. HTTP ქეშირების header-ები ახსნილი განმარტავს, რა არის გასაღები და რამდენ ხანს.
FAQ#
მოქმედებს თუ არა www ან apex SEO-ზე?
არა, სანამ ერთ-ერთი თანმიმდევრულად კანონიკურია და მეორე მასზე 301-ით გადამისამართებს. რაც ზემოქმედებს ძიებაზე, არის ერთი და იგივე გვერდების ორივე ჰოსტზე მიწოდება გადამისამართებისა და canonical ბმულის გარეშე, რადგან crawler-ს უნდა გამოიცნოს, რომელი დააინდექსოს და შენი სიგნალები ორზე იყოფა.
შემიძლია უბრალოდ CNAME გამოვიყენო apex-ზე, თუ პროვაიდერი იძლევა?
თუ პროვაიდერი გთავაზობს CNAME flattening-ს, ALIAS-ს ან ANAME-ს, დიახ - ისინი მისამართებით პასუხობენ, ამიტომ ზონა ვალიდური რჩება. პროვაიდერი, რომელიც apex-ზე ნამდვილ CNAME-ს ინახავს და მას ასე აწვდის, გატეხილ ზონას აწარმოებს და ფოსტის მიწოდება ჩვეულებრივ პირველი მსხვერპლია. სანამ დაუჯერებ, შეამოწმე, რას აბრუნებს პროვაიდერი რეალურად, dig example.com ANY-ით.
გადამისამართება 301 უნდა იყოს თუ 302?
301 კანონიკური ჰოსტისთვის, რადგან ის მუდმივია და გინდა, რომ ქეშირდეს. 302 ტესტირებისას, რომ შეცდომა თვეობით არ დარჩეს ბრაუზერებში. როცა დარწმუნდები, გადადი 301-ზე და უკან აღარ დაბრუნდე.
მჭირდება სერტიფიკატი ჰოსტისთვის, რომლიდანაც გადამისამართებ?
დიახ, თუ ვინმე ოდესმე HTTPS-ით მიაღწევს - რასაც გააკეთებენ, რადგან ბრაუზერები ჯერ HTTPS-ს ცდიან და სხვა საიტები https:// პრეფიქსებით ბმულობენ. გადამისამართება ვერ მიწოდდება, სანამ handshake წარმატებული არ არის, ამიტომ სერტიფიკატმა ორივე სახელი უნდა დაფაროს.
რაც შეეხება დომენს www-ს გარეშე?
სრულიად ვარგისია. შექმენი apex ჩანაწერი, www ზონიდან გამოტოვე და ვიზიტორები, რომლებიც მას აკრეფენ, შეცდომის გვერდის ნაცვლად გადაწყვეტის ჩავარდნას მიიღებენ. უმეტესობა ამჯობინებს www-ის შექმნას და გადამისამართებას, რადგან მისი აკრეფა ძველი ჩვევაა და ჩავარდნა ისე გამოიყურება, თითქოს შენი საიტი გათიშულია.
სად გავაკეთო ეს ყველაფერი, თუ ჩემს ჰოსტს DNS რედაქტორი არ აქვს?
იქ, ვინც შენს ზონას პასუხობს, რაც ნაგულისხმევად ჩვეულებრივ შენი რეგისტრატორია. ჩვენ DNS ზონებს აქ არ ვმასპინძლობთ, ამიტომ RE:NODE-ზე ჩანაწერები შენი რეგისტრატორის ან DNS პროვაიდერის პანელში იქმნება, და მხოლოდ მისამართი, რომელზეც მათ მიუთითებ, მოდის ჩვენგან.
კომენტარები
სრულიად ანონიმურად: ანგარიშის, ელფოსტის და cookie-ის გარეშე. ინახება მხოლოდ სახელი, ტექსტი და დრო - სხვა არაფერი. ბმულების რაოდენობა ლიმიტირებულია.