On Fri, Jun 21, 2024 at 07:03:14AM +0000, 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 <local0.info> 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 <local0.info> conr named[24481]: lame-servers:
! > info: success resolving 'reactivite.fr.intra.daemon.contact/AAAA'
! > 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 <local0.info> 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
