Followup:
I deleted and re-added the zones with this problem (179.in-addr.arpa and
3.1.1.0.0.2.ip6.arpa) as I had to perform other changes as well (a
different policy from "default" and a new way of fetching the zones from
the servers that generate them) and the problem is now gone.
Thank you to
I don't know why you don't see it, but believe me, it was as I said. The
zone file has RRSIGs for DNSKEY RRSets but not for the rest.
On 6/16/11 12:06 PM, Rickard Bellgrim wrote:
> 2011/6/16 Carlos M. Martinez :
>> dig +dnssec 179.in-addr.arpa soa -> no RRSIG
>> dig +dnssec 179.in-addr.arpa dnskey
2011/6/16 Carlos M. Martinez :
> dig +dnssec 179.in-addr.arpa soa -> no RRSIG
> dig +dnssec 179.in-addr.arpa dnskey -> good-looking RRSIG ;)
I do not get a signature for the DNSKEY.
Have you enabled DNSSEC on your name server? Or was it as your said,
that it is also missing the signed zone file f
Hi all,
I might be doing something wrong myself, so please don't be afraid to
let me know it :-)
Situation: OpenDNSSEC 1.2.1 operating fine, only small glitches here and
there but nothing serious. Zones being signed, keys being rollover'd.
I upgraded to OpenDNSSEC 1.3.0rc3 while keeping all XML
+--On 16 juin 2011 13:59:13 +0100 Siôn Lloyd wrote:
| On 13/06/11 16:23, Mathieu Arnold wrote:
|> So, I went back to the database, and updated the keypairs' policy_id (and
|> the dnsseckeys' retire while I was at it.) and there I was, the enforcer
|> was nice enough to publish new KSK.
|>
|> I
On 13/06/11 16:23, Mathieu Arnold wrote:
So, I went back to the database, and updated the keypairs' policy_id (and
the dnsseckeys' retire while I was at it.) and there I was, the enforcer
was nice enough to publish new KSK.
I guess changing a zone's policy is not something that's done often, and