From: cvs2git Date: Wed, 30 Dec 2009 08:02:36 +0000 (+0000) Subject: This commit was manufactured by cvs2git to create tag 'v9_5_2_P1'. X-Git-Tag: v9.5.2-P1^0 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=1503d91dbf776da4bdacff87fb94441fcaaf6084;p=thirdparty%2Fbind9.git This commit was manufactured by cvs2git to create tag 'v9_5_2_P1'. --- diff --git a/bin/tests/system/pending/clean.sh b/bin/tests/system/pending/clean.sh deleted file mode 100644 index b0c0f587154..00000000000 --- a/bin/tests/system/pending/clean.sh +++ /dev/null @@ -1,30 +0,0 @@ -#!/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: clean.sh,v 1.4 2009/12/30 08:02:22 jinmei Exp $ - -rm -rf */*.signed -rm -rf */*.jnl -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 ns2/example.com.db -rm -rf random.data -rm -rf nsupdate.out.test diff --git a/bin/tests/system/pending/ns1/named.conf b/bin/tests/system/pending/ns1/named.conf deleted file mode 100644 index b23843f597a..00000000000 --- a/bin/tests/system/pending/ns1/named.conf +++ /dev/null @@ -1,38 +0,0 @@ -/* - * 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 deleted file mode 100644 index 41d868142d2..00000000000 --- a/bin/tests/system/pending/ns1/root.db.in +++ /dev/null @@ -1,33 +0,0 @@ -; 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.4 2009/12/30 08:02:22 jinmei 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 -example.com. NS ns2.example.com. -ns2.example.com. 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 deleted file mode 100644 index 6a76323e096..00000000000 --- a/bin/tests/system/pending/ns1/sign.sh +++ /dev/null @@ -1,52 +0,0 @@ -#!/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.3 2009/12/30 08:02:22 jinmei 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. . -cp ../ns2/dsset-example.com. . - -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.com.db.in b/bin/tests/system/pending/ns2/example.com.db.in deleted file mode 100644 index 9cdb2fd9a91..00000000000 --- a/bin/tests/system/pending/ns2/example.com.db.in +++ /dev/null @@ -1,31 +0,0 @@ -; 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.com.db.in,v 1.2 2009/12/30 08:02:22 jinmei 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 192.0.2.2 - AAAA 2001:db8::2 -pending-ok A 192.0.2.2 -pending-ng A 192.0.2.102 diff --git a/bin/tests/system/pending/ns2/example.db.in b/bin/tests/system/pending/ns2/example.db.in deleted file mode 100644 index ca0d596b211..00000000000 --- a/bin/tests/system/pending/ns2/example.db.in +++ /dev/null @@ -1,28 +0,0 @@ -; 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 deleted file mode 100644 index 7cc1ffbc632..00000000000 --- a/bin/tests/system/pending/ns2/named.conf +++ /dev/null @@ -1,53 +0,0 @@ -/* - * 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.4 2009/12/30 08:02:22 jinmei 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"; -}; - -zone "example.com" { - type master; - file "example.com.db.signed"; - allow-update { 10.53.0.0/8; }; -}; diff --git a/bin/tests/system/pending/ns2/sign.sh b/bin/tests/system/pending/ns2/sign.sh deleted file mode 100644 index 626927aa06b..00000000000 --- a/bin/tests/system/pending/ns2/sign.sh +++ /dev/null @@ -1,35 +0,0 @@ -#!/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: sign.sh,v 1.4 2009/12/30 08:02:22 jinmei Exp $ - -SYSTEMTESTTOP=../.. -. $SYSTEMTESTTOP/conf.sh - -RANDFILE=../random.data - -for domain in example example.com; do - zone=${domain}. - infile=${domain}.db.in - zonefile=${domain}.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 -done diff --git a/bin/tests/system/pending/ns3/hostile.db b/bin/tests/system/pending/ns3/hostile.db deleted file mode 100644 index 2a2d3501df3..00000000000 --- a/bin/tests/system/pending/ns3/hostile.db +++ /dev/null @@ -1,27 +0,0 @@ -; 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 deleted file mode 100644 index d56f9f01ed7..00000000000 --- a/bin/tests/system/pending/ns3/mail.example.db +++ /dev/null @@ -1,28 +0,0 @@ -; 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 deleted file mode 100644 index 659746a4b74..00000000000 --- a/bin/tests/system/pending/ns3/named.conf +++ /dev/null @@ -1,52 +0,0 @@ -/* - * 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.3 2009/11/18 23:48:07 tbox 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 deleted file mode 100644 index 8c941496e23..00000000000 --- a/bin/tests/system/pending/ns4/named.conf +++ /dev/null @@ -1,37 +0,0 @@ -/* - * 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 deleted file mode 100644 index b05b622ed7e..00000000000 --- a/bin/tests/system/pending/prereq.sh +++ /dev/null @@ -1,27 +0,0 @@ -#!/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: prereq.sh,v 1.3 2009/11/18 23:48:06 tbox 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 deleted file mode 100644 index 5332d36de61..00000000000 --- a/bin/tests/system/pending/setup.sh +++ /dev/null @@ -1,21 +0,0 @@ -#!/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 deleted file mode 100644 index c27b072a01c..00000000000 --- a/bin/tests/system/pending/tests.sh +++ /dev/null @@ -1,162 +0,0 @@ -#!/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: tests.sh,v 1.4 2009/12/30 08:02:22 jinmei Exp $ - -SYSTEMTESTTOP=.. -. $SYSTEMTESTTOP/conf.sh - -# replace_data dname RR old_data new_data -replace_data() -{ - if [ $# -ne 4 ]; then - echo I:unexpected input for replace_data - return 1 - fi - - _dname=$1 - _rr=$2 - _olddata=$3 - _newdata=$4 - - _ret=0 - $NSUPDATE -d <> nsupdate.out.test 2>&1 || _ret=1 -server 10.53.0.2 5300 -update delete ${_dname} 30 ${_rr} ${_olddata} -update add ${_dname} 30 ${_rr} ${_newdata} -send -END - - if [ $_ret != 0 ]; then - echo I:failed to update the test data - return 1 - fi - - return 0 -} - -status=0 -n=0 - -DIGOPTS="+short +tcp -p 5300" -DIGOPTS_CD="$DIGOPTS +cd" - -echo I:Priming cache. -ret=0 -expect="10 mail.example." -ans=`$DIG $DIGOPTS_CD @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_CD @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` - -# -# Prime cache with pending additional records. These should not be promoted -# to answer. -# -echo "I:Priming cache (pending additional A and AAAA)" -ret=0 -expect="10 mail.example.com." -ans=`$DIG $DIGOPTS @10.53.0.4 example.com MX` || ret=1 -test "$ans" = "$expect" || ret=1 -test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'" -status=`expr $status + $ret` - -echo "I:Replacing pending A" -ret=0 -replace_data mail.example.com. A 192.0.2.2 192.0.2.3 || ret=1 -status=`expr $status + $ret` - -echo "I:Replacing pending AAAA" -ret=0 -replace_data mail.example.com. AAAA 2001:db8::2 2001:db8::3 || ret=1 -status=`expr $status + $ret` - -echo "I:Checking updated data to be returned (without CD)" -ret=0 -expect="192.0.2.3" -ans=`$DIG $DIGOPTS @10.53.0.4 mail.example.com A` || ret=1 -test "$ans" = "$expect" || ret=1 -test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'" -status=`expr $status + $ret` - -echo "I:Checking updated data to be returned (with CD)" -ret=0 -expect="2001:db8::3" -ans=`$DIG $DIGOPTS_CD @10.53.0.4 mail.example.com AAAA` || ret=1 -test "$ans" = "$expect" || ret=1 -test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'" -status=`expr $status + $ret` - -# -# Prime cache with a pending answer record. It can be returned (without -# validation) with +CD. -# -echo "I:Priming cache (pending answer)" -ret=0 -expect="192.0.2.2" -ans=`$DIG $DIGOPTS_CD @10.53.0.4 pending-ok.example.com A` || ret=1 -test "$ans" = "$expect" || ret=1 -test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'" -status=`expr $status + $ret` - -echo I:Replacing pending data -ret=0 -replace_data pending-ok.example.com. A 192.0.2.2 192.0.2.3 || ret=1 -status=`expr $status + $ret` - -echo I:Confirming cached pending data to be returned with CD -ret=0 -expect="192.0.2.2" -ans=`$DIG $DIGOPTS_CD @10.53.0.4 pending-ok.example.com A` || ret=1 -test "$ans" = "$expect" || ret=1 -test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'" -status=`expr $status + $ret` - -# -# Prime cache with a pending answer record. It should not be returned -# to no-DNSSEC clients. -# -echo "I:Priming cache (pending answer)" -ret=0 -expect="192.0.2.102" -ans=`$DIG $DIGOPTS_CD @10.53.0.4 pending-ng.example.com A` || ret=1 -test "$ans" = "$expect" || ret=1 -test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'" -status=`expr $status + $ret` - -echo I:Replacing pending data -ret=0 -replace_data pending-ng.example.com. A 192.0.2.102 192.0.2.103 || ret=1 -status=`expr $status + $ret` - -echo I:Confirming updated data returned, not the cached one, without CD -ret=0 -expect="192.0.2.103" -ans=`$DIG $DIGOPTS @10.53.0.4 pending-ng.example.com 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-6man-text-addr-representation-01.txt b/doc/draft/draft-ietf-6man-text-addr-representation-01.txt deleted file mode 100644 index f15b069b5ba..00000000000 --- a/doc/draft/draft-ietf-6man-text-addr-representation-01.txt +++ /dev/null @@ -1,785 +0,0 @@ - - - -IPv6 Maintenance Working Group S. Kawamura -Internet-Draft NEC BIGLOBE, Ltd. -Intended status: Informational M. Kawashima -Expires: April 21, 2010 NEC AccessTechnica, Ltd. - October 18, 2009 - - - A Recommendation for IPv6 Address Text Representation - draft-ietf-6man-text-addr-representation-01 - -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 April 21, 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 - - As IPv6 network grows, there will be more engineers and also non- - engineers who will have the need to use an IPv6 address in text. - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 1] - -Internet-Draft IPv6 Text Representation October 2009 - - - While the IPv6 address architecture RFC 4291 section 2.2 depicts a - flexible model for text representation of an IPv6 address, this - flexibility has been causing problems for operators, system - engineers, and users. This document will describe the problems that - a flexible text representation has been causing. This document also - recommends a canonical representation format that best avoids - confusion. It is expected that the canonical format is followed by - humans and systems when representing IPv6 addresses as text, but all - implementations must accept and be able to handle any legitimate - RFC4291 format. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 - 2. Text Representation Flexibility of RFC4291 . . . . . . . . . . 4 - 2.1. Leading Zeros in a 16 Bit Field . . . . . . . . . . . . . 4 - 2.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5 - 2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 5 - 3. Problems Encountered with the Flexible Model . . . . . . . . . 6 - 3.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1.1. General Summary . . . . . . . . . . . . . . . . . . . 6 - 3.1.2. Searching Spreadsheets and Text Files . . . . . . . . 6 - 3.1.3. Searching with Whois . . . . . . . . . . . . . . . . . 6 - 3.1.4. Searching for an Address in a Network Diagram . . . . 7 - 3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7 - 3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7 - 3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 8 - 3.2.4. Auditing: Case 2 . . . . . . . . . . . . . . . . . . . 8 - 3.2.5. Verification . . . . . . . . . . . . . . . . . . . . . 8 - 3.2.6. Unexpected Modifying . . . . . . . . . . . . . . . . . 8 - 3.3. Operating . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.3.1. General Summary . . . . . . . . . . . . . . . . . . . 8 - 3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 9 - 3.3.3. Abuse . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.4. Other Minor Problems . . . . . . . . . . . . . . . . . . . 9 - 3.4.1. Changing Platforms . . . . . . . . . . . . . . . . . . 9 - 3.4.2. Preference in Documentation . . . . . . . . . . . . . 9 - 3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 10 - 4. A Recommendation for IPv6 Text Representation . . . . . . . . 10 - 4.1. Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10 - 4.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.2.1. Shorten As Much As Possible . . . . . . . . . . . . . 10 - 4.2.2. Handling One 16 Bit 0 Field . . . . . . . . . . . . . 10 - 4.2.3. Choice in Placement of "::" . . . . . . . . . . . . . 10 - 4.3. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 11 - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 2] - -Internet-Draft IPv6 Text Representation October 2009 - - - 5. Text Representation of Special Addresses . . . . . . . . . . . 11 - 6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11 - 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 13 - Appendix B. Prefix Issues . . . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 3] - -Internet-Draft IPv6 Text Representation October 2009 - - -1. Introduction - - A single IPv6 address can be text represented in many ways. Examples - are shown below. - - 2001:db8:0:0:1:0:0:1 - - 2001:0db8:0:0:1:0:0:1 - - 2001:db8::1:0:0:1 - - 2001:db8::0:1:0:0:1 - - 2001:0db8::1:0:0:1 - - 2001:db8:0:0:1::1 - - 2001:db8:0000:0:1::1 - - 2001:DB8:0:0:1::1 - - All the above point to the same IPv6 address. This flexibility has - caused many problems for operators, systems engineers, and customers. - The problems will be noted in Section 3. Also, a canonical - representation format to avoid problems will be introduced in - Section 4. - -1.1. 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 [RFC2119]. - - -2. Text Representation Flexibility of RFC4291 - - Examples of flexibility in Section 2.2 of [RFC4291] are described - below. - -2.1. Leading Zeros in a 16 Bit Field - - 'It is not necessary to write the leading zeros in an individual - field.' - - In other words, it is also not necessary to omit leading zeros. This - means that, it is possible to select from such as the following - example. The final 16 bit field is different, but all these - addresses mean the same. - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 4] - -Internet-Draft IPv6 Text Representation October 2009 - - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001 - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:001 - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:01 - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:1 - -2.2. Zero Compression - - 'A special syntax is available to compress the zeros. The use of - "::" indicates one or more groups of 16 bits of zeros.' - - It is possible to select whether or not to omit just one 16 bits of - zeros. - - 2001:db8:aaaa:bbbb:cccc:dddd::1 - - 2001:db8:aaaa:bbbb:cccc:dddd:0:1 - - In case where there are more than one zero fields, there is a choice - of how many fields can be shortened. Examples follow. - - 2001:db8:0:0:0::1 - - 2001:db8:0:0::1 - - 2001:db8:0::1 - - 2001:db8::1 - - In addition, [RFC4291] in section 2.2 notes, - - 'The "::" can only appear once in an address.' - - This gives a choice on where, in a single address to compress the - zero. Examples are shown below. - - 2001:db8::aaaa:0:0:1 - - 2001:db8:0:0:aaaa::1 - -2.3. Uppercase or Lowercase - - [RFC4291] does not mention about preference of uppercase or - lowercase. Various flavors are shown below. - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 5] - -Internet-Draft IPv6 Text Representation October 2009 - - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa - - -3. Problems Encountered with the Flexible Model - -3.1. Searching - -3.1.1. General Summary - - A search of an IPv6 address if conducted through a UNIX system is - usually case sensitive and extended options to allow for regular - expression use will come in handy. However, there are many - applications in the Internet today that do not provide this - capability. When searching for an IPv6 address in such systems, the - system engineer will have to try each and every possibility to search - for an address. This has critical impacts especially when trying to - deploy IPv6 over an enterprise network. - -3.1.2. Searching Spreadsheets and Text Files - - Spreadsheet applications and text editors on GUI systems, rarely have - the ability to search for a text using regular expression. Moreover, - there are many non-engineers (who are not aware of case sensitivity - and regular expression use) that use these application to manage IP - addresses. This has worked quite well with IPv4 since text - representation in IPv4 has very little flexibility. There is no - incentive to encourage these non-engineers to change their tool or - learn regular expression when they decide to go dual-stack. If the - entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was - conducted as 2001:db8:0:0:1::1, this will show a result of no match. - One example where this will cause problem is, when the search is - being conducted to assign a new address from a pool, and a check was - being done to see if it was not in use. This may cause problems to - the end-hosts or end-users. This type of address management is very - often seen in enterprise networks and also in ISPs. - -3.1.3. Searching with Whois - - The "whois" utility is used by a wide range of people today. When a - record is set to a database, one will likely check the output to see - if the entry is correct. If an entity was recorded as 2001:db8::/48, - but the whois output showed 2001:0db8:0000::/48, most non-engineers - would think that their input was wrong, and will likely retry several - times or make a frustrated call to the database hostmaster. If there - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 6] - -Internet-Draft IPv6 Text Representation October 2009 - - - was a need to register the same address on different systems, and - each system showed a different text representation, this would - confuse people even more. Although this document focuses on - addresses rather than prefixes, this is worth mentioning since - problems encountered are mostly equal. - -3.1.4. Searching for an Address in a Network Diagram - - Network diagrams and blue-prints contain IP addresses as allocated to - system devices. In times of trouble shooting, there may be a need to - search through a diagram to find the point of failure (for example, - if a traceroute stopped at 2001:db8::1, one would search the diagram - for that address). This is a technique quite often in use in - enterprise networks and managed services. Again, the different - flavors of text representation will result in a time-consuming - search, leading to longer MTTR in times of trouble. - -3.2. Parsing and Modifying - -3.2.1. General Summary - - With all the possible text representation ways, each application must - include a module, object, link, etc. to a function that will parse - IPv6 addresses in a manner that no matter how it is represented, they - will mean the same address. This is not too much a problem if the - output is to be just 'read' or 'managed' by a network engineer. - However, many system engineers who integrate complex computer systems - to corporate customers will have difficulties finding that their - favorite tool will not have this function, or will encounter - difficulties such as having to rewrite their macro's or scripts for - their customers. It must be noted that each additional line of a - program will result in increased development fees that will be - charged to the customers. - -3.2.2. Logging - - If an application were to output a log summary that represented the - address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444), - the output would be highly unreadable compared to the IPv4 output. - The address would have to be parsed and reformed to make it useful - for human reading. This will result in additional code on the - applications which will result in extra fees charged to the - customers. Sometimes, logging for critical systems is done by - mirroring the same traffic to two different systems. Care must be - taken that no matter what the log output is, the logs should be - parsed so they will mean the same. - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 7] - -Internet-Draft IPv6 Text Representation October 2009 - - -3.2.3. Auditing: Case 1 - - When a router or any other network appliance machine configuration is - audited, there are many methods to compare the configuration - information of a node. Sometimes, auditing will be done by just - comparing the changes made each day. In this case, if configuration - was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000: - 0000:0000:0000:0001 just because the new engineer on the block felt - it was better, a simple diff will tell you that a different address - was configured. If this was done on a wide scale network, people - will be focusing on 'why the extra zeros were put in' instead of - doing any real auditing. Lots of tools are just plain 'diff's that - do not take into account address representation rules. - -3.2.4. Auditing: Case 2 - - Node configurations will be matched against an information system - that manages IP addresses. If output notation is different, there - will need to be a script that is implemented to cover for this. An - SNMP GET of an interface address and text representation in a humanly - written text file is highly unlikely to match on first try. - -3.2.5. Verification - - Some protocols require certain data fields to be verified. One - example of this is X.509 certificates. If an IPv6 address was - embedded in one of the fields in a certificate, and the verification - was done by just a simple textual comparison, the certificate may be - maistakenly shown as being invalid due to a difference in text - representation methods. - -3.2.6. Unexpected Modifying - - Sometimes, a system will take an address and modify it as a - convenience. For example, a system may take an input of - 2001:0db8:0::1 and make the output 2001:db8::1 (which is seen in some - RIR databases). If the zeros were input for a reason, the outcome - may be somewhat unexpected. - -3.3. Operating - -3.3.1. General Summary - - When an operator sets an IPv6 address of a system as 2001:db8:0:0:1: - 0:0:1, the system may take the address and show the configuration - result as 2001:DB8::1:0:0:1. A distinguished engineer will know that - the right address is set, but an operator, or a customer that is - communicating with the operator to solve a problem, is usually not as - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 8] - -Internet-Draft IPv6 Text Representation October 2009 - - - distinguished as we would like. Again, the extra load in checking - that the IP address is the same as was intended, will result in fees - that will be charged to the customers. - -3.3.2. Customer Calls - - When a customer calls to inquire about a suspected outage, IPv6 - address representation should be handled with care. Not all - customers are engineers nor have the same skill in IPv6 technology. - The NOC will have to take extra steps to humanly parse the address to - avoid having to explain to the customers that 2001:db8:0:1::1 is the - same as 2001:db8::1:0:0:0:1. This is one thing that will never - happen in IPv4 because IPv4 address cannot be abbreviated. - -3.3.3. Abuse - - Network abuse is reported along with the abusing IP address. This - 'reporting' could take any shape or form of the flexible model. A - team that handles network abuse must be able to tell the difference - between a 2001:db8::1:0:1 and 2001:db8:1::0:1. Mistakes in the - placement of the "::" will result in a critical situation. A system - that handles these incidents should be able to handle any type of - input and parse it in a correct manner. Also, incidents are reported - over the phone. It is unnecessary to report if the letter is an - uppercase or lowercase. However, when a letter is spelled uppercase, - people tend to clarify that it is uppercase, which is unnecessary - information. - -3.4. Other Minor Problems - -3.4.1. Changing Platforms - - When an engineer decides to change the platform of a running service, - the same code may not work as expected due to the difference in IPv6 - address text representation. Usually, a change in a platform (e.g. - Unix to Windows, Cisco to Juniper) will result in a major change of - code, but flexibility in address representation will increase the - work load which will again, result in fees that will be charged to - the customers, and also longer down time of systems. - -3.4.2. Preference in Documentation - - A document that is edited by more than one author, may become harder - to read. - - - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 9] - -Internet-Draft IPv6 Text Representation October 2009 - - -3.4.3. Legibility - - Capital case D and 0 can be quite often misread. Capital B and 8 can - also be misread. - - -4. A Recommendation for IPv6 Text Representation - - A recommendation for a canonical text representation format of IPv6 - addresses is presented in this section. The recommendation in this - document is one that, complies fully with [RFC4291], is implemented - by various operating systems, and is human friendly. The - recommendation in this document SHOULD be followed by humans and - systems when generating an address to represent as text, but all - implementations MUST accept any legitimate [RFC4291] format. - -4.1. Handling Leading Zeros in a 16 Bit Field - - Leading zeros should be chopped for human legibility and easier - searching. Also, a single 16 bit 0000 field should be represented as - just 0. Place holder zeros are often cause of misreading. - -4.2. "::" Usage - -4.2.1. Shorten As Much As Possible - - The use of "::" should be used to its maximum capability (i.e. 2001: - db8::0:1 is not considered as clean representation). - -4.2.2. Handling One 16 Bit 0 Field - - "::" should not be used to shorten just one 16 bit 0 field for it - would tend to mislead that there are more than one 16 bit field that - is shortened. - -4.2.3. Choice in Placement of "::" - - When there is an alternative choice in the placement of a "::", the - longest run of consecutive 16 bit 0 fields should be shortened (i.e. - latter is shortened in 2001:0:0:1:0:0:0:1). When the length of the - consecutive 16 bit 0 fields are equal (i.e. 2001:db8:0:0:1:0:0:1), - the former is shortened. This is consistent with many current - implementations. One idea to avoid any confusion, is for the - operator to not use 16 bit field 0 in the first 64 bits. By nature - IPv6 addresses are usually assigned or allocated to end-users as - longer than 32 bits (typically 48 bits or longer). - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 10] - -Internet-Draft IPv6 Text Representation October 2009 - - -4.3. Lower Case - - Recent implementations tend to represent IPv6 address as lower case. - It is better to use lower case to avoid problems such as described in - section 3.3.3 and 3.4.3. - - -5. Text Representation of Special Addresses - - Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and - IPv4-translated addresses [RFC2765] have IPv4 addresses embedded in - the low-order 32 bits of the address. These addresses have special - representation that may mix hexadecimal and decimal notations. In - cases where there is a choice of whether to express the address as - fully hexadecimal or hexadecimal and decimal mixed, and if the - address type can be distinguished as having IPv4 addresses embedded - in the lower 32 bits solely from the 128bits of the address field - itself, mixed notation is the better choice. However, there may be - situations where hexadecimal representation is chosen to meet certain - needs. Addressing those needs is out of the scope of this document. - The text representation method noted in Section 4 should be applied - for the leading hexadecimal part (i.e. ::ffff:192.0.2.1 instead of - 0:0:0:0:0:ffff:192.0.2.1). - - -6. Notes on Combining IPv6 Addresses with Port Numbers - - When IPv6 addresses and port numbers are represented in text combined - together, there seems to be many different ways to do so. Examples - are shown below. - - o [2001:db8::1]:80 - - o 2001:db8::1:80 - - o 2001:db8::1.80 - - o 2001:db8::1 port 80 - - o 2001:db8::1p80 - - o 2001:db8::1#80 - - The situation is not much different in IPv4, but the most ambiguous - case with IPv6 is the second bullet. This is due to the "::"usage in - IPv6 addresses. This style is not recommended for its ambiguity. - The [] style as expressed in [RFC3986] is recommended. Other styles - are acceptable when cross-platform portability does not become an - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 11] - -Internet-Draft IPv6 Text Representation October 2009 - - - issue. - - -7. Conclusion - - The recommended format of text representing an IPv6 address is - summarized as follows. - - (1) omit leading zeros in a 16 bit field - - (2) when using "::", shorten consecutive zero fields to their - maximum extent (leave no zero fields behind). - - (3) "::" used where shortens address the most - - (4) "::" used in the former part in case of a tie breaker - - (5) do not shorten one 16 bit 0 field, but always shorten when - there are two or more consecutive 16 bit 0 fields - - (6) use lower case - - Hints for developers are written in the Appendix section. - - -8. Security Considerations - - None. - - -9. IANA Considerations - - None. - - -10. Acknowledgements - - The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami, - Toshimitsu Matsuura for their generous and helpful comments in kick - starting this document. We also would like to thank Brian Carpenter, - Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler, - Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki - Vatiainen for their input. Also a very special thanks to Ron Bonica, - Fred Baker, Brian Haberman, Robert Hinden, Jari Arkko, and Kurt - Lindqvist for their support in bringing this document to the light of - IETF working groups. - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 12] - -Internet-Draft IPv6 Text Representation October 2009 - - -11. References - -11.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 4291, February 2006. - -11.2. Informative References - - [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm - (SIIT)", RFC 2765, February 2000. - - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, - RFC 3986, January 2005. - - [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. - Castro, "Application Aspects of IPv6 Transition", - RFC 4038, March 2005. - - [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site - Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, - March 2008. - - -Appendix A. For Developers - - We recommend that developers use display routines that conform to - these rules. For example, the usage of getnameinfo() with flags - argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output, - except for the special addresses notes in Section 5. The function - inet_ntop() of FreeBSD7.0 is a good C code reference, but should not - be called directly. See [RFC4038] for details. - - -Appendix B. Prefix Issues - - Problems with prefixes are just the same as problems encountered with - addresses. Text representation method of IPv6 prefixes should be no - different from that of IPv6 addresses. - - - - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 13] - -Internet-Draft IPv6 Text Representation October 2009 - - -Authors' Addresses - - Seiichi Kawamura - NEC BIGLOBE, Ltd. - 14-22, Shibaura 4-chome - Minatoku, Tokyo 108-8558 - JAPAN - - Phone: +81 3 3798 6085 - Email: kawamucho@mesh.ad.jp - - - Masanobu Kawashima - NEC AccessTechnica, Ltd. - 800, Shimomata - Kakegawa-shi, Shizuoka 436-8501 - JAPAN - - Phone: +81 537 23 9655 - Email: kawashimam@necat.nec.co.jp - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 14] - - diff --git a/doc/draft/draft-ietf-behave-dns64-01.txt b/doc/draft/draft-ietf-behave-dns64-01.txt deleted file mode 100644 index 25a6dd4d072..00000000000 --- a/doc/draft/draft-ietf-behave-dns64-01.txt +++ /dev/null @@ -1,1624 +0,0 @@ - - - -BEHAVE WG M. Bagnulo -Internet-Draft UC3M -Intended status: Standards Track A. Sullivan -Expires: April 22, 2010 Shinkuro - P. Matthews - Alcatel-Lucent - I. van Beijnum - IMDEA Networks - October 19, 2009 - - -DNS64: DNS extensions for Network Address Translation from IPv6 Clients - to IPv4 Servers - draft-ietf-behave-dns64-01 - -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 April 22, 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. - - - -Bagnulo, et al. Expires April 22, 2010 [Page 1] - -Internet-Draft DNS64 October 2009 - - -Abstract - - DNS64 is a mechanism for synthesizing AAAA records from A records. - DNS64 is used with an IPv6/IPv4 translator to enable client-server - communication between an IPv6-only client and an IPv4-only server, - without requiring any changes to either the IPv6 or the IPv4 node, - for the class of applications that work through NATs. This document - specifies DNS64, and provides suggestions on how it should be - deployed in conjunction with IPv6/IPv4 translators. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Background to DNS64 - DNSSEC interaction . . . . . . . . . . . 6 - 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 9 - 5.1. Resolving AAAA queries and the answer section . . . . . . 9 - 5.1.1. The answer when there is AAAA data available . . . . . 9 - 5.1.2. The answer when there is an error . . . . . . . . . . 9 - 5.1.3. Data for the answer when performing synthesis . . . . 9 - 5.1.4. Performing the synthesis . . . . . . . . . . . . . . . 10 - 5.1.5. Querying in parallel . . . . . . . . . . . . . . . . . 11 - 5.2. Generation of the IPv6 representations of IPv4 - addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 - 5.3. Handling other RRs . . . . . . . . . . . . . . . . . . . . 12 - 5.3.1. PTR queries . . . . . . . . . . . . . . . . . . . . . 12 - 5.3.2. Handling the additional section . . . . . . . . . . . 13 - 5.3.3. Other records . . . . . . . . . . . . . . . . . . . . 13 - 5.4. Assembling a synthesized response to a AAAA query . . . . 14 - 5.5. DNSSEC processing: DNS64 in recursive server mode . . . . 14 - 5.6. DNS64 and multihoming . . . . . . . . . . . . . . . . . . 15 - 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 16 - 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 16 - 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 16 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 - Appendix A. Deployment scenarios and examples . . . . . . . . . . 20 - A.1. Embed and Zero-Pad algorithm description . . . . . . . . . 21 - A.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in - DNS server mode . . . . . . . . . . . . . . . . . . . . . 22 - A.3. An-IPv6-network-to-IPv4-Internet setup with DNS64 in - stub-resolver mode . . . . . . . . . . . . . . . . . . . . 23 - - - -Bagnulo, et al. Expires April 22, 2010 [Page 2] - -Internet-Draft DNS64 October 2009 - - - A.4. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS - server mode . . . . . . . . . . . . . . . . . . . . . . . 25 - Appendix B. Motivations and Implications of synthesizing AAAA - RR when real AAAA RR exists . . . . . . . . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 3] - -Internet-Draft DNS64 October 2009 - - -1. Introduction - - This document specifies DNS64, a mechanism that is part of the - toolbox for IPv6-IPv4 transition and co-existence. DNS64, used - together with an IPv6/IPv4 translator such as NAT64 - [I-D.bagnulo-behave-nat64], allows an IPv6-only client to initiate - communications by name to an IPv4-only server. - - DNS64 is a mechanism for synthesizing AAAA resource records (RRs) - from A RRs. A synthetic AAAA RR created by the DNS64 from an - original A RR contains the same FQDN of the original A RR but it - contains an IPv6 address instead of an IPv4 address. The IPv6 - address is an IPv6 representation of the IPv4 address contained in - the original A RR. The IPv6 representation of the IPv4 address is - algorithmically generated from the IPv4 address returned in the A RR - and a set of parameters configured in the DNS64 (typically, an IPv6 - prefix used by IPv6 representations of IPv4 addresses and optionally - other parameters). - - Together with a IPv6/IPv4 translator, these two mechanisms allow an - IPv6-only client to initiate communications to an IPv4-only server - using the FQDN of the server. - - These mechanisms are expected to play a critical role in the IPv4- - IPv6 transition and co-existence. Due to IPv4 address depletion, it - is likely that in the future, many IPv6-only clients will want to - connect to IPv4-only servers. In the typical case, the approach only - requires the deployment of IPv6/IPv4 translators that connect an - IPv6-only network to an IPv4-only network, along with the deployment - of one or more DNS64-enabled name servers. However, some advanced - features require performing the DNS64 function directly by the end- - hosts themselves. - - -2. Overview - - This section provides a non-normative introduction to the DNS64 - mechanism. - - We assume that we have an IPv6/IPv4 translator box connecting an IPv4 - network and an IPv6 network. The IPv6/IPv4 translator device - provides translation services between the two networks enabling - communication between IPv4-only hosts and IPv6-only hosts. (NOTE: By - IPv6-only hosts we mean hosts running IPv6-only applications, hosts - that can only use IPv6, as well as the cases where only IPv6 - connectivity is available to the client. By IPv4-only servers we - mean servers running IPv4-only applications, servers that can only - use IPv4, as well as the cases where only IPv4 connectivity is - - - -Bagnulo, et al. Expires April 22, 2010 [Page 4] - -Internet-Draft DNS64 October 2009 - - - available to the server). The IPv6/IPv4 translator used in - conjunction with DNS64 must allow communications initiated from the - IPv6-only host to the IPv4-only host. - - To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to - learn the address of the responder, DNS64 is used to synthesize a - AAAA record from an A record containing a real IPv4 address of the - responder, whenever the DNS64 service cannot retrieve a AAAA record - for the requested host name. The DNS64 device appears as a regular - recursive resolver for the IPv6 initiator. The DNS64 box receives an - AAAA DNS query generated by the IPv6 initiator. It first attempts a - recursive resolution for the requested AAAA records. If there is no - AAAA record available for the target node (which is the normal case - when the target node is an IPv4-only node), DNS64 performs a query - for A records. If any A records are discovered, DNS64 creates a - synthetic AAAA RR from the information retrieved in each A RR. - - The FQDN of a synthetic AAAA RR is the same as that of the original A - RR, but an IPv6 representation of the IPv4 address contained in the - original A RR is included in the AAAA RR. The IPv6 representation of - the IPv4 address is algorithmically generated from the IPv4 address - and additional parameters configured in the DNS64. Among those - parameters configured in the DNS64, there is at least one IPv6 - prefix, called Pref64::/n. The IPv6 address representing IPv4 - addresses included in the AAAA RR synthesized by the DNS64 function - contain Pref64::/n and they also embed the original IPv4 address. - - The same algorithm and the same Pref64::/n prefix or prefixes must be - configured both in the DNS64 device and the IPv6/IPv4 translator, so - that both can algorithmically generate the same IPv6 representation - for a given IPv4 address. In addition, it is required that IPv6 - packets addressed to an IPv6 destination that contains the Pref64::/n - be delivered to the IPv6/IPv4 translator, so they can be translated - into IPv4 packets. - - Once the DNS64 has synthesized the AAAA RR, the synthetic AAAA RR is - passed back to the IPv6 initiator, which will initiate an IPv6 - communication with the IPv6 address associated with the IPv4 - receiver. The packet will be routed to the IPv6/IPv4 translator - which will forward it to the IPv4 network . - - In general, the only shared state between the DNS64 and the IPv6/IPv4 - translator is the Pref64::/n and an optional set of static - parameters. The Pref64::/n and the set of static parameters must be - configured to be the same on both; there is no communication between - the DNS64 device and IPv6/IPv4 translator functions. The mechanism - to be used for configuring the parameters of the DNS64 is beyond the - scope of this memo. - - - -Bagnulo, et al. Expires April 22, 2010 [Page 5] - -Internet-Draft DNS64 October 2009 - - - The DNS64 function can be performed in two places. - - One option is to locate the DNS64 function in recursive name - servers serving end hosts. In this case, when an IPv6-only host - queries the name server for AAAA RRs for an IPv4-only host, the - name server can perform the synthesis of AAAA RRs and pass them - back to the IPv6 only initiator. The main advantage of this mode - is that current IPv6 nodes can use this mechanism without - requiring any modification. This mode is called "DNS64 in DNS - server mode". - - The other option is to place the DNS64 function in the end hosts - themselves, coupled to the local stub resolver. In this case, the - stub resolver will try to obtain (real) AAAA RRs and in case they - are not available, the DNS64 function will synthesize AAAA RRs for - internal usage. This mode is compatible with some advanced - functions like DNSSEC validation in the end host. The main - drawback of this mode is its deployability, since it requires - changes in the end hosts. This mode is called "DNS64 in stub- - resolver mode"". - - -3. Background to DNS64 - DNSSEC interaction - - DNSSEC presents a special challenge for DNS64, because DNSSEC is - designed to detect changes to DNS answers, and DNS64 may alter - answers coming from an authoritative server. - - A recursive resolver can be security-aware or security-oblivious. - Moreover, a security-aware recursive name server can be validating or - non-validating, according to operator policy. In the cases below, - the recursive server is also performing DNS64, and has a local policy - to validate. We call this general case vDNS64, but in all the cases - below the DNS64 functionality should be assumed needed. - - DNSSEC includes some signaling bits that offer some indicators of - what the query originator understands. - - If a query arrives at a vDNS64 device with the DO bit set, the query - originator is signaling that it understands DNSSEC. The DO bit does - not indicate that the query originator will validate the response. - It only means that the query originator can understand responses - containing DNSSEC data. Conversely, if the DO bit is clear, that is - evidence that the querying agent is not aware of DNSSEC. - - If a query arrives at a vDNS64 device with the CD bit set, it is an - indication that the querying agent wants all the validation data so - it can do checking itself. By local policy, vDNS64 could still - - - -Bagnulo, et al. Expires April 22, 2010 [Page 6] - -Internet-Draft DNS64 October 2009 - - - validate, but it must return all data to the querying agent anyway. - - Here are the possible cases: - - 1. A security-oblivious DNS64 node receives a query with the DO bit - clear. In this case, DNSSEC is not a concern, because the - querying agent does not understand DNSSEC responses. - - 2. A security-oblivious DNS64 node receives a query with the DO bit - set, and the CD bit clear. This is just like the case of a non- - DNS64 case: the server doesn't support it, so the querying agent - is out of luck. - - 3. A security-aware and non-validating DNS64 node receives a query - with the DO bit set and the CD bit clear. Such a resolver is not - validating responses, likely due to local policy (see [RFC4035], - section 4.2). For that reason, this case amounts to the same as - the previous case, and no validation happens. - - 4. A security-aware and non-validating DNS64 node receives a query - with the DO bit set and the CD bit set. In this case, the - resolver is supposed to pass on all the data it gets to the query - initiator (see section 3.2.2 of [RFC4035]). This case will be - problematic with DNS64. If the DNS64 server modifies the record, - the client will get the data back and try to validate it, and the - data will be invalid as far as the client is concerned. - - 5. A security-aware and validating DNS64 node receives a query with - the DO bit clear and CD clear. In this case, the resolver - validates the data. If it fails, it returns RCODE 2 (SERVFAIL); - otherwise, it returns the answer. This is the ideal case for - vDNS64. The resolver validates the data, and then synthesizes - the new record and passes that to the client. The client, which - is presumably not validating (else it would have set DO and CD), - cannot tell that DNS64 is involved. - - 6. A security-aware and validating DNS64 node receives a query with - the DO bit set and CD clear. In principle, this ought to work - like the previous case, except that the resolver should also set - the AD bit on the response. - - 7. A security-aware and validating DNS64 node receives a query with - the DO bit set and CD set. This is effectively the same as the - case where a security-aware and non-validating recursive resolver - receives a similar query, and the same thing will happen: the - downstream validator will mark the data as invalid if DNS64 has - performed synthesis. - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 7] - -Internet-Draft DNS64 October 2009 - - -4. Terminology - - This section provides definitions for the special terms used in the - 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 RFC 2119 [RFC2119]. - - Authoritative server: A DNS server that can answer authoritatively a - given DNS question. - - DNS64: A logical function that synthesizes DNS resource records (e.g - AAAA records containing IPv6 addresses) from DNS resource records - actually contained in the global DNS (e.g. A records containing - IPv4 addresses). - - DNS64 recursor: A recursive resolver that provides the DNS64 - functionality as part of its operation. - - Recursive resolver: A DNS server that accepts requests from one - resolver, and asks another resolver for the answer on behalf of - the first resolver. In the context of this document, "the - recursive resolver" means a recursive resolver immediately next in - the DNS resolution chain from an end point. The end point usually - has only a stub resolver available.[[anchor5: I can't actually - remember why we needed the sentences following "In the context of - this document. . ." Unless someone has a reason, I'll take it - out. --ajs@shinkuro.com]] - - Synthetic RR: A DNS resource record (RR) that is not contained in - any zone data file, but has been synthesized from other RRs. An - example is a synthetic AAAA record created from an A record. - - Stub resolver: A resolver with minimum functionality, typically for - use in end points that depend on a recursive resolver. Most end - points on the Internet as of this writing use stub - resolvers.[[anchor6: Do we need this in the document? I don't - think so. 1034 defines this term. --ajs@shinkuro.com]] - - IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4 - packets and vice-versa. It is only required that the - communication initiated from the IPv6 side be supported. - - For a detailed understanding of this document, the reader should also - be familiar with DNS terminology from [RFC1034],[RFC1035] and current - NAT terminology from [RFC4787]. Some parts of this document assume - familiarity with the terminology of the DNS security extensions - - - -Bagnulo, et al. Expires April 22, 2010 [Page 8] - -Internet-Draft DNS64 October 2009 - - - outlined in [RFC4035]. - - -5. DNS64 Normative Specification - - A DNS64 is a logical function that synthesizes AAAA records from A - records. The DNS64 function may be implemented in a stub resolver, - in a recursive resolver, or in an authoritative name server. - - The implementation SHOULD support mapping of IPv4 address ranges to - separate IPv6 prefixes for AAAA record synthesis. This allows - handling of special use IPv4 addresses [I-D.iana-rfc3330bis]. - Multicast address handling is further specified in - [I-D.venaas-behave-mcast46]. - -5.1. Resolving AAAA queries and the answer section - - When the DNS64 receives a query for RRs of type AAAA and class IN, it - first attempts to retrieve non-synthetic RRs of this type and class, - either by performing a query or, in the case of an authoritative - server, by examining its own results. - -5.1.1. The answer when there is AAAA data available - - If the query results in one or more AAAA records in the answer - section, the result is returned to the requesting client as per - normal DNS semantics (except in the case where the AAAA falls in the - ::ffff/96 network; see below for treatment of that network). In this - case, DNS64 SHOULD NOT include synthetic AAAA RRs in the response - (see Appendix B for an analysis of the motivations for and the - implications of not complying with this recommendation). By default - DNS64 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs - exist. - -5.1.2. The answer when there is an error - - If the query results in a response with an error code other than 0, - the result is handled according to normal DNS operation -- that is, - either the resolver tries again using a different server from the - authoritative NS RRSet, or it returns the error to the client. This - stage is still prior to any synthesis having happened, so a response - to be returned to the client does not need any special assembly than - would usually happen in DNS operation. - -5.1.3. Data for the answer when performing synthesis - - If the query results in no error but an empty answer section in the - response, the DNS64 resolver attempts to retrieve A records for the - - - -Bagnulo, et al. Expires April 22, 2010 [Page 9] - -Internet-Draft DNS64 October 2009 - - - name in question. If this new A RR query results in an empty answer - or in an error, then the empty result or error is used as the basis - for the answer returned to the querying client. (Transient errors - may result in retrying the query, depening on the operation of the - resolver; this is just as in Section 5.1.2.) If instead the query - results in one or more A RRs, the DNS64 synthesizes AAAA RRs based on - the A RRs according to the procedure outlined in Section 5.1.4. The - DNS64 resolver then returns the synthesized AAAA records in the - answer section to the client, removing the A records that form the - basis of the synthesis. - - As an exception to the general rule about always returning the AAAA - records if they are returned in the answer, AAAA records with - addresses in the ::ffff/96 network are treated just like the case - where there is neither an error nor an empty answer section. This is - because a real IPv6-only node will not be any more able to reach the - addresses in ::ffff/96 than it is able to reach an IPv4 address - without assistance. An implementation MAY use the address in - ::ffff/96 as the basis of synthesis without querying for an A record, - by using the last 32 bits of the address provided in the AAAA record. - [[anchor10: I changed this to say "neither. . .nor" because the - previous version suggested that it would return the error-or-empty- - answer to the querying client, and that can't be right. Correct? - --ajs@shinkuro.com]] - -5.1.4. Performing the synthesis - - A synthetic AAAA record is created from an A record as follows: - - o The NAME field is set to the NAME field from the A record - - o The TYPE field is set to 28 (AAAA) - - o The CLASS field is set to 1 (IN) - - o The TTL field is set to the minimum of the TTL of the original A - RR and the SOA RR for the queried domain. (Note that in order to - obtain the TTL of the SOA RR the DNS64 does not need to perform a - new query, but it can remember the TTL from the SOA RR in the - negative response to the AAAA query). - - o The RDLENGTH field is set to 16 - - o The RDATA field is set to the IPv6 representation of the IPv4 - address from the RDATA field of the A record. The DNS64 SHOULD - check each A RR against IPv4 address ranges and select the - corresponding IPv6 prefix to use in synthesizing the AAAA RR. See - Section 5.2 for discussion of the algorithms to be used in - - - -Bagnulo, et al. Expires April 22, 2010 [Page 10] - -Internet-Draft DNS64 October 2009 - - - effecting the transformation. - -5.1.5. Querying in parallel - - DNS64 MAY perform the query for the AAAA RR and for the A RR in - parallel, in order to minimize the delay. However, this would result - in performing unnecessary A RR queries in the case no AAAA RR - synthesis is required. A possible trade-off would be to perform them - sequentially but with a very short interval between them, so if we - obtain a fast reply, we avoid doing the additional query. (Note that - this discussion is relevant only if the DNS64 function needs to - perform external queries to fetch the RR. If the needed RR - information is available locally, as in the case of an authoritative - server, the issue is no longer relevant.) - -5.2. Generation of the IPv6 representations of IPv4 addresses - - DNS64 supports multiple algorithms for the generation of the IPv6 - representation of an IPv4 address. The constraints imposed on the - generation algorithms are the following: - - The same algorithm to create an IPv6 address from an IPv4 address - MUST be used by both the DNS64 to create the IPv6 address to be - returned in the synthetic AAAA RR from the IPv4 address contained - in original A RR, and by the IPv6/IPv4 translator to create the - IPv6 address to be included in the destination address field of - the outgoing IPv6 packets from the IPv4 address included in the - destination address field of the incoming IPv4 packet. - - The algorithm MUST be reversible, i.e. it MUST be possible to - extract the original IPv4 address from the IPv6 representation. - - The input for the algorithm MUST be limited to the IPv4 address, - the IPv6 prefix (denoted Pref64::/n) used in the IPv6 - representations and optionally a set of stable parameters that are - configured in the DNS64 (such as fixed string to be used as a - suffix). - - If we note n the length of the prefix Pref64::/n, then n MUST - the less or equal than 96. If a Pref64::/n is configured - through any means in the DNS64 (such as manually configured, or - other automatic mean not specified in this document), the - default algorithm MUST use this prefix. If no prefix is - available, the algorithm MUST use the Well-Known prefix TBD1 - defined in [I-D.thaler-behave-translator-addressing] - - [[anchor12: Note in document: TBD1 in the passage above is to be - substituted by whatever prefix is assigned by IANA to be the well- - - - -Bagnulo, et al. Expires April 22, 2010 [Page 11] - -Internet-Draft DNS64 October 2009 - - - known prefix.]] - - DNS64 MUST support the following algorithms for generating IPv6 - representations of IPv4 addresses defined in - [I-D.thaler-behave-translator-addressing]: - - Zero-Pad And Embed, defined in section 3.2.3 of - [I-D.thaler-behave-translator-addressing] - - Compensation-Pad And Embed, defined in section of 3.2.4 of - [I-D.thaler-behave-translator-addressing] - - Embed And Zero-Pad, defined in section of 3.2.5 of - [I-D.thaler-behave-translator-addressing] - - Preconfigured Mapping Table, defined in section of 3.2.6 of - [I-D.thaler-behave-translator-addressing] - - The default algorithm used by DNS64 must be Embed and Zero-Pad. - While the normative description of the algorithms is provided in - [I-D.thaler-behave-translator-addressing], an sample description of - the algorithm and its application to different scenarios is provided - in Appendix A for illustration purposes. - -5.3. Handling other RRs - -5.3.1. PTR queries - - If a DNS64 nameserver receives a PTR query for a record in the - IP6.ARPA domain, it MUST strip the IP6.ARPA labels from the QNAME, - reverse the address portion of the QNAME according to the encoding - scheme outlined in section 2.5 of [RFC3596] , and examine the - resulting address to see whether its prefix matches the locally- - configured Pref64::/n. There are two alternatives for a DNS64 - nameserver to respond to such PTR queries. A DNS64 node MUST provide - one of these, and SHOULD NOT provide both at the same time unless - different IP6.ARPA zones require answers of different sorts. - - The first option is for the DNS64 nameserver to respond - authoritatively for its prefixes. If the address prefix matches any - Pref64::/n used in the site, either a LIR prefix or a well-known - prefix used for NAT64 as defined in - [I-D.thaler-behave-translator-addressing], then the DNS64 server MAY - answer the query using locally-appropriate RDATA. The DNS64 server - MAY use the same RDATA for all answers. Note that the requirement is - to match any Pref64::/n used at the site, and not merely the locally- - configured Pref64::/n. This is because end clients could ask for a - PTR record matching an address received through a different (site- - - - -Bagnulo, et al. Expires April 22, 2010 [Page 12] - -Internet-Draft DNS64 October 2009 - - - provided) DNS64, and if this strategy is in effect, those queries - should never be sent to the global DNS. The advantage of this - strategy is that it makes plain to the querying client that the - prefix is one operated by the DNS64 site, and that the answers the - client is getting are generated by the DNS64. The disadvantage is - that any useful reverse-tree information that might be in the global - DNS is unavailable to the clients querying the DNS64. - - The second option is for the DNS64 nameserver to synthesize a CNAME - mapping the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA - name. The rest of the response would be the normal DNS processing. - The CNAME can be signed on the fly if need be. The advantage of this - approach is that any useful information in the reverse tree is - available to the querying client. The disadvantage is that it adds - additional load to the DNS64 (because CNAMEs have to be synthesized - for each PTR query that matches the Pref64::/n), and that it may - require signing on the fly. [[anchor15: what are we supposed to do - here when the in-addr.arpa zone is unmaintained, as it may be. If - there is no data at the target name, then we'll get a CNAME with a - map to an empty namespace, I think? Isn't that bad? - --ajs@shinkuro.com]] - - If the address prefix does not match any of the Pref64::/n, then the - DNS64 server MUST process the query as though it were any other query - -- i.e. a recursive nameserver MUST attempt to resolve the query as - though it were any other (non-A/AAAA) query, and an authoritative - server MUST respond authoritatively or with a referral, as - appropriate. - -5.3.2. Handling the additional section - - DNS64 synthesis MUST NOT be performed on any records in the - additional section of synthesized answers. The DNS64 MUST pass the - additional section unchanged. - - [[anchor16: We had some discussion, as an alternative to the above, - of allowing the DNS64 to truncate the additional section completely, - on the grounds that the additional section could break mixed-mode - iterative/forwarding resolvers that happen to end up behind DNS64. - Nobody else seemed to like that plan, so I haven't included it. - --ajs@shinkuro.com]] - -5.3.3. Other records - - If the DNS64 is in recursive resolver mode, then it SHOULD also serve - the zones specified in [I-D.ietf-dnsop-default-local-zones], rather - than forwarding those queries elsewhere to be handled. - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 13] - -Internet-Draft DNS64 October 2009 - - - All other RRs MUST be returned unchanged. - -5.4. Assembling a synthesized response to a AAAA query - - The DNS64 uses different pieces of data to build the response - returned to the querying client. - - The query that is used as the basis for synthesis results either in - an error, an answer that can be used as a basis for synthesis, or an - empty (authoritative) answer. If there is an empty answer, then the - DNS64 responds to the original querying client with the answer the - DNS64 received to the original AAAA query. Otherwise, the response - is assembled as follows. - - The header fields are set according to the usual rules for recursive - or authoritative servers, depending on the role that the DNS64 is - serving. The question section is copied from the original AAAA - query. The answer section is populated according to the rules in - Section 5.1.4. The authority section is copied from the response to - the A query that the DNS64 performed. The additional section is - populated according to the rules in Section 5.3.2. - - [[anchor18: The cross-reference to how to do the additional section - can be removed, and replaced by "copied from the response to the A - query that the DNS64 performed" if we don't want to allow the DNS64 - to truncate the additional section. See the note above. If I hear - no more feedback on this topic, then I'll make this change in the - next version. --ajs@shinkuro.com]] - -5.5. DNSSEC processing: DNS64 in recursive server mode - - We consider the case where the recursive server that is performing - DNS64 also has a local policy to validate the answers according to - the procedures outlined in [RFC4035] Section 5. We call this general - case vDNS64. - - The vDNS64 uses the presence of the DO and CD bits to make some - decisions about what the query originator needs, and can react - accordingly: - - 1. If CD is not set and DO is not set, vDNS64 SHOULD perform - validation and do synthesis as needed. - - 2. If CD is not set and DO is set, then vDNS64 SHOULD perform - validation. Whenever vDNS64 performs validation, it MUST - validate the negative answer for AAAA queries before proceeding - to query for A records for the same name, in order to be sure - that there is not a legitimate AAAA record on the Internet. - - - -Bagnulo, et al. Expires April 22, 2010 [Page 14] - -Internet-Draft DNS64 October 2009 - - - Failing to observe this step would allow an attacker to use DNS64 - as a mechanism to circumvent DNSSEC. If the negative response - validates, and the response to the A query validates, then the - vDNS64 MAY perform synthesis and SHOULD set the AD bit in the - answer to the client. This is acceptable, because [RFC4035], - section 3.2.3 says that the AD bit is set by the name server side - of a security-aware recursive name server if and only if it - considers all the RRSets in the Answer and Authority sections to - be authentic. In this case, the name server has reason to - believe the RRSets are all authentic, so it SHOULD set the AD - bit. If the data does not validate, the vDNS64 MUST respond with - RCODE=2 (server failure). - A security-aware end point might take the presence of the AD bit - as an indication that the data is valid, and may pass the DNS - (and DNSSEC) data to an application. If the application attempts - to validate the synthesized data, of course, the validation will - fail. One could argue therefore that this approach is not - desirable. But security aware stub resolvers MUST NOT place any - reliance on data received from resolvers and validated on their - behalf without certain criteria established by [RFC4035], section - 4.9.3. An application that wants to perform validation on its - own should use the CD bit. - - 3. If the CD bit is set and DO is set, then vDNS64 MAY perform - validation, but MUST NOT perform synthesis. It MUST hand the - data back to the query initiator, just like a regular recursive - resolver, and depend on the client to do the validation and the - synthesis itself. - The disadvantage to this approach is that an end point that is - translation-oblivious but security-aware and validating will not - be able to use the DNS64 functionality. In this case, the end - point will not have the desired benefit of NAT64. In effect, - this strategy means that any end point that wishes to do - validation in a NAT64 context must be upgraded to be translation- - aware as well. - -5.6. DNS64 and multihoming - - Synthetic AAAA records may be constructed on the basis of the network - context in which they were constructed. Therefore, a synthetic AAAA - received from one interface MUST NOT be used to resolve hosts via - another network interface. [[anchor21: This seems to be the result of - the discussion on-list starting with message id 18034D4D7FE9AE48BF19A - B1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com, but it's pretty - strange when stated baldly. In particular, how is the multi-homed - host supposed to know that a given AAAA is synthetic? - --ajs@shinkuro.com]] - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 15] - -Internet-Draft DNS64 October 2009 - - -6. Deployment notes - - While DNS64 is intended to be part of a strategy for aiding IPv6 - deployment in an internetworking environment with some IPv4-only and - IPv6-only networks, it is important to realise that it is - incompatible with some things that may be deployed in an IPv4-only or - dual-stack context. - -6.1. DNS resolvers and DNS64 - - Full-service resolvers that are unaware of the DNS64 function can be - (mis)configured to act as mixed-mode iterative and forwarding - resolvers. In a native-IPv4 context, this sort of configuration may - appear to work. It is impossible to make it work properly without it - being aware of the DNS64 function, because it will likely at some - point obtain IPv4-only glue records and attempt to use them for - resolution. The result that is returned will contain only A records, - and without the ability to perform the DNS64 function the resolver - will simply be unable to answer the necessary AAAA queries. - -6.2. DNSSEC validators and DNS64 - - Existing DNSSEC validators (i.e. that are unaware of DNS64) will - reject all the data that comes from the DNS64 as having been tampered - with. If it is necessary to have validation behind the DNS64, then - the validator must know how to perform the DNS64 function itself. - Alternatively, the validating host may establish a trusted connection - with the DNS64, and allow the DNS64 to do all validation on its - behalf. - - -7. Security Considerations - - See the discussion on the usage of DNSSEC and DNS64 described in the - document. - - -8. Contributors - - Dave Thaler - - Microsoft - - dthaler@windows.microsoft.com - - - - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 16] - -Internet-Draft DNS64 October 2009 - - -9. Acknowledgements - - This draft contains the result of discussions involving many people, - including the participants of the IETF BEHAVE Working Group. The - following IETF participants made specific contributions to parts of - the text, and their help is gratefully acknowledged: Mark Andrews, - Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Marc Blanchet, - Cameron Byrne, Brian Carpenter, Hui Deng, Francis Dupont, Ed - Jankiewicz, Peter Koch, Suresh Krishnan, Ed Lewis, Xing Li, Matthijs - Mekking, Hiroshi Miyata, Simon Perrault, Teemu Savolainen, Jyrki - Soini, Dave Thaler, Mark Townsley, Stig Venaas, Magnus Westerlund, - Florian Weimer, Dan Wing, Xu Xiaohu. - - Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by - Trilogy, a research project supported by the European Commission - under its Seventh Framework Program. - - -10. References - -10.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [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. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - - [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", - RFC 2672, August 1999. - - [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm - (SIIT)", RFC 2765, February 2000. - - [RFC4787] Audet, F. and C. Jennings, "Network Address Translation - (NAT) Behavioral Requirements for Unicast UDP", BCP 127, - RFC 4787, January 2007. - - [I-D.ietf-behave-tcp] - Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. - Srisuresh, "NAT Behavioral Requirements for TCP", - draft-ietf-behave-tcp-08 (work in progress), - - - -Bagnulo, et al. Expires April 22, 2010 [Page 17] - -Internet-Draft DNS64 October 2009 - - - September 2008. - - [I-D.ietf-behave-nat-icmp] - Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT - Behavioral Requirements for ICMP protocol", - draft-ietf-behave-nat-icmp-12 (work in progress), - January 2009. - - [I-D.thaler-behave-translator-addressing] - Thaler, D., "IPv6 Addressing of IPv6/IPv4 Translators", - draft-thaler-behave-translator-addressing-00 (work in - progress), July 2009. - -10.2. Informative References - - [I-D.bagnulo-behave-nat64] - Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network - Address and Protocol Translation from IPv6 Clients to IPv4 - Servers", draft-bagnulo-behave-nat64-03 (work in - progress), March 2009. - - [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address - Translation - Protocol Translation (NAT-PT)", RFC 2766, - February 2000. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security - Considerations for IP Fragment Filtering", RFC 1858, - October 1995. - - [RFC3128] Miller, I., "Protection Against a Variant of the Tiny - Fragment Attack (RFC 1858)", RFC 3128, June 2001. - - [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network - Address Translator (Traditional NAT)", RFC 3022, - January 2001. - - [RFC3484] Draves, R., "Default Address Selection for Internet - Protocol version 6 (IPv6)", RFC 3484, February 2003. - - [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, - "DNS Extensions to Support IP Version 6", RFC 3596, - October 2003. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - - - -Bagnulo, et al. Expires April 22, 2010 [Page 18] - -Internet-Draft DNS64 October 2009 - - - 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. - - [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network - Address Translator - Protocol Translator (NAT-PT) to - Historic Status", RFC 4966, July 2007. - - [I-D.iana-rfc3330bis] - Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", - draft-iana-rfc3330bis-06 (work in progress), - February 2009. - - [I-D.ietf-mmusic-ice] - Rosenberg, J., "Interactive Connectivity Establishment - (ICE): A Protocol for Network Address Translator (NAT) - Traversal for Offer/Answer Protocols", - draft-ietf-mmusic-ice-19 (work in progress), October 2007. - - [I-D.ietf-6man-addr-select-sol] - Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, - "Solution approaches for address-selection problems", - draft-ietf-6man-addr-select-sol-01 (work in progress), - June 2008. - - [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of - Managed Objects for Synchronous Optical Network (SONET) - Linear Automatic Protection Switching (APS) - Architectures", RFC 3498, March 2003. - - [I-D.wing-behave-learn-prefix] - Wing, D., Wang, X., and X. Xu, "Learning the IPv6 Prefix - of an IPv6/IPv4 Translator", - draft-wing-behave-learn-prefix-02 (work in progress), - May 2009. - - [I-D.miyata-behave-prefix64] - Miyata, H. and M. Bagnulo, "PREFIX64 Comparison", - draft-miyata-behave-prefix64-02 (work in progress), - March 2009. - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 19] - -Internet-Draft DNS64 October 2009 - - - [I-D.venaas-behave-mcast46] - Venaas, S., "An IPv4 - IPv6 multicast translator", - draft-venaas-behave-mcast46-00 (work in progress), - December 2008. - - [I-D.ietf-dnsop-default-local-zones] - Andrews, M., "Locally-served DNS Zones", - draft-ietf-dnsop-default-local-zones-08 (work in - progress), February 2009. - - -Appendix A. Deployment scenarios and examples - - In this section, we first provide a description of the default - address transformation algorithm and then we walk through some sample - scenarios that are expected to be common deployment cases. It should - be noted that is provided for illustrative purposes and this section - is not normative. The normative definition of DNS64 is provided in - Section 5 and the normative definition of the address transformation - algorithm is provided in [I-D.thaler-behave-translator-addressing]. - - There are two main different setups where DNS64 is expected to be - used (other setups are possible as well, but these two are the main - ones identified at the time of this writing). - - One possible setup that is expected to be common is the case of an - end site or an ISP that is providing IPv6-only connectivity or - connectivity to IPv6-only hosts that wants to allow the - communication from these IPv6-only connected hosts to the IPv4 - Internet. This case is called An-IPv6-network-to-IPv4-Internet. - In this case, the IPv6/IPv4 Translator is used to connect the end - site or the ISP to the IPv4 Internet and the DNS64 function is - provided by the end site or the ISP. - - The other possible setup that is expected is an IPv4 site that - wants that its IPv4 servers to be reachable from the IPv6 - Internet. This case is called IPv6-Internet-to-an-IPv4-network. - It should be noted that the IPv4 addresses used in the IPv4 site - can be either public or private. In this case, the IPv6/IPv4 - Translator is used to connect the IPv4 end site to the IPv6 - Internet and the DNS64 function is provided by the end site - itself. - - In this section we illustrate how the DNS64 behaves in the different - scenarios that are expected to be common. We consider then 3 - possible scenarios, namely: - - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 20] - -Internet-Draft DNS64 October 2009 - - - 1. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server - mode - - 2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub- - resolver mode - - 3. IPv6-Internet-to-an-IPv4-network setup with DNS64 in DNS server - mode - - The notation used is the following: upper case letters are IPv4 - addresses; upper case letters with a prime(') are IPv6 addresses; - lower case letters are ports; prefixes are indicated by "P::X", which - is an IPv6 address built from an IPv4 address X by adding the prefix - P, mappings are indicated as "(X,x) <--> (Y',y)". - -A.1. Embed and Zero-Pad algorithm description - - In this section we describe the default algorithm for the generation - of IPv6 address from IPv4 address to be implemented in the DNS64. - - The only parameter required by the default algorithm is an IPv6 - prefix. This prefix is used to map IPv4 addresses into IPv6 - addresses, and is denoted Pref64. If we note n the length of the - prefix Pref64, then n must the less or equal than 96. If an Pref64 - is configured through any means in the DNS64 (such as manually - configured, or other automatic mean not specified in this document), - the default algorithm must use this prefix. If no prefix is - available the algorithm must use the Well-Know prefix (include here - the prefix to be assigned by IANA) defined in - [I-D.thaler-behave-translator-addressing] - - The input for the algorithm are: - - The IPv4 address: X - - The IPv6 prefix: Pref64::/n - - The IPv6 address is generated by concatenating the prefix Pref64::/n, - the IPv4 address X and optionally (in case n is strictly smaller than - 96) an all-zero suffix. So, the resulting IPv6 address would be - Pref64:X:: - - Reverse algorithm - - We next describe the reverse algorithm of the algorithm described in - the previous section. This algorithm allows to generate and IPv4 - address from an IPv6 address. This reverse algorithm is NOT - implemented by the DNS64 but it is implemented in the IPv6/IPv4 - - - -Bagnulo, et al. Expires April 22, 2010 [Page 21] - -Internet-Draft DNS64 October 2009 - - - translator that is serving the same domain the DNS64. - - The only parameter required by the default algorithm is an IPv6 - prefix. This prefix is the one originally used to map IPv4 addresses - into IPv6 addresses, and is denoted Pref64. - - The input for the algorithm are: - - The IPv6 address: X' - - The IPv6 prefix: Pref64::/n - - First, the algorithm checks that the fist n bits of the IPv6 address - X' match with the prefix Pref64::/n i.e. verifies that Pref64::/n = - X'/n. - - If this is not the case, the algorithm ends and no IPv4 address is - generated. - - If the verification is successful, then the bits between the n+1 - and the n+32 of the IPv6 address X' are extracted to form the IPv4 - address. - -A.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server - mode - - In this example, we consider an IPv6 node located in an IPv6-only - site that initiates a communication to an IPv4 node located in the - IPv4 Internet. - - The scenario for this case is depicted in the following figure: - - - +---------------------------------------+ +-----------+ - |IPv6 site +-------------+ |IP Addr: | | - | +----+ | Name server | +-------+ T | IPv4 | - | | H1 | | with DNS64 | |64Trans|------| Internet | - | +----+ +-------------+ +-------+ +-----------+ - | |IP addr: Y' | | | |IP addr: X - | --------------------------------- | +----+ - +---------------------------------------+ | H2 | - +----+ - - The figure shows an IPv6 node H1 which has an IPv6 address Y' and an - IPv4 node H2 with IPv4 address X. - - A IPv6/IPv4 Translator connects the IPv6 network to the IPv4 - Internet. This IPv6/IPv4 Translator has a prefix (called Pref64::/n) - - - -Bagnulo, et al. Expires April 22, 2010 [Page 22] - -Internet-Draft DNS64 October 2009 - - - an IPv4 address T assigned to its IPv4 interface. - - The other element involved is the local name server. The name server - is a dual-stack node, so that H1 can contact it via IPv6, while it - can contact IPv4-only name servers via IPv4. - - The local name server needs to know the prefix assigned to the local - IPv6/IPv4 Translator (Pref64::/n). For the purpose of this example, - we assume it learns this through manual configuration. - - For this example, assume the typical DNS situation where IPv6 hosts - have only stub resolvers, and always query a name server that - performs recursive lookups (henceforth called "the recursive - nameserver"). - - The steps by which H1 establishes communication with H2 are: - - 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS - query for an AAAA record for H2 to the recursive name server. - The recursive name server implements DNS64 functionality. - - 2. The recursive name server resolves the query, and discovers that - there are no AAAA records for H2. - - 3. The recursive name server queries for an A record for H2 and gets - back an A record containing the IPv4 address X. The name server - then synthesizes an AAAA record. The IPv6 address in the AAAA - record contains the prefix assigned to the IPv6/IPv4 Translator - in the upper n bits then the IPv4 address X and then an all-zero - padding i.e. the resulting IPv6 address is Pref64:X:: - - 4. H1 receives the synthetic AAAA record and sends a packet towards - H2. The packet is sent from a source transport address of (Y',y) - to a destination transport address of (Pref64:X::,x), where y and - x are ports chosen by H2. - - 5. The packet is routed to the IPv6 interface of the IPv6/IPv4 - Translator and the subsequent communication flows by means of the - IPv6/IPv4 Translator mechanisms. - -A.3. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-resolver - mode - - The scenario for this case is depicted in the following figure: - - - - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 23] - -Internet-Draft DNS64 October 2009 - - - +---------------------------------------+ +-----------+ - |IPv6 site +-------+ |IP addr: | | - | +---------------+ | Name | +-------+ T | IPv4 | - | | H1 with DNS64 | | Server| |64Trans|------| Internet | - | +---------------+ +-------+ +-------+ +-----------+ - | |IP addr: Y' | | | |IP addr: X - | --------------------------------- | +----+ - +---------------------------------------+ | H2 | - +----+ - - The figure shows an IPv6 node H1 which has an IPv6 address Y' and an - IPv4 node H2 with IPv4 address X. Node H1 is implementing the DNS64 - function. - - A IPv6/IPv4 Translator connects the IPv6 network to the IPv4 - Internet. This IPv6/IPv4 Translator has a prefix (called Pref64::/n) - and an IPv4 address T assigned to its IPv4 interface. - - H1 needs to know the prefix assigned to the local IPv6/IPv4 - Translator (Pref64::/n). For the purpose of this example, we assume - it learns this through manual configuration. - - Also shown is a name server. For the purpose of this example, we - assume that the name server is a dual-stack node, so that H1 can - contact it via IPv6, while it can contact IPv4-only name servers via - IPv4. - - For this example, assume the typical situation where IPv6 hosts have - only stub resolvers and always query a name server that provides - recursive lookups (henceforth called "the recursive name server"). - The recursive name server does not perform the DNS64 function. - - The steps by which H1 establishes communication with H2 are: - - 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS - query for a AAAA record for H2 to the recursive name server. - - 2. The recursive DNS server resolves the query, and returns the - answer to H1. Because there are no AAAA records in the global - DNS for H2, the answer is empty. - - 3. The stub resolver at H1 then queries for an A record for H2 and - gets back an A record containing the IPv4 address X. The DNS64 - function within H1 then synthesizes a AAAA record. The IPv6 - address in the AAAA record contains the prefix assigned to the - IPv6/IPv4 Translator in the upper n bits, then the IPv4 address X - and then an all-zero padding i.e. the resulting IPv6 address is - Pref64:X::. - - - -Bagnulo, et al. Expires April 22, 2010 [Page 24] - -Internet-Draft DNS64 October 2009 - - - 4. H1 sends a packet towards H2. The packet is sent from a source - transport address of (Y',y) to a destination transport address of - (Pref64:X::,x), where y and x are ports chosen by H2. - - 5. The packet is routed to the IPv6 interface of the IPv6/IPv4 - Translator and the subsequent communication flows using the IPv6/ - IPv4 Translator mechanisms. - -A.4. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server mode - - In this example, we consider an IPv6 node located in the IPv6 - Internet site that initiates a communication to a IPv4 node located - in the IPv4 site. - - This scenario can be addressed without using any form of DNS64 - function. This is so because it is possible to assign a fixed IPv6 - address to each of the IPv4 servers. Such an IPv6 address would be - constructed as the Pref64::/n concatenated with the IPv4 address of - the IPv4 server and an all-zero padding. Note that the IPv4 address - can be a public or a private address; the latter does not present any - additional difficulty, since the LIR prefix must be used a Pref64 (in - this scenario the usage of the WK prefix is not supported). Once - these IPv6 addresses have been assigned to represent the IPv4 servers - in the IPv6 Internet, real AAAA RRs containing these addresses can be - published in the DNS under the site's domain. This is the - recommended approach to handle this scenario, because it does not - involve synthesizing AAAA records at the time of query. Such a - configuration is easier to troubleshoot in the event of problems, - because it always provides the same answer to every query. - - However, there are some more dynamic scenarios, where synthesizing - AAAA RRs in this setup may be needed. In particular, when DNS Update - [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4 - servers, there are two options: One option is to modify the server - that receives the dynamic DNS updates. That would normally be the - authoritative server for the zone. So the authoritative zone would - have normal AAAA RRs that are synthesized as dynamic updates occur. - The other option is modify the authoritative server to generate - synthetic AAAA records for a zone, possibly based on additional - constraints, upon the receipt of a DNS query for the AAAA RR. The - first option -- in which the AAAA is synthesized when the DNS update - message is received, and the data published in the relevant zone -- - is recommended over the second option (i.e. the synthesis upon - receipt of the AAAA DNS query). This is because it is usually easier - to solve problems of misconfiguration and so on when the DNS - responses are not being generated dynamically. For completeness, the - DNS64 behavior that we describe in this section covers the case of - synthesizing the AAAA RR when the DNS query arrives. Nevertheless, - - - -Bagnulo, et al. Expires April 22, 2010 [Page 25] - -Internet-Draft DNS64 October 2009 - - - such a configuration is NOT RECOMMENDED. Troubleshooting - configurations that change the data depending on the query they - receive is notoriously hard, and the IPv4/IPv6 translation scenario - is complicated enough without adding additional opportunities for - possible malfunction. - - The scenario for this case is depicted in the following figure: - - - +-----------+ +----------------------------------------+ - | | | IPv4 site +-------------+ | - | IPv6 | +-------+ +----+ | Name server | | - | Internet |------|64Trans| | H2 | | with DNS64 | | - +-----------+ +-------+ +----+ +-------------+ | - |IP addr: Y' | | |IP addr: X | | - +----+ | ----------------------------------- | - | H1 | +----------------------------------------+ - +----+ - - The figure shows an IPv6 node H1 which has an IPv6 address Y' and an - IPv4 node H2 with IPv4 address X. - - A IPv6/IPv4 Translator connects the IPv4 network to the IPv6 - Internet. This IPv6/IPv4 Translator has a prefix (called - Pref64::/n). - - Also shown is the authoritative name server for the local domain with - DNS64 functionality. For the purpose of this example, we assume that - the name server is a dual-stack node, so that H1 or a recursive - resolver acting on the request of H1 can contact it via IPv6, while - it can be contacted by IPv4-only nodes to receive dynamic DNS updates - via IPv4. - - The local name server needs to know the prefix assigned to the local - IPv6/IPv4 Translator (Pref64::/n). For the purpose of this example, - we assume it learns this through manual configuration. - - The steps by which H1 establishes communication with H2 are: - - 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS - query for an AAAA record for H2. The query is eventually - forwarded to the server in the IPv4 site. - - 2. The local DNS server resolves the query (locally), and discovers - that there are no AAAA records for H2. - - 3. The name server verifies that FQDN(H2) and its A RR are among - those that the local policy defines as allowed to generate a AAAA - - - -Bagnulo, et al. Expires April 22, 2010 [Page 26] - -Internet-Draft DNS64 October 2009 - - - RR from. If that is the case, the name server synthesizes an - AAAA record from the A RR and the relevant Pref64::/n. The IPv6 - address in the AAAA record contains the prefix assigned to the - IPv6/IPv4 Translator in the first n bits and the IPv4 address X - and then an all-zero padding. - - 4. H1 receives the synthetic AAAA record and sends a packet towards - H2. The packet is sent from a source transport address of (Y',y) - to a destination transport address of (Pref64:X::,x), where y and - x are ports chosen by H2. - - 5. The packet is routed through the IPv6 Internet to the IPv6 - interface of the IPv6/IPv4 Translator and the communication flows - using the IPv6/IPv4 Translator mechanisms. - - -Appendix B. Motivations and Implications of synthesizing AAAA RR when - real AAAA RR exists - - The motivation for synthesizing AAAA RR when a real AAAA RR exists is - to support the following scenario: - - An IPv4-only server application (e.g. web server software) is - running on a dual-stack host. There may also be dual-stack server - applications also running on the same host. That host has fully - routable IPv4 and IPv6 addresses and hence the authoritative DNS - server has an A and a AAAA record as a result. - - An IPv6-only client (regardless of whether the client application - is IPv6-only, the client stack is IPv6-only, or it only has an - IPv6 address) wants to access the above server. - - The client issues a DNS query to a DNS64 recursor. - - If the DNS64 only generates a synthetic AAAA if there's no real AAAA, - then the communication will fail. Even though there's a real AAAA, - the only way for communication to succeed is with the translated - address. So, in order to support this scenario, the administrator of - a DNS64 service may want to enable the synthesis of AAAA RR even when - real AAAA RR exist. - - The implication of including synthetic AAAA RR when real AAAA RR - exist is that translated connectivity may be preferred over native - connectivity in some cases where the DNS64 is operated in DNS server - mode. - - RFC3484 [RFC3484] rules use longest prefix match to select which is - the preferred destination address to use. So, if the DNS64 recursor - - - -Bagnulo, et al. Expires April 22, 2010 [Page 27] - -Internet-Draft DNS64 October 2009 - - - returns both the synthetic AAAA RR and the real AAAA RR, then if the - DNS64 is operated by the same domain as the initiating host, and a - global unicast prefix (called the LIR prefix as defined in - [I-D.thaler-behave-translator-addressing]) is used, then the - synthetic AAAA RR is likely to be preferred. - - This means that without further configuration: - - In the case of An IPv6 network to the IPv4 internet, the host will - prefer translated connectivity if LIR prefix is used. If the - Well-Known (WK) prefix defined in - [I-D.thaler-behave-translator-addressing] is used, it will - probably prefer native connectivity. - - In the case of the IPv6 Internet to an IPv4 network, it is - possible to bias the selection towards the real AAAA RR if the - DNS64 recursor returns the real AAAA first in the DNS reply, when - the LIR prefix is used (the WK prefix usage is not recommended in - this case) - - In the case of the IPv6 to IPv4 in the same network, for local - destinations (i.e., target hosts inside the local site), it is - likely that the LIR prefix and the destination prefix are the - same, so we can use the order of RR in the DNS reply to bias the - selection through native connectivity. If a WK prefix is used, - the longest prefix match rule will select native connectivity. - - So this option introduces problems in the following cases: - - An IPv6 network to the IPv4 internet with the LIR prefix - - IPv6 to IPv4 in the same network when reaching external - destinations and the LIR prefix is used. - - In any case, the problem can be solved by properly configuring the - RFC3484 [RFC3484] policy table, but this requires effort on the part - of the site operator. - - - - - - - - - - - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 28] - -Internet-Draft DNS64 October 2009 - - -Authors' Addresses - - Marcelo Bagnulo - UC3M - Av. Universidad 30 - Leganes, Madrid 28911 - Spain - - Phone: +34-91-6249500 - Fax: - Email: marcelo@it.uc3m.es - URI: http://www.it.uc3m.es/marcelo - - - Andrew Sullivan - Shinkuro - 4922 Fairmont Avenue, Suite 250 - Bethesda, MD 20814 - USA - - Phone: +1 301 961 3131 - Email: ajs@shinkuro.com - - - Philip Matthews - Unaffiliated - 600 March Road - Ottawa, Ontario - Canada - - Phone: +1 613-592-4343 x224 - Fax: - Email: philip_matthews@magma.ca - URI: - - - Iljitsch van Beijnum - IMDEA Networks - Av. Universidad 30 - Leganes, Madrid 28911 - Spain - - Phone: +34-91-6246245 - Email: iljitsch@muada.com - - - - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 29] - diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt deleted file mode 100644 index b0a269b1113..00000000000 --- a/doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt +++ /dev/null @@ -1,1579 +0,0 @@ - - - - - -DNS Extensions Working Group Edward Lewis -Internet-Draft NeuStar, Inc. -Updates: 1034, 1035 (if approved) A. Hoenes -Intended status: Standards Track TR-Sys -Expires: June 6, 2010 December 6, 2009 - - - DNS Zone Transfer Protocol (AXFR) - draft-ietf-dnsext-axfr-clarify-12 - -Abstract - - The Domain Name System standard mechanisms for maintaining coherent - servers for a zone consist of three elements. One mechanism is the - Authoritative Transfer (AXFR) defined in RFC 1034 and RFC 1035. - The definition of AXFR has proven insufficient in detail, thereby - forcing implementations intended to be compliant to make assumptions, - impeding interoperability. Yet today we have a satisfactory set of - implementations that do interoperate. This document is a new - definition of AXFR -- new in the sense that is it recording an - accurate definition of an interoperable AXFR mechanism. - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. 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. - - 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/1id-abstracts.html - - - -Lewis & Hoenes Expires June 6, 2010 [Page 1] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - This Internet-Draft will expire on June 6, 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lewis & Hoenes Expires June 6, 2010 [Page 2] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 - 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3. Context . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.4. Coverage and Relationship to Original AXFR Specification . 5 - 2. AXFR Messages . . . . . . . . . . . . . . . . . . . . . . . 7 - 2.1. AXFR query . . . . . . . . . . . . . . . . . . . . . . . . 8 - 2.1.1. Header Values . . . . . . . . . . . . . . . . . . . . . 9 - 2.1.2. Question Section . . . . . . . . . . . . . . . . . . . . 10 - 2.1.3. Answer Section . . . . . . . . . . . . . . . . . . . . . 10 - 2.1.4. Authority Section . . . . . . . . . . . . . . . . . . . 10 - 2.1.5. Additional Section . . . . . . . . . . . . . . . . . . . 10 - 2.2. AXFR Response . . . . . . . . . . . . . . . . . . . . . . 11 - 2.2.1. "0 Message" Response . . . . . . . . . . . . . . . . . . 11 - 2.2.2. Header Values . . . . . . . . . . . . . . . . . . . . . 12 - 2.2.3. Question Section . . . . . . . . . . . . . . . . . . . . 14 - 2.2.4. Answer Section . . . . . . . . . . . . . . . . . . . . . 14 - 2.2.5. Authority Section . . . . . . . . . . . . . . . . . . . 14 - 2.2.6. Additional Section . . . . . . . . . . . . . . . . . . . 14 - 2.3. TCP Connection Aborts . . . . . . . . . . . . . . . . . . 14 - 3. Zone Contents . . . . . . . . . . . . . . . . . . . . . . . 15 - 3.1. Records to Include . . . . . . . . . . . . . . . . . . . . 15 - 3.2. Delegation Records . . . . . . . . . . . . . . . . . . . . 16 - 3.3. Glue Records . . . . . . . . . . . . . . . . . . . . . . . 18 - 3.4. Name Compression . . . . . . . . . . . . . . . . . . . . . 18 - 3.5. Occluded Names . . . . . . . . . . . . . . . . . . . . . . 19 - 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 4.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 4.1.1. AXFR client TCP . . . . . . . . . . . . . . . . . . . . 20 - 4.1.2. AXFR server TCP . . . . . . . . . . . . . . . . . . . . 21 - 4.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . 22 - 6. Zone Integrity . . . . . . . . . . . . . . . . . . . . . . . 23 - 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . 24 - 7.1. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 7.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 8. Security Considerations . . . . . . . . . . . . . . . . . . 25 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 - 10. Internationalization Considerations . . . . . . . . . . . . 25 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . 25 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 - 12.2. Informative References . . . . . . . . . . . . . . . . . 27 - 13. Editor's Address . . . . . . . . . . . . . . . . . . . . . 28 - - - - - -Lewis & Hoenes Expires June 6, 2010 [Page 3] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - -1. Introduction - - The Domain Name System standard facilities for maintaining coherent - servers for a zone consist of three elements. Authoritative Transfer - (AXFR) is defined in "Domain Names - Concepts and Facilities" - [RFC1034] (referred to in this document as RFC 1034) and "Domain - Names - Implementation and Specification" [RFC1035] (henceforth - RFC 1035). Incremental Zone Transfer (IXFR) is defined in - "Incremental Zone Transfer in DNS" [RFC1995]. A mechanism for prompt - notification of zone changes (NOTIFY) is defined in "A Mechanism for - Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The - goal of these mechanisms is to enable a set of DNS name servers to - remain coherently authoritative for a given zone. - - This document re-specifies the AXFR mechanism as it is deployed in - the Internet at large, hopefully with the precision expected from - modern Internet Standards, and thereby updates RFC 1034 and RFC 1035. - -1.1. Definition of Terms - - 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 "Key words for use in - RFCs to Indicate Requirement Levels" [BCP14]. - - Use of "newer"/"new" and "older"/"old" DNS refers to implementations - written after and prior to the publication of this document. - - "General purpose DNS implementation" refers to DNS software developed - for wide-spread use. This includes resolvers and servers freely - accessible as libraries and standalone processes. This also includes - proprietary implementations used only in support of DNS service - offerings. - - "Turnkey DNS implementation" refers to custom made, single use - implementations of DNS. Such implementations consist of software - that employs the DNS protocol message format yet does not conform to - the entire range of DNS functionality. - - The terms "AXFR session", "AXFR server" and "AXFR client" will be - introduced in the first paragraph of Section 2, after some more - context has been established. - -1.2. Scope - - In general terms, authoritative name servers for a given zone can use - various means to achieve coherency of the zone contents they serve. - For example, there are DNS implementations that assemble answers from - data stored in relational databases (as opposed to master files), - - -Lewis & Hoenes Expires June 6, 2010 [Page 4] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - - relying on the database's non-DNS means to synchronize the database - instances. Some of these non-DNS solutions interoperate in some - fashion. However, AXFR, IXFR, and NOTIFY are the only protocol- - defined in-band mechanisms to provide coherence of a set of name - servers, and they are the only mechanisms specified by the IETF. - - This document does not cover incoherent DNS situations. There are - applications of the DNS in which servers for a zone are designed to - be incoherent. For these configurations, a coherency mechanism as - described here would be unsuitable. - - A DNS implementation is not required to support AXFR, IXFR, and - NOTIFY, but it should have some means for maintaining name server - coherency. A general purpose DNS implementation will likely support - AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS - implementations may exist without AXFR. - -1.3. Context - - Besides describing the mechanisms themselves, there is the context in - which they operate to consider. In the initial specifications of - AXFR (and IXFR and NOTIFY), little consideration was given to - security and privacy issues. Since the original definition of AXFR, - new opinions have appeared on the access to an entire zone's - contents. In this document, the basic mechanisms will be discussed - separately from the permission to use these mechanisms. - -1.4. Coverage and Relationship to Original AXFR Specification - - This document concentrates on just the definition of AXFR. Any - effort to update the specification of the IXFR or NOTIFY mechanisms - is left to different documents. - - The original "specification" of the AXFR sub-protocol is scattered - through RFC 1034 and RFC 1035. Section 2.2 of RFC 1035 (on page 5) - depicts the scenario for which AXFR has been designed. Section 4.3.5 - of RFC 1034 describes the zone synchronization strategies in general - and rules for the invocation of a full zone transfer via AXFR; the - fifth paragraph of that section contains a very short sketch of the - AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant - flaw in that specification. Section 3.2.3 of RFC 1035 has assigned - the code point for the AXFR QTYPE (see Section 2.1.2 below for more - details). Section 4.2 of RFC 1035 discusses the transport layer use - of DNS and shortly explains why UDP transport is deemed inappropriate - for AXFR; the last paragraph of Section 4.2.2 gives details for the - TCP connection management with AXFR. Finally, the second paragraph - of Section 6.3 in RFC 1035 mandates server behavior when zone data - changes occur during an ongoing zone transfer using AXFR. - - - -Lewis & Hoenes Expires June 6, 2010 [Page 5] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - - This document will update the specification of AXFR. To this end, it - fully specifies the record formats and processing rules for AXFR, - largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and it - details the transport considerations for AXFR, thus amending Section - 4.2.2 of RFC 1035. Furthermore, it discusses backward compatibility - issues and provides policy/management considerations as well as - specific Security Considerations for AXFR. The goal of this document - is to define AXFR as it exists, or is supposed to exist, currently. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lewis & Hoenes Expires June 6, 2010 [Page 6] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - -2. AXFR Messages - - An AXFR session consists of an AXFR query message and the sequence of - AXFR response messages returned for it. In this document, the AXFR - client is the sender of the AXFR query and the AXFR server is the - responder. (Use of terms such as master, slave, primary, secondary - are not important to defining AXFR.) The use of the word "session" - without qualification refers to an AXFR session. - - An important aspect to keep in mind is that the definition of AXFR is - restricted to TCP [RFC0793]. The design of the AXFR process has - certain inherent features that are not easily ported to UDP - [RFC0768]. - - The basic format of an AXFR message is the DNS message as defined in - Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the - following documents. - - o The 'Basic' DNS specification: - - - "A Mechanism for Prompt Notification of Zone Changes (DNS Notify)" - [RFC1996] - - "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136] - - "Clarifications to the DNS Specification" [RFC2181] - - "Extension Mechanisms for DNS (EDNS0)" [RFC2671] - - "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845] - - "Secret Key Establishment for DNS (TKEY RR)" [RFC2930] - - "Obsoleting IQUERY" [RFC3425] - - "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597] - - "HMAC SHA TSIG Algorithm Identifiers" [RFC4635] - - "Domain Name System (DNS) IANA Considerations" [RFC5395] - - o Further additions related to the DNS Security Extensions (DNSSEC), - defined in these base documents: - - - "DNS Security Introduction and Requirements" [RFC4033] - - "Resource Records for the DNS Security Extensions" [RFC4034] - - "Protocol Modifications for the DNS Security Extensions" [RFC4035] - - "Use of SHA-256 in DNSSEC Delegation Signer RRs" [RFC4509] - - "DNS Security Hashed Authenticated Denial of Existence" [RFC5155] - - "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource - Records for DNSSEC" [RFC5702] - - "Clarifications and Implementation Notes for DNSSECbis" [DNSSEC-U] - - These documents contain information about the syntax and semantics of - DNS messages. They ought not interfere with AXFR but are also - helpful in understanding what will be carried via AXFR. - - - - -Lewis & Hoenes Expires June 6, 2010 [Page 7] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - - For convenience, the synopsis of the DNS message header from - [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is - reproduced here informally: - - 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ID | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | QDCOUNT/ZOCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ANCOUNT/PRCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | NSCOUNT/UPCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ARCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - This document makes use of the field names as they appear in this - diagram. The names of sections in the body of DNS messages are - capitalized in this document for clarity, e.g., "Additional section". - - The DNS message size limit from [RFC1035] for DNS over UDP (and its - extension via the EDNS0 mechanism specified in [RFC2671]) is not - relevant for AXFR, as explained in Section 4. The upper limit on the - permissible size of a DNS message over TCP is only restricted by the - TCP framing defined in Section 4.2.2 of RFC 1035, which specifies a - two-octet message length field, understood to be unsigned, and thus - causing a limit of 65535 octets. This limit is not changed by EDNS0. - - Note that the TC (truncation) bit is never set by an AXFR server nor - considered/read by an AXFR client. - -2.1. AXFR query - - An AXFR query is sent by a client whenever there is a reason to ask. - This might be because of scheduled or triggered zone maintenance - activities (see Section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996], - respectively) or as a result of a command line request, say for - debugging. - - - - - - - - - - -Lewis & Hoenes Expires June 6, 2010 [Page 8] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - -2.1.1. Header Values - - These are the DNS message header values for an AXFR query. - - ID Selected by client; see Note a) - - QR MUST be 0 (Query) - - OPCODE MUST be 0 (Standard Query) - - Flags: - AA 'n/a' -- see Note b) - TC 'n/a' -- see Note b) - RD 'n/a' -- see Note b) - RA 'n/a' -- see Note b) - Z 'mbz' -- see Note c) - AD 'n/a' -- see Note b) - CD 'n/a' -- see Note b) - - RCODE MUST be 0 (No error) - - QDCOUNT Number of entries in Question section; MUST be 1 - - ANCOUNT Number of entries in Answer section; MUST be 0 - - NSCOUNT Number of entries in Authority section; MUST be 0 - - ARCOUNT Number of entries in Additional section -- see Note d) - - Notes: - - a) Set to any value that the client is not already using with the - same server. There is no specific means for selecting the value - in this field. (Recall that AXFR is done only via TCP connections - -- see Section 4 "Transport".) - - A server MUST reply using messages that use the same message ID to - allow a client to have multiple queries outstanding concurrently - over the same TCP connection -- see Note a) in Section 2.2.2 for - more details. - - b) 'n/a' -- The value in this field has no meaning in the context of - AXFR query messages. For the client, it is RECOMMENDED that the - value be zero. The server MUST ignore this value. - - c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore - it. - - - - -Lewis & Hoenes Expires June 6, 2010 [Page 9] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - - d) The client MUST set this field to the number of resource records - appearing in the Additional section. See Section 2.1.5 - "Additional Section" for details. - - The value MAY be 0, 1 or 2. If it is 2, the Additional section - MUST contain both an EDNS0 [RFC2671] OPT resource record and a - record carrying transaction integrity and authentication data, - currently a choice of TSIG [RFC2845] and SIG(0) [RFC2931]. If the - value is 1, then the Additional section MUST contain either only - an EDNS0 OPT resource record or a record carrying transaction - integrity and authentication data. If the value is 0, the - Additional section MUST be empty. - -2.1.2. Question Section - - The Query section of the AXFR query MUST conform to Section 4.1.2 of - RFC 1035, and contain a single resource record with the following - values: - - QNAME the name of the zone requested - - QTYPE AXFR (= 252), the pseudo-RR type for zone transfer - [DNSVALS] - - QCLASS the class of the zone requested [DNSVALS] - -2.1.3. Answer Section - - The Answer section MUST be empty. - -2.1.4. Authority Section - - The Authority section MUST be empty. - -2.1.5. Additional Section - - The client MAY include an EDNS0 OPT [RFC2671] resource record. If - the server does not support EDNS0, the client MUST send this section - without an EDNS0 OPT resource record if there is a retry. However, - the protocol does not define an explicit indication that the server - does not support EDNS0; that needs to be inferred by the client. - Often, the server will return a FormErr(1) which might be related to - the OPT resource record. - - The client MAY include a transaction integrity and authentication - resource record, currently a choice of TSIG [RFC2845] or SIG(0) - [RFC2931]. If the server has indicated that it does not recognize - the resource record, and that the error is indeed caused by the - resource record, the client probably should not try again. Removing - - -Lewis & Hoenes Expires June 6, 2010 [Page 10] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - - the security data in the face of an obstacle ought to only be done - with full awareness of the implication of doing so. - - In general, if an AXFR client is aware that an AXFR server does not - support a particular mechanism, the client SHOULD NOT attempt to - engage the server using the mechanism (or at all). A client could - become aware of a server's abilities via a configuration setting or - via some other (as yet) undefined means. - - The range of permissible resource records that MAY appear in the - Additional section might change over time. If either a change to an - existing resource record (like the OPT RR for EDNS0) is made or a new - Additional section record is created, the new definitions ought to - include a discussion on the impact upon AXFR. Future resource - records residing in the Additional section might have an effect that - is orthogonal to AXFR, so can ride through the session as opaque - data. In this case, a "wise" implementation ought to be able to pass - these records through without disruption. - -2.2. AXFR Response - - The AXFR response will consist of 0 or more messages. A "0 message" - response is covered in Section 2.2.1. - - An AXFR response that is transferring the zone's contents will - consist of a series (which could be a series of length 1) of DNS - messages. In such a series, the first message MUST begin with the - SOA resource record of the zone, the last message MUST conclude with - the same SOA resource record. Intermediate messages MUST NOT contain - the SOA resource record. The AXFR server MUST copy the Question - section from the corresponding AXFR query message in to the first - response message's Question section. Subsequent messages MAY do the - same or contain an empty Question section. - - An AXFR response indicates an error via a single DNS message with the - return code set to the appropriate value for the condition - encountered, sent once the error condition is detected. Such a - message terminates the AXFR session; it MUST copy the Query Section - from the AXFR query into its Query Section, but the inclusion of the - terminating SOA resource record is not necessary. - - An AXFR server may send a number of AXFR response messages free of an - error condition before it sends the message indicating an error. - -2.2.1. "0 Message" Response - - A legitimate "0 message" response, i.e., the client sees no response - whatsoever, is very exceptional and controversial. Unquestionably it - is unhealthy for there to be 0 responses in a protocol that is - - -Lewis & Hoenes Expires June 6, 2010 [Page 11] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - - designed around a query - response paradigm over an unreliable - transport. The lack of a response could be a sign of underlying - network problems and cause the protocol state machine to react - accordingly. However, AXFR uses TCP and not UDP, eliminating - undetectable network errors. - - A "0 message response" is reserved for situations in which the server - has a reason to suspect that the query is sent for the purpose of - abuse. Due to the use of this being so controversial, a "0 message - response" is not being defined as a legitimate part of the protocol - but the use of it is being acknowledged as a warning to AXFR client - implementations. Any earnest query has the expectation of some - response but nevertheless may not get one. - -2.2.2. Header Values - - These are the DNS message header values for AXFR responses. - - ID MUST be copied from request -- see Note a) - - QR MUST be 1 (Response) - - OPCODE MUST be 0 (Standard Query) - - Flags: - AA normally 1 -- see Note b) - TC MUST be 0 (Not truncated) - RD RECOMMENDED: copy request's value, MAY be set to 0 - RA SHOULD be 0 -- see Note c) - Z 'mbz' -- see Note d) - AD covered by DNSSEC rules -- see Note e) - CD covered by DNSSEC rules -- see Note e) - - RCODE See Note f) - - QDCOUNT MUST be 1 in the first message; - MUST be 0 or 1 in all following messages; - MUST be 1 if RCODE indicates an error - - ANCOUNT See Note g) - - NSCOUNT MUST be 0 - - ARCOUNT See Note h) - - - - - - - -Lewis & Hoenes Expires June 6, 2010 [Page 12] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - - Notes: - - a) Because some old implementations behave differently than is now - desired, the requirement on this field is stated in detail. New - DNS servers MUST set this field to the value of the AXFR query ID - in each AXFR response message for the session. AXFR clients MUST - be able to manage sessions resulting from the issuance of multiple - outstanding queries, whether AXFR queries or other DNS queries. - A client SHOULD discard responses that do not correspond (via the - message ID) to any outstanding queries. - - Unless the client is sure that the server will consistently set - the ID field to the query's ID, the client is NOT RECOMMENDED to - issue any other queries until the end of the zone transfer. - A client MAY become aware of a server's abilities via a - configuration setting. - - b) If the RCODE is 0 (no error), then the AA bit MUST be 1. - For any other value of RCODE, the AA bit MUST be set according to - the rules for that error code. If in doubt, it is RECOMMENDED - that it be set to 1. It is RECOMMENDED that the value be ignored - by the AXFR client. - - c) It is RECOMMENDED that the server set the value to 0, the client - MUST ignore this value. - - The server MAY set this value according to the local policy - regarding recursive service, but doing so might confuse the - interpretation of the response as AXFR can not be retrieved - recursively. A client MAY note the server's policy regarding - recursive service from this value, but SHOULD NOT conclude that - the AXFR response was obtained recursively even if the RD bit was - 1 in the query. - - d) 'mbz' -- The server MUST set this bit to 0, the client MUST ignore - it. - - e) If the implementation supports the DNS Security Extensions (DNSSEC - -- see Section 2), then this value MUST be set according to the - rules in RFC 4035, Section 3.1.6, "The AD and CD Bits in an - Authoritative Response". If the implementation does not support - the DNS Security Extensions, then this value MUST be set to 0 and - MUST be ignored upon receipt. - - f) In the absence of an error, the server MUST set the value of this - field to NoError(0). If a server is not authoritative for the - queried zone, the server SHOULD set the value to NotAuth(9). - (Reminder, consult the appropriate IANA registry [DNSVALS].) If a - client receives any other value in response, it MUST act according - - -Lewis & Hoenes Expires June 6, 2010 [Page 13] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - - to the error. For example, a malformed AXFR query or the presence - of an EDNS0 OPT resource record sent to an old server will garner - a FormErr(1) value. This value is not set as part of the AXFR- - specific response processing. The same is true for other values - indicating an error. - - g) The count of answer records MUST equal the number of resource - records in the AXFR Answer Section. When a server is aware that a - client will only accept one resource record per response message, - then the value MUST be 1. A server MAY be made aware of a - client's limitations via configuration data. - - h) The client MUST set this field to the number of resource records - appearing in the Additional section. The considerations of Note - d) in Section 2.1.1 apply equally; see Section 2.2.6 "Additional - Section" below for more details. - -2.2.3. Question Section - - In the first response message, this section MUST be copied from the - query. In subsequent messages, this section MAY be copied from the - query or it MAY be empty. However, in an error response message (see - Section 2.2), this section MUST be copied as well. The content of - this section MAY be used to determine the context of the message, - that is, the name of the zone being transferred. - -2.2.4. Answer Section - - MUST be populated with the zone contents. See Section 3 below on - encoding zone contents. - -2.2.5. Authority Section - - The Authority section MUST be empty. - -2.2.6. Additional Section - - The contents of this section MUST follow the guidelines for EDNS0 and - TSIG, SIG(0), or whatever other future record is possible here. The - contents of Section 2.1.5 apply analogously as well. - -2.3. TCP Connection Aborts - - If an AXFR client sends a query on a TCP connection and the - connection is closed at any point, the AXFR client MUST consider the - AXFR session terminated. The message ID MAY be used again on a new - connection, even if the question and AXFR server are the same. - - - - -Lewis & Hoenes Expires June 6, 2010 [Page 14] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - - Facing a dropped connection, a client SHOULD try to make some - determination whether the connection closure was the result of - network activity or a decision by the AXFR server. This - determination is not an exact science. It is up to the AXFR client - implementor to react, but the reaction SHOULD NOT be an endless cycle - of retries nor an increasing (in frequency) retry rate. - - An AXFR server implementor SHOULD take into consideration the dilemma - described above when a connection is closed with an outstanding query - in the pipeline. For this reason, a server ought to reserve this - course of action for situations in which it believes beyond a doubt - that the AXFR client is attempting abusive behavior. - - -3. Zone Contents - - The objective of the AXFR session is to request and transfer the - contents of a zone. The objective is to permit the AXFR client to - reconstruct the zone as it exists at the server for the given zone - serial number. Over time the definition of a zone has evolved from - denoting a static set of records to also cover a dynamically updated - set of records, and then a potentially continually regenerated set of - records (e.g., RRs synthesized "on the fly" from rule sets or - database lookup results in other forms than RR format) as well. - -3.1. Records to Include - - In the Answer section of AXFR response messages the resource records - within a zone for the given serial number MUST appear. The - definition of what belongs in a zone is described in RFC 1034, - Section 4.2, "How the database is divided into zones" (in particular - Section 4.2.1, "Technical considerations"), and it has been clarified - in Section 6 of RFC 2181. - - Unless the AXFR server knows that the AXFR client is old and expects - just one resource record per AXFR response message, an AXFR server - SHOULD populate an AXFR response message with as many complete - resource record sets as will fit within a DNS message. - - Zones for which it is impractical to list the entire zone for a - serial number are not suitable for AXFR retrieval. A typical (but - not limiting) description of such a zone is a zone consisting of - responses generated via other database lookups and/or computed based - upon ever changing data. - - - - - - - -Lewis & Hoenes Expires June 6, 2010 [Page 15] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - -3.2. Delegation Records - - In Section 4.2.1 of RFC 1034, this text appears (keep in mind that - the "should" in the quotation predates [BCP14], cf. Section 1.1): - - "The RRs that describe cuts ... should be exactly the same as the - corresponding RRs in the top node of the subzone." - - There has been some controversy over this statement and the impact on - which NS resource records are included in a zone transfer. - - The phrase "that describe cuts" is a reference to the NS set and - applicable glue records. It does not mean that the cut point and - apex resource records are identical. For example, the SOA resource - record is only found at the apex. The discussion here is restricted - to just the NS resource record set and glue as these "describe cuts". - - DNSSEC resource records have special specifications regarding their - occurrence at a zone cut and the apex of a zone. This was first - described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial - specification of DNSSEC), which parts of RFC 2181 now in fact are - historical. The current DNSSEC core document set (see Note e) in - Section 2.2.2 above) gives the full details for DNSSEC(bis) resource - record placement, and Section 3.1.5 of RFC 4035 normatively specifies - their treatment during AXFR; the alternate NSEC3 resource record - defined later in RFC 5155 behaves identically as the NSEC RR, for the - purpose of AXFR. - - Informally: - - o The DS RRSet only occurs at the parental side of a zone cut and is - authoritative data in the parent zone, not the secure child zone. - - o The DNSKEY RRSet only occurs at the APEX of a signed zone and is - part of the authoritative data of the zone it serves. - - o Independent RRSIG RRSets occur at the signed parent side of a zone - cut and at the apex of a signed zone; they are authoritative data - in the respective zone; simple queries for RRSIG resource records - may return both RRSets at once if the same server is authoritative - for the parent zone and the child zone (Section 3.1.5 of RFC 4035 - describes how to distinguish these RRs); this seeming ambiguity - does not occur for AXFR, since each such RRSIG RRset belongs to a - single zone. - - o Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records - equally may occur at the parental side of a zone cut and at the - apex of a zone; each such resource record belongs to exactly one - of these zones and is to be included in the AXFR of that zone. - - -Lewis & Hoenes Expires June 6, 2010 [Page 16] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - - One issue is that in operations there are times when the NS resource - records for a zone might be different at a cut point in the parent - and at the apex of a zone. Sometimes this is the result of an error - and sometimes it is part of an ongoing change in name servers. The - DNS protocol is robust enough to overcome inconsistencies up to (but - not including) there being no parent indicated NS resource record - referencing a server that is able to serve the child zone. This - robustness is one quality that has fueled the success of the DNS. - Still, the inconsistency is an error state and steps need to be taken - to make it apparent (if it is unplanned) and to make it clear once - the inconsistency has been removed. - - Another issue is that the AXFR server could be authoritative for a - different set of zones than the AXFR client. It is possible that the - AXFR server be authoritative for both halves of an inconsistent cut - point and that the AXFR client is authoritative for just the parent - side of the cut point. - - When facing a situation in which a cut point's NS resource records do - not match the authoritative set, the question arises whether an AXFR - server responds with the NS resource record set that is in the zone - being transferred or the one that is at the authoritative location. - - The AXFR response MUST contain the cut point NS resource record set - registered with the zone whether it agrees with the authoritative set - or not. "Registered with" can be widely interpreted to include data - residing in the zone file of the zone for the particular serial - number (in zone file environments) or as any data configured to be in - the zone (database), statically or dynamically. - - The reasons for this requirement are: - - 1) The AXFR server might not be able to determine that there is an - inconsistency given local data, hence requiring consistency would - mean a lot more needed work and even network retrieval of data. An - authoritative server ought not be required to perform any queries. - - 2) By transferring the inconsistent NS resource records from a server - that is authoritative for both the cut point and the apex to a client - that is not authoritative for both, the error is exposed. For - example, an authorized administrator can manually request the AXFR - and inspect the results to see the inconsistent records. (A server - authoritative for both halves would otherwise always answer from the - more authoritative set, concealing the error.) - - 3) The inconsistent NS resource record set might indicate a problem - in a registration database. - - - - -Lewis & Hoenes Expires June 6, 2010 [Page 17] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - - 4) This requirement is necessary to ensure that retrieving a given - (zone,serial) pair by AXFR yields the exact same set of resource - records no matter which of the zone's authoritative servers is chosen - as the source of the transfer. - - If an AXFR server were allowed to respond with the authoritative NS - RRset of a child zone instead of a glue NS RRset in the zone being - transferred, the set of records returned could vary depending on - whether or not the server happens to be authoritative for the child - zone as well. - - The property that a given (zone,serial) pair corresponds to a single, - well-defined set of records is necessary for the correct operation of - incremental transfer protocols such as IXFR [RFC1995]. For example, - a client may retrieve a zone by AXFR from one server, and then apply - an incremental change obtained by IXFR from a different server. If - the two servers have different ideas of the zone contents, the client - can end up attempting to incrementally add records that already exist - or to delete records that do not exist. - -3.3. Glue Records - - As quoted in the previous section, Section 4.2.1 of RFC 1034 provides - guidance and rationale for the inclusion of glue records as part of - an AXFR transfer. And, as also argued in the previous section of - this document, even when there is an inconsistency between the - address in a glue record and the authoritative copy of the name - server's address, the glue resource record that is registered as part - of the zone for that serial number is to be included. - - This applies to glue records for any address family [IANA-AF]. - - The AXFR response MUST contain the appropriate glue records as - registered with the zone. The interpretation of "registered with" in - the previous section applies here. Inconsistent glue records are an - operational matter. - -3.4. Name Compression - - Compression of names in DNS messages is described in RFC 1035, - Section 4.1.4, "Message compression". The issue highlighted here - relates to a comment made in RFC 1034, Section 3.1, "Name space - specifications and terminology" which says "When you receive a domain - name or label, you should preserve its case." ("Should" in the quote - predates [BCP14].) - - Name compression in an AXFR message MUST preserve the case of the - original domain name. That is, although when comparing a domain - name, "a" equals "A", when comparing for the purposes of message - - -Lewis & Hoenes Expires June 6, 2010 [Page 18] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - - compression, "a" is not equal to "A". Note that this is not the - usual definition of name comparison in the DNS protocol and - represents a new requirement on AXFR servers. - - Rules governing name compression of RDATA in an AXFR message MUST - abide by the specification in "Handling of Unknown DNS Resource - Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name - Compression". - -3.5. Occluded Names - - Dynamic Update [RFC2136] operations, and in particular its - interaction with DNAME [RFC2672], can have a side effect of occluding - names in a zone. The addition of a delegation point via dynamic - update will render all subordinate domain names to be in a limbo, - still part of the zone but not available to the lookup process. The - addition of a DNAME resource record has the same impact. The - subordinate names are said to be "occluded". - - Occluded names MUST be included in AXFR responses. An AXFR client - MUST be able to identify and handle occluded names. The rationale - for this action is based on a speedy recovery if the dynamic update - operation was in error and is to be undone. - - -4. Transport - - AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC - 1034 that states: "Because accuracy is essential, TCP or some other - reliable protocol must be used for AXFR requests." The restriction - to TCP is also mentioned in Section 6.1.3.2. of "Requirements for - Internet Hosts - Application and Support" [RFC1123]. - - The most common scenario is for an AXFR client to open a TCP - connection to the AXFR server, send an AXFR query, receive the AXFR - response, and then close the connection. But variations of that - most simple scenario are legitimate and likely, in particular sending - a query for the zone's SOA resource record first over the same TCP - connection, and reusing an existing TCP connection for other queries. - - Therefore, the assumption that a TCP connection is dedicated to a - single AXFR session is incorrect. This wrong assumption has led to - implementation choices that prevent either multiple concurrent zone - transfers or the use of an open connection for other queries. - - Since the early days of the DNS, operators who have sets of name - servers that are authoritative for a common set of zones found it - desirable to be able to have multiple concurrent zone transfers in - progress; this way a name server does not have to wait for one zone - - -Lewis & Hoenes Expires June 6, 2010 [Page 19] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - - transfer to complete before the next could begin. RFC 1035 did not - exclude this possibility, but legacy implementations missed to - support this functionality. The remaining presence of such legacy - implementations makes it necessary that new general purpose server - implementation still provide options for gracefull fallback to the - old behavior in their support of concurrent DNS transactions and AXFR - sessions on a single TCP connection. - -4.1. TCP - - In the original definition there arguably is an implicit assumption - (probably unintentional) that a TCP connection is used for one and - only one AXFR session. This is evidenced in the lack of an explicit - requirement to copy the Query section and/or the message ID into - responses, no explicit ordering information within the AXFR response - messages, and the lack of an explicit notice indicating that a zone - transfer continues in the next message. - - The guidance given below is intended to enable better performance of - the AXFR exchange as well as provide guidelines on interactions with - older software. Better performance includes being able to multiplex - DNS message exchanges including zone transfer sessions. Guidelines - for interacting with older software are generally applicable to new - AXFR clients. In the reverse situation, older AXFR client and newer - AXFR server, the server ought to operate within the specification for - an older server. - -4.1.1. AXFR client TCP - - An AXFR client MAY request a connection to an AXFR server for any - reason. An AXFR client SHOULD close the connection when there is no - apparent need to use the connection for some time period. The AXFR - server ought not have to maintain idle connections, the burden of - connection closure ought to be on the client. "Apparent need" for - the connection is a judgment for the AXFR client and the DNS client. - If the connection is used for multiple sessions, or if it is known - sessions will be coming, or if there is other query/response traffic - anticipated or currently on the open connection, then there is - "apparent need". - - An AXFR client can cancel the delivery of a zone only by closing the - connection. However, this action will also cancel all other - outstanding activity using the connection. There is no other - mechanism by which an AXFR response can be cancelled. - - When a TCP connection is closed remotely (relative to the client), - whether by the AXFR server or due to a network event, the AXFR client - MUST cancel all outstanding sessions and non-AXFR transactions. - Recovery from this situation is not straightforward. If the - - -Lewis & Hoenes Expires June 6, 2010 [Page 20] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - - disruption was a spurious event, attempting to restart the connection - would be proper. If the disruption was caused by a failure that - proved to be persistent, the AXFR client would be wise to not spend - too many resources trying to rebuild the connection. Finally, if the - connection was dropped because of a policy at the AXFR server (as can - be the case with older AXFR servers), the AXFR client would be wise - to not retry the connection. Unfortunately, knowing which of the - three cases above (momentary disruption, failure, policy) applies is - not possible with certainty, and can only be assessed by heuristics. - - An AXFR client MAY use an already opened TCP connection to start an - AXFR session. Using an existing open connection is RECOMMENDED over - opening a new connection. (Non-AXFR session traffic can also use an - open connection.) If in doing so the AXFR client realizes that the - responses cannot be properly differentiated (lack of matching query - IDs for example) or the connection is terminated for a remote reason, - then the AXFR client SHOULD NOT attempt to reuse an open connection - with the specific AXFR server until the AXFR server is updated (which - is, of course, not an event captured in the DNS protocol). - -4.1.2. AXFR server TCP - - An AXFR server MUST be able to handle multiple AXFR sessions on a - single TCP connection, as well as handle other query/response - transactions over it. - - If a TCP connection is closed remotely, the AXFR server MUST cancel - all AXFR sessions in place. No retry activity is necessary; that is - initiated by the AXFR client. - - Local policy MAY dictate that a TCP connection is to be closed. Such - an action SHOULD be in reaction to limits such as those placed on the - number of outstanding open connections. Closing a connection in - response to a suspected security event SHOULD be done only in extreme - cases, when the server is certain the action is warranted. An - isolated request for a zone not on the AXFR server SHOULD receive a - response with the appropriate return code and not see the connection - broken. - -4.2. UDP - - With the addition of EDNS0 and applications which require many small - zones such as in web hosting and some ENUM scenarios, AXFR sessions - on UDP would now seem desirable. However, there are still some - aspects of AXFR sessions that are not easily translated to UDP. - - Therefore, this document does not update RFC 1035 in this respect: - AXFR sessions over UDP transport are not defined. - - - -Lewis & Hoenes Expires June 6, 2010 [Page 21] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - -5. Authorization - - A zone administrator has the option to restrict AXFR access to a - zone. This was not envisioned in the original design of the DNS but - has emerged as a requirement as the DNS has evolved. Restrictions on - AXFR could be for various reasons including a desire (or in some - instances, having a legal requirement) to keep the bulk version of - the zone concealed or to prevent the servers from handling the load - incurred in serving AXFR. It has been argued that these reasons are - questionable, but this document, driven by the desire to leverage the - interoperable practice that has evolved since RFC 1035, acknowledges - the factual requirement to provide mechanisms to restrict AXFR. - - A DNS implementation SHOULD provide means to restrict AXFR sessions - to specific clients. - - An implementation SHOULD allow access to be granted to Internet - Protocol addresses and ranges, regardless of whether a source address - could be spoofed. Combining this with techniques such as Virtual - Private Networks (VPN) [RFC2764] or Virtual LANs has proven to be - effective. - - A general purpose implementation is RECOMMENDED to implement access - controls based upon "Secret Key Transaction Authentication for DNS" - [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" - [RFC2931]. - - A general purpose implementation SHOULD allow access to be open to - all AXFR requests. I.e., an operator ought to be able to allow any - AXFR query to be granted. - - A general purpose implementation SHOULD NOT have a default policy for - AXFR requests to be "open to all". For example, a default could be - to restrict transfers to addresses selected by the DNS - administrator(s) for zones on the server. - - - - - - - - - - - - - - - - -Lewis & Hoenes Expires June 6, 2010 [Page 22] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - -6. Zone Integrity - - An AXFR client MUST ensure that only a successfully transferred copy - of the zone data can be used to serve this zone. Previous - description and implementation practice have introduced a two-stage - model of the whole zone synchronization procedure: Upon a trigger - event (e.g., polling of a SOA resource record detects change in the - SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session is - initiated, whereby the zone data are saved in a zone file or data - base (this latter step is necessary anyway to ensure proper restart - of the server); upon successful completion of the AXFR operation and - some sanity checks, this data set is 'loaded' and made available for - serving the zone in an atomic operation, and flagged 'valid' for use - during the next restart of the DNS server; if any error is detected, - this data set MUST be deleted, and the AXFR client MUST continue to - serve the previous version of the zone, if it did before. The - externally visible behavior of an AXFR client implementation MUST be - equivalent to that of this two-stage model. - - If an AXFR client rejects data contained in an AXFR session, it - SHOULD remember the serial number and MAY attempt to retrieve the - same zone version again. The reason the same retrieval could make - sense is that the reason for the rejection could be rooted in an - implementation detail of one AXFR server used for the zone and not - present in another AXFR server used for the zone. - - Ensuring that an AXFR client does not accept a forged copy of a zone - is important to the security of a zone. If a zone operator has the - opportunity, protection can be afforded via dedicated links, physical - or virtual via a VPN among the authoritative servers. But there are - instances in which zone operators have no choice but to run AXFR - sessions over the global public Internet. - - Besides best attempts at securing TCP connections, DNS - implementations SHOULD provide means to make use of "Secret Key - Transaction Authentication for DNS" [RFC2845] and/or "DNS Request and - Transaction Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients - to verify the contents. These techniques MAY also be used for - authorization. - - - - - - - - - - - - -Lewis & Hoenes Expires June 6, 2010 [Page 23] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - -7. Backwards Compatibility - - Describing backwards compatibility is difficult because of the lack - of specifics in the original definition. In this section some hints - at building in backwards compatibility are given, mostly repeated - from the relevant earlier sections. - - Backwards compatibility is not necessary, but the greater the extent - of an implementation's compatibility the greater its - interoperability. For turnkey implementations this is not usually a - concern. For general purpose implementations this takes on varying - levels of importance depending on the implementer's desire to - maintain interoperability. - - It is unfortunate that a need to fall back to older behavior cannot - be discovered, hence needs to be noted in a configuration file. An - implementation SHOULD, in its documentation, encourage operators to - periodically review AXFR clients and servers it has made notes about - repeatedly, as old software gets updated from time to time. - -7.1. Server - - An AXFR server has the luxury of being able to react to an AXFR - client's abilities with the exception of knowing whether the client - can accept multiple resource records per AXFR response message. The - knowledge that a client is so restricted cannot be discovered, hence - it has to be set by configuration. - - An implementation of an AXFR server MAY permit configuring, on a per - AXFR client basis, the necessity to revert to single resource record - per message; in that case, the default SHOULD be to use multiple - records per message. - -7.2. Client - - An AXFR client has the opportunity to try other features (i.e., those - not defined by this document) when querying an AXFR server. - - Attempting to issue multiple DNS queries over a TCP transport for an - AXFR session SHOULD be aborted if it interrupts the original request, - and SHOULD take into consideration whether the AXFR server intends to - close the connection immediately upon completion of the original - (connection-causing) zone transfer. - - - - - - - - -Lewis & Hoenes Expires June 6, 2010 [Page 24] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - -8. Security Considerations - - Concerns regarding authorization, traffic flooding, and message - integrity are mentioned in "Authorization" (Section 5), "TCP" - (Section 4.2) and "Zone Integrity" (Section 6). - - -9. IANA Considerations - - [[ Note to RFC-Ed: this section may be deleted before publication. ]] - - No new registries or new registrations are included in this document. - - -10. Internationalization Considerations - - The AXFR protocol is transparent to the parts of DNS zone content - that can possibly be subject to Internationalization considerations. - It is assumed that for DNS labels and domain names, the issue has - been solved via "Internationalizing Domain Names in Applications - (IDNA)" [RFC3490] or its successor(s). - - -11. Acknowledgments - - Earlier editions of this document have been edited by Andreas - Gustafsson. In his latest version, this acknowledgment appeared: - - "Many people have contributed input and commentary to earlier - versions of this document, including but not limited to Bob Halley, - Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert - Elz, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam - Trenholme, and Brian Wellington." - - Comments since the -05 version have come from these individuals: - Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch, - Ian Jackson, Andreas Gustafsson, Brian Wellington, and other - participants of the DNSEXT working group. - - Edward Lewis served as a patiently listening sole document editor for - two years. - -12. References - - All "RFC" references by can be obtained from the RFC Editor web site - at the URLs: http://rfc-editor.org/rfc.html - or http://rfc-editor.org/rfcsearch.html ; - information regarding this organization can be found at the following - URL: http://rfc-editor.org/ - - -Lewis & Hoenes Expires June 6, 2010 [Page 25] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - -12.1. Normative References - - [BCP14] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, - RFC 793, September 1981. - - [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, - August 1980. - - [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. - - [RFC1123] Braden, R., "Requirements for Internet Hosts - Application - and Support", STD 3, RFC 1123, October 1989. - - [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, - August 1996. - - [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone - Changes (DNS NOTIFY)", RFC 1996, August 1996. - - [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - - [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", - RFC 2672, August 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures - ( SIG(0)s )", RFC 2931, September 2000. - - - -Lewis & Hoenes Expires June 6, 2010 [Page 26] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - - [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, - November 2002. - - [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. - - [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer - (DS) Resource Records (RRs)", RFC 4509, May 2006 - - [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication - Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", - RFC 4635, August 2006. - - [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS - Security (DNSSEC) Hashed Authenticated Denial of - Existence", RFC 5155, March 2008 - - [RFC5395] Eastlake 3rd, "Domain Name System (DNS) IANA - Considerations", BCP 42, RFC 5395, November 2008. - - [RFC5702] Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY - and RRSIG Resource Records for DNSSEC", RFC 5702, - October 2009. - -12.2. Informative References - - [DNSVALS] IANA Registry "Domain Name System (DNS) Parameters", - http://www.iana.org/assignments/dns-parameters - - [IANA-AF] IANA Registry "Address Family Numbers", - http://www.iana.org/assignments/Address-family-numbers/ . - - [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. - Malis, "A Framework for IP Based Virtual Private - Networks", RFC 2764, February 2000. - - - - -Lewis & Hoenes Expires June 6, 2010 [Page 27] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 - - - [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, - "Internationalizing Domain Names in Applications (IDNA)", - RFC 3490, March 2003. - - [DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and - Implementation Notes for DNSSECbis", - draft-ietf-dnsext-dnssec-bis-updates-09 (work in - progress), September 2009. - - -13. Editors' Addresses - - Edward Lewis - 46000 Center Oak Plaza - Sterling, VA, 22033, US - - Email: ed.lewis@neustar.biz - - - Alfred Hoenes - TR-Sys - Gerlinger Str. 12 - Ditzingen D-71254 - Germany - - Email: ah@TR-Sys.de - - -Editorial Note: Discussion [[ to be removed by RFC-Editor ]] - - Comments on this draft ought to be addressed to the editors and/or to - namedroppers@ops.ietf.org. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lewis & Hoenes Expires June 6, 2010 [Page 28] - diff --git a/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-01.txt b/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-01.txt deleted file mode 100644 index 41ae72ec2eb..00000000000 --- a/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-01.txt +++ /dev/null @@ -1,448 +0,0 @@ - - - -DNSEXT R. Bellis -Internet-Draft Nominet UK -Updates: 1035, 1123 October 26, 2009 -(if approved) -Intended status: Standards Track -Expires: April 29, 2010 - - - DNS Transport over TCP - draft-ietf-dnsext-dns-tcp-requirements-01 - -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 April 29, 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 updates the requirements for the support of the TCP - - - -Bellis Expires April 29, 2010 [Page 1] - -Internet-Draft DNS Transport over TCP October 2009 - - - protocol for the transport of DNS traffic. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - - 2. Terminology used in this document . . . . . . . . . . . . . . . 3 - - 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - - 4. Transport Protocol Selection . . . . . . . . . . . . . . . . . 4 - - 5. Dormant Connection Handling . . . . . . . . . . . . . . . . . . 5 - - 6. Response re-ordering . . . . . . . . . . . . . . . . . . . . . 6 - - 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 - - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 - - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 - - Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 7 - - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 - - - - - - - - - - - - - - - - - - - - - - - -Bellis Expires April 29, 2010 [Page 2] - -Internet-Draft DNS Transport over TCP October 2009 - - -1. Introduction - - Most DNS [RFC1035] transactions take place over the UDP [RFC0792] - protocol. The TCP [RFC0793] protocol is used for zone transfers and - is supported by many implementations for the transfer of other - packets which exceed the protocol's original 512 byte packet-size - limit. - - Section 6.1.3.2 of [RFC1123] states: - - DNS resolvers and recursive servers MUST support UDP, and SHOULD - support TCP, for sending (non-zone-transfer) queries. - - However, some implementors have taken the text quoted above to mean - that TCP support is truly optional for typical DNS operation. - - This document normatively updates the core DNS protocol - specifications such that (except in very limited circumstances) - support for the TCP protocol is henceforth REQUIRED. - - -2. Terminology used 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]. - - -3. Discussion - - In the absence of EDNS0 (see below) the normal behaviour of any DNS - server needing to send a UDP response that exceeds that 512 byte - limit is for the server to truncate the response at the 512 byte - limit and set the TC flag in the response header. When the client - receives such a response it takes the TC flag as notice that it - should retry over TCP instead. - - RFC 1123 also says: - - ... it is also clear that some new DNS record types defined in the - future will contain information exceeding the 512 byte limit that - applies to UDP, and hence will require TCP. Thus, resolvers and - name servers should implement TCP services as a backup to UDP - today, with the knowledge that they will require the TCP service - in the future. - - Existing deployments of DNSSEC [RFC4033] have shown that truncation - at the 512 byte boundary is now commonplace. For example an NXDOMAIN - - - -Bellis Expires April 29, 2010 [Page 3] - -Internet-Draft DNS Transport over TCP October 2009 - - - (RCODE == 3) response from a DNSSEC signed zone using NSEC3 [RFC5155] - is almost invariably longer than 512 bytes. - - Since the original core specifications for DNS were written, the - Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced. - These extensions can be used to indicate that the client is prepared - to receive UDP responses longer than 512 bytes. An EDNS0 compatible - server receiving a request from an EDNS0 compatible client may send - UDP packets up to that client's announced buffer size without - truncation. - - However, transport of UDP packets which exceed the size of the path - MTU has been found to be unreliable in some circumstances because of - IP packet fragmentation. Many firewalls routinely block fragmented - IP packets, and some implementations lack the software logic - necessary to reassemble a fragmented datagram. Worse still, some - devices deliberately refuse to handle DNS packets containing EDNS0 - options. Other issues relating to UDP transport and packet size are - discussed in [RFC5625]. - - The MTU most commonly found in the core of the Internet is around - 1500 bytes, and even that limit is routinely exceeded by DNSSEC - signed responses. - - The future that was anticipated in RFC 1123 has arrived, and the only - standardised mechanism which may have resolved the packet size issue - has been found inadequate. - - -4. Transport Protocol Selection - - All DNS implementations MUST support both UDP and TCP transport - protocols, except as set out below. - - On a case by case basis, authoritative DNS server operators MAY elect - to disable DNS transport over TCP if all of the following conditions - are satisfied: - - o the server is authoritative only - o the server does not support AXFR - o all requests and responses are guaranteed to be <= 512 bytes - - A general purpose stub resolver implementation (e.g. an operating - system's DNS resolution library) MUST support TCP since to do - otherwise would limit its interoperability with its own clients and - with upstream servers. - - A proprietary stub resolver implementation MAY omit support for TCP - - - -Bellis Expires April 29, 2010 [Page 4] - -Internet-Draft DNS Transport over TCP October 2009 - - - if it is operating in an environment where truncation can never - occur, or if it is prepared to accept a DNS lookup failure should - truncation occur. - - A recursive resolver or forwarder MUST support TCP so that it does - not prevent long responses from a TCP-capable server from reaching - its TCP-capable clients. - - Regarding the choice of when to use UDP or TCP, RFC 1123 says: - - ... a DNS resolver or server that is sending a non-zone-transfer - query MUST send a UDP query first. - - That requirement is hereby relaxed. A resolver SHOULD send a UDP - query first, but MAY elect to send a TCP query instead if it has good - reason to expect the response would be truncated if it were sent over - UDP (with or without EDNS0) or for other operational reasons. - - -5. Dormant Connection Handling - - Section 4.2.2 of [RFC1035] says: - - If the server needs to close a dormant connection to reclaim - resources, it should wait until the connection has been idle for a - period on the order of two minutes. - - Other more modern protocols (e.g. HTTP [RFC2616]) have support for - persistent TCP connections and operational experience has shown that - long timeouts can easily cause resource exhaustion and poor response - under heavy load. Intentionally opening many connections and leaving - them dormant can trivially create a "denial of service" attack. - - This document therefore RECOMMENDS that the idle period should be of - the order of TBD seconds. - - Servers MAY allow dormant connections to remain open for longer - periods, but for the avoidance of doubt persistent DNS connections - should generally be considered to be as much for the server's benefit - as for the client's. Therefore if the server needs to unilaterally - close a dormant TCP connection it MUST be free to do so whenever - required. - - Further recommendations for the tuning of TCP parameters to allow - higher throughput or improved resiliency against denial of service - attacks are (currently) outside the scope of this document. - - - - - -Bellis Expires April 29, 2010 [Page 5] - -Internet-Draft DNS Transport over TCP October 2009 - - -6. Response re-ordering - - RFC 1035 is ambiguous on the question of whether TCP queries may be - re-ordered - the only relevant text is in Section 4.2.1 which relates - to UDP: - - Queries or their responses may be reordered by the network, or by - processing in name servers, so resolvers should not depend on them - being returned in order. - - For the avoidance of future doubt, this requirement is clarified. - Client resolvers MUST be able to process responses which arrive in a - different order to that in which the requests were sent, regardless - of the transport protocol in use. - - -7. Security Considerations - - Some DNS server operators have expressed concern that wider use of - DNS over TCP will expose them to a higher risk of "denial of service" - attacks. - - Many large authoritative DNS operators including all but one of the - root servers and the vast majority of TLDs already support TCP and - attacks against them are infrequent and very rarely successful. - - Operators of recursive servers should ensure that they only accept - connections from expected clients, and do not accept them from - unknown sources. In the case of UDP traffic this will protect - against reflector attacks [RFC5358] and in the case of TCP traffic it - will prevent an unknown client from exhausting the server's limits on - the number of concurrent connections. - - -8. IANA Considerations - - This document requests no IANA actions. - - -9. References - -9.1. Normative References - - [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, - RFC 792, September 1981. - - [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, - RFC 793, September 1981. - - - -Bellis Expires April 29, 2010 [Page 6] - -Internet-Draft DNS Transport over TCP October 2009 - - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1123] Braden, R., "Requirements for Internet Hosts - Application - and Support", STD 3, RFC 1123, October 1989. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - -9.2. Informative References - - [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., - Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext - Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS - Security (DNSSEC) Hashed Authenticated Denial of - Existence", RFC 5155, March 2008. - - [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive - Nameservers in Reflector Attacks", BCP 140, RFC 5358, - October 2008. - - [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", - BCP 152, RFC 5625, August 2009. - - -Appendix A. Change Log - - NB: to be removed by the RFC Editor before publication. - - draft-ietf-dnsext-dns-tcp-requirements-01 - Addition of response ordering section - Various minor editorial changes from WG reviewers - - draft-ietf-dnsext-dns-tcp-requirements-00 - Initial draft - - - - - - - -Bellis Expires April 29, 2010 [Page 7] - -Internet-Draft DNS Transport over TCP October 2009 - - -Author's Address - - Ray Bellis - Nominet UK - Edmund Halley Road - Oxford OX4 4DQ - United Kingdom - - Phone: +44 1865 332211 - Email: ray.bellis@nominet.org.uk - URI: http://www.nominet.org.uk/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bellis Expires April 29, 2010 [Page 8] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt deleted file mode 100644 index 0953e28b471..00000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt +++ /dev/null @@ -1,672 +0,0 @@ - - - -Network Working Group S. Weiler -Internet-Draft SPARTA, Inc. -Updates: 4033, 4034, 4035, 5155 D. Blacka -(if approved) VeriSign, Inc. -Intended status: Standards Track September 5, 2009 -Expires: March 9, 2010 - - - Clarifications and Implementation Notes for DNSSECbis - draft-ietf-dnsext-dnssec-bis-updates-09 - -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 March 9, 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 is a collection of technical clarifications to the - - - -Weiler & Blacka Expires March 9, 2010 [Page 1] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - DNSSECbis document set. It is meant to serve as a resource to - implementors as well as a repository of DNSSECbis errata. - - -Table of Contents - - 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 3 - 1.1. Structure of this Document . . . . . . . . . . . . . . . . 3 - 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 3 - 2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 3 - 2.2. SHA-256 Support . . . . . . . . . . . . . . . . . . . . . 3 - 3. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4 - 3.2. Validating Responses to an ANY Query . . . . . . . . . . . 4 - 3.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 5 - 3.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5 - 4. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5 - 4.1. Errors in Canonical Form Type Code List . . . . . . . . . 5 - 4.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 5 - 4.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6 - 4.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7 - 4.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7 - 4.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 7 - 4.7. Setting the AD bit on Replies . . . . . . . . . . . . . . 7 - 4.8. Setting the CD bit on Requests . . . . . . . . . . . . . . 8 - 4.9. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 8 - 5. Minor Corrections and Clarifications . . . . . . . . . . . . . 8 - 5.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 8 - 5.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 9 - 5.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 9 - 5.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 9 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 - - - - - - - - - - - - -Weiler & Blacka Expires March 9, 2010 [Page 2] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - -1. Introduction and Terminology - - This document lists some additions, clarifications and corrections to - the core DNSSECbis specification, as originally described in - [RFC4033], [RFC4034], and [RFC4035]. - - It is intended to serve as a resource for implementors and as a - repository of items that need to be addressed when advancing the - DNSSECbis documents from Proposed Standard to Draft Standard. - -1.1. Structure of this Document - - The clarifications to DNSSECbis are sorted according to their - importance, starting with ones which could, if ignored, lead to - security problems and progressing down to clarifications that are - expected to have little operational impact. - -1.2. Terminology - - 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]. - - -2. Important Additions to DNSSSECbis - - This section updates the set of core DNSSEC protocol documents - originally specified in Section 10 of [RFC4033]. - -2.1. NSEC3 Support - - [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM - records for hashed denial of existence. Validator implementations - are strongly encouraged to include support for NSEC3 because a number - of highly visible zones are expected to use it. Validators that do - not support validation of responses using NSEC3 will likely be - hampered in validating large portions of the DNS space. - - [RFC5155] should be considered part of the DNS Security Document - Family as described by [RFC4033], Section 10. - -2.2. SHA-256 Support - - [RFC4509] describes the use of SHA-256 as a digest algorithm for use - with Delegation Signer (DS) RRs. [I-D.ietf-dnsext-dnssec-rsasha256] - describes the use of the RSASHA256 algorithm for use in DNSKEY and - RRSIG RRs. Validator implementations are strongly encouraged to - include support for this algorithm for DS, DNSKEY, and RRSIG records. - - - -Weiler & Blacka Expires March 9, 2010 [Page 3] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - Both [RFC4509] and [I-D.ietf-dnsext-dnssec-rsasha256] should also be - considered part of the DNS Security Document Family as described by - [RFC4033], Section 10. - - -3. Security Concerns - - This section provides clarifications that, if overlooked, could lead - to security issues. - -3.1. Clarifications on Non-Existence Proofs - - [RFC4035] Section 5.4 under-specifies the algorithm for checking non- - existence proofs. In particular, the algorithm as presented would - incorrectly allow an NSEC or NSEC3 RR from an ancestor zone to prove - the non-existence of RRs in the child zone. - - An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with: - - o the NS bit set, - o the SOA bit clear, and - o a signer field that is shorter than the owner name of the NSEC RR, - or the original owner name for the NSEC3 RR. - - Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non- - existence of any RRs below that zone cut, which include all RRs at - that (original) owner name other than DS RRs, and all RRs below that - owner name regardless of type. - - Similarly, the algorithm would also allow an NSEC RR at the same - owner name as a DNAME RR, or an NSEC3 RR at the same original owner - name as a DNAME, to prove the non-existence of names beneath that - DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used - to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's - (original) owner name. - -3.2. Validating Responses to an ANY Query - - [RFC4035] does not address how to validate responses when QTYPE=*. - As described in Section 6.2.2 of [RFC1034], a proper response to - QTYPE=* may include a subset of the RRsets at a given name. That is, - it is not necessary to include all RRsets at the QNAME in the - response. - - When validating a response to QTYPE=*, all received RRsets that match - QNAME and QCLASS MUST be validated. If any of those RRsets fail - validation, the answer is considered Bogus. If there are no RRsets - matching QNAME and QCLASS, that fact MUST be validated according to - - - -Weiler & Blacka Expires March 9, 2010 [Page 4] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - the rules in [RFC4035] Section 5.4 (as clarified in this document). - To be clear, a validator must not expect to receive all records at - the QNAME in response to QTYPE=*. - -3.3. Check for CNAME - - Section 5 of [RFC4035] says little about validating responses based - on (or that should be based on) CNAMEs. When validating a NOERROR/ - NODATA response, validators MUST check the CNAME bit in the matching - NSEC or NSEC3 RR's type bitmap in addition to the bit for the query - type. Without this check, an attacker could successfully transform a - positive CNAME response into a NOERROR/NODATA response. - -3.4. Insecure Delegation Proofs - - [RFC4035] Section 5.2 specifies that a validator, when proving a - delegation is not secure, needs to check for the absence of the DS - and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also - needs to check for the presence of the NS bit in the matching NSEC - (or NSEC3) RR (proving that there is, indeed, a delegation), or - alternately make sure that the delegation is covered by an NSEC3 RR - with the Opt-Out flag set. If this is not checked, spoofed unsigned - delegations might be used to claim that an existing signed record is - not signed. - - -4. Interoperability Concerns - -4.1. Errors in Canonical Form Type Code List - - When canonicalizing DNS names, DNS names in the RDATA section of NSEC - and RRSIG resource records are not downcased. - - [RFC4034] Section 6.2 item 3 has a list of resource record types for - which DNS names in the RDATA are downcased for purposes of DNSSEC - canonical form (for both ordering and signing). That list - erroneously contains NSEC and RRSIG. According to [RFC3755], DNS - names in the RDATA of NSEC and RRSIG should not be downcased. - - The same section also erroneously lists HINFO, and twice at that. - Since HINFO records contain no domain names, they are not subject to - downcasing. - -4.2. Unknown DS Message Digest Algorithms - - Section 5.2 of [RFC4035] includes rules for how to handle delegations - to zones that are signed with entirely unsupported public key - algorithms, as indicated by the key algorithms shown in those zone's - - - -Weiler & Blacka Expires March 9, 2010 [Page 5] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - DS RRsets. It does not explicitly address how to handle DS records - that use unsupported message digest algorithms. In brief, DS records - using unknown or unsupported message digest algorithms MUST be - treated the same way as DS records referring to DNSKEY RRs of unknown - or unsupported public key algorithms. - - The existing text says: - - If the validator does not support any of the algorithms listed in - an authenticated DS RRset, then the resolver has no supported - authentication path leading from the parent to the child. The - resolver should treat this case as it would the case of an - authenticated NSEC RRset proving that no DS RRset exists, as - described above. - - To paraphrase the above, when determining the security status of a - zone, a validator disregards any DS records listing unknown or - unsupported algorithms. If none are left, the zone is treated as if - it were unsigned. - - Modified to consider DS message digest algorithms, a validator also - disregards any DS records using unknown or unsupported message digest - algorithms. - -4.3. Private Algorithms - - As discussed above, section 5.2 of [RFC4035] requires that validators - make decisions about the security status of zones based on the public - key algorithms shown in the DS records for those zones. In the case - of private algorithms, as described in [RFC4034] Appendix A.1.1, the - eight-bit algorithm field in the DS RR is not conclusive about what - algorithm(s) is actually in use. - - If no private algorithms appear in the DS set or if any supported - algorithm appears in the DS set, no special processing will be - needed. In the remaining cases, the security status of the zone - depends on whether or not the resolver supports any of the private - algorithms in use (provided that these DS records use supported hash - functions, as discussed in Section 4.2). In these cases, the - resolver MUST retrieve the corresponding DNSKEY for each private - algorithm DS record and examine the public key field to determine the - algorithm in use. The security-aware resolver MUST ensure that the - hash of the DNSKEY RR's owner name and RDATA matches the digest in - the DS RR. If they do not match, and no other DS establishes that - the zone is secure, the referral should be considered Bogus data, as - discussed in [RFC4035]. - - This clarification facilitates the broader use of private algorithms, - - - -Weiler & Blacka Expires March 9, 2010 [Page 6] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - as suggested by [RFC4955]. - -4.4. Caution About Local Policy and Multiple RRSIGs - - When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3 - suggests that "the local resolver security policy determines whether - the resolver also has to test these RRSIG RRs and how to resolve - conflicts if these RRSIG RRs lead to differing results." In most - cases, a resolver would be well advised to accept any valid RRSIG as - sufficient. If the first RRSIG tested fails validation, a resolver - would be well advised to try others, giving a successful validation - result if any can be validated and giving a failure only if all - RRSIGs fail validation. - - If a resolver adopts a more restrictive policy, there's a danger that - properly-signed data might unnecessarily fail validation, perhaps - because of cache timing issues. Furthermore, certain zone management - techniques, like the Double Signature Zone-signing Key Rollover - method described in section 4.2.1.2 of [RFC4641] might not work - reliably. - -4.5. Key Tag Calculation - - [RFC4034] Appendix B.1 incorrectly defines the Key Tag field - calculation for algorithm 1. It correctly says that the Key Tag is - the most significant 16 of the least significant 24 bits of the - public key modulus. However, [RFC4034] then goes on to incorrectly - say that this is 4th to last and 3rd to last octets of the public key - modulus. It is, in fact, the 3rd to last and 2nd to last octets. - -4.6. Setting the DO Bit on Replies - - [RFC4035] does not provide any instructions to servers as to how to - set the DO bit. Some authoritative server implementations have - chosen to copy the DO bit settings from the incoming query to the - outgoing response. Others have chosen to never set the DO bit in - responses. Either behavior is permitted. To be clear, in replies to - queries with the DO-bit set servers may or may not set the DO bit. - -4.7. Setting the AD bit on Replies - - Section 3.2.3 of [RFC4035] describes under which conditions a - validating resolver should set or clear the AD bit in a response. In - order to protect legacy stub resolvers and middleboxes, validating - resolvers SHOULD only set the AD bit when a response both meets the - conditions listed in RFC 4035, section 3.2.3, and the request - contained either a set DO bit or a set AD bit. - - - - -Weiler & Blacka Expires March 9, 2010 [Page 7] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - Note that the use of the AD bit in the query was previously - undefined. This document defines it as a signal indicating that the - requester understands and is interested in the value of the AD bit in - the response. This allows a requestor to indicate that it - understands the AD bit without also requesting DNSSEC data via the DO - bit. - -4.8. Setting the CD bit on Requests - - When processing a request with the CD bit set, the resolver MUST set - the CD bit on its upstream queries. - -4.9. Nested Trust Anchors - - A DNSSEC validator may be configured such that, for a given response, - more than one trust anchor could be used to validate the chain of - trust to the response zone. For example, imagine a validator - configured with trust anchors for "example." and "zone.example." - When the validator is asked to validate a response to - "www.sub.zone.example.", either trust anchor could apply. - - When presented with this situation, DNSSEC validators SHOULD try all - applicable trust anchors until one succeeds. - - There are some scenarios where different behaviors, such as choosing - the trust anchor closest to the QNAME of the response, may be - desired. A DNSSEC validator MAY enable such behaviors as - configurable overrides. - - -5. Minor Corrections and Clarifications - -5.1. Finding Zone Cuts - - Appendix C.8 of [RFC4035] discusses sending DS queries to the servers - for a parent zone. To do that, a resolver may first need to apply - special rules to discover what those servers are. - - As explained in Section 3.1.4.1 of [RFC4035], security-aware name - servers need to apply special processing rules to handle the DS RR, - and in some situations the resolver may also need to apply special - rules to locate the name servers for the parent zone if the resolver - does not already have the parent's NS RRset. Section 4.2 of - [RFC4035] specifies a mechanism for doing that. - - - - - - - -Weiler & Blacka Expires March 9, 2010 [Page 8] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - -5.2. Clarifications on DNSKEY Usage - - Questions of the form "can I use a different DNSKEY for signing this - RRset" have occasionally arisen. - - The short answer is "yes, absolutely". You can even use a different - DNSKEY for each RRset in a zone, subject only to practical limits on - the size of the DNSKEY RRset. However, be aware that there is no way - to tell resolvers what a particularly DNSKEY is supposed to be used - for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to - authenticate any RRset in the zone. For example, if a weaker or less - trusted DNSKEY is being used to authenticate NSEC RRsets or all - dynamically updated records, that same DNSKEY can also be used to - sign any other RRsets from the zone. - - Furthermore, note that the SEP bit setting has no effect on how a - DNSKEY may be used -- the validation process is specifically - prohibited from using that bit by [RFC4034] section 2.1.2. It is - possible to use a DNSKEY without the SEP bit set as the sole secure - entry point to the zone, yet use a DNSKEY with the SEP bit set to - sign all RRsets in the zone (other than the DNSKEY RRset). It's also - possible to use a single DNSKEY, with or without the SEP bit set, to - sign the entire zone, including the DNSKEY RRset itself. - -5.3. Errors in Examples - - The text in [RFC4035] Section C.1 refers to the examples in B.1 as - "x.w.example.com" while B.1 uses "x.w.example". This is painfully - obvious in the second paragraph where it states that the RRSIG labels - field value of 3 indicates that the answer was not the result of - wildcard expansion. This is true for "x.w.example" but not for - "x.w.example.com", which of course has a label count of 4 - (antithetically, a label count of 3 would imply the answer was the - result of a wildcard expansion). - - The first paragraph of [RFC4035] Section C.6 also has a minor error: - the reference to "a.z.w.w.example" should instead be "a.z.w.example", - as in the previous line. - -5.4. Errors in RFC 5155 - - A NSEC3 record that matches an Empty Non-Terminal effectively has no - type associated with it. This NSEC3 record has an empty type bit - map. Section 3.2.1 of [RFC5155] contains the statement: - - Blocks with no types present MUST NOT be included. - - However, the same section contains a regular expression: - - - -Weiler & Blacka Expires March 9, 2010 [Page 9] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ - - The plus sign in the regular expression indicates that there is one - or more of the preceding element. This means that there must be at - least one window block. If this window block has no types, it - contradicts with the first statement. Therefore, the correct text in - RFC 5155 3.2.1 should be: - - Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )* - - -6. IANA Considerations - - This document specifies no IANA Actions. - - -7. Security Considerations - - This document adds two cryptographic features to the core DNSSEC - protocol. Additionally, it addresses some ambiguities and omissions - in the core DNSSEC documents that, if not recognized and addressed in - implementations, could lead to security failures. In particular, the - validation algorithm clarifications in Section 3 are critical for - preserving the security properties DNSSEC offers. Furthermore, - failure to address some of the interoperability concerns in Section 4 - could limit the ability to later change or expand DNSSEC, including - adding new algorithms. - - -8. References - -8.1. Normative References - - [I-D.ietf-dnsext-dnssec-rsasha256] - Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY - and RRSIG Resource Records for DNSSEC", - draft-ietf-dnsext-dnssec-rsasha256-14 (work in progress), - June 2009. - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - RFC 1034, STD 13, November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, BCP 14, March 1997. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - - -Weiler & Blacka Expires March 9, 2010 [Page 10] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - [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. - - [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. - -8.2. Informative References - - [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer (DS)", RFC 3755, May 2004. - - [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", - RFC 4641, September 2006. - - [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, - July 2007. - - -Appendix A. Acknowledgments - - The editors would like the thank Rob Austein for his previous work as - an editor of this document. - - The editors are extremely grateful to those who, in addition to - finding errors and omissions in the DNSSECbis document set, have - provided text suitable for inclusion in this document. - - The lack of specificity about handling private algorithms, as - described in Section 4.3, and the lack of specificity in handling ANY - queries, as described in Section 3.2, were discovered by David - Blacka. - - The error in algorithm 1 key tag calculation, as described in - Section 4.5, was found by Abhijit Hayatnagarkar. Donald Eastlake - contributed text for Section 4.5. - - The bug relating to delegation NSEC RR's in Section 3.1 was found by - Roy Badami. Roy Arends found the related problem with DNAME. - - - - -Weiler & Blacka Expires March 9, 2010 [Page 11] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - The errors in the [RFC4035] examples were found by Roy Arends, who - also contributed text for Section 5.3 of this document. - - The editors would like to thank Ed Lewis, Danny Mayer, Olafur - Gudmundsson, Suzanne Woolf, and Scott Rose for their substantive - comments on the text of this document. - - -Authors' Addresses - - Samuel Weiler - SPARTA, Inc. - 7110 Samuel Morse Drive - Columbia, Maryland 21046 - US - - Email: weiler@tislabs.com - - - David Blacka - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166 - US - - Email: davidb@verisign.com - - - - - - - - - - - - - - - - - - - - - - - - - -Weiler & Blacka Expires March 9, 2010 [Page 12] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt b/doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt deleted file mode 100644 index 152d96efaca..00000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt +++ /dev/null @@ -1,448 +0,0 @@ -DNS Extensions working group V.Dolmatov, Ed. -Internet-Draft Cryptocom Ltd. -Intended status: Standards Track November 30, 2009 -Expires: May 30, 2010 - - - Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records - for DNSSEC - draft-ietf-dnsext-dnssec-gost-05 - -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 [DRAFT1, DRAFT2, DRAFT3] 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 30, 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 . . . . . . . . . . . . . . . . . . . . . . 5 - 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 . . . . . . . . . . . . . . . . . . . . . . . . 9 - -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 30, 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 [GOST3410], 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 [GOST3410], 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 30, 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.2.1 - - 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. - 2MIsZWtEx6pcfQrdl376B8sFg0qxsR8XMHpl - jHh+V6U7Qte7WwI4C3Z1nFMRVf//C9rO2dGB - rdp+C7wVoOHBqA== ) - -V.Dolmatov Expires May 30, 2010 [Page 4] - - 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 - RFC4490 [RFC4490], that is digest is in little-endian representation. - - - 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. - -V.Dolmatov Expires May 30, 2010 [Page 5] - -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 - of order 2**256. - - - 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. - -V.Dolmatov Expires May 30, 2010 [Page 6] - - 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. - - [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. - -V.Dolmatov Expires May 30, 2010 [Page 7] - - -10.2. Informative References - - [RFC4509] Hardaker W., "Use of SHA-256 in DNSSEC Delegation Signer - (DS) Resource Records (RRs)", RFC 4509, May 2006. - - [DRAFT1] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S., - "GOST R 34.10-2001 digital signature algorithm" - draft-dolmatov-cryptocom-gost34102001-06, 11.10.09 - work in progress. - - - [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. - -V.Dolmatov Expires May 30, 2010 [Page 8] - - -Authors' Addresses - - -Vasily Dolmatov, Ed. -Cryptocom Ltd. -Kedrova 14, bld.2 -Moscow, 117218, Russian Federation - -EMail: dol@cryptocom.ru - -Artem Chuprina -Cryptocom Ltd. -Kedrova 14, bld.2 -Moscow, 117218, Russian Federation - -EMail: ran@cryptocom.ru - -Igor Ustinov -Cryptocom Ltd. -Kedrova 14, bld.2 -Moscow, 117218, Russian Federation - -EMail: igus@cryptocom.ru - -V.Dolmatov Expires May 30, 2010 [Page 9] - - - - - diff --git a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt deleted file mode 100644 index ba1b4147f4d..00000000000 --- a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt +++ /dev/null @@ -1,616 +0,0 @@ - - - -DNSEXT Working Group M. Graff -Internet-Draft P. Vixie -Obsoletes: 2671 (if approved) Internet Systems Consortium -Intended status: Standards Track July 28, 2009 -Expires: January 29, 2010 - - - Extension Mechanisms for DNS (EDNS0) - draft-ietf-dnsext-rfc2671bis-edns0-02 - -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 January 29, 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 - - The Domain Name System's wire protocol includes a number of fixed - fields whose range has been or soon will be exhausted and does not - - - -Graff & Vixie Expires January 29, 2010 [Page 1] - -Internet-Draft EDNS0 Extensions July 2009 - - - allow requestors to advertise their capabilities to responders. This - document describes backward compatible mechanisms for allowing the - protocol to grow. - - This document updates the EDNS0 specification based on 10 years of - operational experience. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 - 3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3 - 4. Affected Protocol Elements . . . . . . . . . . . . . . . . . . 3 - 4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 3 - 4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 4 - 4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 4 - 5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 4 - 6. OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . . . 4 - 6.1. OPT Record Behavior . . . . . . . . . . . . . . . . . . . 4 - 6.2. OPT Record Format . . . . . . . . . . . . . . . . . . . . 5 - 6.3. Requestor's Payload Size . . . . . . . . . . . . . . . . . 6 - 6.4. Responder's Payload Size . . . . . . . . . . . . . . . . . 6 - 6.5. Payload Size Selection . . . . . . . . . . . . . . . . . . 7 - 6.6. Middleware Boxes . . . . . . . . . . . . . . . . . . . . . 7 - 6.7. Extended RCODE . . . . . . . . . . . . . . . . . . . . . . 7 - 6.8. OPT Options Type Allocation Procedure . . . . . . . . . . 8 - 7. Transport Considerations . . . . . . . . . . . . . . . . . . . 8 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 - - - - - - - - - - - - - - - - -Graff & Vixie Expires January 29, 2010 [Page 2] - -Internet-Draft EDNS0 Extensions July 2009 - - -1. Introduction - - DNS [RFC1035] specifies a Message Format and within such messages - there are standard formats for encoding options, errors, and name - compression. The maximum allowable size of a DNS Message is fixed. - Many of DNS's protocol limits are too small for uses which are or - which are desired to become common. There is no way for - implementations to advertise their capabilities. - - Unextended agents will not know how to interpret the protocol - extensions detailed here. In practice, these clients will be - upgraded when they have need of a new feature, and only new features - will make use of the extensions. Extended agents must be prepared - for behaviour of unextended clients in the face of new protocol - elements, and fall back gracefully to unextended DNS. [RFC2671] - originally proposed extensions to the basic DNS protocol to overcome - these deficiencies. This memo refines that specification and - obsoletes [RFC2671]. - - -2. 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]. - - -3. EDNS Support Requirement - - EDNS support is manditory in a modern world. DNSSEC requires EDNS - support, and many other featres are made possible only by EDNS - support to request or advertise them. - - -4. Affected Protocol Elements - -4.1. Message Header - - The DNS Message Header's (see , section 4.1.1 [RFC1035]) second full - 16-bit word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a - number of 1-bit flags. The original reserved Z bits have been - allocated to various purposes, and most of the RCODE values are now - in use. More flags and more possible RCODEs are needed. The OPT - pseudo-RR specified below contains subfields that carry a bit field - extension of the RCODE field and additional flag bits, respectively. - - - - - - -Graff & Vixie Expires January 29, 2010 [Page 3] - -Internet-Draft EDNS0 Extensions July 2009 - - -4.2. Label Types - - The first two bits of a wire format domain label are used to denote - the type of the label. ,section 4.1.4 [RFC1035] allocates two of the - four possible types and reserves the other two. More label types - were proposed in [RFC2671] section 3. - -4.3. UDP Message Size - - DNS Messages are limited to 512 octets in size when sent over UDP. - While the minimum maximum reassembly buffer size still allows a limit - of 512 octets of UDP payload, most of the hosts now connected to the - Internet are able to reassemble larger datagrams. Some mechanism - must be created to allow requestors to advertise larger buffer sizes - to responders. To this end, the OPT pseudo-RR specified below - contains a maximum payload size field. - - -5. Extended Label Types - - The first octet in the on-the-wire representation of a DNS label - specifies the label type; the basic DNS specification [RFC1035] - dedicates the two most significant bits of that octet for this - purpose. - - This document reserves DNS label type 0b01 for use as an indication - for Extended Label Types. A specific extended label type is selected - by the 6 least significant bits of the first octet. Thus, Extended - Label Types are indicated by the values 64-127 (0b01xxxxxx) in the - first octet of the label. - - This document does not describe any specific Extended Label Type. - - In practice, Extended Label Types are difficult to use due to support - in clients and intermediate gateways. Therefore, the registry of - Extended Label Types is requested to be closed. They cause - interoperability problems and at present no defined label types are - in use. - - -6. OPT pseudo-RR - -6.1. OPT Record Behavior - - One OPT pseudo-RR (RR type 41) MAY be added to the additional data - section of a request. If present in requests, compliant responders - which implement EDNS MUST include an OPT record in non-truncated - responses, and SHOULD attempt to include them in all responses. An - - - -Graff & Vixie Expires January 29, 2010 [Page 4] - -Internet-Draft EDNS0 Extensions July 2009 - - - OPT is called a pseudo-RR because it pertains to a particular - transport level message and not to any actual DNS data. OPT RRs MUST - NOT be cached, forwarded, or stored in or loaded from master files. - The quantity of OPT pseudo-RRs per message MUST be either zero or - one, but not greater. - -6.2. OPT Record Format - - An OPT RR has a fixed part and a variable set of options expressed as - {attribute, value} pairs. The fixed part holds some DNS meta data - and also a small collection of basic extension elements which we - expect to be so popular that it would be a waste of wire space to - encode them as {attribute, value} pairs. - - The fixed part of an OPT RR is structured as follows: - - +------------+--------------+------------------------------+ - | Field Name | Field Type | Description | - +------------+--------------+------------------------------+ - | NAME | domain name | empty (root domain) | - | TYPE | u_int16_t | OPT | - | CLASS | u_int16_t | requestor's UDP payload size | - | TTL | u_int32_t | extended RCODE and flags | - | RDLEN | u_int16_t | describes RDATA | - | RDATA | octet stream | {attribute,value} pairs | - +------------+--------------+------------------------------+ - - OPT RR Format - - The variable part of an OPT RR is encoded in its RDATA and is - structured as zero or more of the following: - - - +0 (MSB) +1 (LSB) - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | OPTION-CODE | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | OPTION-LENGTH | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 4: | | - / OPTION-DATA / - / / - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - - - - - - - -Graff & Vixie Expires January 29, 2010 [Page 5] - -Internet-Draft EDNS0 Extensions July 2009 - - - OPTION-CODE - Assigned by Expert Review. - - OPTION-LENGTH - Size (in octets) of OPTION-DATA. - - OPTION-DATA - Varies per OPTION-CODE. - - Order of appearance of option tuples is never relevant. Any option - whose meaning is affected by other options is so affected no matter - which one comes first in the OPT RDATA. - - Any OPTION-CODE values not understood by a responder or requestor - MUST be ignored. Specifications of such options might wish to - include some kind of signalled acknowledgement. For example, an - option specification might say that if a responder sees option XYZ, - it SHOULD include option XYZ in its response. - -6.3. Requestor's Payload Size - - The requestor's UDP payload size (which OPT stores in the RR CLASS - field) is the number of octets of the largest UDP payload that can be - reassembled and delivered in the requestor's network stack. Note - that path MTU, with or without fragmentation, may be smaller than - this. Values lower than 512 MUST be treated as equal to 512. - - Note that a 512-octet UDP payload requires a 576-octet IP reassembly - buffer. Choosing 1280 for IPv4 over Ethernet would be reasonable. - The consequence of choosing too large a value may be an ICMP message - from an intermediate gateway, or even a silent drop of the response - message. - - The requestor's maximum payload size can change over time, and MUST - therefore not be cached for use beyond the transaction in which it is - advertised. - -6.4. Responder's Payload Size - - The responder's maximum payload size can change over time, but can be - reasonably expected to remain constant between two sequential - transactions; for example, a meaningless QUERY to discover a - responder's maximum UDP payload size, followed immediately by an - UPDATE which takes advantage of this size. (This is considered - preferrable to the outright use of TCP for oversized requests, if - there is any reason to suspect that the responder implements EDNS, - and if a request will not fit in the default 512 payload size limit.) - - - - -Graff & Vixie Expires January 29, 2010 [Page 6] - -Internet-Draft EDNS0 Extensions July 2009 - - -6.5. Payload Size Selection - - Due to transaction overhead, it is unwise to advertise an - architectural limit as a maximum UDP payload size. Just because your - stack can reassemble 64KB datagrams, don't assume that you want to - spend more than about 4KB of state memory per ongoing transaction. - - A requestor MAY choose to implement a fallback to smaller advertised - sizes to work around firewall or other network limitations. A - requestor SHOULD choose to use a fallback mechanism which begins with - a large size, such as 4096. If that fails, a fallback around the - 1220 byte range SHOULD be tried, as it has a reasonable chance to fit - within a single Ethernet frame. Failing that, a requestor MAY choose - a 512 byte packet, which with large answers may cause a TCP retry. - -6.6. Middleware Boxes - - Middleware boxes MUST NOT limit DNS messages over UDP to 512 bytes. - - Middleware boxes which simply forward requests to a recursive - resolver MUST NOT modify the OPT record contents in either direction. - -6.7. Extended RCODE - - The extended RCODE and flags (which OPT stores in the RR TTL field) - are structured as follows: - - +0 (MSB) +1 (LSB) - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | EXTENDED-RCODE | VERSION | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | DO| Z | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - EXTENDED-RCODE - Forms upper 8 bits of extended 12-bit RCODE. Note that - EXTENDED-RCODE value "0" indicates that an unextended RCODE is - in use (values "0" through "15"). - - VERSION - Indicates the implementation level of whoever sets it. Full - conformance with this specification is indicated by version - ``0.'' Requestors are encouraged to set this to the lowest - implemented level capable of expressing a transaction, to - minimize the responder and network load of discovering the - greatest common implementation level between requestor and - responder. A requestor's version numbering strategy MAY - ideally be a run time configuration option. - - - -Graff & Vixie Expires January 29, 2010 [Page 7] - -Internet-Draft EDNS0 Extensions July 2009 - - - If a responder does not implement the VERSION level of the - request, then it answers with RCODE=BADVERS. All responses - MUST be limited in format to the VERSION level of the request, - but the VERSION of each response SHOULD be the highest - implementation level of the responder. In this way a requestor - will learn the implementation level of a responder as a side - effect of every response, including error responses and - including RCODE=BADVERS. - - DO - DNSSEC OK bit as defined by [RFC3225]. - - Z - Set to zero by senders and ignored by receivers, unless - modified in a subsequent specification. - -6.8. OPT Options Type Allocation Procedure - - Allocations assigned by expert review. TBD - - -7. Transport Considerations - - The presence of an OPT pseudo-RR in a request should be taken as an - indication that the requestor fully implements the given version of - EDNS, and can correctly understand any response that conforms to that - feature's specification. - - Lack of presence of an OPT record in a request MUST be taken as an - indication that the requestor does not implement any part of this - specification and that the responder MUST NOT use any protocol - extension described here in its response. - - Responders who do not implement these protocol extensions MUST - respond with FORMERR messages without any OPT record. - - If there is a problem with processing the OPT record itself, such as - an option value that is badly formatted or includes out of range - values, a FORMERR MAY be retured. If this occurs the response MUST - include an OPT record. This MAY be used to distinguish between - servers whcih do not implement EDNS and format errors within EDNS. - - If EDNS is used in a request, and the response arrives with TC set - and with no EDNS OPT RR, a requestor SHOULD assume that truncation - prevented the OPT RR from being appended by the responder, and - further, that EDNS is not used in the response. Correspondingly, an - EDNS responder who cannot fit all necessary elements (including an - OPT RR) into a response, SHOULD respond with a normal (unextended) - - - -Graff & Vixie Expires January 29, 2010 [Page 8] - -Internet-Draft EDNS0 Extensions July 2009 - - - DNS response, possibly setting TC if the response will not fit in the - unextended response message's 512-octet size. - - -8. Security Considerations - - Requestor-side specification of the maximum buffer size may open a - new DNS denial of service attack if responders can be made to send - messages which are too large for intermediate gateways to forward, - thus leading to potential ICMP storms between gateways and - responders. - - Announcing very large UDP buffer sizes may result in dropping by - firewalls. This could cause retransmissions with no hope of success. - Some devices reject fragmented UDP packets. - - Announcing too small UDP buffer sizes may result in fallback to TCP. - This is especially important with DNSSEC, where answers are much - larger. - - -9. IANA Considerations - - The IANA has assigned RR type code 41 for OPT. - - [RFC2671] specified a number of IANA sub-registries within "DOMAIN - NAME SYSTEM PARAMETERS:" "EDNS Extended Label Type", "EDNS Option - Codes", "EDNS Version Numbers", and "Domain System Response Code." - IANA is advised to re-parent these subregistries to this document. - - RFC 2671 created an extended label type registry. We request that - this registry be closed. - - This document assigns extended label type 0bxx111111 as "Reserved for - future extended label types." We request that IANA record this - assignment. - - This document assigns option code 65535 to "Reserved for future - expansion." - - This document expands the RCODE space from 4 bits to 12 bits. This - will allow IANA to assign more than the 16 distinct RCODE values - allowed in RFC 1035 [RFC1035]. - - This document assigns EDNS Extended RCODE "16" to "BADVERS". - - IESG approval should be required to create new entries in the EDNS - Extended Label Type or EDNS Version Number registries, while any - - - -Graff & Vixie Expires January 29, 2010 [Page 9] - -Internet-Draft EDNS0 Extensions July 2009 - - - published RFC (including Informational, Experimental, or BCP) should - be grounds for allocation of an EDNS Option Code. - - -10. Acknowledgements - - Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, - Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas - Narten were each instrumental in creating and refining this - specification. - - -11. References - -11.1. Normative References - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", - RFC 3225, December 2001. - -11.2. Informative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - -Authors' Addresses - - Michael Graff - Internet Systems Consortium - 950 Charter Street - Redwood City, California 94063 - US - - Phone: +1 650.423.1304 - Email: mgraff@isc.org - - - - - - - - - - -Graff & Vixie Expires January 29, 2010 [Page 10] - -Internet-Draft EDNS0 Extensions July 2009 - - - Paul Vixie - Internet Systems Consortium - 950 Charter Street - Redwood City, California 94063 - US - - Phone: +1 650.423.1301 - Email: vixie@isc.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Graff & Vixie Expires January 29, 2010 [Page 11] - diff --git a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-18.txt b/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-18.txt deleted file mode 100644 index 3b9a35aeaf7..00000000000 --- a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-18.txt +++ /dev/null @@ -1,953 +0,0 @@ - - - -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] - - diff --git a/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt b/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt deleted file mode 100644 index ee35cb91af8..00000000000 --- a/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -INTERNET-DRAFT A. Gustafsson - Araneus Information Systems Oy - September 23, 2009 - -Intended status: Draft Standard -Obsoletes: RFC3597 - - Handling of Unknown DNS Resource Record (RR) Types - draft-ietf-dnsext-rfc3597-bis-00.txt - -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/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - -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 - - Extending the Domain Name System (DNS) with new Resource Record (RR) - types should not requires changes to name server software. This - document specifies how new RR types are transparently handled by DNS - software. - - - - -Expires March 2010 Standards Track [Page 1] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - -1. Introduction - - The DNS [RFC1034] is designed to be extensible to support new - services through the introduction of new resource record (RR) types. - Nevertheless, DNS implementations have historically required software - changes to support new RR types, not only at the authoritative DNS - server providing the new information and the client making use of it, - but also at all slave servers for the zone containing it, and in some - cases also at caching name servers and forwarders used by the client. - Because the deployment of new DNS software is slow and expensive, - this has been a significant impediment to supporting new services in - the DNS. - - [RFC3597] defined DNS implementation behavior and procedures for - defining new RR types aimed at simplifying the deployment of new RR - types by allowing them to be treated transparently by existing - implementations. Thanks to the widespread adoption of that - specification, much of the DNS is now capable of handling new record - types without software changes. - - This document is a self-contained revised specification supplanting - and obsoleting [RFC3597]. - -2. Definitions - - 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]. - - An "RR of unknown type" is an RR whose RDATA format is not known to - the DNS implementation at hand, and whose type is not an assigned - QTYPE or Meta-TYPE as specified in [RFC5395] (section 3.1) nor within - the range reserved in that section for assignment only to QTYPEs and - Meta-TYPEs. Such an RR cannot be converted to a type-specific text - format, compressed, or otherwise handled in a type-specific way. - - In the case of a type whose RDATA format is class specific, an RR is - considered to be of unknown type when the RDATA format for that - combination of type and class is not known. - -3. Transparency - - To enable new RR types to be deployed without server changes, name - servers and resolvers MUST handle RRs of unknown type transparently. - That is, they must treat the RDATA section of such RRs as - unstructured binary data, storing and transmitting it without change - [RFC1123]. - - - - -Expires March 2010 Standards Track [Page 2] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - - To ensure the correct operation of equality comparison (section 6) - and of the DNSSEC canonical form (section 7) when an RR type is known - to some but not all of the servers involved, servers MUST also - exactly preserve the RDATA of RRs of known type, except for changes - due to compression or decompression where allowed by section 4 of - this document. In particular, the character case of domain names - that are not subject to compression MUST be preserved. - -4. Domain Name Compression - - RRs containing compression pointers in the RDATA part cannot be - treated transparently, as the compression pointers are only - meaningful within the context of a DNS message. Transparently - copying the RDATA into a new DNS message would cause the compression - pointers to point at the corresponding location in the new message, - which now contains unrelated data. This would cause the compressed - name to be corrupted. - - To avoid such corruption, servers MUST NOT compress domain names - embedded in the RDATA of types that are class-specific or not well- - known. This requirement was stated in [RFC1123] without defining the - term "well-known"; it is hereby specified that only the RR types - defined in [RFC1035] are to be considered "well-known". - - Receiving servers MUST decompress domain names in RRs of well-known - type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX, - NXT, NAPTR, and SRV to ensure interoperability with implementations - predating [RFC3597]. - - Specifications for new RR types that contain domain names within - their RDATA MUST NOT allow the use of name compression for those - names, and SHOULD explicitly state that the embedded domain names - MUST NOT be compressed. - - As noted in [RFC1123], the owner name of an RR is always eligible for - compression. - -5. Text Representation - - In the "type" field of a master file line, an unknown RR type is - represented by the word "TYPE" immediately followed by the decimal RR - type number, with no intervening whitespace. In the "class" field, - an unknown class is similarly represented as the word "CLASS" - immediately followed by the decimal class number. - - This convention allows types and classes to be distinguished from - each other and from TTL values, allowing the "[] [] - " and "[] [] " forms of - - - -Expires March 2010 Standards Track [Page 3] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - - [RFC1035] to both be unambiguously parsed. - - The RDATA section of an RR of unknown type is represented as a - sequence of white space separated words as follows: - - The special token \# (a backslash immediately followed by a hash - sign), which identifies the RDATA as having the generic encoding - defined herein rather than a traditional type-specific encoding. - - An unsigned decimal integer specifying the RDATA length in octets. - - Zero or more words of hexadecimal data encoding the actual RDATA - field, each containing an even number of hexadecimal digits. - - If the RDATA is of zero length, the text representation contains only - the \# token and the single zero representing the length. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Expires March 2010 Standards Track [Page 4] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - - An implementation MAY also choose to represent some RRs of known type - using the above generic representations for the type, class and/or - RDATA, which carries the benefit of making the resulting master file - portable to servers where these types are unknown. Using the generic - representation for the RDATA of an RR of known type can also be - useful in the case of an RR type where the text format varies - depending on a version, protocol, or similar field (or several) - embedded in the RDATA when such a field has a value for which no text - format is known, e.g., a LOC RR [RFC1876] with a VERSION other than - 0. - - Even though an RR of known type represented in the \# format is - effectively treated as an unknown type for the purpose of parsing the - RDATA text representation, all further processing by the server MUST - treat it as a known type and take into account any applicable type- - specific rules regarding compression, canonicalization, etc. - - The following are examples of RRs represented in this manner, - illustrating various combinations of generic and type-specific - encodings for the different fields of the master file format: - - a.example. CLASS32 TYPE731 \# 6 abcd ( - ef 01 23 45 ) - b.example. HS TYPE62347 \# 0 - e.example. IN A \# 4 C0000201 - e.example. CLASS1 TYPE1 192.0.2.1 - -6. Equality Comparison - - Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs - to be compared for equality. Two RRs of the same unknown type are - considered equal when their RDATA is bitwise equal. To ensure that - the outcome of the comparison is identical whether the RR is known to - the server or not, specifications for new RR types MUST NOT specify - type-specific comparison rules. - - This implies that embedded domain names, being included in the - overall bitwise comparison, are compared in a case-sensitive manner. - - As a result, when a new RR type contains one or more embedded domain - names, it is possible to have multiple RRs owned by the same name - that differ only in the character case of the embedded domain - name(s). This is similar to the existing possibility of multiple TXT - records differing only in character case, and not expected to cause - any problems in practice. - - - - - - -Expires March 2010 Standards Track [Page 5] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - -7. DNSSEC Considerations - - The rules for the DNSSEC canonical form and ordering were updated to - support transparent treatment of unknown types in [RFC3597]. Those - updates have subsequently been integrated into the base DNSSEC - specification, such that the DNSSEC canonical form and ordering are - now specified in [RFC4034] or its successors rather than in this - document. - -8. Additional Section Processing - - Unknown RR types cause no additional section processing. Future RR - type specifications MAY specify type-specific additional section - processing rules, but any such processing MUST be optional as it can - only be performed by servers for which the RR type in case is known. - -9. IANA Considerations - - This document does not require any IANA actions. - -10. Security Considerations - - This specification is not believed to cause any new security - problems, nor to solve any existing ones. - -11. Normative References - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specifications", STD 13, RFC 1035, November 1987. - - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -- - Application and Support", STD 3, RFC 1123, October 1989. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA - Considerations", BCP 42, RFC 5395, November 2008. - -12. Informative References - - [RFC1876] Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A - Means for Expressing Location Information in the Domain - Name System", RFC 1876, January 1996. - - - - -Expires March 2010 Standards Track [Page 6] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - - [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - -14. Author's Address - - Andreas Gustafsson - Araneus Information Systems Oy - PL 110 - 02321 Espoo - Finland - - Phone: +358 40 547 2099 - EMail: gson@araneus.fi - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Expires March 2010 Standards Track [Page 7] - diff --git a/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt b/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt deleted file mode 100644 index 72d38aa267a..00000000000 --- a/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt +++ /dev/null @@ -1,336 +0,0 @@ - - - -DNSext Working Group F. Dupont -Internet-Draft ISC -Updates: 2845,2930,4635 May 8, 2009 -(if approved) -Intended status: Standards Track -Expires: November 9, 2009 - - - Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records - draft-ietf-dnsext-tsig-md5-deprecated-03.txt - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. 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. - - 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 November 9, 2009. - -Copyright Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - - -Dupont Expires November 9, 2009 [Page 1] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - - 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 - - The main purpose of this document is to deprecate the use of HMAC-MD5 - as an algorithm for the TSIG (secret key transaction authentication) - resource record in the DNS (domain name system), and the use of MD5 - in TKEY (secret key establishment for DNS). - - -1. Introduction - - The secret key transaction authentication for DNS (TSIG, [RFC2845]) - was defined with the HMAC-MD5 [RFC2104] cryptographic algorithm. - When the MD5 [RFC1321] security came to be considered lower than - expected, [RFC4635] standardized new TSIG algorithms based on SHA - [RFC3174][RFC3874][RFC4634] digests. - - But [RFC4635] did not deprecate the HMAC-MD5 algorithm. This - document is targeted to complete the process, in detail: - 1. Mark HMAC-MD5.SIG-ALG.REG.INT as optional in the TSIG algorithm - name registry managed by the IANA under the IETF Review Policy - [RFC5226] - 2. Make HMAC-MD5.SIG-ALG.REG.INT support "not Mandatory" for - implementations - 3. Provide a keying material derivation for the secret key - establishment for DNS (TKEY, [RFC2930]) using a Diffie-Hellman - exchange with SHA256 [RFC4634] in place of MD5 [RFC1321] - 4. Finally recommend the use of HMAC-SHA256. - - 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]. - - -2. Implementation Requirements - - The table of section 3 of [RFC4635] is replaced by: - - - - - - - - - -Dupont Expires November 9, 2009 [Page 2] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - - +-------------------+--------------------------+ - | Requirement Level | Algorithm Name | - +-------------------+--------------------------+ - | Optional | HMAC-MD5.SIG-ALG.REG.INT | - | Optional | gss-tsig | - | Mandatory | hmac-sha1 | - | Optional | hmac-sha224 | - | Mandatory | hmac-sha256 | - | Optional | hmac-sha384 | - | Optional | hmac-sha512 | - +-------------------+--------------------------+ - - Implementations that support TSIG MUST also implement HMAC-SHA1 and - HMAC-SHA256 (i.e., algorithms at the "Mandatory" requirement level) - and MAY implement GSS-TSIG and the other algorithms listed above - (i.e., algorithms at a "not Mandatory" requirement level). - - -3. TKEY keying material derivation - - When the TKEY [RFC2930] uses a Diffie-Hellman exchange, the keying - material is derived from the shared secret and TKEY resource record - data using MD5 [RFC1321] at the end of section 4.1 page 9. - - This is amended into: - - keying material = - XOR ( DH value, SHA256 ( query data | DH value ) | - SHA256 ( server data | DH value ) ) - - using the same conventions. - - -4. IANA Consideration - - This document extends the "TSIG Algorithm Names - per [] and - [RFC2845]" located at - http://www.iana.org/assignments/tsig-algorithm-names by adding a new - column to the registry "Compliance Requirement". - - The registry should contain the following: - - - - - - - - - - -Dupont Expires November 9, 2009 [Page 3] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - - +--------------------------+------------------------+-------------+ - | Algorithm Name | Compliance Requirement | Reference | - +--------------------------+------------------------+-------------+ - | gss-tsig | Optional | [RFC3645] | - | HMAC-MD5.SIG-ALG.REG.INT | Optional | [][RFC2845] | - | hmac-sha1 | Mandatory | [RFC4635] | - | hmac-sha224 | Optional | [RFC4635] | - | hmac-sha256 | Mandatory | [RFC4635] | - | hmac-sha384 | Optional | [RFC4635] | - | hmac-sha512 | Optional | [RFC4635] | - +--------------------------+------------------------+-------------+ - - where [] is this document. - - -5. Availability Considerations - - MD5 is no longer universally available and its use may lead to - increasing operation issues. SHA1 is likely to suffer from the same - kind of problem. In summary MD5 has reached end-of-life and SHA1 - will likely follow in the near term. - - According to [RFC4635], implementations which support TSIG are - REQUIRED to implement HMAC-SHA256. - - -6. Security Considerations - - This document does not assume anything about the cryptographic - security of different hash algorithms. Its purpose is a better - availability of some security mechanisms in a predictable time frame. - - Requirement levels are adjusted for TSIG and related specifications - (i.e., TKEY): - The support of HMAC-MD5 is changed from mandatory to optional. - The use of MD5 and HMAC-MD5 is NOT RECOMMENDED. - The use of HMAC-SHA256 is RECOMMENDED. - - -7. Acknowledgments - - Olafur Gudmundsson kindly helped in the procedure to deprecate the - MD5 use in TSIG, i.e., the procedure which led to this memo. Alfred - Hoenes, Peter Koch, Paul Hoffman and Edward Lewis proposed some - improvements. - - -8. References - - - -Dupont Expires November 9, 2009 [Page 4] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, BCP 14, March 1997. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC4635] Eastlake, D., "HMAC SHA TSIG Algorithm Identifiers", - RFC 4635, August 2006. - -8.2. Informative References - - [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. - - [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, - February 1997. - - [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 - (SHA1)", RFC 3174, September 2001. - - [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., - and R. Hall, "Generic Security Service Algorithm for - Secret Key Transaction Authentication for DNS (GSS-TSIG)", - RFC 3645, October 2003. - - [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", - RFC 3874, September 2004. - - [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms - (SHA and HMAC-SHA)", RFC 4634, July 2006. - - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", RFC 5226, BCP 26, - May 2008. - - - - - - - - - - -Dupont Expires November 9, 2009 [Page 5] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - -Author's Address - - Francis Dupont - ISC - - Email: Francis.Dupont@fdupont.fr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Dupont Expires November 9, 2009 [Page 6] - diff --git a/doc/draft/draft-ietf-dnsop-default-local-zones-09.txt b/doc/draft/draft-ietf-dnsop-default-local-zones-09.txt deleted file mode 100644 index 7e81e4c4bf5..00000000000 --- a/doc/draft/draft-ietf-dnsop-default-local-zones-09.txt +++ /dev/null @@ -1,729 +0,0 @@ - - - -Network Working Group M. Andrews -Internet-Draft ISC -Intended status: BCP November 19, 2009 -Expires: May 23, 2010 - - - Locally-served DNS Zones - draft-ietf-dnsop-default-local-zones-09 - -Abstract - - Experience with the Domain Name System (DNS) has shown that there are - a number of DNS zones all iterative resolvers and recursive - nameservers should automatically serve, unless configured otherwise. - RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This - document extends the practice to cover the IN-ADDR.ARPA zones for RFC - 1918 address space and other well known zones with similar - characteristics. - -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 23, 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 - - - -Andrews Expires May 23, 2010 [Page 1] - -Internet-Draft Locally-served DNS Zones November 2009 - - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Andrews Expires May 23, 2010 [Page 2] - -Internet-Draft Locally-served DNS Zones November 2009 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Effects on sites using RFC 1918 addresses. . . . . . . . . . . 4 - 3. Changes to Iterative Resolver Behaviour. . . . . . . . . . . . 4 - 4. Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . . 5 - 4.1. RFC1918 Zones . . . . . . . . . . . . . . . . . . . . . . 5 - 4.2. RFC3330 Zones . . . . . . . . . . . . . . . . . . . . . . 6 - 4.3. Local IPv6 Unicast Addresses . . . . . . . . . . . . . . . 6 - 4.4. IPv6 Locally Assigned Local Addresses . . . . . . . . . . 6 - 4.5. IPv6 Link Local Addresses . . . . . . . . . . . . . . . . 7 - 4.6. IPv6 Example Prefix . . . . . . . . . . . . . . . . . . . 7 - 5. Zones that are Out-Of-Scope . . . . . . . . . . . . . . . . . 7 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 - Appendix A. Change History [To Be Removed on Publication] . . . . 10 - A.1. draft-ietf-dnsop-default-local-zones-09.txt . . . . . . . 10 - A.2. draft-ietf-dnsop-default-local-zones-08.txt . . . . . . . 10 - A.3. draft-ietf-dnsop-default-local-zones-07.txt . . . . . . . 10 - A.4. draft-ietf-dnsop-default-local-zones-06.txt . . . . . . . 10 - A.5. draft-ietf-dnsop-default-local-zones-05.txt . . . . . . . 11 - A.6. draft-ietf-dnsop-default-local-zones-04.txt . . . . . . . 11 - A.7. draft-ietf-dnsop-default-local-zones-03.txt . . . . . . . 11 - A.8. draft-ietf-dnsop-default-local-zones-02.txt . . . . . . . 11 - A.9. draft-ietf-dnsop-default-local-zones-01.txt . . . . . . . 11 - A.10. draft-ietf-dnsop-default-local-zones-00.txt . . . . . . . 11 - A.11. draft-andrews-full-service-resolvers-03.txt . . . . . . . 11 - A.12. draft-andrews-full-service-resolvers-02.txt . . . . . . . 12 - Appendix B. Proposed Status [To Be Removed on Publication] . . . 12 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 - - - - - - - - - - - - - - - - -Andrews Expires May 23, 2010 [Page 3] - -Internet-Draft Locally-served DNS Zones November 2009 - - -1. Introduction - - Experience with the Domain Name System (DNS, [RFC1034] and [RFC1035]) - has shown that there are a number of DNS zones that all iterative - resolvers and recursive nameservers SHOULD automatically serve, - unless intentionally configured otherwise. These zones include, but - are not limited to, the IN-ADDR.ARPA zones for the address space - allocated by [RFC1918] and the IP6.ARPA zones for locally assigned - unique local IPv6 addresses defined in [RFC4193]. - - This recommendation is made because data has shown that significant - leakage of queries for these name spaces is occurring, despite - instructions to restrict them, and because it has therefore become - necessary to deploy sacrificial name servers to protect the immediate - parent name servers for these zones from excessive, unintentional, - query load [AS112] [I-D.draft-ietf-dnsop-as112-ops] - [I-D.draft-ietf-dnsop-as112-under-attack-help-help]. There is every - expectation that the query load will continue to increase unless - steps are taken as outlined here. - - Additionally, queries from clients behind badly configured firewalls - that allow outgoing queries for these name spaces but drop the - responses, put a significant load on the root servers (forward but no - reverse zones configured). They also cause operational load for the - root server operators as they have to reply to enquiries about why - the root servers are "attacking" these clients. Changing the default - configuration will address all these issues for the zones listed in - Section 4. - - [RFC4193] recommends that queries for D.F.IP6.ARPA be handled - locally. This document extends the recommendation to cover the IN- - ADDR.ARPA zones for [RFC1918] and other well known IN-ADDR.ARPA and - IP6.ARPA zones for which queries should not appear on the public - Internet. - - It is hoped that by doing this the number of sacrificial servers - [AS112] will not have to be increased, and may in time be reduced. - - This recommendation should also help DNS responsiveness for sites - which are using [RFC1918] addresses but do not follow the last - paragraph in Section 3 of [RFC1918]. - -1.1. Reserved Words - - 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]. - - - - -Andrews Expires May 23, 2010 [Page 4] - -Internet-Draft Locally-served DNS Zones November 2009 - - -2. Effects on sites using RFC 1918 addresses. - - For most sites using [RFC1918] addresses, the changes here will have - little or no detrimental effect. If the site does not already have - the reverse tree populated the only effect will be that the name - error responses will be generated locally rather than remotely. - - For sites that do have the reverse tree populated, most will either - have a local copy of the zones or will be forwarding the queries to - servers which have local copies of the zone. Therefore this - recommendation will not be relevant. - - The most significant impact will be felt at sites that make use of - delegations for [RFC1918] addresses and have populated these zones. - These sites will need to override the default configuration expressed - in this document to allow resolution to continue. Typically, such - sites will be fully disconnected from the Internet and have their own - root servers for their own non-Internet DNS tree. - - -3. Changes to Iterative Resolver Behaviour. - - Unless configured otherwise, an iterative resolver will now return - authoritatively (aa=1) name errors (RCODE=3) for queries within the - zones in Section 4, with the obvious exception of queries for the - zone name itself where SOA, NS and "no data" responses will be - returned as appropriate to the query type. One common way to do this - all at once is to serve empty (SOA and NS only) zones. - - An implementation of this recommendation MUST provide a mechanism to - disable this new behaviour, and SHOULD allow this decision on a zone - by zone basis. - - If using empty zones one SHOULD NOT use the same NS and SOA records - as used on the public Internet servers as that will make it harder to - detect the origin of the responses and thus any leakage to the public - Internet servers. This document recommends that the NS record - defaults to the name of the zone and the SOA MNAME defaults to the - name of the only NS RR's target. The SOA RNAME should default to - "nobody.invalid." [RFC2606]. Implementations SHOULD provide a - mechanism to set these values. No address records need to be - provided for the name server. - - Below is an example of a generic empty zone in master file format. - It will produce a negative cache TTL of 3 hours. - - @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800 - @ 10800 IN NS @ - - - -Andrews Expires May 23, 2010 [Page 5] - -Internet-Draft Locally-served DNS Zones November 2009 - - - The SOA RR is needed to support negative caching [RFC2308] of name - error responses and to point clients to the primary master for DNS - dynamic updates. - - SOA values of particular importance are the MNAME, the SOA RR's TTL - and the negTTL value. Both TTL values SHOULD match. The rest of the - SOA timer values MAY be chosen arbitrarily since they are not - intended to control any zone transfer activity. - - The NS RR is needed as some UPDATE [RFC2136] clients use NS queries - to discover the zone to be updated. Having no address records for - the name server is expected to abort UPDATE processing in the client. - - -4. Lists Of Zones Covered - - The following subsections are intended to seed the IANA registry as - requested in the IANA Considerations Section. The zone name is the - entity to be registered. - -4.1. RFC1918 Zones - - The following zones correspond to the IPv4 address space reserved in - [RFC1918]. - - +----------------------+ - | Zone | - +----------------------+ - | 10.IN-ADDR.ARPA | - | 16.172.IN-ADDR.ARPA | - | 17.172.IN-ADDR.ARPA | - | 18.172.IN-ADDR.ARPA | - | 19.172.IN-ADDR.ARPA | - | 20.172.IN-ADDR.ARPA | - | 21.172.IN-ADDR.ARPA | - | 22.172.IN-ADDR.ARPA | - | 23.172.IN-ADDR.ARPA | - | 24.172.IN-ADDR.ARPA | - | 25.172.IN-ADDR.ARPA | - | 26.172.IN-ADDR.ARPA | - | 27.172.IN-ADDR.ARPA | - | 28.172.IN-ADDR.ARPA | - | 29.172.IN-ADDR.ARPA | - | 30.172.IN-ADDR.ARPA | - | 31.172.IN-ADDR.ARPA | - | 168.192.IN-ADDR.ARPA | - +----------------------+ - - - - -Andrews Expires May 23, 2010 [Page 6] - -Internet-Draft Locally-served DNS Zones November 2009 - - -4.2. RFC3330 Zones - - The following zones correspond to those address ranges from [RFC3330] - that are not expected to appear as source or destination addresses on - the public Internet and to not have a unique name to associate with. - - The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a - attempt to discourage any practice to provide a PTR RR for - 1.0.0.127.IN-ADDR.ARPA locally. In fact, a meaningful reverse - mapping should exist, but the exact setup is out of the scope of this - document. Similar logic applies to the reverse mapping for ::1 - (Section 4.3). The recommendations made here simply assume no other - coverage for these domains exists. - - +------------------------------+------------------------+ - | Zone | Description | - +------------------------------+------------------------+ - | 0.IN-ADDR.ARPA | IPv4 "THIS" NETWORK | - | 127.IN-ADDR.ARPA | IPv4 LOOP-BACK NETWORK | - | 254.169.IN-ADDR.ARPA | IPv4 LINK LOCAL | - | 2.0.192.IN-ADDR.ARPA | IPv4 TEST NET | - | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST | - +------------------------------+------------------------+ - -4.3. Local IPv6 Unicast Addresses - - The reverse mappings ([RFC3596], Section 2.5 IP6.ARPA Domain) for the - IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC4291], - Sections 2.4, 2.5.2 and 2.5.3) are covered by these two zones: - - +-------------------------------------------+ - | Zone | - +-------------------------------------------+ - | 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ | - | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA | - | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ | - | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA | - +-------------------------------------------+ - - Note: Line breaks and a escapes '\' have been inserted above for - readability and to adhere to line width constraints. They are not - parts of the zone names. - -4.4. IPv6 Locally Assigned Local Addresses - - Section 4.4 of [RFC4193] already required special treatment of: - - - - - -Andrews Expires May 23, 2010 [Page 7] - -Internet-Draft Locally-served DNS Zones November 2009 - - - +--------------+ - | Zone | - +--------------+ - | D.F.IP6.ARPA | - +--------------+ - -4.5. IPv6 Link Local Addresses - - IPv6 Link-Local Addresses as of [RFC4291], Section 2.5.6 are covered - by four distinct reverse DNS zones: - - +----------------+ - | Zone | - +----------------+ - | 8.E.F.IP6.ARPA | - | 9.E.F.IP6.ARPA | - | A.E.F.IP6.ARPA | - | B.E.F.IP6.ARPA | - +----------------+ - -4.6. IPv6 Example Prefix - - IPv6 example prefix [RFC3849]. - - +--------------------------+ - | Zone | - +--------------------------+ - | 8.B.D.0.1.0.0.2.IP6.ARPA | - +--------------------------+ - - Note: 8.B.D.0.1.0.0.2.IP6.ARPA is not being used as a example here. - - -5. Zones that are Out-Of-Scope - - IPv6 site-local addresses (deprecated, see [RFC4291] Sections 2.4 and - 2.5.7), and IPv6 Non-Locally Assigned Local addresses ([RFC4193]) are - not covered here. - - It is expected that IPv6 site-local addresses will be self correcting - as IPv6 implementations remove support for site-local addresses. - However, sacrificial servers for the zones C.E.F.IP6.ARPA through - F.E.F.IP6.ARPA may still need to be deployed in the short term if the - traffic becomes excessive. - - For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC4193], - there has been no decision made about whether the Regional Internet - Registries (RIRs) will provide delegations in this space or not. If - - - -Andrews Expires May 23, 2010 [Page 8] - -Internet-Draft Locally-served DNS Zones November 2009 - - - they don't, then C.F.IP6.ARPA will need to be added to the list in - Section 4.4. If they do, then registries will need to take steps to - ensure that name servers are provided for these addresses. - - This document also ignores IP6.INT. IP6.INT has been wound up with - only legacy resolvers now generating reverse queries under IP6.INT - [RFC4159]. - - This document has also deliberately ignored names immediately under - the root domain. While there is a subset of queries to the root name - servers which could be addressed using the techniques described here - (e.g. .local, .workgroup and IPv4 addresses), there is also a vast - amount of traffic that requires a different strategy (e.g. lookups - for unqualified hostnames, IPv6 addresses). - - -6. IANA Considerations - - This document requests that IANA establish a registry of zones which - require this default behaviour. The initial contents of this - registry are defined in Section 4. Implementors are encouraged to - periodically check this registry and adjust their implementations to - reflect changes therein. - - This registry can be amended through "IETF Review" as per [RFC5226]. - - IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is - deployed in the reverse tree, delegations for these zones are made in - the manner described in Section 7. - - -7. Security Considerations - - During the initial deployment phase, particularly where [RFC1918] - addresses are in use, there may be some clients that unexpectedly - receive a name error rather than a PTR record. This may cause some - service disruption until their recursive name server(s) have been re- - configured. - - As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA - namespaces, the zones listed above will need to be delegated as - insecure delegations, or be within insecure zones. This will allow - DNSSEC validation to succeed for queries in these spaces despite not - being answered from the delegated servers. - - It is recommended that sites actively using these namespaces secure - them using DNSSEC [RFC4035] by publishing and using DNSSEC trust - anchors. This will protect the clients from accidental import of - - - -Andrews Expires May 23, 2010 [Page 9] - -Internet-Draft Locally-served DNS Zones November 2009 - - - unsigned responses from the Internet. - - -8. Acknowledgements - - This work was supported by the US National Science Foundation - (research grant SCI-0427144) and DNS-OARC. - - -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. - - [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., - and E. Lear, "Address Allocation for Private Internets", - BCP 5, RFC 1918, February 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., Thomson, A., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2398, March 1998. - - [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS - Names", BCP 32, RFC 2606, June 1999. - - [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, - "DNS Extensions to Support IPv6", RFC 3596, October 2003. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC4159] Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159, - August 2005. - - [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast - Addresses", RFC 4193, October 2005. - - - -Andrews Expires May 23, 2010 [Page 10] - -Internet-Draft Locally-served DNS Zones November 2009 - - - [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 4291, February 2006. - - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 5226, - October 2008. - -9.2. Informative References - - [AS112] "AS112 Project", . - - [I-D.draft-ietf-dnsop-as112-ops] - Abley, J. and W. Maton, "AS112 Nameserver Operations", - draft-ietf-dnsop-as112-ops-01 (work in progress), - November 2007. - - [I-D.draft-ietf-dnsop-as112-under-attack-help-help] - Abley, J. and W. Maton, "I'm Being Attacked by - PRISONER.IANA.ORG!", - draft-ietf-dnsop-as112-under-attack-help-help-01 (work in - progress), November 2007. - - [RFC3330] "Special-Use IPv4 Addresses", RFC 3330, September 2002. - - [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix - Reserved for Documentation", RFC 3849, July 2004. - - -Appendix A. Change History [To Be Removed on Publication] - -A.1. draft-ietf-dnsop-default-local-zones-09.txt - - refresh awaiting writeup - -A.2. draft-ietf-dnsop-default-local-zones-08.txt - - editorial, reference updates - -A.3. draft-ietf-dnsop-default-local-zones-07.txt - - none, expiry prevention - -A.4. draft-ietf-dnsop-default-local-zones-06.txt - - add IPv6 example prefix - - - - - - -Andrews Expires May 23, 2010 [Page 11] - -Internet-Draft Locally-served DNS Zones November 2009 - - -A.5. draft-ietf-dnsop-default-local-zones-05.txt - - none, expiry prevention - -A.6. draft-ietf-dnsop-default-local-zones-04.txt - - Centrally Assigned Local addresses -> Non-Locally Assigned Local - address - -A.7. draft-ietf-dnsop-default-local-zones-03.txt - - expanded section 4 descriptions - - Added references [RFC2136], [RFC3596], - [I-D.draft-ietf-dnsop-as112-ops] and - [I-D.draft-ietf-dnsop-as112-under-attack-help-help]. - - Revised language. - -A.8. draft-ietf-dnsop-default-local-zones-02.txt - - RNAME now "nobody.invalid." - - Revised language. - -A.9. draft-ietf-dnsop-default-local-zones-01.txt - - Revised impact description. - - Updated to reflect change in IP6.INT status. - -A.10. draft-ietf-dnsop-default-local-zones-00.txt - - Adopted by DNSOP. - - "Author's Note" re-titled "Zones that are Out-Of-Scope" - - Add note that these zone are expected to seed the IANA registry. - - Title changed. - -A.11. draft-andrews-full-service-resolvers-03.txt - - Added "Proposed Status". - - - - - - - -Andrews Expires May 23, 2010 [Page 12] - -Internet-Draft Locally-served DNS Zones November 2009 - - -A.12. draft-andrews-full-service-resolvers-02.txt - - Added 0.IN-ADDR.ARPA. - - -Appendix B. Proposed Status [To Be Removed on Publication] - - This Internet-Draft is being submitted for eventual publication as an - RFC with a proposed status of Best Current Practice. - - -Author's Address - - Mark P. Andrews - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - US - - Email: Mark_Andrews@isc.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Andrews Expires May 23, 2010 [Page 13] - - diff --git a/doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt b/doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt deleted file mode 100644 index f64e8dd572e..00000000000 --- a/doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt +++ /dev/null @@ -1,952 +0,0 @@ - - - -DNSOP W. Hardaker -Internet-Draft Sparta, Inc. -Intended status: Informational February 12, 2009 -Expires: August 16, 2009 - - - Requirements for Management of Name Servers for the DNS - draft-ietf-dnsop-name-server-management-reqs-02.txt - -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 August 16, 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. - -Abstract - - Management of name servers for the Domain Name Service (DNS) has - traditionally been done using vendor-specific monitoring, - - - -Hardaker Expires August 16, 2009 [Page 1] - -Internet-Draft Name Server Management Requirements February 2009 - - - configuration and control methods. Although some service monitoring - platforms can test the functionality of the DNS itself there is not a - interoperable way to manage (monitor, control and configure) the - internal aspects of a name server itself. - - This document discusses the requirements of a management system for - DNS name servers. A management solution that is designed to manage - the DNS can use this document as a shopping list of needed features. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 - 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5 - 1.1.2. Document Layout and Requirements . . . . . . . . . . . 5 - 2. Management Architecture Requirements . . . . . . . . . . . . . 5 - 2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5 - 2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 5 - 2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6 - 2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6 - 2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6 - 2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6 - 2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7 - 2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7 - 3. Management Operation Types . . . . . . . . . . . . . . . . . . 7 - 3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8 - 3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8 - 3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8 - 3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9 - 3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9 - 3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9 - 3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9 - 3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9 - 3.2.5. DNS Protocol Authorization Management . . . . . . . . 9 - 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10 - 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 10 - 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11 - 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11 - 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11 - 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11 - 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 11 - 4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12 - 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12 - 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12 - 5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13 - 5.1.2. Extension Identification . . . . . . . . . . . . . . . 13 - 5.1.3. Name-Space Collision Protection . . . . . . . . . . . 13 - - - -Hardaker Expires August 16, 2009 [Page 2] - -Internet-Draft Name Server Management Requirements February 2009 - - - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 13 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 - Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 15 - A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16 - A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16 - A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 16 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hardaker Expires August 16, 2009 [Page 3] - -Internet-Draft Name Server Management Requirements February 2009 - - -1. Introduction - - Management of name servers for the Domain Name Service (DNS) - [RFC1034] [RFC1035] has traditionally been done using vendor-specific - monitoring, configuration and control methods. Although some service - monitoring platforms can test the functionality of the DNS itself - there is not a interoperable way to manage (monitor, control and - configure) the internal aspects of a name server itself. - - Previous standardization work within the IETF resulted in the - creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed - to achieve significant implementation and deployment. The perceived - reasons behind the failure for the two MIB modules are further - documented in [RFC3197]. - - This document discusses the requirements of a management system for - DNS name servers. A management solution that is designed to manage - the DNS can use this document as a shopping list of needed features. - - Specifically out of scope for this document are requirements - associated with management of stub resolvers. It is not the intent - of this document to document stub resolver requirements, although - some of the requirements listed are applicable to stub resolvers as - well. - - Also out of scope for this document is management of the host or - other components of the host upon which the name server software is - running. This document only discusses requirements for managing the - name server component of a system. - - The task of creating a management system for managing DNS servers is - not expected to be a small one. It is likely that components of the - solution will need to be designed in parts over time and these - requirements take this into consideration. In particular, - Section 5.1 discusses the need for future extensibility of the base - management solution. This document is intended to be a road-map - towards a desired outcome and is not intended to define an "all-or- - nothing" system. Successful interoperable management of name servers - even in part is expected to be beneficial to network operators - compared to the entirely custom solutions that are used at the time - of this writing. - -1.1. Requirements notation - - 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]. - - - - -Hardaker Expires August 16, 2009 [Page 4] - -Internet-Draft Name Server Management Requirements February 2009 - - -1.1.1. Terminology - - This document is consistent with the terminology defined in Section 2 - of [RFC4033]. Additional terminology needed for this document is - described below: - - Name Server: When we are discussing servers that don't fall into a - more specific type of server category defined in other documents, - this document will refer to them generically as "name servers". - In particular "name servers" can be considered to be any valid - combination of authoritative, recursive, validating, or security- - aware. The more specific name server labels will be used when - this document refers only to a specific type of server. However, - the term "name server", in this document, will not include stub - resolvers. - -1.1.2. Document Layout and Requirements - - The document is written so that each numbered section will contain - only a single requirement if it contains one at all. Each - requirement will contain needed wording from the terminology - described in Section 1.1. Subsections, however, might exist with - additional related requirements. The document is laid out in this - way so that a specific requirement can be uniquely referred to using - the section number itself and the document version from which it - came. - - -2. Management Architecture Requirements - - This section discusses requirements that reflect the needs of the - expected deployment environments. - -2.1. Expected Deployment Scenarios - - DNS zones vary greatly in the type of content published within them. - Name Servers, too, are deployed with a wide variety of configurations - to support the diversity of the deployed content. It is important - that a management solution trying to meet the criteria specified in - this document consider supporting the largest number of potential - deployment cases as possible. Further deployment scenarios that are - not used as direct examples of specific requirements are listed in - Appendix A. - -2.1.1. Zone Size Constraints - - The management solution MUST support both name servers that are - serving a small number of potentially very large zones (e.g. Top - - - -Hardaker Expires August 16, 2009 [Page 5] - -Internet-Draft Name Server Management Requirements February 2009 - - - Level Domains (TLDs)) as well as name servers that are serving a very - large number of small zones. These scenarios are both commonly seen - deployments. - -2.1.2. Name Server Discovery - - Large enterprise network deployments may contain multiple name - servers operating within the boundaries of the enterprise network. - These name servers may each be serving multiple zones both in and out - of the parent enterprise's zone. Finding and managing large - quantities of name servers would be a useful feature of the resulting - management solution. The management solution MAY support the ability - to discover previously unknown instances of name servers operating - within a deployed network. - -2.1.3. Configuration Data Volatility - - Configuration data is defined as data that relates only to the - configuration of a server and the zones it serves. It specifically - does not include data from the zone contents that is served through - DNS itself. The solution MUST support servers that remain fairly - statically configured over time as well as servers that have numerous - zones being added and removed within an hour. Both of these - scenarios are also commonly seen deployments. - -2.1.4. Protocol Selection - - There are many requirements in this document for many different types - of management operations (see Section 3 for further details). It is - possible that no one protocol will ideally fill all the needs of the - requirements listed in this document and thus multiple protocols - might be needed to produce a completely functional management system. - Multiple protocols might be used to create the complete management - solution, but the number of protocols used SHOULD be reduced to a - reasonable minimum number. - -2.1.5. Common Data Model - - Defining a standardized protocol (or set of protocols) to use for - managing name servers would be a step forward in achieving an - interoperable management solution. However, just defining a protocol - to use by itself would not achieve the complete end goal of a - complete interoperable management solution. Devices also need to - represent their internal management interface using a common - management data model. The solution MUST create a common data model - that management stations can make use of when sending or collecting - data from a managed device so it can successfully manage equipment - from vendors as if they were generic DNS servers. This common data - - - -Hardaker Expires August 16, 2009 [Page 6] - -Internet-Draft Name Server Management Requirements February 2009 - - - model is needed for of the operations discussion in Section 3. Note - that this does not preclude the fact that name server vendors might - provide additional management infrastructure beyond a base management - specification, as discussed further in Section 5.1. - -2.1.6. Operational Impact - - It is impossible to add new features to an existing server (such as - the inclusion of a management infrastructure) and not impact the - existing service and/or server in some fashion. At a minimum, for - example, more memory, disk and/or CPU resources will be required to - implement a new management system. However, the impact to the - existing DNS service MUST be minimized since the DNS service itself - is still the primary service to be offered by the modified name - server. - -2.2. Name Server Types - - There are multiple ways in which name servers can be deployed. Name - servers can take on any of the following roles: - - o Master Servers - - o Slave Servers - - o Recursive Servers - - The management solution SHOULD support all of these types of name - servers as they are all equally important. Note that "Recursive - Servers" can be further broken down by the security sub-roles they - might implement, as defined in section 2 of [RFC4033]. These sub- - roles are also important to support within any management solution. - - As stated earlier, the management of stub resolvers is considered out - of scope for this documents. - - -3. Management Operation Types - - Management operations can traditionally be broken into four - categories: - - o Control - - o Configuration - - o Health and Monitoring - - - - -Hardaker Expires August 16, 2009 [Page 7] - -Internet-Draft Name Server Management Requirements February 2009 - - - o Alarms and Events - - This section discusses requirements for each of these four management - types in detail. - -3.1. Control Requirements - - The management solution MUST be capable of performing basic service - control operations. - -3.1.1. Needed Control Operations - - These operations SHOULD include, at a minimum, the following - operations: - - o Starting the name server - - o Reloading the service configuration - - o Reloading zone data - - o Restarting the name server - - o Stopping the name server - - Note that no restriction is placed on how the management system - implements these operations. In particular, at least "starting the - name server" will require a minimal management system component to - exist independently of the name server itself. - -3.1.2. Asynchronous Status Notifications - - Some control operations might take a long time to complete. As an - example, some name servers take a long time to perform reloads of - large zones. Because of these timing issues, the management solution - SHOULD take this into consideration and offer a mechanism to ease the - burden associated with awaiting the status of a long-running command. - This could, for example, result in the use of asynchronous - notifications for returning the status of a long-running task or it - might require the management station to poll for the status of a - given task using monitoring commands. These and other potential - solutions need to be evaluated carefully to select one that balances - the result delivery needs with the perceived implementation costs. - - Also, see the related discussion in Section 3.4 on notification - messages for supporting delivery of alarm and event messages. - - - - - -Hardaker Expires August 16, 2009 [Page 8] - -Internet-Draft Name Server Management Requirements February 2009 - - -3.2. Configuration Requirements - - Many features of name servers need to be configured before the server - can be considered functional. The management solution MUST be able - to provide name servers with configuration data. The most important - data to be configured, for example, is the served zone data itself. - -3.2.1. Served Zone Modification - - The ability to add, modify and delete zones being served by name - servers is needed. Although there are already solutions for zone - content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007], - AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that - might be used as part of the final management solution, the - management system SHOULD still be able to natively create a new zone - (with enough minimal data to allow the other mechanisms to function - as well) as well as delete a zone. This might be, for example, a - management operation that at least allows for the creation of the - initial SOA record for a new zone as that's the minimum amount of - zone data needed for the other operations to function. - -3.2.2. Trust Anchor Management - - The solution SHOULD support the ability to add, modify and delete - trust anchors that are used by DNS Security (DNSSEC) [RFC4033] - [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust - anchors might be configured using the data from the DNSKEY Resource - Records (RRs) themselves or by using Delegation Signer (DS) - fingerprints. - -3.2.3. Security Expectations - - DNSSEC Validating resolvers need to make policy decisions about the - requests being processed. For example, they need to be configured - with a list of zones expected to be secured by DNSSEC. The - management solution SHOULD be able to add, modify and delete - attributes of DNSSEC security policies. - -3.2.4. TSIG Key Management - - TSIG [RFC2845] allows transaction level authentication of DNS - traffic. The management solution SHOULD be able to add, modify and - delete TSIG keys known to the name server. - -3.2.5. DNS Protocol Authorization Management - - The management solution SHOULD have the ability to add, modify and - delete authorization settings for the DNS protocols itself. Do not - - - -Hardaker Expires August 16, 2009 [Page 9] - -Internet-Draft Name Server Management Requirements February 2009 - - - confuse this with the ability to manage the authorization associated - with the management protocol itself, which is discussed later in - Section 4.4. There are a number of authorization settings that are - used by a name server. Example authorization settings that the - solution might need to cover are: - - o Access to operations on zone data (e.g. DDNS) - - o Access to certain zone data from certain sources (e.g. from - particular network subnets) - - o Access to specific DNS protocol services (e.g. recursive service) - - Note: the above list is expected to be used as a collection of - examples and is not a complete list of needed authorization - protections. - -3.3. Monitoring Requirements - - Monitoring is the process of collecting aspects of the internal state - of a name server at a given moment in time. The solution MUST be - able to monitor the health of a name server to determine its - operational status, load and other internal attributes. Example - management tasks that the solution might need to cover are: - - o Number of requests sent, responses sent, average response latency - and other performance counters - - o Server status (e.g. "serving data", "starting up", "shutting - down", ...) - - o Access control violations - - o List of zones being served - - o Detailed statistics about clients interacting with the name server - (e.g. top 10 clients requesting data). - - Note: the above list is expected to be used as a collection of - examples and is not a complete list of needed monitoring operations. - In particular, some monitoring statistics are expected to be - computationally or resource expensive and are considered to be "nice - to haves" as opposed to "necessary to have". - -3.4. Alarm and Event Requirements - - Events occurring at the name server that trigger alarm notifications - can quickly inform a management station about critical issues. A - - - -Hardaker Expires August 16, 2009 [Page 10] - -Internet-Draft Name Server Management Requirements February 2009 - - - management solution SHOULD include support for delivery of alarm - conditions. - - Example alarm conditions might include: - - o The server's status is changing. (e.g it is starting up, reloading - configuration, restarting or shutting down) - - o A needed resource (e.g. memory or disk space) is exhausted or - nearing exhaustion - - o An authorization violation was detected - - o The server has not received any data traffic (e.g. DNS requests - or NOTIFYs) recently (AKA the "lonely warning"). This condition - might indicate a problem with its deployment. - - -4. Security Requirements - - The management solution will need to be appropriately secured against - attacks on the management infrastructure. - -4.1. Authentication - - The solution MUST support mutual authentication. The management - client needs to be assured that the management operations are being - transferred to and from the correct name server. The managed name - server needs to authenticate the system that is accessing the - management infrastructure within itself. - -4.2. Integrity Protection - - Management operations MUST be protected from modification while in - transit from the management client to the server. - -4.3. Confidentiality - - The management solution MUST support message confidentiality. The - potential transfer of sensitive configuration is expected (such as - TSIG keys or security policies). The solution does not, however, - necessarily need to provide confidentiality to data that would - normally be carried without confidentiality by the DNS system itself. - -4.4. Authorization - - The solution SHOULD be capable of providing a fine-grained - authorization model for any management protocols it introduces to the - - - -Hardaker Expires August 16, 2009 [Page 11] - -Internet-Draft Name Server Management Requirements February 2009 - - - completed system. This authorization differs from the authorization - previously discussed in Section 3.2.5 in that this requirement is - concerned solely with authorization of the management system itself. - - There are a number of authorization settings that might be used by a - managed system to determine whether the managing entity has - authorization to perform the given management task. Example - authorization settings that the solution might need to cover are: - - o Access to the configuration that specifies which zones are to be - served - - o Access to the management system infrastructure - - o Access to other control operations - - o Access to other configuration operations - - o Access to monitoring operations - - Note: the above list is expected to be used as a collection of - examples and is not a complete list of needed authorization - protections. - -4.5. Solution Impacts on Security - - The solution MUST minimize the security risks introduced to the - complete name server system. It is impossible to add new - infrastructure to a server and not impact the security in some - fashion as the introduction of a management protocol alone will - provide a new avenue for potential attack. Although the added - management benefits will be worth the increased risks, the solution - still needs to minimize this impact as much as possible. - - -5. Other Requirements - -5.1. Extensibility - - The management solution is expected to change and expand over time as - lessons are learned and new DNS features are deployed. Thus, the - solution MUST be flexible and be able to accommodate new future - management operations. The solution might, for example, make use of - protocol versioning or capability description exchanges to ensure - that management stations and name servers that weren't written to the - same specification version can still interoperate to the best of - their combined ability. - - - - -Hardaker Expires August 16, 2009 [Page 12] - -Internet-Draft Name Server Management Requirements February 2009 - - -5.1.1. Vendor Extensions - - It MUST be possible for vendors to extend the standardized management - model with vendor-specific extensions to support additional features - offered by their products. - -5.1.2. Extension Identification - - It MUST be possible for a management station to understand which - parts of returned data are specific to a given vendor or other - standardized extension. The data returned needs to be appropriately - marked through the use of name spaces or similar mechanisms to ensure - that the base management model data can be logically separated from - extension data without needing to understand the extension data - itself. - -5.1.3. Name-Space Collision Protection - - It MUST be possible to protect against multiple extensions - conflicting with each other. The use of name-space protection - mechanisms for communicated management variables is common practice - to protect against problems. Name-space identification techniques - also frequently solve the "Extension Identification" requirement - discussed in Section 5.1.2 as well. - - -6. Security Considerations - - Any management protocol that meets the criteria discussed in this - document needs to support the criteria discussed in Section 4 in - order to protect the management infrastructure itself. The DNS is a - core Internet service and management traffic that protects it could - be the target of attacks designed to subvert that service. Because - the management infrastructure will be adding additional interfaces to - that service, it is critical that the management infrastructure - support adequate protections against network attacks. - - -7. IANA Considerations - - No action is required from IANA for this document. - - -8. Document History - - A requirement gathering discussion was held at the December 2007 IETF - meeting in Vancouver, BC, Canada and a follow up meeting was held at - the March 2008 IETF meeting in Philadelphia. This document is a - - - -Hardaker Expires August 16, 2009 [Page 13] - -Internet-Draft Name Server Management Requirements February 2009 - - - compilation of the results of those discussions as well as - discussions on the DCOMA mailing list. - - -9. Acknowledgments - - This draft is the result of discussions within the DCOMA design team - chaired by Jaap Akkerhuis. This team consisted of a large number of - people all of whom provided valuable insight and input into the - discussions surrounding name server management. The text of this - document was written from notes taken during meetings as well as from - contributions sent to the DCOMA mailing list. This work documents - the consensus of the DCOMA design team. - - In particular, the following team members contributed significantly - to the text in the document: - - Stephane Bortzmeyer - - Stephen Morris - - Phil Regnauld - - Further editing contributions and wording suggestions were made by: - Alfred Hoenes. - - -10. References - -10.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. - - [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, - August 1996. - - [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)", - RFC 2136, April 1997. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. - - - -Hardaker Expires August 16, 2009 [Page 14] - -Internet-Draft Name Server Management Requirements February 2009 - - - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [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. - - [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer - (DS) Resource Records (RRs)", RFC 4509, May 2006. - - [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) - Trust Anchors", RFC 5011, September 2007. - - [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS - Security (DNSSEC) Hashed Authenticated Denial of - Existence", RFC 5155, March 2008. - -10.2. Informative References - - [RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions", - RFC 1611, May 1994. - - [RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions", - RFC 1612, May 1994. - - [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection - and Operation of Secondary DNS Servers", BCP 16, RFC 2182, - July 1997. - - [RFC3197] Austein, R., "Applicability Statement for DNS MIB - Extensions", RFC 3197, November 2001. - - -Appendix A. Deployment Scenarios - - This appendix documents some additional deployment scenarios that - have been traditionally difficult to manage. They are provided as - - - -Hardaker Expires August 16, 2009 [Page 15] - -Internet-Draft Name Server Management Requirements February 2009 - - - guidance to protocol developers as data points of real-world name - server management problems. - -A.1. Non-Standard Zones - - If an organization uses non-standard zones (for example a purely- - local TLD), synchronizing all the name servers for these zones is - usually a time-consuming task. It is made worse when two - organizations with conflicting zones merge. This situation is not a - recommended deployment scenario (and is even heavily discouraged) but - it is, unfortunately, seen in the wild. - - It is typically implemented using "forwarding" zones. But there is - no way to ensure automatically that all the resolvers have the same - set of zones to forward at any given time. New zones might be added - to a local forwarding recursive server, for example, without - modifying the rest of the deployed forwarding servers. It is hoped - that a management solution which could handle the configuration of - zone forwarding would finally allow management of servers deployed in - this fashion. - -A.2. Redundancy Sharing - - For reliability reasons it is recommended that zone operators follow - the guidelines documented in [RFC2182] which recommends that multiple - name servers be configured for each zone and that the name servers - are separated both physically and via connectivity routes. A common - solution is to establish DNS-serving partnerships: "I'll host your - zones and you'll host mine". Both entities benefit from increased - DNS reliability via the wider service distribution. This frequently - occurs between cooperating but otherwise unrelated entities (such as - between two distinct companies) as well as between affiliated - organizations (such as between branch offices within a single - company). - - The configuration of these relationships are currently required to be - manually configured and maintained. Changes to the list of zones - that are cross-hosted are manually negotiated between the cooperating - network administrators and configured by hand. A management protocol - with the ability to provide selective authorization, as discussed in - Section 4.4, would solve many of the management difficulties between - cooperating organizations. - -A.3. DNSSEC Management - - There are many different DNSSEC deployment strategies that may be - used for mission-critical zones. The following list describes some - example deployment scenarios that might warrant different management - - - -Hardaker Expires August 16, 2009 [Page 16] - -Internet-Draft Name Server Management Requirements February 2009 - - - strategies. - - All contents and DNSSEC keying information controlled and operated - by a single organization - - Zone contents controlled and operated by one organization, all - DNSSEC keying information controlled and operated by a second - organization. - - Zone contents controlled and operated by one organization, zone - signing keys (ZSKs) controlled and operated by a second - organization, and key signing keys (KSKs) controlled and operated - by a third organization. - - Although this list is not exhaustive in the potential ways that zone - data can be divided up, it should be sufficient to illustrate the - potential ways in which zone data can be controlled by multiple - entities. - - The end result of all of these strategies, however, will be the same: - a live zone containing DNSSEC related resource records. Many of the - above strategies are merely different ways of preparing a zone for - serving. A management solution that includes support for managing - DNSSEC zone data may wish to take into account these potential - management scenarios. - - -Author's Address - - Wes Hardaker - Sparta, Inc. - P.O. Box 382 - Davis, CA 95617 - US - - Phone: +1 530 792 1913 - Email: ietf@hardakers.net - - - - - - - - - - - - - - -Hardaker Expires August 16, 2009 [Page 17] - diff --git a/doc/rfc/rfc1912.txt b/doc/rfc/rfc1912.txt deleted file mode 100644 index 8ace7d26748..00000000000 --- a/doc/rfc/rfc1912.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -Network Working Group D. Barr -Request for Comments: 1912 The Pennsylvania State University -Obsoletes: 1537 February 1996 -Category: Informational - - - Common DNS Operational and Configuration Errors - -Status of this Memo - - This memo provides information for the Internet community. This memo - does not specify an Internet standard of any kind. Distribution of - this memo is unlimited. - -Abstract - - This memo describes errors often found in both the operation of - Domain Name System (DNS) servers, and in the data that these DNS - servers contain. This memo tries to summarize current Internet - requirements as well as common practice in the operation and - configuration of the DNS. This memo also tries to summarize or - expand upon issues raised in [RFC 1537]. - -1. Introduction - - Running a nameserver is not a trivial task. There are many things - that can go wrong, and many decisions have to be made about what data - to put in the DNS and how to set up servers. This memo attempts to - address many of the common mistakes and pitfalls that are made in DNS - data as well as in the operation of nameservers. Discussions are - also made regarding some other relevant issues such as server or - resolver bugs, and a few political issues with respect to the - operation of DNS on the Internet. - -2. DNS Data - - This section discusses problems people typically have with the DNS - data in their nameserver, as found in the zone data files that the - nameserver loads into memory. - -2.1 Inconsistent, Missing, or Bad Data - - Every Internet-reachable host should have a name. The consequences - of this are becoming more and more obvious. Many services available - on the Internet will not talk to you if you aren't correctly - registered in the DNS. - - - - - -Barr Informational [Page 1] - -RFC 1912 Common DNS Errors February 1996 - - - Make sure your PTR and A records match. For every IP address, there - should be a matching PTR record in the in-addr.arpa domain. If a - host is multi-homed, (more than one IP address) make sure that all IP - addresses have a corresponding PTR record (not just the first one). - Failure to have matching PTR and A records can cause loss of Internet - services similar to not being registered in the DNS at all. Also, - PTR records must point back to a valid A record, not a alias defined - by a CNAME. It is highly recommended that you use some software - which automates this checking, or generate your DNS data from a - database which automatically creates consistent data. - - DNS domain names consist of "labels" separated by single dots. The - DNS is very liberal in its rules for the allowable characters in a - domain name. However, if a domain name is used to name a host, it - should follow rules restricting host names. Further if a name is - used for mail, it must follow the naming rules for names in mail - addresses. - - Allowable characters in a label for a host name are only ASCII - letters, digits, and the `-' character. Labels may not be all - numbers, but may have a leading digit (e.g., 3com.com). Labels must - end and begin only with a letter or digit. See [RFC 1035] and [RFC - 1123]. (Labels were initially restricted in [RFC 1035] to start with - a letter, and some older hosts still reportedly have problems with - the relaxation in [RFC 1123].) Note there are some Internet - hostnames which violate this rule (411.org, 1776.com). The presence - of underscores in a label is allowed in [RFC 1033], except [RFC 1033] - is informational only and was not defining a standard. There is at - least one popular TCP/IP implementation which currently refuses to - talk to hosts named with underscores in them. It must be noted that - the language in [1035] is such that these rules are voluntary -- they - are there for those who wish to minimize problems. Note that the - rules for Internet host names also apply to hosts and addresses used - in SMTP (See RFC 821). - - If a domain name is to be used for mail (not involving SMTP), it must - follow the rules for mail in [RFC 822], which is actually more - liberal than the above rules. Labels for mail can be any ASCII - character except "specials", control characters, and whitespace - characters. "Specials" are specific symbols used in the parsing of - addresses. They are the characters "()<>@,;:\".[]". (The "!" - character wasn't in [RFC 822], however it also shouldn't be used due - to the conflict with UUCP mail as defined in RFC 976) However, since - today almost all names which are used for mail on the Internet are - also names used for hostnames, one rarely sees addresses using these - relaxed standard, but mail software should be made liberal and robust - enough to accept them. - - - - -Barr Informational [Page 2] - -RFC 1912 Common DNS Errors February 1996 - - - You should also be careful to not have addresses which are valid - alternate syntaxes to the inet_ntoa() library call. For example 0xe - is a valid name, but if you were to type "telnet 0xe", it would try - to connect to IP address 0.0.0.14. It is also rumored that there - exists some broken inet_ntoa() routines that treat an address like - x400 as an IP address. - - Certain operating systems have limitations on the length of their own - hostname. While not strictly of issue to the DNS, you should be - aware of your operating system's length limits before choosing the - name of a host. - - Remember that many resource records (abbreviated RR) take on more - than one argument. HINFO requires two arguments, as does RP. If you - don't supply enough arguments, servers sometime return garbage for - the missing fields. If you need to include whitespace within any - data, you must put the string in quotes. - -2.2 SOA records - - In the SOA record of every zone, remember to fill in the e-mail - address that will get to the person who maintains the DNS at your - site (commonly referred to as "hostmaster"). The `@' in the e-mail - must be replaced by a `.' first. Do not try to put an `@' sign in - this address. If the local part of the address already contains a - `.' (e.g., John.Smith@widget.xx), then you need to quote the `.' by - preceding it with `\' character. (e.g., to become - John\.Smith.widget.xx) Alternately (and preferred), you can just use - the generic name `hostmaster', and use a mail alias to redirect it to - the appropriate persons. There exists software which uses this field - to automatically generate the e-mail address for the zone contact. - This software will break if this field is improperly formatted. It - is imperative that this address get to one or more real persons, - because it is often used for everything from reporting bad DNS data - to reporting security incidents. - - Even though some BIND versions allow you to use a decimal in a serial - number, don't. A decimal serial number is converted to an unsigned - 32-bit integer internally anyway. The formula for a n.m serial - number is n*10^(3+int(0.9+log10(m))) + m which translates to - something rather unexpected. For example it's routinely possible - with a decimal serial number (perhaps automatically generated by - SCCS) to be incremented such that it is numerically larger, but after - the above conversion yield a serial number which is LOWER than - before. Decimal serial numbers have been officially deprecated in - recent BIND versions. The recommended syntax is YYYYMMDDnn - (YYYY=year, MM=month, DD=day, nn=revision number. This won't - overflow until the year 4294. - - - -Barr Informational [Page 3] - -RFC 1912 Common DNS Errors February 1996 - - - Choose logical values for the timer values in the SOA record (note - values below must be expressed as seconds in the zone data): - - Refresh: How often a secondary will poll the primary server to see - if the serial number for the zone has increased (so it knows - to request a new copy of the data for the zone). Set this to - how long your secondaries can comfortably contain out-of-date - data. You can keep it short (20 mins to 2 hours) if you - aren't worried about a small increase in bandwidth used, or - longer (2-12 hours) if your Internet connection is slow or is - started on demand. Recent BIND versions (4.9.3) have optional - code to automatically notify secondaries that data has - changed, allowing you to set this TTL to a long value (one - day, or more). - - Retry: If a secondary was unable to contact the primary at the - last refresh, wait the retry value before trying again. This - value isn't as important as others, unless the secondary is on - a distant network from the primary or the primary is more - prone to outages. It's typically some fraction of the refresh - interval. - - - Expire: How long a secondary will still treat its copy of the zone - data as valid if it can't contact the primary. This value - should be greater than how long a major outage would typically - last, and must be greater than the minimum and retry - intervals, to avoid having a secondary expire the data before - it gets a chance to get a new copy. After a zone is expired a - secondary will still continue to try to contact the primary, - but it will no longer provide nameservice for the zone. 2-4 - weeks are suggested values. - - Minimum: The default TTL (time-to-live) for resource records -- - how long data will remain in other nameservers' cache. ([RFC - 1035] defines this to be the minimum value, but servers seem - to always implement this as the default value) This is by far - the most important timer. Set this as large as is comfortable - given how often you update your nameserver. If you plan to - make major changes, it's a good idea to turn this value down - temporarily beforehand. Then wait the previous minimum value, - make your changes, verify their correctness, and turn this - value back up. 1-5 days are typical values. Remember this - value can be overridden on individual resource records. - - - - - - - -Barr Informational [Page 4] - -RFC 1912 Common DNS Errors February 1996 - - - As you can see, the typical values above for the timers vary widely. - Popular documentation like [RFC 1033] recommended a day for the - minimum TTL, which is now considered too low except for zones with - data that vary regularly. Once a DNS stabilizes, values on the order - of 3 or more days are recommended. It is also recommended that you - individually override the TTL on certain RRs which are often - referenced and don't often change to have very large values (1-2 - weeks). Good examples of this are the MX, A, and PTR records of your - mail host(s), the NS records of your zone, and the A records of your - nameservers. - -2.3 Glue A Records - - Glue records are A records that are associated with NS records to - provide "bootstrapping" information to the nameserver. For example: - - podunk.xx. in ns ns1.podunk.xx. - in ns ns2.podunk.xx. - ns1.podunk.xx. in a 1.2.3.4 - ns2.podunk.xx. in a 1.2.3.5 - - Here, the A records are referred to as "Glue records". - - Glue records are required only in forward zone files for nameservers - that are located in the subdomain of the current zone that is being - delegated. You shouldn't have any A records in an in-addr.arpa zone - file (unless you're using RFC 1101-style encoding of subnet masks). - - If your nameserver is multi-homed (has more than one IP address), you - must list all of its addresses in the glue to avoid cache - inconsistency due to differing TTL values, causing some lookups to - not find all addresses for your nameserver. - - Some people get in the bad habit of putting in a glue record whenever - they add an NS record "just to make sure". Having duplicate glue - records in your zone files just makes it harder when a nameserver - moves to a new IP address, or is removed. You'll spend hours trying - to figure out why random people still see the old IP address for some - host, because someone forgot to change or remove a glue record in - some other file. Newer BIND versions will ignore these extra glue - records in local zone files. - - Older BIND versions (4.8.3 and previous) have a problem where it - inserts these extra glue records in the zone transfer data to - secondaries. If one of these glues is wrong, the error can be - propagated to other nameservers. If two nameservers are secondaries - for other zones of each other, it's possible for one to continually - pass old glue records back to the other. The only way to get rid of - - - -Barr Informational [Page 5] - -RFC 1912 Common DNS Errors February 1996 - - - the old data is to kill both of them, remove the saved backup files, - and restart them. Combined with that those same versions also tend - to become infected more easily with bogus data found in other non- - secondary nameservers (like the root zone data). - -2.4 CNAME records - - A CNAME record is not allowed to coexist with any other data. In - other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you - can't also have an MX record for suzy.podunk.edu, or an A record, or - even a TXT record. Especially do not try to combine CNAMEs and NS - records like this!: - - - podunk.xx. IN NS ns1 - IN NS ns2 - IN CNAME mary - mary IN A 1.2.3.4 - - - This is often attempted by inexperienced administrators as an obvious - way to allow your domain name to also be a host. However, DNS - servers like BIND will see the CNAME and refuse to add any other - resources for that name. Since no other records are allowed to - coexist with a CNAME, the NS entries are ignored. Therefore all the - hosts in the podunk.xx domain are ignored as well! - - If you want to have your domain also be a host, do the following: - - podunk.xx. IN NS ns1 - IN NS ns2 - IN A 1.2.3.4 - mary IN A 1.2.3.4 - - Don't go overboard with CNAMEs. Use them when renaming hosts, but - plan to get rid of them (and inform your users). However CNAMEs are - useful (and encouraged) for generalized names for servers -- `ftp' - for your ftp server, `www' for your Web server, `gopher' for your - Gopher server, `news' for your Usenet news server, etc. - - Don't forget to delete the CNAMEs associated with a host if you - delete the host it is an alias for. Such "stale CNAMEs" are a waste - of resources. - - - - - - - - -Barr Informational [Page 6] - -RFC 1912 Common DNS Errors February 1996 - - - Don't use CNAMEs in combination with RRs which point to other names - like MX, CNAME, PTR and NS. (PTR is an exception if you want to - implement classless in-addr delegation.) For example, this is - strongly discouraged: - - podunk.xx. IN MX mailhost - mailhost IN CNAME mary - mary IN A 1.2.3.4 - - - [RFC 1034] in section 3.6.2 says this should not be done, and [RFC - 974] explicitly states that MX records shall not point to an alias - defined by a CNAME. This results in unnecessary indirection in - accessing the data, and DNS resolvers and servers need to work more - to get the answer. If you really want to do this, you can accomplish - the same thing by using a preprocessor such as m4 on your host files. - - Also, having chained records such as CNAMEs pointing to CNAMEs may - make administration issues easier, but is known to tickle bugs in - some resolvers that fail to check loops correctly. As a result some - hosts may not be able to resolve such names. - - Having NS records pointing to a CNAME is bad and may conflict badly - with current BIND servers. In fact, current BIND implementations - will ignore such records, possibly leading to a lame delegation. - There is a certain amount of security checking done in BIND to - prevent spoofing DNS NS records. Also, older BIND servers reportedly - will get caught in an infinite query loop trying to figure out the - address for the aliased nameserver, causing a continuous stream of - DNS requests to be sent. - -2.5 MX records - - It is a good idea to give every host an MX record, even if it points - to itself! Some mailers will cache MX records, but will always need - to check for an MX before sending mail. If a site does not have an - MX, then every piece of mail may result in one more resolver query, - since the answer to the MX query often also contains the IP addresses - of the MX hosts. Internet SMTP mailers are required by [RFC 1123] to - support the MX mechanism. - - Put MX records even on hosts that aren't intended to send or receive - e-mail. If there is a security problem involving one of these hosts, - some people will mistakenly send mail to postmaster or root at the - site without checking first to see if it is a "real" host or just a - terminal or personal computer that's not set up to accept e-mail. If - you give it an MX record, then the e-mail can be redirected to a real - person. Otherwise mail can just sit in a queue for hours or days - - - -Barr Informational [Page 7] - -RFC 1912 Common DNS Errors February 1996 - - - until the mailer gives up trying to send it. - - Don't forget that whenever you add an MX record, you need to inform - the target mailer if it is to treat the first host as "local". (The - "Cw" flag in sendmail, for example) - - If you add an MX record which points to an external host (e.g., for - the purposes of backup mail routing) be sure to ask permission from - that site first. Otherwise that site could get rather upset and take - action (like throw your mail away, or appeal to higher authorities - like your parent DNS administrator or network provider.) - -2.6 Other Resource Records - -2.6.1 WKS - - WKS records are deprecated in [RFC 1123]. They serve no known useful - function, except internally among LISP machines. Don't use them. - -2.6.2 HINFO - - On the issue HINFO records, some will argue that these is a security - problem (by broadcasting what vendor hardware and operating system - you so people can run systematic attacks on known vendor security - holes). If you do use them, you should keep up to date with known - vendor security problems. However, they serve a useful purpose. - Don't forget that HINFO requires two arguments, the hardware type, - and the operating system. - - HINFO is sometimes abused to provide other information. The record - is meant to provide specific information about the machine itself. - If you need to express other information about the host in the DNS, - use TXT. - -2.6.3 TXT - - TXT records have no specific definition. You can put most anything - in them. Some use it for a generic description of the host, some put - specific information like its location, primary user, or maybe even a - phone number. - -2.6.4 RP - - RP records are relatively new. They are used to specify an e-mail - address (see first paragraph of section 2.2) of the "Responsible - Person" of the host, and the name of a TXT record where you can get - more information. See [RFC 1183]. - - - - -Barr Informational [Page 8] - -RFC 1912 Common DNS Errors February 1996 - - -2.7 Wildcard records - - Wildcard MXs are useful mostly for non IP-connected sites. A common - mistake is thinking that a wildcard MX for a zone will apply to all - hosts in the zone. A wildcard MX will apply only to names in the - zone which aren't listed in the DNS at all. e.g., - - podunk.xx. IN NS ns1 - IN NS ns2 - mary IN A 1.2.3.4 - *.podunk.xx. IN MX 5 sue - - Mail for mary.podunk.xx will be sent to itself for delivery. Only - mail for jane.podunk.xx or any hosts you don't see above will be sent - to the MX. For most Internet sites, wildcard MX records are not - useful. You need to put explicit MX records on every host. - - Wildcard MXs can be bad, because they make some operations succeed - when they should fail instead. Consider the case where someone in - the domain "widget.com" tries to send mail to "joe@larry". If the - host "larry" doesn't actually exist, the mail should in fact bounce - immediately. But because of domain searching the address gets - resolved to "larry.widget.com", and because of the wildcard MX this - is a valid address according to DNS. Or perhaps someone simply made - a typo in the hostname portion of the address. The mail message then - gets routed to the mail host, which then rejects the mail with - strange error messages like "I refuse to talk to myself" or "Local - configuration error". - - Wildcard MX records are good for when you have a large number of - hosts which are not directly Internet-connected (for example, behind - a firewall) and for administrative or political reasons it is too - difficult to have individual MX records for every host, or to force - all e-mail addresses to be "hidden" behind one or more domain names. - In that case, you must divide your DNS into two parts, an internal - DNS, and an external DNS. The external DNS will have only a few - hosts and explicit MX records, and one or more wildcard MXs for each - internal domain. Internally the DNS will be complete, with all - explicit MX records and no wildcards. - - Wildcard As and CNAMEs are possible too, and are really confusing to - users, and a potential nightmare if used without thinking first. It - could result (due again to domain searching) in any telnet/ftp - attempts from within the domain to unknown hosts to be directed to - one address. One such wildcard CNAME (in *.edu.com) caused - Internet-wide loss of services and potential security nightmares due - to unexpected interactions with domain searching. It resulted in - swift fixes, and even an RFC ([RFC 1535]) documenting the problem. - - - -Barr Informational [Page 9] - -RFC 1912 Common DNS Errors February 1996 - - -2.8 Authority and Delegation Errors (NS records) - - You are required to have at least two nameservers for every domain, - though more is preferred. Have secondaries outside your network. If - the secondary isn't under your control, periodically check up on them - and make sure they're getting current zone data from you. Queries to - their nameserver about your hosts should always result in an - "authoritative" response. If not, this is called a "lame - delegation". A lame delegations exists when a nameserver is - delegated responsibility for providing nameservice for a zone (via NS - records) but is not performing nameservice for that zone (usually - because it is not set up as a primary or secondary for the zone). - - The "classic" lame delegation can be illustrated in this example: - - podunk.xx. IN NS ns1.podunk.xx. - IN NS ns0.widget.com. - - "podunk.xx" is a new domain which has recently been created, and - "ns1.podunk.xx" has been set up to perform nameservice for the zone. - They haven't quite finished everything yet and haven't made sure that - the hostmaster at "ns0.widget.com" has set up to be a proper - secondary, and thus has no information about the podunk.xx domain, - even though the DNS says it is supposed to. Various things can - happen depending on which nameserver is used. At best, extra DNS - traffic will result from a lame delegation. At worst, you can get - unresolved hosts and bounced e-mail. - - Also, sometimes a nameserver is moved to another host or removed from - the list of secondaries. Unfortunately due to caching of NS records, - many sites will still think that a host is a secondary after that - host has stopped providing nameservice. In order to prevent lame - delegations while the cache is being aged, continue to provide - nameservice on the old nameserver for the length of the maximum of - the minimum plus refresh times for the zone and the parent zone. - (See section 2.2) - - Whenever a primary or secondary is removed or changed, it takes a - fair amount of human coordination among the parties involved. (The - site itself, it's parent, and the site hosting the secondary) When a - primary moves, make sure all secondaries have their named.boot files - updated and their servers reloaded. When a secondary moves, make - sure the address records at both the primary and parent level are - changed. - - It's also been reported that some distant sites like to pick popular - nameservers like "ns.uu.net" and just add it to their list of NS - records in hopes that they will magically perform additional - - - -Barr Informational [Page 10] - -RFC 1912 Common DNS Errors February 1996 - - - nameservice for them. This is an even worse form of lame delegation, - since this adds traffic to an already busy nameserver. Please - contact the hostmasters of sites which have lame delegations. - Various tools can be used to detect or actively find lame - delegations. See the list of contributed software in the BIND - distribution. - - Make sure your parent domain has the same NS records for your zone as - you do. (Don't forget your in-addr.arpa zones too!). Do not list - too many (7 is the recommended maximum), as this just makes things - harder to manage and is only really necessary for very popular top- - level or root zones. You also run the risk of overflowing the 512- - byte limit of a UDP packet in the response to an NS query. If this - happens, resolvers will "fall back" to using TCP requests, resulting - in increased load on your nameserver. - - It's important when picking geographic locations for secondary - nameservers to minimize latency as well as increase reliability. - Keep in mind network topologies. For example if your site is on the - other end of a slow local or international link, consider a secondary - on the other side of the link to decrease average latency. Contact - your Internet service provider or parent domain contact for more - information about secondaries which may be available to you. - -3. BIND operation - - This section discusses common problems people have in the actual - operation of the nameserver (specifically, BIND). Not only must the - data be correct as explained above, but the nameserver must be - operated correctly for the data to be made available. - -3.1 Serial numbers - - Each zone has a serial number associated with it. Its use is for - keeping track of who has the most current data. If and only if the - primary's serial number of the zone is greater will the secondary ask - the primary for a copy of the new zone data (see special case below). - - Don't forget to change the serial number when you change data! If - you don't, your secondaries will not transfer the new zone - information. Automating the incrementing of the serial number with - software is also a good idea. - - If you make a mistake and increment the serial number too high, and - you want to reset the serial number to a lower value, use the - following procedure: - - - - - -Barr Informational [Page 11] - -RFC 1912 Common DNS Errors February 1996 - - - Take the `incorrect' serial number and add 2147483647 to it. If - the number exceeds 4294967296, subtract 4294967296. Load the - resulting number. Then wait 2 refresh periods to allow the zone - to propagate to all servers. - - Repeat above until the resulting serial number is less than the - target serial number. - - Up the serial number to the target serial number. - - This procedure won't work if one of your secondaries is running an - old version of BIND (4.8.3 or earlier). In this case you'll have to - contact the hostmaster for that secondary and have them kill the - secondary servers, remove the saved backup file, and restart the - server. Be careful when editing the serial number -- DNS admins - don't like to kill and restart nameservers because you lose all that - cached data. - -3.2 Zone file style guide - - Here are some useful tips in structuring your zone files. Following - these will help you spot mistakes, and avoid making more. - - Be consistent with the style of entries in your DNS files. If your - $ORIGIN is podunk.xx., try not to write entries like: - - mary IN A 1.2.3.1 - sue.podunk.xx. IN A 1.2.3.2 - - or: - - bobbi IN A 1.2.3.2 - IN MX mary.podunk.xx. - - - Either use all FQDNs (Fully Qualified Domain Names) everywhere or - used unqualified names everywhere. Or have FQDNs all on the right- - hand side but unqualified names on the left. Above all, be - consistent. - - Use tabs between fields, and try to keep columns lined up. It makes - it easier to spot missing fields (note some fields such as "IN" are - inherited from the previous record and may be left out in certain - circumstances.) - - - - - - - -Barr Informational [Page 12] - -RFC 1912 Common DNS Errors February 1996 - - - Remember you don't need to repeat the name of the host when you are - defining multiple records for one host. Be sure also to keep all - records associated with a host together in the file. It will make - things more straightforward when it comes time to remove or rename a - host. - - Always remember your $ORIGIN. If you don't put a `.' at the end of - an FQDN, it's not recognized as an FQDN. If it is not an FQDN, then - the nameserver will append $ORIGIN to the name. Double check, triple - check, those trailing dots, especially in in-addr.arpa zone files, - where they are needed the most. - - Be careful with the syntax of the SOA and WKS records (the records - which use parentheses). BIND is not very flexible in how it parses - these records. See the documentation for BIND. - -3.3 Verifying data - - Verify the data you just entered or changed by querying the resolver - with dig (or your favorite DNS tool, many are included in the BIND - distribution) after a change. A few seconds spent double checking - can save hours of trouble, lost mail, and general headaches. Also be - sure to check syslog output when you reload the nameserver. If you - have grievous errors in your DNS data or boot file, named will report - it via syslog. - - It is also highly recommended that you automate this checking, either - with software which runs sanity checks on the data files before they - are loaded into the nameserver, or with software which checks the - data already loaded in the nameserver. Some contributed software to - do this is included in the BIND distribution. - -4. Miscellaneous Topics - -4.1 Boot file setup - - Certain zones should always be present in nameserver configurations: - - primary localhost localhost - primary 0.0.127.in-addr.arpa 127.0 - primary 255.in-addr.arpa 255 - primary 0.in-addr.arpa 0 - - These are set up to either provide nameservice for "special" - addresses, or to help eliminate accidental queries for broadcast or - local address to be sent off to the root nameservers. All of these - files will contain NS and SOA records just like the other zone files - you maintain, the exception being that you can probably make the SOA - - - -Barr Informational [Page 13] - -RFC 1912 Common DNS Errors February 1996 - - - timers very long, since this data will never change. - - The "localhost" address is a "special" address which always refers to - the local host. It should contain the following line: - - localhost. IN A 127.0.0.1 - - The "127.0" file should contain the line: - - 1 PTR localhost. - - There has been some extensive discussion about whether or not to - append the local domain to it. The conclusion is that "localhost." - would be the best solution. The reasons given include: - - "localhost" by itself is used and expected to work in some - systems. - - Translating 127.0.0.1 into "localhost.dom.ain" can cause some - software to connect back to the loopback interface when it didn't - want to because "localhost" is not equal to "localhost.dom.ain". - - The "255" and "0" files should not contain any additional data beyond - the NS and SOA records. - - Note that future BIND versions may include all or some of this data - automatically without additional configuration. - -4.2 Other Resolver and Server bugs - - Very old versions of the DNS resolver have a bug that cause queries - for names that look like IP addresses to go out, because the user - supplied an IP address and the software didn't realize that it didn't - need to be resolved. This has been fixed but occasionally it still - pops up. It's important because this bug means that these queries - will be sent directly to the root nameservers, adding to an already - heavy DNS load. - - While running a secondary nameserver off another secondary nameserver - is possible, it is not recommended unless necessary due to network - topologies. There are known cases where it has led to problems like - bogus TTL values. While this may be caused by older or flawed DNS - implementations, you should not chain secondaries off of one another - since this builds up additional reliability dependencies as well as - adds additional delays in updates of new zone data. - - - - - - -Barr Informational [Page 14] - -RFC 1912 Common DNS Errors February 1996 - - -4.3 Server issues - - DNS operates primarily via UDP (User Datagram Protocol) messages. - Some UNIX operating systems, in an effort to save CPU cycles, run - with UDP checksums turned off. The relative merits of this have long - been debated. However, with the increase in CPU speeds, the - performance considerations become less and less important. It is - strongly encouraged that you turn on UDP checksumming to avoid - corrupted data not only with DNS but with other services that use UDP - (like NFS). Check with your operating system documentation to verify - that UDP checksumming is enabled. - -References - - [RFC 974] Partridge, C., "Mail routing and the domain system", STD - 14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986. - - [RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC - 1033, USC/Information Sciences Institute, November 1987. - - [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, USC/Information Sciences Institute, - November 1987. - - [RFC 1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, USC/Information Sciences - Institute, November 1987. - - [RFC 1123] Braden, R., "Requirements for Internet Hosts -- - Application and Support", STD 3, RFC 1123, IETF, October - 1989. - - [RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC - 1178, Integrated Systems Group/NIST, August 1990. - - [RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart, - "New DNS RR Definitions", RFC 1183, October 1990. - - [RFC 1535] Gavron, E., "A Security Problem and Proposed Correction - With Widely Deployed DNS Software", RFC 1535, ACES - Research Inc., October 1993. - - [RFC 1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. - Miller, "Common DNS Implementation Errors and Suggested - Fixes", RFC 1536, USC/Information Sciences Institute, USC, - October 1993. - - - - - -Barr Informational [Page 15] - -RFC 1912 Common DNS Errors February 1996 - - - [RFC 1537] Beertema, P., "Common DNS Data File Configuration Errors", - RFC 1537, CWI, October 1993. - - [RFC 1713] A. Romao, "Tools for DNS debugging", RFC 1713, FCCN, - November 1994. - - [BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND", - Vixie Enterprises, July 1994. - -5. Security Considerations - - Security issues are not discussed in this memo. - -6. Author's Address - - David Barr - The Pennsylvania State University - Department of Mathematics - 334 Whitmore Building - University Park, PA 16802 - - Voice: +1 814 863 7374 - Fax: +1 814 863-8311 - EMail: barr@math.psu.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - -Barr Informational [Page 16] - diff --git a/doc/rfc/rfc3755.txt b/doc/rfc/rfc3755.txt deleted file mode 100644 index a9a7cf26929..00000000000 --- a/doc/rfc/rfc3755.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -Network Working Group S. Weiler -Request for Comments: 3755 SPARTA, Inc. -Updates: 3658, 2535 May 2004 -Category: Standards Track - - - Legacy Resolver Compatibility for Delegation Signer (DS) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - As the DNS Security (DNSSEC) specifications have evolved, the syntax - and semantics of the DNSSEC resource records (RRs) have changed. - Many deployed nameservers understand variants of these semantics. - Dangerous interactions can occur when a resolver that understands an - earlier version of these semantics queries an authoritative server - that understands the new delegation signer semantics, including at - least one failure scenario that will cause an unsecured zone to be - unresolvable. This document changes the type codes and mnemonics of - the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. - -1. Introduction - - The DNSSEC protocol has been through many iterations whose syntax and - semantics are not completely compatible. This has occurred as part - of the ordinary process of proposing a protocol, implementing it, - testing it in the increasingly complex and diverse environment of the - Internet, and refining the definitions of the initial Proposed - Standard. In the case of DNSSEC, the process has been complicated by - DNS's criticality and wide deployment and the need to add security - while minimizing daily operational complexity. - - A weak area for previous DNS specifications has been lack of detail - in specifying resolver behavior, leaving implementors largely on - their own to determine many details of resolver function. This, - combined with the number of iterations the DNSSEC specifications have - been through, has resulted in fielded code with a wide variety of - - - -Weiler Standards Track [Page 1] - -RFC 3755 Legacy Resolver Compatibility for DS May 2004 - - - behaviors. This variety makes it difficult to predict how a protocol - change will be handled by all deployed resolvers. The risk that a - change will cause unacceptable or even catastrophic failures makes it - difficult to design and deploy a protocol change. One strategy for - managing that risk is to structure protocol changes so that existing - resolvers can completely ignore input that might confuse them or - trigger undesirable failure modes. - - This document addresses a specific problem caused by Delegation - Signer's (DS) [RFC3658] introduction of new semantics for the NXT RR - that are incompatible with the semantics in [RFC2535]. Answers - provided by DS-aware servers can trigger an unacceptable failure mode - in some resolvers that implement RFC 2535, which provides a great - disincentive to sign zones with DS. The changes defined in this - document allow for the incremental deployment of DS. - -1.1. Terminology - - In this document, the term "unsecure delegation" means any delegation - for which no DS record appears at the parent. An "unsecure referral" - is an answer from the parent containing an NS RRset and a proof that - no DS record exists for that name. - - 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]. - -1.2. The Problem - - Delegation Signer (DS) introduces new semantics for the NXT RR that - are incompatible with the semantics in RFC 2535. In RFC 2535, NXT - records were only required to be returned as part of a non-existence - proof. With DS, an unsecure referral returns, in addition to the NS, - a proof of non-existence of a DS RR in the form of an NXT and - SIG(NXT). RFC 2535 didn't specify how a resolver was to interpret a - response with RCODE=0, AA=0, and both an NS and an NXT in the - authority section. Some widely deployed 2535-aware resolvers - interpret any answer with an NXT as a proof of non-existence of the - requested record. This results in unsecure delegations being - invisible to 2535-aware resolvers and violates the basic - architectural principle that DNSSEC must do no harm -- the signing of - zones must not prevent the resolution of unsecured delegations. - -2. Possible Solutions - - This section presents several solutions that were considered. - Section 3 describes the one selected. - - - - -Weiler Standards Track [Page 2] - -RFC 3755 Legacy Resolver Compatibility for DS May 2004 - - -2.1. Change SIG, KEY, and NXT type codes - - To avoid the problem described above, legacy (RFC2535-aware) - resolvers need to be kept from seeing unsecure referrals that include - NXT records in the authority section. The simplest way to do that is - to change the type codes for SIG, KEY, and NXT. - - The obvious drawback to this is that new resolvers will not be able - to validate zones signed with the old RRs. This problem already - exists, however, because of the changes made by DS, and resolvers - that understand the old RRs (and have compatibility issues with DS) - are far more prevalent than 2535-signed zones. - -2.2. Change a subset of type codes - - The observed problem with unsecure referrals could be addressed by - changing only the NXT type code or another subset of the type codes - that includes NXT. This has the virtue of apparent simplicity, but - it risks introducing new problems or not going far enough. It's - quite possible that more incompatibilities exist between DS and - earlier semantics. Legacy resolvers may also be confused by seeing - records they recognize (SIG and KEY) while being unable to find NXTs. - Although it may seem unnecessary to fix that which is not obviously - broken, it's far cleaner to change all of the type codes at once. - This will leave legacy resolvers and tools completely blinded to - DNSSEC -- they will see only unknown RRs. - -2.3. Replace the DO bit - - Another way to keep legacy resolvers from ever seeing DNSSEC records - with DS semantics is to have authoritative servers only send that - data to DS-aware resolvers. It's been proposed that assigning a new - EDNS0 flag bit to signal DS-awareness (tentatively called "DA"), and - having authoritative servers send DNSSEC data only in response to - queries with the DA bit set, would accomplish this. This bit would - presumably supplant the DO bit described in [RFC3225]. - - This solution is sufficient only if all 2535-aware resolvers zero out - EDNS0 flags that they don't understand. If one passed through the DA - bit unchanged, it would still see the new semantics, and it would - probably fail to see unsecure delegations. Since it's impractical to - know how every DNS implementation handles unknown EDNS0 flags, this - is not a universal solution. It could, though, be considered in - addition to changing the RR type codes. - - - - - - - -Weiler Standards Track [Page 3] - -RFC 3755 Legacy Resolver Compatibility for DS May 2004 - - -2.4. Increment the EDNS version - - Another possible solution is to increment the EDNS version number as - defined in [RFC2671], on the assumption that all existing - implementations will reject higher versions than they support, and - retain the DO bit as the signal for DNSSEC awareness. This approach - has not been tested. - -2.5. Do nothing - - There is a large deployed base of DNS resolvers that understand - DNSSEC as defined by the standards track RFC 2535 and [RFC2065] and, - due to under specification in those documents, interpret any answer - with an NXT as a non-existence proof. So long as that is the case, - zone owners will have a strong incentive to not sign any zones that - contain unsecure delegations, lest those delegations be invisible to - such a large installed base. This will dramatically slow DNSSEC - adoption. - - Unfortunately, without signed zones there's no clear incentive for - operators of resolvers to upgrade their software to support the new - version of DNSSEC, as defined in RFC 3658. Historical data suggests - that resolvers are rarely upgraded, and that old nameserver code - never dies. - - Rather than wait years for resolvers to be upgraded through natural - processes before signing zones with unsecure delegations, addressing - this problem with a protocol change will immediately remove the - disincentive for signing zones and allow widespread deployment of - DNSSEC. - -3. Protocol changes - - This document changes the type codes of SIG, KEY, and NXT. This - approach is the cleanest and safest of those discussed above, largely - because the behavior of resolvers that receive unknown type codes is - well understood. This approach has also received the most testing. - - To avoid operational confusion, it's also necessary to change the - mnemonics for these RRs. DNSKEY will be the replacement for KEY, - with the mnemonic indicating that these keys are not for application - use, per [RFC3445]. RRSIG (Resource Record SIGnature) will replace - SIG, and NSEC (Next SECure) will replace NXT. These new types - completely replace the old types, except that SIG(0) [RFC2931] and - TKEY [RFC2930] will continue to use SIG and KEY. - - - - - - -Weiler Standards Track [Page 4] - -RFC 3755 Legacy Resolver Compatibility for DS May 2004 - - - The new types will have exactly the same syntax and semantics as - specified for SIG, KEY, and NXT in RFC 2535 and RFC 3658 except for - the following: - - 1) Consistent with [RFC3597], domain names embedded in RRSIG and NSEC - RRs MUST NOT be compressed, - - 2) Embedded domain names in RRSIG and NSEC RRs are not downcased for - purposes of DNSSEC canonical form and ordering nor for equality - comparison, and - - 3) An RRSIG with a type-covered field of zero has undefined - semantics. The meaning of such a resource record may only be - defined by IETF Standards Action. - - If a resolver receives the old types, it SHOULD treat them as unknown - RRs and SHOULD NOT assign any special meaning to them or give them - any special treatment. It MUST NOT use them for DNSSEC validations - or other DNS operational decision making. For example, a resolver - MUST NOT use DNSKEYs to validate SIGs or use KEYs to validate RRSIGs. - If SIG, KEY, or NXT RRs are included in a zone, they MUST NOT receive - special treatment. As an example, if a SIG is included in a signed - zone, there MUST be an RRSIG for it. Authoritative servers may wish - to give error messages when loading zones containing SIG or NXT - records (KEY records may be included for SIG(0) or TKEY). - - As a clarification to previous documents, some positive responses, - particularly wildcard proofs and unsecure referrals, will contain - NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as negative - answers merely because they contain an NSEC. - -4. IANA Considerations - -4.1. DNS Resource Record Types - - This document updates the IANA registry for DNS Resource Record Types - by assigning types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, - respectively. - - Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and - TKEY [RFC2930] use only. - - Type 30 (NXT) should be marked as Obsolete. - - - - - - - - -Weiler Standards Track [Page 5] - -RFC 3755 Legacy Resolver Compatibility for DS May 2004 - - -4.2. DNS Security Algorithm Numbers - - To allow zone signing (DNSSEC) and transaction security mechanisms - (SIG(0) and TKEY) to use different sets of algorithms, the existing - "DNS Security Algorithm Numbers" registry is modified to include the - applicability of each algorithm. Specifically, two new columns are - added to the registry, showing whether each algorithm may be used for - zone signing, transaction security mechanisms, or both. Only - algorithms usable for zone signing may be used in DNSKEY, RRSIG, and - DS RRs. Only algorithms usable for SIG(0) and/or TSIG may be used in - SIG and KEY RRs. - - All currently defined algorithms except for Indirect (algorithm 252) - remain usable for transaction security mechanisms. Only RSA/SHA-1 - [RFC3110], DSA/SHA-1 [RFC2536], and private algorithms (types 253 and - 254) may be used for zone signing. Note that the registry does not - contain the requirement level of each algorithm, only whether or not - an algorithm may be used for the given purposes. For example, - RSA/MD5, while allowed for transaction security mechanisms, is NOT - RECOMMENDED, per [RFC3110]. - - Additionally, the presentation format algorithm mnemonics from - [RFC2535] Section 7 are added to the registry. This document assigns - RSA/SHA-1 the mnemonic RSASHA1. - - As before, assignment of new algorithms in this registry requires - IETF Standards Action. Additionally, modification of algorithm - mnemonics or applicability requires IETF Standards Action. Documents - defining a new algorithm must address the applicability of the - algorithm and should assign a presentation mnemonic to the algorithm. - -4.3. DNSKEY Flags - - Like the KEY resource record, DNSKEY contains a 16-bit flags field. - This document creates a new registry for the DNSKEY flags field. - - Initially, this registry only contains an assignment for bit 7 (the - ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF - Standards Action. - -4.4. DNSKEY Protocol Octet - - Like the KEY resource record, DNSKEY contains an eight bit protocol - field. The only defined value for this field is 3 (DNSSEC). No - other values are allowed, hence no IANA registry is needed for this - field. - - - - - -Weiler Standards Track [Page 6] - -RFC 3755 Legacy Resolver Compatibility for DS May 2004 - - -5. Security Considerations - - The changes introduced here do not materially affect security. The - implications of trying to use both new and legacy types together are - not well understood, and attempts to do so would probably lead to - unintended and dangerous results. - - Changing type codes will leave code paths in legacy resolvers that - are never exercised. Unexercised code paths are a frequent source of - security holes, largely because those code paths do not get frequent - scrutiny. - - Doing nothing, as described in section 2.5, will slow DNSSEC - deployment. While this does not decrease security, it also fails to - increase it. - -6. References - -6.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System - (DNS)", RFC 2536, March 1999. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", - RFC 2930, September 2000. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures - (SIG(0)s)", RFC 2931, September 2000. - - [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain - Name System (DNS)", RFC 3110, May 2001. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - - - - - - - - - - -Weiler Standards Track [Page 7] - -RFC 3755 Legacy Resolver Compatibility for DS May 2004 - - -6.2. Informative References - - [RFC2065] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System - Security Extensions", RFC 2065, January 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - - [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY - Resource Record (RR)", RFC 3445, December 2002. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - -7. Acknowledgments - - The changes introduced here and the analysis of alternatives had many - contributors. With apologies to anyone overlooked, those include: - Michael Graff, Johan Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis, - Bill Manning, Paul Vixie, and Suzanne Woolf. - - Thanks to Jakob Schlyter and Mark Andrews for identifying the - incompatibility described in section 1.2. - - In addition to the above, the author would like to thank Scott Rose, - Olafur Gudmundsson, and Sandra Murphy for their substantive comments. - -8. Author's Address - - Samuel Weiler - SPARTA, Inc. - 7075 Samuel Morse Drive - Columbia, MD 21046 - USA - - EMail: weiler@tislabs.com - - - - - - - - - - - - -Weiler Standards Track [Page 8] - -RFC 3755 Legacy Resolver Compatibility for DS May 2004 - - -9. Full Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - -Weiler Standards Track [Page 9] - diff --git a/doc/rfc/rfc4294.txt b/doc/rfc/rfc4294.txt deleted file mode 100644 index 8fea5c311bf..00000000000 --- a/doc/rfc/rfc4294.txt +++ /dev/null @@ -1,1123 +0,0 @@ - - - - - - -Network Working Group J. Loughney, Ed. -Request for Comments: 4294 Nokia -Category: Informational April 2006 - - - IPv6 Node Requirements - -Status of This Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document defines requirements for IPv6 nodes. It is expected - that IPv6 will be deployed in a wide range of devices and situations. - Specifying the requirements for IPv6 nodes allows IPv6 to function - well and interoperate in a large number of situations and - deployments. - -Table of Contents - - 1. Introduction ....................................................2 - 1.1. Requirement Language .......................................3 - 1.2. Scope of This Document .....................................3 - 1.3. Description of IPv6 Nodes ..................................3 - 2. Abbreviations Used in This Document .............................3 - 3. Sub-IP Layer ....................................................4 - 3.1. Transmission of IPv6 Packets over Ethernet Networks - - RFC 2464 .................................................4 - 3.2. IP version 6 over PPP - RFC 2472 ...........................4 - 3.3. IPv6 over ATM Networks - RFC 2492 ..........................4 - 4. IP Layer ........................................................5 - 4.1. Internet Protocol Version 6 - RFC 2460 .....................5 - 4.2. Neighbor Discovery for IPv6 - RFC 2461 .....................5 - 4.3. Path MTU Discovery and Packet Size .........................6 - 4.4. ICMP for the Internet Protocol Version 6 (IPv6) - - RFC 2463 ...................................................7 - 4.5. Addressing .................................................7 - 4.6. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 .....8 - 5. DNS and DHCP ....................................................8 - 5.1. DNS ........................................................8 - - - - -Loughney Informational [Page 1] - -RFC 4294 IPv6 Node Requirements April 2006 - - - 5.2. Dynamic Host Configuration Protocol for IPv6 - (DHCPv6) - RFC 3315 ........................................9 - 6. IPv4 Support and Transition ....................................10 - 6.1. Transition Mechanisms .....................................10 - 7. Mobile IP ......................................................10 - 8. Security .......................................................10 - 8.1. Basic Architecture ........................................10 - 8.2. Security Protocols ........................................11 - 8.3. Transforms and Algorithms .................................11 - 8.4. Key Management Methods ....................................12 - 9. Router-Specific Functionality ..................................12 - 9.1. General ...................................................12 - 10. Network Management ............................................12 - 10.1. Management Information Base Modules (MIBs) ...............12 - 11. Security Considerations .......................................13 - 12. References ....................................................13 - 12.1. Normative References .....................................13 - 12.2. Informative References ...................................16 - 13. Authors and Acknowledgements ..................................18 - -1. Introduction - - The goal of this document is to define the common functionality - required from both IPv6 hosts and routers. Many IPv6 nodes will - implement optional or additional features, but this document - summarizes requirements from other published Standards Track - documents in one place. - - This document tries to avoid discussion of protocol details, and - references RFCs for this purpose. This document is informational in - nature and does not update Standards Track RFCs. - - Although the document points to different specifications, it should - be noted that in most cases, the granularity of requirements are - smaller than a single specification, as many specifications define - multiple, independent pieces, some of which may not be mandatory. - - As it is not always possible for an implementer to know the exact - usage of IPv6 in a node, an overriding requirement for IPv6 nodes is - that they should adhere to Jon Postel's Robustness Principle: - - Be conservative in what you do, be liberal in what you accept from - others [RFC-793]. - - - - - - - - -Loughney Informational [Page 2] - -RFC 4294 IPv6 Node Requirements April 2006 - - -1.1. Requirement 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 [RFC-2119]. - -1.2. Scope of This Document - - IPv6 covers many specifications. It is intended that IPv6 will be - deployed in many different situations and environments. Therefore, - it is important to develop the requirements for IPv6 nodes to ensure - interoperability. - - This document assumes that all IPv6 nodes meet the minimum - requirements specified here. - -1.3. Description of IPv6 Nodes - - From the Internet Protocol, Version 6 (IPv6) Specification - [RFC-2460], we have the following definitions: - - Description of an IPv6 Node - - - a device that implements IPv6. - - Description of an IPv6 router - - - a node that forwards IPv6 packets not explicitly addressed - to itself. - - Description of an IPv6 Host - - - any node that is not a router. - -2. Abbreviations Used in This Document - - ATM Asynchronous Transfer Mode - - AH Authentication Header - - DAD Duplicate Address Detection - - ESP Encapsulating Security Payload - - ICMP Internet Control Message Protocol - - IKE Internet Key Exchange - - - - -Loughney Informational [Page 3] - -RFC 4294 IPv6 Node Requirements April 2006 - - - MIB Management Information Base - - MLD Multicast Listener Discovery - - MTU Maximum Transfer Unit - - NA Neighbor Advertisement - - NBMA Non-Broadcast Multiple Access - - ND Neighbor Discovery - - NS Neighbor Solicitation - - NUD Neighbor Unreachability Detection - - PPP Point-to-Point Protocol - - PVC Permanent Virtual Circuit - - SVC Switched Virtual Circuit - -3. Sub-IP Layer - - An IPv6 node must include support for one or more IPv6 link-layer - specifications. Which link-layer specifications are included will - depend upon what link-layers are supported by the hardware available - on the system. It is possible for a conformant IPv6 node to support - IPv6 on some of its interfaces and not on others. - - As IPv6 is run over new layer 2 technologies, it is expected that new - specifications will be issued. This section highlights some major - layer 2 technologies and is not intended to be complete. - -3.1. Transmission of IPv6 Packets over Ethernet Networks - RFC 2464 - - Nodes supporting IPv6 over Ethernet interfaces MUST implement - Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. - -3.2. IP version 6 over PPP - RFC 2472 - - Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP - [RFC-2472]. - -3.3. IPv6 over ATM Networks - RFC 2492 - - Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM - Networks [RFC-2492]. Additionally, RFC 2492 states: - - - -Loughney Informational [Page 4] - -RFC 4294 IPv6 Node Requirements April 2006 - - - A minimally conforming IPv6/ATM driver SHALL support the PVC mode - of operation. An IPv6/ATM driver that supports the full SVC mode - SHALL also support PVC mode of operation. - -4. IP Layer - -4.1. Internet Protocol Version 6 - RFC 2460 - - The Internet Protocol Version 6 is specified in [RFC-2460]. This - specification MUST be supported. - - Unrecognized options in Hop-by-Hop Options or Destination Options - extensions MUST be processed as described in RFC 2460. - - The node MUST follow the packet transmission rules in RFC 2460. - - Nodes MUST always be able to send, receive, and process fragment - headers. All conformant IPv6 implementations MUST be capable of - sending and receiving IPv6 packets; the forwarding functionality MAY - be supported. - - RFC 2460 specifies extension headers and the processing for these - headers. - - A full implementation of IPv6 includes implementation of the - following extension headers: Hop-by-Hop Options, Routing (Type 0), - Fragment, Destination Options, Authentication and Encapsulating - Security Payload [RFC-2460]. - - An IPv6 node MUST be able to process these headers. It should be - noted that there is some discussion about the use of Routing Headers - and possible security threats [IPv6-RH] that they cause. - -4.2. Neighbor Discovery for IPv6 - RFC 2461 - - Neighbor Discovery SHOULD be supported. [RFC-2461] states: - - "Unless specified otherwise (in a document that covers operating - IP over a particular link type) this document applies to all link - types. However, because ND uses link-layer multicast for some of - its services, it is possible that on some link types (e.g., NBMA - links) alternative protocols or mechanisms to implement those - services will be specified (in the appropriate document covering - the operation of IP over a particular link type). The services - described in this document that are not directly dependent on - multicast, such as Redirects, Next-hop determination, Neighbor - Unreachability Detection, etc., are expected to be provided as - - - - -Loughney Informational [Page 5] - -RFC 4294 IPv6 Node Requirements April 2006 - - - specified in this document. The details of how one uses ND on - NBMA links is an area for further study." - - Some detailed analysis of Neighbor Discovery follows: - - Router Discovery is how hosts locate routers that reside on an - attached link. Router Discovery MUST be supported for - implementations. - - Prefix Discovery is how hosts discover the set of address prefixes - that define which destinations are on-link for an attached link. - Prefix discovery MUST be supported for implementations. Neighbor - Unreachability Detection (NUD) MUST be supported for all paths - between hosts and neighboring nodes. It is not required for paths - between routers. However, when a node receives a unicast Neighbor - Solicitation (NS) message (that may be a NUD's NS), the node MUST - respond to it (i.e., send a unicast Neighbor Advertisement). - - Duplicate Address Detection MUST be supported on all links supporting - link-layer multicast (RFC 2462, Section 5.4, specifies DAD MUST take - place on all unicast addresses). - - A host implementation MUST support sending Router Solicitations. - - Receiving and processing Router Advertisements MUST be supported for - host implementations. The ability to understand specific Router - Advertisement options is dependent on supporting the specification - where the RA is specified. - - Sending and Receiving Neighbor Solicitation (NS) and Neighbor - Advertisement (NA) MUST be supported. NS and NA messages are - required for Duplicate Address Detection (DAD). - - Redirect functionality SHOULD be supported. If the node is a router, - Redirect functionality MUST be supported. - -4.3. Path MTU Discovery and Packet Size - -4.3.1. Path MTU Discovery - RFC 1981 - - Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal - implementations MAY choose to not support it and avoid large packets. - The rules in RFC 2460 MUST be followed for packet fragmentation and - reassembly. - -4.3.2. IPv6 Jumbograms - RFC 2675 - - IPv6 Jumbograms [RFC-2675] MAY be supported. - - - -Loughney Informational [Page 6] - -RFC 4294 IPv6 Node Requirements April 2006 - - -4.4. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 2463 - - ICMPv6 [RFC-2463] MUST be supported. - -4.5. Addressing - -4.5.1. IP Version 6 Addressing Architecture - RFC 3513 - - The IPv6 Addressing Architecture [RFC-3513] MUST be supported as - updated by [RFC-3879]. - -4.5.2. IPv6 Stateless Address Autoconfiguration - RFC 2462 - - IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. - This specification MUST be supported for nodes that are hosts. - Static address can be supported as well. - - Nodes that are routers MUST be able to generate link local addresses - as described in RFC 2462 [RFC-2462]. - - From 2462: - - The autoconfiguration process specified in this document applies - only to hosts and not routers. Since host autoconfiguration uses - information advertised by routers, routers will need to be - configured by some other means. However, it is expected that - routers will generate link-local addresses using the mechanism - described in this document. In addition, routers are expected to - successfully pass the Duplicate Address Detection procedure - described in this document on all addresses prior to assigning - them to an interface. - - Duplicate Address Detection (DAD) MUST be supported. - -4.5.3. Privacy Extensions for Address Configuration in IPv6 - RFC 3041 - - Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] - SHOULD be supported. It is recommended that this behavior be - configurable on a connection basis within each application when - available. It is noted that a number of applications do not work - with addresses generated with this method, while other applications - work quite well with them. - -4.5.4. Default Address Selection for IPv6 - RFC 3484 - - The rules specified in the Default Address Selection for IPv6 - [RFC-3484] document MUST be implemented. It is expected that IPv6 - nodes will need to deal with multiple addresses. - - - -Loughney Informational [Page 7] - -RFC 4294 IPv6 Node Requirements April 2006 - - -4.5.5. Stateful Address Autoconfiguration - - Stateful Address Autoconfiguration MAY be supported. DHCPv6 - [RFC-3315] is the standard stateful address configuration protocol; - see Section 5.3 for DHCPv6 support. - - Nodes which do not support Stateful Address Autoconfiguration may be - unable to obtain any IPv6 addresses, aside from link-local addresses, - when it receives a router advertisement with the 'M' flag (Managed - address configuration) set and that contains no prefixes advertised - for Stateless Address Autoconfiguration (see Section 4.5.2). - Additionally, such nodes will be unable to obtain other configuration - information, such as the addresses of DNS servers when it is - connected to a link over which the node receives a router - advertisement in which the 'O' flag ("Other stateful configuration") - is set. - -4.6. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 - - Nodes that need to join multicast groups SHOULD implement MLDv2 - [RFC-3810]. However, if the node has applications that only need - support for Any-Source Multicast [RFC-3569], the node MAY implement - MLDv1 [RFC-2710] instead. If the node has applications that need - support for Source-Specific Multicast [RFC-3569, SSM-ARCH], the node - MUST support MLDv2 [RFC-3810]. - - When MLD is used, the rules in the "Source Address Selection for the - Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be - followed. - -5. DNS and DHCP - -5.1. DNS - - DNS is described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363], - and [RFC-3596]. Not all nodes will need to resolve names; those that - will never need to resolve DNS names do not need to implement - resolver functionality. However, the ability to resolve names is a - basic infrastructure capability that applications rely on and - generally needs to be supported. All nodes that need to resolve - names SHOULD implement stub-resolver [RFC-1034] functionality, as in - RFC 1034, Section 5.3.1, with support for: - - - AAAA type Resource Records [RFC-3596]; - - - reverse addressing in ip6.arpa using PTR records [RFC-3152]; - - - - - -Loughney Informational [Page 8] - -RFC 4294 IPv6 Node Requirements April 2006 - - - - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 - octets. - - Those nodes are RECOMMENDED to support DNS security extensions - [RFC-4033], [RFC-4034], and [RFC-4035]. - - Those nodes are NOT RECOMMENDED to support the experimental A6 and - DNAME Resource Records [RFC-3363]. - -5.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315 - -5.2.1. Managed Address Configuration - - The method by which IPv6 nodes that use DHCP for address assignment - can obtain IPv6 addresses and other configuration information upon - receipt of a Router Advertisement with the 'M' flag set is described - in Section 5.5.3 of RFC 2462. - - In addition, in the absence of a router, those IPv6 nodes that use - DHCP for address assignment MUST initiate DHCP to obtain IPv6 - addresses and other configuration information, as described in - Section 5.5.2 of RFC 2462. Those IPv6 nodes that do not use DHCP for - address assignment can ignore the 'M' flag in Router Advertisements. - -5.2.2. Other Configuration Information - - The method by which IPv6 nodes that use DHCP to obtain other - configuration information can obtain other configuration information - upon receipt of a Router Advertisement with the 'O' flag set is - described in Section 5.5.3 of RFC 2462. - - Those IPv6 nodes that use DHCP to obtain other configuration - information initiate DHCP for other configuration information upon - receipt of a Router Advertisement with the 'O' flag set, as described - in Section 5.5.3 of RFC 2462. Those IPv6 nodes that do not use DHCP - for other configuration information can ignore the 'O' flag in Router - Advertisements. - - An IPv6 node can use the subset of DHCP (described in [RFC-3736]) to - obtain other configuration information. - -5.3.3. Use of Router Advertisements in Managed Environments - - Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - are expected to determine their default router information and on- - link prefix information from received Router Advertisements. - - - - - -Loughney Informational [Page 9] - -RFC 4294 IPv6 Node Requirements April 2006 - - -6. IPv4 Support and Transition - - IPv6 nodes MAY support IPv4. - -6.1. Transition Mechanisms - -6.1.1. Transition Mechanisms for IPv6 Hosts and Routers - RFC 2893 - - If an IPv6 node implements dual stack and tunneling, then [RFC-4213] - MUST be supported. - -7. Mobile IP - - The Mobile IPv6 [RFC-3775] specification defines requirements for the - following types of nodes: - - - mobile nodes - - - correspondent nodes with support for route optimization - - - home agents - - - all IPv6 routers - - Hosts MAY support mobile node functionality described in Section 8.5 - of [RFC-3775], including support of generic packet tunneling [RFC- - 2473] and secure home agent communications [RFC-3776]. - - Hosts SHOULD support route optimization requirements for - correspondent nodes described in Section 8.2 of [RFC-3775]. - - Routers SHOULD support the generic mobility-related requirements for - all IPv6 routers described in Section 8.3 of [RFC-3775]. Routers MAY - support the home agent functionality described in Section 8.4 of - [RFC-3775], including support of [RFC-2473] and [RFC-3776]. - -8. Security - - This section describes the specification of IPsec for the IPv6 node. - -8.1. Basic Architecture - - Security Architecture for the Internet Protocol [RFC-4301] MUST be - supported. - - - - - - - -Loughney Informational [Page 10] - -RFC 4294 IPv6 Node Requirements April 2006 - - -8.2. Security Protocols - - ESP [RFC-4303] MUST be supported. AH [RFC-4302] MUST be supported. - -8.3. Transforms and Algorithms - - Current IPsec RFCs specify the support of transforms and algorithms - for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, and - HMAC-MD5-96. However, "Cryptographic Algorithm Implementation - Requirements For ESP And AH" [RFC-4305] contains the current set of - mandatory to implement algorithms for ESP and AH. It also specifies - algorithms that should be implemented because they are likely to be - promoted to mandatory at some future time. IPv6 nodes SHOULD conform - to the requirements in [RFC-4305], as well as the requirements - specified below. - - Since ESP encryption and authentication are both optional, support - for the NULL encryption algorithm [RFC-2410] and the NULL - authentication algorithm [RFC-4303] MUST be provided to maintain - consistency with the way these services are negotiated. However, - while authentication and encryption can each be NULL, they MUST NOT - both be NULL. The NULL encryption algorithm is also useful for - debugging. - - The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be supported - within ESP. Security issues related to the use of DES are discussed - in [DESDIFF], [DESINT], and [DESCRACK]. DES-CBC is still listed as - required by the existing IPsec RFCs, but updates to these RFCs will - be published in the near future. DES provides 56 bits of protection, - which is no longer considered sufficient. - - The use of the HMAC-SHA-1-96 algorithm [RFC-2404] within AH and ESP - MUST be supported. The use of the HMAC-MD5-96 algorithm [RFC-2403] - within AH and ESP MAY also be supported. - - The 3DES-CBC encryption algorithm [RFC-2451] does not suffer from the - same security issues as DES-CBC, and the 3DES-CBC algorithm within - ESP MUST be supported to ensure interoperability. - - The AES-128-CBC algorithm [RFC-3602] MUST also be supported within - ESP. AES-128 is expected to be a widely available, secure, and - efficient algorithm. While AES-128-CBC is not required by the - current IPsec RFCs, it is expected to become required in the future. - - - - - - - - -Loughney Informational [Page 11] - -RFC 4294 IPv6 Node Requirements April 2006 - - -8.4. Key Management Methods - - An implementation MUST support the manual configuration of the - security key and SPI. The SPI configuration is needed in order to - delineate between multiple keys. - - Key management SHOULD be supported. Examples of key management - systems include IKEv2 [RFC-4306] and Kerberos; S/MIME and TLS include - key management functions. - - Where key refresh, anti-replay features of AH and ESP, or on-demand - creation of Security Associations (SAs) is required, automated keying - MUST be supported. - - Key management methods for multicast traffic are also being worked on - by the MSEC WG. - -9. Router-Specific Functionality - - This section defines general host considerations for IPv6 nodes that - act as routers. Currently, this section does not discuss routing- - specific requirements. - -9.1. General - -9.1.1. IPv6 Router Alert Option - RFC 2711 - - The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by- - Hop Header that is used in conjunction with some protocols (e.g., - RSVP [RFC-2205] or MLD [RFC-2710]). The Router Alert option will - need to be implemented whenever protocols that mandate its usage are - implemented. See Section 4.6. - -9.1.2. Neighbor Discovery for IPv6 - RFC 2461 - - Sending Router Advertisements and processing Router Solicitation MUST - be supported. - -10. Network Management - - Network Management MAY be supported by IPv6 nodes. However, for IPv6 - nodes that are embedded devices, network management may be the only - possible way of controlling these nodes. - -10.1. Management Information Base Modules (MIBs) - - The following two MIBs SHOULD be supported by nodes that support an - SNMP agent. - - - -Loughney Informational [Page 12] - -RFC 4294 IPv6 Node Requirements April 2006 - - -10.1.1. IP Forwarding Table MIB - - IP Forwarding Table MIB [RFC-4292] SHOULD be supported by nodes that - support an SNMP agent. - -10.1.2. Management Information Base for the Internet Protocol (IP) - - IP MIB [RFC-4293] SHOULD be supported by nodes that support an SNMP - agent. - -11. Security Considerations - - This document does not affect the security of the Internet, but - implementations of IPv6 are expected to support a minimum set of - security features to ensure security on the Internet. "IP Security - Document Roadmap" [RFC-2411] is important for everyone to read. - - The security considerations in RFC 2460 state the following: - - The security features of IPv6 are described in the Security - Architecture for the Internet Protocol [RFC-2401]. - - RFC 2401 has been obsoleted by RFC 4301, therefore refer RFC 4301 for - the security features of IPv6. - -12. References - -12.1. Normative References - - [RFC-1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC-1981] McCann, J., Deering, S., and J. Mogul, "Path MTU - Discovery for IP version 6", RFC 1981, August 1996. - - [RFC-2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: - Keyed-Hashing for Message Authentication", RFC 2104, - February 1997. - - [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC-2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 - within ESP and AH", RFC 2403, November 1998. - - [RFC-2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 - within ESP and AH", RFC 2404, November 1998. - - - - -Loughney Informational [Page 13] - -RFC 4294 IPv6 Node Requirements April 2006 - - - [RFC-2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher - Algorithm With Explicit IV", RFC 2405, November 1998. - - [RFC-2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm - and Its Use With IPsec", RFC 2410, November 1998. - - [RFC-2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security - Document Roadmap", RFC 2411, November 1998. - - [RFC-2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher - Algorithms", RFC 2451, November 1998. - - [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version - 6 (IPv6) Specification", RFC 2460, December 1998. - - [RFC-2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor - Discovery for IP Version 6 (IPv6)", RFC 2461, December - 1998. - - [RFC-2462] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. - - [RFC-2463] Conta, A. and S. Deering, "Internet Control Message - Protocol (ICMPv6) for the Internet Protocol Version 6 - (IPv6) Specification", RFC 2463, December 1998. - - [RFC-2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC - 2472, December 1998. - - [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in - IPv6 Specification", RFC 2473, December 1998. - - [RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC-2710] Deering, S., Fenner, W., and B. Haberman, "Multicast - Listener Discovery (MLD) for IPv6", RFC 2710, October - 1999. - - [RFC-2711] Partridge, C. and A. Jackson, "IPv6 Router Alert - Option", RFC 2711, October 1999. - - [RFC-3041] Narten, T. and R. Draves, "Privacy Extensions for - Stateless Address Autoconfiguration in IPv6", RFC - 3041, January 2001. - - [RFC-3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, - August 2001. - - - -Loughney Informational [Page 14] - -RFC 4294 IPv6 Node Requirements April 2006 - - - [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, - C., and M. Carney, "Dynamic Host Configuration - Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. - - [RFC-3363] 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. - - [RFC-3484] Frye, R., Levi, D., Routhier, S., and B. Wijnen, - "Coexistence between Version 1, Version 2, and Version - 3 of the Internet-standard Network Management - Framework", BCP 74, RFC 3584, August 2003. - - [RFC-3513] Hinden, R. and S. Deering, "Internet Protocol Version - 6 (IPv6) Addressing Architecture", RFC 3513, April - 2003. - - [RFC-3590] Haberman, B., "Source Address Selection for the - Multicast Listener Discovery (MLD) Protocol", RFC - 3590, September 2003. - - [RFC-3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, - "DNS Extensions to Support IP Version 6", RFC 3596, - October 2003. - - [RFC-3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC - Cipher Algorithm and Its Use with IPsec", RFC 3602, - September 2003. - - [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility - Support in IPv6", RFC 3775, June 2004. - - [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using - IPsec to Protect Mobile IPv6 Signaling Between Mobile - Nodes and Home Agents", RFC 3776, June 2004. - - [RFC-3810] Vida, R. and L. Costa, "Multicast Listener Discovery - Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. - - [RFC-3879] Huitema, C. and B. Carpenter, "Deprecating Site Local - Addresses", RFC 3879, September 2004. - - [RFC-4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, - April 2006. - - [RFC-4293] Routhier, S., Ed., "Management Information Base for - the Internet Protocol (IP)", RFC 4293, April 2006. - - - -Loughney Informational [Page 15] - -RFC 4294 IPv6 Node Requirements April 2006 - - - [RFC-4301] Kent, S. and R. Atkinson, "Security Architecture for - the Internet Protocol", RFC 4301, December 2005. - - [RFC-4302] Kent, S., "IP Authentication Header", RFC 4302, - December 2005. - - [RFC-4303] Kent, S., "IP Encapsulating Security Payload (ESP)", - RFC 4303, December 2005. - - [RFC-4305] Eastlake 3rd, D., "Cryptographic Algorithm - Implementation Requirements for Encapsulating Security - Payload (ESP) and Authentication Header (AH)", RFC - 4305, December 2005. - -12.2. Informative References - - [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of - DES-like cryptosystems", Journal of Cryptology Vol 4, - Jan 1991. - - [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA - 2000. - - [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without - Strong Integrity", Proceedings of the 32nd IETF, - Danvers, MA, April 1995. - - [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home - Address Options", Work in Progress. - - [RFC-793] Postel, J., "Transmission Control Protocol", STD 7, - RFC 793, September 1981. - - [RFC-1034] Mockapetris, P., "Domain names - concepts and - facilities", STD 13, RFC 1034, November 1987. - - [RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. - Jamin, "Resource ReSerVation Protocol (RSVP) -- - Version 1 Functional Specification", RFC 2205, - September 1997. - - [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over - Ethernet Networks", RFC 2464, December 1998. - - [RFC-2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over - ATM Networks", RFC 2492, January 1999. - - - - - -Loughney Informational [Page 16] - -RFC 4294 IPv6 Node Requirements April 2006 - - - [RFC-2675] Borman, D., Deering, S., and R. Hinden, "IPv6 - Jumbograms", RFC 2675, August 1999. - - [RFC-4213] Nordmark, E. and R. Gilligan, "Basic Transition - Mechanisms for IPv6 Hosts and Routers", RFC 4213, - October 2005. - - [RFC-3569] Bhattacharyya, S., "An Overview of Source-Specific - Multicast (SSM)", RFC 3569, July 2003. - - [RFC-3736] Droms, R., "Stateless Dynamic Host Configuration - Protocol (DHCP) Service for IPv6", RFC 3736, April - 2004. - - [RFC-4001] Daniele, M., Haberman, B., Routhier, S., and J. - Schoenwaelder, "Textual Conventions for Internet - Network Addresses", RFC 4001, February 2005. - - [RFC-4033] Arends, R., Austein, R., Larson, M., Massey, D., and - S. Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC-4034] Arends, R., Austein, R., Larson, M., Massey, D., and - S. Rose, "Resource Records for the DNS Security - Extensions", RFC 4034, March 2005. - - [RFC-4035] Arends, R., Austein, R., Larson, M., Massey, D., and - S. Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC-4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) - Protocol", RFC 4306, December 2005. - - [SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for - IP", Work in Progress. - - - - - - - - - - - - - - - - -Loughney Informational [Page 17] - -RFC 4294 IPv6 Node Requirements April 2006 - - -13. Authors and Acknowledgements - - This document was written by the IPv6 Node Requirements design team: - - Jari Arkko - [jari.arkko@ericsson.com] - - Marc Blanchet - [marc.blanchet@viagenie.qc.ca] - - Samita Chakrabarti - [samita.chakrabarti@eng.sun.com] - - Alain Durand - [alain.durand@sun.com] - - Gerard Gastaud - [gerard.gastaud@alcatel.fr] - - Jun-ichiro itojun Hagino - [itojun@iijlab.net] - - Atsushi Inoue - [inoue@isl.rdc.toshiba.co.jp] - - Masahiro Ishiyama - [masahiro@isl.rdc.toshiba.co.jp] - - John Loughney - [john.loughney@nokia.com] - - Rajiv Raghunarayan - [raraghun@cisco.com] - - Shoichi Sakane - [shouichi.sakane@jp.yokogawa.com] - - Dave Thaler - [dthaler@windows.microsoft.com] - - Juha Wiljakka - [juha.wiljakka@Nokia.com] - - The authors would like to thank Ran Atkinson, Jim Bound, Brian - Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas - Narten, Juha Ollila, and Pekka Savola for their comments. - - - - - -Loughney Informational [Page 18] - -RFC 4294 IPv6 Node Requirements April 2006 - - -Editor's Contact Information - - Comments or questions regarding this document should be sent to the - IPv6 Working Group mailing list (ipv6@ietf.org) or to: - - John Loughney - Nokia Research Center - Itamerenkatu 11-13 - 00180 Helsinki - Finland - - Phone: +358 50 483 6242 - EMail: John.Loughney@Nokia.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Loughney Informational [Page 19] - -RFC 4294 IPv6 Node Requirements April 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Loughney Informational [Page 20] - diff --git a/doc/rfc/rfc4339.txt b/doc/rfc/rfc4339.txt deleted file mode 100644 index a6f29d9f430..00000000000 --- a/doc/rfc/rfc4339.txt +++ /dev/null @@ -1,1459 +0,0 @@ - - - - - - -Network Working Group J. Jeong, Ed. -Request for Comments: 4339 ETRI/University of Minnesota -Category: Informational February 2006 - - - IPv6 Host Configuration of DNS Server Information Approaches - - -Status of This Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -IESG Note - - This document describes three different approaches for the - configuration of DNS name resolution server information in IPv6 - hosts. - - There is not an IETF consensus on which approach is preferred. The - analysis in this document was developed by the proponents for each - approach and does not represent an IETF consensus. - - The 'RA option' and 'Well-known anycast' approaches described in this - document are not standardized. Consequently the analysis for these - approaches might not be completely applicable to any specific - proposal that might be proposed in the future. - -Abstract - - This document describes three approaches for IPv6 recursive DNS - server address configuration. It details the operational attributes - of three solutions: RA option, DHCPv6 option, and well-known anycast - addresses for recursive DNS servers. Additionally, it suggests the - deployment scenarios in four kinds of networks (ISP, enterprise, - 3GPP, and unmanaged networks) considering multi-solution resolution. - - - - - - - - - - -Jeong Informational [Page 1] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - -Table of Contents - - 1. Introduction ....................................................3 - 2. Terminology .....................................................3 - 3. IPv6 DNS Configuration Approaches ...............................3 - 3.1. RA Option ..................................................3 - 3.1.1. Advantages ..........................................4 - 3.1.2. Disadvantages .......................................5 - 3.1.3. Observations ........................................5 - 3.2. DHCPv6 Option ..............................................6 - 3.2.1. Advantages ..........................................7 - 3.2.2. Disadvantages .......................................8 - 3.2.3. Observations ........................................9 - 3.3. Well-known Anycast Addresses ...............................9 - 3.3.1. Advantages .........................................10 - 3.3.2. Disadvantages ......................................10 - 3.3.3. Observations .......................................10 - 4. Interworking among IPv6 DNS Configuration Approaches ...........11 - 5. Deployment Scenarios ...........................................12 - 5.1. ISP Network ...............................................12 - 5.1.1. RA Option Approach .................................13 - 5.1.2. DHCPv6 Option Approach .............................13 - 5.1.3. Well-known Anycast Addresses Approach ..............14 - 5.2. Enterprise Network ........................................14 - 5.3. 3GPP Network ..............................................15 - 5.3.1. Currently Available Mechanisms and - Recommendations ....................................15 - 5.3.2. RA Extension .......................................16 - 5.3.3. Stateless DHCPv6 ...................................16 - 5.3.4. Well-known Addresses ...............................17 - 5.3.5. Recommendations ....................................18 - 5.4. Unmanaged Network .........................................18 - 5.4.1. Case A: Gateway Does Not Provide IPv6 at All .......18 - 5.4.2. Case B: A Dual-stack Gateway Connected to a - Dual-stack ISP .....................................19 - 5.4.3. Case C: A Dual-stack Gateway Connected to - an IPv4-only ISP ...................................19 - 5.4.4. Case D: A Gateway Connected to an IPv6-only ISP ....19 - 6. Security Considerations ........................................19 - 6.1. RA Option .................................................20 - 6.2. DHCPv6 Option .............................................21 - 6.3. Well-known Anycast Addresses ..............................21 - 7. Contributors ...................................................21 - 8. Acknowledgements ...............................................23 - 9. References .....................................................23 - 9.1. Normative References ......................................23 - 9.2. Informative References ....................................23 - - - - -Jeong Informational [Page 2] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - -1. Introduction - - Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address - Autoconfiguration provide ways to configure either fixed or mobile - nodes with one or more IPv6 addresses, default routes, and some other - parameters [1][2]. To support the access to additional services in - the Internet that are identified by a DNS name, such as a web server, - the configuration of at least one recursive DNS server is also needed - for DNS name resolution. - - This document describes three approaches of recursive DNS server - address configuration for IPv6 host: (a) RA option [6], (b) DHCPv6 - option [3]-[5], and (c) well-known anycast addresses for recursive - DNS servers [7]. Also, it suggests the applicable scenarios for four - kinds of networks: (a) ISP network, (b) enterprise network, (c) 3GPP - network, and (d) unmanaged network. - - This document is just an analysis of each possible approach, and it - does not recommend a particular approach or combination of - approaches. Some approaches may even not be adopted at all as a - result of further discussion. - - Therefore, the objective of this document is to help the audience - select the approaches suitable for IPv6 host configuration of - recursive DNS servers. - -2. Terminology - - This document uses the terminology described in [1]-[7]. In - addition, a new term is defined below: - - o Recursive DNS Server (RDNSS): Server which provides a recursive - DNS resolution service. - -3. IPv6 DNS Configuration Approaches - - In this section, the operational attributes of the three solutions - are described in detail. - -3.1. RA Option - - The RA approach defines a new ND option, called the RDNSS option, - that contains a recursive DNS server address [6]. Existing ND - transport mechanisms (i.e., advertisements and solicitations) are - used. This works in the same way that nodes learn about routers and - prefixes. An IPv6 host can configure the IPv6 addresses of one or - more RDNSSes via RA message periodically sent by a router or - solicited by a Router Solicitation (RS). - - - -Jeong Informational [Page 3] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - This approach needs RDNSS information to be configured in the routers - doing the advertisements. The configuration of RDNSS addresses can - be performed manually by an operator or in other ways, such as - automatic configuration through a DHCPv6 client running on the - router. An RA message with one RDNSS option can include as many - RDNSS addresses as needed [6]. - - Through the ND protocol and RDNSS option, along with a prefix - information option, an IPv6 host can perform network configuration of - its IPv6 address and RDNSS simultaneously [1][2]. The RA option for - RDNSS can be used on any network that supports the use of ND. - - The RA approach is useful in some mobile environments where the - addresses of the RDNSSes are changing because the RA option includes - a lifetime field that allows client to use RDNSSes nearer to the - client. This can be configured to a value that will require the - client to time out the entry and switch over to another RDNSS address - [6]. However, from the viewpoint of implementation, the lifetime - field would seem to make matters a bit more complex. Instead of just - writing to a DNS configuration file, such as resolv.conf for the list - of RDNSS addresses, we have to have a daemon around (or a program - that is called at the defined intervals) that keeps monitoring the - lifetime of RDNSSes all the time. - - The preference value of RDNSS, included in the RDNSS option, allows - IPv6 hosts to select primary RDNSS among several RDNSSes [6]; this - can be used for the load balancing of RDNSSes. - -3.1.1. Advantages - - The RA option for RDNSS has a number of advantages. These include: - - 1. The RA option is an extension of existing ND/Autoconfig - mechanisms [1][2] and does not require a change in the base ND - protocol. - - 2. This approach, like ND, works well on a variety of link types, - including point-to-point links, point-to-multipoint, and - multipoint-to-multipoint (i.e., Ethernet LANs). RFC 2461 [1] - states, however, that there may be some link types on which ND is - not feasible; on such links, some other mechanisms will be needed - for DNS configuration. - - 3. All the information a host needs to run the basic Internet - applications (such as the email, web, ftp, etc.) can be obtained - with the addition of this option to ND and address - autoconfiguration. The use of a single mechanism is more - reliable and easier to provide than when the RDNSS information is - - - -Jeong Informational [Page 4] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - learned via another protocol mechanism. Debugging problems when - multiple protocol mechanisms are being used is harder and much - more complex. - - 4. This mechanism works over a broad range of scenarios and - leverages IPv6 ND. This works well on links that are high - performance (e.g., Ethernet LANs) and low performance (e.g., - cellular networks). In the latter case, by combining the RDNSS - information with the other information in the RA, the host can - learn all the information needed to use most Internet - applications, such as the web, in a single packet. This not only - saves bandwidth, but also minimizes the delay needed to learn the - RDNSS information. - - 5. The RA approach could be used as a model for similar types of - configuration information. New RA options for other server - addresses, such as NTP server address, that are common to all - clients on a subnet would be easy to define. - -3.1.2. Disadvantages - - 1. ND is mostly implemented in the kernel of the operating system. - Therefore, if ND supports the configuration of some additional - services, such as DNS servers, ND should be extended in the - kernel and complemented by a user-land process. DHCPv6, however, - has more flexibility for the extension of service discovery - because it is an application layer protocol. - - 2. The current ND framework should be modified to facilitate the - synchronization between another ND cache for RDNSSes in the - kernel space and the DNS configuration file in the user space. - Because it is unacceptable to write and rewrite to the DNS - configuration file (e.g., resolv.conf) from the kernel, another - approach is needed. One simple approach to solve this is to have - a daemon listening to what the kernel conveys, and to have the - daemon do these steps, but such a daemon is not needed with the - current ND framework. - - 3. It is necessary to configure RDNSS addresses at least at one - router on every link where this information needs to be - configured via the RA option. - -3.1.3. Observations - - The proposed RDNSS RA option, along with the IPv6 ND and - Autoconfiguration, allows a host to obtain all of the information it - needs to access basic Internet services like the web, email, ftp, - etc. This is preferable in the environments where hosts use RAs to - - - -Jeong Informational [Page 5] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - autoconfigure their addresses and all the hosts on the subnet share - the same router and server addresses. If the configuration - information can be obtained from a single mechanism, it is preferable - because it does not add additional delay, and because it uses a - minimum of bandwidth. Environments like this include homes, public - cellular networks, and enterprise environments where no per host - configuration is needed. - - DHCPv6 is preferable where it is being used for address configuration - and if there is a need for host specific configuration [3]-[5]. - Environments like this are most likely to be the enterprise - environments where the local administration chooses to have per host - configuration control. - -3.2. DHCPv6 Option - - DHCPv6 [3] includes the "DNS Recursive Name Server" option, through - which a host can obtain a list of IP addresses of recursive DNS - servers [5]. The DNS Recursive Name Server option carries a list of - IPv6 addresses of RDNSSes to which the host may send DNS queries. - The DNS servers are listed in the order of preference for use by the - DNS resolver on the host. - - The DNS Recursive Name Server option can be carried in any DHCPv6 - Reply message, in response to either a Request or an Information - request message. Thus, the DNS Recursive Name Server option can be - used either when DHCPv6 is used for address assignment, or when - DHCPv6 is used only for other configuration information as stateless - DHCPv6 [4]. - - Stateless DHCPv6 can be deployed either by using DHCPv6 servers - running on general-purpose computers, or on router hardware. Several - router vendors currently implement stateless DHCPv6 servers. - Deploying stateless DHCPv6 in routers has the advantage that no - special hardware is required, and it should work well for networks - where DHCPv6 is needed for very straightforward configuration of - network devices. - - However, routers can also act as DHCPv6 relay agents. In this case, - the DHCPv6 server need not be on the router; it can be on a general - purpose computer. This has the potential to give the operator of the - DHCPv6 server more flexibility in how the DHCPv6 server responds to - individual clients that can easily be given different configuration - information based on their identity, or for any other reason. - Nothing precludes adding this flexibility to a router, but generally, - in current practice, DHCP servers running on general-purpose hosts - tend to have more configuration options than those that are embedded - in routers. - - - -Jeong Informational [Page 6] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 - clients that use a stateful configuration assignment. To do this, - the DHCPv6 server sends a Reconfigure message to the client. The - client validates the Reconfigure message, and then contacts the - DHCPv6 server to obtain updated configuration information. By using - this mechanism, it is currently possible to propagate new - configuration information to DHCPv6 clients as this information - changes. - - The DHC Working Group has standardized an additional mechanism - through which configuration information, including the list of - RDNSSes, can be updated. The lifetime option for DHCPv6 [8] assigns - a lifetime to configuration information obtained through DHCPv6. At - the expiration of the lifetime, the host contacts the DHCPv6 server - to obtain updated configuration information, including the list of - RDNSSes. This lifetime gives the network administrator another - mechanism to configure hosts with new RDNSSes by controlling the time - at which the host refreshes the list. - - The DHC Working Group has also discussed the possibility of defining - an extension to DHCPv6 that would allow the use of multicast to - provide configuration information to multiple hosts with a single - DHCPv6 message. Because of the lack of deployment experience, the WG - has deferred consideration of multicast DHCPv6 configuration at this - time. Experience with DHCPv4 has not identified a requirement for - multicast message delivery, even in large service provider networks - with tens of thousands of hosts that may initiate a DHCPv4 message - exchange simultaneously. - -3.2.1. Advantages - - The DHCPv6 option for RDNSS has a number of advantages. These - include: - - 1. DHCPv6 currently provides a general mechanism for conveying - network configuration information to clients. Configuring DHCPv6 - servers in this way allows the network administrator to configure - RDNSSes, the addresses of other network services, and location- - specific information, such as time zones. - - 2. As a consequence, when the network administrator goes to - configure DHCPv6, all the configuration information can be - managed through a single service, typically with a single user - interface and a single configuration database. - - - - - - - -Jeong Informational [Page 7] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - 3. DHCPv6 allows for the configuration of a host with information - specific to that host, so that hosts on the same link can be - configured with different RDNSSes and with other configuration - information. - - 4. A mechanism exists for extending DHCPv6 to support the - transmission of additional configuration that has not yet been - anticipated. - - 5. Hosts that require other configuration information, such as the - addresses of SIP servers and NTP servers, are likely to need - DHCPv6 for other configuration information. - - 6. The specification for configuration of RDNSSes through DHCPv6 is - available as an RFC. No new protocol extensions (such as new - options) are necessary. - - 7. Interoperability among independent implementations has been - demonstrated. - -3.2.2. Disadvantages - - The DHCPv6 option for RDNSS has a few disadvantages. These include: - - 1. Update currently requires a message from server (however, see - [8]). - - 2. Because DNS information is not contained in RA messages, the host - must receive two messages from the router and must transmit at - least one message to the router. On networks where bandwidth is - at a premium, this is a disadvantage, although on most networks - it is not a practical concern. - - 3. There is an increased latency for initial configuration. In - addition to waiting for an RA message, the client must now - exchange packets with a DHCPv6 server. Even if it is locally - installed on a router, this will slightly extend the time - required to configure the client. For clients that are moving - rapidly from one network to another, this will be a disadvantage. - - - - - - - - - - - - -Jeong Informational [Page 8] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - -3.2.3. Observations - - In the general case, on general-purpose networks, stateless DHCPv6 - provides significant advantages and no significant disadvantages. - Even in the case where bandwidth is at a premium and low latency is - desired, if hosts require other configuration information in addition - to a list of RDNSSes or if hosts must be configured selectively, - those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive - name server option will be advantageous. - - However, we are aware of some applications where it would be - preferable to put the RDNSS information into an RA packet; for - example, in a mobile phone network, where bandwidth is at a premium - and extremely low latency is desired. The DNS configuration based on - RA should be standardized so as to allow these special applications - to be handled using DNS information in the RA packet. - -3.3. Well-known Anycast Addresses - - Anycast uses the same routing system as unicast [9]. However, - administrative entities are local ones. The local entities may - accept unicast routes (including default routes) to anycast servers - from adjacent entities. The administrative entities should not - advertise their peer routes to their internal anycast servers, if - they want to prohibit external access from some peers to the servers. - If some advertisement is inevitable (such as the case with default - routes), the packets to the servers should be blocked at the boundary - of the entities. Thus, for this anycast, not only unicast routing - but also unicast ND protocols can be used as is. - - First of all, the well-known anycast addresses approach is much - different from that discussed by the IPv6 Working Group in the past - [7]. Note that "anycast" in this memo is simpler than that of RFC - 1546 [9] and RFC 3513 [10], where it is assumed to be prohibited to - have multiple servers on a single link sharing an anycast address. - That is, on a link, an anycast address is assumed to be unique. DNS - clients today already have redundancy by having multiple well-known - anycast addresses configured as RDNSS addresses. There is no point - in having multiple RDNSSes sharing an anycast address on a single - link. - - The approach with well-known anycast addresses is to set multiple - well-known anycast addresses in clients' resolver configuration files - from the beginning as, say, factory default. Thus, there is no - transport mechanism and no packet format [7]. - - An anycast address is an address shared by multiple servers (in this - case, the servers are RDNSSes). A request from a client to the - - - -Jeong Informational [Page 9] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - anycast address is routed to a server selected by the routing system. - However, it is a bad idea to mandate "site" boundary on anycast - addresses, because most users do not have their own servers and want - to access their ISPs across their site boundaries. Larger sites may - also depend on their ISPs or may have their own RDNSSes within "site" - boundaries. - -3.3.1. Advantages - - The basic advantage of the well-known addresses approach is that it - uses no transport mechanism. Thus, the following apply: - - 1. There is no delay to get the response and no further delay by - packet losses. - - 2. The approach can be combined with any other configuration - mechanisms, such as the RA-based approach and DHCP-based - approach, as well as the factory default configuration. - - 3. The approach works over any environment where DNS works. - - Another advantage is that this approach only needs configuration of - the DNS servers as a router (or configuration of a proxy router). - Considering that DNS servers do need configuration, the amount of - overall configuration effort is proportional to the number of DNS - servers and it scales linearly. Note that, in the simplest case, - where a subscriber to an ISP does not have a DNS server, the - subscriber naturally accesses DNS servers of the ISP, even though the - subscriber and the ISP do nothing and there is no protocol to - exchange DNS server information between the subscriber and the ISP. - -3.3.2. Disadvantages - - The well-known anycast addresses approach requires that DNS servers - (or routers near to them as a proxy) act as routers to advertise - their anycast addresses to the routing system, which requires some - configuration (see the last paragraph of the previous section on the - scalability of the effort). In addition, routers at the boundary of - the "site" might need the configuration of route filters to prevent - providing DNS services for parties outside the "site" and the - possibility of denial of service attacks on the internal DNS - infrastructure. - -3.3.3. Observations - - If other approaches are used in addition, the well-known anycast - addresses should also be set in RA or DHCP configuration files to - reduce the configuration effort of users. - - - -Jeong Informational [Page 10] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - The redundancy by multiple RDNSSes is better provided by multiple - servers with different anycast addresses than by multiple servers - sharing the same anycast address, because the former approach allows - stale servers to generate routes to their anycast addresses. Thus, - in a routing domain (or domains sharing DNS servers), there will be - only one server with an anycast address unless the domain is so large - that load distribution is necessary. - - Small ISPs will operate one RDNSS at each anycast address that is - shared by all the subscribers. Large ISPs may operate multiple - RDNSSes at each anycast address to distribute and reduce load, where - the boundary between RDNSSes may be fixed (redundancy is still - provided by multiple addresses) or change dynamically. DNS packets - with the well-known anycast addresses are not expected (though not - prohibited) to cross ISP boundaries, as ISPs are expected to be able - to take care of themselves. - - Because "anycast" in this memo is simpler than that of RFC 1546 [9] - and RFC 3513 [10], where it is assumed to be administratively - prohibited to have multiple servers on a single link sharing an - anycast address, anycast in this memo should be implemented as - UNICAST of RFC 2461 [1] and RFC 3513 [10]. As a result, ND-related - instability disappears. Thus, in the well-known anycast addresses - approach, anycast can and should use the anycast address as a source - unicast (according to RFC 3513 [10]) address of packets of UDP and - TCP responses. With TCP, if a route flips and packets to an anycast - address are routed to a new server, it is expected that the flip is - detected by ICMP or sequence number inconsistency, and that the TCP - connection is reset and retried. - -4. Interworking among IPv6 DNS Configuration Approaches - - Three approaches can work together for IPv6 host configuration of - RDNSS. This section shows a consideration on how these approaches - can interwork. - - For ordering between RA and DHCP approaches, the O (Other stateful - configuration) flag in the RA message can be used [6][28]. If no - RDNSS option is included, an IPv6 host may perform DNS configuration - through DHCPv6 [3]-[5] regardless of whether the O flag is set or - not. - - The well-known anycast addresses approach fully interworks with the - other approaches. That is, the other approaches can remove the - configuration effort on servers by using the well-known addresses as - the default configuration. Moreover, the clients preconfigured with - the well-known anycast addresses can be further configured to use - other approaches to override the well-known addresses, if the - - - -Jeong Informational [Page 11] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - configuration information from other approaches is available. - Otherwise, all the clients need to have the well-known anycast - addresses preconfigured. In order to use the anycast approach along - with two other approaches, there are three choices as follows: - - 1. The first choice is that well-known addresses are used as last - resort, when an IPv6 host cannot get RDNSS information through RA - and DHCP. The well-known anycast addresses have to be - preconfigured in all of IPv6 hosts' resolver configuration files. - - 2. The second is that an IPv6 host can configure well-known - addresses as the most preferable in its configuration file even - though either an RA option or DHCP option is available. - - 3. The last is that the well-known anycast addresses can be set in - RA or DHCP configuration to reduce the configuration effort of - users. According to either the RA or DHCP mechanism, the well- - known addresses can be obtained by an IPv6 host. Because this - approach is the most convenient for users, the last option is - recommended. - - Note: This section does not necessarily mean that this document - suggests adopting all of these three approaches and making them - interwork in the way described here. In fact, as a result of further - discussion some approaches may not even be adopted at all. - -5. Deployment Scenarios - - Regarding the DNS configuration on the IPv6 host, several mechanisms - are being considered by the DNSOP Working Group, such as RA option, - DHCPv6 option, and well-known preconfigured anycast addresses as of - today, and this document is a final result from the long thread. In - this section, we suggest four applicable scenarios of three - approaches for IPv6 DNS configuration. - - Note: In the applicable scenarios, authors do not implicitly push any - specific approaches into the restricted environments. No enforcement - is in each scenario, and all mentioned scenarios are probable. The - main objective of this work is to provide a useful guideline for IPv6 - DNS configuration. - -5.1. ISP Network - - A characteristic of an ISP network is that multiple Customer Premises - Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) - routers and that each PE connects multiple CPE devices to the - backbone network infrastructure [11]. The CPEs may be hosts or - routers. - - - -Jeong Informational [Page 12] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - If the CPE is a router, there is a customer network that is connected - to the ISP backbone through the CPE. Typically, each customer - network gets a different IPv6 prefix from an IPv6 PE router, but the - same RDNSS configuration will be distributed. - - This section discusses how the different approaches to distributing - DNS information are compared in an ISP network. - -5.1.1. RA Option Approach - - When the CPE is a host, the RA option for RDNSS can be used to allow - the CPE to get RDNSS information and /64 prefix information for - stateless address autoconfiguration at the same time when the host is - attached to a new subnet [6]. Because an IPv6 host must receive at - least one RA message for stateless address autoconfiguration and - router configuration, the host could receive RDNSS configuration - information in the RA without the overhead of an additional message - exchange. - - When the CPE is a router, the CPE may accept the RDNSS information - from the RA on the interface connected to the ISP and copy that - information into the RAs advertised in the customer network. - - This approach is more valuable in the mobile host scenario, in which - the host must receive at least an RA message for detecting a new - network, than in other scenarios generally, although the - administrator should configure RDNSS information on the routers. - Secure ND [12] can provide extended security when RA messages are - used. - -5.1.2. DHCPv6 Option Approach - - DHCPv6 can be used for RDNSS configuration through the use of the DNS - option, and can provide other configuration information in the same - message with RDNSS configuration [3]-[5]. The DHCPv6 DNS option is - already in place for DHCPv6, as RFC 3646 [5] and DHCPv6-lite or - stateless DHCP [4] is not nearly as complex as a full DHCPv6 - implementation. DHCP is a client-server model protocol, so ISPs can - handle user identification on its network intentionally; also, - authenticated DHCP [13] can be used for secure message exchange. - - The expected model for deployment of IPv6 service by ISPs is to - assign a prefix to each customer, which will be used by the customer - gateway to assign a /64 prefix to each network in the customer's - network. Prefix delegation with DHCP (DHCPv6 PD) has already been - adopted by ISPs for automating the assignment of the customer prefix - to the customer gateway [15]. DNS configuration can be carried in - the same DHCPv6 message exchange used for DHCPv6 to provide that - - - -Jeong Informational [Page 13] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - information efficiently, along with any other configuration - information needed by the customer gateway or customer network. This - service model can be useful to Home or SOHO subscribers. The Home or - SOHO gateway, which is a customer gateway for ISP, can then pass that - RDNSS configuration information to the hosts in the customer network - through DHCP. - -5.1.3. Well-known Anycast Addresses Approach - - The well-known anycast addresses approach is also a feasible and - simple mechanism for ISP [7]. The use of well-known anycast - addresses avoids some of the security risks in rogue messages sent - through an external protocol such as RA or DHCPv6. The configuration - of hosts for the use of well-known anycast addresses requires no - protocol or manual configuration, but the configuration of routing - for the anycast addresses requires intervention on the part of the - network administrator. Also, the number of special addresses would - be equal to the number of RDNSSes that could be made available to - subscribers. - -5.2. Enterprise Network - - An enterprise network is defined as a network that has multiple - internal links, one or more router connections to one or more - providers, and is actively managed by a network operations entity - [14]. An enterprise network can get network prefixes from an ISP by - either manual configuration or prefix delegation [15]. In most - cases, because an enterprise network manages its own DNS domains, it - operates its own DNS servers for the domains. These DNS servers - within enterprise networks process recursive DNS name resolution - requests from IPv6 hosts as RDNSSes. The RDNSS configuration in the - enterprise network can be performed as it is in Section 4, in which - three approaches can be used together as follows: - - 1. An IPv6 host can decide which approach is or may be used in its - subnet with the O flag in RA message [6][28]. As the first - choice in Section 4, well-known anycast addresses can be used as - a last resort when RDNSS information cannot be obtained through - either an RA option or a DHCP option. This case needs IPv6 hosts - to preconfigure the well-known anycast addresses in their DNS - configuration files. - - 2. When the enterprise prefers the well-known anycast approach to - others, IPv6 hosts should preconfigure the well-known anycast - addresses as it is in the first choice. - - 3. The last choice, a more convenient and transparent way, does not - need IPv6 hosts to preconfigure the well-known anycast addresses - - - -Jeong Informational [Page 14] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - because the addresses are delivered to IPv6 hosts via either the - RA option or DHCPv6 option as if they were unicast addresses. - This way is most recommended for the sake of the user's - convenience. - -5.3. 3GPP Network - - The IPv6 DNS configuration is a missing part of IPv6 - autoconfiguration and an important part of the basic IPv6 - functionality in the 3GPP User Equipment (UE). The higher-level - description of the 3GPP architecture can be found in [16], and - transition to IPv6 in 3GPP networks is analyzed in [17] and [18]. - - In the 3GPP architecture, there is a dedicated link between the UE - and the GGSN called the Packet Data Protocol (PDP) Context. This - link is created through the PDP Context activation procedure [19]. - There is a separate PDP context type for IPv4 and IPv6 traffic. If a - 3GPP UE user is communicating by using IPv6 (i.e., by having an - active IPv6 PDP context), it cannot be assumed that the user - simultaneously has an active IPv4 PDP context, and DNS queries could - be done using IPv4. A 3GPP UE can thus be an IPv6 node, and somehow - it needs to discover the address of the RDNSS. Before IP-based - services (e.g., web browsing or e-mail) can be used, the IPv6 (and - IPv4) RDNSS addresses need to be discovered in the 3GPP UE. - - Section 5.3.1 briefly summarizes currently available mechanisms in - 3GPP networks and recommendations. 5.3.2 analyzes the Router - Advertisement-based solution, 5.3.3 analyzes the Stateless DHCPv6 - mechanism, and 5.3.4 analyzes the well-known addresses approach. - Section 5.3.5 summarizes the recommendations. - -5.3.1. Currently Available Mechanisms and Recommendations - - 3GPP has defined a mechanism in which RDNSS addresses can be received - in the PDP context activation (a control plane mechanism). That is - called the Protocol Configuration Options Information Element (PCO- - IE) mechanism [20]. The RDNSS addresses can also be received over - the air (using text messages) or typed in manually in the UE. Note - that the two last mechanisms are not very well scalable. The UE user - most probably does not want to type IPv6 RDNSS addresses manually in - the user's UE. The use of well-known addresses is briefly discussed - in section 5.3.4. - - It is seen that the mechanisms above most probably are not sufficient - for the 3GPP environment. IPv6 is intended to operate in a zero- - configuration manner, no matter what the underlying network - infrastructure is. Typically, the RDNSS address is needed to make an - IPv6 node operational, and the DNS configuration should be as simple - - - -Jeong Informational [Page 15] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - as the address autoconfiguration mechanism. Note that there will be - additional IP interfaces in some near-future 3GPP UEs; e.g., 3GPP- - specific DNS configuration mechanisms (such as PCO-IE [20]) do not - work for those IP interfaces. In other words, a good IPv6 DNS - configuration mechanism should also work in a multi-access network - environment. - - From a 3GPP point of view, the best IPv6 DNS configuration solution - is feasible for a very large number of IPv6-capable UEs (even - hundreds of millions in one operator's network), is automatic, and - thus requires no user action. It is suggested that a lightweight, - stateless mechanism be standardized for use in all network - environments. The solution could then be used for 3GPP, 3GPP2, and - other access network technologies. Thus, not only is a light, - stateless IPv6 DNS configuration mechanism needed in 3GPP networks, - but also 3GPP networks and UEs would certainly benefit from the new - mechanism. - -5.3.2. RA Extension - - Router Advertisement extension [6] is a lightweight IPv6 DNS - configuration mechanism that requires minor changes in the 3GPP UE - IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in - the 3GPP architecture) IPv6 stack. This solution can be specified in - the IETF (no action is needed in the 3GPP) and taken in use in 3GPP - UEs and GGSNs. - - In this solution, an IPv6-capable UE configures DNS information via - an RA message sent by its default router (GGSN); i.e., the RDNSS - option for a recursive DNS server is included in the RA message. - This solution is easily scalable for a very large number of UEs. The - operator can configure the RDNSS addresses in the GGSN as a part of - normal GGSN configuration. The IPv6 RDNSS address is received in the - Router Advertisement, and an extra Round Trip Time (RTT) for asking - RDNSS addresses can be avoided. - - When one considers the cons, this mechanism still requires - standardization effort in the IETF, and the end nodes and routers - need to support this mechanism. The equipment software update - should, however, be pretty straightforward, and new IPv6 equipment - could support RA extension already from the beginning. - -5.3.3. Stateless DHCPv6 - - A DHCPv6-based solution needs the implementation of Stateless DHCP - [4] and DHCPv6 DNS options [5] in the UE, and a DHCPv6 server in the - operator's network. A possible configuration is such that the GGSN - works as a DHCP relay. - - - -Jeong Informational [Page 16] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - The pros of a stateless DHCPv6-based solution are: - - 1. Stateless DHCPv6 is a standardized mechanism. - - 2. DHCPv6 can be used for receiving configuration information other - than RDNSS addresses; e.g., SIP server addresses. - - 3. DHCPv6 works in different network environments. - - 4. When DHCPv6 service is deployed through a single, centralized - server, the RDNSS configuration information can be updated by the - network administrator at a single source. - - Some issues with DHCPv6 in 3GPP networks are listed below: - - 1. DHCPv6 requires an additional server in the network unless the - (Stateless) DHCPv6 functionality is integrated into an existing - router. This means that there might be one additional server to - be maintained. - - 2. DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing - (3GPP Stateless Address Autoconfiguration is typically used) and - is not automatically implemented in 3GPP IPv6 UEs. - - 3. Scalability and reliability of DHCPv6 in very large 3GPP networks - (with tens or hundreds of millions of UEs) may be an issue; at - least the redundancy needs to be taken care of. However, if the - DHCPv6 service is integrated into the network elements, such as a - router operating system, scalability and reliability is - comparable with other DNS configuration approaches. - - 4. It is sub-optimal to utilize the radio resources in 3GPP networks - for DHCPv6 messages if there is a simpler alternative is - available. - - * The use of stateless DHCPv6 adds one round-trip delay to the - case in which the UE can start transmitting data right after - the Router Advertisement. - - 5. If the DNS information (suddenly) changes, Stateless DHCPv6 - cannot automatically update the UE; see [21]. - -5.3.4. Well-known Addresses - - Using well-known addresses is also a feasible and light mechanism for - 3GPP UEs. Those well-known addresses can be preconfigured in the UE - software and the operator can make the corresponding configuration on - the network side. Thus, this is a very easy mechanism for the UE, - - - -Jeong Informational [Page 17] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - but it requires some configuration work in the network. When using - well-known addresses, UE forwards queries to any of the preconfigured - addresses. In the current proposal [7], IPv6 anycast addresses are - suggested. - - Note: An IPv6 DNS configuration proposal, based on the use of well- - known site-local addresses, was developed by the IPv6 Working Group; - it was seen as a feasible mechanism for 3GPP UEs, although no IETF - consensus was reached on this proposal. In the end, the deprecation - of IPv6 site-local addresses made it impossible to standardize a - mechanism that uses site-local addresses as well-known addresses. - However, as of this writing, this mechanism is implemented in some - operating systems and 3GPP UEs as a last resort of IPv6 DNS - configuration. - -5.3.5. Recommendations - - It is suggested that a lightweight, stateless DNS configuration - mechanism be specified as soon as possible. From a 3GPP UE and - network point of view, the Router Advertisement-based mechanism looks - most promising. The sooner a light, stateless mechanism is - specified, the sooner we can stop using well-known site-local - addresses for IPv6 DNS configuration. - -5.4. Unmanaged Network - - There are four deployment scenarios of interest in unmanaged networks - [22]: - - 1. A gateway that does not provide IPv6 at all, - - 2. A dual-stack gateway connected to a dual-stack ISP, - - 3. A dual-stack gateway connected to an IPv4-only ISP, and - - 4. A gateway connected to an IPv6-only ISP. - -5.4.1. Case A: Gateway Does Not Provide IPv6 at All - - In this case, the gateway does not provide IPv6; the ISP may or may - not provide IPv6. Automatic or Configured tunnels are the - recommended transition mechanisms for this scenario. - - The case where dual-stack hosts behind an NAT need access to an IPv6 - RDNSS cannot be entirely ruled out. The DNS configuration mechanism - has to work over the tunnel, and the underlying tunneling mechanism - could implement NAT traversal. The tunnel server assumes the role of - a relay (for both DHCP and well-known anycast addresses approaches). - - - -Jeong Informational [Page 18] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - The RA-based mechanism is relatively straightforward in its - operation, assuming the tunnel server is also the IPv6 router - emitting RAs. The well-known anycast addresses approach also seems - simple in operation across the tunnel, but the deployment model using - well-known anycast addresses in a tunneled environment is unclear or - not well understood. - -5.4.2. Case B: A Dual-stack Gateway Connected to a Dual-stack ISP - - This is similar to a typical IPv4 home user scenario, where DNS - configuration parameters are obtained using DHCP. The exception is - that Stateless DHCPv6 is used, as opposed to the IPv4 scenario, where - the DHCP server is stateful (it maintains the state for clients). - -5.4.3. Case C: A Dual-stack Gateway Connected to an IPv4-only ISP - - This is similar to Case B. If a gateway provides IPv6 connectivity - by managing tunnels, then it is also supposed to provide access to an - RDNSS. Like this, the tunnel for IPv6 connectivity originates from - the dual-stack gateway instead of from the host. - -5.4.4. Case D: A Gateway Connected to an IPv6-only ISP - - This is similar to Case B. - -6. Security Considerations - - As security requirements depend solely on applications and differ - from application to application, there can be no generic requirement - defined at the IP or application layer for DNS. - - However, note that cryptographic security requires configured secret - information and that full autoconfiguration and cryptographic - security are mutually exclusive. People insisting on secure, full - autoconfiguration will get false security, false autoconfiguration, - or both. - - In some deployment scenarios [17], where cryptographic security is - required for applications, the secret information for the - cryptographic security is preconfigured, through which application- - specific configuration data, including those for DNS, can be securely - configured. Note that if applications requiring cryptographic - security depend on DNS, the applications also require cryptographic - security to DNS. Therefore, the full autoconfiguration of DNS is not - acceptable. - - However, with full autoconfiguration, weaker but still reasonable - security is being widely accepted and will continue to be acceptable. - - - -Jeong Informational [Page 19] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - That is, with full autoconfiguration, which means there is no - cryptographic security for the autoconfiguration, it is already - assumed that the local environment is secure enough that the - information from the local autoconfiguration server has acceptable - security even without cryptographic security. Thus, the - communication between the local DNS client and local DNS server has - acceptable security. - - In autoconfiguring recursive servers, DNSSEC may be overkill, because - DNSSEC [23]-[25] needs the configuration and reconfiguration of - clients at root key roll-over [26][27]. Even if additional keys for - secure key roll-over are added at the initial configuration, they are - as vulnerable as the original keys to some forms of attack, such as - social hacking. Another problem of using DNSSEC and - autoconfiguration together is that DNSSEC requires secure time, which - means secure communication with autoconfigured time servers, which - requires configured secret information. Therefore, in order that the - autoconfiguration may be secure, configured secret information is - required. - - If DNSSEC [23]-[25] is used and the signatures are verified on the - client host, the misconfiguration of a DNS server may simply be - denial of service. Also, if local routing environment is not - reliable, clients may be directed to a false resolver with the same - IP address as the true one. - -6.1. RA Option - - The security of RA option for RDNSS is the same as the ND protocol - security [1][6]. The RA option does not add any new vulnerability. - - Note that the vulnerability of ND is not worse and is a subset of the - attacks that any node attached to a LAN can do independently of ND. - A malicious node on a LAN can promiscuously receive packets for any - router's MAC address and send packets with the router's MAC address - as the source MAC address in the L2 header. As a result, the L2 - switches send packets addressed to the router to the malicious node. - Also, this attack can send redirects that tell the hosts to send - their traffic somewhere else. The malicious node can send - unsolicited RA or NA replies, answer RS or NS requests, etc. All of - this can be done independently of implementing ND. Therefore, the RA - option for RDNSS does not add to the vulnerability. - - Security issues regarding the ND protocol were discussed by the IETF - SEND (Securing Neighbor Discovery) Working Group, and RFC 3971 for - the ND security has been published [12]. - - - - - -Jeong Informational [Page 20] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - -6.2. DHCPv6 Option - - The DNS Recursive Name Server option may be used by an intruder DHCP - server to cause DHCP clients to send DNS queries to an intruder DNS - recursive name server [5]. The results of these misdirected DNS - queries may be used to spoof DNS names. - - To avoid attacks through the DNS Recursive Name Server option, the - DHCP client SHOULD require DHCP authentication (see "Authentication - of DHCP messages" in RFC 3315 [3][13]) before installing a list of - DNS recursive name servers obtained through authenticated DHCP. - -6.3. Well-known Anycast Addresses - - The well-known anycast addresses approach is not a protocol, thus - there is no need to secure the protocol itself. - - However, denial of service attacks on the DNS resolver system might - be easier to achieve as the anycast addresses used are by definition - well known. - -7. Contributors - - Ralph Droms - Cisco Systems, Inc. - 1414 Massachusetts Ave. - Boxboro, MA 01719 - US - - Phone: +1 978 936 1674 - EMail: rdroms@cisco.com - - - Robert M. Hinden - Nokia - 313 Fairchild Drive - Mountain View, CA 94043 - US - - Phone: +1 650 625 2004 - EMail: bob.hinden@nokia.com - - - - - - - - - - -Jeong Informational [Page 21] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - Ted Lemon - Nominum, Inc. - 950 Charter Street - Redwood City, CA 94043 - US - - EMail: Ted.Lemon@nominum.com - - Masataka Ohta - Tokyo Institute of Technology - 2-12-1, O-okayama, Meguro-ku - Tokyo 152-8552 - Japan - - Phone: +81 3 5734 3299 - Fax: +81 3 5734 3299 - EMail: mohta@necom830.hpcl.titech.ac.jp - - - Soohong Daniel Park - Mobile Platform Laboratory, SAMSUNG Electronics - 416 Maetan-3dong, Yeongtong-Gu - Suwon, Gyeonggi-Do 443-742 - Korea - - Phone: +82 31 200 4508 - EMail: soohong.park@samsung.com - - - Suresh Satapati - Cisco Systems, Inc. - San Jose, CA 95134 - US - - EMail: satapati@cisco.com - - - Juha Wiljakka - Nokia - Visiokatu 3 - FIN-33720, TAMPERE - Finland - - Phone: +358 7180 48372 - EMail: juha.wiljakka@nokia.com - - - - - - -Jeong Informational [Page 22] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - -8. Acknowledgements - - This document has greatly benefited from inputs by David Meyer, Rob - Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, - Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. - Also, Tony Bonanno proofread this document. The authors appreciate - their contribution. - -9. References - -9.1. Normative References - - [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery - for IP Version 6 (IPv6)", RFC 2461, December 1998. - - [2] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. - - [3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. - Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", - RFC 3315, July 2003. - - [4] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) - Service for IPv6", RFC 3736, April 2004. - - [5] Droms, R., "DNS Configuration options for Dynamic Host - Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December - 2003. - -9.2. Informative References - - [6] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 - Router Advertisement Option for DNS Configuration", Work in - Progress, September 2005. - - [7] Ohta, M., "Preconfigured DNS Server Addresses", Work in - Progress, February 2004. - - [8] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time - Option for Dynamic Host Configuration Protocol for IPv6 - (DHCPv6)", RFC 4242, November 2005. - - [9] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting - Service", RFC 1546, November 1993. - - [10] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) - Addressing Architecture", RFC 3513, April 2003. - - - - -Jeong Informational [Page 23] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - [11] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, - "Scenarios and Analysis for Introducing IPv6 into ISP Networks", - RFC 4029, March 2005. - - [12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure - Neighbor Discovery (SEND)", RFC 3971, March 2005. - - [13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", - RFC 3118, June 2001. - - [14] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June - 2005. - - [15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host - Configuration Protocol (DHCP) version 6", RFC 3633, December - 2003. - - [16] Wasserman, M., "Recommendations for IPv6 in Third Generation - Partnership Project (3GPP) Standards", RFC 3314, September 2002. - - [17] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC - 3574, August 2003. - - [18] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation - Partnership Project (3GPP) Networks", RFC 4215, October 2005. - - [19] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); - Service description; Stage 2 (Release 5)", December 2002. - - [20] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 - specification; Core network protocols; Stage 3 (Release 5)", - June 2003. - - [21] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering - Requirements for Stateless Dynamic Host Configuration Protocol - for IPv6 (DHCPv6)", RFC 4076, May 2005. - - [22] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, - "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April - 2004. - - [23] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, March - 2005. - - [24] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - - -Jeong Informational [Page 24] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - - [25] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Protocol Modifications for the DNS Security Extensions", RFC - 4035, March 2005. - - [26] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", Work - in Progress, October 2005. - - [27] Guette, G. and O. Courtay, "Requirements for Automated Key - Rollover in DNSSEC", Work in Progress, January 2005. - - [28] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M - and O Flags of IPv6 Router Advertisement", Work in Progress, - March 2005. - -Author's Address - - Jaehoon Paul Jeong (editor) - ETRI/Department of Computer Science and Engineering - University of Minnesota - 117 Pleasant Street SE - Minneapolis, MN 55455 - US - - Phone: +1 651 587 7774 - Fax: +1 612 625 2002 - EMail: jjeong@cs.umn.edu - URI: http://www.cs.umn.edu/~jjeong/ - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Informational [Page 25] - -RFC 4339 IPv6 Host Configuration of DNS Server February 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Jeong Informational [Page 26] - diff --git a/doc/rfc/rfc4471.txt b/doc/rfc/rfc4471.txt deleted file mode 100644 index eb338e6b5ed..00000000000 --- a/doc/rfc/rfc4471.txt +++ /dev/null @@ -1,1291 +0,0 @@ - - - - - - -Network Working Group G. Sisson -Request for Comments: 4471 B. Laurie -Category: Experimental Nominet - September 2006 - - - Derivation of DNS Name Predecessor and Successor - - -Status of This Memo - - This memo defines an Experimental Protocol for the Internet - community. It does not specify an Internet standard of any kind. - Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes two methods for deriving the canonically- - ordered predecessor and successor of a DNS name. These methods may - be used for dynamic NSEC resource record synthesis, enabling - security-aware name servers to provide authenticated denial of - existence without disclosing other owner names in a DNSSEC secured - zone. - -Table of Contents - - 1. Introduction ....................................................2 - 2. Notational Conventions ..........................................3 - 3. Derivations .....................................................3 - 3.1. Absolute Method ............................................3 - 3.1.1. Derivation of DNS Name Predecessor ..................3 - 3.1.2. Derivation of DNS Name Successor ....................4 - 3.2. Modified Method ............................................4 - 3.2.1. Derivation of DNS Name Predecessor ..................5 - 3.2.2. Derivation of DNS Name Successor ....................6 - 4. Notes ...........................................................6 - 4.1. Test for Existence .........................................6 - 4.2. Case Considerations ........................................7 - 4.3. Choice of Range ............................................7 - 4.4. Wild Card Considerations ...................................8 - 4.5. Possible Modifications .....................................8 - 4.5.1. Restriction of Effective Maximum DNS Name Length ....8 - 4.5.2. Use of Modified Method with Zones Containing - - - -Sisson & Laurie Experimental [Page 1] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - - SRV RRs .............................................8 - 5. Examples ........................................................9 - 5.1. Examples of Immediate Predecessors Using Absolute Method ..10 - 5.2. Examples of Immediate Successors Using Absolute Method ....14 - 5.3. Examples of Predecessors Using Modified Method ............19 - 5.4. Examples of Successors Using Modified Method ..............20 - 6. Security Considerations ........................................21 - 7. Acknowledgements ...............................................21 - 8. References .....................................................21 - 8.1. Normative References ......................................21 - 8.2. Informative References ....................................22 - -1. Introduction - - One of the proposals for avoiding the exposure of zone information - during the deployment DNSSEC is dynamic NSEC resource record (RR) - synthesis. This technique is described in [DNSSEC-TRANS] and - [RFC4470], and involves the generation of NSEC RRs that just span the - query name for non-existent owner names. In order to do this, the - DNS names that would occur just prior to and just following a given - query name must be calculated in real time, as maintaining a list of - all possible owner names that might occur in a zone would be - impracticable. - - Section 6.1 of [RFC4034] defines canonical DNS name order. This - document does not amend or modify this definition. However, the - derivation of immediate predecessor and successor, although trivial, - is non-obvious. Accordingly, several methods are described here as - an aid to implementors and a reference to other interested parties. - - This document describes two methods: - - 1. An "absolute method", which returns the immediate predecessor or - successor of a domain name such that no valid DNS name could - exist between that DNS name and the predecessor or successor. - - 2. A "modified method", which returns a predecessor and successor - that are more economical in size and computation. This method is - restricted to use with zones consisting exclusively of owner - names that contain no more than one label more than the owner - name of the apex, where the longest possible owner name (i.e., - one with a maximum length left-most label) would not exceed the - maximum DNS name length. This is, however, the type of zone for - which the technique of online signing is most likely to be used. - - - - - - - -Sisson & Laurie Experimental [Page 2] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - -2. Notational Conventions - - The following notational conventions are used in this document for - economy of expression: - - N: An unspecified DNS name. - - P(N): Immediate predecessor to N (absolute method). - - S(N): Immediate successor to N (absolute method). - - P'(N): Predecessor to N (modified method). - - S'(N): Successor to N (modified method). - -3. Derivations - - These derivations assume that all uppercase US-ASCII letters in N - have already been replaced by their corresponding lowercase - equivalents. Unless otherwise specified, processing stops after the - first step in which a condition is met. - - The derivations make reference to maximum label length and maximum - DNS name length; these are defined in Section 3.1 of [RFC1034] to be - 63 and 255 octets, respectively. - -3.1. Absolute Method - -3.1.1. Derivation of DNS Name Predecessor - - To derive P(N): - - 1. If N is the same as the owner name of the zone apex, prepend N - repeatedly with labels of the maximum length possible consisting - of octets of the maximum sort value (e.g., 0xff) until N is the - maximum length possible; otherwise proceed to the next step. - - 2. If the least significant (left-most) label of N consists of a - single octet of the minimum sort value (e.g., 0x00), remove that - label; otherwise proceed to the next step. - - 3. If the least significant (right-most) octet in the least - significant (left-most) label of N is the minimum sort value, - remove the least significant octet and proceed to step 5. - - 4. Decrement the value of the least significant (right-most) octet - of the least significant (left-most) label, skipping any values - that correspond to uppercase US-ASCII letters, and then append - - - -Sisson & Laurie Experimental [Page 3] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - - the least significant (left-most) label with as many octets as - possible of the maximum sort value. Proceed to the next step. - - 5. Prepend N repeatedly with labels of as long a length as possible - consisting of octets of the maximum sort value until N is the - maximum length possible. - -3.1.2. Derivation of DNS Name Successor - - To derive S(N): - - 1. If N is two or more octets shorter than the maximum DNS name - length, prepend N with a label containing a single octet of the - minimum sort value (e.g., 0x00); otherwise proceed to the next - step. - - 2. If N is one octet shorter than the maximum DNS name length and - the least significant (left-most) label is one or more octets - shorter than the maximum label length, append an octet of the - minimum sort value to the least significant label; otherwise - proceed to the next step. - - 3. Increment the value of the least significant (right-most) octet - in the least significant (left-most) label that is less than the - maximum sort value (e.g., 0xff), skipping any values that - correspond to uppercase US-ASCII letters, and then remove any - octets to the right of that one. If all octets in the label are - the maximum sort value, then proceed to the next step. - - 4. Remove the least significant (left-most) label. Unless N is now - the same as the owner name of the zone apex (this will occur only - if N was the maximum possible name in canonical DNS name order, - and thus has wrapped to the owner name of zone apex), repeat - starting at step 2. - -3.2. Modified Method - - This method is for use with zones consisting only of single-label - owner names where an owner name consisting of label of maximum length - would not result in a DNS name that exceeded the maximum DNS name - length. This method is computationally simpler and returns values - that are more economical in size than the absolute method. It - differs from the absolute method detailed above in the following - ways: - - 1. Step 1 of the derivation P(N) has been omitted as the existence - of the owner name of the zone apex never requires denial. - - - - -Sisson & Laurie Experimental [Page 4] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - - 2. A new step 1 has been introduced that removes unnecessary labels. - - 3. Step 4 of the derivation P(N) has been omitted as it is only - necessary for zones containing owner names consisting of more - than one label. This omission generally results in a significant - reduction of the length of derived predecessors. - - 4. Step 1 of the derivation S(N) had been omitted as it is only - necessary for zones containing owner names consisting of more - than one label. This omission results in a tiny reduction of the - length of derived successors, and maintains consistency with the - modification of step 4 of the derivation P(N) described above. - - 5. Steps 2 and 4 of the derivation S(N) have been modified to - eliminate checks for maximum DNS name length, as it is an - assumption of this method that no DNS name in the zone can exceed - the maximum DNS name length. - -3.2.1. Derivation of DNS Name Predecessor - - To derive P'(N): - - 1. If N is two or more labels longer than the owner name of the - apex, repeatedly remove the least significant (left-most) label - until N is only one label longer than the owner name of the apex; - otherwise proceed to the next step. - - 2. If the least significant (left-most) label of N consists of a - single octet of the minimum sort value (e.g., 0x00), remove that - label; otherwise proceed to the next step. (If this condition is - met, P'(N) is the owner name of the apex.) - - 3. If the least significant (right-most) octet in the least - significant (left-most) label of N is the minimum sort value, - remove the least significant octet. - - 4. Decrement the value of the least significant (right-most) octet, - skipping any values that correspond to uppercase US-ASCII - letters, and then append the label with as many octets as - possible of the maximum sort value. - - - - - - - - - - - -Sisson & Laurie Experimental [Page 5] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - -3.2.2. Derivation of DNS Name Successor - - To derive S'(N): - - 1. If N is two or more labels longer than the owner name of the - apex, repeatedly remove the least significant (left-most) label - until N is only one label longer than the owner name of the apex. - Proceed to the next step. - - 2. If the least significant (left-most) label of N is one or more - octets shorter than the maximum label length, append an octet of - the minimum sort value to the least significant label; otherwise - proceed to the next step. - - 3. Increment the value of the least significant (right-most) octet - in the least significant (left-most) label that is less than the - maximum sort value (e.g., 0xff), skipping any values that - correspond to uppercase US-ASCII letters, and then remove any - octets to the right of that one. If all octets in the label are - the maximum sort value, then proceed to the next step. - - 4. Remove the least significant (left-most) label. (This will occur - only if the least significant label is the maximum label length - and consists entirely of octets of the maximum sort value, and - thus has wrapped to the owner name of the zone apex.) - -4. Notes - -4.1. Test for Existence - - Before using the result of P(N) or P'(N) as the owner name of an NSEC - RR in a DNS response, a name server should test to see whether the - name exists. If it does, either a standard non-synthesised NSEC RR - should be used, or the synthesised NSEC RR should reflect the RRset - types that exist at the NSEC RR's owner name in the Type Bit Map - field as specified by Section 4.1.2 of [RFC4034]. Implementors will - likely find it simpler to use a non-synthesised NSEC RR. For further - details, see Section 2 of [RFC4470]. - - - - - - - - - - - - - -Sisson & Laurie Experimental [Page 6] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - -4.2. Case Considerations - - Section 3.5 of [RFC1034] specifies that "while upper and lower case - letters are allowed in names, no significance is attached to the - case". Additionally, Section 6.1 of [RFC4034] states that when - determining canonical DNS name order, "uppercase US-ASCII letters are - treated as if they were lowercase US-ASCII letters". Consequently, - values corresponding to US-ASCII uppercase letters must be skipped - when decrementing and incrementing octets in the derivations - described in Section 3. - - The following pseudo-code is illustrative: - - Decrement the value of an octet: - - if (octet == '[') // '[' is just after uppercase 'Z' - octet = '@'; // '@' is just prior to uppercase 'A' - else - octet--; - - Increment the value of an octet: - - if (octet == '@') // '@' is just prior to uppercase 'A' - octet = '['; // '[' is just after uppercase 'Z' - else - octet++; - -4.3. Choice of Range - - [RFC2181] makes the clarification that "any binary string whatever - can be used as the label of any resource record". Consequently, the - minimum sort value may be set as 0x00 and the maximum sort value as - 0xff, and the range of possible values will be any DNS name that - contains octets of any value other than those corresponding to - uppercase US-ASCII letters. - - However, if all owner names in a zone are in the letter-digit-hyphen, - or LDH, format specified in [RFC1034], it may be desirable to - restrict the range of possible values to DNS names containing only - LDH values. This has the effect of - - 1. making the output of tools such as `dig' and `nslookup' less - subject to confusion, - - 2. minimising the impact that NSEC RRs containing DNS names with - non-LDH values (or non-printable values) might have on faulty DNS - resolver implementations, and - - - - -Sisson & Laurie Experimental [Page 7] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - - 3. preventing the possibility of results that are wildcard DNS names - (see Section 4.4). - - This may be accomplished by using a minimum sort value of 0x1f (US- - ASCII character `-') and a maximum sort value of 0x7a (US-ASCII - character lowercase `z'), and then skipping non-LDH, non-lowercase - values when incrementing or decrementing octets. - -4.4. Wild Card Considerations - - Neither derivation avoids the possibility that the result may be a - DNS name containing a wildcard label, i.e., a label containing a - single octet with the value 0x2a (US-ASCII character `*'). With - additional tests, wildcard DNS names may be explicitly avoided; - alternatively, if the range of octet values can be restricted to - those corresponding to letter-digit-hyphen, or LDH, characters (see - Section 4.3), such DNS names will not occur. - - Note that it is improbable that a result that is a wildcard DNS name - will occur unintentionally; even if one does occur either as the - owner name of, or in the RDATA of an NSEC RR, it is treated as a - literal DNS name with no special meaning. - -4.5. Possible Modifications - -4.5.1. Restriction of Effective Maximum DNS Name Length - - [RFC1034] specifies that "the total number of octets that represent a - name (i.e., the sum of all label octets and label lengths) is limited - to 255", including the null (zero-length) label that represents the - root. For the purpose of deriving predecessors and successors during - NSEC RR synthesis, the maximum DNS name length may be effectively - restricted to the length of the longest DNS name in the zone. This - will minimise the size of responses containing synthesised NSEC RRs - but, especially in the case of the modified method, may result in - some additional computational complexity. - - Note that this modification will have the effect of revealing - information about the longest name in the zone. Moreover, when the - contents of the zone changes, e.g., during dynamic updates and zone - transfers, care must be taken to ensure that the effective maximum - DNS name length agrees with the new contents. - -4.5.2. Use of Modified Method with Zones Containing SRV RRs - - Normally, the modified method cannot be used in zones that contain - Service Record (SRV) RRs [RFC2782], as SRV RRs have owner names that - contain multiple labels. However, the use of SRV RRs can be - - - -Sisson & Laurie Experimental [Page 8] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - - accommodated by various techniques. There are at least four possible - ways to do this: - - 1. Use conventional NSEC RRs for the region of the zone that - contains first-level labels beginning with the underscore (`_') - character. For the purposes of generating these NSEC RRs, the - existence of (possibly fictional) ownernames `9{63}' and `a' - could be assumed, providing a lower and upper bound for this - region. Then all queries where the QNAME does not exist but - contains a first-level label beginning with an underscore could - be handled using the normal DNSSEC protocol. - - This approach would make it possible to enumerate all DNS names - in the zone containing a first-level label beginning with - underscore, including all SRV RRs, but this may be of less a - concern to the zone administrator than incurring the overhead of - the absolute method or of the following variants of the modified - method. - - 2. The absolute method could be used for synthesising NSEC RRs for - all queries where the QNAME contains a leading underscore. - However, this re-introduces the susceptibility of the absolute - method to denial of service activity, as an attacker could send - queries for an effectively inexhaustible supply of domain names - beginning with a leading underscore. - - 3. A variant of the modified method could be used for synthesising - NSEC RRs for all queries where the QNAME contains a leading - underscore. This variant would assume that all predecessors and - successors to queries where the QNAME contains a leading - underscore may consist of two labels rather than only one. This - introduces a little additional complexity without incurring the - full increase in response size and computational complexity as - the absolute method. - - 4. Finally, a variant of the modified method that assumes that all - owner names in the zone consist of one or two labels could be - used. However, this negates much of the reduction in response - size of the modified method and may be nearly as computationally - complex as the absolute method. - -5. Examples - - In the following examples, - - the owner name of the zone apex is "example.com.", - - - - - -Sisson & Laurie Experimental [Page 9] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - - the range of octet values is 0x00 - 0xff excluding values - corresponding to uppercase US-ASCII letters, and - - non-printable octet values are expressed as three-digit decimal - numbers preceded by a backslash (as specified in Section 5.1 of - [RFC1035]). - -5.1. Examples of Immediate Predecessors Using Absolute Method - - Example of a typical case: - - P(foo.example.com.) = - - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255.\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255.fon\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255.example.com. - - or, in alternate notation: - - \255{49}.\255{63}.\255{63}.fon\255{60}.example.com. - - where {n} represents the number of repetitions of an octet. - - Example where least significant (left-most) label of DNS name - consists of a single octet of the minimum sort value: - - P(\000.foo.example.com.) = foo.example.com. - - - - - - - -Sisson & Laurie Experimental [Page 10] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - - Example where least significant (right-most) octet of least - significant (left-most) label has the minimum sort value: - - P(foo\000.example.com.) = - - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255.\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255.\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255.foo.example.com. - - or, in alternate notation: - - \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com. - - - - - - - - - - - - - - - - - - - - - - -Sisson & Laurie Experimental [Page 11] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - - Example where DNS name contains an octet that must be decremented by - skipping values corresponding to US-ASCII uppercase letters: - - P(fo\[.example.com.) = - - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255.\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255.fo\@\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255.example.com. - - or, in alternate notation: - - \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com. - - where {n} represents the number of repetitions of an octet. - - - - - - - - - - - - - - - - - - - - -Sisson & Laurie Experimental [Page 12] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - - Example where DNS name is the owner name of the zone apex, and - consequently wraps to the DNS name with the maximum possible sort - order in the zone: - - P(example.com.) = - - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255.\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255.\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.example.com. - - or, in alternate notation: - - \255{49}.\255{63}.\255{63}.\255{63}.example.com. - - - - - - - - - - - - - - - - - - - - -Sisson & Laurie Experimental [Page 13] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - -5.2. Examples of Immediate Successors Using Absolute Method - - Example of typical case: - - S(foo.example.com.) = \000.foo.example.com. - - Example where DNS name is one octet short of the maximum DNS name - length: - - N = fooooooooooooooooooooooooooooooooooooooooooooooo - .ooooooooooooooooooooooooooooooooooooooooooooooo - oooooooooooooooo.ooooooooooooooooooooooooooooooo - oooooooooooooooooooooooooooooooo.ooooooooooooooo - oooooooooooooooooooooooooooooooooooooooooooooooo.example.com. - - or, in alternate notation: - - fo{47}.o{63}.o{63}.o{63}.example.com. - - S(N) = - - fooooooooooooooooooooooooooooooooooooooooooooooo - \000.ooooooooooooooooooooooooooooooooooooooooooo - oooooooooooooooooooo.ooooooooooooooooooooooooooo - oooooooooooooooooooooooooooooooooooo.ooooooooooo - oooooooooooooooooooooooooooooooooooooooooooooooo - oooo.example.com. - - or, in alternate notation: - - fo{47}\000.o{63}.o{63}.o{63}.example.com. - - - - - - - - - - - - - - - - - - - - -Sisson & Laurie Experimental [Page 14] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - - Example where DNS name is the maximum DNS name length: - - N = fooooooooooooooooooooooooooooooooooooooooooooooo - o.oooooooooooooooooooooooooooooooooooooooooooooo - ooooooooooooooooo.oooooooooooooooooooooooooooooo - ooooooooooooooooooooooooooooooooo.oooooooooooooo - oooooooooooooooooooooooooooooooooooooooooooooooo - o.example.com. - - or, in alternate notation: - - fo{48}.o{63}.o{63}.o{63}.example.com. - - S(N) = - - fooooooooooooooooooooooooooooooooooooooooooooooo - p.oooooooooooooooooooooooooooooooooooooooooooooo - ooooooooooooooooo.oooooooooooooooooooooooooooooo - ooooooooooooooooooooooooooooooooo.oooooooooooooo - oooooooooooooooooooooooooooooooooooooooooooooooo - o.example.com. - - or, in alternate notation: - - fo{47}p.o{63}.o{63}.o{63}.example.com. - - - - - - - - - - - - - - - - - - - - - - - - - - -Sisson & Laurie Experimental [Page 15] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - - Example where DNS name is the maximum DNS name length and the least - significant (left-most) label has the maximum sort value: - - N = \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.ooooooooooooooooooooooooooooooooooooooooooo - oooooooooooooooooooo.ooooooooooooooooooooooooooo - oooooooooooooooooooooooooooooooooooo.ooooooooooo - oooooooooooooooooooooooooooooooooooooooooooooooo - oooo.example.com. - - or, in alternate notation: - - \255{49}.o{63}.o{63}.o{63}.example.com. - - S(N) = - - oooooooooooooooooooooooooooooooooooooooooooooooo - oooooooooooooop.oooooooooooooooooooooooooooooooo - ooooooooooooooooooooooooooooooo.oooooooooooooooo - ooooooooooooooooooooooooooooooooooooooooooooooo. - example.com. - - or, in alternate notation: - - o{62}p.o{63}.o{63}.example.com. - - - - - - - - - - - - - - - - - - - - - - - -Sisson & Laurie Experimental [Page 16] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - - Example where DNS name is the maximum DNS name length and the eight - least significant (right-most) octets of the least significant - (left-most) label have the maximum sort value: - - N = foooooooooooooooooooooooooooooooooooooooo\255 - \255\255\255\255\255\255\255.ooooooooooooooooooo - oooooooooooooooooooooooooooooooooooooooooooo.ooo - oooooooooooooooooooooooooooooooooooooooooooooooo - oooooooooooo.ooooooooooooooooooooooooooooooooooo - oooooooooooooooooooooooooooo.example.com. - - or, in alternate notation: - - fo{40}\255{8}.o{63}.o{63}.o{63}.example.com. - - S(N) = - - fooooooooooooooooooooooooooooooooooooooop.oooooo - oooooooooooooooooooooooooooooooooooooooooooooooo - ooooooooo.oooooooooooooooooooooooooooooooooooooo - ooooooooooooooooooooooooo.oooooooooooooooooooooo - ooooooooooooooooooooooooooooooooooooooooo.example.com. - - or, in alternate notation: - - fo{39}p.o{63}.o{63}.o{63}.example.com. - - - - - - - - - - - - - - - - - - - - - - - - - -Sisson & Laurie Experimental [Page 17] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - - Example where DNS name is the maximum DNS name length and contains an - octet that must be incremented by skipping values corresponding to - US-ASCII uppercase letters: - - N = fooooooooooooooooooooooooooooooooooooooooooooooo - \@.ooooooooooooooooooooooooooooooooooooooooooooo - oooooooooooooooooo.ooooooooooooooooooooooooooooo - oooooooooooooooooooooooooooooooooo.ooooooooooooo - oooooooooooooooooooooooooooooooooooooooooooooooo - oo.example.com. - - or, in alternate notation: - - fo{47}\@.o{63}.o{63}.o{63}.example.com. - - S(N) = - - fooooooooooooooooooooooooooooooooooooooooooooooo - \[.ooooooooooooooooooooooooooooooooooooooooooooo - oooooooooooooooooo.ooooooooooooooooooooooooooooo - oooooooooooooooooooooooooooooooooo.ooooooooooooo - oooooooooooooooooooooooooooooooooooooooooooooooo - oo.example.com. - - or, in alternate notation: - - fo{47}\[.o{63}.o{63}.o{63}.example.com. - - - - - - - - - - - - - - - - - - - - - - - - -Sisson & Laurie Experimental [Page 18] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - - Example where DNS name has the maximum possible sort order in the - zone, and consequently wraps to the owner name of the zone apex: - - N = \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255.\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255.\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.example.com. - - or, in alternate notation: - - \255{49}.\255{63}.\255{63}.\255{63}.example.com. - - S(N) = example.com. - -5.3. Examples of Predecessors Using Modified Method - - Example of a typical case: - - P'(foo.example.com.) = - - fon\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.example.com. - - or, in alternate notation: - - fon\255{60}.example.com. - - - - -Sisson & Laurie Experimental [Page 19] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - - Example where DNS name contains more labels than DNS names in the - zone: - - P'(bar.foo.example.com.) = foo.example.com. - - Example where least significant (right-most) octet of least - significant (left-most) label has the minimum sort value: - - P'(foo\000.example.com.) = foo.example.com. - - Example where least significant (left-most) label has the minimum - sort value: - - P'(\000.example.com.) = example.com. - - Example where DNS name is the owner name of the zone apex, and - consequently wraps to the DNS name with the maximum possible sort - order in the zone: - - P'(example.com.) = - - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255.example.com. - - or, in alternate notation: - - \255{63}.example.com. - -5.4. Examples of Successors Using Modified Method - - Example of a typical case: - - S'(foo.example.com.) = foo\000.example.com. - - Example where DNS name contains more labels than DNS names in the - zone: - - S'(bar.foo.example.com.) = foo\000.example.com. - - - Example where least significant (left-most) label has the maximum - sort value, and consequently wraps to the owner name of the zone - apex: - - - - -Sisson & Laurie Experimental [Page 20] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - - N = \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255.example.com. - - or, in alternate notation: - - \255{63}.example.com. - - S'(N) = example.com. - -6. Security Considerations - - The derivation of some predecessors/successors requires the testing - of more conditions than others. Consequently, the effectiveness of a - denial-of-service attack may be enhanced by sending queries that - require more conditions to be tested. The modified method involves - the testing of fewer conditions than the absolute method and - consequently is somewhat less susceptible to this exposure. - -7. Acknowledgements - - The authors would like to thank Sam Weiler, Olaf Kolkman, Olafur - Gudmundsson, and Niall O'Reilly for their review and input. - -8. References - -8.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. - - [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. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and - S. Rose, "Resource Records for the DNS Security - Extensions", RFC 4034, March 2005. - - - - -Sisson & Laurie Experimental [Page 21] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - -8.2. Informative References - - [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC - Records and DNSSEC On-line Signing", RFC 4470, April - 2006. - - [DNSSEC-TRANS] Arends, R., Koch, P., and J. Schlyter, "Evaluating - DNSSEC Transition Mechanisms", Work in Progress, - February 2005. - -Authors' Addresses - - Geoffrey Sisson - Nominet - Sandford Gate - Sandy Lane West - Oxford - OX4 6LB - GB - - Phone: +44 1865 332211 - EMail: geoff@nominet.org.uk - - - Ben Laurie - Nominet - 17 Perryn Road - London - W3 7LR - GB - - Phone: +44 20 8735 0686 - EMail: ben@algroup.co.uk - - - - - - - - - - - - - - - - - - -Sisson & Laurie Experimental [Page 22] - -RFC 4471 DNS Name Predecessor and Successor September 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Sisson & Laurie Experimental [Page 23] - diff --git a/doc/rfc/rfc4472.txt b/doc/rfc/rfc4472.txt deleted file mode 100644 index b396e9a11a5..00000000000 --- a/doc/rfc/rfc4472.txt +++ /dev/null @@ -1,1627 +0,0 @@ - - - - - - -Network Working Group A. Durand -Request for Comments: 4472 Comcast -Category: Informational J. Ihren - Autonomica - P. Savola - CSC/FUNET - April 2006 - - - Operational Considerations and Issues with IPv6 DNS - -Status of This Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This memo presents operational considerations and issues with IPv6 - Domain Name System (DNS), including a summary of special IPv6 - addresses, documentation of known DNS implementation misbehavior, - recommendations and considerations on how to perform DNS naming for - service provisioning and for DNS resolver IPv6 support, - considerations for DNS updates for both the forward and reverse - trees, and miscellaneous issues. This memo is aimed to include a - summary of information about IPv6 DNS considerations for those who - have experience with IPv4 DNS. - -Table of Contents - - 1. Introduction ....................................................3 - 1.1. Representing IPv6 Addresses in DNS Records .................3 - 1.2. Independence of DNS Transport and DNS Records ..............4 - 1.3. Avoiding IPv4/IPv6 Name Space Fragmentation ................4 - 1.4. Query Type '*' and A/AAAA Records ..........................4 - 2. DNS Considerations about Special IPv6 Addresses .................5 - 2.1. Limited-Scope Addresses ....................................5 - 2.2. Temporary Addresses ........................................5 - 2.3. 6to4 Addresses .............................................5 - 2.4. Other Transition Mechanisms ................................5 - 3. Observed DNS Implementation Misbehavior .........................6 - 3.1. Misbehavior of DNS Servers and Load-balancers ..............6 - 3.2. Misbehavior of DNS Resolvers ...............................6 - - - -Durand, et al. Informational [Page 1] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - - 4. Recommendations for Service Provisioning Using DNS ..............7 - 4.1. Use of Service Names instead of Node Names .................7 - 4.2. Separate vs. the Same Service Names for IPv4 and IPv6 ......8 - 4.3. Adding the Records Only When Fully IPv6-enabled ............8 - 4.4. The Use of TTL for IPv4 and IPv6 RRs .......................9 - 4.4.1. TTL with Courtesy Additional Data ...................9 - 4.4.2. TTL with Critical Additional Data ..................10 - 4.5. IPv6 Transport Guidelines for DNS Servers .................10 - 5. Recommendations for DNS Resolver IPv6 Support ..................10 - 5.1. DNS Lookups May Query IPv6 Records Prematurely ............10 - 5.2. Obtaining a List of DNS Recursive Resolvers ...............12 - 5.3. IPv6 Transport Guidelines for Resolvers ...................12 - 6. Considerations about Forward DNS Updating ......................13 - 6.1. Manual or Custom DNS Updates ..............................13 - 6.2. Dynamic DNS ...............................................13 - 7. Considerations about Reverse DNS Updating ......................14 - 7.1. Applicability of Reverse DNS ..............................14 - 7.2. Manual or Custom DNS Updates ..............................15 - 7.3. DDNS with Stateless Address Autoconfiguration .............16 - 7.4. DDNS with DHCP ............................................17 - 7.5. DDNS with Dynamic Prefix Delegation .......................17 - 8. Miscellaneous DNS Considerations ...............................18 - 8.1. NAT-PT with DNS-ALG .......................................18 - 8.2. Renumbering Procedures and Applications' Use of DNS .......18 - 9. Acknowledgements ...............................................19 - 10. Security Considerations .......................................19 - 11. References ....................................................20 - 11.1. Normative References .....................................20 - 11.2. Informative References ...................................22 - Appendix A. Unique Local Addressing Considerations for DNS ........24 - Appendix B. Behavior of Additional Data in IPv4/IPv6 - Environments ..........................................24 - B.1. Description of Additional Data Scenarios ..................24 - B.2. Which Additional Data to Keep, If Any? ....................26 - B.3. Discussion of the Potential Problems ......................27 - - - - - - - - - - - - - - - - -Durand, et al. Informational [Page 2] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - -1. Introduction - - This memo presents operational considerations and issues with IPv6 - DNS; it is meant to be an extensive summary and a list of pointers - for more information about IPv6 DNS considerations for those with - experience with IPv4 DNS. - - The purpose of this document is to give information about various - issues and considerations related to DNS operations with IPv6; it is - not meant to be a normative specification or standard for IPv6 DNS. - - The first section gives a brief overview of how IPv6 addresses and - names are represented in the DNS, how transport protocols and - resource records (don't) relate, and what IPv4/IPv6 name space - fragmentation means and how to avoid it; all of these are described - at more length in other documents. - - The second section summarizes the special IPv6 address types and how - they relate to DNS. The third section describes observed DNS - implementation misbehaviors that have a varying effect on the use of - IPv6 records with DNS. The fourth section lists recommendations and - considerations for provisioning services with DNS. The fifth section - in turn looks at recommendations and considerations about providing - IPv6 support in the resolvers. The sixth and seventh sections - describe considerations with forward and reverse DNS updates, - respectively. The eighth section introduces several miscellaneous - IPv6 issues relating to DNS for which no better place has been found - in this memo. Appendix A looks briefly at the requirements for - unique local addressing. Appendix B discusses additional data. - -1.1. Representing IPv6 Addresses in DNS Records - - In the forward zones, IPv6 addresses are represented using AAAA - records. In the reverse zones, IPv6 address are represented using - PTR records in the nibble format under the ip6.arpa. tree. See - [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] - for background information. - - In particular, one should note that the use of A6 records in the - forward tree or Bitlabels in the reverse tree is not recommended - [RFC3363]. Using DNAME records is not recommended in the reverse - tree in conjunction with A6 records; the document did not mean to - take a stance on any other use of DNAME records [RFC3364]. - - - - - - - - -Durand, et al. Informational [Page 3] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - -1.2. Independence of DNS Transport and DNS Records - - DNS has been designed to present a single, globally unique name space - [RFC2826]. This property should be maintained, as described here and - in Section 1.3. - - The IP version used to transport the DNS queries and responses is - independent of the records being queried: AAAA records can be queried - over IPv4, and A records over IPv6. The DNS servers must not make - any assumptions about what data to return for Answer and Authority - sections based on the underlying transport used in a query. - - However, there is some debate whether the addresses in Additional - section could be selected or filtered using hints obtained from which - transport was being used; this has some obvious problems because in - many cases the transport protocol does not correlate with the - requests, and because a "bad" answer is in a way worse than no answer - at all (consider the case where the client is led to believe that a - name received in the additional record does not have any AAAA records - at all). - - As stated in [RFC3596]: - - The IP protocol version used for querying resource records is - independent of the protocol version of the resource records; e.g., - IPv4 transport can be used to query IPv6 records and vice versa. - -1.3. Avoiding IPv4/IPv6 Name Space Fragmentation - - To avoid the DNS name space from fragmenting into parts where some - parts of DNS are only visible using IPv4 (or IPv6) transport, the - recommendation is to always keep at least one authoritative server - IPv4-enabled, and to ensure that recursive DNS servers support IPv4. - See DNS IPv6 transport guidelines [RFC3901] for more information. - -1.4. Query Type '*' and A/AAAA Records - - QTYPE=* is typically only used for debugging or management purposes; - it is worth keeping in mind that QTYPE=* ("ANY" queries) only return - any available RRsets, not *all* the RRsets, because the caches do not - necessarily have all the RRsets and have no way of guaranteeing that - they have all the RRsets. Therefore, to get both A and AAAA records - reliably, two separate queries must be made. - - - - - - - - -Durand, et al. Informational [Page 4] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - -2. DNS Considerations about Special IPv6 Addresses - - There are a couple of IPv6 address types that are somewhat special; - these are considered here. - -2.1. Limited-Scope Addresses - - The IPv6 addressing architecture [RFC4291] includes two kinds of - local-use addresses: link-local (fe80::/10) and site-local - (fec0::/10). The site-local addresses have been deprecated [RFC3879] - but are discussed with unique local addresses in Appendix A. - - Link-local addresses should never be published in DNS (whether in - forward or reverse tree), because they have only local (to the - connected link) significance [WIP-DC2005]. - -2.2. Temporary Addresses - - Temporary addresses defined in RFC 3041 [RFC3041] (sometimes called - "privacy addresses") use a random number as the interface identifier. - Having DNS AAAA records that are updated to always contain the - current value of a node's temporary address would defeat the purpose - of the mechanism and is not recommended. However, it would still be - possible to return a non-identifiable name (e.g., the IPv6 address in - hexadecimal format), as described in [RFC3041]. - -2.3. 6to4 Addresses - - 6to4 [RFC3056] specifies an automatic tunneling mechanism that maps a - public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. - - If the reverse DNS population would be desirable (see Section 7.1 for - applicability), there are a number of possible ways to do so. - - [WIP-H2005] aims to design an autonomous reverse-delegation system - that anyone being capable of communicating using a specific 6to4 - address would be able to set up a reverse delegation to the - corresponding 6to4 prefix. This could be deployed by, e.g., Regional - Internet Registries (RIRs). This is a practical solution, but may - have some scalability concerns. - -2.4. Other Transition Mechanisms - - 6to4 is mentioned as a case of an IPv6 transition mechanism requiring - special considerations. In general, mechanisms that include a - special prefix may need a custom solution; otherwise, for example, - when IPv4 address is embedded as the suffix or not embedded at all, - special solutions are likely not needed. - - - -Durand, et al. Informational [Page 5] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - - Note that it does not seem feasible to provide reverse DNS with - another automatic tunneling mechanism, Teredo [RFC4380]; this is - because the IPv6 address is based on the IPv4 address and UDP port of - the current Network Address Translation (NAT) mapping, which is - likely to be relatively short-lived. - -3. Observed DNS Implementation Misbehavior - - Several classes of misbehavior in DNS servers, load-balancers, and - resolvers have been observed. Most of these are rather generic, not - only applicable to IPv6 -- but in some cases, the consequences of - this misbehavior are extremely severe in IPv6 environments and - deserve to be mentioned. - -3.1. Misbehavior of DNS Servers and Load-balancers - - There are several classes of misbehavior in certain DNS servers and - load-balancers that have been noticed and documented [RFC4074]: some - implementations silently drop queries for unimplemented DNS records - types, or provide wrong answers to such queries (instead of a proper - negative reply). While typically these issues are not limited to - AAAA records, the problems are aggravated by the fact that AAAA - records are being queried instead of (mainly) A records. - - The problems are serious because when looking up a DNS name, typical - getaddrinfo() implementations, with AF_UNSPEC hint given, first try - to query the AAAA records of the name, and after receiving a - response, query the A records. This is done in a serial fashion -- - if the first query is never responded to (instead of properly - returning a negative answer), significant time-outs will occur. - - In consequence, this is an enormous problem for IPv6 deployments, and - in some cases, IPv6 support in the software has even been disabled - due to these problems. - - The solution is to fix or retire those misbehaving implementations, - but that is likely not going to be effective. There are some - possible ways to mitigate the problem, e.g., by performing the - lookups somewhat in parallel and reducing the time-out as long as at - least one answer has been received, but such methods remain to be - investigated; slightly more on this is included in Section 5. - -3.2. Misbehavior of DNS Resolvers - - Several classes of misbehavior have also been noticed in DNS - resolvers [WIP-LB2005]. However, these do not seem to directly - impair IPv6 use, and are only referred to for completeness. - - - - -Durand, et al. Informational [Page 6] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - -4. Recommendations for Service Provisioning Using DNS - - When names are added in the DNS to facilitate a service, there are - several general guidelines to consider to be able to do it as - smoothly as possible. - -4.1. Use of Service Names instead of Node Names - - It makes sense to keep information about separate services logically - separate in the DNS by using a different DNS hostname for each - service. There are several reasons for doing this, for example: - - o It allows more flexibility and ease for migration of (only a part - of) services from one node to another, - - o It allows configuring different properties (e.g., Time to Live - (TTL)) for each service, and - - o It allows deciding separately for each service whether or not to - publish the IPv6 addresses (in cases where some services are more - IPv6-ready than others). - - Using SRV records [RFC2782] would avoid these problems. - Unfortunately, those are not sufficiently widely used to be - applicable in most cases. Hence an operation technique is to use - service names instead of node names (or "hostnames"). This - operational technique is not specific to IPv6, but required to - understand the considerations described in Section 4.2 and - Section 4.3. - - For example, assume a node named "pobox.example.com" provides both - SMTP and IMAP service. Instead of configuring the MX records to - point at "pobox.example.com", and configuring the mail clients to - look up the mail via IMAP from "pobox.example.com", one could use, - e.g., "smtp.example.com" for SMTP (for both message submission and - mail relaying between SMTP servers) and "imap.example.com" for IMAP. - Note that in the specific case of SMTP relaying, the server itself - must typically also be configured to know all its names to ensure - that loops do not occur. DNS can provide a layer of indirection - between service names and where the service actually is, and using - which addresses. (Obviously, when wanting to reach a specific node, - one should use the hostname rather than a service name.) - - - - - - - - - -Durand, et al. Informational [Page 7] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - -4.2. Separate vs. the Same Service Names for IPv4 and IPv6 - - The service naming can be achieved in basically two ways: when a - service is named "service.example.com" for IPv4, the IPv6-enabled - service could either be added to "service.example.com" or added - separately under a different name, e.g., in a sub-domain like - "service.ipv6.example.com". - - These two methods have different characteristics. Using a different - name allows for easier service piloting, minimizing the disturbance - to the "regular" users of IPv4 service; however, the service would - not be used transparently, without the user/application explicitly - finding it and asking for it -- which would be a disadvantage in most - cases. When the different name is under a sub-domain, if the - services are deployed within a restricted network (e.g., inside an - enterprise), it's possible to prefer them transparently, at least to - a degree, by modifying the DNS search path; however, this is a - suboptimal solution. Using the same service name is the "long-term" - solution, but may degrade performance for those clients whose IPv6 - performance is lower than IPv4, or does not work as well (see - Section 4.3 for more). - - In most cases, it makes sense to pilot or test a service using - separate service names, and move to the use of the same name when - confident enough that the service level will not degrade for the - users unaware of IPv6. - -4.3. Adding the Records Only When Fully IPv6-enabled - - The recommendation is that AAAA records for a service should not be - added to the DNS until all of following are true: - - 1. The address is assigned to the interface on the node. - - 2. The address is configured on the interface. - - 3. The interface is on a link that is connected to the IPv6 - infrastructure. - - In addition, if the AAAA record is added for the node, instead of - service as recommended, all the services of the node should be IPv6- - enabled prior to adding the resource record. - - For example, if an IPv6 node is isolated from an IPv6 perspective - (e.g., it is not connected to IPv6 Internet) constraint #3 would mean - that it should not have an address in the DNS. - - - - - -Durand, et al. Informational [Page 8] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - - Consider the case of two dual-stack nodes, which both are IPv6- - enabled, but the server does not have (global) IPv6 connectivity. As - the client looks up the server's name, only A records are returned - (if the recommendations above are followed), and no IPv6 - communication, which would have been unsuccessful, is even attempted. - - The issues are not always so black-and-white. Usually, it's - important that the service offered using both protocols is of roughly - equal quality, using the appropriate metrics for the service (e.g., - latency, throughput, low packet loss, general reliability, etc.). - This is typically very important especially for interactive or real- - time services. In many cases, the quality of IPv6 connectivity may - not yet be equal to that of IPv4, at least globally; this has to be - taken into consideration when enabling services. - -4.4. The Use of TTL for IPv4 and IPv6 RRs - - The behavior of DNS caching when different TTL values are used for - different RRsets of the same name calls for explicit discussion. For - example, let's consider two unrelated zone fragments: - - example.com. 300 IN MX foo.example.com. - foo.example.com. 300 IN A 192.0.2.1 - foo.example.com. 100 IN AAAA 2001:db8::1 - - ... - - child.example.com. 300 IN NS ns.child.example.com. - ns.child.example.com. 300 IN A 192.0.2.1 - ns.child.example.com. 100 IN AAAA 2001:db8::1 - - In the former case, we have "courtesy" additional data; in the - latter, we have "critical" additional data. See more extensive - background discussion of additional data handling in Appendix B. - -4.4.1. TTL with Courtesy Additional Data - - When a caching resolver asks for the MX record of example.com, it - gets back "foo.example.com". It may also get back either one or both - of the A and AAAA records in the additional section. The resolver - must explicitly query for both A and AAAA records [RFC2821]. - - After 100 seconds, the AAAA record is removed from the cache(s) - because its TTL expired. It could be argued to be useful for the - caching resolvers to discard the A record when the shorter TTL (in - this case, for the AAAA record) expires; this would avoid the - situation where there would be a window of 200 seconds when - incomplete information is returned from the cache. Further argument - - - -Durand, et al. Informational [Page 9] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - - for discarding is that in the normal operation, the TTL values are so - high that very likely the incurred additional queries would not be - noticeable, compared to the obtained performance optimization. The - behavior in this scenario is unspecified. - -4.4.2. TTL with Critical Additional Data - - The difference to courtesy additional data is that the A/AAAA records - served by the parent zone cannot be queried explicitly. Therefore, - after 100 seconds the AAAA record is removed from the cache(s), but - the A record remains. Queries for the remaining 200 seconds - (provided that there are no further queries from the parent that - could refresh the caches) only return the A record, leading to a - potential operational situation with unreachable servers. - - Similar cache flushing strategies apply in this scenario; the - behavior is likewise unspecified. - -4.5. IPv6 Transport Guidelines for DNS Servers - - As described in Section 1.3 and [RFC3901], there should continue to - be at least one authoritative IPv4 DNS server for every zone, even if - the zone has only IPv6 records. (Note that obviously, having more - servers with robust connectivity would be preferable, but this is the - minimum recommendation; also see [RFC2182].) - -5. Recommendations for DNS Resolver IPv6 Support - - When IPv6 is enabled on a node, there are several things to consider - to ensure that the process is as smooth as possible. - -5.1. DNS Lookups May Query IPv6 Records Prematurely - - The system library that implements the getaddrinfo() function for - looking up names is a critical piece when considering the robustness - of enabling IPv6; it may come in basically three flavors: - - 1. The system library does not know whether IPv6 has been enabled in - the kernel of the operating system: it may start looking up AAAA - records with getaddrinfo() and AF_UNSPEC hint when the system is - upgraded to a system library version that supports IPv6. - - 2. The system library might start to perform IPv6 queries with - getaddrinfo() only when IPv6 has been enabled in the kernel. - However, this does not guarantee that there exists any useful - IPv6 connectivity (e.g., the node could be isolated from the - other IPv6 networks, only having link-local addresses). - - - - -Durand, et al. Informational [Page 10] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - - 3. The system library might implement a toggle that would apply some - heuristics to the "IPv6-readiness" of the node before starting to - perform queries; for example, it could check whether only link- - local IPv6 address(es) exists, or if at least one global IPv6 - address exists. - - First, let us consider generic implications of unnecessary queries - for AAAA records: when looking up all the records in the DNS, AAAA - records are typically tried first, and then A records. These are - done in serial, and the A query is not performed until a response is - received to the AAAA query. Considering the misbehavior of DNS - servers and load-balancers, as described in Section 3.1, the lookup - delay for AAAA may incur additional unnecessary latency, and - introduce a component of unreliability. - - One option here could be to do the queries partially in parallel; for - example, if the final response to the AAAA query is not received in - 0.5 seconds, start performing the A query while waiting for the - result. (Immediate parallelism might not be optimal, at least - without information-sharing between the lookup threads, as that would - probably lead to duplicate non-cached delegation chain lookups.) - - An additional concern is the address selection, which may, in some - circumstances, prefer AAAA records over A records even when the node - does not have any IPv6 connectivity [WIP-RDP2004]. In some cases, - the implementation may attempt to connect or send a datagram on a - physical link [WIP-R2006], incurring very long protocol time-outs, - instead of quickly falling back to IPv4. - - Now, we can consider the issues specific to each of the three - possibilities: - - In the first case, the node performs a number of completely useless - DNS lookups as it will not be able to use the returned AAAA records - anyway. (The only exception is where the application desires to know - what's in the DNS, but not use the result for communication.) One - should be able to disable these unnecessary queries, for both latency - and reliability reasons. However, as IPv6 has not been enabled, the - connections to IPv6 addresses fail immediately, and if the - application is programmed properly, the application can fall - gracefully back to IPv4 [RFC4038]. - - The second case is similar to the first, except it happens to a - smaller set of nodes when IPv6 has been enabled but connectivity has - not been provided yet. Similar considerations apply, with the - exception that IPv6 records, when returned, will be actually tried - first, which may typically lead to long time-outs. - - - - -Durand, et al. Informational [Page 11] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - - The third case is a bit more complex: optimizing away the DNS lookups - with only link-locals is probably safe (but may be desirable with - different lookup services that getaddrinfo() may support), as the - link-locals are typically automatically generated when IPv6 is - enabled, and do not indicate any form of IPv6 connectivity. That is, - performing DNS lookups only when a non-link-local address has been - configured on any interface could be beneficial -- this would be an - indication that the address has been configured either from a router - advertisement, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - [RFC3315], or manually. Each would indicate at least some form of - IPv6 connectivity, even though there would not be guarantees of it. - - These issues should be analyzed at more depth, and the fixes found - consensus on, perhaps in a separate document. - -5.2. Obtaining a List of DNS Recursive Resolvers - - In scenarios where DHCPv6 is available, a host can discover a list of - DNS recursive resolvers through the DHCPv6 "DNS Recursive Name - Server" option [RFC3646]. This option can be passed to a host - through a subset of DHCPv6 [RFC3736]. - - The IETF is considering the development of alternative mechanisms for - obtaining the list of DNS recursive name servers when DHCPv6 is - unavailable or inappropriate. No decision about taking on this - development work has been reached as of this writing [RFC4339]. - - In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms - under consideration for development include the use of [WIP-O2004] - and the use of Router Advertisements to convey the information - [WIP-J2006]. - - Note that even though IPv6 DNS resolver discovery is a recommended - procedure, it is not required for dual-stack nodes in dual-stack - networks as IPv6 DNS records can be queried over IPv4 as well as - IPv6. Obviously, nodes that are meant to function without manual - configuration in IPv6-only networks must implement the DNS resolver - discovery function. - -5.3. IPv6 Transport Guidelines for Resolvers - - As described in Section 1.3 and [RFC3901], the recursive resolvers - should be IPv4-only or dual-stack to be able to reach any IPv4-only - DNS server. Note that this requirement is also fulfilled by an IPv6- - only stub resolver pointing to a dual-stack recursive DNS resolver. - - - - - - -Durand, et al. Informational [Page 12] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - -6. Considerations about Forward DNS Updating - - While the topic of how to enable updating the forward DNS, i.e., the - mapping from names to the correct new addresses, is not specific to - IPv6, it should be considered especially due to the advent of - Stateless Address Autoconfiguration [RFC2462]. - - Typically, forward DNS updates are more manageable than doing them in - the reverse DNS, because the updater can often be assumed to "own" a - certain DNS name -- and we can create a form of security relationship - with the DNS name and the node that is allowed to update it to point - to a new address. - - A more complex form of DNS updates -- adding a whole new name into a - DNS zone, instead of updating an existing name -- is considered out - of scope for this memo as it could require zone-wide authentication. - Adding a new name in the forward zone is a problem that is still - being explored with IPv4, and IPv6 does not seem to add much new in - that area. - -6.1. Manual or Custom DNS Updates - - The DNS mappings can also be maintained by hand, in a semi-automatic - fashion or by running non-standardized protocols. These are not - considered at more length in this memo. - -6.2. Dynamic DNS - - Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized - mechanism for dynamically updating the DNS. It works equally well - with Stateless Address Autoconfiguration (SLAAC), DHCPv6, or manual - address configuration. It is important to consider how each of these - behave if IP address-based authentication, instead of stronger - mechanisms [RFC3007], was used in the updates. - - 1. Manual addresses are static and can be configured. - - 2. DHCPv6 addresses could be reasonably static or dynamic, depending - on the deployment, and could or could not be configured on the - DNS server for the long term. - - 3. SLAAC addresses are typically stable for a long time, but could - require work to be configured and maintained. - - As relying on IP addresses for Dynamic DNS is rather insecure at - best, stronger authentication should always be used; however, this - requires that the authorization keying will be explicitly configured - using unspecified operational methods. - - - -Durand, et al. Informational [Page 13] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - - Note that with DHCP it is also possible that the DHCP server updates - the DNS, not the host. The host might only indicate in the DHCP - exchange which hostname it would prefer, and the DHCP server would - make the appropriate updates. Nonetheless, while this makes setting - up a secure channel between the updater and the DNS server easier, it - does not help much with "content" security, i.e., whether the - hostname was acceptable -- if the DNS server does not include - policies, they must be included in the DHCP server (e.g., a regular - host should not be able to state that its name is "www.example.com"). - DHCP-initiated DDNS updates have been extensively described in - [WIP-SV2005], [WIP-S2005a], and [WIP-S2005b]. - - The nodes must somehow be configured with the information about the - servers where they will attempt to update their addresses, sufficient - security material for authenticating themselves to the server, and - the hostname they will be updating. Unless otherwise configured, the - first could be obtained by looking up the authoritative name servers - for the hostname; the second must be configured explicitly unless one - chooses to trust the IP address-based authentication (not a good - idea); and lastly, the nodename is typically pre-configured somehow - on the node, e.g., at install time. - - Care should be observed when updating the addresses not to use longer - TTLs for addresses than are preferred lifetimes for the addresses, so - that if the node is renumbered in a managed fashion, the amount of - stale DNS information is kept to the minimum. That is, if the - preferred lifetime of an address expires, the TTL of the record needs - to be modified unless it was already done before the expiration. For - better flexibility, the DNS TTL should be much shorter (e.g., a half - or a third) than the lifetime of an address; that way, the node can - start lowering the DNS TTL if it seems like the address has not been - renewed/refreshed in a while. Some discussion on how an - administrator could manage the DNS TTL is included in [RFC4192]; this - could be applied to (smart) hosts as well. - -7. Considerations about Reverse DNS Updating - - Updating the reverse DNS zone may be difficult because of the split - authority over an address. However, first we have to consider the - applicability of reverse DNS in the first place. - -7.1. Applicability of Reverse DNS - - Today, some applications use reverse DNS either to look up some hints - about the topological information associated with an address (e.g., - resolving web server access logs) or (as a weak form of a security - check) to get a feel whether the user's network administrator has - - - - -Durand, et al. Informational [Page 14] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - - "authorized" the use of the address (on the premise that adding a - reverse record for an address would signal some form of - authorization). - - One additional, maybe slightly more useful usage is ensuring that the - reverse and forward DNS contents match (by looking up the pointer to - the name by the IP address from the reverse tree, and ensuring that a - record under the name in the forward tree points to the IP address) - and correspond to a configured name or domain. As a security check, - it is typically accompanied by other mechanisms, such as a user/ - password login; the main purpose of the reverse+forward DNS check is - to weed out the majority of unauthorized users, and if someone - managed to bypass the checks, he would still need to authenticate - "properly". - - It may also be desirable to store IPsec keying material corresponding - to an IP address in the reverse DNS, as justified and described in - [RFC4025]. - - It is not clear whether it makes sense to require or recommend that - reverse DNS records be updated. In many cases, it would just make - more sense to use proper mechanisms for security (or topological - information lookup) in the first place. At minimum, the applications - that use it as a generic authorization (in the sense that a record - exists at all) should be modified as soon as possible to avoid such - lookups completely. - - The applicability is discussed at more length in [WIP-S2005c]. - -7.2. Manual or Custom DNS Updates - - Reverse DNS can of course be updated using manual or custom methods. - These are not further described here, except for one special case. - - One way to deploy reverse DNS would be to use wildcard records, for - example, by configuring one name for a subnet (/64) or a site (/48). - As a concrete example, a site (or the site's ISP) could configure the - reverses of the prefix 2001:db8:f00::/48 to point to one name using a - wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR - site.example.com.". Naturally, such a name could not be verified - from the forward DNS, but would at least provide some form of - "topological information" or "weak authorization" if that is really - considered to be useful. Note that this is not actually updating the - DNS as such, as the whole point is to avoid DNS updates completely by - manually configuring a generic name. - - - - - - -Durand, et al. Informational [Page 15] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - -7.3. DDNS with Stateless Address Autoconfiguration - - Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in - some regard, while being more difficult in another, as described - below. - - The address space administrator decides whether or not the hosts are - trusted to update their reverse DNS records. If they are trusted and - deployed at the same site (e.g., not across the Internet), a simple - address-based authorization is typically sufficient (i.e., check that - the DNS update is done from the same IP address as the record being - updated); stronger security can also be used [RFC3007]. If they - aren't allowed to update the reverses, no update can occur. However, - such address-based update authorization operationally requires that - ingress filtering [RFC3704] has been set up at the border of the site - where the updates occur, and as close to the updater as possible. - - Address-based authorization is simpler with reverse DNS (as there is - a connection between the record and the address) than with forward - DNS. However, when a stronger form of security is used, forward DNS - updates are simpler to manage because the host can be assumed to have - an association with the domain. Note that the user may roam to - different networks and does not necessarily have any association with - the owner of that address space. So, assuming a stronger form of - authorization for reverse DNS updates than an address association is - generally infeasible. - - Moreover, the reverse zones must be cleaned up by an unspecified - janitorial process: the node does not typically know a priori that it - will be disconnected, and it cannot send a DNS update using the - correct source address to remove a record. - - A problem with defining the clean-up process is that it is difficult - to ensure that a specific IP address and the corresponding record are - no longer being used. Considering the huge address space, and the - unlikelihood of collision within 64 bits of the interface - identifiers, a process that would remove the record after no traffic - has been seen from a node in a long period of time (e.g., a month or - year) might be one possible approach. - - To insert or update the record, the node must discover the DNS server - to send the update to somehow, similar to as discussed in - Section 6.2. One way to automate this is looking up the DNS server - authoritative (e.g., through SOA record) for the IP address being - updated, but the security material (unless the IP address-based - authorization is trusted) must also be established by some other - means. - - - - -Durand, et al. Informational [Page 16] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - - One should note that Cryptographically Generated Addresses (CGAs) - [RFC3972] may require a slightly different kind of treatment. CGAs - are addresses where the interface identifier is calculated from a - public key, a modifier (used as a nonce), the subnet prefix, and - other data. Depending on the usage profile, CGAs might or might not - be changed periodically due to, e.g., privacy reasons. As the CGA - address is not predictable, a reverse record can only reasonably be - inserted in the DNS by the node that generates the address. - -7.4. DDNS with DHCP - - With DHCPv4, the reverse DNS name is typically already inserted to - the DNS that reflects the name (e.g., "dhcp-67.example.com"). One - can assume similar practice may become commonplace with DHCPv6 as - well; all such mappings would be pre-configured and would require no - updating. - - If a more explicit control is required, similar considerations as - with SLAAC apply, except for the fact that typically one must update - a reverse DNS record instead of inserting one (if an address - assignment policy that reassigns disused addresses is adopted) and - updating a record seems like a slightly more difficult thing to - secure. However, it is yet uncertain how DHCPv6 is going to be used - for address assignment. - - Note that when using DHCP, either the host or the DHCP server could - perform the DNS updates; see the implications in Section 6.2. - - If disused addresses were to be reassigned, host-based DDNS reverse - updates would need policy considerations for DNS record modification, - as noted above. On the other hand, if disused address were not to be - assigned, host-based DNS reverse updates would have similar - considerations as SLAAC in Section 7.3. Server-based updates have - similar properties except that the janitorial process could be - integrated with DHCP address assignment. - -7.5. DDNS with Dynamic Prefix Delegation - - In cases where a prefix, instead of an address, is being used and - updated, one should consider what is the location of the server where - DDNS updates are made. That is, where the DNS server is located: - - 1. At the same organization as the prefix delegator. - - 2. At the site where the prefixes are delegated to. In this case, - the authority of the DNS reverse zone corresponding to the - delegated prefix is also delegated to the site. - - - - -Durand, et al. Informational [Page 17] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - - 3. Elsewhere; this implies a relationship between the site and where - the DNS server is located, and such a relationship should be - rather straightforward to secure as well. Like in the previous - case, the authority of the DNS reverse zone is also delegated. - - In the first case, managing the reverse DNS (delegation) is simpler - as the DNS server and the prefix delegator are in the same - administrative domain (as there is no need to delegate anything at - all); alternatively, the prefix delegator might forgo DDNS reverse - capability altogether, and use, e.g., wildcard records (as described - in Section 7.2). In the other cases, it can be slightly more - difficult, particularly as the site will have to configure the DNS - server to be authoritative for the delegated reverse zone, implying - automatic configuration of the DNS server -- as the prefix may be - dynamic. - - Managing the DDNS reverse updates is typically simple in the second - case, as the updated server is located at the local site, and - arguably IP address-based authentication could be sufficient (or if - not, setting up security relationships would be simpler). As there - is an explicit (security) relationship between the parties in the - third case, setting up the security relationships to allow reverse - DDNS updates should be rather straightforward as well (but IP - address-based authentication might not be acceptable). In the first - case, however, setting up and managing such relationships might be a - lot more difficult. - -8. Miscellaneous DNS Considerations - - This section describes miscellaneous considerations about DNS that - seem related to IPv6, for which no better place has been found in - this document. - -8.1. NAT-PT with DNS-ALG - - The DNS-ALG component of NAT-PT [RFC2766] mangles A records to look - like AAAA records to the IPv6-only nodes. Numerous problems have - been identified with [WIP-AD2005]. This is a strong reason not to - use NAT-PT in the first place. - -8.2. Renumbering Procedures and Applications' Use of DNS - - One of the most difficult problems of systematic IP address - renumbering procedures [RFC4192] is that an application that looks up - a DNS name disregards information such as TTL, and uses the result - obtained from DNS as long as it happens to be stored in the memory of - the application. For applications that run for a long time, this - - - - -Durand, et al. Informational [Page 18] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - - could be days, weeks, or even months. Some applications may be - clever enough to organize the data structures and functions in such a - manner that lookups get refreshed now and then. - - While the issue appears to have a clear solution, "fix the - applications", practically, this is not reasonable immediate advice. - The TTL information is not typically available in the APIs and - libraries (so, the advice becomes "fix the applications, APIs, and - libraries"), and a lot more analysis is needed on how to practically - go about to achieve the ultimate goal of avoiding using the names - longer than expected. - -9. Acknowledgements - - Some recommendations (Section 4.3, Section 5.1) about IPv6 service - provisioning were moved here from [RFC4213] by Erik Nordmark and Bob - Gilligan. Havard Eidnes and Michael Patton provided useful feedback - and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark - Andrews helped in clarifying the issues regarding additional data and - the use of TTL. Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei - Tatuya, Iljitsch van Beijnum, Edward Lewis, and Rob Austein provided - useful feedback during the WG last call. Thomas Narten provided - extensive feedback during the IESG evaluation. - -10. Security Considerations - - This document reviews the operational procedures for IPv6 DNS - operations and does not have security considerations in itself. - - However, it is worth noting that in particular with Dynamic DNS - updates, security models based on the source address validation are - very weak and cannot be recommended -- they could only be considered - in the environments where ingress filtering [RFC3704] has been - deployed. On the other hand, it should be noted that setting up an - authorization mechanism (e.g., a shared secret, or public-private - keys) between a node and the DNS server has to be done manually, and - may require quite a bit of time and expertise. - - To re-emphasize what was already stated, the reverse+forward DNS - check provides very weak security at best, and the only - (questionable) security-related use for them may be in conjunction - with other mechanisms when authenticating a user. - - - - - - - - - -Durand, et al. Informational [Page 19] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - -11. References - -11.1. Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and - facilities", STD 13, RFC 1034, November 1987. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS - UPDATE)", RFC 2136, April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, - "Selection and Operation of Secondary DNS Servers", - BCP 16, RFC 2182, July 1997. - - [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - - [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, - April 2001. - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) - Dynamic Update", RFC 3007, November 2000. - - [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for - Stateless Address Autoconfiguration in IPv6", RFC 3041, - January 2001. - - [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains - via IPv4 Clouds", RFC 3056, February 2001. - - [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, - August 2001. - - [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., - and M. Carney, "Dynamic Host Configuration Protocol for - IPv6 (DHCPv6)", RFC 3315, July 2003. - - [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. - - - -Durand, et al. Informational [Page 20] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - - [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) - Support for Internet Protocol version 6 (IPv6)", - RFC 3364, August 2002. - - [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, - "DNS Extensions to Support IP Version 6", RFC 3596, - October 2003. - - [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host - Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, - December 2003. - - [RFC3736] Droms, R., "Stateless Dynamic Host Configuration - Protocol (DHCP) Service for IPv6", RFC 3736, - April 2004. - - [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local - Addresses", RFC 3879, September 2004. - - [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport - Operational Guidelines", BCP 91, RFC 3901, - September 2004. - - [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. - Castro, "Application Aspects of IPv6 Transition", - RFC 4038, March 2005. - - [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior - Against DNS Queries for IPv6 Addresses", RFC 4074, - May 2005. - - [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for - Renumbering an IPv6 Network without a Flag Day", - RFC 4192, September 2005. - - [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast - Addresses", RFC 4193, October 2005. - - [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 4291, February 2006. - - [RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server - Information Approaches", RFC 4339, February 2006. - - - - - - - - -Durand, et al. Informational [Page 21] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - -11.2. Informative References - - [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address - Translation - Protocol Translation (NAT-PT)", RFC 2766, - February 2000. - - [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR - for specifying the location of services (DNS SRV)", - RFC 2782, February 2000. - - [RFC2826] Internet Architecture Board, "IAB Technical Comment on - the Unique DNS Root", RFC 2826, May 2000. - - [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for - Multihomed Networks", BCP 84, RFC 3704, March 2004. - - [RFC3972] Aura, T., "Cryptographically Generated Addresses - (CGA)", RFC 3972, March 2005. - - [RFC4025] Richardson, M., "A Method for Storing IPsec Keying - Material in DNS", RFC 4025, March 2005. - - [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition - Mechanisms for IPv6 Hosts and Routers", RFC 4213, - October 2005. - - [RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third - Generation Partnership Project (3GPP) Networks", - RFC 4215, October 2005. - - [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through - Network Address Translations (NATs)", RFC 4380, - February 2006. - - [TC-TEST] Jinmei, T., "Thread "RFC2181 section 9.1: TC bit - handling and additional data" on DNSEXT mailing list, - Message- - Id:y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp", August - 1, 2005, . - - [WIP-AD2005] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to - Experimental", Work in Progress, October 2005. - - [WIP-DC2005] Durand, A. and T. Chown, "To publish, or not to - publish, that is the question", Work in Progress, - October 2005. - - - - -Durand, et al. Informational [Page 22] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - - [WIP-H2005] Huston, G., "6to4 Reverse DNS Delegation - Specification", Work in Progress, November 2005. - - [WIP-J2006] Jeong, J., "IPv6 Router Advertisement Option for DNS - Configuration", Work in Progress, January 2006. - - [WIP-LB2005] Larson, M. and P. Barber, "Observed DNS Resolution - Misbehavior", Work in Progress, February 2006. - - [WIP-O2004] Ohta, M., "Preconfigured DNS Server Addresses", Work in - Progress, February 2004. - - [WIP-R2006] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption - Considered Harmful", Work in Progress, January 2006. - - [WIP-RDP2004] Roy, S., Durand, A., and J. Paugh, "Issues with Dual - Stack IPv6 on by Default", Work in Progress, July 2004. - - [WIP-S2005a] Stapp, M., "The DHCP Client FQDN Option", Work in - Progress, March 2006. - - [WIP-S2005b] Stapp, M., "A DNS RR for Encoding DHCP Information - (DHCID RR)", Work in Progress, March 2006. - - [WIP-S2005c] Senie, D., "Encouraging the use of DNS IN-ADDR - Mapping", Work in Progress, August 2005. - - [WIP-SV2005] Stapp, M. and B. Volz, "Resolution of FQDN Conflicts - among DHCP Clients", Work in Progress, March 2006. - - - - - - - - - - - - - - - - - - - - - - -Durand, et al. Informational [Page 23] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - -Appendix A. Unique Local Addressing Considerations for DNS - - Unique local addresses [RFC4193] have replaced the now-deprecated - site-local addresses [RFC3879]. From the perspective of the DNS, the - locally generated unique local addresses (LUL) and site-local - addresses have similar properties. - - The interactions with DNS come in two flavors: forward and reverse - DNS. - - To actually use local addresses within a site, this implies the - deployment of a "split-faced" or a fragmented DNS name space, for the - zones internal to the site, and the outsiders' view to it. The - procedures to achieve this are not elaborated here. The implication - is that local addresses must not be published in the public DNS. - - To facilitate reverse DNS (if desired) with local addresses, the stub - resolvers must look for DNS information from the local DNS servers, - not, e.g., starting from the root servers, so that the local - information may be provided locally. Note that the experience of - private addresses in IPv4 has shown that the root servers get loaded - for requests for private address lookups in any case. This - requirement is discussed in [RFC4193]. - -Appendix B. Behavior of Additional Data in IPv4/IPv6 Environments - - DNS responses do not always fit in a single UDP packet. We'll - examine the cases that happen when this is due to too much data in - the Additional section. - -B.1. Description of Additional Data Scenarios - - There are two kinds of additional data: - - 1. "critical" additional data; this must be included in all - scenarios, with all the RRsets, and - - 2. "courtesy" additional data; this could be sent in full, with only - a few RRsets, or with no RRsets, and can be fetched separately as - well, but at the cost of additional queries. - - The responding server can algorithmically determine which type the - additional data is by checking whether it's at or below a zone cut. - - Only those additional data records (even if sometimes carelessly - termed "glue") are considered "critical" or real "glue" if and only - if they meet the above-mentioned condition, as specified in Section - 4.2.1 of [RFC1034]. - - - -Durand, et al. Informational [Page 24] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - - Remember that resource record sets (RRsets) are never "broken up", so - if a name has 4 A records and 5 AAAA records, you can either return - all 9, all 4 A records, all 5 AAAA records, or nothing. In - particular, notice that for the "critical" additional data getting - all the RRsets can be critical. - - In particular, [RFC2181] specifies (in Section 9) that: - - a. if all the "critical" RRsets do not fit, the sender should set - the TC bit, and the recipient should discard the whole response - and retry using mechanism allowing larger responses such as TCP. - - b. "courtesy" additional data should not cause the setting of the TC - bit, but instead all the non-fitting additional data RRsets - should be removed. - - An example of the "courtesy" additional data is A/AAAA records in - conjunction with MX records as shown in Section 4.4; an example of - the "critical" additional data is shown below (where getting both the - A and AAAA RRsets is critical with respect to the NS RR): - - child.example.com. IN NS ns.child.example.com. - ns.child.example.com. IN A 192.0.2.1 - ns.child.example.com. IN AAAA 2001:db8::1 - - When there is too much "courtesy" additional data, at least the non- - fitting RRsets should be removed [RFC2181]; however, as the - additional data is not critical, even all of it could be safely - removed. - - When there is too much "critical" additional data, TC bit will have - to be set, and the recipient should ignore the response and retry - using TCP; if some data were to be left in the UDP response, the - issue is which data could be retained. - - However, the practice may differ from the specification. Testing and - code analysis of three recent implementations [TC-TEST] confirm this. - None of the tested implementations have a strict separation of - critical and courtesy additional data, while some forms of additional - data may be treated preferably. All the implementations remove some - (critical or courtesy) additional data RRsets without setting the TC - bit if the response would not otherwise fit. - - Failing to discard the response with the TC bit or omitting critical - information but not setting the TC bit lead to an unrecoverable - problem. Omitting only some of the RRsets if all would not fit (but - not setting the TC bit) leads to a performance problem. These are - discussed in the next two subsections. - - - -Durand, et al. Informational [Page 25] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - -B.2. Which Additional Data to Keep, If Any? - - NOTE: omitting some critical additional data instead of setting the - TC bit violates a 'should' in Section 9 of RFC2181. However, as many - implementations still do that [TC-TEST], operators need to understand - its implications, and we describe that behavior as well. - - If the implementation decides to keep as much data (whether - "critical" or "courtesy") as possible in the UDP responses, it might - be tempting to use the transport of the DNS query as a hint in either - of these cases: return the AAAA records if the query was done over - IPv6, or return the A records if the query was done over IPv4. - However, this breaks the model of independence of DNS transport and - resource records, as noted in Section 1.2. - - With courtesy additional data, as long as enough RRsets will be - removed so that TC will not be set, it is allowed to send as many - complete RRsets as the implementations prefers. However, the - implementations are also free to omit all such RRsets, even if - complete. Omitting all the RRsets (when removing only some would - suffice) may create a performance penalty, whereby the client may - need to issue one or more additional queries to obtain necessary - and/or consistent information. - - With critical additional data, the alternatives are either returning - nothing (and absolutely requiring a retry with TCP) or returning - something (working also in the case if the recipient does not discard - the response and retry using TCP) in addition to setting the TC bit. - If the process for selecting "something" from the critical data would - otherwise be practically "flipping the coin" between A and AAAA - records, it could be argued that if one looked at the transport of - the query, it would have a larger possibility of being right than - just 50/50. In other words, if the returned critical additional data - would have to be selected somehow, using something more sophisticated - than a random process would seem justifiable. - - That is, leaving in some intelligently selected critical additional - data is a trade-off between creating an optimization for those - resolvers that ignore the "should discard" recommendation and causing - a protocol problem by propagating inconsistent information about - "critical" records in the caches. - - Similarly, leaving in the complete courtesy additional data RRsets - instead of removing all the RRsets is a performance trade-off as - described in the next section. - - - - - - -Durand, et al. Informational [Page 26] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - -B.3. Discussion of the Potential Problems - - As noted above, the temptation for omitting only some of the - additional data could be problematic. This is discussed more below. - - For courtesy additional data, this causes a potential performance - problem as this requires that the clients issue re-queries for the - potentially omitted RRsets. For critical additional data, this - causes a potential unrecoverable problem if the response is not - discarded and the query not re-tried with TCP, as the nameservers - might be reachable only through the omitted RRsets. - - If an implementation would look at the transport used for the query, - it is worth remembering that often the host using the records is - different from the node requesting them from the authoritative DNS - server (or even a caching resolver). So, whichever version the - requestor (e.g., a recursive server in the middle) uses makes no - difference to the ultimate user of the records, whose transport - capabilities might differ from those of the requestor. This might - result in, e.g., inappropriately returning A records to an IPv6-only - node, going through a translation, or opening up another IP-level - session (e.g., a Packet Data Protocol (PDP) context [RFC4215]). - Therefore, at least in many scenarios, it would be very useful if the - information returned would be consistent and complete -- or if that - is not feasible, leave it to the client to query again. - - The problem of too much additional data seems to be an operational - one: the zone administrator entering too many records that will be - returned truncated (or missing some RRsets, depending on - implementations) to the users. A protocol fix for this is using - Extension Mechanisms for DNS (EDNS0) [RFC2671] to signal the capacity - for larger UDP packet sizes, pushing up the relevant threshold. - Further, DNS server implementations should omit courtesy additional - data completely rather than including only some RRsets [RFC2181]. An - operational fix for this is having the DNS server implementations - return a warning when the administrators create zones that would - result in too much additional data being returned. Further, DNS - server implementations should warn of or disallow such zone - configurations that are recursive or otherwise difficult to manage by - the protocol. - - - - - - - - - - - -Durand, et al. Informational [Page 27] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - -Authors' Addresses - - Alain Durand - Comcast - 1500 Market St. - Philadelphia, PA 19102 - USA - - EMail: Alain_Durand@cable.comcast.com - - - Johan Ihren - Autonomica - Bellmansgatan 30 - SE-118 47 Stockholm - Sweden - - EMail: johani@autonomica.se - - - Pekka Savola - CSC/FUNET - Espoo - Finland - - EMail: psavola@funet.fi - - - - - - - - - - - - - - - - - - - - - - - - - -Durand, et al. Informational [Page 28] - -RFC 4472 Considerations with IPv6 DNS April 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Durand, et al. Informational [Page 29] - diff --git a/doc/rfc/rfc4697.txt b/doc/rfc/rfc4697.txt deleted file mode 100644 index 773507ca690..00000000000 --- a/doc/rfc/rfc4697.txt +++ /dev/null @@ -1,1011 +0,0 @@ - - - - - - -Network Working Group M. Larson -Request for Comments: 4697 P. Barber -BCP: 123 VeriSign, Inc. -Category: Best Current Practice October 2006 - - - Observed DNS Resolution Misbehavior - -Status of This Memo - - This document specifies an Internet Best Current Practices for the - Internet Community, and requests discussion and suggestions for - improvements. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This memo describes DNS iterative resolver behavior that results in a - significant query volume sent to the root and top-level domain (TLD) - name servers. We offer implementation advice to iterative resolver - developers to alleviate these unnecessary queries. The - recommendations made in this document are a direct byproduct of - observation and analysis of abnormal query traffic patterns seen at - two of the thirteen root name servers and all thirteen com/net TLD - name servers. - -Table of Contents - - 1. Introduction ....................................................2 - 1.1. A Note about Terminology in this Memo ......................3 - 1.2. Key Words ..................................................3 - 2. Observed Iterative Resolver Misbehavior .........................3 - 2.1. Aggressive Requerying for Delegation Information ...........3 - 2.1.1. Recommendation ......................................5 - 2.2. Repeated Queries to Lame Servers ...........................6 - 2.2.1. Recommendation ......................................6 - 2.3. Inability to Follow Multiple Levels of Indirection .........7 - 2.3.1. Recommendation ......................................7 - 2.4. Aggressive Retransmission when Fetching Glue ...............8 - 2.4.1. Recommendation ......................................9 - 2.5. Aggressive Retransmission behind Firewalls .................9 - 2.5.1. Recommendation .....................................10 - 2.6. Misconfigured NS Records ..................................10 - 2.6.1. Recommendation .....................................11 - - - - -Larson & Barber Best Current Practice [Page 1] - -RFC 4697 Observed DNS Resolution Misbehavior October 2006 - - - 2.7. Name Server Records with Zero TTL .........................11 - 2.7.1. Recommendation .....................................12 - 2.8. Unnecessary Dynamic Update Messages .......................12 - 2.8.1. Recommendation .....................................13 - 2.9. Queries for Domain Names Resembling IPv4 Addresses ........13 - 2.9.1. Recommendation .....................................14 - 2.10. Misdirected Recursive Queries ............................14 - 2.10.1. Recommendation ....................................14 - 2.11. Suboptimal Name Server Selection Algorithm ...............15 - 2.11.1. Recommendation ....................................15 - 3. Security Considerations ........................................16 - 4. Acknowledgements ...............................................16 - 5. Internationalization Considerations ............................16 - 6. References .....................................................16 - 6.1. Normative References ......................................16 - 6.2. Informative References ....................................16 - -1. Introduction - - Observation of query traffic received by two root name servers and - the thirteen com/net Top-Level Domain (TLD) name servers has revealed - that a large proportion of the total traffic often consists of - "requeries". A requery is the same question () - asked repeatedly at an unexpectedly high rate. We have observed - requeries from both a single IP address and multiple IP addresses - (i.e., the same query received simultaneously from multiple IP - addresses). - - By analyzing requery events, we have found that the cause of the - duplicate traffic is almost always a deficient iterative resolver, - stub resolver, or application implementation combined with an - operational anomaly. The implementation deficiencies we have - identified to date include well-intentioned recovery attempts gone - awry, insufficient caching of failures, early abort when multiple - levels of indirection must be followed, and aggressive retry by stub - resolvers or applications. Anomalies that we have seen trigger - requery events include lame delegations, unusual glue records, and - anything that makes all authoritative name servers for a zone - unreachable (Denial of Service (DoS) attacks, crashes, maintenance, - routing failures, congestion, etc.). - - In the following sections, we provide a detailed explanation of the - observed behavior and recommend changes that will reduce the requery - rate. None of the changes recommended affects the core DNS protocol - specification; instead, this document consists of guidelines to - implementors of iterative resolvers. - - - - - -Larson & Barber Best Current Practice [Page 2] - -RFC 4697 Observed DNS Resolution Misbehavior October 2006 - - -1.1. A Note about Terminology in This Memo - - To recast an old saying about standards, the nice thing about DNS - terms is that there are so many of them to choose from. Writing or - talking about DNS can be difficult and can cause confusion resulting - from a lack of agreed-upon terms for its various components. Further - complicating matters are implementations that combine multiple roles - into one piece of software, which makes naming the result - problematic. An example is the entity that accepts recursive - queries, issues iterative queries as necessary to resolve the initial - recursive query, caches responses it receives, and which is also able - to answer questions about certain zones authoritatively. This entity - is an iterative resolver combined with an authoritative name server - and is often called a "recursive name server" or a "caching name - server". - - This memo is concerned principally with the behavior of iterative - resolvers, which are typically found as part of a recursive name - server. This memo uses the more precise term "iterative resolver", - because the focus is usually on that component. In instances where - the name server role of this entity requires mentioning, this memo - uses the term "recursive name server". As an example of the - difference, the name server component of a recursive name server - receives DNS queries and the iterative resolver component sends - queries. - - The advent of IPv6 requires mentioning AAAA records as well as A - records when discussing glue. To avoid continuous repetition and - qualification, this memo uses the general term "address record" to - encompass both A and AAAA records when a particular situation is - relevant to both types. - -1.2. Key Words - - 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 [1]. - -2. Observed Iterative Resolver Misbehavior - -2.1. Aggressive Requerying for Delegation Information - - There can be times when every name server in a zone's NS RRSet is - unreachable (e.g., during a network outage), unavailable (e.g., the - name server process is not running on the server host), or - misconfigured (e.g., the name server is not authoritative for the - given zone, also known as "lame"). Consider an iterative resolver - that attempts to resolve a query for a domain name in such a zone and - - - -Larson & Barber Best Current Practice [Page 3] - -RFC 4697 Observed DNS Resolution Misbehavior October 2006 - - - discovers that none of the zone's name servers can provide an answer. - We have observed a recursive name server implementation whose - iterative resolver then verifies the zone's NS RRSet in its cache by - querying for the zone's delegation information: it sends a query for - the zone's NS RRSet to one of the parent zone's name servers. (Note - that queries with QTYPE=NS are not required by the standard - resolution algorithm described in Section 4.3.2 of RFC 1034 [2]. - These NS queries represent this implementation's addition to that - algorithm.) - - For example, suppose that "example.com" has the following NS RRSet: - - example.com. IN NS ns1.example.com. - example.com. IN NS ns2.example.com. - - Upon receipt of a query for "www.example.com" and assuming that - neither "ns1.example.com" nor "ns2.example.com" can provide an - answer, this iterative resolver implementation immediately queries a - "com" zone name server for the "example.com" NS RRSet to verify that - it has the proper delegation information. This implementation - performs this query to a zone's parent zone for each recursive query - it receives that fails because of a completely unresponsive set of - name servers for the target zone. Consider the effect when a popular - zone experiences a catastrophic failure of all its name servers: now - every recursive query for domain names in that zone sent to this - recursive name server implementation results in a query to the failed - zone's parent name servers. On one occasion when several dozen - popular zones became unreachable, the query load on the com/net name - servers increased by 50%. - - We believe this verification query is not reasonable. Consider the - circumstances: when an iterative resolver is resolving a query for a - domain name in a zone it has not previously searched, it uses the - list of name servers in the referral from the target zone's parent. - If on its first attempt to search the target zone, none of the name - servers in the referral is reachable, a verification query to the - parent would be pointless: this query to the parent would come so - quickly on the heels of the referral that it would be almost certain - to contain the same list of name servers. The chance of discovering - any new information is slim. - - The other possibility is that the iterative resolver successfully - contacts one of the target zone's name servers and then caches the NS - RRSet from the authority section of a response, the proper behavior - according to Section 5.4.1 of RFC 2181 [3], because the NS RRSet from - the target zone is more trustworthy than delegation information from - the parent zone. If, while processing a subsequent recursive query, - the iterative resolver discovers that none of the name servers - - - -Larson & Barber Best Current Practice [Page 4] - -RFC 4697 Observed DNS Resolution Misbehavior October 2006 - - - specified in the cached NS RRSet is available or authoritative, - querying the parent would be wrong. An NS RRSet from the parent zone - would now be less trustworthy than data already in the cache. - - For this query of the parent zone to be useful, the target zone's - entire set of name servers would have to change AND the former set of - name servers would have to be deconfigured or decommissioned AND the - delegation information in the parent zone would have to be updated - with the new set of name servers, all within the Time to Live (TTL) - of the target zone's NS RRSet. We believe this scenario is uncommon: - administrative best practices dictate that changes to a zone's set of - name servers happen gradually when at all possible, with servers - removed from the NS RRSet left authoritative for the zone as long as - possible. The scenarios that we can envision that would benefit from - the parent requery behavior do not outweigh its damaging effects. - - This section should not be understood to claim that all queries to a - zone's parent are bad. In some cases, such queries are not only - reasonable but required. Consider the situation when required - information, such as the address of a name server (i.e., the address - record corresponding to the RDATA of an NS record), has timed out of - an iterative resolver's cache before the corresponding NS record. If - the name of the name server is below the apex of the zone, then the - name server's address record is only available as glue in the parent - zone. For example, consider this NS record: - - example.com. IN NS ns.example.com. - - If a cache has this NS record but not the address record for - "ns.example.com", it is unable to contact the "example.com" zone - directly and must query the "com" zone to obtain the address record. - Note, however, that such a query would not have QTYPE=NS according to - the standard resolution algorithm. - -2.1.1. Recommendation - - An iterative resolver MUST NOT send a query for the NS RRSet of a - non-responsive zone to any of the name servers for that zone's parent - zone. For the purposes of this injunction, a non-responsive zone is - defined as a zone for which every name server listed in the zone's NS - RRSet: - - 1. is not authoritative for the zone (i.e., lame), or - - 2. returns a server failure response (RCODE=2), or - - 3. is dead or unreachable according to Section 7.2 of RFC 2308 [4]. - - - - -Larson & Barber Best Current Practice [Page 5] - -RFC 4697 Observed DNS Resolution Misbehavior October 2006 - - -2.2. Repeated Queries to Lame Servers - - Section 2.1 describes a catastrophic failure: when every name server - for a zone is unable to provide an answer for one reason or another. - A more common occurrence is when a subset of a zone's name servers is - unavailable or misconfigured. Different failure modes have different - expected durations. Some symptoms indicate problems that are - potentially transient, for example, various types of ICMP unreachable - messages because a name server process is not running or a host or - network is unreachable, or a complete lack of a response to a query. - Such responses could be the result of a host rebooting or temporary - outages; these events do not necessarily require any human - intervention and can be reasonably expected to be temporary. - - Other symptoms clearly indicate a condition requiring human - intervention, such as lame server: if a name server is misconfigured - and not authoritative for a zone delegated to it, it is reasonable to - assume that this condition has potential to last longer than - unreachability or unresponsiveness. Consequently, repeated queries - to known lame servers are not useful. In this case of a condition - with potential to persist for a long time, a better practice would be - to maintain a list of known lame servers and avoid querying them - repeatedly in a short interval. - - It should also be noted, however, that some authoritative name server - implementations appear to be lame only for queries of certain types - as described in RFC 4074 [5]. In this case, it makes sense to retry - the "lame" servers for other types of queries, particularly when all - known authoritative name servers appear to be "lame". - -2.2.1. Recommendation - - Iterative resolvers SHOULD cache name servers that they discover are - not authoritative for zones delegated to them (i.e., lame servers). - If this caching is performed, lame servers MUST be cached against the - specific query tuple . Zone - name can be derived from the owner name of the NS record that was - referenced to query the name server that was discovered to be lame. - - Implementations that perform lame server caching MUST refrain from - sending queries to known lame servers for a configurable time - interval after the server is discovered to be lame. A minimum - interval of thirty minutes is RECOMMENDED. - - - - - - - - -Larson & Barber Best Current Practice [Page 6] - -RFC 4697 Observed DNS Resolution Misbehavior October 2006 - - - An exception to this recommendation occurs if all name servers for a - zone are marked lame. In that case, the iterative resolver SHOULD - temporarily ignore the servers' lameness status and query one or more - servers. This behavior is a workaround for the type-specific - lameness issue described in the previous section. - - Implementors should take care not to make lame server avoidance logic - overly broad: note that a name server could be lame for a parent zone - but not a child zone, e.g., lame for "example.com" but properly - authoritative for "sub.example.com". Therefore, a name server should - not be automatically considered lame for subzones. In the case - above, even if a name server is known to be lame for "example.com", - it should be queried for QNAMEs at or below "sub.example.com" if an - NS record indicates that it should be authoritative for that zone. - -2.3. Inability to Follow Multiple Levels of Indirection - - Some iterative resolver implementations are unable to follow - sufficient levels of indirection. For example, consider the - following delegations: - - foo.example. IN NS ns1.example.com. - foo.example. IN NS ns2.example.com. - - example.com. IN NS ns1.test.example.net. - example.com. IN NS ns2.test.example.net. - - test.example.net. IN NS ns1.test.example.net. - test.example.net. IN NS ns2.test.example.net. - - An iterative resolver resolving the name "www.foo.example" must - follow two levels of indirection, first obtaining address records for - "ns1.test.example.net" or "ns2.test.example.net" in order to obtain - address records for "ns1.example.com" or "ns2.example.com" in order - to query those name servers for the address records of - "www.foo.example". Although this situation may appear contrived, we - have seen multiple similar occurrences and expect more as new generic - top-level domains (gTLDs) become active. We anticipate many zones in - new gTLDs will use name servers in existing gTLDs, increasing the - number of delegations using out-of-zone name servers. - -2.3.1. Recommendation - - Clearly constructing a delegation that relies on multiple levels of - indirection is not a good administrative practice. However, the - practice is widespread enough to require that iterative resolvers be - able to cope with it. Iterative resolvers SHOULD be able to handle - arbitrary levels of indirection resulting from out-of-zone name - - - -Larson & Barber Best Current Practice [Page 7] - -RFC 4697 Observed DNS Resolution Misbehavior October 2006 - - - servers. Iterative resolvers SHOULD implement a level-of-effort - counter to avoid loops or otherwise performing too much work in - resolving pathological cases. - - A best practice that avoids this entire issue of indirection is to - name one or more of a zone's name servers in the zone itself. For - example, if the zone is named "example.com", consider naming some of - the name servers "ns{1,2,...}.example.com" (or similar). - -2.4. Aggressive Retransmission when Fetching Glue - - When an authoritative name server responds with a referral, it - includes NS records in the authority section of the response. - According to the algorithm in Section 4.3.2 of RFC 1034 [2], the name - server should also "put whatever addresses are available into the - additional section, using glue RRs if the addresses are not available - from authoritative data or the cache." Some name server - implementations take this address inclusion a step further with a - feature called "glue fetching". A name server that implements glue - fetching attempts to include address records for every NS record in - the authority section. If necessary, the name server issues multiple - queries of its own to obtain any missing address records. - - Problems with glue fetching can arise in the context of - "authoritative-only" name servers, which only serve authoritative - data and ignore requests for recursion. Such an entity will not - normally generate any queries of its own. Instead it answers non- - recursive queries from iterative resolvers looking for information in - zones it serves. With glue fetching enabled, however, an - authoritative server invokes an iterative resolver to look up an - unknown address record to complete the additional section of a - response. - - We have observed situations where the iterative resolver of a glue- - fetching name server can send queries that reach other name servers, - but is apparently prevented from receiving the responses. For - example, perhaps the name server is authoritative-only and therefore - its administrators expect it to receive only queries and not - responses. Perhaps unaware of glue fetching and presuming that the - name server's iterative resolver will generate no queries, its - administrators place the name server behind a network device that - prevents it from receiving responses. If this is the case, all - glue-fetching queries will go unanswered. - - We have observed name server implementations whose iterative - resolvers retry excessively when glue-fetching queries are - unanswered. A single com/net name server has received hundreds of - queries per second from a single such source. Judging from the - - - -Larson & Barber Best Current Practice [Page 8] - -RFC 4697 Observed DNS Resolution Misbehavior October 2006 - - - specific queries received and based on additional analysis, we - believe these queries result from overly aggressive glue fetching. - -2.4.1. Recommendation - - Implementers whose name servers support glue fetching SHOULD take - care to avoid sending queries at excessive rates. Implementations - SHOULD support throttling logic to detect when queries are sent but - no responses are received. - -2.5. Aggressive Retransmission behind Firewalls - - A common occurrence and one of the largest sources of repeated - queries at the com/net and root name servers appears to result from - resolvers behind misconfigured firewalls. In this situation, an - iterative resolver is apparently allowed to send queries through a - firewall to other name servers, but not receive the responses. The - result is more queries than necessary because of retransmission, all - of which are useless because the responses are never received. Just - as with the glue-fetching scenario described in Section 2.4, the - queries are sometimes sent at excessive rates. To make matters - worse, sometimes the responses, sent in reply to legitimate queries, - trigger an alarm on the originator's intrusion detection system. We - are frequently contacted by administrators responding to such alarms - who believe our name servers are attacking their systems. - - Not only do some resolvers in this situation retransmit queries at an - excessive rate, but they continue to do so for days or even weeks. - This scenario could result from an organization with multiple - recursive name servers, only a subset of whose iterative resolvers' - traffic is improperly filtered in this manner. Stub resolvers in the - organization could be configured to query multiple recursive name - servers. Consider the case where a stub resolver queries a filtered - recursive name server first. The iterative resolver of this - recursive name server sends one or more queries whose replies are - filtered, so it cannot respond to the stub resolver, which times out. - Then the stub resolver retransmits to a recursive name server that is - able to provide an answer. Since resolution ultimately succeeds the - underlying problem might not be recognized or corrected. A popular - stub resolver implementation has a very aggressive retransmission - schedule, including simultaneous queries to multiple recursive name - servers, which could explain how such a situation could persist - without being detected. - - - - - - - - -Larson & Barber Best Current Practice [Page 9] - -RFC 4697 Observed DNS Resolution Misbehavior October 2006 - - -2.5.1. Recommendation - - The most obvious recommendation is that administrators SHOULD take - care not to place iterative resolvers behind a firewall that allows - queries, but not the resulting replies, to pass through. - - Iterative resolvers SHOULD take care to avoid sending queries at - excessive rates. Implementations SHOULD support throttling logic to - detect when queries are sent but no responses are received. - -2.6. Misconfigured NS Records - - Sometimes a zone administrator forgets to add the trailing dot on the - domain names in the RDATA of a zone's NS records. Consider this - fragment of the zone file for "example.com": - - $ORIGIN example.com. - example.com. 3600 IN NS ns1.example.com ; Note missing - example.com. 3600 IN NS ns2.example.com ; trailing dots - - The zone's authoritative servers will parse the NS RDATA as - "ns1.example.com.example.com" and "ns2.example.com.example.com" and - return NS records with this incorrect RDATA in responses, including - typically the authority section of every response containing records - from the "example.com" zone. - - Now consider a typical sequence of queries. An iterative resolver - attempting to resolve address records for "www.example.com" with no - cached information for this zone will query a "com" authoritative - server. The "com" server responds with a referral to the - "example.com" zone, consisting of NS records with valid RDATA and - associated glue records. (This example assumes that the - "example.com" zone delegation information is correct in the "com" - zone.) The iterative resolver caches the NS RRSet from the "com" - server and follows the referral by querying one of the "example.com" - authoritative servers. This server responds with the - "www.example.com" address record in the answer section and, - typically, the "example.com" NS records in the authority section and, - if space in the message remains, glue address records in the - additional section. According to Section 5.4.1 of RFC 2181 [3], NS - records in the authority section of an authoritative answer are more - trustworthy than NS records from the authority section of a non- - authoritative answer. Thus, the "example.com" NS RRSet just received - from the "example.com" authoritative server overrides the - "example.com" NS RRSet received moments ago from the "com" - authoritative server. - - - - - -Larson & Barber Best Current Practice [Page 10] - -RFC 4697 Observed DNS Resolution Misbehavior October 2006 - - - But the "example.com" zone contains the erroneous NS RRSet as shown - in the example above. Subsequent queries for names in "example.com" - will cause the iterative resolver to attempt to use the incorrect NS - records and so it will try to resolve the nonexistent names - "ns1.example.com.example.com" and "ns2.example.com.example.com". In - this example, since all of the zone's name servers are named in the - zone itself (i.e., "ns1.example.com.example.com" and - "ns2.example.com.example.com" both end in "example.com") and all are - bogus, the iterative resolver cannot reach any "example.com" name - servers. Therefore, attempts to resolve these names result in - address record queries to the "com" authoritative servers. Queries - for such obviously bogus glue address records occur frequently at the - com/net name servers. - -2.6.1. Recommendation - - An authoritative server can detect this situation. A trailing dot - missing from an NS record's RDATA always results by definition in a - name server name that exists somewhere under the apex of the zone - that the NS record appears in. Note that further levels of - delegation are possible, so a missing trailing dot could - inadvertently create a name server name that actually exists in a - subzone. - - An authoritative name server SHOULD issue a warning when one of a - zone's NS records references a name server below the zone's apex when - a corresponding address record does not exist in the zone AND there - are no delegated subzones where the address record could exist. - -2.7. Name Server Records with Zero TTL - - Sometimes a popular com/net subdomain's zone is configured with a TTL - of zero on the zone's NS records, which prohibits these records from - being cached and will result in a higher query volume to the zone's - authoritative servers. The zone's administrator should understand - the consequences of such a configuration and provision resources - accordingly. A zero TTL on the zone's NS RRSet, however, carries - additional consequences beyond the zone itself: if an iterative - resolver cannot cache a zone's NS records because of a zero TTL, it - will be forced to query that zone's parent's name servers each time - it resolves a name in the zone. The com/net authoritative servers do - see an increased query load when a popular com/net subdomain's zone - is configured with a TTL of zero on the zone's NS records. - - A zero TTL on an RRSet expected to change frequently is extreme but - permissible. A zone's NS RRSet is a special case, however, because - changes to it must be coordinated with the zone's parent. In most - zone parent/child relationships that we are aware of, there is - - - -Larson & Barber Best Current Practice [Page 11] - -RFC 4697 Observed DNS Resolution Misbehavior October 2006 - - - typically some delay involved in effecting changes. Furthermore, - changes to the set of a zone's authoritative name servers (and - therefore to the zone's NS RRSet) are typically relatively rare: - providing reliable authoritative service requires a reasonably stable - set of servers. Therefore, an extremely low or zero TTL on a zone's - NS RRSet rarely makes sense, except in anticipation of an upcoming - change. In this case, when the zone's administrator has planned a - change and does not want iterative resolvers throughout the Internet - to cache the NS RRSet for a long period of time, a low TTL is - reasonable. - -2.7.1. Recommendation - - Because of the additional load placed on a zone's parent's - authoritative servers resulting from a zero TTL on a zone's NS RRSet, - under such circumstances authoritative name servers SHOULD issue a - warning when loading a zone. - -2.8. Unnecessary Dynamic Update Messages - - The UPDATE message specified in RFC 2136 [6] allows an authorized - agent to update a zone's data on an authoritative name server using a - DNS message sent over the network. Consider the case of an agent - desiring to add a particular resource record. Because of zone cuts, - the agent does not necessarily know the proper zone to which the - record should be added. The dynamic update process requires that the - agent determine the appropriate zone so the UPDATE message can be - sent to one of the zone's authoritative servers (typically the - primary master as specified in the zone's Start of Authority (SOA) - record's MNAME field). - - The appropriate zone to update is the closest enclosing zone, which - cannot be determined only by inspecting the domain name of the record - to be updated, since zone cuts can occur anywhere. One way to - determine the closest enclosing zone entails walking up the name - space tree by sending repeated UPDATE messages until successful. For - example, consider an agent attempting to add an address record with - the name "foo.bar.example.com". The agent could first attempt to - update the "foo.bar.example.com" zone. If the attempt failed, the - update could be directed to the "bar.example.com" zone, then the - "example.com" zone, then the "com" zone, and finally the root zone. - - A popular dynamic agent follows this algorithm. The result is many - UPDATE messages received by the root name servers, the com/net - authoritative servers, and presumably other TLD authoritative - servers. A valid question is why the algorithm proceeds to send - updates all the way to TLD and root name servers. This behavior is - not entirely unreasonable: in enterprise DNS architectures with an - - - -Larson & Barber Best Current Practice [Page 12] - -RFC 4697 Observed DNS Resolution Misbehavior October 2006 - - - "internal root" design, there could conceivably be private, non- - public TLD or root zones that would be the appropriate targets for a - dynamic update. - - A significant deficiency with this algorithm is that knowledge of a - given UPDATE message's failure is not helpful in directing future - UPDATE messages to the appropriate servers. A better algorithm would - be to find the closest enclosing zone by walking up the name space - with queries for SOA or NS rather than "probing" with UPDATE - messages. Once the appropriate zone is found, an UPDATE message can - be sent. In addition, the results of these queries can be cached to - aid in determining the closest enclosing zones for future updates. - Once the closest enclosing zone is determined with this method, the - update will either succeed or fail and there is no need to send - further updates to higher-level zones. The important point is that - walking up the tree with queries yields cacheable information, - whereas walking up the tree by sending UPDATE messages does not. - -2.8.1. Recommendation - - Dynamic update agents SHOULD send SOA or NS queries to progressively - higher-level names to find the closest enclosing zone for a given - name to update. Only after the appropriate zone is found should the - client send an UPDATE message to one of the zone's authoritative - servers. Update clients SHOULD NOT "probe" using UPDATE messages by - walking up the tree to progressively higher-level zones. - -2.9. Queries for Domain Names Resembling IPv4 Addresses - - The root name servers receive a significant number of A record - queries where the QNAME looks like an IPv4 address. The source of - these queries is unknown. It could be attributed to situations where - a user believes that an application will accept either a domain name - or an IP address in a given configuration option. The user enters an - IP address, but the application assumes that any input is a domain - name and attempts to resolve it, resulting in an A record lookup. - There could also be applications that produce such queries in a - misguided attempt to reverse map IP addresses. - - These queries result in Name Error (RCODE=3) responses. An iterative - resolver can negatively cache such responses, but each response - requires a separate cache entry; i.e., a negative cache entry for the - domain name "192.0.2.1" does not prevent a subsequent query for the - domain name "192.0.2.2". - - - - - - - -Larson & Barber Best Current Practice [Page 13] - -RFC 4697 Observed DNS Resolution Misbehavior October 2006 - - -2.9.1. Recommendation - - It would be desirable for the root name servers not to have to answer - these queries: they unnecessarily consume CPU resources and network - bandwidth. A possible solution is to delegate these numeric TLDs - from the root zone to a separate set of servers to absorb the - traffic. The "black hole servers" used by the AS 112 Project - (http://www.as112.net), which are currently delegated the - in-addr.arpa zones corresponding to RFC 1918 [7] private use address - space, would be a possible choice to receive these delegations. Of - course, the proper and usual root zone change procedures would have - to be followed to make such a change to the root zone. - -2.10. Misdirected Recursive Queries - - The root name servers receive a significant number of recursive - queries (i.e., queries with the Recursion Desired (RD) bit set in the - header). Since none of the root servers offers recursion, the - servers' response in such a situation ignores the request for - recursion and the response probably does not contain the data the - querier anticipated. Some of these queries result from users - configuring stub resolvers to query a root server. (This situation - is not hypothetical: we have received complaints from users when this - configuration does not work as hoped.) Of course, users should not - direct stub resolvers to use name servers that do not offer - recursion, but we are not aware of any stub resolver implementation - that offers any feedback to the user when so configured, aside from - simply "not working". - -2.10.1. Recommendation - - When the IP address of a name server that supposedly offers recursion - is configured in a stub resolver using an interactive user interface, - the resolver could send a test query to verify that the server indeed - supports recursion (i.e., verify that the response has the RA bit set - in the header). The user could be notified immediately if the server - is non-recursive. - - The stub resolver could also report an error, either through a user - interface or in a log file, if the queried server does not support - recursion. Error reporting SHOULD be throttled to avoid a - notification or log message for every response from a non-recursive - server. - - - - - - - - -Larson & Barber Best Current Practice [Page 14] - -RFC 4697 Observed DNS Resolution Misbehavior October 2006 - - -2.11. Suboptimal Name Server Selection Algorithm - - An entire document could be devoted to the topic of problems with - different implementations of the recursive resolution algorithm. The - entire process of recursion is woefully under-specified, requiring - each implementor to design an algorithm. Sometimes implementors make - poor design choices that could be avoided if a suggested algorithm - and best practices were documented, but that is a topic for another - document. - - Some deficiencies cause significant operational impact and are - therefore worth mentioning here. One of these is name server - selection by an iterative resolver. When an iterative resolver wants - to contact one of a zone's authoritative name servers, how does it - choose from the NS records listed in the zone's NS RRSet? If the - selection mechanism is suboptimal, queries are not spread evenly - among a zone's authoritative servers. The details of the selection - mechanism are up to the implementor, but we offer some suggestions. - -2.11.1. Recommendation - - This list is not conclusive, but reflects the changes that would - produce the most impact in terms of reducing disproportionate query - load among a zone's authoritative servers. That is, these changes - would help spread the query load evenly. - - o Do not make assumptions based on NS RRSet order: all NS RRs SHOULD - be treated equally. (In the case of the "com" zone, for example, - most of the root servers return the NS record for - "a.gtld-servers.net" first in the authority section of referrals. - Apparently as a result, this server receives disproportionately - more traffic than the other twelve authoritative servers for - "com".) - - o Use all NS records in an RRSet. (For example, we are aware of - implementations that hard-coded information for a subset of the - root servers.) - - o Maintain state and favor the best-performing of a zone's - authoritative servers. A good definition of performance is - response time. Non-responsive servers can be penalized with an - extremely high response time. - - o Do not lock onto the best-performing of a zone's name servers. An - iterative resolver SHOULD periodically check the performance of - all of a zone's name servers to adjust its determination of the - best-performing one. - - - - -Larson & Barber Best Current Practice [Page 15] - -RFC 4697 Observed DNS Resolution Misbehavior October 2006 - - -3. Security Considerations - - The iterative resolver misbehavior discussed in this document exposes - the root and TLD name servers to increased risk of both intentional - and unintentional Denial of Service attacks. - - We believe that implementation of the recommendations offered in this - document will reduce the amount of unnecessary traffic seen at root - and TLD name servers, thus reducing the opportunity for an attacker - to use such queries to his or her advantage. - -4. Acknowledgements - - The authors would like to thank the following people for their - comments that improved this document: Andras Salamon, Dave Meyer, - Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy, - Olafur Gudmundsson, Pekka Savola, Peter Koch, and Rob Austein. We - apologize if we have omitted anyone; any oversight was unintentional. - -5. Internationalization Considerations - - There are no new internationalization considerations introduced by - this memo. - -6. References - -6.1. Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - -6.2. Informative References - - [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification", - RFC 2181, July 1997. - - [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC - 2308, March 1998. - - [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS - Queries for IPv6 Addresses", RFC 4074, May 2005. - - [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April - 1997. - - - -Larson & Barber Best Current Practice [Page 16] - -RFC 4697 Observed DNS Resolution Misbehavior October 2006 - - - [7] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. - Lear, "Address Allocation for Private Internets", BCP 5, RFC - 1918, February 1996. - -Authors' Addresses - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Piet Barber - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: pbarber@verisign.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Best Current Practice [Page 17] - -RFC 4697 Observed DNS Resolution Misbehavior October 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Larson & Barber Best Current Practice [Page 18] - diff --git a/doc/rfc/rfc4955.txt b/doc/rfc/rfc4955.txt deleted file mode 100644 index 2d2eb84e0fb..00000000000 --- a/doc/rfc/rfc4955.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group D. Blacka -Request for Comments: 4955 VeriSign, Inc. -Category: Standards Track July 2007 - - - DNS Security (DNSSEC) Experiments - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - -Abstract - - This document describes a methodology for deploying alternate, non- - backwards-compatible, DNS Security (DNSSEC) methodologies in an - experimental fashion without disrupting the deployment of standard - DNSSEC. - -Table of Contents - - 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Definitions and Terminology . . . . . . . . . . . . . . . . . . 2 - 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 4 - 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 5 - 7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 5 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 - - - - - - - - - - - - -Blacka Standards Track [Page 1] - -RFC 4955 DNS Security (DNSSEC) Experiments July 2007 - - -1. Overview - - Historically, experimentation with DNSSEC alternatives has been a - problematic endeavor. There has typically been a desire to both - introduce non-backwards-compatible changes to DNSSEC and to try these - changes on real zones in the public DNS. This creates a problem when - the change to DNSSEC would make all or part of the zone using those - changes appear bogus (bad) or otherwise broken to existing security- - aware resolvers. - - This document describes a standard methodology for setting up DNSSEC - experiments. This methodology addresses the issue of coexistence - with standard DNSSEC and DNS by using unknown algorithm identifiers - to hide the experimental DNSSEC protocol modifications from standard - security-aware resolvers. - -2. Definitions and Terminology - - Throughout this document, familiarity with the DNS system (RFC 1035 - [5]) and the DNS security extensions (RFC 4033 [2], RFC 4034 [3], and - RFC 4035 [4]) is assumed. - - 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 [1]. - -3. Experiments - - When discussing DNSSEC experiments, it is necessary to classify these - experiments into two broad categories: - - Backwards-Compatible: describes experimental changes that, while not - strictly adhering to the DNSSEC standard, are nonetheless - interoperable with clients and servers that do implement the - DNSSEC standard. - - Non-Backwards-Compatible: describes experiments that would cause a - standard security-aware resolver to (incorrectly) determine that - all or part of a zone is bogus, or to otherwise not interoperate - with standard DNSSEC clients and servers. - - Not included in these terms are experiments with the core DNS - protocol itself. - - The methodology described in this document is not necessary for - backwards-compatible experiments, although it certainly may be used - if desired. - - - - -Blacka Standards Track [Page 2] - -RFC 4955 DNS Security (DNSSEC) Experiments July 2007 - - -4. Method - - The core of the methodology is the use of strictly unknown algorithm - identifiers when signing the experimental zone, and more importantly, - having only unknown algorithm identifiers in the DS records for the - delegation to the zone at the parent. - - This technique works because of the way DNSSEC-compliant validators - are expected to work in the presence of a DS set with only unknown - algorithm identifiers. From RFC 4035 [4], Section 5.2: - - If the validator does not support any of the algorithms listed in - an authenticated DS RRset, then the resolver has no supported - authentication path leading from the parent to the child. The - resolver should treat this case as it would the case of an - authenticated NSEC RRset proving that no DS RRset exists, as - described above. - - And further: - - If the resolver does not support any of the algorithms listed in - an authenticated DS RRset, then the resolver will not be able to - verify the authentication path to the child zone. In this case, - the resolver SHOULD treat the child zone as if it were unsigned. - - Although this behavior isn't strictly mandatory (as marked by MUST), - it is unlikely for a validator to implement a substantially different - behavior. Essentially, if the validator does not have a usable chain - of trust to a child zone, then it can only do one of two things: - treat responses from the zone as insecure (the recommended behavior), - or treat the responses as bogus. If the validator chooses the - latter, this will both violate the expectation of the zone owner and - defeat the purpose of the above rule. However, with local policy, it - is within the right of a validator to refuse to trust certain zones - based on any criteria, including the use of unknown signing - algorithms. - - Because we are talking about experiments, it is RECOMMENDED that - private algorithm numbers be used (see RFC 4034 [3], Appendix A.1.1. - Note that secure handling of private algorithms requires special - handing by the validator logic. See "Clarifications and - Implementation Notes for DNSSECbis" [6] for further details.) - Normally, instead of actually inventing new signing algorithms, the - recommended path is to create alternate algorithm identifiers that - are aliases for the existing, known algorithms. While, strictly - speaking, it is only necessary to create an alternate identifier for - the mandatory algorithms, it is suggested that all optional defined - algorithms be aliased as well. - - - -Blacka Standards Track [Page 3] - -RFC 4955 DNS Security (DNSSEC) Experiments July 2007 - - - It is RECOMMENDED that for a particular DNSSEC experiment, a - particular domain name base is chosen for all new algorithms, then - the algorithm number (or name) is prepended to it. For example, for - experiment A, the base name of "dnssec-experiment-a.example.com" is - chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are - defined to be "3.dnssec-experiment-a.example.com" and - "5.dnssec-experiment-a.example.com". However, any unique identifier - will suffice. - - Using this method, resolvers (or, more specifically, DNSSEC - validators) essentially indicate their ability to understand the - DNSSEC experiment's semantics by understanding what the new algorithm - identifiers signify. - - This method creates two classes of security-aware servers and - resolvers: servers and resolvers that are aware of the experiment - (and thus recognize the experiment's algorithm identifiers and - experimental semantics), and servers and resolvers that are unaware - of the experiment. - - This method also precludes any zone from being both in an experiment - and in a classic DNSSEC island of security. That is, a zone is - either in an experiment and only possible to validate experimentally, - or it is not. - -5. Defining an Experiment - - The DNSSEC experiment MUST define the particular set of (previously - unknown) algorithm identifiers that identify the experiment and - define what each unknown algorithm identifier means. Typically, - unless the experiment is actually experimenting with a new DNSSEC - algorithm, this will be a mapping of private algorithm identifiers to - existing, known algorithms. - - Normally the experiment will choose a DNS name as the algorithm - identifier base. This DNS name SHOULD be under the control of the - authors of the experiment. Then the experiment will define a mapping - between known mandatory and optional algorithms into this private - algorithm identifier space. Alternately, the experiment MAY use the - Object Identifier (OID) private algorithm space instead (using - algorithm number 254), or MAY choose non-private algorithm numbers, - although this would require an IANA allocation. - - For example, an experiment might specify in its description the DNS - name "dnssec-experiment-a.example.com" as the base name, and declare - that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC - algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an - alias of DNSSEC algorithm 5 (RSASHA1). - - - -Blacka Standards Track [Page 4] - -RFC 4955 DNS Security (DNSSEC) Experiments July 2007 - - - Resolvers MUST only recognize the experiment's semantics when present - in a zone signed by one or more of these algorithm identifiers. This - is necessary to isolate the semantics of one experiment from any - others that the resolver might understand. - - In general, resolvers involved in the experiment are expected to - understand both standard DNSSEC and the defined experimental DNSSEC - protocol, although this isn't required. - -6. Considerations - - There are a number of considerations with using this methodology. - - 1. If an unaware validator does not correctly follow the rules laid - out in RFC 4035 (e.g., the validator interprets a DNSSEC record - prior to validating it), or if the experiment is broader in scope - that just modifying the DNSSEC semantics, the experiment may not - be sufficiently masked by this technique. This may cause - unintended resolution failures. - - 2. It will not be possible for security-aware resolvers unaware of - the experiment to build a chain of trust through an experimental - zone. - -7. Use in Non-Experiments - - This general methodology MAY be used for non-backwards compatible - DNSSEC protocol changes that start out as or become standards. In - this case: - - o The protocol change SHOULD use public IANA allocated algorithm - identifiers instead of private algorithm identifiers. This will - help identify the protocol change as a standard, rather than an - experiment. - - o Resolvers MAY recognize the protocol change in zones not signed - (or not solely signed) using the new algorithm identifiers. - -8. Security Considerations - - Zones using this methodology will be considered insecure by all - resolvers except those aware of the experiment. It is not generally - possible to create a secure delegation from an experimental zone that - will be followed by resolvers unaware of the experiment. - - Implementers should take into account any security issues that may - result from environments being configured to trust both experimental - and non-experimental zones. If the experimental zone is more - - - -Blacka Standards Track [Page 5] - -RFC 4955 DNS Security (DNSSEC) Experiments July 2007 - - - vulnerable to attacks, it could, for example, be used to promote - trust in zones not part of the experiment, possibly under the control - of an attacker. - -9. References - -9.1. Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - RFC 4035, March 2005. - -9.2. Informative References - - [5] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [6] Weiler, S. and R. Austein, "Clarifications and Implementation - Notes for DNSSECbis", Work in Progress, March 2007. - -Author's Address - - David Blacka - VeriSign, Inc. - 21355 Ridgetop Circle - Dulles, VA 20166 - US - - Phone: +1 703 948 3200 - EMail: davidb@verisign.com - URI: http://www.verisignlabs.com - - - - - - - - - -Blacka Standards Track [Page 6] - -RFC 4955 DNS Security (DNSSEC) Experiments July 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Blacka Standards Track [Page 7] - diff --git a/doc/rfc/rfc4956.txt b/doc/rfc/rfc4956.txt deleted file mode 100644 index 536c680cbaf..00000000000 --- a/doc/rfc/rfc4956.txt +++ /dev/null @@ -1,955 +0,0 @@ - - - - - - -Network Working Group R. Arends -Request for Comments: 4956 Nominet -Category: Experimental M. Kosters - D. Blacka - VeriSign, Inc. - July 2007 - - - DNS Security (DNSSEC) Opt-In - -Status of This Memo - - This memo defines an Experimental Protocol for the Internet - community. It does not specify an Internet standard of any kind. - Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - -Abstract - - In the DNS security (DNSSEC) extensions, delegations to unsigned - subzones are cryptographically secured. Maintaining this - cryptography is not always practical or necessary. This document - describes an experimental "Opt-In" model that allows administrators - to omit this cryptography and manage the cost of adopting DNSSEC with - large zones. - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Experimental [Page 1] - -RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 - - -Table of Contents - - 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 - 3. Experimental Status . . . . . . . . . . . . . . . . . . . . . 4 - 4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 5 - 4.1. Server Considerations . . . . . . . . . . . . . . . . . . 6 - 4.1.1. Delegations Only . . . . . . . . . . . . . . . . . . . 6 - 4.1.2. Insecure Delegation Responses . . . . . . . . . . . . 6 - 4.1.3. Dynamic Update . . . . . . . . . . . . . . . . . . . . 6 - 4.2. Client Considerations . . . . . . . . . . . . . . . . . . 7 - 4.2.1. Delegations Only . . . . . . . . . . . . . . . . . . . 7 - 4.2.2. Validation Process Changes . . . . . . . . . . . . . . 7 - 4.2.3. NSEC Record Caching . . . . . . . . . . . . . . . . . 8 - 4.2.4. Use of the AD bit . . . . . . . . . . . . . . . . . . 8 - 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 11 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Appendix A. Implementing Opt-In Using "Views" . . . . . . . . . . 15 - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Experimental [Page 2] - -RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 - - -1. Overview - - The cost to cryptographically secure delegations to unsigned zones is - high for large delegation-centric zones and zones where insecure - delegations will be updated rapidly. For these zones, the costs of - maintaining the NextSECure (NSEC) record chain may be extremely high - relative to the gain of cryptographically authenticating existence of - unsecured zones. - - This document describes an experimental method of eliminating the - superfluous cryptography present in secure delegations to unsigned - zones. Using "Opt-In", a zone administrator can choose to remove - insecure delegations from the NSEC chain. This is accomplished by - extending the semantics of the NSEC record by using a redundant bit - in the type map. - -2. Definitions and Terminology - - Throughout this document, familiarity with the DNS system (RFC 1035 - [1]), DNS security extensions ([4], [5], and [6], referred to in this - document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090 - [10]) is assumed. - - The following abbreviations and terms are used in this document: - - RR: is used to refer to a DNS resource record. - - RRset: refers to a Resource Record Set, as defined by [8]. In this - document, the RRset is also defined to include the covering RRSIG - records, if any exist. - - signed name: refers to a DNS name that has, at minimum, a (signed) - NSEC record. - - unsigned name: refers to a DNS name that does not (at least) have an - NSEC record. - - covering NSEC record/RRset: is the NSEC record used to prove - (non)existence of a particular name or RRset. This means that for - a RRset or name 'N', the covering NSEC record has the name 'N', or - has an owner name less than 'N' and "next" name greater than 'N'. - - delegation: refers to an NS RRset with a name different from the - current zone apex (non-zone-apex), signifying a delegation to a - subzone. - - - - - - -Arends, et al. Experimental [Page 3] - -RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 - - - secure delegation: refers to a signed name containing a delegation - (NS RRset), and a signed DS RRset, signifying a delegation to a - signed subzone. - - insecure delegation: refers to a signed name containing a delegation - (NS RRset), but lacking a DS RRset, signifying a delegation to an - unsigned subzone. - - Opt-In insecure delegation: refers to an unsigned name containing - only a delegation NS RRset. The covering NSEC record uses the - Opt-In methodology described 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 RFC 2119 [2]. - -3. Experimental Status - - This document describes an EXPERIMENTAL extension to DNSSEC. It - interoperates with non-experimental DNSSEC using the technique - described in [7]. This experiment is identified with the following - private algorithms (using algorithm 253): - - "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA, - and - - "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5, - RSASHA1. - - Servers wishing to sign and serve zones that utilize Opt-In MUST sign - the zone with only one or more of these private algorithms and MUST - NOT use any other algorithms. - - Resolvers MUST NOT apply the Opt-In validation rules described in - this document unless a zone is signed using one or more of these - private algorithms. - - This experimental protocol relaxes the restriction that validators - MUST ignore the setting of the NSEC bit in the type map as specified - in RFC 4035 [6] Section 5.4. - - The remainder of this document assumes that the servers and resolvers - involved are aware of and are involved in this experiment. - - - - - - - - -Arends, et al. Experimental [Page 4] - -RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 - - -4. Protocol Additions - - In DNSSEC, delegation NS RRsets are not signed, but are instead - accompanied by an NSEC RRset of the same name and (possibly) a DS - record. The security status of the subzone is determined by the - presence or absence of the DS RRset, cryptographically proven by the - NSEC record. Opt-In expands this definition by allowing insecure - delegations to exist within an otherwise signed zone without the - corresponding NSEC record at the delegation's owner name. These - insecure delegations are proven insecure by using a covering NSEC - record. - - Since this represents a change of the interpretation of NSEC records, - resolvers must be able to distinguish between RFC standard DNSSEC - NSEC records and Opt-In NSEC records. This is accomplished by - "tagging" the NSEC records that cover (or potentially cover) insecure - delegation nodes. This tag is indicated by the absence of the NSEC - bit in the type map. Since the NSEC bit in the type map merely - indicates the existence of the record itself, this bit is redundant - and safe for use as a tag. - - An Opt-In tagged NSEC record does not assert the (non)existence of - the delegations that it covers (except for a delegation with the same - name). This allows for the addition or removal of these delegations - without recalculating or resigning records in the NSEC chain. - However, Opt-In tagged NSEC records do assert the (non)existence of - other RRsets. - - An Opt-In NSEC record MAY have the same name as an insecure - delegation. In this case, the delegation is proven insecure by the - lack of a DS bit in the type map, and the signed NSEC record does - assert the existence of the delegation. - - Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC - records and standard DNSSEC NSEC records. If an NSEC record is not - Opt-In, there MUST NOT be any insecure delegations (or any other - records) between it and the RRsets indicated by the 'next domain - name' in the NSEC RDATA. If it is Opt-In, there MUST only be - insecure delegations between it and the next node indicated by the - 'next domain name' in the NSEC RDATA. - - In summary, - - o An Opt-In NSEC type is identified by a zero-valued (or not- - specified) NSEC bit in the type bit map of the NSEC record. - - - - - - -Arends, et al. Experimental [Page 5] - -RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 - - - o A standard DNSSEC NSEC type is identified by a one-valued NSEC bit - in the type bit map of the NSEC record. - - and - - o An Opt-In NSEC record does not assert the non-existence of a name - between its owner name and "next" name, although it does assert - that any name in this span MUST be an insecure delegation. - - o An Opt-In NSEC record does assert the (non)existence of RRsets - with the same owner name. - -4.1. Server Considerations - - Opt-In imposes some new requirements on authoritative DNS servers. - -4.1.1. Delegations Only - - This specification dictates that only insecure delegations may exist - between the owner and "next" names of an Opt-In tagged NSEC record. - Signing tools MUST NOT generate signed zones that violate this - restriction. Servers MUST refuse to load and/or serve zones that - violate this restriction. Servers also MUST reject AXFR or IXFR - responses that violate this restriction. - -4.1.2. Insecure Delegation Responses - - When returning an Opt-In insecure delegation, the server MUST return - the covering NSEC RRset in the Authority section. - - In standard DNSSEC, NSEC records already must be returned along with - the insecure delegation. The primary difference that this proposal - introduces is that the Opt-In tagged NSEC record will have a - different owner name from the delegation RRset. This may require - implementations to search for the covering NSEC RRset. - -4.1.3. Dynamic Update - - Opt-In changes the semantics of Secure DNS Dynamic Update [9]. In - particular, it introduces the need for rules that describe when to - add or remove a delegation name from the NSEC chain. This document - does not attempt to define these rules. Until these rules are - defined, servers MUST NOT process DNS Dynamic Update requests against - zones that use Opt-In NSEC records. Servers SHOULD return responses - to update requests with RCODE=REFUSED. - - - - - - -Arends, et al. Experimental [Page 6] - -RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 - - -4.2. Client Considerations - - Opt-In imposes some new requirements on security-aware resolvers - (caching or otherwise). - -4.2.1. Delegations Only - - As stated in Section 4.1 above, this specification restricts the - namespace covered by Opt-In tagged NSEC records to insecure - delegations only. Clients are not expected to take any special - measures to enforce this restriction; instead, it forms an underlying - assumption that clients may rely on. - -4.2.2. Validation Process Changes - - This specification does not change the resolver's resolution - algorithm. However, it does change the DNSSEC validation process. - -4.2.2.1. Referrals - - Resolvers MUST be able to use Opt-In tagged NSEC records to - cryptographically prove the validity and security status (as - insecure) of a referral. Resolvers determine the security status of - the referred-to zone as follows: - - o In standard DNSSEC, the security status is proven by the existence - or absence of a DS RRset at the same name as the delegation. The - existence of the DS RRset indicates that the referred-to zone is - signed. The absence of the DS RRset is proven using a verified - NSEC record of the same name that does not have the DS bit set in - the type map. This NSEC record MAY also be tagged as Opt-In. - - o Using Opt-In, the security status is proven by the existence of a - DS record (for signed) or the presence of a verified Opt-In tagged - NSEC record that covers the delegation name. That is, the NSEC - record does not have the NSEC bit set in the type map, and the - delegation name falls between the NSEC's owner and "next" name. - - Using Opt-In does not substantially change the nature of following - referrals within DNSSEC. At every delegation point, the resolver - will have cryptographic proof that the referred-to subzone is signed - or unsigned. - -4.2.2.2. Queries for DS Resource Records - - Since queries for DS records are directed to the parent side of a - zone cut (see [5], Section 5), negative responses to these queries - may be covered by an Opt-In flagged NSEC record. - - - -Arends, et al. Experimental [Page 7] - -RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 - - - Resolvers MUST be able to use Opt-In tagged NSEC records to - cryptographically prove the validity and security status of negative - responses to queries for DS records. In particular, a NOERROR/NODATA - (i.e., RCODE=3, but the answer section is empty) response to a DS - query may be proven by an Opt-In flagged covering NSEC record, rather - than an NSEC record matching the query name. - -4.2.3. NSEC Record Caching - - Caching resolvers MUST be able to retrieve the appropriate covering - Opt-In NSEC record when returning referrals that need them. This - requirement differs from standard DNSSEC in that the covering NSEC - will not have the same owner name as the delegation. Some - implementations may have to use new methods for finding these NSEC - records. - -4.2.4. Use of the AD bit - - The AD bit, as defined by [3] and [6], MUST NOT be set when: - - o sending a Name Error (RCODE=3) response where the covering NSEC is - tagged as Opt-In. - - o sending an Opt-In insecure delegation response, unless the - covering (Opt-In) NSEC record's owner name equals the delegation - name. - - o sending a NOERROR/NODATA response when query type is DS and the - covering NSEC is tagged as Opt-In, unless NSEC record's owner name - matches the query name. - - This rule is based on what the Opt-In NSEC record actually proves: - for names that exist between the Opt-In NSEC record's owner and - "next" names, the Opt-In NSEC record cannot prove the non-existence - or existence of the name. As such, not all data in the response has - been cryptographically verified, so the AD bit cannot be set. - -5. Benefits - - Using Opt-In allows administrators of large and/or changing - delegation-centric zones to minimize the overhead involved in - maintaining the security of the zone. - - Opt-In accomplishes this by eliminating the need for NSEC records for - insecure delegations. This, in a zone with a large number of - delegations to unsigned subzones, can lead to substantial space - savings (both in memory and on disk). Additionally, Opt-In allows - for the addition or removal of insecure delegations without modifying - - - -Arends, et al. Experimental [Page 8] - -RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 - - - the NSEC record chain. Zones that are frequently updating insecure - delegations (e.g., Top-Level Domains (TLDs)) can avoid the - substantial overhead of modifying and resigning the affected NSEC - records. - -6. Example - - Consider the zone EXAMPLE shown below. This is a zone where all of - the NSEC records are tagged as Opt-In. - - Example A: Fully Opt-In Zone. - - EXAMPLE. SOA ... - EXAMPLE. RRSIG SOA ... - EXAMPLE. NS FIRST-SECURE.EXAMPLE. - EXAMPLE. RRSIG NS ... - EXAMPLE. DNSKEY ... - EXAMPLE. RRSIG DNSKEY ... - EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. ( - SOA NS RRSIG DNSKEY ) - EXAMPLE. RRSIG NSEC ... - - FIRST-SECURE.EXAMPLE. A ... - FIRST-SECURE.EXAMPLE. RRSIG A ... - FIRST-SECURE.EXAMPLE. NSEC NOT-SECURE-2.EXAMPLE. A RRSIG - FIRST-SECURE.EXAMPLE. RRSIG NSEC ... - - NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. - NS.NOT-SECURE.EXAMPLE. A ... - - NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. - NOT-SECURE-2.EXAMPLE NSEC SECOND-SECURE.EXAMPLE NS RRSIG - NOT-SECURE-2.EXAMPLE RRSIG NSEC ... - - SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE. - SECOND-SECURE.EXAMPLE. DS ... - SECOND-SECURE.EXAMPLE. RRSIG DS ... - SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DNSKEY - SECOND-SECURE.EXAMPLE. RRSIG NSEC ... - - UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE. - NS.UNSIGNED.EXAMPLE. A ... - - - Example A. - - - - - - -Arends, et al. Experimental [Page 9] - -RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 - - - In this example, a query for a signed RRset (e.g., "FIRST- - SECURE.EXAMPLE A") or a secure delegation ("WWW.SECOND-SECURE.EXAMPLE - A") will result in a standard DNSSEC response. - - A query for a nonexistent RRset will result in a response that - differs from standard DNSSEC by the following: the NSEC record will - be tagged as Opt-In, there may be no NSEC record proving the non- - existence of a matching wildcard record, and the AD bit will not be - set. - - A query for an insecure delegation RRset (or a referral) will return - both the answer (in the Authority section) and the corresponding - Opt-In NSEC record to prove that it is not secure. - - Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A - - - RCODE=NOERROR, AD=0 - - Answer Section: - - Authority Section: - UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE - SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DS - SECOND-SECURE.EXAMPLE. RRSIG NSEC ... - - Additional Section: - NS.UNSIGNED.EXAMPLE. A ... - - Example A.1 - - In the Example A.1 zone, the EXAMPLE. node MAY use either style of - NSEC record, because there are no insecure delegations that occur - between it and the next node, FIRST-SECURE.EXAMPLE. In other words, - Example A would still be a valid zone if the NSEC record for EXAMPLE. - was changed to the following RR: - - EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (SOA NS - RRSIG DNSKEY NSEC ) - - However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND- - SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are insecure - delegations in the range they define. (NOT-SECURE.EXAMPLE. and - UNSIGNED.EXAMPLE., respectively). - - NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is - part of the NSEC chain and also covered by an Opt-In tagged NSEC - record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be - - - -Arends, et al. Experimental [Page 10] - -RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 - - - removed from the zone without modifying and resigning the prior NSEC - record. Delegations with names that fall between NOT-SECURE- - 2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without - resigning any NSEC records. - -7. Transition Issues - - Opt-In is not backwards compatible with standard DNSSEC and is - considered experimental. Standard DNSSEC-compliant implementations - would not recognize Opt-In tagged NSEC records as different from - standard NSEC records. Because of this, standard DNSSEC - implementations, if they were to validate Opt-In style responses, - would reject all Opt-In insecure delegations within a zone as - invalid. However, by only signing with private algorithms, standard - DNSSEC implementations will treat Opt-In responses as unsigned. - - It should be noted that all elements in the resolution path between - (and including) the validator and the authoritative name server must - be aware of the Opt-In experiment and implement the Opt-In semantics - for successful validation to be possible. In particular, this - includes any caching middleboxes between the validator and - authoritative name server. - -8. Security Considerations - - Opt-In allows for unsigned names, in the form of delegations to - unsigned subzones, to exist within an otherwise signed zone. All - unsigned names are, by definition, insecure, and their validity or - existence cannot be cryptographically proven. - - In general: - - o Records with unsigned names (whether or not existing) suffer from - the same vulnerabilities as records in an unsigned zone. These - vulnerabilities are described in more detail in [12] (note in - particular Sections 2.3, "Name Games" and 2.6, "Authenticated - Denial"). - - o Records with signed names have the same security whether or not - Opt-In is used. - - Note that with or without Opt-In, an insecure delegation may have its - contents undetectably altered by an attacker. Because of this, the - primary difference in security that Opt-In introduces is the loss of - the ability to prove the existence or nonexistence of an insecure - delegation within the span of an Opt-In NSEC record. - - - - - -Arends, et al. Experimental [Page 11] - -RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 - - - In particular, this means that a malicious entity may be able to - insert or delete records with unsigned names. These records are - normally NS records, but this also includes signed wildcard - expansions (while the wildcard record itself is signed, its expanded - name is an unsigned name), which can be undetectably removed or used - to replace an existing unsigned delegation. - - For example, if a resolver received the following response from the - example zone above: - - Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A - - RCODE=NOERROR - - Answer Section: - - Authority Section: - DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED. - EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \ - RRSIG DNSKEY - EXAMPLE. RRSIG NSEC ... - - Additional Section: - - - Attacker has forged a name - - The resolver would have no choice but to believe that the referral to - NS.FORGED. is valid. If a wildcard existed that would have been - expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could - have undetectably removed it and replaced it with the forged - delegation. - - Note that being able to add a delegation is functionally equivalent - to being able to add any record type: an attacker merely has to forge - a delegation to the nameserver under his/her control and place - whatever records are needed at the subzone apex. - - While in particular cases, this issue may not present a significant - security problem, in general it should not be lightly dismissed. - Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly. - In particular, zone signing tools SHOULD NOT default to Opt-In, and - MAY choose not to support Opt-In at all. - - - - - - - - -Arends, et al. Experimental [Page 12] - -RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 - - -9. Acknowledgments - - The contributions, suggestions, and remarks of the following persons - (in alphabetic order) to this document are acknowledged: - - Mats Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill - Manning, Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, - Brian Wellington. - -10. References - -10.1. Normative References - - [1] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [3] Wellington, B. and O. Gudmundsson, "Redefinition of DNS - Authenticated Data (AD) bit", RFC 3655, November 2003. - - [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - RFC 4035, March 2005. - - [7] Blacka, D., "DNSSEC Experiments", RFC 4955, July 2007. - -10.2. Informative References - - [8] Elz, R. and R. Bush, "Clarifications to the DNS Specification", - RFC 2181, July 1997. - - [9] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [10] Lewis, E., "DNS Security Extension Clarification on Zone - Status", RFC 3090, March 2001. - - - - - -Arends, et al. Experimental [Page 13] - -RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 - - - [11] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, - December 2001. - - [12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name - System (DNS)", RFC 3833, August 2004. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Experimental [Page 14] - -RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 - - -Appendix A. Implementing Opt-In Using "Views" - - In many cases, it may be convenient to implement an Opt-In zone by - combining two separately maintained "views" of a zone at request - time. In this context, "view" refers to a particular version of a - zone, not to any specific DNS implementation feature. - - In this scenario, one view is the secure view, the other is the - insecure (or legacy) view. The secure view consists of an entirely - signed zone using Opt-In tagged NSEC records. The insecure view - contains no DNSSEC information. It is helpful, although not - necessary, for the secure view to be a subset (minus DNSSEC records) - of the insecure view. - - In addition, the only RRsets that may solely exist in the insecure - view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and - the zone apex NS RRset) MUST be signed and in the secure view. - - These two views may be combined at request time to provide a virtual, - single Opt-In zone. The following algorithm is used when responding - to each query: - - V_A is the secure view as described above. - - V_B is the insecure view as described above. - - R_A is a response generated from V_A, following standard DNSSEC. - - R_B is a response generated from V_B, following DNS resolution as - per RFC 1035 [1]. - - R_C is the response generated by combining R_A with R_B, as - described below. - - A query is DNSSEC-aware if it either has the DO bit [11] turned on - or is for a DNSSEC-specific record type. - - 1. If V_A is a subset of V_B and the query is not DNSSEC-aware, - generate and return R_B, otherwise - - 2. Generate R_A. - - 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise - - - - - - - - -Arends, et al. Experimental [Page 15] - -RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 - - - 4. Generate R_B and combine it with R_A to form R_C: - - For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the - records from R_A into R_B, EXCEPT the AUTHORITY section SOA - record, if R_B's RCODE = NOERROR. - - 5. Return R_C. - -Authors' Addresses - - Roy Arends - Nominet - Sandford Gate - Sandy Lane West - Oxford OX4 6LB - UNITED KINGDOM - - Phone: +44 1865 332211 - EMail: roy@nominet.org.uk - - - Mark Kosters - VeriSign, Inc. - 21355 Ridgetop Circle - Dulles, VA 20166 - US - - Phone: +1 703 948 3200 - EMail: mkosters@verisign.com - URI: http://www.verisignlabs.com - - - David Blacka - VeriSign, Inc. - 21355 Ridgetop Circle - Dulles, VA 20166 - US - - Phone: +1 703 948 3200 - EMail: davidb@verisign.com - URI: http://www.verisignlabs.com - - - - - - - - - - -Arends, et al. Experimental [Page 16] - -RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Arends, et al. Experimental [Page 17] - diff --git a/doc/rfc/rfc5001.txt b/doc/rfc/rfc5001.txt deleted file mode 100644 index fe153393694..00000000000 --- a/doc/rfc/rfc5001.txt +++ /dev/null @@ -1,619 +0,0 @@ - - - - - - -Network Working Group R. Austein -Request for Comments: 5001 ISC -Category: Standards Track August 2007 - - - DNS Name Server Identifier (NSID) Option - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - -Abstract - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. While existing ad-hoc - mechanisms allow an operator to send follow-up queries when it is - necessary to debug such a configuration, the only completely reliable - way to obtain the identity of the name server that responded is to - have the name server include this information in the response itself. - This note defines a protocol extension to support this functionality. - - - - - - - - - - - - - - - - - - - - - -Austein Standards Track [Page 1] - -RFC 5001 DNS NSID August 2007 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 3 - 2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 3 - 2.3. The NSID Option . . . . . . . . . . . . . . . . . . . . . 4 - 2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 4 - 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 4 - 3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 7 - 3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 7 - 3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 8 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 - -1. Introduction - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. - - Existing ad-hoc mechanisms allow an operator to send follow-up - queries when it is necessary to debug such a configuration, but there - are situations in which this is not a totally satisfactory solution, - since anycast routing may have changed, or the server pool in - question may be behind some kind of extremely dynamic load balancing - hardware. Thus, while these ad-hoc mechanisms are certainly better - than nothing (and have the advantage of already being deployed), a - better solution seems desirable. - - Given that a DNS query is an idempotent operation with no retained - state, it would appear that the only completely reliable way to - obtain the identity of the name server that responded to a particular - query is to have that name server include identifying information in - the response itself. This note defines a protocol enhancement to - achieve this. - - - - - - - - -Austein Standards Track [Page 2] - -RFC 5001 DNS NSID August 2007 - - -1.1. Reserved Words - - 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]. - -2. Protocol - - This note uses an EDNS [RFC2671] option to signal the resolver's - desire for information identifying the name server and to hold the - name server's response, if any. - -2.1. Resolver Behavior - - A resolver signals its desire for information identifying a name - server by sending an empty NSID option (Section 2.3) in an EDNS OPT - pseudo-RR in the query message. - - The resolver MUST NOT include any NSID payload data in the query - message. - - The semantics of an NSID request are not transitive. That is: the - presence of an NSID option in a query is a request that the name - server which receives the query identify itself. If the name server - side of a recursive name server receives an NSID request, the client - is asking the recursive name server to identify itself; if the - resolver side of the recursive name server wishes to receive - identifying information, it is free to add NSID requests in its own - queries, but that is a separate matter. - -2.2. Name Server Behavior - - A name server that understands the NSID option and chooses to honor a - particular NSID request responds by including identifying information - in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR in the - response message. - - The name server MUST ignore any NSID payload data that might be - present in the query message. - - The NSID option is not transitive. A name server MUST NOT send an - NSID option back to a resolver which did not request it. In - particular, while a recursive name server may choose to add an NSID - option when sending a query, this has no effect on the presence or - absence of the NSID option in the recursive name server's response to - the original client. - - - - - -Austein Standards Track [Page 3] - -RFC 5001 DNS NSID August 2007 - - - As stated in Section 2.1, this mechanism is not restricted to - authoritative name servers; the semantics are intended to be equally - applicable to recursive name servers. - -2.3. The NSID Option - - The OPTION-CODE for the NSID option is 3. - - The OPTION-DATA for the NSID option is an opaque byte string, the - semantics of which are deliberately left outside the protocol. See - Section 3.1 for discussion. - -2.4. Presentation Format - - User interfaces MUST read and write the contents of the NSID option - as a sequence of hexadecimal digits, two digits per payload octet. - - The NSID payload is binary data. Any comparison between NSID - payloads MUST be a comparison of the raw binary data. Copy - operations MUST NOT assume that the raw NSID payload is null- - terminated. Any resemblance between raw NSID payload data and any - form of text is purely a convenience, and does not change the - underlying nature of the payload data. - - See Section 3.3 for discussion. - -3. Discussion - - This section discusses certain aspects of the protocol and explains - considerations that led to the chosen design. - -3.1. The NSID Payload - - The syntax and semantics of the content of the NSID option are - deliberately left outside the scope of this specification. - - Choosing the NSID content is a prerogative of the server - administrator. The server administrator might choose to encode the - NSID content in such a way that the server operator (or clients - authorized by the server operator) can decode the NSID content to - obtain more information than other clients can. Alternatively, the - server operator might choose unencoded NSID content that is equally - meaningful to any client. - - This section describes some of the kinds of data that server - administrators might choose to provide as the content of the NSID - option, and explains the reasoning behind specifying a simple opaque - byte string in Section 2.3. - - - -Austein Standards Track [Page 4] - -RFC 5001 DNS NSID August 2007 - - - There are several possibilities for the payload of the NSID option: - - o It could be the "real" name of the specific name server within the - name server pool. - - o It could be the "real" IP address (IPv4 or IPv6) of the name - server within the name server pool. - - o It could be some sort of pseudo-random number generated in a - predictable fashion somehow using the server's IP address or name - as a seed value. - - o It could be some sort of probabilistically unique identifier - initially derived from some sort of random number generator then - preserved across reboots of the name server. - - o It could be some sort of dynamically generated identifier so that - only the name server operator could tell whether or not any two - queries had been answered by the same server. - - o It could be a blob of signed data, with a corresponding key which - might (or might not) be available via DNS lookups. - - o It could be a blob of encrypted data, the key for which could be - restricted to parties with a need to know (in the opinion of the - server operator). - - o It could be an arbitrary string of octets chosen at the discretion - of the name server operator. - - Each of these options has advantages and disadvantages: - - o Using the "real" name is simple, but the name server may not have - a "real" name. - - o Using the "real" address is also simple, and the name server - almost certainly does have at least one non-anycast IP address for - maintenance operations, but the operator of the name server may - not be willing to divulge its non-anycast address. - - o Given that one common reason for using anycast DNS techniques is - an attempt to harden a critical name server against denial of - service attacks, some name server operators are likely to want an - identifier other than the "real" name or "real" address of the - name server instance. - - o Using a hash or pseudo-random number can provide a fixed length - value that the resolver can use to tell two name servers apart - - - -Austein Standards Track [Page 5] - -RFC 5001 DNS NSID August 2007 - - - without necessarily being able to tell where either one of them - "really" is, but makes debugging more difficult if one happens to - be in a friendly open environment. Furthermore, hashing might not - add much value, since a hash based on an IPv4 address still only - involves a 32-bit search space, and DNS names used for servers - that operators might have to debug at 4am tend not to be very - random. - - o Probabilistically unique identifiers have properties similar to - hashed identifiers, but (given a sufficiently good random number - generator) are immune to the search space issues. However, the - strength of this approach is also its weakness: there is no - algorithmic transformation by which even the server operator can - associate name server instances with identifiers while debugging, - which might be annoying. This approach also requires the name - server instance to preserve the probabilistically unique - identifier across reboots, but this does not appear to be a - serious restriction, since authoritative nameservers almost always - have some form of non-volatile storage. In the rare case of a - name server that does not have any way to store such an - identifier, nothing terrible will happen if the name server - generates a new identifier every time it reboots. - - o Using an arbitrary octet string gives name server operators yet - another setting to configure, or mis-configure, or forget to - configure. Having all the nodes in an anycast name server - constellation identify themselves as "My Name Server" would not be - particularly useful. - - o A signed blob is not particularly useful as an NSID payload unless - the signed data is dynamic and includes some kind of replay - protection, such as a timestamp or some kind of data identifying - the requestor. Signed blobs that meet these criteria could - conceivably be useful in some situations but would require - detailed security analysis beyond the scope of this document. - - o A static encrypted blob would not be particularly useful, as it - would be subject to replay attacks and would, in effect, just be a - random number to any party that does not possess the decryption - key. Dynamic encrypted blobs could conceivably be useful in some - situations but, as with signed blobs, dynamic encrypted blobs - would require detailed security analysis beyond the scope of this - document. - - Given all of the issues listed above, there does not appear to be a - single solution that will meet all needs. Section 2.3 therefore - defines the NSID payload to be an opaque byte string and leaves the - choice of payload up to the implementor and name server operator. - - - -Austein Standards Track [Page 6] - -RFC 5001 DNS NSID August 2007 - - - The following guidelines may be useful to implementors and server - operators: - - o Operators for whom divulging the unicast address is an issue could - use the raw binary representation of a probabilistically unique - random number. This should probably be the default implementation - behavior. - - o Operators for whom divulging the unicast address is not an issue - could just use the raw binary representation of a unicast address - for simplicity. This should only be done via an explicit - configuration choice by the operator. - - o Operators who really need or want the ability to set the NSID - payload to an arbitrary value could do so, but this should only be - done via an explicit configuration choice by the operator. - - This approach appears to provide enough information for useful - debugging without unintentionally leaking the maintenance addresses - of anycast name servers to nogoodniks, while also allowing name - server operators who do not find such leakage threatening to provide - more information at their own discretion. - -3.2. NSID Is Not Transitive - - As specified in Section 2.1 and Section 2.2, the NSID option is not - transitive. This is strictly a hop-by-hop mechanism. - - Most of the discussion of name server identification to date has - focused on identifying authoritative name servers, since the best - known cases of anycast name servers are a subset of the name servers - for the root zone. However, given that anycast DNS techniques are - also applicable to recursive name servers, the mechanism may also be - useful with recursive name servers. The hop-by-hop semantics support - this. - - While there might be some utility in having a transitive variant of - this mechanism (so that, for example, a stub resolver could ask a - recursive server to tell it which authoritative name server provided - a particular answer to the recursive name server), the semantics of - such a variant would be more complicated, and are left for future - work. - -3.3. User Interface Issues - - Given the range of possible payload contents described in - Section 3.1, it is not possible to define a single presentation - format for the NSID payload that is efficient, convenient, - - - -Austein Standards Track [Page 7] - -RFC 5001 DNS NSID August 2007 - - - unambiguous, and aesthetically pleasing. In particular, while it is - tempting to use a presentation format that uses some form of textual - strings, attempting to support this would significantly complicate - what's intended to be a very simple debugging mechanism. - - In some cases the content of the NSID payload may be binary data - meaningful only to the name server operator, and may not be - meaningful to the user or application, but the user or application - must be able to capture the entire content anyway in order for it to - be useful. Thus, the presentation format must support arbitrary - binary data. - - In cases where the name server operator derives the NSID payload from - textual data, a textual form such as US-ASCII or UTF-8 strings might - at first glance seem easier for a user to deal with. There are, - however, a number of complex issues involving internationalized text - which, if fully addressed here, would require a set of rules - significantly longer than the rest of this specification. See - [RFC2277] for an overview of some of these issues. - - It is much more important for the NSID payload data to be passed - unambiguously from server administrator to user and back again than - it is for the payload data to be pretty while in transit. In - particular, it's critical that it be straightforward for a user to - cut and paste an exact copy of the NSID payload output by a debugging - tool into other formats such as email messages or web forms without - distortion. Hexadecimal strings, while ugly, are also robust. - -3.4. Truncation - - In some cases, adding the NSID option to a response message may - trigger message truncation. This specification does not change the - rules for DNS message truncation in any way, but implementors will - need to pay attention to this issue. - - Including the NSID option in a response is always optional, so this - specification never requires name servers to truncate response - messages. - - By definition, a resolver that requests NSID responses also supports - EDNS, so a resolver that requests NSID responses can also use the - "sender's UDP payload size" field of the OPT pseudo-RR to signal a - receive buffer size large enough to make truncation unlikely. - -4. IANA Considerations - - IANA has allocated EDNS option code 3 for the NSID option - (Section 2.3). - - - -Austein Standards Track [Page 8] - -RFC 5001 DNS NSID August 2007 - - -5. Security Considerations - - This document describes a channel signaling mechanism intended - primarily for debugging. Channel signaling mechanisms are outside - the scope of DNSSEC, per se. Applications that require integrity - protection for the data being signaled will need to use a channel - security mechanism such as TSIG [RFC2845]. - - Section 3.1 discusses a number of different kinds of information that - a name server operator might choose to provide as the value of the - NSID option. Some of these kinds of information are security - sensitive in some environments. This specification deliberately - leaves the syntax and semantics of the NSID option content up to the - implementation and the name server operator. - - Two of the possible kinds of payload data discussed in Section 3.1 - involve a digital signature and encryption, respectively. While this - specification discusses some of the pitfalls that might lurk for - careless users of these kinds of payload data, full analysis of the - issues that would be involved in these kinds of payload data would - require knowledge of the content to be signed or encrypted, - algorithms to be used, and so forth, which is beyond the scope of - this document. Implementors should seek competent advice before - attempting to use these kinds of NSID payloads. - -6. Acknowledgements - - Thanks to: Joe Abley, Harald Alvestrand, Dean Anderson, Mark Andrews, - Roy Arends, Steve Bellovin, Alex Bligh, Randy Bush, David Conrad, - John Dickinson, Alfred Hoenes, Johan Ihren, Daniel Karrenberg, Peter - Koch, William Leibzon, Ed Lewis, Thomas Narten, Mike Patton, Geoffrey - Sisson, Andrew Sullivan, Mike StJohns, Tom Taylor, Paul Vixie, Sam - Weiler, and Suzanne Woolf, none of whom are responsible for what the - author did with their comments and suggestions. Apologies to anyone - inadvertently omitted from the above list. - -7. References - -7.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, BCP 14, March 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - - - - - - -Austein Standards Track [Page 9] - -RFC 5001 DNS NSID August 2007 - - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - -7.2. Informative References - - [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and - Languages", RFC 2277, BCP 18, January 1998. - -Author's Address - - Rob Austein - ISC - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Standards Track [Page 10] - -RFC 5001 DNS NSID August 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Austein Standards Track [Page 11] - diff --git a/doc/rfc/rfc5011.txt b/doc/rfc/rfc5011.txt deleted file mode 100644 index 42235e977f8..00000000000 --- a/doc/rfc/rfc5011.txt +++ /dev/null @@ -1,787 +0,0 @@ - - - - - - -Network Working Group M. StJohns -Request for Comments: 5011 Independent -Category: Standards Track September 2007 - - - Automated Updates of DNS Security (DNSSEC) Trust Anchors - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - This document describes a means for automated, authenticated, and - authorized updating of DNSSEC "trust anchors". The method provides - protection against N-1 key compromises of N keys in the trust point - key set. Based on the trust established by the presence of a current - anchor, other anchors may be added at the same place in the - hierarchy, and, ultimately, supplant the existing anchor(s). - - This mechanism will require changes to resolver management behavior - (but not resolver resolution behavior), and the addition of a single - flag bit to the DNSKEY record. - - - - - - - - - - - - - - - - - - - - - - - - -StJohns Standards Track [Page 1] - -RFC 5011 Trust Anchor Update September 2007 - - -Table of Contents - - 1. Introduction ....................................................2 - 1.1. Compliance Nomenclature ....................................3 - 2. Theory of Operation .............................................3 - 2.1. Revocation .................................................4 - 2.2. Add Hold-Down ..............................................4 - 2.3. Active Refresh .............................................5 - 2.4. Resolver Parameters ........................................6 - 2.4.1. Add Hold-Down Time ..................................6 - 2.4.2. Remove Hold-Down Time ...............................6 - 2.4.3. Minimum Trust Anchors per Trust Point ...............6 - 3. Changes to DNSKEY RDATA Wire Format .............................6 - 4. State Table .....................................................6 - 4.1. Events .....................................................7 - 4.2. States .....................................................7 - 5. Trust Point Deletion ............................................8 - 6. Scenarios - Informative .........................................9 - 6.1. Adding a Trust Anchor ......................................9 - 6.2. Deleting a Trust Anchor ....................................9 - 6.3. Key Roll-Over .............................................10 - 6.4. Active Key Compromised ....................................10 - 6.5. Stand-by Key Compromised ..................................10 - 6.6. Trust Point Deletion ......................................10 - 7. IANA Considerations ............................................11 - 8. Security Considerations ........................................11 - 8.1. Key Ownership vs. Acceptance Policy .......................11 - 8.2. Multiple Key Compromise ...................................12 - 8.3. Dynamic Updates ...........................................12 - 9. Normative References ...........................................12 - 10. Informative References ........................................12 - -1. Introduction - - As part of the reality of fielding DNSSEC (Domain Name System - Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has - come to the realization that there will not be one signed name space, - but rather islands of signed name spaces each originating from - specific points (i.e., 'trust points') in the DNS tree. Each of - those islands will be identified by the trust point name, and - validated by at least one associated public key. For the purpose of - this document, we'll call the association of that name and a - particular key a 'trust anchor'. A particular trust point can have - more than one key designated as a trust anchor. - - For a DNSSEC-aware resolver to validate information in a DNSSEC - protected branch of the hierarchy, it must have knowledge of a trust - anchor applicable to that branch. It may also have more than one - - - -StJohns Standards Track [Page 2] - -RFC 5011 Trust Anchor Update September 2007 - - - trust anchor for any given trust point. Under current rules, a chain - of trust for DNSSEC-protected data that chains its way back to ANY - known trust anchor is considered 'secure'. - - Because of the probable balkanization of the DNSSEC tree due to - signing voids at key locations, a resolver may need to know literally - thousands of trust anchors to perform its duties (e.g., consider an - unsigned ".COM"). Requiring the owner of the resolver to manually - manage these many relationships is problematic. It's even more - problematic when considering the eventual requirement for key - replacement/update for a given trust anchor. The mechanism described - herein won't help with the initial configuration of the trust anchors - in the resolvers, but should make trust point key - replacement/rollover more viable. - - As mentioned above, this document describes a mechanism whereby a - resolver can update the trust anchors for a given trust point, mainly - without human intervention at the resolver. There are some corner - cases discussed (e.g., multiple key compromise) that may require - manual intervention, but they should be few and far between. This - document DOES NOT discuss the general problem of the initial - configuration of trust anchors for the resolver. - -1.1. Compliance Nomenclature - - 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 BCP 14, [RFC2119]. - -2. Theory of Operation - - The general concept of this mechanism is that existing trust anchors - can be used to authenticate new trust anchors at the same point in - the DNS hierarchy. When a zone operator adds a new SEP key (i.e., a - DNSKEY with the Secure Entry Point bit set) (see [RFC4034], Section - 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is - validated by an existing trust anchor, then the resolver can add the - new key to its set of valid trust anchors for that trust point. - - There are some issues with this approach that need to be mitigated. - For example, a compromise of one of the existing keys could allow an - attacker to add their own 'valid' data. This implies a need for a - method to revoke an existing key regardless of whether or not that - key is compromised. As another example, assuming a single key - compromise, we need to prevent an attacker from adding a new key and - revoking all the other old keys. - - - - - -StJohns Standards Track [Page 3] - -RFC 5011 Trust Anchor Update September 2007 - - -2.1. Revocation - - Assume two trust anchor keys A and B. Assume that B has been - compromised. Without a specific revocation bit, B could invalidate A - simply by sending out a signed trust point key set that didn't - contain A. To fix this, we add a mechanism that requires knowledge - of the private key of a DNSKEY to revoke that DNSKEY. - - A key is considered revoked when the resolver sees the key in a - self-signed RRSet and the key has the REVOKE bit (see Section 7 - below) set to '1'. Once the resolver sees the REVOKE bit, it MUST - NOT use this key as a trust anchor or for any other purpose except to - validate the RRSIG it signed over the DNSKEY RRSet specifically for - the purpose of validating the revocation. Unlike the 'Add' operation - below, revocation is immediate and permanent upon receipt of a valid - revocation at the resolver. - - A self-signed RRSet is a DNSKEY RRSet that contains the specific - DNSKEY and for which there is a corresponding validated RRSIG record. - It's not a special DNSKEY RRSet, just a way of describing the - validation requirements for that RRSet. - - N.B.: A DNSKEY with the REVOKE bit set has a different fingerprint - than one without the bit set. This affects the matching of a DNSKEY - to DS records in the parent [RFC3755], or the fingerprint stored at a - resolver used to configure a trust point. - - In the given example, the attacker could revoke B because it has - knowledge of B's private key, but could not revoke A. - -2.2. Add Hold-Down - - Assume two trust point keys A and B. Assume that B has been - compromised. An attacker could generate and add a new trust anchor - key C (by adding C to the DNSKEY RRSet and signing it with B), and - then invalidate the compromised key. This would result in both the - attacker and owner being able to sign data in the zone and have it - accepted as valid by resolvers. - - To mitigate but not completely solve this problem, we add a hold-down - time to the addition of the trust anchor. When the resolver sees a - new SEP key in a validated trust point DNSKEY RRSet, the resolver - starts an acceptance timer, and remembers all the keys that validated - the RRSet. If the resolver ever sees the DNSKEY RRSet without the - new key but validly signed, it stops the acceptance process for that - key and resets the acceptance timer. If all of the keys that were - - - - - -StJohns Standards Track [Page 4] - -RFC 5011 Trust Anchor Update September 2007 - - - originally used to validate this key are revoked prior to the timer - expiring, the resolver stops the acceptance process and resets the - timer. - - Once the timer expires, the new key will be added as a trust anchor - the next time the validated RRSet with the new key is seen at the - resolver. The resolver MUST NOT treat the new key as a trust anchor - until the hold-down time expires AND it has retrieved and validated a - DNSKEY RRSet after the hold-down time that contains the new key. - - N.B.: Once the resolver has accepted a key as a trust anchor, the key - MUST be considered a valid trust anchor by that resolver until - explicitly revoked as described above. - - In the given example, the zone owner can recover from a compromise by - revoking B and adding a new key D and signing the DNSKEY RRSet with - both A and B. - - The reason this does not completely solve the problem has to do with - the distributed nature of DNS. The resolver only knows what it sees. - A determined attacker who holds one compromised key could keep a - single resolver from realizing that the key had been compromised by - intercepting 'real' data from the originating zone and substituting - their own (e.g., using the example, signed only by B). This is no - worse than the current situation assuming a compromised key. - -2.3. Active Refresh - - A resolver that has been configured for an automatic update of keys - from a particular trust point MUST query that trust point (e.g., do a - lookup for the DNSKEY RRSet and related RRSIG records) no less often - than the lesser of 15 days, half the original TTL for the DNSKEY - RRSet, or half the RRSIG expiration interval and no more often than - once per hour. The expiration interval is the amount of time from - when the RRSIG was last retrieved until the expiration time in the - RRSIG. That is, queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL, - 1/2*RRSigExpirationInterval)) - - If the query fails, the resolver MUST repeat the query until - satisfied no more often than once an hour and no less often than the - lesser of 1 day, 10% of the original TTL, or 10% of the original - expiration interval. That is, retryTime = MAX (1 hour, MIN (1 day, - .1 * origTTL, .1 * expireInterval)). - - - - - - - - -StJohns Standards Track [Page 5] - -RFC 5011 Trust Anchor Update September 2007 - - -2.4. Resolver Parameters - -2.4.1. Add Hold-Down Time - - The add hold-down time is 30 days or the expiration time of the - original TTL of the first trust point DNSKEY RRSet that contained the - new key, whichever is greater. This ensures that at least two - validated DNSKEY RRSets that contain the new key MUST be seen by the - resolver prior to the key's acceptance. - -2.4.2. Remove Hold-Down Time - - The remove hold-down time is 30 days. This parameter is solely a key - management database bookeeping parameter. Failure to remove - information about the state of defunct keys from the database will - not adversely impact the security of this protocol, but may end up - with a database cluttered with obsolete key information. - -2.4.3. Minimum Trust Anchors per Trust Point - - A compliant resolver MUST be able to manage at least five SEP keys - per trust point. - -3. Changes to DNSKEY RDATA Wire Format - - Bit 8 of the DNSKEY Flags field is designated as the 'REVOKE' flag. - If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY) - signed by the associated key, then the resolver MUST consider this - key permanently invalid for all purposes except for validating the - revocation. - -4. State Table - - The most important thing to understand is the resolver's view of any - key at a trust point. The following state table describes this view - at various points in the key's lifetime. The table is a normative - part of this specification. The initial state of the key is 'Start'. - The resolver's view of the state of the key changes as various events - occur. - - This is the state of a trust-point key as seen from the resolver. - The column on the left indicates the current state. The header at - the top shows the next state. The intersection of the two shows the - event that will cause the state to transition from the current state - to the next. - - - - - - -StJohns Standards Track [Page 6] - -RFC 5011 Trust Anchor Update September 2007 - - - NEXT STATE - -------------------------------------------------- - FROM |Start |AddPend |Valid |Missing|Revoked|Removed| - ---------------------------------------------------------- - Start | |NewKey | | | | | - ---------------------------------------------------------- - AddPend |KeyRem | |AddTime| | | | - ---------------------------------------------------------- - Valid | | | |KeyRem |Revbit | | - ---------------------------------------------------------- - Missing | | |KeyPres| |Revbit | | - ---------------------------------------------------------- - Revoked | | | | | |RemTime| - ---------------------------------------------------------- - Removed | | | | | | | - ---------------------------------------------------------- - - State Table - -4.1. Events - - NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. - That key will become a new trust anchor for the named trust - point after it's been present in the RRSet for at least 'add - time'. - - KeyPres The key has returned to the valid DNSKEY RRSet. - - KeyRem The resolver sees a valid DNSKEY RRSet that does not contain - this key. - - AddTime The key has been in every valid DNSKEY RRSet seen for at - least the 'add time'. - - RemTime A revoked key has been missing from the trust-point DNSKEY - RRSet for sufficient time to be removed from the trust set. - - RevBit The key has appeared in the trust anchor DNSKEY RRSet with - its "REVOKED" bit set, and there is an RRSig over the DNSKEY - RRSet signed by this key. - -4.2. States - - Start The key doesn't yet exist as a trust anchor at the resolver. - It may or may not exist at the zone server, but either - hasn't yet been seen at the resolver or was seen but was - absent from the last DNSKEY RRSet (e.g., KeyRem event). - - - - -StJohns Standards Track [Page 7] - -RFC 5011 Trust Anchor Update September 2007 - - - AddPend The key has been seen at the resolver, has its 'SEP' bit - set, and has been included in a validated DNSKEY RRSet. - There is a hold-down time for the key before it can be used - as a trust anchor. - - Valid The key has been seen at the resolver and has been included - in all validated DNSKEY RRSets from the time it was first - seen through the hold-down time. It is now valid for - verifying RRSets that arrive after the hold-down time. - Clarification: The DNSKEY RRSet does not need to be - continuously present at the resolver (e.g., its TTL might - expire). If the RRSet is seen and is validated (i.e., - verifies against an existing trust anchor), this key MUST be - in the RRSet, otherwise a 'KeyRem' event is triggered. - - Missing This is an abnormal state. The key remains a valid trust- - point key, but was not seen at the resolver in the last - validated DNSKEY RRSet. This is an abnormal state because - the zone operator should be using the REVOKE bit prior to - removal. - - Revoked This is the state a key moves to once the resolver sees an - RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet - contains this key with its REVOKE bit set to '1'. Once in - this state, this key MUST permanently be considered invalid - as a trust anchor. - - Removed After a fairly long hold-down time, information about this - key may be purged from the resolver. A key in the removed - state MUST NOT be considered a valid trust anchor. (Note: - this state is more or less equivalent to the "Start" state, - except that it's bad practice to re-introduce previously - used keys -- think of this as the holding state for all the - old keys for which the resolver no longer needs to track - state.) - -5. Trust Point Deletion - - A trust point that has all of its trust anchors revoked is considered - deleted and is treated as if the trust point was never configured. - If there are no superior configured trust points, data at and below - the deleted trust point are considered insecure by the resolver. If - there ARE superior configured trust points, data at and below the - deleted trust point are evaluated with respect to the superior trust - point(s). - - Alternately, a trust point that is subordinate to another configured - trust point MAY be deleted by a resolver after 180 days, where such a - - - -StJohns Standards Track [Page 8] - -RFC 5011 Trust Anchor Update September 2007 - - - subordinate trust point validly chains to a superior trust point. - The decision to delete the subordinate trust anchor is a local - configuration decision. Once the subordinate trust point is deleted, - validation of the subordinate zone is dependent on validating the - chain of trust to the superior trust point. - -6. Scenarios - Informative - - The suggested model for operation is to have one active key and one - stand-by key at each trust point. The active key will be used to - sign the DNSKEY RRSet. The stand-by key will not normally sign this - RRSet, but the resolver will accept it as a trust anchor if/when it - sees the signature on the trust point DNSKEY RRSet. - - Since the stand-by key is not in active signing use, the associated - private key may (and should) be provided with additional protections - not normally available to a key that must be used frequently (e.g., - locked in a safe, split among many parties, etc). Notionally, the - stand-by key should be less subject to compromise than an active key, - but that will be dependent on operational concerns not addressed - here. - -6.1. Adding a Trust Anchor - - Assume an existing trust anchor key 'A'. - - 1. Generate a new key pair. - - 2. Create a DNSKEY record from the key pair and set the SEP and Zone - Key bits. - - 3. Add the DNSKEY to the RRSet. - - 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - - 'A'. - - 5. Wait for various resolvers' timers to go off and for them to - retrieve the new DNSKEY RRSet and signatures. - - 6. The new trust anchor will be populated at the resolvers on the - schedule described by the state table and update algorithm -- see - Sections 2 and 4 above. - -6.2. Deleting a Trust Anchor - - Assume existing trust anchors 'A' and 'B' and that you want to revoke - and delete 'A'. - - - - -StJohns Standards Track [Page 9] - -RFC 5011 Trust Anchor Update September 2007 - - - 1. Set the revocation bit on key 'A'. - - 2. Sign the DNSKEY RRSet with both 'A' and 'B'. 'A' is now revoked. - The operator should include the revoked 'A' in the RRSet for at - least the remove hold-down time, but then may remove it from the - DNSKEY RRSet. - -6.3. Key Roll-Over - - Assume existing keys A and B. 'A' is actively in use (i.e. has been - signing the DNSKEY RRSet). 'B' was the stand-by key. (i.e. has been - in the DNSKEY RRSet and is a valid trust anchor, but wasn't being - used to sign the RRSet). - - 1. Generate a new key pair 'C'. - 2. Add 'C' to the DNSKEY RRSet. - 3. Set the revocation bit on key 'A'. - 4. Sign the RRSet with 'A' and 'B'. - - 'A' is now revoked, 'B' is now the active key, and 'C' will be the - stand-by key once the hold-down expires. The operator should include - the revoked 'A' in the RRSet for at least the remove hold-down time, - but may then remove it from the DNSKEY RRSet. - -6.4. Active Key Compromised - - This is the same as the mechanism for Key Roll-Over (Section 6.3) - above, assuming 'A' is the active key. - -6.5. Stand-by Key Compromised - - Using the same assumptions and naming conventions as Key Roll-Over - (Section 6.3) above: - - 1. Generate a new key pair 'C'. - 2. Add 'C' to the DNSKEY RRSet. - 3. Set the revocation bit on key 'B'. - 4. Sign the RRSet with 'A' and 'B'. - - 'B' is now revoked, 'A' remains the active key, and 'C' will be the - stand-by key once the hold-down expires. 'B' should continue to be - included in the RRSet for the remove hold-down time. - -6.6. Trust Point Deletion - - To delete a trust point that is subordinate to another configured - trust point (e.g., example.com to .com) requires some juggling of the - data. The specific process is: - - - -StJohns Standards Track [Page 10] - -RFC 5011 Trust Anchor Update September 2007 - - - 1. Generate a new DNSKEY and DS record and provide the DS record to - the parent along with DS records for the old keys. - - 2. Once the parent has published the DSs, add the new DNSKEY to the - RRSet and revoke ALL of the old keys at the same time, while - signing the DNSKEY RRSet with all of the old and new keys. - - 3. After 30 days, stop publishing the old, revoked keys and remove - any corresponding DS records in the parent. - - Revoking the old trust-point keys at the same time as adding new keys - that chain to a superior trust prevents the resolver from adding the - new keys as trust anchors. Adding DS records for the old keys avoids - a race condition where either the subordinate zone becomes unsecure - (because the trust point was deleted) or becomes bogus (because it - didn't chain to the superior zone). - -7. IANA Considerations - - The IANA has assigned a bit in the DNSKEY flags field (see Section 7 - of [RFC4034]) for the REVOKE bit (8). - -8. Security Considerations - - In addition to the following sections, see also Theory of Operation - above (Section 2) and especially Section 2.2 for related discussions. - - Security considerations for trust anchor rollover not specific to - this protocol are discussed in [RFC4986]. - -8.1. Key Ownership vs. Acceptance Policy - - The reader should note that, while the zone owner is responsible for - creating and distributing keys, it's wholly the decision of the - resolver owner as to whether to accept such keys for the - authentication of the zone information. This implies the decision to - update trust-anchor keys based on trusting a current trust-anchor key - is also the resolver owner's decision. - - The resolver owner (and resolver implementers) MAY choose to permit - or prevent key status updates based on this mechanism for specific - trust points. If they choose to prevent the automated updates, they - will need to establish a mechanism for manual or other out-of-band - updates, which are outside the scope of this document. - - - - - - - -StJohns Standards Track [Page 11] - -RFC 5011 Trust Anchor Update September 2007 - - -8.2. Multiple Key Compromise - - This scheme permits recovery as long as at least one valid trust- - anchor key remains uncompromised, e.g., if there are three keys, you - can recover if two of them are compromised. The zone owner should - determine their own level of comfort with respect to the number of - active, valid trust anchors in a zone and should be prepared to - implement recovery procedures once they detect a compromise. A - manual or other out-of-band update of all resolvers will be required - if all trust-anchor keys at a trust point are compromised. - -8.3. Dynamic Updates - - Allowing a resolver to update its trust anchor set based on in-band - key information is potentially less secure than a manual process. - However, given the nature of the DNS, the number of resolvers that - would require update if a trust anchor key were compromised, and the - lack of a standard management framework for DNS, this approach is no - worse than the existing situation. - -9. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer (DS)", RFC 3755, May 2004. - - [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. - -10. Informative References - - [RFC4986] Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy, - "Requirements Related to DNS Security (DNSSEC) Trust - Anchor Rollover", RFC 4986, August 2007. - - - - - - -StJohns Standards Track [Page 12] - -RFC 5011 Trust Anchor Update September 2007 - - -Author's Address - - Michael StJohns - Independent - - EMail: mstjohns@comcast.net - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -StJohns Standards Track [Page 13] - -RFC 5011 Trust Anchor Update September 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - - - - - - - - - - -StJohns Standards Track [Page 14] - diff --git a/doc/rfc/rfc5452.txt b/doc/rfc/rfc5452.txt deleted file mode 100644 index 6f59bf57acf..00000000000 --- a/doc/rfc/rfc5452.txt +++ /dev/null @@ -1,1011 +0,0 @@ - - - - - - -Network Working Group A. Hubert -Request for Comments: 5452 Netherlabs Computer Consulting BV. -Updates: 2181 R. van Mook -Category: Standards Track Equinix - January 2009 - - - Measures for Making DNS More Resilient against Forged Answers - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -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. - -Abstract - - The current Internet climate poses serious threats to the Domain Name - System. In the interim period before the DNS protocol can be secured - more fully, measures can already be taken to harden the DNS to make - 'spoofing' a recursing nameserver many orders of magnitude harder. - - Even a cryptographically secured DNS benefits from having the ability - to discard bogus responses quickly, as this potentially saves large - amounts of computation. - - By describing certain behavior that has previously not been - standardized, this document sets out how to make the DNS more - resilient against accepting incorrect responses. This document - updates RFC 2181. - - - - - - - - -Hubert & van Mook Standards Track [Page 1] - -RFC 5452 DNS Resilience against Forged Answers January 2009 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Requirements and Definitions . . . . . . . . . . . . . . . . . 4 - 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Description of DNS Spoofing . . . . . . . . . . . . . . . . . 5 - 4. Detailed Description of Spoofing Scenarios . . . . . . . . . . 6 - 4.1. Forcing a Query . . . . . . . . . . . . . . . . . . . . . 6 - 4.2. Matching the Question Section . . . . . . . . . . . . . . 7 - 4.3. Matching the ID Field . . . . . . . . . . . . . . . . . . 7 - 4.4. Matching the Source Address of the Authentic Response . . 7 - 4.5. Matching the Destination Address and Port of the - Authentic Response . . . . . . . . . . . . . . . . . . . . 8 - 4.6. Have the Response Arrive before the Authentic Response . . 8 - 5. Birthday Attacks . . . . . . . . . . . . . . . . . . . . . . . 9 - 6. Accepting Only In-Domain Records . . . . . . . . . . . . . . . 9 - 7. Combined Difficulty . . . . . . . . . . . . . . . . . . . . . 10 - 7.1. Symbols Used in Calculation . . . . . . . . . . . . . . . 10 - 7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 11 - 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 8.1. Repetitive Spoofing Attempts for a Single Domain Name . . 13 - 9. Forgery Countermeasures . . . . . . . . . . . . . . . . . . . 13 - 9.1. Query Matching Rules . . . . . . . . . . . . . . . . . . . 13 - 9.2. Extending the Q-ID Space by Using Ports and Addresses . . 14 - 9.2.1. Justification and Discussion . . . . . . . . . . . . . 14 - 9.3. Spoof Detection and Countermeasure . . . . . . . . . . . . 15 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 - - - - - - - - - - - - - - - - - - - -Hubert & van Mook Standards Track [Page 2] - -RFC 5452 DNS Resilience against Forged Answers January 2009 - - -1. Introduction - - This document describes several common problems in DNS - implementations, which, although previously recognized, remain - largely unsolved. Besides briefly recapping these problems, this - document contains rules that, if implemented, make complying - resolvers vastly more resistant to the attacks described. The goal - is to make the existing DNS as secure as possible within the current - protocol boundaries. - - The words below are aimed at authors of resolvers: it is up to - operators to decide which nameserver implementation to use, or which - options to enable. Operational constraints may override the security - concerns described below. However, implementations are expected to - allow an operator to enable functionality described in this document. - - Almost every transaction on the Internet involves the Domain Name - System, which is described in [RFC1034], [RFC1035], and beyond. - - Additionally, it has recently become possible to acquire Secure - Socket Layer/Transport Layer Security (SSL/TLS) certificates with no - other confirmation of identity than the ability to respond to a - verification email sent via SMTP ([RFC5321]) -- which generally uses - DNS for its routing. - - In other words, any party that (temporarily) controls the Domain Name - System is in a position to reroute most kinds of Internet - transactions, including the verification steps in acquiring an SSL/ - TLS certificate for a domain. This in turn means that even - transactions protected by SSL/TLS could be diverted. - - It is entirely conceivable that such rerouted traffic could be used - to the disadvantage of Internet users. - - These and other developments have made the security and - trustworthiness of DNS of renewed importance. Although the DNS - community is working hard on finalizing and implementing a - cryptographically enhanced DNS protocol, steps should be taken to - make sure that the existing use of DNS is as secure as possible - within the bounds of the relevant standards. - - It should be noted that the most commonly used resolvers currently do - not perform as well as possible in this respect, making this document - of urgent importance. - - A thorough analysis of risks facing DNS can be found in [RFC3833]. - - - - - -Hubert & van Mook Standards Track [Page 3] - -RFC 5452 DNS Resilience against Forged Answers January 2009 - - - This document expands on some of the risks mentioned in RFC 3833, - especially those outlined in the sections on "ID Guessing and Query - Prediction" and "Name Chaining". Furthermore, it emphasizes a number - of existing rules and guidelines embodied in the relevant DNS - protocol specifications. The following also specifies new - requirements to make sure the Domain Name System can be relied upon - until a more secure protocol has been standardized and deployed. - - It should be noted that even when all measures suggested below are - implemented, protocol users are not protected against third parties - with the ability to observe, modify, or inject packets in the traffic - of a resolver. - - For protocol extensions that offer protection against these - scenarios, see [RFC4033] and beyond. - -2. Requirements and Definitions - -2.1. Definitions - - This document uses the following definitions: - - Client: typically a 'stub-resolver' on an end-user's computer. - - Resolver: a nameserver performing recursive service for clients, - also known as a caching server, or a full service resolver - ([RFC1123], Section 6.1.3.1). - - Stub resolver: a very limited resolver on a client computer, that - leaves the recursing work to a full resolver. - - Query: a question sent out by a resolver, typically in a UDP - packet - - Response: the answer sent back by an authoritative nameserver, - typically in a UDP packet. - - Third party: any entity other than the resolver or the intended - recipient of a question. The third party may have access to an - arbitrary authoritative nameserver, but has no access to packets - transmitted by the resolver or authoritative server. - - Attacker: malicious third party. - - Spoof: the activity of attempting to subvert the DNS process by - getting a chosen answer accepted. - - - - - -Hubert & van Mook Standards Track [Page 4] - -RFC 5452 DNS Resilience against Forged Answers January 2009 - - - Authentic response: the correct answer that comes from the right - authoritative server. - - Target domain name: domain for which the attacker wishes to spoof - in an answer - - Fake data: response chosen by the attacker. - -2.2. Key Words - - 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]. - -3. Description of DNS Spoofing - - When certain steps are taken, it is feasible to "spoof" the current - deployed majority of resolvers with carefully crafted and timed DNS - packets. Once spoofed, a caching server will repeat the data it - wrongfully accepted, and make its clients contact the wrong, and - possibly malicious, servers. - - To understand how this process works it is important to know what - makes a resolver accept a response. - - The following sentence in Section 5.3.3 of [RFC1034] presaged the - present problem: - - The resolver should be highly paranoid in its parsing of responses. - It should also check that the response matches the query it sent - using the ID field in the response. - - DNS data is to be accepted by a resolver if and only if: - - 1. The question section of the reply packet is equivalent to that of - a question packet currently waiting for a response. - - 2. The ID field of the reply packet matches that of the question - packet. - - 3. The response comes from the same network address to which the - question was sent. - - 4. The response comes in on the same network address, including port - number, from which the question was sent. - - In general, the first response matching these four conditions is - accepted. - - - -Hubert & van Mook Standards Track [Page 5] - -RFC 5452 DNS Resilience against Forged Answers January 2009 - - - If a third party succeeds in meeting the four conditions before the - response from the authentic nameserver does so, it is in a position - to feed a resolver fabricated data. When it does so, we dub it an - "attacker", attempting to spoof in fake data. - - All conditions mentioned above can theoretically be met by a third - party, with the difficulty being a function of the resolver - implementation and zone configuration. - -4. Detailed Description of Spoofing Scenarios - - The previous paragraph discussed a number of requirements an attacker - must match in order to spoof in manipulated (or fake) data. This - section discusses the relative difficulties and how implementation- - defined choices impact the amount of work an attacker has to perform - to meet said difficulties. - - Some more details can be found in Section 2.2 of [RFC3833]. - -4.1. Forcing a Query - - Formally, there is no need for a nameserver to perform service except - for its operator, its customers, or more generally its users. - Recently, open recursing nameservers have been used to amplify - denial-of-service attacks. - - Providing full service enables the third party to send the target - resolver a query for the domain name it intends to spoof. On - receiving this query, and not finding the answer in its cache, the - resolver will transmit queries to relevant authoritative nameservers. - This opens up a window of opportunity for getting fake answer data - accepted. - - Queries may however be forced indirectly, for example, by inducing a - mail server to perform DNS lookups. - - Some operators restrict access by not recursing for unauthorized IP - addresses, but only respond with data from the cache. This makes - spoofing harder for a third party as it cannot then force the exact - moment a question will be asked. It is still possible however to - determine a time range when this will happen, because nameservers - helpfully publish the decreasing time to live (TTL) of entries in the - cache, which indicate from which absolute time onwards a new query - could be sent to refresh the expired entry. - - The time to live of the target domain name's RRSets determines how - often a window of opportunity is available, which implies that a - short TTL makes spoofing far more viable. - - - -Hubert & van Mook Standards Track [Page 6] - -RFC 5452 DNS Resilience against Forged Answers January 2009 - - - Note that the attacker might very well have authorized access to the - target resolver by virtue of being a customer or employee of its - operator. In addition, access may be enabled through the use of - reflectors as outlined in [RFC5358]. - -4.2. Matching the Question Section - - DNS packets, both queries and responses, contain a question section. - Incoming responses should be verified to have a question section that - is equivalent to that of the outgoing query. - -4.3. Matching the ID Field - - The DNS ID field is 16 bits wide, meaning that if full use is made of - all these bits, and if their contents are truly random, it will - require on average 32768 attempts to guess. Anecdotal evidence - suggests there are implementations utilizing only 14 bits, meaning on - average 8192 attempts will suffice. - - Additionally, if the target nameserver can be forced into having - multiple identical queries outstanding, the "Birthday Attack" - phenomenon means that any fake data sent by the attacker is matched - against multiple outstanding queries, significantly raising the - chance of success. Further details in Section 5. - -4.4. Matching the Source Address of the Authentic Response - - It should be noted that meeting this condition entails being able to - transmit packets on behalf of the address of the authoritative - nameserver. While two Best Current Practice documents ([RFC2827] and - [RFC3013] specifically) direct Internet access providers to prevent - their customers from assuming IP addresses that are not assigned to - them, these recommendations are not universally (nor even widely) - implemented. - - Many zones have two or three authoritative nameservers, which make - matching the source address of the authentic response very likely - with even a naive choice having a double digit success rate. - - Most recursing nameservers store relative performance indications of - authoritative nameservers, which may make it easier to predict which - nameserver would originally be queried -- the one most likely to - respond the quickest. - - Generally, this condition requires at most two or three attempts - before it is matched. - - - - - -Hubert & van Mook Standards Track [Page 7] - -RFC 5452 DNS Resilience against Forged Answers January 2009 - - -4.5. Matching the Destination Address and Port of the Authentic - Response - - Note that the destination address of the authentic response is the - source address of the original query. - - The actual address of a recursing nameserver is generally known; the - port used for asking questions is harder to determine. Most current - resolvers pick an arbitrary port at startup (possibly at random) and - use this for all outgoing queries. In quite a number of cases, the - source port of outgoing questions is fixed at the traditional DNS - assigned server port number of 53. - - If the source port of the original query is random, but static, any - authoritative nameserver under observation by the attacker can be - used to determine this port. This means that matching this - conditions often requires no guess work. - - If multiple ports are used for sending queries, this enlarges the - effective ID space by a factor equal to the number of ports used. - - Less common resolving servers choose a random port per outgoing - query. If this strategy is followed, this port number can be - regarded as an additional ID field, again containing up to 16 bits. - - If the maximum ports range is utilized, on average, around 32256 - source ports would have to be tried before matching the source port - of the original query, as ports below 1024 may be unavailable for - use, leaving 64512 options. - - It is in general safe for DNS to use ports in the range 1024-49152 - even though some of these ports are allocated to other protocols. - DNS resolvers will not be able to use any ports that are already in - use. If a DNS resolver uses a port, it will release that port after - a short time and migrate to a different port. Only in the case of a - high-volume resolver is it possible that an application wanting a - particular UDP port suffers a long term block-out. - - It should be noted that a firewall will not prevent the matching of - this address, as it will accept answers that (appear to) come from - the correct address, offering no additional security. - -4.6. Have the Response Arrive before the Authentic Response - - Once any packet has matched the previous four conditions (plus - possible additional conditions), no further responses are generally - accepted. - - - - -Hubert & van Mook Standards Track [Page 8] - -RFC 5452 DNS Resilience against Forged Answers January 2009 - - - This means that the third party has a limited time in which to inject - its spoofed response. For calculations, we will assume a window in - order of at most 100 ms (depending on the network distance to the - authentic authoritative nameserver). - - This time period can be far longer if the authentic authoritative - nameservers are (briefly) overloaded by queries, perhaps by the - attacker. - -5. Birthday Attacks - - The so-called "birthday paradox" implies that a group of 23 people - suffices to have a more than even chance of having two or more - members of the group share a birthday. - - An attacker can benefit from this exact phenomenon if it can force - the target resolver to have multiple equivalent (identical QNAME, - QTYPE, and QCLASS) outstanding queries at any one time to the same - authoritative server. - - Any packet the attacker sends then has a much higher chance of being - accepted because it only has to match any of the outstanding queries - for that single domain. Compared to the birthday analogy above, of - the group composed of queries and responses, the chance of having any - of these share an ID rises quickly. - - As long as small numbers of queries are sent out, the chance of - successfully spoofing a response rises linearly with the number of - outstanding queries for the exact domain and nameserver. - - For larger numbers, this effect is less pronounced. - - More details are available in US-CERT [vu-457875]. - -6. Accepting Only In-Domain Records - - Responses from authoritative nameservers often contain information - that is not part of the zone for which we deem it authoritative. As - an example, a query for the MX record of a domain might get as its - responses a mail exchanger in another domain, and additionally the IP - address of this mail exchanger. - - If accepted uncritically, the resolver stands the chance of accepting - data from an untrusted source. Care must be taken to only accept - data if it is known that the originator is authoritative for the - QNAME or a parent of the QNAME. - - - - - -Hubert & van Mook Standards Track [Page 9] - -RFC 5452 DNS Resilience against Forged Answers January 2009 - - - One very simple way to achieve this is to only accept data if it is - part of the domain for which the query was intended. - -7. Combined Difficulty - - Given a known or static destination port, matching ID field, the - source and destination address requires on average in the order of 2 - * 2^15 = 65000 packets, assuming a zone has 2 authoritative - nameservers. - - If the window of opportunity available is around 100 ms, as assumed - above, an attacker would need to be able to briefly transmit 650000 - packets/s to have a 50% chance to get spoofed data accepted on the - first attempt. - - A realistic minimal DNS response consists of around 80 bytes, - including IP headers, making the packet rate above correspond to a - respectable burst of 416 Mbit/s. - - As of mid-2006, this kind of bandwidth was not common but not scarce - either, especially among those in a position to control many servers. - - These numbers change when a window of a full second is assumed, - possibly because the arrival of the authentic response can be - prevented by overloading the bona fide authoritative hosts with decoy - queries. This reduces the needed bandwidth to 42 Mbit/s. - - If, in addition, the attacker is granted more than a single chance - and allowed up to 60 minutes of work on a domain with a time to live - of 300 seconds, a meager 4 Mbit/s suffices for a 50% chance at - getting fake data accepted. Once equipped with a longer time, - matching condition 1 mentioned above is straightforward -- any - popular domain will have been queried a number of times within this - hour, and given the short TTL, this would lead to queries to - authoritative nameservers, opening windows of opportunity. - -7.1. Symbols Used in Calculation - - Assume the following symbols are used: - - I: Number distinct IDs available (maximum 65536) - - P: Number of ports used (maximum around 64000 as ports under 1024 are - not always available, but often 1) - - N: Number of authoritative nameservers for a domain (averages around - 2.5) - - - - -Hubert & van Mook Standards Track [Page 10] - -RFC 5452 DNS Resilience against Forged Answers January 2009 - - - F: Number of "fake" packets sent by the attacker - - R: Number of packets sent per second by the attacker - - W: Window of opportunity, in seconds. Bounded by the response time - of the authoritative servers (often 0.1s) - - D: Average number of identical outstanding queries of a resolver - (typically 1, see Section 5) - - A: Number of attempts, one for each window of opportunity - -7.2. Calculation - - The probability of spoofing a resolver is equal to the amount of fake - packets that arrive within the window of opportunity, divided by the - size of the problem space. - - When the resolver has 'D' multiple identical outstanding queries, - each fake packet has a proportionally higher chance of matching any - of these queries. This assumption only holds for small values of - 'D'. - - In symbols, if the probability of being spoofed is denoted as P_s: - - D * F - P_s = --------- - N * P * I - - It is more useful to reason not in terms of aggregate packets but to - convert to packet rate, which can easily be converted to bandwidth if - needed. - - If the window of opportunity length is 'W' and the attacker can send - 'R' packets per second, the number of fake packets 'F' that are - candidates to be accepted is: - - D * R * W - F = R * W -> P_s = --------- - N * P * I - - Finally, to calculate the combined chance 'P_cs' of spoofing over a - chosen time period 'T', it should be realized that the attacker has a - new window of opportunity each time the TTL 'TTL' of the target - domain expires. This means that the number of attempts 'A' is equal - to 'T / TTL'. - - - - - -Hubert & van Mook Standards Track [Page 11] - -RFC 5452 DNS Resilience against Forged Answers January 2009 - - - To calculate the combined chance of at least one success, the - following formula holds: - - (T / TTL) - A ( D * R * W ) - P_cs = 1 - ( 1 - P_s ) = 1 - ( 1 - --------- ) - ( N * P * I ) - - When common numbers (as listed above) for D, W, N, P, and I are - inserted, this formula reduces to: - - (T / TTL) - ( R ) - P_cs = 1 - ( 1 - ------- ) - ( 1638400 ) - - From this formula, it can be seen that, if the nameserver - implementation is unchanged, only raising the TTL offers protection. - Raising N, the number of authoritative nameservers, is not feasible - beyond a small number. - - For the degenerate case of a zero-second TTL, a window of opportunity - opens for each query sent, making the effective TTL equal to 'W' - above, the response time of the authoritative server. - - This last case also holds for spoofing techniques that do not rely on - TTL expiry, but use repeated and changing queries. - -8. Discussion - - The calculations above indicate the relative ease with which DNS data - can be spoofed. For example, using the formula derived earlier on an - RRSet with a 3600 second TTL, an attacker sending 7000 fake response - packets/s (a rate of 4.5 Mbit/s), stands a 10% chance of spoofing a - record in the first 24 hours, which rises to 50% after a week. - - For an RRSet with a TTL of 60 seconds, the 10% level is hit after 24 - minutes, 50% after less than 3 hours, 90% after around 9 hours. - - For some classes of attacks, the effective TTL is near zero, as noted - above. - - Note that the attacks mentioned above can be detected by watchful - server operators - an unexpected incoming stream of 4.5 Mbit/s of - packets might be noticed. - - An important assumption however in these calculations is a known or - static destination port of the authentic response. - - - -Hubert & van Mook Standards Track [Page 12] - -RFC 5452 DNS Resilience against Forged Answers January 2009 - - - If that port number is unknown and needs to be guessed as well, the - problem space expands by a factor of 64000, leading the attacker to - need in excess of 285Gb/s to achieve similar success rates. - - Such bandwidth is not generally available, nor is it expected to be - so in the foreseeable future. - - Note that some firewalls may need reconfiguring if they are currently - set up to only allow outgoing queries from a single DNS source port. - -8.1. Repetitive Spoofing Attempts for a Single Domain Name - - Techniques are available to use an effectively infinite number of - queries to achieve a desired spoofing goal. In the math above, this - reduces the effective TTL to 0. - - If such techniques are employed, using the same 7000 packets/s rate - mentioned above, and using 1 source port, the spoofing chance rises - to 50% within 7 seconds. - - If 64000 ports are used, as recommended in this document, using the - same query rate, the 50% level is reached after around 116 hours. - -9. Forgery Countermeasures - -9.1. Query Matching Rules - - A resolver implementation MUST match responses to all of the - following attributes of the query: - - o Source address against query destination address - - o Destination address against query source address - - o Destination port against query source port - - o Query ID - - o Query name - - o Query class and type - - before applying DNS trustworthiness rules (see Section 5.4.1 of - [RFC2181]). - - A mismatch and the response MUST be considered invalid. - - - - - -Hubert & van Mook Standards Track [Page 13] - -RFC 5452 DNS Resilience against Forged Answers January 2009 - - -9.2. Extending the Q-ID Space by Using Ports and Addresses - - Resolver implementations MUST: - - o Use an unpredictable source port for outgoing queries from the - range of available ports (53, or 1024 and above) that is as large - as possible and practicable; - - o Use multiple different source ports simultaneously in case of - multiple outstanding queries; - - o Use an unpredictable query ID for outgoing queries, utilizing the - full range available (0-65535). - - Resolvers that have multiple IP addresses SHOULD use them in an - unpredictable manner for outgoing queries. - - Resolver implementations SHOULD provide means to avoid usage of - certain ports. - - Resolvers SHOULD favor authoritative nameservers with which a trust - relation has been established; stub-resolvers SHOULD be able to use - Transaction Signature (TSIG) ([RFC2845]) or IPsec ([RFC4301]) when - communicating with their recursive resolver. - - In case a cryptographic verification of response validity is - available (TSIG, SIG(0)), resolver implementations MAY waive above - rules, and rely on this guarantee instead. - - Proper unpredictability can be achieved by employing a high quality - (pseudo-)random generator, as described in [RFC4086]. - -9.2.1. Justification and Discussion - - Since an attacker can force a full DNS resolver to send queries to - the attacker's own nameservers, any constant or sequential state held - by such a resolver can be measured, and it must not be trivially easy - to reverse engineer the resolver's internal state in a way that - allows low-cost, high-accuracy prediction of future state. - - A full DNS resolver with only one or a small number of upstream- - facing endpoints is effectively using constants for IP source address - and UDP port number, and these are very predictable by potential - attackers, and must therefore be avoided. - - A full DNS resolver that uses a simple increment to get its next DNS - query ID is likewise very predictable and so very spoofable. - - - - -Hubert & van Mook Standards Track [Page 14] - -RFC 5452 DNS Resilience against Forged Answers January 2009 - - - Finally, weak random number generators have been shown to expose - their internal state, such that an attacker who witnesses several - sequential "random" values can easily predict the next ones. A - crypto-strength random number generator is one whose output cannot be - predicted no matter how many successive values are witnessed. - -9.3. Spoof Detection and Countermeasure - - If a resolver detects that an attempt is being made to spoof it, - perhaps by discovering that many packets fail the criteria as - outlined above, it MAY abandon the UDP query and re-issue it over - TCP. TCP, by the nature of its use of sequence numbers, is far more - resilient against forgery by third parties. - -10. Security Considerations - - This document provides clarification of the DNS specification to - decrease the probability that DNS responses can be successfully - forged. Recommendations found above should be considered - complementary to possible cryptographical enhancements of the domain - name system, which protect against a larger class of attacks. - - This document recommends the use of UDP source port number - randomization to extend the effective DNS transaction ID beyond the - available 16 bits. - - A resolver that does not implement the recommendations outlined above - can easily be forced to accept spoofed responses, which in turn are - passed on to client computers -- misdirecting (user) traffic to - possibly malicious entities. - - This document directly impacts the security of the Domain Name - System, implementers are urged to follow its recommendations. - - Most security considerations can be found in Sections 4 and 5, while - proposed countermeasures are described in Section 9. - - For brevity's sake, in lieu of repeating the security considerations - references, the reader is referred to these sections. - - Nothing in this document specifies specific algorithms for operators - to use; it does specify algorithms implementations SHOULD or MUST - support. - - It should be noted that the effects of source port randomization may - be dramatically reduced by NAT devices that either serialize or limit - in volume the UDP source ports used by the querying resolver. - - - - -Hubert & van Mook Standards Track [Page 15] - -RFC 5452 DNS Resilience against Forged Answers January 2009 - - - DNS recursive servers sitting behind at NAT or a statefull firewall - may consume all available NAT translation entries/ports when - operating under high query load. Port randomization will cause - translation entries to be consumed faster than with fixed query port. - - To avoid this, NAT boxes and statefull firewalls can/should purge - outgoing DNS query translation entries 10-17 seconds after the last - outgoing query on that mapping was sent. [RFC4787]-compliant devices - need to treat UDP messages with port 53 differently than most other - UDP protocols. - - To minimize the potential that port/state exhaustion attacks can be - staged from the outside, it is recommended that services that - generate a number of DNS queries for each connection should be rate - limited. This applies in particular to email servers. - -11. Acknowledgments - - Source port randomization in DNS was first implemented and possibly - invented by Dan J. Bernstein. - - Although any mistakes remain our own, the authors gratefully - acknowledge the help and contributions of: - Stephane Bortzmeyer - Alfred Hoenes - Peter Koch - Sean Leach - Norbert Sendetzky - Paul Vixie - Florian Weimer - Wouter Wijngaards - Dan Wing - -12. References - -12.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. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - - -Hubert & van Mook Standards Track [Page 16] - -RFC 5452 DNS Resilience against Forged Answers January 2009 - - - [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: - Defeating Denial of Service Attacks which employ IP - Source Address Spoofing", BCP 38, RFC 2827, May 2000. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. - Wellington, "Secret Key Transaction Authentication for - DNS (TSIG)", RFC 2845, May 2000. - - [RFC3013] Killalea, T., "Recommended Internet Service Provider - Security Services and Procedures", BCP 46, RFC 3013, - November 2000. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness - Requirements for Security", BCP 106, RFC 4086, - June 2005. - - [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, - October 2008. - -12.2. Informative References - - [RFC1123] Braden, R., "Requirements for Internet Hosts - - Application and Support", STD 3, RFC 1123, October 1989. - - [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the - Domain Name System (DNS)", RFC 3833, August 2004. - - [RFC4301] Kent, S. and K. Seo, "Security Architecture for the - Internet Protocol", RFC 4301, December 2005. - - [RFC4787] Audet, F. and C. Jennings, "Network Address Translation - (NAT) Behavioral Requirements for Unicast UDP", BCP 127, - RFC 4787, January 2007. - - [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive - Nameservers in Reflector Attacks", BCP 140, RFC 5358, - October 2008. - - [vu-457875] United States CERT, "Various DNS service implementations - generate multiple simultaneous queries for the same - resource record", VU 457875, November 2002. - - - - - - -Hubert & van Mook Standards Track [Page 17] - -RFC 5452 DNS Resilience against Forged Answers January 2009 - - -Authors' Addresses - - Bert Hubert - Netherlabs Computer Consulting BV. - Braillelaan 10 - Rijswijk (ZH) 2289 CM - The Netherlands - - EMail: bert.hubert@netherlabs.nl - - - Remco van Mook - Equinix - Auke Vleerstraat 1 - Enschede 7521 PE - The Netherlands - - EMail: remco@eu.equinix.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hubert & van Mook Standards Track [Page 18] - diff --git a/doc/rfc/rfc5625.txt b/doc/rfc/rfc5625.txt deleted file mode 100644 index 102d7e8770e..00000000000 --- a/doc/rfc/rfc5625.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -Network Working Group R. Bellis -Request for Comments: 5625 Nominet UK -BCP: 152 August 2009 -Category: Best Current Practice - - - DNS Proxy Implementation Guidelines - -Abstract - - This document provides guidelines for the implementation of DNS - proxies, as found in broadband gateways and other similar network - devices. - -Status of This Memo - - This document specifies an Internet Best Current Practices for the - Internet Community, and requests discussion and suggestions for - improvements. Distribution of this memo is unlimited. - -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. - - - - - - - - - - - - - - - - - - - - - -Bellis Best Current Practice [Page 1] - -RFC 5625 DNS Proxy Implementation Guidelines August 2009 - - -Table of Contents - - 1. Introduction ....................................................2 - 2. Terminology .....................................................3 - 3. The Transparency Principle ......................................3 - 4. Protocol Conformance ............................................4 - 4.1. Unexpected Flags and Data ..................................4 - 4.2. Label Compression ..........................................4 - 4.3. Unknown Resource Record Types ..............................4 - 4.4. Packet Size Limits .........................................4 - 4.4.1. TCP Transport .......................................5 - 4.4.2. Extension Mechanisms for DNS (EDNS0) ................6 - 4.4.3. IP Fragmentation ....................................6 - 4.5. Secret Key Transaction Authentication for DNS (TSIG) .......7 - 5. DHCP's Interaction with DNS .....................................7 - 5.1. Domain Name Server (DHCP Option 6) .........................7 - 5.2. Domain Name (DHCP Option 15) ...............................8 - 5.3. DHCP Leases ................................................8 - 6. Security Considerations .........................................9 - 6.1. Forgery Resilience .........................................9 - 6.2. Interface Binding .........................................10 - 6.3. Packet Filtering ..........................................10 - 7. Acknowledgements ...............................................10 - 8. References .....................................................11 - 8.1. Normative References ......................................11 - 8.2. Informative References ....................................12 - -1. Introduction - - Research has found ([SAC035], [DOTSE]) that many commonly used - broadband gateways (and similar devices) contain DNS proxies that are - incompatible in various ways with current DNS standards. - - These proxies are usually simple DNS forwarders, but typically do not - have any caching capabilities. The proxy serves as a convenient - default DNS resolver for clients on the LAN, but relies on an - upstream resolver (e.g., at an ISP) to perform recursive DNS lookups. - - Note that to ensure full DNS protocol interoperability it is - preferred that client stub resolvers should communicate directly with - full-feature, upstream recursive resolvers wherever possible. - - That notwithstanding, this document describes the incompatibilities - that have been discovered and offers guidelines to implementors on - how to provide better interoperability in those cases where the - client must use the broadband gateway's DNS proxy. - - - - - -Bellis Best Current Practice [Page 2] - -RFC 5625 DNS Proxy Implementation Guidelines August 2009 - - -2. Terminology - - 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]. - -3. The Transparency Principle - - It is not considered practical for a simple DNS proxy to implement - all current and future DNS features. - - There are several reasons why this is the case: - - o Broadband gateways usually have limited hardware resources. - - o Firmware upgrade cycles are long, and many users do not routinely - apply upgrades when they become available. - - o No one knows what those future DNS features will be or how they - might be implemented. - - o Doing so would substantially complicate the configuration user - interface (UI) of the device. - - Furthermore, some modern DNS protocol extensions (see, e.g., EDNS0 - below) are intended to be used as "hop-by-hop" mechanisms. If the - DNS proxy is considered to be such a "hop" in the resolution chain, - then for it to function correctly, it would need to be fully - compliant with all such mechanisms. - - [SAC035] shows that the more actively a proxy participates in the DNS - protocol, the more likely it is that it will somehow interfere with - the flow of messages between the DNS client and the upstream - recursive resolvers. - - The role of the proxy should therefore be no more and no less than to - receive DNS requests from clients on the LAN side, forward those - verbatim to one of the known upstream recursive resolvers on the WAN - side, and ensure that the whole response is returned verbatim to the - original client. - - It is RECOMMENDED that proxies should be as transparent as possible, - such that any "hop-by-hop" mechanisms or newly introduced protocol - extensions operate as if the proxy were not there. - - Except when required to enforce an active security or network policy - (such as maintaining a pre-authentication "walled garden"), end-users - SHOULD be able to send their DNS queries to specified upstream - - - -Bellis Best Current Practice [Page 3] - -RFC 5625 DNS Proxy Implementation Guidelines August 2009 - - - resolvers, thereby bypassing the proxy altogether. In this case, the - gateway SHOULD NOT modify the DNS request or response packets in any - way. - -4. Protocol Conformance - -4.1. Unexpected Flags and Data - - The Transparency Principle above, when combined with Postel's - Robustness Principle [RFC0793], suggests that DNS proxies should not - arbitrarily reject or otherwise drop requests or responses based on - perceived non-compliance with standards. - - For example, some proxies have been observed to drop any packet - containing either the "Authentic Data" (AD) or "Checking Disabled" - (CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035] - originally specified that these unused "Z" flag bits "MUST" be zero. - However, these flag bits were always intended to be reserved for - future use, so refusing to proxy any packet containing these flags - (now that uses for those flags have indeed been defined) is not - appropriate. - - Therefore, proxies MUST ignore any unknown DNS flags and proxy those - packets as usual. - -4.2. Label Compression - - Compression of labels as per Section 4.1.4 of [RFC1035] is optional. - - Proxies MUST forward packets regardless of the presence or absence of - compressed labels therein. - -4.3. Unknown Resource Record Types - - [RFC3597] requires that resolvers MUST handle Resource Records (RRs) - of unknown type transparently. - - All requests and responses MUST be proxied regardless of the values - of the QTYPE and QCLASS fields. - - Similarly, all responses MUST be proxied regardless of the values of - the TYPE and CLASS fields of any Resource Record therein. - -4.4. Packet Size Limits - - [RFC1035] specifies that the maximum size of the DNS payload in a UDP - packet is 512 octets. Where the required portions of a response - would not fit inside that limit, the DNS server MUST set the - - - -Bellis Best Current Practice [Page 4] - -RFC 5625 DNS Proxy Implementation Guidelines August 2009 - - - "TrunCation" (TC) bit in the DNS response header to indicate that - truncation has occurred. There are however two standard mechanisms - (described in Sections 4.4.1 and 4.4.2) for transporting responses - larger than 512 octets. - - Many proxies have been observed to truncate all responses at 512 - octets, and others at a packet size related to the WAN MTU, in either - case doing so without correctly setting the TC bit. - - Other proxies have been observed to remove the TC bit in server - responses that correctly had the TC bit set by the server. - - If a DNS response is truncated but the TC bit is not set, then client - failures may result. In particular, a naive DNS client library might - suffer crashes due to reading beyond the end of the data actually - received. - - Since UDP packets larger than 512 octets are now expected in normal - operation, proxies SHOULD NOT truncate UDP packets that exceed that - size. See Section 4.4.3 for recommendations for packet sizes - exceeding the WAN MTU. - - If a proxy must unilaterally truncate a response, then the proxy MUST - set the TC bit. Similarly, proxies MUST NOT remove the TC bit from - responses. - -4.4.1. TCP Transport - - Should a UDP query fail because of truncation, the standard fail-over - mechanism is to retry the query using TCP, as described in Section - 6.1.3.2 of [RFC1123]. - - Whilst TCP transport is not strictly mandatory, it is supported by - the vast majority of stub resolvers and recursive servers. Lack of - support in the proxy prevents this fail-over mechanism from working. - - DNS proxies MUST therefore be prepared to receive and forward queries - over TCP. - - Note that it is unlikely that a client would send a request over TCP - unless it had already received a truncated UDP response. Some - "smart" proxies have been observed to first forward any request - received over TCP to an upstream resolver over UDP, only for the - response to be truncated, causing the proxy to retry over TCP. Such - behaviour increases network traffic and causes delay in DNS - resolution since the initial UDP request is doomed to fail. - - - - - -Bellis Best Current Practice [Page 5] - -RFC 5625 DNS Proxy Implementation Guidelines August 2009 - - - Therefore, whenever a proxy receives a request over TCP, the proxy - SHOULD forward the query over TCP and SHOULD NOT attempt the same - query over UDP first. - -4.4.2. Extension Mechanisms for DNS (EDNS0) - - The "Extension Mechanism for DNS" [RFC2671] was introduced to allow - the transport of larger DNS packets over UDP and also to allow for - additional request and response flags. - - A client may send an OPT Resource Record (OPT RR) in the Additional - Section of a request to indicate that it supports a specific receive - buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used - by DNSSEC to indicate that DNSSEC-related RRs should be returned to - the client. - - However, some proxies have been observed to either reject (with a - FORMERR response code) or black-hole any packet containing an OPT RR. - As per Section 4.1, proxies MUST NOT refuse to proxy such packets. - -4.4.3. IP Fragmentation - - Support for UDP packet sizes exceeding the WAN MTU depends on the - gateway's algorithm for handling fragmented IP packets. Several - methods are possible: - - 1. Fragments are dropped. - - 2. Fragments are forwarded individually as they're received. - - 3. Complete packets are reassembled on the gateway and then re- - fragmented (if necessary) as they're forwarded to the client. - - Method 1 above will cause compatibility problems with EDNS0 unless - the DNS client is configured to advertise an EDNS0 buffer size - limited to the WAN MTU less the size of the IP header. Note that RFC - 2671 does recommend that the path MTU should be taken into account - when using EDNS0. - - Also, whilst the EDNS0 specification allows for a buffer size of up - to 65535 octets, most common DNS server implementations do not - support a buffer size above 4096 octets. - - Therefore (irrespective of which of the above methods is in use), - proxies SHOULD be capable of forwarding UDP packets up to a payload - size of at least 4096 octets. - - - - - -Bellis Best Current Practice [Page 6] - -RFC 5625 DNS Proxy Implementation Guidelines August 2009 - - - NB: in theory, IP fragmentation may also occur if the LAN MTU is - smaller than the WAN MTU, although the author has not observed such a - configuration in use on any residential broadband service. - -4.5. Secret Key Transaction Authentication for DNS (TSIG) - - [RFC2845] defines TSIG, which is a mechanism for authenticating DNS - requests and responses at the packet level. - - Any modifications made to the DNS portions of a TSIG-signed query or - response packet (with the exception of the Query ID) will cause a - TSIG authentication failure. - - DNS proxies MUST implement Section 4.7 of [RFC2845] and either - forward packets unchanged (as recommended above) or fully implement - TSIG. - - As per Section 4.3, DNS proxies MUST be capable of proxying packets - containing TKEY [RFC2930] Resource Records. - - NB: any DNS proxy (such as those commonly found in WiFi hotspot - "walled gardens") that transparently intercepts all DNS queries and - that returns unsigned responses to signed queries, will also cause - TSIG authentication failures. - -5. DHCP's Interaction with DNS - - Whilst this document is primarily about DNS proxies, most consumers - rely on DHCP [RFC2131] to obtain network configuration settings. - Such settings include the client machine's IP address, subnet mask, - and default gateway, but also include DNS-related settings. - - It is therefore appropriate to examine how DHCP affects client DNS - configuration. - -5.1. Domain Name Server (DHCP Option 6) - - Most gateways default to supplying their own IP address in the DHCP - "Domain Name Server" option [RFC2132]. The net result is that - without explicit re-configuration many DNS clients will, by default, - send queries to the gateway's DNS proxy. This is understandable - behaviour given that the correct upstream settings are not usually - known at boot time. - - - - - - - - -Bellis Best Current Practice [Page 7] - -RFC 5625 DNS Proxy Implementation Guidelines August 2009 - - - Most gateways learn their own DNS settings via values supplied by an - ISP via DHCP or PPP over the WAN interface. However, whilst many - gateways do allow the device administrator to override those values, - some gateways only use those supplied values to affect the proxy's - own forwarding function, and do not offer these values via DHCP. - - When using such a device, the only way to avoid using the DNS proxy - is to hard-code the required values in the client operating system. - This may be acceptable for a desktop system but it is inappropriate - for mobile devices that are regularly used on many different - networks. - - As per Section 3, end-users SHOULD be able to send their DNS queries - directly to specified upstream resolvers, ideally without hard-coding - those settings in their stub resolver. - - It is therefore RECOMMENDED that gateways SHOULD support device- - administrator configuration of values for the "Domain Name Server" - DHCP option. - -5.2. Domain Name (DHCP Option 15) - - A significant amount of traffic to the DNS Root Name Servers is for - invalid top-level domain names, and some of that traffic can be - attributed to particular equipment vendors whose firmware defaults - this DHCP option to specific values. - - Since no standard exists for a "local" scoped domain name suffix, it - is RECOMMENDED that the default value for this option SHOULD be - empty, and that this option MUST NOT be sent to clients when no value - is configured. - -5.3. DHCP Leases - - It is noted that some DHCP servers in broadband gateways offer, by - default, their own IP address for the "Domain Name Server" option (as - described above) but then automatically start offering the upstream - servers' addresses once they've been learnt over the WAN interface. - - In general, this behaviour is highly desirable, but the effect for - the end-user is that the settings used depend on whether the DHCP - lease was obtained before or after the WAN link was established. - - If the DHCP lease is obtained whilst the WAN link is down, then the - DHCP client (and hence the DNS client) will not receive the correct - values until the DHCP lease is renewed. - - - - - -Bellis Best Current Practice [Page 8] - -RFC 5625 DNS Proxy Implementation Guidelines August 2009 - - - Whilst no specific recommendations are given here, vendors may wish - to give consideration to the length of DHCP leases and to whether - some mechanism for forcing a DHCP lease renewal might be appropriate. - - Another possibility is that the learnt upstream values might be - persisted in non-volatile memory such that on reboot the same values - can be automatically offered via DHCP. However, this does run the - risk that incorrect values are initially offered if the device is - moved or connected to another ISP. - - Alternatively, the DHCP server might only issue very short (i.e., 60 - second) leases while the WAN link is down, only reverting to more - typical lease lengths once the WAN link is up and the upstream DNS - servers are known. Indeed, with such a configuration it may be - possible to avoid the need to implement a DNS proxy function in the - broadband gateway at all. - -6. Security Considerations - - This document introduces no new protocols. However, there are some - security-related recommendations for vendors that are listed here. - -6.1. Forgery Resilience - - Whilst DNS proxies are not usually full-feature resolvers, they - nevertheless share some characteristics with them. - - Notwithstanding the recommendations above about transparency, many - DNS proxies are observed to pick a new Query ID for outbound requests - to ensure that responses are directed to the correct client. - - NB: changing the Query ID is acceptable and compatible with proxying - TSIG-signed packets since the TSIG signature calculation is based on - the original message ID, which is carried in the TSIG RR. - - It has been standard guidance for many years that each DNS query - should use a randomly generated Query ID. However, many proxies have - been observed picking sequential Query IDs for successive requests. - - It is strongly RECOMMENDED that DNS proxies follow the relevant - recommendations in [RFC5452], particularly those in Section 9.2 - relating to randomisation of Query IDs and source ports. This also - applies to source port selection within any NAT function. - - If a DNS proxy is running on a broadband gateway with NAT that is - compliant with [RFC4787], then it SHOULD also follow the - recommendations in Section 10 of [RFC5452] concerning how long DNS - state is kept. - - - -Bellis Best Current Practice [Page 9] - -RFC 5625 DNS Proxy Implementation Guidelines August 2009 - - -6.2. Interface Binding - - Some gateways have been observed to have their DNS proxy listening on - both internal (LAN) and external (WAN) interfaces. In this - configuration, it is possible for the proxy to be used to mount - reflector attacks as described in [RFC5358]. - - The DNS proxy in a gateway SHOULD NOT, by default, be accessible from - the WAN interfaces of the device. - -6.3. Packet Filtering - - The Transparency and Robustness Principles are not entirely - compatible with the deep packet-inspection features of security - appliances such as firewalls, which are intended to protect systems - on the inside of a network from rogue traffic. - - However, a clear distinction may be made between traffic that is - intrinsically malformed and that which merely contains unexpected - data. - - Examples of malformed packets that MAY be dropped include: - - o invalid compression pointers (i.e., those that point outside of - the current packet or that might cause a parsing loop) - - o incorrect counts for the Question, Answer, Authority, and - Additional Sections (although care should be taken where - truncation is a possibility) - - Dropped packets will cause the client to repeatedly retransmit the - original request, with the client only detecting the error after - several retransmit intervals. - - In these circumstances, proxies SHOULD synthesise a suitable DNS - error response to the client (i.e., SERVFAIL) instead of dropping the - packet completely. This will allow the client to detect the error - immediately. - -7. Acknowledgements - - The author would particularly like to acknowledge the assistance of - Lisa Phifer of Core Competence. In addition, the author is grateful - for the feedback from the members of the DNSEXT Working Group. - - - - - - - -Bellis Best Current Practice [Page 10] - -RFC 5625 DNS Proxy Implementation Guidelines August 2009 - - -8. References - -8.1. Normative References - - [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, - RFC 793, September 1981. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1123] Braden, R., "Requirements for Internet Hosts - Application - and Support", STD 3, RFC 1123, October 1989. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", - RFC 2131, March 1997. - - [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor - Extensions", RFC 2132, March 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC4787] Audet, F. and C. Jennings, "Network Address Translation - (NAT) Behavioral Requirements for Unicast UDP", BCP 127, - RFC 4787, January 2007. - - [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive - Nameservers in Reflector Attacks", BCP 140, RFC 5358, - October 2008. - - - - - -Bellis Best Current Practice [Page 11] - -RFC 5625 DNS Proxy Implementation Guidelines August 2009 - - - [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More - Resilient against Forged Answers", RFC 5452, January 2009. - -8.2. Informative References - - [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband - Routers", February 2008, - . - - [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on - Broadband Routers and Firewalls", September 2008, - . - -Author's Address - - Ray Bellis - Nominet UK - Edmund Halley Road - Oxford OX4 4DQ - United Kingdom - - Phone: +44 1865 332211 - EMail: ray.bellis@nominet.org.uk - URI: http://www.nominet.org.uk/ - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bellis Best Current Practice [Page 12] - diff --git a/doc/rfc/rfc5702.txt b/doc/rfc/rfc5702.txt deleted file mode 100644 index 5155cc6440c..00000000000 --- a/doc/rfc/rfc5702.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -Network Working Group J. Jansen -Request for Comments: 5702 NLnet Labs -Category: Standards Track October 2009 - - - Use of SHA-2 Algorithms with RSA in - DNSKEY and RRSIG Resource Records for DNSSEC - -Abstract - - This document describes how to produce RSA/SHA-256 and RSA/SHA-512 - DNSKEY and RRSIG resource records for use in the Domain Name System - Security Extensions (RFC 4033, RFC 4034, and RFC 4035). - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -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. - - - - - - - - - - - - - - - -Jansen Standards Track [Page 1] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - -Table of Contents - - 1. Introduction ....................................................2 - 2. DNSKEY Resource Records .........................................3 - 2.1. RSA/SHA-256 DNSKEY Resource Records ........................3 - 2.2. RSA/SHA-512 DNSKEY Resource Records ........................3 - 3. RRSIG Resource Records ..........................................3 - 3.1. RSA/SHA-256 RRSIG Resource Records .........................4 - 3.2. RSA/SHA-512 RRSIG Resource Records .........................4 - 4. Deployment Considerations .......................................5 - 4.1. Key Sizes ..................................................5 - 4.2. Signature Sizes ............................................5 - 5. Implementation Considerations ...................................5 - 5.1. Support for SHA-2 Signatures ...............................5 - 5.2. Support for NSEC3 Denial of Existence ......................5 - 6. Examples ........................................................6 - 6.1. RSA/SHA-256 Key and Signature ..............................6 - 6.2. RSA/SHA-512 Key and Signature ..............................7 - 7. IANA Considerations .............................................8 - 8. Security Considerations .........................................8 - 8.1. SHA-1 versus SHA-2 Considerations for RRSIG - Resource Records ...........................................8 - 8.2. Signature Type Downgrade Attacks ...........................8 - 9. Acknowledgments .................................................9 - 10. References .....................................................9 - 10.1. Normative References ......................................9 - 10.2. Informative References ....................................9 - -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. [RFC4033], [RFC4034], and - [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 algorithms RSA/SHA-256 and RSA/ - SHA-512, and specifies how to store DNSKEY data and how to produce - RRSIG resource records with these hash algorithms. - - Familiarity with DNSSEC, RSA, and the SHA-2 [FIPS.180-3.2008] family - of algorithms is assumed in this document. - - - - - - - -Jansen Standards Track [Page 2] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - - To refer to both SHA-256 and SHA-512, this document will use the name - SHA-2. This is done to improve readability. When a part of text is - specific for either SHA-256 or SHA-512, their specific names are - used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be - grouped using the name RSA/SHA-2. - - The term "SHA-2" is not officially defined but is usually used to - refer to the collection of the algorithms SHA-224, SHA-256, SHA-384, - and SHA-512. Since SHA-224 and SHA-384 are not used in DNSSEC, SHA-2 - will only refer to SHA-256 and SHA-512 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]. - -2. DNSKEY Resource Records - - The format of the DNSKEY RR can be found in [RFC4034]. [RFC3110] - describes the use of RSA/SHA-1 for DNSSEC signatures. - -2.1. RSA/SHA-256 DNSKEY Resource Records - - RSA public keys for use with RSA/SHA-256 are stored in DNSKEY - resource records (RRs) with the algorithm number 8. - - For interoperability, as in [RFC3110], the key size of RSA/SHA-256 - keys MUST NOT be less than 512 bits and MUST NOT be more than 4096 - bits. - -2.2. RSA/SHA-512 DNSKEY Resource Records - - RSA public keys for use with RSA/SHA-512 are stored in DNSKEY - resource records (RRs) with the algorithm number 10. - - The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits and - MUST NOT be more than 4096 bits. - -3. RRSIG Resource Records - - The value of the signature field in the RRSIG RR follows the RSASSA- - PKCS1-v1_5 signature scheme and is calculated as follows. The values - for the RDATA fields that precede the signature data are specified in - [RFC4034]. - - - - - - - - -Jansen Standards Track [Page 3] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - - hash = SHA-XXX(data) - - Here XXX is either 256 or 512, depending on the algorithm used, as - specified in FIPS PUB 180-3; "data" is the wire format data of the - resource record set that is signed, as specified in [RFC4034]. - - signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) - - Here "|" is concatenation; "00", "01", "FF", and "00" are fixed - octets of corresponding hexadecimal value; "e" is the private - exponent of the signing RSA key; and "n" is the public modulus of the - signing key. The FF octet MUST be repeated the exact number of times - so that the total length of the concatenated term in parentheses - equals the length of the modulus of the signer's public key ("n"). - - The "prefix" is intended to make the use of standard cryptographic - libraries easier. These specifications are taken directly from the - specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 (Section 8.2 of - [RFC3447]), and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 (Section 9.2 - of [RFC3447]). The prefixes for the different algorithms are - specified below. - -3.1. RSA/SHA-256 RRSIG Resource Records - - RSA/SHA-256 signatures are stored in the DNS using RRSIG resource - records (RRs) with algorithm number 8. - - The prefix is the ASN.1 DER SHA-256 algorithm designator prefix, as - specified in PKCS #1 v2.1 [RFC3447]: - - hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 - -3.2. RSA/SHA-512 RRSIG Resource Records - - RSA/SHA-512 signatures are stored in the DNS using RRSIG resource - records (RRs) with algorithm number 10. - - The prefix is the ASN.1 DER SHA-512 algorithm designator prefix, as - specified in PKCS #1 v2.1 [RFC3447]: - - hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 - - - - - - - - - - -Jansen Standards Track [Page 4] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - -4. Deployment Considerations - -4.1. Key Sizes - - Apart from the restrictions in Section 2, this document will not - specify what size of keys to use. That is an operational issue and - depends largely on the environment and intended use. A good starting - point for more information would be NIST SP 800-57 [NIST800-57]. - -4.2. Signature Sizes - - In this family of signing algorithms, the size of signatures is - related to the size of the key and not to the hashing algorithm used - in the signing process. Therefore, RRSIG resource records produced - with RSA/SHA-256 or RSA/SHA-512 will have the same size as those - produced with RSA/SHA-1, if the keys have the same length. - -5. Implementation Considerations - -5.1. Support for SHA-2 Signatures - - DNSSEC-aware implementations SHOULD be able to support RRSIG and - DNSKEY resource records created with the RSA/SHA-2 algorithms as - defined in this document. - -5.2. Support for NSEC3 Denial of Existence - - [RFC5155] defines new algorithm identifiers for existing signing - algorithms, to indicate that zones signed with these algorithm - identifiers can use NSEC3 as well as NSEC records to provide denial - of existence. That mechanism was chosen to protect implementations - predating RFC 5155 from encountering resource records about which - they could not know. This document does not define such algorithm - aliases. - - A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate - negative answers in the form of both NSEC and NSEC3 with hash - algorithm 1, as defined in [RFC5155]. An authoritative server that - does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 - with NSEC denial of existence. - - - - - - - - - - - -Jansen Standards Track [Page 5] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - -6. Examples - -6.1. RSA/SHA-256 Key and Signature - - Given a private key with the following values (in Base64): - - Private-key-format: v1.2 - Algorithm: 8 (RSASHA256) - Modulus: wVwaxrHF2CK64aYKRUibLiH30KpPuPBjel7E8ZydQW1HYWHfoGm - idzC2RnhwCC293hCzw+TFR2nqn8OVSY5t2Q== - PublicExponent: AQAB - PrivateExponent: UR44xX6zB3eaeyvTRzmskHADrPCmPWnr8dxsNwiDGHzrMKLN+i/ - HAam+97HxIKVWNDH2ba9Mf1SA8xu9dcHZAQ== - Prime1: 4c8IvFu1AVXGWeFLLFh5vs7fbdzdC6U82fduE6KkSWk= - Prime2: 2zZpBE8ZXVnL74QjG4zINlDfH+EOEtjJJ3RtaYDugvE= - Exponent1: G2xAPFfK0KGxGANDVNxd1K1c9wOmmJ51mGbzKFFNMFk= - Exponent2: GYxP1Pa7CAwtHm8SAGX594qZVofOMhgd6YFCNyeVpKE= - Coefficient: icQdNRjlZGPmuJm2TIadubcO8X7V4y07aVhX464tx8Q= - - The DNSKEY record for this key would be: - - example.net. 3600 IN DNSKEY (256 3 8 AwEAAcFcGsaxxdgiuuGmCkVI - my4h99CqT7jwY3pexPGcnUFtR2Fh36BponcwtkZ4cAgtvd4Qs8P - kxUdp6p/DlUmObdk= );{id = 9033 (zsk), size = 512b} - - With this key, sign the following RRSet, consisting of 1 A record: - - www.example.net. 3600 IN A 192.0.2.91 - - If the inception date is set at 00:00 hours on January 1st, 2000, and - the expiration date at 00:00 hours on January 1st, 2030, the - following signature should be created: - - www.example.net. 3600 IN RRSIG (A 8 3 3600 20300101000000 - 20000101000000 9033 example.net. kRCOH6u7l0QGy9qpC9 - l1sLncJcOKFLJ7GhiUOibu4teYp5VE9RncriShZNz85mwlMgNEa - cFYK/lPtPiVYP4bwg==);{id = 9033} - - - - - - - - - - - - - - -Jansen Standards Track [Page 6] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - -6.2. RSA/SHA-512 Key and Signature - - Given a private key with the following values (in Base64): - - Private-key-format: v1.2 - Algorithm: 10 (RSASHA512) - Modulus: 0eg1M5b563zoq4k5ZEOnWmd2/BvpjzedJVdfIsDcMuuhE5SQ3pf - Q7qmdaeMlC6Nf8DKGoUPGPXe06cP27/WRODtxXquSUytkO0kJDk - 8KX8PtA0+yBWwy7UnZDyCkynO00Uuk8HPVtZeMO1pHtlAGVnc8V - jXZlNKdyit99waaE4s= - PublicExponent: AQAB - PrivateExponent: rFS1IPbJllFFgFc33B5DDlC1egO8e81P4fFadODbp56V7sphKa6 - AZQCx8NYAew6VXFFPAKTw41QdHnK5kIYOwxvfFDjDcUGza88qbj - yrDPSJenkeZbISMUSSqy7AMFzEolkk6WSn6k3thUVRgSlqDoOV3 - SEIAsrB043XzGrKIVE= - Prime1: 8mbtsu9Tl9v7tKSHdCIeprLIQXQLzxlSZun5T1n/OjvXSUtvD7x - nZJ+LHqaBj1dIgMbCq2U8O04QVcK3TS9GiQ== - Prime2: 3a6gkfs74d0Jb7yL4j4adAif4fcp7ZrGt7G5NRVDDY/Mv4TERAK - Ma0TKN3okKE0A7X+Rv2K84mhT4QLDlllEcw== - Exponent1: v3D5A9uuCn5rgVR7wgV8ba0/KSpsdSiLgsoA42GxiB1gvvs7gJM - MmVTDu/ZG1p1ZnpLbhh/S/Qd/MSwyNlxC+Q== - Exponent2: m+ezf9dsDvYQK+gzjOLWYeKq5xWYBEYFGa3BLocMiF4oxkzOZ3J - PZSWU/h1Fjp5RV7aPP0Vmx+hNjYMPIQ8Y5w== - Coefficient: Je5YhYpUron/WdOXjxNAxDubAp3i5X7UOUfhJcyIggqwY86IE0Q - /Bk0Dw4SC9zxnsimmdBXW2Izd8Lwuk8FQcQ== - - The DNSKEY record for this key would be: - - example.net. 3600 IN DNSKEY (256 3 10 AwEAAdHoNTOW+et86KuJOWRD - p1pndvwb6Y83nSVXXyLA3DLroROUkN6X0O6pnWnjJQujX/AyhqFD - xj13tOnD9u/1kTg7cV6rklMrZDtJCQ5PCl/D7QNPsgVsMu1J2Q8g - pMpztNFLpPBz1bWXjDtaR7ZQBlZ3PFY12ZTSncorffcGmhOL - );{id = 3740 (zsk), size = 1024b} - - With this key, sign the following RRSet, consisting of 1 A record: - - www.example.net. 3600 IN A 192.0.2.91 - - If the inception date is set at 00:00 hours on January 1st, 2000, and - the expiration date at 00:00 hours on January 1st, 2030, the - following signature should be created: - - www.example.net. 3600 IN RRSIG (A 10 3 3600 20300101000000 - 20000101000000 3740 example.net. tsb4wnjRUDnB1BUi+t - 6TMTXThjVnG+eCkWqjvvjhzQL1d0YRoOe0CbxrVDYd0xDtsuJRa - eUw1ep94PzEWzr0iGYgZBWm/zpq+9fOuagYJRfDqfReKBzMweOL - DiNa8iP5g9vMhpuv6OPlvpXwm9Sa9ZXIbNl1MBGk0fthPgxdDLw - =);{id = 3740} - - - -Jansen Standards Track [Page 7] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - -7. IANA Considerations - - This document updates the IANA registry "DNS SECURITY ALGORITHM - NUMBERS -- per [RFC4035]" (http://www.iana.org/protocols). The - following entries are added to the registry: - - Zone Trans. - Value Description Mnemonic Signing Sec. References - 8 RSA/SHA-256 RSASHA256 Y * RFC 5702 - 10 RSA/SHA-512 RSASHA512 Y * RFC 5702 - - * There has been no determination of standardization of the use of - this algorithm with Transaction Security. - -8. Security Considerations - -8.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records - - Users of DNSSEC are encouraged to deploy SHA-2 as soon as software - implementations allow for it. SHA-2 is widely believed to be more - resilient to attack than SHA-1, and confidence in SHA-1's strength is - being eroded by recently announced attacks. Regardless of whether or - not the attacks on SHA-1 will affect DNSSEC, it is believed (at the - time of this writing) that SHA-2 is the better choice for use in - DNSSEC records. - - SHA-2 is considered sufficiently strong for the immediate future, but - predictions about future development in cryptography and - cryptanalysis are beyond the scope of this document. - - The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one - used for RSA/SHA-1 signatures. This should ease implementation of - the new hashing algorithms in DNSSEC software. - -8.2. Signature Type Downgrade Attacks - - Since each RRSet MUST be signed with each algorithm present in the - DNSKEY RRSet at the zone apex (see Section 2.2 of [RFC4035]), a - malicious party cannot filter out the RSA/SHA-2 RRSIG and force the - validator to use the RSA/SHA-1 signature if both are present in the - zone. This should provide resilience against algorithm downgrade - attacks, if the validator supports RSA/SHA-2. - - - - - - - - - -Jansen Standards Track [Page 8] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - -9. Acknowledgments - - This document is a minor extension to [RFC4034]. Also, we try to - follow the documents [RFC3110] and [RFC4509] 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: Jaap - Akkerhuis, Mark Andrews, Roy Arends, Rob Austein, Francis Dupont, - Miek Gieben, Alfred Hoenes, Paul Hoffman, Peter Koch, Scott Rose, - Michael St. Johns, and Wouter Wijngaards. - -10. References - -10.1. Normative References - - [FIPS.180-3.2008] - National Institute of Standards and Technology, "Secure - Hash Standard", FIPS PUB 180-3, October 2008. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, 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. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - -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. - - - -Jansen Standards Track [Page 9] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - - [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. - -Author's Address - - Jelte Jansen - NLnet Labs - Science Park 140 - 1098 XG Amsterdam - NL - - EMail: jelte@NLnetLabs.nl - URI: http://www.nlnetlabs.nl/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jansen Standards Track [Page 10] -