[dns-operations] cool idea regarding root zone inviolability

[Warren Kumari]

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
ftp://ftp.internic.net/domain/root.zone
wkumari-macbookpro1:root-zone wkumari$ wget -q
ftp://ftp.internic.net/domain/root.zone.sig
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.


W


>
>
> --
> 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
pants.
   ---maf
-------------- 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>