Re: tkey-gssapi-credential

At Fri, 17 Sep 2010 13:18:42 -0600, Nicholas F Miller wrote: > > Does anyone have instructions on how to setup a Linux bind server to > use GSS-TSIG against an AD? I have found many articles from people > having issues with it but none that had good instructions on how to > get it working. Last ye

Re: bind 9.7.1-P2 startup: unable to set effective gid to 0

Just a follow up, I've added some debug statements to bin/named/unix/os.c to see the files that named is trying to set the effective gid for, and I see: [ID 873 daemon.warning] Trying to open: '/var/run/named.pid'. [ID 873 daemon.warning] unable to set effective gid to 0: Not owner [ID 873 daemon.i

Re: tkey-gssapi-credential

Thanks, that will save me a bunch of time. Of course I spent my morning testing it out to no avail. Does anyone have instructions on how to setup a Linux bind server to use GSS-TSIG against an AD? I have found many articles from people having issues with it but none that had good instructions o

Re: tkey-gssapi-credential

At Fri, 17 Sep 2010 09:17:09 -0600, Nicholas F Miller wrote: > > I was wondering if it is possible to use the tkey-gssapi-credential > and update-policy on a Windows install of bind. It strikes me that > running bind on a Windows server, snapped into the AD it will serve > DNS to, should be the ea

bind 9.7.1-P2 startup: unable to set effective gid to 0

We recently upgraded from bind version 9.7.0 to 9.7.1-P2 and we noticed that upon start of named, we are seeing the following warning message: [ID 123 daemon.warning] unable to set effective gid to 0: Not owner [ID 123 daemon.info] generating session key for dynamic DNS [ID 123 daemon.warning]

NSEC3 salt lifetime (and some other DNSSEC params): sane value?

Hi, I'm playing around with the different timers of DNSSEC. Usually these timers are a balance between a low overhead vs quick propagation: * A high TTL gives more caching and thus less load on the authoritative server; but it takes a long time for updates to propagate. * A short RRSIG lifetime li

Re: auto-dnssec resign timers

On 2010-09-17 19:50, Tony Finch wrote: > On 17 Sep 2010, at 14:10, Niobos > wrote: >> >> Is the current version of the ARM available online somewhere? > > http://dotat.at/tmp/arm97/ > > IIRC the specific version that comes from is 9.7.1p2. Thanks for the quick and

Re: auto-dnssec resign timers

On 17 Sep 2010, at 14:10, Niobos wrote: > > Is the current version of the ARM available online somewhere? http://dotat.at/tmp/arm97/ IIRC the specific version that comes from is 9.7.1p2. Tony. -- f.anthony.n.finchhttp://dotat.at/___ bind-users ma

Re: auto-dnssec resign timers

On Fri, 17 Sep 2010, Niobos wrote: Is the current version of the ARM available online somewhere? Thx, Niobos It is in the doc directory of the source for the subject binary, in html and pdf formats. Dave -- St. Louis, Missouri ___ bind-users mai

tkey-gssapi-credential

I was wondering if it is possible to use the tkey-gssapi-credential and update-policy on a Windows install of bind. It strikes me that running bind on a Windows server, snapped into the AD it will serve DNS to, should be the easiest way of getting DDNS with update-policy control working. Am I n

Re: auto-dnssec resign timers

On 2010-09-17 12:15, Tony Finch wrote: > On 17 Sep 2010, at 10:44, Niobos > wrote: >> >> In my opinion, BIND should have resigned this by now: The signature is >> valid until a little over 2 days. This means that if the slave would >> loose contact with the master ri

Re: auto-dnssec resign timers

On 17 Sep 2010, at 10:44, Niobos wrote: > > In my opinion, BIND should have resigned this by now: The signature is > valid until a little over 2 days. This means that if the slave would > loose contact with the master right now, it will give out signatures > that will expire before their TTL does

auto-dnssec resign timers

Hi, I'm experimenting with the auto-dnssec feature of bind 9.7.0-P1. I know it's outdated; I did skim over the changelog up until 9.7.2rc2, and didn't find anything that seems like this issue. This query demonstrates the issue: ; <<>> DiG 9.6.0-APPLE-P2 <<>> +dnssec SOA dnssec.dest-unreach.be @im