Agenda: dns-dig-hands-on-2-vRU.txt

File dns-dig-hands-on-2-vRU.txt, 19.5 KB (added by trac, 5 years ago)
Line 
1DNS - лабораторная работа: dig, часть 2
2
3Отладка DNS-серверов при помощи dig +norec
4
5Вам НЕ обязательно иметь права администратора для выполнения этого
6упражнения.  ЗАМЕЧАНИЕ: добавлять точку в конце каждого имени
7хоста является очень хорошей идеей - это предотвращает использование
8домена по умолчанию из `/etc/resolv.conf` в каждом запросе.
9
10Такой пример: проверка __www.tiscali.co.uk.__
11
12Для этой лабораторной, нам придется временно поменять ваш DNS-сервер
13по умолчанию, сконфигурированный в /etc/resolv.conf, на 10.20.0.254,
14примерно так:
15
16    # ee /etc/resolv.conf
17
18    ... и укажите DNS-сервер:
19
20    nameserver 10.20.0.254
21
22    Сохраните файл и выйдите из редактора.
23
24    Замечание: вам необходимо это сделать, в противном случае вы не сможете
25    осуществлять DNS-запросы в сети Интернет!
26   
271. Сделайте запрос, начиная с корневого DNS-сервера
28
29Корневые сервера именуются `[a-m].root-servers.net.` - выберите любой для начала.
30
31    $ dig +norec @f.root-servers.net www.tiscali.co.uk. a
32
33; <<>> DiG 9.7.2-P3 <<>> +norec @a.root-servers.net. www.tiscali.co.uk. a
34; (2 servers found)
35;; global options: +cmd
36;; Got answer:
37;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8712
38;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 11, ADDITIONAL: 14
39
40;; QUESTION SECTION:
41;www.tiscali.co.uk.     IN  A
42
43;; AUTHORITY SECTION:
44uk.         172800  IN  NS  ns1.nic.uk.
45uk.         172800  IN  NS  ns2.nic.uk.
46uk.         172800  IN  NS  ns3.nic.uk.
47uk.         172800  IN  NS  ns4.nic.uk.
48uk.         172800  IN  NS  ns5.nic.uk.
49uk.         172800  IN  NS  ns6.nic.uk.
50uk.         172800  IN  NS  ns7.nic.uk.
51uk.         172800  IN  NS  nsa.nic.uk.
52uk.         172800  IN  NS  nsb.nic.uk.
53uk.         172800  IN  NS  nsc.nic.uk.
54uk.         172800  IN  NS  nsd.nic.uk.
55
56;; ADDITIONAL SECTION:
57ns1.nic.uk.     172800  IN  AAAA    2a01:40:1001:35::2
58ns1.nic.uk.     172800  IN  A   195.66.240.130
59ns2.nic.uk.     172800  IN  A   217.79.164.131
60ns3.nic.uk.     172800  IN  A   213.219.13.131
61ns4.nic.uk.     172800  IN  AAAA    2001:630:181:35::83
62ns4.nic.uk.     172800  IN  A   194.83.244.131
63ns5.nic.uk.     172800  IN  A   213.246.167.131
64ns6.nic.uk.     172800  IN  A   213.248.254.130
65ns7.nic.uk.     172800  IN  A   212.121.40.130
66nsa.nic.uk.     172800  IN  AAAA    2001:502:ad09::3
67nsa.nic.uk.     172800  IN  A   156.154.100.3
68nsb.nic.uk.     172800  IN  A   156.154.101.3
69nsc.nic.uk.     172800  IN  A   156.154.102.3
70nsd.nic.uk.     172800  IN  A   156.154.103.3
71
72;; Query time: 8 msec
73;; SERVER: 198.41.0.4#53(198.41.0.4)
74;; WHEN: Tue Feb 15 15:53:13 2011
75;; MSG SIZE  rcvd: 497
76
77
78Замечание: мы получили в ответ только записи NS (плюс кое-какую имеющую
79к ним отношение информацию - записи A, относящиеся к этим DNS-серверам).
80Это - ССЫЛКА (REFERRAL).
81
82Теоретически нам следовало бы повторить этот запрос для `b.root-servers.net`,
83`c.root-servers.net` ... и убедиться в идентичности ответов.  Иногда вы
84_можете_ найти несоответствия между корневыми серверами, но такое случается
85весьма редко.
86
872. Обратите внимание на одиннадцать DNS-серверов в ответе
88---------------------------------------------------------
89
90(Помните, что имена в DNS не зависят от регистра букв.  Также, мы получим
91имена в ответе в случайном порядке;  это неважно, потому что мы собираемся
92запросить каждый из них, так или иначе)
93
94  ns1.nic.uk.
95  ns2.nic.uk.
96  ns3.nic.uk.
97  ns4.nic.uk.
98  ns5.nic.uk.
99  ns6.nic.uk.
100  ns7.nic.uk.
101  nsa.nic.uk.
102  nsb.nic.uk.
103  nsc.nic.uk.
104  nsd.nic.uk.
105
1063. Повсторите запрос для каждой из записей NS по очереди
107--------------------------------------------------------
108
109    $ dig +norec @ns1.nic.uk. www.tiscali.co.uk. a
110
111    ; <<>> DiG 9.7.2-P3 <<>> +norec @ns1.nic.uk. www.tiscali.co.uk. a
112    ; (1 server found)
113    ;; global options:  printcmd
114    ;; Got answer:
115    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28452
116    ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
117
118    ;; QUESTION SECTION:
119    ;www.tiscali.co.uk.             IN      A
120
121    ;; AUTHORITY SECTION:
122    tiscali.co.uk.          172800  IN      NS      ns0.as9105.com.
123    tiscali.co.uk.          172800  IN      NS      ns0.tiscali.co.uk.
124
125    ;; ADDITIONAL SECTION:
126    ns0.tiscali.co.uk.      172800  IN      A       212.74.114.132
127
128    ;; Query time: 20 msec
129    ;; SERVER: 195.66.240.130#53(195.66.240.130)
130    ;; WHEN: Mon May 16 12:37:23 2005
131    ;; MSG SIZE  rcvd: 97
132
133
134    $ dig +norec @ns2.nic.uk. www.tiscali.co.uk. a
135    ...
136
137    $ dig +norec @ns3.nic.uk. www.tiscali.co.uk. a
138    ...
139    ... etc
140
141*Убедитесь, что результаты соответствуют друг другу!*
142
143Замечание: если какой-то сервер авторитетен и для домена и для поддомена,
144он немедленно вернет результат для поддомена.  Это ожидаемо.  В этом примере,
145одни и те же сервера являются авторитетными и для `.uk`, и для `.co.uk`,
146так что они немедленно могут сослаться на сервера для `tiscali.co.uk`.
147Таким образом, мы спустимся вниз на два уровня иерархии DNS за один
148запрос.
149
150Вы можете увидеть, что мы опять получаем делегирование, на этот раз к
151двум другим DNS-серверам:
152
153>     ns0.as9105.com
154>     ns0.tiscali.co.uk
155
1564. Продолжайте повторять запрос ко всем записям NS найденным на шаге 3
157----------------------------------------------------------------------
158
159    $ dig +norec @ns0.tiscali.co.uk. www.tiscali.co.uk. a
160
161    ; <<>> DiG 9.7.2-P3 <<>> +norec @ns0.tiscali.co.uk. www.tiscali.co.uk. a
162    ; (1 server found)
163    ;; global options: +cmd
164    ;; Got answer:
165    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52841
166    ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
167   
168    ;; QUESTION SECTION:
169    ;www.tiscali.co.uk.     IN  A
170   
171    ;; ANSWER SECTION:
172    www.tiscali.co.uk.  300 IN  A   212.74.99.30
173   
174    ;; AUTHORITY SECTION:
175    tiscali.co.uk.      3600    IN  NS  ns0.tiscali.co.uk.
176    tiscali.co.uk.      3600    IN  NS  ns0.as9105.com.
177   
178    ;; ADDITIONAL SECTION:
179    ns0.as9105.com.     604800  IN  A   212.139.129.130
180    ns0.tiscali.co.uk.  604800  IN  A   212.74.114.132
181   
182    ;; Query time: 322 msec
183    ;; SERVER: 212.74.114.132#53(212.74.114.132)
184    ;; WHEN: Tue Feb 15 16:01:04 2011
185    ;; MSG SIZE  rcvd: 129
186
187
188    $ dig +norec @ns0.as9105.com. www.tiscali.co.uk. a
189    ...
190    ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
191    ...
192    ;; ANSWER SECTION:
193    www.tiscali.co.uk.  300 IN  A   212.74.99.30
194
195
196На этот раз, вместо получения очередного делегирования, мы нашли тот ответ,
197который искали.  Обратите внимание на то, что оба DNS-сервера дают авторитетные
198ответы (`flags: aa`), и что результаты совпадают.  Также обратите внимание
199на то, что 'AUTHORITY SECTION' в ответе показывает *тот же* список DNS-серверов,
200что мы использовали в наших запросах.  (Этот второй набор записей NS находится
201на самом авторитетном сервере, а не является делегированием на уровень выше)
202
203Совет: попробуйте выполнить следующий запрос!
204
205    $ dig +nssearch tiscali.co.uk
206
2075. Памятка
208----------
209
210*   Все ли серверы были доступны?
211*   Принадлежали ли по крайней мере два сервера разным подсетям?
212*   Дали ли все серверы либо ссылку, либо AA (авторитеный ответ)?
213*   Были ли все ответы одинаковыми?
214*   Были ли разумными значения TTL?
215*   Совпадает ли окончательный список сервером в AUTHORITY SECTION со списком
216    серверов в делегации?
217
2186. Теперь проверьте сами записи NS!
219-----------------------------------
220
221Обратите внимание на что, что каждая запись NS указывает на хост,
222а не на IP адрес.  (Запись NS не может указывать на IP адрес,
223это не будет работать)
224
225Однако, когда мы выполняли команду вроде `dig @ns0.as9105.com ...`, мы
226полагались на то, что dig переводил имя в правильный IP адрес.
227Фактически, мы делали два запроса:
228
229- dig спрашивает IP адрес имени ns0.as9105.com, осуществляя рекурсивный
230  запрос используя DNS сервер, сконфигурированный в /etc/resolv.conf
231 
232- после того как dig получил IP адрес DNS сервера, он может послать
233  запрос к этому серверу
234
235Таким образом, вам нужно начать сначала и проверить каждую запись NS,
236начиная опять от корня, точно так же как и раньше!  Это утомительно,
237и обычно корневые сервера предоставляют правильную информацию.
238Тем не менее, стоит проверить записи NS уровня страны, а также ваши
239собственные записи NS.
240
241Пример: проверка ns0.as9105.com
242
243    $ dig +norec @a.root-servers.net. ns0.as9105.com. a
244    ... отсылает к [a-m].gtld-servers.net.
245
246    $ dig +norec @a.gtld-servers.net. ns0.as9105.com. a
247    ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
248    ;; ANSWER SECTION:
249    ns0.as9105.com.         172800  IN      A       212.139.129.130     <====
250
251    ;; AUTHORITY SECTION:
252    as9105.com.             172800  IN      NS      ns0.as9105.com.
253    as9105.com.             172800  IN      NS      ns0.tiscali.co.uk.
254
255Обратите внимание, что мы получили ответ - но это не авторитетный ответ!
256(Отсутствует 'aa', и машина, которую мы запросили, не попала в список
257машин, перечисленных в разделе авторитетов)
258
259Это не является ошибкой, если ответ правильный - это называется "запись-связка",
260которые мы объясним позднее - но нам тем не менее нужно продолжать спускаться
261далее по иерархии для нахождения настоящего авторитетного источника:
262
263    $ dig +norec @ns0.as9105.com. ns0.as9105.com. a
264    ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
265
266    ;; ANSWER SECTION:
267    ns0.as9105.com.         2419200 IN      A       212.139.129.130     <====
268
269    ;; AUTHORITY SECTION:
270    as9105.com.             600     IN      NS      ns0.tiscali.co.uk.
271    as9105.com.             600     IN      NS      ns0.as9105.com.
272
273    ;; ADDITIONAL SECTION:
274    ns0.tiscali.co.uk.      2419200 IN      A       212.74.114.132
275
276
277    $ dig +norec @ns0.tiscali.co.uk. ns0.as9105.com. a
278    ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
279
280    ;; ANSWER SECTION:
281    ns0.as9105.com.         2419200 IN      A       212.139.129.130     <====
282
283    ;; AUTHORITY SECTION:
284    as9105.com.             600     IN      NS      ns0.tiscali.co.uk.
285    as9105.com.             600     IN      NS      ns0.as9105.com.
286
287    ;; ADDITIONAL SECTION:
288    ns0.tiscali.co.uk.      2419200 IN      A       212.74.114.132
289
290Теперь мы проверяем:
291
292*   Все ли ответы совпадают?  (Да: 212.139.129.130 от `a.gtld-servers.net`
293    и от авторитетных серверов)
294*   Совпало ли делегирование с записями NS от авторитеных серверов?
295    (Да: делегирование было на `ns0.as9105.com` и на `ns0.tiscali.co.uk`,
296    и те же записи были перечислены в разделе авторитета в последнем
297    ответе
298
299Значение кода статуса НЕТ ОШИБКИ (NOERROR)
300------------------------------------------
301
302Возможно, вы обратили внимание на поле "status:" в выводе dig:
303
304status: NXDOMAIN
305или
306status: NOERROR
307
308NXDOMAIN означает "домен не существует".  Это означает, "извините,
309вообще нет никаких данных для данного ИМЕНИ".  Например:
310
311    $ dig +norec @ns0.tiscali.co.uk. wibble.tiscali.co.uk. a
312
313... вернет NXDOMAIN.  Никаких записей для "wibble" в домене
314tiscali.co.uk нет.  Нет записи A, нет записи AAAA, и т.д...
315
316Так вот, вы возможно также заметили, что раздел ответа может
317содержать 0 ответов, но тем не менее, запрошенный сервер возвращает
318NOERROR, а не NXDOMAIN.
319
320Как такое может быть?
321
322Скажем например, что мы хотим знать IP адрес для
323www.tiscali.co.uk:
324
325    $ dig +norec @ns0.tiscali.co.uk. www.tiscali.co.uk. a
326
327Пока все нормально - вы увидите:
328
329status: NOERROR
330ANSWER: 1
331
332Теперь, давайте спросим о записи *другого* типа, чем A:
333
334    $ dig +norec @ns0.tiscali.co.uk. www.tiscali.co.uk. txt
335
336Обратите внимание, что мы спросили про запись типа TXT для имени
337"www.tiscali.co.uk."
338
339Что нам ответят?
340
341status: NOERROR
342ANSWER: 0
343
344Как такое может быть?
345
346NOERROR в данном случае означает "извините, нет данных для данной
347комбинации имени и типа".  Ага!  Тут нам сказали, что не существует
348записи TXT для www.tiscali.co.uk - но могут существовать данные для
349других типов но с тем же именем.
350
351В самом деле, мы знаем из предыдущего, что:
352
353        $ dig +norec @ns0.tiscali.co.uk. www.tiscali.co.uk. a
354
355... вернет нам IP адрес имени www.tiscali.co.uk.
356
357Таким образом, несуществующее имя (NXDOMAIN) или пустой ответ (NOERROR,
358ANSWER: 0) *все еще* является ответом, и нам нужно его запомнить (кэшировать),
359как мы увидим в дальнейшем.
360
361Отрицательные ответы
362--------------------
363
364Несуществование записи также является важной информацией.
365Ответ вы получите будет выглядеть примерно так:
366
367    $ dig +norec @ns0.tiscali.co.uk. wibble.tiscali.co.uk. a
368    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51165
369    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
370
371    ;; AUTHORITY SECTION:
372    tiscali.co.uk. 3600 IN  SOA ns0.tiscali.co.uk. hostmaster.talktalkplc.com.
373    2011012703 10800 3600 604800 3600
374
375
376Флаг AA установлен, но в ответе ничего нет, кроме записи SOA.
377Параметры внутри SOA используются для определения того, как
378долго отрицательный ответ может кэшироваться.
379
380Значение флагов (из RFC 1034/RFC 1035)
381--------------------------------------
382
383    QR              Однобитное поле, которое определяет, является ли данное
384                    сообщение запросом (0) или ответом (1).
385
386    AA              Авторитетный ответ - этот бит имеет смысл в ответах,
387                    и указывает, что ответивший сервер является авторитетным
388                    для доменного имени в разделе вопроса.
389
390    RD              Желательна рекурсия - этот бит может быть установлен
391                    в запросе, и копируется в ответе.  Если RD установлен,
392                    это инструктирует сервер попытаться получить ответ
393                    рекурсивно.  Поддержка таким запросов опциональа.
394
395    RA              Рекурся доступна - этот бит может быть установлен либо
396                    сброшен в ответе, и говорит о том, поддерживает ли данный
397                    сервер рекурсивные запросы.
398
399Наряду с отсутствием флага 'AA', хороший способ заметить кэшированные
400ответы - повторить запрос несколько раз и посмотреть, уменьшается ли
401значение TTL.
402
403    $ dig psg.com.
404    ;; ANSWER SECTION:
405    psg.com.                14397   IN      A       147.28.0.62
406                            ^^^^^
407    $ dig psg.com.
408    ;; ANSWER SECTION:
409    psg.com.                14384   IN      A       147.28.0.62
410                            ^^^^^
411
412
413Другие параметры dig
414--------------------
415
416Другие параметры команды dig, которые вы может быть захотите попробовать -
417воспользуйтесь документацией для определения того, что они делают!
418
419dig +tcp
420dig +trace
421
422Попробуйте также другие параметры, которые вы найдете в документации!
423
424
425Восстановление конфигурации
426---------------------------
427
428Наконец, когда вы закончили с этой лабораторной работой, не
429забудьте восстановить ваш /etc/resolv.conf:
430
431nameserver 10.20.0.230
432