Проблемы с распространением 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

Спикизи:

# 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 г.):

Прежде всего, я прошу прощения за длину как исходного вопроса, так и этого обновления. Я обдумывал удаление некоторых излишков из исходного поста, но на случай, если эта проблема и ее решение будут полезны кому-то еще в будущем, я просто оставлю все как есть.

Во всяком случае, я провел еще несколько исследований по этой проблеме, и обнаружил следующее интересное событие. При проверке склеенных записей для faithhiway.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 для faithhiway.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.