<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 5/10/2021 12:38 PM, Tony Finch
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:256441c6-1c81-3b4e-a019-4a50e165dfde@dotat.at">
      <pre class="moz-quote-pre" wrap="">Dan Egli <a class="moz-txt-link-rfc2396E" href="mailto:dan@newideatest.site"><dan@newideatest.site></a> wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">
Still not working for me. The dig doesn't report anything, and I don't HAVE a
keyfile since i'm using inline signing. Or does inline signing still require a
key to be generated?
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Yes, you need to do your own key management with inline-signing using
dnssec-keygen. The new dnssec-policy feature can do automatic key
management for you.

Tony.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>So, I updated the settings. Now I have keyfiles generated by
      bind, as well as a binary .zone.signed in addition to the plain
      text .zone which has no DNSSEC information at all in it. I ran the
      signing routine and bind said it was signed good. So I obtained
      the DS and put in the registrar. Now I am getting SERVFAIL errors
      whenever I try to query my zone from another name server. Here's
      what I did:</p>
    <p>#dig newideatest.site dnskey | dnssec-dsfromkey -2 -f -
      newideatest.site<br>
      newideatest.site. IN DS 49236 13 2 <LONG HASH></p>
    <p>Ok. Copy the long hash to the Registrar, plug it in. Check, done
      that.</p>
    <p> # dig mx newideatest.site @8.8.4.4<br>
      <br>
      ; <<>> DiG 9.16.15 <<>> mx
      newideatest.site @8.8.4.4<br>
      ;; global options: +cmd<br>
      ;; Got answer:<br>
      ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id:
      631<br>
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL:
      1<br>
      <br>
      ;; OPT PSEUDOSECTION:<br>
      ; EDNS: version: 0, flags:; udp: 512<br>
      ;; QUESTION SECTION:<br>
      ;newideatest.site.              IN      MX<br>
      <br>
      ;; Query time: 50 msec<br>
      ;; SERVER: 8.8.4.4#53(8.8.4.4)<br>
      ;; WHEN: Sat May 15 18:12:44 MDT 2021<br>
      ;; MSG SIZE  rcvd: 45<br>
    </p>
    <p>ServFail?! WHAT?  So I go to DNSVIZ and run their test. <br>
    </p>
    <div class="errors">
      <h5 class="notice-state-active">Errors <span class="count">(9)</span></h5>
      <div style="display: block;">
        <ul>
          <li>newideatest.site/A: No RRSIG covering the RRset was
            returned in the response. (31.220.30.73, 45.77.29.133,
            103.6.87.125, 119.252.20.56, 2001:19f0:7001:381::3,
            2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e,
            2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN)</li>
          <li>newideatest.site/AAAA: No RRSIG covering the RRset was
            returned in the response. (31.220.30.73, 45.77.29.133,
            103.6.87.125, 119.252.20.56, 2001:19f0:7001:381::3,
            2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e,
            2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN)</li>
          <li>newideatest.site/DNSKEY (alg 13, id 49236): No RRSIG
            covering the RRset was returned in the response.
            (31.220.30.73, 45.77.29.133, 103.6.87.125, 119.252.20.56,
            2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5,
            2403:2500:4000::f3e, 2a04:bdc7:100:1b::3,
            UDP_-_EDNS0_4096_D_KN, UDP_-_EDNS0_512_D_KN)</li>
          <li>newideatest.site/MX: No RRSIG covering the RRset was
            returned in the response. (31.220.30.73, 45.77.29.133,
            103.6.87.125, 119.252.20.56, 2001:19f0:7001:381::3,
            2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e,
            2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN,
            UDP_-_EDNS0_512_D_KN)</li>
          <li>newideatest.site/NS: No RRSIG covering the RRset was
            returned in the response. (31.220.30.73, 45.77.29.133,
            103.6.87.125, 119.252.20.56, 2001:19f0:7001:381::3,
            2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e,
            2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN)</li>
          <li>newideatest.site/SOA: No RRSIG covering the RRset was
            returned in the response. (31.220.30.73, 45.77.29.133,
            103.6.87.125, 119.252.20.56, 2001:19f0:7001:381::3,
            2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e,
            2a04:bdc7:100:1b::3, TCP_-_EDNS0_4096_D_N,
            UDP_-_EDNS0_4096_D_KN, UDP_-_EDNS0_4096_D_KN_0x20)</li>
          <li>newideatest.site/TXT: No RRSIG covering the RRset was
            returned in the response. (31.220.30.73, 45.77.29.133,
            103.6.87.125, 119.252.20.56, 2001:19f0:7001:381::3,
            2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e,
            2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN)</li>
          <li>site to newideatest.site: No valid RRSIGs made by a key
            corresponding to a DS RR were found covering the DNSKEY
            RRset, resulting in no secure entry point (SEP) into the
            zone. (31.220.30.73, 45.77.29.133, 103.6.87.125,
            119.252.20.56, 2001:19f0:7001:381::3,
            2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e,
            2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN,
            UDP_-_EDNS0_512_D_KN)</li>
          <li>site to newideatest.site: The DS RRset for the zone
            included algorithm 13 (ECDSAP256SHA256), but no DS RR
            matched a DNSKEY with algorithm 13 that signs the zone's
            DNSKEY RRset. (31.220.30.73, 45.77.29.133, 103.6.87.125,
            119.252.20.56, 2001:19f0:7001:381::3,
            2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e,
            2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN,
            UDP_-_EDNS0_512_D_KN)</li>
        </ul>
      </div>
    </div>
    <div class="warnings">
      <h5 class="notice-state-active">Warnings <span class="count">(13)</span></h5>
      <div style="display: block;">
        <ul>
          <li>newideatest.site/A: The server responded with no OPT
            record, rather than with RCODE FORMERR. (31.220.30.73,
            45.77.29.133, 103.6.87.125, 119.252.20.56,
            2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5,
            2403:2500:4000::f3e, 2a04:bdc7:100:1b::3,
            UDP_-_EDNS0_4096_D_KN)</li>
          <li>newideatest.site/AAAA: The server responded with no OPT
            record, rather than with RCODE FORMERR. (31.220.30.73,
            45.77.29.133, 103.6.87.125, 119.252.20.56,
            2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5,
            2403:2500:4000::f3e, 2a04:bdc7:100:1b::3,
            UDP_-_EDNS0_4096_D_KN)</li>
          <li>newideatest.site/DNSKEY (alg 13, id 49236): The server
            responded with no OPT record, rather than with RCODE
            FORMERR. (31.220.30.73, 45.77.29.133, 103.6.87.125,
            119.252.20.56, 2001:19f0:7001:381::3,
            2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e,
            2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN,
            UDP_-_EDNS0_512_D_KN)</li>
          <li>newideatest.site/MX: The server responded with no OPT
            record, rather than with RCODE FORMERR. (31.220.30.73,
            45.77.29.133, 103.6.87.125, 119.252.20.56,
            2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5,
            2403:2500:4000::f3e, 2a04:bdc7:100:1b::3,
            UDP_-_EDNS0_4096_D_KN, UDP_-_EDNS0_512_D_KN)</li>
          <li>newideatest.site/NS: The server responded with no OPT
            record, rather than with RCODE FORMERR. (31.220.30.73,
            45.77.29.133, 103.6.87.125, 119.252.20.56,
            2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5,
            2403:2500:4000::f3e, 2a04:bdc7:100:1b::3,
            UDP_-_EDNS0_4096_D_KN)</li>
          <li>newideatest.site/SOA: The server responded with no OPT
            record, rather than with RCODE FORMERR. (31.220.30.73,
            45.77.29.133, 103.6.87.125, 119.252.20.56,
            2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5,
            2403:2500:4000::f3e, 2a04:bdc7:100:1b::3,
            TCP_-_EDNS0_4096_D_N, UDP_-_EDNS0_4096_D_KN,
            UDP_-_EDNS0_4096_D_KN_0x20)</li>
          <li>newideatest.site/TXT: The server responded with no OPT
            record, rather than with RCODE FORMERR. (31.220.30.73,
            45.77.29.133, 103.6.87.125, 119.252.20.56,
            2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5,
            2403:2500:4000::f3e, 2a04:bdc7:100:1b::3,
            UDP_-_EDNS0_4096_D_KN)</li>
          <li>site to newideatest.site: The following NS name(s) were
            found in the authoritative NS RRset, but not in the
            delegation NS RRset (i.e., in the site zone):
            jupiter.newideatest.site</li>
          <li>site to newideatest.site: The following NS name(s) were
            found in the delegation NS RRset (i.e., in the site zone),
            but not in the authoritative NS RRset:
            jupiter.eglifamily.name</li>
          <li>site/DS (alg 8, id 51676): DNSSEC specification prohibits
            signing with DS records that use digest algorithm 1 (SHA-1).</li>
          <li>site/DS (alg 8, id 51676): DNSSEC specification prohibits
            signing with DS records that use digest algorithm 1 (SHA-1).</li>
          <li>site/DS (alg 8, id 51676): DS records with digest type 1
            (SHA-1) are ignored when DS records with digest type 2
            (SHA-256) exist in the same RRset.</li>
          <li>site/DS (alg 8, id 51676): DS records with digest type 1
            (SHA-1) are ignored when DS records with digest type 2
            (SHA-256) exist in the same RRset.</li>
        </ul>
        <p>So, what am I doing wrong? Here's the zone statement for the
          newideatest.site zone in my named.conf:</p>
        <p>        zone "newideatest.site" {<br>
                          type master;<br>
                          file "pri/newideatest.zone";<br>
                          allow-query { any; };<br>
                          allow-transfer {<br>
                            108.61.224.67; 116.203.6.3; 107.191.99.111;
          185.22.172.112; 103.6.87.125; 192.184.93.99; 119.252.20.56;
          31.220.30.73; 185.34.136.178; 185.136.176.247; 45.77.29.133;
          116.203.0.64; 167.88.161.228; 199.195.249.208; 104.244.78.122;
          2605:6400:30:fd6e::3; 2605:6400:10:65::3; 2605:6400:20:d5e::3;
          2a01:4f8:1c0c:8122::3; 2001:19f0:7001:381::3;
          2a06:fdc0:fade:2f7::1; 2a00:dcc7:d3ff:88b2::1;
          2a04:bdc7:100:1b::3; 2401:1400:1:1201::1:7853:1a5;
          2604:180:1:92a::3; 2403:2500:4000::f3e;
          2a00:1838:20:2::cd5e:68e9; 2604:180:2:4cf::3;
          2a01:4f8:1c0c:8115::3; 2001:19f0:6400:8642::3;<br>
                          };<br>
                          allow-update { trusted; };<br>
                          key-directory "/var/bind/pri/keys";<br>
                          inline-signing yes;<br>
                          dnssec-policy default;<br>
                  };<br>
          };<br>
        </p>
        <p>Help? If you have errors reaching me, try
          <a class="moz-txt-link-abbreviated" href="mailto:dan@eglifamily.name">dan@eglifamily.name</a>, as it doesn't seem to be having issues.<br>
        </p>
      </div>
    </div>
    <pre class="moz-signature" cols="72">--Dan Egli
From my Test Server</pre>
  </body>
</html>