Назад | Перейти на главную страницу

CNAME в другой домен не работает в некоторых офисных сетях, почему?

Наш домен aspenfasteners.com обслуживается Volusion. У нас есть записи CNAME «найти» и «поиск», которые указывают на учетные записи индексации сайта на www.picosearch.com.

Эти адреса не работают в НЕКОТОРЫХ сетях частных офисов, имеющих собственный DNS. Мы подозреваем, что проблема исходит от собственных серверов имен Volusion, n2.volusion.com и n3.volusion.com.

Техническая поддержка по проблемам этой технической поддержки не существует.

Мы попробовали выполнить NSLOOKUP на find.aspenfasteners.com с информацией об отладке уровня 2 и получили результаты ниже. Возможно ли, что локальный DNS рекурсивно обращается к серверам имен Volusion, и что хотя Volusion ДЕЙСТВИТЕЛЬНО возвращает каноническое имя, они НЕ разрешают адрес?

Может ли кто-нибудь с опытом в подобных вещах, ПОЖАЛУЙСТА, посмотрите NSLOOKUP ниже и скажите мне, правы ли мы, потому что Volusion не дает мне абсолютно НИКАКОЙ поддержки по этой теме. Мне нужно доказательство того, в чем проблема.

Огромное спасибо!

Карло

find.aspenfasteners.com Сервер: mtl-srm-dbsv-01.fastenerwholesale.com Адрес: 192.168.0.44


SendRequest (), len 61 ЗАГОЛОВОК: opcode = QUERY, id = 8, rcode = NOERROR флаги заголовка: запрос, требуются вопросы рекурсии = 1, ответы = 0, авторитетные записи = 0, дополнительные = 0

QUESTIONS:
    find.aspenfasteners.com.fastenerwholesale.com, type = A, class = IN

------------

Получен ответ (138 байт): HEADER: opcode = QUERY, id = 8, rcode = NXDOMAIN флаги заголовка: response, auth. ответь, хочу рекурсию, рекурсия польза. вопросы = 1, ответы = 0, авторитетные записи = 1, дополнительные = 0

QUESTIONS:
    find.aspenfasteners.com.fastenerwholesale.com, type = A, class = IN
AUTHORITY RECORDS:
->  fastenerwholesale.com
    type = SOA, class = IN, dlen = 46
    ttl = 3600 (1 hour)
    primary name server = mtl-srm-dbsv-01.fastenerwholesale.com
    responsible mail addr = admin.fastenerwholesale.com
    serial  = 10219
    refresh = 900 (15 mins)
    retry   = 600 (10 mins)
    expire  = 86400 (1 day)
    default TTL = 3600 (1 hour)

------------

SendRequest (), len 41 ЗАГОЛОВОК: opcode = QUERY, id = 9, rcode = NOERROR флаги заголовка: запрос, требуются вопросы рекурсии = 1, ответы = 0, авторитетные записи = 0, дополнительные = 0

QUESTIONS:
    find.aspenfasteners.com, type = A, class = IN

------------

Получен ответ (141 байт): HEADER: opcode = QUERY, id = 9, rcode = NXDOMAIN флаги заголовка: response, auth. ответы на вопросы = 1, ответы = 1, авторитетные записи = 1, дополнительные = 1

QUESTIONS:
    find.aspenfasteners.com, type = A, class = IN
ANSWERS:
->  find.aspenfasteners.com
    type = CNAME, class = IN, dlen = 17
    canonical name = www.picosearch.com
    ttl = 3600 (1 hour)
AUTHORITY RECORDS:
->  com
    type = SOA, class = IN, dlen = 43
    ttl = 900 (15 mins)
    primary name server = ns3.volusion.com
    responsible mail addr = admin.volusion.com
    serial  = 1
    refresh = 900 (15 mins)
    retry   = 600 (10 mins)
    expire  = 86400 (1 day)
    default TTL = 3600 (1 hour)
ADDITIONAL RECORDS:
->  ns3.volusion.com
    type = A, class = IN, dlen = 4
    internet address = 65.61.137.154
    ttl = 900 (15 mins)

*** mtl-srm-dbsv-01.fastenerwholesale.com не может найти find.aspenfasteners.com: Несуществующий домен

Глядя на ваш журнал, кажется, что это не проблема с серверами имен Volusion, скорее это проблема с кэширующими резолверами, используемыми некорректно работающими сетями частных офисов.

Первое намерение разрешения заключается в добавлении того, что, как я полагаю, является их собственным доменным именем, поэтому, когда вы посмотрите find.aspenfasteners.com резолверы сначала запрашивают find.aspenfasteners.com.fastenerwholesale.com. Затем преобразователь запрашивает фактический домен, ничего не добавляя. Он запрашивает IP-адрес, связанный с доменом, путем указания типа записи ресурса. A. Сервер имен Volusion правильно устанавливает код возврата на NXDOMAIN (= несуществующий домен), потому что у него нет записи A для запрашиваемого домена. Однако он действительно возвращает запись ресурса CNAME в разделе aswer, поэтому теперь задача преобразователя - найти имя хоста, указанное в записи ресурса CNAME.

Я бы поискал проблемы на стороне резолвера.