CNAME-запись, указывающая на NS-ы

Правильно, но ТС придумал другую схему, которая, очевидно, не может работать. Для международных доменов можно предварительно зарегистрировать DNS-сервер и в дальнейшем указывать NS на самом домене без IP.

То, что задумал ТС, можно реализовать на "стороннем" домене.

ns1.newdns.ru. CNAME ns1.hosting.ru.

ns2.newdns.ru. CNAME ns2.hosting.ru.

И делегировать домен site.ru

на ns1.newdns.ru и ns2.newdns.ru.

P.S.

Хотя корректнее будет:

ns1.newdns.ru. A IP_ns1.hosting.ru

ns2.newdns.ru. A IP_ns2.hosting.ru

Конечно, делегирование домена можно реализовать в разных вариантах, но только не то, что задумал ТС :)

Т.е. CNAME-записи прописывать не нужно в таком случае? Только создать эти поддомены с А-записями с IP-сервера?

Да, CNAME-записи не нужны.

речь о RU

Да, что то одно, или CNAME или A.

Вот именно, а то Вы пишите:

:)

По RFC нельзя использовать CNAME для записей ns:

http://www.ietf.org/rfc/rfc1912.txt

Having NS records pointing to a CNAME is bad and may conflict badly

with current BIND servers. In fact, current BIND implementations

will ignore such records, possibly leading to a lame delegation.

There is a certain amount of security checking done in BIND to

prevent spoofing DNS NS records. Also, older BIND servers reportedly

will get caught in an infinite query loop trying to figure out the

address for the aliased nameserver, causing a continuous stream of

DNS requests to be sent.

Rel, нигде в теме не идет речь о не RU доменах, как в вопросе ТС site.ru и ns1.hosting.ru, так и в любом из ответов в теме.

#dig -t NS site.ru @ns1.site.ru  +short

ns1.hosting.ru.

ns2.hosting.ru.

Alex_5252, все верно, в RFC так, но работает. ТС не спрашивал как правильно, он спросил - будет ли работать :)

Ещё бы знать - будет ли работать на всех реализациях сервисов DNS :)...