Dear Valued DHCP and BIND user community
Happy New Year. ISC is planning on more communication with our users in
the new year, and this notice is to let you know about upcoming
End-of-Life (EOL) dates so your organization can plan for upgrades.
ISC's Extended Support Versions (ESV) are meant for
On 1/7/2011 3:08 PM, blr maani wrote:
> 1. For each zones, check serial number on both master(s) and slave(s)
> for the zone and compare it. Report mismatch if any.
dig +nssearch
AlanC
signature.asc
Description: OpenPGP digital signature
___
bind-u
You can develop scripts to do the following:
Develop script(s) and run on a host which has access to both Master(s) and
Slave(s). The script should do the following:
1. For each zones, check serial number on both master(s) and slave(s) for
the zone and compare it. Report mismatch if any.
2. If yo
greetings,
Linux ns2.arlut.utexas.edu 2.6.18-194.26.1.el5 #1 SMP Fri Oct 29 14:21:16 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux
bind-9.3.6-4.P1.el5_5.3
(i'm not crazy about running that version of bind, but the choice
isn't entirely mine.)
this has to be an old question, but when i search for it i
Slightly OT, if the test is performed really from outside, it will also
catch a number of other problems like network issues etc. Some of these
issues might look like a DNS issue but with a different root cause,
maybe even happening outside your own network.
On 07/01/11 16:27, Bryan Bradsby wrote
For zones where we provide all the masters and slaves, the external
perspective of an outside testing site is crucial to ensuring that we
have not missed anything, especially after a change.
We find an emphasis on scripts monitoring the log files works best for
zones where we are not providing ma
In message <4d271802.5030...@gmail.com>, Gary Wallis writes:
> Thanks guys for all the feedback.
>
> Yes seems like RIPE is involved, and The Planet (TP) refuses to fix
> delegation or say they can't 'cause of RIPE, but sounds funny to me, and
> I know that many TP tech support staffers know ne
Perhaps if dnssecnsec3qatestdomain.com existed we would be able to
tell you. As it is there is not enough information here to workout
what is broken.
In message , rams
writes:
>
> I have trouble resolving the host name dnssecnsec3qatestdomain.com. which is
> NSEC3 signed. This is the parent a
Thanks guys for all the feedback.
Yes seems like RIPE is involved, and The Planet (TP) refuses to fix
delegation or say they can't 'cause of RIPE, but sounds funny to me, and
I know that many TP tech support staffers know next to nil about DNS.
Have fun with DNS in 2011. Cheers!
Gary
I have trouble resolving the host name dnssecnsec3qatestdomain.com. which is
NSEC3 signed. This is the parent and child zone. If I run dig ( dnssec
query) with the +cd option I which is a proper response:
[r...@stulcqanusbind1 ~]# dig dnssecnsec3qatestdomain.com. any +dnssec *+cd
*
; <<>> Di
> Niall O'Reilly writes:
>> If your zones are properly delegated, and your servers accessible
>> from the public Internet, then the web-based remote-checking tools
>> available at www.zonecheck.fr or dnscheck.iis.se are excellent.
>> Either of these will give you some ideas abo
Niall O'Reilly writes:
If your zones are properly delegated, and your servers accessible
from the public Internet, then the web-based remote-checking tools
available at www.zonecheck.fr or dnscheck.iis.se are excellent.
Either of these will give you some ideas a
On 7 Jan 2011, at 09:10, p...@mail.nsbeta.info wrote:
> I just want to write a script for checking master and slave to make sure they
> have been always syncing the data correctly. What's the idea for doing it?
Initial condition:
dig @master zone SOA
dig @slave zone SOA
Hello,
I just want to write a script for checking master and slave to make sure
they have been always syncing the data correctly. What's the idea for doing
it?
Thanks.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mai
> Phil Mayers writes:
>> Delegation nameservers above differ from nameservers in-zone below
>>>
>>> 147.95.81.in-addr.arpa. 86400 IN NS ns2.callingcloud.net.
>>> 147.95.81.in-addr.arpa. 86400 IN NS ns1.callingcloud.net.
>>> ;; Received 96 bytes from 207.218.247.135#53(ns1.
> Torinthiel writes:
>> If you know which zone has changed, than you can do "rndc reload zonename".
>> If you don't, than "rndc reload" reloads all zones.
>> You could also try "rndc reconfig", but I think it will only load new
>> zonesm the ones just added in configuration, not never wersions of
On 31.12.10 12:33, p...@mail.nsbeta.info wrote:
> Is it a right way to run rsync for bind's zone files replication?
> If we have dozons of zones, each zone has more than one view,
you mean, each zone appears in more than one view?
> under this
> case setup the master/slave with standard zone-t
17 matches
Mail list logo
