• [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.':

    From local10@21:1/5 to All on Mon Mar 13 23:20:02 2023
    Mar 13, 2023, 21:42 by recoverym4n@enotuniq.net:

    Well, it was worth to check it.


    Next idea is somewhat more complicated.

    Install tcpdump.
    Run:
    tcpdump -pni any -s0 -w /tmp/dns.pcap -c 30 udp port 53 or tcp port 53
    Bounce BIND, wait for a minute at least.
    Do some DNS queries. One or two will do.
    Interrupt tcpdump unless it completes by itself.
    Post dns.pcap.



    Strangely, the issue resolved itself without me having to do anything. Am really puzzled as to what it was. Perhaps the internet provider suddenly started to block DNS queries but then allowed them again? If so, why did dig's message say that there was "
    communications error to 127.0.0.1#53: timed out"? It really gives an impression that dig was failing to connect 127.0.0.1 port 53, on which bind was running.

    # dig www.yahoo.com <http://www.yahoo.com>
    ;; communications error to 127.0.0.1#53: timed out
    ;; communications error to 127.0.0.1#53: timed out
    ...

    Maybe someone will shed some light on this.

    Thanks to everyone who responded.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeremy Ardley@21:1/5 to All on Mon Mar 13 23:30:01 2023
    On 14/3/23 06:14, local10 wrote:

    Strangely, the issue resolved itself without me having to do anything. Am really puzzled as to what it was. Perhaps the internet provider suddenly started to block DNS queries but then allowed them again? If so, why did dig's message say that there was
    "communications error to 127.0.0.1#53: timed out"? It really gives an impression that dig was failing to connect 127.0.0.1 port 53, on which bind was running.

    # dig www.yahoo.com <http://www.yahoo.com>
    ;; communications error to 127.0.0.1#53: timed out
    ;; communications error to 127.0.0.1#53: timed out
    ...

    Maybe someone will shed some light on this.

    Thanks to everyone who responded.


    I had a signed DNS error in a similar configuration using a bind
    authoritive and caching server. It turned out it was systemd-resolved interfering and/or replacing part of the DNS chain

    FYI systed-resolved is the inbuilt debian caching DNS server which may
    be enabled by default. If you run that you don't need a bind9 caching
    name server

    What does this report ?

    systemctl status systemd-resolved

    If  there is anything there at all, check logs. You may find something

    --
    Jeremy
    (Lists)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeremy Ardley@21:1/5 to Greg Wooledge on Mon Mar 13 23:40:01 2023
    On 14/3/23 06:34, Greg Wooledge wrote:
    On Tue, Mar 14, 2023 at 06:23:09AM +0800, Jeremy Ardley wrote:
    FYI systed-resolved is the inbuilt debian caching DNS server which may be
    enabled by default.
    It is NOT enabled by default.

    It is if you are using NetworkManager

    --
    Jeremy
    (Lists)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to All on Mon Mar 13 23:40:01 2023
    On Mon, Mar 13, 2023 at 11:14:20PM +0100, local10 wrote:
    Strangely, the issue resolved itself without me having to do anything. Am really puzzled as to what it was. Perhaps the internet provider suddenly started to block DNS queries but then allowed them again? If so, why did dig's message say that there was
    "communications error to 127.0.0.1#53: timed out"? It really gives an impression that dig was failing to connect 127.0.0.1 port 53, on which bind was running.

    # dig www.yahoo.com <http://www.yahoo.com>
    ;; communications error to 127.0.0.1#53: timed out
    ;; communications error to 127.0.0.1#53: timed out
    ...

    Maybe someone will shed some light on this.

    UDP doesn't have a "connection". The client sends a datagram (a one-way message) to the UDP service, and then waits to receive a reply.

    If the UDP service in turn sends a datagram to a third party, and waits
    for a reply, but never receives one... and thus never responds to the
    original client... then all the client knows is that it never got a
    response. It doesn't know why.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeremy Ardley@21:1/5 to Jeremy Ardley on Mon Mar 13 23:40:01 2023
    This is a multi-part message in MIME format.
    On 14/3/23 06:23, Jeremy Ardley wrote:

    I had a signed DNS error in a similar configuration using a bind
    authoritive and caching server. It turned out it was systemd-resolved interfering and/or replacing part of the DNS chain

    FYI systed-resolved is the inbuilt debian caching DNS server which may
    be enabled by default. If you run that you don't need a bind9 caching
    name server

    What does this report ?

    systemctl status systemd-resolved

    If  there is anything there at all, check logs. You may find something

    Also FYI you can run bind9 and systemd-resolved at the same time and set
    bind9 to use systemd-resolved as forwarder


    |options { directory "/var/cache/bind"; // Use systemd-resolved as a DNS resolver forwarders { 127.0.0.53 port 53; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 ... Its probably a good idea to
    not be too keen on dnssec validation - as above. |
    --
    Jeremy
    (Lists)

    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 14/3/23 06:23, Jeremy Ardley wrote:<br>
    </div>
    <blockquote type="cite"
    cite="mid:44493370-d84a-0d12-a3de-4d9b3daa82c0@ardley.org">
    <br>
    I had a signed DNS error in a similar configuration using a bind
    authoritive and caching server. It turned out it was
    systemd-resolved interfering and/or replacing part of the DNS
    chain
    <br>
    <br>
    FYI systed-resolved is the inbuilt debian caching DNS server which
    may be enabled by default. If you run that you don't need a bind9
    caching name server
    <br>
    <br>
    What does this report ?
    <br>
    <br>
    systemctl status systemd-resolved
    <br>
    <br>
    If  there is anything there at all, check logs. You may find
    something
    <br>
    <br>
    </blockquote>
    <p>Also FYI you can run bind9 and systemd-resolved at the same time
    and set bind9 to use systemd-resolved as forwarder</p>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72"><code class="!whitespace-pre hljs language-cpp">options {
    directory <span class="hljs-string">"/var/cache/bind"</span>;

    <span class="hljs-comment">// Use systemd-resolved as a DNS resolver</span>
    forwarders {
    <span class="hljs-number">127.0</span><span class="hljs-number">.0</span><span class="hljs-number">.53</span> port <span class="hljs-number">53</span>;
    };

    dnssec-validation <span class="hljs-keyword">auto</span>;

    auth-nxdomain no; <span class="hljs-meta"># conform to RFC1035

    ...

    Its probably a good idea to not be too keen on dnssec validation - as above. </span></code>
    --
    Jeremy
    (Lists)</pre>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeremy Ardley@21:1/5 to Greg Wooledge on Tue Mar 14 00:10:01 2023
    On 14/3/23 06:34, Greg Wooledge wrote:
    On Tue, Mar 14, 2023 at 06:23:09AM +0800, Jeremy Ardley wrote:
    FYI systed-resolved is the inbuilt debian caching DNS server which may be
    enabled by default.
    It is NOT enabled by default.

    unicorn:~$ systemctl status systemd-resolved
    ● systemd-resolved.service - Network Name Resolution
    Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; ve>
    Active: inactive (dead)
    Docs: man:systemd-resolved.service(8)
    man:org.freedesktop.resolve1(5)
    https://www.freedesktop.org/wiki/Software/systemd/writing-network->
    https://www.freedesktop.org/wiki/Software/systemd/writing-resolver>

    I replicated your test above and it seems your listing has been
    accidentally truncated...

    jeremy@testldap:~$ systemctl status systemd-resolved
    ● systemd-resolved.service - Network Name Resolution
         Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
         Active: inactive (dead)
           Docs: man:systemd-resolved.service(8)
                 man:org.freedesktop.resolve1(5) https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
    https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

    It would seem the debian default is enabled? See vendor preset below.

    Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled;
    vendor preset: enabled)

    --
    Jeremy
    (Lists)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to Jeremy Ardley on Tue Mar 14 00:30:01 2023
    On Tue, Mar 14, 2023 at 07:04:02AM +0800, Jeremy Ardley wrote:
    I replicated your test above and it seems your listing has been accidentally truncated...

    Pipe it through cat to avoid the "left/right scrolling" crap.

    jeremy@testldap:~$ systemctl status systemd-resolved
    ● systemd-resolved.service - Network Name Resolution
         Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled;
    vendor preset: enabled)
         Active: inactive (dead)
           Docs: man:systemd-resolved.service(8)
                 man:org.freedesktop.resolve1(5) https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
    https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

    It would seem the debian default is enabled? See vendor preset below.

    I have not to this day figured out what "vendor preset" means here.

    Mine shows the same as yours -- "disabled; vendor preset: enabled".

    All I care about is the part that says "disabled". That's the actual
    state.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeremy Ardley@21:1/5 to Greg Wooledge on Tue Mar 14 00:40:01 2023
    On 14/3/23 07:23, Greg Wooledge wrote:

    I have not to this day figured out what "vendor preset" means here.

    Mine shows the same as yours -- "disabled; vendor preset: enabled".

    All I care about is the part that says "disabled". That's the actual
    state.

    You may be happy to learn you can't even install it as a separate
    package any more.

    apt  install --reinstall systemd-resolved
    Reading package lists... Done
    Building dependency tree... Done
    Reading state information... Done
    Package systemd-resolved is not available, but is referred to by another package.
    This may mean that the package is missing, has been obsoleted, or
    is only available from another source

    It's on the test VM I built recently so it comes from somewhere

    The general documentation says that if you install it as a package then
    it will rewrite various config files to take over the machine DNS.

    So the mystery is how it gets onto a system using a standard install and
    which package it comes from now and what is done with any presets

    --
    Jeremy
    (Lists)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to Jeremy Ardley on Tue Mar 14 01:00:02 2023
    On Tue, Mar 14, 2023 at 07:33:00AM +0800, Jeremy Ardley wrote:
    So the mystery is how it gets onto a system using a standard install and which package it comes from now and what is done with any presets

    unicorn:~$ dpkg -S systemd-resolved
    systemd: /usr/share/man/man8/systemd-resolved.8.gz
    systemd: /lib/systemd/systemd-resolved
    systemd: /lib/systemd/system/systemd-resolved.service
    systemd: /usr/share/man/man8/systemd-resolved.service.8.gz

    It's installed by default, but it's not ENABLED by default.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From local10@21:1/5 to All on Tue Mar 14 04:20:01 2023
    Mar 13, 2023, 23:33 by jeremy@ardley.org:

    You may be happy to learn you can't even install it as a separate package any more.

    apt  install --reinstall systemd-resolved
    Reading package lists... Done
    Building dependency tree... Done
    Reading state information... Done
    Package systemd-resolved is not available, but is referred to by another package.
    This may mean that the package is missing, has been obsoleted, or
    is only available from another source
    ...

    So the mystery is how it gets onto a system using a standard install and which package it comes from now and what is done with any presets



    On Debian 12 Bookworm it could be done:

    # aptitude show systemd-resolved
    Package: systemd-resolved               
    Version: 252.6-1
    New: yes
    State: not installed
    ...


    # aptitude install systemd-resolved --simulate
    The following NEW packages will be installed:
      libnss-myhostname{a} libnss-resolve{a} systemd-resolved
    0 packages upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
    Need to get 484 kB of archives. After unpacking 1,234 kB will be used.

    Note: Using 'Simulate' mode.
    Do you want to continue? [Y/n/?] n
    Abort.


    Regards,

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Darac Marjal@21:1/5 to All on Tue Mar 14 21:10:02 2023
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------rgYXJ4c3O3H54YOiAbkOa4Q1
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    DQpPbiAxMy8wMy8yMDIzIDIzOjIzLCBHcmVnIFdvb2xlZGdlIHdyb3RlOg0KPiBPbiBUdWUs IE1hciAxNCwgMjAyMyBhdCAwNzowNDowMkFNICswODAwLCBKZXJlbXkgQXJkbGV5IHdyb3Rl Og0KPj4gSSByZXBsaWNhdGVkIHlvdXIgdGVzdCBhYm92ZSBhbmQgaXQgc2VlbXMgeW91ciBs aXN0aW5nIGhhcyBiZWVuIGFjY2lkZW50YWxseQ0KPj4gdHJ1bmNhdGVkLi4uDQo+IFBpcGUg aXQgdGhyb3VnaCBjYXQgdG8gYXZvaWQgdGhlICJsZWZ0L3JpZ2h0IHNjcm9sbGluZyIgY3Jh cC4NCklmIHlvdSB3YW50IHRvIGRvIHRoaXMgcmVndWxhcmx5LCB5b3UgY2FuIHNldCBTWVNU RU1EX1BBR0VSPWNhdA0KPg0KPj4gamVyZW15QHRlc3RsZGFwOn4kIHN5c3RlbWN0bCBzdGF0 dXMgc3lzdGVtZC1yZXNvbHZlZA0KPj4g4pePIHN5c3RlbWQtcmVzb2x2ZWQuc2VydmljZSAt IE5ldHdvcmsgTmFtZSBSZXNvbHV0aW9uDQo+PiAgwqDCoMKgwqAgTG9hZGVkOiBsb2FkZWQg KC9saWIvc3lzdGVtZC9zeXN0ZW0vc3lzdGVtZC1yZXNvbHZlZC5zZXJ2aWNlOyBkaXNhYmxl ZDsNCj4+IHZlbmRvciBwcmVzZXQ6IGVuYWJsZWQpDQo+PiAgwqDCoMKgwqAgQWN0aXZlOiBp bmFjdGl2ZSAoZGVhZCkNCj4+ICDCoMKgwqDCoMKgwqAgRG9jczogbWFuOnN5c3RlbWQtcmVz b2x2ZWQuc2VydmljZSg4KQ0KPj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBtYW46b3Jn LmZyZWVkZXNrdG9wLnJlc29sdmUxKDUpDQo+PiBodHRwczovL3d3dy5mcmVlZGVza3RvcC5v cmcvd2lraS9Tb2Z0d2FyZS9zeXN0ZW1kL3dyaXRpbmctbmV0d29yay1jb25maWd1cmF0aW9u LW1hbmFnZXJzDQo+PiBodHRwczovL3d3dy5mcmVlZGVza3RvcC5vcmcvd2lraS9Tb2Z0d2Fy ZS9zeXN0ZW1kL3dyaXRpbmctcmVzb2x2ZXItY2xpZW50cw0KPj4NCj4+IEl0IHdvdWxkIHNl ZW0gdGhlIGRlYmlhbiBkZWZhdWx0IGlzIGVuYWJsZWQ/IFNlZSB2ZW5kb3IgcHJlc2V0IGJl bG93Lg0KPiBJIGhhdmUgbm90IHRvIHRoaXMgZGF5IGZpZ3VyZWQgb3V0IHdoYXQgInZlbmRv ciBwcmVzZXQiIG1lYW5zIGhlcmUuDQpJdCB3b3VsZCBhcHBlYXIgdG8gYmUgDQpodHRwczov L3d3dy5mcmVlZGVza3RvcC5vcmcvc29mdHdhcmUvc3lzdGVtZC9tYW4vc3lzdGVtZC5wcmVz ZXQuaHRtbC4gSWYgDQpJJ20gcmVhZGluZyB0aGUgaW50cm9kdWN0aW9uIGNvcnJlY3RseSwg dGhpcyBpcyBzeXN0ZW1kJ3MgZXF1aXZhbGVudCB0byANCkRlYmlhbidzIHBvbGljeS1yYy5k LCBpbmFzbXVjaCBhcyBpdCdzIGEgcGxhY2UgdG8gZGVmaW5lIHdoZXRoZXIgYSANCnNlcnZp Y2Ugc3RhcnRzIChvciBub3QpIF9iZWZvcmVfIGluc3RhbGxpbmcgdGhlIHBhY2thZ2UuDQo+ DQo+IE1pbmUgc2hvd3MgdGhlIHNhbWUgYXMgeW91cnMgLS0gImRpc2FibGVkOyB2ZW5kb3Ig cHJlc2V0OiBlbmFibGVkIi4NCj4NCj4gQWxsIEkgY2FyZSBhYm91dCBpcyB0aGUgcGFydCB0 aGF0IHNheXMgImRpc2FibGVkIi4gIFRoYXQncyB0aGUgYWN0dWFsDQo+IHN0YXRlLg0KPg0K


    --------------rgYXJ4c3O3H54YOiAbkOa4Q1--

    -----BEGIN PGP SIGNATURE-----

    wsF5BAABCAAjFiEE1A0c5XWknk+U2MemZUdBNabqRbUFAmQQ06MFAwAAAAAACgkQZUdBNabqRbUY sA//UZkg171JZUxmNybxVdPoE6+n+CCJSpYzWDweVV0viy9jFlqklIJXMWkuVKE0J9EOfa2T3ac9 jy5V2Wj6gQbqsXO0S23AvqocamCiktlLmkh0GyeCz+qKFNg4CkkCjNsa8rnWAz+BqQiJI8L4lHV4 xXHEZah7z2bIzQdJgNTy/OXk8N0h8exGyEf31bKMEKMb+V4hnLjMoXmtOf7VEYFKHu0zBsQK7WzO 4BwISYNW20D+m4Kx642N6Mjbtm5WGK4+lWd7DuUaKmH6RdkJBrX8jSSfvGTD546+v/Y6GietnSEb 6GaZV4mpLwy7HHt0saq+JKlOHB91otDlF63jvgL31CQTEDUbgTeceaCyptSicxOXKpJJzpvG7Vdq Y3dhvcCvJabi4Izju920EH9tZgKmWf1HeOEcdVdEa+mzFjJgn4VIWS5226Lz64kHeeqsSlxrnKhW 9lIOFagyRIFvNNadcZOKcjxZhlAuMHn7rZIQzEuIBekkL8nYKQZuKZOvguWykgL+aZascljcYJlT MrquN/YcZSlNd6hHGgflFJkiJg0TcclyS1C9xCMpcXuHDr8c/Tuu8n6beH70APMtvLL/b6qIKiI+ PyJEYUb+iz+dBZsEAdvoF3gyrBk7WHTA+O1GVRZjOH3lsD2JgQYCqGJtm3oF0b3GUe7Tx8Bb5MYu 7uU=
    =BiYh
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to Darac Marjal on Tue Mar 14 21:30:01 2023
    On Tue, Mar 14, 2023 at 08:05:55PM +0000, Darac Marjal wrote:
    On 13/03/2023 23:23, Greg Wooledge wrote:
    I have not to this day figured out what "vendor preset" means here.
    It would appear to be https://www.freedesktop.org/software/systemd/man/systemd.preset.html. If I'm reading the introduction correctly, this is systemd's equivalent to Debian's policy-rc.d, inasmuch as it's a place to define whether a service starts (or not) _before_ installing the package.

    Hmm. Well, on my system there's a
    /lib/systemd/system-preset/90-systemd.preset file which contains, among
    other things:

    enable systemd-resolved.service

    I'm guessing this file came straight from upstream, and hasn't been
    modified by Debian. I'm also guessing this file is read by
    "systemctl status" (or something acting on its behalf) to generate
    that "vendor preset: enabled" verbiage.

    But because Debian doesn't actually *adhere* to all of the upstream
    semantics, this file and the "vendor preset" verbiage are not correct.
    They don't reflect reality on a Debian system.

    Which is fine. I'll just continue ignoring the "vendor preset" section
    as I have been doing. I mean, it would be *nice* if it actually showed
    the Debian system defaults rather than the upstream defaults, but I can
    live without that.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)