DNSSEC query

[Jim Reid]

>>>>> "Tony" == bind-list  <bind-list at ayahuasca.net> writes:

    Tony> If any of those top level NIC's don't yet sign KEY records
    Tony> can I sign them myself and incorporate that into my signed
    Tony> zone ?  If I can, is this any security at all ? or still
    Tony> better than nothing ?

You can sign your own zones. In fact until your parent zone is signed
(and so on up to the root zone), self-signing is necessary to get a
signed zone. Whether this buys you any security or not is debatable.
The SIG records can only be verified by another DNSSEC-aware name
server or resolver that can verify the public key that you claim to
have used during your signing process. These keys are supposed to be
signed by DNSSEC-aware versions of your parent zone(s). Since they
probably don't exist, the rest of the world that runs secure name
servers needs to add a trusted-keys{} statement for each of your
secure zones to their named.conf files. That isn't going to happen.

Even if you do get someone to include a trusted-keys{} statement, it
doesn't mean much. All it means is the key in that statement can be
used to verify your signed zone's data. It doesn't necessarily mean
that the key is valid (or up to date) or that it came from the true
"owner" or that domain. If you and your collaborators can accept those
assumptions, adding trusted-keys{} statements to named.conf for each
other's zones sort of makes sense if you have important DNS data that
has to be signed.

Personally, I'd only sign a zone if it contained something important
like a PGP key or X.509 certificate that I wanted to guarantee could
not be subjected to DNS spoofing attacks. For regular stuff like A and
MX records, it's probably not worth the bother. The DNS has got along
just fine for over a decade without needing to sign these records.

    Tony> --Secondly, when I create my signed zone file with
    Tony> dnssigner, I don't get the SIG line as shown in the PP
    Tony> Presentation, ie :

    Tony> SIG SOA 3 86400 1990320224141 19990217224141 49292
    Tony> domain.co.uk. ( ya-de-yah-de-yah )

    Tony> but instead get :

    Tony> $SIGNER DEL domain.co.uk. 3 49292

    Tony> and the same line again under the public key.  Is this right?
    Tony> Or am I missing something..?

It's hard to say given that you didn't supply all the information,
chose to conceal some of it and probably mangled a few of the resource
records you did provide by "editing" them.

BEGIN RANT.
Why oh why do people on this list HIDE information?  There's no excuse
for doing this. Ever. All it does is make life difficult for anyone
that tries to diagnose the problem. For instance, if you'd supplied
the original zone data, the keys and details of how you ran dnssigner,
someone might have been able to replicate your work and figure out
what went wrong. And before anyone whines about key secrecy, I would
expect that people would use different, stronger keys with "real"
DNSSEC from the ones used in their first attempts with dnssigner. And
anyway once the problem is solved, they can always re-sign the zone
with new keys. In any case the problem here does not appear to be
about the actual value of the key that was used to sign the zone.
END RANT.

The zone file you presented does not contain any SIG records despite
the fact that you quote a SIG record above. This is odd. [That SIG
record has curious timestamps BTW. It looks to have expired 1800 years
before it was created.] Where did that SIG record come from and how
did it get there? I'd guess you didn't use the right command-line
arguments to dnssigner or kept the K*.private and K*.key files in a
different directory from where you ran dnssigner. That tends to be the
cause of $SIGNER directives in signed zone files. Use the -st and -l 7
arguments to dnssigner and study the reporting output. This should
tell you what keys (if any) were used for signing and how many SIG
records were added or removed.

    Tony> --Finally, what does the 49292 signify or come from ?

Based on the SIG record you quote above, I suppose it is the footprint
of the key that was used to make the SIG record. The footprint is just
a tag in the SIG record which hints at what key was used to generate
the signature. ie When there is >1 key, the footprint can identify the
specific key that was used, saving the name server from possibly
trying all the keys when it verifies the signature.