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

Re: qname minimization: me too :(

[Stephane Bortzmeyer]

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


-- 
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 07:00:51AM +1000, Mark Andrews wrote:
! It’s just a false positive when the result is NXDOMAIN. Because
> people forget to put delegating NS records in parent zones when both
> are served by the same server the lookups continue on NXDOMAIN. There
> is an issue to address this.  

You mean this?

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'

-- 
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: can I provide invalid HTTPS values for testing?

[Stephane Bortzmeyer]

On Thu, Jun 20, 2024 at 02:29:13PM +0100,
 Stephen Farrell  wrote 
 a message of 100 lines which said:

> Actually, it may well be that bind allows me sufficient leeway to do
> most of the tests I want, so this is just to check that there's no
> imminent plan to have bind disallow the kind of rubbish HTTPS RRs
> below.

A related issue: does anyone know a software / service which tests
HTTPS records and actually connects to the HTTPS server to see if it
indeed supports what it claims to support. (Testing all ALPNs, all IP
hints, etc.)

"Error, HTTP record says alpn=h3 but HTTP/3 setup failed"

Bonus if I can integrate it in Nagios/Icinga/Zabbix/etc.
-- 
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 :(

[Stephane Bortzmeyer]

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

[Michael Batchelder]

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

[Mark Andrews]

I should add that a resolver should be able to stop on the first NXDOMAIN.  
It’s only because we know there are mis-implementations of the protocol 
(returning NXDOMAIN rather that NOERROR for empty non-terminals) and 
mis-configurations (missing delegating NS records) that the default is to 
continue.  If people where willing to put up with NXDOMAIN being returned 
rather than the data that is later found by continuing or not using QNAME 
minimisation the default could be changed.  'But it “works" when I ask Google' 
is a hard thing to fight against.

Mark

> On 25 Jun 2024, at 07:00, Mark Andrews  wrote:
> 
> It’s just a false positive when the result is NXDOMAIN. Because people forget 
> to put delegating NS records in parent zones when both are served by the same 
> server the lookups continue on NXDOMAIN. There is an issue to address this. 
> 
> -- 
> Mark Andrews
> 
>> On 25 Jun 2024, at 06:36, Peter  wrote:
>> 
>> On Fri, Jun 21, 2024 at 04:58:55PM +0200, Stephane Bortzmeyer wrote:
>> ! On Fri, Jun 21, 2024 at 07:03:14AM +,
>> ! 65;6800;1c Michael Batchelder  wrote 
>> !  a message of 59 lines which said:
>> ! 
>> ! > You'll need to fix these zones so that the response is NOERROR rather 
>> than NXDOMAIN.
>> ! 
>> ! Yes and, if you want the whole context, you can read RFC 8020
>> !  and section 4 of RFC 7816
>> ! .
>> 
>> 
>> Sure, I did that already. And I also talked to the maintainer of
>> ns*.he.net, i.e. this one:
>> 
>> ! > The f.1.0.7.4.0.1.0.0.2.ip6.arpa zone (@216.66.80.18) responds with 
>> NXDOMAIN to queries for any QTYPE for QNAME f.1.0.7.4.0.1.0.0.2.ip6.arpa
>> ! >
>> ! > You'll need to fix these zones so that the response is NOERROR rather 
>> than NXDOMAIN.
>> 
>> And they seem to think, there is nothing wrong with that, because
>> nobody ever has complained about that.
>> 
>> 
>> Now I am really wondering: why do I, an unemployed old guy just
>> running his own computer, suddenly find myself in between a root
>> operator and the biggest v6 network on the planet?
>> 
>> In other words: why do You guys no longer talk to each other?
>> 
>> 
>> 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
> 
> -- 
> 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: qname minimization: me too :(

[Mark Andrews]

It’s just a false positive when the result is NXDOMAIN. Because people forget 
to put delegating NS records in parent zones when both are served by the same 
server the lookups continue on NXDOMAIN. There is an issue to address this. 

-- 
Mark Andrews

> On 25 Jun 2024, at 06:36, Peter  wrote:
> 
> On Fri, Jun 21, 2024 at 04:58:55PM +0200, Stephane Bortzmeyer wrote:
> ! On Fri, Jun 21, 2024 at 07:03:14AM +,
> ! 65;6800;1c Michael Batchelder  wrote 
> !  a message of 59 lines which said:
> ! 
> ! > You'll need to fix these zones so that the response is NOERROR rather 
> than NXDOMAIN.
> ! 
> ! Yes and, if you want the whole context, you can read RFC 8020
> !  and section 4 of RFC 7816
> ! .
> 
> 
> Sure, I did that already. And I also talked to the maintainer of
> ns*.he.net, i.e. this one:
> 
> ! > The f.1.0.7.4.0.1.0.0.2.ip6.arpa zone (@216.66.80.18) responds with 
> NXDOMAIN to queries for any QTYPE for QNAME f.1.0.7.4.0.1.0.0.2.ip6.arpa
> ! >
> ! > You'll need to fix these zones so that the response is NOERROR rather 
> than NXDOMAIN.
> 
> And they seem to think, there is nothing wrong with that, because
> nobody ever has complained about that.
> 
> 
> Now I am really wondering: why do I, an unemployed old guy just
> running his own computer, suddenly find myself in between a root
> operator and the biggest v6 network on the planet?
> 
> In other words: why do You guys no longer talk to each other?
> 
> 
> 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

-- 
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 Fri, Jun 21, 2024 at 04:58:55PM +0200, Stephane Bortzmeyer wrote:
! On Fri, Jun 21, 2024 at 07:03:14AM +,
! 65;6800;1c Michael Batchelder  wrote 
!  a message of 59 lines which said:
! 
! > You'll need to fix these zones so that the response is NOERROR rather than 
NXDOMAIN.
! 
! Yes and, if you want the whole context, you can read RFC 8020
!  and section 4 of RFC 7816
! .


Sure, I did that already. And I also talked to the maintainer of
ns*.he.net, i.e. this one:

! > The f.1.0.7.4.0.1.0.0.2.ip6.arpa zone (@216.66.80.18) responds with 
NXDOMAIN to queries for any QTYPE for QNAME f.1.0.7.4.0.1.0.0.2.ip6.arpa
! >
! > You'll need to fix these zones so that the response is NOERROR rather than 
NXDOMAIN.

And they seem to think, there is nothing wrong with that, because
nobody ever has complained about that.


Now I am really wondering: why do I, an unemployed old guy just
running his own computer, suddenly find myself in between a root
operator and the biggest v6 network on the planet?

In other words: why do You guys no longer talk to each other?


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

Re: SERVFAIL error during the evening

[Michael Batchelder]

> 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. You will need 
to look at your infrastructure and beyond to determine why you are not getting 
responses to your queries.

One possibility may be in your infrastructure/network, where a firewall or 
other stateful inspection device is running out of resources to make additional 
state table entries. You will need to speak with the technical support of that 
device's vendor if you need help in assessing this.

Michael
-- 
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 :(

[Stephane Bortzmeyer]

On Fri, Jun 21, 2024 at 07:03:14AM +,
65;6800;1c Michael Batchelder  wrote 
 a message of 59 lines which said:

> You'll need to fix these zones so that the response is NOERROR rather than 
> NXDOMAIN.

Yes and, if you want the whole context, you can read RFC 8020
 and section 4 of RFC 7816
.

-- 
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: Debian download source on ISC website

[Ondřej Surý]

The authoritative source is bind.debian.net that can be redirected. But the 
primary reason is that I already have the infrastructure ready and I also 
maintain BIND 9 packages directly in Debian, so the contents mirror what ends 
up in Debian.

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 21. 6. 2024, at 16:05, Dominic Preston  wrote:
> 
> On Wed, 19 Jun 2024 at 14:19, Ondřej Surý  wrote:
>> 
>> If by production-ready you mean it’s reasonably well-tested, we are using it 
>> ourselves and it also matches what’s being uploaded to Debian directly then 
>> yes.
>> 
>> If you mean there will be no bugs and it will magically work until the end 
>> of times without any effort then you might be disappointed.
> 
> Thank you for your reply. Out of interest, what is the reasoning
> behind hosting the binaries on your sury.org domain as opposed to the
> isc.org domain? If (heaven forbid) something should happen to you,
> wouldn't hosting on the isc.org domain more easily facilitate the
> possibility of redirecting the package hosting without users having to
> reconfigure their sources?
> --
> 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: Debian download source on ISC website

[Dominic Preston]

On Fri, 21 Jun 2024 at 15:13, Ondřej Surý  wrote:
>
> The authoritative source is bind.debian.net that can be redirected. But the 
> primary reason is that I already have the infrastructure ready and I also 
> maintain BIND 9 packages directly in Debian, so the contents mirror what ends 
> up in Debian.

Understood, thanks for the clarification.

Regards,
Dominic.
-- 
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: Debian download source on ISC website

[Dominic Preston]

On Wed, 19 Jun 2024 at 14:19, Ondřej Surý  wrote:
>
> If by production-ready you mean it’s reasonably well-tested, we are using it 
> ourselves and it also matches what’s being uploaded to Debian directly then 
> yes.
>
> If you mean there will be no bugs and it will magically work until the end of 
> times without any effort then you might be disappointed.

Thank you for your reply. Out of interest, what is the reasoning
behind hosting the binaries on your sury.org domain as opposed to the
isc.org domain? If (heaven forbid) something should happen to you,
wouldn't hosting on the isc.org domain more easily facilitate the
possibility of redirecting the package hosting without users having to
reconfigure their sources?
-- 
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 Fri, Jun 21, 2024 at 07:03:14AM +, Michael Batchelder wrote:
! > Yes, sure. I grabbed three typical cases to analyze further, and
! > currently trying to understand the proceedings - unsuccessfully, up
! > to now. :(
! >
! > Case 1:
! > ---
! > Jun 19 17:42:12  conr named[24481]: lame-servers:
! >info: success resolving '26.191.165.185.in-addr.arpa/PTR'
! >after disabling qname minimization due to 'ncache nxdomain'
! > 
! > This one does not point back to me, but nevertheless I do not
! > see the lame server.
! > 
! > Case 2:
! > ---
! > Jun 19 18:02:44  conr named[24481]: lame-servers:
! >info: success resolving 'reactivite.fr.intra.daemon.contact/'
! >after disabling qname minimization due to 'ncache nxdomain'
! > 
! > Here, for whatever reason, the client was not happy with the official
! > answer on "reactivite.fr", and tried to append the search domain for
! > internal hosts on my LAN.
! > So this does absolutely point to me, only. The recursing LAN server
! > asks the authoritative LAN server (same image, different view), and>
! > that one basically says, this is bogus.
! > 
! > Case 3:
! > ---
! > Jun 19 18:28:48  conr named[24481]: lame-servers:
! >info: success resolving
! >
'1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.1.0.0.3.2.f.1.0.7.4.0.1.0.0.2.ip6.arpa/PTR'
! >after disabling qname minimization due to 'ncache nxdomain'
! 
! Peter,
! 
! Case 1:
! 
! The 191.165.185.in-addr.arpa zone (@200.3.13.14) responds with NXDOMAIN to 
queries for any QTYPE for QNAME 191.165.185.in-addr.arpa.
! 
! Case 2:
! 
! The intra.daemon.contact zone (@195.154.230.217) responds with NXDOMAIN to 
queries for any QTYPE of QNAME intra.daemon.contact.
! 
! Case 3:
! 
! The f.1.0.7.4.0.1.0.0.2.ip6.arpa zone (@216.66.80.18) responds with NXDOMAIN 
to queries for any QTYPE for QNAME f.1.0.7.4.0.1.0.0.2.ip6.arpa
! 
! You'll need to fix these zones so that the response is NOERROR rather than 
NXDOMAIN.
! 
! b.

Hi Michael,

   thank You very much for looking at this. Now I can see the problem.

Case 3 is indeed an interesting matter:

  7.4.0.1.0.0.2.ip6.arpa -> NOERROR  (ARIN)
0.7.4.0.1.0.0.2.ip6.arpa -> NOERROR  (HE)
  1.0.7.4.0.1.0.0.2.ip6.arpa -> NOERROR
f.1.0.7.4.0.1.0.0.2.ip6.arpa -> NXDOMAIN
  1.f.1.0.7.4.0.1.0.0.2.ip6.arpa -> NXDOMAIN
3.1.f.1.0.7.4.0.1.0.0.2.ip6.arpa -> NOERROR
  0.3.1.f.1.0.7.4.0.1.0.0.2.ip6.arpa -> NXDOMAIN
0.0.3.1.f.1.0.7.4.0.1.0.0.2.ip6.arpa -> NXDOMAIN
  c.0.0.3.1.f.1.0.7.4.0.1.0.0.2.ip6.arpa -> NXDOMAIN
2.c.0.0.3.1.f.1.0.7.4.0.1.0.0.2.ip6.arpa -> NOERROR  (myself)

AFAIK, HE does serve more than only a few IPv6. It's strange that
nobody has worried about this, yet. 


And Case 2 is my own venture into splitting the horizon:
I indeed want /You/ to see NXDOMAIN for intra.daemon.contact when
asking the SOA of daemon.contact

But my internal servers have this:

zone "daemon.contact" {
type static-stub;
server-addresses { fdff::2; } ;
};
zone "intra.daemon.contact" {
type static-stub;
server-addresses { fdff::2; } ;
};

and should get:
$ host -t SOA daemon.contact fdff::2
daemon.contact has SOA record myhost.intra.daemon.contact ...
$ host -t SOA intra.daemon.contact fdff::2
intra.daemon.contact has SOA record myhost.intra.daemon.contact ...

According to the manual:
   "static-stub: ... when recursion is necessary for a query that
   matches a static-stub zone, the locally configured data (name
   server names and glue addresses) is always used, even if
   different authoritative information is cached"

It seems I have to analyze why that doesn't work as inteded in
this case.

Thank You for figuring it out!

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

Re: qname minimization: me too :(

[Michael Batchelder]

> Yes, sure. I grabbed three typical cases to analyze further, and
> currently trying to understand the proceedings - unsuccessfully, up
> to now. :(
>
> Case 1:
> ---
> Jun 19 17:42:12  conr named[24481]: lame-servers:
>info: success resolving '26.191.165.185.in-addr.arpa/PTR'
>after disabling qname minimization due to 'ncache nxdomain'
> 
> This one does not point back to me, but nevertheless I do not
> see the lame server.
> 
> Case 2:
> ---
> Jun 19 18:02:44  conr named[24481]: lame-servers:
>info: success resolving 'reactivite.fr.intra.daemon.contact/'
>after disabling qname minimization due to 'ncache nxdomain'
> 
> Here, for whatever reason, the client was not happy with the official
> answer on "reactivite.fr", and tried to append the search domain for
> internal hosts on my LAN.
> So this does absolutely point to me, only. The recursing LAN server
> asks the authoritative LAN server (same image, different view), and>
> that one basically says, this is bogus.
> 
> Case 3:
> ---
> Jun 19 18:28:48  conr named[24481]: lame-servers:
>info: success resolving
>
> '1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.1.0.0.3.2.f.1.0.7.4.0.1.0.0.2.ip6.arpa/PTR'
>after disabling qname minimization due to 'ncache nxdomain'

Peter,

Case 1:

The 191.165.185.in-addr.arpa zone (@200.3.13.14) responds with NXDOMAIN to 
queries for any QTYPE for QNAME 191.165.185.in-addr.arpa.

Case 2:

The intra.daemon.contact zone (@195.154.230.217) responds with NXDOMAIN to 
queries for any QTYPE of QNAME intra.daemon.contact.

Case 3:

The f.1.0.7.4.0.1.0.0.2.ip6.arpa zone (@216.66.80.18) responds with NXDOMAIN to 
queries for any QTYPE for QNAME f.1.0.7.4.0.1.0.0.2.ip6.arpa

You'll need to fix these zones so that the response is NOERROR rather than 
NXDOMAIN.

b.
-- 
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: can I provide invalid HTTPS values for testing?

[Stephen Farrell]

Hiya,

On 20/06/2024 14:34, Ondřej Surý wrote:

Stephen,

you actually gave me an idea - you should use BIND version without HTTPS record
support and just convert the records to TYPExxx form. That way, there will be no
parser standing in your way and you can put all kind of rubbish to the zone.


Yep, there are likely some tests where I'll want to do that,
or similar, but I'm good for a while at least with cases
where the badness is mostly within the base64 encoding of
the ECHConfigList, which bind seems ok with.


P.S.: Why am I even helping you when the eduroam at TCD didn’t work for me last
week ;))).


I can only apologise for our eduroam setup (again, I've had
to do it before;-), but happy to supply an apologetic beverage
next time we meet.

Cheers,
S.


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 
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: can I provide invalid HTTPS values for testing?

[Ondřej Surý]

Stephen,

you actually gave me an idea - you should use BIND version without HTTPS record 
support and just convert the records to TYPExxx form. That way, there will be 
no parser standing in your way and you can put all kind of rubbish to the zone.

P.S.: Why am I even helping you when the eduroam at TCD didn’t work for me last 
week ;))).

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

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

> On 20. 6. 2024, at 15:29, Stephen Farrell  wrote:
> 
> 
> Hi again,
> 
> Actually, it may well be that bind allows me sufficient
> leeway to do most of the tests I want, so this is just
> to check that there's no imminent plan to have bind
> disallow the kind of rubbish HTTPS RRs below. If that's
> not likely to change in the next few months, then I'd
> say I'm fine. (With apologies for the noise;-)
> 
> Thanks,
> S.
> 
> $ dig +short https dodgy.test.defo.ie
> 1 . alpn="\"" ipv4hint=10.0.0.1 ech=Cg==
> 1 . ech=AAA=
> 1 . 
> ech=ADn+DQA128zMACBZkH1hkFTJB6Hyls62Pd4dV/cvFdsXJgGi9rVeZufNDwAEAAEAAQAGYmFyLmllAAA=
> 1 . alpn="\"" ipv4hint=10.0.0.1 ech
> 1 . alpn="\"" ipv4hint=10.0.0.0 ech=Cg==


OpenPGP_0xE4D8E9F997A833DD.asc
Description: Binary data
> --
> 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: can I provide invalid HTTPS values for testing?

[Stephen Farrell]

Hi again,

Actually, it may well be that bind allows me sufficient
leeway to do most of the tests I want, so this is just
to check that there's no imminent plan to have bind
disallow the kind of rubbish HTTPS RRs below. If that's
not likely to change in the next few months, then I'd
say I'm fine. (With apologies for the noise;-)

Thanks,
S.

$ dig +short https dodgy.test.defo.ie
1 . alpn="\"" ipv4hint=10.0.0.1 ech=Cg==
1 . ech=AAA=
1 . 
ech=ADn+DQA128zMACBZkH1hkFTJB6Hyls62Pd4dV/cvFdsXJgGi9rVeZufNDwAEAAEAAQAGYmFyLmllAAA=

1 . alpn="\"" ipv4hint=10.0.0.1 ech
1 . alpn="\"" ipv4hint=10.0.0.0 ech=Cg==


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 
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: can I provide invalid HTTPS values for testing?

[Stephen Farrell]

Hiya,

Thanks all for the info/suggestions. I guess I'll have
to try what Ondřej suggests or something similar, and
that's ok.

Cheers,
S.


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 
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: can I provide invalid HTTPS values for testing?

[Mark Andrews]

> On 20 Jun 2024, at 15:29, Michael Richardson  wrote:
> 
> 
> Mark Andrews  wrote:
>> Named and nsupdate validate input for types they know about (both text
>> and wire). You would have to use versions that are not HTTPS aware and
>> use unknown type format.
> 
> So, he could code it in Perl or Python or something which had a dynamic DNS
> library.  Bind itself wouldn't validate the "ascii-hex" part when it receives
> it.

Named will reject HTTPS records that it can determine are invalid.  This 
includes
in UPDATE requests.  The server will return FORMERR to the dynamic update 
client.

See lib/dns/rdata/in_1/svcb_64.c for all the checks performed.

-- 
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: can I provide invalid HTTPS values for testing?

[Michael Richardson]

Mark Andrews  wrote:
> Named and nsupdate validate input for types they know about (both text
> and wire). You would have to use versions that are not HTTPS aware and
> use unknown type format.

So, he could code it in Perl or Python or something which had a dynamic DNS
library.  Bind itself wouldn't validate the "ascii-hex" part when it receives
it.



signature.asc
Description: PGP signature
-- 
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: can I provide invalid HTTPS values for testing?

[Ondřej Surý]

Stephen,

I would suggest to write a specialized DNS server using dnspython rather than 
trying to cram the crap into existing DNS servers.

Then it should be possible to use something like this: 
https://hypothesis.readthedocs.io/en/latest/ to generate the test cases 
automatically.

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

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

> On 20. 6. 2024, at 3:40, Stephen Farrell  wrote:
> 
> 
> Hiya,
> 
> Apologies if this is a repeat, I spent a bit of time looking
> but didn't find stuff...
> 
> I'd like to publish various HTTPS RRs with dodgy encodings
> in order to test which clients handle things well or badly.
> 
> Were it possible to use nsupdate for that, that'd make my
> life simpler, but I've not found a way to do that so far.
> 
> What I'd like to be able to do in nsupdate would be like:
> 
>  update add example.com 300 HTTPS 
> 
> Where the ascii-hex value is some (broken) variant of what
> I'd get from:
> 
>  dig +unknownformat https example.com
> 
> Is there a way to do that?
> 
> Thanks in advance,
> Stephen.
> 
> 
> --
> 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: can I provide invalid HTTPS values for testing?

[Mark Andrews]

Named and nsupdate validate input for types they know about (both text
and wire). You would have to use versions that are not HTTPS aware and
use unknown type format.

Mark

> On 20 Jun 2024, at 11:39, Stephen Farrell  wrote:
> 
> 
> Hiya,
> 
> Apologies if this is a repeat, I spent a bit of time looking
> but didn't find stuff...
> 
> I'd like to publish various HTTPS RRs with dodgy encodings
> in order to test which clients handle things well or badly.
> 
> Were it possible to use nsupdate for that, that'd make my
> life simpler, but I've not found a way to do that so far.
> 
> What I'd like to be able to do in nsupdate would be like:
> 
>  update add example.com 300 HTTPS 
> 
> Where the ascii-hex value is some (broken) variant of what
> I'd get from:
> 
>  dig +unknownformat https example.com
> 
> Is there a way to do that?
> 
> Thanks in advance,
> Stephen.
> 
> -- 
> 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

can I provide invalid HTTPS values for testing?

[Stephen Farrell]

Hiya,

Apologies if this is a repeat, I spent a bit of time looking
but didn't find stuff...

I'd like to publish various HTTPS RRs with dodgy encodings
in order to test which clients handle things well or badly.

Were it possible to use nsupdate for that, that'd make my
life simpler, but I've not found a way to do that so far.

What I'd like to be able to do in nsupdate would be like:

  update add example.com 300 HTTPS 

Where the ascii-hex value is some (broken) variant of what
I'd get from:

  dig +unknownformat https example.com

Is there a way to do that?

Thanks in advance,
Stephen.



OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 
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 Wed, Jun 19, 2024 at 10:33:41PM +0200, Stephane Bortzmeyer wrote:
! On Wed, Jun 19, 2024 at 10:15:48PM +0200,
!  Peter  wrote 
!  a message of 32 lines which said:
! 
! >   today I happened to look into a named.log, and found it full of
! > qname minimization messages.
! 
! Which message? Could you copy-and-paste it?

Yes, sure. I grabbed three typical cases to analyze further, and
currently trying to understand the proceedings - unsuccessfully, up
to now. :(

Case 1:
---
Jun 19 17:42:12  conr named[24481]: lame-servers:
   info: success resolving '26.191.165.185.in-addr.arpa/PTR'
   after disabling qname minimization due to 'ncache nxdomain'

This one does not point back to me, but nevertheless I do not
see the lame server.

Case 2:
---
Jun 19 18:02:44  conr named[24481]: lame-servers:
   info: success resolving 'reactivite.fr.intra.daemon.contact/'
   after disabling qname minimization due to 'ncache nxdomain'

Here, for whatever reason, the client was not happy with the official
answer on "reactivite.fr", and tried to append the search domain for
internal hosts on my LAN.
So this does absolutely point to me, only. The recursing LAN server
asks the authoritative LAN server (same image, different view), and
that one basically says, this is bogus.

Case 3:
---
Jun 19 18:28:48  conr named[24481]: lame-servers:
   info: success resolving
   
'1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.1.0.0.3.2.f.1.0.7.4.0.1.0.0.2.ip6.arpa/PTR'
   after disabling qname minimization due to 'ncache nxdomain'

This one does also point back to me (kind of), because HE does
delegate the rDNS zones (I love them), only they do not do DNSSEC
in the rDNS. It correctly ends up at my autoritative public servers
and gets resolved.


I'm currently extracting the exact proceedings from dnstap - but I
don't get much enlighenment from them.
-- 
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 :(

[Stephane Bortzmeyer]

On Wed, Jun 19, 2024 at 10:15:48PM +0200,
 Peter  wrote 
 a message of 32 lines which said:

>   today I happened to look into a named.log, and found it full of
> qname minimization messages.

Which message? Could you copy-and-paste 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

qname minimization: me too :(

[Peter]

Hi all,
  today I happened to look into a named.log, and found it full of
qname minimization messages.
Now as far as I understand, the saying goes that this is a problem
of misconfigured upstream nameservers and we cannot do much about
it.

But, what if these "misconfigured upstream servers" happen do be
some of my own? What do I do then?

Because I've seen through the proceedings, and I do not yet see
the error.

cheerio,
Peter
-- 
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: Debian download source on ISC website

[Ondřej Surý]

If by production-ready you mean it’s reasonably well-tested, we are using it 
ourselves and it also matches what’s being uploaded to Debian directly then yes.

If you mean there will be no bugs and it will magically work until the end of 
times without any effort then you might be disappointed.

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 19. 6. 2024, at 9:19, Dominic Preston  wrote:
> 
> Hello,
> 
> When browsing for Debian download sources on
> https://www.isc.org/download/ , there is a link to
> https://bind.debian.net/bind
> 
> When clicking on https://bind.debian.net/bind I am redirected to
> https://packages.sury.org/bind/
> 
> Since it is listed on https://www.isc.org/download/ , can I assume
> packages.sury.org is an official ISC download source suitable for
> production deployment?
> 
> Regards,
> Dominic.
> --
> 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

Debian download source on ISC website

[Dominic Preston]

Hello,

When browsing for Debian download sources on
https://www.isc.org/download/ , there is a link to
https://bind.debian.net/bind

When clicking on https://bind.debian.net/bind I am redirected to
https://packages.sury.org/bind/

Since it is listed on https://www.isc.org/download/ , can I assume
packages.sury.org is an official ISC download source suitable for
production deployment?

Regards,
Dominic.
-- 
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