static stub zone not working as expected
Mark Andrews
marka at isc.org
Fri Jul 12 03:41:25 UTC 2019
> On 12 Jul 2019, at 1:00 pm, Mark Andrews <marka at isc.org> wrote:
>
>
>
>> On 12 Jul 2019, at 11:12 am, Jay Ford <jnford at uiowa.net> wrote:
>>
>> I have a similar problem with zones for IPv6 ULA space. I'm running BIND 9.14.3. I had hoped that validate-except would do the trick, such as:
>>
>> validate-except { "f.ip6.arpa"; };
>>
>> but alas, no.
>>
>> Extra puzzling so far is that the behavior is time-variable: delegated zones will resolve most of the time, but then fail (NXDOMAIN) for a while.
>>
>> In the ULA space it doesn't seem trivial to own the top zone (ip6.arpa) without breaking stuff. Any suggestions for that case?
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 <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
>>>
>>
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the bind-users
mailing list