qname minimization: me too :(

[Peter]

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