Континент TLS-клиент 2.0.1440 Ошибка разрешения имени хоста

Доброго времени суток. При настройке Континент TLS-клиент после настройки Ресурсов lk2012.budget.gov.ru и lk.budget.gov.ru в статусе соединения появляется ошибка "Ошибка разрешения имени хоста" . Прокси настроены согласно инструкции. В чем может быть причина?

Решилось тем что прописал хосты

Не могли подсказать как именно и где Вы прописали хосты?

В hosts файле прописал ip адрес и lk.budget.gov.ru

Здравствуйте! Опишите пожалуйста поподробнее действия...

заходите на компьютере по данному пути C:\Windows\System32\drivers\etc, далее открываете hosts файл блокнотом, после прописываете внизу
94.25.27.229 lk.budget.gov.ru
94.25.27.229 lk2012.budget.gov.ru сохраняете выбрав не .txt а просто все файлы и все

Здравствуйте! Столкнулся с подобной ошибкой, но только для "lk2012.budget.gov.ru". В хостах прописал, результат нулевой. Что ещё можно сделать для решения?

ОС - Win 10
Версия Континента - 2.0.1440
Решено.
"lk2012.budget.gov.ru" и "lk2012.budget.gov.ru/" - разные вещи.

saydik пишет: заходите на компьютере по данному пути C:\Windows\System32\drivers\etc, далее открываете hosts файл блокнотом, после прописываете внизу
94.25.27.229 lk.budget.gov.ru
94.25.27.229 lk2012.budget.gov.ru сохраняете выбрав не .txt а просто все файлы и все

Вдруг в 2020 у кого то такие же проблемы. Теперь для lk.budget.gov.ru другой ip 95.167.245.91

Спасибо. Этот способ помог при такой же ошибке в учреждении. При подключении через ЕСПД была такая же ошибка при запуске ацк финансы.

Столкнулся с такой же проблемой, причем от версии сборки TLS-клиента это не зависит: проявляется и на 1440 и на свежей 1482.
После перезагрузки компа все ресурсы, добавленные в TLS-клиент, отображаются с красным знаком и статусом "Ошибка разрешения имени хоста". Эта же ошибка мешает регистрации самого TLS-клиента, и работе с CDP.

Опытным путем установил, что проблема проявляется только в том случае, когда в качестве DNS-сервера указан контроллер домена Windows. Если временно указать любой другой адрес в качестве DNS-сервера (8.8.8.8, или свой пограничный роутер, или DNS-сервер провайдера) - то TLS-клиент прекрасно работает, проблем с разрешением имен хостов нет. Более того, если из командной строки на машинке с TLS-клиентом пингануть ресурс, DNS-сервер на контроллере домена прекрасно его распознает, и запись о нем останется в DNS-кеше рабочей станции. После успешного пинга в TLS-клиенте делаем правый клик\Cброс соединений - и все работает.

Напрашивается вывод - что TLS-клиент 2.0 формирует в чем-то нестандартный DNS-запрос, и реализация DNS-сервера от Microsoft такой запрос отработать не может.

>нестандартный DNS-запрос
Забавно. А ресольвер от доменного сервера DNS корректно работает? А в браузере случайно свеженькая технология "DNS over TLD" не включена? Если обратится к своему домену "domain.com" в браузере - что отобразится?

С разрешением имен проблем нет. И на контроллерах домена, и на рабочих станциях - в качестве DNS-серверов прописны только контроллеры домена. В настройках DNS-севреверов на контроллерах домена в качестве серверов пересылки прописаны либо пограничные роутеры, либо DNS-сервера провайдера.
Не думаю, что настройки новомодных протоколов DNS в браузерах могут влиять на работу с DNS самого TLS-клиента.
Смотрел сниффером, видно, как DNS-сервер не может обработать запросы в момент запуска TLS-клиента
Вот пример одного из запросов:

Frame 165: 618 bytes on wire (4944 bits), 618 bytes captured (4944 bits) on interface \Device\NPF_{BDCDC52D-B5C6-48D0-864F-161010DA0079}, id 0
Ethernet II, Src: Microsof_00:7d:21 (00:15:5d:00:7d:21), Dst: Giga-Byt_37:af:02 (90:2b:34:37:af:02)
Internet Protocol Version 4, Src: 192.168.0.50, Dst: 192.168.0.124
User Datagram Protocol, Src Port: 52722, Dst Port: 53
Domain Name System (query)
Transaction ID: 0x0009
Flags: 0x0100 Standard query
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data: Unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
rostelecom.ru: type A, class IN
Name: rostelecom.ru
[Name Length: 13]
[Label Count: 2]
Type: A (Host Address) (1)
Class: IN (0x0001)
[Response In: 172]

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Frame 172: 618 bytes on wire (4944 bits), 618 bytes captured (4944 bits) on interface \Device\NPF_{BDCDC52D-B5C6-48D0-864F-161010DA0079}, id 0
Ethernet II, Src: Giga-Byt_37:af:02 (90:2b:34:37:af:02), Dst: Microsof_00:7d:21 (00:15:5d:00:7d:21)
Internet Protocol Version 4, Src: 192.168.0.124, Dst: 192.168.0.50
User Datagram Protocol, Src Port: 53, Dst Port: 52722
Domain Name System (response)
Transaction ID: 0x0009
Flags: 0x8382 Standard query response, Server failure
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority for domain
.... ..1. .... .... = Truncated: Message is truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... 1... .... = Recursion available: Server can do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... ...0 .... = Non-authenticated data: Unacceptable
.... .... .... 0010 = Reply code: Server failure (2)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
rostelecom.ru: type A, class IN
Name: rostelecom.ru
[Name Length: 13]
[Label Count: 2]
Type: A (Host Address) (1)
Class: IN (0x0001)
[Request In: 165]
[Time: 0.001250000 seconds]

Таки удалось воспроизвести проблему

Чтобы на DNS-запросы от TLS-клиента пришел отклик – временно разрешил использование корневых серверов на доменном DNS-сервере (в реальных сетях так не делается – там жесткая политика доступа к вышестоящим DNS-серверам, допустимо использование только DNS-серверов провайдера. Работа через DNS-сервер провайдера и надежнее, т.к. он ближе и безопаснее – межсетевой экран не позволит обратиться к произвольным DNS-серверам, в т.к. и подставленным вредоносной программой адресам DNS-серверов мошенников).

При установленной галке в дампе трафика видно, что происходит множество обращений к DNS-серверам, обслуживающим конкретные зоны, интересующие TLS-клиента. Видно, что многие промежуточные сервера дают отклик Format Error, но после нескольких неудачных попыток он все-таки достукивается.

Мыши плакали кололись, но продолжали жрать кактус (c)

Зачем вам это убожество? Нельзя через https работать как адекватные люди?

Думаю, большинство пользователей TLS-клиента никто и не спрашивает, просто ставят перед фактом. Чтобы работать с нашим порталом - подключайтесь вот так-то к нам. Сам по себе TLS-клиент бесполезен же. Теоретически, право выбора было у владельцев TLS-сервера, но они явно не придут сюда, чтобы поделиться впечатлениями