Пошук DNS іноді займає 5 секунд

У мене працює VM під керуванням Debian Wheezy, на який деякі пошукові імена хоста потребують декількох секунд, хоча резолютор відповідає негайно. Як не дивно, пошук на getaddrinfo()це впливає, але gethostbyname()це не так.

Я переключився на вирішувачі Google, щоб виключити ймовірність того, що локальні зламні, тому моє /etc/resolv.confвиглядає так:

search my-domain.com
nameserver 8.8.4.4
nameserver 8.8.8.8

У мене nsswitch.confє рядок:

hosts: files dns

і моє /etc/hostsне містить нічого незвичайного.

Якщо я спробую telnet webserver 80, він зависає кілька секунд, перш ніж отримати дозвіл імені. ltraceВихід [1] показано , що зависання знаходиться в getaddrinfo()виклику:

getaddrinfo("ifconfig.me", "telnet", { AI_CANONNAME, 0, SOCK_STREAM, 0, 0, NULL, '\000', NULL }, 0x7fffb4ffc160) = 0 <5.020621>

Однак tcpdumpвиявляється, що сервер імен відповів негайно, і лише на другу відповідь було telnetрозблоковано. Відповіді виглядають однаково:

05:52:58.609731 IP 192.168.1.75.43017 > 8.8.4.4.53: 54755+ A? ifconfig.me. (29)
05:52:58.609786 IP 192.168.1.75.43017 > 8.8.4.4.53: 26090+ AAAA? ifconfig.me. (29)
05:52:58.612188 IP 8.8.4.4.53 > 192.168.1.75.43017: 54755 4/0/0 A 219.94.235.40, A 133.242.129.236, A 49.212.149.105, A 49.212.202.172 (93)

[...five second pause...]

05:53:03.613811 IP 192.168.1.75.43017 > 8.8.4.4.53: 54755+ A? ifconfig.me. (29)
05:53:03.616424 IP 8.8.4.4.53 > 192.168.1.75.43017: 54755 4/0/0 A 219.94.235.40, A 133.242.129.236, A 49.212.149.105, A 49.212.202.172 (93)
05:53:03.616547 IP 192.168.1.75.43017 > 8.8.4.4.53: 26090+ AAAA? ifconfig.me. (29)
05:53:03.618907 IP 8.8.4.4.53 > 192.168.1.75.43017: 26090 0/1/0 (76)

Я перевірив журнали брандмауера хостів, і нічого на порту 53 не блокується.

Що викликає ігнорування першої відповіді DNS?

[1] Я додав пару рядків до свого, ltrace.confщоб я міг бачити всередині addrinfoструктури.

Перша відповідь DNS не ігнорується. getaddrinfo()не повернувся, поки не отримав відповідь на перший запит AAAA (ID: 26090). Отже, справжня проблема полягає в тому, чому ваша машина не одразу отримала відповідь на запит AAAA, тоді як отримала відповідь на запит A (ID: 54755).

Одна з відмінностей між getaddrinfo()і gethostbyname()полягає в тому, що перший підтримує і IPv4, і IPv6, тоді як останній підтримує лише IPv4. Тому , коли ви телефонуєте getaddrinfo()з ai_familyбезліччю 0 ( AF_UNSPEC), він не буде повертатися до тих пір , поки не отримає відповідь (або потрапляє тайм - аут) для обох запитів A і AAAA для імені домену при умови. gethostbyname()лише запити для запису A.

Важко віддалено визначити, що може бути причиною вашої проблеми, тим більше що ви вирізали певний tcpdumpрезультат. Щось може вибірково фільтрувати / скидати DNS-трафік між вашими VM та Google Public DNS-розв’язниками. Я спробував відтворити вашу проблему за допомогою KVM Debian Wheezy VM, але telnet ifconfig.meмайже одразу надрукував Trying <IP_address_here>...рядок (це означає, що вона вже вирішила назву).

Це було спричинено надто обмежуючим набором правил на брандмауері Juniper, який знаходиться перед інфраструктурою VMware.

Я побудував тестовий дозвіл, щоб я міг бачити обидві сторони розмови, і пропавший пакет, визначений Кемпніу у його чудовій відповіді, справді був скинутий десь по дорозі. Як зазначається у цій відповіді, getaddrinfo()без вказаної сім'ї адреси буде чекати відповідей, що стосуються всіх підтримуваних сімей, перш ніж повернутися (або, у моєму випадку, вичерпання часу).

Мій колега, який керує мережею, зазначив це

Поведінка за замовчуванням на брандмауері Juniper полягає у закритті сеансу, пов’язаного з DNS, як тільки надійде відповідь DNS, що відповідає цьому сеансу.

Отже, брандмауер бачив відповідь IPv4, зазначивши, що він відповів на запит VM та закрив вхідний шлях до цього порту. Наступний пакет відповідей IPv6 відмовився. Я не знаю, чому обидва пакети пройшли це через другий раз, але вимкнення цієї функції на брандмауері виправило проблему.

Це споріднений витяг з ялівцю КБ:

Ось сценарій, при якому скидаються пакети відповідей DNS:

1. Сеанс для DNS-трафіку створюється, коли перший пакет запитів DNS потрапляє на брандмауер і там налаштована політика дозволу. Тимчасовий час очікування - 60 сек.
2. Безпосередньо перед закриттям сеансу передається новий запит DNS, і оскільки він відповідає наявному сеансу (оскільки вихідний і цільовий порт / пара IP завжди однаковий), він передається брандмауером. Зауважте, що час очікування сеансу не оновлюється відповідно до жодного новоприбутого пакету.
3. Створений сеанс DNS застаріває, коли перша відповідь (відповідь) на запит DNS потрапляє на пристрій, незалежно від кількості часу, що залишився.
4. Коли відповідь DNS передається через брандмауер, сеанс застаріває.
5. Усі наступні відповіді DNS брандмауером видалено, оскільки не існує сеансу.

Якщо ви думаєте підтримати цю відповідь, будь ласка, підкресліть відповідь Кемпніу. Без цього я все одно бідкаюсь, намагаючись знайти якусь проблему з налаштуванням на VM.