Кеширование DNS не очищает Mac OSX

Question

Что-то странное происходит на моей машине. Я жду на домене для распространения. Я захожу на страницу в Chrome, и она еще не там. но если я посмотрю на него на другой машине, на другом интернет-провайдере, он там.

Я попытался очистить кэш с помощью dscacheutil -flushcache и sudo killall -HUP mDNSResponder но до сих пор там не было.

Если я использую dig , я получаю это, который имеет неправильные записи DNS:

; <<>> DiG 9.8.3-P1 <<>> http://www.xxx.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37789
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;http://www.xxx.com.    IN  A

;; AUTHORITY SECTION:
xxx.com.    3174    IN  SOA dns1.registrar-servers.com. hostmaster.registrar-servers.com. 2014090300 3600 1801 604800 3601

;; Query time: 31 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Fri Oct 17 09:26:21 2014
;; MSG SIZE  rcvd: 119

если я использую dig +trace , последние два шага показывают правильные записи DNS:

;; Received 448 bytes from 000.0.00.00#53(000.0.00.00) in 79 ms

xxx.com.    86400   IN  NS  ns1.correctns.com.
000.0.00.00.    86400   IN  NS  ns2.correctns.com.
;; Received 96 bytes from 1000.0.00.00#53(1000.0.00.00) in 78 ms

000.0.00.00.    86400   IN  SOA ns1.correctns.com. ns2.correctns.com. 2014101603 86400 7200 3600000 86400
;; Received 138 bytes from 66.117.5.83#53(66.117.5.83) in 68 ms

Честно говоря, я не знаю, что я здесь вижу, но похоже, что он кэширует неверную информацию, а затем всегда ссылается на нее, а не на свежую информацию из прогона +trace ?

У меня такое случается очень часто. Могу ли я заставить его выглядеть в нужном месте?

Answer 1

Все работает нормально, насколько я могу судить. Домен xxx.com, похоже, синхронизирован и работает просто отлично. Также заметил, что вы использовали dig http://www.xxx.com . Копать не понимаю URL, попробуйте только часть имени домена, dig www.xxx.com , чтобы получить правильный ответ.

$ dig www.xxx.com

; <<>> DiG 9.9.5-3-Ubuntu <<>> www.xxx.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45553
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.xxx.com.                   IN      A

;; ANSWER SECTION:
www.xxx.com.            86331   IN      A       141.0.173.173

;; Query time: 0 msec
;; SERVER: 
;; WHEN: Sun Oct 19 16:44:50 MDT 2014
;; MSG SIZE  rcvd: 56

Вот подробности о сервере имен.

$ checksoa xxx.com

     Serial #   RTT(ms)  Version                       Nameservers (name, IP, SOA mname field) for xxx.com

    2014040205      80   not currently available       ns4.serverstack.com       69.55.56.130                       SOA: ns1.serverstack.com
    2014040205     111   not currently available       ns1.serverstack.com       69.55.62.180                       SOA: ns1.serverstack.com
    2014040205     185   not currently available       ns2.serverstack.com       141.0.173.228                      SOA: ns1.serverstack.com
    2014040205     174   not currently available       ns3.serverstack.com       87.233.226.25                      SOA: ns1.serverstack.com

Возможно, вам придется очистить локальные кэши DNS, если это не обновляется. Отрицательный TTL кеша - это то, что дает вам новые записи. В этом случае отрицательный TTL составляет 1800 секунд для xxx.com, так что вы можете просто подождать эти 30 минут, и он сам пройдет.

Это распространенная проблема. Вы вносите изменения в DNS, чтобы добавить новую запись, а затем сразу же ищите имя, прежде чем у него есть несколько минут для распространения на все серверы имен, поэтому вы получаете отрицательную запись в кеше прямо перед ее активностью и, таким образом, должны ждать полного заполнения. время (30 минут) или прибегните к очистке локальных кешей DNS, чтобы заставить его работать.

PS: Для тех, кто будет ругать меня за веру, что xxx.com был настоящим доменом, не беспокойтесь. Я знаю, что это фальшивка, но я хочу оставить в реальных доменах, в противном случае помощь ограничена. Я ненавижу угадывать столько же, сколько следующий парень. Используйте реальные домены людей.

Answer 2

Похоже, что он кэшируется DNS-сервером на 10.0.0.1 (вероятно, ваш маршрутизатор). Существует два возможных уровня кэширования, и сброс одного из них не влияет на другой. Позвольте мне пробежаться по опциям:

• dig +trace domainname.com отслеживает DNS-запрос через авторитетные серверы, в вашем случае получая окончательный ответ от 66.117.5.83.

• dig domainname.com просто отправляет запрос на DNS-сервер, настроенный в настройках вашей сети (в вашем случае 10.0.0.1). Обычно это просто сервер кэширования, который запоминает результаты, которые он просматривал ранее, и раздает тот же ответ, пока не истечет время его существования (на xxx.com.3174 В SOA dns1.registrar-servers.com ... осталось 3174 секунды).

• Использование домена с обычными (не ориентированными на DNS) программами, такими как Chrome, проходит через распознаватель OS X, который проверяет свой кэш (здесь применяется та же политика TTL), а если его нет, проверяет настроенный DNS-сервер (помните, что это, вероятно, кеширование). сервер).

Сброс кеша OS X не влияет на кеш на DNS-сервере. Также обратите внимание, что даже если вы перезагрузите свой DNS-сервер (например, перезагрузив маршрутизатор), на других DNS-серверах в сети может сохраняться старая информация. Как правило, когда вы вносите изменения в DNS, вам нужно дождаться истечения срока действия TTL, прежде чем предположить, что новая информация доступна везде.

(И на самом деле, есть еще один уровень, о котором вам нужно беспокоиться - ваши вторичные DNS-серверы только периодически проверяют обновления на первичном сервере, поэтому вам нужно подождать, пока вторичный сервер обновится, ТОГДА для TTL не истечет вся старая информация из различные кеши ...)