Разрешение DNS происходит медленно только при использовании cURL для получения данных

У меня есть домен engine02.prod.qc.offercal.com в моем локальном bind9.

Я не думаю, что это проблема с DNS-сервером или TTL, потому что тест почти всегда выглядит так (я пробовал 2 минуты, используя каждый метод):

curl -o /dev/null http://engine02.prod.qc.offercal.com:49157/void

        time_namelookup:  0.150
           time_connect:  0.151
     time_starttransfer:  0.152
                        ----------
             time_total:  0.152

curl -o /dev/null http://192.168.100.10:49157/void # use IP directly

                  time_namelookup:  0.000
           time_connect:  0.002
     time_starttransfer:  0.003
                        ----------
             time_total:  0.003

time dig @192.168.100.4 engine02.prod.qc.offercal.com

        real 0m0.009s
        user 0m0.004s
        sys  0m0.004s

time host engine02.prod.qc.offercal.com

        engine02.prod.qc.offercal.com has address 192.168.100.10
        real    0m0.011s
        user    0m0.006s
        sys     0m0.004s

Мой resolv.conf файл:

[root@gateway01 ~]# cat /etc/resolv.conf 
nameserver 192.168.100.4

Я когда-то боролся с этой проблемой, пожалуйста, помогите: D

Я недавно столкнулся с этой проблемой при создании updown.io и немного исследовал ее (спасибо @Dan за strace команда). Вот что я нашел:

Состояние

В моем случае curl иногда требовалось 65 мс для разрешения, а иногда <5 мс. Это заняло 65 мс после короткого времени бездействия (пара минут) и <5 мс после повторных вызовов. Определенно звучит как проблема с кешем и TTL. Но моя запись имеет TTL 86400 с (1 день), и она уже была кэширована на моем локальном преобразователе, и копание всегда занимало 1 мс.

Меры

Итак, я попробовал запустить curl с strace чтобы увидеть, на что было потрачено время, и вот что я нашел (для ясности убрал некоторые детали):

05:57:52.303 connect(3) = 0
05:57:52.303 sendmmsg(3, ["1\26\1\0\0\1\0\0\0\0\0\0\22jarthon-architecte\3"..., "\0253\1\0\0\1\0\0\0\0\0\0\22jarthon-architecte\3"...] , 2) = 2
05:57:52.303 poll([{fd=3, events=POLLIN}], 1, 5000) = 1
05:57:52.303 ioctl(3, FIONREAD, [56]) = 0
05:57:52.303 recvfrom(3, "1\26\201\200\0\1\0\1\0\0\0\0\22jarthon-architecte\3"...) = 56
05:57:52.304 poll([{fd=3, events=POLLIN}], 1, 4999) = 1
05:57:52.373 ioctl(3, FIONREAD, [96]) = 0
05:57:52.373 recvfrom(3, "\0253\201\200\0\1\0\0\0\1\0\0\22jarthon-architecte\3"...) = 96
05:57:52.373 close(3) = 0

Это часть разрешения DNS, здесь мы ясно видим, что 2 сообщения отправлено, один ответ получен довольно быстро, а другой получен с задержкой в 69 мс. Я подумал, что этот второй ответ, вероятно, является запросом IPv6 (AAAA), поэтому я попробовал его в dig:

$ dig AAAA jarthon-architecte.com

;; AUTHORITY SECTION:
jarthon-architecte.com. 180 IN  SOA ns0.dnsmadeeasy.com. dns.dnsmadeeasy.com. 2008010120 43200 3600 1209600 180

;; Query time: 86 msec
;; SERVER: ::1#53(::1)

Хорошо, очевидно, нет ответа, но эта запись SOA имеет TTL 180 с, это очень похоже на время, которое потребовалось для перехода с 5 мс до 65 мс в моих тестах curl.

Объяснение

Запись SOA возвращается вашим DNS-сервером, когда нет ответа, и содержит, среди прочего, отрицательный TTL (последнее число в строке, которое вы видите 180), что означает время, когда любому преобразователю разрешено кэшировать отрицательные ответы (отсутствие записи). Это означает, что когда вы запрашиваете запись AAAA, вы должны обращаться к DNS-серверу по крайней мере каждые 3 минуты, чтобы убедиться, что ее все еще нет.

Исправить

Добавить IPv6 ☺
Если вы управляете DNS, самое простое решение - увеличить это значение, в моем случае я использую DNSMadeEasy, я могу создать настраиваемую запись SOA с более высоким значением TTL и назначить ее своим доменам: http://help.dnsmadeeasy.com/managed-dns/records/soa-start-authority-record/. Это заставит curl разрешаться быстрее в большинстве случаев, возвращаясь к уровню производительности, который у нас есть на нашей правильно кэшированной A-записи.
Если вы делаете завитки, но не управляете DNS, вероятно, есть способы оптимизировать это на уровне преобразователя DNS, подав устаревший отрицательный ответ при получении реальных значений или тому подобное, но я не смотрел в это еще.
Если вас не волнует IPv6, вы также можете отключить его, используя curl флаг командной строки -4

Если это более новая версия debian (а именно ubuntu 13+), вам необходимо добавить DNS-серверы в конец / etc / network / interfaces после статической конфигурации IP. Редактирование файла resolv.conf только огорчит вас по поводу этих разновидностей Linux.

т.е.

после линии шлюза

dns-nameservers local.dns.ip.here outside.back.ip.here