+++ /dev/null
-#!/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
+++ /dev/null
-/*
- * 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";
-};
-
+++ /dev/null
-; 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
+++ /dev/null
-#!/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 <<EOF
-trusted-keys {
- "$dn" $flags $proto $alg "$key";
-};
-EOF
-' > trusted.conf
-cp trusted.conf ../ns2/trusted.conf
-cp trusted.conf ../ns3/trusted.conf
-cp trusted.conf ../ns4/trusted.conf
+++ /dev/null
-; 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
+++ /dev/null
-; 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
+++ /dev/null
-/*
- * 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; };
-};
+++ /dev/null
-#!/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
+++ /dev/null
-; 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
+++ /dev/null
-; 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
+++ /dev/null
-/*
- * 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";
-};
+++ /dev/null
-/*
- * 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";
-};
+++ /dev/null
-#!/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
+++ /dev/null
-#!/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
+++ /dev/null
-#!/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 <<END>> 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
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-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]\f
-
-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]\f
-
-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 (<y>256||<x>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]\f
-
- 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]\f
-
- 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]\f
-
-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]\f
-
- 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]\f
-
-
-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]\f
-
-
-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]\f
-
-
-
-
-
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-Internet-Draft DNAME Redirection November 2009
-
-
- Its RDATA is comprised of a single field, <target>, which contains a
- fully qualified domain name that must be sent in uncompressed form
- [RFC1035], [RFC3597]. The <target> field MUST be present. The
- presentation format of <target> is that of a domain name [RFC1035].
-
- <owner> <ttl> <class> DNAME <target>
-
- The effect of the DNAME RR is the substitution of the record's
- <target> 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]
-\f
-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. <no match>
- example.com. example.com. example.net. <no match>
- 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. <no match>
- 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]
-\f
-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]
-\f
-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]
-\f
-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 <target> for its
- <owner> in QNAME would overflow the legal size for a <domain-
- name>, 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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 "[<TTL>] [<class>]
- <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
-
-
-
-Expires March 2010 Standards Track [Page 3]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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", <http://www.as112.net/>.
-
- [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]
-\f
-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]
-\f
-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]
-\f
-
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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, <http://ops.ietf.org/lists/namedroppers/
- namedroppers.2005/msg01102.html>.
-
- [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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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 (<QNAME, QTYPE, QCLASS>)
- 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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, class, server IP address>. 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-RFC 5011 Trust Anchor Update September 2007
-
-
-Author's Address
-
- Michael StJohns
- Independent
-
- EMail: mstjohns@comcast.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Standards Track [Page 13]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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,
- <http://www.iis.se/docs/Routertester_en.pdf>.
-
- [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on
- Broadband Routers and Firewalls", September 2008,
- <http://www.icann.org/committees/security/sac035.pdf>.
-
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
projects / thirdparty / bind9.git / commitdiff
