Subject: [DNSOP] wouldn't it be nice if there was an automatic mechanism to help with this?

From: Joe Abley <[email-masked]>
Date: Tue, 27 Aug 2013 17:56:55 -0400

Just saying :-)

Begin forwarded message:

> From: "[email-masked]" <[email-masked]>
> Subject: [dns-operations] Request To Clear Cache: NYTimes.com
> Date: 27 August 2013 17:55:19 EDT
> To: <[email-masked]>
> Reply-To: [email-masked]
> 
> All,
> 
> I am a DNS Administrator at NYTimes.com.  Earlier today we had issues with
> our registrar updating our NS records on the root servers to a malicious
> site.  The registrar has since locked our domain with the registry on our
> proper Name Servers.  We have had reports that the malicious site that our
> domain was redirected to was infecting users with malware.  It would be a
> great service to the internet if everyone could please clear their cache
> for NYTimes.com.  I understand that several other large websites/domains
> are experience the same thing.  I would not be surprised if several request
> like this come in over the list today.
> 
> Thanks,
> David Porsche
> Systems Administrator
> The New York Times
> _______________________________________________
> dns-operations mailing list
> [email-masked]
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 27 Aug 2013 18:03:45 -0400

Joe

Serendipity, as It appears they decided to apply the same process to one 
of our properties.

tim

On 8/27/13 5:56 PM, Joe Abley wrote:
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: SM <[email-masked]>
Date: Tue, 27 Aug 2013 15:53:37 -0700

Hi Joe,
>Just saying :-)

http://www.ietf.org/mail-archive/web/hybi/current/msg09174.html

Regards,
-sm

---

From: Hosnieh <[email-masked]>
Date: Wed, 28 Aug 2013 03:01:24 -0400 (EDT)

I think this problem has a solution in IPv6, but I am not sure for IPv4. The
current draft, cga-tsig proposed to automate the process of authentication of
resolvers (DNS query resolution) and DNS servers (DNS update) in a secure
manner.
You can take a look on that draft.

Best,
Hosnieh

> On August 27, 2013 at 5:56 PM Joe Abley <[email-masked]> wrote:
>
>
> Just saying :-)
>
> Begin forwarded message:
>

---

From: Hosnieh <[email-masked]>
Date: Wed, 28 Aug 2013 03:03:22 -0400 (EDT)

Follow up,

If you have a secure mechanism that does not allow attackers to do cache
poisioning on the client's stub resolver, then this solve the problem of
malicious websites as well.

Best,
Hosnieh

---

From: "Guangqing Deng" <[email-masked]>
Date: Wed, 28 Aug 2013 15:49:32 +0800

Cga-tsig approach can make sure that the content transferred between resolvers and DNS servers is not maliciously modified by others; while this approach cannot prevent the Resource Record (RR) from being wrongly updated by the registrar (namely man-made mistakes). Then it seems that one kind of RR checking tool (especially for NS RR) is needed by the registrar, and I am wondering that have there been any such tools available yet? 

Guangqing Deng
CNNIC 

From: Hosnieh
Date: 2013-08-28 15:01
To: dnsop WG; Joe Abley
Subject: Re: [DNSOP] wouldn't it be nice if there was an automatic mechanism to help with this?
I think this problem has a solution in IPv6, but I am not sure for IPv4. The current draft, cga-tsig proposed to automate the process of authentication of resolvers (DNS query resolution) and DNS servers (DNS update) in a secure manner. 
You can take a look on that draft. 
 
Best, 
Hosnieh

---

From: "Guangqing Deng" <[email-masked]>
Date: Wed, 28 Aug 2013 16:03:37 +0800

Usually, DNSSEC can stop cache poisoning attack. And for such event where the Resource Records are wrongly updated, maybe the method provided by draft-jabley-dnsop-dns-flush-00 is useful to flush the bad resource records on recursive DNS servers.

Guangqing Deng
CNNIC 

From: Hosnieh
Date: 2013-08-28 15:03
To: Joe Abley
CC: dnsop WG
 
If you have a secure mechanism that does not allow attackers to do cache poisioning on the client's stub resolver, then this solve the problem of malicious websites as well. 
 
Best, 
Hosnieh

---

From: Hosnieh <[email-masked]>
Date: Wed, 28 Aug 2013 10:52:58 -0400 (EDT)

It can provide that as well if you configure your DNS server with a list of
authorized IP addresses for certain zones. In other words, you let your DNS
server know from which IP addresses it can accept updates for a particular zone.
In this case, CGA-TSIG can be helpful,as well, as it can provide the proof of
address ownership for the node so that DNS servers will only accept updates from
the ones whom it is sure are the owner of that IP address. This is also possible
after the node chaning its IP address. Then this process is automatic and no
need for any further manual configurations.

Thanks,
Best,
Hosnieh

> On August 28, 2013 at 3:49 AM Guangqing Deng <[email-masked]> wrote:
> 
>  Cga-tsig approach can make sure that the content transferred between
> resolvers and DNS servers is not maliciously modified by others; while this
> approach cannot prevent the Resource Record (RR) from being wrongly updated by
> the registrar (namely man-made mistakes). Then it seems that one kind of RR
> checking tool (especially for NS RR) is needed by the registrar, and I am
> wondering that have there been any such tools available yet?
>

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 28 Aug 2013 08:15:44 -0700

One thought on DNSSEC and this attack.

DNSSEC couldn't have prevented this attack, as anyone authorized to update the .com zone for a domain can update the DS records just as easily as the NS+glue records.  And the attack could have done orders of magnitude more damage.

Yet DNSSEC can create an anomaly that may prove useful:

If the DS changes but the NS+glue does not, or the NS changes but the DS does not, this is a legit change from the registrar viewpoint as someone needs to change BOTH to be more than just a DOS on the domain.

But if BOTH the DS and NS+glue records for a domain change in a single event, this is NECESSARY for an attack that is more than a DOS, yet it is NOT NECESSARY for a migration (as a migration can change one and then the other).

How does the following policy strike people for DNSSEC recursive resolvers which perform validation:

Keep all seen DS and PARENT NS+glue RRSETs in a much-longer-than-normal (2 day timeout) cache.

When the DS or parent NS+glue RRSET changes, record that change (but still note the old version) in the cache.  

If the other one changes, mark that domain as bogus until either 2 days pass from the first change OR one or the other changes back to the older value.

What this accomplishes:

Registrar hijacks are no longer silent in the face of DNSSEC: it will result in a DOS on the domain rather than full control.

The protection is temporary, and is assuming that the registrar will be straightened out in two days.  

Which is probably a reasonable assumption since registrar hijack is now producing a DOS on the domain (making it visible) if its all done at once.   If the attacker first changes one and then the other, there is a two-day window where the site operator can notice the attack by monitoring the TLD status for the site's domain.

While "proper" migrations under the scheme (2 days between DS change and NS change) are always good, and "improper" migrations do produce a DOS, the DOS is limited to 2 days.

In terms of deployment, if Nominum would do this, now basically everyone gets protected since Nominum's usage by Comcast for recursive resolver validation guarentees that there is a large customer base which will be behind such protection, making this very visible.

Thoughts?  Comments?

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Paul Wouters <[email-masked]>
Date: Wed, 28 Aug 2013 11:37:52 -0400 (EDT)

> If the other one changes, mark that domain as bogus until either 2 days pass from the first change OR one or the other changes back to the older value.

Sounds like certificate pinning or CT-DNSSEC. It has the same problems.
There will be more false positives then actual attacks, and people will
disable it.

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 28 Aug 2013 08:48:44 -0700

On Aug 28, 2013, at 8:37 AM, Paul Wouters <[email-masked]> wrote:
...

> There will be more false positives then actual attacks, and people will

Of course, that argument also says "Ditch DNSSEC altogether, bypass the recursive resolver, and have a nice day":  How many attacks has DNSSEC stopped to date, vs false positives due to misconfiguration?

That's also why its temporary (unlike most CERT pinning which is far more semi-permanent).  And there is the hurdle of "If you are actually configuring DNSSEC, there is an assumed minimum clue level"

Has anyone yet studied whether the DS and NS RRSETs tend to change at the same time for major domains?

---

From: Andreas Schulze <[email-masked]>
Date: Thu, 29 Aug 2013 08:20:21 +0200

Zitat von Nicholas Weaver <[email-masked]>:

> One thought on DNSSEC and this (nytimes.com) attack.

Nickolas,

your suggestion try to solve the problem by inspecting common behaviour.
What about providing a policy statement?

I imagine an extension, where the subdomain declares an explicit  
statement to the TLD
  - yes, my domain awaits a NS (+DS) change in the delegating domain
  - no, I do not authorise the delegating domain for any change
  - no statement at all ( compatibility / legacy mode)

The statement could be a simple secret generated/assigned by the TLD
and the Subdomainowner provide this as txt record.

If the TLD receive any request for to update/change Delegation data,
it first query all *current* NS for this policy statement.

TLDs could implement this extension. If not, it don't hurt.
It's similiar to the Look state, some TLDs just provide but move the  
storage of
the "look information" away from the TLD to the domainowner.

So an attacker must not only hack the registrar interface but also the
domain he wish to attack. That's more difficult.

Just my thoughts...
Andreas