Справочник по сетевым протоколам

       

Примеры работы программы разрешения имен


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

match count = -1

SRI-NIC.ARPA.      26.0.0.73           10.0.0.51

A.ISI.EDU.                26.3.0.103

Эта информация определяет серверы, к которым можно обращаться за информацией. Параметр match count = -1 обозначает "удаление" этих серверов (этот параметр играет роль на последующих стадиях алгоритма разрешения).

  • Предположим, что первый запрос пришел от программы локального почтового клиента, который хочет отправить почту по адресу PVM@ISI.EDU. Почтовый клиент запрашивает записи типа MX домена ISI.EDU.
  • Программа разрешения просматривает кэш и ищет записи MX RR для ISI.EDU. Но поскольку кэш пуст, она организует опрос серверов имен, и ищет записи NS доменов ISI.EDU, EDU и корневого. Предположим, что и этот опрос ничего не дал. Тогда программа обращается за информацией к структуре SBELT — она копирует ее в структуру SLIST.
  • Теперь программа разрешения должна выбрать один из трех адресов серверов имен. Поскольку сеть локального хоста 26.х.х.х, выбор делается между 26.0.0.73 и 26.3.0.103 (как правило, берется первый, по порядку следования, адрес). Затем по выбранному адресу отправляется запрос (рис.26):


  • Header
    Question
    Answer
    Authority
    Additional

    OPCODE=SQUERY
    QNAME=ISI.EDU, QCLASS=IN, QTYPE=MX
    <emply>
    <emply>
    <emply>

    Рис. 26. формат DNS-сообщения запроса серверов MX и значения полей сообщения запроса

  • Если ответ не приходит через определенный промежуток времени, запрос отправляется на другой адрес (при этом запрос может быть отправлен и по ранее использованному адресу).

  • Предположим, что от SRI-NIC. ARPA получен ответ (рис. 27):


    Header
    Question
    Answer
    Authority
    Additional


    OPCODE=SQUERY, RESPONCE
    QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX
    <emply>
    ISI.EDU.                   172800     IN   NS      VAXA.ISI.EDU.
                                                            NS       A.ISI.EDU.
                                                            NS       VENERA.ISI.EDU.
    VAXA.ISI.EDU.       17280              A         10.2.0.27                                  17280              A         128.90.33
    VENERA.ISI.EDU    17280              A          10.1.0.52
                                      17280              A          128.9.0.32
    A.ISI.EDU                  17280              A           26.3.0.103
    <


    /p>

    Рис. 27. Формат DNS- сообщения ответа на запрос серверов MX от неуполномоченного сервера и значения полей сообщения ответа
    Программа разрешения кэширует ответ и на его основе строит новый SLIST, который будет выглядеть следующим образом:
    match count = 3
    A.ISI.EDU.              26.3.0.103
    VAXA.ISI.EDU.     10.2.0.27          128.9.0.33
    VENERA.ISI.EDU. 10.1.0.52         128.9.0.32
    Теперь программа разрешения делает запрос по искомому типу MX. Ответ будет выглядеть примерно так, как показано на рис.28.
    После получения ответа, программа разрешения добавляет эту информацию в кэш и возвращает MX RR клиенту.


    Header
    Question
    Answer
    Authority
    Additional


    OPCODE=SQUERY, RESPONCE, AA
    QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX
    <emply>
    ISI.EDU.                                MX   10  VENERA.ISI.EDU.
                                                 MX    20  VAXA.ISI.EDU
    VAXA.ISI.EDU.       17280      A              10.2.0.27                                 17280       A              128.90.33
    VENERA.ISI.EDU   17280      A              10.1.0.52
                                     17280       A              128.9.0.32
    <

    Содержание раздела