Hi,
I have what I hope is an easy question:
When settingup a 'stub' zone, is it only valid to list the primary
server for the zone in the 'masters {...};' config line?
Or is it OK to list secondary servers in that list also?
-Kyle
___
bind-users ma
recently, a question came up about "stub" zones came up and what they are and
are they part of the DNS standards or are they a good idea. i said, they are
evil and should not be used if you can avoid it. they way I understand them is
the are when you create local zones for zones y
It's perfectly valid to list any or all of the zone's authoritative
servers, whether they are primary master or slave.
Chris Buxton
Professional Services
Men & Mice
On Jan 19, 2009, at 1:40 PM, Kyle McDonald wrote:
Hi,
I have what I hope is an easy question:
When settingup a 'stub' zone, i
to your nameserver.
Since you asked the question, what would you propose as an alternative
for folks running multiple sets of nameservers with different info on them?
John
On 06/02/2014 04:52 PM, Nex6|Bill wrote:
so, stub zones allow you to point a zone to a different name server, and
that
.
>
>Since you asked the question, what would you propose as an alternative
>for folks running multiple sets of nameservers with different info on them?
>
>John
>
>
>On 06/02/2014 04:52 PM, Nex6|Bill wrote:
>> so, stub zones allow you to point a zone to a different name
The typical use case for a stub zone is where the delegation chain is
broken, or incorrect, but you don't want to incur the overhead of
slaving the zone (or some other sort of bureaucratic snafu like the
owner/admin of the zone not letting you do zone transfers).
As a general rule, stub
In message <1401739377.33916.yahoomail...@web163502.mail.gq1.yahoo.com>, Nex6|B
ill writes:
>
> recently, a question came up about "stub" zones came up and what they are
> and are they part of the DNS standards or are they a good idea. i said,
> they are evil and s
So... without stub zones, you know the drill: your local resolver follows
delegation, starting from the root nameservers. Delegation happens, and
life is good. If you're running views, then things work fine as well: your
view just needs to be configured to allow queries from your local reso
On 02/06/2014 23:38, John Miller wrote:
> So... without stub zones, you know the drill: your local resolver
> follows delegation, starting from the root nameservers. Delegation
> happens, and life is good. If you're running views, then things work
> fine as well: your view
On 06.06.14 11:50, Cathy Almond wrote:
And not forgetting that with recent versions of BIND, you have 'stub'
and you have 'static-stub'.
The difference is that with static-stub, if the NS/A/ records
returned by the authoritative server you've pointed your resolver at
don't match the addresse
Good evening,
my freshly recrafted DNS servers got the latest BIND 9.18 pkg from FreeBSD.
They're all supposed to only respond for a certain set of zones to the outside,
but should be able to be used as a resolver from localhost.
The pkg comes with a default config that slaves "." and its cousins
Hi All,
I am in the process of migrating all of our client facing resolver hosts back
to BIND (from unbound) and have hit a roadblock.
I wanted to confirm if I have missed something in my BIND configuration or I
have hit some sort of limitation in BIND.
It appears as if BIND is ignoring the sta
I'm seeing something I didn't expect in BIND's behavior, and I wanted to get
confirmation from someone that this is expected, or at least a known limitation.
If an authoritative server is configured to send minimal responses, will a stub
zone get all the necessary data from that server? What I'm
On Sun, Nov 19, 2023 at 09:10:13PM +, Elmar K. Bins wrote:
! my freshly recrafted DNS servers got the latest BIND 9.18 pkg from FreeBSD.
! They're all supposed to only respond for a certain set of zones to the
outside,
! but should be able to be used as a resolver from localhost.
!
! The pkg
On 20/11/2023 1:00 pm, Peter wrote:
It's tricky. One problem is these are slave zones, they are
authoritative and do not work well with DNSSEC.
I'm curious... What issues did you have with these zones and DNSSEC? I
would have expected that the signed zones should just work?
Nick.
--
Visit h
Have you looked at mirror zones for root?
Zone type "mirror" = it's appropriate for "." but not for other zones.
(Oh - and don't forget to disable ixfr for this zone when you do that -
it's more efficient for the validation step)
Details in the BIND ARM.
Cathy
On 19/11/2023 21:10, Elmar K.
Hi Cathy :-)
cat...@isc.org (Cathy Almond) wrote:
> Have you looked at mirror zones for root?
No... post-1990, what do I know about them ;-)
I did read up in the docs; it does not mention access control, which I would
like to behave just like "hint" zones (only respond to requests coming from a
On Mon, Nov 20, 2023 at 03:30:13PM +1300, Nick Tait via bind-users wrote:
! On 20/11/2023 1:00 pm, Peter wrote:
! > It's tricky. One problem is these are slave zones, they are
! > authoritative and do not work well with DNSSEC.
!
! I'm curious... What issues did you have with these zones and DNSSE
This is partially addressed in the upcoming maintainence release.
diff --git a/lib/bind9/check.c b/lib/bind9/check.c
index 5d95eda..5891255 100644
--- a/lib/bind9/check.c
+++ b/lib/bind9/check.c
@@ -1324,8 +1324,10 @@ check_zoneconf(const cfg_obj_t *zconfig, const cfg_obj_t
*voptions,
{
-Original Message-
From: Mark Picone
Date: Thursday, August 23, 2012 10:45 PM
To: "bind-users@lists.isc.org"
Subject: Static-stub zones and forwarding
>Hi All,
>
>I am in the process of migrating all of our client facing resolver hosts
>back to BIND (from u
m: Mark Andrews [mailto:ma...@isc.org]
Sent: Friday, 24 August 2012 3:58 PM
To: Mark Picone
Cc: bind-users@lists.isc.org
Subject: Re: Static-stub zones and forwarding
This is partially addressed in the upcoming maintainence release.
diff --git a/lib/bind9/check.c b/lib/bind9/check.c index 5d95eda.
Chris Buxton wrote:
>
> If an authoritative server is configured to send minimal responses, will
> a stub zone get all the necessary data from that server? What I'm seeing
> is, the recursive server sends an SOA query; the response contains only
> the SOA record, and no NS or A records. The recurs
On Jun 12, 2013, at 5:23 AM, Tony Finch wrote:
> Chris Buxton wrote:
>>
>> If an authoritative server is configured to send minimal responses, will
>> a stub zone get all the necessary data from that server? What I'm seeing
>> is, the recursive server sends an SOA query; the response contains on
$ dig -tsoa localhost de. @`hostname`
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20230
| localhost. 86400 IN SOA localhost.
| -
| ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 11403
| ;de.IN SOA
[test
;' in the static-stub zone, I
get a REFUSED for clients not enabled in a).
[...]
How can I enable recursive queries for 'static-stub' zones?
static-stub only points server to other servers to look up, therefore it
needs recursion too.
Do you want to provice RFC2318 zones for any
;
>>Although I have set 'allow-query { any; };' in the static-stub zone, I
>>get a REFUSED for clients not enabled in a).
> [...]
>>How can I enable recursive queries for 'static-stub' zones?
>
> static-stub only points server to other servers to look u
et 'allow-query { any; };' in the static-stub zone, I
> >>get a REFUSED for clients not enabled in a).
> > [...]
> >>How can I enable recursive queries for 'static-stub' zones?
> >
> > static-stub only points server to other servers to look up, t
Mark Andrews writes:
> Firstly allow-query on a static stub does nothing.
ok; thx for clarifying
> You should be a master for 31-24.2.1.10.in-addr.arpa and a slave for
> 2.1.10.in-addr.arpa.
Unfortunately, our ISP (Deutsche Telekom) does not allow AXFR of the
/24 zone. I solved it now by dec
Enrico Scholz wrote:
>
> Unfortunately, our ISP (Deutsche Telekom) does not allow AXFR of the
> /24 zone. I solved it now by declaring an external (non-recursive)
> and internal (recursive) view, where the external one is a master
> for 2.1.10.in-addr.arpa covering only our 31-24 range. This wil
Hi Folks,
What does 'lame-servers: error (chase DS servers) resolving [...]'
really mean, and is it really an error?
It seems to be: pause the current resolution whilst I start another
round to fetch a (DS) record from the parent zone, but once that
completes, everything works out.
In particular
that
> completes, everything works out.
>
> In particular, I see this for the first resolution within a static-stub
> zone.
I am not getting this error in my logs. I have a number of static-stub
zones; the interesting ones wrt DS chasing are cam.ac.uk (signed) and
private.cam.ac.uk
b
>> zone.
>
> I am not getting this error in my logs. I have a number of static-stub
> zones; the interesting ones wrt DS chasing are cam.ac.uk (signed) and
> private.cam.ac.uk (unsigned).
Are these static-stub zones configured with 'server-names'? Ours are
'ser
Graham Clinch wrote:
>
> Are these static-stub zones configured with 'server-names'? Ours are
> 'server-addresses'
Mine use server-addresses too.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Cromarty, Forth: Northwesterly 4 or 5, occasionally 6 in east at f
33 matches
Mail list logo
