On Feb 10 2014, Mark Andrews wrote:

In message <52f94ee2.7080...@ksu.edu>, "Lawrence K. Chen, P.Eng." writes:
[... snip ...]
On 02/06/14 15:07, Timothe Litt wrote:
[... snip ...]
> Note also the RFC 5155 recommendation:
>> The salt SHOULD be at least 64 bits long and unpredictable, so that
>> an attacker cannot anticipate the value of the salt and compute the
>> next set of dictionaries before the zone is published.
> In case it wasn't obvious, I should have noted that the length would be
> a config file entry.
[...]

Interesting....I guess I need to keep up more on these things.

I haven't changed my NSEC3 salt since I initially set up DNSSEC here,
and seemed to me that the document I was working off of back then said 4
hex characters.

Which probably made it extra hard for me to come up with a random
number.  So, its totally non-random...so all I did was take the hex for
two (well-known) letters...for my salt.  Since the salt is 'public',
I'll say it.  my salt is "KS", or "4b53".

So now to think of how to add NSEC3 salt changing to my current
automation scripts....

And for most zones it won't make a bit of difference.  Most are
mainly static and once you have sampled the zone enough times to
have (almost) all the NSEC3 records you just keep testing against
those NSEC3 records.  Once you find a name in the zone you can just
test that it still exists.  When the NSEC3 parameters change you
just run the know names through for a non-existing type and you
get confirmation of the name and a new set of NSEC3 records without
having to do as much sampling.

It makes a bit of sense for zones that have names that a coming and
going all the time but even then you can reuse existing knowledge.

It's probably worth noticing what the big operators do, e.g.

$ dig +noall +answer +nottl NSEC3PARAM com. edu. net. org.
com.                    IN      NSEC3PARAM 1 0 0 -
edu.                    IN      NSEC3PARAM 1 0 0 -
net.                    IN      NSEC3PARAM 1 0 0 -
org.                    IN      NSEC3PARAM 1 0 1 D399EAAB

(AFAIK the salt used for "org" has never changed - and the same value
is used for 23 other TLDs.) A quick check revealed 216 TLDs [*] with
NSEC3PARAM records, distributed as follows:

  Extra                 Salt length (bytes)               Total
iterations    0    2    3    4    5    6    8   10   16

    0         7    -    -    -    -    -    -    -    -       7
    1         -    -    -  125    -    -    1    -    -     126
    2         -    -    -    2    -    -    -    -    1       3
    3         -    3    -    1    -    -    -    -    -       4
    5         1    -    -    1    5    -   15    1    -      23
    8         -    -    -    -    -    2    -    -    -       2
   10         2    4    5   25    -    -    1    -    -      37
   12         -    -    -    -    -    -    5    1    -       6
   13         -    -    1    -    -    -    -    -    -       1
   15         -    -    -    1    -    -    -    -    -       1
   17         -    -    -    -    -    -    1    -    -       1
   25         -    -    -    -    -    -    2    -    -       2
  100         -    -    -    -    -    -    1    -    -       1
  150         -    -    -    1    -    -    1    -    -       2

 Total       10    7    6  156    5    2   27    2    1     216


[*] A lot more than there used to be, due to the influx of new gTLDs.

--
Chris Thompson
Email: c...@cam.ac.uk
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to