Что происходит в рекурсивном запросе DNS, если ttl = 0?
Я думаю лучший из лучших, будет: "Abraham Silberschatz - Понятия Операционной системы"
Я изучил оттуда все основы всех Операционных систем, и я думаю, что каждый системный администратор должен сначала прочитать ту книгу, чтобы понять, как это - все работы.
Значение TTL является временем (обычно в secs), кэшируемая запись DNS сохранена в кэше, прежде чем это будет обновлено. Таким образом, после того как значение TTL достигает нуля, оно пойдет, запрашивают авторитетный сервер имен снова для актуальной записи DNS.
Вы видите это обновление записей DNS с вырыть командой. Вот пример, роют запросы домена google.com (я выбрал этот домен из-за его маленького значения TTL, таким образом, я не должен ожидать так долго записи DNS, которая будет обновлена):
$ dig google.com
; <<>> DiG 9.8.1-P1 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39327
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 154 IN A 74.125.237.33 <== '154 is the TTL value'
... (ANSWERS TRUNCATED)
;; Query time: 16 msec <== notice that the query took 16ms to complete
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 17 21:04:56 2012
;; MSG SIZE rcvd: 204
Теперь проверьте Время запроса снова...
$ dig google.com
... (HEADER TRUNCATED)
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 103 IN A 74.125.237.35 <== TTL value gradually decreases over time
... (ANSWERS TRUNCATED)
;; Query time: 2 msec <== query time is much smaller!
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 17 21:05:48 2012
;; MSG SIZE rcvd: 204
Время запроса меньше, потому что локально кэшируемое значение google.com возвращается.
Теперь давайте ожидать значения TTL для уменьшения к нулю...
$ dig google.com @localhost
... (HEADER TRUNCATED)
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 5 IN A 74.125.237.34
... (ANSWERS TRUNCATED)
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 17 21:07:26 2012
;; MSG SIZE rcvd: 204
почти там...
$ dig google.com @localhost
... (HEADER TRUNCATED)
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 1 IN A 74.125.237.39
... (ANSWERS TRUNCATED)
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 17 21:07:30 2012
;; MSG SIZE rcvd: 204
Теперь кэшируемое значение DNS обновляется; значение TTL начинает считать в обратном порядке снова...
$ dig google.com @localhost
... (HEADER TRUNCATED)
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 291 IN A 74.125.237.131
... (ANSWERS TRUNCATED)
;; Query time: 16 msec <== Notice the longer Query time again.
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 17 21:07:32 2012
;; MSG SIZE rcvd: 204
Вы перепутываете Время жизни DNS и IP?
установлен отправителем датаграммы и уменьшен каждым маршрутизатором на маршруте его месту назначения. Если поле TTL достигает нуля, прежде чем датаграмма прибудет к своему месту назначения, то датаграмма отбрасывается, и датаграмму ошибки ICMP (11 - Превышенное Время) передают обратно отправителю.
установлены авторитетным сервером имен для конкретной ресурсной записи. Когда кэширующийся (рекурсивный) сервер имен запросит авторитетный сервер имен для ресурсной записи, это будет кэшировать ту запись в течение времени (в секундах) указанный TTL.
Таким образом запись DNS TTL никогда не достигает нуля; тогда как пакет IP, который используется для запроса записи DNS, мог бы достигнуть TTL=0, что привело бы к отправителю, получающему упомянутую ошибку ICMP.