Hello,
Since enabling the root TA in my resolver, I keep seeing from time to time:
21-Jul-2010 08:52:27.929 dnssec: debug 3: validating @0x134fe7e8: .
SOA: attempting insecurity proof
21-Jul-2010 08:52:27.929 dnssec: debug 3: validating @0x134fe7e8: .
SOA: insecurity proof failed
21-Jul-2010
On Wed, 21 Jul 2010 09:20:21 +0200, Gilles Massen
said:
> Hello,
> Since enabling the root TA in my resolver, I keep seeing from time to time:
> 21-Jul-2010 08:52:27.929 dnssec: debug 3: validating @0x134fe7e8: .
> SOA: attempting insecurity proof
> 21-Jul-2010 08:52:27.929 dnssec: debug 3:
> BIND 9.7.1-P2 is a maintenance release for BIND 9.7.
>
Just an FYI, there are SMF aware packages for bind 9.7.1-P2 avail from the
Blastwave mirrors now. All world wide mirrors will sync within hours but
the primary ( at ISC ) is at http://download.blastwave.org
Please use pkgutil to fet
Hi All,
I am a newbie in BIND. I want to ask for your help on how to upgrade the BIND
version of my DNS. I am using Solaris 10 SPARC and my current BIND version is
BIND 9.6.0-P1. I am planning to upgrade to the latest BIND version, BIND
9.7.1-P2. What are the requirements and procedure for the
Hi
Well i wonder this is the right place. What server characteristics you
recomend me as minimum for a bind that will get about
1 req/sec
Linux OS.
LD
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/b
After specifying MX records for a 2nd tier domain, is it necessary to
restate the MX records for a new $ORIGIN? For example, if I have:
$ORIGIN .
...
IN MX 10 mx1.example.com.
IN MX 10 mx2.example.com.
IN MX 10 mx3.examp
After doing some additional reading, I have another question related to
the MX records.
Using the forward and forwarders statements as follows I could
potentially remove the NS statements for the sub-domains which redirect
queries to the GSLB devices:
forward first;
forwarders { gss1; gss2; };
H
On 7/21/2010 1:15 PM, Atkins, Brian (GD/VA-NSOC) wrote:
After specifying MX records for a 2nd tier domain, is it necessary to
restate the MX records for a new $ORIGIN? For example, if I have:
$ORIGIN .
...
IN MX 10 mx1.example.com.
IN MX 10 m
On 7/21/2010 2:01 PM, Kevin Darcy wrote:
On 7/21/2010 1:15 PM, Atkins, Brian (GD/VA-NSOC) wrote:
After specifying MX records for a 2nd tier domain, is it necessary to
restate the MX records for a new $ORIGIN? For example, if I have:
$ORIGIN .
...
IN MX 10 mx1.example.
This is admittedly not a bind question, but it has
become a major nag factor and I am not sure what to recommend.
We delegate our Microsoft Active Directory zone to
Microsoft domain controllers and they have stuffed their zone
with about 750 AAA records and all are publicly visible
In message <19526.43429.234698.104...@hadron.switch.ch>, Alexander Gall writes:
> On Wed, 21 Jul 2010 09:20:21 +0200, Gilles Massen
> said:
>
> > Hello,
> > Since enabling the root TA in my resolver, I keep seeing from time to time:
>
> > 21-Jul-2010 08:52:27.929 dnssec: debug 3: validating
Does anyone know if there have been problems with the USADOTGOV.NET root name
servers today?
We've had people complaining about resolving RADAR.WEATHER.GOV and several
systems in the NOAA.GOV domain. If you query for the NS resource records, you
only receive the ANSWER section. The ADDITIONAL
Hi,
I am new to socket programming. Please help me with a situation.
The function call connect (non -blocking) is failing with setting the
errorcode as 36 (EINPROGRESS). I have checked all the relative things.
They are set properly.
::connect(sd, ((struct sockaddr*) (void*) &(proxyDataPtr->re
13 matches
Mail list logo
