a "particular benefit" above. Another benefit
> is that maintaining lists of "authorized" slaves, potentially on a
> zone-by-zone basis, complicates named.conf and, as we all know, complicated
> configs lead to a higher risk of error, which can itself lead itself to
> secur
gs lead to a higher risk of error, which can itself
lead itself to security breaches.
- Kevin
--Original Message--
From: Res
Sender: [EMAIL PROTECTED]
To: Jefferson Ogata
Cc: bind-users@lists.isc.org
Subject: Re: Secondary and TLD not updating
Sent: Nov 17, 2008 4:20 PM
On Mon, 17 Nov 20
Res wrote:
On Mon, 17 Nov 2008, Jefferson Ogata wrote:
On 2008-11-17 14:25, Holger Honert wrote:
Chris Thompson schrieb:
On Nov 17 2008, Res wrote:
Ack! allow-transfer should never be any
What, never? Why not?
Security issue! You really want everyone to download your zone(s)?
I couldn'
al Message--
From: Res
Sender: [EMAIL PROTECTED]
To: Jefferson Ogata
Cc: bind-users@lists.isc.org
Subject: Re: Secondary and TLD not updating
Sent: Nov 17, 2008 4:20 PM
On Mon, 17 Nov 2008, Jefferson Ogata wrote:
> On 2008-11-17 14:25, Holger Honert wrote:
>> Chris Thompson schrieb:
>
On 2008-11-17 22:20, Res wrote:
On Mon, 17 Nov 2008, Jefferson Ogata wrote:
On 2008-11-17 14:25, Holger Honert wrote:
Chris Thompson schrieb:
On Nov 17 2008, Res wrote:
Ack! allow-transfer should never be any
What, never? Why not?
Security issue! You really want everyone to download your
On 2008-11-17 14:25, Holger Honert wrote:
Chris Thompson schrieb:
On Nov 17 2008, Res wrote:
Ack! allow-transfer should never be any
What, never? Why not?
Security issue! You really want everyone to download your zone(s)?
I couldn't care less. If the security of my systems were the least
Ack! allow-transfer should never be any
What, never? Why not?
Security issue! You really want everyone to download your zone(s)?
That is a decision for each operator to make. The ability to
transfer a zone is not by itself a security issue.
I guess the question is, what information can be
In message <[EMAIL PROTECTED]>, Holger Honert writes:
> This is a multi-part message in MIME format.
> --090609000409090603090005
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
>
> Chris Thompson schrieb:
> > On Nov 17 2008, Res wrote:
Chris Thompson schrieb:
On Nov 17 2008, Res wrote:
On Sun, 16 Nov 2008, Jeff Justice wrote:
Well, first part solved. I forgot to change the IP address of our
nameserver at the registrar. Secondary is still not updating though.
options { directory "/opt/local/etc/named/";
listen-on po
On Nov 17 2008, Res wrote:
On Sun, 16 Nov 2008, Jeff Justice wrote:
Well, first part solved. I forgot to change the IP address of our nameserver
at the registrar. Secondary is still not updating though.
options { directory "/opt/local/etc/named/";
listen-on port 53 { 127.0.0.1;74.
Seems there were two problems. Part one, my failure to update the IP
address to our new NS at the registrar. Duh! Second, the serial
number on the secondary was higher than the master. How it got that
way, I'm not sure, but I suspect it is because I was using incremental
and the seconda
Can you run "dig @MASTER_DNS_SERVER_ADDR YOUR_ZONE axfr" and get
anything? Can you do this from the slave? If not, you have zone
transfers disabled in your configuration. Your clip of your
configuration would say that transfers are allowed but without seeing
the whole thing we can't say
Well, first part solved. I forgot to change the IP address of our
nameserver at the registrar. Secondary is still not updating though.
Jeff J.
On Nov 16, 2008, at 3:16 PM, Jeff Justice wrote:
I recently moved our DNS from QuickDNS to BIND 9.5.0-P2 on OSX.
Everything appears to be respondi
I recently moved our DNS from QuickDNS to BIND 9.5.0-P2 on OSX.
Everything appears to be responding correctly when the server is
queried, however our secondary is not updating (secondary is hosted by
another provider) and the TLD's keep showing the old ns IP after a
week. I deleted the zon
14 matches
Mail list logo
