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
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
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.
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
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
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
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 (unsigned).
My setup led
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
Graham Clinch g.cli...@lancaster.ac.uk wrote:
Are these static-stub zones configured with 'server-names'? Ours are
'server-addresses'
Mine use server-addresses too.
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
Cromarty, Forth: Northwesterly 4 or 5, occasionally 6 in east
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
'server-addresses', and I imagine that the additional resolution
Enrico Scholz enrico.sch...@sigma-chemnitz.de 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
Mark Andrews ma...@isc.org 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
; };' 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.
ok; some more details. I have a '31-24.2.1.10
; };' 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 anyont or just for your
- opcode: QUERY, status: REFUSED, id: 11403
| ;de.IN SOA
[tested with bind-9.9.6-6.P1.fc21.x86_64 from Fedora 21 and
bind-9.9.4-14.el7_0.1.x86_64 from RHEL7]
How can I enable recursive queries for 'static-stub' zones?
Enrico
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.
ok; some more details. I have a '31-24.2.1.10.in-addr.arpa.' RFC2317 zone
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 just needs
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
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 you
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
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 name-server; to recurse to get
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 zones
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 should not be used if you can avoid
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 resolvers
Chris Buxton cli...@buxtonfamily.us 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
On Jun 12, 2013, at 5:23 AM, Tony Finch d...@dotat.at wrote:
Chris Buxton cli...@buxtonfamily.us 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
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
[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..5891255 100644
-Original Message-
From: Mark Picone mark.pic...@deakin.edu.au
Date: Thursday, August 23, 2012 10:45 PM
To: bind-users@lists.isc.org 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
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
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,
{
31 matches
Mail list logo
