External/Internal dns-request

deekerman commented

2026-03-04 03:22:28 -05:00

Owner

Originally created by @apnagaev on GitHub (Dec 24, 2021).

Hi!
My AdGuard Home version is v0.107
It is docker container in virtual machine vith Ubuntu 20.04, intel x64
I have Inernal Domain (microsoft) DNS-server and AdGuard Home. All internal clients request dns from adguard and adguard request dns from ms dns-server (for domain compatibility) for internal clients. For part of device I use DoH and DoT.
Some devices (mobile phones) can request dns from adguard from internal network and from internet (I use DoT, but this issue will be repeat and with dns:53). This device must resolve dns from internal with internal ip and from external with external ip. For this device I use upstrim with inernal dns-server.
In version v0.106.3 it worked correctly. From internet resolved external ip, from internal network - internal ip. In v0.107 it is not work. Device use DoT and have one clientid in both network. It is resolve internal dns from internal and external networks, so if I add internal upstrim, I can't use adguard over internet and if I add external upstrim, I can't use adguard in internal network.
Can you check it and help with issue?
Thanks in advance

Originally created by @apnagaev on GitHub (Dec 24, 2021). Hi! My AdGuard Home version is v0.107 It is docker container in virtual machine vith Ubuntu 20.04, intel x64 I have Inernal Domain (microsoft) DNS-server and AdGuard Home. All internal clients request dns from adguard and adguard request dns from ms dns-server (for domain compatibility) for internal clients. For part of device I use DoH and DoT. Some devices (mobile phones) can request dns from adguard from internal network and from internet (I use DoT, but this issue will be repeat and with dns:53). This device must resolve dns from internal with internal ip and from external with external ip. For this device I use upstrim with inernal dns-server. In version v0.106.3 it worked correctly. From internet resolved external ip, from internal network - internal ip. In v0.107 it is not work. Device use DoT and have one clientid in both network. It is resolve internal dns from internal and external networks, so if I add internal upstrim, I can't use adguard over internet and if I add external upstrim, I can't use adguard in internal network. Can you check it and help with issue? Thanks in advance

deekerman added the

feature request

label

2026-03-04 03:22:28 -05:00

deekerman commented

2026-03-04 03:22:36 -05:00

Author

Owner

@EugeneOne1 commented on GitHub (Dec 24, 2021):

@apnagaev, hello and thanks for the report. Could you please clarify some points:

How did you configured the devices to use your internal DNS server? Have it been done via client's setting? If so, how do you identify them?
If the internal DNS server is configured for the devices by it's IP address? Or some special domain name is used?

Could you also provide some examples of queries that are preformed but shouldn't along with the appropriate entries from query log?

@EugeneOne1 commented on GitHub (Dec 24, 2021): @apnagaev, hello and thanks for the report. Could you please clarify some points: 1. How did you configured the devices to use your internal DNS server? Have it been done via client's setting? If so, how do you identify them? 1. If the internal DNS server is configured for the devices by it's IP address? Or some special domain name is used? Could you also provide some examples of queries that are preformed but shouldn't along with the appropriate entries from query log?

deekerman commented

2026-03-04 03:22:44 -05:00

Author

Owner

@apnagaev commented on GitHub (Dec 24, 2021):

thanks for answer!

I use standart DoT in android mobilephones with DoT-address=ap.dot.mydomain.ru. In client profile in adguard I use DNS-id = ap
I added internal IP in client profile, but adguard use only DoT-id (ap)
It is example from internal network:

It is from external:

But in version v0.106.3 for internal request adguard gived internal dns-record and for external request - external record.

It is client profile:

I drawed schem, may be it will be useful.

@apnagaev commented on GitHub (Dec 24, 2021): thanks for answer! 1. I use standart DoT in android mobilephones with DoT-address=ap.dot.mydomain.ru. In client profile in adguard I use DNS-id = ap 2. I added internal IP in client profile, but adguard use only DoT-id (ap) It is example from internal network: ![image](https://user-images.githubusercontent.com/87721833/147367339-c6b8d049-b931-4be6-bd65-ba5e1878677f.png) It is from external: ![image](https://user-images.githubusercontent.com/87721833/147367389-dceb0cd6-ca23-4f19-851c-a70b4c7c4c40.png) But in version v0.106.3 for internal request adguard gived internal dns-record and for external request - external record. It is client profile: ![image](https://user-images.githubusercontent.com/87721833/147367457-786ca898-fea0-4907-961b-d1973fffc111.png) I drawed schem, may be it will be useful. ![image](https://user-images.githubusercontent.com/87721833/147367557-1143e9c5-7b5f-48d8-9e52-e7322868370f.png)

deekerman commented

2026-03-04 03:22:44 -05:00

Author

Owner

@ainar-g commented on GitHub (Dec 24, 2021):

(Вижу, у вас интерфейс на русском, так что, если можно, давайте на нём.)

@apnagaev, спасибо за подробный ответ и схему! Если я правильно понял, 10.255.255.2 — это ваш приватный DNS-сервер? В версиях до v0.107.0 функционал кастомных апстримов для клиентов с ClientID не работал, а в v0.107.0 мы его починили, см #3186. Как я вижу, у вашего клиента есть ClientID и кастомный апстрим, поэтому все запросы от него теперь корректно перенаправляются на приватный апстрим.

Если вам для клиента ap_ph совсем не нужны ответы от приватного DNS-сервера, то просто исключите его адрес из настроек клиента. Если вам нужны, например, только для домена my.local, то замените список апстримов на что-то типа:

[/my.local/]10.255.255.2
1.1.1.1

@ainar-g commented on GitHub (Dec 24, 2021): (Вижу, у вас интерфейс на русском, так что, если можно, давайте на нём.) @apnagaev, спасибо за подробный ответ и схему! Если я правильно понял, `10.255.255.2` — это ваш приватный DNS-сервер? В версиях до v0.107.0 функционал кастомных апстримов для клиентов с ClientID не работал, а в v0.107.0 мы его починили, см #3186. Как я вижу, у вашего клиента есть ClientID и кастомный апстрим, поэтому *все* запросы от него теперь корректно перенаправляются на приватный апстрим. Если вам для клиента `ap_ph` совсем не нужны ответы от приватного DNS-сервера, то просто исключите его адрес из настроек клиента. Если вам нужны, например, только для домена `my.local`, то замените список апстримов на что-то типа: ```none [/my.local/]10.255.255.2 1.1.1.1 ```

deekerman commented

2026-03-04 03:22:44 -05:00

Author

Owner

@apnagaev commented on GitHub (Dec 24, 2021):

думал здесь принято на английском) на русском будет продуктивнее, спасибо!

Ваш вариант был одним из первых, которыми я пытался самостоятельно решить проблему) но так не подойдет.
Клиент ap_ph должен получать внешнюю запись при обращении через мобильную сеть и внутреннюю при обращении через WiFi, домен mydomain.ru маршрутизируемый и ресурс cloud.mydomain.ru внутри периметра имеет адрес 10.255.x.x, а за пределами периметра 83.x.x.x. Если я применю конфиг таким образом, то на любое обращение к mydomain.ru будет отдавать внутренний адрес, даже если я за пределами периметра.
Не знаю почему в 106 все работало правильно, но работало, у меня в докере обе версии и этот кейс легко повторяется. На ум приходит какойто параметр который бы менял апстрим дополнительно в зависимости от реального ip клиента.

@apnagaev commented on GitHub (Dec 24, 2021): думал здесь принято на английском) на русском будет продуктивнее, спасибо! Ваш вариант был одним из первых, которыми я пытался самостоятельно решить проблему) но так не подойдет. Клиент ap_ph должен получать внешнюю запись при обращении через мобильную сеть и внутреннюю при обращении через WiFi, домен mydomain.ru маршрутизируемый и ресурс cloud.mydomain.ru внутри периметра имеет адрес 10.255.x.x, а за пределами периметра 83.x.x.x. Если я применю конфиг таким образом, то на любое обращение к mydomain.ru будет отдавать внутренний адрес, даже если я за пределами периметра. Не знаю почему в 106 все работало правильно, но работало, у меня в докере обе версии и этот кейс легко повторяется. На ум приходит какойто параметр который бы менял апстрим дополнительно в зависимости от реального ip клиента.

deekerman commented

2026-03-04 03:22:44 -05:00

Author

Owner

@ainar-g commented on GitHub (Dec 24, 2021):

В настоящее время такое можно сделать либо через правила $dnsrewrite:

||cloud.mydomain.ru^$client=10.255.255.123,dnsrewrite=NOERROR;A;10.255.254.1

Где 10.255.255.123 — IP-адрес клиента ap_ph. Либо сделав двух клиентов, ap_ph_external и ap_ph_internal, расставив им соотв. апстримы.

@ainar-g commented on GitHub (Dec 24, 2021): В настоящее время такое можно сделать либо через [правила `$dnsrewrite`][1]: ```none ||cloud.mydomain.ru^$client=10.255.255.123,dnsrewrite=NOERROR;A;10.255.254.1 ``` Где `10.255.255.123` — IP-адрес клиента `ap_ph`. Либо сделав двух клиентов, `ap_ph_external` и `ap_ph_internal`, расставив им соотв. апстримы. [1]: https://github.com/AdguardTeam/AdGuardHome/wiki/Hosts-Blocklists#dnsrewrite

deekerman commented

2026-03-04 03:22:44 -05:00

Author

Owner

@apnagaev commented on GitHub (Dec 24, 2021):

Разные апстримы для ap_ph_external и ap_ph_internal решило бы вопрос, но это один клиент, просто дома подключается к wifi, а за пределами, соответственно, другие сети. в этом случае придется переписывать профиль DoT в настройках телефона при каждом переключении сети, что не очень удобно.
Вариант с $dnsrewrite возможен, но тоже не идеален, т.к. кроме cloud.mydomain.ru в сети есть еще достаточно большое количество ресурсов, которые также резолвятся по разному снаружи и внутри. придется по сути повторить все записи внутреннего dns на adguard. было бы здорово если бы появился параметр вроде:
||*.mydomain.ru^$client=10.255.0.0/16,dnsserver=10.255.123.123
Пока у меня позникает только желание развернуть еще один контейнер, перед ними поставить haproxy и завернуть запросы с внутренних адресов на "внутренний" adguard, а с внешних на "внешний", но тогда статистика будет не централизованной, да и вцелом такое решение кажется избыточным

@apnagaev commented on GitHub (Dec 24, 2021): Разные апстримы для ap_ph_external и ap_ph_internal решило бы вопрос, но это один клиент, просто дома подключается к wifi, а за пределами, соответственно, другие сети. в этом случае придется переписывать профиль DoT в настройках телефона при каждом переключении сети, что не очень удобно. Вариант с $dnsrewrite возможен, но тоже не идеален, т.к. кроме cloud.mydomain.ru в сети есть еще достаточно большое количество ресурсов, которые также резолвятся по разному снаружи и внутри. придется по сути повторить все записи внутреннего dns на adguard. было бы здорово если бы появился параметр вроде: `||*.mydomain.ru^$client=10.255.0.0/16,dnsserver=10.255.123.123` Пока у меня позникает только желание развернуть еще один контейнер, перед ними поставить haproxy и завернуть запросы с внутренних адресов на "внутренний" adguard, а с внешних на "внешний", но тогда статистика будет не централизованной, да и вцелом такое решение кажется избыточным

deekerman commented

2026-03-04 03:22:44 -05:00

Author

Owner

@ainar-g commented on GitHub (Dec 24, 2021):

Модификатор client (как и настройки перманентных клиентов) поддерживает CIDR, так что вы могли бы сделать что-то типа:

||site1.mydomain.ru^$client=10.255.0.0/16,dnsrewrite=NOERROR;A;10.255.254.1
||site2.mydomain.com^$client=10.255.0.0/16,dnsrewrite=NOERROR;A;10.255.254.2
||site3.mydomain.local^$client=10.255.0.0/16,dnsrewrite=NOERROR;A;10.255.254.3
…

То есть, создание DNS-зоны для клиентов в подсети. По сути заменяя ваш приватный DNS-сервер на AGH. Более того, правила $dnsrewrite будут работать и с фильтрлистами, так что вы можете добавить список со всеми IP приватных сервисов в таком виде в качестве списка на странице «Фильтры → Чёрные списки DNS».

По-другому сейчас сделать будет сложно, так как тут переплетаются идентификация клиента по подсети/IP-адресу, идентификация по ClientID, а также кастомные апстримы для доменов. Мы рассмотрим другие варианты на след. неделе.

@ainar-g commented on GitHub (Dec 24, 2021): Модификатор `client` (как и настройки перманентных клиентов) поддерживает CIDR, так что вы могли бы сделать что-то типа: ```none ||site1.mydomain.ru^$client=10.255.0.0/16,dnsrewrite=NOERROR;A;10.255.254.1 ||site2.mydomain.com^$client=10.255.0.0/16,dnsrewrite=NOERROR;A;10.255.254.2 ||site3.mydomain.local^$client=10.255.0.0/16,dnsrewrite=NOERROR;A;10.255.254.3 … ``` То есть, создание DNS-зоны для клиентов в подсети. По сути заменяя ваш приватный DNS-сервер на AGH. Более того, правила `$dnsrewrite` будут работать и с фильтрлистами, так что вы можете добавить список со всеми IP приватных сервисов в таком виде в качестве списка на странице «Фильтры → Чёрные списки DNS». По-другому сейчас сделать будет сложно, так как тут переплетаются идентификация клиента по подсети/IP-адресу, идентификация по ClientID, а также кастомные апстримы для доменов. Мы рассмотрим другие варианты на след. неделе.

deekerman commented

2026-03-04 03:22:44 -05:00

Author

Owner

@apnagaev commented on GitHub (Dec 24, 2021):

Если что-то подобное реализовать получится или будет в плане, то пока буду сидеть на версии 106.3, т.к. ресурсов внутри достаточно много.
Если возьмёте в работу, буду внимательно следить и с нетерпением ждать))

@apnagaev commented on GitHub (Dec 24, 2021): Если что-то подобное реализовать получится или будет в плане, то пока буду сидеть на версии 106.3, т.к. ресурсов внутри достаточно много. Если возьмёте в работу, буду внимательно следить и с нетерпением ждать))

deekerman commented

2026-03-04 03:22:44 -05:00

Author

Owner

@apnagaev commented on GitHub (Jan 13, 2022):

пока новостей нет?

@apnagaev commented on GitHub (Jan 13, 2022): пока новостей нет?

deekerman commented

2026-03-04 03:22:44 -05:00

Author

Owner

@ainar-g commented on GitHub (Jan 24, 2022):

@apnagaev, в ближайшее время подобная фича вряд ли будет реализована. Модель с двумя разными клиентами пока остаётся главным вариантом решения подобных задач.

@ainar-g commented on GitHub (Jan 24, 2022): @apnagaev, в ближайшее время подобная фича вряд ли будет реализована. Модель с двумя разными клиентами пока остаётся главным вариантом решения подобных задач.

deekerman commented

2026-03-04 03:22:44 -05:00

Author

Owner

@apnagaev commented on GitHub (Jan 24, 2022):

Понял, спасибо. А внешняя СУБД для логов не планируется? чтобы хотябы статистику в одном месте собирать

@apnagaev commented on GitHub (Jan 24, 2022): Понял, спасибо. А внешняя СУБД для логов не планируется? чтобы хотябы статистику в одном месте собирать

deekerman commented

2026-03-04 03:22:44 -05:00

Author

Owner

@ainar-g commented on GitHub (Jan 25, 2022):

Зависит от вашего определения «внешней». Рекомендую подписаться на этот тикет: #2290. Мы в любом случае хотим сделать какой-то дружественный к обработке формат.

@ainar-g commented on GitHub (Jan 25, 2022): Зависит от вашего определения «внешней». Рекомендую подписаться на этот тикет: #2290. Мы в любом случае хотим сделать какой-то дружественный к обработке формат.

Rows
Columns

External/Internal dns-request #3299