Secure Split DNS thought.

[Jim Reid]

>>>>> "Ted" == Ted Rule <Ted_Rule at flextech.co.uk> writes:

    Ted> If I have a split DNS configuration with a "mycompany.co.uk"
    Ted> tree and perhaps subtrees visible to the internet as well as
    Ted> a "mycompany.co.uk" tree and perhaps a DIFFERENT set of
    Ted> subtrees visible to the internal company network..... 

    Ted> Should I use the same DNSSEC KEYs on any given label/RRset
    Ted> which is visible in both the internal and external domains?

Probably not, but it depends.

    Ted> Can I use different ones?

If you have split DNS, there are two copies of your zone/domain. These
are completely seperate (logically at least, even if the contents are
near-identical). This implies there probably should be a different set
of KEY and SIG records for the internal and external name spaces.
However this could be tricky if you use one meta-file or $INCLUDE
directives so that there's one file to manage for generating the
internal and external zone files. So it depends on how you manage your
zone files; what you use DNSSEC for (internally and externally); how
often you change or revoke keys (maybe that's different on the inside
and outside); etc, etc.

    Ted> Do any conflicts arise?

Not if you keep the name spaces apart. However if an internal resolver
queries an external secure name server for your zones and vice
versa. And if that happens, you will probably have other problems to
worry about.

    Ted> Do any issues arise with those pesky NXT records as between
    Ted> the different contexts?

I don't think so. dnssigner can create the NXT records for you, so as
long as you use different zone files for the inside and outside,
things should be fine.

    Ted> Is use of a different KEY set internally preferred, so that
    Ted> compromise of the external KEY set
    Ted> doesn't potentially compromise the internal tree?

This is a Good Idea. After all, you probably don't use the same key to
lock both your house and car.

There are trade-offs to be made here between convenience and
security. Lots of KEY and SIG records can be good for security, but
can make key management - already a very hard problem - even more
difficult. [They can also allow a degree of devolution: for instance
the postmaster could look after the KEY/SIG records that concern the
site's mail servers.] If a key is used for only one thing, it's
probably no big deal if it is compromised. If the one key's used for
everything and it ever gets broken, you will crash and burn
spectacularly. Another consideration is revoking a key (or switching
to a new one). If a key is used for one specific thing, the impact of
changing it should be predictable. If a key is used for lots of
things, getting the rest of the world to simultaneously switch to the
new key for signing zones, secure dynamic updates, etc, etc will be
awkward. OTOH, it can be a real pain keeping track of lots of KEY/SIG
records.

It's a bit like having a big keyring with all your house/office/car
keys. When there are lots of keys on the keyring, finding the right
one to unlock a particular door can be inconvenient. However if there
are only one or two, you're in deep trouble if you lose them or
someone is able to make a copy of those "important" keys or you're
forced to lend a key to someone you don't really trust. Would you give
a garage mechanic the key to your house when you get your car
repaired?

RFC2541 - "DNS Security Operational Considerations" - has some helpful
things to say about key management in DNSSEC.