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
