www.21photo.cn resolution failed on my dns, bind returned SERVFAIL,
this is my trace using "named -u named -d 2 -g". It seems like that
bind use IPv6 first, while there's no IPv6 configed, bind just
returns SERVFAIL, instead of resolve using IPv4 address. How can I fix
this?
02-Feb-2012 14:00:57.
After Doug updated the port for FreeBSD, I have downloaded it, let it
build, and I have been running the rc2 release for the past day or so here,
with no problems. I also went in and updated the serials on several of the
domains that I am using inline-signing with, and then just did a basic 'rn
On Wed, Feb 01, 2012 at 11:51:55PM +, Spain, Dr. Jeffry A. wrote:
> > Any suggestions, folks? What am I not understanding?
>
> Michael: To determine why there is no DNSSEC information being returned by
> your dig query, consider the following:
>
> What are the timestamps in your key metadata
> Any suggestions, folks? What am I not understanding?
Michael: To determine why there is no DNSSEC information being returned by your
dig query, consider the following:
What are the timestamps in your key metadata? Are they currently published and
active?
nstest/etc/namedb/keys;dnssec-settime
Hi,
I'd put off DNSSEC because of the high maintenance requirement. But
with 9.9 and inline signing, it looks like I can now do DNSSEC the way
I need (static zone files that work with legacy tools, automatic key
rotation, etc.)
I see that 9.9-rc2 came out yesterday; I'm building it now, but I
don
On 02/01/2012 01:52, Phil Mayers wrote:
> There's no need for the keyfile to be writeable by bind (at the moment,
> at any rate). So root:bind and 0640 seem more appropriate to me.
This makes more sense to me as well. Assume for the moment that an
attacker gains access as user bind. I really don't
Key management (and how BIND 9 in the form of named handles issues like this)
is likely too large a topic to address before 9.9.0 is out. I don't think the
management has gotten worse from 9.8 to 9.9 though.
We're hoping to make key management the next major focus area in bind 9, now
that we h
>> I can install bind 9.9.0rc2 tomorrow and test with both nsupdate and
>> rndc reload. I would also like to test DNSSEC automatic key rollover
>> with inline signing again. I imagine this will be fixed in rc2, given
>> the success of the patch you provided earlier. My next ZSK activation
>> da
Do you happen to have some sort of web proxy (perhaps transparent) that is
sitting between your windows machine and our server?
In any case, I'll open a ticket with our ops people to investigate from our end.
--Michael
On Feb 1, 2012, at 10:06 AM, TAN BUI wrote:
> I have filed a bug report to
I have filed a bug report to bind9-b...@isc.org, ID is [ISC-Bugs #27700].
I was trying to upload the tar files via https://pandora.isc.org/ ;
after getting to the link provided by "ISC Pandora ",
I filled in all the information, selecting all the files to be
"dropped off" and clicking on "Drop Off
>> Now the private key is inaccessible to the named process, which is
>> running as user bind. User bind is a member of group bind.
> Any time a private key file is rewritten, the mode is changed to 600.
> There's no rule that it has to be owned by root, though; could you just chown
> it to user
> > As is probably obvious, I consider it an irritating bug ;o)
>
> +1
Agreed. A warning that can be redirected to /dev/null might be okay.
Changing it unconditionally is not.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
Please visit h
On 1 Feb 2012, at 09:52, Phil Mayers wrote:
> As is probably obvious, I consider it an irritating bug ;o)
+1
Niall O'Reilly
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users m
> I consider it a feature, though opinions may vary.
I consider it a bug, and it's going to bite hard.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
htt
On 02/01/2012 04:56 AM, Evan Hunt wrote:
Now the private key is inaccessible to the named process, which is
running as user bind. User bind is a member of group bind.
Any time a private key file is rewritten, the mode is changed to 600.
This kind of keyfile nannying annoys me, with other prod
15 matches
Mail list logo