I have tried to consolidate the several suggestions for how to configure a
view that would respond with AD to recursive queries for authoritative
zoned.
I don't have a working recipe. I could use some help.
At this point, it looks like the recursive view is still going to the
external nameserv
---
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-Original Message-
From: Chris Buxton [mailto:chris.p.bux...@gmail.com]
Sent: Saturday, September 11, 2010 22:41
To: Phil Mayers
Cc: bind-users@lists
On Sep 12, 2010, at 10:45 AM, Tony Finch wrote:
> I could not get private stub nor forward zones to work if their public parent
> is signed and does not have a delegation to the private zone.
Does it work if the parent does have a DS record for the child covered by the
stub zone? I would expect
I could not get private stub nor forward zones to work if their public parent
is signed and does not have a delegation to the private zone.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
On 12 Sep 2010, at 03:41, Chris Buxton wrote:
>
> On Sep 11, 2010, at 2:34 AM, Phil Mayers wrote:
>>
>> Y
On 09/12/2010 03:41 AM, Chris Buxton wrote:
Use a stub zone instead of a forward zone, so that the query will
actually reach the authoritative view. With a forward zone, the query
is recursive, so will be picked up by the recursive view - the view
will query itself and not receive an answer.
O
On Sep 11, 2010, at 2:34 AM, Phil Mayers wrote:
> On 09/10/2010 11:12 PM, Timothe Litt wrote:
>>
>> So it looks like the new (r-internal) view is starting at the root when it
>> resolves -- ignoring what it has data for locally. It sorta works for
>
> You'll need a:
>
> zone "name" {
> type
On 09/10/2010 11:12 PM, Timothe Litt wrote:
So it looks like the new (r-internal) view is starting at the root when it
resolves -- ignoring what it has data for locally. It sorta works for
You'll need a:
zone "name" {
type forward;
forward only;
forwarders {
ips;
};
};
It won't
BIND isn't lying about having validated...
Other ideas?
-Original Message-
From: Mark Andrews [mailto:ma...@isc.org]
Sent: Thursday, September 09, 2010 22:06
To: Phil Mayers
Cc: bind-us...@isc.org
Subject: Re: DNSSEC, views & trusted keys...
In message <4c891404.3
Phil Mayers wrote:
> On 09/10/2010 03:05 AM, Mark Andrews wrote:
>>
>> In message<4c891404.3000...@imperial.ac.uk>, Phil Mayers writes:
>>> On 09/09/2010 03:45 PM, Timothe Litt wrote:
>>>
There is other advice in the ARM that says to put 'your organization's
public keys in the truste
On 09/10/2010 03:05 AM, Mark Andrews wrote:
In message<4c891404.3000...@imperial.ac.uk>, Phil Mayers writes:
On 09/09/2010 03:45 PM, Timothe Litt wrote:
There is other advice in the ARM that says to put 'your organization's
public keys in the trusted-keys list'. That doesn't help - and in f
In message <4c891404.3000...@imperial.ac.uk>, Phil Mayers writes:
> On 09/09/2010 03:45 PM, Timothe Litt wrote:
>
> >
> > There is other advice in the ARM that says to put 'your organization's
> > public keys in the trusted-keys list'. That doesn't help - and in fact,
> > confuses me even more s
On 09/09/2010 03:45 PM, Timothe Litt wrote:
There is other advice in the ARM that says to put 'your organization's
public keys in the trusted-keys list'. That doesn't help - and in fact,
confuses me even more since example.net has TWO different public keys - one
for each view. And trusted-key
I have 9.7.1-P2 running and since it's supposed to be 'for humans', I guess
I'm trying to determing if I am one. It's not going as well as hoped... :-)
I have a domain - example.net, with two views, the usual 'internal' and
'external'; a third is planned. The master maintaining all the sub-domai
13 matches
Mail list logo
