ALT Linux Bugzilla – #39440

Created attachment 9082 [details]
MS DNS RFC 2845 violation

Патч включающий доп. обработку ошибки, в случае успешного выполнения через GSSAPI.

В сизиф отправлена таска:
#263464 BUILDING #1 [locked] [test-only] sisyphus bind.git=9.11.25-alt3

Данное исправление хотелось бы также бекпортировать в p9. Сейчас там bind-utils-9.11.22, в то время как в сизифе уже bind-utils-9.11.25. Как лучше поступить? Планировалось ли это обноевление в p9?

Данная проблема у меня воспроизвелась как известная, блуждающая бага:
- https://lists.samba.org/archive/samba/2018-November/219362.html
- https://access.redhat.com/solutions/4437901
- https://lists.samba.org/archive/samba/2019-August/225179.html

которую решают всякими костылями вида:
# cat /usr/local/samba/etc/smb.conf
> dns update command = /usr/sbin/samba_dnsupdate --use-samba-tool

________

Кроме того, обнаружена похожая проблема другой природы:
DNS update using BIND9_DLZ fail using MIT KRB5 with "Request is a replay"
https://bugzilla.samba.org/show_bug.cgi?id=13066

Там решение выглядит так:

# echo 'KRB5RCACHETYPE="none"' >> /etc/sysconfig/bind
# systemctl restart bind

Но уже тема для bind-control.

Спасибо за репорт.

Очевидно, что нарушать RFC - это плохо.
Не знаю почему ISC не смогла повлиять на этот MS DNS(что это?).
Менять в этом случае дефолтное поведение категорически нет, так как на это могут быть завязаны пользователи.

Как вариант, предлагаю добавить кастомную опцию, чтобы быть совместимыми с этим DNS сервером, естественно, через апстрим.

Еще одно обсуждение:
https://bugzilla.redhat.com/show_bug.cgi?id=1394320

Маловлияющий фактор, но просто обратите внимание, что никто не сделал этого в других дистрибутивах, почему?

В действительности нигде не предъявлено четких доказательств, что происходит на самом деле(gdb).

(Ответ для Stanislav Levin на комментарий #4)
...
> Маловлияющий фактор, но просто обратите внимание, что никто не сделал этого
> в других дистрибутивах, почему?

Из этого факта, самого по себе, ещё ничего не следует. Совершенно не стоит предполагать, что причина только в потенциальной несовместимости.

> В действительности нигде не предъявлено четких доказательств, что происходит
> на самом деле(gdb).

Причём тут gdb, как он тут поможет?

Тут всё очевидно:
https://tools.ietf.org/html/rfc2845


   4.2. TSIG on Answers

   When a server has generated a response to a signed request, it signs
   the response using the same algorithm and key.  The server MUST not
   generate a signed response to an unsigned request.  The digest
   components are:

      Request MAC
      DNS Message (response)
      TSIG Variables (response)

Смысл в том, что успешность операции передаётся в переменных. А как быть если в ответе на запрос уже был - status: NOERROR? Каким должен быть, по умолчанию ответ в переменной TSIG RDATA Error, если переменную не вернули? Если обязательно ошибка, то верна традиционная ISC Bind интерпретация RFC 2845. Но я этого не вижу явно их текста RFC.

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

Суть в следующем:
- протокол требует в переменных TSIG явный ответ в виде переменной ERROR;
- при этом в ответе и так присутствует Error: No error (0);
- но, как следует, из коментария - это не по RFC 2845 в чьей-то интерпретации.


Frame 24: 197 bytes on wire (1576 bits), 197 bytes captured (1576 bits) on interface lo, id 0
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 10.64.128.2, Dst: 10.64.128.2
Transmission Control Protocol, Src Port: 53, Dst Port: 33903, Seq: 1, Ack: 144, Len: 143
Domain Name System (response)
    Length: 141
    Transaction ID: 0x20fb
    Flags: 0xa880 Dynamic update response, No error
        1... .... .... .... = Response: Message is a response
        .010 1... .... .... = Opcode: Dynamic update (5)
        .... .0.. .... .... = Authoritative: Server is not an authority for domain
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... 1... .... = Recursion available: Server can do recursive queries
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
        .... .... ...0 .... = Non-authenticated data: Unacceptable
        .... .... .... 0000 = Reply code: No error (0)
    Zones: 1
    Prerequisites: 0
    Updates: 1
    Additional RRs: 1
    Zone
        domain.alt: type SOA, class IN
            Name: domain.alt
            [Name Length: 10]
            [Label Count: 2]
            Type: SOA (Start Of a zone of Authority) (6)
            Class: IN (0x0001)
    Updates
        dc.domain.alt: type A, class IN, addr 10.64.128.2
            Name: dc.domain.alt
            Type: A (Host Address) (1)
            Class: IN (0x0001)
            Time to live: 900 (15 minutes)
            Data length: 4
            Address: 10.64.128.2
    Additional records
        1370890395.sig-dc.domain.alt: type TSIG, class ANY
            Name: 1370890395.sig-dc.domain.alt
            Type: TSIG (Transaction Signature) (250)
            Class: ANY (0x00ff)
            Time to live: 0 (0 seconds)
            Data length: 54
            Algorithm Name: gss-tsig
            Time Signed: Dec 15, 2020 15:36:22.000000000 +04
            Fudge: 300
            MAC Size: 28
            MAC
                [Expert Info (Warning/Undecoded): No dissector for algorithm:gss-tsig]
                    [No dissector for algorithm:gss-tsig]
                    [Severity level: Warning]
                    [Group: Undecoded]
            Original Id: 8443
            Error: No error (0)
            Other Len: 0
    [Request In: 19]
    [Time: 0.282538714 seconds]

Попробую воспроизвести локально, после этого, если потребуется, попробую поговорить с апстримом.

Created attachment 9084 [details]
Лог ошибки tsig

Судя по выводу tshark, проблема может быть в самой обработке пакета.

В коде nsupdate.c имеется такой кусок:

        case ISC_R_SUCCESS:
                /*
                 * XXXSRA Waaay too much fun here.  There's no good
                 * reason why we need a TSIG here (the people who put
                 * it into the spec admitted at the time that it was
                 * not a security issue), and Windows clients don't
                 * seem to work if named complies with the spec and
                 * includes the gratuitous TSIG.  So we're in the
                 * bizarre situation of having to choose between
                 * complying with a useless requirement in the spec
                 * and interoperating.  This is nuts.  If we can
                 * confirm this behavior, we should ask the WG to
                 * consider removing the requirement for the
                 * gratuitous TSIG here.  For the moment, we ignore
                 * the TSIG -- this too is a spec violation, but it's
                 * the least insane thing to do.
                 */
#if 0
                /*
                 * Verify the signature.
                 */
                rcvmsg->state = DNS_SECTION_ANY;
                dns_message_setquerytsig(rcvmsg, NULL);
                result = dns_message_settsigkey(rcvmsg, tsigkey);
                check_result(result, "dns_message_settsigkey");
                result = dns_message_checksig(rcvmsg, NULL);
                ddebug("tsig verification: %s", dns_result_totext(result));
                check_result(result, "dns_message_checksig");
#endif /* 0 */

                send_update(&tmpzonename, &master_servers[master_inuse]);
                setzoneclass(dns_rdataclass_none);
                break;


Если его раскомментировать, то вывод выглядит так:

[root@dc nsupdate]# ./nsupdate -g /var/log/named/req 
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
dc.domain.alt.          900     IN      A       10.64.128.2

dns_message_checksig: did not expect a TSIG or SIG(0)

[root@dc nsupdate]# echo $?
1

Если раскомментировать оба патча, то поведение аналогично.

Ну, то есть вот о чём идёт речь из RFC 2845 4.2. TSIG on Answers:
"The server MUST not generate a signed response to an unsigned request."

Правда кто тут ещё чему не соответствует уже становиться не очевидно:
"So we're in the bizarre situation of having to choose between complying with a useless requirement in the spec and interoperating."

___________________

Таким образом расклад такой:
- коллективный автор nsupdate считает, что samba и другие windows-подобные сервера не соотвествуют некому стандарту (я пока не до конца понял в чем точно);
- по факту мы имеем лишний TSIG-пакет, который как бы не имеет смысла в случае GSSAPI ("did not expect a TSIG or SIG(0)");
- пакет этот игнорируется;
- но, по завершению функции dns_request_getresponse(), при вызове функции dns_tsig_verify(), на такой вот проверке:

        /*
         * If this is a response, there should be a TSIG in the query with the
         * the exception if this is a TKEY request (see RFC 3645, Section 2.2).
         */
        response = is_response(msg);
        if (response && msg->querytsig == NULL) {
                if (msg->tkey != 1) {
                        return (DNS_R_EXPECTEDTSIG);
                }
        }

- Ну, и далее всё отваливается:
; TSIG error with server: tsig verify failure

Ну, оно и логично как бы. Пакет-то пропущен. Как-то на багу похоже.

Плюс имеется опция -o в эту тему, но с ней тоже ничего не работает:

GSS-TSIG uses Kerberos credentials. Standard GSS-TSIG mode is switched on with the -g flag. A non-standards-compliant variant of GSS-TSIG used by Windows 2000 can be switched on with the -o flag.

Что с этой багой?

Работы не проводились