Disable DNSSEC Validation for selected Domains

[Stefan...@t-systems.com]

Hi @all,

I know that BIND has no feature to disable DNSSEC validation for selected Zones/Domains (when working as a recursor).
One can only enable/disable DNSSEC validation globally per view (as a boolean on/off).

I found that Microsoft's DNS Server has a feature to skip the validation for some Domains. They call it NRPT (Name Resolution Policy Table).
Unbound also has such a similar Feature (domain-insecure).

Some of the internal Domains of our customers will fail the proof-of-non-existence. While this is technically correct, we still need access to their internal Domain to do our business...
So the current all-or-nothing approach of BIND prevents us from activating DNSSEC all together (and will probably do so for years to come).

I'm just wondering, is an option like unbound's "domain-insecure" intentionally not implemented in in BIND? Or did just nobody care enough to implement it yet?

Regards,
Stefan

[Tony Finch]

Stefan...@t-systems.com <Stefan...@t-systems.com> wrote:
>
> I know that BIND has no feature to disable DNSSEC validation for
> selected Zones/Domains (when working as a recursor).

BIND 9.11 will have negative trust anchors.

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
Fair Isle: Southwest 6 to gale 8, occasionally severe gale 9 at first. Very
rough or high, but rough east of northern isles. Thundery wintry showers.
Good, occasionally poor.

[Mukund Sivaraman]

Hi Stefen

On Tue, Jan 13, 2015 at 11:35:26AM +0100, Stefan...@t-systems.com wrote:
> Some of the internal Domains of our customers will fail the
> proof-of-non-existence. While this is technically correct, we still
> need access to their internal Domain to do our business... So the
> current all-or-nothing approach of BIND prevents us from activating
> DNSSEC all together (and will probably do so for years to come).
>
> I'm just wondering, is an option like unbound's "domain-insecure"
> intentionally not implemented in in BIND? Or did just nobody care
> enough to implement it yet?

BIND will get support for negative trust anchors in 9.11, which will
provide the feature that you seek. An implementation is now in the
master branch.

https://tools.ietf.org/html/draft-livingood-negative-trust-anchors-07

In partnership with our subscription customers who support future
feature development by helping to fund our engineering work, we
currently have a subscription branch where features critical to their
current needs are backported from master and are currently available for
their use. We are trialling the negative trust anchors feature there
now. If you absoutely need this now, please contact ISC about it.

Another option is to run the master branch, but we don't recommend it as
it is a development branch with several new features, some of which may
be unstable or changing rapidly. Negative trust anchors will be released
to the public in the 9.11 release.

Mukund

[Stefan...@t-systems.com]

Hi Mukund

and thanks a lot for pointing that out!
It is already more than I was hoping for :)

Regards,
Stefan

[Daniel Stirnimann]

Hello Stefan

You may also try to disable all DNSSEC algorithms for a zone:

https://lists.dns-oarc.net/pipermail/dns-operations/2014-October/012282.html

Regards,
Daniel

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>

[Chris Buxton]

On Jan 13, 2015, at 2:35 AM, Stefan...@t-systems.com wrote:

> I know that BIND has no feature to disable DNSSEC validation for selected Zones/Domains (when working as a recursor).

> One can only enable/disable DNSSEC validation globally per view (as a boolean on/off).

[...]

> I'm just wondering, is an option like unbound's "domain-insecure" intentionally not implemented in in BIND? Or did just nobody care enough to implement it yet?

While you wait for this to become generally available, you can do what I like to do for my customers: Use two layers of recursive DNS servers. The first layer takes queries from clients, knows about your insecure domains (through stub zones, slave zones, or conditional forwarding), and does not perform DNSSEC validation. The first layer globally forwards to the second layer, which does DNSSEC validation and recursion. This second layer can also have a few other features:

- Placed in the DMZ, outside the internal firewall
- No access to internal namespace, internal devices, etc.
- RPZ filtering, if you're going to use this

You can also achieve much of this within a single named instance using two views, with forwarding from one view to the other.

Chris

[Evan Hunt]

On Jan 13, 2015, at 2:35 AM, Stefan...@t-systems.com wrote:
> I'm just wondering, is an option like unbound's "domain-insecure"
> intentionally not implemented in in BIND? Or did just nobody care
> enough to implement it yet?

I have resisted implementing it because it's too easy for an operator to
forget they knocked a hole in their DNSSEC protections, and leave the hole
in place long after it stopped being useful.

The negative trust anchor implementation that will be released in 9.11
corrects for this with built-in term limits. NTAs are added via rndc,
and they expire and are removed after a relatively short lifespan, not
exceeding a week.

--
Evan Hunt -- ea...@isc.org
Internet Systems Consortium, Inc.

[Stefan...@t-systems.com]

Hm... In our case a short lifespan won't be enough.
Our customer uses a fictional Toplevel Domain and migrating the whole Infrastructure to a new, proper Domain will take him months if not years.
They'll have to adjust every DNS Config of every Server, every Webservice they have running internally, all Documentations etc...
I wouldn't be surprised if they are not even aware of the problem, yet.

Regards,
Stefan


-----Ursprüngliche Nachricht-----
Von: Evan Hunt [mailto:ea...@isc.org]
Gesendet: Mittwoch, 14. Januar 2015 09:13
An: Lasche, Stefan
Cc: BIND Users
Betreff: Re: Disable DNSSEC Validation for selected Domains

[Stefan...@t-systems.com]

Hi Chris,

> While you wait for this to become generally available, you can do what I like to do for my customers: Use two layers of recursive DNS servers. The first layer takes queries from clients, knows about your insecure domains
> (through stub zones, slave zones, or conditional forwarding), and does not perform DNSSEC validation. The first layer globally forwards to the second layer, which does DNSSEC validation and recursion.

Funny thing is, that I have tried something similar already, placing a validating server in the first layer and forwarding problematic Domains to a non-validating server in the second layer. This didn't help.
Now that I read your message, I see that it should have been the other way around to make it work ;)

Regards,
Stefan

[Graham Clinch]

On 14/01/2015 09:34, Stefan...@t-systems.com wrote:

> Our customer uses a fictional Toplevel Domain[...]

Can you flip the problem on its head, by signing the fictional TLD and
deploying managed-keys (or trusted-keys) on the validating resolvers?

Graham

[Stefan...@t-systems.com]

>> Our customer uses a fictional Toplevel Domain[...]
>
> Can you flip the problem on its head, by signing the fictional TLD and deploying managed-keys (or trusted-keys) on the validating resolvers?
>
> Graham

Unfortunately we can't sign the fictional TLD, since we are neither master nor slave of the zone.
We are just forwarding our queries to a foreign authorative Server.

Grüße,
Stefan

[Stefan...@t-systems.com]

Hi Daniel,

> You may also try to disable all DNSSEC algorithms for a zone:
> https://lists.dns-oarc.net/pipermail/dns-operations/2014-October/012282.html
>
> Regards,
> Daniel

Also a nice idea for a workaround :) But it did not work for me.
This is what I tried:

Options {
forward only;
forwarders {
x.x.x.x;
}
dnssec-enable yes;
dnssec-validation auto;
dnssec-lookaside auto;
disable-algorithms "example." { "RSAMD5"; "RSA"; "DH"; "DSA"; "NSEC3DSA"; "ECC"; "RSASHA1"; "NSEC3RSASHA1"; "RSASHA256"; "RSASHA512"; "ECCGOST"; };
}
zone "example" IN {
type forward;
forward only;
forwarders { y.y.y.y; };
};

But BIND still tries to validate and fails...

Regards,
Stefan

[Stuart Browne]

> Unfortunately we can't sign the fictional TLD, since we are neither master
> nor slave of the zone.
> We are just forwarding our queries to a foreign authorative Server.
>
> Grüße,
> Stefan

If the zone isn't signed, it shouldn't be trying to validate it as there's nothing to validate. Unless this fictional TLD now has a real delegated counter-part?

Stuart

[Warren Kumari]

NSEC.
W

--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf

[Stefan...@t-systems.com]

>
>If the zone isn't signed, it shouldn't be trying to validate it as there's nothing to validate. Unless this fictional TLD now has a real delegated counter-part?
>
>Stuart

Just for clarification:
If a TLD does not exist, it can neither be signed nor unsigned.
And, officially, the mentioned TLD does not exist. DNSSEC can prove that much (using NSEC records). DNSSEC won't successfully validate something that isn't even supposed to exist.
Adding a (non-authoritative) zone declaration to BIND does not change this. DNSSEC will still try to validate and fail.
But a "negative trust anchor" could change that and disable the validation for selected zones/domains on your BIND.

Regards,
Stefan

[/dev/rob0]

> -----Ursprüngliche Nachricht-----
> Von: Evan Hunt [mailto:ea...@isc.org]
>

> On Jan 13, 2015, at 2:35 AM, Stefan...@t-systems.com wrote:
> > I'm just wondering, is an option like unbound's "domain-insecure"
> > intentionally not implemented in in BIND? Or did just nobody care
> > enough to implement it yet?
>
> I have resisted implementing it because it's too easy for an
> operator to forget they knocked a hole in their DNSSEC protections,
> and leave the hole in place long after it stopped being useful.
>
> The negative trust anchor implementation that will be released in
> 9.11 corrects for this with built-in term limits. NTAs are added
> via rndc, and they expire and are removed after a relatively short
> lifespan, not exceeding a week.

On Wed, Jan 14, 2015 at 10:34:35AM +0100, Stefan...@t-systems.com
wrote:

> Hm... In our case a short lifespan won't be enough.

I hate to point this out, but a simple workaround to make NTAs
permanent is to have a cron job which runs your "rndc nta" command
as often as needed.

May Evan and the gods of DNSSEC have mercy on my soul! :(

> Our customer uses a fictional Toplevel Domain and migrating the
> whole Infrastructure to a new, proper Domain will take him months
> if not years. They'll have to adjust every DNS Config of every
> Server, every Webservice they have running internally, all
> Documentations etc... I wouldn't be surprised if they are not even
> aware of the problem, yet.

--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: