Re: Instructions to use delv to test DNS configured domain before DS uploaded to parent

[Brett Delmage via bind-users]

and to answer my own question as I finally found the section in the manual 
here:


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


On Wed, 13 Dec 2023, Brett Delmage via bind-users wrote:


Sorry, I pasted the wrong version (too many remote shells open today)

Should be:
ii  bind9  1:9.18.19-1~deb12u1 amd64Internet Domain Name 
Server

ii  bind9-utils1:9.18.19-1~deb12u1 amd64Utilities for BIND 9


On Wed, 13 Dec 2023, Brett Delmage wrote:

I previously used delv with a manually made trust/key file to test that a 
DNSSEC-enabled zone was generated correctly.


Despite sarching for all kinds of terms I cannot find those instructions 
(in readthedocs I believe).


Could someone please point me there?

bind9, bind9-dnsutils: 9.18.15

Thanks.

Brett




--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Instructions to use delv to test DNS configured domain before DS uploaded to parent

[Brett Delmage via bind-users]

Sorry, I pasted the wrong version (too many remote shells open today)

Should be:
ii  bind9  1:9.18.19-1~deb12u1 amd64Internet Domain Name Server
ii  bind9-utils1:9.18.19-1~deb12u1 amd64Utilities for BIND 9


On Wed, 13 Dec 2023, Brett Delmage wrote:

I previously used delv with a manually made trust/key file to test that a 
DNSSEC-enabled zone was generated correctly.


Despite sarching for all kinds of terms I cannot find those instructions 
(in readthedocs I believe).


Could someone please point me there?

bind9, bind9-dnsutils: 9.18.15

Thanks.

Brett


--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Instructions to use delv to test DNS configured domain before DS uploaded to parent

[Brett Delmage via bind-users]

I previously used delv with a manually made trust/key file to test that a 
DNSSEC-enabled zone was generated correctly.


Despite sarching for all kinds of terms I cannot find those instructions 
(in readthedocs I believe).


Could someone please point me there?

bind9, bind9-dnsutils: 9.18.15

Thanks.

Brett
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

test - please ignore

[Greg Choules via bind-users]

Thanks, Greg
-- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "doth" test failing in 9.18.3

[Josef Moellers]

On 24.05.22 13:27, Michał Kępień wrote:

Hi Josef,


I'm in the process of upgrading openSUSE Tumbleweed to bind 9.18.3 and in
doing so, also run the test suite. However, it fails in step
FAIL: doth

The log file says
I:doth:testing incoming XoT functionality (from the first secondary) (2)
I:doth:timed out waiting for zone transfer

Is there anything I am missing?


I don't think you are missing anything.  The symptoms you described look
very similar to this issue:

 https://gitlab.isc.org/isc-projects/bind9/-/issues/3337

We are working on addressing the above, though feel free to open another
GitLab issue, attaching the entire contents of bin/tests/system/doth/
after the "doth" system test fails.  We could then make sure it is not a
different problem.


I've just set Notifications on that GL issue and will wait for news. For 
the time being I'll just assume that it's a bug in the test suite and 
NOT in the bind code itself.


Thanks,

Josef
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany

(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "doth" test failing in 9.18.3

[Michał Kępień]

Hi Josef,

> I'm in the process of upgrading openSUSE Tumbleweed to bind 9.18.3 and in
> doing so, also run the test suite. However, it fails in step
> FAIL: doth
> 
> The log file says
> I:doth:testing incoming XoT functionality (from the first secondary) (2)
> I:doth:timed out waiting for zone transfer
> 
> Is there anything I am missing?

I don't think you are missing anything.  The symptoms you described look
very similar to this issue:

https://gitlab.isc.org/isc-projects/bind9/-/issues/3337

We are working on addressing the above, though feel free to open another
GitLab issue, attaching the entire contents of bin/tests/system/doth/
after the "doth" system test fails.  We could then make sure it is not a
different problem.

Thanks,

-- 
Best regards,
Michał Kępień
-- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

"doth" test failing in 9.18.3

[Josef Moellers]

Hi,

I'm in the process of upgrading openSUSE Tumbleweed to bind 9.18.3 and 
in doing so, also run the test suite. However, it fails in step

FAIL: doth

The log file says
I:doth:testing incoming XoT functionality (from the first secondary) (2)
I:doth:timed out waiting for zone transfer

Is there anything I am missing?
There is no firewall.

Josef
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany

(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

test, please ignore

[Dan Mahoney (Gushi)]

Thanks, subject is all.

--

Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.org
---

--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: about apply Deckard to test BIND named

[Petr Špaček]

On 16. 02. 22 10:12, Ondřej Surý wrote:

I guess you can possibly workaround this by disabling jemalloc from named build 
and hope that the static shims for jemalloc calls will trump the preloaded 
functions from libfaketime.


Oh right, I forgot we can also compile BIND without jemalloc - it works!

So, this Deckard commit adds support for BIND:

https://gitlab.nic.cz/knot/deckard/-/merge_requests/217/diffs?commit_id=7668661a63d59388a8b1e7e372f58f43ff561934

Be warned that many tests will require tweaking to make them pass on 
BIND. One such example is:

https://gitlab.nic.cz/knot/deckard/-/merge_requests/217/diffs?commit_id=aa70a23ca2dd04929d1425257322bcd55c661065

Enjoy testing BIND :-)
Petr Špaček  @  Internet Systems Consortium


On 16. 2. 2022, at 9:59, Petr Špaček  wrote:

- It does not work anyway because jemalloc library used by libfaketime breaks 
libfaketime library is used by Deckard for DNSSEC tests. See 
https://github.com/wolfcw/libfaketime/issues/130.

--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: about apply Deckard to test BIND named

[Ondřej Surý]

I guess you can possibly workaround this by disabling jemalloc from named build 
and hope that the static shims for jemalloc calls will trump the preloaded 
functions from libfaketime.

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. 2. 2022, at 9:59, Petr Špaček  wrote:
> 
> - It does not work anyway because jemalloc library used by libfaketime breaks 
> libfaketime library is used by Deckard for DNSSEC tests. See 
> https://github.com/wolfcw/libfaketime/issues/130.
-- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: about apply Deckard to test BIND named

[Petr Špaček]

Hi,

it is even more complicated:

- Latest version of Deckard uses Linux network namespaces and thus makes 
BIND GL#2088 unnecessary
- It does not work anyway because jemalloc library used by libfaketime 
breaks libfaketime library is used by Deckard for DNSSEC tests. See 
https://github.com/wolfcw/libfaketime/issues/130.


So for now you are out of luck.

Besides that other points raised by Ondrej below are valid.

Petr Špaček  @  Internet Systems Consortium


On 16. 02. 22 9:04, Ondřej Surý wrote:

Hi Sun,

this is impressive effort, but it has several known gotchas:

1. The `named` looks for real interfaces to listen too and it
 didn’t play well with Deckard in the past. I’ve been told
 that this is no longer a problem, but it could be something
 you should be aware of. See [GL #2088]

2. This is not an easy way to get a “street cred”. First of all,
 the Deckard tests needs to be tailored for a specific DNS
 daemon. Every DNS server has its quirks and this is definitely
 not something that you can take, run and fill issues “named
 failed  Deckard test”. Every failure needs to be individually
 examined, debugged, explained and described. It might not be
 a bug, but just a difference in behavior.

3. Running Deckard as “one time thing” is not appealing at all.
 Any work in this area needs to integrate with the repository.
 Adding a GitLab CI job would be a bare minimum here.

4. Create an issue (I thought there’s already one as integrating
 Deckard has been on our TODO list for couple of years now),
 and track all the ideas and progress there.

GL #2088: https://gitlab.isc.org/isc-projects/bind9/-/issues/2088

--
Ondřej Surý (He/Him)
ond...@isc.org

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


On 16. 2. 2022, at 8:32, Sun Guonian via bind-users  
wrote:

Hi,

I notice that Deckard project can be used to test 
knot/knot-resolver/unbound/pdns except BIND.
And I try to write the configuration and template files for named, but it 
didn't work.

If BIND's implementation/configuration has any limitation to run with Deckard ?

Thanks in advance !

Best Regards,
SUN Guonian


P.S.
Deckard's homepage on github.com is https://github.com/CZ-NIC/deckard

--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: about apply Deckard to test BIND named

[Sun Guonian via bind-users]

Thank Ondřej for the information !
Best Regards,SUN Guonian
 

On Wednesday, February 16, 2022, 04:05:06 PM GMT+8, Ondřej Surý 
 wrote:  
 
 Hi Sun,

this is impressive effort, but it has several known gotchas:

1. The `named` looks for real interfaces to listen too and it
    didn’t play well with Deckard in the past. I’ve been told
    that this is no longer a problem, but it could be something
    you should be aware of. See [GL #2088]

2. This is not an easy way to get a “street cred”. First of all,
    the Deckard tests needs to be tailored for a specific DNS
    daemon. Every DNS server has its quirks and this is definitely
    not something that you can take, run and fill issues “named
    failed  Deckard test”. Every failure needs to be individually
    examined, debugged, explained and described. It might not be
    a bug, but just a difference in behavior.

3. Running Deckard as “one time thing” is not appealing at all.
    Any work in this area needs to integrate with the repository.
    Adding a GitLab CI job would be a bare minimum here.

4. Create an issue (I thought there’s already one as integrating
    Deckard has been on our TODO list for couple of years now),
    and track all the ideas and progress there.

GL #2088: https://gitlab.isc.org/isc-projects/bind9/-/issues/2088

--
Ondřej Surý (He/Him)
ond...@isc.org

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

> On 16. 2. 2022, at 8:32, Sun Guonian via bind-users 
>  wrote:
> 
> Hi,
> 
> I notice that Deckard project can be used to test 
> knot/knot-resolver/unbound/pdns except BIND.
> And I try to write the configuration and template files for named, but it 
> didn't work.
> 
> If BIND's implementation/configuration has any limitation to run with Deckard 
> ?
> 
> Thanks in advance !
> 
> Best Regards,
> SUN Guonian
> 
> 
> P.S.
> Deckard's homepage on github.com is https://github.com/CZ-NIC/deckard
> 
> 
> -- 
> 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

  -- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: about apply Deckard to test BIND named

[Ondřej Surý]

Hi Sun,

this is impressive effort, but it has several known gotchas:

1. The `named` looks for real interfaces to listen too and it
didn’t play well with Deckard in the past. I’ve been told
that this is no longer a problem, but it could be something
you should be aware of. See [GL #2088]

2. This is not an easy way to get a “street cred”. First of all,
the Deckard tests needs to be tailored for a specific DNS
daemon. Every DNS server has its quirks and this is definitely
not something that you can take, run and fill issues “named
failed  Deckard test”. Every failure needs to be individually
examined, debugged, explained and described. It might not be
a bug, but just a difference in behavior.

3. Running Deckard as “one time thing” is not appealing at all.
Any work in this area needs to integrate with the repository.
Adding a GitLab CI job would be a bare minimum here.

4. Create an issue (I thought there’s already one as integrating
Deckard has been on our TODO list for couple of years now),
and track all the ideas and progress there.

GL #2088: https://gitlab.isc.org/isc-projects/bind9/-/issues/2088

--
Ondřej Surý (He/Him)
ond...@isc.org

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

> On 16. 2. 2022, at 8:32, Sun Guonian via bind-users 
>  wrote:
> 
> Hi,
> 
> I notice that Deckard project can be used to test 
> knot/knot-resolver/unbound/pdns except BIND.
> And I try to write the configuration and template files for named, but it 
> didn't work.
> 
> If BIND's implementation/configuration has any limitation to run with Deckard 
> ?
> 
> Thanks in advance !
> 
> Best Regards,
> SUN Guonian
> 
> 
> P.S.
> Deckard's homepage on github.com is https://github.com/CZ-NIC/deckard
> 
> 
> -- 
> 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

about apply Deckard to test BIND named

[Sun Guonian via bind-users]

Hi,
I notice that Deckard project can be used to test 
knot/knot-resolver/unbound/pdns except BIND.And I try to write the 
configuration and template files for named, but it didn't work.
If BIND's implementation/configuration has any limitation to run with Deckard ?
Thanks in advance !
Best Regards,SUN Guonian

P.S.Deckard's homepage on github.com is https://github.com/CZ-NIC/deckard

-- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "make test" not working?

[Reindl Harald]

Am 02.02.22 um 08:23 schrieb Josef Moellers:

On 01.02.22 17:54, Reindl Harald wrote:



Am 01.02.22 um 15:28 schrieb Josef Moellers:

Just for the record:
Thanks, Ondřej, for pushing my nose onto the fact that the test 
should be run as a non-privileged user.


really *nothing* should run as root, especially not building software 
- doing so and even rpmbuild no longer can assure that something don't 
break out of the buildroot


In my case I run it on a private VM


irrelevant - basics are basics


But you're right: if the source is unreliable, anything can happen.
I was assuming the bind sources are reliable.


you are violating the principle of least privilege and that has absolute 
*nothing* to do with reliable


stop that sort of argumentation instead admit that you learned some 
absolute basics - the only error on binds sources is that they donÄt 
refuse to build as root without a special flag like courier-mta does for 
decades


a simple typo on *your side* can make the diffren between terrible 
accidents and a "permission denied" error pointing you to your mistake


mistakes happen, errors happen, bugs happen
all the time, eveywhere

the "make install" in a rpmbuild simply fails when it tries touch 
touch /usr and that's one more reason never type "sudo make install" 
but package everything


Yes ... that's what I'm about to do ... packaging bind


https://www.reddit.com/r/linux/comments/1ekd5w/why_is_it_dangerous_to_compilebuild_packages_as/

!!

It's not just malicious individuals you have to worry about. There can 
also be bugs in the build system


!!

https://serverfault.com/questions/10027/why-is-it-bad-to-build-rpms-as-root
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "make test" not working?

[Josef Moellers]

On 01.02.22 18:13, Ondřej Surý wrote:



On 1. 2. 2022, at 15:28, Josef Moellers  wrote:

Thanks, Ondřej, for pushing my nose onto the fact that the test should be run 
as a non-privileged user. BTDTGT


Well, you are welcome, but please **do** include all the modifications and all 
the steps
you are doing when reporting bugs.  You omitted quite serious information about 
the
build until the very last moment when you reported you found the issue.


I apologize for that.
My only excuse is that many times just raising the question whether 
thisandthat really works gets me an answer "oops ... no ... there's 
thisandthat that prevents it from working at the moment". But I should 
have given the information as soon as possible. I'll try to do so in the 
future.


AAMOF the bug does look like issue# 3069, more because the VM has only a 
single core and a pretty small memory, so I first tried by adding 
"--enable-querytrace" to configure's options, which caused the test to 
completely hang, and then I increased the timeout value to 30 which did 
not help either.
As the issue is already closed, I'll open a new one. But I'd like to 
make a few additional tests first.


Josef
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany

(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "make test" not working?

[Josef Moellers]

On 01.02.22 17:54, Reindl Harald wrote:



Am 01.02.22 um 15:28 schrieb Josef Moellers:

Just for the record:
Thanks, Ondřej, for pushing my nose onto the fact that the test should 
be run as a non-privileged user.


really *nothing* should run as root, especially not building software - 
doing so and even rpmbuild no longer can assure that something don't 
break out of the buildroot


In my case I run it on a private VM.
But you're right: if the source is unreliable, anything can happen.
I was assuming the bind sources are reliable.

the "make install" in a rpmbuild simply fails when it tries touch touch 
/usr and that's one more reason never type "sudo make install" but 
package everything


Yes ... that's what I'm about to do ... packaging bind.

Josef
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany

(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "make test" not working?

[Ondřej Surý]

> On 1. 2. 2022, at 15:28, Josef Moellers  wrote:
> 
> Thanks, Ondřej, for pushing my nose onto the fact that the test should be run 
> as a non-privileged user. BTDTGT

Well, you are welcome, but please **do** include all the modifications and all 
the steps
you are doing when reporting bugs.  You omitted quite serious information about 
the
build until the very last moment when you reported you found the issue.

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

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

-- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "make test" not working?

[Reindl Harald]

Am 01.02.22 um 15:28 schrieb Josef Moellers:

Just for the record:
Thanks, Ondřej, for pushing my nose onto the fact that the test should 
be run as a non-privileged user.


really *nothing* should run as root, especially not building software - 
doing so and even rpmbuild no longer can assure that something don't 
break out of the buildroot


the "make install" in a rpmbuild simply fails when it tries touch touch 
/usr and that's one more reason never type "sudo make install" but 
package everything

--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "make test" not working?

[Ondřej Surý]

Please don’t, use gitlab. The message is just autoconf quirk.

--
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 1. 2. 2022, at 15:28, Josef Moellers  wrote:
> 
> PS The "resolver" test failed, but I'll report that to i...@isc.org
-- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "make test" not working?

[Josef Moellers]

Hi folks,

Just for the record:

Thanks, Ondřej, for pushing my nose onto the fact that the test should 
be run as a non-privileged user. BTDTGT


As I am determined (and it makes sense) to run the tests on the binaries 
that we will eventually ship, I need to build the software according to 
our SPEC file. To do so required a little preparation, but needs no 
modification to the SPEC file.


As root (see NOTE1 below):
D=/usr/src/packages/BUILD
rm -rf $D/bind-; chgrp users $D; chmod 775 $D
D=/usr/src/packages/BUILDROOT
rm -rf $D/bind-; chgrp users $D; chmod 775 $D

(Replace "users" with one of the groups the unprivileged user is a 
member of. Yes, I know that this is dangerous and so should only be done 
on an isolated system without any additional users, eg a private VM).


Then, as the unprivileged user:
ln -s /usr/src/packages ~/rpmbuild  (See NOTE1 below)
rpmbuild -bc /usr/src/packages/SPECS/bind.spec
cd /usr/src/packages/BUILD/bind-
sudo bin/tests/system/ifconfig.sh up(see NOTE2 below)
make test

NOTE1: This needs to be done only once
NOTE2: This needs to be done only once after a (re)boot

Josef

PS The "resolver" test failed, but I'll report that to i...@isc.org
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany

(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "make test" not working?

[Josef Moellers]

On 31.01.22 21:24, Evan Hunt wrote:

On Mon, Jan 31, 2022 at 05:36:28PM +0100, Ondřej Surý wrote:

This works:

$ mkdir /tmp/bind9
$ cd /tmp/bind9
$ curl -sSLO https://downloads.isc.org/isc/bind9/9.18.0/bind-9.18.0.tar.xz
$ tar -xJf bind-9.18.0.tar.xz
$ cd bind-9.18.0/
$ ./configure
$ make -j


A couple of omitted steps here (easy for us to forget since we probably
have it set up already at any given time):

$ cd bin/tests/system
$ sudo sh ifconfig.sh up
$ cd -


Yepp, thanks, that one was already in my list/script.

My main problem with just running "configure" is that it will generate 
the code in a different way as we will ship it, so I need to find out 
what causes the test not to run.


I'll try to add our configure options one by one and see when the tests 
stop running.



$ make test
[…]
make[7]: Entering directory '/tmp/bind9/bind-9.18.0/bin/tests/system'
PASS: auth
[…]

Testsuite summary for BIND 9.18.0

# TOTAL: 106
# PASS:  106
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

make[7]: Leaving directory '/tmp/bind9/bind-9.18.0/bin/tests/system’
[…]
$


Josef
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany

(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "make test" not working?

[Evan Hunt]

On Mon, Jan 31, 2022 at 05:36:28PM +0100, Ondřej Surý wrote:
> This works:
> 
> $ mkdir /tmp/bind9
> $ cd /tmp/bind9
> $ curl -sSLO https://downloads.isc.org/isc/bind9/9.18.0/bind-9.18.0.tar.xz
> $ tar -xJf bind-9.18.0.tar.xz
> $ cd bind-9.18.0/
> $ ./configure
> $ make -j

A couple of omitted steps here (easy for us to forget since we probably
have it set up already at any given time):

$ cd bin/tests/system
$ sudo sh ifconfig.sh up
$ cd -

> $ make test
> […]
> make[7]: Entering directory '/tmp/bind9/bind-9.18.0/bin/tests/system'
> PASS: auth
> […]
> 
> Testsuite summary for BIND 9.18.0
> 
> # TOTAL: 106
> # PASS:  106
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  0
> # XPASS: 0
> # ERROR: 0
> 
> make[7]: Leaving directory '/tmp/bind9/bind-9.18.0/bin/tests/system’
> […]
> $

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
-- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "make test" not working?

[Ondřej Surý]

> On 31. 1. 2022, at 17:15, Josef Moellers  wrote:
> […]

> So, yes: on production builds these options are not enabled, but on the test 
> VMs I must enable them or the tests will not run.

That’s not true and never has been.  The --enable-developer is just a 
convenience setting for **BIND 9 Developers** that
enables various options - one of them does enable --with-cmocka. 

>> Both ‘make test’ and ‘make check’ works as expected.
> 
> So ... what did I do wrong?

I have no idea what you are doing to the sources and to the build system.

This works:

$ mkdir /tmp/bind9
$ cd /tmp/bind9
$ curl -sSLO https://downloads.isc.org/isc/bind9/9.18.0/bind-9.18.0.tar.xz
$ tar -xJf bind-9.18.0.tar.xz
$ cd bind-9.18.0/
$ ./configure
$ make -j
$ make test
[…]
make[7]: Entering directory '/tmp/bind9/bind-9.18.0/bin/tests/system'
PASS: auth
[…]

Testsuite summary for BIND 9.18.0

# TOTAL: 106
# PASS:  106
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

make[7]: Leaving directory '/tmp/bind9/bind-9.18.0/bin/tests/system’
[…]
$

If it doesn’t work on your system, it’s something **you** have done to the 
source tarball as this:

> Making test in misc
> make[2]: Entering directory '/usr/src/packages/BUILD/bind-9.18.0/doc/misc'
> make[2]: *** No rule to make target 'test'.  Stop.
> make[2]: Leaving directory '/usr/src/packages/BUILD/bind-9.18.0/doc/misc'
> make[1]: *** [Makefile:442: test-recursive] Error 1


simply doesn’t happen on vanilla build:

doc/misc$ make test
make: Nothing to be done for 'test’.

I will repeat that again - you should understand what you are doing and why you 
are doing that - that includes
all your local patches, changes to the default options and any other 
modifications to the build system.

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

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


-- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "make test" not working?

[Josef Moellers]

On 31.01.22 16:57, Ondřej Surý wrote:

Hi,


On 31. 1. 2022, at 15:42, Josef Moellers  wrote:

Hi,

Me again ...
I have installed the files required to build the packages on an openSUSE 
Tumbleweed machine. I have also added
--enable-developer --disable-warn-error
to the configure options.


Why? Are you a developer? It’s wrong to have this option enabled for production 
builds.


Well, yes, I am a developer. Not specifically for "bind" (or else I'd be 
more widely known), but, in general, yes! I have been sind 1981 and will 
be for a few more months.


I need to package bind, but before doing so I usually run the tests on a 
couple of VMs to see if no obvious problems exist.


So, yes: on production builds these options are not enabled, but on the 
test VMs I must enable them or the tests will not run.



Yet "make test" fails in that it does not do anything.
"make check" does run some tests, but finishes in ca. 3 minutes rather than the 40 
minutes "make test" usually takes.

The documentation still mentions "make test", so ... what am I missing?
NB I did run
bin/tests/system/ifconfig.sh up


Nobody can really help you if you don’t provide what’s wrong.  Perhaps you can 
start
by trying understanding what you are doing and why it is failing?


As I wrote:
1) I transfer the source archive, the SPEC file (for openSUSE), the 
patches and whatever else is needed to a VM (into 
/usr/src/packages/SOURCES).

2) I modify the SPEC file and add the two options mentioned above
3) I run "rpmbuild -bb /usr/src/packages/SOURCES/bind.spec"
4) I change to /usr/src/packages/BUILD/bind-1.18.0
5) I run "bin/tests/system/ifconfig.sh up"
6) I run "make test"

With 9.16.x, this works and "make test" takes ~40 minutes and gives me 
good confidence that everything is OK.


With 9.18.0, all I get is
# make test
Making test in .
make[1]: Entering directory '/usr/src/packages/BUILD/bind-9.18.0'
make[1]: Nothing to be done for 'test-am'.
make[1]: Leaving directory '/usr/src/packages/BUILD/bind-9.18.0'
Making test in lib
make[1]: Entering directory '/usr/src/packages/BUILD/bind-9.18.0/lib'
Making test in isc
make[2]: Entering directory '/usr/src/packages/BUILD/bind-9.18.0/lib/isc'
Making test in tests
make[3]: Entering directory 
'/usr/src/packages/BUILD/bind-9.18.0/lib/isc/tests'

make[3]: Nothing to be done for 'test'.
make[3]: Leaving directory 
'/usr/src/packages/BUILD/bind-9.18.0/lib/isc/tests'

make[3]: Entering directory '/usr/src/packages/BUILD/bind-9.18.0/lib/isc'
make[3]: Nothing to be done for 'test-am'.
make[3]: Leaving directory '/usr/src/packages/BUILD/bind-9.18.0/lib/isc'
make[2]: Leaving directory '/usr/src/packages/BUILD/bind-9.18.0/lib/isc'
Making test in dns
make[2]: Entering directory '/usr/src/packages/BUILD/bind-9.18.0/lib/dns'
Making test in tests
make[3]: Entering directory 
'/usr/src/packages/BUILD/bind-9.18.0/lib/dns/tests'

make[3]: Nothing to be done for 'test'.
make[3]: Leaving directory 
'/usr/src/packages/BUILD/bind-9.18.0/lib/dns/tests'

make[3]: Entering directory '/usr/src/packages/BUILD/bind-9.18.0/lib/dns'
make[3]: Nothing to be done for 'test-am'.
make[3]: Leaving directory '/usr/src/packages/BUILD/bind-9.18.0/lib/dns'
make[2]: Leaving directory '/usr/src/packages/BUILD/bind-9.18.0/lib/dns'
Making test in isccc
make[2]: Entering directory '/usr/src/packages/BUILD/bind-9.18.0/lib/isccc'
make[2]: Nothing to be done for 'test'.
make[2]: Leaving directory '/usr/src/packages/BUILD/bind-9.18.0/lib/isccc'
Making test in ns
make[2]: Entering directory '/usr/src/packages/BUILD/bind-9.18.0/lib/ns'
Making test in tests
make[3]: Entering directory 
'/usr/src/packages/BUILD/bind-9.18.0/lib/ns/tests'

make[3]: Nothing to be done for 'test'.
make[3]: Leaving directory 
'/usr/src/packages/BUILD/bind-9.18.0/lib/ns/tests'

make[3]: Entering directory '/usr/src/packages/BUILD/bind-9.18.0/lib/ns'
make[3]: Nothing to be done for 'test-am'.
make[3]: Leaving directory '/usr/src/packages/BUILD/bind-9.18.0/lib/ns'
make[2]: Leaving directory '/usr/src/packages/BUILD/bind-9.18.0/lib/ns'
Making test in isccfg
make[2]: Entering directory '/usr/src/packages/BUILD/bind-9.18.0/lib/isccfg'
Making test in tests
make[3]: Entering directory 
'/usr/src/packages/BUILD/bind-9.18.0/lib/isccfg/tests'

make[3]: Nothing to be done for 'test'.
make[3]: Leaving directory 
'/usr/src/packages/BUILD/bind-9.18.0/lib/isccfg/tests'

make[3]: Entering directory '/usr/src/packages/BUILD/bind-9.18.0/lib/isccfg'
make[3]: Nothing to be done for 'test-am'.
make[3]: Leaving directory '/usr/src/packages/BUILD/bind-9.18.0/lib/isccfg'
make[2]: Leaving directory '/usr/src/packages/BUILD/bind-9.18.0/lib/isccfg'
Making test in bind9
make[2]: Entering directory '/usr/src/packages/BUILD/bind-9.18.0/lib/bind9'
make[2]: Nothing to be done for 'test'.
make[2]: Leaving directory '/usr/src/packages/BUILD/bind-9.18.0/lib/bind9'
Making test in irs
make[2]: En

Re: "make test" not working?

[Ondřej Surý]

Hi,

> On 31. 1. 2022, at 15:42, Josef Moellers  wrote:
> 
> Hi,
> 
> Me again ...
> I have installed the files required to build the packages on an openSUSE 
> Tumbleweed machine. I have also added
>--enable-developer --disable-warn-error
> to the configure options.

Why? Are you a developer? It’s wrong to have this option enabled for production 
builds.

> Yet "make test" fails in that it does not do anything.
> "make check" does run some tests, but finishes in ca. 3 minutes rather than 
> the 40 minutes "make test" usually takes.
> 
> The documentation still mentions "make test", so ... what am I missing?
> NB I did run
>   bin/tests/system/ifconfig.sh up

Nobody can really help you if you don’t provide what’s wrong.  Perhaps you can 
start
by trying understanding what you are doing and why it is failing?

Both ‘make test’ and ‘make check’ works as expected.
`
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

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

-- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "make test" not working?

[Josef Moellers]

On 31.01.22 15:42, Josef Moellers wrote:

Hi,

Me again ...
I have installed the files required to build the packages on an openSUSE 
Tumbleweed machine. I have also added

     --enable-developer --disable-warn-error
to the configure options.

Yet "make test" fails in that it does not do anything.
"make check" does run some tests, but finishes in ca. 3 minutes rather 
than the 40 minutes "make test" usually takes.


The documentation still mentions "make test", so ... what am I missing?
NB I did run
 bin/tests/system/ifconfig.sh up


Ah ... sorry ... forgot to mention: this applies to 9.18.0

Josef
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany

(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

"make test" not working?

[Josef Moellers]

Hi,

Me again ...
I have installed the files required to build the packages on an openSUSE 
Tumbleweed machine. I have also added

--enable-developer --disable-warn-error
to the configure options.

Yet "make test" fails in that it does not do anything.
"make check" does run some tests, but finishes in ca. 3 minutes rather 
than the 40 minutes "make test" usually takes.


The documentation still mentions "make test", so ... what am I missing?
NB I did run
bin/tests/system/ifconfig.sh up

Thanks,

Josef
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany

(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: test - ignore

[Benny Pedersen]

On 2022-01-27 08:42, Matus UHLAR - fantomas wrote:


however, this discussion should be probably closed as it's not anymore
related to this mailing list operatiorns.


i only replyed to isc ignore in first place to heads up on that thay 
break there own dkim signer, when maillists do this all will downstream 
break


note disabling dmarc does not fix dkim rejects

take care, we are on a maillist that still break dkim
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: test - ignore

[Matus UHLAR - fantomas]

On 26 Jan 2022, at 17.14, Matus UHLAR - fantomas  wrote:

Altering the body or headers at all (whch lists do) will often break the
hashing.  For this reason, most recent versions of mailman have an option
to rewrite your mail from:



On 26.01.22 17:30, Sten Carlsen wrote:

When the dkim is set up, you can select which parts of the header you want
to include in the signature.


this is not possible for body: modification of body (which this list does)
will always break DKIM signatures.

modifying list of headers to sign should be done carefully, to avoid
either breaking and faking.


I have selected a smaller part of the headers for my signature,  so does
this go through?


since domain s-carlsen.dk don't have dmarc policy, mailman does not care and
leaves dkim as is (broken) as described below.


...but only in the event you have a restrictive DMARC policy.



this explains why both your and Benny's mail did fail here, while Eduard's
did not - that one was signed by mailman because of his domains' restrictive
policy.


however, this discussion should be probably closed as it's not anymore
related to this mailing list operatiorns.

--
Matus UHLAR - fantomas, uh...@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.
I'm not interested in your website anymore.
If you need cookies, bake them yourself.
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: test - ignore

[Sten Carlsen]

Thanks

Sten

> On 26 Jan 2022, at 17.14, Matus UHLAR - fantomas  wrote:
> 
>>> On Jan 25, 2022, at 8:50 AM, Benny Pedersen  wrote:
>>> Authentication-Results: lists.isc.org;
>>> dkim=fail reason="signature verification failed" (1024-bit key; 
>>> unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5;
>>> dkim=fail reason="signature verification failed" (1024-bit key; 
>>> unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z
> 
> On 25.01.22 12:25, Dan Mahoney wrote:
>> The headers you cite are lying to you.  :) The message passed DKIM on the
>> way IN to lists.isc.org (the dedicated vm that runs our lists), but then,
>> when the message got to the mailman python scripts and then shot back out
>> via the MTA, they had an altered body and no longer passed, and the header
>> was rewritten to say "fail".  (This is visible from the logging on the
>> servers, but nowhere else).
> 
> there were multiple headers when that mail came here:
> 
> Authentication-Results: fantomas.fantomas.sk;
>   dkim=fail reason="signature verification failed" (1024-bit key; secure) 
> header.d=isc.org header.i=@isc.org header.b="q/vOEba5";
>   dkim=fail reason="signature verification failed" (1024-bit key; secure) 
> header.d=isc.org header.i=@isc.org header.b="ozeUkO/Z";
>   dkim-atps=neutral
> Authentication-Results: lists.isc.org;
>   dkim=fail reason="signature verification failed" (1024-bit key; 
> unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5;
>   dkim=fail reason="signature verification failed" (1024-bit key; 
> unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z
> 
> obviously when the mail came to list, DKIM was fine, not so after it left
> (thanks to list signature)
> 
>>> will my dkim fail aswell ?
> 
> it did...
> 
>> Altering the body or headers at all (whch lists do) will often break the
>> hashing.  For this reason, most recent versions of mailman have an option
>> to rewrite your mail from:

When the dkim is set up, you can select which parts of the header you want to 
include in the signature.

I have selected a smaller part of the headers for my signature,  so does this 
go through?

> 
> [...]
> 
>> ...but only in the event you have a restrictive DMARC policy. 
> 
> this explains why both your and Benny's mail did fail here, while Eduard's
> did not - that one was signed by mailman because of his domains' restrictive
> policy.
> 
> I missed this part before.
> 
>> I've argued that it should be possible to do so for *any* dmarc policy,
>> even p=none, but that option is not present in mailman 3, at least.
> 
> I agree.
> spam filter is something that can use dkim fail and should not be ignored.
> 
> -- 
> Matus UHLAR - fantomas, uh...@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.
> Support bacteria - they're the only culture some people have.
> ___
> 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@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: test - ignore

[Matus UHLAR - fantomas]

On Jan 25, 2022, at 8:50 AM, Benny Pedersen  wrote:
Authentication-Results: lists.isc.org;
dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5;
dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z


On 25.01.22 12:25, Dan Mahoney wrote:

The headers you cite are lying to you.  :) The message passed DKIM on the
way IN to lists.isc.org (the dedicated vm that runs our lists), but then,
when the message got to the mailman python scripts and then shot back out
via the MTA, they had an altered body and no longer passed, and the header
was rewritten to say "fail".  (This is visible from the logging on the
servers, but nowhere else).


there were multiple headers when that mail came here:

Authentication-Results: fantomas.fantomas.sk;
   dkim=fail reason="signature verification failed" (1024-bit key; secure) 
header.d=isc.org header.i=@isc.org header.b="q/vOEba5";
   dkim=fail reason="signature verification failed" (1024-bit key; secure) 
header.d=isc.org header.i=@isc.org header.b="ozeUkO/Z";
   dkim-atps=neutral
Authentication-Results: lists.isc.org;
   dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5;
   dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z

obviously when the mail came to list, DKIM was fine, not so after it left
(thanks to list signature)


will my dkim fail aswell ?


it did...


Altering the body or headers at all (whch lists do) will often break the
hashing.  For this reason, most recent versions of mailman have an option
to rewrite your mail from:


[...]

...but only in the event you have a restrictive DMARC policy. 


this explains why both your and Benny's mail did fail here, while Eduard's
did not - that one was signed by mailman because of his domains' restrictive
policy.

I missed this part before.


I've argued that it should be possible to do so for *any* dmarc policy,
even p=none, but that option is not present in mailman 3, at least.


I agree.
spam filter is something that can use dkim fail and should not be ignored.

--
Matus UHLAR - fantomas, uh...@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.
Support bacteria - they're the only culture some people have.
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: One more test -- sorry for the noise

[Benny Pedersen]

On 2022-01-25 20:26, Dan Mahoney wrote:

Sorry for the noise, attempting to validate a DKIM issue


Authentication-Results: lists.isc.org;
	dkim=fail reason="signature verification failed" (2048-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=E7VfrLLS


unprotected means opendkim would like to see dnssec in verify :=)

basicly its possible forged dns here

i noted i get spf-helo-pass, spf-pass, dkim-pass, dmarc-pass before 
mailman screwed it all up in return, when dmarc policy is not reject, 
why is chaning from: header still done ?


mailman is worst case of fixing break of dkim ever writed, route to 
solve is


before mailman see any massage, make the ARC-seal, and ARC-sign, later 
when mailman comes to breaking dkim it does not matter becourse dkim 
from the origin poster can still be untrusted or trusted in opendmarc 
when opendmarc verify arc chains, still have to see spamassassin 4 here, 
so far only rspamd verifi it all, but there is perl software that does 
aswell


hope this can close this maillist breaks dkim, its not correct, i bet 
postfix maillist and dovecot does not

___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: test - ignore

[Dan Mahoney]

> On Jan 25, 2022, at 8:50 AM, Benny Pedersen  wrote:
> 
> On 2022-01-25 17:45, Greg Choules wrote:
>> Hello.
> 
> Authentication-Results: lists.isc.org;
>   dkim=fail reason="signature verification failed" (1024-bit key; 
> unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5;
>   dkim=fail reason="signature verification failed" (1024-bit key; 
> unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z
> 
> dont know why it failed

I may as well answer this since other people chimed in on the test message.  
I'm Dan Mahoney, ISC's sysadmin who runs most of our mail systems, and, 
coincidentally, also do some work with the Trusted Domain Project on opendkim 
and opendmarc.

The headers you cite are lying to you.  :) The message passed DKIM on the way 
IN to lists.isc.org <http://lists.isc.org/> (the dedicated vm that runs our 
lists), but then, when the message got to the mailman python scripts and then 
shot back out via the MTA, they had an altered body and no longer passed, and 
the header was rewritten to say "fail".  (This is visible from the logging on 
the servers, but nowhere else).

The solution here, is that lists.isc.org <http://lists.isc.org/> should only be 
running in "signer" mode, and not verifying anything (we verify messages on our 
MXes, and make the decisions there to reject if dmarc says to do so).  The only 
things that lists.isc.org <http://lists.isc.org/> will sign are things that it 
generates itself (i.e. things from the lists.isc.org <http://lists.isc.org/> 
domain).

> 
> will my dkim fail aswell ?

Re: DKIM failure, both SPF and DKIM is well known to be broken by mailing 
lists.  So if you're running a dmarc-enforced domain with a policy of P=reject, 
it's possible that mail you send via a list will be rejected.

Altering the body or headers at all (whch lists do) will often break the 
hashing.  For this reason, most recent versions of mailman have an option to 
rewrite your mail from:

From: "Benny Pedersen" http://example.com/>>

...to...

From: "Benny Pedersen via bind-users" http://lists.isc.org/>>
Reply-To: "Benny Pederson" http://example.com/>>
Cc: bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>

...but only in the event you have a restrictive DMARC policy.  I've argued that 
it should be possible to do so for *any* dmarc policy, even p=none, but that 
option is not present in mailman 3, at least.

Here at ISC, we have a little bit of a cheat -- messages *we* send to 
bind-users will pass SPF, because lists.isc.org <http://lists.isc.org/> is in 
our SPF list.

The upcoming "better" solution for this is ARC: basically a way for 
lists.isc.org <http://lists.isc.org/> to assert "This thing passed muster when 
it entered our borders, trust us".

-Dan Mahoney

> ___
> 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



signature.asc
Description: Message signed with OpenPGP
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

One more test -- sorry for the noise

[Dan Mahoney]

Sorry for the noise, attempting to validate a DKIM issue
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

test -- please ignore

[Dan Mahoney]

testing, please ignore
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: test - ignore

[Eduard via bind-users]

Try using a larger key, at least 2048 bits.

Check all your DNS entries and make sure everything matches correctly, MX, A, 
reverse, etc.

Check to see if your hostname used in the HELO/ELHO process matches what is in 
DNS.

Regards,
 
Eduard Tieseler
Network Operations Director
4050 Truxel Road Suite A
Sacramento, CA 95834
Office  916-922-7584 ext. 288
Fax 916-922-1835
etiese...@metrolist.net
 
   

 
Please consider the environment before printing this e-mail
THE INFORMATION CONTAINED IN THIS ELECTRONIC MESSAGE IS CONFIDENTIAL. THE 
INFORMATION IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHOM IT 
IS ADDRESSED. IF YOU ARE NOT THE INTENDED RECIPIENT, ANY USE, DISSEMINATION, OR 
DISTRIBUTION OF THIS COMMUNICATION IS PROHIBITED. IF YOU HAVE RECEIVED THIS 
ELECTRONIC MESSAGE IN ERROR, PLEASE NOTIFY US IMMEDIATELY AND DELETE THE 
MESSAGE. ANY USE, MODIFICATION, OR REPUBLICATION OF THIS COMMUNICATION, 
INCLUDING ANY ATTACHED FILES, DOCUMENTS, DATA OR OTHER INFORMATION WHICH HAS 
NOT BEEN EXPRESSLY AUTHORIZED BY US IS PROHIBITED. WE SPECIFICALLY DISCLAIM 
RESPONSIBILITY FOR ANY UNAUTHORIZED USE OF THIS COMMUNICATION OR ANY 
ATTACHMENTS TO IT.

On 1/25/22, 8:51 AM, "bind-users on behalf of Benny Pedersen" 
 wrote:

On 2022-01-25 17:45, Greg Choules wrote:
> Hello.

Authentication-Results: lists.isc.org;
dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5;
dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z

dont know why it failed

will my dkim fail aswell ?
___
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@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: test - ignore

[Benny Pedersen]

On 2022-01-25 17:45, Greg Choules wrote:

Hello.


Authentication-Results: lists.isc.org;
	dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5;
	dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z


dont know why it failed

will my dkim fail aswell ?
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

test - ignore

[Greg Choules]

Hello.
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: should I be seeing piles of gnuism extensions in the test suite?

[Ondřej Surý]

I honestly don’t know what you are trying achieve here. We don’t declare that 
system tests are strict POSIX and neither should we. Pragmatic approach here is 
to support Linux and BSD. 

That said, BIND 9 is open source, and we would accept merge requests that are 
reasonable - which means commits must be small(ish), isolated and not 
complicate things just for the sake of the POSIX compatibility. Currently, the 
tests run with (d)ash as shell, so there are no bashisms, but anything beyond 
that - I would rather see a system test rewritten into py.test than dumbed down 
to strict POSIX. Basically, I am saying that anything that will increase 
maintenance costs will not be accepted.

We don’t have strict POSIX systems in the CI nor we are going to add it. It’s 
just a matter of priorities.

If this is something more than a hobby project you’ll have to scratch your itch.

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 1. 8. 2021, at 0:06, Dennis Clarke  wrote:
> 
> What you are saying is that your testsuite is not portable. It may or
> may not work on some systems and good luck if it does not.  If I were
> to try a z/OS system then your code would certainly break there. I can
> and will test that.
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: should I be seeing piles of gnuism extensions in the test suite?

[Dennis Clarke via bind-users]

On 7/30/21 11:13, Ondřej Surý wrote:
> Dennis,
> 
> not sure why you are repeating the message you sent to the list before, but 
> here’s
> the answer I gave you in May and it is still true:

 this -->   -print0 and xargs -0 might not be exactly POSIX.1, but
   it’s important for safe passing of filenames.


What you are saying is that your testsuite is not portable. It may or
may not work on some systems and good luck if it does not.  If I were
to try a z/OS system then your code would certainly break there. I can
and will test that.

Dennis Clarke

ps: I recall I was the person ISC reached out to with your internal
  code that you could not get running on a customer system. I was
  the one that fixed that problem and did it with a smile. Maybe
  you need to get your head out of the clouds.

___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: should I be seeing piles of gnuism extensions in the test suite?

[Ondřej Surý]

Dennis,

not sure why you are repeating the message you sent to the list before, but 
here’s
the answer I gave you in May and it is still true:

https://lists.isc.org/pipermail/bind-users/2021-May/104587.html

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

> On 30. 7. 2021, at 16:38, Dennis Clarke via bind-users 
>  wrote:
> 
> 
> While running the testsuite for 9.11.26 on a strict UNIX system I see :
> 
> .
> .
> .
> I:autosign:  resigned after the active KSK is deleted - stage 2: Verify
> that DNSKEY
> I:autosign:  is now signed with the ZSK. (87)
> I:autosign:check that zone with active and inactive ZSK and active KSK
> is properly
> I:autosign:  resigned after the active ZSK is deleted - stage 2: Verify
> that zone
> I:autosign:  is now signed with the KSK. (88)
> I:autosign:checking for out-of-zone NSEC3 records after ZSK removal (89)
> I:autosign:check that DNAME at apex with NSEC3 is correctly signed
> (auto-dnssec maintain) (90)
> I:autosign:checking that DNAME is not treated as a delegation when
> signing (91)
> I:autosign:exit status: 1
> find: bad option -or
> find: [-H | -L] path-list predicate-list
> xargs: illegal option -- 0
> find: bad option -print0
> findxargs: : [-H | -L] path-list predicate-list
> Usage: xargs: [-t] [-p] [-e[eofstr]] [-E eofstr] [-I replstr]
> [-i[replstr]] [-L #] [-l[#]] [-n # [-x]] [-s size] [cmd [args ...]]
> R:autosign:FAIL
> E:autosign:Fri Jul 30 14:34:57 GMT 2021
> S:builtin:Fri Jul 30 14:34:57 GMT 2021
> T:builtin:1:A
> A:builtin:System test builtin
> I:builtin:PORTRANGE:5800 - 5899
> I:builtin:Checking expected empty zones were configured (1)
> I:builtin:Checking that reconfiguring empty zones is silent (2)
> I:builtin:Checking that reloading empty zones is silent (3)
> I:builtin:Checking that default version works for rndc (4)
> I:builtin:Checking that custom version works for rndc (5)
> I:builtin:Checking that default version works for query (6)
> I:builtin:Checking that custom version works for query (7)
> I:builtin:Checking that default hostname works for query (8)
> I:builtin:Checking that custom hostname works for query (9)
> I:builtin:Checking that default server-id is none for query (10)
> I:builtin:Checking that server-id hostname works for query (11)
> I:builtin:Checking that server-id hostname works for EDNS name server ID
> request (12)
> I:builtin:Checking that custom server-id works for query (13)
> I:builtin:Checking that custom server-id works for EDNS name server ID
> request (14)
> I:builtin:exit status: 0
> find: bad option -or
> find: [-H | -L] path-list predicate-list
> xargs: illegal option -- 0
> find: bad option -print0
> findxargs: : [-H | -L] path-list predicate-list
> Usage: xargs: [-t] [-p] [-e[eofstr]] [-E eofstr] [-I replstr]
> [-i[replstr]] [-L #] [-l[#]] [-n # [-x]] [-s size] [cmd [args ...]]
> R:builtin:PASS
> E:builtin:Fri Jul 30 14:35:19 GMT 2021
> S:cacheclean:Fri Jul 30 14:35:19 GMT 2021
> T:cacheclean:1:A
> A:cacheclean:System test cacheclean
> I:cacheclean:PORTRANGE:5900 - 5999
> I:cacheclean:check correctness of routine cache cleaning (1)
> I:cacheclean:only one tcp socket was used (2)
> I:cacheclean:reset and check that records are correctly cached initially (3)
> I:cacheclean:check flushing of the full cache (4)
> I:cacheclean:check flushing of individual nodes (interior node) (5)
> I:cacheclean:check flushing of individual nodes (leaf node, under the
> interior node) (6)
> I:cacheclean:check flushing of individual nodes (another leaf node, with
> both positive and negative cache entries) (7)
> I:cacheclean:check flushing a nonexistent name (8)
> I:cacheclean:check flushing of namespaces (9)
> I:cacheclean:check flushing a nonexistent namespace (10)
> I:cacheclean:check the number of cached records remaining (11)
> I:cacheclean:check the check that flushname of a partial match works (12)
> I:cacheclean:check the number of cached records remaining (13)
> I:cacheclean:check flushtree clears adb correctly (14)
> I:cacheclean:check expire option returned from master zone (15)
> I:cacheclean:check expire option returned from slave zone (16)
> I:cacheclean:exit status: 0
> .
> .
> .
> 
> Is there a requirement for GNU sed and GNU awk etc etc ?
> 
> Also I will try this on z/OS which is even far more strict and I worry
> that the entire build process may fail due to such extensions.
> 
> -- 
> 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.

should I be seeing piles of gnuism extensions in the test suite?

[Dennis Clarke via bind-users]

While running the testsuite for 9.11.26 on a strict UNIX system I see :

.
.
.
I:autosign:  resigned after the active KSK is deleted - stage 2: Verify
that DNSKEY
I:autosign:  is now signed with the ZSK. (87)
I:autosign:check that zone with active and inactive ZSK and active KSK
is properly
I:autosign:  resigned after the active ZSK is deleted - stage 2: Verify
that zone
I:autosign:  is now signed with the KSK. (88)
I:autosign:checking for out-of-zone NSEC3 records after ZSK removal (89)
I:autosign:check that DNAME at apex with NSEC3 is correctly signed
(auto-dnssec maintain) (90)
I:autosign:checking that DNAME is not treated as a delegation when
signing (91)
I:autosign:exit status: 1
find: bad option -or
find: [-H | -L] path-list predicate-list
xargs: illegal option -- 0
find: bad option -print0
findxargs: : [-H | -L] path-list predicate-list
Usage: xargs: [-t] [-p] [-e[eofstr]] [-E eofstr] [-I replstr]
[-i[replstr]] [-L #] [-l[#]] [-n # [-x]] [-s size] [cmd [args ...]]
R:autosign:FAIL
E:autosign:Fri Jul 30 14:34:57 GMT 2021
S:builtin:Fri Jul 30 14:34:57 GMT 2021
T:builtin:1:A
A:builtin:System test builtin
I:builtin:PORTRANGE:5800 - 5899
I:builtin:Checking expected empty zones were configured (1)
I:builtin:Checking that reconfiguring empty zones is silent (2)
I:builtin:Checking that reloading empty zones is silent (3)
I:builtin:Checking that default version works for rndc (4)
I:builtin:Checking that custom version works for rndc (5)
I:builtin:Checking that default version works for query (6)
I:builtin:Checking that custom version works for query (7)
I:builtin:Checking that default hostname works for query (8)
I:builtin:Checking that custom hostname works for query (9)
I:builtin:Checking that default server-id is none for query (10)
I:builtin:Checking that server-id hostname works for query (11)
I:builtin:Checking that server-id hostname works for EDNS name server ID
request (12)
I:builtin:Checking that custom server-id works for query (13)
I:builtin:Checking that custom server-id works for EDNS name server ID
request (14)
I:builtin:exit status: 0
find: bad option -or
find: [-H | -L] path-list predicate-list
xargs: illegal option -- 0
find: bad option -print0
findxargs: : [-H | -L] path-list predicate-list
Usage: xargs: [-t] [-p] [-e[eofstr]] [-E eofstr] [-I replstr]
[-i[replstr]] [-L #] [-l[#]] [-n # [-x]] [-s size] [cmd [args ...]]
R:builtin:PASS
E:builtin:Fri Jul 30 14:35:19 GMT 2021
S:cacheclean:Fri Jul 30 14:35:19 GMT 2021
T:cacheclean:1:A
A:cacheclean:System test cacheclean
I:cacheclean:PORTRANGE:5900 - 5999
I:cacheclean:check correctness of routine cache cleaning (1)
I:cacheclean:only one tcp socket was used (2)
I:cacheclean:reset and check that records are correctly cached initially (3)
I:cacheclean:check flushing of the full cache (4)
I:cacheclean:check flushing of individual nodes (interior node) (5)
I:cacheclean:check flushing of individual nodes (leaf node, under the
interior node) (6)
I:cacheclean:check flushing of individual nodes (another leaf node, with
both positive and negative cache entries) (7)
I:cacheclean:check flushing a nonexistent name (8)
I:cacheclean:check flushing of namespaces (9)
I:cacheclean:check flushing a nonexistent namespace (10)
I:cacheclean:check the number of cached records remaining (11)
I:cacheclean:check the check that flushname of a partial match works (12)
I:cacheclean:check the number of cached records remaining (13)
I:cacheclean:check flushtree clears adb correctly (14)
I:cacheclean:check expire option returned from master zone (15)
I:cacheclean:check expire option returned from slave zone (16)
I:cacheclean:exit status: 0
.
.
.

Is there a requirement for GNU sed and GNU awk etc etc ?

Also I will try this on z/OS which is even far more strict and I worry
that the entire build process may fail due to such extensions.

-- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test - STILL [LONG]

[G.W. Haywood via bind-users]

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.
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test - STILL [LONG]

[G.W. Haywood via bind-users]

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.
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test - STILL [LONG]

[Ondřej Surý]

her name server. Here's what I did:
>>>>> 
>>>>> #dig newideatest.site dnskey | dnssec-dsfromkey -2 -f - newideatest.site
>>>>> newideatest.site. IN DS 49236 13 2 
>>>>> 
>>>>> 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
>>> 
>>> 
>>> ___
>>> 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@lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
> 
> --
> Dan Egli
> From my Test Server
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test - STILL [LONG]

[Dan Egli via bind-users]

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 
 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) 
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 
 wrote:


On 5/10/2021 12:38 PM, Tony Finch wrote:

Dan Egli 
 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 

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


___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


--
Dan Egli
From my Test Server



OpenPGP_0x11B7451DF2015959.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test - STILL [LONG]

[Mark Andrews]

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  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) 
> 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 
>>>  wrote:
>>> 
>>> On 5/10/2021 12:38 PM, Tony Finch wrote:
>>>> Dan Egli 
>>>>  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 
>>> 
>>> 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
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test - STILL [LONG]

[Ondřej Surý]

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.   3600IN  NS  jupiter.eglifamily.name.
newideatest.site.   3600IN  NS  
uz5qfm8n244kn4qz8mh437w9kzvpudduwyldp5361v9n0vh8sx5ucu.free.ns.buddyns.com.
newideatest.site.   3600IN  NS  
uz5154v9zl2nswf05td8yzgtd0jl6mvvjp98ut07ln0ydp2bqh1skn.free.ns.buddyns.com.
newideatest.site.   3600IN  NS  
uz52u1wtmumlrx5fwu6nmv22ntcddxcjjw41z8sfd6ur9n7797lrv9.free.ns.buddyns.com.
newideatest.site.   3600IN  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  
> 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) 
> 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 
>>>>  wrote:
>>> 
>>> On 5/10/2021 12:38 PM, Tony Finch wrote:
>>>> Dan Egli 
>>>>  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 
>>> 
>>> 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
> 
> 
> ___
> 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@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test - STILL [LONG]

[Dan Egli via bind-users]

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) 
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  
wrote:

On 5/10/2021 12:38 PM, Tony Finch wrote:

Dan Egli 
  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 

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
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test - STILL [LONG]

[Mark Andrews]

> On 16 May 2021, at 10:17, Dan Egli via bind-users  
> wrote:
> 
> On 5/10/2021 12:38 PM, Tony Finch wrote:
>> Dan Egli 
>>  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 
> 
> 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/: 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

Re: Inline signing fails dnsviz test - STILL [LONG]

[Dan Egli via bind-users]

On 5/10/2021 12:38 PM, Tony Finch wrote:

Dan Egli  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 

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

Re: Inline signing fails dnsviz test.

[Dan Egli via bind-users]

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



OpenPGP_0x11B7451DF2015959.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test.

[Tony Finch]

Dan Egli  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.finchhttps://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.

___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test.

[Dan Egli]

On 5/10/2021 12:17 PM, Tony Finch wrote:

Dan Egli  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: f932880860047837010060997aea2f4ce09bf11a954c (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



OpenPGP_0x11B7451DF2015959.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test.

[Tony Finch]

Dan Egli  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.finchhttps://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.

___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test.

[Dan Egli]

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: 8761a3c0b39eccab01006099729d88739143bbe8c230 (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 
*Sent:* Monday, May 10, 2021 12:20 AM
*To:* bind-users@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


--
Dan Egli
From my Test Server



OpenPGP_0x11B7451DF2015959.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
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 subsc

Re: Inline signing fails dnsviz test.

[John W. Blue via bind-users]

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 
Sent: Monday, May 10, 2021 12:20 AM
To: bind-users@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test.

[Ondřej Surý]

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  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
> 
> 
> 
> ___
> 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@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question about Recommended stress test tools for bind.

[Techs-yama]

Hi, UHLAR.

Thank you for your advice.

I'll check these templates.

Best regards.

2020年6月26日(金) 19:28 Matus UHLAR - fantomas :
>
> >On 2020-06-25 04:10, Techs-yama wrote:
> >>and How do you have any recommended statistics items to check by
> >>rndc stats.
>
> On 25.06.20 12:43, Chuck Aurora wrote:
> >I don't know what you are looking for, but I would recommend NOT
> >using rndc stats:
> >
> >https://kb.isc.org/docs/aa-00769
>
> if you want to say that xml statistics are better than rndc stads, I admin
> that they are kind fo better solution, however, I haven't found anything
> better for cacti, that could process those than what we currently have:
>
> https://docs.cacti.net/usertemplate:host:bind9.7
>
> snmp support would be great.
>
> --
> Matus UHLAR - fantomas, uh...@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.
> Microsoft dick is soft to do no harm
> ___
> 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@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question about Recommended stress test tools for bind.

[Matus UHLAR - fantomas]

On 2020-06-25 04:10, Techs-yama wrote:

and How do you have any recommended statistics items to check by
rndc stats.


On 25.06.20 12:43, Chuck Aurora wrote:

I don't know what you are looking for, but I would recommend NOT
using rndc stats:

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


if you want to say that xml statistics are better than rndc stads, I admin
that they are kind fo better solution, however, I haven't found anything
better for cacti, that could process those than what we currently have:

https://docs.cacti.net/usertemplate:host:bind9.7

snmp support would be great.

--
Matus UHLAR - fantomas, uh...@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.
Microsoft dick is soft to do no harm
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question about Recommended stress test tools for bind.

[Brett Delmage]

On Thu, 25 Jun 2020, Chuck Aurora wrote:


On 2020-06-25 04:10, Techs-yama wrote:

Hi, bind forks !


I'm a spoon, not a fork! :)


418 I'm a teapot!

___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question about Recommended stress test tools for bind.

[Techs-yama]

Thank you for your reply!

>I'm a spoon, not a fork! :)
Oops I'm Sorry typo.

>I don't know what you are looking for, but I would recommend NOT
Are there any stats result items, I should check when I perform tuning on bind?
 e.g.) socket error,  cache memory in use, and more...

Thank you and best regards.



2020年6月26日(金) 2:43 Chuck Aurora :
>
> On 2020-06-25 04:10, Techs-yama wrote:
> > Hi, bind forks !
>
> I'm a spoon, not a fork! :)
>
> [snip]
>
> > and How do you have any recommended statistics items to check by
> > rndc stats.
>
> I don't know what you are looking for, but I would recommend NOT
> using rndc stats:
>
> https://kb.isc.org/docs/aa-00769
> ___
> 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@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question about Recommended stress test tools for bind.

[Chuck Aurora]

On 2020-06-25 04:10, Techs-yama wrote:

Hi, bind forks !


I'm a spoon, not a fork! :)

[snip]


and How do you have any recommended statistics items to check by
rndc stats.


I don't know what you are looking for, but I would recommend NOT
using rndc stats:

https://kb.isc.org/docs/aa-00769
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Question about Recommended stress test tools for bind.

[Techs-yama]

Hi, bind forks !

Now, I was bind deployed on a new on-premises server.
I want to make sure that settings are appropriate and check recursion
performance on bind.
Which stress tool would be useful and recommended in this case?
(I already know dnsperf. )
and How do you have any recommended statistics items to check by rndc stats.

Best regards.
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: [dev] Change in the build system - please test

[Xavier Humbert via bind-users]

Ondej,

Built on FreeBSD 12.1-STABLE, so far so good :

[xavier@numenor bind9]$ ./configure --prefix
/home/xavier/Development/bind9/build/
===
Configuration summary:
---
Optional features enabled:
    Allow 'dnstap' packet logging (--enable-dnstap)
    GeoIP2 access control (--enable-geoip)
    GSS-API (--with-gssapi)
    CMocka Unit Testing Framework (--with-cmocka)
    DNSSEC validation active by default (--enable-auto-validation)
    Dynamically loadable zone (DLZ) drivers:
    Berkeley DB (--with-dlz-bdb)
    LDAP (--with-dlz-ldap)
    MySQL (--with-dlz-mysql)
    ODBC (--with-dlz-odbc)
    Postgres (--with-dlz-postgres)
    Filesystem (--with-dlz-filesystem)
    Stub (--with-dlz-stub)
---
Features disabled or unavailable on this platform:
    Small-system tuning (--with-tuning)
    DNS Response Policy Service interface (--enable-dnsrps)
    Allow 'fixed' rrset-order (--enable-fixed-rrset)
    Using PKCS#11 for Public-Key Cryptography (--with-native-pkcs11)
    Print backtrace on crash (--enable-backtrace)
    Very verbose query trace logging (--enable-querytrace)
    LMDB database to store configuration for 'addzone' zones (--with-lmdb)
    IDN support (--with-libidn2)
---
Configured paths:
    prefix: /home/xavier/Development/bind9/build
    sysconfdir: ${prefix}/etc
    localstatedir: ${prefix}/var
---
Compiler: cc
    FreeBSD clang version 9.0.1 (g...@github.com:llvm/llvm-project.git
c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1)
    Target: x86_64-unknown-freebsd12.1
    Thread model: posix
    InstalledDir: /usr/bin
CFLAGS: -Wall -Wextra -Wwrite-strings -Wcast-qual -Wpointer-arith
-Wno-missing-field-initializers -Wformat -Wshadow
-Werror=implicit-function-declaration -Werror=missing-prototypes
-Werror=format-security -Werror=parentheses -Werror=implicit
-Werror=strict-prototypes -fno-strict-aliasing
-fno-delete-null-pointer-checks -fdiagnostics-show-option -g -O2
-pthread -I/usr/local/include
CPPFLAGS: -D_FORTIFY_SOURCE=2
LDFLAGS:
---
For more detail, use --enable-full-report.
===
[xavier@numenor bind9]$ make all install
[...snip...]
[xavier@numenor bind9]$ cd build/bin/
[xavier@numenor bin]$ ./dig soa groumpf.org

; <<>> DiG 9.17.1-dev <<>> soa groumpf.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2634
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 222af390e75487cc01005e9f1b7c4ce411a5b445805d (good)
;; QUESTION SECTION:
;groumpf.org.   IN  SOA

;; ANSWER SECTION:
groumpf.org.    10800   IN  SOA ns3.groumpf.org.
root.groumpf.org. 2020041901 7200 7200 604800 10800

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Tue Apr 21 18:12:44 CEST 2020
;; MSG SIZE  rcvd: 113

[xavier@numenor bin]$ ../sbin/named -V
BIND 9.17.1-dev (Development Release) 
running on FreeBSD amd64 12.1-STABLE FreeBSD 12.1-STABLE r359793 XAVIER
built by make with  '--prefix' '/home/xavier/Development/bind9/build/'
compiled by CLANG FreeBSD Clang 9.0.1
(g...@github.com:llvm/llvm-project.git
c1a0a213378a458fbea1a5c77b315c7dce08fd05)
compiled with OpenSSL version: OpenSSL 1.1.1f  31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f  31 Mar 2020
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
threads support is enabled

default paths:
  named configuration:  /home/xavier/Development/bind9/build/etc/named.conf
  rndc configuration:   /home/xavier/Development/bind9/build/etc/rndc.conf
  DNSSEC root key:  /home/xavier/Development/bind9/build/etc/bind.keys
  nsupdate session key:
/home/xavier/Development/bind9/build/var/run/named/session.key
  named PID file:  
/home/xavier/Development/bind9/build/var/run/named/named.pid
  named lock file: 
/home/xavier/Development/bind9/build/var/run/named/named.lock
  geoip-directory:  /usr/local/share/GeoIP

Regards,

Xavier

On 21/04/2020 15:15, Ondřej Surý wrote:
> Hey all,
>
> the work to upgrade BIND 9 to use automake and more declarative syntax has 
> been
> completed to a state where the majority of the work was merged to the 
> development
> branch and it will be included in the next major release (e.g. BIND 9.18). 
> However
> 

[dev] Change in the build system - please test

[Ondřej Surý]

Hey all,

the work to upgrade BIND 9 to use automake and more declarative syntax has been
completed to a state where the majority of the work was merged to the 
development
branch and it will be included in the next major release (e.g. BIND 9.18). 
However
because this is a big change, I would like to invite people interested in the 
BIND 9
development to actively go and try it.

All you need to do is:

git clone --depth=1 https://gitlab.isc.org/isc-projects/bind9.git
cd bind9
autoreconf -fi
./configure && make && make install # as usual

Few things needs to be said:

* You should read the main commit description:
https://gitlab.isc.org/isc-projects/bind9/-/commit/978c7b2e89aa37a7ddfe2f6b6ba12ce73dd04528

* You should look at the list of linked issues to the main (#4) issue which 
contains list of not-yet-done work:
https://gitlab.isc.org/isc-projects/bind9/-/issues/4

If there’s an issue you found and it’s small, try to look at the list of 
existing issues and add it if it fits, or
just add a comment on the issue #4.  If the problem is reasonable big and 
contained, feel free to open
new issue for it (and probably link it in the comment in issue #4).

Thank you,
Ondrej
--
Ondřej Surý
ond...@isc.org



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Test

[Turritopsis Dohrnii Teo En Ming]

Test








-BEGIN EMAIL SIGNATURE-

The Gospel for all Targeted Individuals (TIs):

[The New York Times] Microwave Weapons Are Prime Suspect in Ills of
U.S. Embassy Workers

Link: 
https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html




Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic
Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United 
Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and 
Australia (25 Dec 2019 to 9 Jan 2020):

[1] https://tdtemcerts.wordpress.com/

[2] https://tdtemcerts.blogspot.sg/

[3] https://www.scribd.com/user/270125049/Teo-En-Ming

-END EMAIL SIGNATURE-

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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DMARC test

[Jim Popovitch via bind-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2019-07-14 at 18:30 -0400, Paul Kosinski via bind-users wrote:
> Testing how lists.isc.org handles DMARC "Quarantine" (and "Reject")
> policy. The enterpr...@mozilla.org mailing list forwards such email in a
> way that some recipients choke on it (i.e., can't validate it).

This list applies the Mailman DMARC handler which, in the case of this
list's configuration, munges the From address.  In your specific case,
subscribers see the email as 

 From: Paul Kosinski via bind-users 
 Reply-to: Paul Kosinski 

You can read more about how Mailman handles DMARC here: 
   https://wiki.list.org/DEV/DMARC

hth,

- -Jim P.
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE3RmV4WutJ2KyCS2zPcxbabkKGJ8FAl0rw7cACgkQPcxbabkK
GJ9JChAAhNPPmoLbUR0UGsPjEfYSSPe1fSoO5q+larj9mXaO9rCOuVpSucf5FqOb
zex2JSqyX7Xh8PUTgUnaNLocKFOXxh2Csdx/a/vagSGBfalFk9cShX92dyn5eySj
Ah+wQjqh+1uA9esJcDpW+/HtPYUCb1+ixlzxCwneF/kNPNX8yxtenqOMBM1l2Pi+
vlt8JYM/OxSs5mOz1AWRh9OLGL+E7eUg3dljrkRhhSDqDYMlswNNT4ffgRX1EvpR
Z6BWgV8gPdmbJPzW+6ZlU53QLauhmGpL8BN6/Ur4739cKgZfxpjyV2DSSau3BGzp
cy3o8g/9Lrvvlnfiv1YZfESnQl2mfeseEj+CZespDbHu4CEVT3DqXWdQQDHAqidv
GRJ8FJtuqU2UjM+W4mNMEAwwKn5lQRbVnct4btExEYWvr7hdTGiaybNYlr9+jGDj
DlnmM9XZE8vIPvOF0mrFA8qWdLkMp5ecOlLn35++XDb2BSLDgZd+n8WqVJ3G+7Df
ZgixhaPQQADisfzk3nujKPu1JVBeIwEKyr8YW4LUvjcORLvp13UTxF00p9EVoLF6
yovKLpYvPXN0Vw6h58YAemWnEr46txzrUnHsW8/6JhT8t1AMew/9nyFu+7maOjX+
wHgFNS+YEkCbG0RbFaAkVH8fGgIwPUMUsx3SpKvkuKZpz/SqTHk=
=blPk
-END PGP SIGNATURE-

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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

DMARC test

[Paul Kosinski via bind-users]

Testing how lists.isc.org handles DMARC "Quarantine" (and "Reject")
policy. The enterpr...@mozilla.org mailing list forwards such email in a
way that some recipients choke on it (i.e., can't validate it).
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Test mail to bind-users

[Warren Kumari]

On Thu, May 31, 2018 at 3:48 AM Matus UHLAR - fantomas
 wrote:
>
> >On Wed, 30 May 2018, Michael McNally wrote:
> >>We have had reports that posts to bind-users are (in at least some
> >>cases) triggering unwelcome direct-to-the-submitter messages from
> >>spammers.
>
> it was about time ;-)
>
> On 31.05.18 08:28, G.W. Haywood via bind-users wrote:
> >I'm not sure that there's much that a list manager can do about it.
>
> they can find the abusers relay posts to spam senders and remove them.
>
> I have met similar case on IRC some 15-20 years ago. Spammer joined a
> channel, and relayed nicknames of those who joined (or left) so they got
> spam srom another nickname
>

... these has also been a (recent) issue where someone subscribed
their ticketing system to the list, and so every posting got a:
[ RT - #4217 ] AutoReply: Re: 

Thank you for opening a ticket. We will get to it soon.
Thanks,
   NOC.

W

> >This has been an issue for most of the lists to which I've subscribed
> >for decades.  My list addresses only accept mail from the lists to
> >which they're subscribed, and I'd imagine most other subscribers (at
> >least to the BIND list) would take similar precautions if necessary.
>
> not everyone can set up such configuration and not everyone of those who can
> is willing to play with it.
> --
> Matus UHLAR - fantomas, uh...@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.
> Remember half the people you know are below average.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Test mail to bind-users

[Matus UHLAR - fantomas]

On Wed, 30 May 2018, Michael McNally wrote:

We have had reports that posts to bind-users are (in at least some
cases) triggering unwelcome direct-to-the-submitter messages from
spammers.


it was about time ;-)

On 31.05.18 08:28, G.W. Haywood via bind-users wrote:

I'm not sure that there's much that a list manager can do about it.


they can find the abusers relay posts to spam senders and remove them.

I have met similar case on IRC some 15-20 years ago. Spammer joined a
channel, and relayed nicknames of those who joined (or left) so they got
spam srom another nickname


This has been an issue for most of the lists to which I've subscribed
for decades.  My list addresses only accept mail from the lists to
which they're subscribed, and I'd imagine most other subscribers (at
least to the BIND list) would take similar precautions if necessary.


not everyone can set up such configuration and not everyone of those who can
is willing to play with it.
--
Matus UHLAR - fantomas, uh...@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.
Remember half the people you know are below average. 
___

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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Test mail to bind-users

[G.W. Haywood via bind-users]

Hi Michael,

On Wed, 30 May 2018, Michael McNally wrote:


We have had reports that posts to bind-users are (in at least some
cases) triggering unwelcome direct-to-the-submitter messages from
spammers.

Please disregard this message while I try to gather some information
in the hopes of stopping this unwelcome behavior.


I'm not sure that there's much that a list manager can do about it.

This has been an issue for most of the lists to which I've subscribed
for decades.  My list addresses only accept mail from the lists to
which they're subscribed, and I'd imagine most other subscribers (at
least to the BIND list) would take similar precautions if necessary.

--

73,
Ged.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

test of bind-users at 20180531.064208, please ignore

[marka]

Sorry for the noise
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Test mail to bind-users

[Michael McNally]

We have had reports that posts to bind-users are (in at least
some cases) triggering unwelcome direct-to-the-submitter messages
from spammers.

Please disregard this message while I try to gather some information
in the hopes of stopping this unwelcome behavior.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Test, please ignore

[Browne, Stuart]

I dunno, at this rate someone's going to have to owe someone a beer or 
something. :P

> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of John 
> W. Blue
> Sent: Monday, 21 November 2016 5:24 PM
> To: bind-us...@isc.org
> Subject: Re: Test, please ignore
> 
> Ignoring level currently at 100% of its original rated performance, beginning
> to throttle up to 104% but doing so under computer control.
> 
> Sent from Nine
> 
> > From: John Anderson <jo...@ccbill.com>
> > Sent: Nov 20, 2016 11:43 PM
> > To: Dan Mahoney <dmaho...@isc.org>;bind-us...@isc.org
> > Subject: RE: Test, please ignore
> > 
> > Ignore successful.
> > 
> > John A.
> > 
> > 
> > 
> > Sent from my T-Mobile 4G LTE Device
> > 
> > 
> > >  Original message ----
> > > From: Dan Mahoney <dmaho...@isc.org> 
> > > Date: 2016/11/20 21:38 (GMT-07:00) 
> > > To: bind-us...@isc.org 
> > > Subject: Test, please ignore 
> > > Sorry for the noise
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Test, please ignore

[John W. Blue]

Ignoring level currently at 100% of its original rated performance, beginning 
to throttle up to 104% but doing so under computer control.

Sent from Nine<http://www.9folders.com/>

From: John Anderson <jo...@ccbill.com>
Sent: Nov 20, 2016 11:43 PM
To: Dan Mahoney <dmaho...@isc.org>;bind-us...@isc.org
Subject: RE: Test, please ignore

Ignore successful.

John A.



Sent from my T-Mobile 4G LTE Device


 Original message 
From: Dan Mahoney <dmaho...@isc.org>
Date: 2016/11/20 21:38 (GMT-07:00)
To: bind-us...@isc.org
Subject: Test, please ignore

Sorry for the noise
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

test, please ignore

[marka]

Sorry for the noise
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

test, please ignore

[mark]

Sorry for the noise
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Test, please ignore

[John Anderson]

Ignore successful.

John A.



Sent from my T-Mobile 4G LTE Device


 Original message 
From: Dan Mahoney <dmaho...@isc.org>
Date: 2016/11/20 21:38 (GMT-07:00)
To: bind-us...@isc.org
Subject: Test, please ignore

Sorry for the noise
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Test, please ignore

[Dan Mahoney]

Sorry for the noise
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

network test machine

[Curtis Blackburn]

ISC's software testing procedures no longer use our Ixia XT80-V2, so
rather than letting it sit idle, we have offered it for sale on eBay:

http://www.ebay.com/itm/-/192000694217

If you don't know what an Ixia XT80 is then probably you don't need one,
but if you do, this is a really good price.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: This is a test. Please disregard.

[Benny Pedersen]

On 2016-08-26 07:09, project722 wrote:

syccessfully breaks dkim from gmail


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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

This is a test. Please disregard.

[project722]

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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Help required to test some Negative Responses from Bind Server.

[Tony Finch]

Alan Clegg  wrote:
>
> As for NOTIMP, I'm not aware of an easy path, but I'm sure that someone here
> knows.

; <<>> DiG 9.11.0a1 <<>> +noedns dotat.at in maila
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 42331
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dotat.at.  IN  MAILA

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Tue Jun 28 14:44:29 BST 2016
;; MSG SIZE  rcvd: 26

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Malin, Hebrides: South or southwest 6 or 7, decreasing 4 or 5. Moderate or
rough. Rain or showers. Good, occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Help required to test some Negative Responses from Bind Server.

[Alan Clegg]

SERVFAIL:   create a delegation NS record in your zone to a server that
isn't authoritative for the zone being delegated.
REFUSED:  create an ACL that matches (and denies) the query being done
NOERROR w/ no RR:   query for  example.com 

As for NOTIMP, I'm not aware of an easy path, but I'm sure that someone here
knows.

AlanC

On 6/28/16, 2:07 AM, "bind-users on behalf of Harshith Mulky"
<bind-users-boun...@lists.isc.org on behalf of harshith.mu...@outlook.com>
wrote:

> Hello Experts,
> 
> 
> 
> As a tester who is testing a client(lwres) developed on same bind stack.
> 
> I would want to generate scenarios and test how the client responds when the
> bind server responds with negative Responses
> 
> 
> 
> I was able to test Negative response like NXDOMAIN as it was straight forward
> where a record is not present in particular Domain file
> 
> 
> 
> I would want to test a scenario where bind Server responds with the following
> Response Codes
> 
> 
> 
> 1. SERVFAIL
> 
> 2. REFUSED
> 
> 3. Receiving NOERROR, but no RR in response
> 
> 4. NOTIMP
> 
> 
> 
> If I have a basic Zone file like this, Can I be able to test the above 4
> scenarios
> 
> 
> 
> 
> $ORIGIN example.com.
> $TTL 600
> @  IN  SOA atlanta.example.com. admin.example.com.  (
>   2003022720 ; Serial
>   56800  ; Refresh
>   14400  ; Retry
>   360; Expire
>   2h ); Minimum
> 
>   IN  NS  atlanta.example.com.
> 
> 
> atlanta.example.com.  IN A10.54.48.68
> 
> ; zone ims.blueslice.com direct  - for some phones
> ;srvtesting.com.   IN A10.128.254.115
> ;example.com.   IN A10.54.25.75
> 
> ;; order preference flags service regexp replacement.
> ;IN NAPTR   22   34   "u""SIP+D2U"   ""
> _sip._udp.test1.com.
> IN NAPTR   22   32   "u""SIP+D2U"   ""
> _sip._udp.example.com.
> IN NAPTR   22   32   "u""SIP+D2T"   ""
> _sip._tcp.example.com.
> ;IN NAPTR   45   56   "u""SIP+D2T"   ""
> _sip._tcp.srvtesting.com.
> ;IN NAPTR   45   56   "u""SIP+D2S"   ""
> _sip._sctp.srvtesting.com.
> 
> ; SRV records for each sip service
> ; service.prot.name   ttl class rr pri weight port target
> ;_sip._udp   IN  SRV  32  7700 denver.example.com.
> _sip._udp   IN  SRV   040  7701
> denver1.example.com.
> _sip._tcp   IN  SRV   040  7701
> denver1.example.com.
> _sip._udp   IN  SRV   010  7702
> denver2.example.com.
> _sip._udp   IN  SRV   110  7703
> denver3.example.com.
> _sip._udp   IN  SRV   210  7704
> denver4.example.com.
> _sip._tcp   IN  SRV  11  0
> icscf52.srvtesting.com.
> _sip._sctp  IN  SRV  11  12215
> icscf71.srvtesting.com.
> 
> 
> denver1.example.com.  IN A10.54.80.150
> denver1.example.com.  IN A10.54.80.17
> denver2.example.com.  IN A10.54.80.150
>   IN A10.54.80.35
> ;denver3.example.com.  IN    fd00:10:6b50:4500::88
> ;denver2.example.com.  IN    fd00:10:6b50:4500::21
> ;denver2.example.com.  IN    fd00:10:6b50:4500::22
> example.com.  IN A   10.54.80.150
> example.com.  IN    fd00:10:6b50:4500::88
> denver1.example.com.  IN    fd00:10:6b50:4500::88
> 
> 
> 
> Thanks
> 
> Harshith
> ___ Please visit
> https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this
> list bind-users mailing list bind-users@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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Help required to test some Negative Responses from Bind Server.

[Harshith Mulky]

Hello Experts,


As a tester who is testing a client(lwres) developed on same bind stack.

I would want to generate scenarios and test how the client responds when the 
bind server responds with negative Responses


I was able to test Negative response like NXDOMAIN as it was straight forward 
where a record is not present in particular Domain file


I would want to test a scenario where bind Server responds with the following 
Response Codes


1. SERVFAIL

2. REFUSED

3. Receiving NOERROR, but no RR in response

4. NOTIMP


If I have a basic Zone file like this, Can I be able to test the above 4 
scenarios



$ORIGIN example.com.
$TTL 600
@  IN  SOA atlanta.example.com. admin.example.com.  (
  2003022720 ; Serial
  56800  ; Refresh
  14400  ; Retry
  360; Expire
  2h ); Minimum

  IN  NS  atlanta.example.com.


atlanta.example.com.  IN A10.54.48.68

; zone ims.blueslice.com direct  - for some phones
;srvtesting.com.   IN A10.128.254.115
;example.com.   IN A10.54.25.75

;; order preference flags service regexp replacement.
;IN NAPTR   22   34   "u""SIP+D2U"   ""  
_sip._udp.test1.com.
IN NAPTR   22   32   "u""SIP+D2U"   ""  
_sip._udp.example.com.
IN NAPTR   22   32   "u""SIP+D2T"   ""  
_sip._tcp.example.com.
;IN NAPTR   45   56   "u""SIP+D2T"   ""  
_sip._tcp.srvtesting.com.
;IN NAPTR   45   56   "u""SIP+D2S"   ""  
_sip._sctp.srvtesting.com.

; SRV records for each sip service
; service.prot.name   ttl class rr pri weight port target
;_sip._udp   IN  SRV  32  7700 denver.example.com.
_sip._udp   IN  SRV   040  7701 denver1.example.com.
_sip._tcp   IN  SRV   040  7701 denver1.example.com.
_sip._udp   IN  SRV   010  7702 denver2.example.com.
_sip._udp   IN  SRV   110  7703 denver3.example.com.
_sip._udp   IN  SRV   210  7704 denver4.example.com.
_sip._tcp   IN  SRV  11  0 
icscf52.srvtesting.com.
_sip._sctp  IN  SRV  11  12215 
icscf71.srvtesting.com.


denver1.example.com.  IN A10.54.80.150
denver1.example.com.  IN A10.54.80.17
denver2.example.com.  IN A10.54.80.150
  IN A10.54.80.35
;denver3.example.com.  IN    fd00:10:6b50:4500::88
;denver2.example.com.  IN    fd00:10:6b50:4500::21
;denver2.example.com.  IN    fd00:10:6b50:4500::22
example.com.  IN A   10.54.80.150
example.com.  IN    fd00:10:6b50:4500::88
denver1.example.com.  IN    fd00:10:6b50:4500::88




Thanks

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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

9.10.4 build/test - one failure

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Building on centos/rhel 6, the build works, but

"make test" has one failure:

S:notify:Mon May  2 11:26:31 PDT 2016
T:notify:1:A
A:System test notify
I:checking initial status (1)
I:reloading with example2 using HUP and waiting up to 45 seconds
I:checking notify message was logged (2)
I:checking example2 loaded (3)
I:checking example2 contents have been transferred after HUP reload (4)
I:stopping master and restarting with example4 then waiting up to 45
seconds
I:checking notify message was logged (5)
I:checking example4 loaded (6)
I:checking example4 contents have been transfered after restart (7)
I:checking notify to alternate port with master inheritance
I:checking notify to multiple views using tsig
I:failed
I:exit status: 1
R:FAIL
E:notify:Mon May  2 11:26:55 PDT 2016



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlcnqCsACgkQL6j7milTFsFJlQCfVl8x1TIQrqKOzu//TxESQAgr
jvkAn0RFsGtlG6n1nbNzGd3vFxyq7eIp
=TiaL
-END PGP SIGNATURE-



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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

答复: Problem in Performance test

[RunxiaWan]

Thanks for relying me and sorry not to be so clearly. In my case, I run the
test twice every time to let the resolver cache the query. So this why I
feel it is weird cause as my concern, all the query should be cached during
the first test.



Best,
Runxia Wan
-邮件原件-
发件人: MURTARI, JOHN [mailto:jm5...@att.com] 
发送时间: 2016年1月15日 21:57
收件人: bind-users@lists.isc.org
抄送: rx...@biigroup.cn
主题: RE: Problem in Performance test

--- Original Msg -
From: "RunxiaWan" <wanrun...@aliyun.com>
Subject: Problem in Performance test

Hi all,
I am doing performance test for my company's resolver with BIND 9.10.3 and
find something weird. The test client and resolver are in the same LAN. When
I use a small set of domain as an input with a 1 per second query
sending rate, everything looks reasonable. However, when I use a set of
thousands of domains as an input, The QPS is unexpectedly low and the
latency is high. Here is the result from DNSperf:

  Queries sent: 11823
  Queries completed:11823 (100.00%)
  Queries lost: 0 (0.00%)

  Response codes:   NOERROR 9883 (83.59%), SERVFAIL 242 (2.05%),
NXDOMAIN 1698 (14.36%)
  Average packet size:  request 48, response 203
  Run time (s): 69.891567
  Queries per second:   169.162039

  Average Latency (s):  0.519502 (min 0.003766, max 211.981919)
  Latency StdDev (s):   1.423057

And when I decreased the query sending rate to 100 per second, the latency
decrease as the same when I use small set of domain as an input. Here is the
result from DNSperf:

Statistics:

  Queries sent: 6000
  Queries completed:6000 (100.00%)
  Queries lost: 0 (0.00%)

  Response codes:   NOERROR 4995 (83.25%), SERVFAIL 37 (0.62%), NXDOMAIN
968 (16.13%)
  Average packet size:  request 54, response 211
  Run time (s): 62.789257
  Queries per second:   95.557748

  Average Latency (s):  0.083028 (min 0.005266, max 134.543920)
  Latency StdDev (s):   0.568863

Anyone knows any explanation for this? Thanks.
---
Runxia Wan(Brian)
Research Engineer
BII Lab
Beijing Internet Institute(BII)
rx...@biigroup.cn
---

Few  things are affecting the resolver test:
1) A resolver is allowed to cache answers, in your small test of zones  it
may have done a series of iterative queries to find the answers, but once it
had the answers, future queries were answered from cache -- easy going and
high QPS, just limited by your memory/cpu performance.

2) When you added thousands of random sites it took it much longer to
perform all the look ups and begin storing cached results.  A much more
realistic test, but slower going.

3) Not sure if you stopped/started named after each test?  If you just left
it running, it still had many results cached and could use those in
subsequent tests.

4) UDP queue length - a realistic test would have several clients running
dnsperf and querying the same resolver.  As the resolver falls behind, the
UDP queue of waiting requests grows and some of those are just dropped by
the OS.

There's a lot going on under the hood!
Hope this helps!
John






-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/bind-users/attachments/20160115/f9cc36a7/at
tachment-0001.html>

--

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

End of bind-users Digest, Vol 2288, Issue 1
***

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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Problem in Performance test

[Tony Finch]

RunxiaWan  wrote:

> However, when I use a set of thousands of domains as an input, The QPS
> is unexpectedly low and the latency is high.

That would be normal if the cache is empty. Did you pre-populate it before
running the benchmark?

> And when I decreased the query sending rate to 100 per second, the latency
> decrease as the same when I use small set of domain as an input.

If you did that after running the previous benchmark, it is benefiting
from a populated cache.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Tyne, Dogger: Northwest 4 or 5, becoming cyclonic 6 to gale 8, occasionally
severe gale 9 in Dogger. Moderate, becoming rough or very rough. Wintry
showers. Good, occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Problem in Performance test

[MURTARI, JOHN]

--- Original Msg -
From: "RunxiaWan" <wanrun...@aliyun.com>
Subject: Problem in Performance test

Hi all,
I am doing performance test for my company's resolver with BIND 9.10.3 and
find something weird. The test client and resolver are in the same LAN. When
I use a small set of domain as an input with a 1 per second query
sending rate, everything looks reasonable. However, when I use a set of
thousands of domains as an input, The QPS is unexpectedly low and the
latency is high. Here is the result from DNSperf:

  Queries sent: 11823
  Queries completed:11823 (100.00%)
  Queries lost: 0 (0.00%)

  Response codes:   NOERROR 9883 (83.59%), SERVFAIL 242 (2.05%),
NXDOMAIN 1698 (14.36%)
  Average packet size:  request 48, response 203
  Run time (s): 69.891567
  Queries per second:   169.162039

  Average Latency (s):  0.519502 (min 0.003766, max 211.981919)
  Latency StdDev (s):   1.423057

And when I decreased the query sending rate to 100 per second, the latency
decrease as the same when I use small set of domain as an input. Here is the
result from DNSperf:

Statistics:

  Queries sent: 6000
  Queries completed:6000 (100.00%)
  Queries lost: 0 (0.00%)

  Response codes:   NOERROR 4995 (83.25%), SERVFAIL 37 (0.62%), NXDOMAIN
968 (16.13%)
  Average packet size:  request 54, response 211
  Run time (s): 62.789257
  Queries per second:   95.557748

  Average Latency (s):  0.083028 (min 0.005266, max 134.543920)
  Latency StdDev (s):   0.568863

Anyone knows any explanation for this? Thanks.
---
Runxia Wan(Brian)
Research Engineer
BII Lab
Beijing Internet Institute(BII)
rx...@biigroup.cn
---

Few  things are affecting the resolver test:
1) A resolver is allowed to cache answers, in your small test of zones  it may 
have done a series of iterative queries to find the answers, but once it had 
the answers, future queries were answered from cache -- easy going and high 
QPS, just limited by your memory/cpu performance.

2) When you added thousands of random sites it took it much longer to perform 
all the look ups and begin storing cached results.  A much more realistic test, 
but slower going.

3) Not sure if you stopped/started named after each test?  If you just left it 
running, it still had many results cached and could use those in subsequent 
tests.

4) UDP queue length - a realistic test would have several clients running 
dnsperf and querying the same resolver.  As the resolver falls behind, the UDP 
queue of waiting requests grows and some of those are just dropped by the OS.

There's a lot going on under the hood!
Hope this helps!
John






-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.isc.org/pipermail/bind-users/attachments/20160115/f9cc36a7/attachment-0001.html>

--

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

End of bind-users Digest, Vol 2288, Issue 1
***
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Problem in Performance test

[RunxiaWan]

Hi all,
I am doing performance test for my company's resolver with BIND 9.10.3 and
find something weird. The test client and resolver are in the same LAN. When
I use a small set of domain as an input with a 1 per second query
sending rate, everything looks reasonable. However, when I use a set of
thousands of domains as an input, The QPS is unexpectedly low and the
latency is high. Here is the result from DNSperf:

Statistics:

  Queries sent: 11823
  Queries completed:11823 (100.00%)
  Queries lost: 0 (0.00%)

  Response codes:   NOERROR 9883 (83.59%), SERVFAIL 242 (2.05%),
NXDOMAIN 1698 (14.36%)
  Average packet size:  request 48, response 203
  Run time (s): 69.891567
  Queries per second:   169.162039

  Average Latency (s):  0.519502 (min 0.003766, max 211.981919)
  Latency StdDev (s):   1.423057

And when I decreased the query sending rate to 100 per second, the latency
decrease as the same when I use small set of domain as an input. Here is the
result from DNSperf:

Statistics:

  Queries sent: 6000
  Queries completed:6000 (100.00%)
  Queries lost: 0 (0.00%)

  Response codes:   NOERROR 4995 (83.25%), SERVFAIL 37 (0.62%), NXDOMAIN
968 (16.13%)
  Average packet size:  request 54, response 211
  Run time (s): 62.789257
  Queries per second:   95.557748

  Average Latency (s):  0.083028 (min 0.005266, max 134.543920)
  Latency StdDev (s):   0.568863

Anyone knows any explanation for this? Thanks.




---
Runxia Wan(Brian)
Research Engineer
BII Lab
Beijing Internet Institute(BII)
rx...@biigroup.cn



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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

make test fails without Net::DNS::Nameserver

[Maria Iano]

I don't see this mentioned anywhere else, although I'm suprised by that
so maybe I'm missing something. When I build bind-9.10.2-P2 I find
that make test fails for reclimit with Couldn't start server ans2 if
I don't have Net::DNS::Nameserver installed. After I install it the
testing is successful.

Maria

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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: make test fails without Net::DNS::Nameserver

[Jeremy C. Reed]

On Tue, 14 Jul 2015, Maria Iano wrote:

 I don't see this mentioned anywhere else, although I'm suprised by that
 so maybe I'm missing something. When I build bind-9.10.2-P2 I find
 that make test fails for reclimit with Couldn't start server ans2 if
 I don't have Net::DNS::Nameserver installed. After I install it the
 testing is successful.

We recently added a bin/tests/system/reclimit/prereq.sh script to check 
for it.

CHANGES entry:

4113.   [test]  Check for Net::DNS is some system test
prerequisites. [RT #39369]
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Tools to automatically test the resolution speed ...

[Barry Greene]

Hi Team,

I'm going to get my team to script a tool to test the DNS resolution speed of 
our DNS Resolvers. Something that would give us a MRTG like output and can be 
used for KPIs. 

I use Namebench a lot for my own testing. Has anyone done any scripting with 
Namebench, GRC's DNS Benchmark, or any other tools? 

Thanks,

Barry




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Tools to automatically test the resolution speed ...

[Mike Hoskins (michoski)]

I haven't used those, but not sure if smokeping's DNS plugin would do what
you want.

-Original Message-
From: Barry Greene bgre...@senki.org
Date: Monday, July 21, 2014 at 11:59 PM
To: bind-users@lists.isc.org bind-users@lists.isc.org
Subject: Tools to automatically test the resolution speed ...

Hi Team,

I'm going to get my team to script a tool to test the DNS resolution
speed of our DNS Resolvers. Something that would give us a MRTG like
output and can be used for KPIs.

I use Namebench a lot for my own testing. Has anyone done any scripting
with Namebench, GRC's DNS Benchmark, or any other tools?

Thanks,

Barry



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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: test bind before moving to production

[Reindl Harald]

Am 04.07.2014 04:29, schrieb brian:
 I can't get this to work.  I'm trying to use the test url tst.com.  
 When I open it in my browser, I get a server not found error.
 
 In /etc/resolv.conf I changed nameserver 127.0.0.1

 I created the file /var/named/tst.com.zone and added:
 @   IN  NS  ns.example.com.
 ns  IN  A   127.0.0.1

there is no tst.com in that zone.file
there is just ns.tst.com pointing to 127.0.0.1




signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: test bind before moving to production

[Matus UHLAR - fantomas]

Am 04.07.2014 04:29, schrieb brian:

I can't get this to work.  I'm trying to use the test url tst.com.
When I open it in my browser, I get a server not found error.

In /etc/resolv.conf I changed nameserver 127.0.0.1

I created the file /var/named/tst.com.zone and added:
@   IN  NS  ns.example.com.
ns  IN  A   127.0.0.1


On 04.07.14 11:36, Reindl Harald wrote:

there is no tst.com in that zone.file


actually, there is - the @ means the current origin (which is the zone name
from config file definition unless you override it).
But it only contains NS record, no A (or )


there is just ns.tst.com pointing to 127.0.0.1


--
Matus UHLAR - fantomas, uh...@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.
Your mouse has moved. Windows NT will now restart for changes to take
to take effect. [OK]
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: test bind before moving to production

[Reindl Harald]

Am 04.07.2014 12:17, schrieb Matus UHLAR - fantomas:
 
 Am 04.07.2014 04:29, schrieb brian:
 I can't get this to work.  I'm trying to use the test url tst.com.
 When I open it in my browser, I get a server not found error.

 In /etc/resolv.conf I changed nameserver 127.0.0.1

 I created the file /var/named/tst.com.zone and added:
 @   IN  NS  ns.example.com.
 ns  IN  A   127.0.0.1
 
 On 04.07.14 11:36, Reindl Harald wrote:
 there is no tst.com in that zone.file
 
 actually, there is - the @ means the current origin 

tell me something new :-)

[root@ns2:~]$ ls named/zones/ | wc -l
521

 But it only contains NS record, no A (or )

and so there is no tst.com in that zone.file as i said

@  IN  A   127.0.0.1

would be the A record




signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

test bind before moving to production

[brian]

*I'm new to bind. I want to be able to test the dns server on my local 
machine before launching it by putting the domain names (ie example.com) 
in my browser and browsing the site.*



*Both the dev and production machines are CentOS. I assume I'll need to 
edit the host file to redirect to the local dns. But with this method 
I'm not sure how it will resolve multiple domains (i.e. example.com and 
example2.com).*



*I use a virtual box version of CentOS to run experiments so I can do a 
host/guest thing if needed. *



*There are 2 ways I'll use the dns in production. At the domain register 
I'll either point to this dns server or host the dns at the domain 
register and point the A record to the IP.*



*Brian*

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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users