Subject: [dnsext] signing referral NSs and glue

From: Edward Lewis <[email-masked]>
Date: Tue, 12 May 2009 09:40:17 -0400

The is a conscious reason why NS sets from the parent and glue 
records aren't signed in DNSSEC.  It is unnecessary.

DNSSEC offers source authenticity and data integrity.  DNSSEC does 
not guarantee answer receipt.  If DNSSEC is to be augmented, a DDoS 
mitigation mechanism is the most needed companion.  (If you assume 
IPSEC/TSIG/TKEY also is involved in last hop protection.)

Note that DNSSEC does not "secure the DNS" if you mean "I ask and 
then I get the valid answer."  DNSSEC only fends off the invalid 
answers.

In a referral with DNSSEC, there are three parts to the message.  One 
is the NS set provided as a hint from the parent.  Two is the glue 
provided as a hint from the parent.  And third is an signed, 
authoritative indication of the DNSSEC parameters for the child zone.

The NS hint and glue are not sourced from the parent, hence not 
signed.  (Remember, DNSSEC -> source authenticity; the parent is not 
the source).  If these were signed, the debugging headache of stale 
glue would be magnified by the confused party seeing a temporally 
valid signature over the problem.

It is true that if the NS set and the glue are entirely forged the 
client will not be able to get to the authentic data.  As far as the 
design goal of DNSSEC, the goal of preventing invalid data is 
achieved by the forged source hints being unable to meet the 
parameters that the parent is the source of - the DS set contents or 
the NSEC[3] statement of no DNSSEC.  I.e., the part of the referral 
that is DNSSEC protected is the DNSSEC parameters.

If the forger has access to a private key that meets what's in the DS 
RR set, then the client will be duped - but DNSSEC assumes the 
private key is private and unguessable.  If the child legitimately is 
not using DNSSEC, we have what we have today.

The choice to fail dead (SERVFAIL) comes from the strict 
interpretation of security that emanated from the DNSSEC WG's being 
placed in the Security Area in the early 90's.  If you wanted to 
DNSSEC to protect you from bad info, it did, no excuses.

Beyond that, there are variations in the way DNSSEC is implemented 
that can make this drop-dead less precipitous.  There are various 
coding choices that can be made.  In the past years I have seen some 
I disagree with that are compliant with the RFCs but "could be 
better." I won't bother with specifics here, I mean to say that when 
considering what you see happen in DNSSEC, research whether it is a 
protocol element or code element that needs fixing.  Security at 
first makes a working system brittle, the next step is to adjust 
security so that it doesn't break the system while security is 
protecting the system.

The issue of signing referrals comes up every few years.  What's been 
lost to history is that the parent's version of the child's NS set 
and the glue are just hints.  The implementation BIND uses the hints 
to find the desired data but also does due diligence in parallel to 
cache the authoritative version of the referral data for future 
reference.  Keeping in mind that the parent has hints and not the 
data, it's easier to understand why the referral NS and glue are not 
DNSSEC signed.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>