On Tue, Aug 30, 2016 at 6:32 PM, Yuri Schaeffer wrote:
> Hi Emil,
>
> > Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
> > the empty non-terminal is only derived from an insecure delegation
> > covered by an Opt-Out NSEC3 RR.
> >
> > If I understand the above corre
On Tue, Aug 30, 2016 at 6:32 PM, Yuri Schaeffer wrote:
> Hi Emil,
>
> > Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
> > the empty non-terminal is only derived from an insecure delegation
> > covered by an Opt-Out NSEC3 RR.
> >
> > If I understand the above corre
On 30/08/2016 17:20, Yuri Schaeffer wrote:
> Hi Mark,
>
>> And in the creation of NSEC3 records, the "next link of the chain"
>> (which is currently in upper case) means the "chained-to" record will
>> also be in Upper Case???
>
> I'm unsure what you mean. In what case are the hashes published
Hi Emil,
> Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
> the empty non-terminal is only derived from an insecure delegation
> covered by an Opt-Out NSEC3 RR.
>
> If I understand the above correctly, NSEC3 records should not be created
> for insecure delegations.
Hi Mark,
> And in the creation of NSEC3 records, the "next link of the chain"
> (which is currently in upper case) means the "chained-to" record will
> also be in Upper Case???
I'm unsure what you mean. In what case are the hashes published in
uppercase by ODS?
The point of the proposed patch is
And in the creation of NSEC3 records, the "next link of the chain"
(which is currently in upper case) means the "chained-to" record will
also be in Upper Case???
eg...
13bu1nqrimn19lbkq6cvqume6thbsebr.web.za. 300 IN NSEC3 1 1 5
A021CAFA36A752AC 1ALJ0RMHHSFU8I2RQ6HB0T74JE03MGC1 MX RRSIG
On 30-08-16 16:10, Mark Elkins wrote:
> Much to my annoyance, OpenDNSSEC converts to lower case the Left Hand
> side of all zones (the name part, before the TTL). Can this modification
> of data be switched off?
Agreed and the next release will have a fix for this.
https://github.com/opendnssec/o
I've been playing with OpenDNSSEC-2.0.1, compiled from scratch on a
Gentoo box. I have three virtual servers, server one is BIND with
unsigned zones - pretending to be the Zone Generator.
Server 3 is also running BIND - pretending to be a distribution master
or "Master" name server.
The Man in the
Hi Mark,
The policy I used for this example was actually created for a very short
zonefile with well known records where the enumeration is not an issue. I
would have even used NSEC, but instead opted for NSEC3 to make the custom
checks I run on the signed zones compliant for all zones (when all z
Excuse my ignorance/sanity, what does it mean to have a NSEC3 iteration
of Zero? Shouldn't the minimum be 1 ?
I would also have thought that salt would be required - so a length of
Zero would be a strange thing to do. Kind of makes the Resalt value of
100 days redundant
Personally - I'd choose an
Hello,
Running ODS 1.4.9. I know 1.4.10 is out (as well 2.x.x) but I do not see
anything related to the issue mentioned in the Changelog, so I presume
1.4.10 inherits the same behavior.
Domain example.com, contains the following insecure delegation:
sub2.sub1 IN NS ns1.yahoo.com.
"Petr Spacek" schreef in bericht
news:2e3a5fd7-0746-c621-d15a-f95abe280...@redhat.com...
On 30.8.2016 10:12, Wytze van der Raay wrote:
On 08/30/2016 09:46 AM, Fred.Zwarts wrote:
ODS 2.0.1 has now been running satisfactory on our test system for
several
weeks. However, recently we noticed tha
On 30.8.2016 10:12, Wytze van der Raay wrote:
> On 08/30/2016 09:46 AM, Fred.Zwarts wrote:
>> ODS 2.0.1 has now been running satisfactory on our test system for several
>> weeks. However, recently we noticed that each time we reboot the system,
>> ods does not startup properly. It turns out that af
On 08/30/2016 09:46 AM, Fred.Zwarts wrote:
> ODS 2.0.1 has now been running satisfactory on our test system for several
> weeks. However, recently we noticed that each time we reboot the system,
> ods does not startup properly. It turns out that after each reboot, the
> directory /var/run/opendnsse
I'm resending the message because it may have been missed by people
on the user list as it was the subject contained the word spam.
Unfortunately the original message was marked as spam because of
high rating in bad To: address.
\Berry
On 08/30/2016 09:59 AM, Berry A.W. van Halderen wrote:
> Than
On 08/30/2016 09:46 AM, Fred.Zwarts wrote:
> ODS 2.0.1 has now been running satisfactory on our test system
>for several weeks. However, recently we noticed that each time we reboot
> the system, ods does not startup properly. It turns out that after each
> reboot,
>the directory /var/r
Spam detection software, running on the system "dicht.nlnetlabs.nl",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
The administrator of that system for details.
17 matches
Mail list logo
