static stub zone not working as expected

Jay Ford jnford at uiowa.net
Fri Jul 12 01:12:00 UTC 2019


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 <jnford at 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 at 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 at 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: marka at isc.org
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>



More information about the bind-users mailing list