Как прикрепить доменное имя к dyndns?

@ CNAME website2.dyndns.org же?

при попытке сделать так говорит: «A record of a different type exists for the hostname @, could not create CNAME»

для @ хоста есть только NS записи, указывающие на сервера регистратора. //регистратор - GoDaddy

это может быть связано с тем, что где-то не успел обновиться кэш? раньше стояла запись типа A с хостом @ и адресом, но я её удалил.

на каком ns сервере управляете зоной? у меня на dns.he.net(рекомендую) есть запись @ A. Создал @ CNAME только что. Запись @ A после этого резолвится для хоста указанного в @ CNAME. Соответственно записи @ A неактуальны вообще и их я могу удалить. Стоит почитать rfc про ограничения cname

походу у гоудяди надмозговые проверки для записей вносимых на нс сервер

управляю зоной на godaddy

там есть какой-то импорт, попробую его

а насчет прокси-фильтров не ясно. DNS работает в основном на udp/53, cname - открыто можно получить из dns, кому только это нужно устанавливать связь и фильтровать ее?

корпоративному прокси :) просто я не знаю, насколько и как именно он копает

@ CNAME website2.dyndns.org же?

Нет. CNAME фактически полное перенаправление, а для самой зоны (@ в большинстве случаев саму зону и обозначает) это делать нельзя, поскольку зона в обязательном порядке должна содержать SOA-запись.

Итого - сделать перенаправление site1.com на website2.dyndns.org нельзя, и дяддя тебя правильно посылает. Максимум только перенаправить http://www.site1.com -> website2.dyndns.org.

или сделать трансфер доменного имени к dyndns, предварительно купив там dns?

или сделать трансфер доменного имени к dyndns, предварительно купив там dns?

Да. Но это уже ничем технически не отличается от зоны на своем выделенном сервере с постоянным IP.

у меня так домена 3 или 4 работают на домашний динамический айпишник. Главное - период статичности у зоны поменьше, да обновлять почаще. Скриптом делаю.

Upd. Два адреса dyndns прописаны в днс-записях - всего-навсего.

я ж говорю: нужно смотреть ограничения для cname. Твои слова выглядят убедитильно. Но я тут глянул Rfc1034(обсолетед, ага) и там тоже вроде здравые строчки:

CNAME RRs cause special action in DNS software.  When a name server
fails to find a desired RR in the resource set associated with the
domain name, it checks to see if the resource set consists of a CNAME
record with a matching class.  If so, the name server includes the CNAME
record in the response and restarts the query at the domain name
specified in the data field of the CNAME record.  The one exception to
this rule is that queries which match the CNAME type are not restarted.

For example, suppose a name server was processing a query with for USC-
ISIC.ARPA, asking for type A information, and had the following resource
records:

    USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU

    C.ISI.EDU       IN      A       10.0.0.52

Both of these RRs would be returned in the response to the type A query,
while a type CNAME or * query should return just the CNAME.

дальше мне стало лень искать, оставлю тебе на контраргументы:3

ну и да - технически это таки работает. и вопрос как к спв: как заставить dig(или любое другое резолвящее говно), отрабатывать запрос итеративно, а не посылать рекурсивные запросы на сторонние сервера? Ведь этот хреносос имеет встроенный root.named, и может делать запросы вида dig @ns.tld poebota.tld. Собственно есть +trace, но там вся трассировочная информация, а не только сам ответ. Нужно собственно чтобы на запрос отвечал только авторитарный сервер(для отсутсвия wrongcached responses). Пока вижу ад вида: dig @`dig @`dig @a.root-servers.net tld.` poebota.tld ns` poebota.tld

Да не стану я с тобой спорить :-)

«@ IN CNAME» вполне работоспособен при соблюдении определённых условий, иное дело что это неправильно, примерно так же как иметь один NS для зоны - работать будет, но «не положено».