Issue 6 - Last Hop, expanded a bit

[Scott Rose]

Issue 6:  Last Hop

1.  Framing the question

The communication between a stub resolver and a caching name server (both
security aware).  A security aware caching name server does the validation
of DNSSEC responses and returns either a response that passes all checks
(according to local policy), or an error message.  Some resolvers may wish
to have a more lenient policy and may be tolerant of certain errors that the
name server is not.  There needs to be a way for the name server to give
more information about the DNSSEC status of a response to a stub resolver
that can understand it.  Other protocols that depend on the DNS (like SPF
for anti-spam and browsers) may wish to have more information about a DNSSEC
response status than a simple binary "valid/invalid" check.

2.  Work to date

The last hop was never covered by DNSSEC from RFC2065 on.  The AD bit in the
DNS message header was meant to convey to the stub the response passed all
the checks the caching name server performs, but no other information.  If a
DNSSEC error occurs a SERVFAIL error is returned even if a traditional
(non-DNSSEC) query would have resulted in a NOERROR response.

3.  Current status

Some work has been done on an API for applications to get more detailed
DNSSEC information from a response, but that requires a full validating
resolver on the same host.  No other work has been done on "on-the-wire"
solutions other than securing the last hop via transaction security (TSIG,
SIG(0)) and trusting the AD bit in the header.

4.  Relation to other issues

The Last Hop issue is related to the business case for DNSSEC.  If
applications require different security postures, it may encourage
deployment.  The Last Hop issue is also related to name server and end
user/application policy issues.  The requirements for what the Last Hop
mechanisms would look like will come from application DNSSEC needs, and
policy on how name servers and applications will handle DNSSEC results will
have to be developed.

5.  Next steps

Possible next steps:
1. Produce a requirements document for what a DNSSEC aware application would
want from the security status of a DNS response.

2. Produce a requirements document for communicating DNSSEC details to the
stub resolver.

3. Produce an API for applications to talk to a DNSSEC aware full resolver
to obtain validation information about DNS queries.

4. Produce an API for applications to talk to a DNSSEC aware stub resolver.


6. Major participants

Resolver developers, recursive name server developers, application
developers.  Network security managers will be involved with setting policy
for DNSSEC on a network as well.

DNSSEC operations is being handled in the IETF by the DNSOP working group,
but any changes/additions to the DNS protocol (revised error codes for
example) will have to be done in DNSEXT WG or some new WG charted with the
task.

7.  How will we know when we are "done"?

Uncertain, as some applications will evolve and develop to use DNSSEC in new
ways.  Certainly the deployment of DNSSEC aware applications and stub
resolvers could be considered a success.






Scott
****************************************
Scott Rose
Adv. Network Tech. Div., NIST
+1 301-975-8439

http://www-x.antd.nist.gov/dnssec/
****************************************