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

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

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

Volusion поддержки по этим техническим вопросам не существует.

Мы попробовали 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 HEADER: код операции = 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 (), длина 41 HEADER: код операции = 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: несуществующий домен

1 ответ

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

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

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

Другие вопросы по тегам