I have a similar problem with zones for IPv6 ULA space. I'm running BIND 9.14.3. I had hoped that validate-except would do the trick, such as:

   validate-except { "f.ip6.arpa"; };

but alas, no.

Extra puzzling so far is that the behavior is time-variable: delegated zones will resolve most of the time, but then fail (NXDOMAIN) for a while.

In the ULA space it doesn't seem trivial to own the top zone (ip6.arpa) without breaking stuff. Any suggestions for that case?

__________________________________________________________________________
Jay Ford <jnf...@uiowa.net>, Network Engineering, University of Iowa

On Fri, 12 Jul 2019, Mark Andrews wrote:
Because static-stub only overrides “where” to find the information about the 
zone
not whether the zone content is valid.

With DNSSEC named will treat zone content as trusted (master/slave).  Slave the 
top
level internal zones.  Note this doesn’t help any application that is also 
performing
DNSSEC validation.

Note .local is reserved for mDNS. getaddrinfo() shouldn’t be looking in the DNS 
for
.local names.

Mark

On 12 Jul 2019, at 7:25 am, btb via bind-users <bind-users@lists.isc.org> wrote:

hi-

i have an environment which over time has managed to accumulate various "internal" zones 
[in this specific case, "foo.local"].  eventually, these zones will be phased out, but 
unfortunately in the interim, i'm stuck with this.  i'm attempting to configure them as static-stub 
zones:

zone "foo.local" {
        type static-stub;
        server-addresses {
                192.168.220.20;
                192.168.220.21;
        };
};

however, queries are not working.  following a cache flush, the initial query 
is servfail and subsequent queries are nxdomain:

dig @localhost foo.local ns
; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @localhost foo.local ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2550
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;foo.local.                     IN      NS

;; Query time: 181 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 11 16:11:02 EDT 2019
;; MSG SIZE  rcvd: 38

dig @localhost foo.local ns
; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @localhost foo.local ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43056
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;foo.local.                     IN      NS

;; AUTHORITY SECTION:
.                       10796   IN      SOA     a.root-servers.net. 
nstld.verisign-grs.com. 2019071101 1800 900 604800 86400

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 11 16:11:06 EDT 2019
;; MSG SIZE  rcvd: 113

querying the auth nameservers directory is successful:
dig @192.168.220.20 foo.local ns +norec

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @192.168.220.20 foo.local ns +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23
;; flags: qr aa ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;foo.local.                     IN      NS

;; ANSWER SECTION:
foo.local.              3600    IN      NS      01.foo.local.
foo.local.              3600    IN      NS      02.foo.local.
foo.local.              3600    IN      NS      a2.foo.local.
foo.local.              3600    IN      NS      a1.foo.local.

;; ADDITIONAL SECTION:
01.foo.local. 3600      IN      A       192.168.0.20
02.foo.local. 3600      IN      A       192.168.0.21
a2.foo.local. 3600      IN      A       10.201.11.8
a1.foo.local. 1200      IN      A       10.201.10.119

;; Query time: 82 msec
;; SERVER: 192.168.220.20#53(192.168.220.20)
;; WHEN: Thu Jul 11 16:35:39 EDT 2019
;; MSG SIZE  rcvd: 214

additionally unfortunate, there is nat involved here, due to address space 
collision, and while this obviously means the practical functionality of this 
is questionable, i was expecting that with a static-stub zone, the query itself 
would at least function.

i see these messages in the logs:
11-Jul-2019 16:08:51.406 lame-servers: info: error (insecurity proof failed) 
resolving 'foo.local/NS/IN': 192.168.220.20#53
11-Jul-2019 16:08:51.489 lame-servers: info: error (insecurity proof failed) 
resolving 'foo.local/NS/IN': 192.168.220.21#53
11-Jul-2019 17:08:44.111 lame-servers: info: error (no valid DS) resolving 
'foo.local/NS/IN': 192.168.220.21#53
11-Jul-2019 17:08:44.194 lame-servers: info: error (broken trust chain) 
resolving 'foo.local/NS/IN': 192.168.220.20#53

i've not had much experience with dnssec yet, but it would seem that perhaps it 
relates here in some capacity, as there is no public .local domain, obviously?  
disabling dnssec [dnssec-enable no;] seems to support this, as when doing so, 
queries work.

that said, i'm wondering why this is happening - e.g. why bind seems to be 
consulting public dns for this zone, if i've explicitly told bind where to go 
to find this zone data, and how i might be able to troubleshoot further, or 
what my options might be.

lastly, this is currently an older version of bind [9.9.5, courtesy of ubuntu 
packages].  it will be updated, but can't be just yet.

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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: ma...@isc.org

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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to