A Deep Dive on the Recent Widespread DNS Hijacking

Mark Andrews marka at isc.org
Mon Feb 25 06:04:39 UTC 2019

> On 25 Feb 2019, at 4:34 pm, Bill Woodcock <woody at pch.net> wrote:
>> On Feb 24, 2019, at 5:51 PM, Keith Medcalf <kmedcalf at dessus.com> wrote:
>> That they also "forgot" to disable DNSSEC on PCH is not particularly relevant.  It only goes to prove my point that DNSSEC is irrelevant and only gives a false sense of security (for this particular attack vector).
> For those watching from the sidelines, This guy is perfectly encapsulating one of the arguments that seem to pop up in the wake of attacks: “What actually happened is irrelevant, because I can imagine other things that could hypothetically have happened, but didn’t, which would have reinforced my view of the world.”
> I can’t say that I understand the psychology behind people thinking this way, but as we’re choosing to be transparent about our experience for the benefit of others, I thought I’d highlight this particular quirk, as Mr. Medcalf is far from alone (not about DNSSEC specifically, but apparently attacks bring people with all manner of chips on their shoulders out of the woodwork).  It’s a particularly self-defeating logical fallacy, so being aware of it is the first step to recognizing it and avoiding it.
>                                -Bill

I would also note that a organisation can deploy RFC 5011 for their own zones and have their own equipment use DNSKEYs managed using RFC 5011 for their own zones.  This isolates the organisation’s equipment from the parent zone’s management practices.

I would also note that you can configure validating resolvers to expect secure responses for parts of the namespace and to reject insecure responses even when they validate as insecure.

An organisation can also deploy DLV for their own zones using their own registry.  While the current code DLV validating code is only invoked when the response validates as insecure, there is nothing preventing a policy which says that DLV trumps or must also validate for entries in a registry.  At this stage is would be a minor code change to add such policy knobs.  DLV is a just a in-band way of distributing trust anchors.

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org

More information about the NANOG mailing list