Please ignore. Internal test from ISC.
-Dan Mahoney
ISC Operations
___
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
On Tue, 1 Nov 2011, Paul Wouters wrote:
There have been discussions in the past over this, but we were once again
bitten by this dnssec-signzone bug:
Tue Nov 1 12:11:28 2011 signDomain: sign command:
/usr/sbin/dnssec-signzone -C -u -r /dev/random -t -o openswan.org -f
/var/tmp/openswan.org
On Tue, 1 Nov 2011, Paul Wouters wrote:
There have been discussions in the past over this, but we were once again
bitten by this dnssec-signzone bug:
Tue Nov 1 12:11:28 2011 signDomain: sign command: /usr/sbin/dnssec-signzone
-C -u -r /dev/random -t -o openswan.org -f /var/tmp/openswan.org.
On 1 Nov 2011 at 20:02, Phil Mayers wrote:
> On 11/01/2011 06:34 PM, Scott Morizot wrote:
>
> > Alternatively, you can sign 'policydomain.internal' and configure its key
> > as one of the trust anchors on the validating name servers. The order of
> > validation is, if I recall correctly, locally
On 11/1/2011 3:02 PM, Phil Mayers wrote:
On 11/01/2011 06:34 PM, Scott Morizot wrote:
Alternatively, you can sign 'policydomain.internal' and configure its key
as one of the trust anchors on the validating name servers. The order of
validation is, if I recall correctly, locally configured trust
On 11/1/2011 3:00 PM, Phil Mayers wrote:
On 11/01/2011 06:24 PM, Lyle Giese wrote:
A work-around (and it has some side effects and could be undesirable,
just be aware of the side effects of doing this) is to declare .internal
as a master zone in your DNS servers and then delegate
policydomain.i
On 11/01/2011 06:34 PM, Scott Morizot wrote:
Alternatively, you can sign 'policydomain.internal' and configure its key
as one of the trust anchors on the validating name servers. The order of
validation is, if I recall correctly, locally configured trust anchors,
then chain of trust from root, a
On 11/01/2011 06:24 PM, Lyle Giese wrote:
A work-around (and it has some side effects and could be undesirable,
just be aware of the side effects of doing this) is to declare .internal
as a master zone in your DNS servers and then delegate
policydomain.internal to your Windows AD servers in your
There have been discussions in the past over this, but we were once again
bitten by this dnssec-signzone bug:
Tue Nov 1 12:11:28 2011 signDomain: sign command: /usr/sbin/dnssec-signzone -C
-u -r /dev/random -t -o openswan.org -f /var/tmp/openswan.org.sign.tmp -i
1296000 -e +2592000 -j 129
On 1 Nov 2011 at 18:12, vinny_abe...@dell.com wrote:
> Thanks, however I can't control the domain in question
> unfortunately. It is what it is. We have to work with it. I totally
> understand why this doesn't work and actually agree with the design,
> however I just don't have a workaround or way
On 11/1/2011 11:23 AM, Phil Mayers wrote:
On 01/11/11 16:14, vinny_abe...@dell.com wrote:
resolution fail since NXDOMAIN is the valid answer... done, end of
story. I thought the forwarder type would bypass this but apparently
I am wrong. Is there some other way to handle this for non-existent
d
Hi Phil,
Thanks, however I can't control the domain in question unfortunately. It is
what it is. We have to work with it. I totally understand why this doesn't work
and actually agree with the design, however I just don't have a workaround or
way to force forwarders for this domain with dnssec
If you get the EDNS errors for many or most remote name servers, look to your
firewall as a suspected culprit. Otherwise, a few of these messages are normal.
You might be able to set query-source (and other *-source) options to just IPv4
addresses to disable use of IPv6. However, this shouldn't
On 01/11/11 16:14, vinny_abe...@dell.com wrote:
resolution fail since NXDOMAIN is the valid answer... done, end of
story. I thought the forwarder type would bypass this but apparently
I am wrong. Is there some other way to handle this for non-existent
domains just for testing purposes?
Don't d
Hello,
I have DNSSEC validation running on a caching name server which is working
fine. In addition, I have tried to add an entry in the named.conf to forward
lookups for a local Active Directory domain name used for testing purposes so
we can easily resolve the handful of servers in this domai
I did get a chance to dig through the syslogs finally on one of the
internal name servers and I'm seeing a lot of these three entries for
various domains. I would have to assume that one or all of these items
would also contribute to the lengthy times to resolve queries?
named[16593]: error (net
Hi,
I seem to have hit the same issue on Bind 9.7.3.
=== [Test environment] ===
- The issued system is cache server. It does not have a zone which it
can respond as a master server.
- The server which receives a recursive query asks a recursive query
from root server to the last server in order
If a given forwarder is "bad " it get its round trip time, rtt, set high
and will not be used until that comes back down via the normal rtt decay
mechanism in BIND. I have not tested the behaviour when all are down. My
assumption would be that if all are down they will all have to be tried
before g
Ben,
I seem to recall reading at some point in the past that after X amount of
time, BIND would stop trying to contact servers it figured to be dead (at
least it would stop trying for some amount of time). Is that in fact the
case and would it eventually come into play here? Any configurable opt
If you have a global forwarder in place there are two options that affect
its use. Forward first, the default, and forward only.
Forward first will exhaust the forwarders you have and then attempt to
follow NS records. Forward only will only use forwarders.
The delay you are seeing is likely the d
We recently tried a test to see how our internal servers would react to a
loss of their external peers, with the goal being that the internal servers
would switch from forwarding to doing recursive queries for clients.
Normally, the internal servers forward to the external servers. To
simulate th
21 matches
Mail list logo
