Re: [IANA #1147230] Re: static stub zone not working as expected
I meant d.f.ip6.arpa rather than f.d.in-addr.arpa.
> On 24 Jul 2019, at 11:18 pm, Mark Andrews 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
>> 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, ma...@isc.org wrote:
>>>
>>>
On 14 Jul 2019, at 1:18 am, Jay Ford 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. 3012IN NSECip6.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. 3600IN NSECip6.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 , 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 wrote:
>>
>> On Fri, 12 Jul 2019, Mark Andrews wrote:
On 12 Jul 2019, at 1:00 pm, Mark Andrews wrote:
> On 12 Jul 2019, at 11:12 am, Jay Ford 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
Re: [IANA #1147230] Re: static stub zone not working as expected
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
> 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, ma...@isc.org wrote:
>>
>>
>>> On 14 Jul 2019, at 1:18 am, Jay Ford 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. 3012IN NSECip6.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. 3600IN NSECip6.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 , 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 wrote:
>
> On Fri, 12 Jul 2019, Mark Andrews wrote:
>>> On 12 Jul 2019, at 1:00 pm, Mark Andrews wrote:
>>>
On 12 Jul 2019, at 11:12 am, Jay Ford 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
Re: static stub zone not working as expected
> On 14 Jul 2019, at 1:18 am, Jay Ford 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. 3012IN NSECip6.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. 3600IN NSECip6.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 , 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 wrote:
>>>
>>> On Fri, 12 Jul 2019, Mark Andrews wrote:
> On 12 Jul 2019, at 1:00 pm, Mark Andrews wrote:
>
>> On 12 Jul 2019, at 11:12 am, Jay Ford 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.INSOA
;; ANSWER SECTION:
D.F.IP6.ARPA.86400INSOAD.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
Re: static stub zone not working as expected
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 , 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 wrote:
On Fri, 12 Jul 2019, Mark Andrews wrote:
On 12 Jul 2019, at 1:00 pm, Mark Andrews wrote:
On 12 Jul 2019, at 11:12 am, Jay Ford 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.INSOA
;; ANSWER SECTION:
D.F.IP6.ARPA.86400INSOAD.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:
Re: static stub zone not working as expected
;>> "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. 3600IN NS 01.foo.local.
>>>> foo.local. 3600IN NS 02.foo.local.
>>>> foo.local. 3600IN NS a2.foo.local.
>>>> foo.local. 3600IN 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 (inse
Re: static stub zone not working as expected
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 wrote:
>
> On Fri, 12 Jul 2019, Mark Andrews wrote:
>>> On 12 Jul 2019, at 1:00 pm, Mark Andrews wrote:
>>>
On 12 Jul 2019, at 11:12 am, Jay Ford 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.INSOA
>>
>> ;; ANSWER SECTION:
>> D.F.IP6.ARPA.86400INSOAD.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.
Re: static stub zone not working as expected
On Fri, 12 Jul 2019, Mark Andrews wrote:
On 12 Jul 2019, at 1:00 pm, Mark Andrews wrote:
On 12 Jul 2019, at 11:12 am, Jay Ford 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 &
Re: static stub zone not working as expected
s >>>> ; (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. 3600IN NS 01.foo.local. >>>> foo.local. 3600IN NS 02.foo.local. >>>> foo.local. 3600IN NS a2.foo.local. >>>> foo.local. 3600IN NS a1.foo.local. >>>> >>>> ;; ADDITIONAL SECTION: >>>> 01.foo.local. 3600 IN A 192.168.0.20 >>>> 02.foo.local. 3600 IN A 192.168.0.21 >>>> a2.foo.local. 3600 IN A 10.201.11.8 >>>> a1.foo.local. 1200 IN A 10.201.10.119 >>>> >>>> ;; Query time: 82 msec >>>> ;; SERVER: 192.168.220.20#53(192.168.220.20) >>>> ;; WHEN: Thu Jul 11 16:35:39 EDT 2019 >>>> ;; MSG SIZE rcvd: 214 >>>> >>>> additionally unfortunate, there is nat involved here, due to address space >>>> collision, and while this obviously means the practical functionality of >>>> this is questionable, i was expecting that with a static-stub zone, the >>>> query itself would at least function. >>>> >>>> i see these messages in the logs: >>>> 11-Jul-2019 16:08:51.406 lame-servers: info: error (insecurity proof >>>> failed) resolving 'foo.local/NS/IN': 192.168.220.20#53 >>>> 11-Jul-2019 16:08:51.489 lame-servers: info: error (insecurity proof >>>> failed) resolving 'foo.local/NS/IN': 192.168.220.21#53 >>>> 11-Jul-2019 17:08:44.111 lame-servers: info: error (no valid DS) resolving >>>> 'foo.local/NS/IN': 192.168.220.21#53 >>>> 11-Jul-2019 17:08:44.194 lame-servers: info: error (broken trust chain) >>>> resolving 'foo.local/NS/IN': 192.168.220.20#53 >>>> >>>> i've not had much experience with dnssec yet, but it would seem that >>>> perhaps it relates here in some capacity, as there is no public .local >>>> domain, obviously? disabling dnssec [dnssec-enable no;] seems to support >>>> this, as when doing so, queries work. >>>> >>>> that said, i'm wondering why this is happening - e.g. why bind seems to be >>>> consulting public dns for this zone, if i've explicitly told bind where to >>>> go to find this zone data, and how i might be able to troubleshoot >>>> further, or what my options might be. >>>> >>>> lastly, this is currently an older version of bind [9.9.5, courtesy of >>>> ubuntu packages]. it will be updated, but can't be just yet. >>>> >>>> thanks! >>>> ___ >>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >>>> unsubscribe from this list >>>> >>>> bind-users mailing list >>>> bind-users@lists.isc.org >>>> https://lists.isc.org/mailman/listinfo/bind-users >>> >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >>> >>> ___ >>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >>> unsubscribe from this list >>> >>> bind-users mailing list >>> bind-users@lists.isc.org >>> https://lists.isc.org/mailman/listinfo/bind-users >>> >> > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > -- 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
Re: static stub zone not working as expected
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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: static stub zone not working as expected
ON: >>> ; 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. 3600IN NS 01.foo.local. >>> foo.local. 3600IN NS 02.foo.local. >>> foo.local. 3600IN NS a2.foo.local. >>> foo.local. 3600IN NS a1.foo.local. >>> >>> ;; ADDITIONAL SECTION: >>> 01.foo.local. 3600 IN A 192.168.0.20 >>> 02.foo.local. 3600 IN A 192.168.0.21 >>> a2.foo.local. 3600 IN A 10.201.11.8 >>> a1.foo.local. 1200 IN A 10.201.10.119 >>> >>> ;; Query time: 82 msec >>> ;; SERVER: 192.168.220.20#53(192.168.220.20) >>> ;; WHEN: Thu Jul 11 16:35:39 EDT 2019 >>> ;; MSG SIZE rcvd: 214 >>> >>> additionally unfortunate, there is nat involved here, due to address space >>> collision, and while this obviously means the practical functionality of >>> this is questionable, i was expecting that with a static-stub zone, the >>> query itself would at least function. >>> >>> i see these messages in the logs: >>> 11-Jul-2019 16:08:51.406 lame-servers: info: error (insecurity proof >>> failed) resolving 'foo.local/NS/IN': 192.168.220.20#53 >>> 11-Jul-2019 16:08:51.489 lame-servers: info: error (insecurity proof >>> failed) resolving 'foo.local/NS/IN': 192.168.220.21#53 >>> 11-Jul-2019 17:08:44.111 lame-servers: info: error (no valid DS) resolving >>> 'foo.local/NS/IN': 192.168.220.21#53 >>> 11-Jul-2019 17:08:44.194 lame-servers: info: error (broken trust chain) >>> resolving 'foo.local/NS/IN': 192.168.220.20#53 >>> >>> i've not had much experience with dnssec yet, but it would seem that >>> perhaps it relates here in some capacity, as there is no public .local >>> domain, obviously? disabling dnssec [dnssec-enable no;] seems to support >>> this, as when doing so, queries work. >>> >>> that said, i'm wondering why this is happening - e.g. why bind seems to be >>> consulting public dns for this zone, if i've explicitly told bind where to >>> go to find this zone data, and how i might be able to troubleshoot further, >>> or what my options might be. >>> >>> lastly, this is currently an older version of bind [9.9.5, courtesy of >>> ubuntu packages]. it will be updated, but can't be just yet. >>> >>> thanks! >>> ___ >>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >>> unsubscribe from this list >>> >>> bind-users mailing list >>> bind-users@lists.isc.org >>> https://lists.isc.org/mailman/listinfo/bind-users >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >> >> ___ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >> unsubscribe from this list >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users >> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: static stub zone not working as expected
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 , 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 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. 3600IN NS 01.foo.local.
foo.local. 3600IN NS 02.foo.local.
foo.local. 3600IN NS a2.foo.local.
foo.local. 3600IN 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,
Re: static stub zone not working as expected
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
> 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.3600IN NS 01.foo.local.
> foo.local.3600IN NS 02.foo.local.
> foo.local.3600IN NS a2.foo.local.
> foo.local.3600IN NS a1.foo.local.
>
> ;; ADDITIONAL SECTION:
> 01.foo.local. 3600IN A 192.168.0.20
> 02.foo.local. 3600IN A 192.168.0.21
> a2.foo.local. 3600IN A 10.201.11.8
> a1.foo.local. 1200IN 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 [d
static stub zone not working as expected
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. 3600IN NS 01.foo.local.
foo.local. 3600IN NS 02.foo.local.
foo.local. 3600IN NS a2.foo.local.
foo.local. 3600IN 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
Re: Issues with Stub Zone
Echoing Chris Buxton - you may be better served by using static-stub rather than stub. Explanation here: https://bugs.isc.org/Ticket/Display.html?id=45734 Cathy ___ 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
Re: Issues with Stub Zone
Thanks for your reply Chris,
When querying the SOA for that domain I successfully receive the full
SOA details including the addition NS and A record for the authoritative
server of the domain.
The stub server can contact the primary zone but only by IP, DNS
resolution fails unless I add in a record in /etc/hosts.
Also the stub zone file updates correctly. I have tested static-stubs
and they work as expected but stubs don't when recursion is enabled on
the BIND server.
Ben
On 08/05/2019 17:02, Chris Buxton wrote:
Remembering that a stub zone is a cache hint, more information is needed.
o What do the two "master" DNS servers say when asked for the SOA record of
'benlavender.co.uk'?
o Are there A or records in the Additional section? If so, can the
indicated IP addresses be reached?
It may be that the behavior you're expecting is more in line with type "static-stub" than
with type "stub".
Regards,
Chris Buxton
On May 7, 2019, at 4:08 PM, Ben Lavender wrote:
Hi,
I've been trying to configure a stub zone using both BIND 9.8x and 9.9x for
some split-brain internal DNS.
The problem I have is that any client that requests the NS or SOA records for
this zone gets SERVFAIL. The BIND server populates the
/var/named/slaves/benlavender.co.uk.DB file with the SOA and NS records
straight away and can query them over UDP 53 to the masters if need be.
I've had a look through the logs that are used in this config but the only
issues I see are in /lame-servers.log shows some IPv6 failures and that the
client is getting a SERVFAIL back in the /default.log:
05-May-2019 22:58:32.846 client 192.168.1.4#51612 (benlavender.co.uk): query
failed (SERVFAIL) for benlavender.co.uk/IN/NS at query.c:7038
The config I'm using in /etc/named.conf is:
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
// See the BIND Administrator's Reference Manual (ARM) for details about the
// configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html
options {
listen-on port 53 { 127.0.0.1; 172.16.4.31;};
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
recursing-file "/var/named/data/named.recursing";
secroots-file "/var/named/data/named.secroots";
allow-query { localhost; 172.16.4.2; 172.16.4.3; 192.168.1.4;};
/*
- If you are building an AUTHORITATIVE DNS server, do NOT enable
recursion.
- If you are building a RECURSIVE (caching) DNS server, you need to
enable
recursion.
- If your recursive DNS server has a public IP address, you MUST
enable access
control to limit queries to your legitimate users. Failing to do so
will
cause your server to become part of large scale DNS amplification
attacks. Implementing BCP38 within your network would greatly
reduce such attack surface
*/
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};
logging {
channel default_file {
file "/var/named/default.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel general_file {
file "/var/named/general.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel database_file {
file "/var/named/database.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel security_file {
file "/var/named/security.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel config_file {
file "/var/named/config.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel resolver_file {
file "/var/named/resolver.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel xfer-in_file {
file "/var/named/xfer-in.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel xfer-out_file {
file "/var/named/xfer-out.log" versions 3 size 5m;
severity debug;
pri
Re: Issues with Stub Zone
Remembering that a stub zone is a cache hint, more information is needed.
o What do the two "master" DNS servers say when asked for the SOA record of
'benlavender.co.uk'?
o Are there A or records in the Additional section? If so, can the
indicated IP addresses be reached?
It may be that the behavior you're expecting is more in line with type
"static-stub" than with type "stub".
Regards,
Chris Buxton
> On May 7, 2019, at 4:08 PM, Ben Lavender wrote:
>
> Hi,
>
> I've been trying to configure a stub zone using both BIND 9.8x and 9.9x for
> some split-brain internal DNS.
>
> The problem I have is that any client that requests the NS or SOA records for
> this zone gets SERVFAIL. The BIND server populates the
> /var/named/slaves/benlavender.co.uk.DB file with the SOA and NS records
> straight away and can query them over UDP 53 to the masters if need be.
>
> I've had a look through the logs that are used in this config but the only
> issues I see are in /lame-servers.log shows some IPv6 failures and that the
> client is getting a SERVFAIL back in the /default.log:
>
> 05-May-2019 22:58:32.846 client 192.168.1.4#51612 (benlavender.co.uk): query
> failed (SERVFAIL) for benlavender.co.uk/IN/NS at query.c:7038
>
> The config I'm using in /etc/named.conf is:
>
> //
> // named.conf
> //
> // Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
> // server as a caching only nameserver (as a localhost DNS resolver only).
> //
> // See /usr/share/doc/bind*/sample/ for example named configuration files.
> //
> // See the BIND Administrator's Reference Manual (ARM) for details about the
> // configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html
>
> options {
> listen-on port 53 { 127.0.0.1; 172.16.4.31;};
> listen-on-v6 port 53 { ::1; };
> directory "/var/named";
> dump-file "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named_stats.txt";
> memstatistics-file "/var/named/data/named_mem_stats.txt";
> recursing-file "/var/named/data/named.recursing";
> secroots-file "/var/named/data/named.secroots";
> allow-query { localhost; 172.16.4.2; 172.16.4.3; 192.168.1.4;};
>
> /*
> - If you are building an AUTHORITATIVE DNS server, do NOT enable
> recursion.
> - If you are building a RECURSIVE (caching) DNS server, you need to
> enable
>recursion.
> - If your recursive DNS server has a public IP address, you MUST
> enable access
>control to limit queries to your legitimate users. Failing to do
> so will
>cause your server to become part of large scale DNS amplification
>attacks. Implementing BCP38 within your network would greatly
>reduce such attack surface
> */
> recursion yes;
>
> dnssec-enable yes;
> dnssec-validation yes;
>
> /* Path to ISC DLV key */
> bindkeys-file "/etc/named.iscdlv.key";
>
> managed-keys-directory "/var/named/dynamic";
>
> pid-file "/run/named/named.pid";
> session-keyfile "/run/named/session.key";
> };
>
> logging {
> channel default_file {
> file "/var/named/default.log" versions 3 size 5m;
> severity debug;
> print-time yes;
> };
> channel general_file {
> file "/var/named/general.log" versions 3 size 5m;
> severity debug;
> print-time yes;
> };
> channel database_file {
> file "/var/named/database.log" versions 3 size 5m;
> severity debug;
> print-time yes;
> };
> channel security_file {
> file "/var/named/security.log" versions 3 size 5m;
> severity debug;
> print-time yes;
> };
> channel config_file {
> file "/var/named/config.log" versions 3 size 5m;
> severity debug;
> print-time yes;
> };
> channel resolver_file {
> file "/var/named/resolver.log" versions 3 size 5m;
> severity debug;
> print-time yes;
> };
> channel xfer-in_file {
> file "/var/named/xfer-in.log" versions 3 size 5m;
> severity debug;
> print-time yes;
> };
> channel xfer-out_file {
> file "/var/named/xfer-out.log" versions 3 size 5m;
> severity debug;
> print-time yes;
> };
> channel
Issues with Stub Zone
Hi,
I've been trying to configure a stub zone using both BIND 9.8x and 9.9x
for some split-brain internal DNS.
The problem I have is that any client that requests the NS or SOA
records for this zone gets SERVFAIL. The BIND server populates the
/var/named/slaves/benlavender.co.uk.DB file with the SOA and NS records
straight away and can query them over UDP 53 to the masters if need be.
I've had a look through the logs that are used in this config but the
only issues I see are in /lame-servers.log shows some IPv6 failures and
that the client is getting a SERVFAIL back in the /default.log:
05-May-2019 22:58:32.846 client 192.168.1.4#51612 (benlavender.co.uk):
query failed (SERVFAIL) for benlavender.co.uk/IN/NS at query.c:7038
The config I'm using in /etc/named.conf is:
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
// See the BIND Administrator's Reference Manual (ARM) for details about
the
// configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html
options {
listen-on port 53 { 127.0.0.1; 172.16.4.31;};
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
recursing-file "/var/named/data/named.recursing";
secroots-file "/var/named/data/named.secroots";
allow-query { localhost; 172.16.4.2; 172.16.4.3;
192.168.1.4;};
/*
- If you are building an AUTHORITATIVE DNS server, do NOT
enable recursion.
- If you are building a RECURSIVE (caching) DNS server, you
need to enable
recursion.
- If your recursive DNS server has a public IP address, you
MUST enable access
control to limit queries to your legitimate users. Failing
to do so will
cause your server to become part of large scale DNS
amplification
attacks. Implementing BCP38 within your network would greatly
reduce such attack surface
*/
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};
logging {
channel default_file {
file "/var/named/default.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel general_file {
file "/var/named/general.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel database_file {
file "/var/named/database.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel security_file {
file "/var/named/security.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel config_file {
file "/var/named/config.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel resolver_file {
file "/var/named/resolver.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel xfer-in_file {
file "/var/named/xfer-in.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel xfer-out_file {
file "/var/named/xfer-out.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel notify_file {
file "/var/named/notify.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel client_file {
file "/var/named/client.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel unmatched_file {
file "/var/named/unmatched.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel queries_file {
file "/var/named/queries.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel network_file {
file "/var/named/network.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel update_file {
file "/var/named/update.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel dispatch_file {
file "/var/named/dispatch.log" versions 3 size 5m;
severity debug;
print-time yes;
};
channel dnssec_f
RE: Stub Zone Behavior?
Forwarding is a different beast from "stub" (recursive rather than iterative
resolution).
I'd look at "static-stub", if your NS list is overgrown with
useless/unreachable stuff. It's configured basically the same way as
forwarding, but without making the paradigm shift (and possible unforeseen
consequences) from iterative to recursive resolution.
http://jpmens.net/2011/01/25/binds-new-static-stub-zone-type/
https://lists.isc.org/pipermail/bind-users/2012-September/088719.html
If you only have a *few*, relatively-static set of unreachables, you might
consider listing just those ones as "bogus".
- Kevin
-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ray Van
Dolson
Sent: Saturday, August 13, 2016 8:29 AM
To: bind-users@lists.isc.org
Subject: Stub Zone Behavior?
Have a resolver at a branch office with a view containing a stub zone as
follows:
zone "domain.com." IN {
type stub;
masters { 10.216.11.6; 10.58.4.1; 10.50.4.32; };
file "stub/domain.com";
forwarders {};
};
Other notes:
- "domain.com" is an Active Directory zone.
- Running bind-9.8.2-0.47.rc1.el6.x86_64 (RHEL6)
This setup seemed to work fine for many months, but within the last two or so
has randomly started returning no answers for only certain queries (well the
SOA stuff is returned) until I rndc flush on the system after which response
returns to normal for a period of time.
After trying a few things without success, I changed the zone type to forward
instead of stub (with the servers used as masters in the stub config as the
forwarders) and this has seemed to solved the problem.
As I understand it, stub zones work by pulling down SOA, NS and "glue"
for the NS from one of the masters into a local zone file and then queries to
the domain are answered by querying one of the authoritative servers defined in
the stub zone.
My working theory is that BIND will randomly choose one of the NS servers to
get an answer from, and since our NS list is very long with the servers
scattered across the globe, perhaps BIND chooses one which doesn't respond
quickly enough or at all (or maybe badly?) and then caches that negative or
absent response.
Probably in this case the forward type works just as well for our local clients
at the office (I believe answers for "forward" zones can also be cached
locally...), so am inclined to stand pat with this config but would still love
to understand what might have caused the original stub setup to fail.
Ray
___
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
Stub Zone Behavior?
Have a resolver at a branch office with a view containing a stub zone
as follows:
zone "domain.com." IN {
type stub;
masters { 10.216.11.6; 10.58.4.1; 10.50.4.32; };
file "stub/domain.com";
forwarders {};
};
Other notes:
- "domain.com" is an Active Directory zone.
- Running bind-9.8.2-0.47.rc1.el6.x86_64 (RHEL6)
This setup seemed to work fine for many months, but within the last two
or so has randomly started returning no answers for only certain
queries (well the SOA stuff is returned) until I rndc flush on the
system after which response returns to normal for a period of time.
After trying a few things without success, I changed the zone type to
forward instead of stub (with the servers used as masters in the stub
config as the forwarders) and this has seemed to solved the problem.
As I understand it, stub zones work by pulling down SOA, NS and "glue"
for the NS from one of the masters into a local zone file and then
queries to the domain are answered by querying one of the authoritative
servers defined in the stub zone.
My working theory is that BIND will randomly choose one of the NS
servers to get an answer from, and since our NS list is very long with
the servers scattered across the globe, perhaps BIND chooses one which
doesn't respond quickly enough or at all (or maybe badly?) and then
caches that negative or absent response.
Probably in this case the forward type works just as well for our local
clients at the office (I believe answers for "forward" zones can also
be cached locally...), so am inclined to stand pat with this config but
would still love to understand what might have caused the original
stub setup to fail.
Ray
___
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
Re: SERVFAIL on stub zone (WAS: dig @server foobar +trace +recurse)
Anne Bennett a...@encs.concordia.ca wrote: It all looks just peachy, but when I issued: dig @localhost -t ns concordia.ca. it gave me a SERVFAIL. I couldn't find anything abnormal in the syslogs. I can't for the life of my figure out why it's unhappy. How can I debug this? Try rndc trace 10. The debug logs are written to named.run (not syslog) by default. (I'm syslogging default syslog_all, minus edns-disabled, lame-servers, rpz, and unmatched.) Excluding lame-servers might be why you aren't seeing any log messages. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Southeast Iceland: Variable 3, becoming cyclonic 4 or 5 later. Moderate, occasionally slight at first. Rain or showers, fog patches. Moderate or good, occasionally very poor. ___ 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
Re: SERVFAIL on stub zone (WAS: dig @server foobar +trace +recurse)
Tony Finch suggested:
(I'm syslogging default syslog_all, minus edns-disabled,
lame-servers, rpz, and unmatched.)
Excluding lame-servers might be why you aren't seeing any log
messages.
I tried un-excluding it: nothing.
zone concordia.ca {
type stub;
file StubData/concordia.ca.SEC;
masters {
132.205.1.1 ;
132.205.7.51 ;
};
multi-master yes;
};
[results in transferring:]
--
$ORIGIN .
$TTL 86400 ; 1 day
concordia.caIN SOA ns1.concordia.ca. hostmaster.concordia.ca. (
2028969738 ; serial
43200 ; refresh (12 hours)
1800 ; retry (30 minutes)
2592000; expire (4 weeks 2 days)
1800 ; minimum (30 minutes)
)
NS ns1.concordia.ca.
NS ns2.concordia.ca.
--
[but querying it for NS gives SERVFAIL]
Midnight insight: glue records??? The two listed NS are below the
zone cut. How can a stub zone work in those circumstances, if at all?
I think I'm onto something; with the above stub zone for
concordia.ca (which transfers information listing two NS
records as ns1.concordia.ca and ns2.concordia.ca but no glue
records), I get SERVFAIL (after a clean start of named).
And in that circumstance, the other two stub zones I have set up
(for the IPv4 and IPv6 reverse zones for my parent networks) also
transfer the same set of two NS records, and also fail.
If I comment out the stub zone for concordia.ca, but leave
in the two reverse IP stub zones, then these two zones work
correctly: when I query for NS, they give me ns1.concordia.ca
and ns2.concordia.ca, with their A records in the additional
section.
I think that clinches it: the implementation of stub zones
indeed replicates only the NS records, but not the needed
glue records, so it cannot work in cases where all of the
listed NS are within the zone itself.
It would be a nice enhancement to make the stub zone pick up
glue records. Is this something I should report separately?
Meanwhile, I'll try a static-stub zone for this case...
Tony Finch has also suggested:
Try rndc trace 10. The debug logs are written to named.run (not
syslog) by default.
After a bit of tweaking of my logging configuration, I was
able to get the trace output. I append it (for a query on
the NS records of concordia.ca, with the stub zone in effect),
in case it is of use to anyone.
Anne.
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
---
15-Jul-2015 14:54:47.342 debug level is now 10
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060: UDP request
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060: using view '_default'
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060: request is not signed
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060: recursion available
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060: query
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060 (concordia.ca):
ns_client_attach: ref = 1
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060 (concordia.ca): query
'concordia.ca/NS/IN' approved
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060 (concordia.ca): replace
15-Jul-2015 14:54:47.353 clientmgr @0x2b31f95c2458: get client
15-Jul-2015 14:54:47.353 clientmgr @0x2b31f95c2458: recycle
15-Jul-2015 14:54:47.353 fetch: concordia.ca/NS
15-Jul-2015 14:54:47.353 client @0x2b31fc0dfa60: udprecv
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): create
15-Jul-2015 14:54:47.353 log_ns_ttl: fctx 0x2b3204c7f010: fctx_create:
concordia.ca (in 'concordia.ca'?): 1 86400
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): join
15-Jul-2015 14:54:47.353 fetch 0x2b31f5babd18 (fctx
0x2b3204c7f010(concordia.ca/NS)): created
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): start
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): try
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): cancelqueries
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): getaddresses
15-Jul-2015 14:54:47.354 fetch: ns1.concordia.ca/A
15-Jul-2015 14:54:47.354 fctx 0x2b3204cc0010(ns1.concordia.ca/A): create
15-Jul-2015 14:54:47.354 log_ns_ttl: fctx 0x2b3204cc0010: fctx_create:
ns1.concordia.ca (in 'concordia.ca'?): 1 86400
15-Jul-2015 14:54:47.354 fctx 0x2b3204cc0010(ns1.concordia.ca/A): join
15-Jul-2015 14:54:47.354 fetch 0x2b31f5babd78 (fctx
0x2b3204cc0010(ns1.concordia.ca/A)): created
15-Jul-2015 14:54:47.354 dns_adb_createfind: started A fetch for name
ns1.concordia.ca
SERVFAIL on stub zone (WAS: dig @server foobar +trace +recurse)
Tony Finch d...@dotat.at enlightens me thus:
The difference between stub and static-stub is that stub works like the
root zone hints, i.e. the servers in the zone override the ones that you
configure for a stub zone, whereas the servers you configure for a
static-stub zone override the servers in the zone.
... so, since I want my parent zone to be able to give me the
set of servers it wants me to use, I configured my resolver
to have (this snippet from named-checkconf -p to deal with
include files and such):
zone concordia.ca {
type stub;
file StubData/concordia.ca.SEC;
masters {
132.205.1.1 ;
132.205.7.51 ;
};
multi-master yes;
};
named-checkconf gave no errors. I issued a reconfig, again
no errors logged or reported. I can confirm that the zone was
transferred correctly (showing me the internal view), because
I have masterfile-format text as a general option (small
enough number of zones that performance is not an issue, but
human ability to debug *is*), and StubData/concordia.ca.SEC
contains a perfectly normal-looking zone stub:
--
$ORIGIN .
$TTL 86400 ; 1 day
concordia.caIN SOA ns1.concordia.ca. hostmaster.concordia.ca. (
2028969738 ; serial
43200 ; refresh (12 hours)
1800 ; retry (30 minutes)
2592000; expire (4 weeks 2 days)
1800 ; minimum (30 minutes)
)
NS ns1.concordia.ca.
NS ns2.concordia.ca.
--
It all looks just peachy, but when I issued:
dig @localhost -t ns concordia.ca.
it gave me a SERVFAIL. I couldn't find anything abnormal
in the syslogs. I can't for the life of my figure out why
it's unhappy. How can I debug this? Is it normal that a
zone could be badly enough out of whack to SERVFAIL, yet
the named would syslog nothing?
(I'm syslogging default syslog_all, minus edns-disabled,
lame-servers, rpz, and unmatched.)
Anne.
--
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
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
Re: SERVFAIL on stub zone (WAS: dig @server foobar +trace +recurse)
zone concordia.ca {
type stub;
file StubData/concordia.ca.SEC;
masters {
132.205.1.1 ;
132.205.7.51 ;
};
multi-master yes;
};
[results in transferring:]
--
$ORIGIN .
$TTL 86400 ; 1 day
concordia.caIN SOA ns1.concordia.ca. hostmaster.concordia.ca. (
2028969738 ; serial
43200 ; refresh (12 hours)
1800 ; retry (30 minutes)
2592000; expire (4 weeks 2 days)
1800 ; minimum (30 minutes)
)
NS ns1.concordia.ca.
NS ns2.concordia.ca.
--
[but querying it for NS gives SERVFAIL]
Midnight insight: glue records??? The two listed NS are below the
zone cut. How can a stub zone work in those circumstances, if at all?
Anne.
--
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
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
Re: order of masters IP addresses in slave/stub zone?
In article mailman.1698.1424913638.26362.bind-us...@lists.isc.org, Hillary Nelson nelsonhilla...@gmail.com wrote: I was asked to add some backup master IP addresses to a slave zone file for some HCP system, but those IPs not active and can't do zone transfer until system failover. My question is, does the order of the master ip list matters, so named always tries first ones until it fails tries next one? Or named pick the IP from the list randomly to do zone transfer? It tries them all. Any master that has a higher serial number than the current serial will be pulled from. -- Barry Margolin Arlington, MA ___ 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
order of masters IP addresses in slave/stub zone?
I was asked to add some backup master IP addresses to a slave zone file for some HCP system, but those IPs not active and can't do zone transfer until system failover. My question is, does the order of the master ip list matters, so named always tries first ones until it fails tries next one? Or named pick the IP from the list randomly to do zone transfer? Thanks! Hillary ___ 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
Re: BIND master , Windows 2008 stub zone not transferring
Well, I have a stub zone on Windows 2008 server set-up to use two different BIND server as its list of IPs to use as masters. In the DNS manager on Windows, you can always right click on the zone and select Transfer zone from Master. With Wireshark on Windows, I have found that this triggers a DNS request for the given zone name. You may be right that it may very well not be a zone transfer and just a regular query/response. However, I was just going by the terminology on the zone from Windows. In any case, the problem is that this zone transfer is finicky. Sometimes, the zone is loaded correctly and sometimes that Zone Tranfer failed or Zone Not Loaded by DNS Server. It has also been hard to understand what makes this failure occur. Another problem I am also having is that Windows 2008 server doesn't seem to pick up the latest SOA i.e. it does not seem to honour the serial number within the SOA. It appears it just picks up the 1st response it gets. So, I find that sometimes the records are stale. I am trying to understand if there is any configuration in BIND that can help provide the right response the 2008 server prefers. Any help appreciated. Thanks, Sowmya. On Thu, Feb 21, 2013 at 6:22 AM, Matus UHLAR - fantomas uh...@fantomas.skwrote: On 20.02.13 17:41, Sowmya Manjanatha wrote: Subject: BIND master , Windows 2008 stub zone not transferring I am having the same issue and saw a couple of questions but didn't see any resolutions. Any one have any luck with this. stub zone is never transferred. It is only queried for NS records for the BIND to know who to ask for records. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod __**_ Please visit https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-usersto unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/**listinfo/bind-usershttps://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
Re: BIND master , Windows 2008 stub zone not transferring
From: Sowmya Manjanatha sowmy...@gmail.com Well, I have a stub zone on Windows 2008 server set-up to use two different BIND server as its list of IPs to use as masters. In the DNS manager on Windows, you can always right click on the zone and select Transfer zone from Master. With Wireshark on Windows, I have found that this triggers a DNS request for the given zone name. Yes. DNS does a query for the SOA record so it can compare serial numbers. If the received serial number is not higher, no transfer is started. You may be right that it may very well not be a zone transfer and just a regular query/response. However, I was just going by the terminology on the zone from Windows. Bad plan. Microsoft like to redefine terms. They do so in many of their products, even terms that have been around since before Johannes Gutenberg was moving type. In any case, the problem is that this zone transfer is finicky. Sometimes, the zone is loaded correctly and sometimes that Zone Tranfer failed or Zone Not Loaded by DNS Server. It has also been hard to understand what makes this failure occur. Are they allowed to do zone transfers (allow-transfer option)? Another problem I am also having is that Windows 2008 server doesn't seem to pick up the latest SOA i.e. it does not seem to honour the serial number within the SOA. It appears it just picks up the 1st response it gets. So, I find that sometimes the records are stale. I am trying to understand if there is any configuration in BIND that can help provide the right response the 2008 server prefers. Do all of your masters agree on the serial number? Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ 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
Re: BIND master , Windows 2008 stub zone not transferring
-Original Message- From: Sowmya Manjanatha sowmy...@gmail.com Date: Thursday, February 21, 2013 1:11 PM To: bind-users@lists.isc.org bind-users@lists.isc.org Subject: Re: BIND master , Windows 2008 stub zone not transferring Well, I have a stub zone on Windows 2008 server set-up to use two different BIND server as its list of IPs to use as masters. In the DNS manager on Windows, you can always right click on the zone and select Transfer zone from Master. With Wireshark on Windows, I have found that this triggers a DNS request for the given zone name. You may be right that it may very well not be a zone transfer and just a regular query/response. However, I was just going by the terminology on the zone from Windows. Yes, it is a request for the NS RRset I presume...as Mark kindly pointed out, stub zones do not transfer by definition: http://technet.microsoft.com/en-us/library/cc771898.aspx Another problem I am also having is that Windows 2008 server doesn't seem to pick up the latest SOA i.e. it does not seem to honour the serial number within the SOA. It appears it just picks up the 1st response it gets. So, I find that sometimes the records are stale. I am trying to understand if there is any configuration in BIND that can help provide the right response the 2008 server prefers. Are you simply seeing the effects of TTL and caching on the Windows side? ___ 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
BIND master , Windows 2008 stub zone not transferring
I am having the same issue and saw a couple of questions but didn't see any resolutions. Any one have any luck with this. 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
does a stub zone require an IXFR?
Attempting to determine if a stub zone requires any kind of zone transfer. Reading through online doc I find mixed opinions. Here's one: … Stub-Zones do receive their information by just querying DNS-Servers instead of requesting a Zone-Transfer. You can even add Stub-Zones for Zones where Zone-Transfers are not allowed. ... But on a different web site / forum here's another: The Stubzone has an SOA record and the NS glue records. When you add a stub zone to a DNS server you would need it to zone transfer to get the NS records. The stubzone does update the NS records automatically unlike the delegated zone which is alll manual for NS records. So a stubzone must zone transfer based off SOA record settings. Also i would bet its an incremental zone transfer IXFR (?). Can anyone answer this question definitively? Thanks! Marty ___ 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
Re: does a stub zone require an IXFR?
On Sep 20, 2012, at 4:39 AM, M. Meadows wrote: Attempting to determine if a stub zone requires any kind of zone transfer. Reading through online doc I find mixed opinions. No zone transfer. Just an SOA query, an NS query, and (if necessary) A and record queries for name server names. Chris Buxton BlueCat Networks signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
RE: BIND master , Windows 2008 stub zone not transferring
I had a very similar issue recently, but it was with secondaries on Windows Server 2008 R2 and not stub zones. We actually went to stub zones afterwards to prevent the issue from happening again, hopefully. The issue was that a machine had done DCHP and gotten the DDNS created A/TXT/PTR records, but had registered some invalid Unicode characters in its host name, including spaces so the host record was garbage. Windows didn't know what to do and stopped transferring all zones, BIND just chugged along blissfully unaware. I had to use nsupdate on the BIND side to remove the bad record and get the host renamed. After that, Windows still would not transfer any zones (not even the zones that were not impacted by the bad records) until ALL zones were deleted and recreated on each Windows DNS server. I was able to find the offending record by using the zone transfer function in Windows nslookup and fortunately the bad characters made the record easy to spot in the list. I don't know that this scenario would cause your situation, but it was close so I thought it might be of some help. -Will -Original Message- From: bind-users-bounces+listswill=gmail@lists.isc.org [mailto:bind-users-bounces+listswill=gmail@lists.isc.org] On Behalf Of Gregory Machin Sent: Wednesday, October 19, 2011 11:48 PM To: bind-us...@isc.org Subject: BIND master , Windows 2008 stub zone not transferring Hi We have a Linux server running bind 9.2.4 and dhcpd in a ddns configuration. We also have a number of windows 2008 R2 servers running AD / DNS / dhcp on other sites. These windows servers have stub zones configured, for the zones on the Linux server. All worked fine up until yesterday. Now none of the zones will transfer to the stub zones on the Windows servers. From the windows servers I can use nslookup to do zone transfers with out any issues. But in DNS mangers , on the stub zone , when I click one reload, or Transfer from Master, or Transfer new copy from zone Master then result is the same Zone Not Loaded by DNS server there is nothing in the bind logs that relate to this server or the zone transfer request. As far a I can see there are no firewall issues or connectivity issues. Any suggestions ? G ___ 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
BIND master , Windows 2008 stub zone not transferring
Hi We have a Linux server running bind 9.2.4 and dhcpd in a ddns configuration. We also have a number of windows 2008 R2 servers running AD / DNS / dhcp on other sites. These windows servers have stub zones configured, for the zones on the Linux server. All worked fine up until yesterday. Now none of the zones will transfer to the stub zones on the Windows servers. From the windows servers I can use nslookup to do zone transfers with out any issues. But in DNS mangers , on the stub zone , when I click one reload, or Transfer from Master, or Transfer new copy from zone Master then result is the same Zone Not Loaded by DNS server there is nothing in the bind logs that relate to this server or the zone transfer request. As far a I can see there are no firewall issues or connectivity issues. Any suggestions ? G ___ 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
Re: stub zone
On Jul 26, 2011, at 10:51 PM, Feng He wrote:
On Wed, Jul 27, 2011 at 8:51 AM, Chris Buxton chris.p.bux...@gmail.com
wrote:
On Jul 25, 2011, at 10:33 PM, Feng He wrote:
On Tue, Jul 26, 2011 at 3:55 AM, ju wusuo juwu...@yahoo.com wrote:
Would like to use the BIND stub zone function, however, heard that ISC
considers stopping support to stub zone in the future, is that true?
___
Hi,
what's the use of stub zone? I never used it, thanks.
A stub zone is conceptually similar to the root hints zone, but for a domain
other than the root. It's a way to add NS and glue records to the cache as a
way to either optimize recursion performance or overlay a private namespace
onto the public Internet.
For example, suppose you have a name server with this configuration:
options {
some stuff goes here
};
zone bluecatnetworks.com {
type stub;
masters { 192.168.0.1; };
};
Thanks.
So, what's the difference between a stub zone and a slave zone?
I think the configure:
zone bluecatnetworks.com {
type slave;
masters { 192.168.0.1; };
};
Will be able to have the same effect.
Mostly, yes. The difference is that with the slave zone, the server is
authoritative. This may have undesirable side effects:
- You must consider either using a low refresh timer or configuring DNS notify
on the master.
- It may cause problems for DNSSEC-aware clients that hit the server.
- It takes more memory and possibly more bandwidth. For a single zone, probably
not a problem, but suppose there are 1 or more zones involved.
Chris Buxton
BlueCat Networks
___
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
Re: stub zone
In message 1311623708.59385.yahoomail...@web44803.mail.sp1.yahoo.com, ju wusuo writes: Would like to use the BIND stub zone function, however, heard that ISC cons= iders stopping support to stub zone in the future, is that true?=A0 No. There are no plans to remove support for stub zones. Mark -- 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
Re: stub zone
On Tue, Jul 26, 2011 at 3:55 AM, ju wusuo juwu...@yahoo.com wrote: Would like to use the BIND stub zone function, however, heard that ISC considers stopping support to stub zone in the future, is that true? ___ Hi, what's the use of stub zone? I never used it, 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
Re: stub zone
Thanks Mark .. I think that probably is the misunderstanding of the delegation usage part. From: Mark Andrews ma...@isc.org To: ju wusuo juwu...@yahoo.com Cc: bind-users@lists.isc.org bind-us...@isc.org Sent: Monday, July 25, 2011 9:57 PM Subject: Re: stub zone In message 1311623708.59385.yahoomail...@web44803.mail.sp1.yahoo.com, ju wusuo writes: Would like to use the BIND stub zone function, however, heard that ISC cons= iders stopping support to stub zone in the future, is that true?=A0 No. There are no plans to remove support for stub zones. Mark -- 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
Re: stub zone
On Jul 25, 2011, at 10:33 PM, Feng He wrote:
On Tue, Jul 26, 2011 at 3:55 AM, ju wusuo juwu...@yahoo.com wrote:
Would like to use the BIND stub zone function, however, heard that ISC
considers stopping support to stub zone in the future, is that true?
___
Hi,
what's the use of stub zone? I never used it, thanks.
A stub zone is conceptually similar to the root hints zone, but for a domain
other than the root. It's a way to add NS and glue records to the cache as a
way to either optimize recursion performance or overlay a private namespace
onto the public Internet.
For example, suppose you have a name server with this configuration:
options {
some stuff goes here
};
zone bluecatnetworks.com {
type stub;
masters { 192.168.0.1; };
};
Then assuming the server 192.168.0.1 has a zone named bluecatnetworks.com,
which might have different content than the public version of that zone, the
server with this configuration will be able to find that private version of
bluecatnetworks.com, while still being able to resolve names from the Internet
for everything else.
The difference between a stub zone and a forward zone is that a stub zone
causes the server to send iterative queries, not recursive. Note that the two
are not mutually exclusive, though, so if you have a forwarding configuration
that also covers the zone, the server will forward those queries rather than
resolving them using the stub zone. This can be overcome by adding an empty
forwarders list to the stub zone:
zone bluecatnetworks.com {
type stub;
masters { 192.168.0.1; };
forwarders { };
};
Under the hood, the stub zone causes the server to query the indicated master
server(s) periodically for the zone's SOA record, NS records, and any necessary
glue records, and these are inserted into cache. The records are refreshed
according to the refresh setting in the SOA record, similar to a slave zone
(sans the notify mechanism), so in this way the behavior is slightly different
than a root hints zone.
Chris Buxton
BlueCat Networks
___
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
Re: stub zone
need to use it to send out iterative queries, instead of recursive ones (if using forwarding). From: Feng He lt;short...@gmail.comgt; To: ju wusuo lt;juwu...@yahoo.comgt; Cc: quot;bind-users@lists.isc.orgquot; lt;bind-users@lists.isc.orggt; Sent: Tuesday, July 26, 2011 1:33 AM Subject: Re: stub zone On Tue, Jul 26, 2011 at 3:55 AM, ju wusuo lt;juwu...@yahoo.comgt; wrote: gt; Would like to use the BIND stub zone function, however, heard that ISC gt; considers stopping support to stub zone in the future, is that true? gt; ___ Hi, what#39;s the use of stub zone? I never used it, 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
Re: stub zone
On Jul 25, 2011, at 12:55 PM, ju wusuo wrote: Would like to use the BIND stub zone function, however, heard that ISC considers stopping support to stub zone in the future, is that true? I've heard that rumor from my customers, too. But I haven't heard anything from ISC about not supporting them ongoing. Chris Buxton BlueCat Networks ___ 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
Re: stub zone
On 25/07/11 20:55, ju wusuo wrote: Would like to use the BIND stub zone function, however, heard that ISC considers stopping support to stub zone in the future, is that true? I think we may have confused some people in the past about support for this because of what's written in the ARM about some configurations that use stub zones for a child zone on the parent that delegated it instead of maintaining the NS records directly in the parent zone. A stub zone is similar to a slave zone, except that it replicates only the NS records of a master zone instead of the entire zone. Stub zones are not a standard part of the DNS; they are a feature specific to the BIND implementation. Stub zones can be used to eliminate the need for glue NS record in a parent zone at the expense of maintaining a stub zone entry and a set of name server addresses in named.conf. This usage is not recommended for new configurations, and BIND 9 supports it only in a limited way. In BIND 4/8, zone transfers of a par- ent zone included the NS records from stub children of that zone. This meant that, in some cases, users could get away with con- figuring child stubs only in the master server for the parent zone. BIND 9 never mixes together zone data from different zones in this way. Therefore, if a BIND 9 master serving a parent zone has child stub zones configured, all the slave servers for the parent zone also need to have the same child stub zones configured. Stub zones can also be used as a way of forcing the resolution of a given domain to use a particular set of authoritative servers. For example, the caching name servers on a private network us- ing RFC1918 addressing may be configured with stub zones for 10.in-addr.arpa to use a set of internal name servers as the authoritative servers for that domain. Basically, the behaviour changed between BIND4/8 and BIND9 and the particular use case above was discouraged. But not use of stub zones entirely. (We also added static-stub as a new zone type - see the ARM for details). ___ 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
Re: stub zone
On Wed, Jul 27, 2011 at 8:51 AM, Chris Buxton chris.p.bux...@gmail.com wrote:
On Jul 25, 2011, at 10:33 PM, Feng He wrote:
On Tue, Jul 26, 2011 at 3:55 AM, ju wusuo juwu...@yahoo.com wrote:
Would like to use the BIND stub zone function, however, heard that ISC
considers stopping support to stub zone in the future, is that true?
___
Hi,
what's the use of stub zone? I never used it, thanks.
A stub zone is conceptually similar to the root hints zone, but for a domain
other than the root. It's a way to add NS and glue records to the cache as a
way to either optimize recursion performance or overlay a private namespace
onto the public Internet.
For example, suppose you have a name server with this configuration:
options {
some stuff goes here
};
zone bluecatnetworks.com {
type stub;
masters { 192.168.0.1; };
};
Thanks.
So, what's the difference between a stub zone and a slave zone?
I think the configure:
zone bluecatnetworks.com {
type slave;
masters { 192.168.0.1; };
};
Will be able to have the same effect.
Regards,
Feng.
___
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
stub zone
Would like to use the BIND stub zone function, however, heard that ISC considers stopping support to stub zone in the future, is that true? ___ 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
Re: Stub zone vs forward zone
Hi,
On Mon, Mar 14, 2011 at 09:16:13PM -0400, Kevin Darcy wrote:
Stub zones: only available as a single level beyond one's authoritative
core, i.e. the stub server must be able to talk directly to one or more
authoritative servers for the zone.
Forward zones: can be daisy-chained an arbitrary number of levels from
the authoritative core (but this is not recommended due to
manageability, performance and reliability concerns).
Stub zones: will use whatever is in the NS records of the zone (or
descendants of the zone, if not otherwise defined) to resolve queries
which are below a zone cut.
Forward zones: will always use the configured forwarders, which must
support recursion, even for names which are known to be deeper in the
delegation hierarchy and whose delegated/authoritative nameservers might
respond more quickly than the forwarders, if asked.
Thanks for the clarification, I appreciate that.
As a general rule, use type forward zones only if you have some
connectivity issue you need to work around, e.g. trying to resolve
Internet names from behind a restrictive firewall.
So, a type forward zone is the right thing to do for the reverse DNS
zones of RFC1918 networks that are reachable via a VPN link. However,
my setup using a type forward zone doesn't work, and bind does not
even try querying the forwarders listed in the type forward zone
statement when I try to obtain a PTR record for an IP on these nets.
Use slave zones if you want a full copy of the zone available at all
times (unless it expires of course), thus maximizing fault-tolerance
and client-to-resolver performance, but subject to the replication
overhead, storage space and willingness of the zone owner to allow
zone transfers. And use stub zones if you want a more lightweight
alternative to slaving, at the expense of some fault-tolerance and
client-to-resolver performance.
In my case, my slave could only intermittendly reach the master
servers for the zones, so I'd need to reload these zones quite
frequently to catch a time when the VPN tunnel is built. Does a stub
zone use the same mechanism, or will it immediately query for the
stub's NS records when a query comes in and the NS records are no
longer cached?
To answer your specific question, the non-intuitive[1] forwarders { };
is needed to inhibit forwarding which has presumably been defined at a
higher level (semantically) in your config, either at the
1.10.in-addr.arpa level, or somewhere above that, explicitly, or
so-called global forwarding defined in the options clause.
Global forwarders. So they would take precedence over the locally
available delegations for the stub zone?
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
On Mon, Mar 14, 2011 at 01:36:10PM +0100, Jan-Piet Mens wrote:
A stub zone tells BIND to load SOA and NS records from its masters {}.
(forwarders {} is, I belive, both useless and incorrect here.) From that
point onwards, your BIND will use the data in the stub to recursively
find answers to queries for that zone.
The forwarder on the other hand, instructs BIND to forward all queries
for the zone to the addresses in the forwarders {} list; the target
server must be prepared and willing to perform recursive lookups on your
behalf.
In this case, the servers mentioned in the configuration I posted are
both authoritative for the zones that they're query for _and_ willing
to recurse for my bind if it asked them a recursive query. Which it
doesn't in the forward setup, it just immediately returns NXDOMAIN.
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
On 18.03.2011 10:17, Marc Haber wrote:
Which it doesn't in the forward setup, it just immediately returns NXDOMAIN.
Do you include zones.rfc1918 in your configuration? What SOA RR does the
NXDOMAIN return?
| zone 0.10.in-addr.arpa {
| type forward;
| forwarders { 10.0.0.2; };
| };
|
| include /etc/bind/zones.rfc1918;
The dummy zone overrides the forward declaration:
| $ dig -x 10.0.0.3
| ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 59555
|
| ;; AUTHORITY SECTION:
| 10.in-addr.arpa. 86400 IN SOA localhost. root.localhost. 1
604800
86400 2419200 86400
Hauke.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
On Mon, Mar 14, 2011 at 09:16:13PM -0400, Kevin Darcy wrote: As a general rule, use type forward zones only if you have some connectivity issue you need to work around, e.g. trying to resolve Internet names from behind a restrictive firewall. On 18.03.11 10:15, Marc Haber wrote: So, a type forward zone is the right thing to do for the reverse DNS zones of RFC1918 networks that are reachable via a VPN link. I wouldn't say so. You need forward zone, if you: - don't know which servers provide the zone, so you need to query recursive servers - want to fall back to standard resolution if forward servers are unreachable. Otherwise stub or static-stub zones will do what you want. However, my setup using a type forward zone doesn't work, and bind does not even try querying the forwarders listed in the type forward zone statement when I try to obtain a PTR record for an IP on these nets. do you have recursion enabled? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. We are but packets in the Internet of life (userfriendly.org) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Stub zone vs forward zone
Hi,
I am running a local instance of bind on my notebook to spare myself
some rather annoying reconfiguration orgies that are bound to happen
when changing networks.
On my biggest customer's network, I am trying to be able to access
their reverse DNS, which is (don't ask) not loaded on the servers that
my notebook is assigned via DHCP as forwarders.
I have thus configured these zones locally, experimenting with
differnt configuration types:
zone 2.1.10.in-addr.arpa {
type stub;
masters { 10.1.2.11; 10.1.2.45; };
file stub/2.1.10.in-addr.arpa;
forwarders { };
};
zone 101.1.10.in-addr.arpa {
type forward;
forwarders { 10.1.101.6; };
forward only;
};
The stub zone works; the forward zone doesn't. When I ask my local
bind for 6.101.1.10.in-addr.arpa (PTR), I get an immediate NXDOMAIN
without bind even trying to talk to the actual name server.
I can ping 10.1.101.6 just fine.
I must admit that I haven't yet full understood the difference between
a stub zone and a forward zone, any why i need the forwarders { } on
the stub zone.
Any hints will be appreciated.
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
Marc,
A stub zone tells BIND to load SOA and NS records from its masters {}.
(forwarders {} is, I belive, both useless and incorrect here.) From that
point onwards, your BIND will use the data in the stub to recursively
find answers to queries for that zone.
The forwarder on the other hand, instructs BIND to forward all queries
for the zone to the addresses in the forwarders {} list; the target
server must be prepared and willing to perform recursive lookups on your
behalf.
-JP
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
In message 20110314104330.ga29...@torres.zugschlus.de, Marc Haber writes:
Hi,
I am running a local instance of bind on my notebook to spare myself
some rather annoying reconfiguration orgies that are bound to happen
when changing networks.
On my biggest customer's network, I am trying to be able to access
their reverse DNS, which is (don't ask) not loaded on the servers that
my notebook is assigned via DHCP as forwarders.
I have thus configured these zones locally, experimenting with
differnt configuration types:
zone 2.1.10.in-addr.arpa {
type stub;
masters { 10.1.2.11; 10.1.2.45; };
file stub/2.1.10.in-addr.arpa;
forwarders { };
};
zone 101.1.10.in-addr.arpa {
type forward;
forwarders { 10.1.101.6; };
forward only;
};
The stub zone works; the forward zone doesn't. When I ask my local
bind for 6.101.1.10.in-addr.arpa (PTR), I get an immediate NXDOMAIN
without bind even trying to talk to the actual name server.
I can ping 10.1.101.6 just fine.
I must admit that I haven't yet full understood the difference between
a stub zone and a forward zone, any why i need the forwarders { } on
the stub zone.
The empty forwarders clause turns off the enclosing/global forwarders.
Any hints will be appreciated.
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
___
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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
On Mon, 14 Mar 2011, Jan-Piet Mens wrote:
A stub zone tells BIND to load SOA and NS records from its masters {}.
(forwarders {} is, I belive, both useless and incorrect here.) From that
point onwards, your BIND will use the data in the stub to recursively
find answers to queries for that zone.
The forwarder on the other hand, instructs BIND to forward all queries
for the zone to the addresses in the forwarders {} list; the target
server must be prepared and willing to perform recursive lookups on your
behalf.
If I understand correctly, the difference is visible if there are
delegated sub-zones. For a stub zone BIND will follow the NS records to
the delegated zone's authoritative servers; for a forward zone all
sub-domains will use the specified recursive servers in the forwarders
clause.
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
South Fisher, German Bight: Variable, becoming easterly 3 or 4, increasing 5
or 6. Slight or moderate. Fog banks. Moderate, occasionally very poor.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
stub zone and dnssec processing fails?
Hi,
I've been trying to configure bind to use a stub zone, for which I
have keys configured. When I do this, I see a ServFail, with the
logs pointing to:
01-Oct-2009 11:00:03.053 lame-servers: info: not insecure resolving
'xelerance.ca/DNSKEY/IN': 193.110.157.135#53
When I disable the trusted-keys {} for this zone, the resolving
works, but then it seems to ignore the stub and go out via the
regular path
Enabling/disabling DLV did not make a difference. The relevant parts of
the named.conf:
options {
dnssec-enable yes;
dnssec-validation yes;
// dnssec-lookaside . trust-anchor dlv.isc.org.;
recursion yes;
};
zone ca. IN {
type stub;
masters { 192.228.22.190; 192.228.22.189; };
};
trusted-keys {
ca. 257 3 7 AwEAAbTcBX0/Z6uh4gUFmPhNMExALpP8eVy+KyHQ3IY8z/XlDoRVoe2Cv0IXBWp
MFme3sQpAEGg9Ps1+lYXpn2zO0BfpcED2nVlZ9KFBwh1MuEHvaAAkYKZtT/aqOIDJftRdmU8ClFZgaeJ
c8Scvf5boGczVvG/ZdbDpHVM73x6a4rQqjTDlgwSaNU+/vimOWii5d4lWBxUDQKsqkQ27UGqyGtYQxNY
giRGx80phZkmhxOnSwfXIG/RJa0Hl6CtlsG3klywJ+7NAZM/n8Y0TQqjOHudC0SedXSCmQ0C/Ds0QX5M
7c/S7alVBYsOdHhJF05MaIA5ij0thAmuvJUW7ofqO5ec= ; // key id = 46215
};
Paul
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: stub zone and dnssec processing fails?
On Fri, 2 Oct 2009, Mark Andrews wrote:
zone ca. IN {
type stub;
masters { 192.228.22.190; 192.228.22.189; };
};
To make the test signed ca work you need to replace the NS RRet
with the names of the nameservers that serve the signed CA zone.
At the moment you end up with those that server unsigned content
which is correctly rejected. Stubs pre-populate the delegation,
they do not override the delegation.
It seems that using a forward type zone does work:
zone ca. IN {
type forward;
forwarders { 66.241.135.248; 193.110.157.136; };
};
dig +dnssec -t ds xelerance.ca. @localhost
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 12, ADDITIONAL: 1
I had tried it before and it failed. Must have been an operator error.
Paul
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: stub zone
On Thu, Mar 05, 2009 at 02:06:18PM +0100,
squid proxy squidcac...@gmail.com wrote
a message of 13 lines which said:
Howto create a stub zone instead of slave zone on BIND 9.3.4-P1.1?
Read the documentation ?
https://www.isc.org/software/bind/documentation/arm95
zone zone_name [class] {
type stub;
[ allow-query { address_match_list }; ]
[ allow-query-on { address_match_list }; ]
...
};
What are differences between slave and stub zone?
Read the documentation ?
https://www.isc.org/software/bind/documentation/arm95
A stub zone is similar to a slave zone, except that it replicates only the NS
records of a master zone instead of the entire zone. Stub zones are not a
standard part of the DNS; they are a feature specific to the BIND
implementation.
Stub zones can be used to eliminate the need for glue NS record in a parent
zone at the expense of maintaining a stub zone entry and a set of name server
addresses in named.conf. This usage is not recommended for new configurations,
and BIND 9 supports it only in a limited way. In BIND 4/8, zone transfers of a
parent zone included the NS records from stub children of that zone. This meant
that, in some cases, users could get away with configuring child stubs only in
the master server for the parent zone. BIND 9 never mixes together zone data
from different zones in this way. Therefore, if a BIND 9 master serving a
parent zone has child stub zones configured, all the slave servers for the
parent zone also need to have the same child stub zones configured.
Stub zones can also be used as a way of forcing the resolution of a given
domain to use a particular set of authoritative servers. For example, the
caching name servers on a private network using RFC1918 addressing may be
configured with stub zones for 10.in-addr.arpa to use a set of internal name
servers as the authoritative servers for that domain.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
stub zone
hi At the moment our internal DNS servers are authorative for the main domain via slave zones, which will be generating unnecessary replication traffic. Howto create a stub zone instead of slave zone on BIND 9.3.4-P1.1? What are differences between slave and stub zone? Piotr ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
