Please allow a, partly/mostly, non-technical feedback
as security officer for a tld (.eu)
First of all : I do not deny DNSSEC adds a challenge for administrators.
They must understand that adding this additional SECurity aspect,
will generate extra work (keygeneration/re-generation/signing and
So it sounds like in this case, stub zones don't buy me anything? What I
wanted was for this secondary to query the subdomain name servers directly
instead of relying on the domain primary via forwarding. Is making this
server a secondary for the subdomain the only way?
_
From: Nex6
On Tue, Feb 28, 2012 at 01:16:16PM +0100, Marc Lampo wrote:
Please allow a, partly/mostly, non-technical feedback
as security officer for a tld (.eu)
First of all : I do not deny DNSSEC adds a challenge for administrators.
They must understand that adding this additional SECurity aspect,
Original Message
Subject: RE: Configuring a domain slave to look up subdomain hosts
From: "Mike Bernhardt" bernha...@bart.gov
Date: Tue, February 28, 2012 10:15 am
To: bind-users@lists.isc.org, "'Mark Andrews'" ma...@isc.org
So it sounds like in this case, stub zones
Yes, you are confused :-)
I am simply trying to get the domain slave to make queries for hosts in the
subdomain which is hosted on other servers, instead of forwarding the
queries to the domain master. I thought a stub zone would facilitate this by
giving my server the lookup information it
On 2/28/12 9:26 AM, /dev/rob0 r...@gmx.co.uk wrote:
On Tue, Feb 28, 2012 at 01:16:16PM +0100, Marc Lampo wrote:
First of all : I do not deny DNSSEC adds a challenge for administrators.
They must understand that adding this additional SECurity aspect,
will generate extra work
I suppose there are different classes of failures; unfortunately on
the resolver, there is only one result, SERVFAIL, to cover all. It
would be better if there was a way to distinguish the oops, admin
bungled DNSSEC errors from the ones which are more likely to be
indicative of spoofing.
On Feb 28, 2012, at 10:04 AM, Mike Bernhardt wrote:
Yes, you are confused J
I am simply trying to get the domain slave to make queries for hosts in the
subdomain which is hosted on other servers, instead of forwarding the queries
to the domain master. I thought a stub zone would
Why not set up the zone with its own forward statement like this:
zone subdomain.example.com {
type forward;
forwarders { 10.172.2.50; 10.172.2.51; };
forward only;
};
--
bind-users-bounces+wbrown=e1b@lists.isc.org wrote on 02/28/2012
01:04:46 PM:
I am simply
Perhaps this article from the ISC knowledge base will help:
https://kb.isc.org/article/AA-00302/47/I-want-to-forward-all-DNS-queries-from-my-caching-nameserver-to-another-server-but-configure-exceptions-for-some-domains-how.html
Confidentiality Notice:
This electronic message and any
Forwarding was disabled for the parent zone, but it still didn't work.
That's why I asked the question. I was doing one or the other, and trying to
get rid of forwarding to the domain master. I have it on in global options
because we don't let internal name servers go to the root; they forward to
So, it seems that the stub zone only works as I expected if I disable ALL
forwarding- not just in the parent zone but also in global options. Is that
the expected behavior for a stub zone? It's not consistent with what you
said below.
_
From: Mike Bernhardt [mailto:bernha...@bart.gov]
Hello all,
Recently I’ve started getting numerous errors in my logs of the form:
Feb 24 15:12:50 server named[3511]: validating @0xb8976b78: com SOA: got
insecure response; parent indicates it should be secure
Feb 24 15:12:50 server named[3511]: error (no valid RRSIG) resolving
Sorry, my mistake. Apparently, it needs to be overridden (disabled) in each
affected zone, not just at the domain apex.
If you leave out the stub zones entirely and disable forwarding in the parent
zones, it should work. That way, the server is simply following delegations,
rather than relying
Original Message
Subject: Re: Configuring a domain slave to look up subdomain hosts
From: Chris Buxton chris.p.bux...@gmail.com
Date: Tue, February 28, 2012 4:58 pm
To: Mike Bernhardt bernha...@bart.gov
Cc: bind-users@lists.isc.org
Sorry, my mistake. Apparently, it needs to
Stub zones record the NS list and associated address records for
the zone. Think of it as pre-populating the cache.
Forwarder clauses override the normal recusive resolution process.
A empty forwarders clause disables the override for names at or
below the zone it appears in.
These are
In message cb725c9f.24ec1%micho...@cisco.com, michoski writes:
Doing DNSSEC verification in 2012 is lopsided the other way. You
cannot resolve the names you need sometimes. You're probably not
receiving any actual protection from spoofing.
I feel similarly. I do see risk in the non
On Tue, Feb 28, 2012 at 06:28:54PM +, Evan Hunt wrote:
the one that bites us most often is that of the expired RRSIG. If
we could log that but go ahead and accept the data, most of the
pain would stop.
BIND has this: dnssec-accept-expired yes; Note that it opens you
to replay
Hi Rob,
VeriSign contact as the operator of g.gtld-servers.net in CC.
I think your resolver is noticing the right thing here. When running multiple
queries against this server I occassionally receive a response that indeed has
no signatures:
$ dig @192.42.93.30 google.com +dnssec +norec
;
In message c9506136-4a8d-4891-ab20-105b05dc0...@ausregistry.com.au, Wolfgang N
agele writes:
Hi Rob,
VeriSign contact as the operator of g.gtld-servers.net in CC.
I think your resolver is noticing the right thing here. When running multip=
le queries against this server I occassionally
Have seen some anycast DNS implementations using more than one address, some
times even on the same subnet, any considerations or reasons for doing that? ___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
21 matches
Mail list logo
