Защо прокси контейнерът не използва автоматично DNS контейнера

Стартирането на прокси и DNS сървър на един Docker хост не свързва DNS пътищата им. Важни са три отделни връзки:

• Мрежова достъпност. Отделните Compose проекти обикновено имат отделни мрежи по подразбиране. Поставете услугите в подходяща споделена мрежа — или в един проект, или чрез изрично споделена мрежа между проекти.
• Откриване на услуги. Вграденият DNS на персонализирана Docker мрежа може да резолвва имена на контейнери. Това позволява на приложението да открие съсед; но не избира автоматично този съсед като свой DNS resolver.
• Избор на resolver. Определете resolver-а, използван в прокси контейнера. Полето dns на Compose приема адреси на DNS сървъри. Име като dns.local, което се резолвва в приложение, не го прави валидна стойност за това поле.

Проследете заявката от прокси контейнера до конфигурирания адрес на resolver. Потвърдете маршрут и DNS слушател на този адрес. Публикуването на порт 53 на хоста създава път за достъп от страна на хоста; то не казва на контейнерите да го използват. Контейнери, споделящи мрежа, могат вместо това да комуникират директно.

Ако конфигурацията реферира адреса на DNS контейнера, поддържайте го стабилен при съвместима IPAM конфигурация. Динамично зададен адрес, копиран от контейнера от вчера, може да се провали при пресъздаване. Проверете също и upstream пътя на resolver-а: препращането на неотговорени заявки обратно към самия него създава различен отказ от недостъпен resolver.

Накрая определете кой резолвва дестинацията. HTTP прокси, което резолвва име за CONNECT, може да използва този път през контейнера; SOCKS клиент, който резолвва локално, може и да не го прави. Търсене от хоста доказва маршрута на хоста, не този на прокси процеса.