Отправить запись CNAME как ответ на запрос DNS CNAME - PullRequest
Новая
       12

Отправить запись CNAME как ответ на запрос DNS CNAME

0 голосов
/ 21 октября 2019

Я хочу ответить на запрос CNAME на моем DNS-сервере node.js, и я хочу поместить свой раздел ответа в буфер ответа. Я попробовал этот буфер для секции ответа и проверил это с помощью модуля dig в Windows и получил этот ответ: 

    ;; Got bad packet: bad label type
    53 bytes
    0d c4 85 80 00 01 00 01 00 00 00 00 04 74 65 73          .............tes
    74 03 63 6f 6d 00 00 05 00 01 c0 0c 00 05 00 01          t.com...........
    00 00 00 00 00 0a 73 65 63 6f 6e 64 54 65 73 74          ......secondTest
    03 63 6f 6d 00                                           .com.

Я отправил этот буфер клиенту как секцию ответа: 

[170,254,133,128,0,1,0,1,0,0,0,0,4,116,101,115,116,3,99,111,109,0,0,5,0,1,192,12,0,5,0,1,0,0,0,0,0,10,115,101,99,111,110,100,84,101,115,116,3,99,111,109,0]

Я не могу понять, что с этим не так?

1 Ответ

0 голосов
/ 22 октября 2019

Если вы посмотрите на исходный код dig на https://salsa.debian.org/dns-team/bind9/blob/debian/master/lib/dns/name.c, вы увидите, что ошибка «неверный тип метки» равна DNS_R_BADLABELTYPE и возникает, только если байт имеет значение 91 10 или любойзначение между 64 10 включительно и 192 10 , поскольку все они обозначают проблемы при кодировании имени.

Из вашего буфера:

  • 0d c4, 16-битный идентификатор для идентификации сообщения
  • 85 80 равен 1 0000 1 0 1 1 000 0000, что означает:
    • 1: сообщение является ответом
    • 0000: стандартный запрос
    • 1: AA, достоверный ответ
    • 0: TC, НЕ усекается
    • 1: RD, требуемая рекурсия
    • 1: RA, возможна рекурсия
    • 000: Z, должны быть нули
    • 0000: RCODE, без ошибок
  • 00 01 QDCOUNT, 1 запись в разделе вопросов
  • 00 01 ANCOUNT, 1 запись в разделе ответов
  • 00 00 NSCOUNT, 0 записей в разделе полномочий
  • 00 00 ARCOUNT, 0 записей в дополнительном разделе

Теперь вопрос:

  • 04 метка из 4 байтов
  • 74 65 73 74, что составляет test
  • 03 метка 3 байта
  • 63 6f 6d, что составляет com
  • 00 метка 0 байт, то есть root
  • 00 05 тип, CNAME
  • 00 01 класс, IN

И теперь мы входим в раздел ответа:

  • c0 0c означаетуказатель (первый байт имеет 2 первых установленных бита) на позицию 0c, что составляет 13 10 . В этой позиции мы снова находим test.com как 74 65 73 74 03 63 6f 6d 00
  • 00 05 тип, CNAME
  • 00 01 класс, IN,
  • 00 00 00 00 TTL, 0
  • 00 0a RDLENGTH, размер следующих данных, 10 байтов
  • для типа записи CNAME, RDATA после значения RDLENGTH снова является именем
  • , поэтому 10 байтов, которые нужно принять во внимание, теперь 73 65 63 6f 6e 64 54 65 73 74, первые 1 или 2 байта должны быть размером или указателем, но 73 16 равен 115 10 ,следовательно, вы попадаете в ситуацию, описанную сверху, и это приводит к сообщению об ошибке, поскольку байт начинается с 01 2 , а RFC 1035 четко говорит: «(комбинации 10 и 01 зарезервированы для будущего использования.)

Если вы хотите test.com. 0 IN CNAME secondTest.com, это должно привести к следующему буферу (без сжатия имени): 04 74 65 73 74 03 63 6f 6d 00 00 05 00 01 00 00 00 00 00 10 0a 73 65 63 6f 6e 64 74 65 73 74 03 63 6f 6d 00

, так что на самом деле вам нужно заменить 0,10,115,101,99,111,110,100,84,101,115,116,3,99,111,109,0 на 0,16,10,115,101,99,111,110,100,116,101,115,116,3,99,111,109,0

То есть вы пропускаете первый 16 байт. (А разница 84 против 116 позже, если вы хотите T или t в первом т secondTest)

...