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 <jnf...@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 <jnf...@uiowa.net> wrote:
On Fri, 12 Jul 2019, Mark Andrews wrote:
On 12 Jul 2019, at 1:00 pm, Mark Andrews <ma...@isc.org> wrote:
On 12 Jul 2019, at 11:12 am, Jay Ford <jnf...@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 <jnf...@uiowa.net>, Network Engineering, University of Iowa
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
