Exclude a domain from DNSSEC validation, like Unbound's "domain-insecure".

Vernon Schryver vjs at rhyolite.com
Wed Feb 6 21:07:41 UTC 2013


] from Augie Schwer

] Is there a way to exclude a domain from DNSSEC validation, like
] Unbound's "domain-insecure"?

Unless you start at the root with your own forged root trust anchor,
you cannot do more than lie to DNS clients that rely on you to
validate.  DNS clients that do their own validation starting with
their copies of the root trust anchor will always see the problem.
If it were otherwise, then any resolver or firewall in the path
could pervert any and all DNS bits.
 
] For example if a popular site ( say nasa.gov ) updates their keys
] incorrectly so that their domain fails validation, you contact their
] admins. and with a high level of confidence you determine this is a
] configuration mistake and  not a security breach, you can then
] exclude them from DNSSEC validation so your customers can access their
] site while they fix their error.

In such cases, wouldn't it faster, easier, and generally better to
wait a few seconds for those administrators to fix their keys and then
use `rndc flush` or restart your resolver?

There were Comcast's negative trust anchors to address such problems for
Comcast customers.
https://www.google.com/search?q=negative+trust+anchors
It looks as if Comcast has stopped using them.
http://dns.comcast.net/

    ....

> From: Carl Byington <carl at byington.org>

> I have not tested this, but if you use RPZ to block the DS record for
> nasa.gov, that should turn it into an insecure zone.

I don't see how to use RPZ to block only the DS record, because the
DS record is in the parent zone and because RPZ lies about all records
for a domain instead of only a single record type.

You might use RPZ to rewrite and fix an entire zone if you include
"break-dnssec yes" on the response-policy{} statement.  However, DNS
clients that do their own validation will still notice that your fixed
version does not verify and throw fits.  If you could somehow hide the
DS RRs in the parent zone from them, they would notice that the NSEC
or NSEC3 records fail to authenticate the absense of the DS RRs.

I do not see a way to do use RPZ to fix bad keys for nasa.gov,
because nasa.gov contains no A or AAAA records.

There are A and AAAA records for www.nasa.gov, but trying to fix a
hypothetically broken www.nasa.gov looks painful to me, because
www.nasa.gov has the messy, broken DNSSEC chain of CNAMEs of an akamaized
domain.

All of that gets back to honesty being the best policy and letting other
people fix their own stuff in their own time.


RPZ is a fine tool for breaking and generally trashing a domain.
That can a good thing when bad things such as "drive by malware"
would happen if the domain were working.  It's hard to build or fix
things with a wrecking ball.


Vernon Schryver    vjs at rhyolite.com



More information about the bind-users mailing list