DNSSEC single point of failure?

older
More NZ SDN news - CARDIGAN gains...

Jean-Francois Pirus

23 Aug 2014 23 Aug '14

4 a.m.

Unless I'm missing something, looks like my internal dns stopped working because there were issues with the link to the US. All because dnssec is enabled in bind. Namely queries from a resolver server would timeout looking up MYHOST.MYDOMAIN.com.dlv.isc.org before it got to querying my authoritative server. Is there any way to work around that? Seems like a single point of failure, where resolvers will fail if there are any issues with com.dlv.isc.org. Thanks. -- Jean-Francois Pirus | Technical Manager francois(a)clearfield.com | Mob +64 21 640 779 | DDI +64 9 282 3401 Clearfield Software Ltd | Ph +64 9 358 2081 | www.clearfield.com

Show replies by date

Jay Daley

23 Aug 23 Aug

4:12 a.m.

Is there any particular reason you are using DLV and not ordinary root DNSSEC? On 24/08/2014, at 9:00 am, Jean-Francois Pirus wrote:

...

Unless I'm missing something, looks like my internal dns stopped working because there were issues with the link to the US.

All because dnssec is enabled in bind.

Namely queries from a resolver server would timeout looking up MYHOST.MYDOMAIN.com.dlv.isc.org before it got to querying my authoritative server.

It's been a while but I thought it was myhost.mydomain.dlv.isc.org (i.e. no .com)

...

Is there any way to work around that?

Don't use DLV? Jay

...

Seems like a single point of failure, where resolvers will fail if there are any issues with com.dlv.isc.org.

Thanks.

-- Jean-Francois Pirus | Technical Manager francois(a)clearfield.com | Mob +64 21 640 779 | DDI +64 9 282 3401

Clearfield Software Ltd | Ph +64 9 358 2081 | www.clearfield.com _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley

Jean-Francois Pirus

4:23 a.m.

On Sun, 24 Aug 2014 09:12:26 Jay Daley wrote:

...

Is there any particular reason you are using DLV and not ordinary root DNSSEC?

I'm just using the default dnssec config for Bind 9.8 on RHEL 6, under the assumption that the defaults would be safe. Thanks.

...

On 24/08/2014, at 9:00 am, Jean-Francois Pirus wrote:

...
Unless I'm missing something, looks like my internal dns stopped working because there were issues with the link to the US.

All because dnssec is enabled in bind.

Namely queries from a resolver server would timeout looking up MYHOST.MYDOMAIN.com.dlv.isc.org before it got to querying my authoritative server.

It's been a while but I thought it was myhost.mydomain.dlv.isc.org (i.e. no .com)

...
Is there any way to work around that?

Don't use DLV?

Jay

...
Seems like a single point of failure, where resolvers will fail if there are any issues with com.dlv.isc.org.

Thanks.

Sebastian Castro

4:50 a.m.

On 24/08/14 9:23 am, Jean-Francois Pirus wrote:

...

On Sun, 24 Aug 2014 09:12:26 Jay Daley wrote:

...
Is there any particular reason you are using DLV and not ordinary root DNSSEC?

I'm just using the default dnssec config for Bind 9.8 on RHEL 6, under the assumption that the defaults would be safe.

That's interesting to see. Your configuration has a SPoF because requires access to the DLV @ isc.org. But if you use the root trust anchor, you can benefit from the multiple copies of the root zone around the world (including 3 in NZ if my memory serves me well). Sounds like a good point to raise to the BIND configuration maintainer at RedHat, because unless you have specific requirements, it's better not to use DLV. Cheers,

...

Thanks.

...
On 24/08/2014, at 9:00 am, Jean-Francois Pirus wrote:

...
Unless I'm missing something, looks like my internal dns stopped working because there were issues with the link to the US.

All because dnssec is enabled in bind.

Namely queries from a resolver server would timeout looking up MYHOST.MYDOMAIN.com.dlv.isc.org before it got to querying my authoritative server.

It's been a while but I thought it was myhost.mydomain.dlv.isc.org (i.e. no .com)

...
Is there any way to work around that?

Don't use DLV?

Jay

...
Seems like a single point of failure, where resolvers will fail if there are any issues with com.dlv.isc.org.

Thanks.

-- Sebastian Castro Technical Research Manager .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535

Jay Daley

4:56 a.m.

On 24/08/2014, at 9:23 am, Jean-Francois Pirus wrote:

...

On Sun, 24 Aug 2014 09:12:26 Jay Daley wrote:

...
Is there any particular reason you are using DLV and not ordinary root DNSSEC?

I'm just using the default dnssec config for Bind 9.8 on RHEL 6, under the assumption that the defaults would be safe.

As sebastian says, no need for DLV. Remove the line dnssec-lookaside auto Jay -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley

Jean-Francois Pirus

5:01 a.m.

On Sun, 24 Aug 2014 09:56:59 Jay Daley wrote:

...

On 24/08/2014, at 9:23 am, Jean-Francois Pirus wrote:

...
On Sun, 24 Aug 2014 09:12:26 Jay Daley wrote:

...
Is there any particular reason you are using DLV and not ordinary root DNSSEC?

I'm just using the default dnssec config for Bind 9.8 on RHEL 6, under the assumption that the defaults would be safe.

As sebastian says, no need for DLV. Remove the line

dnssec-lookaside auto

I'll do that. Thanks. A bit of a gotcha I though people should be aware of.

...

Jay

Jasper Bryant-Greene

9:10 a.m.

On Sun, Aug 24, 2014 at 10:01:13AM +1200, Jean-Francois Pirus wrote:

...

I'll do that. Thanks.

A bit of a gotcha I though people should be aware of.

The gotcha here is using your distro's default configuration for a piece of software as complex as BIND, for something as important as DNS, without reading and fully understanding what that default configuration does. -jasper

Phil Regnauld

6:54 p.m.

On Sun, Aug 24, 2014 at 10:01:13AM +1200, Jean-Francois Pirus wrote:

...

I'll do that. Thanks.

A bit of a gotcha I though people should be aware of.

Very good info - thanks for bringing this up. It's definitely not common practice to be using DLV nowadays, and I hope RedHat can disable that in future revisions. Oh, and upgrade to bind 9.10 as well :) Cheers, Phil

Joe Abley

24 Aug 24 Aug

9:06 p.m.

On 23 Aug 2014, at 17:00, Jean-Francois Pirus wrote:

...

Unless I'm missing something, looks like my internal dns stopped working because there were issues with the link to the US.

My understanding is that dlv.isc.org is served on three separate anycast clouds, hosted by ISC, Afilias and Ultra. If there's none of any of those in New Zealand (which seems entirely possible) you're going to have problems doing local resolution with DLV. You you have a better chance of maintaining local resolution and validation if you turn off DLV and just use a root KSK trust anchor. There are multiple root servers reachable within New Zealand, peering willing. DLV was a transition mechanism that was arguably most useful before the root zone was signed. The root zone was signed in 2010. My advice would be to turn it off, to avoid exactly the kind of problem you described. Joe

Ewen McNeill

25 Aug 25 Aug

2:37 a.m.

On 26/08/14 2:06, Joe Abley wrote:

...

DLV was a transition mechanism that was arguably most useful before the root zone was signed. The root zone was signed in 2010.

FWIW, the original poster mentioned using RHEL 6. Which was first released in 2010: https://access.redhat.com/articles/3078 Presumably the default config file examples were first prepared at a point when DLV still looked like a useful idea (eg, before the root/as many TLDs were signed, when 2LD/3LD trust anchors were potentially helpful). AFAIK RHEL don't update the default config files in point releases, so I suspect it still has the GA config files by default. I'd definitely echo the sentiments of others that when deploying an older operating system (and RHEL 6 is coming up to 4 years old; RHEL 7 was released earlier this year) it is worth the time to double check that key software components important to you, especially those for an area like DNSSEC which has seen significant change over that time, are (a) still the best version for you to run and (b) have appropriate configuration. What was potentially a good idea in 2010 may not still be a good idea in 2014. Which is not really specific to RHEL 6, or even DNSSEC, so much as best practice when deploying older software. Definitely something to be aware of with RHEL 6 and DNSSEC though, as they were one of the first OS to ship with DNSSEC validation preconfigured. I doubt this will be the last time someone deploys RHEL 6 in 2014 or even 2015... Ewen

Jean-Francois Pirus

5:43 a.m.

On the slightly worse news department, DLV lookup is still the default for RHEL7/Centos7 with bind-9.9.4. So this will be an issue for future deployments too.

...

From the named.conf: dnssec-lookaside auto; and // Provided by Red Hat bind package to configure the ISC BIND named(8) DNS

On Tue, 26 Aug 2014 07:37:52 Ewen McNeill wrote:

...

On 26/08/14 2:06, Joe Abley wrote:

...
DLV was a transition mechanism that was arguably most useful before the root zone was signed. The root zone was signed in 2010.

FWIW, the original poster mentioned using RHEL 6. Which was first released in 2010:

https://access.redhat.com/articles/3078

Presumably the default config file examples were first prepared at a point when DLV still looked like a useful idea (eg, before the root/as many TLDs were signed, when 2LD/3LD trust anchors were potentially helpful). AFAIK RHEL don't update the default config files in point releases, so I suspect it still has the GA config files by default.

I'd definitely echo the sentiments of others that when deploying an older operating system (and RHEL 6 is coming up to 4 years old; RHEL 7 was released earlier this year) it is worth the time to double check that key software components important to you, especially those for an area like DNSSEC which has seen significant change over that time, are (a) still the best version for you to run and (b) have appropriate configuration. What was potentially a good idea in 2010 may not still be a good idea in 2014.

Which is not really specific to RHEL 6, or even DNSSEC, so much as best practice when deploying older software. Definitely something to be aware of with RHEL 6 and DNSSEC though, as they were one of the first OS to ship with DNSSEC validation preconfigured. I doubt this will be the last time someone deploys RHEL 6 in 2014 or even 2015...

Ewen _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Jean-Francois Pirus

6:40 a.m.

FYI: A bug has been raised with RedHat. "Outaded DLV (DNSSEC Lookaside Validation) configuration causes single point of failure" https://bugzilla.redhat.com/show_bug.cgi?id=1133713 On Tue, 26 Aug 2014 10:43:53 Jean-Francois Pirus wrote:

...

On the slightly worse news department, DLV lookup is still the default for RHEL7/Centos7 with bind-9.9.4.

So this will be an issue for future deployments too.

From the named.conf: dnssec-lookaside auto; and // Provided by Red Hat bind package to configure the ISC BIND named(8) DNS

On Tue, 26 Aug 2014 07:37:52 Ewen McNeill wrote:

...
On 26/08/14 2:06, Joe Abley wrote:

...
DLV was a transition mechanism that was arguably most useful before the root zone was signed. The root zone was signed in 2010.

FWIW, the original poster mentioned using RHEL 6. Which was first released in 2010:

https://access.redhat.com/articles/3078

Presumably the default config file examples were first prepared at a point when DLV still looked like a useful idea (eg, before the root/as many TLDs were signed, when 2LD/3LD trust anchors were potentially helpful). AFAIK RHEL don't update the default config files in point releases, so I suspect it still has the GA config files by default.

I'd definitely echo the sentiments of others that when deploying an older operating system (and RHEL 6 is coming up to 4 years old; RHEL 7 was released earlier this year) it is worth the time to double check that key software components important to you, especially those for an area like DNSSEC which has seen significant change over that time, are (a) still the best version for you to run and (b) have appropriate configuration. What was potentially a good idea in 2010 may not still be a good idea in 2014.

Which is not really specific to RHEL 6, or even DNSSEC, so much as best practice when deploying older software. Definitely something to be aware of with RHEL 6 and DNSSEC though, as they were one of the first OS to ship with DNSSEC validation preconfigured. I doubt this will be the last time someone deploys RHEL 6 in 2014 or even 2015...

Ewen _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Fraser McGlinn

26 Aug 26 Aug

11:08 a.m.

Hi Everyone, Just as an FYI to those not on the Bind Mailing list, there has also been some discussion on there (from the engineer who responded to the bug) regarding the DLV configuration. https://lists.isc.org/pipermail/bind-users/2014-August/093834.html Thanks, Fraser On 26/08/2014 11:40 a.m., Jean-Francois Pirus wrote:

...

FYI: A bug has been raised with RedHat.

"Outaded DLV (DNSSEC Lookaside Validation) configuration causes single point of failure" https://bugzilla.redhat.com/show_bug.cgi?id=1133713

On Tue, 26 Aug 2014 10:43:53 Jean-Francois Pirus wrote:

...
On the slightly worse news department, DLV lookup is still the default for RHEL7/Centos7 with bind-9.9.4.

So this will be an issue for future deployments too.

From the named.conf: dnssec-lookaside auto; and // Provided by Red Hat bind package to configure the ISC BIND named(8) DNS

On Tue, 26 Aug 2014 07:37:52 Ewen McNeill wrote:

...
On 26/08/14 2:06, Joe Abley wrote:

...
DLV was a transition mechanism that was arguably most useful before the root zone was signed. The root zone was signed in 2010. FWIW, the original poster mentioned using RHEL 6. Which was first released in 2010:

https://access.redhat.com/articles/3078

Presumably the default config file examples were first prepared at a point when DLV still looked like a useful idea (eg, before the root/as many TLDs were signed, when 2LD/3LD trust anchors were potentially helpful). AFAIK RHEL don't update the default config files in point releases, so I suspect it still has the GA config files by default.

I'd definitely echo the sentiments of others that when deploying an older operating system (and RHEL 6 is coming up to 4 years old; RHEL 7 was released earlier this year) it is worth the time to double check that key software components important to you, especially those for an area like DNSSEC which has seen significant change over that time, are (a) still the best version for you to run and (b) have appropriate configuration. What was potentially a good idea in 2010 may not still be a good idea in 2014.

Which is not really specific to RHEL 6, or even DNSSEC, so much as best practice when deploying older software. Definitely something to be aware of with RHEL 6 and DNSSEC though, as they were one of the first OS to ship with DNSSEC validation preconfigured. I doubt this will be the last time someone deploys RHEL 6 in 2014 or even 2015...

Ewen _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

3771

Age (days ago)

3774

Last active (days ago)

List overview

Download

12 comments

8 participants

participants (8)

Ewen McNeill
Fraser McGlinn
Jasper Bryant-Greene
Jay Daley
Jean-Francois Pirus
Joe Abley
Phil Regnauld
Sebastian Castro