Проблеми з розповсюдженням DNS через 10 днів після внесення змін

25

Інженерна команда, з якою я працюю, перебуває в процесі переміщення обладнання з одного центру обробки даних в інший. Десять днів тому ми перемістили один з наших серверів імен, авторитетний для доменів нашого клієнта (ns1.faithhiway.com) та оновив його IP-адресу відповідним постачальником DNS (register.com), щоб вказати на новий центр обробки даних. Усі проведені тести показують, що цей сервер імен правильно працює у своєму новому місці та коли його запитують, повертаючи правильну відповідь для будь-яких доменів, за які він відповідає.

Проблема полягає в тому, що через 72 години ми все ще спостерігали більше DNS-активності за старою IP-адресою, ніж за новою. Хороша новина полягає в тому, що на даний момент сервер імен відповідав на стару IP-адресу, тому ми не бачимо жодних проблем з доменами, за які несе відповідальність сервер імен, але мета полягає в тому, щоб якнайшвидше відмовитися від цього. Як видно з WhatsMyDNS.net , протягом останніх 10 днів, як ми внесли цю зміну, відбулося пристойне поширення, але все ж є деякі місця, які повідомляють про наш початковий IP.

введіть тут опис зображення

Зважаючи на те, що TTL лише 3600 з серверами імен, відповідальних за цей домен, це не має сенсу ні мені, ні іншим інженерам, які працюють зі мною, що у нас виникає ця проблема.

Тепер, якщо я запускаю перевірку DNS за допомогою одного з DNS-серверів Register.com (прямих серверів імен для faithhiway.com), я отримую такий (правильний) результат:

# dig @dns01.gpn.register.com ns1.faithhiway.com A

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @dns01.gpn.register.com. ns1.faithhiway.com A
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43232
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5

;; QUESTION SECTION:
;ns1.faithhiway.com.  IN A

;; ANSWER SECTION:
ns1.faithhiway.com. 3601 IN A 206.127.2.71

;; AUTHORITY SECTION:
faithhiway.com.  3600 IN NS dns01.gpn.register.com.
faithhiway.com.  3600 IN NS dns02.gpn.register.com.
faithhiway.com.  3600 IN NS dns03.gpn.register.com.
faithhiway.com.  3600 IN NS dns04.gpn.register.com.
faithhiway.com.  3600 IN NS dns05.gpn.register.com.

;; ADDITIONAL SECTION:
dns01.gpn.register.com. 3600 IN A 98.124.192.1
dns02.gpn.register.com. 3600 IN A 98.124.197.1
dns03.gpn.register.com. 3600 IN A 98.124.193.1
dns04.gpn.register.com. 3600 IN A 69.64.145.225
dns05.gpn.register.com. 3600 IN A 98.124.196.1

;; Query time: 50 msec
;; SERVER: 98.124.192.1#53(98.124.192.1)
;; WHEN: Thu Jan 27 15:16:57 2011
;; MSG SIZE  rcvd: 269

Як довідка, ось результати, коли той самий запит перевіряється на різних загальнодоступних серверах DNS:

Google:

# dig @8.8.8.8 ns1.faithhiway.com A

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @8.8.8.8. ns1.faithhiway.com A
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12773
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.faithhiway.com.  IN A

;; ANSWER SECTION:
ns1.faithhiway.com. 997 IN A 206.127.2.71

;; Query time: 29 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Jan 27 15:17:31 2011
;; MSG SIZE  rcvd: 52

3 рівень:

# dig @4.2.2.1 ns1.faithhiway.com A

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @4.2.2.1. ns1.faithhiway.com A
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46505
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.faithhiway.com.  IN A

;; ANSWER SECTION:
ns1.faithhiway.com. 2623 IN A 206.127.2.71

;; Query time: 7 msec
;; SERVER: 4.2.2.1#53(4.2.2.1)
;; WHEN: Thu Jan 27 15:18:35 2011
;; MSG SIZE  rcvd: 52

Verizon:

# dig @151.197.0.38 ns1.faithhiway.com A

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @151.197.0.38. ns1.faithhiway.com A
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32658
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.faithhiway.com.  IN A

;; ANSWER SECTION:
ns1.faithhiway.com. 3601 IN A 206.127.2.71

;; Query time: 81 msec
;; SERVER: 151.197.0.38#53(151.197.0.38)
;; WHEN: Thu Jan 27 15:19:15 2011
;; MSG SIZE  rcvd: 52

Cisco:

# dig @64.102.255.44 ns1.faithhiway.com A

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @64.102.255.44. ns1.faithhiway.com A
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39689
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.faithhiway.com.  IN A

;; ANSWER SECTION:
ns1.faithhiway.com. 3601 IN A 206.127.2.71

;; AUTHORITY SECTION:
faithhiway.com.  3600 IN NS dns01.gpn.register.com.
faithhiway.com.  3600 IN NS dns04.gpn.register.com.
faithhiway.com.  3600 IN NS dns05.gpn.register.com.
faithhiway.com.  3600 IN NS dns02.gpn.register.com.
faithhiway.com.  3600 IN NS dns03.gpn.register.com.

;; Query time: 105 msec
;; SERVER: 64.102.255.44#53(64.102.255.44)
;; WHEN: Thu Jan 27 15:20:05 2011
;; MSG SIZE  rcvd: 165

OpenDNS:

# dig @208.67.222.222 ns1.faithhiway.com A

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @208.67.222.222. ns1.faithhiway.com A
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12328
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.faithhiway.com.  IN A

;; ANSWER SECTION:
ns1.faithhiway.com. 169507 IN A 207.200.19.162

;; Query time: 6 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Thu Jan 27 15:19:29 2011
;; MSG SIZE  rcvd: 52

SpeakEasy:

# dig @66.93.87.2 ns1.faithhiway.com A

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @66.93.87.2. ns1.faithhiway.com A
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9342
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.faithhiway.com.  IN A

;; ANSWER SECTION:
ns1.faithhiway.com. 169323 IN A 207.200.19.162

;; Query time: 69 msec
;; SERVER: 66.93.87.2#53(66.93.87.2)
;; WHEN: Thu Jan 27 15:19:51 2011
;; MSG SIZE  rcvd: 52

Як ви бачите вище, більшість запитів повертають правильний результат. Але деякі (OpenDNS та SpeakEasy у наведених вище прикладах) все ще показують стару IP-адресу. З огляду на тривалий час, мені здається очевидним, що ми або помилилися, і не ретельно обробили зміни DNS з нашого кінця (швидше за все), або є проблема з будь-яким постачальником DNS для цього домену (Зареєструйтесь ) або з деякими з серверів DNS у дикій природі (досить малоймовірно).

Будь-яка порада, як я можу продовжувати це?

ОНОВЛЕННЯ (31 січня 2011 р.):

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

У будь-якому разі я проводив ще кілька досліджень цієї проблеми і виявив наступне цікаве явище. Під час перевірки записів на клей для verhiway.com завжди вирішується правильно, якщо я переходжу і перевіряю домен клієнта (де ns1.faithhiway.com є авторитетним), я отримую дивну відповідь. Схоже, кореневі сервери повертають nsX.faithhiway.com як свої старі IP-адреси (у Додатковому розділі). Оскільки у нас все ще є сервер, який відповідає на запити DNS, трасування завершується і повертає правильні IP-адреси в якості останнього кроку (знову ж таки, у розділі Додатковий розділ). У наведеному нижче прикладі використовується один з доменів, який ми використовуємо, який використовує ns1.faithhiway.com як його авторитетний DNS-сервер.

# dig +trace +nosearch +all +norecurse ignitemail.com

; <<>> DiG 9.2.4 <<>> +trace +nosearch +all +norecurse ignitemail.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46856
;; flags: qr ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;.    IN NS

;; ANSWER SECTION:
.   7986 IN NS a.root-servers.net.
.   7986 IN NS b.root-servers.net.
.   7986 IN NS c.root-servers.net.
.   7986 IN NS d.root-servers.net.
.   7986 IN NS e.root-servers.net.
.   7986 IN NS f.root-servers.net.
.   7986 IN NS g.root-servers.net.
.   7986 IN NS h.root-servers.net.
.   7986 IN NS i.root-servers.net.
.   7986 IN NS j.root-servers.net.
.   7986 IN NS k.root-servers.net.
.   7986 IN NS l.root-servers.net.
.   7986 IN NS m.root-servers.net.

;; Query time: 39 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Jan 31 09:22:17 2011
;; MSG SIZE  rcvd: 228

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16325
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14

;; QUESTION SECTION:
;ignitemail.com.   IN A

;; AUTHORITY SECTION:
com.   172800 IN NS h.gtld-servers.net.
com.   172800 IN NS m.gtld-servers.net.
com.   172800 IN NS i.gtld-servers.net.
com.   172800 IN NS l.gtld-servers.net.
com.   172800 IN NS c.gtld-servers.net.
com.   172800 IN NS k.gtld-servers.net.
com.   172800 IN NS d.gtld-servers.net.
com.   172800 IN NS f.gtld-servers.net.
com.   172800 IN NS b.gtld-servers.net.
com.   172800 IN NS a.gtld-servers.net.
com.   172800 IN NS e.gtld-servers.net.
com.   172800 IN NS g.gtld-servers.net.
com.   172800 IN NS j.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 172800 IN A 192.33.14.30
b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 172800 IN A 192.26.92.30
d.gtld-servers.net. 172800 IN A 192.31.80.30
e.gtld-servers.net. 172800 IN A 192.12.94.30
f.gtld-servers.net. 172800 IN A 192.35.51.30
g.gtld-servers.net. 172800 IN A 192.42.93.30
h.gtld-servers.net. 172800 IN A 192.54.112.30
i.gtld-servers.net. 172800 IN A 192.43.172.30
j.gtld-servers.net. 172800 IN A 192.48.79.30
k.gtld-servers.net. 172800 IN A 192.52.178.30
l.gtld-servers.net. 172800 IN A 192.41.162.30

;; Query time: 64 msec
;; SERVER: 198.41.0.4#53(a.root-servers.net)
;; WHEN: Mon Jan 31 09:22:17 2011
;; MSG SIZE  rcvd: 504

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12860
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ignitemail.com.   IN A

;; AUTHORITY SECTION:
ignitemail.com.  172800 IN NS ns1.faithhiway.com.
ignitemail.com.  172800 IN NS ns2.faithhiway.com.

;; ADDITIONAL SECTION:
ns1.faithhiway.com. 172800 IN A 207.200.19.162
ns2.faithhiway.com. 172800 IN A 207.200.50.142

;; Query time: 152 msec
;; SERVER: 192.54.112.30#53(h.gtld-servers.net)
;; WHEN: Mon Jan 31 09:22:17 2011
;; MSG SIZE  rcvd: 111

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43016
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ignitemail.com.   IN A

;; ANSWER SECTION:
ignitemail.com.  3600 IN A 206.127.2.64

;; AUTHORITY SECTION:
ignitemail.com.  3600 IN NS ns1.faithhiway.com.
ignitemail.com.  3600 IN NS ns2.faithhiway.com.

;; ADDITIONAL SECTION:
ns1.faithhiway.com. 3600 IN A 206.127.2.71
ns2.faithhiway.com. 3600 IN A 206.127.2.72

;; Query time: 25 msec
;; SERVER: 206.127.2.71#53(ns1.faithhiway.com)
;; WHEN: Mon Jan 31 09:22:18 2011
;; MSG SIZE  rcvd: 127

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

opendns  domain-name-system  glue-record 
— runlevelsix
джерело
3
Я хотів би, щоб це було задано більше питань, ви маєте мою нагоду щодо якості
— Джефф Етвуд

Відповіді:

5

Проблема вирішена. Нарешті. Мабуть, Register.com не оновив записи про клей для ns1 та ns2.faithhiway.com, незважаючи на наш первинний запит про це (і підтвердження того, що це було зроблено).

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

# dig +trace +nosearch +all +norecurse ignitemail.com

; <<>> DiG 9.2.4 <<>> +trace +nosearch +all +norecurse ignitemail.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12706
;; flags: qr ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;.              IN  NS

;; ANSWER SECTION:
.           79883   IN  NS  a.root-servers.net.
.           79883   IN  NS  b.root-servers.net.
.           79883   IN  NS  c.root-servers.net.
.           79883   IN  NS  d.root-servers.net.
.           79883   IN  NS  e.root-servers.net.
.           79883   IN  NS  f.root-servers.net.
.           79883   IN  NS  g.root-servers.net.
.           79883   IN  NS  h.root-servers.net.
.           79883   IN  NS  i.root-servers.net.
.           79883   IN  NS  j.root-servers.net.
.           79883   IN  NS  k.root-servers.net.
.           79883   IN  NS  l.root-servers.net.
.           79883   IN  NS  m.root-servers.net.

;; Query time: 293 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Jan 31 13:24:02 2011
;; MSG SIZE  rcvd: 228

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43910
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14

;; QUESTION SECTION:
;ignitemail.com.            IN  A

;; AUTHORITY SECTION:
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800  IN  A   192.5.6.30
a.gtld-servers.net. 172800  IN  AAAA    2001:503:a83e::2:30
b.gtld-servers.net. 172800  IN  A   192.33.14.30
b.gtld-servers.net. 172800  IN  AAAA    2001:503:231d::2:30
c.gtld-servers.net. 172800  IN  A   192.26.92.30
d.gtld-servers.net. 172800  IN  A   192.31.80.30
e.gtld-servers.net. 172800  IN  A   192.12.94.30
f.gtld-servers.net. 172800  IN  A   192.35.51.30
g.gtld-servers.net. 172800  IN  A   192.42.93.30
h.gtld-servers.net. 172800  IN  A   192.54.112.30
i.gtld-servers.net. 172800  IN  A   192.43.172.30
j.gtld-servers.net. 172800  IN  A   192.48.79.30
k.gtld-servers.net. 172800  IN  A   192.52.178.30
l.gtld-servers.net. 172800  IN  A   192.41.162.30

;; Query time: 336 msec
;; SERVER: 198.41.0.4#53(a.root-servers.net)
;; WHEN: Mon Jan 31 13:24:03 2011
;; MSG SIZE  rcvd: 504

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44133
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ignitemail.com.            IN  A

;; AUTHORITY SECTION:
ignitemail.com.     172800  IN  NS  ns1.faithhiway.com.
ignitemail.com.     172800  IN  NS  ns2.faithhiway.com.

;; ADDITIONAL SECTION:
ns1.faithhiway.com. 172800  IN  A   206.127.2.71
ns2.faithhiway.com. 172800  IN  A   206.127.2.72

;; Query time: 2411 msec
;; SERVER: 192.43.172.30#53(i.gtld-servers.net)
;; WHEN: Mon Jan 31 13:24:06 2011
;; MSG SIZE  rcvd: 111

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50833
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ignitemail.com.            IN  A

;; ANSWER SECTION:
ignitemail.com.     3600    IN  A   206.127.2.64

;; AUTHORITY SECTION:
ignitemail.com.     3600    IN  NS  ns1.faithhiway.com.
ignitemail.com.     3600    IN  NS  ns2.faithhiway.com.

;; ADDITIONAL SECTION:
ns1.faithhiway.com. 3600    IN  A   206.127.2.71
ns2.faithhiway.com. 3600    IN  A   206.127.2.72

;; Query time: 1495 msec
;; SERVER: 206.127.2.71#53(ns1.faithhiway.com)
;; WHEN: Mon Jan 31 13:24:09 2011
;; MSG SIZE  rcvd: 127
— runlevelsix
джерело
4

У вас є 2 проблеми:

  1. Запити ns1.faithhiway.com повертають неправильні результати.

  2. Сервери імен, вказані для вашого домену, неправильні.

Ви насправді випробовуєте трохи назад. Ви перевіряєте, яка ip-адреса повертається під час запиту на ns1.faithhiway.com, але для початку слід тестувати, які сервери імен фактично повертаються для faithhiway.com. Пошук Whois та nslookup повертають такі сервери як сервери імен для faithhiway.com:

dns01.gpn.register.com

dns02.gpn.register.com

dns03.gpn.register.com

dns04.gpn.register.com

dns05.gpn.register.com

Тож вам потрібно це виправити спочатку.

— joeqwerty
джерело
по-перше - ns1 і ns2 - сервери імен, не є авторитетними для себе. Реєстрація розміщує DNS нашого сервера NS, тоді як усі інші вказують нам свої записи DNS для авторитетного відгуку. | Я шукав NS-записи для verhiway.com на всіх перерахованих вище серверах, і вони також дозволяють зареєструватися як авторитетні сервери імен домену.
— grufftech
Я неправильно зрозумів проблему тоді. Сервери імен для faithhiway.com не є nsX.faithhiway.com. nsX.faithhiway.com - це сервери імен для DNS-зон, на яких ви розміщуєте своїх клієнтів. Це так? Якщо так, то вибачте за непорозуміння.
— joeqwerty
Це правильно - Register.com є авторитетним для faithhiway.com, а nsX.faithhiway.com є відповідальними серверами імен для наших клієнтів.
— runlevelsix
(на моє власне розуміння) Якби ваш сервер доменних імен не був авторитетним, для себе це не є відносно поганою ідеєю, оскільки якщо з якихось (божевільних) причин ви втратите доступ до IP-адрес, на які вказують ці домени, у вас більше немає будь-які авторитетні сервери імен, які вказують ваші домени, куди йти, а також куди звертатися, щоб отримати оновлення, як-от нове для себе місцезнаходження ns # .yourdomain.com. у тому ж ключі, якщо я купую awesomedomain.com і вказую його на ns1 & ns2.awesomedomain.com, однак жодним кореневим серверам ніколи не було сказано, куди вказують ці два субдомена. Не повинно нічого статися?
— grufftech
Я не знаю, наскільки ця ідея погана, але я знаю безліч компаній, які розміщують власні сервери імен для їх публічного простору імен. Якщо я розумію, про що ви запитуєте, саме для цього потрібні записи клею на батьківських серверах.
— joeqwerty
2

Багато серверів ігнорують ваш TTL та кешують інформацію набагато довше, ніж слід. Найпростіший спосіб вирішити це, як правило, зв’язатися з операторами постраждалої мережі та повідомити їх. Зазвичай вони дуже хороші в тому, щоб виправити це досить швидко.

— Кріс С
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.