Features/DNSSEC

From FedoraProject

< Features(Difference between revisions)
Jump to: navigation, search
(Feature Name)
 
(48 intermediate revisions by 9 users not shown)
Line 1: Line 1:
 
= Feature Name =
 
= Feature Name =
DNSSEC - Secure our DNS servers
+
DNSSEC - Enable DNSSEC and DLV security extensions for DNS and prime validating resolvers with DNSSEC keys. This feature has been included in Fedora 11
 +
 
 +
This page has been obsoleted by:
 +
 
 +
 
 +
https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations
 +
 
 +
 
 +
 
  
 
== Summary ==
 
== Summary ==
DNSSEC (DNS SECurity) is mechanism which can prove integrity and autenticity of DNS data. It became important after new DNS poisonning attacks which were found recently. The most widely used servers should be DNSSEC aware by default (bind, nsd, unbound)
+
DNSSEC (DNS SECurity) is mechanism which provides integrity and authenticity of DNS data. It became more important after new Kaminsky DNS poisoning attacks were found in early 2008. The most widely used recursing nameservers support DNSSEC. We currently support it for [https://admin.fedoraproject.org/pkgdb/packages/name/bind bind] and [https://admin.fedoraproject.org/pkgdb/packages/name/unbound unbound].
  
 
== Owner ==
 
== Owner ==
* Name: [[AdamTkac| AdamTkac]]
+
* Name: [[AdamTkac| Adam Tkac]]
 
+
* Name: [[pwouters| Paul Wouters]]
<!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or  technical issues need to be resolved-->
+
* email: <your email address so we can contact you, invite you to meetings, etc.>
+
  
 
== Current status ==
 
== Current status ==
* Targeted release: [[Releases/{{FedoraVersion||next}} | {{FedoraVersion|long|next}} ]]  
+
* Targeted release: [[Releases/{{FedoraVersion||11}} | {{FedoraVersion|long|next}} ]]  
* Last updated: (DATE)
+
* Last updated: 2009-04-15
* Percentage of completion: XX%
+
* Percentage of completion: 100%
 
+
<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. -->
+
  
 
== Detailed Description ==
 
== Detailed Description ==
<!-- Expand on the summary, if appropriateA couple sentences suffices to explain the goal, but the more details you can provide the better. -->
+
Important DNS nameserver software and some TLD's already support DNSSEC. Main problem is key distribution. A full validation path would start at the root (".") but it is not likely that the root will be signed very soon. There are two methods for working around not having a signed root:
 +
* Using Trust Anchor Repositories (TAR's or "batched TAR") for TLD keys
 +
* Using DNSSEC Lookaside Verification (DLV or "live TAR") for enduser domains within an unsigned TLD.
 +
 
 +
This feature adds support for both TAR and DLV support, using the following approach:
 +
 
 +
* supply initial set of DNSSEC keys for TLD's (and perhaps some "very important domains") as long as the root is not signed. This is done via [https://admin.fedoraproject.org/pkgdb/packages/name/dnssec-conf dnssec-conf]) (completed)
 +
* allow easy way to enable/disable DNSSEC via commandline tool dnssec-configure from the dnssec-conf package (completed)
 +
* allow configuration of any DLV Registry, with the default set to [http://dlv.isc.org ISC], using the above two mentioned tools (completed)
 +
* support for automated Trust Anchor Rollovers from DNS information via the [https://admin.fedoraproject.org/pkgdb/packages/nameautotrust autotrust] package using secure RFC5011 update mechanism. This is in addition to updates supplied via the dnssec-conf package. (completed)
  
 
== Benefit to Fedora ==
 
== Benefit to Fedora ==
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
+
Our servers (and clients) will be able to use DNSSEC, and be safer against cache poisoning, Kaminsky attacks, spoofing and other known DNS attacks. Fedora machines will also be able to use signed TLD's and individually signed domains in DLV without any additional administration. For example, right now that already includes DNSSEC for the entire .gov domain, plus a handful of TLD's and a few dozen in-arpa domains including the ENUM zone.
  
 
== Scope ==
 
== Scope ==
<!-- What work do the developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
+
* create and add a package dnssec-conf which will supply initial set of DNSSEC keys to machines. (completed)
 +
* Do not yet enable DNSSEC in default bind and unbound configurations. But make it trivially easy to enable DNSSEC via dnssec-conf. (completed)
 +
* create commandline tool (dnssec-configure from the dnssec-conf package) that will easily enable/disable DNSSEC and which allows to switch between DLV Registries and supplied DNSSEC keys (completed)
 +
* add the "autotrust" package which implements RFC 5011 - "Automated Updates of DNS Security (DNSSEC) Trust Anchors". This package includes a daily cronjob that will try to update any configured DNSSEC trust anchors from the dnssec-conf package, and any manually installed trust anchors by the administrator. (completed)
 +
* create system-config-dnssec GUI tool to enable / disable the most important features (70% done)
 +
* Update the Bind and Unbound packages so the default configurations enable DNSSEC for Fedora-11
  
== How To Test ==
+
== How To Install ==
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them. The QA team will turn this information into a more complete test plan.  The more specific you can be, the better the final test plan will be.
+
<pre>
 +
yum install bind-utils
 +
  yum install bind (or unbound or both)
 +
  service named start (or unbound or both)
 +
</pre>
  
Remember that you are writing this test plan for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.
+
This installation should bring in dnssec-conf. Starting the daemon once will update the DNSSEC and DLV settings for the daemons. Settings can be changed in /etc/sysconfig/dnssec
 +
You can verify the installation and configuration using:
  
A good Test Plan should answer these four questions:
+
<pre>
 +
dnssec-configure -s
 +
</pre>
  
0. What special hardware / data / etc. is needed (if any)?
+
DNSSEC is enabled per default. DLV is also enabled per default, and uses [http://dlv.isc.org dlv.isc.org] as the DLV Registry. If you want to disable DNSSEC or DLV, edit /etc/sysconfig/dnssec. After changing this file, restart the daemon you were using:
1. How do I prepare my system to test this feature? What packages
+
<pre>
need to be installed, config files edited, etc.?
+
service named restart (or service unbound restart)
2. What specific actions do I perform to check that the feature is
+
</pre>
working like it's supposed to?
+
3. What are the expected results of those actions?
+
  
-->
+
For the GUI, use
 +
 
 +
<pre>
 +
yum install system-config-dnssec
 +
</pre>
 +
 
 +
Navigate to System->Administration->DNSSEC
 +
 
 +
(system-config-dnssec is not yet finished)
 +
 
 +
== How to Test ==
 +
<pre>
 +
dig +dnssec +multiline -t ns gov. @localhost
 +
</pre>
 +
You should see the AD ("Authenticated Data") bit in the reply, as well as the RRSIG signature record:
 +
<pre>
 +
$ dig +dnssec +multiline -t ns gov. @127.0.0.1
 +
 +
; <<>> DiG 9.5.1b3-RedHat-9.5.1-0.9.b3.fc10 <<>> +dnssec +multiline -t ns gov. @localhost
 +
;; global options:  printcmd
 +
;; Got answer:
 +
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14948
 +
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1
 +
 
 +
;; OPT PSEUDOSECTION:
 +
; EDNS: version: 0, flags: do; udp: 4096
 +
;; QUESTION SECTION:
 +
;gov. IN NS
 +
 
 +
;; ANSWER SECTION:
 +
gov. 259188 IN NS G.GOV.ZONEEDIT.COM.
 +
gov. 259188 IN NS A.GOV.ZONEEDIT.COM.
 +
gov. 259188 IN NS C.GOV.ZONEEDIT.COM.
 +
gov. 259188 IN NS E.GOV.ZONEEDIT.COM.
 +
gov. 259188 IN NS D.GOV.ZONEEDIT.COM.
 +
gov. 259188 IN NS F.GOV.ZONEEDIT.COM.
 +
gov. 259188 IN NS B.GOV.ZONEEDIT.COM.
 +
gov. 259188 IN RRSIG NS 7 1 259200 20090309210102 (
 +
20090304210102 31802 gov.
 +
N1azd+3+CfHD4YIMukC/cGlNBTvaG6gDOa7KmSy+MmjI
 +
hWiJv+1bHuj3caDrJ98vR4KuyS7xCb/q5J7ParrjtLYV
 +
YWxnB6dDdX8cyhB9NjAuwOmCrmXIM9/3uedKwpbuQK1z
 +
ktWuHp0xbQT1bkxKnqZswASqbqB96lvfryWsAH01M9b9
 +
AOA/FP/iefWLGD/JaDCEfy2DtD2tke7hXNIQZICegoye
 +
oK1VhiOgkRYv6iEdYIH/pBztsP+DfaD5+hdBjQp2/P5b
 +
7LflyjK2S26ZSZ3LAxDgWZGDvCFngCozSaoLq16RO4DU
 +
vVPg33HHycdslVP2s+mtthkW9wcAC9+IMA== )
 +
 
 +
;; Query time: 122 msec
 +
;; SERVER: 193.110.157.136#53(193.110.157.136)
 +
;; WHEN: Wed Mar  4 18:07:11 2009
 +
;; MSG SIZE  rcvd: 451
 +
</pre>
 +
If you want to see more DNSSEC related records run:
 +
<pre>
 +
dig +multiline +dnssec -t any gov. @localhost
 +
</pre>
 +
 
 +
To test the DLV, try to resolve a known DLV entry that does not occur in a DNSSEC signed zone (and is not loaded explicitely, such as dlv.isc.org), for example:
 +
<pre>
 +
dig +dnssec +multiline -t ns isc.org.
 +
</pre>
 +
 
 +
To verify that forged/broken data is properly refused, you can test against some test zones:
 +
<pre>
 +
dig +multiline +dnssec forged.test.xelerance.com @localhost
 +
</pre>
 +
This should produce a ServFail answer. To force getting the known bad answer, run:
 +
<pre>
 +
dig +multiline +dnssec +cd forged.test.xelerance.com @localhost
 +
</pre>
 +
This should produce the forged/broken answer despite its known forgery.
 +
 
 +
To test the denial of existence, you can query a non-existing domain in a dnssec siged zone, eg:
 +
<pre>
 +
dig +dnssec +multiline -t ns thisdoesnotexist.se.
 +
</pre>
 +
This should return a the same "AD" bit, as well as an NSEC record. In this case:
 +
 
 +
<pre>
 +
thisdesertlife.se. 7200 IN NSEC thisell.se. NS RRSIG NSEC
 +
</pre>
 +
This is a signed response saying your domain thisdoesnotexist.se does not exist. The signed entry here starts with "thisdesertlife.se." and the next record is "thisell.se". Since "thisdoesnotexist.se" would fall in between these two, this (sgned) record would only exist if "thisdoesnotexist.se" would not exist. To avoid revealing other domain names, another more complex method, called NSEC3, can be used. This is in use wth .gov, so you will see that manually validating that answer is much harder. For details on NSEC3, see RFC-5155
  
 
== User Experience ==
 
== User Experience ==
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. -->
+
Easy configuration and priming of DNSSEC aware resolvers.
 +
 
 +
== Related Packages ==
 +
 
 +
* [https://admin.fedoraproject.org/pkgdb/acls/name/ldns ldns]
 +
* [https://admin.fedoraproject.org/pkgdb/acls/name/unbound unbound]
 +
* [https://admin.fedoraproject.org/pkgdb/acls/name/bind bind]
 +
* [https://admin.fedoraproject.org/pkgdb/acls/name/nsd nsd]
 +
* [https://admin.fedoraproject.org/pkgdb/acls/name/autotrust autotrust]
 +
* [https://admin.fedoraproject.org/pkgdb/acls/name/dnssec-conf dnssec-conf]
 +
* [https://admin.fedoraproject.org/pkgdb/acls/name/sshfp sshfp]
 +
* system-config-dnssec (preview: [ftp://ftp.xelerance.com/system-config-dnssec])
  
 
== Dependencies ==
 
== Dependencies ==
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
+
None
  
 
== Contingency Plan ==
 
== Contingency Plan ==
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
+
Disable DNSSEC and/or DLV by default in /etc/sysconfig/dnssec and release a software update of dnssec-conf
  
 
== Documentation ==
 
== Documentation ==
<!-- Is there upstream documentation on this feature, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
+
http://www.dnssec.net/
 
+
  
 
== Release Notes ==
 
== Release Notes ==
 +
Bind and unbound (recursive DNS servers) now enable DNSSEC validation in their default configuration. DNSSEC Lookaside Verification (DLV) is also enabled with the [http://dlv.isc.org/ dlv.sc.org] DLV Registry.
 +
This behaviour can be modified in /etc/sysconfig/dnssec by changing the DNSSEC and DLV settings.
  
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
+
With DNSSEC enabled, when a domain supplies DNSSEC data (such as .gov, .se, the ENUM zone and other TLD's) then that data will be cryptographically validated on the recursive DNS server. If validation fails, due to attempts at cache poisoning (eg via a Kaminsky Attack) then the enduser will not be given this forged/spoofed data. DNSSEC deployment is gaining speed rapidly, and is a crucial part and the next logical step to make the internet more secure for end users. DLV is used to add DNSSEC signed domains into TLD's that themselves are not yet signed, such as .com and .org.
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
+
  
 
== Comments and Discussion ==
 
== Comments and Discussion ==
  
* See [[Talk:Features/YourFeatureName]]  <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
+
* See [[Talk:Features/DNSSEC]]  <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
 
+
  
----
+
[[Category:FeatureAcceptedF11]]
  
[[Category:FeaturePageIncomplete]]
 
 
<!-- When your feature page is completed and ready for review -->
 
<!-- When your feature page is completed and ready for review -->
 
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
 
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
 
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
 
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
 
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->
 
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

Latest revision as of 16:24, 11 March 2012

Contents

[edit] Feature Name

DNSSEC - Enable DNSSEC and DLV security extensions for DNS and prime validating resolvers with DNSSEC keys. This feature has been included in Fedora 11

This page has been obsoleted by:


https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations



[edit] Summary

DNSSEC (DNS SECurity) is mechanism which provides integrity and authenticity of DNS data. It became more important after new Kaminsky DNS poisoning attacks were found in early 2008. The most widely used recursing nameservers support DNSSEC. We currently support it for bind and unbound.

[edit] Owner

[edit] Current status

  • Targeted release: Fedora 21
  • Last updated: 2009-04-15
  • Percentage of completion: 100%

[edit] Detailed Description

Important DNS nameserver software and some TLD's already support DNSSEC. Main problem is key distribution. A full validation path would start at the root (".") but it is not likely that the root will be signed very soon. There are two methods for working around not having a signed root:

  • Using Trust Anchor Repositories (TAR's or "batched TAR") for TLD keys
  • Using DNSSEC Lookaside Verification (DLV or "live TAR") for enduser domains within an unsigned TLD.

This feature adds support for both TAR and DLV support, using the following approach:

  • supply initial set of DNSSEC keys for TLD's (and perhaps some "very important domains") as long as the root is not signed. This is done via dnssec-conf) (completed)
  • allow easy way to enable/disable DNSSEC via commandline tool dnssec-configure from the dnssec-conf package (completed)
  • allow configuration of any DLV Registry, with the default set to ISC, using the above two mentioned tools (completed)
  • support for automated Trust Anchor Rollovers from DNS information via the autotrust package using secure RFC5011 update mechanism. This is in addition to updates supplied via the dnssec-conf package. (completed)

[edit] Benefit to Fedora

Our servers (and clients) will be able to use DNSSEC, and be safer against cache poisoning, Kaminsky attacks, spoofing and other known DNS attacks. Fedora machines will also be able to use signed TLD's and individually signed domains in DLV without any additional administration. For example, right now that already includes DNSSEC for the entire .gov domain, plus a handful of TLD's and a few dozen in-arpa domains including the ENUM zone.

[edit] Scope

  • create and add a package dnssec-conf which will supply initial set of DNSSEC keys to machines. (completed)
  • Do not yet enable DNSSEC in default bind and unbound configurations. But make it trivially easy to enable DNSSEC via dnssec-conf. (completed)
  • create commandline tool (dnssec-configure from the dnssec-conf package) that will easily enable/disable DNSSEC and which allows to switch between DLV Registries and supplied DNSSEC keys (completed)
  • add the "autotrust" package which implements RFC 5011 - "Automated Updates of DNS Security (DNSSEC) Trust Anchors". This package includes a daily cronjob that will try to update any configured DNSSEC trust anchors from the dnssec-conf package, and any manually installed trust anchors by the administrator. (completed)
  • create system-config-dnssec GUI tool to enable / disable the most important features (70% done)
  • Update the Bind and Unbound packages so the default configurations enable DNSSEC for Fedora-11

[edit] How To Install

 yum install bind-utils
 yum install bind (or unbound or both)
 service named start (or unbound or both)

This installation should bring in dnssec-conf. Starting the daemon once will update the DNSSEC and DLV settings for the daemons. Settings can be changed in /etc/sysconfig/dnssec You can verify the installation and configuration using:

 dnssec-configure -s

DNSSEC is enabled per default. DLV is also enabled per default, and uses dlv.isc.org as the DLV Registry. If you want to disable DNSSEC or DLV, edit /etc/sysconfig/dnssec. After changing this file, restart the daemon you were using:

 service named restart (or service unbound restart)

For the GUI, use

 yum install system-config-dnssec

Navigate to System->Administration->DNSSEC

(system-config-dnssec is not yet finished)

[edit] How to Test

 dig +dnssec +multiline -t ns gov. @localhost

You should see the AD ("Authenticated Data") bit in the reply, as well as the RRSIG signature record:

$ dig +dnssec +multiline -t ns gov. @127.0.0.1
 
; <<>> DiG 9.5.1b3-RedHat-9.5.1-0.9.b3.fc10 <<>> +dnssec +multiline -t ns gov. @localhost
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14948
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;gov.			IN NS

;; ANSWER SECTION:
gov.			259188 IN NS G.GOV.ZONEEDIT.COM.
gov.			259188 IN NS A.GOV.ZONEEDIT.COM.
gov.			259188 IN NS C.GOV.ZONEEDIT.COM.
gov.			259188 IN NS E.GOV.ZONEEDIT.COM.
gov.			259188 IN NS D.GOV.ZONEEDIT.COM.
gov.			259188 IN NS F.GOV.ZONEEDIT.COM.
gov.			259188 IN NS B.GOV.ZONEEDIT.COM.
gov.			259188 IN RRSIG	NS 7 1 259200 20090309210102 (
				20090304210102 31802 gov.
				N1azd+3+CfHD4YIMukC/cGlNBTvaG6gDOa7KmSy+MmjI
				hWiJv+1bHuj3caDrJ98vR4KuyS7xCb/q5J7ParrjtLYV
				YWxnB6dDdX8cyhB9NjAuwOmCrmXIM9/3uedKwpbuQK1z
				ktWuHp0xbQT1bkxKnqZswASqbqB96lvfryWsAH01M9b9
				AOA/FP/iefWLGD/JaDCEfy2DtD2tke7hXNIQZICegoye
				oK1VhiOgkRYv6iEdYIH/pBztsP+DfaD5+hdBjQp2/P5b
				7LflyjK2S26ZSZ3LAxDgWZGDvCFngCozSaoLq16RO4DU
				vVPg33HHycdslVP2s+mtthkW9wcAC9+IMA== )

;; Query time: 122 msec
;; SERVER: 193.110.157.136#53(193.110.157.136)
;; WHEN: Wed Mar  4 18:07:11 2009
;; MSG SIZE  rcvd: 451

If you want to see more DNSSEC related records run:

 dig +multiline +dnssec -t any gov. @localhost

To test the DLV, try to resolve a known DLV entry that does not occur in a DNSSEC signed zone (and is not loaded explicitely, such as dlv.isc.org), for example:

dig +dnssec +multiline -t ns isc.org.

To verify that forged/broken data is properly refused, you can test against some test zones:

 dig +multiline +dnssec forged.test.xelerance.com @localhost

This should produce a ServFail answer. To force getting the known bad answer, run:

 dig +multiline +dnssec +cd forged.test.xelerance.com @localhost

This should produce the forged/broken answer despite its known forgery.

To test the denial of existence, you can query a non-existing domain in a dnssec siged zone, eg:

dig +dnssec +multiline -t ns thisdoesnotexist.se.

This should return a the same "AD" bit, as well as an NSEC record. In this case:

thisdesertlife.se.	7200 IN	NSEC thisell.se. NS RRSIG NSEC

This is a signed response saying your domain thisdoesnotexist.se does not exist. The signed entry here starts with "thisdesertlife.se." and the next record is "thisell.se". Since "thisdoesnotexist.se" would fall in between these two, this (sgned) record would only exist if "thisdoesnotexist.se" would not exist. To avoid revealing other domain names, another more complex method, called NSEC3, can be used. This is in use wth .gov, so you will see that manually validating that answer is much harder. For details on NSEC3, see RFC-5155

[edit] User Experience

Easy configuration and priming of DNSSEC aware resolvers.

[edit] Related Packages

[edit] Dependencies

None

[edit] Contingency Plan

Disable DNSSEC and/or DLV by default in /etc/sysconfig/dnssec and release a software update of dnssec-conf

[edit] Documentation

http://www.dnssec.net/

[edit] Release Notes

Bind and unbound (recursive DNS servers) now enable DNSSEC validation in their default configuration. DNSSEC Lookaside Verification (DLV) is also enabled with the dlv.sc.org DLV Registry. This behaviour can be modified in /etc/sysconfig/dnssec by changing the DNSSEC and DLV settings.

With DNSSEC enabled, when a domain supplies DNSSEC data (such as .gov, .se, the ENUM zone and other TLD's) then that data will be cryptographically validated on the recursive DNS server. If validation fails, due to attempts at cache poisoning (eg via a Kaminsky Attack) then the enduser will not be given this forged/spoofed data. DNSSEC deployment is gaining speed rapidly, and is a crucial part and the next logical step to make the internet more secure for end users. DLV is used to add DNSSEC signed domains into TLD's that themselves are not yet signed, such as .com and .org.

[edit] Comments and Discussion