Bind-users;
I have been asked to slave a /24 from a microsoft SOA, however, their
authority for the /24 is false in that they really only have authority
to 192/26.
Am I correct in that there is no way to slave said zone
[x.y.z.in-addr.arpa] but serve it as a different zone
[192/26.x.y.z.in-
Hello-
Our recursive nameservers are having trouble with .MIL today. I see
some public servers [8.8.8.8] are not. I am not running a dns-sec
enabled recursive resolver.
In the below I was expecting an 'ADDITIONAL' section, not based on the
DIG header, but based on expecting delegation glue
I recently [8/1/2009] upgraded to 9.5.1P3. Last evening there were two
brief moments that the named process was not resolving out of cache.
This is a recursive only server that is basically opened to all clients,
mostly for historical reasons. The named process recovered on its own.
While I
sure what ISC_R_NRESULTS
'invalid file' is trying to tell me. As before, the server seems to
recover, but DNS resolution does stop for about a minute.
-Michael
Michael Hare wrote:
I recently [8/1/2009] upgraded to 9.5.1P3. Last evening there were two
brief moments that the named
For those of us that are still running auth and recursive on the same
IP, I believe the benefit would be to deploy a best practices recursive
only nameserver on a different machine/IP address without getting, in my
case, possibly hundreds of thousands of clients to change their DNS
resolver IP
Well, except then you need to update all of your delegations. That can
not only be an administrative hassle, but can also get very expensive,
especially if you have hundreds of them in ccTLDs, where you have to pay
your "in-country agent" a fee for every registry change. It's quite a
racket.
Doesn't DDNS rely on a single SOA? If so, is there a best practice on
how to deal with this?
-Michael
On 4/8/2010 9:15 AM, Stephane Bortzmeyer wrote:
On Thu, Apr 08, 2010 at 01:18:33PM +0200,
Arnoud Tijssen wrote
a message of 14 lines which said:
Since everything nowadays is dependant
Agreed, using outdated built in hints and diligent logging does cause a minor
annoyance (minor as it can be filtered after verifying the incident), so there
is merit in updating even if automatic updates might not make sense. For
example, an unfiltered log from a production resolver of ours wou
+1 to Alan. While I work at an ivory tower and support Mark's mission, in
practice I don't have operational time (nor is it necessarily the best use of
my time) to maintain a per-ip bypass.
100% in support of enabling this by default as long as their as an option to
disable.
-Michael
> -
Hello-
Sorry for the wide blast (and long email), but perhaps some fellow .edu's can
help us through this one.
I'm one of the DNS admins for wisc.edu. An academic group on campus has
noticed an issue with the atecentral.net delegation, for which two of the
listed NS are on campus.
[]$ dig at
10 matches
Mail list logo
