static stub zone not working as expected
Mark Andrews
marka at isc.org
Sun Jul 14 21:31:08 UTC 2019
> On 14 Jul 2019, at 1:18 am, Jay Ford <jnford at uiowa.net> wrote:
>
> 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.
The cache doesn’t know about zones. The lookup just make a query of
the cache for the name and also asks for potential covering NSEC records
to be returned if it is not found. In this case it finds a covering NSEC
record.
0.c.2.ip6.arpa. 3012 IN NSEC ip6.arpa. NS DS RRSIG NSEC
d.f.ip6.arpa lies between 0.c.2.ip6.arpa and ip6.arpa. Now if there was
the requested break in the chain of trust existed that was requested to be
added in RFC 6303 it would find.
d.f.ip6.arpa. 3600 IN NSEC ip6.arpa. NS RRSIG NSEC
Which says d.f.ip6.arpa is a delegation point so I don’t know anything about
names ending in d.f.ip6.arpa but there are no names in ip6.arpa between
d.f.ip6.arpa and ip6.arpa. Named won’t synthesis negative responses for ULA
reverse names from that NSEC record.
> Is this something I can fix or work around?
You can turn off synthesis "synth-from-dnssec no;”
> __________________________________________________________________________
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the bind-users
mailing list