[dns-operations] Broken black lies implementation at ns{1..4}.sectigoweb.com (a.k.a. ns{1..4}.dnsimple.com)

Viktor Dukhovni ietf-dane at dukhovni.org
Sat Sep 17 23:08:10 UTC 2022


The nameservers in question attempt to deny the existence of TLSA
records at "_25._tcp.mx2.beheerd.nl" with a "black lies" response
whose type bitmap includes "CNAME", but in that case the correct
response would be to return the CNAME, and the NODATA response is
bogus:

    $ dig +nsid +nocmd +nocl +nottl +dnssec +norecur +nosplit +nocrypt -t tlsa _25._tcp.mx2.beheerd.nl @ns1.sectigoweb.com.
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39716
    ;; flags: qr aa ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 1232
    ; NSID: 34 34 35 6d 31 32 35 ("445m125")
    ;; QUESTION SECTION:
    ;_25._tcp.mx2.beheerd.nl. IN TLSA

    ;; AUTHORITY SECTION:
    beheerd.nl.              SOA    ns1.sectigoweb.com. admin.sectigo.com. 1647435746 86400 7200 604800 300
    _25._tcp.mx2.beheerd.nl. NSEC   \000._25._tcp.mx2.beheerd.nl. CNAME RRSIG NSEC
    beheerd.nl.              RRSIG  SOA 8 2 3600 20221127150000 20220829150000 15885 beheerd.nl. [omitted]
    _25._tcp.mx2.beheerd.nl. RRSIG  NSEC 8 5 300 20221127150000 20220829150000 15885 beheerd.nl. [omitted]

    ;; Query time: 13 msec
    ;; SERVER: 2400:cb00:2049:1::a29f:1804#53(2400:cb00:2049:1::a29f:1804)
    ;; WHEN: Sat Sep 17 22:54:03 UTC 2022
    ;; MSG SIZE  rcvd: 518

This MX host handles at least 25 domains, which may have issues
receiving mail from DANE-enabled sending MTAs.

Some resolver behaviours:

    - Forwarding the query to 8.8.8.8 correctly elicits SERVFAIL.

    - Forwarding the query to 1.1.1.1 wrongly (bug reported to
      CloudFlare 2022-08-12) incorrectly stutters the NODATA.

    - DNSViz.net also (again reported to @caseyd) presently fails to tag
      this as an error.

Does anyone know a contact at dnsimple.com who might investigate and
ultimately resolve the problem?

-- 
    Viktor.


More information about the dns-operations mailing list