From wdgarc88 at gmail.com  Sat May  1 05:52:17 2021
From: wdgarc88 at gmail.com (Edwardo Garcia)
Date: Sat, 1 May 2021 15:52:17 +1000
Subject: DNSSEC upgrade
In-Reply-To: <9734b122-1d3f-19e3-ad51-02d852eb077@dotat.at>
References: <CANso6eEPJ22htrvS=T5u0GW3nG2jf3cFdvgrD-C3gMoP9e599A@mail.gmail.com>
 <bc3356f-4cf3-10ef-e52-1c6db73e1df@dotat.at>
 <CANso6eFZ+j6zxtEiA19W+Yi8cTJ4x2MpKQmWRfn74wphHtHLoA@mail.gmail.com>
 <9734b122-1d3f-19e3-ad51-02d852eb077@dotat.at>
Message-ID: <CANso6eFE=VY=PH1jbofweXOY2teG+YnuTy+a=F7VB9MuvTJHZg@mail.gmail.com>

One thing I note, all check say everything is good, but when using dnsviz,
it says secure, shows the ecd...  but also puts up warnings that I am using
alg 13 but digest 1 (sha1), which is not allowed, I never use the setting
when create keys as the guide says not needed, if this a problem with them
or maybe the .com and .net zones having longer TTL than ours (4 hours),
confused, but I am happy enough since verisignlabs says all green ticks


On Sat, May 1, 2021 at 4:15 AM Tony Finch <dot at dotat.at> wrote:

> Edwardo Garcia <wdgarc88 at gmail.com> wrote:
> >
> > One question however it talk about longest TTL, does this mean also root
> > TLD zones (.com, .net) which from memory are 48 hours, so before we
> delete
> > old keys we need wait 48 hours, even though our zone TTL was 24 ?
>
> When you are waiting after adding and signing with the new keys and before
> swapping the DS records, it's only the longest TTL in your own zone that
> matters. In my notes I call this the "child TTL" because the root and TLD
> etc. don't matter.
>
> https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html
>
> When you're waiting for the DS TTL it's only the TTL of that particular
> record that matters. (It's in the parent zone so I called it the parent
> TTL.) To be sure you are getting the right number you will need something
> like:
>
>         dig +ttlunits example.com ds @$(dig +short com ns | head -1)
>
> i.e. pick one of the nameservers of the parent zone and ask it for your
> zone's DS record, so you don't get mislead by decremented cached TTLs.
> Note the DS TTL is often not the same as the parent NS or glue TTL.
>
> > Thank you, wow much much easy than I hoped for :-)
>
> I'm happy it helped!
>
> Tony.
> --
> f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
> Biscay: North, backing northwest later, 2 to 4, occasionally 5 later
> in east. Slight. Showers. Good.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210501/dc4f4e64/attachment.htm>

From marka at isc.org  Sat May  1 06:52:01 2021
From: marka at isc.org (Mark Andrews)
Date: Sat, 1 May 2021 16:52:01 +1000
Subject: managed-keys-error since BIND-9.16.15
In-Reply-To: <cb1fcc69-f7df-dd99-7940-b2336020fe98@verreckte-cheib.ch>
References: <cb1fcc69-f7df-dd99-7940-b2336020fe98@verreckte-cheib.ch>
Message-ID: <FB20048E-EC84-49AE-8C4E-FC3BBFDCFF05@isc.org>

Named should automatically correct this error. The journal version was not updated when the transaction header was updated. This has been corrected and named detects the unexpected transaction header and writes out a corrected journal. 

-- 
Mark Andrews

> On 30 Apr 2021, at 21:16, Tom <lists at verreckte-cheib.ch> wrote:
> 
> ?Hi
> 
> After upgrading to BIND-9.16.15, I have the following error in named.log:
> 
> 30-Apr-2021 12:41:29.194 general: error: managed-keys.bind.jnw: journal file corrupt: expected serial 1823, got 1824
> 30-Apr-2021 12:41:29.194 general: error: managed-keys-zone: dns_journal_compact failed: unexpected error
> 
> $ l /var/named/managed-keys.bind*
> -rw-r--r--. 1 named named  821 30. Apr 12:41 /var/named/managed-keys.bind
> -rw-r--r--. 1 named named 4.5K 30. Apr 12:41 /var/named/managed-keys.bind.jnl
> 
> Yesterday (after initially starting the latest version) the error occured the first time on server1. Then I stopped named on server1, removed both files (.bind and .bind.jnl), and startet named again.
> 
> Today, the same error appeared one time on server2, but named seems working fine, also DNSSEC verification. With "named-journalprint" I'm able to print to content of the managed-keys.bind.jnl.
> 
> Any hints about this error?
> 
> Thank you.
> Kind regards,
> Tom
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


From dot at dotat.at  Sat May  1 10:25:04 2021
From: dot at dotat.at (Tony Finch)
Date: Sat, 1 May 2021 11:25:04 +0100
Subject: DNSSEC upgrade
In-Reply-To: <CANso6eFE=VY=PH1jbofweXOY2teG+YnuTy+a=F7VB9MuvTJHZg@mail.gmail.com>
References: <CANso6eEPJ22htrvS=T5u0GW3nG2jf3cFdvgrD-C3gMoP9e599A@mail.gmail.com>
 <bc3356f-4cf3-10ef-e52-1c6db73e1df@dotat.at>
 <CANso6eFZ+j6zxtEiA19W+Yi8cTJ4x2MpKQmWRfn74wphHtHLoA@mail.gmail.com>
 <9734b122-1d3f-19e3-ad51-02d852eb077@dotat.at>
 <CANso6eFE=VY=PH1jbofweXOY2teG+YnuTy+a=F7VB9MuvTJHZg@mail.gmail.com>
Message-ID: <476f58de-6a73-9316-d914-bdc2d5a56483@dotat.at>

Edwardo Garcia <wdgarc88 at gmail.com> wrote:

> One thing I note, all check say everything is good, but when using dnsviz,
> it says secure, shows the ecd...  but also puts up warnings that I am using
> alg 13 but digest 1 (sha1), which is not allowed,

I guess the "digest 1" is referring to your DS records. In my guide I
said, get the DS record for the new algorithm like this:

	dnssec-dsfromkey -2 Kbotolph.cam.ac.uk.+013+YYYYY

The -2 option forces SHA-2 and avoids the deprecated SHA-1 hash.

Old versions of BIND by default print both SHA1 and SHA2 DS records, and
it's relatively common for zones to have both kinds of DS record in their
delegation.

SHA1 DS records are now discouraged so it's best to replace them with
SHA2, or just delete them if you have both kinds of DS record.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
harness technological change to human advantage


From wdgarc88 at gmail.com  Sat May  1 11:37:32 2021
From: wdgarc88 at gmail.com (Edwardo Garcia)
Date: Sat, 1 May 2021 21:37:32 +1000
Subject: DNSSEC upgrade
In-Reply-To: <476f58de-6a73-9316-d914-bdc2d5a56483@dotat.at>
References: <CANso6eEPJ22htrvS=T5u0GW3nG2jf3cFdvgrD-C3gMoP9e599A@mail.gmail.com>
 <bc3356f-4cf3-10ef-e52-1c6db73e1df@dotat.at>
 <CANso6eFZ+j6zxtEiA19W+Yi8cTJ4x2MpKQmWRfn74wphHtHLoA@mail.gmail.com>
 <9734b122-1d3f-19e3-ad51-02d852eb077@dotat.at>
 <CANso6eFE=VY=PH1jbofweXOY2teG+YnuTy+a=F7VB9MuvTJHZg@mail.gmail.com>
 <476f58de-6a73-9316-d914-bdc2d5a56483@dotat.at>
Message-ID: <CANso6eF93fPqZmKti7H1e58qHS8Qrh7Au2NRaFW-S=UQ7y3-zA@mail.gmail.com>

OKi, I assume that was same as


dig @ns0 dnskey guiltyparty.net | dnssec-dsfromkey -f - guiltyparty.net


Which is in our internals wiki for all these years (predate my employment
2012 )

So you mean to say when it print out

IN DS 45701 13 1 5422E9...
IN DS 45701 13 2 qwertyE9...

we never needed 45701 13 1 5422E9   only   45701 13 2 qwertyE9  ?

and we only need run

dig @ns0 dnskey guiltyparty.net | dnssec-dsfromkey -2 -f - guiltyparty.net

and enter  in just that one entry?  45701 13 2 qwertyE to the DS in domain
reg?




and we have been upload both all this years was wrong ?


way we been do it is instruction from wiki in full, more or less which I
guess
worked back in the day,

dnssec-keygen -r /dev/urandom -a rsasha1 -b 1024 -K keys/ -n ZONE foo.net
dnssec-keygen -r /dev/urandom -a rsasha1 -b 4096 -K keys/ -n ZONE -f KSK
foo.net

add into zone file

$INCLUDE keys/Kfoo.net.+005+6341.key
$INCLUDE keys/Kfoo.net.+005+9847.key

dnssec-signzone -a -e +9590400 -K keys/ -N INCREMENT foo.net
rndc stuff

then get DS and add both info registrar from dig (like above)

foo.net. IN DS 1234 5 1 .....
foo.net. IN DS 1234 5 2 .....

which stretch memory back to 2012 domain registrasr wanted both


hrmm, now I start to understand why not many use DNSSEC so confusing to
those who not
do this every day, or so many instructions around nobody knows what works

But we getting there :->

On Sat, May 1, 2021 at 8:25 PM Tony Finch <dot at dotat.at> wrote:

> Edwardo Garcia <wdgarc88 at gmail.com> wrote:
>
> > One thing I note, all check say everything is good, but when using
> dnsviz,
> > it says secure, shows the ecd...  but also puts up warnings that I am
> using
> > alg 13 but digest 1 (sha1), which is not allowed,
>
> I guess the "digest 1" is referring to your DS records. In my guide I
> said, get the DS record for the new algorithm like this:
>
>         dnssec-dsfromkey -2 Kbotolph.cam.ac.uk.+013+YYYYY
>
> The -2 option forces SHA-2 and avoids the deprecated SHA-1 hash.
>
> Old versions of BIND by default print both SHA1 and SHA2 DS records, and
> it's relatively common for zones to have both kinds of DS record in their
> delegation.
>
> SHA1 DS records are now discouraged so it's best to replace them with
> SHA2, or just delete them if you have both kinds of DS record.
>
> Tony.
> --
> f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
> harness technological change to human advantage
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210501/de9dce1c/attachment.htm>

From dot at dotat.at  Sat May  1 12:31:25 2021
From: dot at dotat.at (Tony Finch)
Date: Sat, 1 May 2021 13:31:25 +0100
Subject: DNSSEC upgrade
In-Reply-To: <CANso6eF93fPqZmKti7H1e58qHS8Qrh7Au2NRaFW-S=UQ7y3-zA@mail.gmail.com>
References: <CANso6eEPJ22htrvS=T5u0GW3nG2jf3cFdvgrD-C3gMoP9e599A@mail.gmail.com>
 <bc3356f-4cf3-10ef-e52-1c6db73e1df@dotat.at>
 <CANso6eFZ+j6zxtEiA19W+Yi8cTJ4x2MpKQmWRfn74wphHtHLoA@mail.gmail.com>
 <9734b122-1d3f-19e3-ad51-02d852eb077@dotat.at>
 <CANso6eFE=VY=PH1jbofweXOY2teG+YnuTy+a=F7VB9MuvTJHZg@mail.gmail.com>
 <476f58de-6a73-9316-d914-bdc2d5a56483@dotat.at>
 <CANso6eF93fPqZmKti7H1e58qHS8Qrh7Au2NRaFW-S=UQ7y3-zA@mail.gmail.com>
Message-ID: <276be9f7-70c9-d8d5-8c10-98a7d7835b4@dotat.at>

Edwardo Garcia <wdgarc88 at gmail.com> wrote:
>
> So you mean to say when it print out
>
> IN DS 45701 13 1 5422E9...
> IN DS 45701 13 2 qwertyE9...
>
> we never needed 45701 13 1 5422E9   only   45701 13 2 qwertyE9  ?

Exactly, yes!

> and we only need run
>
> dig @ns0 dnskey guiltyparty.net | dnssec-dsfromkey -2 -f - guiltyparty.net
>
> and enter  in just that one entry?  45701 13 2 qwertyE to the DS in domain
> reg?

Correct!

> and we have been upload both all this years was wrong ?

Well, not wrong, but unnecessary. The tools generally encouraged everyone
to publish both SHA1 and SHA2 DS records even though just SHA2 has been
enough for more than 10 years and SHA1 has had known weaknesses for even
longer.

> hrmm, now I start to understand why not many use DNSSEC so confusing to
> those who not do this every day, or so many instructions around nobody
> knows what works
>
> But we getting there :->

Yes, slowly...

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
Shannon, Rockall: Variable 4 or less, becoming southwest 3 to 5 later.
Slight, occasionally moderate in Rockall and at first in Shannon.
Showers. Good.


From wdgarc88 at gmail.com  Sat May  1 12:55:56 2021
From: wdgarc88 at gmail.com (Edwardo Garcia)
Date: Sat, 1 May 2021 22:55:56 +1000
Subject: DNSSEC upgrade
In-Reply-To: <276be9f7-70c9-d8d5-8c10-98a7d7835b4@dotat.at>
References: <CANso6eEPJ22htrvS=T5u0GW3nG2jf3cFdvgrD-C3gMoP9e599A@mail.gmail.com>
 <bc3356f-4cf3-10ef-e52-1c6db73e1df@dotat.at>
 <CANso6eFZ+j6zxtEiA19W+Yi8cTJ4x2MpKQmWRfn74wphHtHLoA@mail.gmail.com>
 <9734b122-1d3f-19e3-ad51-02d852eb077@dotat.at>
 <CANso6eFE=VY=PH1jbofweXOY2teG+YnuTy+a=F7VB9MuvTJHZg@mail.gmail.com>
 <476f58de-6a73-9316-d914-bdc2d5a56483@dotat.at>
 <CANso6eF93fPqZmKti7H1e58qHS8Qrh7Au2NRaFW-S=UQ7y3-zA@mail.gmail.com>
 <276be9f7-70c9-d8d5-8c10-98a7d7835b4@dotat.at>
Message-ID: <CANso6eHS_rVz_MtvScbcuk3PCfZv6Vmb00-++Q5D4vTZO3=3vA@mail.gmail.com>

Thank you!  I have now corrected our ancient internal wiki so we now have
learned how it goes
Very much appreciate your patience and help, now I can start my weekend :->


On Sat, May 1, 2021 at 10:31 PM Tony Finch <dot at dotat.at> wrote:

> Edwardo Garcia <wdgarc88 at gmail.com> wrote:
> >
> > So you mean to say when it print out
> >
> > IN DS 45701 13 1 5422E9...
> > IN DS 45701 13 2 qwertyE9...
> >
> > we never needed 45701 13 1 5422E9   only   45701 13 2 qwertyE9  ?
>
> Exactly, yes!
>
> > and we only need run
> >
> > dig @ns0 dnskey guiltyparty.net | dnssec-dsfromkey -2 -f -
> guiltyparty.net
> >
> > and enter  in just that one entry?  45701 13 2 qwertyE to the DS in
> domain
> > reg?
>
> Correct!
>
> > and we have been upload both all this years was wrong ?
>
> Well, not wrong, but unnecessary. The tools generally encouraged everyone
> to publish both SHA1 and SHA2 DS records even though just SHA2 has been
> enough for more than 10 years and SHA1 has had known weaknesses for even
> longer.
>
> > hrmm, now I start to understand why not many use DNSSEC so confusing to
> > those who not do this every day, or so many instructions around nobody
> > knows what works
> >
> > But we getting there :->
>
> Yes, slowly...
>
> Tony.
> --
> f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
> Shannon, Rockall: Variable 4 or less, becoming southwest 3 to 5 later.
> Slight, occasionally moderate in Rockall and at first in Shannon.
> Showers. Good.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210501/3b70641c/attachment.htm>

From empbilly at gmail.com  Sat May  1 13:03:17 2021
From: empbilly at gmail.com (Elias Pereira)
Date: Sat, 1 May 2021 10:03:17 -0300
Subject: bind vulnerabilities
Message-ID: <CAHdxDAFYRyXE3x0m6nX+JVWbzpYHrUsAqaaycYn=QTNXOgya_A@mail.gmail.com>

According to the article below, only the: "BIND 9.11.31, 9.16.15, and
9.17.12 all contain patches and the appropriate update should be applied"
https://www.zdnet.com/google-amp/article/isc-urges-updates-of-dns-servers-to-wipe-out-new-bind-vulnerabilities/

Is this statement correct?

-- 
Elias Pereira
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210501/3e8a981d/attachment.htm>

From alcol at hotmail.com  Sat May  1 13:29:42 2021
From: alcol at hotmail.com (alcol alcol)
Date: Sat, 1 May 2021 13:29:42 +0000
Subject: bind vulnerabilities
In-Reply-To: <CAHdxDAFYRyXE3x0m6nX+JVWbzpYHrUsAqaaycYn=QTNXOgya_A@mail.gmail.com>
References: <CAHdxDAFYRyXE3x0m6nX+JVWbzpYHrUsAqaaycYn=QTNXOgya_A@mail.gmail.com>
Message-ID: <CY4PR19MB1494A66BF5BE64D73E0B6256A25D9@CY4PR19MB1494.namprd19.prod.outlook.com>

from isc

https://kb.isc.org/docs/aa-00913
[https://cdn.document360.io/956e37e2-5ec0-4942-8b27-35533899f099/Images/Documentation/ISC-logo-rgb-2048x1149.png]<https://kb.isc.org/docs/aa-00913>
BIND 9 Security Vulnerability Matrix - Security Advisories<https://kb.isc.org/docs/aa-00913>
kb.isc.org




________________________________
From: bind-users <bind-users-bounces at lists.isc.org> on behalf of Elias Pereira <empbilly at gmail.com>
Sent: Saturday, May 1, 2021 3:03 PM
To: bind-users at lists.isc.org <bind-users at lists.isc.org>
Subject: bind vulnerabilities

According to the article below, only the: "BIND 9.11.31, 9.16.15, and 9.17.12 all contain patches and the appropriate update should be applied"
https://www.zdnet.com/google-amp/article/isc-urges-updates-of-dns-servers-to-wipe-out-new-bind-vulnerabilities/

Is this statement correct?

--
Elias Pereira
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210501/fa7de4f2/attachment-0001.htm>

From lists at verreckte-cheib.ch  Mon May  3 05:31:35 2021
From: lists at verreckte-cheib.ch (Tom)
Date: Mon, 3 May 2021 07:31:35 +0200
Subject: managed-keys-error since BIND-9.16.15
In-Reply-To: <FB20048E-EC84-49AE-8C4E-FC3BBFDCFF05@isc.org>
References: <cb1fcc69-f7df-dd99-7940-b2336020fe98@verreckte-cheib.ch>
 <FB20048E-EC84-49AE-8C4E-FC3BBFDCFF05@isc.org>
Message-ID: <1687c6e1-8de1-67f0-2e8e-cdf3a2103085@verreckte-cheib.ch>

I see the same error also on a couple of slave zones on a updated 
authoritative server, not only on the "managed-keys.bind"-file. So this 
is also not critical and can be ignored?

03-May-2021 00:20:28.532 general: error: 
/var/named/slave/example.com.hosts.jnw: journal file corrupt: expected 
serial 2021050100, got 2021050300
03-May-2021 00:20:28.532 general: error: zone example.com/IN: 
dns_journal_compact failed: unexpected error

Thank you.
Kind regards,
Tom


On 01.05.21 08:52, Mark Andrews wrote:
> Named should automatically correct this error. The journal version was not updated when the transaction header was updated. This has been corrected and named detects the unexpected transaction header and writes out a corrected journal.
> 

From marka at isc.org  Mon May  3 05:52:32 2021
From: marka at isc.org (Mark Andrews)
Date: Mon, 3 May 2021 15:52:32 +1000
Subject: managed-keys-error since BIND-9.16.15
In-Reply-To: <1687c6e1-8de1-67f0-2e8e-cdf3a2103085@verreckte-cheib.ch>
References: <cb1fcc69-f7df-dd99-7940-b2336020fe98@verreckte-cheib.ch>
 <FB20048E-EC84-49AE-8C4E-FC3BBFDCFF05@isc.org>
 <1687c6e1-8de1-67f0-2e8e-cdf3a2103085@verreckte-cheib.ch>
Message-ID: <56C010BB-50A2-4829-8B7A-DB9C7AACA287@isc.org>

I suspect we missed a auto detection case.  Can you open ticket on https://gitlab.isc.org.  We will need to see the journal and
whatever else was logged at the same time.

That said "named-journalprint -u /var/named/slave/example.com.hosts.jnl" should fix the issue.  Only run this when named
is stopped.

> On 3 May 2021, at 15:31, Tom <lists at verreckte-cheib.ch> wrote:
> 
> I see the same error also on a couple of slave zones on a updated authoritative server, not only on the "managed-keys.bind"-file. So this is also not critical and can be ignored?
> 
> 03-May-2021 00:20:28.532 general: error: /var/named/slave/example.com.hosts.jnw: journal file corrupt: expected serial 2021050100, got 2021050300
> 03-May-2021 00:20:28.532 general: error: zone example.com/IN: dns_journal_compact failed: unexpected error
> 
> Thank you.
> Kind regards,
> Tom
> 
> 
> On 01.05.21 08:52, Mark Andrews wrote:
>> Named should automatically correct this error. The journal version was not updated when the transaction header was updated. This has been corrected and named detects the unexpected transaction header and writes out a corrected journal.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org


From pemensik at redhat.com  Mon May  3 12:48:08 2021
From: pemensik at redhat.com (=?UTF-8?B?UGV0ciBNZW7FocOtaw==?=)
Date: Mon, 3 May 2021 14:48:08 +0200
Subject: CVE-2021-25216
In-Reply-To: <CAF0K6dRhaNQCJUngDscr+mJaYNkdTcc1X8URpPAmJJaxq0Y-_A@mail.gmail.com>
References: <CAF0K6dRhaNQCJUngDscr+mJaYNkdTcc1X8URpPAmJJaxq0Y-_A@mail.gmail.com>
Message-ID: <1255a8ec-bb62-eb1e-68ae-f6dd0ccba5eb@redhat.com>

Hello Jordan,

Red Hat have been building their BIND packages with --disable-isc-spnego
configure parameter for years, all versions still somehow supported by
Red Hat are built with them. This means the mentioned issue should not
affect Red Hat packages. Please visit [1] to check affected versions.

Your version is still vulnerable to CVE-2021-25215 [2] [3] however,
upgrade to a fixed version is required anyway. But your BIND9 kerberos
support should be fine as it is.

Best Regards,
Petr

1. https://access.redhat.com/security/cve/CVE-2021-25216
2. https://access.redhat.com/security/cve/CVE-2021-25215
3. https://bugzilla.redhat.com/show_bug.cgi?id=1953857

On 4/30/21 4:21 PM, Jordan Tinsley wrote:
> I have a question -
> 
> Is BIND 9.11.6 (Extended Support Version) vulnerable?
If this is vanilla build without special parameters, it is most likely
vulnerable.
> 
> Is BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.3 (Extended Support Version)
> vulnerable?
This version is not vulnerable. Check named -V | grep
disable-isc-spnego, if it finds the string, it is not affected.
> 
> Thanks

-- 
Petr Men??k
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210503/b04de787/attachment.bin>

From roee at cyberpion.com  Tue May  4 12:41:47 2021
From: roee at cyberpion.com (Roee Mayerowicz)
Date: Tue, 4 May 2021 12:41:47 +0000
Subject: REST API for recursive queries
Message-ID: <HE1PR0301MB21888B534B36150A02B7DED6DF5A9@HE1PR0301MB2188.eurprd03.prod.outlook.com>

Hey,
Do you know of a way to ask multiple DNS queries in a recursive bind server at the same packet\request? Using DoH might work? How? Is there a plugin which does that?

Tnx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210504/81689b5f/attachment.htm>

From d.lawrence at salesforce.com  Tue May  4 14:26:31 2021
From: d.lawrence at salesforce.com (tale)
Date: Tue, 4 May 2021 10:26:31 -0400
Subject: REST API for recursive queries
In-Reply-To: <HE1PR0301MB21888B534B36150A02B7DED6DF5A9@HE1PR0301MB2188.eurprd03.prod.outlook.com>
References: <HE1PR0301MB21888B534B36150A02B7DED6DF5A9@HE1PR0301MB2188.eurprd03.prod.outlook.com>
Message-ID: <CAGrdBBupiPeZY11q9j0GxJNK2DcF-MzQmfssGnEkTvgNrdRDzQ@mail.gmail.com>

On Tue, May 4, 2021 at 8:42 AM Roee Mayerowicz <roee at cyberpion.com> wrote:
> Do you know of a way to ask multiple DNS queries in a recursive bind server at the same packet\request?
> Using DoH might work? How? Is there a plugin which does that?

The short answer is no, but it might not be answering the question
you're really trying to ask.

In strict terms of what would constitute "the same request", though,
no.   While you could conceive of
a legally-formed DNS packet that had multiple questions in the
Question section, a server has no way
to acceptably indicate the proper response for all questions.  In some
cases, it might be obvious --
say, asking for the address of a.example.com and b.example.com, and
them both having addresses --
but things quickly get out of hand when you look at the problems of
indicating the many other ways
that DNS can answer, like NXDOMAIN, NODATA, or delegation.

With various forms of DNS TCP connections -- vanilla DNS, DNS over TLS
(DoT), DNS over
HTTPS (DoH) -- you can put multiple DNS request messages over the same
connection.  But that's
not quite the same as "at the same packet\request".  It also can
depend on the end points; you
might want to shove 1000 requests down a TCP connection, but server
policy might limit the
number it will actually process before terminating the link.

And plugins are specific to a particular software package.   Plugin to
what?  BIND and other major
DNS resolvers and authoritative servers support TCP technologies
natively.  The clients that talk
to them are numerous, with varying degrees of support for both TCP
initiation and multi-request
streaming.

-- 
tale

From m3047 at m3047.net  Tue May  4 15:50:49 2021
From: m3047 at m3047.net (Fred Morris)
Date: Tue, 4 May 2021 08:50:49 -0700 (PDT)
Subject: REST API for recursive queries
In-Reply-To: <HE1PR0301MB21888B534B36150A02B7DED6DF5A9@HE1PR0301MB2188.eurprd03.prod.outlook.com>
References: <HE1PR0301MB21888B534B36150A02B7DED6DF5A9@HE1PR0301MB2188.eurprd03.prod.outlook.com>
Message-ID: <alpine.LSU.2.21.2105040805350.20690@flame.m3047>

You don't say /why/ you want to do this. This forwarder only does a single 
request per TCP connection and also supports TLS:

   https://github.com/m3047/tcp_only_forwarder/blob/master/forwarder.py

If you want to run DoT, I'm pretty sure that's on the BIND roadmap. The 
BIND distro has provided instructions for setting up Nginx as an SSL 
terminator in front of BIND in contrib/dnspriv/.

If you're trying to authenticate DNS queries/responses, you can also look 
at using TSIG.

On Tue, 4 May 2021, Roee Mayerowicz wrote:
> Do you know of a way to ask multiple DNS queries in a recursive bind 
> server at the same packet\request? Using DoH might work? How? Is there a 
> plugin which does that?

There is no way to send multiple requests in a single UDP datagram, but 
you can send multiple requests in a TCP connection. There is only ever 
supposed to be exactly one RR in the QUERY section.

--

Fred Morris

--

#!/usr/bin/python3
# Copyright (c) 2021 by Fred Morris Tacoma WA
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#    http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

"""Multiple requests in a single TCP stream.

There is no way to send multiple queries in a single UDP datagram.

Tweak the following to your needs:

    * 10.0.0.220 => your server address
    * sophia.m3047. => a query name
    * flame.m3047. => another query name

Mind the trailing dot at the end of the FQDNs.
"""
import socket
import dns.message

SERVER = ('10.0.0.220', 53)
BIG_ENDIAN = { 'byteorder':'big', 'signed':False }

def main():
     sock = socket.create_connection(SERVER)

     req = dns.message.make_query('sophia.m3047.','A')
     wire_req = req.to_wire()
     sock.send(len(wire_req).to_bytes(2, **BIG_ENDIAN) + wire_req)
     resp_length = sock.recv(2)
     wire_resp = sock.recv(int.from_bytes(resp_length, **BIG_ENDIAN))
     resp = dns.message.from_wire(wire_resp)
     print(resp)

     req = dns.message.make_query('flame.m3047.','A')
     wire_req = req.to_wire()
     sock.send(len(wire_req).to_bytes(2, **BIG_ENDIAN) + wire_req)
     resp_length = sock.recv(2)
     wire_resp = sock.recv(int.from_bytes(resp_length, **BIG_ENDIAN))
     resp = dns.message.from_wire(wire_resp)
     print(resp)

     sock.close()
     return

if __name__ == '__main__':
     main()


From pemensik at redhat.com  Tue May  4 20:07:38 2021
From: pemensik at redhat.com (=?UTF-8?B?UGV0ciBNZW7FocOtaw==?=)
Date: Tue, 4 May 2021 22:07:38 +0200
Subject: REST API for recursive queries
In-Reply-To: <HE1PR0301MB21888B534B36150A02B7DED6DF5A9@HE1PR0301MB2188.eurprd03.prod.outlook.com>
References: <HE1PR0301MB21888B534B36150A02B7DED6DF5A9@HE1PR0301MB2188.eurprd03.prod.outlook.com>
Message-ID: <536adbb5-7be1-3a47-9a5e-eec71476bff1@redhat.com>

systemd-resolved has private api, which attempts to do multiple DNS
queries for one originating query. But it is not accepted to do that
using DNS protocol, it uses d-bus calls I think. Because BIND uses DNS
protocol only and not any dbus or former lwres protocol, you can count
only querying -t ANY for single name as something similar.

But DNS protocol is quite light weight. Multiple UDP queries are still
fast to serve. Can you explain, why are you looking for single query?

It seems to me tool like command "host example.com", which runs 3
queries on the name for you, might work. It does 3 queries, but from
just single call. Would that work for you?

On 5/4/21 2:41 PM, Roee Mayerowicz wrote:
> Hey,
> Do you know of a way to ask multiple DNS queries in a recursive bind server at the same packet\request? Using DoH might work? How? Is there a plugin which does that?
> 
> Tnx
> 
-- 
Petr Men??k
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210504/6acd4d7e/attachment.bin>

From dot at dotat.at  Tue May  4 21:21:02 2021
From: dot at dotat.at (Tony Finch)
Date: Tue, 4 May 2021 22:21:02 +0100
Subject: REST API for recursive queries
In-Reply-To: <536adbb5-7be1-3a47-9a5e-eec71476bff1@redhat.com>
References: <HE1PR0301MB21888B534B36150A02B7DED6DF5A9@HE1PR0301MB2188.eurprd03.prod.outlook.com>
 <536adbb5-7be1-3a47-9a5e-eec71476bff1@redhat.com>
Message-ID: <7644b840-ddb7-8e1-ea0-4a703f46384f@dotat.at>

Petr Men??k <pemensik at redhat.com> wrote:

> Because BIND uses DNS protocol only and not any dbus or former lwres
> protocol, you can count only querying -t ANY for single name as
> something similar.

ANY queries don't necessarily give you all the records :-)

In situations where a DNS client wants to do multiple queries at once, it
can either send a load of UDP queries then wait for the answers, or if it
has a TCP connection open, write all the queries in one go, then read the
answers. There's not really much need for fancy features to support
multiple questions when you can do hundreds of concurrent queries with one
or two sockets.

Happy Eyeballs version 2 requires concurrent DNS queries
https://tools.ietf.org/html/rfc8305#section-3

I like to use `adns` for bulk concurrent queries
http://www.chiark.greenend.org.uk/~ian/adns/

Much newer is getdns which has a more JSON-friendly design.
https://getdnsapi.net/

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
Biscay: West or northwest 5 or 6, becoming variable 2 to 4 later.
Moderate or rough, becoming moderate. Rain at first. Good,
occasionally moderate.

From blevi.linux at gmail.com  Wed May  5 10:26:44 2021
From: blevi.linux at gmail.com (Levente Birta)
Date: Wed, 5 May 2021 13:26:44 +0300
Subject: Log queried forwarder IP address
Message-ID: <8926947f-c9c1-4ceb-5a86-c330329caca4@gmail.com>

Hi

I have a caching resolver. Is it possible to log the IP address of the 
queried forwarder without too much overhead?
As I see, the resolver category should log this, but only in debug 3. Is 
there another way to do this?

Thanks
Levi



From roee at cyberpion.com  Wed May  5 12:01:38 2021
From: roee at cyberpion.com (Roee Mayerowicz)
Date: Wed, 5 May 2021 12:01:38 +0000
Subject: REST API for recursive queries
In-Reply-To: <HE1PR0301MB21888B534B36150A02B7DED6DF5A9@HE1PR0301MB2188.eurprd03.prod.outlook.com>
References: <HE1PR0301MB21888B534B36150A02B7DED6DF5A9@HE1PR0301MB2188.eurprd03.prod.outlook.com>
Message-ID: <HE1PR0301MB21884C767B53C48628ADEB8EDF599@HE1PR0301MB2188.eurprd03.prod.outlook.com>

I have ~700k (and growing) domain names that should be resolved daily. I'm trying to make it efficient as possible using the recursive BIND server (do you know a better option?), the goal is to get 2000 queries per second with minimum server\s cost.
I thought using a single packet for multiple queries might be more efficient than multiple UDPs. I'll try reading more about adns to reach more queries at the same TCP connection. Any better ideas?
________________________________
From: bind-users <bind-users-bounces at lists.isc.org> on behalf of Roee Mayerowicz <roee at cyberpion.com>
Sent: Tuesday, May 4, 2021 3:41 PM
To: bind-users at lists.isc.org <bind-users at lists.isc.org>
Subject: REST API for recursive queries


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Hey,
Do you know of a way to ask multiple DNS queries in a recursive bind server at the same packet\request? Using DoH might work? How? Is there a plugin which does that?

Tnx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210505/2fbe0da8/attachment.htm>

From dclarke at blastwave.org  Wed May  5 12:31:39 2021
From: dclarke at blastwave.org (Dennis Clarke)
Date: Wed, 5 May 2021 08:31:39 -0400
Subject: Slightly baffled about Undefined symbols that are in OpenSSL
Message-ID: <a23e80ff-b2ff-fd7b-09ea-583b324e5590@blastwave.org>


This has kept me spinning in a few hours since yesterday. So I gave a
try at configure and compile of bind-9.11.31 on ye Fujitsu/Oracle SPARC
Solaris 10 boxen and I see :


.
.
.
/opt/developerstudio12.6/bin/cc -mt
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003 -I../..
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/dns/include
-I../../lib/dns/include
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include
-I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include
-I../../lib/isc/pthreads/include -I../../lib/isc/noatomic/include
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isccfg/include
-I../../lib/isccfg/include
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/lwres/include
-I../../lib/lwres/unix/include -I../../lib/lwres/include
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/bind9/include
-I../../lib/bind9/include  -I/opt/bw/include  -D_REENTRANT
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DOPENSSL
-DVERSION=\"9.11.31\" -D_XPG4_2 -D__EXTENSIONS__ -std=iso9899:2011 -m64
-xarch=sparc -g -mc -xs -errfmt=error -erroff=%none -errshort=full
-errtags=yes -errwarn=%none -ftrap=%none -xbuiltin=%none -xildoff
-xlibmieee -xstrconst -xcode=pic32 -xmemalign=8s -xnolibmil -xunroll=1
-xregs=no%appl -xdebugformat=dwarf -I/usr/include/libxml2    -KPIC    -c
isc-hmac-fixup-symtbl.c
gmake[3]: Leaving directory
'/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/bin/tools'
Undefined                       first referenced
 symbol                             in file
EVP_MD_CTX_new                      ../../lib/isc/libisc-nosymtbl.a(md5.o)
EVP_sha512                          ../../lib/isc/libisc-nosymtbl.a(sha2.o)
EVP_sha384                          ../../lib/isc/libisc-nosymtbl.a(sha2.o)
EVP_sha224                          ../../lib/isc/libisc-nosymtbl.a(sha2.o)
EVP_sha256                          ../../lib/isc/libisc-nosymtbl.a(sha2.o)
EVP_DigestInit                      ../../lib/isc/libisc-nosymtbl.a(md5.o)
EVP_DigestUpdate                    ../../lib/isc/libisc-nosymtbl.a(md5.o)
EVP_MD_CTX_reset                    ../../lib/isc/libisc-nosymtbl.a(sha2.o)
EVP_md5                             ../../lib/isc/libisc-nosymtbl.a(md5.o)
EVP_sha1                            ../../lib/isc/libisc-nosymtbl.a(sha1.o)
EVP_DigestFinal                     ../../lib/isc/libisc-nosymtbl.a(md5.o)
EVP_MD_CTX_free                     ../../lib/isc/libisc-nosymtbl.a(md5.o)
ld: fatal: symbol referencing errors. No output written to
isc-hmac-fixuptmp1
gmake[2]: *** [Makefile:495: isc-hmac-fixup] Error 1
gmake[2]: Leaving directory
'/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/bin/tools'
gmake[1]: *** [Makefile:79: subdirs] Error 1
gmake[1]: Leaving directory
'/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/bin'
gmake: *** [Makefile:88: subdirs] Error 1


That is just bizarre because I can cd into the bin/tools directory and
do the link stage manually just fine :

alpha $ /opt/developerstudio12.6/bin/cc -mt \
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003 \
> -I../.. \
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/dns/include \
> -I../../lib/dns/include \
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include \
> -I../../lib/isc \
> -I../../lib/isc/include \
> -I../../lib/isc/unix/include \
> -I../../lib/isc/pthreads/include \
> -I../../lib/isc/noatomic/include \
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isccfg/include \
> -I../../lib/isccfg/include \
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/lwres/include \
> -I../../lib/lwres/unix/include \
> -I../../lib/lwres/include \
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/bind9/include \
> -I../../lib/bind9/include \
> -I/opt/bw/include \
> -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DOPENSSL \
> -DVERSION=\"9.11.31\" \
> -D_XPG4_2 -D__EXTENSIONS__ -std=iso9899:2011 \
> -m64 -xarch=sparc -g -mc -xs -errfmt=error -erroff=%none -errshort=full \
> -errtags=yes -errwarn=%none -ftrap=%none -xbuiltin=%none -xildoff \
> -xlibmieee -xstrconst -xcode=pic32 -xmemalign=8s -xnolibmil -xunroll=1 \
> -xregs=no%appl -xdebugformat=dwarf -KPIC \
> -H -# -c isc-hmac-fixup-symtbl.c
### cc: Note: NLSPATH =
/opt/developerstudio12.6/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/developerstudio12.6/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
### cc: Note: TMPDIR = /var/tmp/dclarke
###     command line files and options (expanded):
### -mt=yes -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003 -I../..
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/dns/include
-I../../lib/dns/include
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include
-I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include
-I../../lib/isc/pthreads/include -I../../lib/isc/noatomic/include
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isccfg/include
-I../../lib/isccfg/include
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/lwres/include
-I../../lib/lwres/unix/include -I../../lib/lwres/include
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/bind9/include
-I../../lib/bind9/include -I/opt/bw/include -D_REENTRANT
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DOPENSSL -DVERSION="9.11.31"
-D_XPG4_2 -D__EXTENSIONS__ -std=c11 -m64 -xarch=sparc
-xdebuginfo=line,param,variable,tagtype,codetag,decl -xglobalize=yes
-xpatchpadding=fix -xkeep_unref=funcs,vars -mc -xs=yes -errfmt=error
-erroff=%none -errshort=full -errtags=yes -errwarn=%none -ftrap=%none
-xbuiltin=%none -xlibmieee -xstrconst -xmemalign=8s -xnolibmil
-xunroll=1 -xregs=no%appl -xdebugformat=dwarf -xcode=pic32 -H -# -c
isc-hmac-fixup-symtbl.c
/opt/developerstudio12.6/lib/compilers/bin/acomp -D_REENTRANT
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DOPENSSL -DVERSION="9.11.31"
-D_XPG4_2 -D__EXTENSIONS__ -H -Qy -std=c11 -i isc-hmac-fixup-symtbl.c
-D__SunOS_5_10 -D__SunOS_RELEASE=0x051000 -D__SUNPRO_C=0x5150 -D__unix
-D__SVR4__ -D__svr4__ -D__SVR4 -D__sun -D__sun__ -D__SunOS -D__sparcv9
-D__sparc_v9__ -D__sparc -D__sparc__ -D_LP64 -D__LP64__ -D__arch64__
-D__ORDER_LITTLE_ENDIAN__=1234 -D__ORDER_BIG_ENDIAN__=4321
-D__BYTE_ORDER__=__ORDER_BIG_ENDIAN__ -D__BUILTIN_VA_ARG_INCR
-D__C11FEATURES__ -D__C99FEATURES__ -D__STRICT_ANSI__
-D__PRAGMA_REDEFINE_EXTNAME -Dunix -Dsun -Dsparc -D__RESTRICT
-D__FLT_EVAL_METHOD__=0 -D_REENTRANT -D__SUN_PREFETCH
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003 -I../..
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/dns/include
-I../../lib/dns/include
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include
-I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include
-I../../lib/isc/pthreads/include -I../../lib/isc/noatomic/include
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isccfg/include
-I../../lib/isccfg/include
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/lwres/include
-I../../lib/lwres/unix/include -I../../lib/lwres/include
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/bind9/include
-I../../lib/bind9/include -I/opt/bw/include -I-xbuiltin
-I/opt/developerstudio12.6/lib/compilers/include/cc -2K -errfmt=error
-erroff=%none -errshort=full -errwarn=%none -errtags -xbuiltin=%none
-strconst -fsimple=0 -m64 -fparam_ir -fparam_ir -xglobalize=yes
-xdebuginfo=line,param,variable,tagtype,codetag,decl
-xkeep_unref=funcs,vars -xF=%none
-xdbggen=dwarf+usedonly+incl+line+param+variable+tagtype+codetag+decl
-xldscope=global -xivdep=loop -xanalyze=code -c99OS
"-g/opt/developerstudio12.6/bin/cc -mt
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003 -I../..
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/dns/include
-I../../lib/dns/include
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include
-I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include
-I../../lib/isc/pthreads/include -I../../lib/isc/noatomic/include
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isccfg/include
-I../../lib/isccfg/include
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/lwres/include
-I../../lib/lwres/unix/include -I../../lib/lwres/include
-I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/bind9/include
-I../../lib/bind9/include -I/opt/bw/include -D_REENTRANT
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS='64' -DOPENSSL
-DVERSION='"9.11.31"' -D_XPG4_2 -D__EXTENSIONS__ -std=iso9899:2011 -m64
-xarch=sparc -g -mc -xs -errfmt=error -erroff=%none -errshort=full
-errtags=yes -errwarn=%none -ftrap=%none -xbuiltin=%none -xildoff
-xlibmieee -xstrconst -xcode=pic32 -xmemalign=8s -xnolibmil -xunroll=1
-xregs=no%appl -xdebugformat=dwarf -KPIC -H -c " -destination_ir=iropt
-r /var/tmp/dclarke/acomp.1620217682.10303.01.ir
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include/isc/backtrace.h

/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include/isc/types.h
                /usr/include/stdbool.h
                        /usr/include/sys/feature_tests.h
                                /usr/include/sys/ccompile.h
                                /usr/include/sys/isa_defs.h

/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include/isc/bind9.h

/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include/isc/platform.h
                                /usr/include/limits.h
                                        /usr/include/iso/limits_iso.h
                                        /usr/include/sys/int_limits.h
                                        /usr/include/sys/unistd.h
                /usr/include/inttypes.h
                        /usr/include/sys/inttypes.h
                                /usr/include/sys/int_types.h
                                /usr/include/sys/int_const.h
                                /usr/include/sys/int_fmtio.h
                        /usr/include/sys/stdint.h
                ../../lib/isc/unix/include/isc/offset.h
                        /usr/include/sys/types.h
                                /usr/include/sys/machtypes.h
                                /usr/include/sys/select.h
                                        /usr/include/sys/time_impl.h
                                        /usr/include/sys/time.h
                                                /usr/include/sys/types.h
                                                /usr/include/time.h

/usr/include/iso/time_iso.h
                                                /usr/include/sys/select.h
                        /usr/include/stddef.h
                                /usr/include/iso/stddef_iso.h

/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include/isc/list.h

/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include/isc/assertions.h

/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include/isc/lang.h

/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include/isc/likely.h
cat /var/tmp/dclarke/acomp.1620217682.10303.01.ir
>/var/tmp/dclarke/acomp.1620217682.10303.02.ir
/opt/developerstudio12.6/lib/compilers/bin/previse -Qy -erroff=%none
-errwarn=%none -errtags -O3 -xarch=sparc -m64 -xchip=generic
-xcache=generic -xdebuginfo=line,param,variable,tagtype,codetag,decl
-depend -xbuiltin=%none -xprefetch=auto,explicit -xprefetch_level=1
-xprefetch_auto_type=no%indirect_array_access -o
/var/tmp/dclarke/iropt.1620217682.10303.03.ir
"-Astatic_err_check:previse_iropt=on:umr=on:aob=on:free=on:nulld=on:nullc=on:msg_ctl_level=0:analytics=off:stderr_output=on"
/var/tmp/dclarke/acomp.1620217682.10303.02.ir
/opt/developerstudio12.6/lib/compilers/bin/cg -Qy -fsimple=0
-xarch=sparc -m64 -xchip=generic -xcache=generic -comdat -ftrap=%none
-xpatchpadding=fix -xdebuginfo=line,param,variable,tagtype,codetag,decl
-xkeep_unref=funcs,vars -s -xbuiltin=%none -xcode=pic32 -xannotate=yes
-xmemalign=8s -xprefetch=auto,explicit
-xprefetch_auto_type=no%indirect_array_access -xcheck=stkovf
-xcheck=noreturn -xthreadvar=dynamic -xregs=no%appl -unroll=1
-xvector=no -mt -oo isc-hmac-fixup-symtbl.o -ir
/var/tmp/dclarke/acomp.1620217682.10303.01.ir
/usr/ccs/bin/mcs -c isc-hmac-fixup-symtbl.o
alpha $

OKee and that looks like it worked.

I did go back and rebuild 9.11.26 with no issue. However this same
strange bizarre pile of undefined symbols appears when I try to build
9.11.27 and 9.11.28 and of course 9.11.31.

Any hints at all would be great.



-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

From marka at isc.org  Wed May  5 12:35:44 2021
From: marka at isc.org (Mark Andrews)
Date: Wed, 5 May 2021 22:35:44 +1000
Subject: Slightly baffled about Undefined symbols that are in OpenSSL
In-Reply-To: <a23e80ff-b2ff-fd7b-09ea-583b324e5590@blastwave.org>
References: <a23e80ff-b2ff-fd7b-09ea-583b324e5590@blastwave.org>
Message-ID: <E40F8656-E055-4AF0-85F1-CBE5A68463E0@isc.org>

Use a non EoL version of OpenSSL. 

-- 
Mark Andrews

> On 5 May 2021, at 22:32, Dennis Clarke via bind-users <bind-users at lists.isc.org> wrote:
> 
> ?
> This has kept me spinning in a few hours since yesterday. So I gave a
> try at configure and compile of bind-9.11.31 on ye Fujitsu/Oracle SPARC
> Solaris 10 boxen and I see :
> 
> 
> .
> .
> .
> /opt/developerstudio12.6/bin/cc -mt
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003 -I../..
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/dns/include
> -I../../lib/dns/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include
> -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include
> -I../../lib/isc/pthreads/include -I../../lib/isc/noatomic/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isccfg/include
> -I../../lib/isccfg/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/lwres/include
> -I../../lib/lwres/unix/include -I../../lib/lwres/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/bind9/include
> -I../../lib/bind9/include  -I/opt/bw/include  -D_REENTRANT
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DOPENSSL
> -DVERSION=\"9.11.31\" -D_XPG4_2 -D__EXTENSIONS__ -std=iso9899:2011 -m64
> -xarch=sparc -g -mc -xs -errfmt=error -erroff=%none -errshort=full
> -errtags=yes -errwarn=%none -ftrap=%none -xbuiltin=%none -xildoff
> -xlibmieee -xstrconst -xcode=pic32 -xmemalign=8s -xnolibmil -xunroll=1
> -xregs=no%appl -xdebugformat=dwarf -I/usr/include/libxml2    -KPIC    -c
> isc-hmac-fixup-symtbl.c
> gmake[3]: Leaving directory
> '/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/bin/tools'
> Undefined                       first referenced
> symbol                             in file
> EVP_MD_CTX_new                      ../../lib/isc/libisc-nosymtbl.a(md5.o)
> EVP_sha512                          ../../lib/isc/libisc-nosymtbl.a(sha2.o)
> EVP_sha384                          ../../lib/isc/libisc-nosymtbl.a(sha2.o)
> EVP_sha224                          ../../lib/isc/libisc-nosymtbl.a(sha2.o)
> EVP_sha256                          ../../lib/isc/libisc-nosymtbl.a(sha2.o)
> EVP_DigestInit                      ../../lib/isc/libisc-nosymtbl.a(md5.o)
> EVP_DigestUpdate                    ../../lib/isc/libisc-nosymtbl.a(md5.o)
> EVP_MD_CTX_reset                    ../../lib/isc/libisc-nosymtbl.a(sha2.o)
> EVP_md5                             ../../lib/isc/libisc-nosymtbl.a(md5.o)
> EVP_sha1                            ../../lib/isc/libisc-nosymtbl.a(sha1.o)
> EVP_DigestFinal                     ../../lib/isc/libisc-nosymtbl.a(md5.o)
> EVP_MD_CTX_free                     ../../lib/isc/libisc-nosymtbl.a(md5.o)
> ld: fatal: symbol referencing errors. No output written to
> isc-hmac-fixuptmp1
> gmake[2]: *** [Makefile:495: isc-hmac-fixup] Error 1
> gmake[2]: Leaving directory
> '/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/bin/tools'
> gmake[1]: *** [Makefile:79: subdirs] Error 1
> gmake[1]: Leaving directory
> '/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/bin'
> gmake: *** [Makefile:88: subdirs] Error 1
> 
> 
> That is just bizarre because I can cd into the bin/tools directory and
> do the link stage manually just fine :
> 
> alpha $ /opt/developerstudio12.6/bin/cc -mt \
>> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003 \
>> -I../.. \
>> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/dns/include \
>> -I../../lib/dns/include \
>> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include \
>> -I../../lib/isc \
>> -I../../lib/isc/include \
>> -I../../lib/isc/unix/include \
>> -I../../lib/isc/pthreads/include \
>> -I../../lib/isc/noatomic/include \
>> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isccfg/include \
>> -I../../lib/isccfg/include \
>> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/lwres/include \
>> -I../../lib/lwres/unix/include \
>> -I../../lib/lwres/include \
>> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/bind9/include \
>> -I../../lib/bind9/include \
>> -I/opt/bw/include \
>> -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DOPENSSL \
>> -DVERSION=\"9.11.31\" \
>> -D_XPG4_2 -D__EXTENSIONS__ -std=iso9899:2011 \
>> -m64 -xarch=sparc -g -mc -xs -errfmt=error -erroff=%none -errshort=full \
>> -errtags=yes -errwarn=%none -ftrap=%none -xbuiltin=%none -xildoff \
>> -xlibmieee -xstrconst -xcode=pic32 -xmemalign=8s -xnolibmil -xunroll=1 \
>> -xregs=no%appl -xdebugformat=dwarf -KPIC \
>> -H -# -c isc-hmac-fixup-symtbl.c
> ### cc: Note: NLSPATH =
> /opt/developerstudio12.6/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/developerstudio12.6/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
> ### cc: Note: TMPDIR = /var/tmp/dclarke
> ###     command line files and options (expanded):
> ### -mt=yes -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003 -I../..
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/dns/include
> -I../../lib/dns/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include
> -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include
> -I../../lib/isc/pthreads/include -I../../lib/isc/noatomic/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isccfg/include
> -I../../lib/isccfg/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/lwres/include
> -I../../lib/lwres/unix/include -I../../lib/lwres/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/bind9/include
> -I../../lib/bind9/include -I/opt/bw/include -D_REENTRANT
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DOPENSSL -DVERSION="9.11.31"
> -D_XPG4_2 -D__EXTENSIONS__ -std=c11 -m64 -xarch=sparc
> -xdebuginfo=line,param,variable,tagtype,codetag,decl -xglobalize=yes
> -xpatchpadding=fix -xkeep_unref=funcs,vars -mc -xs=yes -errfmt=error
> -erroff=%none -errshort=full -errtags=yes -errwarn=%none -ftrap=%none
> -xbuiltin=%none -xlibmieee -xstrconst -xmemalign=8s -xnolibmil
> -xunroll=1 -xregs=no%appl -xdebugformat=dwarf -xcode=pic32 -H -# -c
> isc-hmac-fixup-symtbl.c
> /opt/developerstudio12.6/lib/compilers/bin/acomp -D_REENTRANT
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DOPENSSL -DVERSION="9.11.31"
> -D_XPG4_2 -D__EXTENSIONS__ -H -Qy -std=c11 -i isc-hmac-fixup-symtbl.c
> -D__SunOS_5_10 -D__SunOS_RELEASE=0x051000 -D__SUNPRO_C=0x5150 -D__unix
> -D__SVR4__ -D__svr4__ -D__SVR4 -D__sun -D__sun__ -D__SunOS -D__sparcv9
> -D__sparc_v9__ -D__sparc -D__sparc__ -D_LP64 -D__LP64__ -D__arch64__
> -D__ORDER_LITTLE_ENDIAN__=1234 -D__ORDER_BIG_ENDIAN__=4321
> -D__BYTE_ORDER__=__ORDER_BIG_ENDIAN__ -D__BUILTIN_VA_ARG_INCR
> -D__C11FEATURES__ -D__C99FEATURES__ -D__STRICT_ANSI__
> -D__PRAGMA_REDEFINE_EXTNAME -Dunix -Dsun -Dsparc -D__RESTRICT
> -D__FLT_EVAL_METHOD__=0 -D_REENTRANT -D__SUN_PREFETCH
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003 -I../..
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/dns/include
> -I../../lib/dns/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include
> -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include
> -I../../lib/isc/pthreads/include -I../../lib/isc/noatomic/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isccfg/include
> -I../../lib/isccfg/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/lwres/include
> -I../../lib/lwres/unix/include -I../../lib/lwres/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/bind9/include
> -I../../lib/bind9/include -I/opt/bw/include -I-xbuiltin
> -I/opt/developerstudio12.6/lib/compilers/include/cc -2K -errfmt=error
> -erroff=%none -errshort=full -errwarn=%none -errtags -xbuiltin=%none
> -strconst -fsimple=0 -m64 -fparam_ir -fparam_ir -xglobalize=yes
> -xdebuginfo=line,param,variable,tagtype,codetag,decl
> -xkeep_unref=funcs,vars -xF=%none
> -xdbggen=dwarf+usedonly+incl+line+param+variable+tagtype+codetag+decl
> -xldscope=global -xivdep=loop -xanalyze=code -c99OS
> "-g/opt/developerstudio12.6/bin/cc -mt
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003 -I../..
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/dns/include
> -I../../lib/dns/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include
> -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include
> -I../../lib/isc/pthreads/include -I../../lib/isc/noatomic/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isccfg/include
> -I../../lib/isccfg/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/lwres/include
> -I../../lib/lwres/unix/include -I../../lib/lwres/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/bind9/include
> -I../../lib/bind9/include -I/opt/bw/include -D_REENTRANT
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS='64' -DOPENSSL
> -DVERSION='"9.11.31"' -D_XPG4_2 -D__EXTENSIONS__ -std=iso9899:2011 -m64
> -xarch=sparc -g -mc -xs -errfmt=error -erroff=%none -errshort=full
> -errtags=yes -errwarn=%none -ftrap=%none -xbuiltin=%none -xildoff
> -xlibmieee -xstrconst -xcode=pic32 -xmemalign=8s -xnolibmil -xunroll=1
> -xregs=no%appl -xdebugformat=dwarf -KPIC -H -c " -destination_ir=iropt
> -r /var/tmp/dclarke/acomp.1620217682.10303.01.ir
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include/isc/backtrace.h
> 
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include/isc/types.h
>                /usr/include/stdbool.h
>                        /usr/include/sys/feature_tests.h
>                                /usr/include/sys/ccompile.h
>                                /usr/include/sys/isa_defs.h
> 
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include/isc/bind9.h
> 
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include/isc/platform.h
>                                /usr/include/limits.h
>                                        /usr/include/iso/limits_iso.h
>                                        /usr/include/sys/int_limits.h
>                                        /usr/include/sys/unistd.h
>                /usr/include/inttypes.h
>                        /usr/include/sys/inttypes.h
>                                /usr/include/sys/int_types.h
>                                /usr/include/sys/int_const.h
>                                /usr/include/sys/int_fmtio.h
>                        /usr/include/sys/stdint.h
>                ../../lib/isc/unix/include/isc/offset.h
>                        /usr/include/sys/types.h
>                                /usr/include/sys/machtypes.h
>                                /usr/include/sys/select.h
>                                        /usr/include/sys/time_impl.h
>                                        /usr/include/sys/time.h
>                                                /usr/include/sys/types.h
>                                                /usr/include/time.h
> 
> /usr/include/iso/time_iso.h
>                                                /usr/include/sys/select.h
>                        /usr/include/stddef.h
>                                /usr/include/iso/stddef_iso.h
> 
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include/isc/list.h
> 
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include/isc/assertions.h
> 
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include/isc/lang.h
> 
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include/isc/likely.h
> cat /var/tmp/dclarke/acomp.1620217682.10303.01.ir
>> /var/tmp/dclarke/acomp.1620217682.10303.02.ir
> /opt/developerstudio12.6/lib/compilers/bin/previse -Qy -erroff=%none
> -errwarn=%none -errtags -O3 -xarch=sparc -m64 -xchip=generic
> -xcache=generic -xdebuginfo=line,param,variable,tagtype,codetag,decl
> -depend -xbuiltin=%none -xprefetch=auto,explicit -xprefetch_level=1
> -xprefetch_auto_type=no%indirect_array_access -o
> /var/tmp/dclarke/iropt.1620217682.10303.03.ir
> "-Astatic_err_check:previse_iropt=on:umr=on:aob=on:free=on:nulld=on:nullc=on:msg_ctl_level=0:analytics=off:stderr_output=on"
> /var/tmp/dclarke/acomp.1620217682.10303.02.ir
> /opt/developerstudio12.6/lib/compilers/bin/cg -Qy -fsimple=0
> -xarch=sparc -m64 -xchip=generic -xcache=generic -comdat -ftrap=%none
> -xpatchpadding=fix -xdebuginfo=line,param,variable,tagtype,codetag,decl
> -xkeep_unref=funcs,vars -s -xbuiltin=%none -xcode=pic32 -xannotate=yes
> -xmemalign=8s -xprefetch=auto,explicit
> -xprefetch_auto_type=no%indirect_array_access -xcheck=stkovf
> -xcheck=noreturn -xthreadvar=dynamic -xregs=no%appl -unroll=1
> -xvector=no -mt -oo isc-hmac-fixup-symtbl.o -ir
> /var/tmp/dclarke/acomp.1620217682.10303.01.ir
> /usr/ccs/bin/mcs -c isc-hmac-fixup-symtbl.o
> alpha $
> 
> OKee and that looks like it worked.
> 
> I did go back and rebuild 9.11.26 with no issue. However this same
> strange bizarre pile of undefined symbols appears when I try to build
> 9.11.27 and 9.11.28 and of course 9.11.31.
> 
> Any hints at all would be great.
> 
> 
> 
> -- 
> Dennis Clarke
> RISC-V/SPARC/PPC/ARM/CISC
> UNIX and Linux spoken
> GreyBeard and suspenders optional
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


From dclarke at blastwave.org  Wed May  5 13:14:25 2021
From: dclarke at blastwave.org (Dennis Clarke)
Date: Wed, 5 May 2021 09:14:25 -0400
Subject: Slightly baffled about Undefined symbols that are in OpenSSL
In-Reply-To: <E40F8656-E055-4AF0-85F1-CBE5A68463E0@isc.org>
References: <a23e80ff-b2ff-fd7b-09ea-583b324e5590@blastwave.org>
 <E40F8656-E055-4AF0-85F1-CBE5A68463E0@isc.org>
Message-ID: <ffb0bb80-b04a-1566-d842-9fd5818f7867@blastwave.org>

On 5/5/21 08:35, Mark Andrews wrote:
> Use a non EoL version of OpenSSL. 
> 
alpha $ openssl version
OpenSSL 1.1.1k  25 Mar 2021

Not a problem. I have all that sorted out and I did go climb all over
the Makefile in bin/tools and see that it is borked. So I did some
un-bork and now the compile completes.

I will dig a bit and see where things went wrong after 9.11.26.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

From dot at dotat.at  Wed May  5 13:19:14 2021
From: dot at dotat.at (Tony Finch)
Date: Wed, 5 May 2021 14:19:14 +0100
Subject: REST API for recursive queries
In-Reply-To: <HE1PR0301MB21884C767B53C48628ADEB8EDF599@HE1PR0301MB2188.eurprd03.prod.outlook.com>
References: <HE1PR0301MB21888B534B36150A02B7DED6DF5A9@HE1PR0301MB2188.eurprd03.prod.outlook.com>
 <HE1PR0301MB21884C767B53C48628ADEB8EDF599@HE1PR0301MB2188.eurprd03.prod.outlook.com>
Message-ID: <4f747ef-20c9-90d7-4c40-2e1a61c42db9@dotat.at>

Roee Mayerowicz <roee at cyberpion.com> wrote:

> I have ~700k (and growing) domain names that should be resolved daily.
> I'm trying to make it efficient as possible using the recursive BIND
> server (do you know a better option?), the goal is to get 2000 queries
> per second with minimum server\s cost.

I do bulk lookups on that kind of scale when I am preparing a recursive
server to go into production. I use this small (250 line) program as a
front end to adns that works the way I like. It can easily manage
thousands of queries per second.

https://git.uis.cam.ac.uk/x/uis/ipreg/adns-masterfile.git

(That URL may stop working within the next few months because we're moving
to GitLab and my old git server will be shut down, though I would like to
find somewhere to host redirection tombstones...)

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
North Foreland to Selsey Bill: Westerly 5 or 6, decreasing 3 or 4,
becoming variable 2 to 4 later. Slight or moderate, becoming slight
later. Showers, occasional rain later. Moderate or good, occasionally
poor.


From Axel.Rau at Chaos1.DE  Wed May  5 19:09:52 2021
From: Axel.Rau at Chaos1.DE (Axel Rau)
Date: Wed, 5 May 2021 21:09:52 +0200
Subject: How to return REFUSED
Message-ID: <A29DD154-300C-4063-8A95-FA2621254595@Chaos1.DE>

I have,

	allow-query { any; };
	allow-query-cache { recursive-users; };
	allow-recursion { recursive-users; };

How can I make sure that none recursive-users get a REFUSED if query is recursive?

Axel

PS: I want to minimize the responses to this amplification attack:
- - -
19:05:18.703238 185.230.55.130.30120 > 91.216.35.71.53: [no udp cksum] 1+ RRSIG? pizzaseo.com.(30) (ttl 249, id 33043, len 58)
19:05:18.703568 91.216.35.71.53 > 185.230.55.130.30120: [udp sum ok] 1- q: RRSIG? pizzaseo.com. 0/13/14 ns: com. NS j.gtld-servers.net., com. NS m.gtld-servers.net., com. NS c.gtld-servers.net., com. NS b.gtld-servers.net., com. NS d.gtld-servers.net., com. NS e.gtld-servers.net., com. NS l.gtld-servers.net., com. NS f.gtld-servers.net., com. NS h.gtld-servers.net., com. NS i.gtld-servers.net., com. NS a.gtld-servers.net., com. NS k.gtld-servers.net., com. NS g.gtld-servers.net. ar: m.gtld-servers.net. A 192.55.83.30, l.gtld-servers.net. A 192.41.162.30, k.gtld-servers.net. A 192.52.178.30, j.gtld-servers.net. A 192.48.79.30, i.gtld-servers.net. A 192.43.172.30, h.gtld-servers.net. A 192.54.112.30, g.gtld-servers.net. A 192.42.93.30, f.gtld-servers.net. A 192.35.51.30, e.gtld-servers.net. A 192.12.94.30, d.gtld-servers.net. A 192.31.80.30, c.gtld-servers.net. A 192.26.92.30, b.gtld-servers.net. A 192.33.14.30, a.gtld-servers.net. A 192.5.6.30, m.gtld-servers.net. AAAA 2001:501:b1f9::30(490) (ttl 63, id 11754, len 518)
- - -
---
PGP-Key: CDE74120  ?  computing @ chaos claudius

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210505/ddff40ff/attachment.bin>

From kevin.darcy at stellantis.com  Wed May  5 20:06:29 2021
From: kevin.darcy at stellantis.com (Kevin Darcy)
Date: Wed, 5 May 2021 16:06:29 -0400
Subject: How to return REFUSED
In-Reply-To: <A29DD154-300C-4063-8A95-FA2621254595@Chaos1.DE>
References: <A29DD154-300C-4063-8A95-FA2621254595@Chaos1.DE>
Message-ID: <CAAeHe+wirgvcC8SD2D-KBvP7fC6km0YLj4-hFat_KQ69rK4DWg@mail.gmail.com>

[ Classification Level: GENERAL BUSINESS ]

I just checked the ARM, and it denotes that "match-recursive-only"
(boolean) still exists for views. So, you might be able to set up a special
view with that, as well as a negated match-clients, specifying allow-query
{ none; }. Put it as the first view, and both non-recursive queries, and
queries from your "recursive-users" ACL, will fall through to subsequent
views.


                        - Kevin

P.S. ISC's "understanding views" knowledgebase article doesn't mention
match-recursive-only, so there is a discrepancy there. Either the feature
has been removed, and the ARM documentation hasn't been updated to reflect
it, or the knowledgebase article only focuses on the most common
view-matching criteria, omitting match-recursive-only, since the use cases
for that are very rare.


On Wed, May 5, 2021 at 3:10 PM Axel Rau <Axel.Rau at chaos1.de> wrote:

> I have,
>
>         allow-query { any; };
>         allow-query-cache { recursive-users; };
>         allow-recursion { recursive-users; };
>
> How can I make sure that none recursive-users get a REFUSED if query is
> recursive?
>
> Axel
>
> PS: I want to minimize the responses to this amplification attack:
> - - -
> 19:05:18.703238 185.230.55.130.30120 > 91.216.35.71.53: [no udp cksum] 1+
> RRSIG? pizzaseo.com.(30) (ttl 249, id 33043, len 58)
> 19:05:18.703568 91.216.35.71.53 > 185.230.55.130.30120: [udp sum ok] 1- q:
> RRSIG? pizzaseo.com. 0/13/14 ns: com. NS j.gtld-servers.net., com. NS
> m.gtld-servers.net., com. NS c.gtld-servers.net., com. NS
> b.gtld-servers.net., com. NS d.gtld-servers.net., com. NS
> e.gtld-servers.net., com. NS l.gtld-servers.net., com. NS
> f.gtld-servers.net., com. NS h.gtld-servers.net., com. NS
> i.gtld-servers.net., com. NS a.gtld-servers.net., com. NS
> k.gtld-servers.net., com. NS g.gtld-servers.net. ar: m.gtld-servers.net.
> A 192.55.83.30, l.gtld-servers.net. A 192.41.162.30, k.gtld-servers.net.
> A 192.52.178.30, j.gtld-servers.net. A 192.48.79.30, i.gtld-servers.net.
> A 192.43.172.30, h.gtld-servers.net. A 192.54.112.30, g.gtld-servers.net.
> A 192.42.93.30, f.gtld-servers.net. A 192.35.51.30, e.gtld-servers.net. A
> 192.12.94.30, d.gtld-servers.net. A 192.31.80.30, c.gtld-servers.net. A
> 192.26.92.30, b.gtld-servers.net. A 192.33.14.30, a.gtld-servers.net. A
> 192.5.6.30, m.gtld-servers.net. AAAA 2001:501:b1f9::30(490) (ttl 63, id
> 11754, len 518)
> - - -
> ---
> PGP-Key: CDE74120  ?  computing @ chaos claudius
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210505/673f3a5c/attachment.htm>

From dclarke at blastwave.org  Thu May  6 01:59:27 2021
From: dclarke at blastwave.org (Dennis Clarke)
Date: Wed, 5 May 2021 21:59:27 -0400
Subject: where are the testing docs ?
Message-ID: <66858559-2ff9-083e-c26f-0a401c18a011@blastwave.org>


Hey there. I looked in the README and I dont see an INSTALL file at all
 so I have to assume that the testing docs exist somewhere.

I build 9.11.31 after wrangling the Makefile(s) everywhere and now I
have built a separate machine to run the tests.  I needed that because
there are a bucket of interfaces needed and I can not do that on any
large production hardware easily. So anyways ... where are the testing
docs ?


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

From uhlar at fantomas.sk  Thu May  6 10:05:35 2021
From: uhlar at fantomas.sk (Matus UHLAR - fantomas)
Date: Thu, 6 May 2021 12:05:35 +0200
Subject: How to return REFUSED
In-Reply-To: <A29DD154-300C-4063-8A95-FA2621254595@Chaos1.DE>
References: <A29DD154-300C-4063-8A95-FA2621254595@Chaos1.DE>
Message-ID: <20210506100535.GB18648@fantomas.sk>

On 05.05.21 21:09, Axel Rau wrote:
>	allow-query { any; };
>	allow-query-cache { recursive-users; };
>	allow-recursion { recursive-users; };
>
>How can I make sure that none recursive-users get a REFUSED if query is recursive?

I thought this is the default...
>PS: I want to minimize the responses to this amplification attack:
>19:05:18.703238 185.230.55.130.30120 > 91.216.35.71.53: [no udp cksum] 1+ RRSIG? pizzaseo.com.(30) (ttl 249, id 33043, len 58)
>19:05:18.703568 91.216.35.71.53 > 185.230.55.130.30120: [udp sum ok] 1- q: RRSIG? pizzaseo.com. 0/13/14 ns: com. NS j.gtld-servers.net., com. NS m.gtld-servers.net., com. NS c.gtld-servers.net., com. NS b.gtld-servers.net., com. NS d.gtld-servers.net., com. NS e.gtld-servers.net., com. NS l.gtld-servers.net., com. NS f.gtld-servers.net., com. NS h.gtld-servers.net., com. NS i.gtld-servers.net., com. NS a.gtld-servers.net., com. NS k.gtld-servers.net., com. NS g.gtld-servers.net. ar: m.gtld-servers.net. A 192.55.83.30, l.gtld-servers.net. A 192.41.162.30, k.gtld-servers.net. A 192.52.178.30, j.gtld-servers.net. A 192.48.79.30, i.gtld-servers.net. A 192.43.172.30, h.gtld-servers.net. A 192.54.112.30, g.gtld-servers.net. A 192.42.93.30, f.gtld-servers.net. A 192.35.51.30, e.gtld-servers.net. A 192.12.94.30, d.gtld-servers.net. A 192.31.80.30, c.gtld-servers.net. A 192.26.92.30, b.gtld-servers.net. A 192.33.14.30, a.gtld-servers.net. A 192.5.6.30, m.gtld-servers.net. AAAA 2001:501:b1f9::30(490) (ttl 63, id 11754, len 518)

... exactly because of this reason.

Which named version do you run?
do you use views?

-- 
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
2B|!2B, that's a question!

From dot at dotat.at  Thu May  6 14:45:07 2021
From: dot at dotat.at (Tony Finch)
Date: Thu, 6 May 2021 15:45:07 +0100
Subject: How to return REFUSED
In-Reply-To: <A29DD154-300C-4063-8A95-FA2621254595@Chaos1.DE>
References: <A29DD154-300C-4063-8A95-FA2621254595@Chaos1.DE>
Message-ID: <7dfa2e0-90ec-71d8-cd83-985d38687b1c@dotat.at>

Axel Rau <Axel.Rau at Chaos1.DE> wrote:

> I have,
>
> 	allow-query { any; };
> 	allow-query-cache { recursive-users; };
> 	allow-recursion { recursive-users; };
>
> How can I make sure that none recursive-users get a REFUSED if query is recursive?

Weird! I think your config should do what you want so I wonder why it
isn't working. Your server is responding to the problem queries with a
referral from the root zone, so have you configured your server with a
local authoritative copy of the root?

There's a broader issue here:

Usually when you have a server that is providing recursive service to
anyone, it is best to set the allow-query ACL to cover just your users, so
everyone else gets REFUSED.

This means that your recursive server cannot also be used as an
authoritative server advertised in NS records. Your public authoritative
servers should be authoritative-only and not offer recursion to anyone.

> PS: I want to minimize the responses to this amplification attack:

Ooh, RRSIG queries are fun. They are like a stealth ANY query.

BIND has several tools for dealing with this kind of junk:

  * RRL is very effective

  * minimal-any also minimizes responses to RRSIG queries

  * minimal-responses can also help to reduce packet sizes

Your server is responding with a referral from the root, so minimal-any
won't have any effect on the response. And because it's a referral, the
glue etc. is not optional, so there's nothing that minimal-responses can
omit. So in your situation the most useful things to do would be:

  * tighten up your allow-query ACL

  * if you can't do that, use RRL (you can add recursive-users to the
    exempt-clients list)

  * configure separate views for recursive-users and others; do not
    include the root zone in your external view

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
The Minch: North 6 or 7, backing northwest 3 to 5. Rough or very rough
at first northeast of skye, otherwise slight or moderate. Wintry
showers. Good, occasionally poor.


From dot at dotat.at  Thu May  6 14:50:17 2021
From: dot at dotat.at (Tony Finch)
Date: Thu, 6 May 2021 15:50:17 +0100
Subject: where are the testing docs ?
In-Reply-To: <66858559-2ff9-083e-c26f-0a401c18a011@blastwave.org>
References: <66858559-2ff9-083e-c26f-0a401c18a011@blastwave.org>
Message-ID: <dd1ff597-3fdc-8258-5da0-f0da9a1fda2b@dotat.at>

Dennis Clarke via bind-users <bind-users at lists.isc.org> wrote:
>
> Hey there. I looked in the README and I dont see an INSTALL file at all
>  so I have to assume that the testing docs exist somewhere.

Have a look at

https://gitlab.isc.org/isc-projects/bind9/-/tree/main/bin/tests/system

There are some more notes in:

https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/dev

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
disperse power, foster diversity, and nurture creativity


From dot at dotat.at  Thu May  6 14:52:16 2021
From: dot at dotat.at (Tony Finch)
Date: Thu, 6 May 2021 15:52:16 +0100
Subject: Log queried forwarder IP address
In-Reply-To: <8926947f-c9c1-4ceb-5a86-c330329caca4@gmail.com>
References: <8926947f-c9c1-4ceb-5a86-c330329caca4@gmail.com>
Message-ID: <50f1cc67-ceeb-5c65-2b38-e78395887470@dotat.at>

Levente Birta <blevi.linux at gmail.com> wrote:
>
> I have a caching resolver. Is it possible to log the IP address of the queried
> forwarder without too much overhead?

dnstap might be what you want, but it's a bit intricate.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
Irish Sea: Northwesterly 4 to 6, occasionally 7 in north. Slight or
moderate. Showers. Good.

From dclarke at blastwave.org  Thu May  6 15:03:21 2021
From: dclarke at blastwave.org (Dennis Clarke)
Date: Thu, 6 May 2021 11:03:21 -0400
Subject: where are the testing docs ?
In-Reply-To: <dd1ff597-3fdc-8258-5da0-f0da9a1fda2b@dotat.at>
References: <66858559-2ff9-083e-c26f-0a401c18a011@blastwave.org>
 <dd1ff597-3fdc-8258-5da0-f0da9a1fda2b@dotat.at>
Message-ID: <b42b34ac-fc4c-6286-d43c-0710c5f4960f@blastwave.org>

On 5/6/21 10:50, Tony Finch wrote:
> Dennis Clarke via bind-users <bind-users at lists.isc.org> wrote:
>>
>> Hey there. I looked in the README and I dont see an INSTALL file at all
>>  so I have to assume that the testing docs exist somewhere.
> 
> Have a look at
> 
> https://gitlab.isc.org/isc-projects/bind9/-/tree/main/bin/tests/system

Good stuff, thank you. I was searching high and low and I did see :

    https://kb.isc.org/docs/aa-00768

However that says nothing at all about running the testsuite after a
nice clean build. Which is non-trivial now that Makefiles are slightly
borked but that is another issue.

Perhaps the docs at https://kb.isc.org/docs/aa-00768 can be updated to
at least point to the gutlab link above?

> 
> There are some more notes in:
> 
> https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/dev
> 

I will glance there but for now I think the testsuite should be able to
at least run.

Dennis


From ondrej at isc.org  Thu May  6 15:24:04 2021
From: ondrej at isc.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Thu, 6 May 2021 17:24:04 +0200
Subject: where are the testing docs ?
In-Reply-To: <b42b34ac-fc4c-6286-d43c-0710c5f4960f@blastwave.org>
References: <b42b34ac-fc4c-6286-d43c-0710c5f4960f@blastwave.org>
Message-ID: <12DDE1B3-B32F-439C-AF53-356D2AFF6210@isc.org>

FTR the test suite is meant to be used by developers. There?s little value to use it for validating the production systems.

Generally speaking, having the dependencies and test interfaces (`sudo bin/tests/system/ifconfig.sh up`) and running `make check` is enough.

Ond?ej 
--
Ond?ej Sur? ? ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 6. 5. 2021, at 17:03, Dennis Clarke via bind-users <bind-users at lists.isc.org> wrote:
> 
> ?On 5/6/21 10:50, Tony Finch wrote:
>> Dennis Clarke via bind-users <bind-users at lists.isc.org> wrote:
>>> 
>>> Hey there. I looked in the README and I dont see an INSTALL file at all
>>> so I have to assume that the testing docs exist somewhere.
>> 
>> Have a look at
>> 
>> https://gitlab.isc.org/isc-projects/bind9/-/tree/main/bin/tests/system
> 
> Good stuff, thank you. I was searching high and low and I did see :
> 
>    https://kb.isc.org/docs/aa-00768
> 
> However that says nothing at all about running the testsuite after a
> nice clean build. Which is non-trivial now that Makefiles are slightly
> borked but that is another issue.
> 
> Perhaps the docs at https://kb.isc.org/docs/aa-00768 can be updated to
> at least point to the gutlab link above?
> 
>> 
>> There are some more notes in:
>> 
>> https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/dev
>> 
> 
> I will glance there but for now I think the testsuite should be able to
> at least run.
> 
> Dennis
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


From dclarke at blastwave.org  Thu May  6 15:57:58 2021
From: dclarke at blastwave.org (Dennis Clarke)
Date: Thu, 6 May 2021 11:57:58 -0400
Subject: where are the testing docs ?
In-Reply-To: <12DDE1B3-B32F-439C-AF53-356D2AFF6210@isc.org>
References: <b42b34ac-fc4c-6286-d43c-0710c5f4960f@blastwave.org>
 <12DDE1B3-B32F-439C-AF53-356D2AFF6210@isc.org>
Message-ID: <f3ceaf81-d084-9d97-5cc1-25b9d2ed72ae@blastwave.org>

On 5/6/21 11:24, Ond?ej Sur? wrote:
> FTR the test suite is meant to be used by developers. There?s little value to use it for validating the production systems.
> 
> Generally speaking, having the dependencies and test interfaces (`sudo bin/tests/system/ifconfig.sh up`) and running `make check` is enough.
> 

I do NOT trust a build result where I had to go hacking into all the
Makefiles just to get it to build. You install without doing testing?

Dennis

From Axel.Rau at chaos1.de  Thu May  6 16:41:58 2021
From: Axel.Rau at chaos1.de (Axel Rau)
Date: Thu, 6 May 2021 18:41:58 +0200
Subject: How to return REFUSED
In-Reply-To: <7dfa2e0-90ec-71d8-cd83-985d38687b1c@dotat.at>
References: <A29DD154-300C-4063-8A95-FA2621254595@Chaos1.DE>
 <7dfa2e0-90ec-71d8-cd83-985d38687b1c@dotat.at>
Message-ID: <B79AE8B8-D151-4395-8EB3-2DE03C10556A@Chaos1.DE>



> Am 06.05.2021 um 16:45 schrieb Tony Finch <dot at dotat.at>:
> 
> Axel Rau <Axel.Rau at Chaos1.DE> wrote:
> 
>> I have,
>> 
>> 	allow-query { any; };
>> 	allow-query-cache { recursive-users; };
>> 	allow-recursion { recursive-users; };
>> 
>> How can I make sure that none recursive-users get a REFUSED if query is recursive?
> 
> Weird! I think your config should do what you want so I wonder why it
> isn't working. Your server is responding to the problem queries with a
> referral from the root zone, so have you configured your server with a
> local authoritative copy of the root?

Yes.
> 
> There's a broader issue here:
> 
> Usually when you have a server that is providing recursive service to
> anyone, it is best to set the allow-query ACL to cover just your users, so
> everyone else gets REFUSED.
> 
> This means that your recursive server cannot also be used as an
> authoritative server advertised in NS records. Your public authoritative
> servers should be authoritative-only and not offer recursion to anyone.
> 
>> PS: I want to minimize the responses to this amplification attack:
> 
> Ooh, RRSIG queries are fun. They are like a stealth ANY query.
> 
> BIND has several tools for dealing with this kind of junk:
> 
>  * RRL is very effective
> 
>  * minimal-any also minimizes responses to RRSIG queries
> 
>  * minimal-responses can also help to reduce packet sizes
> 
> Your server is responding with a referral from the root, so minimal-any
> won't have any effect on the response. And because it's a referral, the
> glue etc. is not optional, so there's nothing that minimal-responses can
> omit. So in your situation the most useful things to do would be:
> 
>  * tighten up your allow-query ACL
> 
>  * if you can't do that, use RRL (you can add recursive-users to the
>    exempt-clients list)
> 
>  * configure separate views for recursive-users and others; do not
>    include the root zone in your external view

Currently, I have:

    minimal-responses yes;
	require-server-cookie yes;

	rate-limit {
        responses-per-second 5;
        exempt-clients { recursive-users; };
    };

which do not really help.

This NS has some other clients in the DMZ LAN, so I need Views.
I gave up with views years ago and I have now to learn to use them with all the recent stuff, like in-view.
in-view can be helpful to reference the auth zones in the local view, I guess.

Thanks for your your comprehensive explanation,
Axel
---
PGP-Key: CDE74120  ?  computing @ chaos claudius

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/2f80ec80/attachment-0001.bin>

From Axel.Rau at Chaos1.DE  Thu May  6 16:45:26 2021
From: Axel.Rau at Chaos1.DE (Axel Rau)
Date: Thu, 6 May 2021 18:45:26 +0200
Subject: How to return REFUSED
In-Reply-To: <20210506100535.GB18648@fantomas.sk>
References: <A29DD154-300C-4063-8A95-FA2621254595@Chaos1.DE>
 <20210506100535.GB18648@fantomas.sk>
Message-ID: <12531D0D-E1B9-40BE-879D-E984377685F6@Chaos1.DE>



> Am 06.05.2021 um 12:05 schrieb Matus UHLAR - fantomas <uhlar at fantomas.sk>:
> 
> 
> Which named version do you run?
9.16.15
> do you use views?
No, but after reading Tonys response, I?m  now starting to convert my config to views.

Axel
---
PGP-Key: CDE74120  ?  computing @ chaos claudius

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/ff8520eb/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/ff8520eb/attachment.bin>

From james.j.decaro3.civ at mail.mil  Thu May  6 16:47:32 2021
From: james.j.decaro3.civ at mail.mil (DeCaro, James John (Jim) CIV DISA FE (USA))
Date: Thu, 6 May 2021 16:47:32 +0000
Subject: Installing BIND 9.16.15
Message-ID: <SN5P111MB0574158193F648E6B34AF36BD0589@SN5P111MB0574.NAMP111.PROD.OUTLOOK.COM>

Hello,

I have what is probably a very rudimentary question, but I am stuck.

I am attempting to upgrade BIND on a Solaris 11.4 x86 virtual platform.  I have installed BIND successfully up to version 9.16.12 using  ./configure --enable-full-report --with-gssapi=krb5-config --sysconfdir=/etc --with-openssl=/usr/local --localstatedir=/var --enable-fixed-rrset  

I also added environment variables: export LDFLAGS="-L/usr/local/lib -R/usr/local/lib"  [and]  export PKG_CONFIG_PATH="usr/lib/pkgconfig:/usr/local/lib/pkgconfig (for libuv)

This time ./configure aborts with errors related to linking gssapi to kerberos

checking krb5.h presence... yes
checking for krb5.h... yes
checking krb5-config linking as -lkrb5 -lk5crypto -lcom_err... krb5-config: could not determine proper GSSAPI linkage
checking for GSSAPI library, non krb5-config method... looking in /usr/lib
checking for gssapi.h... (cached) yes
checking for gssapi/gssapi.h... (cached) yes
checking gssapi_krb5.h usability... no
checking gssapi_krb5.h presence... no
checking for gssapi_krb5.h... no
checking gssapi/gssapi_krb5.h usability... no
checking gssapi/gssapi_krb5.h presence... no
checking for gssapi/gssapi_krb5.h... no
checking for krb5.h... (cached) yes
checking for krb5/krb5.h... (cached) yes
checking kerberosv5/krb5.h usability... no
checking kerberosv5/krb5.h presence... no
checking for kerberosv5/krb5.h... no
checking linking as -lgssapi_krb5... no
checking linking as -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err... no
checking linking as -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv... no
checking linking as -lgssapi... no
checking linking as -lgssapi -lkrb5 -ldes -lcrypt -lasn1 -lroken -lcom_err... no
checking linking as -lgssapi -lkrb5 -lcrypt -lasn1 -lroken -lcom_err... no
checking linking as -lgssapi -lkrb5 -lgssapi_krb5 -lcrypt -lasn1 -lroken -lcom_err... no
checking linking as -lgssapi -lkrb5 -lhx509 -lcrypt -lasn1 -lroken -lcom_err... no
checking linking as -lgss -lkrb5... no
configure: error: could not determine proper GSSAPI linkage

I am looking all through the internet, the config.log, README etc. and I can't seem to find a solution. 
krb5.h is located at 
/usr/include/kerberosv5/krb5/krb5.h
/usr/include/kerberosv5/krb5.h
/usr/lib/krb5/krb5.h  

I am pretty sure it is a matter of setting the correct path variable, but I am new at this and I can't figure it out yet.  Any help would be appreciated.

Jim 


From Axel.Rau at chaos1.de  Thu May  6 16:54:00 2021
From: Axel.Rau at chaos1.de (Axel Rau)
Date: Thu, 6 May 2021 18:54:00 +0200
Subject: How to return REFUSED
In-Reply-To: <CAAeHe+wirgvcC8SD2D-KBvP7fC6km0YLj4-hFat_KQ69rK4DWg@mail.gmail.com>
References: <A29DD154-300C-4063-8A95-FA2621254595@Chaos1.DE>
 <CAAeHe+wirgvcC8SD2D-KBvP7fC6km0YLj4-hFat_KQ69rK4DWg@mail.gmail.com>
Message-ID: <3EB669C9-C2D2-41AD-9AA0-D9853AD343B6@Chaos1.DE>



> Am 05.05.2021 um 22:06 schrieb Kevin Darcy via bind-users <bind-users at lists.isc.org <mailto:bind-users at lists.isc.org>>:
> 
> I just checked the ARM, and it denotes that "match-recursive-only" (boolean) still exists for views. So, you might be able to set up a special view with that, as well as a negated match-clients, specifying allow-query { none; }. Put it as the first view, and both non-recursive queries, and queries from your "recursive-users" ACL, will fall through to subsequent views.
> 
> P.S. ISC's "understanding views" knowledgebase article doesn't mention match-recursive-only, so there is a discrepancy there. Either the feature has been removed, and the ARM documentation hasn't been updated to reflect it, or the knowledgebase article only focuses on the most common view-matching criteria, omitting match-recursive-only, since the use cases for that are very rare.


Thanks, Kevin for your quick response, which let me start converting to views,

Axel
---
PGP-Key: CDE74120  ?  computing @ chaos claudius

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/0268937f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/0268937f/attachment-0001.bin>

From ondrej at isc.org  Thu May  6 16:56:45 2021
From: ondrej at isc.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Thu, 6 May 2021 18:56:45 +0200
Subject: Installing BIND 9.16.15
In-Reply-To: <SN5P111MB0574158193F648E6B34AF36BD0589@SN5P111MB0574.NAMP111.PROD.OUTLOOK.COM>
References: <SN5P111MB0574158193F648E6B34AF36BD0589@SN5P111MB0574.NAMP111.PROD.OUTLOOK.COM>
Message-ID: <1B2F4956-4069-4C85-93B7-D96F7CCAAFB6@isc.org>

See https://gitlab.isc.org/isc-projects/bind9/-/issues/2667

--
Ond?ej Sur? ? ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 6. 5. 2021, at 18:48, DeCaro, James John (Jim) CIV DISA FE (USA) via bind-users <bind-users at lists.isc.org> wrote:
> 
> ?Hello,
> 
> I have what is probably a very rudimentary question, but I am stuck.
> 
> I am attempting to upgrade BIND on a Solaris 11.4 x86 virtual platform.  I have installed BIND successfully up to version 9.16.12 using  ./configure --enable-full-report --with-gssapi=krb5-config --sysconfdir=/etc --with-openssl=/usr/local --localstatedir=/var --enable-fixed-rrset  
> 
> I also added environment variables: export LDFLAGS="-L/usr/local/lib -R/usr/local/lib"  [and]  export PKG_CONFIG_PATH="usr/lib/pkgconfig:/usr/local/lib/pkgconfig (for libuv)
> 
> This time ./configure aborts with errors related to linking gssapi to kerberos
> 
> checking krb5.h presence... yes
> checking for krb5.h... yes
> checking krb5-config linking as -lkrb5 -lk5crypto -lcom_err... krb5-config: could not determine proper GSSAPI linkage
> checking for GSSAPI library, non krb5-config method... looking in /usr/lib
> checking for gssapi.h... (cached) yes
> checking for gssapi/gssapi.h... (cached) yes
> checking gssapi_krb5.h usability... no
> checking gssapi_krb5.h presence... no
> checking for gssapi_krb5.h... no
> checking gssapi/gssapi_krb5.h usability... no
> checking gssapi/gssapi_krb5.h presence... no
> checking for gssapi/gssapi_krb5.h... no
> checking for krb5.h... (cached) yes
> checking for krb5/krb5.h... (cached) yes
> checking kerberosv5/krb5.h usability... no
> checking kerberosv5/krb5.h presence... no
> checking for kerberosv5/krb5.h... no
> checking linking as -lgssapi_krb5... no
> checking linking as -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err... no
> checking linking as -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv... no
> checking linking as -lgssapi... no
> checking linking as -lgssapi -lkrb5 -ldes -lcrypt -lasn1 -lroken -lcom_err... no
> checking linking as -lgssapi -lkrb5 -lcrypt -lasn1 -lroken -lcom_err... no
> checking linking as -lgssapi -lkrb5 -lgssapi_krb5 -lcrypt -lasn1 -lroken -lcom_err... no
> checking linking as -lgssapi -lkrb5 -lhx509 -lcrypt -lasn1 -lroken -lcom_err... no
> checking linking as -lgss -lkrb5... no
> configure: error: could not determine proper GSSAPI linkage
> 
> I am looking all through the internet, the config.log, README etc. and I can't seem to find a solution. 
> krb5.h is located at 
> /usr/include/kerberosv5/krb5/krb5.h
> /usr/include/kerberosv5/krb5.h
> /usr/lib/krb5/krb5.h  
> 
> I am pretty sure it is a matter of setting the correct path variable, but I am new at this and I can't figure it out yet.  Any help would be appreciated.
> 
> Jim 
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/cd6139c8/attachment.htm>

From Axel.Rau at chaos1.de  Thu May  6 18:15:58 2021
From: Axel.Rau at chaos1.de (Axel Rau)
Date: Thu, 6 May 2021 20:15:58 +0200
Subject: How to return REFUSED
In-Reply-To: <B79AE8B8-D151-4395-8EB3-2DE03C10556A@Chaos1.DE>
References: <A29DD154-300C-4063-8A95-FA2621254595@Chaos1.DE>
 <7dfa2e0-90ec-71d8-cd83-985d38687b1c@dotat.at>
 <B79AE8B8-D151-4395-8EB3-2DE03C10556A@Chaos1.DE>
Message-ID: <6C131BFD-FB5B-46EA-B938-8285F58B034D@Chaos1.DE>



> Am 06.05.2021 um 18:41 schrieb Axel Rau <Axel.Rau at chaos1.de>:
> 
> This NS has some other clients in the DMZ LAN, so I need Views.


With 2 views ddos trace looks much better:

17:40:21.483188 186.149.116.55.80 > 91.216.35.171.53: [no udp cksum] 1+ RRSIG? pizzaseo.com.(30) (ttl 242, id 21165, len 58)
17:40:21.483470 91.216.35.171.53 > 186.149.116.55.80: [udp sum ok] 1 Refused- q: RRSIG? pizzaseo.com. 0/0/0(30) (DF) (ttl 64, id 0, len 58)

Hopefully, they give up in some days, if there is no amplification any more.

I have now 2 views. All zones are in the internal view.
The (only) external zones in external view use in-view to reference them in internal view.
axfr seems to work,, notify still to be tested.

If someone wants to play with the staging server please:

	dig ANY chaos1.de. @ns3.lrau.net.

Any feedback welcome,
Axel
---
PGP-Key: CDE74120  ?  computing @ chaos claudius

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/8e0400dc/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/8e0400dc/attachment.bin>

From bind at beyondthepale.ie  Thu May  6 18:35:18 2021
From: bind at beyondthepale.ie (Peter Coghlan)
Date: Thu, 06 May 2021 19:35:18 +0100 (WET-DST)
Subject: How to return REFUSED
In-Reply-To: <6C131BFD-FB5B-46EA-B938-8285F58B034D@Chaos1.DE>
References: <A29DD154-300C-4063-8A95-FA2621254595@Chaos1.DE>
 <7dfa2e0-90ec-71d8-cd83-985d38687b1c@dotat.at>
 <B79AE8B8-D151-4395-8EB3-2DE03C10556A@Chaos1.DE>
Message-ID: <01RYQ6HCJ26G8X4VLR@beyondthepale.ie>

A non-text attachment was scrubbed...
Name: not available
Type: multipart/signed
Size: 1010 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/f67427c6/attachment.bin>

From jukka.pakkanen at qnet.fi  Thu May  6 22:09:42 2021
From: jukka.pakkanen at qnet.fi (Jukka Pakkanen)
Date: Thu, 6 May 2021 22:09:42 +0000
Subject: BIND 9.16.15 Windows x64 broken?
Message-ID: <013b67deb4e648569b3f8479e16f8f85@qnet.fi>

What changed between Bind 9.16.13 and 9.16.15 Windows x64 binaries?

9.16.15 will not start at all in Server 2008 R2 Enterprise x64, 9.16.13 worked fine.

Only get "The service is not responding to the control function" when trying to start the service.

Tried this as an upgrade to the 9.16.13, or as a fresh install, same result in both cases.  Downgrading to 9.16.13 and works fine again.

Jukka


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/0c6d5cc6/attachment-0001.htm>

From dclarke at blastwave.org  Thu May  6 22:20:06 2021
From: dclarke at blastwave.org (Dennis Clarke)
Date: Thu, 6 May 2021 18:20:06 -0400
Subject: took a while to figure out why all your tests fail
Message-ID: <24a1c608-19aa-6c1e-d141-a6866555204e@blastwave.org>



I very carefully created an airgap test system for this process and did
setup all the required network interfaces. However all tests fail
terribly due to some weird python requirement ?

airgap$ ./runall.sh -n
+ SYSTEMTESTTOP=.
+ . ./conf.sh
++ TOP=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005
++ DEFAULT_ALGORITHM=RSASHA256
++ DEFAULT_ALGORITHM_NUMBER=8
++ DEFAULT_BITS=1280
++ TMPDIR=/tmp
++ ALTERNATIVE_ALGORITHM=RSASHA1
++ ALTERNATIVE_ALGORITHM_NUMBER=5
++ ALTERNATIVE_BITS=1280
++ DISABLED_ALGORITHM=ECDSAP384SHA384
++ DISABLED_ALGORITHM_NUMBER=14
++ DISABLED_BITS=384
++ NAMED=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/named/named
++
LWRESD='/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/named/named -l'
++ DIG=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dig/dig
++ DELV=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/delv/delv
++ RNDC=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/rndc/rndc
++
NSUPDATE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/nsupdate/nsupdate
++
DDNSCONFGEN=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/confgen/ddns-confgen
++
TSIGKEYGEN=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/confgen/tsig-keygen
++
RNDCCONFGEN=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/confgen/rndc-confgen
++
KEYGEN=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-keygen
++
KEYFRLAB=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-keyfromlabel
++
SIGNER=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-signzone
++
REVOKE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-revoke
++
SETTIME=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-settime
++
DSFROMKEY=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-dsfromkey
++ HOST=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dig/host
++
IMPORTKEY=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-importkey
++
CHECKDS=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/python/dnssec-checkds
++
COVERAGE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/python/dnssec-coverage
++
KEYMGR=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/python/dnssec-keymgr
++
CHECKZONE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/check/named-checkzone
++
CHECKCONF=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/check/named-checkconf
++
PK11GEN='/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/pkcs11/pkcs11-keygen
-q -s 0 -p 1234'
++
PK11LIST='/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/pkcs11/pkcs11-list
-s 0 -p 1234'
++
PK11DEL='/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/pkcs11/pkcs11-destroy
-s 0 -p 1234 -w 0'
++
JOURNALPRINT=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/named-journalprint
++
VERIFY=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-verify
++
ARPANAME=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/arpaname
++
RESOLVE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/lib/samples/resolve
++
RRCHECKER=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/named-rrchecker
++
GENRANDOM=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/genrandom
++
NSLOOKUP=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dig/nslookup
++
DNSTAPREAD=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/dnstap-read
++ MDIG=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/mdig
++
NZD2NZF=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/named-nzd2nzf
++ FSTRM_CAPTURE=
++
FEATURETEST=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/feature-test
++
RANDFILE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/random.data
++
BIGKEY=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/rsabigexponent/bigkey
++
GENCHECK=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/rndc/gencheck
++
KEYCREATE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/tkey/keycreate
++
KEYDELETE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/tkey/keydelete
++
LWTEST=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/lwresd/lwtest
++
MAKEJOURNAL=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/makejournal
++
PIPEQUERIES=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/pipelined/pipequeries
++
SAMPLEUPDATE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/lib/samples/sample-update
++ KRB5_CONFIG=/dev/null
++ RANDOMSIZE=4096
++ SEQUENTIALDIRS='ecdsa eddsa gost lwresd  tkey'
++ PARALLELDIRS='dnssec rpzrecurse      acl additional addzone
allow-query auth autosign        builtin cacheclean case catz chain
 checkconf checknames checkzone          cookie database digdelv dlv dlz
dlzexternal     dns64  dscp dsdigest dyndb      ednscompliance
emptyzones       fetchlimit filter-aaaa formerr forward  geoip geoip2
glue idna inline integrity ixfr    legacy limits logfileconfig
masterfile masterformat metadata mkeys  names notify nslookup nsupdate
nzd2nzf  pending pipelined       reclimit redirect resolver rndc
rootkeysentinel rpz     rrchecker rrl rrsetorder rsabigexponent runtime
        sfcache smartsign sortlist      spf staticstub statistics
statschannel stub     tcp tsig tsiggss        unknown upforwd verify
views wildcard   xfer xferquota zero zonechecks'
++ SUBDIRS='ecdsa eddsa gost lwresd  tkey dnssec rpzrecurse     acl
additional addzone allow-query auth autosign        builtin cacheclean
case catz chain      checkconf checknames checkzone          cookie
database digdelv dlv dlz dlzexternal     dns64  dscp dsdigest dyndb
 ednscompliance emptyzones       fetchlimit filter-aaaa formerr forward
 geoip geoip2 glue idna inline integrity ixfr    legacy limits
logfileconfig     masterfile masterformat metadata mkeys  names notify
nslookup nsupdate nzd2nzf  pending pipelined       reclimit redirect
resolver rndc rootkeysentinel rpz     rrchecker rrl rrsetorder
rsabigexponent runtime         sfcache smartsign sortlist      spf
staticstub statistics statschannel stub     tcp tsig tsiggss
unknown upforwd verify views wildcard   xfer xferquota zero zonechecks'
++ KILL=kill
++ DIFF=diff
++ DOS2UNIX=true
++ TP=.
++ SHELL=/opt/bw/bin/bash
++ CURL=/opt/bw/bin/curl
++ XMLLINT=/opt/bw/bin/xmllint
++ XSLTPROC=/bin/xsltproc
++ PERL=/opt/bw/bin/perl
++ PSSUSPEND=
++ PYTHON=
++ CHECK_DSA=0
++ HAVEXMLSTATS=1
++ HAVEJSONSTATS=
++ ZLIB=1
++ NZD=
++ . /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/version
+++ PRODUCT=BIND
+++ DESCRIPTION='(Extended Support Version)'
+++ MAJORVER=9
+++ MINORVER=11
+++ PATCHVER=31
+++ RELEASETYPE=
+++ RELEASEVER=
+++ EXTENSIONS=
++ '[' 0 -eq 1 ']'
++ test -t 1
++ type tput
++ tput setaf 7
++ COLOR_END=
++ COLOR_FAIL=
++ COLOR_INFO=
++ COLOR_NONE=
++ COLOR_PASS=
++ COLOR_START=
++ COLOR_WARN=
+++ basename
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system
++ SYSTESTDIR=system
++ type printf
++ export ARPANAME
++ export BIGKEY
++ export CHECKZONE
++ export CYGWIN
++ export DESCRIPTION
++ export DIG
++ export FEATURETEST
++ export FSTRM_CAPTURE
++ export GENCHECK
++ export JOURNALPRINT
++ export KEYCREATE
++ export KEYDELETE
++ export KEYFRLAB
++ export KEYGEN
++ export KEYSETTOOL
++ export KEYSIGNER
++ export KRB5_CONFIG
++ export LWRESD
++ export LWTEST
++ export MAKEJOURNAL
++ export MDIG
++ export NAMED
++ export NSLOOKUP
++ export NSUPDATE
++ export NZD2NZF
++ export PERL
++ export PIPEQUERIES
++ export PK11DEL
++ export PK11GEN
++ export PK11LIST
++ export PSSUSPEND
++ export PYTHON
++ export RANDFILE
++ export RESOLVE
++ export RNDC
++ export RRCHECKER
++ export SAMPLEUPDATE
++ export SIGNER
++ export SUBDIRS
++ export TMPDIR
+ usage='Usage: ./runall.sh [-c] [-n] [numprocesses]'
+ SYSTEMTEST_FORCE_COLOR=0
+ SYSTEMTEST_NO_CLEAN=0
+ getopts cn flag
+ case "$flag" in
+ SYSTEMTEST_NO_CLEAN=1
+ getopts cn flag
+ export NOCLEAN
++ expr 2 - 1
+ shift 1
+ '[' 0 -eq 0 ']'
+ numproc=1
+ export SYSTEMTEST_FORCE_COLOR
+ export SYSTEMTEST_NO_CLEAN
+ status=0
+ '[' '' = '' ']'
+ '[' '' = '' ']'
+ make -j 1 check
make: Warning: Ignoring DistributedMake -j option
making all in
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/dlzexternal
make: Warning: Ignoring DistributedMake -j option
making all in
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/dyndb
make: Warning: Ignoring DistributedMake -j option
making all in
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/dyndb/driver
make: Warning: Ignoring DistributedMake -j option
making all in
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/lwresd
make: Warning: Ignoring DistributedMake -j option
making all in
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/pipelined
make: Warning: Ignoring DistributedMake -j option
making all in
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/rndc
make: Warning: Ignoring DistributedMake -j option
making all in
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/rsabigexponent
make: Warning: Ignoring DistributedMake -j option
making all in
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/tkey
make: Warning: Ignoring DistributedMake -j option
make: Warning: Ignoring DistributedMake -j option
tee: test.output.dnssec: Permission denied
S:dnssec:Thu May  6 22:16:17 GMT 2021
T:dnssec:1:A
A:dnssec:System test dnssec
I:dnssec:PORTRANGE:5000 - 5099
I:dnssec:This test requires Python and the dnspython module.
I:dnssec:Prerequisites missing, skipping test.
R:dnssec:UNTESTED
E:dnssec:Thu May  6 22:16:18 GMT 2021
*** Error code 1
The following command caused the error:
/opt/bw/bin/bash ./run.sh -p 5000 dnssec 2>&1 | tee test.output.dnssec
make: Fatal error: Command failed for target `test-dnssec'
Current working directory
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system
*** Error code 1
The following command caused the error:
make -f parallel.mk check
make: Fatal error: Command failed for target `test'
airgap$


So then, is there a non-node.js and python way to test this build?


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

From richard at richardneal.com  Thu May  6 22:26:46 2021
From: richard at richardneal.com (Richard T.A. Neal)
Date: Thu, 6 May 2021 22:26:46 +0000
Subject: BIND 9.16.15 Windows x64 broken?
In-Reply-To: <013b67deb4e648569b3f8479e16f8f85@qnet.fi>
References: <013b67deb4e648569b3f8479e16f8f85@qnet.fi>
Message-ID: <LO2P123MB41100BCA47014296809D83C6B3589@LO2P123MB4110.GBRP123.PROD.OUTLOOK.COM>

I'm running BIND 9.16.15 fine on Windows Server Standard 2019. What do you see in the Event Viewer > Application log?

There'll be lots of entries in there of course, so just filter by Source "named" and look for any Critical, Error, or Warning messages.

Richard.

From: bind-users <bind-users-bounces at lists.isc.org> On Behalf Of Jukka Pakkanen
Sent: 06 May 2021 11:10 pm
To: bind-users at isc.org
Subject: BIND 9.16.15 Windows x64 broken?

What changed between Bind 9.16.13 and 9.16.15 Windows x64 binaries?

9.16.15 will not start at all in Server 2008 R2 Enterprise x64, 9.16.13 worked fine.

Only get "The service is not responding to the control function" when trying to start the service.

Tried this as an upgrade to the 9.16.13, or as a fresh install, same result in both cases.  Downgrading to 9.16.13 and works fine again.

Jukka

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/daa6451a/attachment.htm>

From marka at isc.org  Thu May  6 23:03:50 2021
From: marka at isc.org (Mark Andrews)
Date: Fri, 7 May 2021 09:03:50 +1000
Subject: took a while to figure out why all your tests fail
In-Reply-To: <24a1c608-19aa-6c1e-d141-a6866555204e@blastwave.org>
References: <24a1c608-19aa-6c1e-d141-a6866555204e@blastwave.org>
Message-ID: <C1AEAB69-E07C-4849-9D2C-3F6F3CA97141@isc.org>

First of all the user running the tests needs to be able to write to bin/tests/system. See the permission denied from tee. 

-- 
Mark Andrews

> On 7 May 2021, at 08:20, Dennis Clarke via bind-users <bind-users at lists.isc.org> wrote:
> 
> ?
> 
> I very carefully created an airgap test system for this process and did
> setup all the required network interfaces. However all tests fail
> terribly due to some weird python requirement ?
> 
> airgap$ ./runall.sh -n
> + SYSTEMTESTTOP=.
> + . ./conf.sh
> ++ TOP=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005
> ++ DEFAULT_ALGORITHM=RSASHA256
> ++ DEFAULT_ALGORITHM_NUMBER=8
> ++ DEFAULT_BITS=1280
> ++ TMPDIR=/tmp
> ++ ALTERNATIVE_ALGORITHM=RSASHA1
> ++ ALTERNATIVE_ALGORITHM_NUMBER=5
> ++ ALTERNATIVE_BITS=1280
> ++ DISABLED_ALGORITHM=ECDSAP384SHA384
> ++ DISABLED_ALGORITHM_NUMBER=14
> ++ DISABLED_BITS=384
> ++ NAMED=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/named/named
> ++
> LWRESD='/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/named/named -l'
> ++ DIG=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dig/dig
> ++ DELV=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/delv/delv
> ++ RNDC=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/rndc/rndc
> ++
> NSUPDATE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/nsupdate/nsupdate
> ++
> DDNSCONFGEN=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/confgen/ddns-confgen
> ++
> TSIGKEYGEN=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/confgen/tsig-keygen
> ++
> RNDCCONFGEN=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/confgen/rndc-confgen
> ++
> KEYGEN=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-keygen
> ++
> KEYFRLAB=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-keyfromlabel
> ++
> SIGNER=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-signzone
> ++
> REVOKE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-revoke
> ++
> SETTIME=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-settime
> ++
> DSFROMKEY=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-dsfromkey
> ++ HOST=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dig/host
> ++
> IMPORTKEY=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-importkey
> ++
> CHECKDS=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/python/dnssec-checkds
> ++
> COVERAGE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/python/dnssec-coverage
> ++
> KEYMGR=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/python/dnssec-keymgr
> ++
> CHECKZONE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/check/named-checkzone
> ++
> CHECKCONF=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/check/named-checkconf
> ++
> PK11GEN='/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/pkcs11/pkcs11-keygen
> -q -s 0 -p 1234'
> ++
> PK11LIST='/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/pkcs11/pkcs11-list
> -s 0 -p 1234'
> ++
> PK11DEL='/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/pkcs11/pkcs11-destroy
> -s 0 -p 1234 -w 0'
> ++
> JOURNALPRINT=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/named-journalprint
> ++
> VERIFY=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-verify
> ++
> ARPANAME=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/arpaname
> ++
> RESOLVE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/lib/samples/resolve
> ++
> RRCHECKER=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/named-rrchecker
> ++
> GENRANDOM=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/genrandom
> ++
> NSLOOKUP=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dig/nslookup
> ++
> DNSTAPREAD=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/dnstap-read
> ++ MDIG=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/mdig
> ++
> NZD2NZF=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/named-nzd2nzf
> ++ FSTRM_CAPTURE=
> ++
> FEATURETEST=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/feature-test
> ++
> RANDFILE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/random.data
> ++
> BIGKEY=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/rsabigexponent/bigkey
> ++
> GENCHECK=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/rndc/gencheck
> ++
> KEYCREATE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/tkey/keycreate
> ++
> KEYDELETE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/tkey/keydelete
> ++
> LWTEST=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/lwresd/lwtest
> ++
> MAKEJOURNAL=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/makejournal
> ++
> PIPEQUERIES=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/pipelined/pipequeries
> ++
> SAMPLEUPDATE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/lib/samples/sample-update
> ++ KRB5_CONFIG=/dev/null
> ++ RANDOMSIZE=4096
> ++ SEQUENTIALDIRS='ecdsa eddsa gost lwresd  tkey'
> ++ PARALLELDIRS='dnssec rpzrecurse      acl additional addzone
> allow-query auth autosign        builtin cacheclean case catz chain
> checkconf checknames checkzone          cookie database digdelv dlv dlz
> dlzexternal     dns64  dscp dsdigest dyndb      ednscompliance
> emptyzones       fetchlimit filter-aaaa formerr forward  geoip geoip2
> glue idna inline integrity ixfr    legacy limits logfileconfig
> masterfile masterformat metadata mkeys  names notify nslookup nsupdate
> nzd2nzf  pending pipelined       reclimit redirect resolver rndc
> rootkeysentinel rpz     rrchecker rrl rrsetorder rsabigexponent runtime
>        sfcache smartsign sortlist      spf staticstub statistics
> statschannel stub     tcp tsig tsiggss        unknown upforwd verify
> views wildcard   xfer xferquota zero zonechecks'
> ++ SUBDIRS='ecdsa eddsa gost lwresd  tkey dnssec rpzrecurse     acl
> additional addzone allow-query auth autosign        builtin cacheclean
> case catz chain      checkconf checknames checkzone          cookie
> database digdelv dlv dlz dlzexternal     dns64  dscp dsdigest dyndb
> ednscompliance emptyzones       fetchlimit filter-aaaa formerr forward
> geoip geoip2 glue idna inline integrity ixfr    legacy limits
> logfileconfig     masterfile masterformat metadata mkeys  names notify
> nslookup nsupdate nzd2nzf  pending pipelined       reclimit redirect
> resolver rndc rootkeysentinel rpz     rrchecker rrl rrsetorder
> rsabigexponent runtime         sfcache smartsign sortlist      spf
> staticstub statistics statschannel stub     tcp tsig tsiggss
> unknown upforwd verify views wildcard   xfer xferquota zero zonechecks'
> ++ KILL=kill
> ++ DIFF=diff
> ++ DOS2UNIX=true
> ++ TP=.
> ++ SHELL=/opt/bw/bin/bash
> ++ CURL=/opt/bw/bin/curl
> ++ XMLLINT=/opt/bw/bin/xmllint
> ++ XSLTPROC=/bin/xsltproc
> ++ PERL=/opt/bw/bin/perl
> ++ PSSUSPEND=
> ++ PYTHON=
> ++ CHECK_DSA=0
> ++ HAVEXMLSTATS=1
> ++ HAVEJSONSTATS=
> ++ ZLIB=1
> ++ NZD=
> ++ . /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/version
> +++ PRODUCT=BIND
> +++ DESCRIPTION='(Extended Support Version)'
> +++ MAJORVER=9
> +++ MINORVER=11
> +++ PATCHVER=31
> +++ RELEASETYPE=
> +++ RELEASEVER=
> +++ EXTENSIONS=
> ++ '[' 0 -eq 1 ']'
> ++ test -t 1
> ++ type tput
> ++ tput setaf 7
> ++ COLOR_END=
> ++ COLOR_FAIL=
> ++ COLOR_INFO=
> ++ COLOR_NONE=
> ++ COLOR_PASS=
> ++ COLOR_START=
> ++ COLOR_WARN=
> +++ basename
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system
> ++ SYSTESTDIR=system
> ++ type printf
> ++ export ARPANAME
> ++ export BIGKEY
> ++ export CHECKZONE
> ++ export CYGWIN
> ++ export DESCRIPTION
> ++ export DIG
> ++ export FEATURETEST
> ++ export FSTRM_CAPTURE
> ++ export GENCHECK
> ++ export JOURNALPRINT
> ++ export KEYCREATE
> ++ export KEYDELETE
> ++ export KEYFRLAB
> ++ export KEYGEN
> ++ export KEYSETTOOL
> ++ export KEYSIGNER
> ++ export KRB5_CONFIG
> ++ export LWRESD
> ++ export LWTEST
> ++ export MAKEJOURNAL
> ++ export MDIG
> ++ export NAMED
> ++ export NSLOOKUP
> ++ export NSUPDATE
> ++ export NZD2NZF
> ++ export PERL
> ++ export PIPEQUERIES
> ++ export PK11DEL
> ++ export PK11GEN
> ++ export PK11LIST
> ++ export PSSUSPEND
> ++ export PYTHON
> ++ export RANDFILE
> ++ export RESOLVE
> ++ export RNDC
> ++ export RRCHECKER
> ++ export SAMPLEUPDATE
> ++ export SIGNER
> ++ export SUBDIRS
> ++ export TMPDIR
> + usage='Usage: ./runall.sh [-c] [-n] [numprocesses]'
> + SYSTEMTEST_FORCE_COLOR=0
> + SYSTEMTEST_NO_CLEAN=0
> + getopts cn flag
> + case "$flag" in
> + SYSTEMTEST_NO_CLEAN=1
> + getopts cn flag
> + export NOCLEAN
> ++ expr 2 - 1
> + shift 1
> + '[' 0 -eq 0 ']'
> + numproc=1
> + export SYSTEMTEST_FORCE_COLOR
> + export SYSTEMTEST_NO_CLEAN
> + status=0
> + '[' '' = '' ']'
> + '[' '' = '' ']'
> + make -j 1 check
> make: Warning: Ignoring DistributedMake -j option
> making all in
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/dlzexternal
> make: Warning: Ignoring DistributedMake -j option
> making all in
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/dyndb
> make: Warning: Ignoring DistributedMake -j option
> making all in
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/dyndb/driver
> make: Warning: Ignoring DistributedMake -j option
> making all in
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/lwresd
> make: Warning: Ignoring DistributedMake -j option
> making all in
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/pipelined
> make: Warning: Ignoring DistributedMake -j option
> making all in
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/rndc
> make: Warning: Ignoring DistributedMake -j option
> making all in
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/rsabigexponent
> make: Warning: Ignoring DistributedMake -j option
> making all in
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/tkey
> make: Warning: Ignoring DistributedMake -j option
> make: Warning: Ignoring DistributedMake -j option
> tee: test.output.dnssec: Permission denied
> S:dnssec:Thu May  6 22:16:17 GMT 2021
> T:dnssec:1:A
> A:dnssec:System test dnssec
> I:dnssec:PORTRANGE:5000 - 5099
> I:dnssec:This test requires Python and the dnspython module.
> I:dnssec:Prerequisites missing, skipping test.
> R:dnssec:UNTESTED
> E:dnssec:Thu May  6 22:16:18 GMT 2021
> *** Error code 1
> The following command caused the error:
> /opt/bw/bin/bash ./run.sh -p 5000 dnssec 2>&1 | tee test.output.dnssec
> make: Fatal error: Command failed for target `test-dnssec'
> Current working directory
> /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system
> *** Error code 1
> The following command caused the error:
> make -f parallel.mk check
> make: Fatal error: Command failed for target `test'
> airgap$
> 
> 
> So then, is there a non-node.js and python way to test this build?
> 
> 
> -- 
> Dennis Clarke
> RISC-V/SPARC/PPC/ARM/CISC
> UNIX and Linux spoken
> GreyBeard and suspenders optional
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


From dan at newideatest.site  Fri May  7 04:35:47 2021
From: dan at newideatest.site (Dan Egli)
Date: Thu, 6 May 2021 22:35:47 -0600
Subject: Bind refusing my DKIM key
Message-ID: <8acbd8ec-ae63-8b2c-8aaa-81a0e69466d3@newideatest.site>

I don't know what's up, but when I tried to put my DKIM into the test 
server, named-checkzone keeps giving a syntax error on the key line. 
Here's what I'm putting in (it really is on one line in the zone file, 
just too long for my MUA to put on one line):

key1._domainkey??? ??? IN??? 
TXT??? 
"v=DKIM1;p=QUFBQUIzTnphQzF5YzJFQUFBQURBUUFCQUFBQWdRQ3B0Uy9SMzRJQm5yZEhGZFYzNE4zMmdWUjQyelFDUnpXdkJMWDloNkUwOUlRNnBsV0p3S09aL0hHQ3ZjSHlaNytKZVk4MWlCR1p4NWhLN1pvQkZaYTMxcjlmMDRZU2NkeVZmVUQrb004UjJCQzBGNVdQY3ptMGl1TVJQemFqY29tSU5LSHltWEplRHU0K05oTnlhWEJoRi9oS0hrUlNJeFNDU3JqbWxlZWRsdz09IA=="


But when I run checkzone:
dns_rdata_fromtext: myzone.zone:26: syntax error
zone eglifamily.name/IN: loading from master file myzone.zone failed: 
syntax error

What's wrong? Why is it failing?

-- 
Dan Egli
 From my Test Server

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/dc8cd4e8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x11B7451DF2015959.asc
Type: application/pgp-keys
Size: 3792 bytes
Desc: OpenPGP public key
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/dc8cd4e8/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/dc8cd4e8/attachment-0001.bin>

From marka at isc.org  Fri May  7 04:40:30 2021
From: marka at isc.org (Mark Andrews)
Date: Fri, 7 May 2021 14:40:30 +1000
Subject: Bind refusing my DKIM key
In-Reply-To: <8acbd8ec-ae63-8b2c-8aaa-81a0e69466d3@newideatest.site>
References: <8acbd8ec-ae63-8b2c-8aaa-81a0e69466d3@newideatest.site>
Message-ID: <B67053F8-7FDC-4A6B-BA3A-E21B1110E3E9@isc.org>

Split the record at 255 characters.  TXT field need to be <= 255 characters.
Complain to the developers of the tool that created this record that it is
INVALID as the field length is TOO BIG. 

> On 7 May 2021, at 14:35, Dan Egli <dan at newideatest.site> wrote:
> 
> I don't know what's up, but when I tried to put my DKIM into the test server, named-checkzone keeps giving a syntax error on the key line. Here's what I'm putting in (it really is on one line in the zone file, just too long for my MUA to put on one line):
> 
> key1._domainkey        IN    TXT    "v=DKIM1;p=QUFBQUIzTnphQzF5YzJFQUFBQURBUUFCQUFBQWdRQ3B0Uy9SMzRJQm5yZEhGZFYzNE4zMmdWUjQyelFDUnpXdkJMWDloNkUwOUlRNnBsV0p3S09aL0hHQ3ZjSHlaNytKZVk4MWlCR1p4NWhLN1pvQkZaYTMxcjlmMDRZU2NkeVZmVUQrb004UjJCQzBGNVdQY3ptMGl1TVJQemFqY29tSU5LSHltWEplRHU0K05oTnlhWEJoRi9oS0hrUlNJeFNDU3JqbWxlZWRsdz09IA=="
> 
> 
> But when I run checkzone:
> dns_rdata_fromtext: myzone.zone:26: syntax error
> zone eglifamily.name/IN: loading from master file myzone.zone failed: syntax error
> 
> What's wrong? Why is it failing?
> -- 
> Dan Egli
> From my Test Server
> 
> <OpenPGP_0x11B7451DF2015959.asc>_______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org


From dan at newideatest.site  Fri May  7 05:14:51 2021
From: dan at newideatest.site (Dan Egli)
Date: Thu, 6 May 2021 23:14:51 -0600
Subject: Bind refusing my DKIM key
In-Reply-To: <B67053F8-7FDC-4A6B-BA3A-E21B1110E3E9@isc.org>
References: <8acbd8ec-ae63-8b2c-8aaa-81a0e69466d3@newideatest.site>
 <B67053F8-7FDC-4A6B-BA3A-E21B1110E3E9@isc.org>
Message-ID: <6e327f07-d778-4a79-5c1d-6009101e5b4f@newideatest.site>

Thanks! I went somewhere else, used THEIR dkim generator, and it works 
fine. I've sent a message to support at powerdmarc.com about this.

On 5/6/2021 10:40 PM, Mark Andrews wrote:
> Split the record at 255 characters.  TXT field need to be <= 255 characters.
> Complain to the developers of the tool that created this record that it 
is
> INVALID as the field length is TOO BIG.
>
>> On 7 May 2021, at 14:35, Dan Egli <dan at newideatest.site> wrote:
>>
>> I don't know what's up, but when I tried to put my DKIM into the test server, named-checkzone keeps giving a syntax error on the key line. Here's what I'm putting in (it really is on one line in the zone file, just too long for my MUA to put on one line):
>>
>> key1._domainkey        IN    TXT    "v=DKIM1;p=QUFBQUIzTnphQzF5YzJFQUFBQURBUUFCQUFBQWdRQ3B0Uy9SMzRJQm5yZEhGZFYzNE4zMmdWUjQyelFDUnpXdkJMWDloNkUwOUlRNnBsV0p3S09aL0hHQ3ZjSHlaNytKZVk4MWlCR1p4NWhLN1pvQkZaYTMxcjlmMDRZU2NkeVZmVUQrb004UjJCQzBGNVdQY3ptMGl1TVJQemFqY29tSU5LSHltWEplRHU0K05oTnlhWEJoRi9oS0hrUlNJeFNDU3JqbWxlZWRsdz09IA=="
>>
>>
>> But when I run checkzone:
>> dns_rdata_fromtext: myzone.zone:26: syntax error
>> zone eglifamily.name/IN: loading from master file myzone.zone failed: syntax error
>>
>> What's wrong? Why is it failing?
>> -- 
>> Dan Egli
>>  From my Test Server
>>
>> <OpenPGP_0x11B7451DF2015959.asc>_______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>
>> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>>
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Dan Egli
 From my Test Server

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x11B7451DF2015959.asc
Type: application/pgp-keys
Size: 3792 bytes
Desc: OpenPGP public key
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/647359e1/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/647359e1/attachment-0001.bin>

From dan at newideatest.site  Fri May  7 05:37:30 2021
From: dan at newideatest.site (Dan Egli)
Date: Thu, 6 May 2021 23:37:30 -0600
Subject: Bind won't listen
Message-ID: <8bb21b3c-c46b-e7a5-4786-9e2c7e367ece@newideatest.site>

Okay, I got all the zones loaded by named-checkzone, and named-checkconf 
returns no errors. So I started up named in the foreground using the -g 
option. All looks good, UNTIL it gets to where it is supposed to listen 
on port 53. Then I get:

06-May-2021 23:35:20.979 not listening on any interfaces

Why not? My config file specifically says listen-on { 0.0.0.0; }; and 
listen-on-v6 { ::; };

-- 
Dan Egli
 From my Test Server

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x11B7451DF2015959.asc
Type: application/pgp-keys
Size: 3792 bytes
Desc: OpenPGP public key
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/f7ace0e6/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210506/f7ace0e6/attachment-0003.bin>

From ondrej at isc.org  Fri May  7 05:40:09 2021
From: ondrej at isc.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Fri, 7 May 2021 07:40:09 +0200
Subject: Bind won't listen
In-Reply-To: <8bb21b3c-c46b-e7a5-4786-9e2c7e367ece@newideatest.site>
References: <8bb21b3c-c46b-e7a5-4786-9e2c7e367ece@newideatest.site>
Message-ID: <008F63D5-47DE-4B97-B54E-EEF48A036826@isc.org>

Dan,

nobody can help you if you strip the logs to bare minimum.

--
Ond?ej Sur? ? ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 7. 5. 2021, at 7:37, Dan Egli <dan at newideatest.site> wrote:
> 
> ?Okay, I got all the zones loaded by named-checkzone, and named-checkconf returns no errors. So I started up named in the foreground using the -g option. All looks good, UNTIL it gets to where it is supposed to listen on port 53. Then I get:
> 
> 06-May-2021 23:35:20.979 not listening on any interfaces
> 
> Why not? My config file specifically says listen-on { 0.0.0.0; }; and listen-on-v6 { ::; };
> 
> -- 
> Dan Egli
> From my Test Server
> 
> <OpenPGP_0x11B7451DF2015959.asc>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


From marka at isc.org  Fri May  7 05:44:12 2021
From: marka at isc.org (Mark Andrews)
Date: Fri, 7 May 2021 15:44:12 +1000
Subject: Bind won't listen
In-Reply-To: <8bb21b3c-c46b-e7a5-4786-9e2c7e367ece@newideatest.site>
References: <8bb21b3c-c46b-e7a5-4786-9e2c7e367ece@newideatest.site>
Message-ID: <592C56E5-1F23-4740-A5B9-0DE9D7E97F53@isc.org>

listen-on is a ACL.  0.0.0.0 is short hand for 0.0.0.0/32 and that matches an
interface that is NOT configured.  Use ?any;?.

> On 7 May 2021, at 15:37, Dan Egli <dan at newideatest.site> wrote:
> 
> Okay, I got all the zones loaded by named-checkzone, and named-checkconf returns no errors. So I started up named in the foreground using the -g option. All looks good, UNTIL it gets to where it is supposed to listen on port 53. Then I get:
> 
> 06-May-2021 23:35:20.979 not listening on any interfaces
> 
> Why not? My config file specifically says listen-on { 0.0.0.0; }; and listen-on-v6 { ::; };
> 
> -- 
> Dan Egli
> From my Test Server
> 
> <OpenPGP_0x11B7451DF2015959.asc>_______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org


From uhlar at fantomas.sk  Fri May  7 08:00:53 2021
From: uhlar at fantomas.sk (Matus UHLAR - fantomas)
Date: Fri, 7 May 2021 10:00:53 +0200
Subject: How to return REFUSED
In-Reply-To: <B79AE8B8-D151-4395-8EB3-2DE03C10556A@Chaos1.DE>
References: <A29DD154-300C-4063-8A95-FA2621254595@Chaos1.DE>
 <7dfa2e0-90ec-71d8-cd83-985d38687b1c@dotat.at>
 <B79AE8B8-D151-4395-8EB3-2DE03C10556A@Chaos1.DE>
Message-ID: <20210507080053.GB22344@fantomas.sk>

On 06.05.21 18:41, Axel Rau wrote:
>This NS has some other clients in the DMZ LAN, so I need Views.

you need multiple views if you are going to provide multiple versions of the
same zones, different forwardings for different domains or alike.

Not just if you have other clients.

-- 
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux is like a teepee: no Windows, no Gates and an apache inside...

From james.j.decaro3.civ at mail.mil  Fri May  7 12:14:16 2021
From: james.j.decaro3.civ at mail.mil (DeCaro, James John (Jim) CIV DISA FE (USA))
Date: Fri, 7 May 2021 12:14:16 +0000
Subject: [Non-DoD Source] Re: Installing BIND 9.16.15
In-Reply-To: <1B2F4956-4069-4C85-93B7-D96F7CCAAFB6@isc.org>
References: <SN5P111MB0574158193F648E6B34AF36BD0589@SN5P111MB0574.NAMP111.PROD.OUTLOOK.COM>
 <1B2F4956-4069-4C85-93B7-D96F7CCAAFB6@isc.org>
Message-ID: <SN5P111MB0574AC0160D44B135AE1721AD0579@SN5P111MB0574.NAMP111.PROD.OUTLOOK.COM>

OK, thanks--After reading the article, I have a vague idea of the issue but I am not clear on the exact solution.  The article mentions a patch but I don't see a patch link.

Understand, I am a novice with this and I am not familiar with the discussion format.  Also, the article discusses version 9.11.31.  I was successful at installing a number of updated versions of BIND along the way up to and including 9.16.12 on the Solaris platform without the gssapi link problem.  I am only interested in installing non-development (production) stable versions.

Is there anything else I can review which has more specific solutions?

Many Thanks for your time.

-----Original Message-----
From: Ond?ej Sur? <ondrej at isc.org> 
Sent: Thursday, May 6, 2021 12:57 PM
To: DeCaro, James John (Jim) CIV DISA FE (USA) <james.j.decaro3.civ at mail.mil>
Cc: bind-users at lists.isc.org
Subject: [Non-DoD Source] Re: Installing BIND 9.16.15

All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. 


________________________________



See Caution-https://gitlab.isc.org/isc-projects/bind9/-/issues/2667 < Caution-https://gitlab.isc.org/isc-projects/bind9/-/issues/2667 > 


--
Ond?ej Sur? ? ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.


	On 6. 5. 2021, at 18:48, DeCaro, James John (Jim) CIV DISA FE (USA) via bind-users <bind-users at lists.isc.org> wrote:
	
	

	?Hello,
	
	I have what is probably a very rudimentary question, but I am stuck.
	
	I am attempting to upgrade BIND on a Solaris 11.4 x86 virtual platform.  I have installed BIND successfully up to version 9.16.12 using  ./configure --enable-full-report --with-gssapi=krb5-config --sysconfdir=/etc --with-openssl=/usr/local --localstatedir=/var --enable-fixed-rrset  
	
	I also added environment variables: export LDFLAGS="-L/usr/local/lib -R/usr/local/lib"  [and]  export PKG_CONFIG_PATH="usr/lib/pkgconfig:/usr/local/lib/pkgconfig (for libuv)
	
	This time ./configure aborts with errors related to linking gssapi to kerberos
	
	checking krb5.h presence... yes
	checking for krb5.h... yes
	checking krb5-config linking as -lkrb5 -lk5crypto -lcom_err... krb5-config: could not determine proper GSSAPI linkage
	checking for GSSAPI library, non krb5-config method... looking in /usr/lib
	checking for gssapi.h... (cached) yes
	checking for gssapi/gssapi.h... (cached) yes
	checking gssapi_krb5.h usability... no
	checking gssapi_krb5.h presence... no
	checking for gssapi_krb5.h... no
	checking gssapi/gssapi_krb5.h usability... no
	checking gssapi/gssapi_krb5.h presence... no
	checking for gssapi/gssapi_krb5.h... no
	checking for krb5.h... (cached) yes
	checking for krb5/krb5.h... (cached) yes
	checking kerberosv5/krb5.h usability... no
	checking kerberosv5/krb5.h presence... no
	checking for kerberosv5/krb5.h... no
	checking linking as -lgssapi_krb5... no
	checking linking as -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err... no
	checking linking as -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv... no
	checking linking as -lgssapi... no
	checking linking as -lgssapi -lkrb5 -ldes -lcrypt -lasn1 -lroken -lcom_err... no
	checking linking as -lgssapi -lkrb5 -lcrypt -lasn1 -lroken -lcom_err... no
	checking linking as -lgssapi -lkrb5 -lgssapi_krb5 -lcrypt -lasn1 -lroken -lcom_err... no
	checking linking as -lgssapi -lkrb5 -lhx509 -lcrypt -lasn1 -lroken -lcom_err... no
	checking linking as -lgss -lkrb5... no
	configure: error: could not determine proper GSSAPI linkage
	
	I am looking all through the internet, the config.log, README etc. and I can't seem to find a solution. 
	krb5.h is located at 
	/usr/include/kerberosv5/krb5/krb5.h
	/usr/include/kerberosv5/krb5.h
	/usr/lib/krb5/krb5.h  
	
	I am pretty sure it is a matter of setting the correct path variable, but I am new at this and I can't figure it out yet.  Any help would be appreciated.
	
	Jim 
	
	_______________________________________________
	Please visit Caution-https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
	
	ISC funds the development of this software with paid support subscriptions. Contact us at Caution-https://www.isc.org/contact/ for more information.
	
	
	bind-users mailing list
	bind-users at lists.isc.org
	Caution-https://lists.isc.org/mailman/listinfo/bind-users
	


From ondrej at isc.org  Fri May  7 14:12:34 2021
From: ondrej at isc.org (=?utf-8?B?T25kxZllaiBTdXLDvQ==?=)
Date: Fri, 7 May 2021 16:12:34 +0200
Subject: Intent to remove native PKCS#11 from BIND 9.18+
Message-ID: <CD9DA6D6-BD49-486F-8F68-79E26E08D1BC@isc.org>

Hey everybody,

this topic is even more obscure than Windows.

Currently, BIND 9 has two PKCS#11 interfaces:

* native PKCS#11 that uses direct PKCS#11 API calls to library that dynamically loaded (from compiled-in path)
* OpenSSL engine PKCS#11 from OpenSC project[1]

ISC has sponsored significant improvements to the OpenSC engine_pkcs11 and the next OpenSC version will include those improvements. The new version has better performance and is maintained by people who actually understand the PKCS#11 interface. Those improvements will be part of libp11 0.4.12 release.

Therefore we intent to drop the native PKCS#11 interface from BIND 9.18, so there?s less arcane code in named and we can focus on the DNS.

1. https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9-PKCS11

Ondrej
--
Ond?ej Sur? (He/Him)
ondrej at isc.org


From bind at kretz.net  Fri May  7 17:32:23 2021
From: bind at kretz.net (Kevin Kretz)
Date: Fri, 7 May 2021 13:32:23 -0400 (EDT)
Subject: strange queries incrementing letter by letter
Message-ID: <1493172176.1490122.1620408743205.JavaMail.zimbra@kretz.net>

I see occasional series of queries like this, from within my network and among disparate types of host (linux, windows): 

If there's a host called 

hostname.mynet.com 

I'll see a sequence of queries like 

hostname.m 
hostname.my 
hostname.myn 
hostname.myne 
hostname.mynet 
hostname.mynet.c 
hostname.mynet.co 
hostname.mynet.com 

Can anyone tell me what this is? 


thanks 

Kevin 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210507/5070b217/attachment.htm>

From richard at richardneal.com  Fri May  7 17:51:40 2021
From: richard at richardneal.com (Richard T.A. Neal)
Date: Fri, 7 May 2021 17:51:40 +0000
Subject: BIND 9.16.15 Windows x64 broken?
In-Reply-To: <LO2P123MB41100BCA47014296809D83C6B3589@LO2P123MB4110.GBRP123.PROD.OUTLOOK.COM>
References: <013b67deb4e648569b3f8479e16f8f85@qnet.fi>
 <LO2P123MB41100BCA47014296809D83C6B3589@LO2P123MB4110.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <LO2P123MB4110A697D75FAB5F3F299EABB3579@LO2P123MB4110.GBRP123.PROD.OUTLOOK.COM>

Hi Jukka,

I spun-up a brand new Windows 2008 R2 Enterprise x64 server today to try and replicate this, and unfortunately you're right - BIND 9.16.15 won't run on that environment.

In fact if you simply try and run [dig] from the command line you will get this:

/////
The procedure entry point GetSystemTimePreciseAsFileTime could not be located in the dynamic link library KERNEL32.dll
/////

Having done a bit of Google'ing it appears that this method /procedure is not available in Window 7 / 2008 R2. As such it's never going to work.

I hate to be "that guy" but Windows Server 2008 R2 is of course long out-of-support from Microsoft unless you happen to have an Extended Support Agreement with them. How feasible is it for you to upgrade your Windows BIND servers to Windows Server 2012 R2 or higher?

Richard.

From: bind-users <bind-users-bounces at lists.isc.org<mailto:bind-users-bounces at lists.isc.org>> On Behalf Of Jukka Pakkanen
Sent: 06 May 2021 11:10 pm
To: bind-users at isc.org<mailto:bind-users at isc.org>
Subject: BIND 9.16.15 Windows x64 broken?

What changed between Bind 9.16.13 and 9.16.15 Windows x64 binaries?

9.16.15 will not start at all in Server 2008 R2 Enterprise x64, 9.16.13 worked fine.

Only get "The service is not responding to the control function" when trying to start the service.

Tried this as an upgrade to the 9.16.13, or as a fresh install, same result in both cases.  Downgrading to 9.16.13 and works fine again.

Jukka
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210507/6d0b42a0/attachment-0001.htm>

From dclarke at blastwave.org  Fri May  7 18:01:48 2021
From: dclarke at blastwave.org (Dennis Clarke)
Date: Fri, 7 May 2021 14:01:48 -0400
Subject: took a while to figure out why all your tests fail
In-Reply-To: <C1AEAB69-E07C-4849-9D2C-3F6F3CA97141@isc.org>
References: <24a1c608-19aa-6c1e-d141-a6866555204e@blastwave.org>
 <C1AEAB69-E07C-4849-9D2C-3F6F3CA97141@isc.org>
Message-ID: <62c435c8-016c-20bc-4871-08380b58dd23@blastwave.org>

On 5/6/21 19:03, Mark Andrews wrote:
> First of all the user running the tests needs to be able to write to bin/tests/system. See the permission denied from tee. 
> 

I tried that and a pile of *other* things fail :


dude at nix$ ifconfig -a
lo0:6: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
8232 index 1
        inet 127.0.0.1 netmask ff000000
bge2:6: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 4
        inet 172.16.1.202 netmask ffffff00 broadcast 172.16.1.255
bge2:7: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 4
        inet 10.53.0.1 netmask ff000000 broadcast 10.255.255.255
bge2:8: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 4
        inet 10.53.0.2 netmask ff000000 broadcast 10.255.255.255
bge2:9: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 4
        inet 10.53.0.3 netmask ff000000 broadcast 10.255.255.255
bge2:10: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 4
        inet 10.53.0.4 netmask ff000000 broadcast 10.255.255.255
bge2:11: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 4
        inet 10.53.0.5 netmask ff000000 broadcast 10.255.255.255
bge2:12: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 4
        inet 10.53.0.6 netmask ff000000 broadcast 10.255.255.255
bge2:13: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 4
        inet 10.53.0.7 netmask ff000000 broadcast 10.255.255.255
bge2:14: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 4
        inet 10.53.0.8 netmask ff000000 broadcast 10.255.255.255
bge2:15: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 4
        inet 10.53.0.9 netmask ff000000 broadcast 10.255.255.255
bge2:16: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 4
        inet 10.53.0.10 netmask ff000000 broadcast 10.255.255.255
bge2:17: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 4
        inet 10.53.1.1 netmask ff000000 broadcast 10.255.255.255
bge2:18: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 4
        inet 10.53.1.2 netmask ff000000 broadcast 10.255.255.255
bge2:19: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 4
        inet 10.53.2.1 netmask ff000000 broadcast 10.255.255.255
bge2:20: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 4
        inet 10.53.2.2 netmask ff000000 broadcast 10.255.255.255
lo0:6: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu
8252 index 1
        inet6 ::1/128
bge2:1: flags=2000801<UP,MULTICAST,IPv6> mtu 1500 index 4
        inet6 fd92:7065:b8e:ffff::1/128
bge2:2: flags=2000801<UP,MULTICAST,IPv6> mtu 1500 index 4
        inet6 fd92:7065:b8e:ffff::2/128
bge2:3: flags=2000801<UP,MULTICAST,IPv6> mtu 1500 index 4
        inet6 fd92:7065:b8e:ffff::3/128
bge2:4: flags=2000801<UP,MULTICAST,IPv6> mtu 1500 index 4
        inet6 fd92:7065:b8e:ffff::4/128
bge2:5: flags=2000801<UP,MULTICAST,IPv6> mtu 1500 index 4
        inet6 fd92:7065:b8e:ffff::5/128
bge2:6: flags=2000801<UP,MULTICAST,IPv6> mtu 1500 index 4
        inet6 fd92:7065:b8e:ffff::6/128
bge2:7: flags=2000801<UP,MULTICAST,IPv6> mtu 1500 index 4
        inet6 fd92:7065:b8e:ffff::7/128
bge2:8: flags=2000801<UP,MULTICAST,IPv6> mtu 1500 index 4
        inet6 fd92:7065:b8e:ffff::8/128
bge2:9: flags=2000801<UP,MULTICAST,IPv6> mtu 1500 index 4
        inet6 fd92:7065:b8e:ffff::9/128
bge2:10: flags=2000801<UP,MULTICAST,IPv6> mtu 1500 index 4
        inet6 fd92:7065:b8e:ffff::10/128
bge2:11: flags=2000801<UP,MULTICAST,IPv6> mtu 1500 index 4
        inet6 fd92:7065:b8e:99ff::1/128
bge2:12: flags=2000801<UP,MULTICAST,IPv6> mtu 1500 index 4
        inet6 fd92:7065:b8e:99ff::2/128
bge2:13: flags=2000801<UP,MULTICAST,IPv6> mtu 1500 index 4
        inet6 fd92:7065:b8e:ff::1/128
bge2:14: flags=2000801<UP,MULTICAST,IPv6> mtu 1500 index 4
        inet6 fd92:7065:b8e:ff::2/128
bge2:15: flags=2000801<UP,MULTICAST,IPv6> mtu 1500 index 4
        inet6 fe80::203:baff:fe13:3c25/10
dude at nix$
dude at nix$ ./runall.sh -n
+ SYSTEMTESTTOP=.
+ . ./conf.sh
++ TOP=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005
++ DEFAULT_ALGORITHM=RSASHA256
++ DEFAULT_ALGORITHM_NUMBER=8
++ DEFAULT_BITS=1280
++ TMPDIR=/tmp
++ ALTERNATIVE_ALGORITHM=RSASHA1
++ ALTERNATIVE_ALGORITHM_NUMBER=5
++ ALTERNATIVE_BITS=1280
++ DISABLED_ALGORITHM=ECDSAP384SHA384
++ DISABLED_ALGORITHM_NUMBER=14
++ DISABLED_BITS=384
++ NAMED=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/named/named
++
LWRESD='/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/named/named -l'
++ DIG=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dig/dig
++ DELV=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/delv/delv
++ RNDC=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/rndc/rndc
++
NSUPDATE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/nsupdate/nsupdate
++
DDNSCONFGEN=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/confgen/ddns-confgen
++
TSIGKEYGEN=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/confgen/tsig-keygen
++
RNDCCONFGEN=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/confgen/rndc-confgen
++
KEYGEN=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-keygen
++
KEYFRLAB=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-keyfromlabel
++
SIGNER=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-signzone
++
REVOKE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-revoke
++
SETTIME=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-settime
++
DSFROMKEY=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-dsfromkey
++ HOST=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dig/host
++
IMPORTKEY=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-importkey
++
CHECKDS=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/python/dnssec-checkds
++
COVERAGE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/python/dnssec-coverage
++
KEYMGR=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/python/dnssec-keymgr
++
CHECKZONE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/check/named-checkzone
++
CHECKCONF=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/check/named-checkconf
++
PK11GEN='/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/pkcs11/pkcs11-keygen
-q -s 0 -p 1234'
++
PK11LIST='/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/pkcs11/pkcs11-list
-s 0 -p 1234'
++
PK11DEL='/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/pkcs11/pkcs11-destroy
-s 0 -p 1234 -w 0'
++
JOURNALPRINT=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/named-journalprint
++
VERIFY=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-verify
++
ARPANAME=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/arpaname
++
RESOLVE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/lib/samples/resolve
++
RRCHECKER=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/named-rrchecker
++
GENRANDOM=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/genrandom
++
NSLOOKUP=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dig/nslookup
++
DNSTAPREAD=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/dnstap-read
++ MDIG=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/mdig
++
NZD2NZF=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/named-nzd2nzf
++ FSTRM_CAPTURE=
++
FEATURETEST=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/feature-test
++
RANDFILE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/random.data
++
BIGKEY=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/rsabigexponent/bigkey
++
GENCHECK=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/rndc/gencheck
++
KEYCREATE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/tkey/keycreate
++
KEYDELETE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/tkey/keydelete
++
LWTEST=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/lwresd/lwtest
++
MAKEJOURNAL=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/makejournal
++
PIPEQUERIES=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/pipelined/pipequeries
++
SAMPLEUPDATE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/lib/samples/sample-update
++ KRB5_CONFIG=/dev/null
++ RANDOMSIZE=4096
++ SEQUENTIALDIRS='ecdsa eddsa gost lwresd  tkey'
++ PARALLELDIRS='dnssec rpzrecurse      acl additional addzone
allow-query auth autosign        builtin cacheclean case catz chain
 checkconf checknames checkzone          cookie database digdelv dlv dlz
dlzexternal     dns64  dscp dsdigest dyndb      ednscompliance
emptyzones       fetchlimit filter-aaaa formerr forward  geoip geoip2
glue idna inline integrity ixfr    legacy limits logfileconfig
masterfile masterformat metadata mkeys  names notify nslookup nsupdate
nzd2nzf  pending pipelined       reclimit redirect resolver rndc
rootkeysentinel rpz     rrchecker rrl rrsetorder rsabigexponent runtime
        sfcache smartsign sortlist      spf staticstub statistics
statschannel stub     tcp tsig tsiggss        unknown upforwd verify
views wildcard   xfer xferquota zero zonechecks'
++ SUBDIRS='ecdsa eddsa gost lwresd  tkey dnssec rpzrecurse     acl
additional addzone allow-query auth autosign        builtin cacheclean
case catz chain      checkconf checknames checkzone          cookie
database digdelv dlv dlz dlzexternal     dns64  dscp dsdigest dyndb
 ednscompliance emptyzones       fetchlimit filter-aaaa formerr forward
 geoip geoip2 glue idna inline integrity ixfr    legacy limits
logfileconfig     masterfile masterformat metadata mkeys  names notify
nslookup nsupdate nzd2nzf  pending pipelined       reclimit redirect
resolver rndc rootkeysentinel rpz     rrchecker rrl rrsetorder
rsabigexponent runtime         sfcache smartsign sortlist      spf
staticstub statistics statschannel stub     tcp tsig tsiggss
unknown upforwd verify views wildcard   xfer xferquota zero zonechecks'
++ KILL=kill
++ DIFF=diff
++ DOS2UNIX=true
++ TP=.
++ SHELL=/opt/bw/bin/bash
++ CURL=/opt/bw/bin/curl
++ XMLLINT=/opt/bw/bin/xmllint
++ XSLTPROC=/bin/xsltproc
++ PERL=/opt/bw/bin/perl
++ PSSUSPEND=
++ PYTHON=
++ CHECK_DSA=0
++ HAVEXMLSTATS=1
++ HAVEJSONSTATS=
++ ZLIB=1
++ NZD=
++ . /opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/version
+++ PRODUCT=BIND
+++ DESCRIPTION='(Extended Support Version)'
+++ MAJORVER=9
+++ MINORVER=11
+++ PATCHVER=31
+++ RELEASETYPE=
+++ RELEASEVER=
+++ EXTENSIONS=
++ '[' 0 -eq 1 ']'
++ test -t 1
++ type tput
++ tput setaf 7
++ COLOR_END=
++ COLOR_FAIL=
++ COLOR_INFO=
++ COLOR_NONE=
++ COLOR_PASS=
++ COLOR_START=
++ COLOR_WARN=
+++ basename
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system
++ SYSTESTDIR=system
++ type printf
++ export ARPANAME
++ export BIGKEY
++ export CHECKZONE
++ export CYGWIN
++ export DESCRIPTION
++ export DIG
++ export FEATURETEST
++ export FSTRM_CAPTURE
++ export GENCHECK
++ export JOURNALPRINT
++ export KEYCREATE
++ export KEYDELETE
++ export KEYFRLAB
++ export KEYGEN
++ export KEYSETTOOL
++ export KEYSIGNER
++ export KRB5_CONFIG
++ export LWRESD
++ export LWTEST
++ export MAKEJOURNAL
++ export MDIG
++ export NAMED
++ export NSLOOKUP
++ export NSUPDATE
++ export NZD2NZF
++ export PERL
++ export PIPEQUERIES
++ export PK11DEL
++ export PK11GEN
++ export PK11LIST
++ export PSSUSPEND
++ export PYTHON
++ export RANDFILE
++ export RESOLVE
++ export RNDC
++ export RRCHECKER
++ export SAMPLEUPDATE
++ export SIGNER
++ export SUBDIRS
++ export TMPDIR
+ usage='Usage: ./runall.sh [-c] [-n] [numprocesses]'
+ SYSTEMTEST_FORCE_COLOR=0
+ SYSTEMTEST_NO_CLEAN=0
+ getopts cn flag
+ case "$flag" in
+ SYSTEMTEST_NO_CLEAN=1
+ getopts cn flag
+ export NOCLEAN
++ expr 2 - 1
+ shift 1
+ '[' 0 -eq 0 ']'
+ numproc=1
+ export SYSTEMTEST_FORCE_COLOR
+ export SYSTEMTEST_NO_CLEAN
+ status=0
+ '[' '' = '' ']'
+ '[' '' = '' ']'
+ make -j 1 check
make: Warning: Ignoring DistributedMake -j option
/opt/bw/bin/bash parallel.sh > parallel.mk
making all in
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/dlzexternal
make: Warning: Ignoring DistributedMake -j option
making all in
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/dyndb
make: Warning: Ignoring DistributedMake -j option
making all in
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/dyndb/driver
make: Warning: Ignoring DistributedMake -j option
making all in
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/lwresd
make: Warning: Ignoring DistributedMake -j option
making all in
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/pipelined
make: Warning: Ignoring DistributedMake -j option
making all in
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/rndc
make: Warning: Ignoring DistributedMake -j option
making all in
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/rsabigexponent
make: Warning: Ignoring DistributedMake -j option
making all in
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/tkey
make: Warning: Ignoring DistributedMake -j option
make: Warning: Ignoring DistributedMake -j option
S:dnssec:Fri May  7 17:55:31 GMT 2021
T:dnssec:1:A
A:dnssec:System test dnssec
I:dnssec:PORTRANGE:5000 - 5099
I:dnssec:This test requires Python and the dnspython module.
I:dnssec:Prerequisites missing, skipping test.
R:dnssec:UNTESTED
E:dnssec:Fri May  7 17:55:32 GMT 2021
S:rpzrecurse:Fri May  7 17:55:32 GMT 2021
T:rpzrecurse:1:A
A:rpzrecurse:System test rpzrecurse
I:rpzrecurse:PORTRANGE:5100 - 5199
I:rpzrecurse:This test requires support for cryptography
I:rpzrecurse:configure with --with-openssl, or --enable-native-pkcs11
--with-pkcs11
I:rpzrecurse:Prerequisites missing, skipping test.
R:rpzrecurse:SKIPPED
E:rpzrecurse:Fri May  7 17:55:32 GMT 2021
S:acl:Fri May  7 17:55:32 GMT 2021
T:acl:1:A
A:acl:System test acl
I:acl:PORTRANGE:5200 - 5299
setup.sh: line 15: ns2/example.db: Permission denied
setup.sh: line 16: ns2/tsigzone.db: Permission denied
../conf.sh: line 588: ns2/named.conf: Permission denied
../conf.sh: line 588: ns3/named.conf: Permission denied
../conf.sh: line 588: ns4/named.conf: Permission denied
sh: named.run: cannot create
I:acl:Couldn't start server
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/named/named -D
acl-ns2 -X named.lock -m record,size,mctx -T clienttest -c named.conf -d
99 -g -U 4 >named.run 2>&1 & echo $! (pid=16752)
I:acl:failed
kill: 16752: no such process
R:acl:FAIL
E:acl:Fri May  7 17:55:48 GMT 2021
S:additional:Fri May  7 17:55:48 GMT 2021
T:additional:1:A
A:additional:System test additional
I:additional:PORTRANGE:5300 - 5399
../conf.sh: line 588: ns1/named.conf: Permission denied
../conf.sh: line 588: ns3/named.conf: Permission denied
sh: named.run: cannot create
I:additional:Couldn't start server
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/named/named -m
record,size,mctx -c named.conf -d 99 -D additional-ns1 -X named.lock -g
-T clienttest -n 1 >named.run 2>&1 & echo $! (pid=16795)
I:additional:failed
kill: 16795: no such process
R:additional:FAIL
E:additional:Fri May  7 17:56:04 GMT 2021
S:addzone:Fri May  7 17:56:04 GMT 2021
T:addzone:1:A
A:addzone:System test addzone
I:addzone:PORTRANGE:5400 - 5499
../conf.sh: line 588: ns1/named.conf: Permission denied
../conf.sh: line 588: ns2/named.conf: Permission denied
cp: cannot create ns2/3bf305731dd26307.nzf: Permission denied
../conf.sh: line 588: ns3/named.conf: Permission denied
sh: named.run: cannot create
I:addzone:Couldn't start server
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/named/named -D
addzone-ns1 -X named.lock -m record,size,mctx -T clienttest -c
named.conf -d 99 -g -U 4 >named.run 2>&1 & echo $! (pid=16853)
I:addzone:failed
kill: 16853: no such process
R:addzone:FAIL
E:addzone:Fri May  7 17:56:19 GMT 2021
S:allow-query:Fri May  7 17:56:19 GMT 2021
T:allow-query:1:A
A:allow-query:System test allow-query
I:allow-query:PORTRANGE:5500 - 5599
../conf.sh: line 588: ns2/controls.conf: Permission denied
../conf.sh: line 588: ns1/named.conf: Permission denied
../conf.sh: line 588: ns2/named.conf: Permission denied
../conf.sh: line 588: ns3/named.conf: Permission denied
sh: named.run: cannot create
I:allow-query:Couldn't start server
/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/named/named -D
allow-query-ns1 -X named.lock -m record,size,mctx -T clienttest -c
named.conf -d 99 -g -U 4 >named.run 2>&1 & echo $! (pid=16899)
I:allow-query:failed
kill: 16899: no such process
R:allow-query:FAIL
E:allow-query:Fri May  7 17:56:35 GMT 2021
S:auth:Fri May  7 17:56:35 GMT 2021
T:auth:1:A
A:auth:System test auth
I:auth:PORTRANGE:5600 - 5699
../conf.sh: line 588: ns1/named.conf: Permission denied
../conf.sh: line 588: ns2/named.conf: Permission denied
sh: named.run: cannot create
^Cdude at nix$
dude at nix$

The username "dude" is in the group "devl" wherein the tests directory
is chmod 775 so I think perhaps a lot of other stuff may need to also
be writable.

I may try to slice along through this or just give "dude" write
access to everything in the build pile.  Could work?

Dennis


From kmcgrail at pccc.com  Fri May  7 18:21:29 2021
From: kmcgrail at pccc.com (Kevin A. McGrail)
Date: Fri, 7 May 2021 14:21:29 -0400
Subject: [External] strange queries incrementing letter by letter
In-Reply-To: <1493172176.1490122.1620408743205.JavaMail.zimbra@kretz.net>
References: <1493172176.1490122.1620408743205.JavaMail.zimbra@kretz.net>
Message-ID: <d29be319-57c0-9cec-b279-1c3c0d68d6eb@pccc.com>

Weird.

Thoughts are:

Bad software?? What we call ratware.

UDP/TCP Firewall issues?

Regards,

KAM

On 5/7/2021 1:32 PM, Kevin Kretz wrote:
> I see occasional series of queries like this, from within my network 
> and among disparate types of host (linux, windows):
>
> If there's a host called
>
> hostname.mynet.com
>
> I'll see a sequence of queries like
>
> hostname.m
> hostname.my
> hostname.myn
> hostname.myne
> hostname.mynet
> hostname.mynet.c
> hostname.mynet.co
> hostname.mynet.com
>
> Can anyone tell me what this is?
>
>
> thanks
>
> Kevin
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 


	

	*Kevin A. McGrail*
/CEO Emeritus/
*Peregrine Computer Consultants Corporation*
	+1.703.798.0171 		kmcgrail at pccc.com
	?https://pccc.com/ 		https://raptoremailsecurity.com

	10311 Cascade Lane, Fairfax, Virginia 22032-2357 USA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210507/d49a1f2a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PCCC-Logo-Vertical-Blue-75x75.png
Type: image/png
Size: 4745 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210507/d49a1f2a/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: raptor-logo-vertical-blue-75x75.png
Type: image/png
Size: 5456 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210507/d49a1f2a/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: phone_sig_icon_orange.png
Type: image/png
Size: 494 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210507/d49a1f2a/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: email_sig_icon_orange.png
Type: image/png
Size: 395 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210507/d49a1f2a/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: web_sig_icon_orange.png
Type: image/png
Size: 918 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210507/d49a1f2a/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: location_sig_icon_orange.png
Type: image/png
Size: 561 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210507/d49a1f2a/attachment-0011.png>

From ondrej at isc.org  Fri May  7 18:54:34 2021
From: ondrej at isc.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Fri, 7 May 2021 20:54:34 +0200
Subject: BIND 9.16.15 Windows x64 broken?
In-Reply-To: <LO2P123MB4110A697D75FAB5F3F299EABB3579@LO2P123MB4110.GBRP123.PROD.OUTLOOK.COM>
References: <LO2P123MB4110A697D75FAB5F3F299EABB3579@LO2P123MB4110.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <3DA8127A-34B8-43CA-A5E0-86B37C14A271@isc.org>

The list of supported platforms for 9.16 is here: https://gitlab.isc.org/isc-projects/bind9/-/blob/v9_16/PLATFORMS.md

And here?s the simplified table: https://kb.isc.org/docs/supported-platforms

--
Ond?ej Sur? ? ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 7. 5. 2021, at 19:52, Richard T.A. Neal <richard at richardneal.com> wrote:
> 
> ?
> Hi Jukka,
>  
> I spun-up a brand new Windows 2008 R2 Enterprise x64 server today to try and replicate this, and unfortunately you?re right ? BIND 9.16.15 won?t run on that environment.
>  
> In fact if you simply try and run [dig] from the command line you will get this:
>  
> /////
> The procedure entry point GetSystemTimePreciseAsFileTime could not be located in the dynamic link library KERNEL32.dll
> /////
>  
> Having done a bit of Google?ing it appears that this method /procedure is not available in Window 7 / 2008 R2. As such it?s never going to work.
>  
> I hate to be ?that guy? but Windows Server 2008 R2 is of course long out-of-support from Microsoft unless you happen to have an Extended Support Agreement with them. How feasible is it for you to upgrade your Windows BIND servers to Windows Server 2012 R2 or higher?
>  
> Richard.
>  
> From: bind-users <bind-users-bounces at lists.isc.org> On Behalf Of Jukka Pakkanen
> Sent: 06 May 2021 11:10 pm
> To: bind-users at isc.org
> Subject: BIND 9.16.15 Windows x64 broken?
>  
> What changed between Bind 9.16.13 and 9.16.15 Windows x64 binaries?
> 
> 9.16.15 will not start at all in Server 2008 R2 Enterprise x64, 9.16.13 worked fine.
> 
> Only get ?The service is not responding to the control function? when trying to start the service.
> 
> Tried this as an upgrade to the 9.16.13, or as a fresh install, same result in both cases.  Downgrading to 9.16.13 and works fine again.
> 
> Jukka
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210507/4699d80b/attachment.htm>

From dclarke at blastwave.org  Fri May  7 18:55:04 2021
From: dclarke at blastwave.org (Dennis Clarke)
Date: Fri, 7 May 2021 14:55:04 -0400
Subject: took a while to figure out why all your tests fail
In-Reply-To: <C1AEAB69-E07C-4849-9D2C-3F6F3CA97141@isc.org>
References: <24a1c608-19aa-6c1e-d141-a6866555204e@blastwave.org>
 <C1AEAB69-E07C-4849-9D2C-3F6F3CA97141@isc.org>
Message-ID: <d9e24330-b3f5-a14d-a98f-39f41d8a7a84@blastwave.org>

On 5/6/21 19:03, Mark Andrews wrote:
> First of all the user running the tests needs to be able to write to bin/tests/system. See the permission denied from tee. 
> 


Well I gave up and decided to run the tests with the same userid and
gid as the acct that created the build.

However I see a whack of :

I:allow-query:exit status: 0
find: bad option -or
find: [-H | -L] path-list predicate-list
find: bad option -print0
find: [-H | -L] path-list predicate-list
xargs: illegal option -- 0
xargs: Usage: xargs: [-t] [-p] [-e[eofstr]] [-E eofstr] [-I replstr]
[-i[replstr]] [-L #] [-l[#]] [-n # [-x]] [-s size] [cmd [args ...]]
R:allow-query:PASS


So I guess there are hard coded gnuisms in there?

Dennis

From marka at isc.org  Fri May  7 19:11:30 2021
From: marka at isc.org (Mark Andrews)
Date: Sat, 8 May 2021 05:11:30 +1000
Subject: [External] strange queries incrementing letter by letter
In-Reply-To: <d29be319-57c0-9cec-b279-1c3c0d68d6eb@pccc.com>
References: <d29be319-57c0-9cec-b279-1c3c0d68d6eb@pccc.com>
Message-ID: <D604FA1F-6017-4E1A-ADAD-CBECEC5F7B05@isc.org>

Some piece of software trying to speed up resolution by resolving names as you type.

-- 
Mark Andrews

> On 8 May 2021, at 04:21, Kevin A. McGrail <kmcgrail at pccc.com> wrote:
> 
> ?
> Weird.
> 
> Thoughts are:
> 
> Bad software?  What we call ratware.  
> 
> UDP/TCP Firewall issues?
> 
> Regards,
> 
> KAM
> 
>> On 5/7/2021 1:32 PM, Kevin Kretz wrote:
>> I see occasional series of queries like this, from within my network and among disparate types of host (linux, windows):
>> 
>> If there's a host called 
>> 
>> hostname.mynet.com
>> 
>> I'll see a sequence of queries like
>> 
>> hostname.m
>> hostname.my
>> hostname.myn
>> hostname.myne
>> hostname.mynet
>> hostname.mynet.c
>> hostname.mynet.co
>> hostname.mynet.com
>> 
>> Can anyone tell me what this is?
>> 
>> 
>> thanks
>> 
>> Kevin
>> 
>> 
>> 
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>> 
>> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>> 
>> 
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> -- 
> <PCCC-Logo-Vertical-Blue-75x75.png>
> 
> <raptor-logo-vertical-blue-75x75.png>
> 
>  
> 
> Kevin A. McGrail
> CEO Emeritus
> Peregrine Computer Consultants Corporation
>  
> <phone_sig_icon_orange.png>
> +1.703.798.0171	
> <email_sig_icon_orange.png>
> kmcgrail at pccc.com
> <web_sig_icon_orange.png>
>  https://pccc.com/	
> <web_sig_icon_orange.png>
> https://raptoremailsecurity.com
> <location_sig_icon_orange.png>
> 10311 Cascade Lane, Fairfax, Virginia 22032-2357 USA
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210508/0cfb8acc/attachment.htm>

From ondrej at isc.org  Fri May  7 19:29:36 2021
From: ondrej at isc.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Fri, 7 May 2021 21:29:36 +0200
Subject: [External] strange queries incrementing letter by letter
In-Reply-To: <D604FA1F-6017-4E1A-ADAD-CBECEC5F7B05@isc.org>
References: <D604FA1F-6017-4E1A-ADAD-CBECEC5F7B05@isc.org>
Message-ID: <A14FF942-E69B-48CB-A9C1-001428ABF5AB@isc.org>

aka browsers

--
Ond?ej Sur? ? ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 7. 5. 2021, at 21:11, Mark Andrews <marka at isc.org> wrote:
> 
> ?Some piece of software trying to speed up resolution by resolving names as you type.
> 
> -- 
> Mark Andrews
> 
>>> On 8 May 2021, at 04:21, Kevin A. McGrail <kmcgrail at pccc.com> wrote:
>>> 
>> ?
>> Weird.
>> 
>> Thoughts are:
>> 
>> Bad software?  What we call ratware.  
>> 
>> UDP/TCP Firewall issues?
>> 
>> Regards,
>> 
>> KAM
>> 
>>> On 5/7/2021 1:32 PM, Kevin Kretz wrote:
>>> I see occasional series of queries like this, from within my network and among disparate types of host (linux, windows):
>>> 
>>> If there's a host called 
>>> 
>>> hostname.mynet.com
>>> 
>>> I'll see a sequence of queries like
>>> 
>>> hostname.m
>>> hostname.my
>>> hostname.myn
>>> hostname.myne
>>> hostname.mynet
>>> hostname.mynet.c
>>> hostname.mynet.co
>>> hostname.mynet.com
>>> 
>>> Can anyone tell me what this is?
>>> 
>>> 
>>> thanks
>>> 
>>> Kevin
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>> 
>>> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>>> 
>>> 
>>> bind-users mailing list
>>> bind-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>> -- 
>> <PCCC-Logo-Vertical-Blue-75x75.png>
>> 
>> <raptor-logo-vertical-blue-75x75.png>
>>  
>> 
>> Kevin A. McGrail
>> CEO Emeritus
>> Peregrine Computer Consultants Corporation
>>  
>> <phone_sig_icon_orange.png>
>> +1.703.798.0171	
>> <email_sig_icon_orange.png>
>> kmcgrail at pccc.com
>> <web_sig_icon_orange.png>
>>  https://pccc.com/	
>> <web_sig_icon_orange.png>
>> https://raptoremailsecurity.com
>> <location_sig_icon_orange.png>
>> 10311 Cascade Lane, Fairfax, Virginia 22032-2357 USA
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>> 
>> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>> 
>> 
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210507/aabf43f5/attachment-0001.htm>

From dclarke at blastwave.org  Fri May  7 19:51:03 2021
From: dclarke at blastwave.org (Dennis Clarke)
Date: Fri, 7 May 2021 15:51:03 -0400
Subject: how to run tests separately
Message-ID: <3df1b022-98df-0d9b-f1d2-349ad81b377f@blastwave.org>


My test results are a little suspect :

.
.
.
I:ok
I:lwresd:using nosearch.conf
I:ok
I:lwresd:exit status: 0
find: bad option -or
find: [-H | -L] path-list predicate-list
xargs: illegal option -- 0
xargs: find: bad option -print0Usage: xargs: [-t] [-p] [-e[eofstr]] [-E
eofstr] [-I replstr] [-i[replstr]] [-L #] [-l[#]] [-n # [-x]] [-s size]
[cmd [args ...]]

find: [-H | -L] path-list predicate-list
R:lwresd:PASS
E:lwresd:Fri May  7 19:37:44 GMT 2021
S:tkey:Fri May  7 19:37:44 GMT 2021
T:tkey:1:A
A:tkey:System test tkey
I:tkey:PORTRANGE:5300 - 5399
I:tkey:generating new DH key (1)
I:tkey:creating new key using owner name "." (2)
I:tkey:checking the new key (3)
I:tkey:deleting new key (4)
I:tkey:checking that new key has been deleted (5)
I:tkey:creating new key using owner name "foo.example." (6)
I:tkey:checking the new key (7)
I:tkey:deleting new key (8)
I:tkey:checking that new key has been deleted (9)
I:tkey:creating new key using owner name bar.example. (10)
I:tkey:checking the key with 'rndc tsig-list' (11)
I:tkey:using key in a request (12)
I:tkey:deleting the key with 'rndc tsig-delete' (13)
I:tkey:recreating the bar.example. key (14)
I:tkey:checking the new key with 'rndc tsig-list' (15)
I:tkey:using the new key in a request (16)
I:tkey:exit status: 0
find: bad option -or
find: [-H | -L] path-list predicate-list
xargs: illegal option -- 0
find: bad option -print0
find: [-H | -L] path-list predicate-list
xargs: Usage: xargs: [-t] [-p] [-e[eofstr]] [-E eofstr] [-I replstr]
[-i[replstr]] [-L #] [-l[#]] [-n # [-x]] [-s size] [cmd [args ...]]
R:tkey:PASS
E:tkey:Fri May  7 19:37:51 GMT 2021
I:System test result summary:
I:   4 FAIL
I:  65 PASS
I:   5 SKIPPED
I:  15 UNTESTED
I:The following system tests failed:
I:      autosign
I:      ecdsa
I:      nsupdate
I:      tsig
find: bad option -or
find: [-H | -L] path-list predicate-list
*** Error code 1
The following command caused the error:
/opt/bw/bin/bash ./testsummary.sh
make: Fatal error: Command failed for target `test'
-bash-5.0$


Let's ignore the bad xargs and find options for now. How can I run those
 tests as separate items manually ?

-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

From ondrej at isc.org  Fri May  7 20:00:08 2021
From: ondrej at isc.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Fri, 7 May 2021 22:00:08 +0200
Subject: took a while to figure out why all your tests fail
In-Reply-To: <d9e24330-b3f5-a14d-a98f-39f41d8a7a84@blastwave.org>
References: <d9e24330-b3f5-a14d-a98f-39f41d8a7a84@blastwave.org>
Message-ID: <FEDBC1F6-BC0D-409B-A818-02B717132509@isc.org>

No, the tests run fine on BSDs, there are no gnuisms.

Solaris just isn?t on our supported platform list and it should really make an effort to be more compatible with the rest of the world. find -print0 and xargs -0 might not be exactly POSIX.1, but it?s important for safe passing of filenames.

Ondrej
--
Ond?ej Sur? ? ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 7. 5. 2021, at 20:55, Dennis Clarke via bind-users <bind-users at lists.isc.org> wrote:
> So I guess there are hard coded gnuisms in there?


From dclarke at blastwave.org  Fri May  7 20:32:34 2021
From: dclarke at blastwave.org (Dennis Clarke)
Date: Fri, 7 May 2021 16:32:34 -0400
Subject: took a while to figure out why all your tests fail
In-Reply-To: <FEDBC1F6-BC0D-409B-A818-02B717132509@isc.org>
References: <d9e24330-b3f5-a14d-a98f-39f41d8a7a84@blastwave.org>
 <FEDBC1F6-BC0D-409B-A818-02B717132509@isc.org>
Message-ID: <82fd28b8-f8bf-c10a-6f80-bc53dd63150b@blastwave.org>

On 5/7/21 16:00, Ond?ej Sur? wrote:
> No, the tests run fine on BSDs, there are no gnuisms.
> 
> Solaris just isn?t on our supported platform list

Oh thats right .. you guys dropped it.

Still a whack of legacy boxes out there running but I guess
not ISC Bind in the very very very near future anyways.

.whatever.

Dennis

From elliott.chas at comcast.net  Sat May  8 11:09:23 2021
From: elliott.chas at comcast.net (Charles Elliott)
Date: Sat, 8 May 2021 07:09:23 -0400
Subject: [External] strange queries incrementing letter by letter
In-Reply-To: <A14FF942-E69B-48CB-A9C1-001428ABF5AB@isc.org>
References: <D604FA1F-6017-4E1A-ADAD-CBECEC5F7B05@isc.org>
 <A14FF942-E69B-48CB-A9C1-001428ABF5AB@isc.org>
Message-ID: <000801d743fa$9c61a950$d524fbf0$@comcast.net>

It could also be a really cleaver security ploy to see if there are any close matches to your domain name or URL that turn up copycats or bad guys.

For example, typing Walmrat into Chrome and pressing Ctrl+Enter used turn up a copycat Walmart site, but now one accesses a correctly spelled 

Walmart URL and the actual website.   As another illustration, at least it used to be common with misspelled bank names to access a copycat 

website or one or more claiming a special connection to the actual bank.

 

The Web is like Europe before and during the 1100 s when it was common for unemployed soldiers to roam the highways and byways looking

for people to rob and damsels to distress.  We need something like knighthood, the first state police.

 

Charles Elliott

From: bind-users [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Ondrej Sur?
Sent: Friday, May 7, 2021 3:30 PM
To: Mark Andrews <marka at isc.org>
Cc: bind-users at lists.isc.org
Subject: Re: [External] strange queries incrementing letter by letter

 

aka browsers

--

Ond?ej Sur? ? ISC (He/Him)

 

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.





On 7. 5. 2021, at 21:11, Mark Andrews <marka at isc.org <mailto:marka at isc.org> > wrote:

?Some piece of software trying to speed up resolution by resolving names as you type.

-- 

Mark Andrews





On 8 May 2021, at 04:21, Kevin A. McGrail <kmcgrail at pccc.com <mailto:kmcgrail at pccc.com> > wrote:

? 

Weird.

Thoughts are:

Bad software?  What we call ratware.  

UDP/TCP Firewall issues?

Regards,

KAM

On 5/7/2021 1:32 PM, Kevin Kretz wrote:

I see occasional series of queries like this, from within my network and among disparate types of host (linux, windows):

 

If there's a host called 

 

hostname.mynet.com

 

I'll see a sequence of queries like

 

hostname.m

hostname.my

hostname.myn

hostname.myne

hostname.mynet

hostname.mynet.c

hostname.mynet.co

hostname.mynet.com

 

Can anyone tell me what this is?

 

thanks


Kevin

 





_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
 
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
 
 
bind-users mailing list
bind-users at lists.isc.org <mailto:bind-users at lists.isc.org> 
https://lists.isc.org/mailman/listinfo/bind-users

-- 


<PCCC-Logo-Vertical-Blue-75x75.png>

 

<raptor-logo-vertical-blue-75x75.png>

 

Kevin A. McGrail
CEO Emeritus
Peregrine Computer Consultants Corporation
  


<phone_sig_icon_orange.png>

+1.703.798.0171

<email_sig_icon_orange.png>

kmcgrail at pccc.com <mailto:kmcgrail at pccc.com> 


<web_sig_icon_orange.png>

 https://pccc.com/

<web_sig_icon_orange.png>

https://raptoremailsecurity.com

 


<location_sig_icon_orange.png>

10311 Cascade Lane, Fairfax, Virginia 22032-2357 USA

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users at lists.isc.org <mailto:bind-users at lists.isc.org> 
https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users at lists.isc.org <mailto:bind-users at lists.isc.org> 
https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210508/cf875256/attachment-0001.htm>

From each at isc.org  Sat May  8 18:13:37 2021
From: each at isc.org (Evan Hunt)
Date: Sat, 8 May 2021 18:13:37 +0000
Subject: where are the testing docs ?
In-Reply-To: <f3ceaf81-d084-9d97-5cc1-25b9d2ed72ae@blastwave.org>
References: <b42b34ac-fc4c-6286-d43c-0710c5f4960f@blastwave.org>
 <12DDE1B3-B32F-439C-AF53-356D2AFF6210@isc.org>
 <f3ceaf81-d084-9d97-5cc1-25b9d2ed72ae@blastwave.org>
Message-ID: <20210508181337.GA56411@isc.org>

On Thu, May 06, 2021 at 11:57:58AM -0400, Dennis Clarke via bind-users wrote:
> I do NOT trust a build result where I had to go hacking into all the
> Makefiles just to get it to build. You install without doing testing?

I think Ondrej just meant that we haven't put much emphasis on making the
tests user-friendly, since most of the time you *don't* have to hack
makefiles. We generally use the tests to make sure we haven't broken
something while making changes, but we're not expecting everybody to
do so when installing a published release.  That said, I'm *delighted*
to see people running them.

We seem to have inadvertently removed a nice feature when the tests were
revamped a while back - it used to print a helpful message if you ran
"make check" without setting up the environment first, and told you what
you needed to do (specifically, "sudo sh bin/tests/system/ifconfig.sh up").
I think the message got lost when we switched to automake.

Some tests will be skipped if there are missing dependencies, so you may
also wish to install the Net::DNS, Net::DNS::Nameserver and XML::Simple
modules for perl, and dnspython for python.

-- 
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.

From dclarke at blastwave.org  Sat May  8 18:23:30 2021
From: dclarke at blastwave.org (Dennis Clarke)
Date: Sat, 8 May 2021 14:23:30 -0400
Subject: where are the testing docs ?
In-Reply-To: <20210508181337.GA56411@isc.org>
References: <b42b34ac-fc4c-6286-d43c-0710c5f4960f@blastwave.org>
 <12DDE1B3-B32F-439C-AF53-356D2AFF6210@isc.org>
 <f3ceaf81-d084-9d97-5cc1-25b9d2ed72ae@blastwave.org>
 <20210508181337.GA56411@isc.org>
Message-ID: <605ec738-ec8f-e28a-bf5b-91508a0cf498@blastwave.org>

On 5/8/21 14:13, Evan Hunt wrote:
> On Thu, May 06, 2021 at 11:57:58AM -0400, Dennis Clarke via bind-users wrote:
>> I do NOT trust a build result where I had to go hacking into all the
>> Makefiles just to get it to build. You install without doing testing?
> 
> I think Ondrej just meant that we haven't put much emphasis on making the
> tests user-friendly, since most of the time you *don't* have to hack
> makefiles. We generally use the tests to make sure we haven't broken
> something while making changes, but we're not expecting everybody to
> do so when installing a published release.  That said, I'm *delighted*
> to see people running them.
> 
> We seem to have inadvertently removed a nice feature when the tests were
> revamped a while back - it used to print a helpful message if you ran
> "make check" without setting up the environment first, and told you what
> you needed to do (specifically, "sudo sh bin/tests/system/ifconfig.sh up").
> I think the message got lost when we switched to automake.
> 
> Some tests will be skipped if there are missing dependencies, so you may
> also wish to install the Net::DNS, Net::DNS::Nameserver and XML::Simple
> modules for perl, and dnspython for python.
> 

Well to be fair the build result seems to be just fine. At least fine
enough on this legacy system. The idea is to rip this machine out of
existence in the next year regardless and that will be the last time I
ever look at Solaris or SPARC. End of an era and I think LawnMower Larry
wants things that way.  So 9.11.31 will be running as a service on some
Fujitsu SPARC64 boxen until Jan next year and that is he end of that.

For that matter, even Fujitsu tossed the platform out a window and they
built their latest supercomputer with arm64.  Lets hope that RISC-V will
get some traction but risc on big endian anything is an endangered
species rarely ever seen in the wild anymore.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

From xavier.humbert at ac-nancy-metz.fr  Sun May  9 10:32:01 2021
From: xavier.humbert at ac-nancy-metz.fr (Xavier Humbert)
Date: Sun, 9 May 2021 12:32:01 +0200
Subject: Strange DNS behaviour
Message-ID: <a5fc5899-844e-b97f-e8e0-76d657b142f0@ac-nancy-metz.fr>

Hi,

My DNS system if perfectly working :

> [xavier at numenor ~]$ dig dns.google.com
>
> ; <<>> DiG 9.16.15 <<>> dns.google.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12276
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; COOKIE: 7b606d7c32a99906010000006097b6d7f61894ea0a92dac2 (good)
> ;; QUESTION SECTION:
> ;dns.google.com.??????????????????????? 
> IN????? A
>
> ;; ANSWER SECTION:
> dns.google.com.???????? 880???? IN????? A?????? 
> 8.8.4.4
> dns.google.com.???????? 880???? IN????? A?????? 
> 8.8.8.8
>
> ;; Query time: 0 msec
> ;; SERVER: ::1#53(::1)
> ;; WHEN: Sun May 09 12:17:59 CEST 2021
> ;; MSG SIZE? rcvd: 103

On other hosts in my home, it works, too.

But on one machine, it fails :

> [xavier at feanor ~]$ dig @numenor dns.google.com +trace
>
> ; <<>> DiG 9.16.8-Ubuntu <<>> @numenor dns.google.com +trace
> ; (1 server found)
> ;; global options: +cmd
> . ??????????????????????518400 ?IN ?????NS 
> ?????m.root-servers.net.
> . ??????????????????????518400 ?IN ?????NS 
> ?????b.root-servers.net.
> . ??????????????????????518400 ?IN ?????NS 
> ?????e.root-servers.net.
> . ??????????????????????518400 ?IN ?????NS 
> ?????d.root-servers.net.
> . ??????????????????????518400 ?IN ?????NS 
> ?????h.root-servers.net.
> . ??????????????????????518400 ?IN ?????NS 
> ?????f.root-servers.net.
> . ??????????????????????518400 ?IN ?????NS 
> ?????g.root-servers.net.
> . ??????????????????????518400 ?IN ?????NS 
> ?????c.root-servers.net.
> . ??????????????????????518400 ?IN ?????NS 
> ?????i.root-servers.net.
> . ??????????????????????518400 ?IN ?????NS 
> ?????j.root-servers.net.
> . ??????????????????????518400 ?IN ?????NS 
> ?????k.root-servers.net.
> . ??????????????????????518400 ?IN ?????NS 
> ?????l.root-servers.net.
> . ??????????????????????518400 ?IN ?????NS 
> ?????a.root-servers.net.
> . ??????????????????????518400 ?IN 
> ?????RRSIG ??NS 8 0 518400 20210521170000 20210508160000 14631 
> . IgUiqHrRXT5hTAa5wnubyCL0T9iq+iRAQIUQlIStRYqZh6Qp5W3sZLum 
> 6O+EkYZALJda6RJwQY8oPEgQVQymGmGyAxcZBekX5vsMm8MgovQIA+Ev 
> SroSeV9yXDURHqt8af+25bw
> 6YyUQEOblPehxyUYYkF9cP8FlieAUw1Fn 
> HMvqpQlEn2sYS4UjA+euhcS2k7jnyEdBNbXbEZVq56zHK1aHPQIp2f4/ 
> byHaC55zPJ5rgLwMUh+8JuP47wb4NWAKIj76EUlqcidfI8hxZI5KPoNZ 
> vmIcEtQSfRYqVxoc+BiEEgalw5afAmXjEtvJaWm4v5383uatiQ1s9AgC MPQFHw==
> couldn't get address for 'm.root-servers.net': not found

None of the root servers can't be found. My root hint file is up to date.

The network configuration on this machine :

> [xavier at feanor ~]$ nmcli device show enp10s0
> GENERAL.DEVICE: ????????????????????????enp10s0
> GENERAL.TYPE: 
> ??????????????????????????ethernet
> GENERAL.HWADDR: 
> ????????????????????????04:7D:7B:02:68:67
> GENERAL.MTU: ???????????????????????????1500
> GENERAL.STATE: ?????????????????????????100 
> (connected)
> GENERAL.CONNECTION: ????????????????????Wired
> GENERAL.CON-PATH: 
> ??????????????????????/org/freedesktop/NetworkManager/ActiveConnection/3 
>
> WIRED-PROPERTIES.CARRIER: ??????????????on
> IP4.ADDRESS[1]: 
> ????????????????????????192.168.100.25/24
> IP4.GATEWAY: 
> ???????????????????????????192.168.100.254
> IP4.ROUTE[1]: ??????????????????????????dst 
> = 0.0.0.0/0, nh = 192.168.100.254, mt = 100
> IP4.ROUTE[2]: ??????????????????????????dst 
> = 192.168.100.0/24, nh = 0.0.0.0, mt = 100
> IP4.ROUTE[3]: ??????????????????????????dst 
> = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
> IP4.DNS[1]: 
> ????????????????????????????192.168.100.144
> IP4.DNS[2]: 
> ????????????????????????????192.168.100.254
This is not an ACL problem, the whole subnet is allowed. Nmap and/or 
telnet shows no blocked port problem

Trying on the secondary leads to the same behaviour

Eventually, I am lost.

Could anyone help ?

Thanks,

Regards

-- 
Xavier Humbert
CRT Supervision et Exploitation de Niveau 1
Rectorat de Nancy-Metz
03 83 86 27 39

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210509/a5a80129/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x90B78A89BCC49C10.asc
Type: application/pgp-keys
Size: 3154 bytes
Desc: OpenPGP public key
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210509/a5a80129/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210509/a5a80129/attachment-0003.bin>

From xavier.humbert at ac-nancy-metz.fr  Sun May  9 11:44:22 2021
From: xavier.humbert at ac-nancy-metz.fr (Xavier Humbert)
Date: Sun, 9 May 2021 13:44:22 +0200
Subject: [SOLVED] Re: Strange DNS behaviour
In-Reply-To: <a5fc5899-844e-b97f-e8e0-76d657b142f0@ac-nancy-metz.fr>
References: <a5fc5899-844e-b97f-e8e0-76d657b142f0@ac-nancy-metz.fr>
Message-ID: <51e3979a-c486-1128-0b76-7f127c6f2e19@ac-nancy-metz.fr>

On 09/05/2021 12:32, Xavier Humbert via bind-users wrote:
>
> Hi,
>
> My DNS system if perfectly working :
>
>> [xavier at numenor ~]$ dig dns.google.com
>>
>> ; <<>> DiG 9.16.15 <<>> dns.google.com
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12276
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 1232
>> ; COOKIE: 7b606d7c32a99906010000006097b6d7f61894ea0a92dac2 (good)
>> ;; QUESTION SECTION:
>> ;dns.google.com.??????????????????????? 
>> IN????? A
>>
>> ;; ANSWER SECTION:
>> dns.google.com.???????? 880???? IN????? 
>> A?????? 8.8.4.4
>> dns.google.com.???????? 880???? IN????? 
>> A?????? 8.8.8.8
>>
>> ;; Query time: 0 msec
>> ;; SERVER: ::1#53(::1)
>> ;; WHEN: Sun May 09 12:17:59 CEST 2021
>> ;; MSG SIZE? rcvd: 103
>
> On other hosts in my home, it works, too.
>
> But on one machine, it fails :
>
>> [xavier at feanor ~]$ dig @numenor dns.google.com +trace
>>
>> ; <<>> DiG 9.16.8-Ubuntu <<>> @numenor dns.google.com +trace
>> ; (1 server found)
>> ;; global options: +cmd
>> . ??????????????????????518400 ?IN 
>> ?????NS ?????m.root-servers.net.
>> . ??????????????????????518400 ?IN 
>> ?????NS ?????b.root-servers.net.
>> . ??????????????????????518400 ?IN 
>> ?????NS ?????e.root-servers.net.
>> . ??????????????????????518400 ?IN 
>> ?????NS ?????d.root-servers.net.
>> . ??????????????????????518400 ?IN 
>> ?????NS ?????h.root-servers.net.
>> . ??????????????????????518400 ?IN 
>> ?????NS ?????f.root-servers.net.
>> . ??????????????????????518400 ?IN 
>> ?????NS ?????g.root-servers.net.
>> . ??????????????????????518400 ?IN 
>> ?????NS ?????c.root-servers.net.
>> . ??????????????????????518400 ?IN 
>> ?????NS ?????i.root-servers.net.
>> . ??????????????????????518400 ?IN 
>> ?????NS ?????j.root-servers.net.
>> . ??????????????????????518400 ?IN 
>> ?????NS ?????k.root-servers.net.
>> . ??????????????????????518400 ?IN 
>> ?????NS ?????l.root-servers.net.
>> . ??????????????????????518400 ?IN 
>> ?????NS ?????a.root-servers.net.
>> . ??????????????????????518400 ?IN 
>> ?????RRSIG ??NS 8 0 518400 20210521170000 20210508160000 14631 
>> . IgUiqHrRXT5hTAa5wnubyCL0T9iq+iRAQIUQlIStRYqZh6Qp5W3sZLum 
>> 6O+EkYZALJda6RJwQY8oPEgQVQymGmGyAxcZBekX5vsMm8MgovQIA+Ev 
>> SroSeV9yXDURHqt8af+25bw
>> 6YyUQEOblPehxyUYYkF9cP8FlieAUw1Fn 
>> HMvqpQlEn2sYS4UjA+euhcS2k7jnyEdBNbXbEZVq56zHK1aHPQIp2f4/ 
>> byHaC55zPJ5rgLwMUh+8JuP47wb4NWAKIj76EUlqcidfI8hxZI5KPoNZ 
>> vmIcEtQSfRYqVxoc+BiEEgalw5afAmXjEtvJaWm4v5383uatiQ1s9AgC MPQFHw==
>> couldn't get address for 'm.root-servers.net': not found
>
> None of the root servers can't be found. My root hint file is up to date.
>
> The network configuration on this machine :
>
>> [xavier at feanor ~]$ nmcli device show enp10s0
>> GENERAL.DEVICE: ????????????????????????enp10s0
>> GENERAL.TYPE: 
>> ??????????????????????????ethernet
>> GENERAL.HWADDR: 
>> ????????????????????????04:7D:7B:02:68:67
>> GENERAL.MTU: ???????????????????????????1500
>> GENERAL.STATE: ?????????????????????????100 
>> (connected)
>> GENERAL.CONNECTION: ????????????????????Wired
>> GENERAL.CON-PATH: 
>> ??????????????????????/org/freedesktop/NetworkManager/ActiveConnection/3 
>>
>> WIRED-PROPERTIES.CARRIER: ??????????????on
>> IP4.ADDRESS[1]: 
>> ????????????????????????192.168.100.25/24
>> IP4.GATEWAY: 
>> ???????????????????????????192.168.100.254
>> IP4.ROUTE[1]: ??????????????????????????dst 
>> = 0.0.0.0/0, nh = 192.168.100.254, mt = 100
>> IP4.ROUTE[2]: ??????????????????????????dst 
>> = 192.168.100.0/24, nh = 0.0.0.0, mt = 100
>> IP4.ROUTE[3]: ??????????????????????????dst 
>> = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
>> IP4.DNS[1]: 
>> ????????????????????????????192.168.100.144
>> IP4.DNS[2]: 
>> ????????????????????????????192.168.100.254
> This is not an ACL problem, the whole subnet is allowed. Nmap and/or 
> telnet shows no blocked port problem
>
> Trying on the secondary leads to the same behaviour
>
> Eventually, I am lost.
>
Sorry for the disturbance, it was caused by faulty remnants of a VPN 
connection. I fixed that in /etc/systemd/resolved.conf

Cheers

-- 
Xavier Humbert
CRT Supervision et Exploitation de Niveau 1
Rectorat de Nancy-Metz
03 83 86 27 39

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210509/8808f43b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x90B78A89BCC49C10.asc
Type: application/pgp-keys
Size: 3154 bytes
Desc: OpenPGP public key
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210509/8808f43b/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210509/8808f43b/attachment-0003.bin>

From xavier.humbert at ac-nancy-metz.fr  Sun May  9 12:35:23 2021
From: xavier.humbert at ac-nancy-metz.fr (Xavier Humbert)
Date: Sun, 9 May 2021 14:35:23 +0200
Subject: [UNSOLVED] Re: Strange DNS behaviour
In-Reply-To: <51e3979a-c486-1128-0b76-7f127c6f2e19@ac-nancy-metz.fr>
References: <a5fc5899-844e-b97f-e8e0-76d657b142f0@ac-nancy-metz.fr>
 <51e3979a-c486-1128-0b76-7f127c6f2e19@ac-nancy-metz.fr>
Message-ID: <29106605-c389-9414-a61f-c79efa75c06b@ac-nancy-metz.fr>

On 09/05/2021 13:44, Xavier Humbert via bind-users wrote:
> On 09/05/2021 12:32, Xavier Humbert via bind-users wrote:
>>
>> Hi,
>>
>> My DNS system if perfectly working :
>>
>>> [xavier at numenor ~]$ dig dns.google.com
>>>
>>> ; <<>> DiG 9.16.15 <<>> dns.google.com
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12276
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 1232
>>> ; COOKIE: 7b606d7c32a99906010000006097b6d7f61894ea0a92dac2 (good)
>>> ;; QUESTION SECTION:
>>> ;dns.google.com.??????????????????????? 
>>> IN????? A
>>>
>>> ;; ANSWER SECTION:
>>> dns.google.com.???????? 880???? IN????? 
>>> A?????? 8.8.4.4
>>> dns.google.com.???????? 880???? IN????? 
>>> A?????? 8.8.8.8
>>>
>>> ;; Query time: 0 msec
>>> ;; SERVER: ::1#53(::1)
>>> ;; WHEN: Sun May 09 12:17:59 CEST 2021
>>> ;; MSG SIZE? rcvd: 103
>>
>> On other hosts in my home, it works, too.
>>
>> But on one machine, it fails :
>>
>>> [xavier at feanor ~]$ dig @numenor dns.google.com +trace
>>>
>>> ; <<>> DiG 9.16.8-Ubuntu <<>> @numenor dns.google.com +trace
>>> ; (1 server found)
>>> ;; global options: +cmd
>>> . ??????????????????????518400 ?IN 
>>> ?????NS ?????m.root-servers.net.
>>> . ??????????????????????518400 ?IN 
>>> ?????NS ?????b.root-servers.net.
>>> . ??????????????????????518400 ?IN 
>>> ?????NS ?????e.root-servers.net.
>>> . ??????????????????????518400 ?IN 
>>> ?????NS ?????d.root-servers.net.
>>> . ??????????????????????518400 ?IN 
>>> ?????NS ?????h.root-servers.net.
>>> . ??????????????????????518400 ?IN 
>>> ?????NS ?????f.root-servers.net.
>>> . ??????????????????????518400 ?IN 
>>> ?????NS ?????g.root-servers.net.
>>> . ??????????????????????518400 ?IN 
>>> ?????NS ?????c.root-servers.net.
>>> . ??????????????????????518400 ?IN 
>>> ?????NS ?????i.root-servers.net.
>>> . ??????????????????????518400 ?IN 
>>> ?????NS ?????j.root-servers.net.
>>> . ??????????????????????518400 ?IN 
>>> ?????NS ?????k.root-servers.net.
>>> . ??????????????????????518400 ?IN 
>>> ?????NS ?????l.root-servers.net.
>>> . ??????????????????????518400 ?IN 
>>> ?????NS ?????a.root-servers.net.
>>> . ??????????????????????518400 ?IN 
>>> ?????RRSIG ??NS 8 0 518400 20210521170000 20210508160000 
>>> 14631 . IgUiqHrRXT5hTAa5wnubyCL0T9iq+iRAQIUQlIStRYqZh6Qp5W3sZLum 
>>> 6O+EkYZALJda6RJwQY8oPEgQVQymGmGyAxcZBekX5vsMm8MgovQIA+Ev 
>>> SroSeV9yXDURHqt8af+25bw
>>> 6YyUQEOblPehxyUYYkF9cP8FlieAUw1Fn 
>>> HMvqpQlEn2sYS4UjA+euhcS2k7jnyEdBNbXbEZVq56zHK1aHPQIp2f4/ 
>>> byHaC55zPJ5rgLwMUh+8JuP47wb4NWAKIj76EUlqcidfI8hxZI5KPoNZ 
>>> vmIcEtQSfRYqVxoc+BiEEgalw5afAmXjEtvJaWm4v5383uatiQ1s9AgC MPQFHw==
>>> couldn't get address for 'm.root-servers.net': not found
>>
>> None of the root servers can't be found. My root hint file is up to date.
>>
>> The network configuration on this machine :
>>
>>> [xavier at feanor ~]$ nmcli device show enp10s0
>>> GENERAL.DEVICE: ????????????????????????enp10s0
>>> GENERAL.TYPE: 
>>> ??????????????????????????ethernet
>>> GENERAL.HWADDR: 
>>> ????????????????????????04:7D:7B:02:68:67
>>> GENERAL.MTU: ???????????????????????????1500
>>> GENERAL.STATE: ?????????????????????????100 
>>> (connected)
>>> GENERAL.CONNECTION: ????????????????????Wired
>>> GENERAL.CON-PATH: 
>>> ??????????????????????/org/freedesktop/NetworkManager/ActiveConnection/3 
>>>
>>> WIRED-PROPERTIES.CARRIER: ??????????????on
>>> IP4.ADDRESS[1]: 
>>> ????????????????????????192.168.100.25/24
>>> IP4.GATEWAY: 
>>> ???????????????????????????192.168.100.254
>>> IP4.ROUTE[1]: 
>>> ??????????????????????????dst = 0.0.0.0/0, 
>>> nh = 192.168.100.254, mt = 100
>>> IP4.ROUTE[2]: 
>>> ??????????????????????????dst = 
>>> 192.168.100.0/24, nh = 0.0.0.0, mt = 100
>>> IP4.ROUTE[3]: 
>>> ??????????????????????????dst = 
>>> 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
>>> IP4.DNS[1]: 
>>> ????????????????????????????192.168.100.144
>>> IP4.DNS[2]: 
>>> ????????????????????????????192.168.100.254
>> This is not an ACL problem, the whole subnet is allowed. Nmap and/or 
>> telnet shows no blocked port problem
>>
>> Trying on the secondary leads to the same behaviour
>>
>> Eventually, I am lost.
>>
Sorry, typed too quickly. Problem stands.

-- 
Xavier Humbert
CRT Supervision et Exploitation de Niveau 1
Rectorat de Nancy-Metz
03 83 86 27 39

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210509/b9f4b7ce/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x90B78A89BCC49C10.asc
Type: application/pgp-keys
Size: 3154 bytes
Desc: OpenPGP public key
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210509/b9f4b7ce/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210509/b9f4b7ce/attachment-0003.bin>

From uhlar at fantomas.sk  Sun May  9 14:37:58 2021
From: uhlar at fantomas.sk (Matus UHLAR - fantomas)
Date: Sun, 9 May 2021 16:37:58 +0200
Subject: [UNSOLVED] Re: Strange DNS behaviour
In-Reply-To: <29106605-c389-9414-a61f-c79efa75c06b@ac-nancy-metz.fr>
References: <a5fc5899-844e-b97f-e8e0-76d657b142f0@ac-nancy-metz.fr>
 <51e3979a-c486-1128-0b76-7f127c6f2e19@ac-nancy-metz.fr>
 <29106605-c389-9414-a61f-c79efa75c06b@ac-nancy-metz.fr>
Message-ID: <20210509143757.GA7847@fantomas.sk>

On 09.05.21 14:35, Xavier Humbert via bind-users wrote:
>>>But on one machine, it fails :
>>>
>>>>[xavier at feanor ~]$ dig @numenor dns.google.com +trace


are you aware that +trace sends queries across the servers from root to
leaf, it doesn't go through the server numenor?

>>>>couldn't get address for 'm.root-servers.net': not found
>>>
>>>None of the root servers can't be found. My root hint file is up to date.

>Sorry, typed too quickly. Problem stands.

-- 
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux is like a teepee: no Windows, no Gates and an apache inside...

From softwareinfojam at gmail.com  Mon May 10 01:48:38 2021
From: softwareinfojam at gmail.com (Peter Fraser)
Date: Sun, 9 May 2021 20:48:38 -0500
Subject: Update DNSSEC Zone
Message-ID: <FB381F46-C18C-4640-AF24-281B53D2F20D@gmail.com>

HI All,
I really would appreciate a pointer in the right direction. I took over a bind server recently. I am not new to bind. I have used it many times and honestly prefer it to windows dns but I have never worked with DNSSEC.  I have been reading all day and I still can?t figure out how to update the DNSSEC zone. Can anyone assist me please? I did see one site that said I could just put in regular A record entries and run rndc reload and that would resign the zone. I tried that but it didn?t work.
 
I am using bind-9.14.x and here are the DNSSEC related entries in the zone.
 
auto-dnssec maintain;
update-policy local;
key-directory ?zones/domain-keys?;
 
Best Regards,
SI
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210509/bd7fbd40/attachment.htm>

From john.blue at rrcic.com  Mon May 10 02:34:57 2021
From: john.blue at rrcic.com (John W. Blue)
Date: Mon, 10 May 2021 02:34:57 +0000
Subject: Update DNSSEC Zone
In-Reply-To: <FB381F46-C18C-4640-AF24-281B53D2F20D@gmail.com>
References: <FB381F46-C18C-4640-AF24-281B53D2F20D@gmail.com>
Message-ID: <4b9cd684d1fa4ca395c7806da90726ce@mail.rrcic.com>

Hi Peter ..

How do you know your DNSSEC is working to begin with?

Here is a URL that I prefer to use that will help answer that question:

https://dnsviz.net/

What you are looking for is your to zone to be ?secure?.

Since you are an experienced BIND admin .. any clues to be found in the logs?  grep for ?unsigned?.

One option that appears to be missing from your conf file is:

zone "supercoolzonehere.com" IN {
inline-signing yes;
};

Which would achieve the result that you described below wherein a record is added and ?rndc reload? is executed.

Good hunting.

John

From: bind-users [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Peter Fraser
Sent: Sunday, May 09, 2021 8:49 PM
To: bind-users at lists.isc.org
Subject: Update DNSSEC Zone

HI All,
I really would appreciate a pointer in the right direction. I took over a bind server recently. I am not new to bind. I have used it many times and honestly prefer it to windows dns but I have never worked with DNSSEC.  I have been reading all day and I still can?t figure out how to update the DNSSEC zone. Can anyone assist me please? I did see one site that said I could just put in regular A record entries and run rndc reload and that would resign the zone. I tried that but it didn?t work.

I am using bind-9.14.x and here are the DNSSEC related entries in the zone.

auto-dnssec maintain;
update-policy local;
key-directory ?zones/domain-keys?;

Best Regards,
SI

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210510/a3a787fb/attachment-0001.htm>

From dan at newideatest.site  Mon May 10 05:18:40 2021
From: dan at newideatest.site (Dan Egli)
Date: Sun, 9 May 2021 23:18:40 -0600
Subject: Inline signing fails dnsviz test.
Message-ID: <a14145f2-ed72-80e2-85b2-c490be43ba03@newideatest.site>

I tried to setup inline signing on my DNS server, and after reading the 
results from DNSVIZ, i'd say I was PARTIALLY successful, but there still 
seems to be a lot missing.

You can check the status on dnsviz yourself with the names 
eglifamily.name and newideatest.site. Both resulted in nearly identical 
responses, wtih a lot of warning and some errors. A few of those errors 
I could blame on my backup DNS provider. You get what you pay for and 
they are free. But not everything could be blamed on them.

I've attached a PNG of the output. Hopefully it comes through. 
Meanwhile, here's the zone statements from my named.conf:

view "standard" IN {
 ??????? zone "eglifamily.name" {
 ??????????????? type master;
 ??????????????? file "pri/eglifamily.zone";
 ??????????????? allow-query { any; };
 ??????????????? allow-transfer {
 ????????????????? 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;
 ??????????????? };
//????????????? also-notify { 1.2.3.4; }; // none for now
 ??????????????? allow-update { trusted; };
 ??????????????? key-directory "/var/bind/pri/keys";
 ??????????????? auto-dnssec maintain;
 ??????????????? inline-signing yes;
 ??????? };

 ??????? zone "newideatest.site" {
 ??????????????? type master;
 ??????????????? file "pri/newideatest.zone";
 ??????????????? allow-query { any; };
 ??????????????? allow-transfer {
 ????????????????? 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;
 ??????????????? };
//????????????? also-notify { 1.2.3.4; }; // none for now
 ??????????????? allow-update { trusted; };
 ??????????????? key-directory "/var/bind/pri/keys";
 ??????????????? auto-dnssec maintain;
 ??????????????? inline-signing yes;
 ??????? };

-- 

Dan Egli
 From my Test Server

-------------- next part --------------
A non-text attachment was scrubbed...
Name: newideatest.site-2021-05-10-05 11 22-UTC(1).png
Type: image/png
Size: 108257 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210509/40fa0af8/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x11B7451DF2015959.asc
Type: application/pgp-keys
Size: 3792 bytes
Desc: OpenPGP public key
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210509/40fa0af8/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210509/40fa0af8/attachment-0003.bin>

From  at lbutlr  Mon May 10 05:55:13 2021
From:  at lbutlr ( at lbutlr)
Date: Sun, 9 May 2021 23:55:13 -0600
Subject: where are the testing docs ?
In-Reply-To: <f3ceaf81-d084-9d97-5cc1-25b9d2ed72ae@blastwave.org>
References: <b42b34ac-fc4c-6286-d43c-0710c5f4960f@blastwave.org>
 <12DDE1B3-B32F-439C-AF53-356D2AFF6210@isc.org>
 <f3ceaf81-d084-9d97-5cc1-25b9d2ed72ae@blastwave.org>
Message-ID: <C37ABB87-347E-4C2F-9EED-79C4A7000C1C@kreme.com>

On 06 May 2021, at 09:57, Dennis Clarke via bind-users <bind-users at lists.isc.org> wrote:
> I do NOT trust a build result where I had to go hacking into all the
> Makefiles just to get it to build. You install without doing testing?

That's a very strange definition of "hacking". Setting makefile [preferences and options is not in and way "hacking".

-- 
I started playing Myst at 4:30 in the afternoon and looked up
	suddenly and realized it was February.


From ondrej at isc.org  Mon May 10 05:55:22 2021
From: ondrej at isc.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Mon, 10 May 2021 07:55:22 +0200
Subject: Inline signing fails dnsviz test.
In-Reply-To: <a14145f2-ed72-80e2-85b2-c490be43ba03@newideatest.site>
References: <a14145f2-ed72-80e2-85b2-c490be43ba03@newideatest.site>
Message-ID: <CB367A65-3213-4432-80CA-53C933D6FD39@isc.org>

I would recommend starting here: https://bind9.readthedocs.io/en/latest/dnssec-guide.html

--
Ond?ej Sur? ? ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 10. 5. 2021, at 7:19, Dan Egli <dan at newideatest.site> wrote:
> 
> ?I tried to setup inline signing on my DNS server, and after reading the results from DNSVIZ, i'd say I was PARTIALLY successful, but there still seems to be a lot missing.
> 
> You can check the status on dnsviz yourself with the names eglifamily.name and newideatest.site. Both resulted in nearly identical responses, wtih a lot of warning and some errors. A few of those errors I could blame on my backup DNS provider. You get what you pay for and they are free. But not everything could be blamed on them.
> 
> I've attached a PNG of the output. Hopefully it comes through. Meanwhile, here's the zone statements from my named.conf:
> 
> view "standard" IN {
>         zone "eglifamily.name" {
>                 type master;
>                 file "pri/eglifamily.zone";
>                 allow-query { any; };
>                 allow-transfer {
>                   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;
>                 };
> //              also-notify { 1.2.3.4; }; // none for now
>                 allow-update { trusted; };
>                 key-directory "/var/bind/pri/keys";
>                 auto-dnssec maintain;
>                 inline-signing yes;
>         };
> 
>         zone "newideatest.site" {
>                 type master;
>                 file "pri/newideatest.zone";
>                 allow-query { any; };
>                 allow-transfer {
>                   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;
>                 };
> //              also-notify { 1.2.3.4; }; // none for now
>                 allow-update { trusted; };
>                 key-directory "/var/bind/pri/keys";
>                 auto-dnssec maintain;
>                 inline-signing yes;
>         };
> 
> -- 
> 
> Dan Egli
> From my Test Server
> 
> <newideatest.site-2021-05-10-05 11 22-UTC(1).png>
> <OpenPGP_0x11B7451DF2015959.asc>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210510/3a71eefd/attachment.htm>

From richard at richardneal.com  Mon May 10 08:29:23 2021
From: richard at richardneal.com (Richard T.A. Neal)
Date: Mon, 10 May 2021 08:29:23 +0000
Subject: Deprecating BIND 9.18+ on Windows (or making it community
 improved and supported)
In-Reply-To: <LO2P123MB411058E22C5C112AF74EFFC3B35F9@LO2P123MB4110.GBRP123.PROD.OUTLOOK.COM>
References: <DB685A3B-2275-4721-8CC2-7AE640EF42B8@isc.org>
 <LO2P123MB411058E22C5C112AF74EFFC3B35F9@LO2P123MB4110.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <LO2P123MB4110188A83C071A0CA825F72B3549@LO2P123MB4110.GBRP123.PROD.OUTLOOK.COM>

I spent some time last week looking at options for running BIND under WSL on Windows Server. Unfortunately it doesn't presently look like a viable solution for the following reasons:

There are two versions of WSL: WSL1 and WSL2. Development has all but ceased on WSL1, but WSL1 is the only version that can be installed on Windows Server 2019.

Microsoft have not yet confirmed whether WSL2 will be available for Windows Server vNext (Windows Server 2022, or whatever they name it).

Even if WSL2 is made available for Windows Server 2022 it has some serious networking limitations: it uses NAT from the host, so your Linux instance gets a private 172.x.y.z style IP address, and that IP address is different every reboot. Proxy port forwarding must therefore be reconfigured on every reboot as well.

There has been mixed success getting WSL2 to work in bridged mode, but it is not supported by MS. I expect many/most Windows server admins would not want to run something in an unsupported configuration which may suddenly stop working following a Windows Update.

At this time I don't therefore believe that running BIND via WSL or WSL2 on Windows Server is a viable reliable solution.

Best,

Richard.

-----Original Message-----
From: Richard T.A. Neal 
Sent: 29 April 2021 6:41 pm
To: BIND Users <bind-users at lists.isc.org>
Subject: RE: Deprecating BIND 9.18+ on Windows (or making it community improved and supported)

<snip>
The WSL2 option is an interesting one and not something I'd ever considered.
</snip>

Richard.


From ondrej at isc.org  Mon May 10 09:11:26 2021
From: ondrej at isc.org (=?utf-8?B?T25kxZllaiBTdXLDvQ==?=)
Date: Mon, 10 May 2021 11:11:26 +0200
Subject: Deprecating BIND 9.18+ on Windows (or making it community
 improved and supported)
In-Reply-To: <LO2P123MB4110188A83C071A0CA825F72B3549@LO2P123MB4110.GBRP123.PROD.OUTLOOK.COM>
References: <DB685A3B-2275-4721-8CC2-7AE640EF42B8@isc.org>
 <LO2P123MB411058E22C5C112AF74EFFC3B35F9@LO2P123MB4110.GBRP123.PROD.OUTLOOK.COM>
 <LO2P123MB4110188A83C071A0CA825F72B3549@LO2P123MB4110.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <87DE2266-8F44-48BF-9DA1-3541CFCA6070@isc.org>

> On 10. 5. 2021, at 10:29, Richard T.A. Neal <richard at richardneal.com> wrote:
> 
> At this time I don't therefore believe that running BIND via WSL or WSL2 on Windows Server is a viable reliable solution.

Thanks for the analysis.

The alternative is as I outlined in the first email, somebody needs to step up
and start maintaining the BIND 9.18+ Windows version properly. FTR the
?somebody? doesn?t have to do it with their own hands.

Using mingw-w64 to compile BIND 9.18+ instead of using MSVC would be also
accepted as a contribution.

Ondrej
--
Ond?ej Sur? (He/Him)
ondrej at isc.org


From john.blue at rrcic.com  Mon May 10 09:29:28 2021
From: john.blue at rrcic.com (John W. Blue)
Date: Mon, 10 May 2021 09:29:28 +0000
Subject: Inline signing fails dnsviz test.
In-Reply-To: <a14145f2-ed72-80e2-85b2-c490be43ba03@newideatest.site>
References: <a14145f2-ed72-80e2-85b2-c490be43ba03@newideatest.site>
Message-ID: <629f4963-b50c-47db-b532-ba48da9566a6@rrcic.com>

Hello Dan.

Does your registrar have the ability via a UI to place a DS record in the .name zone?

And if so, have you done that already?

John

Sent from Nine<http://www.9folders.com/>
________________________________
From: Dan Egli <dan at newideatest.site>
Sent: Monday, May 10, 2021 12:20 AM
To: bind-users at lists.isc.org
Subject: Inline signing fails dnsviz test.

I tried to setup inline signing on my DNS server, and after reading the
results from DNSVIZ, i'd say I was PARTIALLY successful, but there still
seems to be a lot missing.

You can check the status on dnsviz yourself with the names
eglifamily.name and newideatest.site. Both resulted in nearly identical
responses, wtih a lot of warning and some errors. A few of those errors
I could blame on my backup DNS provider. You get what you pay for and
they are free. But not everything could be blamed on them.

I've attached a PNG of the output. Hopefully it comes through.
Meanwhile, here's the zone statements from my named.conf:

view "standard" IN {
         zone "eglifamily.name" {
                 type master;
                 file "pri/eglifamily.zone";
                 allow-query { any; };
                 allow-transfer {
                   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;
                 };
//              also-notify { 1.2.3.4; }; // none for now
                 allow-update { trusted; };
                 key-directory "/var/bind/pri/keys";
                 auto-dnssec maintain;
                 inline-signing yes;
         };

         zone "newideatest.site" {
                 type master;
                 file "pri/newideatest.zone";
                 allow-query { any; };
                 allow-transfer {
                   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;
                 };
//              also-notify { 1.2.3.4; }; // none for now
                 allow-update { trusted; };
                 key-directory "/var/bind/pri/keys";
                 auto-dnssec maintain;
                 inline-signing yes;
         };

--

Dan Egli
 From my Test Server

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210510/2b0a523f/attachment.htm>

From dot at dotat.at  Mon May 10 10:53:07 2021
From: dot at dotat.at (Tony Finch)
Date: Mon, 10 May 2021 11:53:07 +0100
Subject: Update DNSSEC Zone
In-Reply-To: <FB381F46-C18C-4640-AF24-281B53D2F20D@gmail.com>
References: <FB381F46-C18C-4640-AF24-281B53D2F20D@gmail.com>
Message-ID: <8cf22794-834-bf36-4eb6-dc129745c078@dotat.at>

Peter Fraser <softwareinfojam at gmail.com> wrote:
>
> I am using bind-9.14.x and here are the DNSSEC related entries in the zone.
>
> auto-dnssec maintain;
> update-policy local;
> key-directory ?zones/domain-keys?;

How you go about this depends on whether your configuration enables
`inline-signing` or not.

If it has inline-signing, you should see in the filesystem that each zone
file has .signed (and possibly .jnl) files alongside. You can update the
zone using

	(edit the non-.signed zone file)
	rndc reload

If it does not have inline-signing I prefer to use `nsupdate` to update
the zones, usually with my `nsdiff` or `nsvi` tools. Or you can,

	rndc freeze
	(edit the zone file)
	rndc thaw

https://dotat.at/prog/nsdiff/

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
Biscay: Southwest 3 to 5 increasing 5 to 7. Rough, occasionally
moderate in east, becoming very rough in west. Thundery showers. Good,
occasionally poor.

From dclarke at blastwave.org  Mon May 10 17:43:45 2021
From: dclarke at blastwave.org (Dennis Clarke)
Date: Mon, 10 May 2021 13:43:45 -0400
Subject: where are the testing docs ?
In-Reply-To: <C37ABB87-347E-4C2F-9EED-79C4A7000C1C@kreme.com>
References: <b42b34ac-fc4c-6286-d43c-0710c5f4960f@blastwave.org>
 <12DDE1B3-B32F-439C-AF53-356D2AFF6210@isc.org>
 <f3ceaf81-d084-9d97-5cc1-25b9d2ed72ae@blastwave.org>
 <C37ABB87-347E-4C2F-9EED-79C4A7000C1C@kreme.com>
Message-ID: <f2c68d1e-5bfd-253f-265b-76f56fa9c324@blastwave.org>

On 5/10/21 01:55, @lbutlr wrote:
> On 06 May 2021, at 09:57, Dennis Clarke via bind-users <bind-users at lists.isc.org> wrote:
>> I do NOT trust a build result where I had to go hacking into all the
>> Makefiles just to get it to build. You install without doing testing?
> 
> That's a very strange definition of "hacking". Setting makefile [preferences and options is not in and way "hacking".
> 

I realize you are being a jerk on purpose but regardless :

    1) 9.11.26 builds perfectly out of the box with no issues

    2) 9.11.27 fails to build with a bucket of undefined symbols

    3) 9.11.28 fails to build in the same manner

    4) 9.11.29 why waste my time looking here ?

    5) 9.11.30 does not even exist ... please play again

    6) 9.11.31 fails to build with a bucket of undefined symbols

    7) dig around madly into 9.11.26 to see if *something* has gone
       wonky thereafter ... rebuild it and watch everything "just work"

    8) change some compiler flags, look at the CPPFLAGS and begin
       digging into the Makefiles to see where things have gone bork

    9) find that the Makefile in bin/tools is in fact bork bork bork

   10) compare the Makefile in bin/tools with the results from 9.11.26

   11) find possible bork botk bork and begin to hack in some silly
       edits to get past the bin/tools portion of this mess

   12) that works and now other things break, so begin a pile of sed
       and grep and awk and such over ALL the Makefiles everywhere and
       determine that in fact yes they are all borked slightly

I call all of those four days of work a pile of hack. On an old legacy
platform that no one wants to keep running anymore, and it just keeps
running and running. I don't know what you call it. I just say that
releases after 9.11.26 are borked. However only slightly and in places
no one would look at anyways.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional



From dan at newideatest.site  Mon May 10 17:53:25 2021
From: dan at newideatest.site (Dan Egli)
Date: Mon, 10 May 2021 11:53:25 -0600
Subject: Inline signing fails dnsviz test.
In-Reply-To: <629f4963-b50c-47db-b532-ba48da9566a6@rrcic.com>
References: <a14145f2-ed72-80e2-85b2-c490be43ba03@newideatest.site>
 <629f4963-b50c-47db-b532-ba48da9566a6@rrcic.com>
Message-ID: <e00f633e-6bf7-6e3d-0e29-03067676a07a@newideatest.site>

They do, and I had forgotten that. But I don't know where to get the DS 
record I'd place. I tried querying bind, but all I got back was 
someone's SOA record:

; <<>> DiG 9.16.12 <<>> @localhost ds eglifamily.name
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62605
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 8761a3c0b39eccab010000006099729d88739143bbe8c230 (good)
;; QUESTION SECTION:
;eglifamily.name.?????????????? IN????? DS

;; AUTHORITY SECTION:
name.?????????????????? 10794?? IN????? SOA???? ac1.nstld.com. 
info.verisign-grs.com. 1620669036 1800 900 604800 86400

;; Query time: 10 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon May 10 11:51:25 MDT 2021
;; MSG SIZE? rcvd: 142

Where do I get the DS record, since i'm using bind's inline signing?

On 5/10/2021 3:29 AM, John W. Blue via bind-users wrote:
> Hello Dan.
>
> Does your registrar have the ability via a UI to place a DS record in 
> the .name zone?
>
> And if so, have you done that already?
>
> John
>
> Sent from Nine <http://www.9folders.com/>
> ------------------------------------------------------------------------
> *From:* Dan Egli <dan at newideatest.site>
> *Sent:* Monday, May 10, 2021 12:20 AM
> *To:* bind-users at lists.isc.org
> *Subject:* Inline signing fails dnsviz test.
>
> I tried to setup inline signing on my DNS server, and after reading the
> results from DNSVIZ, i'd say I was PARTIALLY successful, but there still
> seems to be a lot missing.
>
> You can check the status on dnsviz yourself with the names
> eglifamily.name and newideatest.site. Both resulted in nearly identical
> responses, wtih a lot of warning and some errors. A few of those errors
> I could blame on my backup DNS provider. You get what you pay for and
> they are free. But not everything could be blamed on them.
>
> I've attached a PNG of the output. Hopefully it comes through.
> Meanwhile, here's the zone statements from my named.conf:
>
> view "standard" IN {
> ???????? zone "eglifamily.name" {
> ???????????????? type master;
> ???????????????? file "pri/eglifamily.zone";
> ???????????????? allow-query { any; };
> ???????????????? allow-transfer {
> ?????????????????? 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;
> ???????????????? };
> //????????????? also-notify { 1.2.3.4; }; // none for now
> ???????????????? allow-update { trusted; };
> ???????????????? key-directory "/var/bind/pri/keys";
> ???????????????? auto-dnssec maintain;
> ???????????????? inline-signing yes;
> ???????? };
>
> ???????? zone "newideatest.site" {
> ???????????????? type master;
> ???????????????? file "pri/newideatest.zone";
> ???????????????? allow-query { any; };
> ???????????????? allow-transfer {
> ?????????????????? 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;
> ???????????????? };
> //????????????? also-notify { 1.2.3.4; }; // none for now
> ???????????????? allow-update { trusted; };
> ???????????????? key-directory "/var/bind/pri/keys";
> ???????????????? auto-dnssec maintain;
> ???????????????? inline-signing yes;
> ???????? };
>
> -- 
>
> Dan Egli
> ?From my Test Server
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Dan Egli
 From my Test Server

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210510/221c8848/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x11B7451DF2015959.asc
Type: application/pgp-keys
Size: 3792 bytes
Desc: OpenPGP public key
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210510/221c8848/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210510/221c8848/attachment-0003.bin>

From dot at dotat.at  Mon May 10 18:17:48 2021
From: dot at dotat.at (Tony Finch)
Date: Mon, 10 May 2021 19:17:48 +0100
Subject: Inline signing fails dnsviz test.
In-Reply-To: <e00f633e-6bf7-6e3d-0e29-03067676a07a@newideatest.site>
References: <a14145f2-ed72-80e2-85b2-c490be43ba03@newideatest.site>
 <629f4963-b50c-47db-b532-ba48da9566a6@rrcic.com>
 <e00f633e-6bf7-6e3d-0e29-03067676a07a@newideatest.site>
Message-ID: <9551b280-554d-4bcf-c932-e16540997af9@dotat.at>

Dan Egli <dan at newideatest.site> wrote:
>
> Where do I get the DS record, since i'm using bind's inline signing?

Use the dnssec-dsfromkey tool, e.g. from a key file (make sure it's the
KSK file)

	$ grep This Kcam.ac.uk.+013+32840.key
	; This is a key-signing key, keyid 32840, for cam.ac.uk.
	$ dnssec-dsfromkey -2 Kcam.ac.uk.+013+32840.key
	cam.ac.uk. IN DS 32840 13 2 2BDAF21907420CE792AF02B55071953BC2BDB64B5126710E12AF89F711322B85

or from your DNSKEY RRset (safest to run this on your primary to be sure
the keys aren't mangled)

	$ dig cam.ac.uk dnskey | dnssec-dsfromkey -2 -f - cam.ac.uk
	cam.ac.uk. IN DS 32840 13 2 2BDAF21907420CE792AF02B55071953BC2BDB64B5126710E12AF89F711322B85

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
Berwick upon Tweed to Whitby: South backing southeast, 3 to 5,
occasionally 6 at first. Slight or moderate becoming slight. Showers,
perhaps thundery later. Good occasionally moderate later.


From bind at iment.com  Mon May 10 18:18:26 2021
From: bind at iment.com (Paul Kosinski)
Date: Mon, 10 May 2021 14:18:26 -0400
Subject: where are the testing docs ?
In-Reply-To: <C37ABB87-347E-4C2F-9EED-79C4A7000C1C@kreme.com>
References: <b42b34ac-fc4c-6286-d43c-0710c5f4960f@blastwave.org>
 <12DDE1B3-B32F-439C-AF53-356D2AFF6210@isc.org>
 <f3ceaf81-d084-9d97-5cc1-25b9d2ed72ae@blastwave.org>
 <C37ABB87-347E-4C2F-9EED-79C4A7000C1C@kreme.com>
Message-ID: <20210510141826.7b32f153@ime1.iment.local>

Actually, it's in keeping with the *original* definition of hacking!


On Sun, 9 May 2021 23:55:13 -0600
@lbutlr <kremels at kreme.com> wrote:

> On 06 May 2021, at 09:57, Dennis Clarke via bind-users <bind-users at lists.isc.org> wrote:
> > I do NOT trust a build result where I had to go hacking into all the
> > Makefiles just to get it to build. You install without doing testing?  
> 
> That's a very strange definition of "hacking". Setting makefile [preferences and options is not in and way "hacking".
> 

From ondrej at isc.org  Mon May 10 18:22:27 2021
From: ondrej at isc.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Mon, 10 May 2021 20:22:27 +0200
Subject: where are the testing docs ?
In-Reply-To: <20210510141826.7b32f153@ime1.iment.local>
References: <20210510141826.7b32f153@ime1.iment.local>
Message-ID: <07190E53-9112-43E2-8CCB-88D2E64A9371@isc.org>

And I am saying all of this is a definition of off-topic, so please be nice to each other and stay on topic.

Dennis, we are going to accept a MR that would fix your case and not break anything else. You can either submit patch inline in the issue or you can ask and I can permit forking the project in ISC GitLab.

Ond?ej
--
Ond?ej Sur? ? ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 10. 5. 2021, at 20:19, Paul Kosinski via bind-users <bind-users at lists.isc.org> wrote:
> 
> ?Actually, it's in keeping with the *original* definition of hacking!
> 
> 
>> On Sun, 9 May 2021 23:55:13 -0600
>> @lbutlr <kremels at kreme.com> wrote:
>> 
>>> On 06 May 2021, at 09:57, Dennis Clarke via bind-users <bind-users at lists.isc.org> wrote:
>>> I do NOT trust a build result where I had to go hacking into all the
>>> Makefiles just to get it to build. You install without doing testing?  
>> 
>> That's a very strange definition of "hacking". Setting makefile [preferences and options is not in and way "hacking".
>> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


From dan at newideatest.site  Mon May 10 18:30:26 2021
From: dan at newideatest.site (Dan Egli)
Date: Mon, 10 May 2021 12:30:26 -0600
Subject: Inline signing fails dnsviz test.
In-Reply-To: <9551b280-554d-4bcf-c932-e16540997af9@dotat.at>
References: <a14145f2-ed72-80e2-85b2-c490be43ba03@newideatest.site>
 <629f4963-b50c-47db-b532-ba48da9566a6@rrcic.com>
 <e00f633e-6bf7-6e3d-0e29-03067676a07a@newideatest.site>
 <9551b280-554d-4bcf-c932-e16540997af9@dotat.at>
Message-ID: <30a70313-bc54-f536-a2a4-f067a68529a2@newideatest.site>

On 5/10/2021 12:17 PM, Tony Finch wrote:
> Dan Egli <dan at newideatest.site> wrote:
>> Where do I get the DS record, since i'm using bind's inline signing?
> Use the dnssec-dsfromkey tool, e.g. from a key file (make sure it's the
> KSK file)
>
> 	$ grep This Kcam.ac.uk.+013+32840.key
> 	; This is a key-signing key, keyid 32840, for cam.ac.uk.
> 	$ dnssec-dsfromkey -2 Kcam.ac.uk.+013+32840.key
> 	cam.ac.uk. IN DS 32840 13 2 2BDAF21907420CE792AF02B55071953BC2BDB64B5126710E12AF89F711322B85
>
> or from your DNSKEY RRset (safest to run this on your primary to be sure
> the keys aren't mangled)
>
> 	$ dig cam.ac.uk dnskey | dnssec-dsfromkey -2 -f - cam.ac.uk
> 	cam.ac.uk. IN DS 32840 13 2 2BDAF21907420CE792AF02B55071953BC2BDB64B5126710E12AF89F711322B85
>
> Tony.

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? The walkthrough I was looking at 
didn't seem to indicate that.

 ?dig @localhost newideatest.site dnskey

; <<>> DiG 9.16.12 <<>> @localhost newideatest.site dnskey
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38832
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: f9328808600478370100000060997aea2f4ce09bf11a954c (good)
;; QUESTION SECTION:
;newideatest.site.????????????? IN????? DNSKEY

;; AUTHORITY SECTION:
newideatest.site.?????? 120???? IN????? SOA???? newideatest.site. 
dan.newideatest.site. 5 120 240 604800 86400

;; Query time: 10 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon May 10 12:26:50 MDT 2021
;; MSG SIZE? rcvd: 113

So, of course dnssec-dsfromkey does't work:

 ?dig @localhost newideatest.site dnskey | dnssec-dsfromkey -2 -f - 
newideatest.site
dnssec-dsfromkey: fatal: no DNSKEY RR for newideatest.site in input


-- 
Dan Egli
 From my Test Server

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x11B7451DF2015959.asc
Type: application/pgp-keys
Size: 3792 bytes
Desc: OpenPGP public key
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210510/15b04225/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210510/15b04225/attachment-0001.bin>

From dot at dotat.at  Mon May 10 18:38:25 2021
From: dot at dotat.at (Tony Finch)
Date: Mon, 10 May 2021 19:38:25 +0100
Subject: Inline signing fails dnsviz test.
In-Reply-To: <30a70313-bc54-f536-a2a4-f067a68529a2@newideatest.site>
References: <a14145f2-ed72-80e2-85b2-c490be43ba03@newideatest.site>
 <629f4963-b50c-47db-b532-ba48da9566a6@rrcic.com>
 <e00f633e-6bf7-6e3d-0e29-03067676a07a@newideatest.site>
 <9551b280-554d-4bcf-c932-e16540997af9@dotat.at>
 <30a70313-bc54-f536-a2a4-f067a68529a2@newideatest.site>
Message-ID: <256441c6-1c81-3b4e-a019-4a50e165dfde@dotat.at>

Dan Egli <dan at newideatest.site> wrote:
>
> 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?

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.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
Lundy, Fastnet: Southwest 5 to 7, backing southeast 4 to 6 for a time.
Moderate or rough, occasionally very rough in southwest Fastnet.
Thundery rain. Good, occasionally poor.


From dan at newideatest.site  Mon May 10 21:36:55 2021
From: dan at newideatest.site (Dan Egli)
Date: Mon, 10 May 2021 15:36:55 -0600
Subject: Inline signing fails dnsviz test.
In-Reply-To: <256441c6-1c81-3b4e-a019-4a50e165dfde@dotat.at>
References: <a14145f2-ed72-80e2-85b2-c490be43ba03@newideatest.site>
 <629f4963-b50c-47db-b532-ba48da9566a6@rrcic.com>
 <e00f633e-6bf7-6e3d-0e29-03067676a07a@newideatest.site>
 <9551b280-554d-4bcf-c932-e16540997af9@dotat.at>
 <30a70313-bc54-f536-a2a4-f067a68529a2@newideatest.site>
 <256441c6-1c81-3b4e-a019-4a50e165dfde@dotat.at>
Message-ID: <feb096b4-711e-1b16-664e-0de6c8782d2a@newideatest.site>

Okay, so I added the policy, and things MOSTLY look okay. But when I 
retake the verification test, I get errors about no RRSIGs found. What 
do I do to resolve that issue?

On 5/10/2021 12:38 PM, Tony Finch wrote:
> Dan Egli <dan at newideatest.site> wrote:
>> 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?
> 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.

-- 
Dan Egli
 From my Test Server

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x11B7451DF2015959.asc
Type: application/pgp-keys
Size: 3792 bytes
Desc: OpenPGP public key
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210510/3a6dbc87/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210510/3a6dbc87/attachment-0003.bin>

From John.Stoffel at toshiba.com  Tue May 11 20:24:02 2021
From: John.Stoffel at toshiba.com (Stoffel, John (TAI))
Date: Tue, 11 May 2021 20:24:02 +0000
Subject: ISC Bind as secondary to Windows Server: bad bitmap error on named
 xfer.
Message-ID: <SJ0PR05MB75959B3BB4025C6AB07C270693539@SJ0PR05MB7595.namprd05.prod.outlook.com>

Hi,
I'm setting up an ISC Bind 9.11.20-RedHat-9.11.20-5  on a CentOS 8.3.2011 server and I'm running into a problem transferring a domain from our primary to this new secondary.  The primary is a Windows Server 2012R2 system.  I have 300+ domains setup and most of them are working just fine, and I can see the data for them in /var/named/secondary/<zone> files.

But my main domain isn't transferring, I keep getting the following:

May 11 20:06:42 foo-dns-p03 named[71418]: zone foo.com/IN: Transfer started.
May 11 20:06:42 foo-dns-p03 named[71418]: transfer of 'foo.com/IN' from xxx.xxx.xxx.xxx#53: connected using yyy.yyy.yyy.yyy#39861
May 11 20:06:43 foo-dns-p03 named[71418]: transfer of 'foo.com/IN' from xxx.xxx.xxx.xxx#53: failed while receiving responses: bad bitmap
May 11 20:06:43 foo-dns-p03 named[71418]: transfer of 'foo.com/IN' from xxx.xxx.xxx.xxx#53: Transfer status: bad bitmap
May 11 20:06:43 foo-dns-p03 named[71418]: transfer of 'foo.com/IN' from xxx.xxx.xxx.xxx#53: Transfer completed: 19 messages, 2518 records, 309684 bytes, 0.355 secs (872349 bytes/sec)

Which really implies to me that we have some issues on the source Windows DNS server, but it's not easy to find.  Is there anyway I can relax named to access this domain transfer, even with a bad bitmap?   Or is there a good way to bump up the logging so I can find out which record(s) are causing the problem so I can maybe fix them on the source?

None of my googling has given me any hints on what this error could be.    My config looks like this:

options {
  listen-on port 53 { any; };
  listen-on-v6 port 53 { ::1; };
  directory   "/var/named";
  dump-file   "/var/named/data/cache_dump.db";
  statistics-file "/var/named/data/named_stats.txt";
  memstatistics-file "/var/named/data/named_mem_stats.txt";
  allow-query     { any; };

  recursion no;

  rrset-order { order random; };

  dnssec-enable False;
  dnssec-validation False;

  /* Path to ISC DLV key */
  bindkeys-file "/etc/named.iscdlv.key";

  managed-keys-directory "/var/named/dynamic";

  pid-file "/run/named/named.pid";
  session-keyfile "/run/named/session.key";
};


logging {
  channel default_debug {
    file "data/named.run";
    severity dynamic;
    print-time yes;
  };
};

zone "foo.com" IN {
   type slave;
   masters { xxx.xxx.xxx.xxx; } ;
};

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210511/58f0aa04/attachment.htm>

From mayer at pdmconsulting.net  Tue May 11 20:43:37 2021
From: mayer at pdmconsulting.net (Danny Mayer)
Date: Tue, 11 May 2021 16:43:37 -0400
Subject: Deprecating BIND 9.18+ on Windows (or making it community
 improved and supported)
In-Reply-To: <87DE2266-8F44-48BF-9DA1-3541CFCA6070@isc.org>
References: <DB685A3B-2275-4721-8CC2-7AE640EF42B8@isc.org>
 <LO2P123MB411058E22C5C112AF74EFFC3B35F9@LO2P123MB4110.GBRP123.PROD.OUTLOOK.COM>
 <LO2P123MB4110188A83C071A0CA825F72B3549@LO2P123MB4110.GBRP123.PROD.OUTLOOK.COM>
 <87DE2266-8F44-48BF-9DA1-3541CFCA6070@isc.org>
Message-ID: <1f4de6b9-5e6f-61a4-7d99-1a44124f41cc@pdmconsulting.net>


On 5/10/21 5:11 AM, Ond?ej Sur? wrote:
>> On 10. 5. 2021, at 10:29, Richard T.A. Neal <richard at richardneal.com> wrote:
>>
>> At this time I don't therefore believe that running BIND via WSL or WSL2 on Windows Server is a viable reliable solution.
> Thanks for the analysis.
>
> The alternative is as I outlined in the first email, somebody needs to step up
> and start maintaining the BIND 9.18+ Windows version properly. FTR the
> ?somebody? doesn?t have to do it with their own hands.
>
> Using mingw-w64 to compile BIND 9.18+ instead of using MSVC would be also
> accepted as a contribution.
>
As original developer of the Windows implementation I'd be happy to help 
out and take this on. However, I would not be able to do this without 
funding. If people want me to pursue this please let me know.

Danny


From dot at dotat.at  Tue May 11 21:23:41 2021
From: dot at dotat.at (Tony Finch)
Date: Tue, 11 May 2021 22:23:41 +0100
Subject: ISC Bind as secondary to Windows Server: bad bitmap error on
 named xfer.
In-Reply-To: <SJ0PR05MB75959B3BB4025C6AB07C270693539@SJ0PR05MB7595.namprd05.prod.outlook.com>
References: <SJ0PR05MB75959B3BB4025C6AB07C270693539@SJ0PR05MB7595.namprd05.prod.outlook.com>
Message-ID: <f3520d6-a36c-9429-ba60-91b3fbab67c5@dotat.at>

Stoffel, John (TAI) <John.Stoffel at toshiba.com> wrote:

> failed while receiving responses: bad bitmap
>
> None of my googling has given me any hints on what this error could be.

I had to look at the source, which told me it's to do with NXT records
which are super obsolete, so I wonder what weird stuff is in the zone that
might cause this.

(The NXT record was a predecessor of NSEC; NXT was badly designed so it is
unable to support all possible DNS RR types, which is why it needed
replacing.)

$ rg 'bad bitmap'
lib/dns/result.c:137:	"bad bitmap",	     /*%< 94 DNS_R_BADBITMAP */
$ rg BADBITMAP
lib/dns/include/dns/result.h:132:#define DNS_R_BADBITMAP		(ISC_RESULTCLASS_DNS + 94)
lib/dns/rdata/generic/nxt_30.c:154:		return (DNS_R_BADBITMAP);
lib/dns/result.c:137:	"bad bitmap",	     /*%< 94 DNS_R_BADBITMAP */
lib/dns/result.c:278:	"DNS_R_BADBITMAP",

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
Viking, North Utsire, South Utsire: Southerly or southeasterly 3 to 5
becoming variable 2 to 4, then northerly 5 to 7 later in Viking and
northern North Utsire. Moderate or rough in Viking and northern North
Utsire, slight or moderate elsewhere. Showers, fog patches. Moderate
or good, occasionally very poor.


From John.Stoffel at toshiba.com  Tue May 11 22:02:46 2021
From: John.Stoffel at toshiba.com (Stoffel, John (TAI))
Date: Tue, 11 May 2021 22:02:46 +0000
Subject: ISC Bind as secondary to Windows Server: bad bitmap error on
 named xfer.
In-Reply-To: <f3520d6-a36c-9429-ba60-91b3fbab67c5@dotat.at>
References: <SJ0PR05MB75959B3BB4025C6AB07C270693539@SJ0PR05MB7595.namprd05.prod.outlook.com>
 <f3520d6-a36c-9429-ba60-91b3fbab67c5@dotat.at>
Message-ID: <SJ0PR05MB759544226D8400B5421E191B93539@SJ0PR05MB7595.namprd05.prod.outlook.com>

Tony,
Thank you for your help.  I was going *insane* trying to figure out where this was coming from, and I had literally just pulled down the source to look at the code.  So now it looks like I need to find and kill any and all  NXT records in my domain.  Sigh...  So it's part of the DNSSEC setup, and it's not clear how to do an 'fsck' like scan on a Windows DNS server to look for problems like this.  

But trawling through my DNS tool on windows (which sucks... btw) I don't see any NXT records, though I see a ton of NSEC3 records.  Does anyone have a clue how I can try to find these bad record(s)?  I can do the following on my Linux secondary:

   dig AXFR foo.com @xxx.xxx.xxx.xxx > /tmp/foo.com

And it does dump some errors too, which hopefully will give me an idea of where my crappy bad record is located, and no use hiding crap:

www.cisco.toshiba.com.  3600    IN      CNAME   redirect.toshiba.com.
www.cisco.toshiba.com.  3600    IN      RRSIG   CNAME 8 4 3600 20210517093721 20210507083721 38628 t
oshiba.com. OEmGkGWSPtbjlCGVt5Ejkgncg2wRcbnfCMSm2By6Fl4gN8R1uXx/ucdN hVrdiiP8BHWTIte/fvoMrMXbMHxarPJ
C6zJn9HHdC9o2dwBoGpknTwJM DYsy8wA5byhT9f8RVLi0WxLDmncWl2vJcZM6wsKfJ5HWAklGh9YxhOar nCM=
;; Got bad packet: bad bitmap
16358 bytes
46 98 80 00 00 01 00 97 00 00 00 00 07 74 6f 73          F............tos
68 69 62 61 03 63 6f 6d 00 00 fc 00 01 08 63 69          hiba.com......ci
74 69 62 61 6e 6b c0 0c 00 05 00 01 00 00 0e 10          tibank..........
00 0b 08 72 65 64 69 72 65 63 74 c0 0c c0 1d 00          ...redirect.....
2e 00 01 00 00 0e 10 00 9f 00 05 08 03 00 00 0e          ................
10 60 a2 39 51 60 94 fc 41 96 e4 07 74 6f 73 68          .`.9Q`..A...tosh
69 62 61 03 63 6f 6d 00 83 b6 df 32 9f d9 2a 54          iba.com....2..*T
65 16 1b 28 09 ac aa b3 41 f0 85 60 e6 e2 18 ae          e..(....A..`....

-----Original Message-----
From: Tony Finch <fanf2 at hermes.cam.ac.uk> On Behalf Of Tony Finch
Sent: Tuesday, May 11, 2021 5:24 PM
To: Stoffel, John (TAI) <John.Stoffel at toshiba.com>
Cc: bind-users at lists.isc.org
Subject: Re: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.

Stoffel, John (TAI) <John.Stoffel at toshiba.com> wrote:

> failed while receiving responses: bad bitmap
>
> None of my googling has given me any hints on what this error could be.

I had to look at the source, which told me it's to do with NXT records which are super obsolete, so I wonder what weird stuff is in the zone that might cause this.

(The NXT record was a predecessor of NSEC; NXT was badly designed so it is unable to support all possible DNS RR types, which is why it needed
replacing.)

$ rg 'bad bitmap'
lib/dns/result.c:137:	"bad bitmap",	     /*%< 94 DNS_R_BADBITMAP */
$ rg BADBITMAP
lib/dns/include/dns/result.h:132:#define DNS_R_BADBITMAP		(ISC_RESULTCLASS_DNS + 94)
lib/dns/rdata/generic/nxt_30.c:154:		return (DNS_R_BADBITMAP);
lib/dns/result.c:137:	"bad bitmap",	     /*%< 94 DNS_R_BADBITMAP */
lib/dns/result.c:278:	"DNS_R_BADBITMAP",

Tony.
--
f.anthony.n.finch  <dot at dotat.at>  https://urldefense.com/v3/__https://dotat.at/__;!!BiNunAf9XXY-!VH-JqRCMfVb-2Su9Du-D3OA4DlJi6q3lXIg4s9pjD9fwN1atleDmzsKASzloojK1C1WS$
Viking, North Utsire, South Utsire: Southerly or southeasterly 3 to 5 becoming variable 2 to 4, then northerly 5 to 7 later in Viking and northern North Utsire. Moderate or rough in Viking and northern North Utsire, slight or moderate elsewhere. Showers, fog patches. Moderate or good, occasionally very poor.


From dot at dotat.at  Tue May 11 23:13:01 2021
From: dot at dotat.at (Tony Finch)
Date: Wed, 12 May 2021 00:13:01 +0100
Subject: ISC Bind as secondary to Windows Server: bad bitmap error on
 named xfer.
In-Reply-To: <SJ0PR05MB759544226D8400B5421E191B93539@SJ0PR05MB7595.namprd05.prod.outlook.com>
References: <SJ0PR05MB75959B3BB4025C6AB07C270693539@SJ0PR05MB7595.namprd05.prod.outlook.com>
 <f3520d6-a36c-9429-ba60-91b3fbab67c5@dotat.at>
 <SJ0PR05MB759544226D8400B5421E191B93539@SJ0PR05MB7595.namprd05.prod.outlook.com>
Message-ID: <783f3dec-3d71-835b-a3a4-e4aeab766bc9@dotat.at>

Stoffel, John (TAI) <John.Stoffel at toshiba.com> wrote:
>
> And it does dump some errors too, which hopefully will give me an idea
> of where my crappy bad record is located, and no use hiding crap:

yuck, this looks like no fun...

> www.cisco.toshiba.com.  3600    IN      CNAME   redirect.toshiba.com.
> www.cisco.toshiba.com.  3600    IN      RRSIG   CNAME 8 4 3600 20210517093721 20210507083721 38628 t
> oshiba.com. OEmGkGWSPtbjlCGVt5Ejkgncg2wRcbnfCMSm2By6Fl4gN8R1uXx/ucdN hVrdiiP8BHWTIte/fvoMrMXbMHxarPJ
> C6zJn9HHdC9o2dwBoGpknTwJM DYsy8wA5byhT9f8RVLi0WxLDmncWl2vJcZM6wsKfJ5HWAklGh9YxhOar nCM=
> ;; Got bad packet: bad bitmap
> 16358 bytes

does it print more hexdump? who knows where the problem might be in 16KB
of wire-format DNS...

I would try another DNS AXFR client that might not give up so easily, e.g.
if you have a handy copy of perl and Net::DNS, put your Windows DNS server
IP address into this one-liner instead of 127.0.0.1

perl -MNet::DNS -wE 'my $r = Net::DNS::Resolver->new(); $r->nameservers("127.0.0.1"); for my $rr ($r->axfr("toshiba.com")) { $rr->print }'

The bit of the hexdump you pasted shows another similar CNAME and its
RRSIG, so it isn't very enlightening.

> 46 98 80 00 00 01 00 97 00 00 00 00 07 74 6f 73          F............tos
  header....        RR counts         qname = zone name
> 68 69 62 61 03 63 6f 6d 00 00 fc 00 01 08 63 69          hiba.com......ci
                              00fc = axfr
> 74 69 62 61 6e 6b c0 0c 00 05 00 01 00 00 0e 10          tibank..........
backpointer to zone = c00c 0005 = cname

citibank looks like it follows cisco alphabetically which suggests the
zone transfer might be in canonical order, which could perhaps make it
easier to find the stray NXT / TYPE30 record(s)

> 00 0b 08 72 65 64 69 72 65 63 74 c0 0c c0 1d 00          ...redirect.....
           cname target                  c01d = backpointer to citibank
> 2e 00 01 00 00 0e 10 00 9f 00 05 08 03 00 00 0e          ................
  2e = rrsig   type covered = 0005 (cname)
> 10 60 a2 39 51 60 94 fc 41 96 e4 07 74 6f 73 68          .`.9Q`..A...tosh
> 69 62 61 03 63 6f 6d 00 83 b6 df 32 9f d9 2a 54          iba.com....2..*T
> 65 16 1b 28 09 ac aa b3 41 f0 85 60 e6 e2 18 ae          e..(....A..`....

etc.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
Fisher, German Bight: Variable, becoming mainly west, 2 to 4. Slight
or moderate in Fisher, smooth or slight in German Bight. Showers, fog
patches. Moderate, occasionally very poor.


From John.Stoffel at toshiba.com  Wed May 12 01:33:27 2021
From: John.Stoffel at toshiba.com (Stoffel, John (TAI))
Date: Wed, 12 May 2021 01:33:27 +0000
Subject: ISC Bind as secondary to Windows Server: bad bitmap error on
 named xfer.
In-Reply-To: <f3520d6-a36c-9429-ba60-91b3fbab67c5@dotat.at>
References: <SJ0PR05MB75959B3BB4025C6AB07C270693539@SJ0PR05MB7595.namprd05.prod.outlook.com>
 <f3520d6-a36c-9429-ba60-91b3fbab67c5@dotat.at>
Message-ID: <SJ0PR05MB7595356C66C8830C7D78EA5193529@SJ0PR05MB7595.namprd05.prod.outlook.com>

Tony,
Thank you so much for your help!  Your suggestion to use Net::DNS really saved the day, because then I could do a brute force binary search to find the broken DNS record which was screwing me up.  Once I deleted that record, all was well in the world, and my AXFR transfers happened just fine.  

I owe you a beer or two.  Where in the UK are you located?  My mom was from Hudderfield (Go Terriers!!!!) Looks like you're in Cambridge for your email, I think I've got a contact there I could get to draw you a few pints maybe.  

Thanks again,
Cheers,
John



Sr. Storage Architect
TOSHIBA AMERICA, INC.
290 Donald Lynch Blvd - Suite 201
Marlborough, MA 01752
508-736-5499 (mobile)
E-Mail:? john.stoffel at toshiba.com
Website: Service Now Self Service Portal


-----Original Message-----
From: Tony Finch <fanf2 at hermes.cam.ac.uk> On Behalf Of Tony Finch
Sent: Tuesday, May 11, 2021 5:24 PM
To: Stoffel, John (TAI) <John.Stoffel at toshiba.com>
Cc: bind-users at lists.isc.org
Subject: Re: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.

Stoffel, John (TAI) <John.Stoffel at toshiba.com> wrote:

> failed while receiving responses: bad bitmap
>
> None of my googling has given me any hints on what this error could be.

I had to look at the source, which told me it's to do with NXT records which are super obsolete, so I wonder what weird stuff is in the zone that might cause this.

(The NXT record was a predecessor of NSEC; NXT was badly designed so it is unable to support all possible DNS RR types, which is why it needed
replacing.)

$ rg 'bad bitmap'
lib/dns/result.c:137:	"bad bitmap",	     /*%< 94 DNS_R_BADBITMAP */
$ rg BADBITMAP
lib/dns/include/dns/result.h:132:#define DNS_R_BADBITMAP		(ISC_RESULTCLASS_DNS + 94)
lib/dns/rdata/generic/nxt_30.c:154:		return (DNS_R_BADBITMAP);
lib/dns/result.c:137:	"bad bitmap",	     /*%< 94 DNS_R_BADBITMAP */
lib/dns/result.c:278:	"DNS_R_BADBITMAP",

Tony.
--
f.anthony.n.finch  <dot at dotat.at>  https://urldefense.com/v3/__https://dotat.at/__;!!BiNunAf9XXY-!VH-JqRCMfVb-2Su9Du-D3OA4DlJi6q3lXIg4s9pjD9fwN1atleDmzsKASzloojK1C1WS$
Viking, North Utsire, South Utsire: Southerly or southeasterly 3 to 5 becoming variable 2 to 4, then northerly 5 to 7 later in Viking and northern North Utsire. Moderate or rough in Viking and northern North Utsire, slight or moderate elsewhere. Showers, fog patches. Moderate or good, occasionally very poor.


From John.Stoffel at toshiba.com  Wed May 12 12:17:07 2021
From: John.Stoffel at toshiba.com (Stoffel, John (TAI))
Date: Wed, 12 May 2021 12:17:07 +0000
Subject: ISC Bind as secondary to Windows Server: bad bitmap error on
 named xfer.
In-Reply-To: <783f3dec-3d71-835b-a3a4-e4aeab766bc9@dotat.at>
References: <SJ0PR05MB75959B3BB4025C6AB07C270693539@SJ0PR05MB7595.namprd05.prod.outlook.com>
 <f3520d6-a36c-9429-ba60-91b3fbab67c5@dotat.at>
 <SJ0PR05MB759544226D8400B5421E191B93539@SJ0PR05MB7595.namprd05.prod.outlook.com>
 <783f3dec-3d71-835b-a3a4-e4aeab766bc9@dotat.at>
Message-ID: <SJ0PR05MB759501AD8A67B7DD3CAFFC1C93529@SJ0PR05MB7595.namprd05.prod.outlook.com>

Tony,
A big thanks to you for your suggestion on using the Perl Net::DNS module, using that, I was then able to run named-checkzone on the dumped file (35,000+ lines!) to find the one bad record which was making things crap out.  I'm back a bit on bind versions, but not that far back, so I would have expected bind to just ignore that bogus record instead of crapping out.  

Unfortunately, I don't think I saved a copy of the bad record so I could file a bug report, too busy trying to make things work.  

Cheers,
John


Sr. Storage Architect
TOSHIBA AMERICA, INC.
290 Donald Lynch Blvd - Suite 201
Marlborough, MA 01752
508-736-5499 (mobile)
E-Mail:? john.stoffel at toshiba.com
Website: Service Now Self Service Portal


-----Original Message-----
From: Tony Finch <fanf2 at hermes.cam.ac.uk> On Behalf Of Tony Finch
Sent: Tuesday, May 11, 2021 7:13 PM
To: Stoffel, John (TAI) <John.Stoffel at toshiba.com>
Cc: bind-users at lists.isc.org
Subject: RE: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.

Stoffel, John (TAI) <John.Stoffel at toshiba.com> wrote:
>
> And it does dump some errors too, which hopefully will give me an idea 
> of where my crappy bad record is located, and no use hiding crap:

yuck, this looks like no fun...

> http://www.cisco.toshiba.com.  3600    IN      CNAME   redirect.toshiba.com.
> http://www.cisco.toshiba.com.  3600    IN      RRSIG   CNAME 8 4 3600 20210517093721 20210507083721 38628 t
> oshiba.com. OEmGkGWSPtbjlCGVt5Ejkgncg2wRcbnfCMSm2By6Fl4gN8R1uXx/ucdN 
> hVrdiiP8BHWTIte/fvoMrMXbMHxarPJ C6zJn9HHdC9o2dwBoGpknTwJM 
> DYsy8wA5byhT9f8RVLi0WxLDmncWl2vJcZM6wsKfJ5HWAklGh9YxhOar nCM= ;; Got 
> bad packet: bad bitmap
> 16358 bytes

does it print more hexdump? who knows where the problem might be in 16KB of wire-format DNS...

I would try another DNS AXFR client that might not give up so easily, e.g.
if you have a handy copy of perl and Net::DNS, put your Windows DNS server IP address into this one-liner instead of 127.0.0.1

perl -MNet::DNS -wE 'my $r = Net::DNS::Resolver->new(); $r->nameservers("127.0.0.1"); for my $rr ($r->axfr("toshiba.com")) { $rr->print }'

The bit of the hexdump you pasted shows another similar CNAME and its RRSIG, so it isn't very enlightening.

> 46 98 80 00 00 01 00 97 00 00 00 00 07 74 6f 73          F............tos
  header....        RR counts         qname = zone name
> 68 69 62 61 03 63 6f 6d 00 00 fc 00 01 08 63 69          hiba.com......ci
                              00fc = axfr
> 74 69 62 61 6e 6b c0 0c 00 05 00 01 00 00 0e 10          tibank..........
backpointer to zone = c00c 0005 = cname

citibank looks like it follows cisco alphabetically which suggests the zone transfer might be in canonical order, which could perhaps make it easier to find the stray NXT / TYPE30 record(s)

> 00 0b 08 72 65 64 69 72 65 63 74 c0 0c c0 1d 00          ...redirect.....
           cname target                  c01d = backpointer to citibank
> 2e 00 01 00 00 0e 10 00 9f 00 05 08 03 00 00 0e          ................
  2e = rrsig   type covered = 0005 (cname)
> 10 60 a2 39 51 60 94 fc 41 96 e4 07 74 6f 73 68          .`.9Q`..A...tosh
> 69 62 61 03 63 6f 6d 00 83 b6 df 32 9f d9 2a 54          iba.com....2..*T
> 65 16 1b 28 09 ac aa b3 41 f0 85 60 e6 e2 18 ae          e..(....A..`....

etc.

Tony.
--
f.anthony.n.finch  <dot at dotat.at>  https://urldefense.com/v3/__https://dotat.at/__;!!BiNunAf9XXY-!TxYeCrRieZyIcOGlb6sXZGm2RAMoSAa_FQxkoFEaSb2XkNsrzZa1Jjd7CvB-n6i-tTNB$
Fisher, German Bight: Variable, becoming mainly west, 2 to 4. Slight or moderate in Fisher, smooth or slight in German Bight. Showers, fog patches. Moderate, occasionally very poor.


From marka at isc.org  Wed May 12 12:40:00 2021
From: marka at isc.org (Mark Andrews)
Date: Wed, 12 May 2021 22:40:00 +1000
Subject: ISC Bind as secondary to Windows Server: bad bitmap error on
 named xfer.
In-Reply-To: <SJ0PR05MB759501AD8A67B7DD3CAFFC1C93529@SJ0PR05MB7595.namprd05.prod.outlook.com>
References: <SJ0PR05MB759501AD8A67B7DD3CAFFC1C93529@SJ0PR05MB7595.namprd05.prod.outlook.com>
Message-ID: <71000BEC-FC6F-49A9-87B5-C5AB6384B213@isc.org>

There is enough information to reproduce. Dig does have +besteffort but it doesn?t recover from this. 

You don?t want default handling to accept broken records so just skipping isn?t good behavior.  It should be possible to extend +besteffort to print bad records in unknown format. 

-- 
Mark Andrews

> On 12 May 2021, at 22:17, Stoffel, John (TAI) <John.Stoffel at toshiba.com> wrote:
> 
> ?Tony,
> A big thanks to you for your suggestion on using the Perl Net::DNS module, using that, I was then able to run named-checkzone on the dumped file (35,000+ lines!) to find the one bad record which was making things crap out.  I'm back a bit on bind versions, but not that far back, so I would have expected bind to just ignore that bogus record instead of crapping out.  
> 
> Unfortunately, I don't think I saved a copy of the bad record so I could file a bug report, too busy trying to make things work.  
> 
> Cheers,
> John
> 
> 
> Sr. Storage Architect
> TOSHIBA AMERICA, INC.
> 290 Donald Lynch Blvd - Suite 201
> Marlborough, MA 01752
> 508-736-5499 (mobile)
> E-Mail:  john.stoffel at toshiba.com
> Website: Service Now Self Service Portal
> 
> 
> -----Original Message-----
> From: Tony Finch <fanf2 at hermes.cam.ac.uk> On Behalf Of Tony Finch
> Sent: Tuesday, May 11, 2021 7:13 PM
> To: Stoffel, John (TAI) <John.Stoffel at toshiba.com>
> Cc: bind-users at lists.isc.org
> Subject: RE: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.
> 
> Stoffel, John (TAI) <John.Stoffel at toshiba.com> wrote:
>> 
>> And it does dump some errors too, which hopefully will give me an idea 
>> of where my crappy bad record is located, and no use hiding crap:
> 
> yuck, this looks like no fun...
> 
>> http://www.cisco.toshiba.com.  3600    IN      CNAME   redirect.toshiba.com.
>> http://www.cisco.toshiba.com.  3600    IN      RRSIG   CNAME 8 4 3600 20210517093721 20210507083721 38628 t
>> oshiba.com. OEmGkGWSPtbjlCGVt5Ejkgncg2wRcbnfCMSm2By6Fl4gN8R1uXx/ucdN 
>> hVrdiiP8BHWTIte/fvoMrMXbMHxarPJ C6zJn9HHdC9o2dwBoGpknTwJM 
>> DYsy8wA5byhT9f8RVLi0WxLDmncWl2vJcZM6wsKfJ5HWAklGh9YxhOar nCM= ;; Got 
>> bad packet: bad bitmap
>> 16358 bytes
> 
> does it print more hexdump? who knows where the problem might be in 16KB of wire-format DNS...
> 
> I would try another DNS AXFR client that might not give up so easily, e.g.
> if you have a handy copy of perl and Net::DNS, put your Windows DNS server IP address into this one-liner instead of 127.0.0.1
> 
> perl -MNet::DNS -wE 'my $r = Net::DNS::Resolver->new(); $r->nameservers("127.0.0.1"); for my $rr ($r->axfr("toshiba.com")) { $rr->print }'
> 
> The bit of the hexdump you pasted shows another similar CNAME and its RRSIG, so it isn't very enlightening.
> 
>> 46 98 80 00 00 01 00 97 00 00 00 00 07 74 6f 73          F............tos
>  header....        RR counts         qname = zone name
>> 68 69 62 61 03 63 6f 6d 00 00 fc 00 01 08 63 69          hiba.com......ci
>                              00fc = axfr
>> 74 69 62 61 6e 6b c0 0c 00 05 00 01 00 00 0e 10          tibank..........
> backpointer to zone = c00c 0005 = cname
> 
> citibank looks like it follows cisco alphabetically which suggests the zone transfer might be in canonical order, which could perhaps make it easier to find the stray NXT / TYPE30 record(s)
> 
>> 00 0b 08 72 65 64 69 72 65 63 74 c0 0c c0 1d 00          ...redirect.....
>           cname target                  c01d = backpointer to citibank
>> 2e 00 01 00 00 0e 10 00 9f 00 05 08 03 00 00 0e          ................
>  2e = rrsig   type covered = 0005 (cname)
>> 10 60 a2 39 51 60 94 fc 41 96 e4 07 74 6f 73 68          .`.9Q`..A...tosh
>> 69 62 61 03 63 6f 6d 00 83 b6 df 32 9f d9 2a 54          iba.com....2..*T
>> 65 16 1b 28 09 ac aa b3 41 f0 85 60 e6 e2 18 ae          e..(....A..`....
> 
> etc.
> 
> Tony.
> --
> f.anthony.n.finch  <dot at dotat.at>  https://urldefense.com/v3/__https://dotat.at/__;!!BiNunAf9XXY-!TxYeCrRieZyIcOGlb6sXZGm2RAMoSAa_FQxkoFEaSb2XkNsrzZa1Jjd7CvB-n6i-tTNB$
> Fisher, German Bight: Variable, becoming mainly west, 2 to 4. Slight or moderate in Fisher, smooth or slight in German Bight. Showers, fog patches. Moderate, occasionally very poor.
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


From John.Stoffel at toshiba.com  Wed May 12 12:49:31 2021
From: John.Stoffel at toshiba.com (Stoffel, John (TAI))
Date: Wed, 12 May 2021 12:49:31 +0000
Subject: ISC Bind as secondary to Windows Server: bad bitmap error on
 named xfer.
In-Reply-To: <71000BEC-FC6F-49A9-87B5-C5AB6384B213@isc.org>
References: <SJ0PR05MB759501AD8A67B7DD3CAFFC1C93529@SJ0PR05MB7595.namprd05.prod.outlook.com>
 <71000BEC-FC6F-49A9-87B5-C5AB6384B213@isc.org>
Message-ID: <SJ0PR05MB7595BB4F2E37BB9A7368D7EF93529@SJ0PR05MB7595.namprd05.prod.outlook.com>

If dig (and named) would just print the record that broke things, it would help a lot more.  Or print more debug info on the parsing to show where it went off the rails... I found it interesting that perl Net::DNS would pull down the records, and kept going even though there was a problem.  

In any case, Tony was a huge huge help and it got me going enough so I could do a binary search and find the bad record.

John



Sr. Storage Architect
TOSHIBA AMERICA, INC.
290 Donald Lynch Blvd ? Suite 201
Marlborough, MA 01752
508-736-5499 (mobile)
E-Mail:? john.stoffel at toshiba.com
Website: Service Now Self Service Portal


-----Original Message-----
From: Mark Andrews <marka at isc.org> 
Sent: Wednesday, May 12, 2021 8:40 AM
To: Stoffel, John (TAI) <John.Stoffel at toshiba.com>
Cc: Tony Finch <dot at dotat.at>; bind-users at lists.isc.org
Subject: Re: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.

There is enough information to reproduce. Dig does have +besteffort but it doesn?t recover from this. 

You don?t want default handling to accept broken records so just skipping isn?t good behavior.  It should be possible to extend +besteffort to print bad records in unknown format. 

--
Mark Andrews

> On 12 May 2021, at 22:17, Stoffel, John (TAI) <John.Stoffel at toshiba.com> wrote:
> 
> ?Tony,
> A big thanks to you for your suggestion on using the Perl Net::DNS module, using that, I was then able to run named-checkzone on the dumped file (35,000+ lines!) to find the one bad record which was making things crap out.  I'm back a bit on bind versions, but not that far back, so I would have expected bind to just ignore that bogus record instead of crapping out.  
> 
> Unfortunately, I don't think I saved a copy of the bad record so I could file a bug report, too busy trying to make things work.  
> 
> Cheers,
> John
> 
> 
> Sr. Storage Architect
> TOSHIBA AMERICA, INC.
> 290 Donald Lynch Blvd - Suite 201
> Marlborough, MA 01752
> 508-736-5499 (mobile)
> E-Mail:  john.stoffel at toshiba.com
> Website: Service Now Self Service Portal
> 
> 
> -----Original Message-----
> From: Tony Finch <fanf2 at hermes.cam.ac.uk> On Behalf Of Tony Finch
> Sent: Tuesday, May 11, 2021 7:13 PM
> To: Stoffel, John (TAI) <John.Stoffel at toshiba.com>
> Cc: bind-users at lists.isc.org
> Subject: RE: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.
> 
> Stoffel, John (TAI) <John.Stoffel at toshiba.com> wrote:
>> 
>> And it does dump some errors too, which hopefully will give me an 
>> idea of where my crappy bad record is located, and no use hiding crap:
> 
> yuck, this looks like no fun...
> 
>> http://www.cisco.toshiba.com.  3600    IN      CNAME   redirect.toshiba.com.
>> http://www.cisco.toshiba.com.  3600    IN      RRSIG   CNAME 8 4 3600 20210517093721 20210507083721 38628 t
>> oshiba.com. OEmGkGWSPtbjlCGVt5Ejkgncg2wRcbnfCMSm2By6Fl4gN8R1uXx/ucdN
>> hVrdiiP8BHWTIte/fvoMrMXbMHxarPJ C6zJn9HHdC9o2dwBoGpknTwJM 
>> DYsy8wA5byhT9f8RVLi0WxLDmncWl2vJcZM6wsKfJ5HWAklGh9YxhOar nCM= ;; Got 
>> bad packet: bad bitmap
>> 16358 bytes
> 
> does it print more hexdump? who knows where the problem might be in 16KB of wire-format DNS...
> 
> I would try another DNS AXFR client that might not give up so easily, e.g.
> if you have a handy copy of perl and Net::DNS, put your Windows DNS 
> server IP address into this one-liner instead of 127.0.0.1
> 
> perl -MNet::DNS -wE 'my $r = Net::DNS::Resolver->new(); $r->nameservers("127.0.0.1"); for my $rr ($r->axfr("toshiba.com")) { $rr->print }'
> 
> The bit of the hexdump you pasted shows another similar CNAME and its RRSIG, so it isn't very enlightening.
> 
>> 46 98 80 00 00 01 00 97 00 00 00 00 07 74 6f 73          F............tos
>  header....        RR counts         qname = zone name
>> 68 69 62 61 03 63 6f 6d 00 00 fc 00 01 08 63 69          hiba.com......ci
>                              00fc = axfr
>> 74 69 62 61 6e 6b c0 0c 00 05 00 01 00 00 0e 10          tibank..........
> backpointer to zone = c00c 0005 = cname
> 
> citibank looks like it follows cisco alphabetically which suggests the 
> zone transfer might be in canonical order, which could perhaps make it 
> easier to find the stray NXT / TYPE30 record(s)
> 
>> 00 0b 08 72 65 64 69 72 65 63 74 c0 0c c0 1d 00          ...redirect.....
>           cname target                  c01d = backpointer to citibank
>> 2e 00 01 00 00 0e 10 00 9f 00 05 08 03 00 00 0e          ................
>  2e = rrsig   type covered = 0005 (cname)
>> 10 60 a2 39 51 60 94 fc 41 96 e4 07 74 6f 73 68          .`.9Q`..A...tosh
>> 69 62 61 03 63 6f 6d 00 83 b6 df 32 9f d9 2a 54          iba.com....2..*T
>> 65 16 1b 28 09 ac aa b3 41 f0 85 60 e6 e2 18 ae          e..(....A..`....
> 
> etc.
> 
> Tony.
> --
> f.anthony.n.finch  <dot at dotat.at>  
> https://urldefense.com/v3/__https://dotat.at/__;!!BiNunAf9XXY-!TxYeCrR
> ieZyIcOGlb6sXZGm2RAMoSAa_FQxkoFEaSb2XkNsrzZa1Jjd7CvB-n6i-tTNB$
> Fisher, German Bight: Variable, becoming mainly west, 2 to 4. Slight or moderate in Fisher, smooth or slight in German Bight. Showers, fog patches. Moderate, occasionally very poor.
> 
> _______________________________________________
> Please visit 
> https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/bin
> d-users__;!!BiNunAf9XXY-!WndX01fI68KFdfkv8Dd1sUoCS6-HU0arHJIQ534Lx1jfr
> KSSFoxDg59xx1d-rriL9zwE$  to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://urldefense.com/v3/__https://www.isc.org/contact/__;!!BiNunAf9XXY-!WndX01fI68KFdfkv8Dd1sUoCS6-HU0arHJIQ534Lx1jfrKSSFoxDg59xx1d-rg_Z_OUM$  for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/bin
> d-users__;!!BiNunAf9XXY-!WndX01fI68KFdfkv8Dd1sUoCS6-HU0arHJIQ534Lx1jfrKSSFoxDg59xx1d-rriL9zwE$


From ondrej at isc.org  Thu May 13 13:45:20 2021
From: ondrej at isc.org (=?utf-8?B?T25kxZllaiBTdXLDvQ==?=)
Date: Thu, 13 May 2021 15:45:20 +0200
Subject: Deprecating BIND 9.18+ on Windows (or making it community
 improved and supported)
In-Reply-To: <DB685A3B-2275-4721-8CC2-7AE640EF42B8@isc.org>
References: <DB685A3B-2275-4721-8CC2-7AE640EF42B8@isc.org>
Message-ID: <9C3CA6FA-5D1A-47FB-AEC2-8EAA78C14791@isc.org>

Hey,

just a follow-up with a recent real life example.

I?ve spent few days hunting a problem on Windows that got introduced by a fix to outgoing UDP selection code.  While having bugs in normal (and this was really one-liner), it?s abnormal to not have tools for debugging the problem.  Here?s the (incomplete) list of things that would have to be fixed:

1. Automatic crashdump collection in our CI - it should work, but it simply doesn?t and it also ignores the crashdump collection on the Hyper-V Windows Server 2016 I am using for building and debugging Windows binaries

2. Automatic crashdump processing - we need full backtrace printed for all the threads, both in the CI and as a ?cookbook? for developers.

3. The build system rewrite - currently, the build system is this horrible hybrid of Perl that generated MSVC solution files (ninja-build or cmake would be sane alternatives)

4. Improvements like this: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5020 <? the new networking stack uses libuv where we setup listening on each netmgr thread, on Windows, we currently limit this to **single thread**. This branch is an attempt to use WS2 API to make Windows work same as the rest of platforms, but it fails horribly.  It?s beyond our capacity to pursue this any further.

Currently, working on Windows feels like landing on an alien planet with failing lifesupport and finding these strange large eggs in the cavern while having Sigourney Weaver on the team.

Ondrej
--
Ond?ej Sur? (He/Him)
ondrej at isc.org

> On 29. 4. 2021, at 13:35, Ond?ej Sur? <ondrej at isc.org> wrote:
> 
> Hi,
> 
> we?ve been discussing the /subj for quite some time and we are either thinking about deprecating the BIND 9 on Windows completely or just handing it over to the ?community supported? level.
> 
> There are couple reasons for the move:
> 
> * Neither the VisualStudio 2017 which we use nor VS2019 supports the C11 features we extensively use (stdatomic.h) which makes us to write a horrible horrible shims on top of Windows API
> * No BIND 9 developer uses Windows even as secondary platform
> * BIND 9 doesn?t compile on Windows 10 nor with VS2019 and that would require extensive work
> * Windows now has WSL2 (https://docs.microsoft.com/en-us/windows/wsl/install-win10) that can be used to run BIND 9 natively
> 
> We think that the resources that would require us to support new Windows and Visual Studio versions would be better spent elsewhere and therefore we would like to deprecate the official support for Windows since BIND 9.18 (the next ESV, to be released in 2022), the Windows support for BIND 9.16 will be kept intact.
> 
> Now, there are two options:
> 
> a) The support will be completely dropped and the official way to run BIND 9 on Windows would be using WSL2
> b) A volunteer will step up and improve the Windows implementation to support newer platforms and make it up to par with POSIX platforms.
> 
> 1. Let me be absolutely clear here - we are not interested to keep the Windows port just on the life support, that would miss the point. It has been neglected for too long and if we are to keep it, there are several other areas that would need an improvement - the installer, the system integration and the build system would have to be extensively improved as well.
> 
> Thanks,
> Ondrej
> --
> Ond?ej Sur? (He/Him)
> ondrej at isc.org
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210513/c6dda7c8/attachment.bin>

From softwareinfojam at gmail.com  Thu May 13 14:41:27 2021
From: softwareinfojam at gmail.com (Software Info)
Date: Thu, 13 May 2021 09:41:27 -0500
Subject: Update DNSSEC Zone
In-Reply-To: <4b9cd684d1fa4ca395c7806da90726ce@mail.rrcic.com>
References: <FB381F46-C18C-4640-AF24-281B53D2F20D@gmail.com>
 <4b9cd684d1fa4ca395c7806da90726ce@mail.rrcic.com>
Message-ID: <380CD3A4-3E49-48DB-8F61-05F906509EE8@gmail.com>

Wow. Thanks so much for all the responses. Really appreciate it. They made me truly realize that a lot on the info on the net may be either incomplete or just old. I understand a bit better now.
I added the line inline-signing yes; as was suggested and reloaded bind. I am now seeing the .signed, .jbk and .jnl files. The zone also replicates to the slaves and I am seeing the NSEC, RRSIG and DNSKEY entries in the zone files on the slaves. I also checked with the yogaDNS client and it had no problems identifying the DNSSEC server. So I would imagine at this point it is working. I believe as was said too I need now to register the DS with the registrar? Hopefully that should be it if I am not missing anything?

Thanks so much again for the very informative replies.

Best Regards,


From mayer at pdmconsulting.net  Thu May 13 15:29:40 2021
From: mayer at pdmconsulting.net (Danny Mayer)
Date: Thu, 13 May 2021 11:29:40 -0400
Subject: Deprecating BIND 9.18+ on Windows (or making it community
 improved and supported)
In-Reply-To: <9C3CA6FA-5D1A-47FB-AEC2-8EAA78C14791@isc.org>
References: <DB685A3B-2275-4721-8CC2-7AE640EF42B8@isc.org>
 <9C3CA6FA-5D1A-47FB-AEC2-8EAA78C14791@isc.org>
Message-ID: <14432364-f243-62d1-f1eb-e79838ceffa4@pdmconsulting.net>


On 5/13/21 9:45 AM, Ond?ej Sur? wrote:
> Hey,
>
> just a follow-up with a recent real life example.
>
> I?ve spent few days hunting a problem on Windows that got introduced by a fix to outgoing UDP selection code.  While having bugs in normal (and this was really one-liner), it?s abnormal to not have tools for debugging the problem.  Here?s the (incomplete) list of things that would have to be fixed:
>
> 1. Automatic crashdump collection in our CI - it should work, but it simply doesn?t and it also ignores the crashdump collection on the Hyper-V Windows Server 2016 I am using for building and debugging Windows binaries
If you build the binaries in debug mode does it give you the crashdump 
collection? Hard to know without looking at the sources.
> 2. Automatic crashdump processing - we need full backtrace printed for all the threads, both in the CI and as a ?cookbook? for developers.
What happens on Unix? If this is not out-of-the-box then you have to use 
the microsoft tools to do that.
> 3. The build system rewrite - currently, the build system is this horrible hybrid of Perl that generated MSVC solution files (ninja-build or cmake would be sane alternatives)
When the build system was written, around 2001, there were not a lot of 
alternatives. I was used to writing TCL but not a lot of people knew 
that language. Perl was the popular choice. Today that would need to be 
worth revisiting.
> 4. Improvements like this: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5020 <? the new networking stack uses libuv where we setup listening on each netmgr thread, on Windows, we currently limit this to **single thread**. This branch is an attempt to use WS2 API to make Windows work same as the rest of platforms, but it fails horribly.  It?s beyond our capacity to pursue this any further.
Why is this single-threaded? The Windows code handling the incoming and 
outgoing requests was always multithreaded. There was handling within 
the Windows code to properly deal with the threads and locking that was 
necessary.
> Currently, working on Windows feels like landing on an alien planet with failing lifesupport and finding these strange large eggs in the cavern while having Sigourney Weaver on the team.
Well I had warned that there needed to be someone on the team to 
properly deal with the Windows side.


Danny



From ondrej at isc.org  Thu May 13 17:14:29 2021
From: ondrej at isc.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Thu, 13 May 2021 19:14:29 +0200
Subject: Deprecating BIND 9.18+ on Windows (or making it community
 improved and supported)
In-Reply-To: <14432364-f243-62d1-f1eb-e79838ceffa4@pdmconsulting.net>
References: <14432364-f243-62d1-f1eb-e79838ceffa4@pdmconsulting.net>
Message-ID: <E9347922-7BD1-4311-B441-56E5AB75E6BB@isc.org>

Danny,

I didn?t write the email to put the blame anywhere or point fingers. I am just describing the situation.

Ond?ej
--
Ond?ej Sur? ? ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 13. 5. 2021, at 17:29, Danny Mayer <mayer at pdmconsulting.net> wrote:
> 
> ?
>> On 5/13/21 9:45 AM, Ond?ej Sur? wrote:
>> Hey,
>> 
>> just a follow-up with a recent real life example.
>> 
>> I?ve spent few days hunting a problem on Windows that got introduced by a fix to outgoing UDP selection code.  While having bugs in normal (and this was really one-liner), it?s abnormal to not have tools for debugging the problem.  Here?s the (incomplete) list of things that would have to be fixed:
>> 
>> 1. Automatic crashdump collection in our CI - it should work, but it simply doesn?t and it also ignores the crashdump collection on the Hyper-V Windows Server 2016 I am using for building and debugging Windows binaries
> If you build the binaries in debug mode does it give you the crashdump collection? Hard to know without looking at the sources.
>> 2. Automatic crashdump processing - we need full backtrace printed for all the threads, both in the CI and as a ?cookbook? for developers.
> What happens on Unix? If this is not out-of-the-box then you have to use the microsoft tools to do that.
>> 3. The build system rewrite - currently, the build system is this horrible hybrid of Perl that generated MSVC solution files (ninja-build or cmake would be sane alternatives)
> When the build system was written, around 2001, there were not a lot of alternatives. I was used to writing TCL but not a lot of people knew that language. Perl was the popular choice. Today that would need to be worth revisiting.
>> 4. Improvements like this: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5020 <? the new networking stack uses libuv where we setup listening on each netmgr thread, on Windows, we currently limit this to **single thread**. This branch is an attempt to use WS2 API to make Windows work same as the rest of platforms, but it fails horribly.  It?s beyond our capacity to pursue this any further.
> Why is this single-threaded? The Windows code handling the incoming and outgoing requests was always multithreaded. There was handling within the Windows code to properly deal with the threads and locking that was necessary.
>> Currently, working on Windows feels like landing on an alien planet with failing lifesupport and finding these strange large eggs in the cavern while having Sigourney Weaver on the team.
> Well I had warned that there needed to be someone on the team to properly deal with the Windows side.
> 
> 
> Danny
> 
> 


From mayer at pdmconsulting.net  Thu May 13 17:36:18 2021
From: mayer at pdmconsulting.net (Danny Mayer)
Date: Thu, 13 May 2021 13:36:18 -0400
Subject: Deprecating BIND 9.18+ on Windows (or making it community
 improved and supported)
In-Reply-To: <E9347922-7BD1-4311-B441-56E5AB75E6BB@isc.org>
References: <14432364-f243-62d1-f1eb-e79838ceffa4@pdmconsulting.net>
 <E9347922-7BD1-4311-B441-56E5AB75E6BB@isc.org>
Message-ID: <bbb4227f-f54a-0a10-f461-b73f41415827@pdmconsulting.net>

I didn't think you were blaming anyone. I was just explaining the 
history though my work on it largely stopped after 2008-9.

Danny

On 5/13/21 1:14 PM, Ond?ej Sur? wrote:
> Danny,
>
> I didn?t write the email to put the blame anywhere or point fingers. I am just describing the situation.
>
> Ond?ej
> --
> Ond?ej Sur? ? ISC (He/Him)
>
> My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.
>
>> On 13. 5. 2021, at 17:29, Danny Mayer <mayer at pdmconsulting.net> wrote:
>>
>> ?
>>> On 5/13/21 9:45 AM, Ond?ej Sur? wrote:
>>> Hey,
>>>
>>> just a follow-up with a recent real life example.
>>>
>>> I?ve spent few days hunting a problem on Windows that got introduced by a fix to outgoing UDP selection code.  While having bugs in normal (and this was really one-liner), it?s abnormal to not have tools for debugging the problem.  Here?s the (incomplete) list of things that would have to be fixed:
>>>
>>> 1. Automatic crashdump collection in our CI - it should work, but it simply doesn?t and it also ignores the crashdump collection on the Hyper-V Windows Server 2016 I am using for building and debugging Windows binaries
>> If you build the binaries in debug mode does it give you the crashdump collection? Hard to know without looking at the sources.
>>> 2. Automatic crashdump processing - we need full backtrace printed for all the threads, both in the CI and as a ?cookbook? for developers.
>> What happens on Unix? If this is not out-of-the-box then you have to use the microsoft tools to do that.
>>> 3. The build system rewrite - currently, the build system is this horrible hybrid of Perl that generated MSVC solution files (ninja-build or cmake would be sane alternatives)
>> When the build system was written, around 2001, there were not a lot of alternatives. I was used to writing TCL but not a lot of people knew that language. Perl was the popular choice. Today that would need to be worth revisiting.
>>> 4. Improvements like this: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5020 <? the new networking stack uses libuv where we setup listening on each netmgr thread, on Windows, we currently limit this to **single thread**. This branch is an attempt to use WS2 API to make Windows work same as the rest of platforms, but it fails horribly.  It?s beyond our capacity to pursue this any further.
>> Why is this single-threaded? The Windows code handling the incoming and outgoing requests was always multithreaded. There was handling within the Windows code to properly deal with the threads and locking that was necessary.
>>> Currently, working on Windows feels like landing on an alien planet with failing lifesupport and finding these strange large eggs in the cavern while having Sigourney Weaver on the team.
>> Well I had warned that there needed to be someone on the team to properly deal with the Windows side.
>>
>>
>> Danny
>>
>>
>


From dan at newideatest.site  Sun May 16 00:17:31 2021
From: dan at newideatest.site (Dan Egli)
Date: Sat, 15 May 2021 18:17:31 -0600
Subject: Inline signing fails dnsviz test - STILL [LONG]
In-Reply-To: <256441c6-1c81-3b4e-a019-4a50e165dfde@dotat.at>
References: <a14145f2-ed72-80e2-85b2-c490be43ba03@newideatest.site>
 <629f4963-b50c-47db-b532-ba48da9566a6@rrcic.com>
 <e00f633e-6bf7-6e3d-0e29-03067676a07a@newideatest.site>
 <9551b280-554d-4bcf-c932-e16540997af9@dotat.at>
 <30a70313-bc54-f536-a2a4-f067a68529a2@newideatest.site>
 <256441c6-1c81-3b4e-a019-4a50e165dfde@dotat.at>
Message-ID: <21879c71-ab6e-0e8e-3049-0c2b5d05cc97@newideatest.site>

On 5/10/2021 12:38 PM, Tony Finch wrote:
> Dan Egli <dan at newideatest.site> wrote:
>> 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?
> 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.


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:

#dig newideatest.site dnskey | dnssec-dsfromkey -2 -f - newideatest.site
newideatest.site. IN DS 49236 13 2 <LONG HASH>

Ok. Copy the long hash to the Registrar, plug it in. Check, done that.

 ?# dig mx newideatest.site @8.8.4.4

; <<>> DiG 9.16.15 <<>> mx newideatest.site @8.8.4.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 631
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;newideatest.site.????????????? IN????? MX

;; Query time: 50 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Sat May 15 18:12:44 MDT 2021
;; MSG SIZE? rcvd: 45

ServFail?! WHAT?? So I go to DNSVIZ and run their test.


          Errors (9)

  * 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)
  * 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)
  * 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)
  * 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)
  * 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)
  * 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)
  * 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)
  * 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)
  * 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)


          Warnings (13)

  * 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)
  * 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)
  * 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)
  * 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)
  * 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)
  * 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)
  * 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)
  * 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
  * 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
  * site/DS (alg 8, id 51676): DNSSEC specification prohibits signing
    with DS records that use digest algorithm 1 (SHA-1).
  * site/DS (alg 8, id 51676): DNSSEC specification prohibits signing
    with DS records that use digest algorithm 1 (SHA-1).
  * 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.
  * 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.

So, what am I doing wrong? Here's the zone statement for the 
newideatest.site zone in my named.conf:

 ??????? zone "newideatest.site" {
 ??????????????? type master;
 ??????????????? file "pri/newideatest.zone";
 ??????????????? allow-query { any; };
 ??????????????? allow-transfer {
 ????????????????? 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;
 ??????????????? };
 ??????????????? allow-update { trusted; };
 ??????????????? key-directory "/var/bind/pri/keys";
 ??????????????? inline-signing yes;
 ??????????????? dnssec-policy default;
 ??????? };
};

Help? If you have errors reaching me, try dan at eglifamily.name, as it 
doesn't seem to be having issues.

--Dan Egli
 From my Test Server

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210515/5035880b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x11B7451DF2015959.asc
Type: application/pgp-keys
Size: 3792 bytes
Desc: OpenPGP public key
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210515/5035880b/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210515/5035880b/attachment-0003.bin>

From marka at isc.org  Sun May 16 06:06:42 2021
From: marka at isc.org (Mark Andrews)
Date: Sun, 16 May 2021 16:06:42 +1000
Subject: Inline signing fails dnsviz test - STILL [LONG]
In-Reply-To: <21879c71-ab6e-0e8e-3049-0c2b5d05cc97@newideatest.site>
References: <a14145f2-ed72-80e2-85b2-c490be43ba03@newideatest.site>
 <629f4963-b50c-47db-b532-ba48da9566a6@rrcic.com>
 <e00f633e-6bf7-6e3d-0e29-03067676a07a@newideatest.site>
 <9551b280-554d-4bcf-c932-e16540997af9@dotat.at>
 <30a70313-bc54-f536-a2a4-f067a68529a2@newideatest.site>
 <256441c6-1c81-3b4e-a019-4a50e165dfde@dotat.at>
 <21879c71-ab6e-0e8e-3049-0c2b5d05cc97@newideatest.site>
Message-ID: <8F597D10-E70B-4A1D-9A49-7E070BE6669E@isc.org>



> On 16 May 2021, at 10:17, Dan Egli via bind-users <bind-users at lists.isc.org> wrote:
> 
> On 5/10/2021 12:38 PM, Tony Finch wrote:
>> Dan Egli <dan at newideatest.site>
>>  wrote:
>> 
>>> 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?
>>> 
>> 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.
>> 
> 
> 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:
> 
> #dig newideatest.site dnskey | dnssec-dsfromkey -2 -f - newideatest.site
> newideatest.site. IN DS 49236 13 2 <LONG HASH>
> 
> Ok. Copy the long hash to the Registrar, plug it in. Check, done that.
> 
>  # dig mx newideatest.site @8.8.4.4
> 
> ; <<>> DiG 9.16.15 <<>> mx newideatest.site @8.8.4.4
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 631
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;newideatest.site.              IN      MX
> 
> ;; Query time: 50 msec
> ;; SERVER: 8.8.4.4#53(8.8.4.4)
> ;; WHEN: Sat May 15 18:12:44 MDT 2021
> ;; MSG SIZE  rcvd: 45
> ServFail?! WHAT?

This is a known bug fixed in BIND 9.11.25.  Upgrade.  Once the DS is added to .site for
newideatest.site the resolution will work.
  
> So I go to DNSVIZ and run their test. 
> Errors (9)
> 
> 	? 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)
> 	? 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)
> 	? 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)
> 	? 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)
> 	? 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)
> 	? 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)
> 	? 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)
> 	? 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)
> 	? 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)
> Warnings (13)
> 
> 	? 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)
> 	? 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)
> 	? 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)
> 	? 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)
> 	? 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)
> 	? 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)
> 	? 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)
> 	? 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
> 	? 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
> 	? site/DS (alg 8, id 51676): DNSSEC specification prohibits signing with DS records that use digest algorithm 1 (SHA-1).
> 	? site/DS (alg 8, id 51676): DNSSEC specification prohibits signing with DS records that use digest algorithm 1 (SHA-1).
> 	? 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.
> 	? 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.
> So, what am I doing wrong? Here's the zone statement for the newideatest.site zone in my named.conf:
> 
>         zone "newideatest.site" {
>                 type master;
>                 file "pri/newideatest.zone";
>                 allow-query { any; };
>                 allow-transfer {
>                   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;
>                 };
>                 allow-update { trusted; };
>                 key-directory "/var/bind/pri/keys";
>                 inline-signing yes;
>                 dnssec-policy default;
>         };
> };
> Help? If you have errors reaching me, try dan at eglifamily.name, as it doesn't seem to be having issues.
> --Dan Egli
> From my Test Server
> 
> <OpenPGP_0x11B7451DF2015959.asc>_______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org


From dan at newideatest.site  Sun May 16 06:44:56 2021
From: dan at newideatest.site (Dan Egli)
Date: Sun, 16 May 2021 00:44:56 -0600
Subject: Inline signing fails dnsviz test - STILL [LONG]
In-Reply-To: <8F597D10-E70B-4A1D-9A49-7E070BE6669E@isc.org>
References: <a14145f2-ed72-80e2-85b2-c490be43ba03@newideatest.site>
 <629f4963-b50c-47db-b532-ba48da9566a6@rrcic.com>
 <e00f633e-6bf7-6e3d-0e29-03067676a07a@newideatest.site>
 <9551b280-554d-4bcf-c932-e16540997af9@dotat.at>
 <30a70313-bc54-f536-a2a4-f067a68529a2@newideatest.site>
 <256441c6-1c81-3b4e-a019-4a50e165dfde@dotat.at>
 <21879c71-ab6e-0e8e-3049-0c2b5d05cc97@newideatest.site>
 <8F597D10-E70B-4A1D-9A49-7E070BE6669E@isc.org>
Message-ID: <62ecc5b7-0641-fbd5-6c46-06e8a408815b@newideatest.site>

Upgrade to WHAT? You said it was fixed in 9.11.25, but isn't that a lot 
OLDER than 9.16.15, which is what I'm running?
jupiter ~ # named -v
BIND 9.16.15 (Stable Release) <id:4469e3e>
jupiter ~ # dig -v
DiG 9.16.15


On 5/16/2021 12:06 AM, Mark Andrews wrote:
>
>> On 16 May 2021, at 10:17, Dan Egli via bind-users <bind-users at lists.isc.org> wrote:
>>
>> On 5/10/2021 12:38 PM, Tony Finch wrote:
>>> Dan Egli <dan at newideatest.site>
>>>   wrote:
>>>
>>>> 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?
>>>>
>>> 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.
>>>
>> 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:
>>
>> #dig newideatest.site dnskey | dnssec-dsfromkey -2 -f - newideatest.site
>> newideatest.site. IN DS 49236 13 2 <LONG HASH>
>>
>> Ok. Copy the long hash to the Registrar, plug it in. Check, done that.
>>
>>   # dig mx newideatest.site @8.8.4.4
>>
>> ; <<>> DiG 9.16.15 <<>> mx newideatest.site @8.8.4.4
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 631
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 512
>> ;; QUESTION SECTION:
>> ;newideatest.site.              IN      MX
>>
>> ;; Query time: 50 msec
>> ;; SERVER: 8.8.4.4#53(8.8.4.4)
>> ;; WHEN: Sat May 15 18:12:44 MDT 2021
>> ;; MSG SIZE  rcvd: 45
>> ServFail?! WHAT?
> This is a known bug fixed in BIND 9.11.25.  Upgrade.  Once the DS is added to .site for
> newideatest.site the resolution will work.
>    

-- 
Dan Egli
 From my Test Server

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x11B7451DF2015959.asc
Type: application/pgp-keys
Size: 3792 bytes
Desc: OpenPGP public key
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210516/223a8c4d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210516/223a8c4d/attachment-0001.bin>

From ondrej at isc.org  Sun May 16 07:03:30 2021
From: ondrej at isc.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Sun, 16 May 2021 09:03:30 +0200
Subject: Inline signing fails dnsviz test - STILL [LONG]
In-Reply-To: <62ecc5b7-0641-fbd5-6c46-06e8a408815b@newideatest.site>
References: <62ecc5b7-0641-fbd5-6c46-06e8a408815b@newideatest.site>
Message-ID: <79970DDD-868D-4354-9D7A-BB138FB1BA54@isc.org>

I think Mark jumped on something else, your zone is seriously broken and not because of DNSSEC:

https://dnssec-analyzer.verisignlabs.com/newideatest.site

All of these NSes must have the correct zone content and not be broken:

newideatest.site.       3600    IN      NS      jupiter.eglifamily.name.
newideatest.site.       3600    IN      NS      uz5qfm8n244kn4qz8mh437w9kzvpudduwyldp5361v9n0vh8sx5ucu.free.ns.buddyns.com.
newideatest.site.       3600    IN      NS      uz5154v9zl2nswf05td8yzgtd0jl6mvvjp98ut07ln0ydp2bqh1skn.free.ns.buddyns.com.
newideatest.site.       3600    IN      NS      uz52u1wtmumlrx5fwu6nmv22ntcddxcjjw41z8sfd6ur9n7797lrv9.free.ns.buddyns.com.
newideatest.site.       3600    IN      NS      uz5w6sb91zt99b73bznfkvtd0j1snxby06gg4hr0p8uum27n0hf6cd.free.ns.buddyns.com.

--
Ond?ej Sur? ? ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 16. 5. 2021, at 8:45, Dan Egli via bind-users <bind-users at lists.isc.org> wrote:
> 
> ?Upgrade to WHAT? You said it was fixed in 9.11.25, but isn't that a lot OLDER than 9.16.15, which is what I'm running?
> jupiter ~ # named -v
> BIND 9.16.15 (Stable Release) <id:4469e3e>
> jupiter ~ # dig -v
> DiG 9.16.15
> 
> 
>> On 5/16/2021 12:06 AM, Mark Andrews wrote:
>> 
>>>> On 16 May 2021, at 10:17, Dan Egli via bind-users <bind-users at lists.isc.org> wrote:
>>> 
>>> On 5/10/2021 12:38 PM, Tony Finch wrote:
>>>> Dan Egli <dan at newideatest.site>
>>>>  wrote:
>>>> 
>>>>> 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?
>>>>> 
>>>> 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.
>>>> 
>>> 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:
>>> 
>>> #dig newideatest.site dnskey | dnssec-dsfromkey -2 -f - newideatest.site
>>> newideatest.site. IN DS 49236 13 2 <LONG HASH>
>>> 
>>> Ok. Copy the long hash to the Registrar, plug it in. Check, done that.
>>> 
>>>  # dig mx newideatest.site @8.8.4.4
>>> 
>>> ; <<>> DiG 9.16.15 <<>> mx newideatest.site @8.8.4.4
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 631
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>>> 
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 512
>>> ;; QUESTION SECTION:
>>> ;newideatest.site.              IN      MX
>>> 
>>> ;; Query time: 50 msec
>>> ;; SERVER: 8.8.4.4#53(8.8.4.4)
>>> ;; WHEN: Sat May 15 18:12:44 MDT 2021
>>> ;; MSG SIZE  rcvd: 45
>>> ServFail?! WHAT?
>> This is a known bug fixed in BIND 9.11.25.  Upgrade.  Once the DS is added to .site for
>> newideatest.site the resolution will work.
>>   
> 
> -- 
> Dan Egli
> From my Test Server
> 
> <OpenPGP_0x11B7451DF2015959.asc>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210516/56b6d407/attachment-0001.htm>

From marka at isc.org  Sun May 16 07:08:14 2021
From: marka at isc.org (Mark Andrews)
Date: Sun, 16 May 2021 17:08:14 +1000
Subject: Inline signing fails dnsviz test - STILL [LONG]
In-Reply-To: <62ecc5b7-0641-fbd5-6c46-06e8a408815b@newideatest.site>
References: <a14145f2-ed72-80e2-85b2-c490be43ba03@newideatest.site>
 <629f4963-b50c-47db-b532-ba48da9566a6@rrcic.com>
 <e00f633e-6bf7-6e3d-0e29-03067676a07a@newideatest.site>
 <9551b280-554d-4bcf-c932-e16540997af9@dotat.at>
 <30a70313-bc54-f536-a2a4-f067a68529a2@newideatest.site>
 <256441c6-1c81-3b4e-a019-4a50e165dfde@dotat.at>
 <21879c71-ab6e-0e8e-3049-0c2b5d05cc97@newideatest.site>
 <8F597D10-E70B-4A1D-9A49-7E070BE6669E@isc.org>
 <62ecc5b7-0641-fbd5-6c46-06e8a408815b@newideatest.site>
Message-ID: <9411293F-E1BA-4A57-860F-81F94E698481@isc.org>

Sorry, miss read your version 11 vs 16.  That said it is hard to work out what is going wrong when
you keep changing things and don?t actually have nameservers that are responding.   You had servers
that where giving DNSSEC responses, then ones that are returning unsigned responses and now ones
that are not answering.

> On 16 May 2021, at 16:44, Dan Egli <dan at newideatest.site> wrote:
> 
> Upgrade to WHAT? You said it was fixed in 9.11.25, but isn't that a lot OLDER than 9.16.15, which is what I'm running?
> jupiter ~ # named -v
> BIND 9.16.15 (Stable Release) <id:4469e3e>
> jupiter ~ # dig -v
> DiG 9.16.15
> 
> 
> On 5/16/2021 12:06 AM, Mark Andrews wrote:
>> 
>>> On 16 May 2021, at 10:17, Dan Egli via bind-users <bind-users at lists.isc.org> wrote:
>>> 
>>> On 5/10/2021 12:38 PM, Tony Finch wrote:
>>>> Dan Egli <dan at newideatest.site>
>>>>  wrote:
>>>> 
>>>>> 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?
>>>>> 
>>>> 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.
>>>> 
>>> 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:
>>> 
>>> #dig newideatest.site dnskey | dnssec-dsfromkey -2 -f - newideatest.site
>>> newideatest.site. IN DS 49236 13 2 <LONG HASH>
>>> 
>>> Ok. Copy the long hash to the Registrar, plug it in. Check, done that.
>>> 
>>>  # dig mx newideatest.site @8.8.4.4
>>> 
>>> ; <<>> DiG 9.16.15 <<>> mx newideatest.site @8.8.4.4
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 631
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>>> 
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 512
>>> ;; QUESTION SECTION:
>>> ;newideatest.site.              IN      MX
>>> 
>>> ;; Query time: 50 msec
>>> ;; SERVER: 8.8.4.4#53(8.8.4.4)
>>> ;; WHEN: Sat May 15 18:12:44 MDT 2021
>>> ;; MSG SIZE  rcvd: 45
>>> ServFail?! WHAT?
>> This is a known bug fixed in BIND 9.11.25.  Upgrade.  Once the DS is added to .site for
>> newideatest.site the resolution will work.
>>   
> 
> -- 
> Dan Egli
> From my Test Server
> 
> <OpenPGP_0x11B7451DF2015959.asc>

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org


From dan at newideatest.site  Sun May 16 08:47:10 2021
From: dan at newideatest.site (Dan Egli)
Date: Sun, 16 May 2021 02:47:10 -0600
Subject: Inline signing fails dnsviz test - STILL [LONG]
In-Reply-To: <79970DDD-868D-4354-9D7A-BB138FB1BA54@isc.org>
References: <62ecc5b7-0641-fbd5-6c46-06e8a408815b@newideatest.site>
 <79970DDD-868D-4354-9D7A-BB138FB1BA54@isc.org>
Message-ID: <7c57aef4-2204-2a37-98da-0e37869446c4@newideatest.site>

Yea, I'm aware of the buddyns.com servers not responding. Noting I can 
do about that. They CLAIM I've had over 300k requests in the last couple 
of weeks and have exceeded my monthly cap. I say Bull Crap and am 
looking to move to different servers.

Meanwhile, I found that the google nameservers are currently not working 
either. I can query my domain at places like 1.1.1.1 and 1.0.0.1 no 
problem. But if I query at 8.8.8.8 or 8.8.4.4 I get servfail even though 
I have completely disabled DNSSEC for this zone.

Once I get rid of BuddyNS and place it with a working secondary I'll 
re-apply the DNSSEC setup and try again.

On 5/16/2021 1:03 AM, Ond?ej Sur? wrote:
> I think Mark jumped on something else, your zone is seriously broken 
> and not because of DNSSEC:
>
> https://dnssec-analyzer.verisignlabs.com/newideatest.site 
> <https://dnssec-analyzer.verisignlabs.com/newideatest.site>
>
> All of these NSes must have the correct zone content and not be broken:
>
> newideatest.site. ? ? ? 3600 ? ?IN ? ? ?NS ?jupiter.eglifamily.name.
> newideatest.site. ? ? ? 3600 ? ?IN ? ? ?NS 
> ?uz5qfm8n244kn4qz8mh437w9kzvpudduwyldp5361v9n0vh8sx5ucu.free.ns.buddyns.com.
> newideatest.site. ? ? ? 3600 ? ?IN ? ? ?NS 
> ?uz5154v9zl2nswf05td8yzgtd0jl6mvvjp98ut07ln0ydp2bqh1skn.free.ns.buddyns.com.
> newideatest.site. ? ? ? 3600 ? ?IN ? ? ?NS 
> ?uz52u1wtmumlrx5fwu6nmv22ntcddxcjjw41z8sfd6ur9n7797lrv9.free.ns.buddyns.com.
> newideatest.site. ? ? ? 3600 ? ?IN ? ? ?NS 
> ?uz5w6sb91zt99b73bznfkvtd0j1snxby06gg4hr0p8uum27n0hf6cd.free.ns.buddyns.com.
>
> --
> Ond?ej Sur? ? ISC (He/Him)
>
> My working hours and your working hours may be different. Please do 
> not feel obligated to reply outside your normal working hours.
>
>> On 16. 5. 2021, at 8:45, Dan Egli via bind-users 
>> <bind-users at lists.isc.org> wrote:
>>
>> ?Upgrade to WHAT? You said it was fixed in 9.11.25, but isn't that a 
>> lot OLDER than 9.16.15, which is what I'm running?
>> jupiter ~ # named -v
>> BIND 9.16.15 (Stable Release) <id:4469e3e>
>> jupiter ~ # dig -v
>> DiG 9.16.15
>>
>>
>> On 5/16/2021 12:06 AM, Mark Andrews wrote:
>>>
>>>> On 16 May 2021, at 10:17, Dan Egli via bind-users 
>>>> <bind-users at lists.isc.org> wrote:
>>>>
>>>> On 5/10/2021 12:38 PM, Tony Finch wrote:
>>>>> Dan Egli <dan at newideatest.site>
>>>>> ?wrote:
>>>>>
>>>>>> 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?
>>>>>>
>>>>> 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.
>>>>>
>>>> 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:
>>>>
>>>> #dig newideatest.site dnskey | dnssec-dsfromkey -2 -f - 
>>>> newideatest.site
>>>> newideatest.site. IN DS 49236 13 2 <LONG HASH>
>>>>
>>>> Ok. Copy the long hash to the Registrar, plug it in. Check, done that.
>>>>
>>>> ?# dig mx newideatest.site @8.8.4.4
>>>>
>>>> ; <<>> DiG 9.16.15 <<>> mx newideatest.site @8.8.4.4
>>>> ;; global options: +cmd
>>>> ;; Got answer:
>>>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 631
>>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>>>>
>>>> ;; OPT PSEUDOSECTION:
>>>> ; EDNS: version: 0, flags:; udp: 512
>>>> ;; QUESTION SECTION:
>>>> ;newideatest.site. ?????????????IN ?????MX
>>>>
>>>> ;; Query time: 50 msec
>>>> ;; SERVER: 8.8.4.4#53(8.8.4.4)
>>>> ;; WHEN: Sat May 15 18:12:44 MDT 2021
>>>> ;; MSG SIZE ?rcvd: 45
>>>> ServFail?! WHAT?
>>> This is a known bug fixed in BIND 9.11.25. ?Upgrade. ?Once the DS is 
>>> added to .site for
>>> newideatest.site the resolution will work.
>>>
>>
>> -- 
>> Dan Egli
>> From my Test Server
>>
>> <OpenPGP_0x11B7451DF2015959.asc>
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>>
>> ISC funds the development of this software with paid support 
>> subscriptions. Contact us at https://www.isc.org/contact/ for more 
>> information.
>>
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Dan Egli
 From my Test Server

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x11B7451DF2015959.asc
Type: application/pgp-keys
Size: 3792 bytes
Desc: OpenPGP public key
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210516/73a1397b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210516/73a1397b/attachment-0001.bin>

From ondrej at isc.org  Sun May 16 09:10:08 2021
From: ondrej at isc.org (=?utf-8?B?T25kxZllaiBTdXLDvQ==?=)
Date: Sun, 16 May 2021 11:10:08 +0200
Subject: Inline signing fails dnsviz test - STILL [LONG]
In-Reply-To: <7c57aef4-2204-2a37-98da-0e37869446c4@newideatest.site>
References: <62ecc5b7-0641-fbd5-6c46-06e8a408815b@newideatest.site>
 <79970DDD-868D-4354-9D7A-BB138FB1BA54@isc.org>
 <7c57aef4-2204-2a37-98da-0e37869446c4@newideatest.site>
Message-ID: <691AC0F0-B988-4AD6-9E7D-5B4E6290E9AA@isc.org>

Even jupiter.eglifamily.name. doesn?t return DNSSEC signed zone:

$ dig +norec +dnssec IN mx newideatest.site @jupiter.eglifamily.name.

; <<>> DiG 9.17.11-1+0~20210318.53+debian10~1.gbp0184f1-Debian <<>> +norec +dnssec IN mx newideatest.site @jupiter.eglifamily.name.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41775
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 4f4d8ab87a8cc4240100000060a0e1211ad492152d054053 (good)
;; QUESTION SECTION:
;newideatest.site.		IN	MX

;; ANSWER SECTION:
newideatest.site.	120	IN	MX	0 athena.newideatest.site.
newideatest.site.	120	IN	MX	9999 gw.kictanet.or.ke.

;; Query time: 152 msec
;; SERVER: 209.141.58.25#53(jupiter.eglifamily.name.) (UDP)
;; WHEN: Sun May 16 11:08:49 CEST 2021
;; MSG SIZE  rcvd: 129

First fix this ^^^

Ondrej
--
Ond?ej Sur? (He/Him)
ondrej at isc.org

> On 16. 5. 2021, at 10:47, Dan Egli <dan at newideatest.site> wrote:
> 
> Yea, I'm aware of the buddyns.com servers not responding. Noting I can do about that. They CLAIM I've had over 300k requests in the last couple of weeks and have exceeded my monthly cap. I say Bull Crap and am looking to move to different servers.
> 
> Meanwhile, I found that the google nameservers are currently not working either. I can query my domain at places like 1.1.1.1 and 1.0.0.1 no problem. But if I query at 8.8.8.8 or 8.8.4.4 I get servfail even though I have completely disabled DNSSEC for this zone.
> 
> Once I get rid of BuddyNS and place it with a working secondary I'll re-apply the DNSSEC setup and try again.
> 
> On 5/16/2021 1:03 AM, Ond?ej Sur? wrote:
>> I think Mark jumped on something else, your zone is seriously broken and not because of DNSSEC:
>> 
>> https://dnssec-analyzer.verisignlabs.com/newideatest.site <https://dnssec-analyzer.verisignlabs.com/newideatest.site>
>> 
>> All of these NSes must have the correct zone content and not be broken:
>> 
>> newideatest.site.       3600    IN      NS  jupiter.eglifamily.name.
>> newideatest.site.       3600    IN      NS  uz5qfm8n244kn4qz8mh437w9kzvpudduwyldp5361v9n0vh8sx5ucu.free.ns.buddyns.com.
>> newideatest.site.       3600    IN      NS  uz5154v9zl2nswf05td8yzgtd0jl6mvvjp98ut07ln0ydp2bqh1skn.free.ns.buddyns.com.
>> newideatest.site.       3600    IN      NS  uz52u1wtmumlrx5fwu6nmv22ntcddxcjjw41z8sfd6ur9n7797lrv9.free.ns.buddyns.com.
>> newideatest.site.       3600    IN      NS  uz5w6sb91zt99b73bznfkvtd0j1snxby06gg4hr0p8uum27n0hf6cd.free.ns.buddyns.com.
>> 
>> --
>> Ond?ej Sur? ? ISC (He/Him)
>> 
>> My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.
>> 
>>> On 16. 5. 2021, at 8:45, Dan Egli via bind-users <bind-users at lists.isc.org> wrote:
>>> 
>>> ?Upgrade to WHAT? You said it was fixed in 9.11.25, but isn't that a lot OLDER than 9.16.15, which is what I'm running?
>>> jupiter ~ # named -v
>>> BIND 9.16.15 (Stable Release) <id:4469e3e>
>>> jupiter ~ # dig -v
>>> DiG 9.16.15
>>> 
>>> 
>>> On 5/16/2021 12:06 AM, Mark Andrews wrote:
>>>> 
>>>>> On 16 May 2021, at 10:17, Dan Egli via bind-users <bind-users at lists.isc.org> wrote:
>>>>> 
>>>>> On 5/10/2021 12:38 PM, Tony Finch wrote:
>>>>>> Dan Egli <dan at newideatest.site>
>>>>>>  wrote:
>>>>>> 
>>>>>>> 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?
>>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>> 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:
>>>>> 
>>>>> #dig newideatest.site dnskey | dnssec-dsfromkey -2 -f - newideatest.site
>>>>> newideatest.site. IN DS 49236 13 2 <LONG HASH>
>>>>> 
>>>>> Ok. Copy the long hash to the Registrar, plug it in. Check, done that.
>>>>> 
>>>>>  # dig mx newideatest.site @8.8.4.4
>>>>> 
>>>>> ; <<>> DiG 9.16.15 <<>> mx newideatest.site @8.8.4.4
>>>>> ;; global options: +cmd
>>>>> ;; Got answer:
>>>>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 631
>>>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>>>>> 
>>>>> ;; OPT PSEUDOSECTION:
>>>>> ; EDNS: version: 0, flags:; udp: 512
>>>>> ;; QUESTION SECTION:
>>>>> ;newideatest.site.              IN      MX
>>>>> 
>>>>> ;; Query time: 50 msec
>>>>> ;; SERVER: 8.8.4.4#53(8.8.4.4)
>>>>> ;; WHEN: Sat May 15 18:12:44 MDT 2021
>>>>> ;; MSG SIZE  rcvd: 45
>>>>> ServFail?! WHAT?
>>>> This is a known bug fixed in BIND 9.11.25.  Upgrade.  Once the DS is added to .site for
>>>> newideatest.site the resolution will work.
>>>> 
>>> 
>>> --
>>> Dan Egli
>>> From my Test Server
>>> 
>>> <OpenPGP_0x11B7451DF2015959.asc>
>>> _______________________________________________
>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>> 
>>> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>>> 
>>> 
>>> bind-users mailing list
>>> bind-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
> 
> --
> Dan Egli
> From my Test Server
> 
> <OpenPGP_0x11B7451DF2015959.asc>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210516/4f55102b/attachment-0001.bin>

From bind at jubileegroup.co.uk  Sun May 16 10:33:18 2021
From: bind at jubileegroup.co.uk (G.W. Haywood)
Date: Sun, 16 May 2021 11:33:18 +0100 (BST)
Subject: Inline signing fails dnsviz test - STILL [LONG]
Message-ID: <alpine.DEB.2.21.2105161115420.25570@piplus.local.jubileegroup.co.uk>

Hi there,

On Sun, 16 May 2021, Dan Egli wrote:

> ... I'm aware of the buddyns.com servers not responding. Noting I can 
> do about that. They CLAIM I've had over 300k requests in the last couple 
> of weeks and have exceeded my monthly cap. I say Bull Crap ...

I'd be inclined to believe them, but you could monitor the traffic
directly e.g. with tcpdump.  If you can't agree their numbers then
you're some information, I'd be dissatisfied with that.

But FWIW I've no complaints about the service from Hurricane Electric.

> Meanwhile, I found that the google nameservers are currently not working 
> either. I can query my domain at places like 1.1.1.1 and 1.0.0.1 no 
> problem. But if I query at 8.8.8.8 or 8.8.4.4 I get servfail even though 
> I have completely disabled DNSSEC for this zone.

Something somewhere seems, er, unusual.

Your problems aren't being compounded by some dumb firewall are they?

Some long TTL?

Just shootin' the fish, I don't know nearly as much about this stuff
at the guys already helping you.

-- 

73,
Ged.

From bind at jubileegroup.co.uk  Sun May 16 12:12:44 2021
From: bind at jubileegroup.co.uk (G.W. Haywood)
Date: Sun, 16 May 2021 13:12:44 +0100 (BST)
Subject: Inline signing fails dnsviz test - STILL [LONG]
Message-ID: <alpine.DEB.2.21.2105161310300.25570@piplus.local.jubileegroup.co.uk>

Hello again,

On Sun, 16 May 2021, I wrote:

> ...  If you can't agree their numbers then
> you're some information ...

Having screen troubles.  The word 'missing' is missing.

-- 

73,
Ged.

From ca at nodns4.us  Sun May 16 19:50:27 2021
From: ca at nodns4.us (Chuck Aurora)
Date: Sun, 16 May 2021 14:50:27 -0500
Subject: BIND 9 ARM, html/pdf not in the source?
Message-ID: <9f2054a93a6345dc02744e4014ad8690@nodns4.us>

I was about to reply to some other post on this list, when I
needed to look something up to be sure about it, and I looked in
my local OS (Slackware) documentation directory for the BIND 9
ARM.  It's there in what appears to be a format for the Sphinx
documentation builder, but no longer shipped in HTML nor PDF.
See doc/arm/ in the source code.

The README still says this:

"Documentation

The BIND 9 Administrator Reference Manual is included with the source
distribution, in DocBook XML, HTML, and PDF format, in the doc/arm
directory."

This no longer appears to be the case, going back several minor
versions.  I don't know exactly how far, but at least through the
9.16.11 release, which is what I had installed at the start of my
quest today.  (I have 9.16.15 now.)

I guess the Sphinx processing should be done prior to generating
the tarball, is that correct?

Said README also says for reporting bugs to use Gitlab, but without
a Gitlab account I did not readily see how to do this.  Are Gitlab
accounts for bug reports now?  Can you accept one from someone who
does not have a Gitlab account?  Does bugs at isc.org no longer work
for bug reporting?

From ondrej at isc.org  Sun May 16 19:59:39 2021
From: ondrej at isc.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Sun, 16 May 2021 21:59:39 +0200
Subject: BIND 9 ARM, html/pdf not in the source?
In-Reply-To: <9f2054a93a6345dc02744e4014ad8690@nodns4.us>
References: <9f2054a93a6345dc02744e4014ad8690@nodns4.us>
Message-ID: <0E23E162-A116-4C23-8E04-853662BC749F@isc.org>

Chuck,

yes, the generated documentation is no longer part of sources, but you can read the rst files used to generate documentation - those are just plain text files with little extra markup.

Also yes, you need ISC GitLab account to create new issues (unless it?s a security vulnerability then OpenPGP encrypted email is accepted). We need to interact with the reporters from the issue and we think this is a reasonable requirement.

The README.md has to be reviewed and fixed, but I guess you don?t need to fill the issue for this.

Ond?ej
--
Ond?ej Sur? ? ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 16. 5. 2021, at 21:50, Chuck Aurora <ca at nodns4.us> wrote:
> 
> ?I was about to reply to some other post on this list, when I
> needed to look something up to be sure about it, and I looked in
> my local OS (Slackware) documentation directory for the BIND 9
> ARM.  It's there in what appears to be a format for the Sphinx
> documentation builder, but no longer shipped in HTML nor PDF.
> See doc/arm/ in the source code.
> 
> The README still says this:
> 
> "Documentation
> 
> The BIND 9 Administrator Reference Manual is included with the source
> distribution, in DocBook XML, HTML, and PDF format, in the doc/arm
> directory."
> 
> This no longer appears to be the case, going back several minor
> versions.  I don't know exactly how far, but at least through the
> 9.16.11 release, which is what I had installed at the start of my
> quest today.  (I have 9.16.15 now.)
> 
> I guess the Sphinx processing should be done prior to generating
> the tarball, is that correct?
> 
> Said README also says for reporting bugs to use Gitlab, but without
> a Gitlab account I did not readily see how to do this.  Are Gitlab
> accounts for bug reports now?  Can you accept one from someone who
> does not have a Gitlab account?  Does bugs at isc.org no longer work
> for bug reporting?
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


From ca at nodns4.us  Sun May 16 20:20:06 2021
From: ca at nodns4.us (Chuck Aurora)
Date: Sun, 16 May 2021 15:20:06 -0500
Subject: BIND 9 ARM, html/pdf not in the source?
In-Reply-To: <0E23E162-A116-4C23-8E04-853662BC749F@isc.org>
References: <9f2054a93a6345dc02744e4014ad8690@nodns4.us>
 <0E23E162-A116-4C23-8E04-853662BC749F@isc.org>
Message-ID: <20eb944fc07f425f1c07774ced70a094@nodns4.us>

On 2021-05-16 14:59, Ond?ej Sur? wrote:
> yes, the generated documentation is no longer part of sources, but you
> can read the rst files used to generate documentation - those are just
> plain text files with little extra markup.

Yes, I saw that.  But the HTML markup is super nice to go to
hyperlinked settings and related documentation sections.  Will
the HTML documentation no longer be available at all, other
than to access it online?

(I'm currently in a bandwidth-limited ISP, so I try to limit
such things.  Fiber is ordered and coming soon!  Yay!  Those
of you who know me and where I live will understand how cool
and amazing this is. :) )

(But even with fiber and unlimited high speed connections, I
like having documentation on my trusty old laptop.)

> Also yes, you need ISC GitLab account to create new issues (unless
> it?s a security vulnerability then OpenPGP encrypted email is
> accepted). We need to interact with the reporters from the issue and
> we think this is a reasonable requirement.

FWIW I do not agree.  I don't get why a free software project
would shut out input from non-users of a third-party service.
Email works since forever.  But then, you're not shutting out
input, as we did settle this through the mailing list. :)

> The README.md has to be reviewed and fixed, but I guess you don?t need
> to fill the issue for this.

Thank you for the reply, Ond?ej, much appreciated.

>> On 16. 5. 2021, at 21:50, Chuck Aurora <ca at nodns4.us> wrote:
... and sorry, I missed a word here:

>> Said README also says for reporting bugs to use Gitlab, but without
>> a Gitlab account I did not readily see how to do this.  Are Gitlab
>> accounts for bug reports now?  Can you accept one from someone who
            ^ required
>> does not have a Gitlab account?  Does bugs at isc.org no longer work
>> for bug reporting?

From ca at nodns4.us  Sun May 16 21:05:55 2021
From: ca at nodns4.us (Chuck Aurora)
Date: Sun, 16 May 2021 16:05:55 -0500
Subject: Update DNSSEC Zone
In-Reply-To: <380CD3A4-3E49-48DB-8F61-05F906509EE8@gmail.com>
References: <FB381F46-C18C-4640-AF24-281B53D2F20D@gmail.com>
 <4b9cd684d1fa4ca395c7806da90726ce@mail.rrcic.com>
 <380CD3A4-3E49-48DB-8F61-05F906509EE8@gmail.com>
Message-ID: <910d8e948597afa8a70590dd418be669@nodns4.us>

On 2021-05-13 09:41, Software Info wrote:
> Wow. Thanks so much for all the responses. Really appreciate it. They
> made me truly realize that a lot on the info on the net may be either
> incomplete or just old. I understand a bit better now.
> I added the line inline-signing yes;

inline-signing is not required; you already had "update-policy local;"
which gives you a key to use with nsupdate(8)'s -l option.  This is
a perfectly valid way to maintain zone data, and in my opinion much
better than editing zone files and inline-signing.  You have taken a
step backwards.

This has the overview of both DNSSEC and dynamic zones:

http://ftp.isc.org/isc/bind/cur/9.16/doc/arm/html/advanced.html

See section "5.2. Dynamic Update".  Also see the "auto-dnssec
maintain;" option described there.  With a dynamic zone and
nsupdate, inline-signing is completely unnecessary.

For those who insist on editing zone files rather than learning how
to use nsupdate, I still recommend "update-policy local;" see Tony
Finch's post where he mentions his nsdiff tool.

> as was suggested and reloaded
> bind. I am now seeing the .signed, .jbk and .jnl files. The zone also
> replicates to the slaves and I am seeing the NSEC, RRSIG and DNSKEY
> entries in the zone files on the slaves. I also checked with the
> yogaDNS client and it had no problems identifying the DNSSEC server.
> So I would imagine at this point it is working. I believe as was said
> too I need now to register the DS with the registrar? Hopefully that
> should be it if I am not missing anything?

Yes, submitting the DS to the registrar is always the last step to
take in signing.  It's best to be sure the signing is being done
before you tell the world to accept only signed data from your zone.
We see that a lot, BTW. :)

> Thanks so much again for the very informative replies.

And a highly opinionated one? :)

I'd also recommend the DNSSEC guide,

https://bind9.readthedocs.io/en/latest/dnssec-guide.html

This is all on one page; or, the same document broken down in
sections can be seen here:

http://dnsinstitute.com/documentation/dnssec-guide/dnssec-guide.html

From ondrej at isc.org  Sun May 16 21:45:06 2021
From: ondrej at isc.org (=?utf-8?B?T25kxZllaiBTdXLDvQ==?=)
Date: Sun, 16 May 2021 23:45:06 +0200
Subject: BIND 9 ARM, html/pdf not in the source?
In-Reply-To: <20eb944fc07f425f1c07774ced70a094@nodns4.us>
References: <9f2054a93a6345dc02744e4014ad8690@nodns4.us>
 <0E23E162-A116-4C23-8E04-853662BC749F@isc.org>
 <20eb944fc07f425f1c07774ced70a094@nodns4.us>
Message-ID: <1D7CF02F-71DB-4972-A983-B23F29F37BE5@isc.org>

> On 16. 5. 2021, at 22:20, Chuck Aurora <ca at nodns4.us> wrote:
> 
> Yes, I saw that.  But the HTML markup is super nice to go to
> hyperlinked settings and related documentation sections.  Will
> the HTML documentation no longer be available at all, other
> than to access it online?

1. install sphinx-build (pip(3) install sphinx sphinx-rtd-theme)
2. make html
3. (xdg-)open doc/arm/_build/html/index.html

or just download it from:

https://bind9.readthedocs.io/_/downloads/en/v9_16_15/pdf/
https://bind9.readthedocs.io/_/downloads/en/v9_16_15/htmlzip/
https://bind9.readthedocs.io/_/downloads/en/v9_16_15/epub/

> I don't get why a free software project
> would shut out input from non-users of a third-party service.

Umm, what? The ISC GitLab is run by ISC. All the data is handled
by ISC.

But even if it wasn?t - it?s about choices where to invest the time.
Do you want us rather improving the code because we can focus
or rather the development team should invest the time to scan
multiple sources for incoming issues? I think that the rational choice
here is obvious.

I can chit-chat here as much as I like because it?s Sunday and I was
waiting for the vaccination registration to be open for my age group,
but as long as I am fully in the work mode, I need a single source of
truth for all the issues, all the merge requests, so I don?t spend much
time on searching ?where the heck the information was? because it?s
all in the one place. I don?t think it?s too much to ask a little bit of
inconvenience from the users, so we can actually focus on fixing
bugs and improving the software.

Ondrej
--
Ond?ej Sur? (He/Him)
ondrej at isc.org


From dominiks.mail at gmx.net  Mon May 17 07:13:59 2021
From: dominiks.mail at gmx.net (Dominik)
Date: Mon, 17 May 2021 09:13:59 +0200
Subject: Bind9 version 9.17.12 not starting without different DNS server
Message-ID: <006ea79c-51a2-7fe4-2f2a-7ae9993978a2@gmx.net>

Hello,

yesterday I tried version 9.17.12 because of the new TLS features.
My resolv.conf only contains the local resolver 127.0.0.1 and ::1.

The problem is that the new Bind9 doesn't start without having an
alternative resolver in resolv.conf. It looks like something in the
Bind9 startup process relies on DNS before itself is serving queries.

The last message in the logfile is:

named[14264]: managed-keys-zone: Failed to create fetch for DNSKEY update

After that the Bind9 process is running but doesn't answer queries.

Thanks for any help.

--
Regards

Dominik



The named.conf looks like this:
tls mytls {
    cert-file "/etc/ssl/example.crt";
    key-file "/etc/ssl/example.key";
};

options {
    directory "/usr/local/bind9/var/cache";
    querylog no;
    auth-nxdomain no;
    dnssec-validation auto;
    minimal-responses no-auth-recursive;
    listen-on port 53 { any; };
    listen-on-v6 { ::1; };
    listen-on port 853 tls mytls { any; };
    allow-transfer { none; };
    allow-recursion { 127.0.0.1; ::1; };
    recursion yes;
};

logging {
    category lame-servers { null; };
};

// prime the server with knowledge of the root servers
zone "." {
    type hint;
    file "/usr/local/bind9/etc/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
    type master;
    file "/usr/local/bind9/etc/db.local";
};

zone "127.in-addr.arpa" {
    type master;
    file "/usr/local/bind9/etc/db.127";
};

zone "0.in-addr.arpa" {
    type master;
    file "/usr/local/bind9/etc/db.0";
};

zone "255.in-addr.arpa" {
    type master;
    file "/usr/local/bind9/etc/db.255";
};

From ondrej at isc.org  Mon May 17 07:52:43 2021
From: ondrej at isc.org (=?utf-8?B?T25kxZllaiBTdXLDvQ==?=)
Date: Mon, 17 May 2021 09:52:43 +0200
Subject: Bind9 version 9.17.12 not starting without different DNS server
In-Reply-To: <006ea79c-51a2-7fe4-2f2a-7ae9993978a2@gmx.net>
References: <006ea79c-51a2-7fe4-2f2a-7ae9993978a2@gmx.net>
Message-ID: <FF875D33-E71D-4B87-AE75-DBCF4DDE9825@isc.org>

Dominik,

please create issue in our GitLab (https://gitlab.isc.org/) and include
full logs (preferably run named with `-d 99` to get most diagnostic
output).

Thanks,
--
Ond?ej Sur? (He/Him)
ondrej at isc.org

> On 17. 5. 2021, at 9:13, Dominik <dominiks.mail at gmx.net> wrote:
> 
> Hello,
> 
> yesterday I tried version 9.17.12 because of the new TLS features.
> My resolv.conf only contains the local resolver 127.0.0.1 and ::1.
> 
> The problem is that the new Bind9 doesn't start without having an
> alternative resolver in resolv.conf. It looks like something in the
> Bind9 startup process relies on DNS before itself is serving queries.
> 
> The last message in the logfile is:
> 
> named[14264]: managed-keys-zone: Failed to create fetch for DNSKEY update
> 
> After that the Bind9 process is running but doesn't answer queries.
> 
> Thanks for any help.
> 
> --
> Regards
> 
> Dominik
> 
> 
> 
> The named.conf looks like this:
> tls mytls {
>   cert-file "/etc/ssl/example.crt";
>   key-file "/etc/ssl/example.key";
> };
> 
> options {
>   directory "/usr/local/bind9/var/cache";
>   querylog no;
>   auth-nxdomain no;
>   dnssec-validation auto;
>   minimal-responses no-auth-recursive;
>   listen-on port 53 { any; };
>   listen-on-v6 { ::1; };
>   listen-on port 853 tls mytls { any; };
>   allow-transfer { none; };
>   allow-recursion { 127.0.0.1; ::1; };
>   recursion yes;
> };
> 
> logging {
>   category lame-servers { null; };
> };
> 
> // prime the server with knowledge of the root servers
> zone "." {
>   type hint;
>   file "/usr/local/bind9/etc/db.root";
> };
> 
> // be authoritative for the localhost forward and reverse zones, and for
> // broadcast zones as per RFC 1912
> zone "localhost" {
>   type master;
>   file "/usr/local/bind9/etc/db.local";
> };
> 
> zone "127.in-addr.arpa" {
>   type master;
>   file "/usr/local/bind9/etc/db.127";
> };
> 
> zone "0.in-addr.arpa" {
>   type master;
>   file "/usr/local/bind9/etc/db.0";
> };
> 
> zone "255.in-addr.arpa" {
>   type master;
>   file "/usr/local/bind9/etc/db.255";
> };
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


From bind at jubileegroup.co.uk  Mon May 17 10:23:09 2021
From: bind at jubileegroup.co.uk (G.W. Haywood)
Date: Mon, 17 May 2021 11:23:09 +0100 (BST)
Subject: BIND 9 ARM, html/pdf not in the source?
Message-ID: <alpine.DEB.2.21.2105170933140.25570@piplus.local.jubileegroup.co.uk>

Hi there,

On Sun, 16 May 2021, Ond?ej Sur? wrote:
> On Sun, 16 May 2021, Chuck Aurora wrote:
> > On Sun, 16 May 2021, Ond?ej Sur? wrote:
> > 
> > > ... yes, you need ISC GitLab account to create new issues (unless
> > > it's a security vulnerability then OpenPGP encrypted email is
> > > accepted). We need to interact with the reporters from the issue and
> > > we think this is a reasonable requirement.
> > 
> > FWIW I do not agree.
> 
> ... I don't think it's too much to ask a little bit of inconvenience
> from the users, so we can actually focus on fixing bugs and
> improving the software.

I feel strongly that I should chime in with my experiences of trying
to use Git/Web interfaces to report issues.  Not, I hasten to add,
issues with BIND - I don't recall ever trying to use ISC's GitLab and
I'd have no particular issues with creating an account except that I'd
try to make sure that it could never be linked to me by criminals when
it's almost inevitably compromised.

I don't want this to sound like an attempt to pour fuel onto the flames
but insisting on Git/HTTP is not just "a little bit of inconvenience".

After finding it necessary to download tens of megabytes of source to
make a ten character change to the code, and finding that the little
'Commit' button that you have to press to the pull request would not
come out of its greyed-out state no matter what I do, and on enquiry
after some hours of digging being told that I need to use a different
browser (I use Palemoon; one suggestion was Firefox), I've now reached
the point that if it says 'http' and 'git' I will look for the little
'X' in the tab near the top of my browser window.  Call me a dinosaur
if you like but after wasting much time on it, I flatly refuse to even
try to use a Git/Web interface any more.  If I expected to use it all
day every day things might be different, but for chipping in a minor
report or small improvement the bars to entry seem to be set too high.
If I found a mistake in the ARM I'd cheerfully send an email, but I'd
never even consider navigating through a GitLab maze to do the same
thing and I'd just keep quiet about it.

There is an email interface for GitLab.  It requires no account to be
created by the user.  You get to keep the single repository of wisdom.

https://docs.gitlab.com/ee/user/project/service_desk.html

Would it be too onerous for the ISC to make this available?

-- 

73,
Ged.

From ondrej at isc.org  Mon May 17 11:41:40 2021
From: ondrej at isc.org (=?utf-8?B?T25kxZllaiBTdXLDvQ==?=)
Date: Mon, 17 May 2021 13:41:40 +0200
Subject: BIND 9 ARM, html/pdf not in the source?
In-Reply-To: <alpine.DEB.2.21.2105170933140.25570@piplus.local.jubileegroup.co.uk>
References: <alpine.DEB.2.21.2105170933140.25570@piplus.local.jubileegroup.co.uk>
Message-ID: <9D5A7211-6297-4D11-8820-7A1552AAB806@isc.org>

Hi,

I am sorry, but what?  I would suggest to actually try the interface
before you write angry emails. There?s nothing of sorts as you
describe. The only hassle is that before forking, you need to ask
ISC to actually allow your user account to create forks.

There?s no requirement to use anything like ?Git/Web?, I don?t even
know what you exactly mean by that.

Also for this

> After finding it necessary to download tens of megabytes of source

$ git clone --depth=1 https://gitlab.isc.org/isc-projects/bind9.git
Cloning into 'bind9'...
remote: Enumerating objects: 4755, done.
remote: Counting objects: 100% (4755/4755), done.
remote: Compressing objects: 100% (3558/3558), done.
remote: Total 4755 (delta 2009), reused 2211 (delta 865), pack-reused 0
Receiving objects: 100% (4755/4755), 6.81 MiB | 4.29 MiB/s, done.
Resolving deltas: 100% (2009/2009), done.

It?s less then 7MB when you use proper `git clone` options (and probably even less
on the wire as the compression is used transparently).

> I flatly refuse to even try to use a Git/Web interface any more.


So, here?s my blunt question - do you have any experience using ISC GitLab?

> Would it be too onerous for the ISC to make this available?


Well, unless the goal is to keep us busy with handling all the incoming spam?

Again, I don?t think that the creating user account is such high-entry barrier
that it would require shifting the costs from the reported to the already too-busy
open-source developers.

Ondrej
--
Ond?ej Sur? (He/Him)
ondrej at isc.org

> On 17. 5. 2021, at 12:23, G.W. Haywood via bind-users <bind-users at lists.isc.org> wrote:
> 
> Hi there,
> 
> On Sun, 16 May 2021, Ond?ej Sur? wrote:
>> On Sun, 16 May 2021, Chuck Aurora wrote:
>> > On Sun, 16 May 2021, Ond?ej Sur? wrote:
>> > > > ... yes, you need ISC GitLab account to create new issues (unless
>> > > it's a security vulnerability then OpenPGP encrypted email is
>> > > accepted). We need to interact with the reporters from the issue and
>> > > we think this is a reasonable requirement.
>> > > FWIW I do not agree.
>> ... I don't think it's too much to ask a little bit of inconvenience
>> from the users, so we can actually focus on fixing bugs and
>> improving the software.
> 
> I feel strongly that I should chime in with my experiences of trying
> to use Git/Web interfaces to report issues.  Not, I hasten to add,
> issues with BIND - I don't recall ever trying to use ISC's GitLab and
> I'd have no particular issues with creating an account except that I'd
> try to make sure that it could never be linked to me by criminals when
> it's almost inevitably compromised.
> 
> I don't want this to sound like an attempt to pour fuel onto the flames
> but insisting on Git/HTTP is not just "a little bit of inconvenience".
> 
> After finding it necessary to download tens of megabytes of source to
> make a ten character change to the code, and finding that the little
> 'Commit' button that you have to press to the pull request would not
> come out of its greyed-out state no matter what I do, and on enquiry
> after some hours of digging being told that I need to use a different
> browser (I use Palemoon; one suggestion was Firefox), I've now reached
> the point that if it says 'http' and 'git' I will look for the little
> 'X' in the tab near the top of my browser window.  Call me a dinosaur
> if you like but after wasting much time on it, I flatly refuse to even
> try to use a Git/Web interface any more.  If I expected to use it all
> day every day things might be different, but for chipping in a minor
> report or small improvement the bars to entry seem to be set too high.
> If I found a mistake in the ARM I'd cheerfully send an email, but I'd
> never even consider navigating through a GitLab maze to do the same
> thing and I'd just keep quiet about it.
> 
> There is an email interface for GitLab.  It requires no account to be
> created by the user.  You get to keep the single repository of wisdom.
> 
> https://docs.gitlab.com/ee/user/project/service_desk.html
> 
> Would it be too onerous for the ISC to make this available?
> 
> -- 
> 
> 73,
> Ged.
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


From ondrej at isc.org  Mon May 17 13:41:23 2021
From: ondrej at isc.org (=?utf-8?B?T25kxZllaiBTdXLDvQ==?=)
Date: Mon, 17 May 2021 15:41:23 +0200
Subject: BIND 9 ARM, html/pdf not in the source?
In-Reply-To: <alpine.DEB.2.21.2105171327400.25570@piplus.local.jubileegroup.co.uk>
References: <alpine.DEB.2.21.2105170933140.25570@piplus.local.jubileegroup.co.uk>
 <9D5A7211-6297-4D11-8820-7A1552AAB806@isc.org>
 <alpine.DEB.2.21.2105171327400.25570@piplus.local.jubileegroup.co.uk>
Message-ID: <64821334-446E-4176-93D4-75491AF09659@isc.org>

> On 17. 5. 2021, at 15:10, G.W. Haywood <ged at jubileegroup.co.uk> wrote:
> 
> a simple unified diff and sending a patch by email

Here?s what happens when you do that:

1. somebody has to download your patch locally
2. somebody needs to triage the patch (and the issue) and if the description isn?t up-to-par write back to you
3. this might continue for a while ending up with multiple patches in multiple emails
4. somebody has to create a git branch out of the patch
5a. the patch might not apply because the branch could have been modified meanwhile, so back to 2) or
5b. the developer will have to spend a time fixing the patch themselves.
6. then there might be additional questions that goes between you and the reporter
7. oh no, the developer went to PTO for next two weeks and everything is stalled because there?s no record of the communication

So, when you say ?simple unified diff? it means a huge pile of additional work with the record of any changes and communications being inaccessible to other team members (or it will have to be posted publicly creating clutter in the mailing list). So, what?s simple for you will burn time for multiple people that could be spent on fixing stuff.

On the contrary:

* A good descriptive bug report in the GitLab issue helps
* Merge requests that follows the coding standard, has a good commit message and good description and is based on the current `main` branch helps?

So, is it really that much to ask?

Ondrej
--
Ond?ej Sur? (He/Him)
ondrej at isc.org


From jm5903 at att.com  Mon May 17 15:42:39 2021
From: jm5903 at att.com (MURTARI, JOHN)
Date: Mon, 17 May 2021 15:42:39 +0000
Subject: Using Ansible to manage bind installation/basic setup.
Message-ID: <5131805bb656441582bf234ac6c70ac0@att.com>

Folks,


Thinking of using Ansible to help with standardized bind installations & auto setup.  Searched the list Archives/ISC website and didn't see much.   Found a variety of Ansible roles/playbooks on Google, but nothing seemed to be the clear preferred favorite?    Any recommendations are welcome.    Does ISC have/plan on having some modules for Ansible?


Limited goals right now while we gain experience:

1) Ability to manage named.conf - confirm standard setups except for site-specific options.

2)  Ability to stop/start/reload named.

3)  Nothing special installed on remote servers, use just ssh for access. Works across RHEL, CENTOS, & UBUNTU.


Thanks!
John


-------------------------------

John Murtari

Orion Inc.

office: 315-944-0998

cell: 315-430-2702
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210517/ba9f7a20/attachment.htm>

From list at mens.de  Tue May 18 17:29:51 2021
From: list at mens.de (Jan-Piet Mens)
Date: Tue, 18 May 2021 19:29:51 +0200
Subject: Using Ansible to manage bind installation/basic setup.
In-Reply-To: <5131805bb656441582bf234ac6c70ac0@att.com>
References: <5131805bb656441582bf234ac6c70ac0@att.com>
Message-ID: <YKP5j4Nx3lA13q3j@rabbit.ww.mens.de>

Ansible's template module is what you'd probably use for #1, the service 
module (with handlers) for #2, and #3 comes out of the box when you use 
Ansible.

While you might find existing roles and playbooks on the internets, I 
would strongly recommend to vet them carefully in a test environment 
before using them in production; just because something works for me 
doesn't mean it will satisfy you. :)

Good luck,

	-JP

From jm5903 at att.com  Wed May 19 11:40:04 2021
From: jm5903 at att.com (MURTARI, JOHN)
Date: Wed, 19 May 2021 11:40:04 +0000
Subject: Using Ansible to manage bind installation/basic setup.
In-Reply-To: <YKP5j4Nx3lA13q3j@rabbit.ww.mens.de>
References: <5131805bb656441582bf234ac6c70ac0@att.com>,
 <YKP5j4Nx3lA13q3j@rabbit.ww.mens.de>
Message-ID: <58dc3463be0648c9afa00b32f7a2ad56@att.com>

> Ansible's template module is what you'd probably use for #1, the service  module (with handlers) for #2, and #3 comes out of the box when you use Ansible.

> While you might find existing roles and playbooks on the internets, I  would strongly recommend to vet them carefully in a test environment  before using them in production; just because something works for me  doesn't mean it will satisfy you. :)


Thanks for the recommendation.  I had found some existing playbook stuff, but confusing to understand.  Just using their basic support for templates was pretty easy.  Had some experience with Puppet in the past.  Ansible's use of simple SSH for access instead of requiring a remote client installed does make it a lot easier.


Best regards!
John


________________________________
From: bind-users <bind-users-bounces at lists.isc.org> on behalf of Jan-Piet Mens via bind-users <bind-users at lists.isc.org>
Sent: Tuesday, May 18, 2021 1:29:51 PM
To: bind-users at lists.isc.org
Subject: Re: Using Ansible to manage bind installation/basic setup.

Ansible's template module is what you'd probably use for #1, the service
module (with handlers) for #2, and #3 comes out of the box when you use
Ansible.

While you might find existing roles and playbooks on the internets, I
would strongly recommend to vet them carefully in a test environment
before using them in production; just because something works for me
doesn't mean it will satisfy you. :)

Good luck,

        -JP
_______________________________________________
Please visit https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/bind-users__;!!BhdT!2lED6vbUEHG2F8ocQh8Fn7IxVUx1x_4UeguTObEE64xI6g-6VYkphsl6O4BthDo$  to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://urldefense.com/v3/__https://www.isc.org/contact/__;!!BhdT!2lED6vbUEHG2F8ocQh8Fn7IxVUx1x_4UeguTObEE64xI6g-6VYkphsl69XQ71wc$  for more information.


bind-users mailing list
bind-users at lists.isc.org
https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/bind-users__;!!BhdT!2lED6vbUEHG2F8ocQh8Fn7IxVUx1x_4UeguTObEE64xI6g-6VYkphsl6O4BthDo$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210519/a88c1130/attachment.htm>

From mcnally at isc.org  Wed May 19 22:06:47 2021
From: mcnally at isc.org (Michael McNally)
Date: Wed, 19 May 2021 14:06:47 -0800
Subject: New BIND releases are available: 9.11.32, 9.16.16, and 9.17.13
Message-ID: <31050054-a733-fce2-12ad-7baa9261c5bb@isc.org>

The May 2021 maintenance releases of BIND are available and can be downloaded
from the ISC software download page, https://www.isc.org/download

A summary of changes in the new releases can be found in their release notes:

current supported stable branches:

   9.11.32 - https://downloads.isc.org/isc/bind9/9.11.32/RELEASE-NOTES-bind-9.11.32.html
   9.16.16  - https://downloads.isc.org/isc/bind9/9.16.16/RELEASE-NOTES-bind-9.16.16.html

experimental development branch:

   9.17.13  - https://downloads.isc.org/isc/bind9/9.17.13/RELEASE-NOTES-bind-9.17.13.html

Please note:

    The 9.17 experimental development branch is produced on a best-effort basis.
    In this particular set of releases, an issue in our build tools prevented
    the creation of the usual installer package for Windows users.  Rather than
    delay the release, we went ahead, with the consequence that there are no
    Windows zips provided for the 9.17 branch this month.

    Zip files with Windows packages were provided as usual for the 9.11 and
    9.16 branches.

Michael McNally
ISC Support

From tundra at tundraware.com  Thu May 20 13:30:00 2021
From: tundra at tundraware.com (Tim Daneliuk)
Date: Thu, 20 May 2021 08:30:00 -0500
Subject: Corrupted Slave Data?
Message-ID: <a77aa46c-14ce-3dbe-698b-3f9ab1d303a6@tundraware.com>

Running bind 9.16.15 on FreeBSD 11.4-STABLE.

Master is out on a cloud server at Digital Ocean.  Slave is on-premise.
All on-prem LANs point to the slave instance.

Running split horizon to keep nosey parkers out of our local DNS assignments.

Recently - and for no obvious reason - the on-prem instance stops resolving
properly.  The fix is to stop it, clear out the slave files, and restart.
Then it works for a few days and repeats its misbehavior.

The logs show nothing remarkable, at least at first look.

Is there a known slave file corruption problem?

Could someone kindly suggest things we could look into otherwise?

Many Thanks ...

From anandb at ripe.net  Thu May 20 13:43:02 2021
From: anandb at ripe.net (Anand Buddhdev)
Date: Thu, 20 May 2021 15:43:02 +0200
Subject: Corrupted Slave Data?
In-Reply-To: <a77aa46c-14ce-3dbe-698b-3f9ab1d303a6@tundraware.com>
References: <a77aa46c-14ce-3dbe-698b-3f9ab1d303a6@tundraware.com>
Message-ID: <7286a530-dfae-0a76-8925-1ba93c809770@ripe.net>

On 20/05/2021 15:30, Tim Daneliuk via bind-users wrote:

Hi Tim,

> Recently - and for no obvious reason - the on-prem instance stops resolving
> properly.  The fix is to stop it, clear out the slave files, and restart.
> Then it works for a few days and repeats its misbehavior.
> 
> The logs show nothing remarkable, at least at first look.
> 
> Is there a known slave file corruption problem?
> 
> Could someone kindly suggest things we could look into otherwise?

This is not a useful report at all. Your statement, "the on-prem
instance stops resolving properly", provides absolutely no useful
information about the failure. You haven't provided any configuration
details either. All you're saying is "I have a problem. Help!" We are
not mind-readers, and can't even begin to imagine what might be wrong.

If you provide more details about your configuration, and about what
kind of failure you're observing (dig queries and responses, for
example), then perhaps some people might be able to assist you.

Regards,
Anand

From anandb at ripe.net  Thu May 20 14:38:26 2021
From: anandb at ripe.net (Anand Buddhdev)
Date: Thu, 20 May 2021 16:38:26 +0200
Subject: New BIND releases are available: 9.11.32, 9.16.16, and 9.17.13
In-Reply-To: <31050054-a733-fce2-12ad-7baa9261c5bb@isc.org>
References: <31050054-a733-fce2-12ad-7baa9261c5bb@isc.org>
Message-ID: <c1b4e0e8-76a0-84ce-877a-99fe9f7510df@ripe.net>

On 20/05/2021 00:06, Michael McNally wrote:

Hi ISC people,

> RELEASE-NOTES-bind-9.16.16.html

I was just reading the release notes, and noticed:

"The default value of the max-ixfr-ratio option was changed to
unlimited, for better backwards compatibility in the stable release series."

Thank you for this. Just yesterday, I was looking at XFRs between BIND
9.16.15, and a downstream Knot DNS server, which kept getting AXFRs
instead of IXFRs. I was going to open an issue about this in GitLab.
However, upgrading to 9.16.16 restored the previous (expected) behaviour.

Regards,
Anand

From manishr78 at gmail.com  Thu May 20 15:22:08 2021
From: manishr78 at gmail.com (Manish Rane)
Date: Thu, 20 May 2021 20:52:08 +0530
Subject: New BIND releases are available: 9.11.32, 9.16.16, and 9.17.13
In-Reply-To: <c1b4e0e8-76a0-84ce-877a-99fe9f7510df@ripe.net>
References: <31050054-a733-fce2-12ad-7baa9261c5bb@isc.org>
 <c1b4e0e8-76a0-84ce-877a-99fe9f7510df@ripe.net>
Message-ID: <CA+z6RjFcRYt6u63q5xMa3OdqAnQsL8NAGi5HyqfCs5RCj3nY-w@mail.gmail.com>

Hi Team,

Are those new versions available in Linux distro packages?
--------------------------------------------------------------------------
Thanks and Regards,
Manish R


On Thu, May 20, 2021 at 8:08 PM Anand Buddhdev <anandb at ripe.net> wrote:

> On 20/05/2021 00:06, Michael McNally wrote:
>
> Hi ISC people,
>
> > RELEASE-NOTES-bind-9.16.16.html
>
> I was just reading the release notes, and noticed:
>
> "The default value of the max-ixfr-ratio option was changed to
> unlimited, for better backwards compatibility in the stable release
> series."
>
> Thank you for this. Just yesterday, I was looking at XFRs between BIND
> 9.16.15, and a downstream Knot DNS server, which kept getting AXFRs
> instead of IXFRs. I was going to open an issue about this in GitLab.
> However, upgrading to 9.16.16 restored the previous (expected) behaviour.
>
> Regards,
> Anand
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210520/2a8e11d9/attachment.htm>

From anandb at ripe.net  Thu May 20 15:44:47 2021
From: anandb at ripe.net (Anand Buddhdev)
Date: Thu, 20 May 2021 17:44:47 +0200
Subject: New BIND releases are available: 9.11.32, 9.16.16, and 9.17.13
In-Reply-To: <CA+z6RjFcRYt6u63q5xMa3OdqAnQsL8NAGi5HyqfCs5RCj3nY-w@mail.gmail.com>
References: <31050054-a733-fce2-12ad-7baa9261c5bb@isc.org>
 <c1b4e0e8-76a0-84ce-877a-99fe9f7510df@ripe.net>
 <CA+z6RjFcRYt6u63q5xMa3OdqAnQsL8NAGi5HyqfCs5RCj3nY-w@mail.gmail.com>
Message-ID: <a6953a4b-d008-8f11-e919-2b01a4c46901@ripe.net>

On 20/05/2021 17:22, Manish Rane wrote:

> Are those new versions available in Linux distro packages?

Bleeding-edge distros like Gentoo Linux will probably have packages
within a short time. If you use Homebrew on your system, you'll also
have the newest version soonish.

Most of the major distributions are conservative, and are unlikely to
have this new version in their base installation any time soon. However,
ISC creates packages of the newst versions for some of the more common
distros like Debian, Ubuntu, CentOS and Fedora. Check out this page for
more information:

https://www.isc.org/bind/

Regards,
Anand

From tundra at tundraware.com  Thu May 20 15:54:55 2021
From: tundra at tundraware.com (Tim Daneliuk)
Date: Thu, 20 May 2021 10:54:55 -0500
Subject: Corrupted Slave Data?
In-Reply-To: <7286a530-dfae-0a76-8925-1ba93c809770@ripe.net>
References: <a77aa46c-14ce-3dbe-698b-3f9ab1d303a6@tundraware.com>
 <7286a530-dfae-0a76-8925-1ba93c809770@ripe.net>
Message-ID: <65901074-bad1-ab02-2082-7860bf84d784@tundraware.com>

On 5/20/21 8:43 AM, Anand Buddhdev wrote:
> On 20/05/2021 15:30, Tim Daneliuk via bind-users wrote:
> 
> Hi Tim,
> 
>> Recently - and for no obvious reason - the on-prem instance stops resolving
>> properly.  The fix is to stop it, clear out the slave files, and restart.
>> Then it works for a few days and repeats its misbehavior.
>>
>> The logs show nothing remarkable, at least at first look.
>>
>> Is there a known slave file corruption problem?
>>
>> Could someone kindly suggest things we could look into otherwise?
> 
> This is not a useful report at all. Your statement, "the on-prem
> instance stops resolving properly", provides absolutely no useful
> information about the failure. You haven't provided any configuration
> details either. All you're saying is "I have a problem. Help!" We are
> not mind-readers, and can't even begin to imagine what might be wrong.
> 
> If you provide more details about your configuration, and about what
> kind of failure you're observing (dig queries and responses, for
> example), then perhaps some people might be able to assist you.
> 
> Regards,
> Anand


Fair enough.  Although I was just curious about known slave file corruption
issue, for now.   When this happens again, I will do digs and submit deets here.

Thanks

From klaus.darilion at nic.at  Thu May 20 16:08:06 2021
From: klaus.darilion at nic.at (Klaus Darilion)
Date: Thu, 20 May 2021 18:08:06 +0200
Subject: AW: New BIND releases are available: 9.11.32, 9.16.16, and 9.17.13
In-Reply-To: <c1b4e0e8-76a0-84ce-877a-99fe9f7510df@ripe.net>
References: <31050054-a733-fce2-12ad-7baa9261c5bb@isc.org>
 <c1b4e0e8-76a0-84ce-877a-99fe9f7510df@ripe.net>
Message-ID: <3E18C1A0C550C44DA156DA5DA8ECCC6AB67C6E7B@NICS-EXCH2.sbg.nic.at>

Nevertheless I think there is a bug. IIR the previous default was 100% (switch to AXFR if IXFR would be grater than AXFR) and we also saw plenty of AXFR although the IXFR difference was very small and far away from 100%

regards
Klaus

> -----Urspr?ngliche Nachricht-----
> Von: bind-users <bind-users-bounces at lists.isc.org> Im Auftrag von Anand
> Buddhdev
> Gesendet: Donnerstag, 20. Mai 2021 16:38
> An: bind-users at lists.isc.org
> Betreff: Re: New BIND releases are available: 9.11.32, 9.16.16, and 9.17.13
> 
> On 20/05/2021 00:06, Michael McNally wrote:
> 
> Hi ISC people,
> 
> > RELEASE-NOTES-bind-9.16.16.html
> 
> I was just reading the release notes, and noticed:
> 
> "The default value of the max-ixfr-ratio option was changed to
> unlimited, for better backwards compatibility in the stable release series."
> 
> Thank you for this. Just yesterday, I was looking at XFRs between BIND
> 9.16.15, and a downstream Knot DNS server, which kept getting AXFRs
> instead of IXFRs. I was going to open an issue about this in GitLab.
> However, upgrading to 9.16.16 restored the previous (expected) behaviour.
> 
> Regards,
> Anand
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
> 
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

From anandb at ripe.net  Thu May 20 16:15:36 2021
From: anandb at ripe.net (Anand Buddhdev)
Date: Thu, 20 May 2021 18:15:36 +0200
Subject: AW: New BIND releases are available: 9.11.32, 9.16.16, and 9.17.13
In-Reply-To: <3E18C1A0C550C44DA156DA5DA8ECCC6AB67C6E7B@NICS-EXCH2.sbg.nic.at>
References: <31050054-a733-fce2-12ad-7baa9261c5bb@isc.org>
 <c1b4e0e8-76a0-84ce-877a-99fe9f7510df@ripe.net>
 <3E18C1A0C550C44DA156DA5DA8ECCC6AB67C6E7B@NICS-EXCH2.sbg.nic.at>
Message-ID: <004d521e-63d2-b1e3-cc99-fae27f097121@ripe.net>

On 20/05/2021 18:08, Klaus Darilion wrote:

Hi Klaus,

> Nevertheless I think there is a bug. IIR the previous default was
> 100% (switch to AXFR if IXFR would be grater than AXFR) and we also saw
> plenty of AXFR although the IXFR difference was very small and far away
> from 100%

Yes, I agree. I noticed the same thing. This feature needs more logging
and testing before it can be enabled by default.

Regards,
Anand

From ondrej at isc.org  Thu May 20 16:18:21 2021
From: ondrej at isc.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Thu, 20 May 2021 18:18:21 +0200
Subject: New BIND releases are available: 9.11.32, 9.16.16, and 9.17.13
In-Reply-To: <004d521e-63d2-b1e3-cc99-fae27f097121@ripe.net>
References: <004d521e-63d2-b1e3-cc99-fae27f097121@ripe.net>
Message-ID: <1622F6CD-3912-4E30-A933-B16BBB389B77@isc.org>

Well, yes, that?s why the default was reverted. There?s a bug in the feature, and there?s already MR fixing it. Sorry for the inconvenience.

If anybody is willing to test the fix, I would be happy to point them towards the MR (and patch).

Ondrej
--
Ond?ej Sur? ? ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 20. 5. 2021, at 18:15, Anand Buddhdev <anandb at ripe.net> wrote:
> 
> ?On 20/05/2021 18:08, Klaus Darilion wrote:
> 
> Hi Klaus,
> 
>> Nevertheless I think there is a bug. IIR the previous default was
>> 100% (switch to AXFR if IXFR would be grater than AXFR) and we also saw
>> plenty of AXFR although the IXFR difference was very small and far away
>> from 100%
> 
> Yes, I agree. I noticed the same thing. This feature needs more logging
> and testing before it can be enabled by default.
> 
> Regards,
> Anand
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


From manishr78 at gmail.com  Thu May 20 17:08:01 2021
From: manishr78 at gmail.com (Manish Rane)
Date: Thu, 20 May 2021 22:38:01 +0530
Subject: New BIND releases are available: 9.11.32, 9.16.16, and 9.17.13
In-Reply-To: <a6953a4b-d008-8f11-e919-2b01a4c46901@ripe.net>
References: <31050054-a733-fce2-12ad-7baa9261c5bb@isc.org>
 <c1b4e0e8-76a0-84ce-877a-99fe9f7510df@ripe.net>
 <CA+z6RjFcRYt6u63q5xMa3OdqAnQsL8NAGi5HyqfCs5RCj3nY-w@mail.gmail.com>
 <a6953a4b-d008-8f11-e919-2b01a4c46901@ripe.net>
Message-ID: <CA+z6RjFgTxr840Q-FPO=K7e2cpnN686b7zBxzsLTsshBf6-AOQ@mail.gmail.com>

Thanks for the reply
--------------------------------------------------------------------------
Thanks and Regards,
Manish R


On Thu, May 20, 2021 at 9:15 PM Anand Buddhdev <anandb at ripe.net> wrote:

> On 20/05/2021 17:22, Manish Rane wrote:
>
> > Are those new versions available in Linux distro packages?
>
> Bleeding-edge distros like Gentoo Linux will probably have packages
> within a short time. If you use Homebrew on your system, you'll also
> have the newest version soonish.
>
> Most of the major distributions are conservative, and are unlikely to
> have this new version in their base installation any time soon. However,
> ISC creates packages of the newst versions for some of the more common
> distros like Debian, Ubuntu, CentOS and Fedora. Check out this page for
> more information:
>
> https://www.isc.org/bind/
>
> Regards,
> Anand
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210520/8d4f67bf/attachment.htm>

From john.thurston at alaska.gov  Thu May 20 21:34:18 2021
From: john.thurston at alaska.gov (John Thurston)
Date: Thu, 20 May 2021 13:34:18 -0800
Subject: Syslog with BIND on CentOS
Message-ID: <e149ab46-95e5-4b99-2fe1-c47c6cefb6ac@alaska.gov>

Many years ago, when we ran ISC BIND on Solaris, we created a logging 
channel to send the logged-queries to the local syslogd. We then had our 
local syslogd forward most of the traffic on to a central syslog server.

I just tried to re-implement something like that on CentOS, and thought 
I had it working . . until it was exposed to full production traffic 
load. The output to our central syslog server was truncated, and my 
local system log was filled with messages saying jourald was activating 
ratelimiting. !?

My subsequent read of the docs indicates that BIND on CentOS 7, while 
being told it is sending to 'syslogd', is sending to 'journald' which is 
handling all the messages and forwarding them on to 'syslogd'. I don't 
want journald handling my thousands of messages per second from BIND. I 
don't want that information in my journal logs. I just want it out in 
the central syslog server.

Is there some direct way to get the logging channel of BIND pointed 
directly into the local syslogd? (which would then apply its forwarding 
rules to get traffic to the central syslog server)

I thought about trying to rip jourald out entirely, and quickly decided 
that was a path to madness.

The only thing I can come up with is to activate dnstap, and have some 
other process absorbing the data and spewing it directly to the central 
syslogd.

-- 
--
Do things because you should, not just because you can.

John Thurston    907-465-8591
John.Thurston at alaska.gov
Department of Administration
State of Alaska

From anandb at ripe.net  Thu May 20 22:17:11 2021
From: anandb at ripe.net (Anand Buddhdev)
Date: Fri, 21 May 2021 00:17:11 +0200
Subject: Syslog with BIND on CentOS
In-Reply-To: <e149ab46-95e5-4b99-2fe1-c47c6cefb6ac@alaska.gov>
References: <e149ab46-95e5-4b99-2fe1-c47c6cefb6ac@alaska.gov>
Message-ID: <59efdfa7-7605-e757-7f2c-f1b8d1d0f235@ripe.net>

On 20/05/2021 23:34, John Thurston wrote:

Hi John,

> My subsequent read of the docs indicates that BIND on CentOS 7, while
> being told it is sending to 'syslogd', is sending to 'journald' which is
> handling all the messages and forwarding them on to 'syslogd'. I don't
> want journald handling my thousands of messages per second from BIND. I
> don't want that information in my journal logs. I just want it out in
> the central syslog server.

On CentOS, journald listens on the syslog socket, and intercepts ALL log
messages, and logs them into files that are either in a memory-based
tmpfs (the default), or to disk (if you configure journald that way).
After intercepting the log message, and saving it to the journal,
journald then forwards the message to rsyslog, which listens on a
different socket.

> Is there some direct way to get the logging channel of BIND pointed
> directly into the local syslogd? (which would then apply its forwarding
> rules to get traffic to the central syslog server)

As far as I know, BIND just calls the syslog functions, and so the log
messages will go to whatever is listening on the default syslog socket
(journald on CentOS). I don't think there's any way to point BIND to
rsyslog's socket.

> I thought about trying to rip jourald out entirely, and quickly decided
> that was a path to madness.

That is indeed the path to madness. On systemd-based servers, you can't
really do without journald.

> The only thing I can come up with is to activate dnstap, and have some
> other process absorbing the data and spewing it directly to the central
> syslogd.

You could also log directly to files (bypassing syslog), and then have
some process follow the files and send the logs to a remote server.

Regards,
Anand

From bind at iment.com  Thu May 20 22:55:02 2021
From: bind at iment.com (Paul Kosinski)
Date: Thu, 20 May 2021 18:55:02 -0400
Subject: Syslog with BIND on CentOS
In-Reply-To: <59efdfa7-7605-e757-7f2c-f1b8d1d0f235@ripe.net>
References: <e149ab46-95e5-4b99-2fe1-c47c6cefb6ac@alaska.gov>
 <59efdfa7-7605-e757-7f2c-f1b8d1d0f235@ripe.net>
Message-ID: <20210520185502.34017d8e@ime1.iment.local>

If you can have BIND log directly to a file, couldn't you use a FIFO (prwxrwxrwx) or Unix domain socket (srwxrwxrwx) and avoid the disk I/O by sending the log data directly to the forwarder? (E.g., Pulse Audio listens on a socket for audio data from an application, and sends it in real-time to the D/A hardware driver etc.)


On Fri, 21 May 2021 00:17:11 +0200
Anand Buddhdev <anandb at ripe.net> wrote:

> On 20/05/2021 23:34, John Thurston wrote:
> 
> Hi John,
> 
> > My subsequent read of the docs indicates that BIND on CentOS 7, while
> > being told it is sending to 'syslogd', is sending to 'journald' which is
> > handling all the messages and forwarding them on to 'syslogd'. I don't
> > want journald handling my thousands of messages per second from BIND. I
> > don't want that information in my journal logs. I just want it out in
> > the central syslog server.  
> 
> On CentOS, journald listens on the syslog socket, and intercepts ALL log
> messages, and logs them into files that are either in a memory-based
> tmpfs (the default), or to disk (if you configure journald that way).
> After intercepting the log message, and saving it to the journal,
> journald then forwards the message to rsyslog, which listens on a
> different socket.
> 
> > Is there some direct way to get the logging channel of BIND pointed
> > directly into the local syslogd? (which would then apply its forwarding
> > rules to get traffic to the central syslog server)  
> 
> As far as I know, BIND just calls the syslog functions, and so the log
> messages will go to whatever is listening on the default syslog socket
> (journald on CentOS). I don't think there's any way to point BIND to
> rsyslog's socket.
> 
> > I thought about trying to rip jourald out entirely, and quickly decided
> > that was a path to madness.  
> 
> That is indeed the path to madness. On systemd-based servers, you can't
> really do without journald.
> 
> > The only thing I can come up with is to activate dnstap, and have some
> > other process absorbing the data and spewing it directly to the central
> > syslogd.  
> 
> You could also log directly to files (bypassing syslog), and then have
> some process follow the files and send the logs to a remote server.
> 
> Regards,
> Anand


From jmoellers at suse.de  Fri May 21 05:31:51 2021
From: jmoellers at suse.de (Josef Moellers)
Date: Fri, 21 May 2021 07:31:51 +0200
Subject: New BIND releases are available: 9.11.32, 9.16.16, and 9.17.13
In-Reply-To: <CA+z6RjFcRYt6u63q5xMa3OdqAnQsL8NAGi5HyqfCs5RCj3nY-w@mail.gmail.com>
References: <31050054-a733-fce2-12ad-7baa9261c5bb@isc.org>
 <c1b4e0e8-76a0-84ce-877a-99fe9f7510df@ripe.net>
 <CA+z6RjFcRYt6u63q5xMa3OdqAnQsL8NAGi5HyqfCs5RCj3nY-w@mail.gmail.com>
Message-ID: <a9e93256-23a4-505f-4fcb-09d7a26e74a9@suse.de>

On 20.05.21 17:22, Manish Rane wrote:
> Hi Team,
> 
> Are those new versions available in Linux distro packages?

As Anand already wrote: our Enterprise releases won't have this atm,
unless you request it through the official channels.
OpenSUSE Tumbleweed will hopefully have in a few days.

Josef
> --------------------------------------------------------------------------
> Thanks and Regards,
> Manish R
> 
> 
> On Thu, May 20, 2021 at 8:08 PM Anand Buddhdev <anandb at ripe.net
> <mailto:anandb at ripe.net>> wrote:
> 
>     On 20/05/2021 00:06, Michael McNally wrote:
> 
>     Hi ISC people,
> 
>     > RELEASE-NOTES-bind-9.16.16.html
> 
>     I was just reading the release notes, and noticed:
> 
>     "The default value of the max-ixfr-ratio option was changed to
>     unlimited, for better backwards compatibility in the stable release
>     series."
> 
>     Thank you for this. Just yesterday, I was looking at XFRs between BIND
>     9.16.15, and a downstream Knot DNS server, which kept getting AXFRs
>     instead of IXFRs. I was going to open an issue about this in GitLab.
>     However, upgrading to 9.16.16 restored the previous (expected)
>     behaviour.
> 
>     Regards,
>     Anand
>     _______________________________________________
>     Please visit https://lists.isc.org/mailman/listinfo/bind-users
>     <https://lists.isc.org/mailman/listinfo/bind-users> to unsubscribe
>     from this list
> 
>     ISC funds the development of this software with paid support
>     subscriptions. Contact us at https://www.isc.org/contact/
>     <https://www.isc.org/contact/> for more information.
> 
> 
>     bind-users mailing list
>     bind-users at lists.isc.org <mailto:bind-users at lists.isc.org>
>     https://lists.isc.org/mailman/listinfo/bind-users
>     <https://lists.isc.org/mailman/listinfo/bind-users>
> 
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 


-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 N?rnberg
Germany

(HRB 36809, AG N?rnberg)
Gesch?ftsf?hrer: Felix Imend?rffer

From manishr78 at gmail.com  Fri May 21 06:04:53 2021
From: manishr78 at gmail.com (Manish Rane)
Date: Fri, 21 May 2021 11:34:53 +0530
Subject: New BIND releases are available: 9.11.32, 9.16.16, and 9.17.13
In-Reply-To: <a9e93256-23a4-505f-4fcb-09d7a26e74a9@suse.de>
References: <31050054-a733-fce2-12ad-7baa9261c5bb@isc.org>
 <c1b4e0e8-76a0-84ce-877a-99fe9f7510df@ripe.net>
 <CA+z6RjFcRYt6u63q5xMa3OdqAnQsL8NAGi5HyqfCs5RCj3nY-w@mail.gmail.com>
 <a9e93256-23a4-505f-4fcb-09d7a26e74a9@suse.de>
Message-ID: <CA+z6RjF9Xp-1hiRytA6Vc17_aNSQ=_sFkgVa6s959b6Of5TUFg@mail.gmail.com>

I already tried the official Repository on my existing Ubuntu 18.04 and it
worked perfectly.
--------------------------------------------------------------------------
Thanks and Regards,
Manish R


On Fri, May 21, 2021 at 11:02 AM Josef Moellers <jmoellers at suse.de> wrote:

> On 20.05.21 17:22, Manish Rane wrote:
> > Hi Team,
> >
> > Are those new versions available in Linux distro packages?
>
> As Anand already wrote: our Enterprise releases won't have this atm,
> unless you request it through the official channels.
> OpenSUSE Tumbleweed will hopefully have in a few days.
>
> Josef
> >
> --------------------------------------------------------------------------
> > Thanks and Regards,
> > Manish R
> >
> >
> > On Thu, May 20, 2021 at 8:08 PM Anand Buddhdev <anandb at ripe.net
> > <mailto:anandb at ripe.net>> wrote:
> >
> >     On 20/05/2021 00:06, Michael McNally wrote:
> >
> >     Hi ISC people,
> >
> >     > RELEASE-NOTES-bind-9.16.16.html
> >
> >     I was just reading the release notes, and noticed:
> >
> >     "The default value of the max-ixfr-ratio option was changed to
> >     unlimited, for better backwards compatibility in the stable release
> >     series."
> >
> >     Thank you for this. Just yesterday, I was looking at XFRs between
> BIND
> >     9.16.15, and a downstream Knot DNS server, which kept getting AXFRs
> >     instead of IXFRs. I was going to open an issue about this in GitLab.
> >     However, upgrading to 9.16.16 restored the previous (expected)
> >     behaviour.
> >
> >     Regards,
> >     Anand
> >     _______________________________________________
> >     Please visit https://lists.isc.org/mailman/listinfo/bind-users
> >     <https://lists.isc.org/mailman/listinfo/bind-users> to unsubscribe
> >     from this list
> >
> >     ISC funds the development of this software with paid support
> >     subscriptions. Contact us at https://www.isc.org/contact/
> >     <https://www.isc.org/contact/> for more information.
> >
> >
> >     bind-users mailing list
> >     bind-users at lists.isc.org <mailto:bind-users at lists.isc.org>
> >     https://lists.isc.org/mailman/listinfo/bind-users
> >     <https://lists.isc.org/mailman/listinfo/bind-users>
> >
> >
> > _______________________________________________
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> >
> > ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >
> >
> > bind-users mailing list
> > bind-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> >
>
>
> --
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5
> 90409 N?rnberg
> Germany
>
> (HRB 36809, AG N?rnberg)
> Gesch?ftsf?hrer: Felix Imend?rffer
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210521/5ac09224/attachment-0001.htm>

From pemensik at redhat.com  Fri May 21 10:44:36 2021
From: pemensik at redhat.com (=?UTF-8?B?UGV0ciBNZW7FocOtaw==?=)
Date: Fri, 21 May 2021 12:44:36 +0200
Subject: Syslog with BIND on CentOS
In-Reply-To: <e149ab46-95e5-4b99-2fe1-c47c6cefb6ac@alaska.gov>
References: <e149ab46-95e5-4b99-2fe1-c47c6cefb6ac@alaska.gov>
Message-ID: <468710a7-a006-b080-a9f0-e0f60470614a@redhat.com>

Hello John,

I think it should be possible to use chroot and have there custom socket
mapped directly to rsyslog.

bind-chroot should be available in CentOS, try running
named-chroot.service instead of named.service.

I have not tried it on real installation, but I guess it should be
easiest way to use arbitrary socket different than common one.

Regards,
Petr

On 5/20/21 11:34 PM, John Thurston wrote:
> Many years ago, when we ran ISC BIND on Solaris, we created a logging
> channel to send the logged-queries to the local syslogd. We then had our
> local syslogd forward most of the traffic on to a central syslog server.
> 
> I just tried to re-implement something like that on CentOS, and thought
> I had it working . . until it was exposed to full production traffic
> load. The output to our central syslog server was truncated, and my
> local system log was filled with messages saying jourald was activating
> ratelimiting. !?
> 
> My subsequent read of the docs indicates that BIND on CentOS 7, while
> being told it is sending to 'syslogd', is sending to 'journald' which is
> handling all the messages and forwarding them on to 'syslogd'. I don't
> want journald handling my thousands of messages per second from BIND. I
> don't want that information in my journal logs. I just want it out in
> the central syslog server.
> 
> Is there some direct way to get the logging channel of BIND pointed
> directly into the local syslogd? (which would then apply its forwarding
> rules to get traffic to the central syslog server)
> 
> I thought about trying to rip jourald out entirely, and quickly decided
> that was a path to madness.
> 
> The only thing I can come up with is to activate dnstap, and have some
> other process absorbing the data and spewing it directly to the central
> syslogd.
> 

-- 
Petr Men??k
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210521/6b483848/attachment.bin>

From john.thurston at alaska.gov  Fri May 21 18:39:05 2021
From: john.thurston at alaska.gov (John Thurston)
Date: Fri, 21 May 2021 10:39:05 -0800
Subject: Syslog with BIND on CentOS
In-Reply-To: <59efdfa7-7605-e757-7f2c-f1b8d1d0f235@ripe.net>
References: <e149ab46-95e5-4b99-2fe1-c47c6cefb6ac@alaska.gov>
 <59efdfa7-7605-e757-7f2c-f1b8d1d0f235@ripe.net>
Message-ID: <3f9cf7a5-5397-f61c-2891-19749adb2698@alaska.gov>


On 5/20/2021 2:17 PM, Anand Buddhdev wrote:
> You could also log directly to files (bypassing syslog), and then have
> some process follow the files and send the logs to a remote server.

This seems rather inefficient, but there are established and flexible 
tools to do just this.

Without changing the configuration of my named (which is currently 
logging to a local file), I can make rsyslogd consider that file an 
input source. Once in, the parsing and output modules can then work on it.

This relies on the input module "imfile", and the output module "omfwd"

https://rsyslog-doc.readthedocs.io/en/latest/configuration/modules/idx_input.html

imfile appears to follow log rotations cleanly. A limitation I see is 
everything is assigned the same syslog facility.priority values.

It remains to be seen if this process can keep up with the query volume.

Warning: When started for the first time, imfile will read the existing 
file and start forwarding. If the query log already contains 800MB of 
lines, those will all be read in and passed through the parser and 
output modules.

--
Do things because you should, not just because you can.

John Thurston    907-465-8591
John.Thurston at alaska.gov
Department of Administration
State of Alaska

From John.Stoffel at toshiba.com  Fri May 21 19:26:06 2021
From: John.Stoffel at toshiba.com (Stoffel, John (TAI))
Date: Fri, 21 May 2021 19:26:06 +0000
Subject: Using Ansible to manage bind installation/basic setup.
In-Reply-To: <58dc3463be0648c9afa00b32f7a2ad56@att.com>
References: <5131805bb656441582bf234ac6c70ac0@att.com>,
 <YKP5j4Nx3lA13q3j@rabbit.ww.mens.de>
 <58dc3463be0648c9afa00b32f7a2ad56@att.com>
Message-ID: <SJ0PR05MB7595001E74F10813763EBC7B93299@SJ0PR05MB7595.namprd05.prod.outlook.com>

I'm using the following role, but only for a very simple secondary setup.

   ansible-galaxy install bertvv.bind

It's not the fastest, and I'm sure my ansible-foo isn't the best, but it's working for me so far.

John


Sr. Storage Architect
TOSHIBA AMERICA, INC.
290 Donald Lynch Blvd - Suite 201
Marlborough, MA 01752
508-736-5499 (mobile)
E-Mail:  john.stoffel at toshiba.com<mailto:john.stoffel at toshiba.com>
Website: Service Now Self Service Portal<https://nassc.service-now.com/ess/navpage.do>

From: bind-users <bind-users-bounces at lists.isc.org> On Behalf Of MURTARI, JOHN
Sent: Wednesday, May 19, 2021 7:40 AM
To: bind-users at lists.isc.org
Subject: Re: Using Ansible to manage bind installation/basic setup.


> Ansible's template module is what you'd probably use for #1, the service  module (with handlers) for #2, and #3 comes out of the box when you use Ansible.

> While you might find existing roles and playbooks on the internets, I  would strongly recommend to vet them carefully in a test environment  before using them in production; just because something works for me  doesn't mean it will satisfy you. :)



Thanks for the recommendation.  I had found some existing playbook stuff, but confusing to understand.  Just using their basic support for templates was pretty easy.  Had some experience with Puppet in the past.  Ansible's use of simple SSH for access instead of requiring a remote client installed does make it a lot easier.



Best regards!
John



________________________________
From: bind-users <bind-users-bounces at lists.isc.org<mailto:bind-users-bounces at lists.isc.org>> on behalf of Jan-Piet Mens via bind-users <bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>>
Sent: Tuesday, May 18, 2021 1:29:51 PM
To: bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>
Subject: Re: Using Ansible to manage bind installation/basic setup.

Ansible's template module is what you'd probably use for #1, the service
module (with handlers) for #2, and #3 comes out of the box when you use
Ansible.

While you might find existing roles and playbooks on the internets, I
would strongly recommend to vet them carefully in a test environment
before using them in production; just because something works for me
doesn't mean it will satisfy you. :)

Good luck,

        -JP
_______________________________________________
Please visit https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/bind-users__;!!BhdT!2lED6vbUEHG2F8ocQh8Fn7IxVUx1x_4UeguTObEE64xI6g-6VYkphsl6O4BthDo$<https://urldefense.com/v3/__https:/lists.isc.org/mailman/listinfo/bind-users__;!!BhdT!2lED6vbUEHG2F8ocQh8Fn7IxVUx1x_4UeguTObEE64xI6g-6VYkphsl6O4BthDo$>  to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://urldefense.com/v3/__https://www.isc.org/contact/__;!!BhdT!2lED6vbUEHG2F8ocQh8Fn7IxVUx1x_4UeguTObEE64xI6g-6VYkphsl69XQ71wc$<https://urldefense.com/v3/__https:/www.isc.org/contact/__;!!BhdT!2lED6vbUEHG2F8ocQh8Fn7IxVUx1x_4UeguTObEE64xI6g-6VYkphsl69XQ71wc$>  for more information.


bind-users mailing list
bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>
https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/bind-users__;!!BhdT!2lED6vbUEHG2F8ocQh8Fn7IxVUx1x_4UeguTObEE64xI6g-6VYkphsl6O4BthDo$<https://urldefense.com/v3/__https:/lists.isc.org/mailman/listinfo/bind-users__;!!BhdT!2lED6vbUEHG2F8ocQh8Fn7IxVUx1x_4UeguTObEE64xI6g-6VYkphsl6O4BthDo$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210521/ae654c42/attachment-0001.htm>

From thomas.strike at gmail.com  Sun May 23 14:24:28 2021
From: thomas.strike at gmail.com (Thomas Strike)
Date: Sun, 23 May 2021 09:24:28 -0500
Subject: Bind9.16 zone SOA record issue.
Message-ID: <e858b3c6-fb82-3b30-3656-17cd4a875376@gmail.com>

I've been pounding my head over this issue all day with no results.

I am hosting Bind9.16 on a Ubuntu 20.04 server.

I have several zone records that report the same problem but I also have 
several zoned that are configured with this same template and run okay 
on the server. I've surfed the Internet for any clues and tried 
everything I can think of but cannot get rid of this problem.
I really would appreciate any help I can get.

ZONE FILE:
$ttl 3600
ORIGIN ancienttom.us.
@??????? IN???? SOA???? ancienttom.us. thomas\.strike.sleepyvalley.net. (
 ??????????????????????? 1588097734
 ??????????????????????? 1200
 ??????????????????????? 600
 ??????????????????????? 86400
 ??????????????????????? 3600 )
ancienttom.us.?????????????????????????????? 1H??????? IN 
NS????????????? ns1.Sleepyvalley.net.
ancienttom.us.?????????????????????????????? 1H??????? IN 
NS????????????? ns2.Sleepyvalley.net.
ancienttom.us.?????????????????????????????????? ??? ??? IN 
A?????????????????? 51.222.143.198
ns1.ancienttom.us.?????????????????????????????? ??? ? IN 
A?????????????????? 51.222.143.198
ns2.ancienttom.us.?????????????????????????????? ????? IN 
A?????????????????? 51.222.143.198
www.ancienttom.us.?????????????????????????????? ??? IN 
A?????????????????? 51.222.143.198
ftp.ancienttom.us.?????????????????????????????? ??? ?? IN 
A?????????????????? 51.222.143.198
mailadmin.ancienttom.us.????????????????????????? IN A?????????????????? 
51.222.143.198
ancienttom.us.?????????????????????????????? 1H??????? IN MX????????? 10 
mx.mydomain.com.
mail.ancienttom.us.??????????????????????????????????? IN 
A?????????????????? 66.96.163.96
smtp.ancienttom.us.?????????????????????????????????? IN 
A?????????????????? 66.96.163.96

When I run named-checkzone I get 'unknown RR type 'ancienttom.us.'

My named.log shows;
22-May-2021 23:57:05.819 zoneload: error: zone ancienttom.us/IN: has 0 
SOA records
22-May-2021 23:57:05.819 zoneload: error: zone ancienttom.us/IN: has no 
NS records
22-May-2021 23:57:05.819 zoneload: error: zone ancienttom.us/IN: not 
loaded due to errors.



From ondrej at isc.org  Sun May 23 14:27:52 2021
From: ondrej at isc.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Sun, 23 May 2021 16:27:52 +0200
Subject: Bind9.16 zone SOA record issue.
In-Reply-To: <e858b3c6-fb82-3b30-3656-17cd4a875376@gmail.com>
References: <e858b3c6-fb82-3b30-3656-17cd4a875376@gmail.com>
Message-ID: <0A927BB6-A250-4DA4-A9DE-06DBA1DBE675@isc.org>

$ORIGIN ancienttom.us.

?

--
Ond?ej Sur? ? ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 23. 5. 2021, at 16:24, Thomas Strike <thomas.strike at gmail.com> wrote:
> 
> ORIGIN ancienttom.us.


From stenc at s-carlsen.dk  Sun May 23 15:15:14 2021
From: stenc at s-carlsen.dk (Sten Carlsen)
Date: Sun, 23 May 2021 17:15:14 +0200
Subject: Bind9.16 zone SOA record issue.
In-Reply-To: <e858b3c6-fb82-3b30-3656-17cd4a875376@gmail.com>
References: <e858b3c6-fb82-3b30-3656-17cd4a875376@gmail.com>
Message-ID: <D4F904BE-157A-4B3E-97D9-572438A5437D@s-carlsen.dk>



> On 23 May 2021, at 16.24, Thomas Strike <thomas.strike at gmail.com> wrote:
> 
> ZONE FILE:
> $ttl 3600
> ORIGIN ancienttom.us <http://ancienttom.us/>.
> @        IN     SOA     ancienttom.us <http://ancienttom.us/>. thomas\.strike.sleepyvalley.net <http://strike.sleepyvalley.net/>. (

The "\" above is what I would suspect. I could be wrong.

>                         1588097734
>                         1200
>                         600
>                         86400
>                         3600 )

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210523/6b7cac67/attachment.htm>

From ondrej at isc.org  Sun May 23 15:27:35 2021
From: ondrej at isc.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Sun, 23 May 2021 17:27:35 +0200
Subject: Bind9.16 zone SOA record issue.
In-Reply-To: <D4F904BE-157A-4B3E-97D9-572438A5437D@s-carlsen.dk>
References: <D4F904BE-157A-4B3E-97D9-572438A5437D@s-carlsen.dk>
Message-ID: <AA929264-E16E-47BF-9AB5-4050FC97F748@isc.org>

Nope, that?s how you enter email to SOA with dot in user part as the first dot gets converted to @.

--
Ond?ej Sur? ? ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 23. 5. 2021, at 17:15, Sten Carlsen <stenc at s-carlsen.dk> wrote:
> 
> The "\" above is what I would suspect. I could be wrong.


From gtaylor at tnetconsulting.net  Sun May 23 16:48:03 2021
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sun, 23 May 2021 10:48:03 -0600
Subject: Bind9.16 zone SOA record issue.
In-Reply-To: <AA929264-E16E-47BF-9AB5-4050FC97F748@isc.org>
References: <D4F904BE-157A-4B3E-97D9-572438A5437D@s-carlsen.dk>
 <AA929264-E16E-47BF-9AB5-4050FC97F748@isc.org>
Message-ID: <9f42595e-3582-9460-2685-f25bc93a666a@spamtrap.tnetconsulting.net>

On 5/23/21 9:27 AM, Ond?ej Sur? wrote:
> Nope, that?s how you enter email to SOA with dot in user part as 
> the first dot gets converted to @.

#TodayIlearned

I agree with Ond?ej.  I think it's the missing $ in front of ORIGIN. 

Remember the $<bla> lines are directives to BIND and not zone data. 
ORIGIN without the leading $ would be zone data.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210523/b860d23c/attachment-0001.bin>

From ondrej at isc.org  Tue May 25 12:37:17 2021
From: ondrej at isc.org (=?utf-8?B?T25kxZllaiBTdXLDvQ==?=)
Date: Tue, 25 May 2021 14:37:17 +0200
Subject: BIND 9.16.17-snapshot - testers needed - recursive performance
Message-ID: <4546B744-6B45-4B59-85CB-B2145354F2A0@isc.org>

Hi,

we merged a change that substantially reduces a contention between threads
and improves the recursive performance in 9.16 branch quite significantly.

After the change, the 9.16 branch performance will surpass 9.11 performance
in both scenarios - authoritative (already the case, from the very beginning)
and recursive (since a version to be released in June).

Although, we are quite confident that the new code is correct, we would appreciate
if people running different work loads than ours to test the snapshot tarball available
from here:

https://users.isc.org/~ondrej/bind-9.16.17-pre.tar.xz

We would like to hear both success (it?s ok here in the mailing list) and failure stories
(please create GitLab issues).

Thanks,
Ondrej
--
Ond?ej Sur? (He/Him)
ondrej at isc.org


From bind at eckner.net  Tue May 25 14:44:38 2021
From: bind at eckner.net (Erich Eckner)
Date: Tue, 25 May 2021 16:44:38 +0200 (CEST)
Subject: BIND 9.16.17-snapshot - testers needed - recursive performance
In-Reply-To: <4546B744-6B45-4B59-85CB-B2145354F2A0@isc.org>
References: <4546B744-6B45-4B59-85CB-B2145354F2A0@isc.org>
Message-ID: <2a366516-7e8f-dcfb-ab99-763e989a8dcf@eckner.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, 25 May 2021, Ond?ej Sur? wrote:

> Hi,

Hi Ondrej,

>
> we merged a change that substantially reduces a contention between threads
> and improves the recursive performance in 9.16 branch quite significantly.
>
> After the change, the 9.16 branch performance will surpass 9.11 performance
> in both scenarios - authoritative (already the case, from the very beginning)
> and recursive (since a version to be released in June).
>
> Although, we are quite confident that the new code is correct, we would appreciate
> if people running different work loads than ours to test the snapshot tarball available
> from here:
>
> https://users.isc.org/~ondrej/bind-9.16.17-pre.tar.xz

I tried to pull the tarball from this url, but only got some gitlab page 
(which firefox refused to show, but insisted to download). Is this my 
error or did you accidentally push the wrong content?

>
> We would like to hear both success (it?s ok here in the mailing list) and failure stories
> (please create GitLab issues).
>
> Thanks,
> Ondrej

regards,
Erich

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

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmCtDVkACgkQCu7JB1Xa
e1orPA/+NjQN6Z7zhz2aI/XQkf7eK0s810hpuXN5zJiQG7OJwogr+SLOrW6VKLa/
UrfqXIoDU36kNKHQTWTjlOxi2Eh2l/c5W5qWv2I0ZQdLe4pU//5+i+Bxdv8o925r
d3nATQeYdi4sz8LZtzI0GTbyIRVCF7rQki1F5PGnk3XteT5zuZYNxTbkqv8/m+Lg
VX/bc5KmY5SVZBge4aNk+rI03v1+KMT5zVwVhlgTS3dpgCI7qhtWKyMN686nMfcN
0v/7mRa9qFHklBh7FTLpY5N/vW89NM40IYjehyoXc3QA/IzU7SqKbSPuJjB5tMkK
ct4UMX+P7ISAPu82w2vf/86UYdO/GiHWGeisG4322rdydDVh5vaa5jn/a6YVTl5h
SdfbqDTevG2n+/T3FOT1/hf4Ryb8WaG2gH4iqHiNeuiM1VNeR40cQZIe0euBVv4H
MomQHFQBHzHjP8HIFTkKs3XVX+LtsAIq5AvhXcYkGozPNLz0/+W/8LniV+jFgKzX
oR8sRlzNTFwmNHDhRd0AAZyw84ZvAam424DcNYuR1bP5nPXBGY0S1tktfQ7wJD4D
1oWyuu9bKz5wEHIx9GpenAoRfc0feL6LjwnRYc4q0t/hkfbEgOz/jpOEI1UVWfLq
O1yJPhSvoR8gW2PMMrNSxGqUtlJ7pbQPvRFPyC7sejBboAfjRQ0=
=GN6u
-----END PGP SIGNATURE-----

From ondrej at isc.org  Tue May 25 14:48:36 2021
From: ondrej at isc.org (=?utf-8?B?T25kxZllaiBTdXLDvQ==?=)
Date: Tue, 25 May 2021 16:48:36 +0200
Subject: BIND 9.16.17-snapshot - testers needed - recursive performance
In-Reply-To: <2a366516-7e8f-dcfb-ab99-763e989a8dcf@eckner.net>
References: <4546B744-6B45-4B59-85CB-B2145354F2A0@isc.org>
 <2a366516-7e8f-dcfb-ab99-763e989a8dcf@eckner.net>
Message-ID: <CE925E1D-7620-43C8-B3C0-3122817EFBA6@isc.org>

Hi Erich,

it was error on my side, it should be ok now.

Ondrej
--
Ond?ej Sur? (He/Him)
ondrej at isc.org

> On 25. 5. 2021, at 16:44, Erich Eckner <bind at eckner.net> wrote:
> 
> Signed PGP part
> On Tue, 25 May 2021, Ond?ej Sur? wrote:
> 
> > Hi,
> 
> Hi Ondrej,
> 
> >
> > we merged a change that substantially reduces a contention between threads
> > and improves the recursive performance in 9.16 branch quite significantly.
> >
> > After the change, the 9.16 branch performance will surpass 9.11 performance
> > in both scenarios - authoritative (already the case, from the very beginning)
> > and recursive (since a version to be released in June).
> >
> > Although, we are quite confident that the new code is correct, we would appreciate
> > if people running different work loads than ours to test the snapshot tarball available
> > from here:
> >
> > https://users.isc.org/~ondrej/bind-9.16.17-pre.tar.xz
> 
> I tried to pull the tarball from this url, but only got some gitlab page
> (which firefox refused to show, but insisted to download). Is this my
> error or did you accidentally push the wrong content?
> 
> >
> > We would like to hear both success (it?s ok here in the mailing list) and failure stories
> > (please create GitLab issues).
> >
> > Thanks,
> > Ondrej
> 
> regards,
> Erich
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210525/1f81ea9a/attachment.bin>

From petr at bena.rocks  Tue May 25 14:49:19 2021
From: petr at bena.rocks (Petr Bena)
Date: Tue, 25 May 2021 16:49:19 +0200
Subject: BIND 9.16.17-snapshot - testers needed - recursive performance
In-Reply-To: <2a366516-7e8f-dcfb-ab99-763e989a8dcf@eckner.net>
References: <4546B744-6B45-4B59-85CB-B2145354F2A0@isc.org>
 <2a366516-7e8f-dcfb-ab99-763e989a8dcf@eckner.net>
Message-ID: <63779bcb-3720-7d7c-48ed-2b78a8c78558@bena.rocks>

Hello,

It works just fine to me, so I guess it's a problem on your end? Try 
using wget instead of firefox, or different browser.

On 25/05/2021 16:44, Erich Eckner wrote:
> On Tue, 25 May 2021, Ond?ej Sur? wrote:
>
> > Hi,
>
> Hi Ondrej,
>
>
> > we merged a change that substantially reduces a contention between 
> threads
> > and improves the recursive performance in 9.16 branch quite 
> significantly.
>
> > After the change, the 9.16 branch performance will surpass 9.11 
> performance
> > in both scenarios - authoritative (already the case, from the very 
> beginning)
> > and recursive (since a version to be released in June).
>
> > Although, we are quite confident that the new code is correct, we 
> would appreciate
> > if people running different work loads than ours to test the 
> snapshot tarball available
> > from here:
>
> > https://users.isc.org/~ondrej/bind-9.16.17-pre.tar.xz
>
> I tried to pull the tarball from this url, but only got some gitlab 
> page (which firefox refused to show, but insisted to download). Is 
> this my error or did you accidentally push the wrong content?
>
>
> > We would like to hear both success (it?s ok here in the mailing 
> list) and failure stories
> > (please create GitLab issues).
>
> > Thanks,
> > Ondrej
>
> regards,
> Erich
>
 >
 > _______________________________________________
 > Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list
 >
 > ISC funds the development of this software with paid support 
subscriptions. Contact us at https://www.isc.org/contact/ for more 
information.
 >
 >
 > bind-users mailing list
 > bind-users at lists.isc.org
 > https://lists.isc.org/mailman/listinfo/bind-users


From carl at byington.org  Tue May 25 15:48:56 2021
From: carl at byington.org (Carl Byington)
Date: Tue, 25 May 2021 08:48:56 -0700
Subject: RHEL, Centos, Fedora rpm 9.16.16
In-Reply-To: <c7a6e34d8aefb7999cb578bc564d88cc708c7507.camel@byington.org>
References: <c7a6e34d8aefb7999cb578bc564d88cc708c7507.camel@byington.org>
Message-ID: <d6176a8071c626590347e4290f0cc5996190ca30.camel@byington.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

https://www.five-ten-sg.com/mapper/bind contains links to the source
rpm, and build instructions. This .src.rpm contains a .tar.gz file with
the ARM documentation, so the rpm rebuild process does not need sphinx-
build and associated dependencies.

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

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYK0cMxUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsHgOACdHD/vT82dCiVETeHyb7oyxxZ9LxYA
oIIUlyYU+9yuFtQKjNd0SKI1Ljej
=Tugz
-----END PGP SIGNATURE-----



From byteshifter at shifted-bytes.de  Wed May 26 07:29:12 2021
From: byteshifter at shifted-bytes.de (M.)
Date: Wed, 26 May 2021 09:29:12 +0200
Subject: troubleshooting slow queries?
Message-ID: <682046fb-cd55-d4ec-5290-3ce9ac8362de@shifted-bytes.de>

Hi!


Are there any best practices on troubleshooting slow queries?



From bind at jubileegroup.co.uk  Wed May 26 16:14:02 2021
From: bind at jubileegroup.co.uk (G.W. Haywood)
Date: Wed, 26 May 2021 17:14:02 +0100 (BST)
Subject: BIND 9.16.17-snapshot - testers needed - recursive performance
Message-ID: <alpine.DEB.2.21.2105261705310.672@piplus.local.jubileegroup.co.uk>

Hi there,

On Wed, 26 May 2021, He/Him wrote:

> we merged a change that substantially reduces a contention between threads
> and improves the recursive performance ...

We are currently running 9.11.26, and 9.11 has always built with no issues.
Debian 9.13 (Stretch).

$ aunpack bind-9.16.17-pre.tar.xz
$ cd bind-9.16.16	# NB bind-9.16.16 in the tarball, not bind-9.16.17
$ ./configure --prefix=/usr/local --sysconfdir=/etc --with-openssl
...
...
configure: error: The pkg-config script could not be found or is too old.
$

-- 

73,
Ged.

From sys.admin at xn--zhxu-cloud-c7ac.eu  Wed May 26 17:07:02 2021
From: sys.admin at xn--zhxu-cloud-c7ac.eu (=?utf-8?Q?Zh=C3=A9xu=C3=A9_M._=40SysAdmin?=)
Date: Wed, 26 May 2021 19:07:02 +0200
Subject: Problems with compiling BIND 9.17.10 or above ...
Message-ID: <ffc30345-949c-4baa-9a29-c97335cb6c16@Canary>


Dear Ladies and Gentlemen,

I wanted to update my BIND server to the current version 9.10.17 and keep getting stuck in the compile process.

First I compiled and installed the tool "NGHTTP/2" under "/user/local/nghttp2/1.43.0/".
But the "CONFIGURE" - process constantly brings me the error message "...error: libnghttp2 not found.

The path of the library is set correctly...

What else can I do? What is possibly going wrong here?

Best regards from Berlin

Matthias
-------------------------------------------------------------------------
The diversity of human dignity
"Jede Handlung, die mit gutem Willen und Wirksamkeit
ausgef?hrt wird, ist eine mystische Handlung"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210526/0b5b9d00/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210526/0b5b9d00/attachment.bin>

From kritek at gmail.com  Wed May 26 17:25:10 2021
From: kritek at gmail.com (Rick Dicaire)
Date: Wed, 26 May 2021 13:25:10 -0400
Subject: Problems with compiling BIND 9.17.10 or above ...
In-Reply-To: <ffc30345-949c-4baa-9a29-c97335cb6c16@Canary>
References: <ffc30345-949c-4baa-9a29-c97335cb6c16@Canary>
Message-ID: <CA+Cc--fKVD=1u0DyaTXXEXQwo2pE_d0N-od39Q-xamwZK0BffQ@mail.gmail.com>

On Wed, May 26, 2021 at 1:07 PM Zh?xu? M. @SysAdmin <
sys.admin at zh?xu?-cloud.eu> wrote:

> The path of the library is set correctly...
>

How are you setting it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210526/a5efbe06/attachment.htm>

From usenet at umbral.org.uk  Thu May 27 11:21:27 2021
From: usenet at umbral.org.uk (usenet at umbral.org.uk)
Date: Thu, 27 May 2021 12:21:27 +0100
Subject: TCP connections left in CLOSE_WAIT in 9.16.15/16
Message-ID: <CANo-oo7fhCkbBAZyYeb-2pLu-bVqcufjTNcBectX1B7_3-HHgw@mail.gmail.com>

Hello

We updated on Monday from bind-9.16.6/8 to bind-9.16.15/16 on some
public-facing authoritative nameservers.  Since then, we are seeing
a build-up of inbound TCP connections to port 53 being left in
CLOSE_WAIT state indefinitely until named is restarted, or exhausting
the tcp-clients limit if not restarted.  Anyone else seeing similar?

Platform is 64bit ArchLinux 5.12.6-arch1-1.

This sort of thing (netstat -tn):

tcp        1      0 194.83.56.250:53        40.113.98.76:13214
 CLOSE_WAIT
tcp        1      0 194.83.56.250:53        52.232.251.180:61357
 CLOSE_WAIT
tcp        1      0 194.83.56.250:53        137.116.220.118:11234
CLOSE_WAIT
tcp        1      0 194.83.56.250:53        23.100.54.67:17825
 CLOSE_WAIT
tcp        1      0 194.83.56.250:53        94.245.94.142:12397
CLOSE_WAIT
etc etc etc

On cursory examination, all of the querying IPs appear to be registered
to Microsoft, may imply Windows resolvers, querying for large TXT records
without EDNS, eg the first above:

May 27 10:06:50 ns12.ja.net named[156930]: client @0x7f7b08033908
40.113.98.76#50868 (gbmc.ac.uk): query: gbmc.ac.uk IN TXT - (194.83.56.250)

May 27 10:06:50 ns12.ja.net named[156930]: client @0x7f7b0895b348
40.113.98.76#13214 (gbmc.ac.uk): query: gbmc.ac.uk IN TXT -T (194.83.56.250)


Regards,
Ronan Flood
(resurrecting an old bind-users subbed address for this, if it works!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210527/984b0567/attachment.htm>

From bind at eckner.net  Thu May 27 12:35:01 2021
From: bind at eckner.net (Erich Eckner)
Date: Thu, 27 May 2021 14:35:01 +0200 (CEST)
Subject: BIND 9.16.17-snapshot - testers needed - recursive performance
In-Reply-To: <4546B744-6B45-4B59-85CB-B2145354F2A0@isc.org>
References: <4546B744-6B45-4B59-85CB-B2145354F2A0@isc.org>
Message-ID: <9aff4cba-d439-7039-3a62-851a60e4b18d@eckner.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

I switched to the 9.16.17 release candidate yesterday and so far, it runs 
well on my 6 very-low traffic dns servers (one of which is also 
authoritative).

Only thing, I noticed, is, that it uses more memory than 9.16.16 on the 
weakest of my servers (a 32-bit machine running archlinux32):

~14.8% -> ~20.4% (of 256MB total memory)

But this could also be due to different load - there is no real long-time 
monitor set up for this, and I simply took some values right before the 
change and have been monitoring the memory consumption since then.

I cannot really tell, whether the memory consumption is higher on the 
other machines, as those circle around or below 1% and there's too much 
noise down there :-D (but "10MB more ram needed" could well be possible, 
as these other machines all have >=2GB ram).

regards,
Erich

On Tue, 25 May 2021, Ond?ej Sur? wrote:

> Hi,
>
> we merged a change that substantially reduces a contention between threads
> and improves the recursive performance in 9.16 branch quite significantly.
>
> After the change, the 9.16 branch performance will surpass 9.11 performance
> in both scenarios - authoritative (already the case, from the very beginning)
> and recursive (since a version to be released in June).
>
> Although, we are quite confident that the new code is correct, we would appreciate
> if people running different work loads than ours to test the snapshot tarball available
> from here:
>
> https://users.isc.org/~ondrej/bind-9.16.17-pre.tar.xz
>
> We would like to hear both success (it?s ok here in the mailing list) and failure stories
> (please create GitLab issues).
>
> Thanks,
> Ondrej
> --
> Ond?ej Sur? (He/Him)
> ondrej at isc.org
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmCvkfcACgkQCu7JB1Xa
e1oQ7A/9HLKlZYHrnnNUyirda9rN2dn1sAooGm3EPESNSK264afB09lUHtUPrxZZ
RXVKET5pKmyVyxuidm4pyytxG7UbBcw+pR7eW6aBQ84a6P7sEbTm4qQYEbBXkCHx
4VZn5d3rzaFnOdUHiFpSFR2rkD8Xty2X0fR/usYSrA3Qhe+Iu9HEeFzezQnevTYK
AiXxFYghiHcTnSVM/tjL16f8iOs7u+QNM/jHncouM2x0AFJ5N3bBvz8SsTVlM8lr
A1jxxh37N5/HT/d2vTz6PW4J18A7IaXbc323HUwvYJ/+vxY1s0u3CKhLO2+sctnX
PkIIXD3G7jStCP2+HZgLnw3KPGDEU+Nxi79jirZxRI2NFB8wlon69LUd17W+Om3g
0OsHMIsRLblcmyBTdWoa35peeRchS9ktaWPh3TdoDwEBuU3QiYgjJTWFbxJ0lfhI
KlFx0TLU6ZgI3vaF4av/7FMvoFn+ouOtha2gu62B13qGgHXVAS1XnVSM2XONmsLJ
PaOTAPGpV9+SoC5ENNnyeRtP6wVlclogOO/RSwlNY357feqPSCOlPfuCJp1i9JCJ
+G+Xe2dRVeRhJRv7qnUvM8nubV9rpIHYrNJX871Qv7MbFU+U21Zbs/ejptrlXvVO
V2S32/TTq2n07Jt05qmmp624gYytGyl+hRj6Jya1iaITfmsbwVs=
=HK4f
-----END PGP SIGNATURE-----

From kritek at gmail.com  Thu May 27 15:11:41 2021
From: kritek at gmail.com (Rick Dicaire)
Date: Thu, 27 May 2021 11:11:41 -0400
Subject: Fwd: Problems with compiling BIND 9.17.10 or above ...
In-Reply-To: <1f5c0e04-a02a-4763-87f0-095bc4a61f5d@Canary>
References: <ffc30345-949c-4baa-9a29-c97335cb6c16@Canary>
 <CA+Cc--fKVD=1u0DyaTXXEXQwo2pE_d0N-od39Q-xamwZK0BffQ@mail.gmail.com>
 <1f5c0e04-a02a-4763-87f0-095bc4a61f5d@Canary>
Message-ID: <CA+Cc--eM2oTHj1hp2mfPeAJvCCm4e0idvfBznibOGsPahWsffg@mail.gmail.com>

Now another problem comes up and I hope someone here can help me. The
Configure process now produces the message:

checking for OPENSSL... yes

checking for OpenSSL >= 1.0.0 or LibreSSL >= 2.7.0... yes

checking for OPENSSL_init_ssl... no

checking for OPENSSL_init_crypto... no

checking for CRYPTO_zalloc... no

checking for EVP_CIPHER_CTX_new... no

checking for EVP_CIPHER_CTX_free... no

checking for EVP_MD_CTX_new... no

checking for EVP_MD_CTX_free... no

checking for EVP_MD_CTX_reset... no

checking for HMAC_CTX_new... no

checking for HMAC_CTX_free... no

checking for HMAC_CTX_reset... no

checking for HMAC_CTX_get_md... no

checking for SSL_read_ex... no

checking for SSL_peek_ex... no

checking for SSL_write_ex... no

checking for BIO_read_ex... no

checking for BIO_write_ex... no

checking for SSL_CTX_up_ref... no

checking for SSL_CTX_set_min_proto_version... no

checking for ECDSA_sign... no

configure: error: in `/root/tools/software/bind-9.17.13':

configure: error: ECDSA support in OpenSSL is mandatory.



But with the command "openssl ciphers -v 'ALL:COMPLEMENTOFALL' | grep
ECDSA" I get several lines with ECDSA. What could be the reason for this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210527/ba828ca6/attachment.htm>

From ondrej at isc.org  Thu May 27 16:28:06 2021
From: ondrej at isc.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Thu, 27 May 2021 18:28:06 +0200
Subject: Problems with compiling BIND 9.17.10 or above ...
In-Reply-To: <CA+Cc--eM2oTHj1hp2mfPeAJvCCm4e0idvfBznibOGsPahWsffg@mail.gmail.com>
References: <CA+Cc--eM2oTHj1hp2mfPeAJvCCm4e0idvfBznibOGsPahWsffg@mail.gmail.com>
Message-ID: <B81D6869-7797-4418-AE0E-02A666CA71B6@isc.org>

Hi,

you need to post full config.log, not just snippet of the console. But I would suggest to look into the config.log first.

Ondrej
--
Ond?ej Sur? ? ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 27. 5. 2021, at 17:12, Rick Dicaire <kritek at gmail.com> wrote:
> 
> ?
> Now another problem comes up and I hope someone here can help me. The Configure process now produces the message:
> checking for OPENSSL... yes
> checking for OpenSSL >= 1.0.0 or LibreSSL >= 2.7.0... yes
> checking for OPENSSL_init_ssl... no
> checking for OPENSSL_init_crypto... no
> checking for CRYPTO_zalloc... no
> checking for EVP_CIPHER_CTX_new... no
> checking for EVP_CIPHER_CTX_free... no
> checking for EVP_MD_CTX_new... no
> checking for EVP_MD_CTX_free... no
> checking for EVP_MD_CTX_reset... no
> checking for HMAC_CTX_new... no
> checking for HMAC_CTX_free... no
> checking for HMAC_CTX_reset... no
> checking for HMAC_CTX_get_md... no
> checking for SSL_read_ex... no
> checking for SSL_peek_ex... no
> checking for SSL_write_ex... no
> checking for BIO_read_ex... no
> checking for BIO_write_ex... no
> checking for SSL_CTX_up_ref... no
> checking for SSL_CTX_set_min_proto_version... no
> checking for ECDSA_sign... no
> configure: error: in `/root/tools/software/bind-9.17.13':
> configure: error: ECDSA support in OpenSSL is mandatory.
> 
> 
> But with the command "openssl ciphers -v 'ALL:COMPLEMENTOFALL' | grep ECDSA" I get several lines with ECDSA. What could be the reason for this?
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


From jw at pcthink.com  Thu May 27 17:52:11 2021
From: jw at pcthink.com (=?UTF-8?Q?JW_=CE=BB_John_Woodworth?=)
Date: Thu, 27 May 2021 13:52:11 -0400
Subject: BIND9 Feature Request: inheritance-policy
Message-ID: <202105271752.14RHqH33031486@jax4mhob01.registeredsite.com>

Greetings,?I would like to request a new feature which I hope will make management of the 'allow' match-lists a tad easier.In short, an option such as 'allow-transfer' in view or zone contexts could extend the match-list as defined in the options section.? This would flow from options->view->zone.This could minimize some of the duplication when the same set of servers are used at lower levels in the config.Additionally, a 'reset' flag would set the policy within its context, while clearing the accumulated list prior to setting the match-list in that context.Below is a proposed ABNF:inheritance-policy "{" 1*policy "};"reset ? ? ?= ?"reset"rule ? ? ? = ?"allow-query"rule ? ? ? =/ "allow-query-cache"rule ? ? ? =/ "allow-notify"rule ? ? ? =/ "allow-transfer"rule ? ? ? =/ "allow-update"rule ? ? ? =/ "allow-update-forwarding"rule ? ? ? =/ "also-notify"policy ? ? = ?rule "replace" *1reset ";"policy ? ? =/ rule "extend" *1reset ";"Best regards,?John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210527/26465be5/attachment-0001.htm>

From dot at dotat.at  Thu May 27 20:27:10 2021
From: dot at dotat.at (Tony Finch)
Date: Thu, 27 May 2021 21:27:10 +0100
Subject: BIND9 Feature Request: inheritance-policy
In-Reply-To: <202105271752.14RHqH33031486@jax4mhob01.registeredsite.com>
References: <202105271752.14RHqH33031486@jax4mhob01.registeredsite.com>
Message-ID: <35e98813-eb25-d296-029-6a1973fd437e@dotat.at>

JW ? John Woodworth <jw at pcthink.com> wrote:

> Greetings,?I would like to request a new feature which I hope will make
> management of the 'allow' match-lists a tad easier.In short, an option
> such as 'allow-transfer' in view or zone contexts could extend the
> match-list as defined in the options section.

You can sort of do what you want already, by defining named ACLs. ACLs can
refer to named ACLs: you can include a named ACL or exclude it. For
example, in my production config, I have some acl clauses roughly like the
ones outlined below.

I like named ACLs and named "masters" lists because they allow our config
generation scripts to use symbolic names to describe a zone's config:
query and xfer ACLs, upstream xfer sources, downstream notify targets. And
when I look at the generated config I see the same symbolic names, so I
have a reasonably consistent and simple vocabulary from the source of all
knowledge through to the run-time config. (And the logs when I have
persuaded the other end to do TSIG!)

acl cudn {
	# cambridge university data network address ranges
};

acl mythic {
	# mythic beasts xfer and auth servers
};

acl secondaries {
	cudn;
	mythic;
	# some xfers allowed by key instead of address
	key tsig-maths;
	key tsig-imperial;
};

zone cam.ac.uk {
	# blah blah
	allow-query { any; };
	allow-transfer { secondaries; };
};

zone private.cam.ac.uk {
	# etc usw
	allow-query { cudn; };
	allow-transfer { cudn; };
};

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
work to the benefit of all

From jw at pcthink.com  Thu May 27 22:35:30 2021
From: jw at pcthink.com (=?UTF-8?Q?JW_=CE=BB_John_Woodworth?=)
Date: Thu, 27 May 2021 18:35:30 -0400
Subject: BIND9 Feature Request: inheritance-policy
In-Reply-To: <35e98813-eb25-d296-029-6a1973fd437e@dotat.at>
Message-ID: <202105272235.14RMZj1A006788@jax4mhob11.registeredsite.com>

Thanks Tony!This is essentially what we do today.? In fact, I was ecstatic when acl's were finally able to be used for all address match-lists.However, (and I realize this not a common use case) with over 150,000 zones -- some in multiple views, with different sets of rules (e.g., allow-query, etc.).? Even with short 3-5 character acl's, repeating them every few lines will make the file grow...a lot, and I expect to be at around 250,000 zones fairly soon.I understand I could play hide-the-body and stuff the acl's into include file(s), but this level of duplication has bothered me for a while I and was hoping for something a little more elegant.Having said this, your suggestion holds true and is appreciated!Thanks,John
-------- Original message --------> From: Tony Finch <dot at dotat.at>> You can sort of do what you want already, by defining> named ACLs. ACLs can refer to named ACLs: you can> include a named ACL or exclude it.Tony.-- f.anthony.n.finch? <dot at dotat.at>? https://dotat.at/work to the benefit of all
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210527/601e3035/attachment.htm>

From richard at richardneal.com  Sun May 30 15:24:49 2021
From: richard at richardneal.com (Richard T.A. Neal)
Date: Sun, 30 May 2021 15:24:49 +0000
Subject: Any interest in a write-up showing how to configure BIND 9.17x with
 DoH and LetsEncrypt?
Message-ID: <CWXP123MB4104172FE6513C5BD214CA8BB3209@CWXP123MB4104.GBRP123.PROD.OUTLOOK.COM>

DNS over HTTPS support appears to be steadily increasing and it looks like the next version of Windows 10, Windows 10 21H2, will including support for DoH at the operating system level.

I spent a little time this weekend setting-up BIND 9.17.13 on Ubuntu 21.04 and configuring the system as a recursive resolver offering DNS over HTTPS using a LetsEncrypt certificate.

Is there any interest in me writing this up as a web article, or has everyone who's interested in DoH already got it running comfortably in their test environment?

Best.

Richard.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210530/461f0025/attachment.htm>

From carl at byington.org  Sun May 30 15:44:41 2021
From: carl at byington.org (Carl Byington)
Date: Sun, 30 May 2021 08:44:41 -0700
Subject: Any interest in a write-up showing how to configure BIND 9.17x
 with DoH and LetsEncrypt?
In-Reply-To: <CWXP123MB4104172FE6513C5BD214CA8BB3209@CWXP123MB4104.GBRP123.PROD.OUTLOOK.COM>
References: <CWXP123MB4104172FE6513C5BD214CA8BB3209@CWXP123MB4104.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <4c686e95b829b0c585ae42c3ea91c3b7ae4b014c.camel@byington.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Sun, 2021-05-30 at 15:24 +0000, Richard T.A. Neal wrote:
> Is there any interest in me writing this up as a web article, or has
> everyone who's interested in DoH already got it running comfortably in
> their test environment?

I am interested.


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

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYLOyzxUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsFMfACfcs9Ovcyvw6sHjmwz1wHuf9gPXzgA
oIo0M0HeOogH88oih5+8Edv7TVGI
=BvAs
-----END PGP SIGNATURE-----



From gtaylor at tnetconsulting.net  Sun May 30 18:23:31 2021
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sun, 30 May 2021 12:23:31 -0600
Subject: Any interest in a write-up showing how to configure BIND 9.17x
 with DoH and LetsEncrypt?
In-Reply-To: <CWXP123MB4104172FE6513C5BD214CA8BB3209@CWXP123MB4104.GBRP123.PROD.OUTLOOK.COM>
References: <CWXP123MB4104172FE6513C5BD214CA8BB3209@CWXP123MB4104.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <151644a4-1e36-66fb-788d-2eeb3d09a0f7@spamtrap.tnetconsulting.net>

On 5/30/21 9:24 AM, Richard T.A. Neal wrote:
> I spent a little time this weekend setting-up BIND 9.17.13 on Ubuntu 
> 21.04 and configuring the system as a recursive resolver offering DNS 
> over HTTPS using a LetsEncrypt certificate.

Nice work.

> Is there any interest in me writing this up as a web article, or has 
> everyone who?s interested in DoH already got it running comfortably in 
> their test environment?

Yes!

I would be /very/ interested in reading such a write up.

If you do write it up, please share where you publish your write up.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210530/339c0e48/attachment.bin>

From kremels at kreme.com  Mon May 31 06:18:23 2021
From: kremels at kreme.com (@lbutlr)
Date: Mon, 31 May 2021 00:18:23 -0600
Subject: Any interest in a write-up showing how to configure BIND 9.17x
 with DoH and LetsEncrypt?
In-Reply-To: <151644a4-1e36-66fb-788d-2eeb3d09a0f7@spamtrap.tnetconsulting.net>
References: <CWXP123MB4104172FE6513C5BD214CA8BB3209@CWXP123MB4104.GBRP123.PROD.OUTLOOK.COM>
 <151644a4-1e36-66fb-788d-2eeb3d09a0f7@spamtrap.tnetconsulting.net>
Message-ID: <342BC08E-B6C5-442B-8EF8-5E7B52D9178B@kreme.com>

On 30 May 2021, at 12:23, Grant Taylor via bind-users <bind-users at lists.isc.org> wrote:
> On 5/30/21 9:24 AM, Richard T.A. Neal wrote:
>> I spent a little time this weekend setting-up BIND 9.17.13 on Ubuntu 21.04 and configuring the system as a recursive resolver offering DNS over HTTPS using a LetsEncrypt certificate.
> 
> Nice work.
> 
>> Is there any interest in me writing this up as a web article, or has everyone who?s interested in DoH already got it running comfortably in their test environment?
> 
> Yes!

+1

Or, perhaps, +100


-- 
NO ONE WANTS TO HEAR FROM MY ARMPITS Bart chalkboard Ep. 3F01


From xavier.humbert at ac-nancy-metz.fr  Mon May 31 06:19:54 2021
From: xavier.humbert at ac-nancy-metz.fr (Xavier Humbert)
Date: Mon, 31 May 2021 08:19:54 +0200
Subject: Any interest in a write-up showing how to configure BIND 9.17x
 with DoH and LetsEncrypt?
In-Reply-To: <CWXP123MB4104172FE6513C5BD214CA8BB3209@CWXP123MB4104.GBRP123.PROD.OUTLOOK.COM>
References: <CWXP123MB4104172FE6513C5BD214CA8BB3209@CWXP123MB4104.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <4cf0179d-2b6b-bada-ec63-631a1f9f268c@ac-nancy-metz.fr>

On 30/05/2021 17:24, Richard T.A. Neal wrote:
>
> DNS over HTTPS support appears to be steadily increasing and it looks 
> like the next version of Windows 10, Windows 10 21H2, will including 
> support for DoH at the operating system level.
>
> ?
>
> I spent a little time this weekend setting-up BIND 9.17.13 on Ubuntu 
> 21.04 and configuring the system as a recursive resolver offering DNS 
> over HTTPS using a LetsEncrypt certificate.
>
> ?
>
> Is there any interest in me writing this up as a web article, or has 
> everyone who???s interested in DoH already got it running comfortably 
> in their test environment?
>
> ?
>
> Best.
>
> ?
>
> Richard.
>
>
Oh yes, please do !

Xavier

-- 
Xavier Humbert
CRT Supervision et Exploitation de Niveau 1
Rectorat de Nancy-Metz
03 83 86 27 39

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210531/d6f074c4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x90B78A89BCC49C10.asc
Type: application/pgp-keys
Size: 3154 bytes
Desc: OpenPGP public key
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210531/d6f074c4/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210531/d6f074c4/attachment-0003.bin>