Re: qname minimization: me too :(

2024-06-21 Thread 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

2024-06-21 Thread 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

2024-06-21 Thread 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

2024-06-21 Thread 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 :(

2024-06-21 Thread 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 :(

2024-06-21 Thread 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