[dns-operations] cool idea regarding root zone inviolability

Warren Kumari warren at kumari.net
Tue Dec 2 21:24:48 UTC 2014

On Mon, Dec 1, 2014 at 6:13 PM, Paul Vixie <paul at redbarn.org> wrote:

>   Paul Vixie <paul at redbarn.org>
>  Sunday, November 30, 2014 2:29 PM
> why? (your use case is not obvious from what you've written.) ...
>   Chuck Anderson <cra at wpi.edu>
>  Monday, December 01, 2014 7:09 AM
> Silent on-disk corruption. It happens, and it would be nice to be
> able to detect that.
>  if you're concerned about operating system or hardware or network errors,
> then i assume you're also concerned about them hitting your name server
> executable, in which case you'll be running a file system like ZFS that
> catches these things.
> if you're concerned about malevolent on-disk editing, then i assume you're
> running something like tripwire to snapshot with secure hashes every file
> in your operating system, and that it will have hooks to manage and monitor
> the zone files as well.
> either way i'm not seeing a unique "has to be done with an in-zone
> signature" situation here.

It's not necessarily a "has to be done with an in-zone signature", but
doing it with an in-zone signature is:
A: easy
B: convenient
C: I have a single blob I can validate.
If you are concerned about malevolent on-disk editing and OS issues, you
can run ZFS and tripwire to snapshot with secure hashes every file *as well
as this".

Using the root-zone as an example, currently if I want to validate the zone
I do:
wkumari-macbookpro1:root-zone wkumari$ wget -q
wkumari-macbookpro1:root-zone wkumari$ wget -q
wkumari-macbookpro1:root-zone wkumari$ gpg --verify root.zone.sig root.zone
gpg: Signature made Mon Dec  1 13:53:30 2014 EST using DSA key ID 4150E298
gpg: Good signature from "Registry Administrator <nstld at verisign-grs.com>"
(entertainingly enough I trust 4150E298 because it was signed on 2013-02-11
by "Larson, Matt </o=VERISIGN/ou=VA-EAST/cn=Recipients/cn=mlarson>")

Clearly detached signatures *do* work, but if I happened to get the
root.zone at 6:52:59PM and the root.zone.sig file at 6:53:01PM I'd have an
issue (noting that the file time stamp is "6:53:00 PM") I now have an
issue. This also gets finicky if I try and keep multiple copies of the
zones for historical reasons, to be able to show that what I served was
what I got, etc. Yes, having version numbers on the files and detached sigs
is doable (or simply retrying if I get a validation failure, etc) but I
cannot see the downside to including it in the zone as well - if you
dislike the ZONESIG RR (just made up name) you can simply choose not to
check it.

Similarly, if someone emails me example.com.db and says "Please serve this
zonefile, I signed it with my GPG key, and the signature is
0xdeadbeef...cafe" (or "I attached example.com.db.sig") I have a bunch more
places where things could go wrong, including the obvious forgetting to
attach both files, having a signature for serial 2014120117 and the zone
contents for serial 2014120142, etc.
Having "Here is the signed zone example.com.db" and passing that to
"load_and_validate_zone.sh" or 'rndc addzone --validate example.com." is
(IMO) much less error prone.

I think that this is similar to how, when you get a PGP signed email you
get the signature in the same message, and not one email saying "Foo Bar
Baz" and then a second email with a signature for the first message.


> --
> Paul Vixie
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141202/73ce8ba5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1222 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141202/73ce8ba5/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141202/73ce8ba5/attachment-0001.jpg>

More information about the dns-operations mailing list