static stub zone not working as expected

[Jay Ford]

On Fri, 12 Jul 2019, Mark Andrews wrote:
>> On 12 Jul 2019, at 1:00 pm, Mark Andrews <marka at isc.org> wrote:
>>
>>> On 12 Jul 2019, at 11:12 am, Jay Ford <jnford at uiowa.net> wrote:
>>>
>>> I have a similar problem with zones for IPv6 ULA space.  I'm running BIND 9.14.3.  I had hoped that validate-except would do the trick, such as:
>>>
>>>   validate-except { "f.ip6.arpa"; };
>>>
>>> but alas, no.
>>>
>>> Extra puzzling so far is that the behavior is time-variable: delegated zones will resolve most of the time, but then fail (NXDOMAIN) for a while.
>>>
>>> In the ULA space it doesn't seem trivial to own the top zone (ip6.arpa) without breaking stuff.  Any suggestions for that case?
>
> ULA space it trivial to own.  D.F.IP6.ARPA is what you use if you have multiple ULA prefixes.
> If you have a single ULA prefix in use then just use that.  e.g. e.8.b.0.5.6.0.7.2.9.d.f.ip6.arpa
> which matches the ULA prefix used in the system tests (fd92:7065:b8e::/48).
>
> This is no different to using 10.in-addr.arpa, 168.192.in-addr.arpa or one of 16.172.in-addr.arpa
> though 31.172.in-addr.arpa for RFC 1918 space.
>
> If fc00::/8 is ever used then you would also have C.F.IP6.ARPA.
>
> Named creates the D.F.IP6.ARPA zone automatically if you don’t create it when the view is
> configured for recursion.  This is done to stop reverse lookups leaking onto the internet
> as a whole.
>
> % dig soa d.f.ip6.arpa
> ;; BADCOOKIE, retrying.
>
> ; <<>> DiG 9.15.1 <<>> soa d.f.ip6.arpa
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23519
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: aa8a24a1cce6c010b9d3a1b75d28009bb013cb0a2f58a961 (good)
> ;; QUESTION SECTION:
> ;d.f.ip6.arpa.			IN	SOA
>
> ;; ANSWER SECTION:
> D.F.IP6.ARPA.		86400	IN	SOA	D.F.IP6.ARPA. . 0 28800 7200 604800 86400
>
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Fri Jul 12 13:38:03 AEST 2019
> ;; MSG SIZE  rcvd: 116

Yep, that's what I thought.  I have master/slave for the zone corresponding
to my ULA /48 (c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa), which is solid including
zones under it also handled as master/slave, but not for zones which are
delegated via NS records to other servers (not master/slave), such as
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa which usually resolves like this:

    % dig -t ns d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-itf.uiowa.edu

    ; <<>> DiG 9.10.3-P4-Debian <<>> -t ns d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-itf.uiowa.edu
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23886
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. IN NS

    ;; ANSWER SECTION:
    d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc1.iowa.uiowa.edu.
    d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc4.iowa.uiowa.edu.
    d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc3.iowa.uiowa.edu.
    d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc5.iowa.uiowa.edu.
    d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc2.iowa.uiowa.edu.
    d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc6.iowa.uiowa.edu.

    ;; Query time: 2 msec
    ;; SERVER: fd9a:2c75:7d0c:5::e#53(fd9a:2c75:7d0c:5::e)
    ;; WHEN: Fri Jul 12 09:19:30 CDT 2019
    ;; MSG SIZE  rcvd: 215

but sometimes fails like this:

    % dig -t ns d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-cb.uiowa.edu

    ; <<>> DiG 9.10.3-P4-Debian <<>> -t ns d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-cb.uiowa.edu
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20175
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. IN NS

    ;; AUTHORITY SECTION:
    ip6.arpa.  3009  IN  SOA  b.ip6-servers.arpa. nstld.iana.org. 2019024499 1800 900 604800 3600

    ;; Query time: 0 msec
    ;; SERVER: fd9a:2c75:7d0c:5::a#53(fd9a:2c75:7d0c:5::a)
    ;; WHEN: Fri Jul 12 09:19:25 CDT 2019
    ;; MSG SIZE  rcvd: 145

Those 2 servers (& others) are configured identically regarding the zones in
question, but some of them sometimes fail this way despite being
authoritative for c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa.  An "rndc flushtree
ip6.arpa" will fix it for a while.

I do very similar stuff with zones for IPv4 RFC1918 space with no trouble.  I
had noticed the authenticated behavior for f.ip6.arpa differing from the
behavior for 10.in-addr.arpa & friends.  Thanks for poking at IANA about
that.  As I mentioned earlier, my use of validate-except { "f.ip6.arpa"; };
to work around that failed to help.  Can you explain why?

I might be hijacking this thread, but it seemed possible that my issue & that
of the original poster could have a common root cause.  I can start a
different thread on the list or pursue it as a BIND bug if you think that's
more appropriate.

__________________________________________________________________________
Jay Ford <jnford at uiowa.net>, Network Engineering, University of Iowa