[dns-operations] summary of recent vulnerabilities in DNS security.

[Vernon Schryver]

} From: Haya Shulman <haya.shulman at gmail.com>

} > In that case, on what should an organization spend time or money
} first, on DNSSEC or the recommendations in the mail message?  Would
} it be better if each of the recommendations in the mail message
} started with something like this?
}
}     Deploy DNSSEC, and consider the follow to help protect cached
}     data not yet protected with DNSSEC.
}
} It's a good point, thanks. I will rewrite the recommendations according to
} what is essential and also against which type of attack and to what network
} configuration it applies.

I do not see an answer to my intended question.  Again, given inevitiably
limited real time, over-committed programmer and DNS adminstrator
hours, and limited money, should problems in DNSSEC implementations
and installations be addressed before or after your issues?

Should the people working on DNS implementations prioritize making
their DNSSEC code more robust and easier to use above or below
addressing your issues?

Which should be built or fixed first, mechanisms such as auto-signing
that make DNSSEC easier to deploy and more robust (e.g. reducing
accidental signature expiration), or your cache pollution issues?

Should requests for proposals and requests for quotes rank DNSSEC
features including ease of DNSSEC use above or below fixes for your
cache pollution issues?

Should you spend most of your own time looking for improvements and
bugs in DNSSEC or looking for more ways to pollute DNS caches where
DNSSEC is not used?


} That sounds like a more significant bug than port obscurity or
} randomization.  

} It is not always a bug imho. Some resolvers, e.g., unbound, explicitly
} allow such permissive modes of DNSSEC validation, others support this
} implicitly and the rest may simply be not configured properly.
} Permissive modes are typically used during the incremental deployment
} phases prior to full adoption, e.g., to see that DNSSEC works ok, and does
} not break anything.
}
} Permissive mode introduces a security vulnerability - since a resolver
} signals support of DNSSEC, it receives large (often fragmented) responses,
} and thus may be vulnerable to our cache poisoning attack. On the other
} hand, network operators, may be concerned (often justly) with enforcing
} strict DNSSEC validation, due to interoperability (or other) problems (we
} discuss this in more detail in `Availability and Security Challenges
} Towards Adoption of DNSSEC`).

I think that is neither a response to my claim, accurate, nor
relevant to what I understood of your claim about forwarders.

How can something that introduces a security vulnerability not always
be a bug in your or anyone's opinion?

If you meant instead to say that permissive verification is a less
important bug that other things, then how do you rank your cache
pollution issues against other bugs starting with not deploying DNSSEC?

Your work would be valuable if it helped pressure people to get
busy on DNSSEC.  However, instead of saying "Use DNSSEC because
port randomization has these newly discovered weaknesses", you only
grudgingly and under pressure admit that DNSSEC even exists.


Vernon Schryver    vjs at rhyolite.com