Re: DNSSEC - mismatch between algorithm and type of NSEC
On 12/29/2010 3:37 AM, Marc Lampo wrote: > However, we now found the following case : > 1) registrar offers us DNSKEY information with algorithm 7 : > RSASHA1-NSEC3-SHA1 > 2) in the zone file, there are NSEC (and not NSEC3) records This is not an error. The only reason for there being "different" algorithm numbers within RSASHA1 was to keep "older" systems that don't know about NSEC3 from dealing with NSEC3 responses incorrectly. All "newer" algorithms can be used for both NSEC and NSEC3. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC - mismatch between algorithm and type of NSEC
What was the observed behaviour in your test system? >From a sanity point of view and if you are checking the zone prior to accepting the DNSKEY, then I see nothing wrong in rejecting it. There are already other restrictions on domains in .EU that establish a precedent for being more demanding on DNSSEC signed zones. On 29/12/10 9:37 AM, "Marc Lampo" wrote: > Hello, > > And my best whishes for the new year 2011 ! > May we have lots of interesting questions, where we all can learn from ;-) > > (hope my question is also in that category ...) > > As .eu top level domain we try to avoid inserting DS records in our zone > where corresponding DNSKEY information is missing from the customers' zone > file, > thus avoiding to activated DNSSEC with an already broken chain-of-trust. > > However, we now found the following case : > 1) registrar offers us DNSKEY information with algorithm 7 : > RSASHA1-NSEC3-SHA1 > 2) in the zone file, there are NSEC (and not NSEC3) records > > Public DNSSEC verification tools (dnsviz, verisignlabs) > don't seem to make a problem out of this > (they do signal an insecure delegation, obviously : we don't publish a DS > record). > ((there must be a wildcard in the zone file, > So I can enter a domain name where the verification tools get NSEC > records)) > > > I can simulate the case in a test environment, of course, > But then I only see the behaviour of a specific name server > implementation. > But what is the list's interpretation of this situation : erronous or not > ? > Does any DNSSEC RFC mention this case and prescribe a reaction to this ? > (I didn't find any - > RFC5155 states the new algorithms - 6 and 7 - *must* be used when NSEC3 > is used, > But not a word - unless I overlooked it - about using algorithm 7 and > yet, NSEC ...) > > > Looking forward to your comments. > > Kind regards, > > > Marc Lampo > Security Officer > > EURid > Woluwelaan 150 > 1831 Diegem - Belgium > TEL.: +32 (0) 2 401 3030 > MOB.:+32 (0)476 984 391 > marc.la...@eurid.eu > http://www.eurid.eu > > > > Want a .eu web address in your own language? Find out how so you don¹t > miss out! > > > Register your .eu domain name and win an iPod touch this X-Mas > http://www.winwith.eu > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC - mismatch between algorithm and type of NSEC
Hello, And my best whishes for the new year 2011 ! May we have lots of interesting questions, where we all can learn from ;-) (hope my question is also in that category ...) As .eu top level domain we try to avoid inserting DS records in our zone where corresponding DNSKEY information is missing from the customers' zone file, thus avoiding to activated DNSSEC with an already broken chain-of-trust. However, we now found the following case : 1) registrar offers us DNSKEY information with algorithm 7 : RSASHA1-NSEC3-SHA1 2) in the zone file, there are NSEC (and not NSEC3) records Public DNSSEC verification tools (dnsviz, verisignlabs) don't seem to make a problem out of this (they do signal an insecure delegation, obviously : we don't publish a DS record). ((there must be a wildcard in the zone file, So I can enter a domain name where the verification tools get NSEC records)) I can simulate the case in a test environment, of course, But then I only see the behaviour of a specific name server implementation. But what is the list's interpretation of this situation : erronous or not ? Does any DNSSEC RFC mention this case and prescribe a reaction to this ? (I didn't find any - RFC5155 states the new algorithms - 6 and 7 - *must* be used when NSEC3 is used, But not a word - unless I overlooked it - about using algorithm 7 and yet, NSEC ...) Looking forward to your comments. Kind regards, Marc Lampo Security Officer EURid Woluwelaan 150 1831 Diegem - Belgium TEL.: +32 (0) 2 401 3030 MOB.:+32 (0)476 984 391 marc.la...@eurid.eu http://www.eurid.eu Want a .eu web address in your own language? Find out how so you dont miss out! Register your .eu domain name and win an iPod touch this X-Mas http://www.winwith.eu ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
