Bug 678899

Summary:	harden-referral-path should default to "no" (as upstream has)
Product:	[Fedora] Fedora	Reporter:	Stefan Neufeind <redhat>
Component:	unbound	Assignee:	Paul Wouters <pwouters>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	15	CC:	pwouters
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-10-06 02:00:43 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Stefan Neufeind 2011-02-20 17:10:57 UTC

The current default is "harden-referral-path: yes" in Fedora while upstream defaults to "no". We've encountered and debugged strange behaviours which only occured on Fedora and, after quite a while debugging, was found to be caused by harden-referral-path begin activated.

This option is experimental, does not RFC and breaks some things. So while it might be up to everybody to enable it when they really want to, please consider defaulting this to "no" as upstream does.

One reference for such strange behaviour:
http://www.mail-archive.com/unbound-users@unbound.net/msg00423.html

PS: Please "backport" for packages in F14 etc. as well, if needed.

Comment 1 Stefan Neufeind 2011-05-24 06:19:07 UTC

*ping*

Comment 2 Paul Wouters 2011-06-07 01:35:48 UTC

So there is a good reason to do this.

What this option does is provide added security to non-DNSSEC domains.

It looks up NS records on at least two nameservers, so that you would have to cache poison not one, but two packets successfully.

If this is failing, it usually means the domain nameservers are not setup properly.

The link you refer to is a bug that has been fixed.

Is this really a widespread problem?

Comment 3 Paul Wouters 2011-09-21 18:32:42 UTC

*ping* ?