diff --git a/bin/tests/system/pending/clean.sh b/bin/tests/system/pending/clean.sh new file mode 100644 index 0000000000..3ecb0302bc --- /dev/null +++ b/bin/tests/system/pending/clean.sh @@ -0,0 +1,10 @@ +# +rm -rf */*.signed +rm -rf */K* +rm -rf */dsset-* +rm -rf */named.memstats +rm -rf */named.run +rm -rf */trusted.conf +rm -rf ns1/root.db +rm -rf ns2/example.db +rm -rf random.data diff --git a/bin/tests/system/pending/ns1/named.conf b/bin/tests/system/pending/ns1/named.conf new file mode 100644 index 0000000000..b23843f597 --- /dev/null +++ b/bin/tests/system/pending/ns1/named.conf @@ -0,0 +1,38 @@ +/* + * Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") + * + * Permission to use, copy, modify, and/or distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: named.conf,v 1.2 2009/11/17 23:55:18 marka Exp $ */ + +controls { /* empty */ }; + +include "trusted.conf"; + +options { + query-source address 10.53.0.1; + notify-source 10.53.0.1; + transfer-source 10.53.0.1; + port 5300; + pid-file "named.pid"; + listen-on { 10.53.0.1; }; + listen-on-v6 { none; }; + recursion no; +}; + +zone "." { + type master; + file "root.db.signed"; +}; + diff --git a/bin/tests/system/pending/ns1/root.db.in b/bin/tests/system/pending/ns1/root.db.in new file mode 100644 index 0000000000..d32be8a76c --- /dev/null +++ b/bin/tests/system/pending/ns1/root.db.in @@ -0,0 +1,31 @@ +; Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") +; +; Permission to use, copy, modify, and/or distribute this software for any +; purpose with or without fee is hereby granted, provided that the above +; copyright notice and this permission notice appear in all copies. +; +; THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +; REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +; AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +; INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +; LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +; PERFORMANCE OF THIS SOFTWARE. + +; $Id: root.db.in,v 1.2 2009/11/17 23:55:18 marka Exp $ + +$TTL 30 +. IN SOA marka.isc.org. a.root.servers.nil. ( + 2000042100 ; serial + 600 ; refresh + 600 ; retry + 1200 ; expire + 600 ; minimum + ) +. NS a.root-servers.nil. +a.root-servers.nil. A 10.53.0.1 + +example. NS ns2.example. +ns2.example. A 10.53.0.2 +hostile. NS ns3.hostile. +ns3.hostile. A 10.53.0.3 diff --git a/bin/tests/system/pending/ns1/sign.sh b/bin/tests/system/pending/ns1/sign.sh new file mode 100644 index 0000000000..b0b0a0e40b --- /dev/null +++ b/bin/tests/system/pending/ns1/sign.sh @@ -0,0 +1,51 @@ +#!/bin/sh +# +# Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") +# +# Permission to use, copy, modify, and/or distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: sign.sh,v 1.2 2009/11/17 23:55:18 marka Exp $ + +SYSTEMTESTTOP=../.. +. $SYSTEMTESTTOP/conf.sh + +RANDFILE=../random.data + +zone=. +infile=root.db.in +zonefile=root.db + +(cd ../ns2 && sh -e sign.sh ) + +cp ../ns2/dsset-example. . + +keyname1=`$KEYGEN -q -r $RANDFILE -a RSASHA256 -b 1024 -n zone $zone` +keyname2=`$KEYGEN -q -r $RANDFILE -a RSASHA256 -b 2048 -f KSK -n zone $zone` +cat $infile $keyname1.key $keyname2.key > $zonefile + +$SIGNER -g -r $RANDFILE -o $zone $zonefile > /dev/null + +# Configure the resolving server with a trusted key. + +cat $keyname2.key | grep -v '^; ' | $PERL -n -e ' +local ($dn, $class, $type, $flags, $proto, $alg, @rest) = split; +local $key = join("", @rest); +print < trusted.conf +cp trusted.conf ../ns2/trusted.conf +cp trusted.conf ../ns3/trusted.conf +cp trusted.conf ../ns4/trusted.conf diff --git a/bin/tests/system/pending/ns2/example.db.in b/bin/tests/system/pending/ns2/example.db.in new file mode 100644 index 0000000000..ca0d596b21 --- /dev/null +++ b/bin/tests/system/pending/ns2/example.db.in @@ -0,0 +1,28 @@ +; Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") +; +; Permission to use, copy, modify, and/or distribute this software for any +; purpose with or without fee is hereby granted, provided that the above +; copyright notice and this permission notice appear in all copies. +; +; THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +; REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +; AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +; INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +; LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +; PERFORMANCE OF THIS SOFTWARE. + +; $Id: example.db.in,v 1.2 2009/11/17 23:55:18 marka Exp $ + +$TTL 30 +@ IN SOA mname1. . ( + 2009110300 ; serial + 20 ; refresh (20 seconds) + 20 ; retry (20 seconds) + 1814400 ; expire (3 weeks) + 3600 ; minimum (1 hour) + ) + NS ns2 + MX 10 mail +ns2 A 10.53.0.2 +mail A 10.0.0.2 diff --git a/bin/tests/system/pending/ns2/named.conf b/bin/tests/system/pending/ns2/named.conf new file mode 100644 index 0000000000..5ed012459f --- /dev/null +++ b/bin/tests/system/pending/ns2/named.conf @@ -0,0 +1,48 @@ +/* + * Copyright (C) 2004, 2006-2008 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000-2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and/or distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: named.conf,v 1.2 2009/11/17 23:55:18 marka Exp $ */ + +// NS2 + +controls { /* empty */ }; + +include "trusted.conf"; + +options { + query-source address 10.53.0.2; + notify-source 10.53.0.2; + transfer-source 10.53.0.2; + port 5300; + pid-file "named.pid"; + listen-on { 10.53.0.2; }; + listen-on-v6 { none; }; + recursion no; + notify yes; + dnssec-enable yes; + dnssec-validation yes; +}; + +zone "." { + type hint; + file "../../common/root.hint"; +}; + +zone "example" { + type master; + file "example.db.signed"; +}; diff --git a/bin/tests/system/pending/ns2/sign.sh b/bin/tests/system/pending/ns2/sign.sh new file mode 100644 index 0000000000..ea8af0a8a5 --- /dev/null +++ b/bin/tests/system/pending/ns2/sign.sh @@ -0,0 +1,34 @@ +#!/bin/sh -e +# +# Copyright (C) 2004, 2006-2009 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2000-2003 Internet Software Consortium. +# +# Permission to use, copy, modify, and/or distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: sign.sh,v 1.2 2009/11/17 23:55:18 marka Exp $ + +SYSTEMTESTTOP=../.. +. $SYSTEMTESTTOP/conf.sh + +RANDFILE=../random.data + +zone=example. +infile=example.db.in +zonefile=example.db + +keyname1=`$KEYGEN -q -r $RANDFILE -a RSASHA1 -b 768 -n zone $zone` +keyname2=`$KEYGEN -q -r $RANDFILE -a RSASHA1 -b 1024 -f KSK -n zone $zone` + +cat $infile $keyname1.key $keyname2.key >$zonefile + +$SIGNER -r $RANDFILE -o $zone $zonefile > /dev/null diff --git a/bin/tests/system/pending/ns3/hostile.db b/bin/tests/system/pending/ns3/hostile.db new file mode 100644 index 0000000000..2a2d3501df --- /dev/null +++ b/bin/tests/system/pending/ns3/hostile.db @@ -0,0 +1,27 @@ +; Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") +; +; Permission to use, copy, modify, and/or distribute this software for any +; purpose with or without fee is hereby granted, provided that the above +; copyright notice and this permission notice appear in all copies. +; +; THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +; REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +; AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +; INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +; LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +; PERFORMANCE OF THIS SOFTWARE. + +; $Id: hostile.db,v 1.2 2009/11/17 23:55:18 marka Exp $ + +$TTL 30 +@ IN SOA mname1. . ( + 2009110500 ; serial + 20 ; refresh (20 seconds) + 20 ; retry (20 seconds) + 1814400 ; expire (3 weeks) + 3600 ; minimum (1 hour) + ) + NS ns3 + MX 10 mail.example. +ns3 A 10.53.0.3 diff --git a/bin/tests/system/pending/ns3/mail.example.db b/bin/tests/system/pending/ns3/mail.example.db new file mode 100644 index 0000000000..d56f9f01ed --- /dev/null +++ b/bin/tests/system/pending/ns3/mail.example.db @@ -0,0 +1,28 @@ +; Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") +; +; Permission to use, copy, modify, and/or distribute this software for any +; purpose with or without fee is hereby granted, provided that the above +; copyright notice and this permission notice appear in all copies. +; +; THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +; REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +; AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +; INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +; LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +; PERFORMANCE OF THIS SOFTWARE. + +; $Id: mail.example.db,v 1.2 2009/11/17 23:55:18 marka Exp $ + +$TTL 30 +@ IN SOA mname1. . ( + 2009110300 ; serial + 20 ; refresh (20 seconds) + 20 ; retry (20 seconds) + 1814400 ; expire (3 weeks) + 3600 ; minimum (1 hour) + ) +@ NS ns3 +ns3 A 10.53.0.3 +;mail A 10.0.0.2 // the correct record +@ A 10.0.0.3 diff --git a/bin/tests/system/pending/ns3/named.conf b/bin/tests/system/pending/ns3/named.conf new file mode 100644 index 0000000000..6d39ae9b87 --- /dev/null +++ b/bin/tests/system/pending/ns3/named.conf @@ -0,0 +1,53 @@ +/* + * Copyright (C) 2004, 2006-2008 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000-2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and/or distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: named.conf,v 1.2 2009/11/17 23:55:18 marka Exp $ */ + +// NS2 + +controls { /* empty */ }; + +include "trusted.conf"; + +options { + query-source address 10.53.0.3; + notify-source 10.53.0.3; + transfer-source 10.53.0.3; + port 5300; + pid-file "named.pid"; + listen-on { 10.53.0.3; }; + listen-on-v6 { none; }; + recursion no; + notify no; + dnssec-enable yes; + dnssec-validation yes; +}; + +zone "." { + type hint; + file "../../common/root.hint"; +}; + +zone "mail.example" { + type master; + file "mail.example.db"; +}; + +zone "hostile" { + type master; + file "hostile.db"; +}; diff --git a/bin/tests/system/pending/ns4/named.conf b/bin/tests/system/pending/ns4/named.conf new file mode 100644 index 0000000000..8c941496e2 --- /dev/null +++ b/bin/tests/system/pending/ns4/named.conf @@ -0,0 +1,37 @@ +/* + * Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") + * + * Permission to use, copy, modify, and/or distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: named.conf,v 1.2 2009/11/17 23:55:18 marka Exp $ */ + +controls { /* empty */ }; + +include "trusted.conf"; + +options { + query-source address 10.53.0.4; + notify-source 10.53.0.4; + transfer-source 10.53.0.4; + port 5300; + pid-file "named.pid"; + listen-on { 10.53.0.4; }; + listen-on-v6 { none; }; + recursion yes; +}; + +zone "." { + type hint; + file "../../common/root.hint"; +}; diff --git a/bin/tests/system/pending/prereq.sh b/bin/tests/system/pending/prereq.sh new file mode 100644 index 0000000000..1e1b22ad5e --- /dev/null +++ b/bin/tests/system/pending/prereq.sh @@ -0,0 +1,28 @@ +#!/bin/sh +# +# Copyright (C) 2004, 2006, 2007, 2009 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2000-2002 Internet Software Consortium. +# +# Permission to use, copy, modify, and/or distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: prereq.sh,v 1.2 2009/11/17 23:55:18 marka Exp $ + +../../../tools/genrandom 400 random.data + +if $KEYGEN -q -a RSAMD5 -b 512 -n zone -r random.data foo > /dev/null 2>&1 +then + rm -f Kfoo* +else + echo "I:This test requires that --with-openssl was used." >&2 + exit 1 +fi diff --git a/bin/tests/system/pending/setup.sh b/bin/tests/system/pending/setup.sh new file mode 100644 index 0000000000..5332d36de6 --- /dev/null +++ b/bin/tests/system/pending/setup.sh @@ -0,0 +1,21 @@ +#!/bin/sh -e +# +# Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") +# +# Permission to use, copy, modify, and/or distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: setup.sh,v 1.2 2009/11/17 23:55:18 marka Exp $ + +../../../tools/genrandom 400 random.data + +cd ns1 && sh -e sign.sh diff --git a/bin/tests/system/pending/tests.sh b/bin/tests/system/pending/tests.sh new file mode 100644 index 0000000000..58019a9d48 --- /dev/null +++ b/bin/tests/system/pending/tests.sh @@ -0,0 +1,47 @@ +#!/bin/sh +# +# Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2000-2002 Internet Software Consortium. +# +# Permission to use, copy, modify, and/or distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: tests.sh,v 1.2 2009/11/17 23:55:18 marka Exp $ + +SYSTEMTESTTOP=.. +. $SYSTEMTESTTOP/conf.sh + +status=0 +n=0 + +rm -f dig.out.* + +DIGOPTS="+short +tcp +cd -p 5300" + +echo I:Priming cache. +ret=0 +expect="10 mail.example." +ans=`$DIG $DIGOPTS @10.53.0.4 hostile MX` || ret=1 +test "$ans" = "$expect" || ret=1 +test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'" +status=`expr $status + $ret` + +echo I:Checking that bogus additional is not returned with +CD. +ret=0 +expect="10.0.0.2" +ans=`$DIG $DIGOPTS @10.53.0.4 mail.example A` || ret=1 +test "$ans" = "$expect" || ret=1 +test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'" +status=`expr $status + $ret` + +echo "I:exit status: $status" +exit $status diff --git a/doc/draft/draft-ietf-dnsext-dnssec-gost-03.txt b/doc/draft/draft-ietf-dnsext-dnssec-gost-03.txt new file mode 100644 index 0000000000..061df67944 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-gost-03.txt @@ -0,0 +1,455 @@ +DNS Extensions working group V.Dolmatov, Ed. +Internet-Draft Cryptocom Ltd. +Intended status: Standards Track November 10, 2009 +Expires: May 10, 2010 + + + Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records + for DNSSEC + draft-ietf-dnsext-dnssec-gost-03 + +Status of this Memo + + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on May 10 2010. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Abstract + + This document describes how to produce signature and hash using + GOST algorithms for DNSKEY, RRSIG and DS resource records for use in + the Domain Name System Security Extensions (DNSSEC, RFC 4033, + RFC 4034, and RFC 4035). + +V.Dolmatov Expires May 10, 2010 [Page 1] + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Using a public key with existing cryptographic libraries. . 3 + 2.2. GOST DNSKEY RR Example . . . . . . . . . . . . . . . . . . 3 + 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4 + 3.1 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . . 4 + 4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 4 + 4.1 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . . 5 + 5. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5 + 5.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 5.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5 + 5.3. Digest Sizes . . . . . . . . . . . . . . . . . . . . . . . 5 + 6. Implementation Considerations . . . . . . . . . . . . . . . . . 5 + 6.1. Support for GOST signatures . . . . . . . . . . . . . . . . 5 + 6.2. Support for NSEC3 Denial of Existence . . . . . . . . . . . 5 + 6.3. Byte order . . . . . . . . . . . . . . . . . . . . . . . . 5 + 7. Security consideration . . . . . . . . . . . . . . . . . . . . . 5 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical distributed + database for Internet Naming. The DNS has been extended to use + cryptographic keys and digital signatures for the verification of the + authenticity and integrity of its data. RFC 4033 [RFC4033], RFC 4034 + [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security + Extensions, called DNSSEC. + + RFC 4034 describes how to store DNSKEY and RRSIG resource records, + and specifies a list of cryptographic algorithms to use. This + document extends that list with the signature and hash algorithms + GOST [GOST3410, GOST3411], + and specifies how to store DNSKEY data and how to produce + RRSIG resource records with these hash algorithms. + + Familiarity with DNSSEC and GOST signature and hash + algorithms is assumed in this document. + + The term "GOST" is not officially defined, but is usually used to + refer to the collection of the Russian cryptographic algorithms + GOST R 34.10-2001, GOST R 34.11-94, GOST 28147-89. + Since GOST 28147-89 is not used in DNSSEC, "GOST" will only refer to + the GOST R 34.10-2001 and GOST R 34.11-94 in this document. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +V.Dolmatov Expires May 10, 2010 [Page 2] + +2. DNSKEY Resource Records + + The format of the DNSKEY RR can be found in RFC 4034 [RFC4034]. + + GOST R 34.10-2001 public keys are stored with the algorithm number + {TBA1}. + + The wire format of the public key is compatible with + RFC 4491 [RFC4491]: + + According to [GOSTR341001], a public key is a point on the elliptic + curve Q = (x,y). + + The wire representation of a public key MUST contain 66 octets, + where the first octet designates public key parameters, the second + octet designates digest parameters next 32 octets contain the + little-endian representation of x and the second 32 octets contain + the little-endian representation of y. + This corresponds to the binary representation of (256||256) + from [GOSTR341001], ch. 5.3. + + The only valid value for both parameters octets is 0. + Other parameters octets values are reserved for future use. + + Corresponding public key parameters are those identified by + id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357], + and the digest parameters are those identified by + id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357]. + +2.1. Using a public key with existing cryptographic libraries + + Existing GOST-aware cryptographic libraries at the time of this + document writing are capable to read GOST public keys via a generic + X509 API if the key is encoded according to RFC 4491 [RFC4491], + section 2.3.2. + + To make this encoding from the wire format of a GOST public key + with the parameters used in this document, prepend the last 64 octets + of key data (in other words, substitute first two parameter octets) + with the following 37-byte sequence: + + 0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 + 0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a + 0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40 + +2.2. GOST DNSKEY RR Example + + Given a private key with the following value (the value of GostAsn1 + field is split here into two lines to simplify reading; in the + private key file it must be in one line): + + Private-key-format: v1.2 + Algorithm: {TBA1} (GOST) + GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgV/S + 2FXdMtzKJBehZvjF4lVSx6m66TwqSe/MFwKSH/3E= + +V.Dolmatov Expires May 10, 2010 [Page 3] + + The following DNSKEY RR stores a DNS zone key for example.net + + example.net. 86400 IN DNSKEY 256 3 {TBA1} ( + AADMrbi2vAs4hklTmmzGE3WWNtJ8Dll0u0jq + tGRbNKeJguZQj/9EpGWmQK9hekPiPlzH2Ph6 + yB7i836EfzmJo5LP + ) ; key id = 15820 + +3. RRSIG Resource Records + + The value of the signature field in the RRSIG RR follows RFC 4490 + [RFC4490] and is calculated as follows. The values for the RDATA + fields that precede the signature data are specified + in RFC 4034 [RFC4034]. + + hash = GOSTR3411(data) + + where "data" is the wire format data of the resource record set + that is signed, as specified in RFC 4034 [RFC4034]. + + Hash MUST be calculated with GOST R 34.11-94 parameters identified + by id-GostR3411-94-CryptoProParamSet [RFC4357]. + + Signature is calculated from the hash according to the + GOST R 34.10-2001 standard and its wire format is compatible with + RFC 4490 [RFC4490]. + + Quoting RFC 4490: + + "The signature algorithm GOST R 34.10-2001 generates a digital + signature in the form of two 256-bit numbers, r and s. Its octet + string representation consists of 64 octets, where the first 32 + octets contain the big-endian representation of s and the second 32 + octets contain the big-endian representation of r." + +3.1. RRSIG RR Example + + With the private key from section 2.2 sign the following RRSet, + consisting of one A record: + + www.example.net. 3600 IN A 192.0.32.10 + + Setting the inception date to 2000-01-01 00:00:00 UTC and the + expiration date to 2030-01-01 00:00:00 UTC, the following signature + should be created (assuming {TBA1}==249 until proper code is + assigned by IANA) + + www.example.net. 3600 IN RRSIG A {TBA1} 3 3600 20300101000000 ( + 20000101000000 15820 example.net. + K4sw+TOJz47xqP6685ItDfPhkktyvgxXrLdX + aQLX01mMZbJUp6tzetBYGpdHciAW5RLvHLVB + P8RtFK8Qv5DRsA== ) + + Note: Several GOST signatures calculated for the same message text + differ because of using of a random element is used in signature + generation process. + +4. DS Resource Records + + GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest + type {TBA2}. The wire format of a digest value is compatible with + RFC 4490 [RFC4490], that is digest is in little-endian representation. + +V.Dolmatov Expires May 10, 2010 [Page 4] + + The digest MUST always be calculated with GOST R 34.11-94 parameters + identified by id-GostR3411-94-CryptoProParamSet [RFC4357]. + +4.1. DS RR Example + + For key signing key (assuming {TBA1}==249 until proper code is + assigned by IANA) + + example.net. 86400 DNSKEY 257 3 {TBA1} ( + AAADr5vmKVdXo780hSRU1YZYWuMZUbEe9R7C + RRLc7Wj2osDXv2XbCnIpTUx8dVLnLKmDBquu + 9tCz5oSsZl0cL0R2 + ) ; key id = 21649 + + The DS RR will be + + example.net. 3600 IN DS 21649 {TBA1} {TBA2} ( + A8146F448569F30B91255BA8E98DE14B18569A524C49593ADCA4103A + A44649C6 ) + + +5. Deployment Considerations + +5.1. Key Sizes + + According to RFC4357 [RFC4357], the key size of GOST public keys + MUST be 512 bits. + +5.2. Signature Sizes + + According to the GOST signature algorithm specification [GOST3410], + the size of a GOST signature is 512 bits. + +5.3. Digest Sizes + + According to the GOST R 34.11-94 [GOST3411], the size of a GOST digest + is 256 bits. + +6. Implementation Considerations + +6.1. Support for GOST signatures + + DNSSEC aware implementations SHOULD be able to support RRSIG and + DNSKEY resource records created with the GOST algorithms as + defined in this document. + +6.2. Support for NSEC3 Denial of Existence + + Any DNSSEC-GOST implementation is required to have either NSEC or + NSEC3 support. + +6.3 Byte order + + Due to the fact that all existing industry implementations of GOST + cryptographic libraries are returning GOST blobs in little-endian + format and in order to avoid the necessity for DNSSEC developers + to handle different cryptographic algorithms differently, it was + chosen to send these blobs on the wire "as is" without + transformation of endianness. + +7. Security considerations + + Currently, the cryptographic resistance of the GOST 34.10-2001 + digital signature algorithm is estimated as 2**128 operations + of multiple elliptic curve point computations on prime modulus + 2**256. + +V.Dolmatov Expires May 10, 2010 [Page 5] + + Currently, the cryptographic resistance of GOST 34.11-94 hash + algorithm is estimated as 2**128 operations of computations of a + step hash function. (There is known method to reduce this + estimate to 2**105 operations, but it demands padding the + colliding message with 1024 random bit blocks each of 256 bit + length, thus it cannot be used in any practical implementation). + +8. IANA Considerations + + This document updates the IANA registry "DNS Security Algorithm + Numbers [RFC4034]" + (http://www.iana.org/assignments/dns-sec-alg-numbers). The + following entries are added to the registry: + Zone Trans. + Value Algorithm Mnemonic Signing Sec. References Status + {TBA1} GOST R 34.10-2001 GOST Y * (this memo) OPTIONAL + + This document updates the RFC 4034 Digest Types assignment + (section A.2)by adding the value and status for the GOST R 34.11-94 + algorithm: + + Value Algorithm Status + {TBA2} GOST R 34.11-94 OPTIONAL + +9. Acknowledgments + + This document is a minor extension to RFC 4034 [RFC4034]. Also, we + tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509], + and RFC 4357 [RFC4357] for consistency. The authors of and + contributors to these documents are gratefully acknowledged for + their hard work. + + The following people provided additional feedback and text: Dmitry + Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen + and Wouter Wijngaards. + + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + + [RFC3110] Eastlake D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [RFC4033] Arends R., Austein R., Larson M., Massey D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4034] Arends R., Austein R., Larson M., Massey D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + +V.Dolmatov Expires May 10, 2010 [Page 6] + + [RFC4035] Arends R., Austein R., Larson M., Massey D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [GOST3410] "Information technology. Cryptographic data security. + Signature and verification processes of [electronic] + digital signature.", GOST R 34.10-2001, Gosudarstvennyi + Standard of Russian Federation, Government Committee of + the Russia for Standards, 2001. (In Russian) + + [GOST3411] "Information technology. Cryptographic Data Security. + Hashing function.", GOST R 34.11-94, Gosudarstvennyi + Standard of Russian Federation, Government Committee of + the Russia for Standards, 1994. (In Russian) + + [RFC4357] Popov V., Kurepkin I., and S. Leontiev, "Additional + Cryptographic Algorithms for Use with GOST 28147-89, + GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 + Algorithms", RFC 4357, January 2006. + + [RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89, + GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 + Algorithms with Cryptographic Message Syntax (CMS)", + RFC 4490, May 2006. + + [RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST + R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 + Algorithms with the Internet X.509 Public Key + Infrastructure Certificate and CRL Profile", RFC 4491, + May 2006. + + + +10.2. Informative References + + [NIST800-57] + Barker E., Barker W., Burr W., Polk W., and M. Smid, + "Recommendations for Key Management", NIST SP 800-57, + March 2007. + + [RFC3447] Jonsson J. and B. Kaliski, "Public-Key Cryptography + Standards (PKCS) #1: RSA Cryptography Specifications + Version 2.1", RFC 3447, February 2003. + + [RFC4509] Hardaker W., "Use of SHA-256 in DNSSEC Delegation Signer + (DS) Resource Records (RRs)", RFC 4509, May 2006. + + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, March 2008. + + [DRAFT1] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S., + "GOST R 34.10-2001 digital signature algorithm" + draft-dolmatov-cryptocom-gost3410-2001-06, 11.10.09 + work in progress. +V.Dolmatov Expires May 10, 2010 [Page 7] + + [DRAFT2] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S., + "GOST R 34.11-94 Hash function algorithm" + draft-dolmatov-cryptocom-gost341194-04, 11.10.09 + work in progress. + + [DRAFT3] Dolmatov V., Kabelev D., Ustinov I., Emelyanova I., + "GOST 28147-89 encryption, decryption and MAC algorithms" + draft-dolmatov-cryptocom-gost2814789-04, 11.10.09 + work in progress. + +Authors' Addresses + + +Vasily Dolmatov, Ed. +Cryptocom Ltd. +Bolotnikovskaya, 23 +Moscow, 117303, Russian Federation + +EMail: dol@cryptocom.ru + +Artem Chuprina +Cryptocom Ltd. +Bolotnikovskaya, 23 +Moscow, 117303, Russian Federation + +EMail: ran@cryptocom.ru + +Igor Ustinov +Cryptocom Ltd. +Bolotnikovskaya, 23 +Moscow, 117303, Russian Federation + +EMail: igus@cryptocom.ru + +V.Dolmatov Expires May 10, 2010 [Page 8] + + + + diff --git a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-18.txt b/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-18.txt new file mode 100644 index 0000000000..3b9a35aeaf --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-18.txt @@ -0,0 +1,953 @@ + + + +DNS Extensions Working Group S. Rose +Internet-Draft NIST +Obsoletes: 2672 (if approved) W. Wijngaards +Updates: 3363,4294 NLnet Labs +(if approved) November 12, 2009 +Intended status: Standards Track +Expires: May 16, 2010 + + + Update to DNAME Redirection in the DNS + draft-ietf-dnsext-rfc2672bis-dname-18 + +Abstract + + The DNAME record provides redirection for a sub-tree of the domain + name tree in the DNS system. That is, all names that end with a + particular suffix are redirected to another part of the DNS. This is + a revision of the original specification in RFC 2672, also aligning + RFC 3363 and RFC 4294 with this revision. + +Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +Status of This Memo + + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on May 16, 2010. + + + +Rose & Wijngaards Expires May 16, 2010 [Page 1] + +Internet-Draft DNAME Redirection November 2009 + + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Rose & Wijngaards Expires May 16, 2010 [Page 2] + +Internet-Draft DNAME Redirection November 2009 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + + 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 4 + 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5 + 2.3. DNAME Owner Name not Redirected Itself . . . . . . . . . . 6 + 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 7 + 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 7 + + 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 8 + 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 8 + 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 10 + + 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 11 + + 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 12 + 5.1. Canonical hostnames cannot be below DNAME owners . . . . . 12 + 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 12 + 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 13 + 5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 13 + 5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 13 + 5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 13 + 5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 13 + 5.3.4.1. DNAME in Bitmap Causes Invalid Name Error . . . . 13 + 5.3.4.2. Valid Name Error Response Involving DNAME in + Bitmap . . . . . . . . . . . . . . . . . . . . . . 14 + 5.3.4.3. Response With Synthesized CNAME . . . . . . . . . 14 + + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 + + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 + + + + + + + + + + +Rose & Wijngaards Expires May 16, 2010 [Page 3] + +Internet-Draft DNAME Redirection November 2009 + + +1. Introduction + + DNAME is a DNS Resource Record type originally defined in RFC 2672 + [RFC2672]. DNAME provides redirection from a part of the DNS name + tree to another part of the DNS name tree. + + The DNAME RR and the CNAME RR [RFC1034] cause a lookup to + (potentially) return data corresponding to a domain name different + from the queried domain name. The difference between the two + resource records is that the CNAME RR directs the lookup of data at + its owner to another single name, a DNAME RR directs lookups for data + at descendents of its owner's name to corresponding names under a + different (single) node of the tree. + + Take for example, looking through a zone (see RFC 1034 [RFC1034], + section 4.3.2, step 3) for the domain name "foo.example.com" and a + DNAME resource record is found at "example.com" indicating that all + queries under "example.com" be directed to "example.net". The lookup + process will return to step 1 with the new query name of + "foo.example.net". Had the query name been "www.foo.example.com" the + new query name would be "www.foo.example.net". + + This document is a revision of the original specification of DNAME in + RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of + maintaining address-to-name mappings in a context of network + renumbering. With a careful set-up, a renumbering event in the + network causes no change to the authoritative server that has the + address-to-name mappings. Examples in practice are classless reverse + address space delegations. + + Another usage of DNAME lies in aliasing of name spaces. For example, + a zone administrator may want sub-trees of the DNS to contain the + same information. Examples include punycode alternates for domain + spaces. + + This revision to DNAME does not change the wire format or the + handling of DNAME Resource Records. Discussion is added on problems + that may be encountered when using DNAME. + +2. The DNAME Resource Record + +2.1. Format + + The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is + not class-sensitive. + + + + + + +Rose & Wijngaards Expires May 16, 2010 [Page 4] + +Internet-Draft DNAME Redirection November 2009 + + + Its RDATA is comprised of a single field, , which contains a + fully qualified domain name that must be sent in uncompressed form + [RFC1035], [RFC3597]. The field MUST be present. The + presentation format of is that of a domain name [RFC1035]. + + DNAME + + The effect of the DNAME RR is the substitution of the record's + for its owner name, as a suffix of a domain name. This + substitution has to be applied for every DNAME RR found in the + resolution process, which allows fairly lengthy valid chains of DNAME + RRs. + + Details of the substitution process, methods to avoid conflicting + resource records, and rules for specific corner cases are given in + the following subsections. + +2.2. The DNAME Substitution + + When following RFC 1034 [RFC1034], section 4.3.2's algorithm's third + step, "start matching down, label by label, in the zone" and a node + is found to own a DNAME resource record a DNAME substitution occurs. + The name being sought may be the original query name or a name that + is the result of a CNAME resource record being followed or a + previously encountered DNAME. As in the case when finding a CNAME + resource record or NS resource record set, the processing of a DNAME + will happen prior to finding the desired domain name. + + A DNAME substitution is performed by replacing the suffix labels of + the name being sought matching the owner name of the DNAME resource + record with the string of labels in the RDATA field. The matching + labels end with the root label in all cases. Only whole labels are + replaced. See the table of examples for common cases and corner + cases. + + + + + + + + + + + + + + + + + +Rose & Wijngaards Expires May 16, 2010 [Page 5] + +Internet-Draft DNAME Redirection November 2009 + + + In the table below, the QNAME refers to the query name. The owner is + the DNAME owner domain name, and the target refers to the target of + the DNAME record. The result is the resulting name after performing + the DNAME substitution on the query name. "no match" means that the + query did not match the DNAME and thus no substitution is performed + and a possible error message is returned (if no other result is + possible). Thus every line contains one example substitution. In + the examples below, 'cyc' and 'shortloop' contain loops. + + QNAME owner DNAME target result + ---------------- -------------- -------------- ----------------- + com. example.com. example.net. + example.com. example.com. example.net. + a.example.com. example.com. example.net. a.example.net. + a.b.example.com. example.com. example.net. a.b.example.net. + ab.example.com. b.example.com. example.net. + foo.example.com. example.com. example.net. foo.example.net. + a.x.example.com. x.example.com. example.net. a.example.net. + a.example.com. example.com. y.example.net. a.y.example.net. + cyc.example.com. example.com. example.com. cyc.example.com. + cyc.example.com. example.com. c.example.com. cyc.c.example.com. + shortloop.x.x. x. . shortloop.x. + shortloop.x. x. . shortloop. + + Table 1. DNAME Substitution Examples. + + It is possible for DNAMEs to form loops, just as CNAMEs can form + loops. DNAMEs and CNAMEs can chain together to form loops. A single + corner case DNAME can form a loop. Resolvers and servers should be + cautious in devoting resources to a query, but be aware that fairly + long chains of DNAMEs may be valid. Zone content administrators + should take care to insure that there are no loops that could occur + when using DNAME or DNAME/CNAME redirection. + + The domain name can get too long during substitution. For example, + suppose the target name of the DNAME RR is 250 octets in length + (multiple labels), if an incoming QNAME that has a first label over 5 + octets in length, the result would be a name over 255 octets. If + this occurs the server returns an RCODE of YXDOMAIN [RFC2136]. The + DNAME record and its signature (if the zone is signed) are included + in the answer as proof for the YXDOMAIN (value 6) RCODE. + +2.3. DNAME Owner Name not Redirected Itself + + Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its + owner name; the owner name of a DNAME is not redirected itself. The + domain name that owns a DNAME record is allowed to have other + resource record types at that domain name, except DNAMEs, CNAMEs or + + + +Rose & Wijngaards Expires May 16, 2010 [Page 6] + +Internet-Draft DNAME Redirection November 2009 + + + other types that have restrictions on what they can co-exist with. + DNAME RRs MUST NOT appear at the same owner name as an NS RR unless + the owner name is the zone apex. + + If a DNAME record is present at the zone apex, there is still a need + to have the customary SOA and NS resource records there as well. + Such a DNAME cannot be used to mirror a zone completely, as it does + not mirror the zone apex. + + These rules also allow DNAME records to be queried through RFC 1034 + [RFC1034] compliant, DNAME-unaware caches. + +2.4. Names Next to and Below a DNAME Record + + Resource records MUST NOT exist at any sub-domain of the owner of a + DNAME RR. To get the contents for names subordinate to that owner + name, the DNAME redirection must be invoked and the resulting target + queried. A server MAY refuse to load a zone that has data at a sub- + domain of a domain name owning a DNAME RR. If the server does load + the zone, those names below the DNAME RR will be occluded as + described in RFC 2136 [RFC2136], section 7.18. Also a server SHOULD + refuse to load a zone subordinate to the owner of a DNAME record in + the ancestor zone. See Section 5.2 for further discussion related to + dynamic update. + + DNAME is a singleton type, meaning only one DNAME is allowed per + name. The owner name of a DNAME can only have one DNAME RR, and no + CNAME RRs can exist at that name. These rules make sure that for a + single domain name only one redirection exists, and thus no confusion + which one to follow. A server SHOULD refuse to load a zone that + violates these rules. + +2.5. Compression of the DNAME record. + + The DNAME owner name can be compressed like any other owner name. + The DNAME RDATA target name MUST NOT be sent out in compressed form, + so that a DNAME RR can be treated as an unknown type [RFC3597]. + + Although the previous DNAME specification [RFC2672] (that is + obsoleted by this specification) talked about signaling to allow + compression of the target name, such signaling has never been + specified and this document also does not specify this signaling + behavior. + + RFC 2672 (obsoleted by this document) stated that the EDNS version + had a meaning for understanding of DNAME and DNAME target name + compression. This document revises RFC 2672, in that there is no + EDNS version signaling for DNAME. + + + +Rose & Wijngaards Expires May 16, 2010 [Page 7] + +Internet-Draft DNAME Redirection November 2009 + + +3. Processing + + The DNAME RR causes type NS additional section processing. This + refers to action at step 6 of the server algorithm outlined in + section 3.2. + +3.1. CNAME synthesis + + When preparing a response, a server performing a DNAME substitution + will in all cases include the relevant DNAME RR in the answer + section. A CNAME RR with TTL equal to the corresponding DNAME RR is + synthesized and included in the answer section. The owner name of + the CNAME is the QNAME of the query. The DNSSEC specification + [RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does + not have to be signed. The DNAME has an RRSIG and a validating + resolver can check the CNAME against the DNAME record and validate + the signature over the DNAME RR. + + Resolvers MUST be able to handle a synthesized CNAME TTL of zero or + equal to the TTL of the corresponding DNAME record. A TTL of zero + means that the CNAME can be discarded immediately after processing + the answer. + + Servers MUST be able to answer a query for a synthesized CNAME. Like + other query types this invokes the DNAME, and synthesizes the CNAME + into the answer. + +3.2. Server algorithm + + Below is the server algorithm, which appeared in RFC 2672 Section + 4.1. + + 1. Set or clear the value of recursion available in the response + depending on whether the name server is willing to provide + recursive service. If recursive service is available and + requested via the RD bit in the query, go to step 5, otherwise + step 2. + + + 2. Search the available zones for the zone which is the nearest + ancestor to QNAME. If such a zone is found, go to step 3, + otherwise step 4. + + + 3. Start matching down, label by label, in the zone. The matching + process can terminate several ways: + + + + + +Rose & Wijngaards Expires May 16, 2010 [Page 8] + +Internet-Draft DNAME Redirection November 2009 + + + A. If the whole of QNAME is matched, we have found the node. + + If the data at the node is a CNAME, and QTYPE does not match + CNAME, copy the CNAME RR into the answer section of the + response, change QNAME to the canonical name in the CNAME RR, + and go back to step 1. + + Otherwise, copy all RRs which match QTYPE into the answer + section and go to step 6. + + + B. If a match would take us out of the authoritative data, we + have a referral. This happens when we encounter a node with + NS RRs marking cuts along the bottom of a zone. + + Copy the NS RRs for the sub-zone into the authority section + of the reply. Put whatever addresses are available into the + additional section, using glue RRs if the addresses are not + available from authoritative data or the cache. Go to step + 4. + + + C. If at some label, a match is impossible (i.e., the + corresponding label does not exist), look to see whether the + last label matched has a DNAME record. + + If a DNAME record exists at that point, copy that record into + the answer section. If substitution of its for its + in QNAME would overflow the legal size for a , set RCODE to YXDOMAIN [RFC2136] and exit; otherwise + perform the substitution and continue. The server MUST + synthesize a CNAME record as described above and include it + in the answer section. Go back to step 1. + + If there was no DNAME record, look to see if the "*" label + exists. + + If the "*" label does not exist, check whether the name we + are looking for is the original QNAME in the query or a name + we have followed due to a CNAME or DNAME. If the name is + original, set an authoritative name error in the response and + exit. Otherwise just exit. + + If the "*" label does exist, match RRs at that node against + QTYPE. If any match, copy them into the answer section, but + set the owner of the RR to be QNAME, and not the node with + the "*" label. If the data at the node with the "*" label is + a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR + + + +Rose & Wijngaards Expires May 16, 2010 [Page 9] + +Internet-Draft DNAME Redirection November 2009 + + + into the answer section of the response changing the owner + name to the QNAME, change QNAME to the canonical name in the + CNAME RR, and go back to step 1. Otherwise, Go to step 6. + + + 4. Start matching down in the cache. If QNAME is found in the + cache, copy all RRs attached to it that match QTYPE into the + answer section. If QNAME is not found in the cache but a DNAME + record is present at an ancestor of QNAME, copy that DNAME record + into the answer section. If there was no delegation from + authoritative data, look for the best one from the cache, and put + it in the authority section. Go to step 6. + + + 5. Use the local resolver or a copy of its algorithm to answer the + query. Store the results, including any intermediate CNAMEs and + DNAMEs, in the answer section of the response. + + + 6. Using local data only, attempt to add other RRs which may be + useful to the additional section of the query. Exit. + + Note that there will be at most one ancestor with a DNAME as + described in step 4 unless some zone's data is in violation of the + no-descendants limitation in section 3. An implementation might take + advantage of this limitation by stopping the search of step 3c or + step 4 when a DNAME record is encountered. + +3.3. Wildcards + + The use of DNAME in conjunction with wildcards is discouraged + [RFC4592]. Thus records of the form "*.example.com DNAME + example.net" SHOULD NOT be used. + + The interaction between the expansion of the wildcard and the + redirection of the DNAME is non-deterministic. Because the + processing is non-deterministic, DNSSEC validating resolvers may not + be able to validate a wildcarded DNAME. + + A server MAY give a warning that the behavior is unspecified if such + a wildcarded DNAME is loaded. The server MAY refuse it, refuse to + load the zone or refuse dynamic updates. + +3.4. Acceptance and Intermediate Storage + + Recursive caching name servers can encounter data at names below the + owner name of a DNAME RR, due to a change at the authoritative server + where data from before and after the change resides in the cache. + + + +Rose & Wijngaards Expires May 16, 2010 [Page 10] + +Internet-Draft DNAME Redirection November 2009 + + + This conflict situation is a transitional phase that ends when the + old data times out. The caching name server can opt to store both + old and new data and treat each as if the other did not exist, or + drop the old data, or drop the longer domain name. In any approach, + consistency returns after the older data TTL times out. + + Recursive caching name servers MUST perform CNAME synthesis on behalf + of clients. + + If a recursive caching name server encounters a DNAME RR which + contradicts information already in the cache (excluding CNAME + records), it SHOULD NOT cache the DNAME RR, but it MAY cache the + CNAME record received along with it, subject to the rules for CNAME. + +4. DNAME Discussions in Other Documents + + In [RFC2181], in Section 10.3., the discussion on MX and NS records + touches on redirection by CNAMEs, but this also holds for DNAMEs. + + Excerpt from 10.3. MX and NS records (in RFC 2181). + + The domain name used as the value of a NS resource record, + or part of the value of a MX resource record must not be + an alias. Not only is the specification clear on this + point, but using an alias in either of these positions + neither works as well as might be hoped, nor well fulfills + the ambition that may have led to this approach. This + domain name must have as its value one or more address + records. Currently those will be A records, however in + the future other record types giving addressing + information may be acceptable. It can also have other + RRs, but never a CNAME RR. + + The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME. + The opening premise of this section is demonstrably wrong, and so the + conclusion based on that premise is wrong. In particular, [RFC3363] + deprecates the use of DNAME in the IPv6 reverse tree, which is then + carried forward as a recommendation in [RFC4294]. Based on the + experience gained in the meantime, [RFC3363] should be revised, + dropping all constraints on having DNAME RRs in these zones. This + would greatly improve the manageability of the IPv6 reverse tree. + These changes are made explicit below. + + + + + + + + + +Rose & Wijngaards Expires May 16, 2010 [Page 11] + +Internet-Draft DNAME Redirection November 2009 + + + In [RFC3363], the paragraph + + "The issues for DNAME in the reverse mapping tree appears to be + closely tied to the need to use fragmented A6 in the main tree: if + one is necessary, so is the other, and if one isn't necessary, the + other isn't either. Therefore, in moving RFC 2874 to experimental, + the intent of this document is that use of DNAME RRs in the reverse + tree be deprecated." + + is to be replaced with the word "DELETED". + + In [RFC4294], the reference to DNAME was left in as an editorial + oversight. The paragraph + + "Those nodes are NOT RECOMMENDED to support the experimental A6 and + DNAME Resource Records [RFC3363]." + + is to be replaced by + + "Those nodes are NOT RECOMMENDED to support the experimental + A6 Resource Record [RFC3363]." + +5. Other Issues with DNAME + + There are several issues to be aware of about the use of DNAME. + +5.1. Canonical hostnames cannot be below DNAME owners + + The names listed as target names of MX, NS, PTR and SRV [RFC2782] + records must be canonical hostnames. This means no CNAME or DNAME + redirection may be present during DNS lookup of the address records + for the host. This is discussed in RFC 2181 [RFC2181], section 10.3, + and RFC 1912 [RFC1912], section 2.4. For SRV see RFC 2782 [RFC2782] + page 4. + + The upshot of this is that although the lookup of a PTR record can + involve DNAMEs, the name listed in the PTR record can not fall under + a DNAME. The same holds for NS, SRV and MX records. For example, + when punycode alternates for a zone use DNAME then the NS, MX, SRV + and PTR records that point to that zone must use names without + punycode in their RDATA. What must be done then is to have the + domain names with DNAME substitution already applied to it as the MX, + NS, PTR, SRV data. These are valid canonical hostnames. + +5.2. Dynamic Update and DNAME + + DNAME records can be added, changed and removed in a zone using + dynamic update transactions. Adding a DNAME RR to a zone occludes + + + +Rose & Wijngaards Expires May 16, 2010 [Page 12] + +Internet-Draft DNAME Redirection November 2009 + + + any domain names that may exist under the added DNAME. + + A server MUST reject a dynamic update message that attempts to add a + DNAME RR at a name that already has a CNAME RR or another DNAME RR + associated with that name. + +5.3. DNSSEC and DNAME + + The following subsections specify the behavior of implementations + that understand both DNSSEC and DNAME (synthesis). + +5.3.1. Signed DNAME, Unsigned Synthesized CNAME + + In any response, a signed DNAME RR indicates a non-terminal + redirection of the query. There might or might not be a server + synthesized CNAME in the answer section; if there is, the CNAME will + never be signed. For a DNSSEC validator, verification of the DNAME + RR and then checking that the CNAME was properly synthesized is + sufficient proof. + +5.3.2. DNAME Bit in NSEC Type Map + + In any negative response, the NSEC or NSEC3 [RFC5155] record type bit + map SHOULD be checked to see that there was no DNAME that could have + been applied. If the DNAME bit in the type bit map is set and the + query name is a subdomain of the closest encloser that is asserted, + then DNAME substitution should have been done, but the substitution + has not been done as specified. + +5.3.3. DNAME Chains as Strong as the Weakest Link + + A response can contain a chain of DNAME and CNAME redirections. That + chain can end in a positive answer or a negative (no name error or no + data error) reply. Each step in that chain results in resource + records added to the answer or authority section of the response. + Only if all steps are secure can the AD bit be set for the response. + If one of the steps is bogus, the result is bogus. + +5.3.4. Validators Must Understand DNAME + + Below are examples of why DNSSEC validators MUST understand DNAME. + In the examples below, SOA records, wildcard denial NSECs and other + material not under discussion has been omitted. + +5.3.4.1. DNAME in Bitmap Causes Invalid Name Error + + + + + + +Rose & Wijngaards Expires May 16, 2010 [Page 13] + +Internet-Draft DNAME Redirection November 2009 + + + ;; Header: QR AA DO RCODE=3(NXDOMAIN) + ;; Question + foo.bar.example.com. IN A + ;; Authority + bar.example.com. NSEC dub.example.com. A DNAME + bar.example.com. RRSIG NSEC [valid signature] + + If this is the received response, then only by understanding that the + DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to + have been redirected by the DNAME, the validator can see that it is a + BOGUS reply from an attacker that collated existing records from the + DNS to create a confusing reply. + + If the DNAME bit had not been set in the NSEC record above then the + answer would have validated as a correct name error response. + +5.3.4.2. Valid Name Error Response Involving DNAME in Bitmap + + ;; Header: QR AA DO RCODE=3(NXDOMAIN) + ;; Question + cee.example.com. IN A + ;; Authority + bar.example.com. NSEC dub.example.com. A DNAME + bar.example.com. RRSIG NSEC [valid signature] + + This response has the same NSEC records as the example above, but + with this query name (cee.example.com), the answer is validated, + because 'cee' does not get redirected by the DNAME at 'bar'. + +5.3.4.3. Response With Synthesized CNAME + + ;; Header: QR AA DO RCODE=0(NOERROR) + ;; Question + foo.bar.example.com. IN A + ;; Answer + bar.example.com. DNAME bar.example.net. + bar.example.com. RRSIG DNAME [valid signature] + foo.bar.example.com. CNAME foo.bar.example.net. + + The response shown above has the synthesized CNAME included. + However, the CNAME has no signature, since the server does not sign + online. So this response cannot be trusted. It could be altered by + an attacker to be foo.bar.example.com CNAME bla.bla.example. The + DNAME record does have its signature included, since it does not + change. The validator must verify the DNAME signature and then + recursively resolve further to query for the foo.bar.example.net A + record. + + + + +Rose & Wijngaards Expires May 16, 2010 [Page 14] + +Internet-Draft DNAME Redirection November 2009 + + +6. IANA Considerations + + The DNAME Resource Record type code 39 (decimal) originally has been + registered by [RFC2672]. IANA should update the DNS resource record + registry to point to this document for RR type 39. + +7. Security Considerations + + DNAME redirects queries elsewhere, which may impact security based on + policy and the security status of the zone with the DNAME and the + redirection zone's security status. For validating resolvers, the + lowest security status of the links in the chain of CNAME and DNAME + redirections is applied to the result. + + If a validating resolver accepts wildcarded DNAMEs, this creates + security issues. Since the processing of a wildcarded DNAME is non- + deterministic and the CNAME that was substituted by the server has no + signature, the resolver may choose a different result than what the + server meant, and consequently end up at the wrong destination. Use + of wildcarded DNAMEs is discouraged in any case [RFC4592]. + + A validating resolver MUST understand DNAME, according to [RFC4034]. + The examples in Section 5.3.4 illustrate this need. + +8. Acknowledgments + + The authors of this draft would like to acknowledge Matt Larson for + beginning this effort to address the issues related to the DNAME RR + type. The authors would also like to acknowledge Paul Vixie, Ed + Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred + Hoenes and Kevin Darcy for their review and comments on this + document. + +9. References + +9.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + + + +Rose & Wijngaards Expires May 16, 2010 [Page 15] + +Internet-Draft DNAME Redirection November 2009 + + + RFC 2136, April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name + System", RFC 4592, July 2006. + + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, March 2008. + +9.2. Informative References + + [RFC1912] Barr, D., "Common DNS Operational and Configuration + Errors", RFC 1912, February 1996. + + [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", + RFC 2672, August 1999. + + [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. + Hain, "Representing Internet Protocol version 6 (IPv6) + Addresses in the Domain Name System (DNS)", RFC 3363, + August 2002. + + [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, + April 2006. + + + + + +Rose & Wijngaards Expires May 16, 2010 [Page 16] + +Internet-Draft DNAME Redirection November 2009 + + +Authors' Addresses + + Scott Rose + NIST + 100 Bureau Dr. + Gaithersburg, MD 20899 + USA + + Phone: +1-301-975-8439 + Fax: +1-301-975-6238 + EMail: scottr@nist.gov + + + Wouter Wijngaards + NLnet Labs + Science Park 140 + Amsterdam 1098 XG + The Netherlands + + Phone: +31-20-888-4551 + EMail: wouter@nlnetlabs.nl + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose & Wijngaards Expires May 16, 2010 [Page 17] + +