Re: named hangs when trying to sign a large zone after upgrading to 9.18.28

[Ondřej Surý]

Hi Brian,

here are some hints what can you do to get more information of of the running 
`named` process:

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

Basically pstack / eu-stack and or gcore (or attaching gdb). It's important to 
have debugging symbols present, without them it's virtually impossible to debug 
the issue.

I would suggest you fill an issue in our GitLab (gitlab.isc.org 
) and we can continue there.

Also please include the information about previous BIND 9 version.

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.

> On 25. 7. 2024, at 12:02, Sebby, Brian A. via bind-users 
>  wrote:
> 
> I upgraded our DNS servers when the 9.18.28 release came out, and ran into a 
> problem today that I wanted to know if anyone else had seen or had any 
> suggestions about how to debug.
>  We have our DNS configured in a hidden primary configuration, where the 
> primary has internal and external views and serves and internal and external 
> copy of one of our domains.  The external version is fairly small, while the 
> internal version is significantly larger.  We use the same DNSSEC keys to 
> sign both versions of the domain.  Every once in a while, we have encountered 
> an issue where the unsigned and signed versions of the domain get out of 
> sync, which causes this message to appear in our logs (note that I have 
> modified all of the following log entries to replace our domain with 
> example.org):
>  25-Jul-2024 10:12:32.202 general: error: zone example.org/IN/internal 
> (signed): receive_secure_serial: not exact
>  The solution I’ve always been able to follow previously is to comment out 
> the DNSSEC config options in named.conf, restart named with the zone 
> unsigned, retransfer the unsigned zone to our secondaries, and then put back 
> the DNSSEC config options, restart named, and let it re-sign the zone.  It 
> takes a little bit, but normally everything has then gotten back to normal.
>  Today, however, when I tried to do that, it started to sign the zone – and 
> then named just hung.  It stopped updating any of the log files, stopped 
> sending any notifies, and stopped returning DNS data of any sort.  When I 
> tried to restart named via systemctl it had to kill the process because named 
> would not respond.  I was able to undo the DNSSEC changes, restart named, and 
> it continued to work.  I tried it again, and named hung once again in the 
> middle of signing the zone.  Throughout all of these restarts, the signed 
> version of the external zone continued to work normally.
>  This is frustrating because when named hangs, there are no error messages in 
> the logs that I can see, and no indication of why it has failed.   If I try 
> running rndc commands locally I get this error:
>  rndc: recv failed: timed out
>  Remote servers show a timeout and then I saw this in some of their transfer 
> logs:
>  25-Jul-2024 10:27:01.827 general: info: zone example.org/IN: refresh: 
> skipping zone transfer as primary A.B.C.D#53 (source E.F.G.H#0) is 
> unreachable (cached)
>  I was able to solve that one by sending notifies from the primary after 
> restarting it without DNSSEC, but I really need to get DNSSEC working again.
>  The configuration for the zone in named.conf is (and yes, I know I need to 
> update to dnssec-policy):
>  view "internal" {
> ...
> zone "example.org" {
> type primary;
> file "/path/to/internal/example.org";
>key-directory "/path/to/keys";
>auto-dnssec maintain;
>inline-signing yes;
> };
> ...
> };
>  Does anyone have any suggestions for putting named into a debug mode to try 
> to get more data if it hangs again?  I was thinking of turning the DNSSEC 
> options back on but setting “notify no” so it didn’t try to notify the 
> secondaries in case all of the notifies and zone transfers going on while it 
> was signing was part of the problem.
>  The memory and CPU resources of the system should be sufficient – it’s got 2 
> virtual CPUs and 8GB of memory, but it’s not close to using up the memory, 
> and since it doesn’t have clients, the CPU has never been an issue before.  I 
> tried replicating this issue on our test server but it managed to sign the 
> zone with no problems – though it doesn’t have as many clients.
>  I don’t think the new max-records-per-type or max-types-per-name options are 
> involved as we don’t have any cases where we have that many records with the 
> same name.
>   Thanks,
>  Brian
>  -- 
> Brian Sebby (he/him/his)  |  Lead Systems Engineer
> Email: se...@anl.gov  |  Information Technology Infrastructure
> Phone: +1 630.252.9935|  Business Information Services
> Cell:  +1 630.921.4305|  Argonne National Laboratory
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users 

named hangs when trying to sign a large zone after upgrading to 9.18.28

[Sebby, Brian A. via bind-users]

I upgraded our DNS servers when the 9.18.28 release came out, and ran into a 
problem today that I wanted to know if anyone else had seen or had any 
suggestions about how to debug.

We have our DNS configured in a hidden primary configuration, where the primary 
has internal and external views and serves and internal and external copy of 
one of our domains.  The external version is fairly small, while the internal 
version is significantly larger.  We use the same DNSSEC keys to sign both 
versions of the domain.  Every once in a while, we have encountered an issue 
where the unsigned and signed versions of the domain get out of sync, which 
causes this message to appear in our logs (note that I have modified all of the 
following log entries to replace our domain with example.org):

25-Jul-2024 10:12:32.202 general: error: zone example.org/IN/internal (signed): 
receive_secure_serial: not exact

The solution I’ve always been able to follow previously is to comment out the 
DNSSEC config options in named.conf, restart named with the zone unsigned, 
retransfer the unsigned zone to our secondaries, and then put back the DNSSEC 
config options, restart named, and let it re-sign the zone.  It takes a little 
bit, but normally everything has then gotten back to normal.

Today, however, when I tried to do that, it started to sign the zone – and then 
named just hung.  It stopped updating any of the log files, stopped sending any 
notifies, and stopped returning DNS data of any sort.  When I tried to restart 
named via systemctl it had to kill the process because named would not respond. 
 I was able to undo the DNSSEC changes, restart named, and it continued to 
work.  I tried it again, and named hung once again in the middle of signing the 
zone.  Throughout all of these restarts, the signed version of the external 
zone continued to work normally.

This is frustrating because when named hangs, there are no error messages in 
the logs that I can see, and no indication of why it has failed.   If I try 
running rndc commands locally I get this error:

rndc: recv failed: timed out

Remote servers show a timeout and then I saw this in some of their transfer 
logs:

25-Jul-2024 10:27:01.827 general: info: zone example.org/IN: refresh: skipping 
zone transfer as primary A.B.C.D#53 (source E.F.G.H#0) is unreachable (cached)

I was able to solve that one by sending notifies from the primary after 
restarting it without DNSSEC, but I really need to get DNSSEC working again.

The configuration for the zone in named.conf is (and yes, I know I need to 
update to dnssec-policy):

view "internal" {
...
zone "example.org" {
type primary;
file "/path/to/internal/example.org";
   key-directory "/path/to/keys";
   auto-dnssec maintain;
   inline-signing yes;
};
...
};

Does anyone have any suggestions for putting named into a debug mode to try to 
get more data if it hangs again?  I was thinking of turning the DNSSEC options 
back on but setting “notify no” so it didn’t try to notify the secondaries in 
case all of the notifies and zone transfers going on while it was signing was 
part of the problem.

The memory and CPU resources of the system should be sufficient – it’s got 2 
virtual CPUs and 8GB of memory, but it’s not close to using up the memory, and 
since it doesn’t have clients, the CPU has never been an issue before.  I tried 
replicating this issue on our test server but it managed to sign the zone with 
no problems – though it doesn’t have as many clients.

I don’t think the new max-records-per-type or max-types-per-name options are 
involved as we don’t have any cases where we have that many records with the 
same name.


Thanks,

Brian

--
Brian Sebby (he/him/his)  |  Lead Systems Engineer
Email: se...@anl.gov  |  Information Technology 
Infrastructure
Phone: +1 630.252.9935|  Business Information Services
Cell:  +1 630.921.4305|  Argonne National Laboratory
-- 
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: informing about potentially breaking security fixes

[Petr Špaček]

Hi,

we are always trying to improve!

We thought that mentioning it in the release announcement e-mail and in 
the release notes is enough. What other channel we failed to consider?


Thank you for constructive suggestions.
Petr Špaček
Internet Systems Consortium


On 25. 07. 24 15:08, Veronique Lefebure wrote:

Hi,
We had the same issue as James, fortunately with no impact on production.
But I agree that , although I finally found the warning at the very 
bottom of the mail announcing the new release,  this MAJOR change should 
have been announced more clearly.
How do you find out whether or not you have domains with more than 100 
records?
I myself was not aware of that until our domain got dropped (on a 
non-production server, luckily)


cheers,
Veronique



*From:* bind-users  on behalf of 
bind-users-requ...@lists.isc.org 

*Sent:* Thursday, July 25, 2024 2:00 PM
*To:* bind-users@lists.isc.org 
*Subject:* bind-users Digest, Vol 4516, Issue 1
Send bind-users mailing list submissions to
     bind-users@lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/bind-users 


or, via email, send a message with subject or body 'help' to
     bind-users-requ...@lists.isc.org

You can reach the person managing the list at
     bind-users-ow...@lists.isc.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bind-users digest..."


Today's Topics:

    1. Re: New BIND releases are available: 9.18.28, 9.20.0 (Ond?ej Sur?)


--

Message: 1
Date: Wed, 24 Jul 2024 06:09:14 -0700
From: Ond?ej Sur? 
To: James Stegemeyer 
Cc: bind-users@lists.isc.org
Subject: Re: New BIND releases are available: 9.18.28, 9.20.0
Message-ID: 
Content-Type: text/plain;   charset=utf-8

Hi James,

I understand this has caused you some discomfort, but it was documented both
in the release notes and in the announcement and it was necessary to 
introduce
the limits because more fix would have to be intrusive refactoring of 
the internals,

and that is exactly the thing that we were trying to avoid.

As for your suggestion to ship the BIND 9 in a vulnerable state - that 
would be

absolutely wrong thing to do. We released the new version to make sure the
BIND 9 is not vulnerable in the default configuration and administrators 
might
assess the risks when increasing the value of the max-types-per-name for 
their

particular environment.

Cheers,
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.


 > On 24. 7. 2024, at 4:18, James Stegemeyer  wrote:
 >
 > Thanks for the new release, and the hard work you do.
 >
 > I recently upgraded from 9.18.24 to 9.18.28 per prompting by Ubuntu 
USN-6909-1 to preform a security update.  I deployed this into 
production after passing some tests when installed in a lab.  After the 
upgrade, Internal Zones that were hosted by Windows Active Directory 
were rejected and caused a production impact.  Under Windows Active 
Directory, the DC's create a round robin DNS record at the apex of the 
zone and the number of entries approximately match the number of DC's in 
the domain.  It is not uncommon to have hundreds of DC's in a domain, so 
setting a limit of 100 will likely cause a series of unexpected outages 
for IT administrators.   Because this change restricts existing 
functionality, This is a breaking change and as such should be reserved 
to a minor release. If this feature was critical to resolve an issue a 
provider was having, it should be shipped with default values of 0 
causing it to be effectively disabled allowing the provider to opt 
in.I
   was able to resolve this issue by adding the following directive to 
the affected views:

 > max-types-per-name 1000;
 >
 > --James
 >
 >
 >
 > --
 > 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 





--

Subject: Digest Footer

___
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: bind-users Digest, Vol 4516, Issue 1

[James Stegemeyer]

Veronique,


There are two restrictions:

max-types-per-name 100; (Unlikely to cause issues)
max-records-per-type 100;
So to list the counts of each each name you could use the following command:

dig -t axfr $zone  @$server | awk '{print $1,$4}' | sort | uniq -c | sort -n


Where $zone is zone FQDN and $server is DNS server.
When I ran this command the following two entries had the highest counts:


NNN _ldap._tcp.DomainDnsZones.~~~.com

NNN _ldap._tcp.ForestDnsZones.~~~.com

Thanks,
--James


On 7/25/24 09:08, Veronique Lefebure wrote:

Hi,
We had the same issue as James, fortunately with no impact on production.
But I agree that , although I finally found the warning at the very 
bottom of the mail announcing the new release,  this MAJOR change 
should have been announced more clearly.
How do you find out whether or not you have domains with more than 100 
records?
I myself was not aware of that until our domain got dropped (on a 
non-production server, luckily)


cheers,
Veronique



*From:* bind-users  on behalf of 
bind-users-requ...@lists.isc.org 

*Sent:* Thursday, July 25, 2024 2:00 PM
*To:* bind-users@lists.isc.org 
*Subject:* bind-users Digest, Vol 4516, Issue 1
Send bind-users mailing list submissions to
bind-users@lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/bind-users 


or, via email, send a message with subject or body 'help' to
bind-users-requ...@lists.isc.org

You can reach the person managing the list at
bind-users-ow...@lists.isc.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bind-users digest..."


Today's Topics:

   1. Re: New BIND releases are available: 9.18.28, 9.20.0 (Ond?ej Sur?)


--

Message: 1
Date: Wed, 24 Jul 2024 06:09:14 -0700
From: Ond?ej Sur? 
To: James Stegemeyer 
Cc: bind-users@lists.isc.org
Subject: Re: New BIND releases are available: 9.18.28, 9.20.0
Message-ID: 
Content-Type: text/plain;   charset=utf-8

Hi James,

I understand this has caused you some discomfort, but it was 
documented both
in the release notes and in the announcement and it was necessary to 
introduce
the limits because more fix would have to be intrusive refactoring of 
the internals,

and that is exactly the thing that we were trying to avoid.

As for your suggestion to ship the BIND 9 in a vulnerable state - that 
would be

absolutely wrong thing to do. We released the new version to make sure the
BIND 9 is not vulnerable in the default configuration and 
administrators might
assess the risks when increasing the value of the max-types-per-name 
for their

particular environment.

Cheers,
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.


> On 24. 7. 2024, at 4:18, James Stegemeyer  wrote:
>
> Thanks for the new release, and the hard work you do.
>
> I recently upgraded from 9.18.24 to 9.18.28 per prompting by Ubuntu 
USN-6909-1 to preform a security update.  I deployed this into 
production after passing some tests when installed in a lab.  After 
the upgrade, Internal Zones that were hosted by Windows Active 
Directory were rejected and caused a production impact.  Under Windows 
Active Directory, the DC's create a round robin DNS record at the apex 
of the zone and the number of entries approximately match the number 
of DC's in the domain. It is not uncommon to have hundreds of DC's in 
a domain, so setting a limit of 100 will likely cause a series of 
unexpected outages for IT administrators.   Because this change 
restricts existing functionality, This is a breaking change and as 
such should be reserved to a minor release. If this feature was 
critical to resolve an issue a provider was having, it should be 
shipped with default values of 0 causing it to be effectively disabled 
allowing the provider to opt in.I
  was able to resolve this issue by adding the following directive to 
the affected views:

> max-types-per-name 1000;
>
> --James
>
>
>
> --
> 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 





--

Subject: Digest Footer

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

Re: bind-users Digest, Vol 4516, Issue 1

[Veronique Lefebure]

Hi,
We had the same issue as James, fortunately with no impact on production.
But I agree that , although I finally found the warning at the very bottom of 
the mail announcing the new release,  this MAJOR change should have been 
announced more clearly.
How do you find out whether or not you have domains with more than 100 records?
I myself was not aware of that until our domain got dropped (on a 
non-production server, luckily)

cheers,
Veronique



From: bind-users  on behalf of 
bind-users-requ...@lists.isc.org 
Sent: Thursday, July 25, 2024 2:00 PM
To: bind-users@lists.isc.org 
Subject: bind-users Digest, Vol 4516, Issue 1

Send bind-users mailing list submissions to
bind-users@lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/bind-users
or, via email, send a message with subject or body 'help' to
bind-users-requ...@lists.isc.org

You can reach the person managing the list at
bind-users-ow...@lists.isc.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bind-users digest..."


Today's Topics:

   1. Re: New BIND releases are available: 9.18.28, 9.20.0 (Ond?ej Sur?)


--

Message: 1
Date: Wed, 24 Jul 2024 06:09:14 -0700
From: Ond?ej Sur? 
To: James Stegemeyer 
Cc: bind-users@lists.isc.org
Subject: Re: New BIND releases are available: 9.18.28, 9.20.0
Message-ID: 
Content-Type: text/plain;   charset=utf-8

Hi James,

I understand this has caused you some discomfort, but it was documented both
in the release notes and in the announcement and it was necessary to introduce
the limits because more fix would have to be intrusive refactoring of the 
internals,
and that is exactly the thing that we were trying to avoid.

As for your suggestion to ship the BIND 9 in a vulnerable state - that would be
absolutely wrong thing to do. We released the new version to make sure the
BIND 9 is not vulnerable in the default configuration and administrators might
assess the risks when increasing the value of the max-types-per-name for their
particular environment.

Cheers,
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.

> On 24. 7. 2024, at 4:18, James Stegemeyer  wrote:
>
> Thanks for the new release, and the hard work you do.
>
> I recently upgraded from 9.18.24 to 9.18.28 per prompting by Ubuntu 
> USN-6909-1 to preform a security update.  I deployed this into production 
> after passing some tests when installed in a lab.  After the upgrade, 
> Internal Zones that were hosted by Windows Active Directory were rejected and 
> caused a production impact.  Under Windows Active Directory, the DC's create 
> a round robin DNS record at the apex of the zone and the number of entries 
> approximately match the number of DC's in the domain.  It is not uncommon to 
> have hundreds of DC's in a domain, so setting a limit of 100 will likely 
> cause a series of unexpected outages for IT administrators.   Because this 
> change restricts existing functionality, This is a breaking change and as 
> such should be reserved to a minor release. If this feature was critical to 
> resolve an issue a provider was having, it should be shipped with default 
> values of 0 causing it to be effectively disabled allowing the provider to 
> opt in.I
  was able to resolve this issue by adding the following directive to the 
affected views:
> max-types-per-name 1000;
>
> --James
>
>
>
> --
> 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



--

Subject: Digest Footer

___
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


--

End of bind-users Digest, Vol 4516, Issue 1
***
-- 
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: New BIND releases are available: 9.18.28, 9.20.0

[Ondřej Surý]

Hi James,

I understand this has caused you some discomfort, but it was documented both
in the release notes and in the announcement and it was necessary to introduce
the limits because more fix would have to be intrusive refactoring of the 
internals,
and that is exactly the thing that we were trying to avoid.

As for your suggestion to ship the BIND 9 in a vulnerable state - that would be
absolutely wrong thing to do. We released the new version to make sure the
BIND 9 is not vulnerable in the default configuration and administrators might
assess the risks when increasing the value of the max-types-per-name for their
particular environment.

Cheers,
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.

> On 24. 7. 2024, at 4:18, James Stegemeyer  wrote:
> 
> Thanks for the new release, and the hard work you do.
> 
> I recently upgraded from 9.18.24 to 9.18.28 per prompting by Ubuntu 
> USN-6909-1 to preform a security update.  I deployed this into production 
> after passing some tests when installed in a lab.  After the upgrade, 
> Internal Zones that were hosted by Windows Active Directory were rejected and 
> caused a production impact.  Under Windows Active Directory, the DC's create 
> a round robin DNS record at the apex of the zone and the number of entries 
> approximately match the number of DC's in the domain.  It is not uncommon to 
> have hundreds of DC's in a domain, so setting a limit of 100 will likely 
> cause a series of unexpected outages for IT administrators.   Because this 
> change restricts existing functionality, This is a breaking change and as 
> such should be reserved to a minor release. If this feature was critical to 
> resolve an issue a provider was having, it should be shipped with default 
> values of 0 causing it to be effectively disabled allowing the provider to 
> opt in.I was able to resolve this issue by adding the 
> following directive to the affected views:
> max-types-per-name 1000;
> 
> --James
> 
> 
> 
> -- 
> 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: New BIND releases are available: 9.18.28, 9.20.0

[James Stegemeyer]

I should have said, I changed the following parameter to resolve the issue:

max-records-per-type 1000;

--James

On 7/24/24 07:18, James Stegemeyer wrote:


Thanks for the new release, and the hard work you do.

I recently upgraded from 9.18.24 to 9.18.28 per prompting by Ubuntu 
USN-6909-1 to preform a security update.  I deployed this into 
production after passing some tests when installed in a lab.  After 
the upgrade, Internal Zones that were hosted by Windows Active 
Directory were rejected and caused a production impact.  Under Windows 
Active Directory, the DC's create a round robin DNS record at the apex 
of the zone and the number of entries approximately match the number 
of DC's in the domain. It is not uncommon to have hundreds of DC's in 
a domain, so setting a limit of 100 will likely cause a series of 
unexpected outages for IT administrators.   Because this change 
restricts existing functionality, This is a breaking change and as 
such should be reserved to a minor release. If this feature was 
critical to resolve an issue a provider was having, it should be 
shipped with default values of 0 causing it to be effectively disabled 
allowing the provider to opt in.


I was able to resolve this issue by adding the following directive to 
the affected views:

max-types-per-name 1000;

--James




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

New BIND releases are available: 9.18.28, 9.20.0

[James Stegemeyer]

Thanks for the new release, and the hard work you do.

I recently upgraded from 9.18.24 to 9.18.28 per prompting by Ubuntu 
USN-6909-1 to preform a security update.  I deployed this into 
production after passing some tests when installed in a lab. After the 
upgrade, Internal Zones that were hosted by Windows Active Directory 
were rejected and caused a production impact. Under Windows Active 
Directory, the DC's create a round robin DNS record at the apex of the 
zone and the number of entries approximately match the number of DC's in 
the domain.  It is not uncommon to have hundreds of DC's in a domain, so 
setting a limit of 100 will likely cause a series of unexpected outages 
for IT administrators.   Because this change restricts existing 
functionality, This is a breaking change and as such should be reserved 
to a minor release. If this feature was critical to resolve an issue a 
provider was having, it should be shipped with default values of 0 
causing it to be effectively disabled allowing the provider to opt in.


I was able to resolve this issue by adding the following directive to 
the affected views:

max-types-per-name 1000;

--James



-- 
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: New BIND releases are available: 9.18.28, 9.20.0

[Adam Augustine]

I should have refreshed my email before hitting reply.

Thanks Victoria! That is a great summary and I totally agree with the
direction stated.

I don't know that it needs to be included in the announcement itself,
but maybe a link in the announcement to an article describing how it
works on an ongoing basis (not just for the 9.18->9.20 transition)
would be good. That would most likely have shown up at the top of the
results when I searched.

But really, it is on me for not knowing and failing to be thorough
when the list already answered the question a month ago.

On Tue, Jul 23, 2024 at 12:24 PM Victoria Risk  wrote:
>
> Adam,
>
> > What is the proper mapping of "Current Stable, ESV", "Development", and 
> > "New Stable" BIND versions to their respective COPR repos? I feel like it 
> > should be obvious, but I am missing something.
>
> I did consider whether we should summarize this in the announcement. Perhaps 
> I should have. It is confusing but as Ondřej pointed out, it was discussed 
> here, and was intentional for user benefit. We think that most users are 
> unlikely to want to swap their production environment from one stable version 
> to a new .0 stable version the day it is released, so this design was 
> supposed to minimize surprise major version upgrades.
>
> BIND 9.20.0 is in the bind-dev repositories, because it is the least delta vs 
> the last development release on 9.19. There is no new 9.19 version released 
> today, so that == 9.20.0. So, IF you are using 9.19.x in a production 
> environment, you should update to 9.20 to fix any CVEs that may apply in your 
> situation.
>
> now (July 2024)
> bind = 9.18
> bind-esv = 9.18
> bind-dev = 9.20.0
>
> later (once we have a new 9.21 version, August?? 2024)
> bind = 9.20.x
> bind-esv = 9.18.x
> bind-dev = 9.21.x
>
> I hope this is a bit clearer. Sorry for not including this in the 
> announcement.
>
> Vicky
>
> > On Jul 23, 2024, at 10:31 AM, Ondřej Surý  wrote:
> >
> > Hi Adam,
> >
> > this was discussed a month ago:
> >
> > https://lists.isc.org/pipermail/bind-users/2024-June/108638.html
> >
> > and we were basically asked to make the bumps in the repositories to not 
> > follow the releases.
> >
> > 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.
> >
> >> On 23. 7. 2024, at 10:17, Adam Augustine  wrote:
> >>
> >> First, thank you all for the hard work you do on BIND.
> >>
> >> What is the proper mapping of "Current Stable, ESV", "Development", and 
> >> "New Stable" BIND versions to their respective COPR repos? I feel like it 
> >> should be obvious, but I am missing something.
> >>
> >> I think I expected 9.18.28 to appear in isc/bind-esv with this release 
> >> (which it does) and for 9.20.0 to appear in isc/bind (which it doesn't, as 
> >> far as I can tell anyway). 9.18.28 does appear in isc/bind as well as in 
> >> isc/bind-esv, which seems reasonable (though the "07776636-isc-bind-bind" 
> >> directory is hidden in isc/bind, it is accessible and referenced in the 
> >> respective repo xml files). I recognize that a direct upgrade from 9.18 to 
> >> 9.20 for those on the isc/bind repo might be a bit surprising at this 
> >> point, despite the very clear messaging about how the versioning is meant 
> >> to work, but at the same time, I wouldn't expect we want people using the 
> >> isc/bind-dev repo to get 9.20.0 for production use either.
> >>
> >> I don't recall how this transition was handled for 9.16->9.18, but if I 
> >> recall it seemed like it just magically worked for us. But back then we 
> >> weren't as aggressive about updating as we are now. I probably just missed 
> >> some explanation somewhere about how the transition is meant to be 
> >> handled, but my searches aren't returning anything specific to this 
> >> situation. Speaking of which, is there an equivalent to the 
> >> https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918
> >>  article for 9.18->9.20?
> >>
> >> We have already upgraded most of our systems to 9.18.28, but want to move 
> >> to 9.20.0 soon, but aren't certain the right way forward.
> >>
> >> Thanks again for this release. I know refactoring code is extremely 
> >> challenging and doesn't get the praise it deserves.
> >>
>
-- 
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: New BIND releases are available: 9.18.28, 9.20.0

[Adam Augustine]

Ah, thank you! I knew I was missing something. The mailing list should
have been my first place to look. I should have specified
"site:lists.isc.org/pipermail/bind-users/" in my searches.

To summarize the thread Ondřej referenced, this bit from Michał Kępień
explains the plan:

"While I don't have a specific date for you, we plan to do such a
"rollover" again when BIND 9.20.1 or 9.20.2 gets released, i.e. in about
2-3 months from now.  We will definitely roll all three repositories at
the same time, i.e.:

  - "bind-esv" will move from 9.16 to 9.18,
  - "bind" will move from 9.18 to 9.20,
  - "bind-dev" will move from 9.19/9.20 to 9.21."

Then this paragraph from Ondřej Surý himself:
"The current plan is that on next Wednesday (next week)
[ed:2024-06-26], the bind-esv repositories will
be bumped from 9.16 to 9.18, the 'bind' repository will stay on 9.18
until 9.20 is released,
and we'll probably stick with Michał's plan to do the bump around
9.20.1 or 9.20.2 release,
probably mid 9.20.1-9.20.2 release cycle as you suggested."

So we will look for 9.20.1 or .2 in the isc/bind repo in the next few
months. The update plan is very sensible to me.

Thanks again! You are doing great work.


On Tue, Jul 23, 2024 at 11:32 AM Ondřej Surý  wrote:
>
> Hi Adam,
>
> this was discussed a month ago:
>
> https://lists.isc.org/pipermail/bind-users/2024-June/108638.html
>
> and we were basically asked to make the bumps in the repositories to not 
> follow the releases.
>
> 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.
>
> > On 23. 7. 2024, at 10:17, Adam Augustine  wrote:
> >
> > First, thank you all for the hard work you do on BIND.
> >
> > What is the proper mapping of "Current Stable, ESV", "Development", and 
> > "New Stable" BIND versions to their respective COPR repos? I feel like it 
> > should be obvious, but I am missing something.
> >
> > I think I expected 9.18.28 to appear in isc/bind-esv with this release 
> > (which it does) and for 9.20.0 to appear in isc/bind (which it doesn't, as 
> > far as I can tell anyway). 9.18.28 does appear in isc/bind as well as in 
> > isc/bind-esv, which seems reasonable (though the "07776636-isc-bind-bind" 
> > directory is hidden in isc/bind, it is accessible and referenced in the 
> > respective repo xml files). I recognize that a direct upgrade from 9.18 to 
> > 9.20 for those on the isc/bind repo might be a bit surprising at this 
> > point, despite the very clear messaging about how the versioning is meant 
> > to work, but at the same time, I wouldn't expect we want people using the 
> > isc/bind-dev repo to get 9.20.0 for production use either.
> >
> > I don't recall how this transition was handled for 9.16->9.18, but if I 
> > recall it seemed like it just magically worked for us. But back then we 
> > weren't as aggressive about updating as we are now. I probably just missed 
> > some explanation somewhere about how the transition is meant to be handled, 
> > but my searches aren't returning anything specific to this situation. 
> > Speaking of which, is there an equivalent to the 
> > https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918
> >  article for 9.18->9.20?
> >
> > We have already upgraded most of our systems to 9.18.28, but want to move 
> > to 9.20.0 soon, but aren't certain the right way forward.
> >
> > Thanks again for this release. I know refactoring code is extremely 
> > challenging and doesn't get the praise it deserves.
> >
> > On Tue, Jul 23, 2024 at 7:30 AM Victoria Risk  wrote:
> > BIND users-
> >
> > Our July 2024 maintenance release of BIND 9.18, as well as the new 9.20.0 
> > stable branch, are available and can be downloaded from the ISC software 
> > download page, https://www.isc.org/download.
> >
> > In addition to bug fixes and feature improvements, these releases also 
> > contain fixes for security vulnerabilities (CVE-2024-0760, CVE-2024-1737, 
> > CVE-2024-1975, CVE-2024-4076), about which more information is provided in 
> > the following Security Advisories:
> >
> > https://kb.isc.org/docs/cve-2024-0760
> > https://kb.isc.org/docs/cve-2024-1737
> > https://kb.isc.org/docs/cve-2024-1975
> > https://kb.isc.org/docs/cve-2024-4076
> >
> > A summary of significant changes in the new releases can be found in their 
> > release notes:
> >
> >   - Current supported stable branches:
> >
> > 9.18.28 - 
> > https://downloads.isc.org/isc/bind9/9.18.28/doc/arm/html/notes.html
> > 9.20.0  - 
> > https://downloads.isc.org/isc/bind9/9.20.0/doc/arm/html/notes.html
> >
> > We also have a nice blog post from Ondřej Surý on the 9.20.0 release, 
> > including performance testing results 
> > (https://www.isc.org/blogs/2024-bind920/).
> >
> > ---
> > Please Note:
> >
> > To create an effective mitigation for CVE-2024-1737 we have introduced two 
> > new 

Re: New BIND releases are available: 9.18.28, 9.20.0

[Victoria Risk]

Adam,

> What is the proper mapping of "Current Stable, ESV", "Development", and "New 
> Stable" BIND versions to their respective COPR repos? I feel like it should 
> be obvious, but I am missing something.

I did consider whether we should summarize this in the announcement. Perhaps I 
should have. It is confusing but as Ondřej pointed out, it was discussed here, 
and was intentional for user benefit. We think that most users are unlikely to 
want to swap their production environment from one stable version to a new .0 
stable version the day it is released, so this design was supposed to minimize 
surprise major version upgrades.

BIND 9.20.0 is in the bind-dev repositories, because it is the least delta vs 
the last development release on 9.19. There is no new 9.19 version released 
today, so that == 9.20.0. So, IF you are using 9.19.x in a production 
environment, you should update to 9.20 to fix any CVEs that may apply in your 
situation.  

now (July 2024)
bind = 9.18
bind-esv = 9.18
bind-dev = 9.20.0

later (once we have a new 9.21 version, August?? 2024)
bind = 9.20.x
bind-esv = 9.18.x
bind-dev = 9.21.x

I hope this is a bit clearer. Sorry for not including this in the announcement.

Vicky

> On Jul 23, 2024, at 10:31 AM, Ondřej Surý  wrote:
> 
> Hi Adam,
> 
> this was discussed a month ago:
> 
> https://lists.isc.org/pipermail/bind-users/2024-June/108638.html
> 
> and we were basically asked to make the bumps in the repositories to not 
> follow the releases.
> 
> 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.
> 
>> On 23. 7. 2024, at 10:17, Adam Augustine  wrote:
>> 
>> First, thank you all for the hard work you do on BIND.
>> 
>> What is the proper mapping of "Current Stable, ESV", "Development", and "New 
>> Stable" BIND versions to their respective COPR repos? I feel like it should 
>> be obvious, but I am missing something.
>> 
>> I think I expected 9.18.28 to appear in isc/bind-esv with this release 
>> (which it does) and for 9.20.0 to appear in isc/bind (which it doesn't, as 
>> far as I can tell anyway). 9.18.28 does appear in isc/bind as well as in 
>> isc/bind-esv, which seems reasonable (though the "07776636-isc-bind-bind" 
>> directory is hidden in isc/bind, it is accessible and referenced in the 
>> respective repo xml files). I recognize that a direct upgrade from 9.18 to 
>> 9.20 for those on the isc/bind repo might be a bit surprising at this point, 
>> despite the very clear messaging about how the versioning is meant to work, 
>> but at the same time, I wouldn't expect we want people using the 
>> isc/bind-dev repo to get 9.20.0 for production use either.
>> 
>> I don't recall how this transition was handled for 9.16->9.18, but if I 
>> recall it seemed like it just magically worked for us. But back then we 
>> weren't as aggressive about updating as we are now. I probably just missed 
>> some explanation somewhere about how the transition is meant to be handled, 
>> but my searches aren't returning anything specific to this situation. 
>> Speaking of which, is there an equivalent to the 
>> https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918
>>  article for 9.18->9.20? 
>> 
>> We have already upgraded most of our systems to 9.18.28, but want to move to 
>> 9.20.0 soon, but aren't certain the right way forward.
>> 
>> Thanks again for this release. I know refactoring code is extremely 
>> challenging and doesn't get the praise it deserves.
>> 

-- 
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: New BIND releases are available: 9.18.28, 9.20.0

[Ondřej Surý]

Hi Adam,

this was discussed a month ago:

https://lists.isc.org/pipermail/bind-users/2024-June/108638.html

and we were basically asked to make the bumps in the repositories to not follow 
the releases.

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.

> On 23. 7. 2024, at 10:17, Adam Augustine  wrote:
> 
> First, thank you all for the hard work you do on BIND.
> 
> What is the proper mapping of "Current Stable, ESV", "Development", and "New 
> Stable" BIND versions to their respective COPR repos? I feel like it should 
> be obvious, but I am missing something.
> 
> I think I expected 9.18.28 to appear in isc/bind-esv with this release (which 
> it does) and for 9.20.0 to appear in isc/bind (which it doesn't, as far as I 
> can tell anyway). 9.18.28 does appear in isc/bind as well as in isc/bind-esv, 
> which seems reasonable (though the "07776636-isc-bind-bind" directory is 
> hidden in isc/bind, it is accessible and referenced in the respective repo 
> xml files). I recognize that a direct upgrade from 9.18 to 9.20 for those on 
> the isc/bind repo might be a bit surprising at this point, despite the very 
> clear messaging about how the versioning is meant to work, but at the same 
> time, I wouldn't expect we want people using the isc/bind-dev repo to get 
> 9.20.0 for production use either.
> 
> I don't recall how this transition was handled for 9.16->9.18, but if I 
> recall it seemed like it just magically worked for us. But back then we 
> weren't as aggressive about updating as we are now. I probably just missed 
> some explanation somewhere about how the transition is meant to be handled, 
> but my searches aren't returning anything specific to this situation. 
> Speaking of which, is there an equivalent to the 
> https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918
>  article for 9.18->9.20? 
> 
> We have already upgraded most of our systems to 9.18.28, but want to move to 
> 9.20.0 soon, but aren't certain the right way forward.
> 
> Thanks again for this release. I know refactoring code is extremely 
> challenging and doesn't get the praise it deserves.
> 
> On Tue, Jul 23, 2024 at 7:30 AM Victoria Risk  wrote:
> BIND users-
> 
> Our July 2024 maintenance release of BIND 9.18, as well as the new 9.20.0 
> stable branch, are available and can be downloaded from the ISC software 
> download page, https://www.isc.org/download.
> 
> In addition to bug fixes and feature improvements, these releases also 
> contain fixes for security vulnerabilities (CVE-2024-0760, CVE-2024-1737, 
> CVE-2024-1975, CVE-2024-4076), about which more information is provided in 
> the following Security Advisories:
> 
> https://kb.isc.org/docs/cve-2024-0760
> https://kb.isc.org/docs/cve-2024-1737
> https://kb.isc.org/docs/cve-2024-1975
> https://kb.isc.org/docs/cve-2024-4076
> 
> A summary of significant changes in the new releases can be found in their 
> release notes:
> 
>   - Current supported stable branches:
> 
> 9.18.28 - 
> https://downloads.isc.org/isc/bind9/9.18.28/doc/arm/html/notes.html
> 9.20.0  - 
> https://downloads.isc.org/isc/bind9/9.20.0/doc/arm/html/notes.html
> 
> We also have a nice blog post from Ondřej Surý on the 9.20.0 release, 
> including performance testing results 
> (https://www.isc.org/blogs/2024-bind920/).
> 
> ---
> Please Note:
> 
> To create an effective mitigation for CVE-2024-1737 we have introduced two 
> new configurable limits that prevent the loading (into zones or into cache) 
> of DNS resource records (RRs) that exceed them. We therefore recommend 
> reading this KB article,
> https://kb.isc.org/docs/rrset-limits-in-zones, in case you need to change the 
> defaults to suit your specific operational environment.
> 
> We recommend that users planning to upgrade from the EOL 9.16 branch read the 
> following document first:
> 
> 
> https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918
> 
> -- 
> 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

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

Re: New BIND releases are available: 9.18.28, 9.20.0

[Adam Augustine]

 First, thank you all for the hard work you do on BIND.

What is the proper mapping of "Current Stable, ESV", "Development", and
"New Stable" BIND versions to their respective COPR repos? I feel like it
should be obvious, but I am missing something.

I think I expected 9.18.28 to appear in isc/bind-esv with this release
(which it does) and for 9.20.0 to appear in isc/bind (which it doesn't, as
far as I can tell anyway). 9.18.28 does appear in isc/bind as well as in
isc/bind-esv, which seems reasonable (though the "07776636-isc-bind-bind"
directory is hidden in isc/bind, it is accessible and referenced in the
respective repo xml files). I recognize that a direct upgrade from 9.18 to
9.20 for those on the isc/bind repo might be a bit surprising at this
point, despite the very clear messaging about how the versioning is meant
to work, but at the same time, I wouldn't expect we want people using the
isc/bind-dev repo to get 9.20.0 for production use either.

I don't recall how this transition was handled for 9.16->9.18, but if I
recall it seemed like it just magically worked for us. But back then we
weren't as aggressive about updating as we are now. I probably just missed
some explanation somewhere about how the transition is meant to be handled,
but my searches aren't returning anything specific to this situation.
Speaking of which, is there an equivalent to the
https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918
article for 9.18->9.20?

We have already upgraded most of our systems to 9.18.28, but want to move
to 9.20.0 soon, but aren't certain the right way forward.

Thanks again for this release. I know refactoring code is extremely
challenging and doesn't get the praise it deserves.

On Tue, Jul 23, 2024 at 7:30 AM Victoria Risk  wrote:

> BIND users-
>
> Our July 2024 maintenance release of BIND 9.18, as well as the new 9.20.0
> stable branch, are available and can be downloaded from the ISC software
> download page, https://www.isc.org/download.
>
> In addition to bug fixes and feature improvements, these releases also
> contain fixes for security vulnerabilities (CVE-2024-0760, CVE-2024-1737,
> CVE-2024-1975, CVE-2024-4076), about which more information is provided in
> the following Security Advisories:
>
> https://kb.isc.org/docs/cve-2024-0760
> https://kb.isc.org/docs/cve-2024-1737
> https://kb.isc.org/docs/cve-2024-1975
> https://kb.isc.org/docs/cve-2024-4076
>
> A summary of significant changes in the new releases can be found in their
> release notes:
>
>   - Current supported stable branches:
>
> 9.18.28 -
> https://downloads.isc.org/isc/bind9/9.18.28/doc/arm/html/notes.html
> 9.20.0  -
> https://downloads.isc.org/isc/bind9/9.20.0/doc/arm/html/notes.html
>
> We also have a nice blog post from Ondřej Surý on the 9.20.0 release,
> including performance testing results (
> https://www.isc.org/blogs/2024-bind920/).
>
> ---
> Please Note:
>
> To create an effective mitigation for CVE-2024-1737 we have introduced two
> new configurable limits that prevent the loading (into zones or into cache)
> of DNS resource records (RRs) that exceed them. We therefore recommend
> reading this KB article,
>
> https://kb.isc.org/docs/rrset-limits-in-zones, in case you need to change
> the defaults to suit your specific operational environment.
>
>
> We recommend that users planning to upgrade from the EOL 9.16 branch read
> the following document first:
>
>
> https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918
>
> --
> 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: 9.16.27 - Cache Prefetch

[Greg Choules via bind-users]

Hi Gabe.
Prefetch still exists; reference here:
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-prefetch

Hope that helps.
Greg

On Tue, 23 Jul 2024 at 17:36, Gabe Loyer  wrote:

> In searching for documentation I can only find something for prefetch in
> 9.10, which apparently caused some issues. Is there any new alternative in
> later versions?
>
> Thanks,
> Gabe
> --
> 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

9.16.27 - Cache Prefetch

[Gabe Loyer]

In searching for documentation I can only find something for prefetch in
9.10, which apparently caused some issues. Is there any new alternative in
later versions?

Thanks,
Gabe
-- 
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: New BIND releases are available: 9.18.28, 9.20.0

[Michał Kępień]

Brian,

> We use the COPR to install BIND on our servers, and I wanted to mention that 
> it looks like in both the isc/bind and isc/bind-esv repos, the build of the 
> package “isc-bind-bind” failed for version  9.18.28-1.1 in (as far as I can 
> tell) only the EPEL 7 repo in Build 7776636.  Could someone look at that?  
> We’re on RHEL 8 and 9 for our BIND servers and it looks like the EPEL 8 and 9 
> versions build successfully, but I want to make sure that I’m not missing 
> something.  Thanks!

You are correct: only EL7 builds failed; EL8 and EL9 builds are fine.

The reason for this is that Copr's epel-7-x86_64 chroot uses CentOS 7
repositories and these are no longer available as that system has
reached End-of-Life last month:


https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux/rhel-7-end-of-maintenance

We will shortly disable epel-7-x86_64 builds in our Copr repositories to
prevent confusion in the future.

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

Re: New BIND releases are available: 9.18.28, 9.20.0

[Sebby, Brian A. via bind-users]

We use the COPR to install BIND on our servers, and I wanted to mention that it 
looks like in both the isc/bind and isc/bind-esv repos, the build of the 
package “isc-bind-bind” failed for version  9.18.28-1.1 in (as far as I can 
tell) only the EPEL 7 repo in Build 7776636.  Could someone look at that?  
We’re on RHEL 8 and 9 for our BIND servers and it looks like the EPEL 8 and 9 
versions build successfully, but I want to make sure that I’m not missing 
something.  Thanks!


Brian

--
Brian Sebby (he/him/his)  |  Lead Systems Engineer
Email: se...@anl.gov  |  Information Technology 
Infrastructure
Phone: +1 630.252.9935|  Business Information Services
Cell:  +1 630.921.4305|  Argonne National Laboratory

From: bind-users  on behalf of Victoria Risk 

Date: Tuesday, July 23, 2024 at 8:32 AM
To: bind-annou...@lists.isc.org , BIND Users 

Subject: New BIND releases are available: 9.18.28, 9.20.0
BIND users- Our July 2024 maintenance release of BIND 9. 18, as well as the new 
9. 20. 0 stable branch, are available and can be downloaded from the ISC 
software download page, https: //www. isc. org/download. In addition to bug 
fixes and feature
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd
BIND users-

Our July 2024 maintenance release of BIND 9.18, as well as the new 9.20.0 
stable branch, are available and can be downloaded from the ISC software 
download page, 
https://www.isc.org/download.

In addition to bug fixes and feature improvements, these releases also contain 
fixes for security vulnerabilities (CVE-2024-0760, CVE-2024-1737, 
CVE-2024-1975, CVE-2024-4076), about which more information is provided in the 
following Security Advisories:


https://kb.isc.org/docs/cve-2024-0760

https://kb.isc.org/docs/cve-2024-1737

https://kb.isc.org/docs/cve-2024-1975

https://kb.isc.org/docs/cve-2024-4076

A summary of significant changes in the new releases can be found in their 
release notes:

  - Current supported stable branches:

9.18.28 - 
https://downloads.isc.org/isc/bind9/9.18.28/doc/arm/html/notes.html
9.20.0  - 
https://downloads.isc.org/isc/bind9/9.20.0/doc/arm/html/notes.html

We also have a nice blog post from Ondřej Surý on the 9.20.0 release, including 
performance testing results 
(https://www.isc.org/blogs/2024-bind920/).

---
Please Note:


To create an effective mitigation for CVE-2024-1737 we have introduced two new 
configurable limits that prevent the loading (into zones or into cache) of DNS 
resource records (RRs) that exceed them. We therefore recommend reading this KB 
article,

New BIND releases are available: 9.18.28, 9.20.0

[Victoria Risk]

BIND users-

Our July 2024 maintenance release of BIND 9.18, as well as the new 9.20.0 
stable branch, are available and can be downloaded from the ISC software 
download page, https://www.isc.org/download.

In addition to bug fixes and feature improvements, these releases also contain 
fixes for security vulnerabilities (CVE-2024-0760, CVE-2024-1737, 
CVE-2024-1975, CVE-2024-4076), about which more information is provided in the 
following Security Advisories:

https://kb.isc.org/docs/cve-2024-0760
https://kb.isc.org/docs/cve-2024-1737
https://kb.isc.org/docs/cve-2024-1975
https://kb.isc.org/docs/cve-2024-4076

A summary of significant changes in the new releases can be found in their 
release notes:

  - Current supported stable branches:

9.18.28 - 
https://downloads.isc.org/isc/bind9/9.18.28/doc/arm/html/notes.html
9.20.0  - https://downloads.isc.org/isc/bind9/9.20.0/doc/arm/html/notes.html

We also have a nice blog post from Ondřej Surý on the 9.20.0 release, including 
performance testing results (https://www.isc.org/blogs/2024-bind920/).

---
Please Note:

To create an effective mitigation for CVE-2024-1737 we have introduced two new 
configurable limits that prevent the loading (into zones or into cache) of DNS 
resource records (RRs) that exceed them. We therefore recommend reading this KB 
article,
https://kb.isc.org/docs/rrset-limits-in-zones, in case you need to change the 
defaults to suit your specific operational environment.

We recommend that users planning to upgrade from the EOL 9.16 branch read the 
following document first:


https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918

-- 
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: checkds - min. version for this ?

[Matthijs Mekking]

On 7/18/24 15:53, vom513 wrote:

Hello all,

I could have sworn I saw mention on this list at some point of this (just can’t 
find it in the archives).

I currently run a 9.18.x BIND and I use parental agents for automatic key 
rollover.  I have a script that builds these and I included them in my config.

 From what I read on:

https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-checkds

The “checkds” statement, if set to yes, will simply look at the parent NSes 
with no need to create/maintain the parental-agents list.

Is this correct ?  And also - what version of BIND was this first introduced 
(seems like something 9.19.x ?) ?


Correct. The "checkds" option was introduced in 9.19.12.

Best regards,

Matthijs


My current setup is fine for me - but if there is a more elegant/native way of 
doing it in the future I’d want to do that vs. reinventing the wheel.

Thanks.

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

checkds - min. version for this ?

[vom513]

Hello all,

I could have sworn I saw mention on this list at some point of this (just can’t 
find it in the archives).

I currently run a 9.18.x BIND and I use parental agents for automatic key 
rollover.  I have a script that builds these and I included them in my config.

From what I read on:

https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-checkds

The “checkds” statement, if set to yes, will simply look at the parent NSes 
with no need to create/maintain the parental-agents list.

Is this correct ?  And also - what version of BIND was this first introduced 
(seems like something 9.19.x ?) ?

My current setup is fine for me - but if there is a more elegant/native way of 
doing it in the future I’d want to do that vs. reinventing the wheel.

Thanks.
-- 
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: qname minimisation per domain

[Matus UHLAR - fantomas]

On 15 Jul 2024, at 23:27, Matus UHLAR - fantomas  wrote:
I have noticed that especially DNS blocklist cause errors like:

Jul 14 01:41:28 fantomas named[1854]: success resolving 
'D.C.B.A.zen.spamhaus.org/A' after disabling qname minimization due to 'ncache 
nxdomain'

and blocklists like spamhaus are sensitive to too many queries.

is it possible to disable query minimisation for particular domains?


On 16.07.24 09:23, Mark Andrews wrote:
Is it really too much effort for the servers to return NOERROR instead of 
an incorrect NXDOMAIN for the intermediate names?  That would get rid of 
the log message.


These seem to run rbldnsd which is optimised for memory usage and speed of 
response, and returning different replies would I guess affect speed.


It’s changing 1 bit (0 vs 4 for the rcode) in the DNS 
header.  They don’t even have to lookup if there are names below the 
query.  The server can just assume that there are records there and return 
NOERROR for [0..255].zen.spamhaus.org, [0..255].[0..255].zen.spamhaus.org 
and [0..255].[0..255].[0..255].zen.spamhaus.org. Really we would like to 
be able to move to strict QNAME minimisation so we don’t need to make all 
the other queries after the first NXDOMAIN response but broken 
implementations like this are making that difficult.  It’s not like this 
is a new requirement.  A NOERROR response goes back the RFC 1034.  


I see there's issue and merge containing exactly this change: 
https://github.com/spamhaus/rbldnsd/issues/17


The discussion also mentions things like
 
  There is also quite a lot of consensus in the SMTP World that qname 
  minimization shouldn't be used on the resolvers used by mail servers


and

  For the IP(v4 and v6) datasets, all of them, we could implement a hackish 
  solution so that when a query for a "partial" ip address is received, 
  rbldnsd doesn't reply NXDOMAIN but NOERROR instead.


Additionally Spamhaus controls how often resolvers re-query.  10 seconds 
is a very short negative response TTL.  If they don’t like the query rate 
they can control it by returning longer negative cache responses.  Named 
does check in the cache for negative cache entries to determine whether or 
not to make the intermediate QNAME minimisation queries.


Lower negative TTLs allow for faster listing detection.
I also believe that it is in Spamhaus interest to have more paying clients 
(although this may not be the primary reason for short negative TTLs).



I guess for now, since the qname minimization increases number of queries 
sent and resolving time, I should disable qname-minimization on all named 
instances used by mail server.


--
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.
My mind is like a steel trap - rusty and illegal in 37 states.
--
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: strange reply dumped URGENT

[Mark Andrews]

Looking at the log file it looks like you did not start named as root as none 
of the interfaces worked.

5-Jul-2024 08:45:59.005 listening on IPv4 interface lo, 45.225.75.241#53
15-Jul-2024 08:45:59.005 creating IPv4 interface lo failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv4 interface enp2s0, 199.38.247.210#53
15-Jul-2024 08:45:59.005 creating IPv4 interface enp2s0 failed; interface 
ignored
15-Jul-2024 08:45:59.005 IPv6 socket API is incomplete; explicitly binding to 
each IPv6 address separately
15-Jul-2024 08:45:59.005 listening on IPv6 interface lo, 
2803:1920::b4b2:5f61:d37f:9#53
15-Jul-2024 08:45:59.005 creating IPv6 interface lo failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface lo, 
2803:1920::b4b2:5f61:d37f:8#53
15-Jul-2024 08:45:59.005 creating IPv6 interface lo failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface lo, 
2803:1920::b4b2:5f61:d37f:7#53
15-Jul-2024 08:45:59.005 creating IPv6 interface lo failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface lo, 
2803:1920::b4b2:5f61:d37f:6#53
15-Jul-2024 08:45:59.005 creating IPv6 interface lo failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface lo, 
2803:1920::b4b2:5f61:d37f:5#53
15-Jul-2024 08:45:59.005 creating IPv6 interface lo failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface lo, 
2803:1920::b4b2:5f61:d37f:4#53
15-Jul-2024 08:45:59.005 creating IPv6 interface lo failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface lo, 
2803:1920::b4b2:5f61:d37f:3#53
15-Jul-2024 08:45:59.005 creating IPv6 interface lo failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface lo, 
2803:1920::b4b2:5f61:d37f:2#53
15-Jul-2024 08:45:59.005 creating IPv6 interface lo failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface lo, 
2803:1920::b4b2:5f61:d37f:1#53
15-Jul-2024 08:45:59.005 creating IPv6 interface lo failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface lo, 
2803:1920::b4b2:5f61:d37f:0#53
15-Jul-2024 08:45:59.005 creating IPv6 interface lo failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface lo, ::1#53
15-Jul-2024 08:45:59.005 creating IPv6 interface lo failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface enp2s0, 2606:d280::4a#53
15-Jul-2024 08:45:59.005 creating IPv6 interface enp2s0 failed; interface 
ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface enp2s0, 
fe80::be5f:f4ff:feaf:6e51%2#53
15-Jul-2024 08:45:59.005 creating IPv6 interface enp2s0 failed; interface 
ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface orion, 
2803:1920::9c8f:e163:d79:0#53
15-Jul-2024 08:45:59.005 creating IPv6 interface orion failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface orion, 
fe80::8c49:9979:5ca1:26c6%4#53
15-Jul-2024 08:45:59.005 creating IPv6 interface orion failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface hades, 
2803:1920::9c8f:e163:d6d:0#53
15-Jul-2024 08:45:59.005 creating IPv6 interface hades failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface hades, 
fe80::94f3:47ff:fea3:5687%6#53
15-Jul-2024 08:45:59.005 creating IPv6 interface hades failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface dc3l1, 
2803:1920::9c8f:e163:d77:b#53
15-Jul-2024 08:45:59.005 creating IPv6 interface dc3l1 failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface dc3l1, 
fe80::33ba:486d:c987:9706%7#53
15-Jul-2024 08:45:59.005 creating IPv6 interface dc3l1 failed; interface ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface hadesbis, 
2803:1920::9c8f:e163:d6e:0#53
15-Jul-2024 08:45:59.005 creating IPv6 interface hadesbis failed; interface 
ignored
15-Jul-2024 08:45:59.005 listening on IPv6 interface hadesbis, 
fe80::94f3:47ff:e0a6:53ce%9#53
15-Jul-2024 08:45:59.005 creating IPv6 interface hadesbis failed; interface 
ignored

Additionally if named normally starts with '-u bind' add that to the command 
line when you start
it by hand as named uses Linux's capabilities to drop root’s ability to 
override file permissions.

First thing I would check is if the zone is being served by the IPv6 only 
machine and it doesn’t
appear to be.  Read the logs on that machine to determine why the zone failed 
to load.

% dig testadmin.ovh @2803:1920::4:a09

; <<>> DiG 9.19.25-dev <<>> testadmin.ovh @2803:1920::4:a09
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1782
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 65393f74ffe49e2b01006695bc1990097dcbf2cdae38 (good)
;; QUESTION SECTION:
;testadmin.ovh. IN A

;; Query time: 558 msec
;; SERVER: 

Re: qname minimisation per domain

[Mark Andrews]

Is it really too much effort for the servers to return NOERROR instead of an 
incorrect NXDOMAIN for the intermediate names?  That would get rid of the log 
message.  It’s changing 1 bit (0 vs 4 for the rcode) in the DNS header.  They 
don’t even have to lookup if there are names below the query.  The server can 
just assume that there are records there and return NOERROR for 
[0..255].zen.spamhaus.org, [0..255].[0..255].zen.spamhaus.org and 
[0..255].[0..255].[0..255].zen.spamhaus.org.  Really we would like to be able 
to move to strict QNAME minimisation so we don’t need to make all the other 
queries after the first NXDOMAIN response but broken implementations like this 
are making that difficult.  It’s not like this is a new requirement.  A NOERROR 
response goes back the RFC 1034.  Additionally Spamhaus controls how often 
resolvers re-query.  10 seconds is a very short negative response TTL.  If they 
don’t like the query rate they can control it by returning longer negative 
cache responses.  Named does check in the cache for negative cache entries to 
determine whether or not to make the intermediate QNAME minimisation queries.

> On 15 Jul 2024, at 23:27, Matus UHLAR - fantomas  wrote:
> 
> Hello,
> 
> I have noticed that especially DNS blocklist cause errors like:
> 
> Jul 14 01:41:28 fantomas named[1854]: success resolving 
> 'D.C.B.A.zen.spamhaus.org/A' after disabling qname minimization due to 
> 'ncache nxdomain'
> 
> and blocklists like spamhaus are sensitive to too many queries.
> 
> is it possible to disable query minimisation for particular domains?
> 
> 
> -- 
> 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.
> Atheism is a non-prophet organization.
> -- 
> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@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

qname minimisation per domain

[Matus UHLAR - fantomas]

Hello,

I have noticed that especially DNS blocklist cause errors like:

Jul 14 01:41:28 fantomas named[1854]: success resolving 
'D.C.B.A.zen.spamhaus.org/A' after disabling qname minimization due to 'ncache 
nxdomain'

and blocklists like spamhaus are sensitive to too many queries.

is it possible to disable query minimisation for particular domains?


--
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.
Atheism is a non-prophet organization.
--
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: strange reply dumped URGENT

[Herman Brule via bind-users]

Hi,

Sorry I had to fix for my customer the domain ore.org.bo, but I have 
open another domain to test: testadmin.ovh


Sorry for all this change. I have defined better test case and have 
normal IP to prevent problem from this part.


69.162.65.138-> not my IP 2803:1920::4:a09 IPv6 only, VPS customer (here I'm the 
customer) <-> EDGE 199.38.247.210 IPv4+IPv6 <-> upstream provider of my 
autonomous system Each time I try enable log, named not start, see 
attached file Debian 12 into /etc/bind/named.conf.local I replace 
(/var/log/bind.log exist with bind user): logging {    category 
default { null; }; }; logging {   channel bind_log {   
 file "/var/log/bind.log" versions 3 size 10m;     
   severity info;    print-category  yes;   
 print-severity  yes;    print-time  yes; 
   };    category default { bind_log; };   category 
lame-servers { null; };  category update { bind_log; };    
   category update-security { bind_log; };    category security { 
bind_log; }; };


alpha_one_x86/BRULE Herman
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server 
management
IT, OS, technologies, research & development, security and business department

On 7/15/24 02:43, Mark Andrews wrote:

Really it is very hard to help people who keep changing random things making a 
moving
target.  You started out with a machine at 45.225.75.8 that could reach 
2803:1920::c:1963
based on the forward zone declaration so it had to be dual stacked (both IPv4 
and IPv6).

You have now added two new machines 69.162.65.138 and 192.169.93.210 which may 
or may not
be able to reach 2803:1920::c:1963 and have changed the delegation to point to 
them and they
return NXDOMAIN for smtp.ore.org.bo.

Now if you have IPv4 only nameservers that need to get the zone content from an 
IPv6 only
server you will need to have an intermediate dual stacked server that can 
transfer the zone
content from the IPv6 only server and send it to the IPv4 only servers when 
they request it.

P(IPv6-only) -> I(IPv4 and IPv6) -> S(IPv4 only)

Also read the nameserver’s logs.  They will help you work out what is going 
wrong.

2803:1920::c:1963 (IPv6 only):
zone ore.org.bo {
type primary;
file "ore.org.bo.db”;
};

45.225.75.8/ (dual stacked):
zone ore.org.bo {
type secondary;
file "ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};

69.162.65.138 (IPv4 only):
zone ore.org.bo {
type secondary;
file "ore.org.bo.db”;
primaries { 45.225.75.8; };
};

Alternatively you can add IPv6 to an IPv4 only machine using services like
https://tunnelbroker.net/  even when the ISP does not support IPv6.

Mark


On 15 Jul 2024, at 11:00, Herman Brule  wrote:

I open this to test (45.225.75.8 is particial anycast IP, for DNS/UDP have 
bind9):
dig A ore.org.bo @199.38.247.210
With on 199.38.247.210 (work):
zone ore.org.bo {
 type master;
 file "/etc/bind/ore.org.bo.db";
};
; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> A ore.org.bo @199.38.247.210
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39291
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 9948d53f96271fa8010066947311b2e477062b98c6ee (good)
;; QUESTION SECTION:
;ore.org.bo.IN  A

;; ANSWER SECTION:
ore.org.bo. 3600IN  A   45.225.75.8

;; Query time: 99 msec
;; SERVER: 199.38.247.210#53(199.38.247.210) (UDP)
;; WHEN: Mon Jul 15 00:53:38 UTC 2024
;; MSG SIZE  rcvd: 83

With on 199.38.247.210 (not work):
zone ore.org.bo {
type secondary;
file “/etc/bind/ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};

; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> A ore.org.bo @199.38.247.210
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14941
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: f9006eb35715f0da0100669473a08e2898af7098316c (good)
;; QUESTION SECTION:
;ore.org.bo.IN  A

;; Query time: 87 msec
;; SERVER: 199.38.247.210#53(199.38.247.210) (UDP)
;; WHEN: Mon Jul 15 00:56:01 UTC 2024
;; MSG SIZE  rcvd: 67
alpha_one_x86/BRULE Herman
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server 
management
IT, OS, technologies, research & development, security and business department
On 7/14/24 20:00, Mark Andrews wrote:



On 13 Jul 2024, at 12:44, Herman Brule  wrote:

Thanks, I'm looking how solve this, cleanly.
In my country only 1 ISP have IPv6, then I need keep IPv4.
I have 1 IPv4 for 1000 VPS, no way here to have more IPv4.
Then:
1) I'm not sure if my DNS authoritative on IPv6 reply correctly (but reply 
correctly to all my dig query)
2) I have to provide a way to my customer can 

Re: strange reply dumped URGENT

[Mark Andrews]

Really it is very hard to help people who keep changing random things making a 
moving
target.  You started out with a machine at 45.225.75.8 that could reach 
2803:1920::c:1963
based on the forward zone declaration so it had to be dual stacked (both IPv4 
and IPv6).

You have now added two new machines 69.162.65.138 and 192.169.93.210 which may 
or may not
be able to reach 2803:1920::c:1963 and have changed the delegation to point to 
them and they
return NXDOMAIN for smtp.ore.org.bo.

Now if you have IPv4 only nameservers that need to get the zone content from an 
IPv6 only
server you will need to have an intermediate dual stacked server that can 
transfer the zone
content from the IPv6 only server and send it to the IPv4 only servers when 
they request it.

P(IPv6-only) -> I(IPv4 and IPv6) -> S(IPv4 only)

Also read the nameserver’s logs.  They will help you work out what is going 
wrong.

2803:1920::c:1963 (IPv6 only):
zone ore.org.bo {
type primary;
file "ore.org.bo.db”;
};

45.225.75.8/ (dual stacked):
zone ore.org.bo {
type secondary;
file "ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};

69.162.65.138 (IPv4 only):
zone ore.org.bo {
type secondary;
file "ore.org.bo.db”;
primaries { 45.225.75.8; };
};

Alternatively you can add IPv6 to an IPv4 only machine using services like
https://tunnelbroker.net/ even when the ISP does not support IPv6.

Mark

> On 15 Jul 2024, at 11:00, Herman Brule  wrote:
> 
> I open this to test (45.225.75.8 is particial anycast IP, for DNS/UDP have 
> bind9):
> dig A ore.org.bo @199.38.247.210 
> With on 199.38.247.210 (work):
> zone ore.org.bo { 
> type master; 
> file "/etc/bind/ore.org.bo.db"; 
> };
> ; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> A ore.org.bo @199.38.247.210 
> ;; global options: +cmd 
> ;; Got answer: 
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39291 
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 
> 
> ;; OPT PSEUDOSECTION: 
> ; EDNS: version: 0, flags:; udp: 1232 
> ; COOKIE: 9948d53f96271fa8010066947311b2e477062b98c6ee (good) 
> ;; QUESTION SECTION: 
> ;ore.org.bo.IN  A 
> 
> ;; ANSWER SECTION: 
> ore.org.bo. 3600IN  A   45.225.75.8 
> 
> ;; Query time: 99 msec 
> ;; SERVER: 199.38.247.210#53(199.38.247.210) (UDP) 
> ;; WHEN: Mon Jul 15 00:53:38 UTC 2024 
> ;; MSG SIZE  rcvd: 83 
> 
> With on 199.38.247.210 (not work):
> zone ore.org.bo {
> type secondary;
> file “/etc/bind/ore.org.bo.db”;
> primaries { 2803:1920::c:1963; };
> };
> 
> ; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> A ore.org.bo @199.38.247.210 
> ;; global options: +cmd 
> ;; Got answer: 
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14941 
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 
> 
> ;; OPT PSEUDOSECTION: 
> ; EDNS: version: 0, flags:; udp: 1232 
> ; COOKIE: f9006eb35715f0da0100669473a08e2898af7098316c (good) 
> ;; QUESTION SECTION: 
> ;ore.org.bo.IN  A 
> 
> ;; Query time: 87 msec 
> ;; SERVER: 199.38.247.210#53(199.38.247.210) (UDP) 
> ;; WHEN: Mon Jul 15 00:56:01 UTC 2024 
> ;; MSG SIZE  rcvd: 67
> alpha_one_x86/BRULE Herman 
> Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and 
> server management
> IT, OS, technologies, research & development, security and business department
> On 7/14/24 20:00, Mark Andrews wrote:
>> 
>> 
>>> On 13 Jul 2024, at 12:44, Herman Brule  wrote:
>>> 
>>> Thanks, I'm looking how solve this, cleanly.
>>> In my country only 1 ISP have IPv6, then I need keep IPv4.
>>> I have 1 IPv4 for 1000 VPS, no way here to have more IPv4.
>>> Then:
>>> 1) I'm not sure if my DNS authoritative on IPv6 reply correctly (but reply 
>>> correctly to all my dig query)
>>> 2) I have to provide a way to my customer can resolve query on their DNS 
>>> server on their IPv6 VPS, their need be able to just put their vps dns or 
>>> at least common server dns (where I had to put their zone, then I dislike 
>>> this idea)
>>> For now your method fail, include I try:
>>> zone "ore.org.bo" { 
>>> type master; 
>>> file "/etc/bind/ore.org.bo.db"; 
>>> };
>>> But failed too.
>>> 
>> Well I didn’t say to do that. You have they wrong type of zone. Make it a 
>> secondary (slave) zone
>> like I told you to do.
>> 
>> zone ore.org.bo {
>> type secondary;
>> file “ore.org.bo.db”;
>> primaries { 2803:1920::c:1963; };
>> };
>> 
>> Now that should work as I can AXFR the zone from that server. You should 
>> also note the difference in
>> the flags in the responses for smtp.ore.org.bo. The one from 
>> 2803:1920::c:1963 is an authoritative
>> reply (aa) and the TTL stays at 3600, whereas the one from 45.225.75.8 is 
>> not (aa is not set in the
>> flags) and the TTL decreases indicating that it comes from a recursive 
>> server.
>> 
>> It also looks like someone tried to comment out *.ore.org.bo but used the 
>> wrong comment character ‘#'
>> 

Re: Building bind 9.19.24 on Openwrt w/ MUSL

[Philip Prindeville via bind-users]

Finally got it done.

Sorry for taking so long.  Had a lot of travel.



> On Jun 2, 2024, at 2:37 AM, Ondřej Surý  wrote:
> 
> Hi Philip,
> 
> we'll need more. Ideally fill an issue, follow the bug template and attach 
> config.log as a bare minimum.
> --
> Ondřej Surý — ISC (He/Him)
> 
> My working hours and your working hours may be different. Please do not feel 
> obligated to reply outside your normal working hours.
> 
>> On 1. 6. 2024, at 23:19, Philip Prindeville via bind-users 
>>  wrote:
>> 
>> Hi,
>> 
>> Having some more issues building 9.19.24 on MUSL.  configure.ac isn't 
>> correctly detecting the following:
>> 
>> ac_cv_func_setresuid=yes
>> ac_cv_type_size_t=yes
>> ac_cv_type_ssize_t=yes
>> ac_cv_type_uintptr_t=yes
>> 
>> And even passing this manually via ./configure's environment isn't causing 
>> it to work... it's showing as the wrong value and not "(cached)".
>> 
>> I wouldn't have noticed except that the included replacement for setresuid() 
>> dies in compilation with a warning about it being declared as static and 
>> then later defined as non-static or some such.
>> 
>> Anyone else had problems with autoconf and cross-compilation w/ MUSL?
>> 
>> I wanted to do a bump on bind to pick up this fix:
>> 
>> https://gitlab.isc.org/isc-projects/bind9/-/issues/3152
>> 
>> Thanks,
>> 
>> -Philip
>> 
>> --
>> 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: strange reply dumped URGENT

[Herman Brule via bind-users]

I open this to test (45.225.75.8 is particial anycast IP, for DNS/UDP 
have bind9):


dig A ore.org.bo @199.38.247.210

With on 199.38.247.210 (work):

zone ore.org.bo {
    type master;
    file "/etc/bind/ore.org.bo.db";
};

; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> A ore.org.bo @199.38.247.210
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39291
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 9948d53f96271fa8010066947311b2e477062b98c6ee (good)
;; QUESTION SECTION:
;ore.org.bo.    IN  A

;; ANSWER SECTION:
ore.org.bo. 3600    IN  A   45.225.75.8

;; Query time: 99 msec
;; SERVER: 199.38.247.210#53(199.38.247.210) (UDP)
;; WHEN: Mon Jul 15 00:53:38 UTC 2024
;; MSG SIZE  rcvd: 83

With on 199.38.247.210 (not work):

zone ore.org.bo {
type secondary;
file “/etc/bind/ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};

; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> A ore.org.bo @199.38.247.210
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14941
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: f9006eb35715f0da0100669473a08e2898af7098316c (good)
;; QUESTION SECTION:
;ore.org.bo.    IN  A

;; Query time: 87 msec
;; SERVER: 199.38.247.210#53(199.38.247.210) (UDP)
;; WHEN: Mon Jul 15 00:56:01 UTC 2024
;; MSG SIZE  rcvd: 67

alpha_one_x86/BRULE Herman
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server 
management
IT, OS, technologies, research & development, security and business department

On 7/14/24 20:00, Mark Andrews wrote:



On 13 Jul 2024, at 12:44, Herman Brule  wrote:

Thanks, I'm looking how solve this, cleanly.
In my country only 1 ISP have IPv6, then I need keep IPv4.
I have 1 IPv4 for 1000 VPS, no way here to have more IPv4.
Then:
1) I'm not sure if my DNS authoritative on IPv6 reply correctly (but reply 
correctly to all my dig query)
2) I have to provide a way to my customer can resolve query on their DNS server 
on their IPv6 VPS, their need be able to just put their vps dns or at least 
common server dns (where I had to put their zone, then I dislike this idea)
For now your method fail, include I try:
zone "ore.org.bo" {
 type master;
 file "/etc/bind/ore.org.bo.db";
};
But failed too.

Well I didn’t say to do that.  You have they wrong type of zone.  Make it a 
secondary (slave) zone
like I told you to do.

zone ore.org.bo {
type secondary;
file “ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};

Now that should work as I can AXFR the zone from that server.  You should also 
note the difference in
the flags in the responses for smtp.ore.org.bo.  The one from 2803:1920::c:1963 
is an authoritative
reply (aa) and the TTL stays at 3600, whereas the one from 45.225.75.8 is not 
(aa is not set in the
flags) and the TTL decreases indicating that it comes from a recursive server.

It also looks like someone tried to comment out *.ore.org.bo but used the wrong 
comment character ‘#'
rather than ‘;’.

[ant:~/git/bind9] marka% dig axfr ore.org.bo @2803:1920::c:1963

; <<>> DiG 9.19.25-dev <<>> axfr ore.org.bo @2803:1920::c:1963
;; global options: +cmd
ore.org.bo. 604800 IN SOA 811.vps.confiared.com. admin.ore.org.bo. 3 604800 
86400 2419200 604800
ore.org.bo. 604800 IN NS 811.vps.confiared.com.
ore.org.bo. 3600 IN MX 1 smtp.ore.org.bo.
ore.org.bo. 3600 IN A 45.225.75.8
ore.org.bo. 3600 IN  2803:1920::c:1963
#*.ore.org.bo. 604800 IN CNAME ore.org.bo.
smtp.ore.org.bo. 3600 IN A 45.225.75.8
smtp.ore.org.bo. 3600 IN  2803:1920::c:1963
www.ore.org.bo. 604800 IN CNAME ore.org.bo.
ore.org.bo. 604800 IN SOA 811.vps.confiared.com. admin.ore.org.bo. 3 604800 
86400 2419200 604800
;; Query time: 497 msec
;; SERVER: 2803:1920::c:1963#53(2803:1920::c:1963) (TCP)
;; WHEN: Mon Jul 15 09:47:16 AEST 2024
;; XFR size: 10 records (messages 1, bytes 324)

[ant:~/git/bind9] marka% dig a smtp.ore.org.bo @2803:1920::c:1963

; <<>> DiG 9.19.25-dev <<>> a smtp.ore.org.bo @2803:1920::c:1963
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4584
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: cdbac4bb692528b30100669463a2ffd887df1b2535a8 (good)
;; QUESTION SECTION:
;smtp.ore.org.bo. IN A

;; ANSWER SECTION:
smtp.ore.org.bo. 3600 IN A 45.225.75.8

;; Query time: 659 msec
;; SERVER: 2803:1920::c:1963#53(2803:1920::c:1963) (UDP)
;; WHEN: Mon Jul 15 09:47:47 AEST 2024
;; MSG SIZE  rcvd: 88

[ant:~/git/bind9] marka% dig a smtp.ore.org.bo @45.225.75.8

; <<>> DiG 9.19.25-dev <<>> a smtp.ore.org.bo @45.225.75.8
;; global 

Re: strange reply dumped URGENT

[Mark Andrews]

> On 13 Jul 2024, at 12:44, Herman Brule  wrote:
> 
> Thanks, I'm looking how solve this, cleanly.
> In my country only 1 ISP have IPv6, then I need keep IPv4.
> I have 1 IPv4 for 1000 VPS, no way here to have more IPv4.
> Then:
> 1) I'm not sure if my DNS authoritative on IPv6 reply correctly (but reply 
> correctly to all my dig query)
> 2) I have to provide a way to my customer can resolve query on their DNS 
> server on their IPv6 VPS, their need be able to just put their vps dns or at 
> least common server dns (where I had to put their zone, then I dislike this 
> idea)
> For now your method fail, include I try:
> zone "ore.org.bo" { 
> type master; 
> file "/etc/bind/ore.org.bo.db"; 
> };
> But failed too.

Well I didn’t say to do that.  You have they wrong type of zone.  Make it a 
secondary (slave) zone
like I told you to do.

zone ore.org.bo {
type secondary;
file “ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};

Now that should work as I can AXFR the zone from that server.  You should also 
note the difference in
the flags in the responses for smtp.ore.org.bo.  The one from 2803:1920::c:1963 
is an authoritative
reply (aa) and the TTL stays at 3600, whereas the one from 45.225.75.8 is not 
(aa is not set in the
flags) and the TTL decreases indicating that it comes from a recursive server.

It also looks like someone tried to comment out *.ore.org.bo but used the wrong 
comment character ‘#'
rather than ‘;’.

[ant:~/git/bind9] marka% dig axfr ore.org.bo @2803:1920::c:1963

; <<>> DiG 9.19.25-dev <<>> axfr ore.org.bo @2803:1920::c:1963
;; global options: +cmd
ore.org.bo. 604800 IN SOA 811.vps.confiared.com. admin.ore.org.bo. 3 604800 
86400 2419200 604800
ore.org.bo. 604800 IN NS 811.vps.confiared.com.
ore.org.bo. 3600 IN MX 1 smtp.ore.org.bo.
ore.org.bo. 3600 IN A 45.225.75.8
ore.org.bo. 3600 IN  2803:1920::c:1963
#*.ore.org.bo. 604800 IN CNAME ore.org.bo.
smtp.ore.org.bo. 3600 IN A 45.225.75.8
smtp.ore.org.bo. 3600 IN  2803:1920::c:1963
www.ore.org.bo. 604800 IN CNAME ore.org.bo.
ore.org.bo. 604800 IN SOA 811.vps.confiared.com. admin.ore.org.bo. 3 604800 
86400 2419200 604800
;; Query time: 497 msec
;; SERVER: 2803:1920::c:1963#53(2803:1920::c:1963) (TCP)
;; WHEN: Mon Jul 15 09:47:16 AEST 2024
;; XFR size: 10 records (messages 1, bytes 324)

[ant:~/git/bind9] marka% dig a smtp.ore.org.bo @2803:1920::c:1963

; <<>> DiG 9.19.25-dev <<>> a smtp.ore.org.bo @2803:1920::c:1963
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4584
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: cdbac4bb692528b30100669463a2ffd887df1b2535a8 (good)
;; QUESTION SECTION:
;smtp.ore.org.bo. IN A

;; ANSWER SECTION:
smtp.ore.org.bo. 3600 IN A 45.225.75.8

;; Query time: 659 msec
;; SERVER: 2803:1920::c:1963#53(2803:1920::c:1963) (UDP)
;; WHEN: Mon Jul 15 09:47:47 AEST 2024
;; MSG SIZE  rcvd: 88

[ant:~/git/bind9] marka% dig a smtp.ore.org.bo @45.225.75.8

; <<>> DiG 9.19.25-dev <<>> a smtp.ore.org.bo @45.225.75.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33189
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 42c6758d745eb62b0100669463baea9db7cd3474c256 (good)
;; QUESTION SECTION:
;smtp.ore.org.bo. IN A

;; ANSWER SECTION:
smtp.ore.org.bo. 3266 IN A 45.225.75.8

;; Query time: 264 msec
;; SERVER: 45.225.75.8#53(45.225.75.8) (UDP)
;; WHEN: Mon Jul 15 09:48:10 AEST 2024
;; MSG SIZE  rcvd: 88

[ant:~/git/bind9] marka% 

Mark

> alpha_one_x86/BRULE Herman 
> Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and 
> server management
> IT, OS, technologies, research & development, security and business department
> On 7/12/24 19:01, Mark Andrews wrote:
>> 
>> 
>>> On 13 Jul 2024, at 04:38, Herman Brule via bind-users 
>>>  wrote:
>>> 
>>> Because the customer are into IPv6 zone
>>> 
>> Well all zones should be served by both IPv4 servers and IPv6 servers. IPv6 
>> is nearly 30 years old now. There are
>> sites that are IPv6 only because they would prefer to not have to run 
>> everything through 2 or 3 layers of NAT when
>> they don’t need it at all for IPv6 and would really like to not have to send 
>> all there DNS queries though NAT64 boxes.
>> 
>> 
>>> And the EDGE router connecting IPv4 and IPv6 is internal to the data center 
>>> company, not accessible for the customer.
>>> Forward zone to edge will be more complex, it's more simple just forward 
>>> the query.
>>> Thanks for you observation, but I know, I doing this quickly, I will keep 
>>> like this for now, this will produce only problem for availability if the 
>>> server is down.
>>> 
>> Except you are wrong. You are writing here because it *is* causing you and 
>> everyone else 

Re: strange reply dumped URGENT

[Marco Moock]

Am Fri, 12 Jul 2024 22:44:38 -0400
schrieb Herman Brule :

> For now your method fail, include I try:
> 
> zone "ore.org.bo" {
>      type master;
>      file "/etc/bind/ore.org.bo.db";
> };

Only have one, exactly one master for a zone. Everything else will
create a big mess.

The other servers are slaves and will poll the zones from the master.

E.g.

ns1.example.org is IPv6 only and the master for example.org.
Glue records will only include the IPv6 address.
It will be listed as NS for example.org.

ns2.example.org is a slave and will poll the stuff from ns1, not
forward it to it.
-- 
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: strange reply dumped URGENT

[Marco Moock]

Am Fri, 12 Jul 2024 15:51:32 -0400
schrieb Herman Brule :

>   Loop detected! We were referred back to '45.225.75.8'

That's why I say:
Have real NS records that point to unique systems.
If you forward, make sure the other machine is the master.

I operate DNS with 2 NS records, one dual-stack, the other only IPv6.
No forwards, simply zone transfer.
-- 
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: strange reply dumped URGENT

[Herman Brule via bind-users]

Thanks, I'm looking how solve this, cleanly.

In my country only 1 ISP have IPv6, then I need keep IPv4.

I have 1 IPv4 for 1000 VPS, no way here to have more IPv4.

Then:

1) I'm not sure if my DNS authoritative on IPv6 reply correctly (but 
reply correctly to all my dig query)


2) I have to provide a way to my customer can resolve query on their DNS 
server on their IPv6 VPS, their need be able to just put their vps dns 
or at least common server dns (where I had to put their zone, then I 
dislike this idea)


For now your method fail, include I try:

zone "ore.org.bo" {
    type master;
    file "/etc/bind/ore.org.bo.db";
};

But failed too.

alpha_one_x86/BRULE Herman
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server 
management
IT, OS, technologies, research & development, security and business department

On 7/12/24 19:01, Mark Andrews wrote:



On 13 Jul 2024, at 04:38, Herman Brule via bind-users 
 wrote:

Because the customer are into IPv6 zone

Well all zones should be served by both IPv4 servers and IPv6 servers.  IPv6 is 
nearly 30 years old now.  There are
sites that are IPv6 only because they would prefer to not have to run 
everything through 2 or 3 layers of NAT when
they don’t need it at all for IPv6 and would really like to not have to send 
all there DNS queries though NAT64 boxes.


And the EDGE router connecting IPv4 and IPv6 is internal to the data center 
company, not accessible for the customer.
Forward zone to edge will be more complex, it's more simple just forward the 
query.
Thanks for you observation, but I know, I doing this quickly, I will keep like 
this for now, this will produce only problem for availability if the server is 
down.

Except you are wrong.  You are writing here because it *is* causing you and 
everyone else a problem.  The correct way to
fix this is to transfer the zone contents to the listed primary servers if you 
are using nameservers.  Alternatively
don’t run nameservers at all but use IP level proxies. Either the whole address 
or port forward 53/TCP and 53/UDP.


alpha_one_x86/BRULE Herman
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server 
management
IT, OS, technologies, research & development, security and business department
On 7/12/24 14:28, Marco Moock wrote:

Am 12.07.2024 um 14:13:03 Uhr schrieb Herman Brule via bind-users:



bind to my proxy from IPv4 to IPv6 zone


Why don't you simply run multiple authoritative servers, some only
accessible by IPv6, some dual-stack?

They are independent of each other and only the zone transfer need to
work.

I also see some strange things:

m@ryz:~$ host 811.vps.confiared.com.
811.vps.CONFIARED.com has address 45.225.75.8
811.vps.CONFIARED.com has IPv6 address 2803:1920::c:1963
m@ryz:~$ host 811b.vps.confiared.com.
811b.vps.CONFIARED.com is an alias for 811.vps.confiared.com.
811.vps.CONFIARED.com has address 45.225.75.8
811.vps.CONFIARED.com has IPv6 address 2803:1920::c:1963
m@ryz:~$

You should have redundant servers and not 2 NS records that point to
the same machine.

Please fix that first and update your glue records.



--
Visithttps://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 athttps://www.isc.org/contact/  for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users$TTL 60
@   IN SOA 811.vps.confiared.com 811b.vps.confiared.com. confiared.com. 
(2020102000 86400 3600 360 300)
   3600 IN NS 811.vps.confiared.com.
   3600 IN MX 1 smtp.testadmin.ovh.
   3600 IN A 45.225.75.8
   3600 IN 2803:1920::c:1963
aIN A 45.225.75.8
IN  2803:1920::c:1963
smtpIN CNAME ore.org.bo.
wwwIN CNAME ore.org.bo.
*  IN CNAME ore.org.bo.
-- 
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: strange reply dumped URGENT

[Mark Andrews]

> On 13 Jul 2024, at 04:38, Herman Brule via bind-users 
>  wrote:
> 
> Because the customer are into IPv6 zone

Well all zones should be served by both IPv4 servers and IPv6 servers.  IPv6 is 
nearly 30 years old now.  There are
sites that are IPv6 only because they would prefer to not have to run 
everything through 2 or 3 layers of NAT when
they don’t need it at all for IPv6 and would really like to not have to send 
all there DNS queries though NAT64 boxes.

> And the EDGE router connecting IPv4 and IPv6 is internal to the data center 
> company, not accessible for the customer.
> Forward zone to edge will be more complex, it's more simple just forward the 
> query.
> Thanks for you observation, but I know, I doing this quickly, I will keep 
> like this for now, this will produce only problem for availability if the 
> server is down.

Except you are wrong.  You are writing here because it *is* causing you and 
everyone else a problem.  The correct way to
fix this is to transfer the zone contents to the listed primary servers if you 
are using nameservers.  Alternatively
don’t run nameservers at all but use IP level proxies. Either the whole address 
or port forward 53/TCP and 53/UDP.

> alpha_one_x86/BRULE Herman 
> Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and 
> server management
> IT, OS, technologies, research & development, security and business department
> On 7/12/24 14:28, Marco Moock wrote:
>> Am 12.07.2024 um 14:13:03 Uhr schrieb Herman Brule via bind-users:
>> 
>> 
>>> bind to my proxy from IPv4 to IPv6 zone
>>> 
>> Why don't you simply run multiple authoritative servers, some only
>> accessible by IPv6, some dual-stack?
>> 
>> They are independent of each other and only the zone transfer need to
>> work.
>> 
>> I also see some strange things:
>> 
>> m@ryz:~$ host 811.vps.confiared.com.
>> 811.vps.CONFIARED.com has address 45.225.75.8
>> 811.vps.CONFIARED.com has IPv6 address 2803:1920::c:1963
>> m@ryz:~$ host 811b.vps.confiared.com.
>> 811b.vps.CONFIARED.com is an alias for 811.vps.confiared.com.
>> 811.vps.CONFIARED.com has address 45.225.75.8
>> 811.vps.CONFIARED.com has IPv6 address 2803:1920::c:1963
>> m@ryz:~$ 
>> 
>> You should have redundant servers and not 2 NS records that point to
>> the same machine.
>> 
>> Please fix that first and update your glue records.
>> 
>> 
> -- 
> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@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: strange reply dumped URGENT

[Mark Andrews]

Named can NOT be configured as a proxy server for an authoritative server.  It 
is NOT
designed to be run like that.

Forwarding is for RECURSIVE queries (made by stub resolvers) not ITERATIVE 
queries (made
by recursive servers).  When you specify forwarding you tell the recursive 
server to behave
like a stub resolver for the specified namespace rather than being an iterative 
resolver.

Transfer the zone from the hidden primary rather than configuring forward mode.

zone ore.org.bo {
type secondary;
file “ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};

Mark

> On 13 Jul 2024, at 04:13, Herman Brule via bind-users 
>  wrote:
> 
> Hi,
> I have dns problem, mostly show by dig A smtp.ore.org.bo @8.8.8.8
> Then I have dump the connection by dumpcap, the raw reply by bind is wrong.
> As attached file:
> - dump of ethernet interface
> I have into /etc/bind/named.conf.rproxy:
> zone "ore.org.bo" { 
>type forward; 
>forward only; 
>forwarders { 2803:1920::c:1963; }; 
> };
> /etc/bind/named.conf have:
> include "/etc/bind/named.conf.rproxy";
> bind to my proxy from IPv4 to IPv6 zone
> dig A smtp.ore.org.bo @45.225.75.8
> show me correct reply
> dig A smtp.ore.org.bo @2803:1920::c:1963
> show me correct reply
> -- 
> alpha_one_x86/BRULE Herman 
> Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and 
> server management
> IT, OS, technologies, research & development, security and business department
> -- 
> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@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: strange reply dumped URGENT

[Herman Brule via bind-users]

I see 
https://mxtoolbox.com/SuperTool.aspx?action=a%3aore.org.bo=toolpage



 Loop detected! We were referred back to '45.225.75.8'

dns check 
 
	mx lookup 
 
	dmarc lookup 
 
	spf lookup 
 
	dns propagation 



Reported by *mxtoolbox.com* on 7/12/2024 at *2:40:49 PM*, just for you 
.


bind run on 45.225.75.8 with is the edge

The hostname is speedykvm

All query related to ore.org.bo have to be forwarded to 
2803:1920::c:1963 (811.vps.confiared.com) final customer VPS


Note dig report me:

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 0 (Other): ([45.225.75.8] Lame delegation at ore.org.bo for 
ore.org.bo/a)
; EDE: 22 (No Reachable Authority): (At delegation ore.org.bo for 
ore.org.bo/a)

;; QUESTION SECTION:
;ore.org.bo.

alpha_one_x86/BRULE Herman
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server 
management
IT, OS, technologies, research & development, security and business department

On 7/12/24 15:00, Marco Moock wrote:

Am 12.07.2024 um 14:56:28 Uhr schrieb Herman Brule via bind-users:


The edge router receive the query, should just forward to the IP into
the named.conf.rproxy (then IPv6 master)

So bind runs on this router?

What is the hostname of this router?
To which IP addresses does it point?
-- 
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: strange reply dumped URGENT

[Marco Moock]

Am 12.07.2024 um 14:56:28 Uhr schrieb Herman Brule via bind-users:

> The edge router receive the query, should just forward to the IP into 
> the named.conf.rproxy (then IPv6 master)

So bind runs on this router?

What is the hostname of this router?
To which IP addresses does it point?

-- 
Gruß
Marco

Send unsolicited bulk mail to 1720788988mu...@cartoonies.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: strange reply dumped URGENT

[Herman Brule via bind-users]

The edge router receive the query, should just forward to the IP into 
the named.conf.rproxy (then IPv6 master)


alpha_one_x86/BRULE Herman
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server 
management
IT, OS, technologies, research & development, security and business department

On 7/12/24 14:46, Marco Moock wrote:

Am 12.07.2024 um 14:38:58 Uhr schrieb Herman Brule:


Because the customer are into IPv6 zone

So the master DNS is IPv6 only?
No problem for the zone transfer.


And the EDGE router connecting IPv4 and IPv6 is internal to the data
center company, not accessible for the customer.

In which way is this router involved in DNS resolution?
-- 
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: strange reply dumped URGENT

[Marco Moock]

Am 12.07.2024 um 14:38:58 Uhr schrieb Herman Brule:

> Because the customer are into IPv6 zone

So the master DNS is IPv6 only?
No problem for the zone transfer.

> And the EDGE router connecting IPv4 and IPv6 is internal to the data 
> center company, not accessible for the customer.

In which way is this router involved in DNS resolution?

-- 
Gruß
Marco

Send unsolicited bulk mail to 1720787938mu...@cartoonies.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: strange reply dumped URGENT

[Herman Brule via bind-users]

Because the customer are into IPv6 zone

And the EDGE router connecting IPv4 and IPv6 is internal to the data 
center company, not accessible for the customer.


Forward zone to edge will be more complex, it's more simple just forward 
the query.


Thanks for you observation, but I know, I doing this quickly, I will 
keep like this for now, this will produce only problem for availability 
if the server is down.


alpha_one_x86/BRULE Herman
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server 
management
IT, OS, technologies, research & development, security and business department

On 7/12/24 14:28, Marco Moock wrote:

Am 12.07.2024 um 14:13:03 Uhr schrieb Herman Brule via bind-users:


bind to my proxy from IPv4 to IPv6 zone

Why don't you simply run multiple authoritative servers, some only
accessible by IPv6, some dual-stack?

They are independent of each other and only the zone transfer need to
work.

I also see some strange things:

m@ryz:~$ host 811.vps.confiared.com.
811.vps.CONFIARED.com has address 45.225.75.8
811.vps.CONFIARED.com has IPv6 address 2803:1920::c:1963
m@ryz:~$ host 811b.vps.confiared.com.
811b.vps.CONFIARED.com is an alias for 811.vps.confiared.com.
811.vps.CONFIARED.com has address 45.225.75.8
811.vps.CONFIARED.com has IPv6 address 2803:1920::c:1963
m@ryz:~$

You should have redundant servers and not 2 NS records that point to
the same machine.

Please fix that first and update your glue records.
-- 
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: strange reply dumped URGENT

[Marco Moock]

Am 12.07.2024 um 14:13:03 Uhr schrieb Herman Brule via bind-users:

> bind to my proxy from IPv4 to IPv6 zone

Why don't you simply run multiple authoritative servers, some only
accessible by IPv6, some dual-stack?

They are independent of each other and only the zone transfer need to
work.

I also see some strange things:

m@ryz:~$ host 811.vps.confiared.com.
811.vps.CONFIARED.com has address 45.225.75.8
811.vps.CONFIARED.com has IPv6 address 2803:1920::c:1963
m@ryz:~$ host 811b.vps.confiared.com.
811b.vps.CONFIARED.com is an alias for 811.vps.confiared.com.
811.vps.CONFIARED.com has address 45.225.75.8
811.vps.CONFIARED.com has IPv6 address 2803:1920::c:1963
m@ryz:~$ 

You should have redundant servers and not 2 NS records that point to
the same machine.

Please fix that first and update your glue records.

-- 
Gruß
Marco

Send unsolicited bulk mail to 1720786383mu...@cartoonies.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

strange reply dumped URGENT

[Herman Brule via bind-users]

Hi,

I have dns problem, mostly show by dig A smtp.ore.org.bo @8.8.8.8

Then I have dump the connection by dumpcap, the raw reply by bind is wrong.

As attached file:

- dump of ethernet interface

I have into /etc/bind/named.conf.rproxy:

zone "ore.org.bo" {
   type forward;
   forward only;
   forwarders { 2803:1920::c:1963; };
};

/etc/bind/named.conf have:

include "/etc/bind/named.conf.rproxy";

bind to my proxy from IPv4 to IPv6 zone

dig A smtp.ore.org.bo @45.225.75.8

show me correct reply

dig A smtp.ore.org.bo @2803:1920::c:1963

show me correct reply

--
alpha_one_x86/BRULE Herman
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server 
management
IT, OS, technologies, research & development, security and business department


dns.pcapng
Description: application/pcapng
-- 
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: Accepting TCP connection failed: socket is not connected

[Ondřej Surý]

There’s no issue. The message is already logged at INFO level.

Ondrej
--
Ondřej Surý — ISC (He/Him)

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

> On 12. 7. 2024, at 10:07, sami.ra...@sofrecom.com wrote:
> 
> Hello
> Do I need to update BIND to version 9.18 to fix this issue?
> 
> https://gitlab.isc.org/isc-projects/bind9/-/issues/2700
> Regards
> 
> -Message d'origine-
> De : bind-users  De la part de 
> bind-users-requ...@lists.isc.org
> Envoyé : jeudi 11 juillet 2024 20:26
> À : bind-users@lists.isc.org
> Objet : bind-users Digest, Vol 4508, Issue 1
> 
> --
> CAUTION : This email originated outside the company. Do not click on any 
> links or open attachments unless you are expecting them from the sender.
> 
> ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez 
> pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre 
> l'expéditeur.
> --
> 
> Send bind-users mailing list submissions to
>bind-users@lists.isc.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>https://lists.isc.org/mailman/listinfo/bind-users
> or, via email, send a message with subject or body 'help' to
>bind-users-requ...@lists.isc.org
> 
> You can reach the person managing the list at
>bind-users-ow...@lists.isc.org
> 
> When replying, please edit your Subject line so it is more specific than "Re: 
> Contents of bind-users digest..."
> 
> 
> Today's Topics:
> 
>   1. Accepting TCP connection failed: socket is not connected
>  (sami.ra...@sofrecom.com)
>   2. Re: Accepting TCP connection failed: socket is not connected
>  (Ond?ej Sur?)
> 
> 
> --
> 
> Message: 1
> Date: Thu, 11 Jul 2024 19:19:04 +
> From: sami.ra...@sofrecom.com
> To: "bind-users@lists.isc.org" 
> Subject: Accepting TCP connection failed: socket is not connected
> Message-ID:
>
> 
> 
> Content-Type: text/plain; charset="us-ascii"
> 
> Hello community,
> Could someone please help me understand these errors in the log of a resolver 
> server BIND 9.16.48 running on Red Hat 7 as the operating system.
> 
> Log :
> 07-Jul-2024 07:06:35.746 Accepting TCP connection failed: socket is not 
> connected
> 07-Jul-2024 07:07:29.724 Accepting TCP connection failed: socket is not 
> connected
> 
> Thank you in advance
> Orange Restricted
> 
> 
> 
> Orange Restricted
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> 
> 
> --
> 
> Message: 2
> Date: Thu, 11 Jul 2024 21:25:36 +0200
> From: Ond?ej Sur? 
> To: sami.ra...@sofrecom.com
> Cc: bind-users@lists.isc.org
> Subject: Re: Accepting TCP connection failed: socket is not connected
> Message-ID: <92cf7cbb-0c30-405e-9d5e-4bb584efe...@isc.org>
> Content-Type: text/plain; charset="utf-8"
> 
> It means what it says - the networking layer reports that the TCP socket is 
> no longer connected at the time named is accepting the connection. It means 
> that the client gave up between the 3-way handshake completion and accepting 
> the connection.
> 
> Ondrej
> --
> Ond?ej Sur? ? ISC (He/Him)
> 
> My working hours and your working hours may be different. Please do not feel 
> obligated to reply outside your normal working hours.
> 
>> On 11. 7. 2024, at 21:19, sami.ra...@sofrecom.com wrote:
>> 
>> ?
>> Hello community,
>> Could someone please help me understand these errors in the log of a 
>> resolver server BIND 9.16.48 running on Red Hat 7 as the operating system.
>> 
>> Log :
>> 07-Jul-2024 07:06:35.746 Accepting TCP connection failed: socket is
>> not connected
>> 07-Jul-2024 07:07:29.724 Accepting TCP connection failed: socket is
>> not connected
>> 
>> Thank you in advance
>> Orange Restricted
>> 
>> 
>> Orange Restricted
>> 
>> --
>> Visit
>> https://list/
>> s.isc.org%2Fmailman%2Flistinfo%2Fbind-users=05%7C02%7Csami.rahal%
>> 40sofrecom.com%7C08e125dc6574416e4fb908dca1df5593%7C90c7a20af34b40bfbc
>> 48b9253b6f5d20%7C0%7C0%7C638563227793302329%7CUnknown%7CTWFpbGZsb3d8ey
>> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
>> C%7C%7C=9bQUpEkd%2BMtuYOYi2Ad3XLPlu8nrvlCXW725FSBo9bA%3D
>> d=0 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://list/
>> s.isc.org%2Fmailman%2Flistinfo%2Fbind-users=05%7C02%7Csami.rahal%
>> 

RE: Accepting TCP connection failed: socket is not connected

[sami . rahal]

Hello
Do I need to update BIND to version 9.18 to fix this issue?

https://gitlab.isc.org/isc-projects/bind9/-/issues/2700
Regards

-Message d'origine-
De : bind-users  De la part de 
bind-users-requ...@lists.isc.org
Envoyé : jeudi 11 juillet 2024 20:26
À : bind-users@lists.isc.org
Objet : bind-users Digest, Vol 4508, Issue 1

--
CAUTION : This email originated outside the company. Do not click on any links 
or open attachments unless you are expecting them from the sender.

ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas 
sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre 
l'expéditeur.
--

Send bind-users mailing list submissions to
bind-users@lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/bind-users
or, via email, send a message with subject or body 'help' to
bind-users-requ...@lists.isc.org

You can reach the person managing the list at
bind-users-ow...@lists.isc.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of bind-users digest..."


Today's Topics:

   1. Accepting TCP connection failed: socket is not connected
  (sami.ra...@sofrecom.com)
   2. Re: Accepting TCP connection failed: socket is not connected
  (Ond?ej Sur?)


--

Message: 1
Date: Thu, 11 Jul 2024 19:19:04 +
From: sami.ra...@sofrecom.com
To: "bind-users@lists.isc.org" 
Subject: Accepting TCP connection failed: socket is not connected
Message-ID:



Content-Type: text/plain; charset="us-ascii"

Hello community,
Could someone please help me understand these errors in the log of a resolver 
server BIND 9.16.48 running on Red Hat 7 as the operating system.

Log :
07-Jul-2024 07:06:35.746 Accepting TCP connection failed: socket is not 
connected
07-Jul-2024 07:07:29.724 Accepting TCP connection failed: socket is not 
connected

Thank you in advance
Orange Restricted



Orange Restricted
-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 2
Date: Thu, 11 Jul 2024 21:25:36 +0200
From: Ond?ej Sur? 
To: sami.ra...@sofrecom.com
Cc: bind-users@lists.isc.org
Subject: Re: Accepting TCP connection failed: socket is not connected
Message-ID: <92cf7cbb-0c30-405e-9d5e-4bb584efe...@isc.org>
Content-Type: text/plain; charset="utf-8"

It means what it says - the networking layer reports that the TCP socket is no 
longer connected at the time named is accepting the connection. It means that 
the client gave up between the 3-way handshake completion and accepting the 
connection.

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

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

> On 11. 7. 2024, at 21:19, sami.ra...@sofrecom.com wrote:
>
> ?
> Hello community,
> Could someone please help me understand these errors in the log of a resolver 
> server BIND 9.16.48 running on Red Hat 7 as the operating system.
>
> Log :
> 07-Jul-2024 07:06:35.746 Accepting TCP connection failed: socket is
> not connected
> 07-Jul-2024 07:07:29.724 Accepting TCP connection failed: socket is
> not connected
>
> Thank you in advance
> Orange Restricted
>
>
> Orange Restricted
>
> --
> Visit
> https://list/
> s.isc.org%2Fmailman%2Flistinfo%2Fbind-users=05%7C02%7Csami.rahal%
> 40sofrecom.com%7C08e125dc6574416e4fb908dca1df5593%7C90c7a20af34b40bfbc
> 48b9253b6f5d20%7C0%7C0%7C638563227793302329%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7C=9bQUpEkd%2BMtuYOYi2Ad3XLPlu8nrvlCXW725FSBo9bA%3D
> d=0 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://list/
> s.isc.org%2Fmailman%2Flistinfo%2Fbind-users=05%7C02%7Csami.rahal%
> 40sofrecom.com%7C08e125dc6574416e4fb908dca1df5593%7C90c7a20af34b40bfbc
> 48b9253b6f5d20%7C0%7C0%7C638563227793312013%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7C=UwYbG4oLiZSOMPm7xLUyBF%2FR9J7vr9Qn1t76WfxRpgs%3D
> d=0
-- next part --
An HTML attachment was scrubbed...
URL: 


--

Subject: Digest Footer

___
ISC funds the development of this 

Re: Accepting TCP connection failed: socket is not connected

[Rob Foehl]

On Thu, 2024-07-11 at 21:25 +0200, Ondřej Surý wrote:
> It means what it says - the networking layer reports that the TCP socket is 
> no longer connected at the time named is accepting the connection. It means 
> that the client gave up between the 3-way handshake completion and accepting 
> the connection.

On that point, these entries aren't particularly useful without any
information about the other end of the attempted connection -- dialing
back the severity was an improvement, but how about just eliminating
them altogether?

-Rob
-- 
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: Accepting TCP connection failed: socket is not connected

[Ondřej Surý]

It means what it says - the networking layer reports that the TCP socket is no 
longer connected at the time named is accepting the connection. It means that 
the client gave up between the 3-way handshake completion and accepting the 
connection.

Ondrej
--
Ondřej Surý — ISC (He/Him)

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

> On 11. 7. 2024, at 21:19, sami.ra...@sofrecom.com wrote:
> 
> 
> Hello community,
> Could someone please help me understand these errors in the log of a resolver 
> server BIND 9.16.48 running on Red Hat 7 as the operating system.
>  
> Log :
> 07-Jul-2024 07:06:35.746 Accepting TCP connection failed: socket is not 
> connected
> 07-Jul-2024 07:07:29.724 Accepting TCP connection failed: socket is not 
> connected
>  
> Thank you in advance
> Orange Restricted
>  
> 
> Orange Restricted
> 
> --
> 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

Accepting TCP connection failed: socket is not connected

[sami . rahal]

Hello community,
Could someone please help me understand these errors in the log of a resolver 
server BIND 9.16.48 running on Red Hat 7 as the operating system.

Log :
07-Jul-2024 07:06:35.746 Accepting TCP connection failed: socket is not 
connected
07-Jul-2024 07:07:29.724 Accepting TCP connection failed: socket is not 
connected

Thank you in advance
Orange Restricted



Orange Restricted
-- 
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: netstat showing multiple lines for each listening socket

[Greg Choules]

I’m afraid we’re a little out of sync between the documentation and the code, 
depending on which code you’re running.

-U was changed some time ago to mean the number of dispatchers to use for 
outgoing queries, not listeners to use for incoming queries. Post 9.18 it won’t 
do anything at all, so best to ignore it. We will document this properly!

-n sets the number of event loops. You can tweak this manually if you find that 
the autodetected value is not suitable for your environment and usage.

I hope that helps.
Greg


> On 10 Jul 2024, at 15:43, Thomas Hungenberg via bind-users 
>  wrote:
> 
> On 10.07.24 14:20, Tom Marcoen (EXT) wrote:
>> My server has four (virtual; it runs on vSphere) CPUs and also shows four 
>> lines in `ss` output.
>> The `ps` command shows the `-U` which - I assume - is set automatically 
>> triggered by the number of CPUs.
>> # ps -elf | grep named
>> 5 S named23769 1  9  80   0 - 251941 do_sig 07:12 ?   00:39:02 
>> /usr/local/sbin/named -U4 -u named -c /usr/local/etc/namedb/named.conf
> 
> The manpage says:
> 
>   -U #listeners
>  This option tells named the number of #listeners worker  threads
>  to  listen  on, for incoming UDP packets on each address. If not
>  specified, named calculates a default value based on the  number
>  of  detected  CPUs: 1 for 1 CPU, and the number of detected CPUs
>  minus one for machines with more than 1 CPU.
> 
> 
> So if not specified, the value of "-U" should be set to 3 with four CPUs.
> Also, the parameter "-U" usually does not show up in the ps output if not 
> specified.
> 
> So in your case it looks more like named is specifically started with "-U4"?
> 
> 
>- Thomas
> 
> -- 
> 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: netstat showing multiple lines for each listening socket

[Thomas Hungenberg via bind-users]

On 10.07.24 14:20, Tom Marcoen (EXT) wrote:

My server has four (virtual; it runs on vSphere) CPUs and also shows four lines 
in `ss` output.

The `ps` command shows the `-U` which - I assume - is set automatically 
triggered by the number of CPUs.

# ps -elf | grep named
5 S named23769 1  9  80   0 - 251941 do_sig 07:12 ?   00:39:02 
/usr/local/sbin/named -U4 -u named -c /usr/local/etc/namedb/named.conf


The manpage says:

   -U #listeners
  This option tells named the number of #listeners worker  threads
  to  listen  on, for incoming UDP packets on each address. If not
  specified, named calculates a default value based on the  number
  of  detected  CPUs: 1 for 1 CPU, and the number of detected CPUs
  minus one for machines with more than 1 CPU.


So if not specified, the value of "-U" should be set to 3 with four CPUs.
Also, the parameter "-U" usually does not show up in the ps output if not 
specified.

So in your case it looks more like named is specifically started with "-U4"?


- Thomas

--
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: netstat showing multiple lines for each listening socket

[Tom Marcoen (EXT) via bind-users]

My server has four (virtual; it runs on vSphere) CPUs and also shows four lines 
in `ss` output.

The `ps` command shows the `-U` which - I assume - is set automatically 
triggered by the number of CPUs.

# ps -elf | grep named
5 S named23769 1  9  80   0 - 251941 do_sig 07:12 ?   00:39:02 
/usr/local/sbin/named -U4 -u named -c /usr/local/etc/namedb/named.conf

I am still in the process of figuring out my predecessor's custom setup...




-Oorspronkelijk bericht-
Van: Thomas Hungenberg 
Verzonden: dinsdag 9 juli 2024 14:52
Aan: Lee ; Tom Marcoen (EXT) 
; bind-users@lists.isc.org
Onderwerp: Re: netstat showing multiple lines for each listening socket

On 08.07.24 15:59, Lee wrote:
> How many cpus does your machine have?
> I'm running bind at home; not a whole lot of traffic to named so it
> seemed like all those threads were a waste.  So pretend there's only
> one cpu:
> $ grep bind /etc/default/named
> # OPTIONS="-u bind "
>OPTIONS="-u bind -n 1"

Thanks!
I can confirm netstat and ss show only one line per socket when starting
named with option "-n 1".

However, according to the manpage there should be "*two* threads per each CPU 
present":

=
-n #cpus
   This option controls the number of CPUs that named assumes the 
presence of.
   If not specified, named tries to determine the number of CPUs
   present automatically; if it fails, a single CPU is assumed to 
be present.

   named  creates  two  threads per each CPU present (one thread 
for receiving
   and sending client traffic and another thread for sending and
   receiving resolver traffic) and then on top of that a single 
thread for
   handling time-based events.
=

When running named without setting "-n" on a test VM with a single CPU assigned,
I see two threads per socket which matches what the manpage says.

When starting named with "-n 1" I would expect to see two threads as well
but there is only one in the netstat / ss output.

And on a small embedded system with a single CPU, it creates *four* threads
per socket.

Hmmm...


 - Thomas


Disclaimer High Tech Campus Eindhoven: The information contained in this 
message and attachments may be confidential and legally protected under 
applicable law. The message and attachments are intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby notified 
that any use, forwarding, dissemination, or reproduction of this message and 
attachments is strictly prohibited and may be unlawful. If you are not the 
intended recipient, please contact the sender by return e-mail and destroy all 
copies of the original message. Please visit: 
http://www.hightechcampus.com/go/pages/disclaimer for the most recent 
disclaimer.
-- 
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: netstat showing multiple lines for each listening socket

[Thomas Hungenberg via bind-users]

On 08.07.24 15:59, Lee wrote:

How many cpus does your machine have?
I'm running bind at home; not a whole lot of traffic to named so it
seemed like all those threads were a waste.  So pretend there's only
one cpu:
$ grep bind /etc/default/named
# OPTIONS="-u bind "
   OPTIONS="-u bind -n 1"


Thanks!
I can confirm netstat and ss show only one line per socket when starting
named with option "-n 1".

However, according to the manpage there should be "*two* threads per each CPU 
present":

=
   -n #cpus
  This option controls the number of CPUs that named assumes the 
presence of.
  If not specified, named tries to determine the number of CPUs
  present automatically; if it fails, a single CPU is assumed to be 
present.

  named  creates  two  threads per each CPU present (one thread for 
receiving
  and sending client traffic and another thread for sending and
  receiving resolver traffic) and then on top of that a single 
thread for
  handling time-based events.
=

When running named without setting "-n" on a test VM with a single CPU assigned,
I see two threads per socket which matches what the manpage says.

When starting named with "-n 1" I would expect to see two threads as well
but there is only one in the netstat / ss output.

And on a small embedded system with a single CPU, it creates *four* threads
per socket.

Hmmm...


- Thomas

--
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: netstat showing multiple lines for each listening socket

[Marc]

el9 bind-9.16, maybe netstat/os?

tcp0  0 x.x.x.x:530.0.0.0:*   LISTEN  
46622/named
tcp0  0 y.y.y.y:530.0.0.0:*   LISTEN  
46622/named
tcp0  0 127.0.0.1:53  0.0.0.0:*   LISTEN  
46622/named


> -Original Message-
> From: bind-users  On Behalf Of Thomas
> Hungenberg via bind-users
> Sent: Monday, 8 July 2024 10:53
> To: bind-users@lists.isc.org
> Subject: netstat showing multiple lines for each listening socket
> 
> Hello,
> 
> we have been running some BIND nameservers on Debian-based systems for
> many years.
> 
> Until (including) Debian 10 with BIND 9.11.5, netstat always showed only
> one line
> per listening socket, e.g.
> 
> tcp0  0 10.x.x.x:53 0.0.0.0:*
> LISTEN  1234/named
> tcp0  0 127.0.0.1:530.0.0.0:*
> LISTEN  1234/named
> udp0  0 10.x.x.x:53 0.0.0.0:*
> 1234/named
> udp0  0 127.0.0.1:530.0.0.0:*
> 1234/named
> 
> 
> We noticed that with Debian 11 and 12 (BIND 9.16.48 / 9.18.24), netstat
> instead
> shows multiple (on some systems four, on others up to 20) completely
> identical lines
> for each listening socket, like this:
> 
> tcp0  0 10.x.x.x:53 0.0.0.0:*
> LISTEN  1234/named
> tcp0  0 10.x.x.x:53 0.0.0.0:*
> LISTEN  1234/named
> tcp0  0 10.x.x.x:53 0.0.0.0:*
> LISTEN  1234/named
> tcp0  0 10.x.x.x:53 0.0.0.0:*
> LISTEN  1234/named
> tcp0  0 127.0.0.1:530.0.0.0:*
> LISTEN  1234/named
> tcp0  0 127.0.0.1:530.0.0.0:*
> LISTEN  1234/named
> tcp0  0 127.0.0.1:530.0.0.0:*
> LISTEN  1234/named
> tcp0  0 127.0.0.1:530.0.0.0:*
> LISTEN  1234/named
> udp0  0 10.x.x.x:53 0.0.0.0:*
> 1234/named
> udp0  0 10.x.x.x:53 0.0.0.0:*
> 1234/named
> udp0  0 10.x.x.x:53 0.0.0.0:*
> 1234/named
> udp0  0 10.x.x.x:53 0.0.0.0:*
> 1234/named
> udp0  0 127.0.0.1:530.0.0.0:*
> 1234/named
> udp0  0 127.0.0.1:530.0.0.0:*
> 1234/named
> udp0  0 127.0.0.1:530.0.0.0:*
> 1234/named
> udp0  0 127.0.0.1:530.0.0.0:*
> 1234/named
> 
> 
> We wonder what is causing this and if this is intended behaviour?
> 
> 
> - Thomas
> 
> --
> 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: zone_journal_compact: could not get zone size: not found

[Ondřej Surý]

You need to ask your supplier. BIND 9.16 is end-of-life and for all practical 
purposes,
everything that ISC provides doesn't have the problem. Unfortunately, RedHat 
decided
to provide FreeIP dyndb plugin under incompatible license with BIND 9, so we 
can't
really do anything about that.

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.

> On 9. 7. 2024, at 9:34, Kees Bakker  wrote:
> 
> Indeed the LDAP plugin does not provide the getsize method. Until now it 
> never has.
> I'll notify the maintainer.
> 
> I have a question that you may be able to answer. Is the getsize method a 
> required method or an optional one?
> If the latter then the zone_journal_compact function needs to become a bit 
> more friendly with its logging, because journalctl colors the message in red 
> (meaning: something is wrong here).
> -- Kees
> 
> On 08-07-2024 17:17, Ondřej Surý wrote:
>> You need to ask FreeIPA people and your vendor (but my guess is that the 
>> dyndb plugin provided by RH doesn’t provide this method).
>> --
>> 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 8. 7. 2024, at 16:48, Kees Bakker via bind-users 
>>>  wrote:
>>> 
>>>  Running gdb showed that the "not found" comes from this piece of code
>>> 
>>> isc_result_t
>>> dns_db_getsize(dns_db_t *db, dns_dbversion_t *version, uint64_t *records,
>>> uint64_t *bytes) {
>>> REQUIRE(DNS_DB_VALID(db));
>>> REQUIRE(dns_db_iszone(db));
>>> if (db->methods->getsize != NULL) {
>>> return ((db->methods->getsize)(db, version, records, bytes));
>>> }
>>> return (ISC_R_NOTFOUND);
>>> } That db->methods-getsize is NULL. Here is a piece of the gdb session 
>>> 08-Jul-2024 16:39:29.587 dump_done: zone 29.16.172.in-addr.arpa/IN: enter 
>>> Thread 2 "isc-net-" hit Breakpoint 2, zone_journal_compact 
>>> (zone=0x7062ffd0, db=0x76151268, serial=1720448567) at 
>>> ../../../lib/dns/zone.c:11654 11654 dns_db_currentversion(db, ); (gdb) 
>>> n 11655 result = dns_db_getsize(db, ver, NULL, ); (gdb) s 
>>> dns_db_getsize (db=0x76151268, version=0x7fffdba86640, records=0x0, 
>>> bytes=0x75fcc4b8) at ../../../lib/dns/db.c:955 955 uint64_t *bytes) { 
>>> (gdb) n 956 REQUIRE(DNS_DB_VALID(db)); (gdb) 957 
>>> REQUIRE(dns_db_iszone(db)); (gdb) 959 if (db->methods->getsize != NULL) { 
>>> (gdb) p db->methods->getsize $3 = (isc_result_t (*)(dns_db_t *, 
>>> dns_dbversion_t *, uint64_t *, uint64_t *)) 0x0 The question now is: why is 
>>> that getsize method NULL? Or, should it never have gotten here? 
>>> -- Kees
>>> 
>>> On 08-07-2024 13:42, Greg Choules wrote:
 *** EXTERNAL E-MAIL ***
 
 Hi Kees. 
 A few questions:
 - What version of BIND are you running?
 - How large (number of RRs) are your zones?
 - What is the peak rate of dynamic updates?
 - Do you have "max-journal-size" configured to anything?
 - Are you perhaps getting short on disc storage in the place where BIND 
 keeps its files?
 - How much RAM does the server have and how much of that is BIND using?
 
 I would recommend reading the ARM section on the journal. The log message 
 itself comes from "zone.c"
 
 Cheers, Greg
 
 On Mon, 8 Jul 2024 at 12:18, Kees Bakker via bind-users 
  wrote:
 Hi,
 
 At the moment I have three FreeIPA systems (replicas), recently 
 installed with CentOS 9-Stream.
 All three of these show this message at irregular intervals.
 
 Jul 03 07:50:44 iparep5.example.com named[541]: zone example.com/IN: 
 zone_journal_compact: could not get zone size: not found
 Jul 03 07:50:51 iparep5.example.com named[541]: zone 
 16.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
 size: not found
 Jul 03 07:51:03 iparep5.example.com named[541]: zone 
 17.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
 size: not found
 Jul 03 07:51:34 iparep5.example.com named[541]: zone 
 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
 size: not found
 Jul 03 07:52:12 iparep5.example.com named[541]: zone 
 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
 size: not found
 Jul 03 08:03:51 iparep5.example.com named[541]: zone example.com/IN: 
 zone_journal_compact: could not get zone size: not found
 Jul 03 08:04:52 iparep5.example.com named[541]: zone 
 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
 size: not found
 Jul 03 08:06:30 iparep5.example.com named[541]: zone 
 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
 size: not found
 Jul 03 08:18:42 iparep5.example.com named[541]: zone example.com/IN: 
 zone_journal_compact: could not get zone 

Re: zone_journal_compact: could not get zone size: not found

[Kees Bakker via bind-users]

Indeed the LDAP plugin does not provide the getsize method. Until now it 
never has.

I'll notify the maintainer.

I have a question that you may be able to answer. Is the getsize method 
a required method or an optional one?
If the latter then the zone_journal_compact function needs to become a 
bit more friendly with its logging, because journalctl colors the 
message in red (meaning: something is wrong here).

-- Kees

On 08-07-2024 17:17, Ondřej Surý wrote:
You need to ask FreeIPA people and your vendor (but my guess is that 
the dyndb plugin provided by RH doesn’t provide this method).

--
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 8. 7. 2024, at 16:48, Kees Bakker via bind-users 
 wrote:


 Running gdb showed that the "not found" comes from this piece of code

isc_result_t
dns_db_getsize(dns_db_t*db, dns_dbversion_t*version, uint64_t*records,
uint64_t*bytes) {
REQUIRE(DNS_DB_VALID(db));
REQUIRE(dns_db_iszone(db));
if(db->methods->getsize!= NULL) {
return((db->methods->getsize)(db, version, records, bytes));
}
return(ISC_R_NOTFOUND);
} That db->methods-getsize is NULL. Here is a piece of the gdb 
session 08-Jul-2024 16:39:29.587 dump_done: zone 
29.16.172.in-addr.arpa/IN: enter Thread 2 "isc-net-" hit 
Breakpoint 2, zone_journal_compact (zone=0x7062ffd0, 
db=0x76151268, serial=1720448567) at 
../../../lib/dns/zone.c:11654 11654 dns_db_currentversion(db, ); 
(gdb) n 11655 result = dns_db_getsize(db, ver, NULL, ); (gdb) 
s dns_db_getsize (db=0x76151268, version=0x7fffdba86640, 
records=0x0, bytes=0x75fcc4b8) at ../../../lib/dns/db.c:955 955 
uint64_t *bytes) { (gdb) n 956 REQUIRE(DNS_DB_VALID(db)); (gdb) 957 
REQUIRE(dns_db_iszone(db)); (gdb) 959 if (db->methods->getsize != 
NULL) { (gdb) p db->methods->getsize $3 = (isc_result_t (*)(dns_db_t 
*, dns_dbversion_t *, uint64_t *, uint64_t *)) 0x0 The question now 
is: why is that getsize method NULL? Or, should it never have gotten 
here?

-- Kees

On 08-07-2024 13:42, Greg Choules wrote:

 EXTERNAL E-MAIL 

Hi Kees.
A few questions:
- What version of BIND are you running?
- How large (number of RRs) are your zones?
- What is the peak rate of dynamic updates?
- Do you have "max-journal-size" configured to anything?
- Are you perhaps getting short on disc storage in the place where 
BIND keeps its files?

- How much RAM does the server have and how much of that is BIND using?

I would recommend reading the ARM section on the journal. The log 
message itself comes from "zone.c"


Cheers, Greg

On Mon, 8 Jul 2024 at 12:18, Kees Bakker via bind-users 
 wrote:


Hi,

At the moment I have three FreeIPA systems (replicas), recently
installed with CentOS 9-Stream.
All three of these show this message at irregular intervals.

Jul 03 07:50:44 iparep5.example.com 
named[541]: zone example.com/IN :
zone_journal_compact: could not get zone size: not found
Jul 03 07:50:51 iparep5.example.com 
named[541]: zone
16.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 07:51:03 iparep5.example.com 
named[541]: zone
17.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 07:51:34 iparep5.example.com 
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 07:52:12 iparep5.example.com 
named[541]: zone
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:03:51 iparep5.example.com 
named[541]: zone example.com/IN :
zone_journal_compact: could not get zone size: not found
Jul 03 08:04:52 iparep5.example.com 
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:06:30 iparep5.example.com 
named[541]: zone
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:18:42 iparep5.example.com 
named[541]: zone example.com/IN :
zone_journal_compact: could not get zone size: not found
Jul 03 08:20:19 iparep5.example.com 
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:26:23 iparep5.example.com 
named[541]: zone
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:34:12 iparep5.example.com 
named[541]: 

Re: zone_journal_compact: could not get zone size: not found

[Ondřej Surý]

You need to ask FreeIPA people and your vendor (but my guess is that the dyndb plugin provided by RH doesn’t provide this method).--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 8. 7. 2024, at 16:48, Kees Bakker via bind-users  wrote:

  
  
Running gdb showed that the "not found" comes from this piece of
code

isc_result_tdns_db_getsize(dns_db_t *db, dns_dbversion_t *version, uint64_t *records,   uint64_t *bytes) {REQUIRE(DNS_DB_VALID(db));REQUIRE(dns_db_iszone(db));
if (db->methods->getsize != NULL) {return ((db->methods->getsize)(db, version, records, bytes));}
return (ISC_R_NOTFOUND);}

That db->methods-getsize is NULL.

Here is a piece of the gdb session
08-Jul-2024 16:39:29.587 dump_done: zone 29.16.172.in-addr.arpa/IN: enter

Thread 2 "isc-net-" hit Breakpoint 2, zone_journal_compact (zone=0x7062ffd0, db=0x76151268, serial=1720448567) at ../../../lib/dns/zone.c:11654
11654			dns_db_currentversion(db, );
(gdb) n
11655			result = dns_db_getsize(db, ver, NULL, );
(gdb) s
dns_db_getsize (db=0x76151268, version=0x7fffdba86640, records=0x0, bytes=0x75fcc4b8) at ../../../lib/dns/db.c:955
955		   uint64_t *bytes) {
(gdb) n
956		REQUIRE(DNS_DB_VALID(db));
(gdb) 
957		REQUIRE(dns_db_iszone(db));
(gdb) 
959		if (db->methods->getsize != NULL) {
(gdb) p db->methods->getsize
$3 = (isc_result_t (*)(dns_db_t *, dns_dbversion_t *, uint64_t *, uint64_t *)) 0x0

The question now is: why is that getsize method NULL? Or, should it never have gotten here?

-- Kees

On 08-07-2024 13:42, Greg Choules
  wrote:


  
  
***
EXTERNAL E-MAIL ***
  
  
Hi Kees.
  A few questions:
  - What version of BIND are you running?
  - How large (number of RRs) are your zones?
  - What is the peak rate of dynamic updates?
  - Do you have "max-journal-size" configured to anything?
  - Are you perhaps getting short on disc storage in the
place where BIND keeps its files?
  - How much RAM does the server have and how much of that
is BIND using?
  
  
  I would recommend reading the ARM section on the journal.
The log message itself comes from "zone.c"
  
  
  Cheers, Greg



  On Mon, 8 Jul 2024 at 12:18,
Kees Bakker via bind-users 
wrote:
  
  
Hi,

At the moment I have three FreeIPA systems (replicas),
recently 
installed with CentOS 9-Stream.
All three of these show this message at irregular intervals.

Jul 03 07:50:44 
  iparep5.example.com named[541]: zone 
  example.com/IN: 
zone_journal_compact: could not get zone size: not found
Jul 03 07:50:51 
  iparep5.example.com named[541]: zone 
16.16.172.in-addr.arpa/IN: zone_journal_compact: could not
get zone 
size: not found
Jul 03 07:51:03 
  iparep5.example.com named[541]: zone 
17.16.172.in-addr.arpa/IN: zone_journal_compact: could not
get zone 
size: not found
Jul 03 07:51:34 
  iparep5.example.com named[541]: zone 
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not
get zone 
size: not found
Jul 03 07:52:12 
  iparep5.example.com named[541]: zone 
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not
get zone 
size: not found
Jul 03 08:03:51 
  iparep5.example.com named[541]: zone 
  example.com/IN: 
zone_journal_compact: could not get zone size: not found
Jul 03 08:04:52 
  iparep5.example.com named[541]: zone 
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not
get zone 
size: not found
Jul 03 08:06:30 
  iparep5.example.com named[541]: zone 
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not
get zone 
size: not found
Jul 03 08:18:42 
  iparep5.example.com named[541]: zone 
  example.com/IN: 
zone_journal_compact: could not get zone size: not found
Jul 03 08:20:19 
  iparep5.example.com named[541]: zone 
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not
get zone 
size: not found
Jul 03 08:26:23 
  iparep5.example.com named[541]: zone 

Re: zone_journal_compact: could not get zone size: not found

[Kees Bakker via bind-users]

Running gdb showed that the "not found" comes from this piece of code

isc_result_t
dns_db_getsize(dns_db_t*db, dns_dbversion_t*version, uint64_t*records,
uint64_t*bytes) {
REQUIRE(DNS_DB_VALID(db));
REQUIRE(dns_db_iszone(db));
if(db->methods->getsize!= NULL) {
return((db->methods->getsize)(db, version, records, bytes));
}
return(ISC_R_NOTFOUND);
} That db->methods-getsize is NULL. Here is a piece of the gdb session 
08-Jul-2024 16:39:29.587 dump_done: zone 29.16.172.in-addr.arpa/IN: 
enter Thread 2 "isc-net-" hit Breakpoint 2, zone_journal_compact 
(zone=0x7062ffd0, db=0x76151268, serial=1720448567) at 
../../../lib/dns/zone.c:11654 11654 dns_db_currentversion(db, ); 
(gdb) n 11655 result = dns_db_getsize(db, ver, NULL, ); (gdb) s 
dns_db_getsize (db=0x76151268, version=0x7fffdba86640, records=0x0, 
bytes=0x75fcc4b8) at ../../../lib/dns/db.c:955 955 uint64_t *bytes) 
{ (gdb) n 956 REQUIRE(DNS_DB_VALID(db)); (gdb) 957 
REQUIRE(dns_db_iszone(db)); (gdb) 959 if (db->methods->getsize != NULL) 
{ (gdb) p db->methods->getsize $3 = (isc_result_t (*)(dns_db_t *, 
dns_dbversion_t *, uint64_t *, uint64_t *)) 0x0 The question now is: why 
is that getsize method NULL? Or, should it never have gotten here?

-- Kees

On 08-07-2024 13:42, Greg Choules wrote:

 EXTERNAL E-MAIL 

Hi Kees.
A few questions:
- What version of BIND are you running?
- How large (number of RRs) are your zones?
- What is the peak rate of dynamic updates?
- Do you have "max-journal-size" configured to anything?
- Are you perhaps getting short on disc storage in the place where 
BIND keeps its files?

- How much RAM does the server have and how much of that is BIND using?

I would recommend reading the ARM section on the journal. The log 
message itself comes from "zone.c"


Cheers, Greg

On Mon, 8 Jul 2024 at 12:18, Kees Bakker via bind-users 
 wrote:


Hi,

At the moment I have three FreeIPA systems (replicas), recently
installed with CentOS 9-Stream.
All three of these show this message at irregular intervals.

Jul 03 07:50:44 iparep5.example.com 
named[541]: zone example.com/IN :
zone_journal_compact: could not get zone size: not found
Jul 03 07:50:51 iparep5.example.com 
named[541]: zone
16.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 07:51:03 iparep5.example.com 
named[541]: zone
17.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 07:51:34 iparep5.example.com 
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 07:52:12 iparep5.example.com 
named[541]: zone
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:03:51 iparep5.example.com 
named[541]: zone example.com/IN :
zone_journal_compact: could not get zone size: not found
Jul 03 08:04:52 iparep5.example.com 
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:06:30 iparep5.example.com 
named[541]: zone
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:18:42 iparep5.example.com 
named[541]: zone example.com/IN :
zone_journal_compact: could not get zone size: not found
Jul 03 08:20:19 iparep5.example.com 
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:26:23 iparep5.example.com 
named[541]: zone
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:34:12 iparep5.example.com 
named[541]: zone example.com/IN :
zone_journal_compact: could not get zone size: not found
Jul 03 08:34:50 iparep5.example.com 
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found

I have been running FreeIPA (including the bind nameserver) for
several
years now and I have never seen this message before.
I still have one FreeIPA system running CentOS 8-Stream.

Does anyone have a clue what it can be? Or how to find out? There are
close to zero hits when I searched for this on the internet.
How to debug this? (How to debug this in a production environment,
ha ha)
-- 
Kees
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to

unsubscribe from this list

  

Re: netstat showing multiple lines for each listening socket

[Lee]

On Mon, Jul 8, 2024 at 7:52 AM Tom Marcoen (EXT) via bind-users
 wrote:
>
> I observe the same behaviour. I have similar output for TCP/53 on the 
> loopback and public IP addresses. The IP addresses and port numbers are the 
> same, but the fd (file descriptors?) are different. I assumed different 
> threads of the same process.
>
> # named -V | grep ^BIND
> BIND 9.18.26 (Extended Support Version) 
> # ss -lntp | grep 953
> LISTEN   0   5   127.0.0.1:953   *:*   users:(("named",pid=9623,fd=64))
> LISTEN   0   5   127.0.0.1:953   *:*   users:(("named",pid=9623,fd=61))
> LISTEN   0   5   127.0.0.1:953   *:*   users:(("named",pid=9623,fd=63))
> LISTEN   0   5   127.0.0.1:953   *:*   users:(("named",pid=9623,fd=62))

How many cpus does your machine have?
I'm running bind at home; not a whole lot of traffic to named so it
seemed like all those threads were a waste.  So pretend there's only
one cpu:
$ grep bind /etc/default/named
# OPTIONS="-u bind "
  OPTIONS="-u bind -n 1"

$ ps -elf | grep [b]ind
4 S bind 944   1  0  80   0 - 103557 - Jul07 ?
00:00:31 /usr/sbin/named -f -u bind -n 1

$ ss -lntp | grep 953
LISTEN 0  4096127.0.0.1:953   0.0.0.0:*
LISTEN 0  4096[::1]:953  [::]:*

Regards,
Lee



> -Oorspronkelijk bericht-
> Van: bind-users  Namens Thomas Hungenberg 
> via bind-users
> Verzonden: maandag 8 juli 2024 13:13
> Aan: Robert Wagner ; bind-users@lists.isc.org
> Onderwerp: Re: netstat showing multiple lines for each listening socket
>
> Hi Robert,
>
> it's the same PID for all lines, parent process is systemd.
>
> The lines in the netstat output are exact duplicates (same IP, port and PID).
> Other tools like ss show the same, so it's not a problem with netstat.
>
> It's the same bahaviour on different machines, some upgraded from Debian < 11
> and others installed from scratch with Debian 11 or 12.
>
> I also set up a test VM and started BIND with the default configuration 
> shipped with Debian.
> Same behaviour: All lines are shown twice.
>
> It looks like on machines with only two interfaces (lo / eth0) the lines are 
> shown twice
> while on machines with more interfaces (active or not) there are up to 20 
> duplicate lines.
>
>
>  - Thomas
>
>
> On 08.07.24 12:10, Robert Wagner wrote:
> > Some diagnostics is needed.  When you reboot, does it show it up multiple 
> > binds to the same port?  Can your run netstat -tP to identify the process 
> > ID (are they the same or different).  There may also be other options to 
> > provide more diagnostics.
> >
> > -Trying to determine if you are really binding the service four times to 
> > the same port or this is just a ghost in the netstat program...  Most 
> > systems are designed to prevent binding multiple applications to the same 
> > ip/port, but a service can spawn multiple threads on the same ip/port.  You 
> > may be seeing the threads and not unique service instances.
> >
> > Looking at the process ID, you may be able to track back to the root 
> > process and determine if these are just service threads.
> >
> >
> > Robert Wagner
> >
> > 
> > From: bind-users  on behalf of Thomas 
> > Hungenberg via bind-users 
> > Sent: Monday, July 8, 2024 4:52 AM
> > To: bind-users@lists.isc.org 
> > Subject: netstat showing multiple lines for each listening socket
> >
> > This email originated from outside of TESLA
> >
> > Do not click links or open attachments unless you recognize the sender and 
> > know the content is safe.
> >
> > Hello,
> >
> > we have been running some BIND nameservers on Debian-based systems for many 
> > years.
> >
> > Until (including) Debian 10 with BIND 9.11.5, netstat always showed only 
> > one line
> > per listening socket, e.g.
> >
> > tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
> > 1234/named
> > tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
> > 1234/named
> > udp0  0 10.x.x.x:53 0.0.0.0:*   
> > 1234/named
> > udp0  0 127.0.0.1:530.0.0.0:*   
> > 1234/named
> >
> >
> > We noticed that with Debian 11 and 12 (BIND 9.16.48 / 9.18.24), netstat 
> > instead
> > shows multiple (on some systems four, on others up to 20) completely 
> > identical lines
> > for each listening socket, like this:
> >
> > tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
> > 1234/named
> > tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
> > 1234/named
> > tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
> > 1234/named
> > tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
> > 1234/named
> > tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
> > 1234/named
> > tcp0  0 127.0.0.1:530.0.0.0:*   

Re: zone_journal_compact: could not get zone size: not found

[Kees Bakker via bind-users]

On 08-07-2024 13:42, Greg Choules wrote:
Hi Kees. 


Hi Greg, thanks for the quick reply.


A few questions:
- What version of BIND are you running?

9.16.23 (in centos that is 32:9.16.23-15.el9)


- How large (number of RRs) are your zones?
My main zone (renamed to example.com) is about 800 RRs (if I interpret 
RR correctly).

The in-addr.arpa zones have 150-200 entrie.
What you need to know is that this is a FreeIPA environment. The zones 
are stored in LDAP.
The DHCP sends its updates to one of the bind servers. These updates are 
then replicated in LDAP.



- What is the peak rate of dynamic updates?

Don't know. Is there is simple command to show this.


- Do you have "max-journal-size" configured to anything?

That should be the default. I haven't specifically changed it.

- Are you perhaps getting short on disc storage in the place where 
BIND keeps its files?
No. Many GBs free disk space. The jnl files that I see are just a few 
kbs in size.



- How much RAM does the server have and how much of that is BIND using?
One has 8GB. Two others have 128GB (because they run in an LXC/Incus 
container).




I would recommend reading the ARM section on the journal. The log 
message itself comes from "zone.c"
OK. I have a global understanding what the journal is doing. I went 
through the zone.c code before posting this here.
But so far I could not figure out how this message can be triggered. And 
also, the systems didn't show this message before upgrading CentOS.

One system is still at CentOS 8-Stream. The message isn't shown on that one.



Cheers, Greg

-- Kees



On Mon, 8 Jul 2024 at 12:18, Kees Bakker via bind-users 
 wrote:


Hi,

At the moment I have three FreeIPA systems (replicas), recently
installed with CentOS 9-Stream.
All three of these show this message at irregular intervals.

Jul 03 07:50:44 iparep5.example.com 
named[541]: zone example.com/IN :
zone_journal_compact: could not get zone size: not found
Jul 03 07:50:51 iparep5.example.com 
named[541]: zone
16.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 07:51:03 iparep5.example.com 
named[541]: zone
17.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 07:51:34 iparep5.example.com 
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 07:52:12 iparep5.example.com 
named[541]: zone
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:03:51 iparep5.example.com 
named[541]: zone example.com/IN :
zone_journal_compact: could not get zone size: not found
Jul 03 08:04:52 iparep5.example.com 
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:06:30 iparep5.example.com 
named[541]: zone
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:18:42 iparep5.example.com 
named[541]: zone example.com/IN :
zone_journal_compact: could not get zone size: not found
Jul 03 08:20:19 iparep5.example.com 
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:26:23 iparep5.example.com 
named[541]: zone
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:34:12 iparep5.example.com 
named[541]: zone example.com/IN :
zone_journal_compact: could not get zone size: not found
Jul 03 08:34:50 iparep5.example.com 
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found

I have been running FreeIPA (including the bind nameserver) for
several
years now and I have never seen this message before.
I still have one FreeIPA system running CentOS 8-Stream.

Does anyone have a clue what it can be? Or how to find out? There are
close to zero hits when I searched for this on the internet.
How to debug this? (How to debug this in a production environment,
ha ha)
-- 
Kees
-- 
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
  

RE: netstat showing multiple lines for each listening socket

[Tom Marcoen (EXT) via bind-users]

I observe the same behaviour. I have similar output for TCP/53 on the loopback 
and public IP addresses. The IP addresses and port numbers are the same, but 
the fd (file descriptors?) are different. I assumed different threads of the 
same process.

# named -V | grep ^BIND
BIND 9.18.26 (Extended Support Version) 
# ss -lntp | grep 953
LISTEN   0   5   127.0.0.1:953   *:*   users:(("named",pid=9623,fd=64))
LISTEN   0   5   127.0.0.1:953   *:*   users:(("named",pid=9623,fd=61))
LISTEN   0   5   127.0.0.1:953   *:*   users:(("named",pid=9623,fd=63))
LISTEN   0   5   127.0.0.1:953   *:*   users:(("named",pid=9623,fd=62))



-Oorspronkelijk bericht-
Van: bind-users  Namens Thomas Hungenberg via 
bind-users
Verzonden: maandag 8 juli 2024 13:13
Aan: Robert Wagner ; bind-users@lists.isc.org
Onderwerp: Re: netstat showing multiple lines for each listening socket

Hi Robert,

it's the same PID for all lines, parent process is systemd.

The lines in the netstat output are exact duplicates (same IP, port and PID).
Other tools like ss show the same, so it's not a problem with netstat.

It's the same bahaviour on different machines, some upgraded from Debian < 11
and others installed from scratch with Debian 11 or 12.

I also set up a test VM and started BIND with the default configuration shipped 
with Debian.
Same behaviour: All lines are shown twice.

It looks like on machines with only two interfaces (lo / eth0) the lines are 
shown twice
while on machines with more interfaces (active or not) there are up to 20 
duplicate lines.


 - Thomas


On 08.07.24 12:10, Robert Wagner wrote:
> Some diagnostics is needed.  When you reboot, does it show it up multiple 
> binds to the same port?  Can your run netstat -tP to identify the process ID 
> (are they the same or different).  There may also be other options to provide 
> more diagnostics.
>
> -Trying to determine if you are really binding the service four times to the 
> same port or this is just a ghost in the netstat program...  Most systems are 
> designed to prevent binding multiple applications to the same ip/port, but a 
> service can spawn multiple threads on the same ip/port.  You may be seeing 
> the threads and not unique service instances.
>
> Looking at the process ID, you may be able to track back to the root process 
> and determine if these are just service threads.
>
>
> Robert Wagner
>
> 
> From: bind-users  on behalf of Thomas 
> Hungenberg via bind-users 
> Sent: Monday, July 8, 2024 4:52 AM
> To: bind-users@lists.isc.org 
> Subject: netstat showing multiple lines for each listening socket
>
> This email originated from outside of TESLA
>
> Do not click links or open attachments unless you recognize the sender and 
> know the content is safe.
>
> Hello,
>
> we have been running some BIND nameservers on Debian-based systems for many 
> years.
>
> Until (including) Debian 10 with BIND 9.11.5, netstat always showed only one 
> line
> per listening socket, e.g.
>
> tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN
>   1234/named
> tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN
>   1234/named
> udp0  0 10.x.x.x:53 0.0.0.0:* 
>   1234/named
> udp0  0 127.0.0.1:530.0.0.0:* 
>   1234/named
>
>
> We noticed that with Debian 11 and 12 (BIND 9.16.48 / 9.18.24), netstat 
> instead
> shows multiple (on some systems four, on others up to 20) completely 
> identical lines
> for each listening socket, like this:
>
> tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN
>   1234/named
> tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN
>   1234/named
> tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN
>   1234/named
> tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN
>   1234/named
> tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN
>   1234/named
> tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN
>   1234/named
> tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN
>   1234/named
> tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN
>   1234/named
> udp0  0 10.x.x.x:53 0.0.0.0:* 
>   1234/named
> udp0  0 10.x.x.x:53 0.0.0.0:* 
>   1234/named
> udp0  0 10.x.x.x:53 0.0.0.0:* 
>   1234/named
> udp0  0 10.x.x.x:53 0.0.0.0:* 
>   1234/named
> udp0  0 127.0.0.1:530.0.0.0:* 
>   1234/named
> udp0  0 127.0.0.1:530.0.0.0:* 
>   1234/named
> udp0  0 127.0.0.1:53   

Re: zone_journal_compact: could not get zone size: not found

[Greg Choules via bind-users]

Hi Kees.
A few questions:
- What version of BIND are you running?
- How large (number of RRs) are your zones?
- What is the peak rate of dynamic updates?
- Do you have "max-journal-size" configured to anything?
- Are you perhaps getting short on disc storage in the place where BIND
keeps its files?
- How much RAM does the server have and how much of that is BIND using?

I would recommend reading the ARM section on the journal. The log message
itself comes from "zone.c"

Cheers, Greg

On Mon, 8 Jul 2024 at 12:18, Kees Bakker via bind-users <
bind-users@lists.isc.org> wrote:

> Hi,
>
> At the moment I have three FreeIPA systems (replicas), recently
> installed with CentOS 9-Stream.
> All three of these show this message at irregular intervals.
>
> Jul 03 07:50:44 iparep5.example.com named[541]: zone example.com/IN:
> zone_journal_compact: could not get zone size: not found
> Jul 03 07:50:51 iparep5.example.com named[541]: zone
> 16.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
> Jul 03 07:51:03 iparep5.example.com named[541]: zone
> 17.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
> Jul 03 07:51:34 iparep5.example.com named[541]: zone
> 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
> Jul 03 07:52:12 iparep5.example.com named[541]: zone
> 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
> Jul 03 08:03:51 iparep5.example.com named[541]: zone example.com/IN:
> zone_journal_compact: could not get zone size: not found
> Jul 03 08:04:52 iparep5.example.com named[541]: zone
> 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
> Jul 03 08:06:30 iparep5.example.com named[541]: zone
> 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
> Jul 03 08:18:42 iparep5.example.com named[541]: zone example.com/IN:
> zone_journal_compact: could not get zone size: not found
> Jul 03 08:20:19 iparep5.example.com named[541]: zone
> 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
> Jul 03 08:26:23 iparep5.example.com named[541]: zone
> 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
> Jul 03 08:34:12 iparep5.example.com named[541]: zone example.com/IN:
> zone_journal_compact: could not get zone size: not found
> Jul 03 08:34:50 iparep5.example.com named[541]: zone
> 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
>
> I have been running FreeIPA (including the bind nameserver) for several
> years now and I have never seen this message before.
> I still have one FreeIPA system running CentOS 8-Stream.
>
> Does anyone have a clue what it can be? Or how to find out? There are
> close to zero hits when I searched for this on the internet.
> How to debug this? (How to debug this in a production environment, ha ha)
> --
> Kees
> --
> 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

zone_journal_compact: could not get zone size: not found

[Kees Bakker via bind-users]

Hi,

At the moment I have three FreeIPA systems (replicas), recently 
installed with CentOS 9-Stream.

All three of these show this message at irregular intervals.

Jul 03 07:50:44 iparep5.example.com named[541]: zone example.com/IN: 
zone_journal_compact: could not get zone size: not found
Jul 03 07:50:51 iparep5.example.com named[541]: zone 
16.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found
Jul 03 07:51:03 iparep5.example.com named[541]: zone 
17.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found
Jul 03 07:51:34 iparep5.example.com named[541]: zone 
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found
Jul 03 07:52:12 iparep5.example.com named[541]: zone 
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found
Jul 03 08:03:51 iparep5.example.com named[541]: zone example.com/IN: 
zone_journal_compact: could not get zone size: not found
Jul 03 08:04:52 iparep5.example.com named[541]: zone 
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found
Jul 03 08:06:30 iparep5.example.com named[541]: zone 
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found
Jul 03 08:18:42 iparep5.example.com named[541]: zone example.com/IN: 
zone_journal_compact: could not get zone size: not found
Jul 03 08:20:19 iparep5.example.com named[541]: zone 
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found
Jul 03 08:26:23 iparep5.example.com named[541]: zone 
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found
Jul 03 08:34:12 iparep5.example.com named[541]: zone example.com/IN: 
zone_journal_compact: could not get zone size: not found
Jul 03 08:34:50 iparep5.example.com named[541]: zone 
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found


I have been running FreeIPA (including the bind nameserver) for several 
years now and I have never seen this message before.

I still have one FreeIPA system running CentOS 8-Stream.

Does anyone have a clue what it can be? Or how to find out? There are 
close to zero hits when I searched for this on the internet.

How to debug this? (How to debug this in a production environment, ha ha)
--
Kees
--
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: netstat showing multiple lines for each listening socket

[Thomas Hungenberg via bind-users]

Hi Robert,

it's the same PID for all lines, parent process is systemd.

The lines in the netstat output are exact duplicates (same IP, port and PID).
Other tools like ss show the same, so it's not a problem with netstat.

It's the same bahaviour on different machines, some upgraded from Debian < 11
and others installed from scratch with Debian 11 or 12.

I also set up a test VM and started BIND with the default configuration shipped 
with Debian.
Same behaviour: All lines are shown twice.

It looks like on machines with only two interfaces (lo / eth0) the lines are 
shown twice
while on machines with more interfaces (active or not) there are up to 20 
duplicate lines.


- Thomas


On 08.07.24 12:10, Robert Wagner wrote:

Some diagnostics is needed.  When you reboot, does it show it up multiple binds 
to the same port?  Can your run netstat -tP to identify the process ID (are 
they the same or different).  There may also be other options to provide more 
diagnostics.

-Trying to determine if you are really binding the service four times to the 
same port or this is just a ghost in the netstat program...  Most systems are 
designed to prevent binding multiple applications to the same ip/port, but a 
service can spawn multiple threads on the same ip/port.  You may be seeing the 
threads and not unique service instances.

Looking at the process ID, you may be able to track back to the root process 
and determine if these are just service threads.


Robert Wagner


From: bind-users  on behalf of Thomas Hungenberg 
via bind-users 
Sent: Monday, July 8, 2024 4:52 AM
To: bind-users@lists.isc.org 
Subject: netstat showing multiple lines for each listening socket

This email originated from outside of TESLA

Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

Hello,

we have been running some BIND nameservers on Debian-based systems for many 
years.

Until (including) Debian 10 with BIND 9.11.5, netstat always showed only one 
line
per listening socket, e.g.

tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named


We noticed that with Debian 11 and 12 (BIND 9.16.48 / 9.18.24), netstat instead
shows multiple (on some systems four, on others up to 20) completely identical 
lines
for each listening socket, like this:

tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named


We wonder what is causing this and if this is intended behaviour?


 - Thomas

--
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: netstat showing multiple lines for each listening socket

[Ondřej Surý]

That's correct.

Since BIND 9.16, `named` binds to individual addresses instead of "any" because
it needs to send responses back from the same address and it's just easier this 
way.

Cheers,
--
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 8. 7. 2024, at 10:52, Thomas Hungenberg via bind-users 
>  wrote:
> 
> Hello,
> 
> we have been running some BIND nameservers on Debian-based systems for many 
> years.
> 
> Until (including) Debian 10 with BIND 9.11.5, netstat always showed only one 
> line
> per listening socket, e.g.
> 
> tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN
>   1234/named
> tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN
>   1234/named
> udp0  0 10.x.x.x:53 0.0.0.0:* 
>   1234/named
> udp0  0 127.0.0.1:530.0.0.0:* 
>   1234/named
> 
> 
> We noticed that with Debian 11 and 12 (BIND 9.16.48 / 9.18.24), netstat 
> instead
> shows multiple (on some systems four, on others up to 20) completely 
> identical lines
> for each listening socket, like this:
> 
> tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN
>   1234/named
> tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN
>   1234/named
> tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN
>   1234/named
> tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN
>   1234/named
> tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN
>   1234/named
> tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN
>   1234/named
> tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN
>   1234/named
> tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN
>   1234/named
> udp0  0 10.x.x.x:53 0.0.0.0:* 
>   1234/named
> udp0  0 10.x.x.x:53 0.0.0.0:* 
>   1234/named
> udp0  0 10.x.x.x:53 0.0.0.0:* 
>   1234/named
> udp0  0 10.x.x.x:53 0.0.0.0:* 
>   1234/named
> udp0  0 127.0.0.1:530.0.0.0:* 
>   1234/named
> udp0  0 127.0.0.1:530.0.0.0:* 
>   1234/named
> udp0  0 127.0.0.1:530.0.0.0:* 
>   1234/named
> udp0  0 127.0.0.1:530.0.0.0:* 
>   1234/named
> 
> 
> We wonder what is causing this and if this is intended behaviour?
> 
> 
>   - Thomas
> 
> -- 
> 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: netstat showing multiple lines for each listening socket

[Robert Wagner]

Some diagnostics is needed.  When you reboot, does it show it up multiple binds 
to the same port?  Can your run netstat -tP to identify the process ID (are 
they the same or different).  There may also be other options to provide more 
diagnostics.

-Trying to determine if you are really binding the service four times to the 
same port or this is just a ghost in the netstat program...  Most systems are 
designed to prevent binding multiple applications to the same ip/port, but a 
service can spawn multiple threads on the same ip/port.  You may be seeing the 
threads and not unique service instances.

Looking at the process ID, you may be able to track back to the root process 
and determine if these are just service threads.


Robert Wagner


From: bind-users  on behalf of Thomas 
Hungenberg via bind-users 
Sent: Monday, July 8, 2024 4:52 AM
To: bind-users@lists.isc.org 
Subject: netstat showing multiple lines for each listening socket

This email originated from outside of TESLA

Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

Hello,

we have been running some BIND nameservers on Debian-based systems for many 
years.

Until (including) Debian 10 with BIND 9.11.5, netstat always showed only one 
line
per listening socket, e.g.

tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named


We noticed that with Debian 11 and 12 (BIND 9.16.48 / 9.18.24), netstat instead
shows multiple (on some systems four, on others up to 20) completely identical 
lines
for each listening socket, like this:

tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named


We wonder what is causing this and if this is intended behaviour?


- Thomas

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

netstat showing multiple lines for each listening socket

[Thomas Hungenberg via bind-users]

Hello,

we have been running some BIND nameservers on Debian-based systems for many 
years.

Until (including) Debian 10 with BIND 9.11.5, netstat always showed only one 
line
per listening socket, e.g.

tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named


We noticed that with Debian 11 and 12 (BIND 9.16.48 / 9.18.24), netstat instead
shows multiple (on some systems four, on others up to 20) completely identical 
lines
for each listening socket, like this:

tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named


We wonder what is causing this and if this is intended behaviour?


   - Thomas

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

Difference between query hung and timeout

[J Doe]

Hi list,

I run a BIND 9.18.27 resolver on a small mail server.

Sometimes in the logs I will see entries similar to the following:

04-Jul-2024 12:20:48.048 query-errors: info: client @0x3777f6412b0
127.0.0.1#48123 (bras-base-toroon0964w-
grc-41-142-198-14-9.dsl.bell.ca): query failed (timed out) for
bras-base-toroon0964w-grc-41-142-198-14-9.dsl.bell.ca/IN/A at
query.c:7843

04-Jul-2024 20:07:35.308 resolver: info: shut down hung fetch
while resolving '164.212.87.77.in-addr.arpa/PTR'

My question is: what is the difference between a query that times out
versus a query that hangs ?

In both cases, I would think these queries are hitting a time limit and
are stopped by BIND, but  the fact that there are two different log
entries makes me wonder if there's more to this.

Thanks,

- J
--
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: forward option in dns server

[Renzo Marengo]

yes this helped me. thanks Il giorno 28 giu 2024, alle ore 13:10, Greg Choules  ha scritto:Does that help?Cheers, GregOn Fri, 28 Jun 2024 at 11:58, Renzo Marengo  wrote:Hi Greg again! :)> 
1) This should help you understand the difference between recursive and non-recursive queries. I read about recursive and iterative query but I think A.B.C.D server should be as recursive server for domain controllers, I ask myself the same question to root servers? Or Bind9 server should have to make iterative queries to root servers ?
> I hope this server is behind a good firewall?Yes>Do you 
only have one BIND server? >I would recommend two at least, in case you 
need to take one down for maintenance or it fails for some reason.Yes only one server>> Your "allow-..." statements should look like this, with IP addresses, not domain names.Oh yes, this one was to explain you what servers I inserted into this list. I have another doubt, /etc/resolv.conf in bind server is used only from client services ? E.g. ping toolI think bind9 dns service doesn't contact any /etc/resolv.conf, right?

Il giorno ven 28 giu 2024 alle ore 08:46 Greg Choules  ha scritto:Hi Renzo.You're welcome.1) Correct. You don't need forwarding for a simple resolver. Take a look at the meaning of the RD flag in the BIND protocol header. This should help you understand the difference between recursive and non-recursive queries.2) No. See 1)3) Yes. For a standard resolver facing the Internet you do not need a hint zone.Some more thoughts occurred to me:- I hope this server is behind a good firewall?- Do you only have one BIND server? I would recommend two at least, in case you need to take one down for maintenance or it fails for some reason.- Your "allow-..." statements should look like this, with IP addresses, not domain names.   allow-... {127.0.0.1; ; ; ;}; You do not need to include this server in the list.Any changes you make should be done on a test server first, so you can be comfortable understanding what effect those changes have and only move them to production when you are certain.Cheers, GregOn Fri, 28 Jun 2024 at 07:14, Renzo Marengo  wrote:Hi greg,I thank you again for your suggestions.>A.B.C.D is the address of this server? yes, It's the Bind serverI read several documents about DNS architectureMy questions is about this configuration of bind:1- according to your opinion my bind makes queries ro root server if is set no 'forwarders' option? I'll verify It by tcpdump as you suggested2- Do you suggest to set some "forwarders" ?3-- This bind version has root server built-in? If I removed 'named.ca' reference, Bind would use root server built-in?thanksIl giorno ven 28 giu 2024 alle ore 07:51 Greg Choules  ha scritto:Hi Renzo.Thank you for that. The hints look OK. A bit old, but they will work. The first thing I would advise you to do as a matter of priority is to upgrade BIND.9.11 has been end-of-life for a few years and there have been many security fixes since then. 9.18.27 is the current version.You could install that directly, or upgrade RHEL and obtain a more recent packaged version.You can check what BIND is doing by using "tcpdump". For example:sudo tcpdump -n -i  -c 1000 port 53 and host A.B.C.DI am making some assumptions:A.B.C.D is the address of this server? is the name of the interface the server will use for outbound queries, according to its routeing table. I am guessing this is the interface with address A.B.C.D?-c stops the capture after 1000 packets. This is just a safety precaution.port 53 and host A.B.C.D limits the capture to only packets with port 53 (DNS) AND with the address of this interface, so you don't capture any SSH or HTTPS etc.A fresh (recently restarted) DNS resolver - any one, not just BIND - will make queries to the root to start with. It does this to learn where to go next. It stores the results of those queries in its cache so that it doesn't have to make them again for some time.There are many good books and articles available online to explain the basics of DNS. The BIND ARM (distributed with BIND and also available online) is the reference manual for BIND itself.I hope that helps.GregOn Fri, 28 Jun 2024 at 05:57, Renzo Marengo  wrote:Hi Greg,he info you required:1) BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.2 (Extended Support Version) on running on Linux x86_64 3.10.0-1160.2.2.el7.x86_642) named.ca if file which contains root serversnamed.ca.                       518400  IN      NS      a.root-servers.net..                       518400  IN      NS      b.root-servers.net..                       518400  IN      NS      c.root-servers.net..                       518400  IN      NS      d.root-servers.net..                       518400  IN      NS      e.root-servers.net..                       518400  IN      NS      f.root-servers.net..                   

Re: bind 9.18 few system tests failing

[Ondřej Surý]

Hi,

I find it hard to believe that IBM can't test it themselves on any Linux really,
but yes, all system tests pass correctly on all supported platforms.

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.

> On 3. 7. 2024, at 10:22, Sharada N Allimatti  wrote:
> 
> Hi,
> 
> We have ported the bind 9.18 for AIX , everything looks fine except few 
> system tests which use dlopen() fails.
> like hooks, dlzexternal and dyndb. Would like to know are these tests works 
> fine in 9.18/
> I see this dynamic library not getting some symbols in libisc.a..
> -- 
> 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

bind 9.18 few system tests failing

[Sharada N Allimatti]

Hi,

We have ported the bind 9.18 for AIX , everything looks fine except few system 
tests which use dlopen() fails.
like hooks, dlzexternal and dyndb. Would like to know are these tests works 
fine in 9.18/
I see this dynamic library not getting some symbols in libisc.a..
-- 
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: forward option in dns server

[Greg Sloop]

I have a similar setup, and I do it the way that Greg Choules suggests.

I could probably dig up the exact way I have BIND configured, but the
function is like this:
Clients query the non-AD BIND servers, for *all* queries. For the AD zone,
we use something like this; Our first level domain, lets assume is
example.com. All domain resources are in ad.example.com. So we configure
the non AD BIND servers to send queries for *.ad.example.com to the AD
servers.

So, in this way, the non-AD BIND servers handle all queries, but they
forward queries for ad.example,com to the AD name servers and return the
results.

I can't tell from the OP if they are using Samba or something else - but
we're using Samba in the example above. Samba has a couple of options for
their name server, an "internal" name server and a BIND version. Both can
be configured to forward any queries they aren't authoritative for to
another server. However, IIRC, at least the internal one can't handle large
loads. And while we'd probably be fine using it as our "primary" name
server, it seems needlessly risky.

I'd much rather have a well understood and mainstream BIND server as the
"front-line" server and then only forward queries for the AD zones to the
AD servers. (If you have some odd issue with a query outside the AD server
you can have a much larger support base, here, to help understand and fix
the issue.)

YMMV, but this was the way we decided to handle it after quite a bit of
consideration.
I hope that's helpful, though perhaps straying slightly off-topic for the
list.



On Thu, Jun 27, 2024 at 1:16 PM Greg Choules via bind-users <
bind-users@lists.isc.org> wrote:

> Hi Renzo.
> Ah OK, I had it the wrong way round. AD DNS needs to resolve names in the
> Internet on behalf of its clients, so it forwards to BIND.
>
> In that case, two questions:
> 1) What version of BIND are you running? You can get this with "named -V"
> 2) What is in the file "named.ca"?
> For a long time (which is why I need to know the version) BIND has had the
> Internet root hints built in, so you don't need a hint zone anymore. Unless
> you are defining different roots for some reason. Hence why I need to know
> the contents of that file.
>
> Thanks, Greg
>
>
>
> On Thu, 27 Jun 2024 at 18:06, Renzo Marengo 
> wrote:
>
>>
>> Hi Greg,
>>
>> thank you very much for your explanation.
>>
>> Let’s supposte AD domain was ‘my domain.it’  and I have 6000 computers
>> of government institute.
>>
>> Here my bind configuration:
>>
>>
>> named.conf
>>
>> ———
>>
>> include “…. named.conf.options" ;
>>
>> zone "." IN {
>>
>> type hint;
>>
>> file "named.ca";
>>
>> };
>>
>> include “…. named.rfc1912.zones";
>>
>> include “….  named.root.key";
>>
>> ———
>>
>>
>>
>> named.conf.options
>>
>> ———
>>
>> logging {
>>
>> channel named_debug {
>>
>> syslog local6;
>>
>> severity debug 1;
>>
>> print-category yes;
>>
>> print-severity yes;
>>
>> print-time yes;
>>
>> };
>>
>> category default { named_debug; };
>>
>> };
>>
>>
>> options {
>>
>> auth-nxdomain no;# conform to RFC1035
>>
>> allow-recursion {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
>> ….. } ;
>>
>> allow-query   {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
>> ….. } ;
>>
>> recursive-clients 3000;
>>
>> allow-query-cache {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
>> ….. } ; ;
>>
>>
>> listen-on port 53 { 127.0.0.1; A.B.C.D; };
>>
>> directory “….. named";
>>
>> dump-file “….. cache_dump.db";
>>
>> statistics-file “….. named_stats.txt";
>>
>> memstatistics-file “…. named_mem_stats.txt";
>>
>> recursing-file  “… named.recursing";
>>
>> secroots-file   “… named.secroots";
>>
>> recursion yes;
>>
>> dnssec-enable no;
>>
>> dnssec-validation no;
>>
>>
>> bindkeys-file "….. named.iscdlv.key";
>>
>> managed-keys-directory "….. dynamic";
>>
>> pid-file "….. named.pid";
>>
>> session-keyfile "….. session.key";
>>
>> ———
>>
>>
>>
>> >Thirdly, I would not forward to AD DNS, unless the AD servers also
>> recurse and can provide >resolution for delegated names below the AD domain
>>
>> >that are not hosted on the AD servers themselves.
>>
>>
>> There is no forward option to AD DNS. Forward is enable from AD DNS to
>> A.B.C.D. bind9 server.
>>
>>
>>
>>
>> All clients are using AD DNS infact every query, about name of ‘
>> mydomain.it,’ is resolved from AD DNS.
>>
>> When client asks an external domain, e.g. www.google.it, AD server
>> forward query to A.B.C.D. server. (Forward option is set on every domain
>> controller)
>>
>> Only AD DNS  make queries to A.B.C.D server and it’s necessary only to
>> solve external domains.
>>
>> A.B.C.D. server never makes queries to AD server. A.B.C.D. is next dns
>> server which partecipates when it’s necessary to resolve an external domain
>>
>>
>> I hope to have explained right.
>>
>> I thought A.B.C.D server made query to root 

Debian 10 Buster LTS end-of-life

[Ondřej Surý]

Hi folks,

as some of you might be using the Debian repositories, the Debian 10 Buster 
reached
end-of-life by the end of June 2024 and the BIND repositories for Debian 10 
will be
also removed.

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: rolling my own hints file

[Greg Choules via bind-users]

Hi Brian.
You need the NS record(s) in hints because this is what a resolver wants
first; the name(s) of the NS for a given zone.
Regarding "@" or ".", they amount to the same thing in my example, though
perhaps I was being a bit lazy and minimal.

@ represents the name of the zone (or the most recent $ORIGIN declaration),
so in this case "", or the root zone. The names of the NS are specified
with this, so they have no explicit names and that's what the A records are
tied to.
For the NS record it says that it belongs to the zone with name "@", or
root (the "owner" field, on the left hand side), and the name of the NS for
that zone is also @, which from above is what owns the A records.


It might be easier to understand if you give the NS a name, such as:
myroots.mydomain.  A   X.Y.Z.7
myroots.mydomain.  A   X.Y.Z.8

NOTE: The dot after "...mydomain" terminates the name (like "." in a
sentence) and prevents it from inheriting the name of the zone. In this
zone it doesn't matter because the zone is "", so there is nothing to
inherit. In any other zone, it matters.

Then the NS record would become either:
.  IN   NS   myroots.mydomain.
or
@  IN   NS   myroots.mydomain.

"." is more conventional and is an absolute representation of the root.
"@" works too, but is a relative reference to 'this zone we are in', which
just happens to be the root zone.

Compare this with how it's done in the Internet hints file:

.360  IN  NSA.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.  360  A 198.41.0.4
A.ROOT-SERVERS.NET.  360    2001:503:BA3E::2:30


Hope that helps.
Greg

On Mon, 1 Jul 2024 at 16:05, Cuttler, Brian R (HEALTH) <
brian.cutt...@health.ny.gov> wrote:

> Greg, David,
>
>
>
> Another questions or two before I commit the changes to my hints file.
>
>
> I have only the two servers, this last line isn’t necessary? Or for that
> matter, possibly detrimental?
> If it is, its “dot” rather than “at”?
>
> @ 518400   IN A xx.yy.zz..7
>
> @ 518400   IN A xx.yy.zz..8
>
> .   518400IN NS @
>
>
>
> Thank you.
>
> Brian
>
>
>
> *From:* bind-users  * On Behalf Of *Cuttler,
> Brian R (HEALTH) via bind-users
> *Sent:* Wednesday, June 26, 2024 12:56 PM
> *To:* Greg Choules ; David Farje <
> davidabelfa...@gmail.com>
> *Cc:* bind-users ; Hefner, Joseph (HEALTH) <
> joseph.hef...@health.ny.gov>
> *Subject:* RE: rolling my own hints file
>
>
>
> *ATTENTION: This email came from an external source. Do not open
> attachments or click on links from unknown senders or unexpected emails.*
>
>
>
>
>
> Greg, David,
>
>
>
> Thanks, much easier than what I thought it would be.
>
> I have two “root” servers so I went with this format, allowing a round
> robin selection.
>
> Essentially this, sorry trying to be vague on the IPs.
>
>
>
> @ 518400   IN A xx.yy.zz..7
>
> @ 518400   IN A xx.yy.zz..8
>
> .   518400IN NS @
>
>
>
> Server reloaded fine and I am able to resolve non-domain information.
> Is there a flag someplace in dig or nslookup to show what root server I’m
> hitting? I don’t see that in any of the named log files, I may need to add
> an ACL to log the traffic in a router to verify.
> Then again – my FW is not seeing queries to any of the normal root
> servers, so that is in fact a good sign.
>
>
>
> New root servers are managed by my parent organization and my manager
> asked me to send these queries through them. Wouldn’t be performing this
> exercise otherwise.
>
>
>
> Thank you – I think you’ve given me exactly what was needed.
>
>
>
> Brian
>
>
>
> *From:* Greg Choules 
> *Sent:* Wednesday, June 26, 2024 12:29 PM
> *To:* Cuttler, Brian R (HEALTH) 
> *Cc:* bind-users 
> *Subject:* Re: rolling my own hints file
>
>
>
> You don't often get email from gregchoules+bindus...@googlemail.com. Learn
> why this is important 
>
> *ATTENTION: This email came from an external source. Do not open
> attachments or click on links from unknown senders or unexpected emails.*
>
>
>
> Hi Brian.
>
> Yes, you can define your own hint zone and tell BIND to use it. The
> contents (I called the file "db.root" but the name is your choice) could be
> as simple as:
>
>
>
> @ 300 IN A 127.0.0.3
> @ 300 IN NS @
>
>
>
> which says for this zone (which will be called ".", coming next) the NS is
> the same name and its IP is 127.0.0.3, which happens to be another instance
> of BIND I have running. Your file would contain the names and IPs of your
> internal roots.
>
>
>
> In the config, define the hint zone like this:
>
>
>
> zone "." {
> type hint;
> file "db.root";
> };
>
>
>
> That should be all you need.
>
> Cheers, Greg
>
>
>
> On Wed, 26 Jun 2024 at 15:58, Cuttler, Brian R (HEALTH) via bind-users <
> bind-users@lists.isc.org> wrote:
>
> Running Bind 9.18.18 on Ubuntu 22.04
>
>
>
> We would like to use root servers within our organization rather than the
> actual root servers.
> I updated the hints file with the names and IPs of 

RE: rolling my own hints file

[Cuttler, Brian R (HEALTH) via bind-users]

Greg, David,

Another questions or two before I commit the changes to my hints file.

I have only the two servers, this last line isn't necessary? Or for that 
matter, possibly detrimental?
If it is, its "dot" rather than "at"?

@ 518400   IN A xx.yy.zz..7
@ 518400   IN A xx.yy.zz..8
.   518400IN NS @

Thank you.
Brian

From: bind-users  On Behalf Of Cuttler, Brian 
R (HEALTH) via bind-users
Sent: Wednesday, June 26, 2024 12:56 PM
To: Greg Choules ; David Farje 

Cc: bind-users ; Hefner, Joseph (HEALTH) 

Subject: RE: rolling my own hints file


ATTENTION: This email came from an external source. Do not open attachments or 
click on links from unknown senders or unexpected emails.


Greg, David,

Thanks, much easier than what I thought it would be.

I have two "root" servers so I went with this format, allowing a round robin 
selection.
Essentially this, sorry trying to be vague on the IPs.

@ 518400   IN A xx.yy.zz..7
@ 518400   IN A xx.yy.zz..8
.   518400IN NS @

Server reloaded fine and I am able to resolve non-domain information.
Is there a flag someplace in dig or nslookup to show what root server I'm 
hitting? I don't see that in any of the named log files, I may need to add an 
ACL to log the traffic in a router to verify.
Then again - my FW is not seeing queries to any of the normal root servers, so 
that is in fact a good sign.

New root servers are managed by my parent organization and my manager asked me 
to send these queries through them. Wouldn't be performing this exercise 
otherwise.

Thank you - I think you've given me exactly what was needed.

Brian

From: Greg Choules 
mailto:gregchoules+bindus...@googlemail.com>>
Sent: Wednesday, June 26, 2024 12:29 PM
To: Cuttler, Brian R (HEALTH) 
mailto:brian.cutt...@health.ny.gov>>
Cc: bind-users mailto:bind-users@lists.isc.org>>
Subject: Re: rolling my own hints file

You don't often get email from 
gregchoules+bindus...@googlemail.com.
 Learn why this is important

ATTENTION: This email came from an external source. Do not open attachments or 
click on links from unknown senders or unexpected emails.

Hi Brian.
Yes, you can define your own hint zone and tell BIND to use it. The contents (I 
called the file "db.root" but the name is your choice) could be as simple as:

@ 300 IN A 127.0.0.3
@ 300 IN NS @

which says for this zone (which will be called ".", coming next) the NS is the 
same name and its IP is 127.0.0.3, which happens to be another instance of BIND 
I have running. Your file would contain the names and IPs of your internal 
roots.

In the config, define the hint zone like this:

zone "." {
type hint;
file "db.root";
};

That should be all you need.
Cheers, Greg

On Wed, 26 Jun 2024 at 15:58, Cuttler, Brian R (HEALTH) via bind-users 
mailto:bind-users@lists.isc.org>> wrote:
Running Bind 9.18.18 on Ubuntu 22.04

We would like to use root servers within our organization rather than the 
actual root servers.
I updated the hints file with the names and IPs of our servers, but we seem to 
still access the official root servers.

Wondering how I ignore the internal/build-in hints and have my own file.

Wondering if replacing the IP addresses in the db.cache file with a round-robin 
of my internal IP addresses isn't the answer.
Not elegant but perhaps would work?

Is there a supported way to do what I want to do - we do not want an forwarding 
only server, we do serve a good number of internal statis and dynamic zones but 
also want to resolve non-domain addresses or addresses we lack forwarder zones 
for from a 'root' source.

;; ADDITIONAL SECTION:
a.root-servers.net. 518400  IN  A   
198.41.0.4
b.root-servers.net. 518400  IN  A   
170.247.170.2
c.root-servers.net. 518400  IN  A   
192.33.4.12

Thanks for your help and suggestions,
Brian


Brian Cuttler, System and Network Administration
Wadsworth Center, NYS Department of Health
Albany, NY 12201 POB 509
brian.cutt...@health.ny.gov
518 486-1697

--
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: forward option in dns server

[Fred Morris]

Although I see listen-on in your named.conf snippet, I don't see 
query-source. You can listen on a different interface / address than the 
one you issue queries from. If you need to issue queries selectively on 
different interfaces, see the server stanza and put query-source in there.


--

Fred Morris

--
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: tryisc.com is not an isc.org domain

[JW ,\ John Woodworth]

Hi Vicky,I received one of these and it felt "phishy."  Particularly since they 
didn't know the "C" in ISC was for "consortium."Thanks for clarifying./John
 Original message From: Victoria Risk Update: 
This was not the fraud we thought it was We have learned that emails we 
originally identified as abuse were sent by an external contractor engaged by 
ISC to conduct a focussed and short-term lead generation campaign. We have 
instructed the vendor to halt that campaign.We clearly suffered some 
communications failures here. Our communication with the vendor should have 
made it clear that we would not be comfortable with the approach they adopted. 
Plus, our internal communication failed as we lacked sufficient awareness of 
the campaign to respond in a more appropriate fashion when we received 
questions about the emails.We have been assured by the vendor that this was not 
a bulk unsolicited email campaign. We affirm our stance that bulk unsolicited 
email is counter to our mission in support of Internet infrastructure.We 
apologize for any inconvenience or disruption this event may have caused. We 
promptly canceled our abuse complaint concerning the domain name, and we ask 
any of you who have taken any filtering or blocking or complaint action against 
the domain name or the originating IP addresses to do the same. We appreciate 
the outpouring of sympathy from our community, many of whom have emailed us 
with helpful suggestions. We thank you for your continued support.On Jun 25, 
2024, at 10:42 AM, Victoria Risk  wrote:BIND-users,Someone is 
sending emails from tryisc.com, pretending to be from Internet Systems 
Corporation, and offering information about undisclosed BIND software 
vulnerabilities. These emails are NOT from ISC, the authors of BIND, and they 
are not authorized by ISC.If you feel you have received illegitimate 
communications from someone purporting to be an ISC staff member, please report 
it (https://www.isc.org/security-report/). If someone other than ISC.org is 
offering to provide software vulnerability information about ISC software, this 
is suspicious and probably fraudulent. ISC does offer professional support 
services, which includes advance notification of security vulnerabilities in 
our software but we have not authorized anyone else to disclose that 
information prior to public disclosure.Be safe out there, and check the domain 
name if you are not sure about the sender. ISC.org is signed, so you can also 
validate it (since you are all operating resolvers, right?).Vicky Risk (working 
at the actual 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: forward option in dns server

[Greg Choules via bind-users]

Correct.

On Fri, 28 Jun 2024, 12:54 Renzo Marengo,  wrote:

> Ok very veri interesting,and about this doubt?
>
> etc/resolv.conf in bind server is used only from client services ? E.g.
> ping tool
> I think bind9 dns service doesn't contact any /etc/resolv.conf, right?
>
> Thanks again
>
> Il giorno ven 28 giu 2024 alle ore 13:10 Greg Choules <
> gregchoules+bindus...@googlemail.com> ha scritto:
>
>> Hi again Renzo.
>>
>> In general, BIND (and other resolvers) make non-recursives (aka
>> iterative) queries to authoritative servers, such as the roots and others.
>>
>> - Clients (laptops etc.) make recursive queries to the DCs. If the DCs
>> know the answer they respond immediately; no forwarding needed.
>> - If the DCs don't (currently) know the answer, they make recursive
>> queries to BIND because that's what you have told them to do, using either
>> global or conditional forwarding. If BIND knows the answer it responds
>> immediately; no need to make queries into the Internet.
>> - If BIND doesn't (currently) know the answer it makes non-recursive
>> queries to anywhere it needs, to gather information to construct a response.
>> It is important to note that each of these is a separate DNS conversation.
>>
>> Does that help?
>>
>> Please get another server (and a test server) and upgrade them all to
>> current software.
>>
>> Cheers, Greg
>>
>> On Fri, 28 Jun 2024 at 11:58, Renzo Marengo 
>> wrote:
>>
>>> Hi Greg again! :)
>>>
>>> > 1) This should help you understand the difference between recursive
>>> and non-recursive queries.
>>> I read about recursive and iterative query but I think A.B.C.D server
>>> should be as recursive server for domain controllers, I ask myself the same
>>> question to root servers? Or Bind9 server should have to make iterative
>>> queries to root servers ?
>>>
>>> > I hope this server is behind a good firewall?
>>> Yes
>>>
>>> >Do you only have one BIND server?
>>> >I would recommend two at least, in case you need to take one down for
>>> maintenance or it fails for some reason.
>>> Yes only one server
>>>
>>> >> Your "allow-..." statements should look like this, with IP addresses,
>>> not domain names.
>>> Oh yes, this one was to explain you what servers I inserted into this
>>> list.
>>>
>>>
>>> I have another doubt, /etc/resolv.conf in bind server is used only from
>>> client services ? E.g. ping tool
>>> I think bind9 dns service doesn't contact any /etc/resolv.conf, right?
>>>
>>>
>>>
>>>
>>>
>>> Il giorno ven 28 giu 2024 alle ore 08:46 Greg Choules <
>>> gregchoules+bindus...@googlemail.com> ha scritto:
>>>
 Hi Renzo.
 You're welcome.
 1) Correct. You don't need forwarding for a simple resolver. Take a
 look at the meaning of the RD flag in the BIND protocol header. This should
 help you understand the difference between recursive and non-recursive
 queries.
 2) No. See 1)
 3) Yes. For a standard resolver facing the Internet you do not need a
 hint zone.

 Some more thoughts occurred to me:
 - I hope this server is behind a good firewall?
 - Do you only have one BIND server? I would recommend two at least, in
 case you need to take one down for maintenance or it fails for some reason.
 - Your "allow-..." statements should look like this, with IP addresses,
 not domain names.
allow-... {127.0.0.1; ;
 ; ;}; You do
 not need to include this server in the list.

 Any changes you make should be done on a test server first, so you can
 be comfortable understanding what effect those changes have and only move
 them to production when you are certain.

 Cheers, Greg

 On Fri, 28 Jun 2024 at 07:14, Renzo Marengo 
 wrote:

> Hi greg,
> I thank you again for your suggestions.
>
> >A.B.C.D is the address of this server?
> yes, It's the Bind server
>
> I read several documents about DNS architecture
> My questions is about this configuration of bind:
>
> 1- according to your opinion my bind makes queries ro root server if
> is set no 'forwarders' option? I'll verify It by tcpdump as you suggested
> 2- Do you suggest to set some "forwarders" ?
> 3-- This bind version has root server built-in? If I removed 'named.ca'
> reference, Bind would use root server built-in?
>
> thanks
>
> Il giorno ven 28 giu 2024 alle ore 07:51 Greg Choules <
> gregchoules+bindus...@googlemail.com> ha scritto:
>
>> Hi Renzo.
>>
>> Thank you for that. The hints look OK. A bit old, but they will work.
>>
>> The first thing I would advise you to do as a matter of priority is
>> to upgrade BIND.
>> 9.11 has been end-of-life for a few years and there have been many
>> security fixes since then. 9.18.27 is the current version.
>> You could install that directly, or upgrade RHEL and obtain a more
>> recent packaged version.
>>
>>
>> You can check what BIND is doing 

Re: forward option in dns server

[Renzo Marengo]

Ok very veri interesting,and about this doubt?

etc/resolv.conf in bind server is used only from client services ? E.g.
ping tool
I think bind9 dns service doesn't contact any /etc/resolv.conf, right?

Thanks again

Il giorno ven 28 giu 2024 alle ore 13:10 Greg Choules <
gregchoules+bindus...@googlemail.com> ha scritto:

> Hi again Renzo.
>
> In general, BIND (and other resolvers) make non-recursives (aka iterative)
> queries to authoritative servers, such as the roots and others.
>
> - Clients (laptops etc.) make recursive queries to the DCs. If the DCs
> know the answer they respond immediately; no forwarding needed.
> - If the DCs don't (currently) know the answer, they make recursive
> queries to BIND because that's what you have told them to do, using either
> global or conditional forwarding. If BIND knows the answer it responds
> immediately; no need to make queries into the Internet.
> - If BIND doesn't (currently) know the answer it makes non-recursive
> queries to anywhere it needs, to gather information to construct a response.
> It is important to note that each of these is a separate DNS conversation.
>
> Does that help?
>
> Please get another server (and a test server) and upgrade them all to
> current software.
>
> Cheers, Greg
>
> On Fri, 28 Jun 2024 at 11:58, Renzo Marengo 
> wrote:
>
>> Hi Greg again! :)
>>
>> > 1) This should help you understand the difference between recursive and
>> non-recursive queries.
>> I read about recursive and iterative query but I think A.B.C.D server
>> should be as recursive server for domain controllers, I ask myself the same
>> question to root servers? Or Bind9 server should have to make iterative
>> queries to root servers ?
>>
>> > I hope this server is behind a good firewall?
>> Yes
>>
>> >Do you only have one BIND server?
>> >I would recommend two at least, in case you need to take one down for
>> maintenance or it fails for some reason.
>> Yes only one server
>>
>> >> Your "allow-..." statements should look like this, with IP addresses,
>> not domain names.
>> Oh yes, this one was to explain you what servers I inserted into this
>> list.
>>
>>
>> I have another doubt, /etc/resolv.conf in bind server is used only from
>> client services ? E.g. ping tool
>> I think bind9 dns service doesn't contact any /etc/resolv.conf, right?
>>
>>
>>
>>
>>
>> Il giorno ven 28 giu 2024 alle ore 08:46 Greg Choules <
>> gregchoules+bindus...@googlemail.com> ha scritto:
>>
>>> Hi Renzo.
>>> You're welcome.
>>> 1) Correct. You don't need forwarding for a simple resolver. Take a look
>>> at the meaning of the RD flag in the BIND protocol header. This should help
>>> you understand the difference between recursive and non-recursive queries.
>>> 2) No. See 1)
>>> 3) Yes. For a standard resolver facing the Internet you do not need a
>>> hint zone.
>>>
>>> Some more thoughts occurred to me:
>>> - I hope this server is behind a good firewall?
>>> - Do you only have one BIND server? I would recommend two at least, in
>>> case you need to take one down for maintenance or it fails for some reason.
>>> - Your "allow-..." statements should look like this, with IP addresses,
>>> not domain names.
>>>allow-... {127.0.0.1; ;
>>> ; ;}; You do
>>> not need to include this server in the list.
>>>
>>> Any changes you make should be done on a test server first, so you can
>>> be comfortable understanding what effect those changes have and only move
>>> them to production when you are certain.
>>>
>>> Cheers, Greg
>>>
>>> On Fri, 28 Jun 2024 at 07:14, Renzo Marengo 
>>> wrote:
>>>
 Hi greg,
 I thank you again for your suggestions.

 >A.B.C.D is the address of this server?
 yes, It's the Bind server

 I read several documents about DNS architecture
 My questions is about this configuration of bind:

 1- according to your opinion my bind makes queries ro root server if is
 set no 'forwarders' option? I'll verify It by tcpdump as you suggested
 2- Do you suggest to set some "forwarders" ?
 3-- This bind version has root server built-in? If I removed 'named.ca'
 reference, Bind would use root server built-in?

 thanks

 Il giorno ven 28 giu 2024 alle ore 07:51 Greg Choules <
 gregchoules+bindus...@googlemail.com> ha scritto:

> Hi Renzo.
>
> Thank you for that. The hints look OK. A bit old, but they will work.
>
> The first thing I would advise you to do as a matter of priority is to
> upgrade BIND.
> 9.11 has been end-of-life for a few years and there have been many
> security fixes since then. 9.18.27 is the current version.
> You could install that directly, or upgrade RHEL and obtain a more
> recent packaged version.
>
>
> You can check what BIND is doing by using "tcpdump". For example:
> sudo tcpdump -n -i  -c 1000 port 53 and host A.B.C.D
>
> I am making some assumptions:
> A.B.C.D is the address of this server?
>  is the name of the 

Re: forward option in dns server

[Greg Choules via bind-users]

Hi again Renzo.

In general, BIND (and other resolvers) make non-recursives (aka iterative)
queries to authoritative servers, such as the roots and others.

- Clients (laptops etc.) make recursive queries to the DCs. If the DCs know
the answer they respond immediately; no forwarding needed.
- If the DCs don't (currently) know the answer, they make recursive queries
to BIND because that's what you have told them to do, using either global
or conditional forwarding. If BIND knows the answer it responds
immediately; no need to make queries into the Internet.
- If BIND doesn't (currently) know the answer it makes non-recursive
queries to anywhere it needs, to gather information to construct a response.
It is important to note that each of these is a separate DNS conversation.

Does that help?

Please get another server (and a test server) and upgrade them all to
current software.

Cheers, Greg

On Fri, 28 Jun 2024 at 11:58, Renzo Marengo  wrote:

> Hi Greg again! :)
>
> > 1) This should help you understand the difference between recursive and
> non-recursive queries.
> I read about recursive and iterative query but I think A.B.C.D server
> should be as recursive server for domain controllers, I ask myself the same
> question to root servers? Or Bind9 server should have to make iterative
> queries to root servers ?
>
> > I hope this server is behind a good firewall?
> Yes
>
> >Do you only have one BIND server?
> >I would recommend two at least, in case you need to take one down for
> maintenance or it fails for some reason.
> Yes only one server
>
> >> Your "allow-..." statements should look like this, with IP addresses,
> not domain names.
> Oh yes, this one was to explain you what servers I inserted into this
> list.
>
>
> I have another doubt, /etc/resolv.conf in bind server is used only from
> client services ? E.g. ping tool
> I think bind9 dns service doesn't contact any /etc/resolv.conf, right?
>
>
>
>
>
> Il giorno ven 28 giu 2024 alle ore 08:46 Greg Choules <
> gregchoules+bindus...@googlemail.com> ha scritto:
>
>> Hi Renzo.
>> You're welcome.
>> 1) Correct. You don't need forwarding for a simple resolver. Take a look
>> at the meaning of the RD flag in the BIND protocol header. This should help
>> you understand the difference between recursive and non-recursive queries.
>> 2) No. See 1)
>> 3) Yes. For a standard resolver facing the Internet you do not need a
>> hint zone.
>>
>> Some more thoughts occurred to me:
>> - I hope this server is behind a good firewall?
>> - Do you only have one BIND server? I would recommend two at least, in
>> case you need to take one down for maintenance or it fails for some reason.
>> - Your "allow-..." statements should look like this, with IP addresses,
>> not domain names.
>>allow-... {127.0.0.1; ;
>> ; ;}; You do
>> not need to include this server in the list.
>>
>> Any changes you make should be done on a test server first, so you can be
>> comfortable understanding what effect those changes have and only move them
>> to production when you are certain.
>>
>> Cheers, Greg
>>
>> On Fri, 28 Jun 2024 at 07:14, Renzo Marengo 
>> wrote:
>>
>>> Hi greg,
>>> I thank you again for your suggestions.
>>>
>>> >A.B.C.D is the address of this server?
>>> yes, It's the Bind server
>>>
>>> I read several documents about DNS architecture
>>> My questions is about this configuration of bind:
>>>
>>> 1- according to your opinion my bind makes queries ro root server if is
>>> set no 'forwarders' option? I'll verify It by tcpdump as you suggested
>>> 2- Do you suggest to set some "forwarders" ?
>>> 3-- This bind version has root server built-in? If I removed 'named.ca'
>>> reference, Bind would use root server built-in?
>>>
>>> thanks
>>>
>>> Il giorno ven 28 giu 2024 alle ore 07:51 Greg Choules <
>>> gregchoules+bindus...@googlemail.com> ha scritto:
>>>
 Hi Renzo.

 Thank you for that. The hints look OK. A bit old, but they will work.

 The first thing I would advise you to do as a matter of priority is to
 upgrade BIND.
 9.11 has been end-of-life for a few years and there have been many
 security fixes since then. 9.18.27 is the current version.
 You could install that directly, or upgrade RHEL and obtain a more
 recent packaged version.


 You can check what BIND is doing by using "tcpdump". For example:
 sudo tcpdump -n -i  -c 1000 port 53 and host A.B.C.D

 I am making some assumptions:
 A.B.C.D is the address of this server?
  is the name of the interface the server will use for
 outbound queries, according to its routeing table. I am guessing this is
 the interface with address A.B.C.D?
 -c stops the capture after 1000 packets. This is just a safety
 precaution.
 port 53 and host A.B.C.D limits the capture to only packets with port
 53 (DNS) AND with the address of this interface, so you don't capture any
 SSH or HTTPS etc.

 A fresh (recently restarted) DNS resolver 

Re: forward option in dns server

[Renzo Marengo]

Hi Greg again! :)

> 1) This should help you understand the difference between recursive and
non-recursive queries.
I read about recursive and iterative query but I think A.B.C.D server
should be as recursive server for domain controllers, I ask myself the same
question to root servers? Or Bind9 server should have to make iterative
queries to root servers ?

> I hope this server is behind a good firewall?
Yes

>Do you only have one BIND server?
>I would recommend two at least, in case you need to take one down for
maintenance or it fails for some reason.
Yes only one server

>> Your "allow-..." statements should look like this, with IP addresses,
not domain names.
Oh yes, this one was to explain you what servers I inserted into this list.


I have another doubt, /etc/resolv.conf in bind server is used only from
client services ? E.g. ping tool
I think bind9 dns service doesn't contact any /etc/resolv.conf, right?





Il giorno ven 28 giu 2024 alle ore 08:46 Greg Choules <
gregchoules+bindus...@googlemail.com> ha scritto:

> Hi Renzo.
> You're welcome.
> 1) Correct. You don't need forwarding for a simple resolver. Take a look
> at the meaning of the RD flag in the BIND protocol header. This should help
> you understand the difference between recursive and non-recursive queries.
> 2) No. See 1)
> 3) Yes. For a standard resolver facing the Internet you do not need a hint
> zone.
>
> Some more thoughts occurred to me:
> - I hope this server is behind a good firewall?
> - Do you only have one BIND server? I would recommend two at least, in
> case you need to take one down for maintenance or it fails for some reason.
> - Your "allow-..." statements should look like this, with IP addresses,
> not domain names.
>allow-... {127.0.0.1; ;
> ; ;}; You do
> not need to include this server in the list.
>
> Any changes you make should be done on a test server first, so you can be
> comfortable understanding what effect those changes have and only move them
> to production when you are certain.
>
> Cheers, Greg
>
> On Fri, 28 Jun 2024 at 07:14, Renzo Marengo 
> wrote:
>
>> Hi greg,
>> I thank you again for your suggestions.
>>
>> >A.B.C.D is the address of this server?
>> yes, It's the Bind server
>>
>> I read several documents about DNS architecture
>> My questions is about this configuration of bind:
>>
>> 1- according to your opinion my bind makes queries ro root server if is
>> set no 'forwarders' option? I'll verify It by tcpdump as you suggested
>> 2- Do you suggest to set some "forwarders" ?
>> 3-- This bind version has root server built-in? If I removed 'named.ca'
>> reference, Bind would use root server built-in?
>>
>> thanks
>>
>> Il giorno ven 28 giu 2024 alle ore 07:51 Greg Choules <
>> gregchoules+bindus...@googlemail.com> ha scritto:
>>
>>> Hi Renzo.
>>>
>>> Thank you for that. The hints look OK. A bit old, but they will work.
>>>
>>> The first thing I would advise you to do as a matter of priority is to
>>> upgrade BIND.
>>> 9.11 has been end-of-life for a few years and there have been many
>>> security fixes since then. 9.18.27 is the current version.
>>> You could install that directly, or upgrade RHEL and obtain a more
>>> recent packaged version.
>>>
>>>
>>> You can check what BIND is doing by using "tcpdump". For example:
>>> sudo tcpdump -n -i  -c 1000 port 53 and host A.B.C.D
>>>
>>> I am making some assumptions:
>>> A.B.C.D is the address of this server?
>>>  is the name of the interface the server will use for
>>> outbound queries, according to its routeing table. I am guessing this is
>>> the interface with address A.B.C.D?
>>> -c stops the capture after 1000 packets. This is just a safety
>>> precaution.
>>> port 53 and host A.B.C.D limits the capture to only packets with port 53
>>> (DNS) AND with the address of this interface, so you don't capture any SSH
>>> or HTTPS etc.
>>>
>>> A fresh (recently restarted) DNS resolver - any one, not just BIND -
>>> will make queries to the root to start with. It does this to learn where to
>>> go next. It stores the results of those queries in its cache so that it
>>> doesn't have to make them again for some time.
>>>
>>> There are many good books and articles available online to explain the
>>> basics of DNS. The BIND ARM (distributed with BIND and also available
>>> online) is the reference manual for BIND itself.
>>>
>>> I hope that helps.
>>> Greg
>>>
>>> On Fri, 28 Jun 2024 at 05:57, Renzo Marengo 
>>> wrote:
>>>
 Hi Greg,
 he info you required:

 1) BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.2 (Extended Support
 Version) on running on Linux x86_64 3.10.0-1160.2.2.el7.x86_64
 2) named.ca if file which contains root servers
 named.ca
 
 .   518400  IN  NS  a.root-servers.net.
 .   518400  IN  NS  b.root-servers.net.
 .   518400  IN  NS  c.root-servers.net.
 .   518400  IN  NS  

Re: forward option in dns server

[Greg Choules via bind-users]

Hi Renzo.
You're welcome.
1) Correct. You don't need forwarding for a simple resolver. Take a look at
the meaning of the RD flag in the BIND protocol header. This should help
you understand the difference between recursive and non-recursive queries.
2) No. See 1)
3) Yes. For a standard resolver facing the Internet you do not need a hint
zone.

Some more thoughts occurred to me:
- I hope this server is behind a good firewall?
- Do you only have one BIND server? I would recommend two at least, in case
you need to take one down for maintenance or it fails for some reason.
- Your "allow-..." statements should look like this, with IP addresses, not
domain names.
   allow-... {127.0.0.1; ;
; ;}; You do
not need to include this server in the list.

Any changes you make should be done on a test server first, so you can be
comfortable understanding what effect those changes have and only move them
to production when you are certain.

Cheers, Greg

On Fri, 28 Jun 2024 at 07:14, Renzo Marengo  wrote:

> Hi greg,
> I thank you again for your suggestions.
>
> >A.B.C.D is the address of this server?
> yes, It's the Bind server
>
> I read several documents about DNS architecture
> My questions is about this configuration of bind:
>
> 1- according to your opinion my bind makes queries ro root server if is
> set no 'forwarders' option? I'll verify It by tcpdump as you suggested
> 2- Do you suggest to set some "forwarders" ?
> 3-- This bind version has root server built-in? If I removed 'named.ca'
> reference, Bind would use root server built-in?
>
> thanks
>
> Il giorno ven 28 giu 2024 alle ore 07:51 Greg Choules <
> gregchoules+bindus...@googlemail.com> ha scritto:
>
>> Hi Renzo.
>>
>> Thank you for that. The hints look OK. A bit old, but they will work.
>>
>> The first thing I would advise you to do as a matter of priority is to
>> upgrade BIND.
>> 9.11 has been end-of-life for a few years and there have been many
>> security fixes since then. 9.18.27 is the current version.
>> You could install that directly, or upgrade RHEL and obtain a more recent
>> packaged version.
>>
>>
>> You can check what BIND is doing by using "tcpdump". For example:
>> sudo tcpdump -n -i  -c 1000 port 53 and host A.B.C.D
>>
>> I am making some assumptions:
>> A.B.C.D is the address of this server?
>>  is the name of the interface the server will use for outbound
>> queries, according to its routeing table. I am guessing this is the
>> interface with address A.B.C.D?
>> -c stops the capture after 1000 packets. This is just a safety precaution.
>> port 53 and host A.B.C.D limits the capture to only packets with port 53
>> (DNS) AND with the address of this interface, so you don't capture any SSH
>> or HTTPS etc.
>>
>> A fresh (recently restarted) DNS resolver - any one, not just BIND - will
>> make queries to the root to start with. It does this to learn where to go
>> next. It stores the results of those queries in its cache so that it
>> doesn't have to make them again for some time.
>>
>> There are many good books and articles available online to explain the
>> basics of DNS. The BIND ARM (distributed with BIND and also available
>> online) is the reference manual for BIND itself.
>>
>> I hope that helps.
>> Greg
>>
>> On Fri, 28 Jun 2024 at 05:57, Renzo Marengo 
>> wrote:
>>
>>> Hi Greg,
>>> he info you required:
>>>
>>> 1) BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.2 (Extended Support Version)
>>> on running on Linux x86_64 3.10.0-1160.2.2.el7.x86_64
>>> 2) named.ca if file which contains root servers
>>> named.ca
>>> 
>>> .   518400  IN  NS  a.root-servers.net.
>>> .   518400  IN  NS  b.root-servers.net.
>>> .   518400  IN  NS  c.root-servers.net.
>>> .   518400  IN  NS  d.root-servers.net.
>>> .   518400  IN  NS  e.root-servers.net.
>>> .   518400  IN  NS  f.root-servers.net.
>>> .   518400  IN  NS  g.root-servers.net.
>>> .   518400  IN  NS  h.root-servers.net.
>>> .   518400  IN  NS  i.root-servers.net.
>>> .   518400  IN  NS  j.root-servers.net.
>>> .   518400  IN  NS  k.root-servers.net.
>>> .   518400  IN  NS  l.root-servers.net.
>>> .   518400  IN  NS  m.root-servers.net.
>>>
>>> ;; ADDITIONAL SECTION:
>>> a.root-servers.net. 518400  IN  A   198.41.0.4
>>> b.root-servers.net. 518400  IN  A   199.9.14.201
>>> c.root-servers.net. 518400  IN  A   192.33.4.12
>>> d.root-servers.net. 518400  IN  A   199.7.91.13
>>> e.root-servers.net. 518400  IN  A   192.203.230.10
>>> f.root-servers.net. 518400  IN  A   192.5.5.241
>>> g.root-servers.net. 518400  IN  A   192.112.36.4
>>> h.root-servers.net.

Re: forward option in dns server

[Renzo Marengo]

Hi greg,
I thank you again for your suggestions.

>A.B.C.D is the address of this server?
yes, It's the Bind server

I read several documents about DNS architecture
My questions is about this configuration of bind:

1- according to your opinion my bind makes queries ro root server if is set
no 'forwarders' option? I'll verify It by tcpdump as you suggested
2- Do you suggest to set some "forwarders" ?
3-- This bind version has root server built-in? If I removed 'named.ca'
reference, Bind would use root server built-in?

thanks

Il giorno ven 28 giu 2024 alle ore 07:51 Greg Choules <
gregchoules+bindus...@googlemail.com> ha scritto:

> Hi Renzo.
>
> Thank you for that. The hints look OK. A bit old, but they will work.
>
> The first thing I would advise you to do as a matter of priority is to
> upgrade BIND.
> 9.11 has been end-of-life for a few years and there have been many
> security fixes since then. 9.18.27 is the current version.
> You could install that directly, or upgrade RHEL and obtain a more recent
> packaged version.
>
>
> You can check what BIND is doing by using "tcpdump". For example:
> sudo tcpdump -n -i  -c 1000 port 53 and host A.B.C.D
>
> I am making some assumptions:
> A.B.C.D is the address of this server?
>  is the name of the interface the server will use for outbound
> queries, according to its routeing table. I am guessing this is the
> interface with address A.B.C.D?
> -c stops the capture after 1000 packets. This is just a safety precaution.
> port 53 and host A.B.C.D limits the capture to only packets with port 53
> (DNS) AND with the address of this interface, so you don't capture any SSH
> or HTTPS etc.
>
> A fresh (recently restarted) DNS resolver - any one, not just BIND - will
> make queries to the root to start with. It does this to learn where to go
> next. It stores the results of those queries in its cache so that it
> doesn't have to make them again for some time.
>
> There are many good books and articles available online to explain the
> basics of DNS. The BIND ARM (distributed with BIND and also available
> online) is the reference manual for BIND itself.
>
> I hope that helps.
> Greg
>
> On Fri, 28 Jun 2024 at 05:57, Renzo Marengo 
> wrote:
>
>> Hi Greg,
>> he info you required:
>>
>> 1) BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.2 (Extended Support Version)
>> on running on Linux x86_64 3.10.0-1160.2.2.el7.x86_64
>> 2) named.ca if file which contains root servers
>> named.ca
>> 
>> .   518400  IN  NS  a.root-servers.net.
>> .   518400  IN  NS  b.root-servers.net.
>> .   518400  IN  NS  c.root-servers.net.
>> .   518400  IN  NS  d.root-servers.net.
>> .   518400  IN  NS  e.root-servers.net.
>> .   518400  IN  NS  f.root-servers.net.
>> .   518400  IN  NS  g.root-servers.net.
>> .   518400  IN  NS  h.root-servers.net.
>> .   518400  IN  NS  i.root-servers.net.
>> .   518400  IN  NS  j.root-servers.net.
>> .   518400  IN  NS  k.root-servers.net.
>> .   518400  IN  NS  l.root-servers.net.
>> .   518400  IN  NS  m.root-servers.net.
>>
>> ;; ADDITIONAL SECTION:
>> a.root-servers.net. 518400  IN  A   198.41.0.4
>> b.root-servers.net. 518400  IN  A   199.9.14.201
>> c.root-servers.net. 518400  IN  A   192.33.4.12
>> d.root-servers.net. 518400  IN  A   199.7.91.13
>> e.root-servers.net. 518400  IN  A   192.203.230.10
>> f.root-servers.net. 518400  IN  A   192.5.5.241
>> g.root-servers.net. 518400  IN  A   192.112.36.4
>> h.root-servers.net. 518400  IN  A   198.97.190.53
>> i.root-servers.net. 518400  IN  A   192.36.148.17
>> j.root-servers.net. 518400  IN  A   192.58.128.30
>> k.root-servers.net. 518400  IN  A   193.0.14.129
>> l.root-servers.net. 518400  IN  A   199.7.83.42
>> m.root-servers.net. 518400  IN  A   202.12.27.33
>> a.root-servers.net. 518400  IN  2001:503:ba3e::2:30
>> b.root-servers.net. 518400  IN  2001:500:200::b
>> c.root-servers.net. 518400  IN  2001:500:2::c
>> d.root-servers.net. 518400  IN  2001:500:2d::d
>> e.root-servers.net. 518400  IN  2001:500:a8::e
>> f.root-servers.net. 518400  IN  2001:500:2f::f
>> g.root-servers.net. 518400  IN  2001:500:12::d0d
>> h.root-servers.net. 518400  IN  2001:500:1::53
>> i.root-servers.net. 518400  IN  2001:7fe::53
>> j.root-servers.net. 518400  IN  2001:503:c27::2:30
>> k.root-servers.net. 518400  IN  2001:7fd::1
>> 

Re: forward option in dns server

[Greg Choules via bind-users]

Hi Renzo.

Thank you for that. The hints look OK. A bit old, but they will work.

The first thing I would advise you to do as a matter of priority is to
upgrade BIND.
9.11 has been end-of-life for a few years and there have been many security
fixes since then. 9.18.27 is the current version.
You could install that directly, or upgrade RHEL and obtain a more recent
packaged version.


You can check what BIND is doing by using "tcpdump". For example:
sudo tcpdump -n -i  -c 1000 port 53 and host A.B.C.D

I am making some assumptions:
A.B.C.D is the address of this server?
 is the name of the interface the server will use for outbound
queries, according to its routeing table. I am guessing this is the
interface with address A.B.C.D?
-c stops the capture after 1000 packets. This is just a safety precaution.
port 53 and host A.B.C.D limits the capture to only packets with port 53
(DNS) AND with the address of this interface, so you don't capture any SSH
or HTTPS etc.

A fresh (recently restarted) DNS resolver - any one, not just BIND - will
make queries to the root to start with. It does this to learn where to go
next. It stores the results of those queries in its cache so that it
doesn't have to make them again for some time.

There are many good books and articles available online to explain the
basics of DNS. The BIND ARM (distributed with BIND and also available
online) is the reference manual for BIND itself.

I hope that helps.
Greg

On Fri, 28 Jun 2024 at 05:57, Renzo Marengo  wrote:

> Hi Greg,
> he info you required:
>
> 1) BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.2 (Extended Support Version)
> on running on Linux x86_64 3.10.0-1160.2.2.el7.x86_64
> 2) named.ca if file which contains root servers
> named.ca
> 
> .   518400  IN  NS  a.root-servers.net.
> .   518400  IN  NS  b.root-servers.net.
> .   518400  IN  NS  c.root-servers.net.
> .   518400  IN  NS  d.root-servers.net.
> .   518400  IN  NS  e.root-servers.net.
> .   518400  IN  NS  f.root-servers.net.
> .   518400  IN  NS  g.root-servers.net.
> .   518400  IN  NS  h.root-servers.net.
> .   518400  IN  NS  i.root-servers.net.
> .   518400  IN  NS  j.root-servers.net.
> .   518400  IN  NS  k.root-servers.net.
> .   518400  IN  NS  l.root-servers.net.
> .   518400  IN  NS  m.root-servers.net.
>
> ;; ADDITIONAL SECTION:
> a.root-servers.net. 518400  IN  A   198.41.0.4
> b.root-servers.net. 518400  IN  A   199.9.14.201
> c.root-servers.net. 518400  IN  A   192.33.4.12
> d.root-servers.net. 518400  IN  A   199.7.91.13
> e.root-servers.net. 518400  IN  A   192.203.230.10
> f.root-servers.net. 518400  IN  A   192.5.5.241
> g.root-servers.net. 518400  IN  A   192.112.36.4
> h.root-servers.net. 518400  IN  A   198.97.190.53
> i.root-servers.net. 518400  IN  A   192.36.148.17
> j.root-servers.net. 518400  IN  A   192.58.128.30
> k.root-servers.net. 518400  IN  A   193.0.14.129
> l.root-servers.net. 518400  IN  A   199.7.83.42
> m.root-servers.net. 518400  IN  A   202.12.27.33
> a.root-servers.net. 518400  IN  2001:503:ba3e::2:30
> b.root-servers.net. 518400  IN  2001:500:200::b
> c.root-servers.net. 518400  IN  2001:500:2::c
> d.root-servers.net. 518400  IN  2001:500:2d::d
> e.root-servers.net. 518400  IN  2001:500:a8::e
> f.root-servers.net. 518400  IN  2001:500:2f::f
> g.root-servers.net. 518400  IN  2001:500:12::d0d
> h.root-servers.net. 518400  IN  2001:500:1::53
> i.root-servers.net. 518400  IN  2001:7fe::53
> j.root-servers.net. 518400  IN  2001:503:c27::2:30
> k.root-servers.net. 518400  IN  2001:7fd::1
> l.root-servers.net. 518400  IN  2001:500:9f::42
> m.root-servers.net. 518400  IN  2001:dc3::35
> 
>
> I didn't know some Bind versions had the Internet root hints built-in.
> About my configuration I understand that bind makes always queries to root
> servers ? Right?
> I'd like to re-check configuration of bind
>
>
> Il giorno gio 27 giu 2024 alle ore 22:15 Greg Choules <
> gregchoules+bindus...@googlemail.com> ha scritto:
>
>> Hi Renzo.
>> Ah OK, I had it the wrong way round. AD DNS needs to resolve names in the
>> Internet on behalf of its clients, so it forwards to BIND.
>>
>> In that case, two questions:
>> 1) What version of BIND are you running? You can get this with "named -V"
>> 2) What is in the file "named.ca"?
>> 

Re: forward option in dns server

[Renzo Marengo]

Hi Greg,
he info you required:

1) BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.2 (Extended Support Version) on
running on Linux x86_64 3.10.0-1160.2.2.el7.x86_64
2) named.ca if file which contains root servers
named.ca

.   518400  IN  NS  a.root-servers.net.
.   518400  IN  NS  b.root-servers.net.
.   518400  IN  NS  c.root-servers.net.
.   518400  IN  NS  d.root-servers.net.
.   518400  IN  NS  e.root-servers.net.
.   518400  IN  NS  f.root-servers.net.
.   518400  IN  NS  g.root-servers.net.
.   518400  IN  NS  h.root-servers.net.
.   518400  IN  NS  i.root-servers.net.
.   518400  IN  NS  j.root-servers.net.
.   518400  IN  NS  k.root-servers.net.
.   518400  IN  NS  l.root-servers.net.
.   518400  IN  NS  m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net. 518400  IN  A   198.41.0.4
b.root-servers.net. 518400  IN  A   199.9.14.201
c.root-servers.net. 518400  IN  A   192.33.4.12
d.root-servers.net. 518400  IN  A   199.7.91.13
e.root-servers.net. 518400  IN  A   192.203.230.10
f.root-servers.net. 518400  IN  A   192.5.5.241
g.root-servers.net. 518400  IN  A   192.112.36.4
h.root-servers.net. 518400  IN  A   198.97.190.53
i.root-servers.net. 518400  IN  A   192.36.148.17
j.root-servers.net. 518400  IN  A   192.58.128.30
k.root-servers.net. 518400  IN  A   193.0.14.129
l.root-servers.net. 518400  IN  A   199.7.83.42
m.root-servers.net. 518400  IN  A   202.12.27.33
a.root-servers.net. 518400  IN  2001:503:ba3e::2:30
b.root-servers.net. 518400  IN  2001:500:200::b
c.root-servers.net. 518400  IN  2001:500:2::c
d.root-servers.net. 518400  IN  2001:500:2d::d
e.root-servers.net. 518400  IN  2001:500:a8::e
f.root-servers.net. 518400  IN  2001:500:2f::f
g.root-servers.net. 518400  IN  2001:500:12::d0d
h.root-servers.net. 518400  IN  2001:500:1::53
i.root-servers.net. 518400  IN  2001:7fe::53
j.root-servers.net. 518400  IN  2001:503:c27::2:30
k.root-servers.net. 518400  IN  2001:7fd::1
l.root-servers.net. 518400  IN  2001:500:9f::42
m.root-servers.net. 518400  IN  2001:dc3::35


I didn't know some Bind versions had the Internet root hints built-in.
About my configuration I understand that bind makes always queries to root
servers ? Right?
I'd like to re-check configuration of bind


Il giorno gio 27 giu 2024 alle ore 22:15 Greg Choules <
gregchoules+bindus...@googlemail.com> ha scritto:

> Hi Renzo.
> Ah OK, I had it the wrong way round. AD DNS needs to resolve names in the
> Internet on behalf of its clients, so it forwards to BIND.
>
> In that case, two questions:
> 1) What version of BIND are you running? You can get this with "named -V"
> 2) What is in the file "named.ca"?
> For a long time (which is why I need to know the version) BIND has had the
> Internet root hints built in, so you don't need a hint zone anymore. Unless
> you are defining different roots for some reason. Hence why I need to know
> the contents of that file.
>
> Thanks, Greg
>
>
>
> On Thu, 27 Jun 2024 at 18:06, Renzo Marengo 
> wrote:
>
>>
>> Hi Greg,
>>
>> thank you very much for your explanation.
>>
>> Let’s supposte AD domain was ‘my domain.it’  and I have 6000 computers
>> of government institute.
>>
>> Here my bind configuration:
>>
>>
>> named.conf
>>
>> ———
>>
>> include “…. named.conf.options" ;
>>
>> zone "." IN {
>>
>> type hint;
>>
>> file "named.ca";
>>
>> };
>>
>> include “…. named.rfc1912.zones";
>>
>> include “….  named.root.key";
>>
>> ———
>>
>>
>>
>> named.conf.options
>>
>> ———
>>
>> logging {
>>
>> channel named_debug {
>>
>> syslog local6;
>>
>> severity debug 1;
>>
>> print-category yes;
>>
>> print-severity yes;
>>
>> print-time yes;
>>
>> };
>>
>> category default { named_debug; };
>>
>> };
>>
>>
>> options {
>>
>> auth-nxdomain no;# conform to RFC1035
>>
>> allow-recursion {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
>> ….. } ;
>>
>> allow-query   {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
>> ….. } ;
>>
>> recursive-clients 3000;
>>
>> allow-query-cache {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
>> ….. } ; ;
>>
>>
>> listen-on port 53 { 127.0.0.1; A.B.C.D; };
>>
>> directory “….. named";
>>
>> dump-file “….. 

Re: forward option in dns server

[Greg Choules via bind-users]

Hi Renzo.
Ah OK, I had it the wrong way round. AD DNS needs to resolve names in the
Internet on behalf of its clients, so it forwards to BIND.

In that case, two questions:
1) What version of BIND are you running? You can get this with "named -V"
2) What is in the file "named.ca"?
For a long time (which is why I need to know the version) BIND has had the
Internet root hints built in, so you don't need a hint zone anymore. Unless
you are defining different roots for some reason. Hence why I need to know
the contents of that file.

Thanks, Greg



On Thu, 27 Jun 2024 at 18:06, Renzo Marengo  wrote:

>
> Hi Greg,
>
> thank you very much for your explanation.
>
> Let’s supposte AD domain was ‘my domain.it’  and I have 6000 computers of
> government institute.
>
> Here my bind configuration:
>
>
> named.conf
>
> ———
>
> include “…. named.conf.options" ;
>
> zone "." IN {
>
> type hint;
>
> file "named.ca";
>
> };
>
> include “…. named.rfc1912.zones";
>
> include “….  named.root.key";
>
> ———
>
>
>
> named.conf.options
>
> ———
>
> logging {
>
> channel named_debug {
>
> syslog local6;
>
> severity debug 1;
>
> print-category yes;
>
> print-severity yes;
>
> print-time yes;
>
> };
>
> category default { named_debug; };
>
> };
>
>
> options {
>
> auth-nxdomain no;# conform to RFC1035
>
> allow-recursion {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
> ….. } ;
>
> allow-query   {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
> ….. } ;
>
> recursive-clients 3000;
>
> allow-query-cache {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
> ….. } ; ;
>
>
> listen-on port 53 { 127.0.0.1; A.B.C.D; };
>
> directory “….. named";
>
> dump-file “….. cache_dump.db";
>
> statistics-file “….. named_stats.txt";
>
> memstatistics-file “…. named_mem_stats.txt";
>
> recursing-file  “… named.recursing";
>
> secroots-file   “… named.secroots";
>
> recursion yes;
>
> dnssec-enable no;
>
> dnssec-validation no;
>
>
> bindkeys-file "….. named.iscdlv.key";
>
> managed-keys-directory "….. dynamic";
>
> pid-file "….. named.pid";
>
> session-keyfile "….. session.key";
>
> ———
>
>
>
> >Thirdly, I would not forward to AD DNS, unless the AD servers also
> recurse and can provide >resolution for delegated names below the AD domain
>
> >that are not hosted on the AD servers themselves.
>
>
> There is no forward option to AD DNS. Forward is enable from AD DNS to
> A.B.C.D. bind9 server.
>
>
>
>
> All clients are using AD DNS infact every query, about name of ‘
> mydomain.it,’ is resolved from AD DNS.
>
> When client asks an external domain, e.g. www.google.it, AD server
> forward query to A.B.C.D. server. (Forward option is set on every domain
> controller)
>
> Only AD DNS  make queries to A.B.C.D server and it’s necessary only to
> solve external domains.
>
> A.B.C.D. server never makes queries to AD server. A.B.C.D. is next dns
> server which partecipates when it’s necessary to resolve an external domain
>
>
> I hope to have explained right.
>
> I thought A.B.C.D server made query to root server because into
> configuration there is no reference to forward option, because I thought to
> set as DNS forward a government dns of my country. What do you think?
>
> I have doubts about recursive and iterative queries options too.
>
> Thanks
>
>
> Il giorno gio 27 giu 2024 alle ore 13:24 Greg Choules <
> gregchoules+bindus...@googlemail.com> ha scritto:
>
>> Hi Renzo.
>> Firstly, please can we see your BIND configuration and have the actual AD
>> domain name.
>>
>> Secondly, BIND, or any other recursive DNS server, does not 'forward' to
>> the root servers, unless you have configured it explicitly to do so, which
>> would be a bad idea and not work anyway. It will recurse (paradoxically,
>> perform non-recursive aka iterative queries) to the roots and other
>> authoritative servers. It is an important distinction to be aware of.
>>
>> Thirdly, I would not forward to AD DNS, unless the AD servers also
>> recurse and can provide resolution for delegated names below the AD domain
>> that are not hosted on the AD servers themselves. Personally I would use a
>> stub or static-stub zone in BIND to refer to the AD domain.
>>
>> In general, decide which DNS is going to do the resolving and make that
>> the control point, fetching data from wherever it needs to (e.g. AD DNS) -
>> using non-recursive queries - and using that data to construct answers for
>> its clients.
>>
>> I hope that helps.
>> Cheers, Greg
>>
>> On Thu, 27 Jun 2024 at 12:02, Renzo Marengo 
>> wrote:
>>
>>> I have Active Directory domain ( 'mydomain.it' ) with 8 domain
>>> controllers to manage 8000 computers. Every Domain controller acts as dns
>>> service and resolve internal domain names while forward queries about
>>> external domains to another server, which Bind9 dns server (It's inside my
>>> company)
>>> I'm checking this 

Re: forward option in dns server

[Renzo Marengo]

Hi Greg,

thank you very much for your explanation.

Let’s supposte AD domain was ‘my domain.it’  and I have 6000 computers of
government institute.

Here my bind configuration:


named.conf

———

include “…. named.conf.options" ;

zone "." IN {

type hint;

file "named.ca";

};

include “…. named.rfc1912.zones";

include “….  named.root.key";

———



named.conf.options

———

logging {

channel named_debug {

syslog local6;

severity debug 1;

print-category yes;

print-severity yes;

print-time yes;

};

category default { named_debug; };

};


options {

auth-nxdomain no;# conform to RFC1035

allow-recursion {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it; …..
} ;

allow-query   {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
….. } ;

recursive-clients 3000;

allow-query-cache {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
….. } ; ;


listen-on port 53 { 127.0.0.1; A.B.C.D; };

directory “….. named";

dump-file “….. cache_dump.db";

statistics-file “….. named_stats.txt";

memstatistics-file “…. named_mem_stats.txt";

recursing-file  “… named.recursing";

secroots-file   “… named.secroots";

recursion yes;

dnssec-enable no;

dnssec-validation no;


bindkeys-file "….. named.iscdlv.key";

managed-keys-directory "….. dynamic";

pid-file "….. named.pid";

session-keyfile "….. session.key";

———



>Thirdly, I would not forward to AD DNS, unless the AD servers also recurse
and can provide >resolution for delegated names below the AD domain

>that are not hosted on the AD servers themselves.


There is no forward option to AD DNS. Forward is enable from AD DNS to
A.B.C.D. bind9 server.




All clients are using AD DNS infact every query, about name of ‘mydomain.it,’
is resolved from AD DNS.

When client asks an external domain, e.g. www.google.it, AD server forward
query to A.B.C.D. server. (Forward option is set on every domain controller)

Only AD DNS  make queries to A.B.C.D server and it’s necessary only to
solve external domains.

A.B.C.D. server never makes queries to AD server. A.B.C.D. is next dns
server which partecipates when it’s necessary to resolve an external domain


I hope to have explained right.

I thought A.B.C.D server made query to root server because into
configuration there is no reference to forward option, because I thought to
set as DNS forward a government dns of my country. What do you think?

I have doubts about recursive and iterative queries options too.

Thanks


Il giorno gio 27 giu 2024 alle ore 13:24 Greg Choules <
gregchoules+bindus...@googlemail.com> ha scritto:

> Hi Renzo.
> Firstly, please can we see your BIND configuration and have the actual AD
> domain name.
>
> Secondly, BIND, or any other recursive DNS server, does not 'forward' to
> the root servers, unless you have configured it explicitly to do so, which
> would be a bad idea and not work anyway. It will recurse (paradoxically,
> perform non-recursive aka iterative queries) to the roots and other
> authoritative servers. It is an important distinction to be aware of.
>
> Thirdly, I would not forward to AD DNS, unless the AD servers also recurse
> and can provide resolution for delegated names below the AD domain that are
> not hosted on the AD servers themselves. Personally I would use a stub or
> static-stub zone in BIND to refer to the AD domain.
>
> In general, decide which DNS is going to do the resolving and make that
> the control point, fetching data from wherever it needs to (e.g. AD DNS) -
> using non-recursive queries - and using that data to construct answers for
> its clients.
>
> I hope that helps.
> Cheers, Greg
>
> On Thu, 27 Jun 2024 at 12:02, Renzo Marengo 
> wrote:
>
>> I have Active Directory domain ( 'mydomain.it' ) with 8 domain
>> controllers to manage 8000 computers. Every Domain controller acts as dns
>> service and resolve internal domain names while forward queries about
>> external domains to another server, which Bind9 dns server (It's inside my
>> company)
>> I'm checking this Bind9 configuration (Centos server) and I see no
>> forward servers so I think It makes bind9 forward queries directly to root
>> servers. What do you think ?
>> According your opinion this Bind9 server should have to forward requests
>> to one or more dns server by forward option?
>>
>> --
>> 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 

Re: tryisc.com is not an isc.org domain

[Victoria Risk]

Update: 

This was not the fraud we thought it was 

We have learned that emails we originally identified as abuse were sent by an 
external contractor engaged by ISC to conduct a focussed and short-term lead 
generation campaign. We have instructed the vendor to halt that campaign.

We clearly suffered some communications failures here. Our communication with 
the vendor should have made it clear that we would not be comfortable with the 
approach they adopted. Plus, our internal communication failed as we lacked 
sufficient awareness of the campaign to respond in a more appropriate fashion 
when we received questions about the emails.

We have been assured by the vendor that this was not a bulk unsolicited email 
campaign. We affirm our stance that bulk unsolicited email is counter to our 
mission in support of Internet infrastructure.

We apologize for any inconvenience or disruption this event may have caused. We 
promptly canceled our abuse complaint concerning the domain name, and we ask 
any of you who have taken any filtering or blocking or complaint action against 
the domain name or the originating IP addresses to do the same. We appreciate 
the outpouring of sympathy from our community, many of whom have emailed us 
with helpful suggestions. We thank you for your continued support.



> On Jun 25, 2024, at 10:42 AM, Victoria Risk  wrote:
> 
> BIND-users,
> 
> Someone is sending emails from tryisc.com, pretending to be from Internet 
> Systems Corporation, and offering information about undisclosed BIND software 
> vulnerabilities. These emails are NOT from ISC, the authors of BIND, and they 
> are not authorized by ISC.
> 
> If you feel you have received illegitimate communications from someone 
> purporting to be an ISC staff member, please report it 
> (https://www.isc.org/security-report/). If someone other than ISC.org is 
> offering to provide software vulnerability information about ISC software, 
> this is suspicious and probably fraudulent. ISC does offer professional 
> support services, which includes advance notification of security 
> vulnerabilities in our software but we have not authorized anyone else to 
> disclose that information prior to public disclosure.
> 
> Be safe out there, and check the domain name if you are not sure about the 
> sender. ISC.org  is signed, so you can also validate it 
> (since you are all operating resolvers, right?).
> 
> Vicky Risk (working at the actual 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: forward option in dns server

[Greg Choules via bind-users]

Hi Renzo.
Firstly, please can we see your BIND configuration and have the actual AD
domain name.

Secondly, BIND, or any other recursive DNS server, does not 'forward' to
the root servers, unless you have configured it explicitly to do so, which
would be a bad idea and not work anyway. It will recurse (paradoxically,
perform non-recursive aka iterative queries) to the roots and other
authoritative servers. It is an important distinction to be aware of.

Thirdly, I would not forward to AD DNS, unless the AD servers also recurse
and can provide resolution for delegated names below the AD domain that are
not hosted on the AD servers themselves. Personally I would use a stub or
static-stub zone in BIND to refer to the AD domain.

In general, decide which DNS is going to do the resolving and make that the
control point, fetching data from wherever it needs to (e.g. AD DNS) -
using non-recursive queries - and using that data to construct answers for
its clients.

I hope that helps.
Cheers, Greg

On Thu, 27 Jun 2024 at 12:02, Renzo Marengo  wrote:

> I have Active Directory domain ( 'mydomain.it' ) with 8 domain
> controllers to manage 8000 computers. Every Domain controller acts as dns
> service and resolve internal domain names while forward queries about
> external domains to another server, which Bind9 dns server (It's inside my
> company)
> I'm checking this Bind9 configuration (Centos server) and I see no forward
> servers so I think It makes bind9 forward queries directly to root servers.
> What do you think ?
> According your opinion this Bind9 server should have to forward requests
> to one or more dns server by forward option?
>
> --
> 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

forward option in dns server

[Renzo Marengo]

I have Active Directory domain ( 'mydomain.it' ) with 8 domain controllers
to manage 8000 computers. Every Domain controller acts as dns service and
resolve internal domain names while forward queries about external domains
to another server, which Bind9 dns server (It's inside my company)
I'm checking this Bind9 configuration (Centos server) and I see no forward
servers so I think It makes bind9 forward queries directly to root servers.
What do you think ?
According your opinion this Bind9 server should have to forward requests to
one or more dns server by forward option?
-- 
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: SERVFAIL error during the evening

[sami . rahal]

Hello 
Thank you for these suggestions and advice. I will start by updating BIND to 
version 9.18, then monitor the situation and provide feedback

Regards

-Message d'origine-
De : bind-users  De la part de 
bind-users-requ...@lists.isc.org
Envoyé : jeudi 27 juin 2024 02:04
À : bind-users@lists.isc.org
Objet : bind-users Digest, Vol 4497, Issue 1

--
CAUTION : This email originated outside the company. Do not click on any links 
or open attachments unless you are expecting them from the sender.

ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas 
sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre 
l'expéditeur.
--

Send bind-users mailing list submissions to
bind-users@lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/bind-users
or, via email, send a message with subject or body 'help' to
bind-users-requ...@lists.isc.org

You can reach the person managing the list at
bind-users-ow...@lists.isc.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of bind-users digest..."


Today's Topics:

   1. Re: rolling my own hints file (Greg Choules)
   2. Re: SERVFAIL error during the evening (Michael Batchelder)


--

Message: 1
Date: Wed, 26 Jun 2024 20:46:46 +0100
From: Greg Choules 
To: "Cuttler, Brian R (HEALTH)" 
Cc: David Farje , bind-users
,  "Hefner, Joseph (HEALTH)"

Subject: Re: rolling my own hints file
Message-ID:

Content-Type: text/plain; charset="utf-8"

Hi Brian.
Ni problem. The server may tell the client (dig; please not nslookup) 
information about where the answer came from, if 'minimal-responses' is set to 
"no". Usually clients don't need to know that, so please take a look at how m-r 
works:
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-minimal-responses

Cheers, Greg

On Wed, 26 Jun 2024 at 17:55, Cuttler, Brian R (HEALTH) < 
brian.cutt...@health.ny.gov> wrote:

>
>
> Greg, David,
>
>
>
> Thanks, much easier than what I thought it would be.
>
> I have two ?root? servers so I went with this format, allowing a round 
> robin selection.
>
> Essentially this, sorry trying to be vague on the IPs.
>
>
>
> @ 518400   IN A xx.yy.zz..7
>
> @ 518400   IN A xx.yy.zz..8
>
> .   518400IN NS @
>
>
>
> Server reloaded fine and I am able to resolve non-domain information.
> Is there a flag someplace in dig or nslookup to show what root server 
> I?m hitting? I don?t see that in any of the named log files, I may 
> need to add an ACL to log the traffic in a router to verify.
> Then again ? my FW is not seeing queries to any of the normal root 
> servers, so that is in fact a good sign.
>
>
>
> New root servers are managed by my parent organization and my manager 
> asked me to send these queries through them. Wouldn?t be performing 
> this exercise otherwise.
>
>
>
> Thank you ? I think you?ve given me exactly what was needed.
>
>
>
> Brian
>
>
>
> *From:* Greg Choules 
> *Sent:* Wednesday, June 26, 2024 12:29 PM
> *To:* Cuttler, Brian R (HEALTH) 
> *Cc:* bind-users 
> *Subject:* Re: rolling my own hints file
>
>
>
> You don't often get email from gregchoules+bindus...@googlemail.com. 
> Learn why this is important 
> 
>
> *ATTENTION: This email came from an external source. Do not open 
> attachments or click on links from unknown senders or unexpected 
> emails.*
>
>
>
> Hi Brian.
>
> Yes, you can define your own hint zone and tell BIND to use it. The 
> contents (I called the file "db.root" but the name is your choice) 
> could be as simple as:
>
>
>
> @ 300 IN A 127.0.0.3
> @ 300 IN NS @
>
>
>
> which says for this zone (which will be called ".", coming next) the 
> NS is the same name and its IP is 127.0.0.3, which happens to be 
> another instance of BIND I have running. Your file would contain the 
> names and IPs of your internal roots.
>
>
>
> In the config, define the hint zone like this:
>
>
>
> zone "." {
> type hint;
> file "db.root";
> };
>
>
>
> That should be all you need.
>
> Cheers, Greg
>
>
>
> On Wed, 26 Jun 2024 at 15:58, Cuttler, Brian R (HEALTH) via bind-users 
> < bind-users@lists.isc.org> wrote:
>
> Running Bind 9.18.18 on Ubuntu 22.04
>
>
>
> We would like to use root servers within our organization rather than 
> the actual root servers.
> I updated the hints file with the names and IPs of our servers, but we 
> seem to still access the official root servers.
>
> Wondering how I ignore the internal/build-in hints and have my own file.
>
> Wondering if replacing the IP addresses in the db.cache file with a 
> 

Re: SERVFAIL error during the evening

[Michael Batchelder]

> I have configured qname to disabled for now. Once the issue is resolved,
> I will set it to relaxed. I have provided a download link for the log
> files and a dig +trace test for more details on this issue, which I do
> not think is related to BIND or its configuration.

Sami,

Discussions of non-BIND issues are outside the scope of this list. If you 
believe an issue is not related to BIND, you should look for a different forum 
or resource (such as vendor technical support) whose purview is relevant to the 
problem you have.

Regarding your example dig +trace for push-rtmp-l96.douyincdn.com, you stopped 
at the point of tracing that produced this answer:

push-rtmp-l96.douyincdn.com. 600 IN CNAME   
push-rtmp-l96.douyincdn.com.d.live.cdn.chinamobile.com.

You will need to do the next steps of troubleshooting to see how 
push-rtmp-l96.douyincdn.com.d.live.cdn.chinamobile.com is resolved. To do that, 
I recommend using an excellent tool written by Shumon Huque: resolve.py 
(https://github.com/shuque/resolve). In particular, this tool will help you to 
see problems when QNAME minimization breaks due to bad zone configurations. 
Running the tool with the appropriate command-line switches:

resolve.py -mv push-rtmp-l96.douyincdn.com.d.live.cdn.chinamobile.com

will reveal multiple issues. One is:

# QUERY: com.d.live.cdn.chinamobile.com. A IN at zone 
d.live.cdn.chinamobile.com. address 139.159.208.46
#[Got answer in 0.378 s]
ERROR: NXDOMAIN: com.d.live.cdn.chinamobile.com. not found

NXDOMAIN is an incorrect response for this query; the correct response is 
NODATA (i.e. RCODE = 0, ANSWER = 0). So China Mobile's CDN has broken DNS 
configuration and this breaks QNAME minimization. And querying the domain of 
the CNAME you would get if this failure wasn't present 
(cmcczjcdnl.pushcmcc.rtmps.gslb.d.live.cdn.chinamobile.com) also produces an 
NXDOMAIN at gslb.d.live.cdn.chinamobile.com and the nodes below it. So same 
problem.

> I suspected that a firewall was blocking the DNS traffic, so I bypassed
> the firewall, but the result is the same. How can we ensure that this is
> a network-level issue?

I looked at some of your logs. The resolver.log file is mostly errors of the 
form:

resolver: notice: DNS format error from #53 resolving 
ns-open3.qq.com/ for : Name qq.com (SOA) not subdomain of zone 
ns-open3.qq.com -- invalid response

If you look at the corresponding packets in your pcap, the responses are NODATA 
with an SOA record for the qq.com zone indicating the authoritative zone. But 
if you query for the NS records from the authoritative servers, you get a reply 
that indicates the zone ns-open3.qq.com is authoritative for resolving 
ns-open3.qq.com/all QTYPEs:

# dig @59.36.132.142 ns-open3.qq.com ns

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> @59.36.132.142 ns-open3.qq.com 
ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1621
;; flags: qr aa rd ad; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4304
; COOKIE: 4cd34d4c82645709 (echoed)
;; QUESTION SECTION:
;ns-open3.qq.com.   IN  NS

;; ANSWER SECTION:
ns-open3.qq.com.86400   IN  NS  ns-tel1.qq.com.
ns-open3.qq.com.86400   IN  NS  ns-cnc1.qq.com.
ns-open3.qq.com.86400   IN  NS  ns-os1.qq.com.
ns-open3.qq.com.86400   IN  NS  ns-cmn1.qq.com.

This mismatch between the authoritative zone name in the SOA record (qq.com) 
and what the delegated nameservers claim is the authoritative zone 
(ns-open3.qq.com) causes these messages.

If you use the search for this mailing list at 
https://lists.isc.org/pipermail/bind-users/ or just use any public search 
engine you will see examples of people reporting this issue, and even citing 
this particular domain. This is not a BIND problem, it's a misconfiguration of 
records/zones. You can try contacting the administrator of the zone, 
webmas...@qq.com (per the SOA record).

And before you ask for help from this list for future issues, I strongly 
recommend you run any domain that is failing to resolve through dnsviz.net to 
ensure that you're not asking about another zone misconfiguration, rather than 
an actual BIND problem.

> download link: 
>
> https://we.tl/t-M77os84duE

This link does not appear to be a "public" link. A login appears to be 
required. In the future, please check that you are providing a public link 
(i.e. no login required) by using "private" mode of your chosen browser to see 
if a link can be accessed without prior login.

Beyond that... As I mentioned in my initial email, your version of BIND is old 
and end-of-life. You should upgrade so that any issues can be discussed and 
bugs filed if necessary. Problems found in EOL'd versions are less likely to be 
addressed by listmembers (beyond indicating that you should 

Re: rolling my own hints file

[Greg Choules via bind-users]

Hi Brian.
Ni problem. The server may tell the client (dig; please not nslookup)
information about where the answer came from, if 'minimal-responses' is set
to "no". Usually clients don't need to know that, so please take a look at
how m-r works:
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-minimal-responses

Cheers, Greg

On Wed, 26 Jun 2024 at 17:55, Cuttler, Brian R (HEALTH) <
brian.cutt...@health.ny.gov> wrote:

>
>
> Greg, David,
>
>
>
> Thanks, much easier than what I thought it would be.
>
> I have two “root” servers so I went with this format, allowing a round
> robin selection.
>
> Essentially this, sorry trying to be vague on the IPs.
>
>
>
> @ 518400   IN A xx.yy.zz..7
>
> @ 518400   IN A xx.yy.zz..8
>
> .   518400IN NS @
>
>
>
> Server reloaded fine and I am able to resolve non-domain information.
> Is there a flag someplace in dig or nslookup to show what root server I’m
> hitting? I don’t see that in any of the named log files, I may need to add
> an ACL to log the traffic in a router to verify.
> Then again – my FW is not seeing queries to any of the normal root
> servers, so that is in fact a good sign.
>
>
>
> New root servers are managed by my parent organization and my manager
> asked me to send these queries through them. Wouldn’t be performing this
> exercise otherwise.
>
>
>
> Thank you – I think you’ve given me exactly what was needed.
>
>
>
> Brian
>
>
>
> *From:* Greg Choules 
> *Sent:* Wednesday, June 26, 2024 12:29 PM
> *To:* Cuttler, Brian R (HEALTH) 
> *Cc:* bind-users 
> *Subject:* Re: rolling my own hints file
>
>
>
> You don't often get email from gregchoules+bindus...@googlemail.com. Learn
> why this is important 
>
> *ATTENTION: This email came from an external source. Do not open
> attachments or click on links from unknown senders or unexpected emails.*
>
>
>
> Hi Brian.
>
> Yes, you can define your own hint zone and tell BIND to use it. The
> contents (I called the file "db.root" but the name is your choice) could be
> as simple as:
>
>
>
> @ 300 IN A 127.0.0.3
> @ 300 IN NS @
>
>
>
> which says for this zone (which will be called ".", coming next) the NS is
> the same name and its IP is 127.0.0.3, which happens to be another instance
> of BIND I have running. Your file would contain the names and IPs of your
> internal roots.
>
>
>
> In the config, define the hint zone like this:
>
>
>
> zone "." {
> type hint;
> file "db.root";
> };
>
>
>
> That should be all you need.
>
> Cheers, Greg
>
>
>
> On Wed, 26 Jun 2024 at 15:58, Cuttler, Brian R (HEALTH) via bind-users <
> bind-users@lists.isc.org> wrote:
>
> Running Bind 9.18.18 on Ubuntu 22.04
>
>
>
> We would like to use root servers within our organization rather than the
> actual root servers.
> I updated the hints file with the names and IPs of our servers, but we
> seem to still access the official root servers.
>
> Wondering how I ignore the internal/build-in hints and have my own file.
>
> Wondering if replacing the IP addresses in the db.cache file with a
> round-robin of my internal IP addresses isn’t the answer.
> Not elegant but perhaps would work?
>
> Is there a supported way to do what I want to do – we do not want an
> forwarding only server, we do serve a good number of internal statis and
> dynamic zones but also want to resolve non-domain addresses or addresses we
> lack forwarder zones for from a ‘root’ source.
>
>
>
> ;; ADDITIONAL SECTION:
>
> a.root-servers.net. 518400  IN  A   198.41.0.4
>
> b.root-servers.net. 518400  IN  A   170.247.170.2
>
> c.root-servers.net. 518400  IN  A   192.33.4.12
>
>
>
> Thanks for your help and suggestions,
>
> Brian
>
>
>
>
>
> Brian Cuttler, System and Network Administration
>
> Wadsworth Center, NYS Department of Health
>
> Albany, NY 12201 POB 509
>
> brian.cutt...@health.ny.gov
>
> 518 486-1697
>
>
>
> --
> 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: rolling my own hints file

[Cuttler, Brian R (HEALTH) via bind-users]

Greg, David,

Thanks, much easier than what I thought it would be.

I have two "root" servers so I went with this format, allowing a round robin 
selection.
Essentially this, sorry trying to be vague on the IPs.

@ 518400   IN A xx.yy.zz..7
@ 518400   IN A xx.yy.zz..8
.   518400IN NS @

Server reloaded fine and I am able to resolve non-domain information.
Is there a flag someplace in dig or nslookup to show what root server I'm 
hitting? I don't see that in any of the named log files, I may need to add an 
ACL to log the traffic in a router to verify.
Then again - my FW is not seeing queries to any of the normal root servers, so 
that is in fact a good sign.

New root servers are managed by my parent organization and my manager asked me 
to send these queries through them. Wouldn't be performing this exercise 
otherwise.

Thank you - I think you've given me exactly what was needed.

Brian

From: Greg Choules 
Sent: Wednesday, June 26, 2024 12:29 PM
To: Cuttler, Brian R (HEALTH) 
Cc: bind-users 
Subject: Re: rolling my own hints file

You don't often get email from 
gregchoules+bindus...@googlemail.com.
 Learn why this is important

ATTENTION: This email came from an external source. Do not open attachments or 
click on links from unknown senders or unexpected emails.

Hi Brian.
Yes, you can define your own hint zone and tell BIND to use it. The contents (I 
called the file "db.root" but the name is your choice) could be as simple as:

@ 300 IN A 127.0.0.3
@ 300 IN NS @

which says for this zone (which will be called ".", coming next) the NS is the 
same name and its IP is 127.0.0.3, which happens to be another instance of BIND 
I have running. Your file would contain the names and IPs of your internal 
roots.

In the config, define the hint zone like this:

zone "." {
type hint;
file "db.root";
};

That should be all you need.
Cheers, Greg

On Wed, 26 Jun 2024 at 15:58, Cuttler, Brian R (HEALTH) via bind-users 
mailto:bind-users@lists.isc.org>> wrote:
Running Bind 9.18.18 on Ubuntu 22.04

We would like to use root servers within our organization rather than the 
actual root servers.
I updated the hints file with the names and IPs of our servers, but we seem to 
still access the official root servers.

Wondering how I ignore the internal/build-in hints and have my own file.

Wondering if replacing the IP addresses in the db.cache file with a round-robin 
of my internal IP addresses isn't the answer.
Not elegant but perhaps would work?

Is there a supported way to do what I want to do - we do not want an forwarding 
only server, we do serve a good number of internal statis and dynamic zones but 
also want to resolve non-domain addresses or addresses we lack forwarder zones 
for from a 'root' source.

;; ADDITIONAL SECTION:
a.root-servers.net. 518400  IN  A   
198.41.0.4
b.root-servers.net. 518400  IN  A   
170.247.170.2
c.root-servers.net. 518400  IN  A   
192.33.4.12

Thanks for your help and suggestions,
Brian


Brian Cuttler, System and Network Administration
Wadsworth Center, NYS Department of Health
Albany, NY 12201 POB 509
brian.cutt...@health.ny.gov
518 486-1697

--
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: rolling my own hints file

[David Farje]

Hi Brian R,

I built a lab to investigate DNS cache poisoning with custom root servers,
no DNSSEC.  What you're trying to do is possible in production I'm just not
sure it's recommended.
You will need to update your root.hints (or whatever file name you're using
for the root hint zone) file to point to your custom root server and you
will probably have to restart named daemon.
The root server must serve the root zone authoritatively. You can find an
example root zone in the following link
https://www.internic.net/domain/root.zone.   In my lab I had to edit this
file to use my custom TLD server for the .net domain.

Best Regards,
David Farje
On Wed, Jun 26, 2024 at 10:58 AM Cuttler, Brian R (HEALTH) via bind-users <
bind-users@lists.isc.org> wrote:

> Running Bind 9.18.18 on Ubuntu 22.04
>
>
>
> We would like to use root servers within our organization rather than the
> actual root servers.
> I updated the hints file with the names and IPs of our servers, but we
> seem to still access the official root servers.
>
> Wondering how I ignore the internal/build-in hints and have my own file.
>
> Wondering if replacing the IP addresses in the db.cache file with a
> round-robin of my internal IP addresses isn’t the answer.
> Not elegant but perhaps would work?
>
> Is there a supported way to do what I want to do – we do not want an
> forwarding only server, we do serve a good number of internal statis and
> dynamic zones but also want to resolve non-domain addresses or addresses we
> lack forwarder zones for from a ‘root’ source.
>
>
>
> ;; ADDITIONAL SECTION:
>
> a.root-servers.net. 518400  IN  A   198.41.0.4
>
> b.root-servers.net. 518400  IN  A   170.247.170.2
>
> c.root-servers.net. 518400  IN  A   192.33.4.12
>
>
>
> Thanks for your help and suggestions,
>
> Brian
>
>
>
>
>
> Brian Cuttler, System and Network Administration
>
> Wadsworth Center, NYS Department of Health
>
> Albany, NY 12201 POB 509
>
> brian.cutt...@health.ny.gov
>
> 518 486-1697
>
>
> --
> 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: rolling my own hints file

[Greg Choules via bind-users]

Hi Brian.
Yes, you can define your own hint zone and tell BIND to use it. The
contents (I called the file "db.root" but the name is your choice) could be
as simple as:

@ 300 IN A 127.0.0.3
@ 300 IN NS @

which says for this zone (which will be called ".", coming next) the NS is
the same name and its IP is 127.0.0.3, which happens to be another instance
of BIND I have running. Your file would contain the names and IPs of your
internal roots.

In the config, define the hint zone like this:

zone "." {
type hint;
file "db.root";
};

That should be all you need.
Cheers, Greg

On Wed, 26 Jun 2024 at 15:58, Cuttler, Brian R (HEALTH) via bind-users <
bind-users@lists.isc.org> wrote:

> Running Bind 9.18.18 on Ubuntu 22.04
>
>
>
> We would like to use root servers within our organization rather than the
> actual root servers.
> I updated the hints file with the names and IPs of our servers, but we
> seem to still access the official root servers.
>
> Wondering how I ignore the internal/build-in hints and have my own file.
>
> Wondering if replacing the IP addresses in the db.cache file with a
> round-robin of my internal IP addresses isn’t the answer.
> Not elegant but perhaps would work?
>
> Is there a supported way to do what I want to do – we do not want an
> forwarding only server, we do serve a good number of internal statis and
> dynamic zones but also want to resolve non-domain addresses or addresses we
> lack forwarder zones for from a ‘root’ source.
>
>
>
> ;; ADDITIONAL SECTION:
>
> a.root-servers.net. 518400  IN  A   198.41.0.4
>
> b.root-servers.net. 518400  IN  A   170.247.170.2
>
> c.root-servers.net. 518400  IN  A   192.33.4.12
>
>
>
> Thanks for your help and suggestions,
>
> Brian
>
>
>
>
>
> Brian Cuttler, System and Network Administration
>
> Wadsworth Center, NYS Department of Health
>
> Albany, NY 12201 POB 509
>
> brian.cutt...@health.ny.gov
>
> 518 486-1697
>
>
> --
> 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

rolling my own hints file

[Cuttler, Brian R (HEALTH) via bind-users]

Running Bind 9.18.18 on Ubuntu 22.04

We would like to use root servers within our organization rather than the 
actual root servers.
I updated the hints file with the names and IPs of our servers, but we seem to 
still access the official root servers.

Wondering how I ignore the internal/build-in hints and have my own file.

Wondering if replacing the IP addresses in the db.cache file with a round-robin 
of my internal IP addresses isn't the answer.
Not elegant but perhaps would work?

Is there a supported way to do what I want to do - we do not want an forwarding 
only server, we do serve a good number of internal statis and dynamic zones but 
also want to resolve non-domain addresses or addresses we lack forwarder zones 
for from a 'root' source.

;; ADDITIONAL SECTION:
a.root-servers.net. 518400  IN  A   198.41.0.4
b.root-servers.net. 518400  IN  A   170.247.170.2
c.root-servers.net. 518400  IN  A   192.33.4.12

Thanks for your help and suggestions,
Brian


Brian Cuttler, System and Network Administration
Wadsworth Center, NYS Department of Health
Albany, NY 12201 POB 509
brian.cutt...@health.ny.gov
518 486-1697

-- 
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 ISC BIND COPR repositories for 9.16->9.18 ESV transition

[Michał Kępień]

We have just upgraded the "bind-esv" repository from BIND 9.16.50 to
BIND 9.18.27, i.e. the same version as in the "bind" repository.

We will try to keep everyone informed about further major version
upgrades in our package repositories in the coming months.

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

Re: SERVFAIL error during the evening

[Greg Choules via bind-users]

Hi Sami.
If you can, I would set up a new BIND (test) server running the current
code - 9.18.27 - next to your current production system and compare how
they behave: current code uses NS queries for qmin rather than _... A
queries. There may still be failures, but this would allow you to pinpoint
better which domains are the problematic ones.
Packet captures are always good for showing exactly what servers send and
what they get back. There's no hiding in Wireshark!

Cheers, Greg

On Wed, 26 Jun 2024 at 07:45,  wrote:

> Hello
> Thank you for your response. I have configured qname to disabled for now.
> Once the issue is resolved, I will set it to relaxed. I have provided a
> download link for the log files and a dig +trace test for more details on
> this issue, which I do not think is related to BIND or its configuration. I
> suspected that a firewall was blocking the DNS traffic, so I bypassed the
> firewall, but the result is the same. How can we ensure that this is a
> network-level issue?
>
> download link:
>
> https://we.tl/t-M77os84duE
>
> Regards
>
> Sami
>
> -Message d'origine-
> De : bind-users  De la part de
> bind-users-requ...@lists.isc.org
> Envoyé : mardi 25 juin 2024 13:00
> À : bind-users@lists.isc.org
> Objet : bind-users Digest, Vol 4495, Issue 2
>
>
> --
> CAUTION : This email originated outside the company. Do not click on any
> links or open attachments unless you are expecting them from the sender.
>
> ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez
> pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre
> l'expéditeur.
>
> --
>
> Send bind-users mailing list submissions to
> bind-users@lists.isc.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isc.org/mailman/listinfo/bind-users
> or, via email, send a message with subject or body 'help' to
> bind-users-requ...@lists.isc.org
>
> You can reach the person managing the list at
> bind-users-ow...@lists.isc.org
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of bind-users digest..."
>
>
> Today's Topics:
>
>1. Re: SERVFAIL error during the evening (Michael Batchelder)
>2. Re: qname minimization: me too :( (Stephane Bortzmeyer)
>3. Re: can I provide invalid HTTPS values for testing?
>   (Stephane Bortzmeyer)
>
>
> --
>
> Message: 1
> Date: Tue, 25 Jun 2024 06:34:42 + (UTC)
> From: Michael Batchelder 
> To: bind-users 
> Cc: sami rahal 
> Subject: Re: SERVFAIL error during the evening
> Message-ID: <646819319.2383375.1719297282567.javamail.zim...@isc.org>
> Content-Type: text/plain; charset=utf-8
>
> >> Hello Michael
> >> Thank you for your response. Here is a pcap file and some logs.
> >
> > Hello Sami,
> >
> > Your pcap shows your resolver making thousands of queries that get no
> > responses (or at least the pcap does not contain them). There's not
> > much I can say, beyond that this does not appear to be a > problem
> > related to BIND.
>
> Sami,
>
> My co-worker helpfully pointed out something I missed when reviewing your
> packet capture. A large number of your resolution failures are because your
> BIND is configured to use QNAME minimization (a.k.a. "qmin") and the
> queries are to zones whose configuration is done incorrectly and breaks
> qmin.
>
> The pcap indicates you have the 'qname-minimization strict' setting in
> your BIND configuration file. See the "qname-minimization" statement in the
> Options section of the BIND ARM (
> https://bind9.readthedocs.io/en/v9.16.25/reference.html#options-statement-definition-and-usage).
> For the general background on qmin, read RFCs 7816 and 9156.
>
> I don't know of a reason why you would experience more qmin failures in
> the evening, other than the requests that fail are only made at that time.
> Regardless, if you want to stop the failures completely, you can change the
> 'qname-minimization strict' setting to 'qname-minimization disabled'. The
> drawback is that your queries will no longer be minimized, so all
> authoritative servers will see the full query name during recursion.
>
> As a compromise between doing nothing and fully disabling qmin, you can
> use the 'qname-minimization relaxed' setting which will try qmin and if
> BIND encounters a zone which breaks qmin, then BIND will switch to not
> doing qmin and do normal recursion (equivalent to 'qname-minimization
> disabled') for that query.
>
> Also, you should upgrade your version of BIND, as we can see that the qmin
> queries are those used in older versions of BIND.
>
> Michael
>
>
> --
>
> Message: 2
> Date: Tue, 25 Jun 2024 10:59:19 

RE: SERVFAIL error during the evening

[sami . rahal]

Hello 
Thank you for your response. I have configured qname to disabled for now. Once 
the issue is resolved, I will set it to relaxed. I have provided a download 
link for the log files and a dig +trace test for more details on this issue, 
which I do not think is related to BIND or its configuration. I suspected that 
a firewall was blocking the DNS traffic, so I bypassed the firewall, but the 
result is the same. How can we ensure that this is a network-level issue?

download link: 

https://we.tl/t-M77os84duE

Regards

Sami

-Message d'origine-
De : bind-users  De la part de 
bind-users-requ...@lists.isc.org
Envoyé : mardi 25 juin 2024 13:00
À : bind-users@lists.isc.org
Objet : bind-users Digest, Vol 4495, Issue 2

--
CAUTION : This email originated outside the company. Do not click on any links 
or open attachments unless you are expecting them from the sender.

ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas 
sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre 
l'expéditeur.
--

Send bind-users mailing list submissions to
bind-users@lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/bind-users
or, via email, send a message with subject or body 'help' to
bind-users-requ...@lists.isc.org

You can reach the person managing the list at
bind-users-ow...@lists.isc.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of bind-users digest..."


Today's Topics:

   1. Re: SERVFAIL error during the evening (Michael Batchelder)
   2. Re: qname minimization: me too :( (Stephane Bortzmeyer)
   3. Re: can I provide invalid HTTPS values for testing?
  (Stephane Bortzmeyer)


--

Message: 1
Date: Tue, 25 Jun 2024 06:34:42 + (UTC)
From: Michael Batchelder 
To: bind-users 
Cc: sami rahal 
Subject: Re: SERVFAIL error during the evening
Message-ID: <646819319.2383375.1719297282567.javamail.zim...@isc.org>
Content-Type: text/plain; charset=utf-8

>> Hello Michael
>> Thank you for your response. Here is a pcap file and some logs.
> 
> Hello Sami,
>
> Your pcap shows your resolver making thousands of queries that get no 
> responses (or at least the pcap does not contain them). There's not 
> much I can say, beyond that this does not appear to be a > problem 
> related to BIND.

Sami,

My co-worker helpfully pointed out something I missed when reviewing your 
packet capture. A large number of your resolution failures are because your 
BIND is configured to use QNAME minimization (a.k.a. "qmin") and the queries 
are to zones whose configuration is done incorrectly and breaks qmin.

The pcap indicates you have the 'qname-minimization strict' setting in your 
BIND configuration file. See the "qname-minimization" statement in the Options 
section of the BIND ARM 
(https://bind9.readthedocs.io/en/v9.16.25/reference.html#options-statement-definition-and-usage).
 For the general background on qmin, read RFCs 7816 and 9156.

I don't know of a reason why you would experience more qmin failures in the 
evening, other than the requests that fail are only made at that time. 
Regardless, if you want to stop the failures completely, you can change the 
'qname-minimization strict' setting to 'qname-minimization disabled'. The 
drawback is that your queries will no longer be minimized, so all authoritative 
servers will see the full query name during recursion.

As a compromise between doing nothing and fully disabling qmin, you can use the 
'qname-minimization relaxed' setting which will try qmin and if BIND encounters 
a zone which breaks qmin, then BIND will switch to not doing qmin and do normal 
recursion (equivalent to 'qname-minimization disabled') for that query.

Also, you should upgrade your version of BIND, as we can see that the qmin 
queries are those used in older versions of BIND. 

Michael


--

Message: 2
Date: Tue, 25 Jun 2024 10:59:19 +0200
From: Stephane Bortzmeyer 
To: Peter 
Cc: Stephane Bortzmeyer , Michael Batchelder
, bind-users 
Subject: Re: qname minimization: me too :(
Message-ID: 
Content-Type: text/plain; charset=us-ascii

On Mon, Jun 24, 2024 at 10:32:37PM +0200,  Peter  
wrote  a message of 40 lines which said:

> In other words: why do You guys no longer talk to each other?

We do but talking is one thing, convincing is another one, and making people 
act is a third :-(


--

Message: 3
Date: Tue, 25 Jun 2024 11:03:22 +0200
From: Stephane Bortzmeyer 
To: Stephen Farrell 
Cc: bind-users@lists.isc.org
Subject: Re: can I provide invalid HTTPS values for testing?

Re: qname minimization: me too :(

[tale via bind-users]

On Tue, Jun 25, 2024 at 10:42 AM Stephane Bortzmeyer  wrote:
> > Jun 25 16:18:31  conr named[4725]: lame-servers:
> >info: success resolving 'bar.foo.isc.org/A' after disabling
> >qname minimization due to 'ncache nxdomain'
>
> I do not see how this is possible ("success resolving") since the name
> does not exist and all ISC name servers reply it does not exist.
>
> And all the resolvers I tried (through RIPE Atlas) say the same. No
> "success resolving".

Admittedly "success" can be ambiguous, and in this case it means
successfully got an answer for the question that was originally being
pursued.  In this context, a negative answer is still a successful
resolution, unlike timeout or servfail from auths or various other
failures.

-- 
tale
-- 
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: qname minimization: me too :(

[Peter]

On Tue, Jun 25, 2024 at 04:41:54PM +0200, Stephane Bortzmeyer wrote:
! On Tue, Jun 25, 2024 at 04:22:40PM +0200,
!  Peter  wrote 
!  a message of 16 lines which said:
! 
! > Jun 25 16:18:31  conr named[4725]: lame-servers:
! >info: success resolving 'bar.foo.isc.org/A' after disabling
! >qname minimization due to 'ncache nxdomain'
! 
! I do not see how this is possible ("success resolving") since the name
! does not exist and all ISC name servers reply it does not exist.
! 
! And all the resolvers I tried (through RIPE Atlas) say the same. No
! "success resolving".
! 
! Strange...

Good, now we're getting on the same page. :)

I think I understand it now (more or less):

Let's assume the nameserver for isc.org. is configured correctly. Then
this message concerning qname-minimization cannot be substantial, it
likely rather is, as Mark Andrews said, a "false positive".

Second, what do we mean by "success resolving"? Do we mean we got the
desired answer? Do we mean we got a correct proof of nonexistance? Or
do we just mean we did not end up in timeout/SERVFAIL?

I don't know exactly, and I don't bother anymore. I spent my time
searching my own configurations for an error (or just an
imperfectness) due to this same message - and probably there is none.


cheerio,
PMc
-- 
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

tryisc.com is not an isc.org domain

[Victoria Risk]

BIND-users,

Someone is sending emails from tryisc.com, pretending to be from Internet 
Systems Corporation, and offering information about undisclosed BIND software 
vulnerabilities. These emails are NOT from ISC, the authors of BIND, and they 
are not authorized by ISC.

If you feel you have received illegitimate communications from someone 
purporting to be an ISC staff member, please report it 
(https://www.isc.org/security-report/). If someone other than ISC.org is 
offering to provide software vulnerability information about ISC software, this 
is suspicious and probably fraudulent. ISC does offer professional support 
services, which includes advance notification of security vulnerabilities in 
our software but we have not authorized anyone else to disclose that 
information prior to public disclosure.

Be safe out there, and check the domain name if you are not sure about the 
sender. ISC.org  is signed, so you can also validate it (since 
you are all operating resolvers, right?).

Vicky Risk (working at the actual 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