On 11/24/2011 20:10, Loganathan Thirukkumaran wrote:
Hello All,
We have our slave servers running compiled Bind 9.6.1-P3 on CentOS 5.4.
Can I upgrade to 9.8.1-P1 directly from the current version 9.6.1-P3?
Or It has to be on the same 9.6.ESV-R5-P1 latest version?
Should be Ok unless
On 11/24/2011 20:10, Loganathan Thirukkumaran wrote:
Master is in internal running on Bind 9.2.1,
On 25.11.11 00:14, Doug Barton wrote:
You want to update this one as well. I know that the theory is that it's
hidden, but the first time an attacker finds it, it's going to get 0wn3d.
not
Hello,
Just for my curiosity:
Is it possible to update DNSSEC-signed domain, re-sign and generate
small differencies to be transferred by IXFR?
Does it apply with dynamic updates, and with manually configur4ed
zones (via ixfr-from-differencies turned on)?
OT: if anyone uses opendnssec,
On 11/25/2011 00:38, Matus UHLAR - fantomas wrote:
not mentioning new features (mostly DNSSEC related) that new servers have.
The OP explicitly excluded DNSSEC, but, yeah. :)
--
We could put the whole Internet into a book.
Too practical.
Breadth of IT
Hi,
I am having a problem,
I am signing a zone with opendnssec,
After signing it seems fine and
If issue a
*dig @[dnssec-aware-recursive-server] [zone] +dnssec SOA*
from this [*dnssec-aware-recursive-server*]
And the answer is returned with RRSIGS and ad bit
But after some time if I issue
Matus UHLAR - fantomas uh...@fantomas.sk wrote:
Is it possible to update DNSSEC-signed domain, re-sign and generate small
differencies to be transferred by IXFR?
Yes, it just works with no special effort if you use dynamic updates and
auto-dnssec maintain.
Tony.
--
f.anthony.n.finch
Bryton bry...@tznic.or.tz wrote:
I wonder if anyone has ever got the error
In my logs I have some of this:
25-Nov-2011 11:23:00.332 dnssec: info: validating @0xabe00470: uofk.edu MX: bad
cache hit (uofk.edu/DNSKEY)
Which is fairly nicely explained by this:
On 11/25/2011 03:19 PM, Tony Finch wrote:
Bryton bry...@tznic.or.tz wrote:
I wonder if anyone has ever got the error
In my logs I have some of this:
25-Nov-2011 11:23:00.332 dnssec: info: validating @0xabe00470: uofk.edu MX:
bad cache hit (uofk.edu/DNSKEY)
Which is fairly nicely explained
On Fri, Nov 25, 2011 at 11:59 AM, Marek Kozlowski
kozlo...@mini.pw.edu.pl wrote:
Do I *have* to use views to deal with such distinction or can I specify
it just as above without views?
Pretty sure you have to use views, in the least doing so would likely
be the best good practice to follow.
Is it possible to update DNSSEC-signed domain, re-sign and generate
small differencies to be transferred by IXFR?
Does it apply with dynamic updates, and with manually configur4ed
zones (via ixfr-from-differencies turned on)?
It works fine with dynamic updates, and as of 9.9.0 it will
Do I *have* to use views to deal with such distinction or can I specify
it just as above without views?
You have to use views so that the server can decide which clients get
which responses. This you specify in a match-clients {} stanza within
the view.
-JP
Using managed-keys for the root zone and for dlv.isc.org can give one
a warm fuzzy feeling, given that their respective administrators have
declared an intention to follow RFC 5011 if they ever roll over their
KSKs.
Except, they never have changed their KSKs so far, so the relevant code
in BIND
given that their respective administrators have
declared an intention to follow RFC 5011 if they ever roll over their
KSKs.
As you say if they ever roll; I'm not placing any money on that. ;-)
I could of course set up such a test zone and try to perform an RFC 5011
rollover on it, using
Does anyone provide a zone with a trust anchor that is frequently rolled
over in that way, just so that one can see whether it really works? Then
one's feelings might be warmer and less fuzzy...
I looked at the DNSSEC section of the bind test suite
(bind-9.9.0b2/bin/tests/system/dnssec) to see
I looked at the DNSSEC section of the bind test suite
(bind-9.9.0b2/bin/tests/system/dnssec) to see if a key rollover test is
part of it. I didn't see that, but it may be elsewhere, as the test suite
is pretty elaborate. The test suite does contain a simulated root server
(ns1), so I bet
On 25/11/2011 16:59, Marek Kozlowski wrote:
Is it allowed to use a few `zone' clauses for a single domain? Is
something like this correct:
zone mickey.mouse.com in {
type master;
file pri/mickey-public.zone;
allow-query { any; };
allow-transfer { xfer; };
:-)
One more question:
The documentation for `match-clients' isn't comprehensive enough... Can
I add all host from, for example 172.16/16 except a single host? Does:
match-clients { 172.16.0.0/16;!172.16.1.1; }
form an AND or an OR?
Best regards,
/m
On 25/11/2011 23:36, Marek Kozlowski wrote:
One more question:
The documentation for `match-clients' isn't comprehensive enough... Can
I add all host from, for example 172.16/16 except a single host? Does:
match-clients { 172.16.0.0/16;!172.16.1.1; }
List the exception first, otherwise it
On 11/24/2011 11:21 AM, Jan-Piet Mens wrote:
Jeffry,
I have had a tendency to dig axfr from my Windows workstation
+1 to you for using `dig' on Windows; most don't even know it exists
and suffer the `nslookup' pain. ;-)
It comes with the Windows version of BIND9.
Danny
The documentation for `match-clients' isn't comprehensive enough... Can
I add all host from, for example 172.16/16 except a single host? Does:
match-clients { 172.16.0.0/16;!172.16.1.1; }
BIND checks the ACL in the order you specify. In your example,
172.16.1.1 will be allowed by the first
:-)
I have defined two views (let's call them an `internal' and an
`external') for my zones on the primary DNS server. Let's assume I'd
like the secondary DNS server to use the same two views synchronized to
the primary DNS. May I transfer *views* rather than zone description
files? May I transfer
May I transfer *views* rather than zone description files?
No. That's why it is called zone transfer. :)
May I transfer two zone description files for a single zone to a
single server?
Again no. (See previous thread on your request to serve two zone files
for the same zone in the one view;
22 matches
Mail list logo
