[dnssec-deployment] DNSSEC plenary discussion paper - trust anchors, last mile, etc.
matt.pounsett at cira.ca
Wed Jan 7 15:58:14 EST 2009
On 07-Jan-2009, at 13:35 , Edward Lewis wrote:
> At 9:57 -0500 1/7/09, Paul Wouters wrote:
>> On Wed, 7 Jan 2009, Edward Lewis wrote:
>>> (A DNSSEC-caused rejection of data is a service failure. It is a
>> Not really. without history, dnssec rejection would be a
>> notification by the
>> service, not a service failure. We just don't have anything to deal
>> with it,
>> so we are overloading DNS servfail for this DNSSEC notification
> What is the difference between the failure to get answers because
> all of the authoritative servers for a zone are down versus a
> verification failure?
It makes a difference to what the application is able to do in terms
of user-friendliness in its failure modes. The DNSSEC Tools project's
patches to Firefox are a good example of where this can start .. in
the event of a DNS failure, instead of telling the user the generic 5
or 6 reasons why the web site may not be available, it can be very
specific about what went wrong.
For more security-conscious applications it might be important to
notify the user that the domain in question may be under attack
(though yes, the DNSKEY data for the domain may also just be broken).
Signalling the difference between protocol and validation failures
provides a better starting point for troubleshooting, by potentially
eliminating the need to look for several different types of
I could probably think of more.. but I'm certain anything I could
think of has already been enumerated elsewhere.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20090107/0e757559/attachment.bin
More information about the Dnssec-deployment