static stub zone not working as expected

Jay Ford jnford at uiowa.net
Sat Jul 13 15:18:33 UTC 2019


I'm still confused about why named looks further up the tree than
c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa which it holds authoritatively via
master/slave zone type.  That seems like incorrect behavior.

Is this something I can fix or work around?

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

On Sat, 13 Jul 2019, Mark Andrews wrote:
> I suspect this will be negative response synthesis. The cache has learnt that d.f.ip6.arpa doesn’t exist in ip6.arpa and when the name in question is looked up the covering NSEC is returned which covers all of ULA space.
>
> If I’m right querying for DS d.f.ip6.arpa will load the cache appropriately to allow this to be triggered.  One then needs to trigger a lookup for a name which finds the covering NSEC in the search back through the cache.  Named skips some responses in the search depending on the content but aborts it on others content.
> -- 
> Mark Andrews
>
>> On 13 Jul 2019, at 00:42, Jay Ford <jnford at uiowa.net> wrote:
>>
>> 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


More information about the bind-users mailing list