See ticket [IANA #992665] from December 2017 for at least one previous request
to get this fixed.
Mark
> On 12 Jul 2019, at 12:13 pm, Mark Andrews <ma...@isc.org> wrote:
>
> IANA, why is there NOT a insecure delegation for D.F.IP6.ARPA as REQUIRED by
> RFC 6303?
>
> How many times does this need to be reported before it is FIXED! Yes, it has
> been reported
> before.
>
> It should take a total of less than 10 minutes to fix. Create a empty zone
> called
> D.F.IP6.ARPA (SOA and NS records only) on the servers for ip6.arpa. Add a
> delegation
> to D.F.IP6.ARPA to the IP6.ARPA zone for D.F.IP6.ARPA and re-sign.
>
> This should not take years to do.
>
> Add this to IP6.ARPA zone. It produces the requires insecure delegation.
>
> d.f.ip6.arpa. 3600 IN NS c.ip6-servers.arpa.
> d.f.ip6.arpa. 3600 IN NS b.ip6-servers.arpa.
> d.f.ip6.arpa. 3600 IN NS d.ip6-servers.arpa.
> d.f.ip6.arpa. 3600 IN NS a.ip6-servers.arpa.
> d.f.ip6.arpa. 3600 IN NS f.ip6-servers.arpa.
> d.f.ip6.arpa. 3600 IN NS e.ip6-servers.arpa.
>
> This is the complete contents of D.F.IP6.ARPA.
>
> d.f.ip6.arpa. 3600 IN SOA b.ip6-servers.arpa.
> nstld.iana.org. 2019071200 1800 900 604800 d.f.ip6.arpa. 3600
> IN NS c.ip6-servers.arpa.
> d.f.ip6.arpa. 3600 IN NS b.ip6-servers.arpa.
> d.f.ip6.arpa. 3600 IN NS d.ip6-servers.arpa.
> d.f.ip6.arpa. 3600 IN NS a.ip6-servers.arpa.
> d.f.ip6.arpa. 3600 IN NS f.ip6-servers.arpa.
> d.f.ip6.arpa. 3600 IN NS e.ip6-servers.arpa.
>
> NXDOMAIN is the WRONG response to any query for d.f.ip6.arpa on the public
> Internet. The
> response for D.F.IP6.ARPA should be similar to that for 10.IN-ADDR.ARPA, i.e.
> a NEC record
> that proves that there is a delegation without a DS record being present.
>
> 4.4. IPv6 Locally Assigned Local Addresses
>
> Section 4.4 of [RFC4193] already required special treatment of:
>
> +--------------+
> | Zone |
> +--------------+
> | D.F.IP6.ARPA |
> +--------------+
>
>
> 6. IANA Considerations
>
>
> IANA has established a registry of zones that require this default
> behaviour. The initial contents of this registry are defined in
> Section 4. Implementors are encouraged to periodically check this
> registry and adjust their implementations to reflect changes therein.
>
> This registry can be amended through "IETF Review" as per [RFC5226].
> As part of this review process, it should be noted that once a zone
> is added it is effectively added permanently; once an address range
> starts being configured as a local zone in systems on the Internet,
> it will be impossible to reverse those changes.
>
> IANA should coordinate with the RIRs to ensure that, as DNS Security
> (DNSSEC) is deployed in the reverse tree, delegations for these zones
> are made in the manner described in Section 7.
>
> 7. Security Considerations
>
>
> During the initial deployment phase, particularly where [RFC1918]
> addresses are in use, there may be some clients that unexpectedly
> receive a name error rather than a PTR record. This may cause some
> service disruption until their recursive nameserver(s) have been
> re-configured.
>
> As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
> namespaces, the zones listed above will need to be delegated as
> insecure delegations, or be within insecure zones. This will allow
> DNSSEC validation to succeed for queries in these spaces despite not
> being answered from the delegated servers.
>
> It is recommended that sites actively using these namespaces secure
> them using DNSSEC [RFC4035] by publishing and using DNSSEC trust
> anchors. This will protect the clients from accidental import of
> unsigned responses from the Internet.
>
> Mark
>
> [beetle:bin/tests/system] marka% dig ds d.f.ip6.arpa +dnssec
> ;; BADCOOKIE, retrying.
>
> ; <<>> DiG 9.15.1+hotspot+add-prefetch+marka <<>> ds d.f.ip6.arpa +dnssec
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14025
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ; COOKIE: 2294c99d5f3d1f0f2fb618b85d27e819d11327fa7b6fd1ed (good)
> ;; QUESTION SECTION:
> ;d.f.ip6.arpa. IN DS
>
> ;; AUTHORITY SECTION:
> ip6.arpa. 3012 IN SOA b.ip6-servers.arpa.
> nstld.iana.org. 2019024486 1800 900 604800 3600
> ip6.arpa. 3012 IN RRSIG SOA 8 2 3600 20190802071617
> 20190712000003 58119 ip6.arpa.
> NuIfqgE/u/UiZeIt4Gkhdtgq+ompfC7Q16WZ2jTFhfi8KJz7aBKK+6FO
> QyadI9l0J89bg6Q42hvA5FGxedRNAAqw513cCRNUzBRse5JZGGl238gy
> V1SO1gsmmPNuPVBsyDnyx0C0F0hO6iH73FoClwUU3fCSjGvkOLItmpg5 gJA=
> ip6.arpa. 3012 IN NSEC 5.0.0.0.1.0.0.2.ip6.arpa. NS
> SOA RRSIG NSEC DNSKEY
> ip6.arpa. 3012 IN RRSIG NSEC 8 2 3600 20190718212414
> 20190627090003 58119 ip6.arpa.
> OmSDuGAU5c5q568TYagYaOlQg/kPYPzPRCi3pI5POcL/CDE0LYjfQW3c
> K/5JFLOuPDDKJNL+UC2ASyE0iMAFkKjRkI5aSOvqA17aCvaJQ28/HlWu
> WYz25MF9lICAZcWhRT+x2OoShRxtvB1trv28egmphX3tGCk1EKBCyIH8 9+Q=
> 0.c.2.ip6.arpa. 3012 IN NSEC ip6.arpa. NS DS RRSIG
> NSEC
> 0.c.2.ip6.arpa. 3012 IN RRSIG NSEC 8 5 3600
> 20190801203149 20190711100004 58119 ip6.arpa.
> pcIPmYJhhoE+AngywDz2WASmw7iP5j5zKEDCeTMxSxkkBSWQO0tnUyVK
> +HM4rvOFaGZvPlyIulDyh/ewfZBxEGjN4VqKaHHvdg1s7jckLxH2FsBL
> 1aVum7KK6nvBS82OOkWaGqNDful1u+iDGvMRerp19yb61aQRJBaLMKtd qBk=
>
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Fri Jul 12 11:53:29 AEST 2019
> ;; MSG SIZE rcvd: 740
>
> [beetle:bin/tests/system] marka% dig ds 10.in-addr.arpa +dnssec
> ;; BADCOOKIE, retrying.
>
> ; <<>> DiG 9.15.1+hotspot+add-prefetch+marka <<>> ds 10.in-addr.arpa +dnssec
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12515
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ; COOKIE: 726200ffe7372cf84be4c2a05d27e82f3d61e28d25f4fc62 (good)
> ;; QUESTION SECTION:
> ;10.in-addr.arpa. IN DS
>
> ;; AUTHORITY SECTION:
> 10.in-addr.arpa. 3600 IN RRSIG NSEC 8 3 3600 20190722224148
> 20190701150002 16953 in-addr.arpa.
> s5djGXJHu+HV6JRPhJswAfYWJqBCxRMlEHGD6Gn2t/4pmaZCtEAC+3Bm
> IjnL16E9EE0sNWerDdNukyuL3Af9YM7q+cK7AuiqWidJMq5bWTsKbBbb
> WnpOOkyTUk4KdLzXkpew0GDqAmOuEqoDXeRH1Eoj4elr+KHGFGcJHOVf Gxg=
> 10.in-addr.arpa. 3600 IN NSEC 100.in-addr.arpa. NS RRSIG NSEC
> in-addr.arpa. 3600 IN SOA b.in-addr-servers.arpa.
> nstld.iana.org. 2019024485 1800 900 604800 3600
> in-addr.arpa. 3600 IN RRSIG SOA 8 2 3600 20190801154709
> 20190712000002 16953 in-addr.arpa.
> u5BiasRjzaU+ikZ7s9Wj7x8IzIM2wmZdPO1WlNQ3eetPG6CAjfxkNfhp
> hBJW3JxebAKaZA4wj4Jgat9aa1DAXiKv1l7t4xmuGhQ+yyHzs2fy8hmc
> EnN9qlybPTs1wJ2jMU0TfCXO3v9X4ZA27Aj3E4FuCqDNdrbT4mejeD6J RQs=
>
> ;; Query time: 1784 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Fri Jul 12 11:53:51 AEST 2019
> ;; MSG SIZE rcvd: 526
>
> [beetle:bin/tests/system] marka%
>
>
>
>> 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?
>>
>> __________________________________________________________________________
>> Jay Ford <jnf...@uiowa.net>, Network Engineering, University of Iowa
>>
>> On Fri, 12 Jul 2019, Mark Andrews wrote:
>>> Because static-stub only overrides “where” to find the information about
>>> the zone
>>> not whether the zone content is valid.
>>>
>>> With DNSSEC named will treat zone content as trusted (master/slave). Slave
>>> the top
>>> level internal zones. Note this doesn’t help any application that is also
>>> performing
>>> DNSSEC validation.
>>>
>>> Note .local is reserved for mDNS. getaddrinfo() shouldn’t be looking in the
>>> DNS for
>>> .local names.
>>>
>>> Mark
>>>
>>>> On 12 Jul 2019, at 7:25 am, btb via bind-users <bind-users@lists.isc.org>
>>>> wrote:
>>>>
>>>> hi-
>>>>
>>>> i have an environment which over time has managed to accumulate various
>>>> "internal" zones [in this specific case, "foo.local"]. eventually, these
>>>> zones will be phased out, but unfortunately in the interim, i'm stuck with
>>>> this. i'm attempting to configure them as static-stub zones:
>>>>
>>>> zone "foo.local" {
>>>> type static-stub;
>>>> server-addresses {
>>>> 192.168.220.20;
>>>> 192.168.220.21;
>>>> };
>>>> };
>>>>
>>>> however, queries are not working. following a cache flush, the initial
>>>> query is servfail and subsequent queries are nxdomain:
>>>>
>>>>> dig @localhost foo.local ns
>>>> ; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @localhost foo.local ns
>>>> ; (1 server found)
>>>> ;; global options: +cmd
>>>> ;; Got answer:
>>>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2550
>>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>>>>
>>>> ;; OPT PSEUDOSECTION:
>>>> ; EDNS: version: 0, flags:; udp: 4096
>>>> ;; QUESTION SECTION:
>>>> ;foo.local. IN NS
>>>>
>>>> ;; Query time: 181 msec
>>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>>> ;; WHEN: Thu Jul 11 16:11:02 EDT 2019
>>>> ;; MSG SIZE rcvd: 38
>>>>
>>>>> dig @localhost foo.local ns
>>>> ; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @localhost foo.local ns
>>>> ; (1 server found)
>>>> ;; global options: +cmd
>>>> ;; Got answer:
>>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43056
>>>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>>>>
>>>> ;; OPT PSEUDOSECTION:
>>>> ; EDNS: version: 0, flags:; udp: 4096
>>>> ;; QUESTION SECTION:
>>>> ;foo.local. IN NS
>>>>
>>>> ;; AUTHORITY SECTION:
>>>> . 10796 IN SOA a.root-servers.net.
>>>> nstld.verisign-grs.com. 2019071101 1800 900 604800 86400
>>>>
>>>> ;; Query time: 0 msec
>>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>>> ;; WHEN: Thu Jul 11 16:11:06 EDT 2019
>>>> ;; MSG SIZE rcvd: 113
>>>>
>>>> querying the auth nameservers directory is successful:
>>>>> dig @192.168.220.20 foo.local ns +norec
>>>>
>>>> ; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @192.168.220.20 foo.local ns +norec
>>>> ; (1 server found)
>>>> ;; global options: +cmd
>>>> ;; Got answer:
>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23
>>>> ;; flags: qr aa ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 5
>>>>
>>>> ;; OPT PSEUDOSECTION:
>>>> ; EDNS: version: 0, flags:; udp: 4000
>>>> ;; QUESTION SECTION:
>>>> ;foo.local. IN NS
>>>>
>>>> ;; ANSWER SECTION:
>>>> foo.local. 3600 IN NS 01.foo.local.
>>>> foo.local. 3600 IN NS 02.foo.local.
>>>> foo.local. 3600 IN NS a2.foo.local.
>>>> foo.local. 3600 IN NS a1.foo.local.
>>>>
>>>> ;; ADDITIONAL SECTION:
>>>> 01.foo.local. 3600 IN A 192.168.0.20
>>>> 02.foo.local. 3600 IN A 192.168.0.21
>>>> a2.foo.local. 3600 IN A 10.201.11.8
>>>> a1.foo.local. 1200 IN A 10.201.10.119
>>>>
>>>> ;; Query time: 82 msec
>>>> ;; SERVER: 192.168.220.20#53(192.168.220.20)
>>>> ;; WHEN: Thu Jul 11 16:35:39 EDT 2019
>>>> ;; MSG SIZE rcvd: 214
>>>>
>>>> additionally unfortunate, there is nat involved here, due to address space
>>>> collision, and while this obviously means the practical functionality of
>>>> this is questionable, i was expecting that with a static-stub zone, the
>>>> query itself would at least function.
>>>>
>>>> i see these messages in the logs:
>>>> 11-Jul-2019 16:08:51.406 lame-servers: info: error (insecurity proof
>>>> failed) resolving 'foo.local/NS/IN': 192.168.220.20#53
>>>> 11-Jul-2019 16:08:51.489 lame-servers: info: error (insecurity proof
>>>> failed) resolving 'foo.local/NS/IN': 192.168.220.21#53
>>>> 11-Jul-2019 17:08:44.111 lame-servers: info: error (no valid DS) resolving
>>>> 'foo.local/NS/IN': 192.168.220.21#53
>>>> 11-Jul-2019 17:08:44.194 lame-servers: info: error (broken trust chain)
>>>> resolving 'foo.local/NS/IN': 192.168.220.20#53
>>>>
>>>> i've not had much experience with dnssec yet, but it would seem that
>>>> perhaps it relates here in some capacity, as there is no public .local
>>>> domain, obviously? disabling dnssec [dnssec-enable no;] seems to support
>>>> this, as when doing so, queries work.
>>>>
>>>> that said, i'm wondering why this is happening - e.g. why bind seems to be
>>>> consulting public dns for this zone, if i've explicitly told bind where to
>>>> go to find this zone data, and how i might be able to troubleshoot
>>>> further, or what my options might be.
>>>>
>>>> lastly, this is currently an older version of bind [9.9.5, courtesy of
>>>> ubuntu packages]. it will be updated, but can't be just yet.
>>>>
>>>> thanks!
>>>> _______________________________________________
>>>> 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
>>>
>>> --
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
> _______________________________________________
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
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
