static stub zone not working as expected

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

static stub zone not working as expected

Bind-Users forum mailing list
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: static stub zone not working as expected

Mark Andrews
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 <[hidden email]> 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
> [hidden email]
> 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: [hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: static stub zone not working as expected

Jay Ford-2
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 <[hidden email]>, 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 <[hidden email]> 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
>> [hidden email]
>> 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: [hidden email]
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users
>

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: static stub zone not working as expected

Mark Andrews
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 <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]> 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
>>> [hidden email]
>>> 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: [hidden email]
>>
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>
>> bind-users mailing list
>> [hidden email]
>> 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: [hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: static stub zone not working as expected

Fred Morris
In reply to this post by Mark Andrews
Almost my point. It comes to my attention the hard way, that MDNS is
enabled by default or by accident in some Linux distros. Check
/etc/nsswitch.conf. Let us know what you find, and thanks a lot!

Longer answer: it depends on whether MDNS is in nsswitch, and what the
ordering is.

--

Fred Morris

On Fri, 12 Jul 2019, Mark Andrews wrote:
>
> Note .local is reserved for mDNS. getaddrinfo() shouldn’t be looking in the DNS for
> .local names.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: static stub zone not working as expected

Mark Andrews
In reply to this post by Jay Ford-2


> On 12 Jul 2019, at 1:00 pm, Mark Andrews <[hidden email]> wrote:
>
>
>
>> On 12 Jul 2019, at 11:12 am, Jay Ford <[hidden email]> 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

%


>> __________________________________________________________________________
>> Jay Ford <[hidden email]>, 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 <[hidden email]> 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
>>>> [hidden email]
>>>> 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: [hidden email]
>>>
>>> _______________________________________________
>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>>
>>> bind-users mailing list
>>> [hidden email]
>>> 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: [hidden email]
>

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: static stub zone not working as expected

Jay Ford-2
On Fri, 12 Jul 2019, Mark Andrews wrote:

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

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: static stub zone not working as expected

Mark Andrews
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 <[hidden email]> wrote:
>
> On Fri, 12 Jul 2019, Mark Andrews wrote:
>>> On 12 Jul 2019, at 1:00 pm, Mark Andrews <[hidden email]> wrote:
>>>
>>>> On 12 Jul 2019, at 11:12 am, Jay Ford <[hidden email]> 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 <[hidden email]>, Network Engineering, University of Iowa

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: static stub zone not working as expected

Mark Andrews
In reply to this post by Mark Andrews
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]> 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
>>>> [hidden email]
>>>> 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: [hidden email]
>>>
>>> _______________________________________________
>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>>
>>> bind-users mailing list
>>> [hidden email]
>>> 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: [hidden email]
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> [hidden email]
> 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: [hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: static stub zone not working as expected

Jay Ford-2
In reply to this post by Mark Andrews
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 <[hidden email]>, 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 <[hidden email]> wrote:
>>
>> On Fri, 12 Jul 2019, Mark Andrews wrote:
>>>> On 12 Jul 2019, at 1:00 pm, Mark Andrews <[hidden email]> wrote:
>>>>
>>>>> On 12 Jul 2019, at 11:12 am, Jay Ford <[hidden email]> 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 <[hidden email]>, Network Engineering, University of Iowa
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: static stub zone not working as expected

Mark Andrews


> On 14 Jul 2019, at 1:18 am, Jay Ford <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]> wrote:
>>>
>>> On Fri, 12 Jul 2019, Mark Andrews wrote:
>>>>> On 12 Jul 2019, at 1:00 pm, Mark Andrews <[hidden email]> wrote:
>>>>>
>>>>>> On 12 Jul 2019, at 11:12 am, Jay Ford <[hidden email]> 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 <[hidden email]>, Network Engineering, University of Iowa

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: [IANA #1147230] Re: static stub zone not working as expected

Mark Andrews
There is f.d.in-addr.arpa which is what this ticket is about and ipv4only.arpa which Stuart Cheshire is writing a update for and for which there is a seperate ticket.  Both are DNSSEC related.  Both cause operational problems. Both involve having unsigned zones for the relevant names.

For f.d.in-addr.arpa there are clear instructions to break the chain of trust.

For ipv4only.arpa you need to understand the RFC to know that ipv4only.arpa should be unsigned.  Stuart’s  draft just makes that clearer.  

Please don’t confuse the two issues.

Mark

> On 24 Jul 2019, at 10:24 pm, Michelle Cotton via RT <[hidden email]> wrote:
>
> Hello Mark,
>
> Thank you for your message.
>
> We are in discussion with IESG members on this matter.  When this was being discussed last year with IESG members, we were advised not to proceed at that time as there was a document that was going to be written to document the instructions.
> We are following up to see what the status is and will keep you informed.
>
> Thank you,
>
> Michelle Cotton
>
>
> On Sun Jul 14 21:31:52 2019, [hidden email] wrote:
>>
>>
>>> On 14 Jul 2019, at 1:18 am, Jay Ford <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]> wrote:
>>>>>
>>>>> On Fri, 12 Jul 2019, Mark Andrews wrote:
>>>>>>> On 12 Jul 2019, at 1:00 pm, Mark Andrews <[hidden email]> wrote:
>>>>>>>
>>>>>>>> On 12 Jul 2019, at 11:12 am, Jay Ford <[hidden email]> 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 <[hidden email]>, Network Engineering, University of
>>>>> Iowa
>

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: [IANA #1147230] Re: static stub zone not working as expected

Mark Andrews
I meant d.f.ip6.arpa rather than f.d.in-addr.arpa.

> On 24 Jul 2019, at 11:18 pm, Mark Andrews <[hidden email]> wrote:
>
> There is f.d.in-addr.arpa which is what this ticket is about and ipv4only.arpa which Stuart Cheshire is writing a update for and for which there is a seperate ticket.  Both are DNSSEC related.  Both cause operational problems. Both involve having unsigned zones for the relevant names.
>
> For f.d.in-addr.arpa there are clear instructions to break the chain of trust.
>
> For ipv4only.arpa you need to understand the RFC to know that ipv4only.arpa should be unsigned.  Stuart’s  draft just makes that clearer.  
>
> Please don’t confuse the two issues.
>
> Mark
>
>> On 24 Jul 2019, at 10:24 pm, Michelle Cotton via RT <[hidden email]> wrote:
>>
>> Hello Mark,
>>
>> Thank you for your message.
>>
>> We are in discussion with IESG members on this matter.  When this was being discussed last year with IESG members, we were advised not to proceed at that time as there was a document that was going to be written to document the instructions.
>> We are following up to see what the status is and will keep you informed.
>>
>> Thank you,
>>
>> Michelle Cotton
>>
>>
>> On Sun Jul 14 21:31:52 2019, [hidden email] wrote:
>>>
>>>
>>>> On 14 Jul 2019, at 1:18 am, Jay Ford <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]> wrote:
>>>>>>
>>>>>> On Fri, 12 Jul 2019, Mark Andrews wrote:
>>>>>>>> On 12 Jul 2019, at 1:00 pm, Mark Andrews <[hidden email]> wrote:
>>>>>>>>
>>>>>>>>> On 12 Jul 2019, at 11:12 am, Jay Ford <[hidden email]> 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 <[hidden email]>, Network Engineering, University of
>>>>>> Iowa
>>
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: [hidden email]
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> [hidden email]
> 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: [hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users