Ох, като почнете да ги криете тия домейни и IP-та... Нали така или иначе трябва да са публично видими, за да имат хората достъп до тях. Криенето е загуба на време. В твоя случай - съвсем, защото даже не си ги скрил на всички места
Имаме два варианта откъм ползването на NS сървъри за управление на домейни - или притежаваш собствени NS сървъри, в които сам управляваш зоните на домейните ти, или ползваш NS сървърите на някой друг (най-често на регистратора или хостинг услугата), където ти е предоставен контролен панел, в който да въведеш записите за домейните ти.
Особеното при първия вариант е, че домейните ще се управляват от NS сървъри, на които изначално никой не знае IP адресите им, за да се свърже с тях, когато отправи питане за адресите на някой твой домейн. Да приемем, че си си купил домейна example.com и смяташ NS сървърите да се казват ns1.example.com и ns2.example.com. В съответната форма в настройките за домейна при регистратора си задаваш NS сървърите, обслужващи домейна example.com, да бъдат ns1.example.com и ns2.example.com. Проблемът е, че IP-тата за тези два субдомейна ще са описани в зоновия файл на твои две машини, за които никой не знае, поради което няма как да се свърже към тях. Питащият за IP адреса на example.com ще получи отговор, че трябва да пита ns1.example.com и ns2.example.com за IP-то на example.com, но тъй като никой не знае IP адресите на ns1.example.com и ns2.example.com (понеже са описани в твоите машини, за които никой все още не знае, че трябва да пита), DNS заявката на питащия се връща отново към example.com, и се изпада в безкрайния цикъл, за който вече говорихме. Тук, в този и само в този вариант се намесват въпросните glue records, които трябва сам да въведеш. Въвеждат се при регистратора, от който си купил домейна (или при регистратора, на който твоят регистратор е посредник). За целта регистраторът трябва да ти е предоставил отделна форма в настройките специално за това. В тази форма трябва да опишеш двете имена ns1.example.com и ns2.example.com заедно с IP адресите им (IPv4 и IPv6). Това не е формата, в която въвеждаш останалите DNS записи (A, MX, TXT и т.н.), при този вариант (при който управлението на DNS записите е на твои машини), нямаш такава форма - A, MX, TXT и т.н. записите се описват в зоновите файлове в твоите машини. Настройките за glue records са в самостоятелна форма. Glue records не се записват в зоновия файл на твоя домейн при останалите DNS записи за домейна. Записват се при регистратора, които се синхронизират с централните домейн регистри, към които всички се допитваме, когато отправим заявка за някой домейн.
Тук можеш да видиш пример как се въвеждат glue records в GoDaddy.
При втория вариант, при който ползваш нечии NS сървъри, в които да си опишеш DNS записите (A, MX, TXT и т.н.), и който, доколкото виждам, е твоят вариант, не ти е нужно да въвеждаш glue records. Собственикът на NS сървърите, които ползваш, вече го е сторил. В случая, собственикът на домейна he.net е въвел нужните glue records за ns1.he.net, ns2.he.net и т.н. (гледам, че има още) при регистратора, от който е купил домейна he.net. На теб ти остава единствено да въведеш DNS записите, които касаят твоите услуги (A, AAAA, MX, TXT и т.н.). Няма никакъв смисъл да въвеждаш A и AAAA записи, сочещи към IP адресите на NS сървърите на he.net, освен ако хостингът ти не е на същите IP-та. Това не са glue records. NS записите, които си въвел, също не вършат никаква работа. Ако за твоя домейн зададеш да се обслужва от NS сървърите на he.net, няма нужда да се грижиш за никакви записи, касаещи NS сървърите. Въведи си A и AAAA записи за домейните и субдомейните, сочещи към IP адресите, където ти е сайтът (сайтовете), въведи си MX запис, ако имаш пощенски сървър, обслужващ този домейн...
Дано сега ти се е поизяснила картинката, че няма да мога да го обясня някак по-иначе за по-ясно
Автор
Тема: tunnelbroker ipv6 и Guru тест проблем (Прочетена 3620 пъти)
Apr 13, 2006, 17:37