diff --git a/CHANGES b/CHANGES index 37730a9c05..d3e1a74bc9 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +3457. [protocol] Add ILNP records (NID, LP, L32, L64). [RT #31836] + 3456. [port] g++47: aft fails to compile. [RT #32012] 3455. [contrib] queryperf: fix getopt option list. [RT #32338] diff --git a/bin/tests/system/additional/clean.sh b/bin/tests/system/additional/clean.sh new file mode 100644 index 0000000000..4a375b2fcb --- /dev/null +++ b/bin/tests/system/additional/clean.sh @@ -0,0 +1,26 @@ +#!/bin/sh +# +# Copyright (C) 2005-2007, 2012 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.6 2007/09/26 03:22:44 marka Exp $ + +# +# Clean up after tests. +# + +rm -f dig.out.* +rm -f */named.memstats +rm -f */named.conf +rm -f */named.run diff --git a/bin/tests/system/additional/ns1/named.args b/bin/tests/system/additional/ns1/named.args new file mode 100644 index 0000000000..4ae1d9b04e --- /dev/null +++ b/bin/tests/system/additional/ns1/named.args @@ -0,0 +1,2 @@ +# this server runs named with only one worker thread +-m record,size,mctx -c named.conf -d 99 -g -T clienttest -n 1 \ No newline at end of file diff --git a/bin/tests/system/additional/ns1/named1.conf b/bin/tests/system/additional/ns1/named1.conf new file mode 100644 index 0000000000..1ce8b264e2 --- /dev/null +++ b/bin/tests/system/additional/ns1/named1.conf @@ -0,0 +1,62 @@ +/* + * Copyright (C) 2005-2007 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.5 2007/06/19 23:47:06 tbox Exp $ */ + +options { + query-source address 10.53.0.1; + notify-source 10.53.0.1; + transfer-source 10.53.0.1; + recursion no; + additional-from-auth no; + port 5300; + pid-file "named.pid"; + listen-on { 10.53.0.1; }; + listen-on-v6 { none; }; + notify no; + minimal-responses yes; +}; + +include "../../common/rndc.key"; + +controls { + inet 10.53.0.1 port 9953 allow { any; } keys { rndc_key; }; +}; + +zone "rt.example" { + type master; + file "rt.db"; +}; + +zone "naptr.example" { + type master; + file "naptr.db"; +}; + +zone "rt2.example" { + type master; + file "rt2.db"; +}; + +zone "naptr2.example" { + type master; + file "naptr2.db"; +}; + +zone "nid.example" { + type master; + file "nid.db"; +}; diff --git a/bin/tests/system/additional/ns1/named2.conf b/bin/tests/system/additional/ns1/named2.conf new file mode 100644 index 0000000000..56966493b5 --- /dev/null +++ b/bin/tests/system/additional/ns1/named2.conf @@ -0,0 +1,62 @@ +/* + * Copyright (C) 2005-2007 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.5 2007/06/19 23:47:06 tbox Exp $ */ + +options { + query-source address 10.53.0.1; + notify-source 10.53.0.1; + transfer-source 10.53.0.1; + recursion no; + additional-from-auth no; + port 5300; + pid-file "named.pid"; + listen-on { 10.53.0.1; }; + listen-on-v6 { none; }; + notify no; + minimal-responses no; +}; + +include "../../common/rndc.key"; + +controls { + inet 10.53.0.1 port 9953 allow { any; } keys { rndc_key; }; +}; + +zone "rt.example" { + type master; + file "rt.db"; +}; + +zone "naptr.example" { + type master; + file "naptr.db"; +}; + +zone "rt2.example" { + type master; + file "rt2.db"; +}; + +zone "naptr2.example" { + type master; + file "naptr2.db"; +}; + +zone "nid.example" { + type master; + file "nid.db"; +}; diff --git a/bin/tests/system/additional/ns1/naptr.db b/bin/tests/system/additional/ns1/naptr.db new file mode 100644 index 0000000000..5905c3554b --- /dev/null +++ b/bin/tests/system/additional/ns1/naptr.db @@ -0,0 +1,9 @@ +$TTL 86400 +@ IN SOA ns1 hostmaster ( 2 8H 2H 4W 1D ); + NS ns1 +ns1 A 127.0.0.0 + +nap IN NAPTR 50 50 "S" "SIPS+D2T" "" server +server SRV 0 0 5061 server +server A 192.168.2.9 +server AAAA 192::9 diff --git a/bin/tests/system/additional/ns1/naptr2.db b/bin/tests/system/additional/ns1/naptr2.db new file mode 100644 index 0000000000..ae26f690eb --- /dev/null +++ b/bin/tests/system/additional/ns1/naptr2.db @@ -0,0 +1,9 @@ +$TTL 86400 +@ IN SOA ns1 hostmaster ( 2 8H 2H 4W 1D ); + NS ns1 +ns1 A 127.0.0.0 + +nap IN NAPTR 50 50 "S" "SIPS+D2T" "" server.hang3a.zone. +www AAAA 192::99 +www A 192.168.2.99 +www X25 100099 diff --git a/bin/tests/system/additional/ns1/nid.db b/bin/tests/system/additional/ns1/nid.db new file mode 100644 index 0000000000..c43332f452 --- /dev/null +++ b/bin/tests/system/additional/ns1/nid.db @@ -0,0 +1,10 @@ +$TTL 86400 +@ IN SOA ns1 hostmaster ( 2 8H 2H 4W 1D ); + NS ns1 +ns1 A 127.0.0.0 + +ns1 NID 2 0:0:0:0 +ns1 L64 2 0:0:0:0 +ns1 L32 2 0.0.0.0 +nid2 NID 2 0:0:0:1 +nid2 LP 2 ns1 diff --git a/bin/tests/system/additional/ns1/rt.db b/bin/tests/system/additional/ns1/rt.db new file mode 100644 index 0000000000..508a331d24 --- /dev/null +++ b/bin/tests/system/additional/ns1/rt.db @@ -0,0 +1,9 @@ +$TTL 86400 +@ IN SOA ns1 hostmaster ( 2 8H 2H 4W 1D ); + NS ns1 +ns1 A 127.0.0.0 + +rt RT 2 www +www AAAA 192::99 +www A 192.168.2.99 +www X25 100099 diff --git a/bin/tests/system/additional/ns1/rt2.db b/bin/tests/system/additional/ns1/rt2.db new file mode 100644 index 0000000000..594ca7f5f6 --- /dev/null +++ b/bin/tests/system/additional/ns1/rt2.db @@ -0,0 +1,9 @@ +$TTL 86400 +@ IN SOA ns1 hostmaster ( 2 8H 2H 4W 1D ); + NS ns1 +ns1 A 127.0.0.0 + +rt RT 2 www.hang3b.zone. +server SRV 0 0 5061 server +server A 192.168.2.9 +server AAAA 192::9 diff --git a/bin/tests/system/additional/setup.sh b/bin/tests/system/additional/setup.sh new file mode 100644 index 0000000000..16d928d5a2 --- /dev/null +++ b/bin/tests/system/additional/setup.sh @@ -0,0 +1,17 @@ +#!/bin/sh +# +# Copyright (C) 2012 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. + +cp -f ns1/named1.conf ns1/named.conf diff --git a/bin/tests/system/additional/tests.sh b/bin/tests/system/additional/tests.sh new file mode 100644 index 0000000000..91f16c68f3 --- /dev/null +++ b/bin/tests/system/additional/tests.sh @@ -0,0 +1,121 @@ +#!/bin/sh +# +# Copyright (C) 2005-2007, 2011, 2012 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.7 2011/11/06 23:46:40 tbox Exp $ + +SYSTEMTESTTOP=.. +. $SYSTEMTESTTOP/conf.sh + +status=0 +n=0 + +dotests() { + n=`expr $n + 1` + echo "I:test with RT, single zone ($n)" + ret=0 + $DIG -t RT rt.rt.example @10.53.0.1 -p 5300 > dig.out.$n || ret=1 + if [ $ret -eq 1 ] ; then + echo "I: failed"; status=1 + fi + + n=`expr $n + 1` + echo "I:test with RT, two zones ($n)" + ret=0 + $DIG -t RT rt.rt2.example @10.53.0.1 -p 5300 > dig.out.$n || ret=1 + if [ $ret -eq 1 ] ; then + echo "I: failed"; status=1 + fi + + n=`expr $n + 1` + echo "I:test with NAPTR, single zone ($n)" + ret=0 + $DIG -t NAPTR nap.naptr.example @10.53.0.1 -p 5300 > dig.out.$n || ret=1 + if [ $ret -eq 1 ] ; then + echo "I: failed"; status=1 + fi + + n=`expr $n + 1` + echo "I:test with NAPTR, two zones ($n)" + ret=0 + $DIG -t NAPTR nap.hang3b.example @10.53.0.1 -p 5300 > dig.out.$n || ret=1 + if [ $ret -eq 1 ] ; then + echo "I: failed"; status=1 + fi + + n=`expr $n + 1` + echo "I:test with LP ($n)" + ret=0 + $DIG -t LP nid2.nid.example @10.53.0.1 -p 5300 > dig.out.$n || ret=1 + if [ $minimal = no ] ; then + grep "L64" dig.out.$n > /dev/null || ret=1 + grep "L32" dig.out.$n > /dev/null || ret=1 + else + grep "L64" dig.out.$n > /dev/null && ret=1 + grep "L32" dig.out.$n > /dev/null && ret=1 + fi + if [ $ret -eq 1 ] ; then + echo "I: failed"; status=1 + fi + + n=`expr $n + 1` + echo "I:test with NID ($n)" + ret=0 + $DIG -t NID ns1.nid.example @10.53.0.1 -p 5300 > dig.out.$n || ret=1 + if [ $minimal = no ] ; then + # change && to || when we support NID additional processing + grep "L64" dig.out.$n > /dev/null && ret=1 + grep "L32" dig.out.$n > /dev/null && ret=1 + else + grep "L64" dig.out.$n > /dev/null && ret=1 + grep "L32" dig.out.$n > /dev/null && ret=1 + fi + if [ $ret -eq 1 ] ; then + echo "I: failed"; status=1 + fi + + n=`expr $n + 1` + echo "I:test with NID + LP ($n)" + ret=0 + $DIG -t NID nid2.nid.example @10.53.0.1 -p 5300 > dig.out.$n || ret=1 + if [ $minimal = no ] ; then + # change && to || when we support NID additional processing + grep "LP" dig.out.$n > /dev/null && ret=1 + grep "L64" dig.out.$n > /dev/null && ret=1 + grep "L32" dig.out.$n > /dev/null && ret=1 + else + grep "LP" dig.out.$n > /dev/null && ret=1 + grep "L64" dig.out.$n > /dev/null && ret=1 + grep "L32" dig.out.$n > /dev/null && ret=1 + fi + if [ $ret -eq 1 ] ; then + echo "I: failed"; status=1 + fi +} + +echo "I:testing with 'minimal-responses yes;'" +minimal=yes +dotests + +echo "I:reconfiguring server" +cp ns1/named2.conf ns1/named.conf +$RNDC -c ../common/rndc.conf -s 10.53.0.1 -p 9953 reconfig 2>&1 | sed 's/^/I:ns1 /' +sleep 2 + +echo "I:testing with 'minimal-responses no;'" +minimal=no +dotests + +exit $status diff --git a/bin/tests/system/conf.sh.in b/bin/tests/system/conf.sh.in index ed23ac1948..3df4c3f10d 100644 --- a/bin/tests/system/conf.sh.in +++ b/bin/tests/system/conf.sh.in @@ -55,14 +55,14 @@ ARPANAME=$TOP/bin/tools/arpaname # The "stress" test is not run by default since it creates enough # load on the machine to make it unusable to other users. # v6synth -SUBDIRS="acl allow_query addzone autosign builtin cacheclean checkconf - @CHECKDS@ checknames checkzone database dlv dlvauto dlz dlzexternal - dname dns64 dnssec ecdsa forward glue gost ixfr inline limits - logfileconfig lwresd masterfile masterformat metadata notify - nsupdate pending pkcs11 redirect resolver rndc rpz rrsetorder - rsabigexponent sortlist smartsign staticstub stub tkey tsig - tsiggss unknown upforwd verify views wildcard xfer xferquota - zonechecks" +SUBDIRS="acl additional allow_query addzone autosign builtin + cacheclean checkconf @CHECKDS@ checknames checkzone database + dlv dlvauto dlz dlzexternal dname dns64 dnssec ecdsa forward + glue gost ixfr inline limits logfileconfig lwresd masterfile + masterformat metadata notify nsupdate pending pkcs11 + redirect resolver rndc rpz rrsetorder rsabigexponent + sortlist smartsign staticstub stub tkey tsig tsiggss unknown + upforwd verify views wildcard xfer xferquota zonechecks" # PERL will be an empty string if no perl interpreter was found. PERL=@PERL@ diff --git a/bin/tests/system/genzone.sh b/bin/tests/system/genzone.sh index cc39e01913..1c112eecf3 100644 --- a/bin/tests/system/genzone.sh +++ b/bin/tests/system/genzone.sh @@ -275,6 +275,14 @@ tlsa TLSA ( 1 1 2 92003ba34942dc74152e2f2c408d29ec 1b177615d466f6c4b71c216a50292bd5 8c9ebdd2f74e38fe51ffd48c43326cbc ) +nid NID 10 0014:4fff:ff20:ee64 + +l32 L32 10 1.2.3.4 + +l64 L64 10 0014:4fff:ff20:ee64 + +lp LP 10 example.net. + ; type 255 ; TSIG is a meta-type and should never occur in master files. diff --git a/bin/tests/system/xfer/dig1.good b/bin/tests/system/xfer/dig1.good index e44db2fbd6..cdfceb7a6b 100644 --- a/bin/tests/system/xfer/dig1.good +++ b/bin/tests/system/xfer/dig1.good @@ -20,7 +20,7 @@ gpos01.example. 3600 IN GPOS "-22.6882" "116.8652" "250.0" gpos02.example. 3600 IN GPOS "" "" "" hinfo01.example. 3600 IN HINFO "Generic PC clone" "NetBSD-1.4" hinfo02.example. 3600 IN HINFO "PC" "NetBSD" -hip1.example. 3600 IN HIP 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D +hip1.example. 3600 IN HIP 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D hip2.example. 3600 IN HIP 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D rvs.example.com. isdn01.example. 3600 IN ISDN "isdn-address" isdn02.example. 3600 IN ISDN "isdn-address" "subaddress" @@ -31,6 +31,10 @@ kx01.example. 3600 IN KX 10 kdc.example. kx02.example. 3600 IN KX 10 . loc01.example. 3600 IN LOC 60 9 0.000 N 24 39 0.000 E 10.00m 20m 2000m 20m loc02.example. 3600 IN LOC 60 9 0.000 N 24 39 0.000 E 10.00m 20m 2000m 20m +l32.example. 3600 IN L32 10 1.2.3.4 +l64.example. 3600 IN L64 10 14:4fff:ff20:ee64 +lp.example. 3600 IN LP 10 example.net. +nid.example. 3600 IN NID 10 14:4fff:ff20:ee64 mb01.example. 3600 IN MG madname.example. mb02.example. 3600 IN MG . mg01.example. 3600 IN MG mgmname.example. diff --git a/bin/tests/system/xfer/dig2.good b/bin/tests/system/xfer/dig2.good index 25724944c6..6c761dbc6b 100644 --- a/bin/tests/system/xfer/dig2.good +++ b/bin/tests/system/xfer/dig2.good @@ -31,6 +31,10 @@ kx01.example. 3600 IN KX 10 kdc.example. kx02.example. 3600 IN KX 10 . loc01.example. 3600 IN LOC 60 9 0.000 N 24 39 0.000 E 10.00m 20m 2000m 20m loc02.example. 3600 IN LOC 60 9 0.000 N 24 39 0.000 E 10.00m 20m 2000m 20m +l32.example. 3600 IN L32 10 1.2.3.4 +l64.example. 3600 IN L64 10 14:4fff:ff20:ee64 +lp.example. 3600 IN LP 10 example.net. +nid.example. 3600 IN NID 10 14:4fff:ff20:ee64 mb01.example. 3600 IN MG madname.example. mb02.example. 3600 IN MG . mg01.example. 3600 IN MG mgmname.example. diff --git a/doc/rfc/index b/doc/rfc/index index bd72fdef13..5635b98af3 100644 --- a/doc/rfc/index +++ b/doc/rfc/index @@ -141,3 +141,6 @@ 5933: Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC 6303: Locally Served DNS Zones +6742: DNS Resource Records for the + Identifier-Locator Network Protocol (ILNP) + diff --git a/doc/rfc/rfc6742.txt b/doc/rfc/rfc6742.txt new file mode 100644 index 0000000000..7aad015724 --- /dev/null +++ b/doc/rfc/rfc6742.txt @@ -0,0 +1,1123 @@ + + + + + + +Internet Research Task Force (IRTF) RJ Atkinson +Request for Comments: 6742 Consultant +Category: Experimental SN Bhatti +ISSN: 2070-1721 U. St Andrews + S. Rose + US NIST + November 2012 + + + DNS Resource Records for the + Identifier-Locator Network Protocol (ILNP) + +Abstract + + This note describes additional optional resource records for use with + the Domain Name System (DNS). These optional resource records are + for use with the Identifier-Locator Network Protocol (ILNP). This + document is a product of the IRTF Routing Research Group. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Research Task + Force (IRTF). The IRTF publishes the results of Internet-related + research and development activities. These results might not be + suitable for deployment. This RFC represents the individual + opinion(s) of one or more members of the Routing Research Group of + the Internet Research Task Force (IRTF). Documents approved for + publication by the IRSG are not a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6742. + + + + + + + + + + + + + +Atkinson, et al. Experimental [Page 1] + +RFC 6742 ILNP DNS November 2012 + + +Copyright Notice + + Copyright (c) 2012 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. + + This document may not be modified, and derivative works of it may not + be created, except to format it for publication as an RFC or to + translate it into languages other than English. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Document Roadmap ...........................................4 + 1.2. Terminology ................................................5 + 2. New Resource Records ............................................5 + 2.1. The NID Resource Record ....................................5 + 2.2. The L32 Resource Record ....................................7 + 2.3. The L64 Resource Record ...................................10 + 2.4. The LP Resource Record ....................................12 + 3. Deployment Example .............................................15 + 3.1. Use of ILNP Records .......................................15 + 3.2. Additional Section Processing .............................16 + 4. Security Considerations ........................................17 + 5. IANA Considerations ............................................17 + 6. References .....................................................17 + 6.1. Normative References ......................................17 + 6.2. Informative References ....................................18 + 7. Acknowledgements ...............................................20 + +1. Introduction + + This document is part of the ILNP document set, which has had + extensive review within the IRTF Routing RG. ILNP is one of the + recommendations made by the RG Chairs. Separately, various refereed + research papers on ILNP have also been published during this decade. + So, the ideas contained herein have had much broader review than the + IRTF Routing RG. The views in this document were considered + controversial by the Routing RG, but the RG reached a consensus that + the document still should be published. The Routing RG has had + remarkably little consensus on anything, so virtually all Routing RG + outputs are considered controversial. + + + +Atkinson, et al. Experimental [Page 2] + +RFC 6742 ILNP DNS November 2012 + + + At present, the Internet research and development community is + exploring various approaches to evolving the Internet Architecture to + solve a variety of issues including, but not limited to, scalability + of inter-domain routing [RFC4984]. A wide range of other issues + (e.g., site multihoming, node multihoming, site/subnet mobility, node + mobility) are also active concerns at present. Several different + classes of evolution are being considered by the Internet research + and development community. One class is often called "Map and + Encapsulate", where traffic would be mapped and then tunnelled + through the inter-domain core of the Internet. Another class being + considered is sometimes known as "Identifier/Locator Split". This + document relates to a proposal that is in the latter class of + evolutionary approaches. + + The Identifier-Locator Network Protocol (ILNP) was developed to + explore a possible evolutionary direction for the Internet + Architecture. A description of the ILNP architecture is available in + a separate document [RFC6740]. Implementation and engineering + details are largely isolated into a second document [RFC6741]. + + The Domain Name System (DNS) is the standard way that Internet nodes + locate information about addresses, mail exchangers, and other data + relating to remote Internet nodes [RFC1034] [RFC1035]. + + More recently, the IETF has defined standards-track security + extensions to the DNS [RFC4033]. These security extensions can be + used to authenticate signed DNS data records and can be used to store + signed public keys in the DNS. Further, the IETF has defined a + standards-track approach to enable secure dynamic update of DNS + records over the network [RFC3007]. + + This document defines several new optional data resource records. + This note specifies the syntax and other items required for + independent implementations of these DNS resource records. The + reader is assumed to be familiar with the basics of DNS, including + familiarity with [RFC1034] [RFC1035]. + + The concept of using DNS for rendezvous with mobile nodes or mobile + networks has been proposed earlier, more than once, independently, by + several other researchers; for example, please see [SB00], [SBK01], + and [PHG02]. + + + + + + + + + + +Atkinson, et al. Experimental [Page 3] + +RFC 6742 ILNP DNS November 2012 + + +1.1. Document Roadmap + + This document describes defines additional DNS resource records that + support ILNP. + + The ILNP architecture can have more than one engineering + instantiation. For example, one can imagine a "clean-slate" + engineering design based on the ILNP architecture. In separate + documents, we describe two specific engineering instances of ILNP. + The term "ILNPv6" refers precisely to an instance of ILNP that is + based upon, and backwards compatible with, IPv6. The term "ILNPv4" + refers precisely to an instance of ILNP that is based upon, and + backwards compatible with, IPv4. + + Many engineering aspects common to both ILNPv4 and ILNPv6 are + described in [RFC6741]. A full engineering specification for either + ILNPv6 or ILNPv4 is beyond the scope of this document. + + Readers are referred to other related ILNP documents for details not + described here: + + a) [RFC6740] is the main architectural description of ILNP, including + the concept of operations. + + b) [RFC6741] describes engineering and implementation considerations + that are common to both ILNPv4 and ILNPv6. + + c) [RFC6743] defines a new ICMPv6 Locator Update message used by an + ILNP node to inform its correspondent nodes of any changes to its + set of valid Locators. + + d) [RFC6744] defines a new IPv6 Nonce Destination Option used by + ILNPv6 nodes (1) to indicate to ILNP correspondent nodes (by + inclusion within the initial packets of an ILNP session) that the + node is operating in the ILNP mode and (2) to prevent off-path + attacks against ILNP ICMP messages. This Nonce is used, for + example, with all ILNP ICMPv6 Locator Update messages that are + exchanged among ILNP correspondent nodes. + + e) [RFC6745] defines a new ICMPv4 Locator Update message used by an + ILNP node to inform its correspondent nodes of any changes to its + set of valid Locators. + + f) [RFC6746] defines a new IPv4 Nonce Option used by ILNPv4 nodes to + carry a security nonce to prevent off-path attacks against ILNP + ICMP messages and also defines a new IPv4 Identifier Option used + by ILNPv4 nodes. + + + + +Atkinson, et al. Experimental [Page 4] + +RFC 6742 ILNP DNS November 2012 + + + g) [RFC6747] describes extensions to Address Resolution Protocol + (ARP) for use with ILNPv4. + + h) [RFC6748] describes optional engineering and deployment functions + for ILNP. These are not required for the operation or use of ILNP + and are provided as additional options. + +1.2. Terminology + + In this document, the term "ILNP-aware" applied to a DNS component + (either authoritative server or cache) is used to indicate that the + component attempts to include other ILNP RRTypes to the Additional + section of a DNS response to increase performance and reduce the + number of follow-up queries for other ILNP RRTypes. These other + RRsets MAY be added to the Additional section if space permits and + only when the QTYPE equals NID, L64, L32, or LP. There is no method + for a server to signal that it is ILNP-aware. + + 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. New Resource Records + + This document specifies several new and closely related DNS data + resource records (RRs). These new RR types have the mnemonics "NID", + "L32", "L64", and "LP". These RR types are associated with a Fully + Qualified Domain Name (FQDN) that is hereafter called the "owner + name". These are part of work on the Identifier-Locator Network + Protocol (ILNP) [RFC6740]. + + For clarity, throughout this section of this document, the "RDATA" + subsections specify the on-the-wire format for these records, while + the "Presentation Format" subsections specify the human-readable + format used in a DNS configuration file (i.e., "master file" as + defined by RFC 1035, Section 5.1). + +2.1. The NID Resource Record + + The Node Identifier (NID) DNS resource record (RR) is used hold + values for Node Identifiers that will be used for ILNP-capable nodes. + + NID records are present only for ILNP-capable nodes. This + restriction is important; ILNP-capable nodes use the presence of NID + records in the DNS to learn that a correspondent node is also ILNP- + capable. While erroneous NID records in the DNS for a node that is + not ILNP-capable would not prevent communication, such erroneous DNS + records could increase the delay at the start of an IP session. + + + +Atkinson, et al. Experimental [Page 5] + +RFC 6742 ILNP DNS November 2012 + + + A given owner name may have zero or more NID records at a given time. + In normal operation, nodes that support the Identifier-Locator + Network Protocol (ILNP) will have at least one valid NID record. + + The type value for the NID RR type is 104. + + The NID RR is class independent. + + The NID RR has no special Time to Live (TTL) requirements. + +2.1.1. NID RDATA Wire Format + + The RDATA for an NID RR consists of: + + - a 16-bit Preference field + - a 64-bit NodeID field + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Preference | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | NodeID | + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.1.1.1. The Preference Field + + The field contains a 16-bit unsigned integer in network + byte order that indicates the owner name's relative preference for + this NID record among other NID records associated with this owner + name. Lower Preference values are preferred over higher Preference + values. + +2.1.1.2. The NodeID Field + + The NodeID field is an unsigned 64-bit value in network byte order. + It complies with the syntactic rules of IPv6 interface identifiers + [RFC4291], Section 2.5.1, but has slightly different semantics. + Unlike IPv6 interface identifiers, which are bound to a specific + *interface* of a specific node, NodeID values are bound to a specific + *node*, and they MAY be used with *any interface* of that node. + + + + + + + + +Atkinson, et al. Experimental [Page 6] + +RFC 6742 ILNP DNS November 2012 + + +2.1.2. NID RR Presentation Format + + The presentation of the format of the RDATA portion is as follows: + + - The Preference field MUST be represented as a 16-bit unsigned + decimal integer. + + - The NodeID field MUST be represented using the same syntax (i.e., + groups of 4 hexadecimal digits, with each group separated by a + colon) that is already used for DNS AAAA records (and also used for + IPv6 interface IDs). + + - The NodeID value MUST NOT be in the 'compressed' format (e.g., + using "::") that is defined in RFC 4291, Section 2.2 (2). This + restriction exists to avoid confusion with 128-bit IPv6 addresses, + because the NID is a 64-bit field. + +2.1.3. NID RR Examples + + An NID record has the following logical components: + + IN NID + + In the above, is the owner name string, is + an unsigned 16-bit value, and is an unsigned 64-bit value. + + host1.example.com. IN NID 10 0014:4fff:ff20:ee64 + host1.example.com. IN NID 20 0015:5fff:ff21:ee65 + host2.example.com. IN NID 10 0016:6fff:ff22:ee66 + + As NodeID values use the same syntax as IPv6 interface identifiers, + when displayed for human readership, the NodeID values are presented + in the same hexadecimal format as IPv6 interface identifiers. This + is shown in the example above. + +2.1.4. Additional Section Processing + + To improve performance, ILNP-aware DNS servers and DNS resolvers MAY + attempt to return all L32, L64, and LP records for the same owner + name of the NID RRset in the Additional section of the response, if + space permits. + +2.2. The L32 Resource Record + + An L32 DNS RR is used to hold 32-bit Locator values for + ILNPv4-capable nodes. + + + + + +Atkinson, et al. Experimental [Page 7] + +RFC 6742 ILNP DNS November 2012 + + + L32 records are present only for ILNPv4-capable nodes. This + restriction is important; ILNP-capable nodes use the presence of L32 + records in the DNS to learn that a correspondent node is also + ILNPv4-capable. While erroneous L32 records in the DNS for a node + that is not ILNP-capable would not prevent communication, such + erroneous DNS records could increase the delay at the start of an IP + session. + + A given owner name might have zero or more L32 values at a given + time. An ILNPv4-capable host SHOULD have at least 1 Locator (i.e., + L32 or LP) DNS resource record while it is connected to the Internet. + An ILNPv4-capable multihomed host normally will have multiple Locator + values while multihomed. An IP host that is NOT ILNPv4-capable MUST + NOT have an L32 or LP record in its DNS entries. A node that is not + currently connected to the Internet might not have any L32 values in + the DNS associated with its owner name. + + A DNS owner name that is naming a subnetwork, rather than naming a + host, MAY have an L32 record as a wild-card entry, thereby applying + to entries under that DNS owner name. This deployment scenario + probably is most common if the named subnetwork is, was, or might + become, mobile. + + The type value for the L32 RR type is 105. + + The L32 RR is class independent. + + The L32 RR has no special TTL requirements. + +2.2.1. L32 RDATA Wire Format + + The RDATA for an L32 RR consists of: + + - a 16-bit Preference field + - a 32-bit Locator32 field + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Preference | Locator32 (16 MSBs) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Locator32 (16 LSBs) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + MSB = most significant bit + LSB = least significant bit + + + + + +Atkinson, et al. Experimental [Page 8] + +RFC 6742 ILNP DNS November 2012 + + +2.2.1.1. The Preference Field + + The field is an unsigned 16-bit field in network byte + order that indicates the owner name's relative preference for this + L32 record among other L32 records associated with this owner name. + Lower Preference values are preferred over higher Preference values. + +2.2.1.2. The Locator32 Field + + The field is an unsigned 32-bit integer in network byte + order that is identical on-the-wire to the ADDRESS field of the + existing DNS A record. + +2.2.2. L32 RR Presentation Format + + The presentation of the format of the RDATA portion is as follows: + + - The Preference field MUST be represented as a 16-bit unsigned + decimal integer. + + - The Locator32 field MUST be represented using the same syntax used + for existing DNS A records (i.e., 4 decimal numbers separated by + periods without any embedded spaces). + +2.2.3. L32 RR Examples + + An L32 record has the following logical components: + + IN L32 + + In the above is the owner name string, is + an unsigned 16-bit value, and is an unsigned 32-bit + value. + + host1.example.com. IN L32 10 10.1.02.0 + host1.example.com. IN L32 20 10.1.04.0 + host2.example.com. IN L32 10 10.1.08.0 + + As L32 values have the same syntax and semantics as IPv4 routing + prefixes, when displayed for human readership, the values are + presented in the same dotted-decimal format as IPv4 addresses. An + example of this syntax is shown above. + + In the example above, the owner name is from an FQDN for an + individual host. host1.example.com has two L32 values, so + host1.example.com is multihomed. + + + + + +Atkinson, et al. Experimental [Page 9] + +RFC 6742 ILNP DNS November 2012 + + + Another example is when the owner name is that learned from an LP + record (see below for details of LP records). + + l32-subnet1.example.com. IN L32 10 10.1.02.0 + l32-subnet2.example.com. IN L32 20 10.1.04.0 + l32-subnet3.example.com. IN L32 30 10.1.08.0 + + In this example above, the owner name is for a subnetwork rather than + an individual node. + +2.2.4. Additional Section Processing + + To improve performance, ILNP-aware DNS servers and DNS resolvers MAY + attempt to return all NID, L64, and LP records for the same owner + name of the L32 RRset in the Additional section of the response, if + space permits. + +2.3. The L64 Resource Record + + The L64 resource record (RR) is used to hold unsigned 64-bit Locator + values for ILNPv6-capable nodes. + + L64 records are present only for ILNPv6-capable nodes. This + restriction is important; ILNP-capable nodes use the presence of L64 + records in the DNS to learn that a correspondent node is also + ILNPv6-capable. While erroneous L64 records in the DNS for a node + that is not ILNP-capable would not prevent communication, such + erroneous DNS records could increase the delay at the start of an IP + session. + + A given owner name might have zero or more L64 values at a given + time. An ILNPv6-capable host SHOULD have at least 1 Locator (i.e., + L64 or LP) DNS resource record while it is connected to the Internet. + An ILNPv6-capable multihomed host normally will have multiple Locator + values while multihomed. An IP host that is NOT ILNPv6-capable MUST + NOT have an L64 or LP record in its DNS entries. A node that is not + currently connected to the Internet might not have any L64 values in + the DNS associated with its owner name. + + A DNS owner name that is naming a subnetwork, rather than naming a + host, MAY have an L64 record as a wild-card entry, thereby applying + to entries under that DNS owner name. This deployment scenario + probably is most common if the named subnetwork is, was, or might + become, mobile. + + The type value for the L64 RR type is 106. + + + + + +Atkinson, et al. Experimental [Page 10] + +RFC 6742 ILNP DNS November 2012 + + + The L64 RR is class independent. + + The L64 RR has no special TTL requirements. + +2.3.1. The L64 RDATA Wire Format + + The RDATA for an L64 RR consists of: + + - a 16-bit Preference field + - a 64-bit Locator64 field + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Preference | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | Locator64 | + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.3.1.1. The Preference Field + + The field is an unsigned 16-bit integer in network byte + order that indicates the owner name's relative preference for this + L64 record among other L64 records associated with this owner name. + Lower Preference values are preferred over higher Preference values. + +2.3.1.2. The Locator64 Field + + The field is an unsigned 64-bit integer in network byte + order that has the same syntax and semantics as a 64-bit IPv6 routing + prefix. + +2.3.2. L64 RR Presentation Format + + The presentation of the format of the RDATA portion is as follows: + + - The Preference field MUST be represented as a 16-bit unsigned + decimal integer. + + - The Locator64 field MUST be represented using the same syntax used + for AAAA records (i.e., groups of 4 hexadecimal digits separated by + colons). However, the 'compressed' display format (e.g., using + "::") that is specified in RFC 4291, Section 2.2 (2), MUST NOT be + used. This is done to avoid confusion with a 128-bit IPv6 address, + since the Locator64 is a 64-bit value, while the IPv6 address is a + 128-bit value. + + + +Atkinson, et al. Experimental [Page 11] + +RFC 6742 ILNP DNS November 2012 + + +2.3.3. L64 RR Examples + + An L64 record has the following logical components: + + IN L64 + + In the above, is the owner name string, is + an unsigned 16-bit value, while is an unsigned 64-bit + value. + + host1.example.com. IN L64 10 2001:0DB8:1140:1000 + host1.example.com. IN L64 20 2001:0DB8:2140:2000 + host2.example.com. IN L64 10 2001:0DB8:4140:4000 + + As L64 values have the same syntax and semantics as IPv6 routing + prefixes, when displayed for human readership, the values might + conveniently be presented in hexadecimal format, as above. + + In the example above, the owner name is from an FQDN for an + individual host. host1.example.com has two L64 values, so it will be + multihomed. + + Another example is when the owner name is that learned from an LP + record (see below for details of LP records). + + l64-subnet1.example.com. IN L64 10 2001:0DB8:1140:1000 + l64-subnet2.example.com. IN L64 20 2001:0DB8:2140:2000 + l64-subnet3.example.com. IN L64 30 2001:0DB8:4140:4000 + + Here, the owner name is for a subnetwork rather than an individual + node. + +2.3.4. Additional Section Processing + + To improve performance, ILNP-aware DNS servers and DNS resolvers MAY + attempt to return all NID, L32, and LP records for the same owner + name of the L64 RRset in the Additional section of the response, if + space permits. + +2.4. The LP Resource Record + + The LP DNS resource record (RR) is used to hold the name of a + subnetwork for ILNP. The name is an FQDN which can then be used to + look up L32 or L64 records. LP is, effectively, a Locator Pointer to + L32 and/or L64 records. + + + + + + +Atkinson, et al. Experimental [Page 12] + +RFC 6742 ILNP DNS November 2012 + + + As described in [RFC6740], the LP RR provides one level of + indirection within the DNS in naming a Locator value. This is useful + in several deployment scenarios, such as for a multihomed site where + the multihoming is handled entirely by the site's border routers + (e.g., via Locator rewriting) or in some mobile network deployment + scenarios [RFC6748]. + + LP records MUST NOT be present for owner name values that are not + ILNP-capable nodes. This restriction is important; ILNP-capable + nodes use the presence of LP records in the DNS to infer that a + correspondent node is also ILNP-capable. While erroneous LP records + in the DNS for an owner name would not prevent communication, + presence of such erroneous DNS records could increase the delay at + the start of an IP session. + + The type value for the LP RR type is 107. + + The LP RR is class independent. + + The LP RR has no special TTL requirements. + +2.4.1. LP RDATA Wire Format + + The RDATA for an LP RR consists of: + + - an unsigned 16-bit Preference field + - a variable-length FQDN field + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Preference | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / + / / + / FQDN / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.4.1.1. The Preference Field + + The field contains an unsigned 16-bit integer in network + byte order that indicates the owner name's relative preference for + this LP record among other LP records associated with this owner + name. Lower Preference values are preferred over higher Preference + values. + + + + + + +Atkinson, et al. Experimental [Page 13] + +RFC 6742 ILNP DNS November 2012 + + +2.4.1.2. The FQDN Field + + The variable-length FQDN field contains the DNS target name that is + used to reference L32 and/or L64 records. This field MUST NOT have + the same value as the owner name of the LP RR instance. + + A sender MUST NOT use DNS name compression on the FQDN field when + transmitting an LP RR. + +2.4.2. LP RR Presentation Format + + The presentation of the format of the RDATA portion is as follows: + + - The Preference field MUST be represented as a 16-bit unsigned + decimal integer. + + - The FQDN field MUST be represented as a domain name. + +2.4.3. LP RR Examples + + An LP record has the following logical components: + + IN LP + + In the above, is the owner name string, is + an unsigned 16-bit value, while is the domain name which + should be resolved further. + + host1.example.com. IN LP 10 l64-subnet1.example.com. + host1.example.com. IN LP 10 l64-subnet2.example.com. + host1.example.com. IN LP 20 l32-subnet1.example.com. + + In the example above, host1.example.com is multihomed on three + subnets. Resolving the FQDNs return in the LP records would allow + the actual subnet prefixes to be resolved, e.g., as in the examples + for the L32 and L64 RR descriptions, above. This level of + indirection allows the same L32 and/or L64 records to be used by many + hosts in the same subnetwork, easing management of the ILNP network + and potentially reducing the number of DNS Update transactions, + especially when that network is mobile [RAB09] or multihomed + [ABH09a]. + +2.4.4. Additional Section Processing + + To improve performance, ILNP-aware DNS servers and DNS resolvers MAY + attempt to return all L32 and L64 records for the same owner name of + the LP RRset in the Additional section of the response, if space + permits. + + + +Atkinson, et al. Experimental [Page 14] + +RFC 6742 ILNP DNS November 2012 + + +3. Deployment Example + + Given a domain name, one can use the Domain Name System (DNS) to + discover the set of NID records, the set of L32 records, the set of + L64 records, and the set of LP records that are associated with that + DNS owner name. + + For example: + + host1.example.com. IN NID 10 0014:4fff:ff20:ee64 + host1.example.com. IN L64 10 2001:0DB8:1140:1000 + + would be the minimum requirement for an ILNPv6 node that has owner + name host1.example.com and is connected to the Internet at the + subnetwork having routing prefix 2001:0DB8:1140:1000. + + If that host were multihomed on two different IPv6 subnets: + + host1.example.com. IN NID 10 0014:4fff:ff20:ee64 + host1.example.com. IN L64 10 2001:0DB8:1140:1000 + host1.example.com. IN L64 20 2001:0DB8:2140:2000 + + would indicate the Identifier and two subnets that host1.example.com + is attached to, along with the relative preference that a client + would use in selecting the Locator value for use in initiating + communication. + + If host1.example.com were part of a mobile network, a DNS query might + return: + + host1.example.com. IN NID 10 0014:4fff:ff20:ee64 + host1.example.com. IN LP 10 mobile-net1.example.com. + + and then a DNS query to find the current Locator value(s) for the + node named by the LP record: + + mobile-net1.example.com. IN L64 2001:0DB8:8140:8000 + +3.1. Use of ILNP Records + + As these DNS records are only used with the Identifier-Locator + Network Protocol (ILNP), these records MUST NOT be present for a node + that does not support ILNP. This lookup process is considered to be + in the "forward" direction. + + The Preference fields associated with the NID, L32, L64, and LP + records are used to indicate the owner name's preference for others + to use one particular NID, L32, L64, or LP record, rather than use + + + +Atkinson, et al. Experimental [Page 15] + +RFC 6742 ILNP DNS November 2012 + + + another NID, L32, L64, or LP record also associated with that owner + name. Lower Preference field values are preferred over higher + Preference field values. + + It is possible that a DNS stub resolver querying for one of these + record types will not receive all NID, L32, L64, and LP RR's in a + single response. Credible anecdotal reports indicate at least one + DNS recursive cache implementation actively drops all Additional Data + records that were not expected by that DNS recursive cache. So even + if the authoritative DNS server includes all the relevant records in + the Additional Data section of the DNS response, the querying DNS + stub resolver might not receive all of those Additional Data records. + DNS resolvers also might purge some ILNP RRsets before others, for + example, if NID RRsets have a longer DNS TTL value than Locator- + related (e.g., LP, L32, L64) RRsets. So a DNS stub resolver sending + queries to a DNS resolver cannot be certain if they have obtained all + available RRtypes for a given owner name. Therefore, the DNS stub + resolver SHOULD send follow-up DNS queries for RRTYPE values that + were missing and are desired, to ensure that the DNS stub resolver + receives all the necessary information. + + Note nodes likely either to be mobile or to be multihomed normally + will have very low DNS TTL values for L32 and L64 records, as those + values might change frequently. However, the DNS TTL values for NID + and LP records normally will be higher, as those values are not + normally impacted by node location changes. Previous trace-driven + DNS simulations from MIT [JSBM02] and more recent experimental + validation of operational DNS from U. of St Andrews [BA11] both + indicate deployment and use of very short DNS TTL values within + 'stub' or 'leaf' DNS domains is not problematic. + + An ILNP node MAY use any NID value associated with its DNS owner name + with any or all Locator (L32 or L64) values also associated with its + DNS owner name. + + Existing DNS servers that do not explicitly support the new DNS RRs + defined in this specification are expected to follow existing + standards for handling unknown DNS RRs [RFC3597]. + +3.2. Additional Section Processing + + For all the records above, Additional Section Processing MAY be used. + This is intended to improve performance for both the DNS client and + the DNS server. For example, a node sending DNS query for an NID + owner name, such as host1.example.com, would benefit from receiving + all ILNP DNS records related to that owner name being returned, as it + is quite likely that the client will need that information to + initiate an ILNP session. + + + +Atkinson, et al. Experimental [Page 16] + +RFC 6742 ILNP DNS November 2012 + + + However, this is not always the case: a DNS query for L64 for a + particular owner name might be made because the DNS TTL for a + previously resolved L64 RR has expired, while the NID RR for that + same owner name has a DNS TTL that has not expired. + +4. Security Considerations + + These new DNS resource record types do not create any new + vulnerabilities in the Domain Name System. + + Existing mechanisms for DNS Security can be used unchanged with these + record types [RFC4033] [RFC3007]. As of this writing, the DNS + Security mechanisms are believed to be widely implemented in + currently available DNS servers and DNS clients. Deployment of DNS + Security appears to be growing rapidly. + + In situations where authentication of DNS data is a concern, the DNS + Security extensions SHOULD be used [RFC4033]. + + If these DNS records are updated dynamically over the network, then + the Secure Dynamic DNS Update [RFC3007] mechanism SHOULD be used to + secure such transactions. + +5. IANA Considerations + + IANA has allocated each of the following DNS resource records + (described above in Section 2) a Data RRTYPE value according to the + procedures of Sections 3.1 and 3.1.1 of [RFC6195]. + + Type Value + ---- ----- + NID 104 + L32 105 + L64 106 + LP 107 + +6. References + +6.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. + + + +Atkinson, et al. Experimental [Page 17] + +RFC 6742 ILNP DNS November 2012 + + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 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. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [RFC6195] Eastlake 3rd, D., "Domain Name System (DNS) IANA + Considerations", BCP 42, RFC 6195, March 2011. + + [RFC6740] Atkinson, R. and S. Bhatti, "Identifier-Locator Network + Protocol (ILNP) Architectural Description", RFC 6740, + November 2012. + + [RFC6741] Atkinson, R. and S. Bhatti, "Identifier-Locator Network + Protocol (ILNP) Engineering and Implementation + Considerations", RFC 6741, November 2012. + +6.2. Informative References + + [ABH09a] Atkinson, R., Bhatti, S. and S. Hailes, "Site-Controlled + Secure Multi-Homing and Traffic Engineering For IP", + Proceedings of IEEE Military Communications Conference, + IEEE, Boston, MA, USA, October 2009. + + [BA11] Bhatti, S. and R. Atkinson, "Reducing DNS Caching", + Proceedings of IEEE Global Internet Symposium (GI2011), + Shanghai, P.R. China. 15 April 2011. + + + [JSBM02] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS + performance and the effectiveness of caching", IEEE/ACM + Trans. Netw. 10(5) (October 2002), pp 589-603. + + + [PHG02] Pappas, A., Hailes, S. and R. Giaffreda, "Mobile Host + Location Tracking through DNS", IEEE London + Communications Symposium, London, England, UK, September + 2002. + + + + + + +Atkinson, et al. Experimental [Page 18] + +RFC 6742 ILNP DNS November 2012 + + + [RAB09] Rehunathan, D., Atkinson, R. and S. Bhatti, "Enabling + Mobile Networks Through Secure Naming", Proceedings of + IEEE Military Communications Conference (MILCOM), IEEE, + Boston, MA, USA, October 2009. + + [SB00] Snoeren, A. and H. Balakrishnan, "An End-To-End Approach + To Host Mobility", Proceedings of 6th Conference on + Mobile Computing and Networking (MobiCom), ACM, Boston, + MA, USA, August 2000. + + [SBK01] Snoeren, A., Balakrishnan, H., and M. Frans Kaashoek, + "Reconsidering Internet Mobility", Proceedings of 8th + Workshop on Hot Topics in Operating Systems (HotOS), IEEE + Computer Society, Elmau, Germany, May 2001. + + [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report + from the IAB Workshop on Routing and Addressing", RFC + 4984, September 2007. + + [RFC6743] Atkinson, R. and S. Bhatti, "ICMPv6 Locator Update + Message", RFC 6743, November 2012. + + [RFC6744] Atkinson, R. and S. Bhatti, "IPv6 Nonce Destination + Option for the Identifier-Locator Network Protocol for + IPv6 (ILNPv6)", RFC 6744, November 2012. + + [RFC6745] Atkinson, R. and S. Bhatti, "ICMP Locator Update Message + for the Identifier-Locator Network Protocol for IPv4 + (ILNPv4)", RFC 6745, November 2012. + + [RFC6746] Atkinson, R. and S.Bhatti, "IPv4 Options for the + Identifier-Locator Network Protocol (ILNP)", RFC 6746, + November 2012. + + [RFC6747] Atkinson, R. and S. Bhatti, "Address Resolution Protocol + (ARP) Extension for the Identifier-Locator Network + Protocol for IPv4 (ILNPv4)", RFC 6747, November 2012. + + [RFC6748] Atkinson, R. and S. Bhatti, "Optional Advanced Deployment + Scenarios for the Identifier-Locator Network Protocol + (ILNP)", RFC 6748, November 2012. + + + + + + + + + + +Atkinson, et al. Experimental [Page 19] + +RFC 6742 ILNP DNS November 2012 + + +7. Acknowledgements + + Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel Chiappa, + Wes George, Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt, + Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, Bruce Simpson, + Robin Whittle, and John Wroclawski (in alphabetical order) provided + review and feedback on earlier versions of this document. Steve + Blake provided an especially thorough review of an early version of + the entire ILNP document set, which was extremely helpful. We also + wish to thank the anonymous reviewers of the various ILNP papers for + their feedback. + + Roy Arends provided expert guidance on technical and procedural + aspects of DNS issues, for which the authors are greatly obliged. + +Authors' Addresses + + RJ Atkinson + Consultant + San Jose, CA 95125 + USA + + EMail: rja.lists@gmail.com + + + SN Bhatti + School of Computer Science + University of St Andrews + North Haugh, St Andrews + Fife, Scotland + KY16 9SX, UK + + EMail: saleem@cs.st-andrews.ac.uk + + + Scott Rose + US National Institute for Standards & Technology + 100 Bureau Drive + Gaithersburg, MD 20899 + USA + + EMail: scottr.nist@gmail.com + + + + + + + + + +Atkinson, et al. Experimental [Page 20] + diff --git a/lib/dns/rdata.c b/lib/dns/rdata.c index ea9190faa6..562f8ef54c 100644 --- a/lib/dns/rdata.c +++ b/lib/dns/rdata.c @@ -221,6 +221,72 @@ static isc_result_t unknown_totext(dns_rdata_t *rdata, dns_rdata_textctx_t *tctx, isc_buffer_t *target); +/*% INT16 Size */ +#define NS_INT16SZ 2 +/*% IPv6 Address Size */ +#define NS_LOCATORSZ 8 + +/*% + * convert presentation level address to network order binary form. + * \return + * 1 if `src' is a valid [RFC1884 2.2] address, else 0. + * \note + * (1) does not touch `dst' unless it's returning 1. + */ +static inline int +locator_pton(const char *src, unsigned char *dst) { + static const char xdigits_l[] = "0123456789abcdef", + xdigits_u[] = "0123456789ABCDEF"; + unsigned char tmp[NS_LOCATORSZ]; + unsigned char *tp = tmp, *endp; + const char *xdigits, *curtok; + int ch, seen_xdigits; + unsigned int val; + + memset(tp, '\0', NS_LOCATORSZ); + endp = tp + NS_LOCATORSZ; + curtok = src; + seen_xdigits = 0; + val = 0; + while ((ch = *src++) != '\0') { + const char *pch; + + pch = strchr((xdigits = xdigits_l), ch); + if (pch == NULL) + pch = strchr((xdigits = xdigits_u), ch); + if (pch != NULL) { + val <<= 4; + val |= (pch - xdigits); + if (++seen_xdigits > 4) + return (0); + continue; + } + if (ch == ':') { + curtok = src; + if (!seen_xdigits) + return (0); + if (tp + NS_INT16SZ > endp) + return (0); + *tp++ = (unsigned char) (val >> 8) & 0xff; + *tp++ = (unsigned char) val & 0xff; + seen_xdigits = 0; + val = 0; + continue; + } + return (0); + } + if (seen_xdigits) { + if (tp + NS_INT16SZ > endp) + return (0); + *tp++ = (unsigned char) (val >> 8) & 0xff; + *tp++ = (unsigned char) val & 0xff; + } + if (tp != endp) + return (0); + memcpy(dst, tmp, NS_LOCATORSZ); + return (1); +} + static inline int getquad(const void *src, struct in_addr *dst, isc_lex_t *lexer, dns_rdatacallbacks_t *callbacks) diff --git a/lib/dns/rdata/generic/l32_105.c b/lib/dns/rdata/generic/l32_105.c new file mode 100644 index 0000000000..0b3e6830f4 --- /dev/null +++ b/lib/dns/rdata/generic/l32_105.c @@ -0,0 +1,233 @@ +/* + * Copyright (C) 2012 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. + */ + +#ifndef RDATA_GENERIC_L32_105_C +#define RDATA_GENERIC_L32_105_C + +#include + +#include + +#define RRTYPE_L32_ATTRIBUTES (0) + +static inline isc_result_t +fromtext_l32(ARGS_FROMTEXT) { + isc_token_t token; + struct in_addr addr; + isc_region_t region; + + REQUIRE(type == 105); + + UNUSED(type); + UNUSED(rdclass); + UNUSED(origin); + UNUSED(options); + UNUSED(callbacks); + + RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number, + ISC_FALSE)); + if (token.value.as_ulong > 0xffffU) + RETTOK(ISC_R_RANGE); + RETERR(uint16_tobuffer(token.value.as_ulong, target)); + + RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_string, + ISC_FALSE)); + + if (getquad(DNS_AS_STR(token), &addr, lexer, callbacks) != 1) + RETTOK(DNS_R_BADDOTTEDQUAD); + isc_buffer_availableregion(target, ®ion); + if (region.length < 4) + return (ISC_R_NOSPACE); + memcpy(region.base, &addr, 4); + isc_buffer_add(target, 4); + return (ISC_R_SUCCESS); +} + +static inline isc_result_t +totext_l32(ARGS_TOTEXT) { + isc_region_t region; + char buf[sizeof("65000")]; + unsigned short num; + + REQUIRE(rdata->type == 105); + REQUIRE(rdata->length == 6); + + UNUSED(tctx); + + dns_rdata_toregion(rdata, ®ion); + num = uint16_fromregion(®ion); + isc_region_consume(®ion, 2); + sprintf(buf, "%u", num); + RETERR(str_totext(buf, target)); + + RETERR(str_totext(" ", target)); + + return (inet_totext(AF_INET, ®ion, target)); +} + +static inline isc_result_t +fromwire_l32(ARGS_FROMWIRE) { + isc_region_t sregion; + + REQUIRE(type == 105); + + UNUSED(type); + UNUSED(options); + UNUSED(rdclass); + UNUSED(dctx); + + isc_buffer_activeregion(source, &sregion); + if (sregion.length != 6) + return (DNS_R_FORMERR); + isc_buffer_forward(source, sregion.length); + return (mem_tobuffer(target, sregion.base, sregion.length)); +} + +static inline isc_result_t +towire_l32(ARGS_TOWIRE) { + + REQUIRE(rdata->type == 105); + REQUIRE(rdata->length == 6); + + UNUSED(cctx); + + return (mem_tobuffer(target, rdata->data, rdata->length)); +} + +static inline int +compare_l32(ARGS_COMPARE) { + isc_region_t region1; + isc_region_t region2; + + REQUIRE(rdata1->type == rdata2->type); + REQUIRE(rdata1->rdclass == rdata2->rdclass); + REQUIRE(rdata1->type == 105); + REQUIRE(rdata1->length == 6); + REQUIRE(rdata2->length == 6); + + dns_rdata_toregion(rdata1, ®ion1); + dns_rdata_toregion(rdata2, ®ion2); + return (isc_region_compare(®ion1, ®ion2)); +} + +static inline isc_result_t +fromstruct_l32(ARGS_FROMSTRUCT) { + dns_rdata_l32_t *l32 = source; + isc_uint32_t n; + + REQUIRE(type == 105); + REQUIRE(source != NULL); + REQUIRE(l32->common.rdtype == type); + REQUIRE(l32->common.rdclass == rdclass); + + UNUSED(type); + UNUSED(rdclass); + + RETERR(uint16_tobuffer(l32->pref, target)); + n = ntohl(l32->l32.s_addr); + return (uint32_tobuffer(n, target)); +} + +static inline isc_result_t +tostruct_l32(ARGS_TOSTRUCT) { + isc_region_t region; + dns_rdata_l32_t *l32 = target; + isc_uint32_t n; + + REQUIRE(rdata->type == 105); + REQUIRE(target != NULL); + REQUIRE(rdata->length == 6); + + UNUSED(mctx); + + l32->common.rdclass = rdata->rdclass; + l32->common.rdtype = rdata->type; + ISC_LINK_INIT(&l32->common, link); + + dns_rdata_toregion(rdata, ®ion); + l32->pref = uint16_fromregion(®ion); + n = uint32_fromregion(®ion); + l32->l32.s_addr = htonl(n); + return (ISC_R_SUCCESS); +} + +static inline void +freestruct_l32(ARGS_FREESTRUCT) { + dns_rdata_l32_t *l32 = source; + + REQUIRE(source != NULL); + REQUIRE(l32->common.rdtype == 105); + + return; +} + +static inline isc_result_t +additionaldata_l32(ARGS_ADDLDATA) { + + REQUIRE(rdata->type == 105); + REQUIRE(rdata->length == 6); + + UNUSED(rdata); + UNUSED(add); + UNUSED(arg); + + return (ISC_R_SUCCESS); +} + +static inline isc_result_t +digest_l32(ARGS_DIGEST) { + isc_region_t r; + + REQUIRE(rdata->type == 105); + REQUIRE(rdata->length == 6); + + dns_rdata_toregion(rdata, &r); + + return ((digest)(arg, &r)); +} + +static inline isc_boolean_t +checkowner_l32(ARGS_CHECKOWNER) { + + REQUIRE(type == 105); + + UNUSED(name); + UNUSED(type); + UNUSED(rdclass); + UNUSED(wildcard); + + return (ISC_TRUE); +} + +static inline isc_boolean_t +checknames_l32(ARGS_CHECKNAMES) { + + REQUIRE(rdata->type == 105); + REQUIRE(rdata->length == 6); + + UNUSED(rdata); + UNUSED(owner); + UNUSED(bad); + + return (ISC_TRUE); +} + +static inline int +casecompare_l32(ARGS_COMPARE) { + return (compare_l32(rdata1, rdata2)); +} + +#endif /* RDATA_GENERIC_L32_105_C */ diff --git a/lib/dns/rdata/generic/l32_105.h b/lib/dns/rdata/generic/l32_105.h new file mode 100644 index 0000000000..d330b8b6ac --- /dev/null +++ b/lib/dns/rdata/generic/l32_105.h @@ -0,0 +1,27 @@ +/* + * Copyright (C) 2012 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. + */ + +/* */ +#ifndef GENERIC_L32_105_H +#define GENERIC_L32_105_H 1 + +typedef struct dns_rdata_l32 { + dns_rdatacommon_t common; + isc_uint16_t pref; + struct in_addr l32; +} dns_rdata_l32_t; + +#endif /* GENERIC_L32_105_H */ diff --git a/lib/dns/rdata/generic/l64_106.c b/lib/dns/rdata/generic/l64_106.c new file mode 100644 index 0000000000..2424bcde2a --- /dev/null +++ b/lib/dns/rdata/generic/l64_106.c @@ -0,0 +1,228 @@ +/* + * Copyright (C) 2012 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. + */ + +#ifndef RDATA_GENERIC_L64_106_C +#define RDATA_GENERIC_L64_106_C + +#include + +#include + +#define RRTYPE_L64_ATTRIBUTES (0) + +static inline isc_result_t +fromtext_l64(ARGS_FROMTEXT) { + isc_token_t token; + unsigned char locator[NS_LOCATORSZ]; + + REQUIRE(type == 106); + + UNUSED(type); + UNUSED(rdclass); + UNUSED(origin); + UNUSED(options); + UNUSED(callbacks); + + RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number, + ISC_FALSE)); + if (token.value.as_ulong > 0xffffU) + RETTOK(ISC_R_RANGE); + RETERR(uint16_tobuffer(token.value.as_ulong, target)); + + RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_string, + ISC_FALSE)); + + if (locator_pton(DNS_AS_STR(token), locator) != 1) + RETTOK(DNS_R_SYNTAX); + return (mem_tobuffer(target, locator, NS_LOCATORSZ)); +} + +static inline isc_result_t +totext_l64(ARGS_TOTEXT) { + isc_region_t region; + char buf[sizeof("xxxx:xxxx:xxxx:xxxx")]; + unsigned short num; + + REQUIRE(rdata->type == 106); + REQUIRE(rdata->length == 10); + + UNUSED(tctx); + + dns_rdata_toregion(rdata, ®ion); + num = uint16_fromregion(®ion); + isc_region_consume(®ion, 2); + sprintf(buf, "%u", num); + RETERR(str_totext(buf, target)); + + RETERR(str_totext(" ", target)); + + sprintf(buf, "%x:%x:%x:%x", + region.base[0]<<8 | region.base[1], + region.base[2]<<8 | region.base[3], + region.base[4]<<8 | region.base[5], + region.base[6]<<8 | region.base[7]); + return (str_totext(buf, target)); +} + +static inline isc_result_t +fromwire_l64(ARGS_FROMWIRE) { + isc_region_t sregion; + + REQUIRE(type == 106); + + UNUSED(type); + UNUSED(options); + UNUSED(rdclass); + UNUSED(dctx); + + isc_buffer_activeregion(source, &sregion); + if (sregion.length != 10) + return (DNS_R_FORMERR); + isc_buffer_forward(source, sregion.length); + return (mem_tobuffer(target, sregion.base, sregion.length)); +} + +static inline isc_result_t +towire_l64(ARGS_TOWIRE) { + + REQUIRE(rdata->type == 106); + REQUIRE(rdata->length == 10); + + UNUSED(cctx); + + return (mem_tobuffer(target, rdata->data, rdata->length)); +} + +static inline int +compare_l64(ARGS_COMPARE) { + isc_region_t region1; + isc_region_t region2; + + REQUIRE(rdata1->type == rdata2->type); + REQUIRE(rdata1->rdclass == rdata2->rdclass); + REQUIRE(rdata1->type == 106); + REQUIRE(rdata1->length == 10); + REQUIRE(rdata2->length == 10); + + dns_rdata_toregion(rdata1, ®ion1); + dns_rdata_toregion(rdata2, ®ion2); + return (isc_region_compare(®ion1, ®ion2)); +} + +static inline isc_result_t +fromstruct_l64(ARGS_FROMSTRUCT) { + dns_rdata_l64_t *l64 = source; + + REQUIRE(type == 106); + REQUIRE(source != NULL); + REQUIRE(l64->common.rdtype == type); + REQUIRE(l64->common.rdclass == rdclass); + + UNUSED(type); + UNUSED(rdclass); + + RETERR(uint16_tobuffer(l64->pref, target)); + return (mem_tobuffer(target, l64->l64, sizeof(l64->l64))); +} + +static inline isc_result_t +tostruct_l64(ARGS_TOSTRUCT) { + isc_region_t region; + dns_rdata_l64_t *l64 = target; + + REQUIRE(rdata->type == 106); + REQUIRE(target != NULL); + REQUIRE(rdata->length == 10); + + UNUSED(mctx); + + l64->common.rdclass = rdata->rdclass; + l64->common.rdtype = rdata->type; + ISC_LINK_INIT(&l64->common, link); + + dns_rdata_toregion(rdata, ®ion); + l64->pref = uint16_fromregion(®ion); + memcpy(l64->l64, region.base, region.length); + return (ISC_R_SUCCESS); +} + +static inline void +freestruct_l64(ARGS_FREESTRUCT) { + dns_rdata_l64_t *l64 = source; + + REQUIRE(source != NULL); + REQUIRE(l64->common.rdtype == 106); + + return; +} + +static inline isc_result_t +additionaldata_l64(ARGS_ADDLDATA) { + + REQUIRE(rdata->type == 106); + REQUIRE(rdata->length == 10); + + UNUSED(rdata); + UNUSED(add); + UNUSED(arg); + + return (ISC_R_SUCCESS); +} + +static inline isc_result_t +digest_l64(ARGS_DIGEST) { + isc_region_t r; + + REQUIRE(rdata->type == 106); + REQUIRE(rdata->length == 10); + + dns_rdata_toregion(rdata, &r); + + return ((digest)(arg, &r)); +} + +static inline isc_boolean_t +checkowner_l64(ARGS_CHECKOWNER) { + + REQUIRE(type == 106); + + UNUSED(name); + UNUSED(type); + UNUSED(rdclass); + UNUSED(wildcard); + + return (ISC_TRUE); +} + +static inline isc_boolean_t +checknames_l64(ARGS_CHECKNAMES) { + + REQUIRE(rdata->type == 106); + REQUIRE(rdata->length == 10); + + UNUSED(rdata); + UNUSED(owner); + UNUSED(bad); + + return (ISC_TRUE); +} + +static inline int +casecompare_l64(ARGS_COMPARE) { + return (compare_l64(rdata1, rdata2)); +} + +#endif /* RDATA_GENERIC_L64_106_C */ diff --git a/lib/dns/rdata/generic/l64_106.h b/lib/dns/rdata/generic/l64_106.h new file mode 100644 index 0000000000..e1f970d757 --- /dev/null +++ b/lib/dns/rdata/generic/l64_106.h @@ -0,0 +1,27 @@ +/* + * Copyright (C) 2012 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. + */ + +/* */ +#ifndef GENERIC_L64_106_H +#define GENERIC_L64_106_H 1 + +typedef struct dns_rdata_l64 { + dns_rdatacommon_t common; + isc_uint16_t pref; + unsigned char l64[8]; +} dns_rdata_l64_t; + +#endif /* GENERIC_L64_106_H */ diff --git a/lib/dns/rdata/generic/lp_107.c b/lib/dns/rdata/generic/lp_107.c new file mode 100644 index 0000000000..32f0366094 --- /dev/null +++ b/lib/dns/rdata/generic/lp_107.c @@ -0,0 +1,276 @@ +/* + * Copyright (C) 2004, 2005, 2007, 2009 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1998-2001, 2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and/or distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +#ifndef RDATA_GENERIC_LP_107_C +#define RDATA_GENERIC_LP_107_C + +#include + +#include + +#define RRTYPE_LP_ATTRIBUTES (0) + +static inline isc_result_t +fromtext_lp(ARGS_FROMTEXT) { + isc_token_t token; + dns_name_t name; + isc_buffer_t buffer; + + REQUIRE(type == 107); + + UNUSED(type); + UNUSED(rdclass); + UNUSED(callbacks); + + RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number, + ISC_FALSE)); + if (token.value.as_ulong > 0xffffU) + RETTOK(ISC_R_RANGE); + RETERR(uint16_tobuffer(token.value.as_ulong, target)); + + RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_string, + ISC_FALSE)); + + dns_name_init(&name, NULL); + buffer_fromregion(&buffer, &token.value.as_region); + origin = (origin != NULL) ? origin : dns_rootname; + return (dns_name_fromtext(&name, &buffer, origin, options, target)); +} + +static inline isc_result_t +totext_lp(ARGS_TOTEXT) { + isc_region_t region; + dns_name_t name; + dns_name_t prefix; + isc_boolean_t sub; + char buf[sizeof("64000")]; + unsigned short num; + + REQUIRE(rdata->type == 107); + REQUIRE(rdata->length != 0); + + dns_name_init(&name, NULL); + dns_name_init(&prefix, NULL); + + dns_rdata_toregion(rdata, ®ion); + num = uint16_fromregion(®ion); + isc_region_consume(®ion, 2); + sprintf(buf, "%u", num); + RETERR(str_totext(buf, target)); + + RETERR(str_totext(" ", target)); + + dns_name_fromregion(&name, ®ion); + sub = name_prefix(&name, tctx->origin, &prefix); + return (dns_name_totext(&prefix, sub, target)); +} + +static inline isc_result_t +fromwire_lp(ARGS_FROMWIRE) { + dns_name_t name; + isc_region_t sregion; + + REQUIRE(type == 107); + + UNUSED(type); + UNUSED(rdclass); + + dns_decompress_setmethods(dctx, DNS_COMPRESS_GLOBAL14); + + dns_name_init(&name, NULL); + + isc_buffer_activeregion(source, &sregion); + if (sregion.length < 2) + return (ISC_R_UNEXPECTEDEND); + RETERR(mem_tobuffer(target, sregion.base, 2)); + isc_buffer_forward(source, 2); + return (dns_name_fromwire(&name, source, dctx, options, target)); +} + +static inline isc_result_t +towire_lp(ARGS_TOWIRE) { + + REQUIRE(rdata->type == 107); + REQUIRE(rdata->length != 0); + + UNUSED(cctx); + + return (mem_tobuffer(target, rdata->data, rdata->length)); +} + +static inline int +compare_lp(ARGS_COMPARE) { + isc_region_t region1; + isc_region_t region2; + + REQUIRE(rdata1->type == rdata2->type); + REQUIRE(rdata1->rdclass == rdata2->rdclass); + REQUIRE(rdata1->type == 107); + REQUIRE(rdata1->length != 0); + REQUIRE(rdata2->length != 0); + + dns_rdata_toregion(rdata1, ®ion1); + dns_rdata_toregion(rdata2, ®ion2); + + return (isc_region_compare(®ion1, ®ion2)); +} + +static inline isc_result_t +fromstruct_lp(ARGS_FROMSTRUCT) { + dns_rdata_lp_t *lp = source; + isc_region_t region; + + REQUIRE(type == 107); + REQUIRE(source != NULL); + REQUIRE(lp->common.rdtype == type); + REQUIRE(lp->common.rdclass == rdclass); + + UNUSED(type); + UNUSED(rdclass); + + RETERR(uint16_tobuffer(lp->pref, target)); + dns_name_toregion(&lp->lp, ®ion); + return (isc_buffer_copyregion(target, ®ion)); +} + +static inline isc_result_t +tostruct_lp(ARGS_TOSTRUCT) { + isc_region_t region; + dns_rdata_lp_t *lp = target; + dns_name_t name; + + REQUIRE(rdata->type == 107); + REQUIRE(target != NULL); + REQUIRE(rdata->length != 0); + + lp->common.rdclass = rdata->rdclass; + lp->common.rdtype = rdata->type; + ISC_LINK_INIT(&lp->common, link); + + dns_name_init(&name, NULL); + dns_rdata_toregion(rdata, ®ion); + lp->pref = uint16_fromregion(®ion); + isc_region_consume(®ion, 2); + dns_name_fromregion(&name, ®ion); + dns_name_init(&lp->lp, NULL); + RETERR(name_duporclone(&name, mctx, &lp->lp)); + lp->mctx = mctx; + return (ISC_R_SUCCESS); +} + +static inline void +freestruct_lp(ARGS_FREESTRUCT) { + dns_rdata_lp_t *lp = source; + + REQUIRE(source != NULL); + REQUIRE(lp->common.rdtype == 107); + + if (lp->mctx == NULL) + return; + + dns_name_free(&lp->lp, lp->mctx); + lp->mctx = NULL; +} + +static inline isc_result_t +additionaldata_lp(ARGS_ADDLDATA) { + dns_name_t name; + dns_offsets_t offsets; + isc_region_t region; + isc_result_t result; + + REQUIRE(rdata->type == 107); + + dns_name_init(&name, offsets); + dns_rdata_toregion(rdata, ®ion); + isc_region_consume(®ion, 2); + dns_name_fromregion(&name, ®ion); + + result = (add)(arg, &name, dns_rdatatype_l32); + if (result != ISC_R_SUCCESS) + return (result); + return ((add)(arg, &name, dns_rdatatype_l64)); +} + +static inline isc_result_t +digest_lp(ARGS_DIGEST) { + isc_region_t region; + + REQUIRE(rdata->type == 107); + + dns_rdata_toregion(rdata, ®ion); + return ((digest)(arg, ®ion)); +} + +static inline isc_boolean_t +checkowner_lp(ARGS_CHECKOWNER) { + + REQUIRE(type == 107); + + UNUSED(type); + UNUSED(rdclass); + UNUSED(name); + UNUSED(wildcard); + + return (ISC_TRUE); +} + +static inline isc_boolean_t +checknames_lp(ARGS_CHECKNAMES) { + + REQUIRE(rdata->type == 107); + + UNUSED(bad); + UNUSED(owner); + + return (ISC_TRUE); +} + +static inline int +casecompare_lp(ARGS_COMPARE) { + dns_name_t name1; + dns_name_t name2; + isc_region_t region1; + isc_region_t region2; + int order; + + REQUIRE(rdata1->type == rdata2->type); + REQUIRE(rdata1->rdclass == rdata2->rdclass); + REQUIRE(rdata1->type == 107); + REQUIRE(rdata1->length != 0); + REQUIRE(rdata2->length != 0); + + order = memcmp(rdata1->data, rdata2->data, 2); + if (order != 0) + return (order < 0 ? -1 : 1); + + dns_name_init(&name1, NULL); + dns_name_init(&name2, NULL); + + dns_rdata_toregion(rdata1, ®ion1); + dns_rdata_toregion(rdata2, ®ion2); + + isc_region_consume(®ion1, 2); + isc_region_consume(®ion2, 2); + + dns_name_fromregion(&name1, ®ion1); + dns_name_fromregion(&name2, ®ion2); + + return (dns_name_rdatacompare(&name1, &name2)); +} + +#endif /* RDATA_GENERIC_LP_107_C */ diff --git a/lib/dns/rdata/generic/lp_107.h b/lib/dns/rdata/generic/lp_107.h new file mode 100644 index 0000000000..de7119389f --- /dev/null +++ b/lib/dns/rdata/generic/lp_107.h @@ -0,0 +1,28 @@ +/* + * Copyright (C) 2012 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. + */ + +/* */ +#ifndef GENERIC_LP_107_H +#define GENERIC_LP_107_H 1 + +typedef struct dns_rdata_lp { + dns_rdatacommon_t common; + isc_mem_t *mctx; + isc_uint16_t pref; + dns_name_t lp; +} dns_rdata_lp_t; + +#endif /* GENERIC_LP_107_H */ diff --git a/lib/dns/rdata/generic/nid_104.c b/lib/dns/rdata/generic/nid_104.c new file mode 100644 index 0000000000..383c795d07 --- /dev/null +++ b/lib/dns/rdata/generic/nid_104.c @@ -0,0 +1,228 @@ +/* + * Copyright (C) 2012 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. + */ + +#ifndef RDATA_GENERIC_NID_104_C +#define RDATA_GENERIC_NID_104_C + +#include + +#include + +#define RRTYPE_NID_ATTRIBUTES (0) + +static inline isc_result_t +fromtext_nid(ARGS_FROMTEXT) { + isc_token_t token; + unsigned char locator[NS_LOCATORSZ]; + + REQUIRE(type == 104); + + UNUSED(type); + UNUSED(rdclass); + UNUSED(origin); + UNUSED(options); + UNUSED(callbacks); + + RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number, + ISC_FALSE)); + if (token.value.as_ulong > 0xffffU) + RETTOK(ISC_R_RANGE); + RETERR(uint16_tobuffer(token.value.as_ulong, target)); + + RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_string, + ISC_FALSE)); + + if (locator_pton(DNS_AS_STR(token), locator) != 1) + RETTOK(DNS_R_SYNTAX); + return (mem_tobuffer(target, locator, NS_LOCATORSZ)); +} + +static inline isc_result_t +totext_nid(ARGS_TOTEXT) { + isc_region_t region; + char buf[sizeof("xxxx:xxxx:xxxx:xxxx")]; + unsigned short num; + + REQUIRE(rdata->type == 104); + REQUIRE(rdata->length != 0); + + UNUSED(tctx); + + dns_rdata_toregion(rdata, ®ion); + num = uint16_fromregion(®ion); + isc_region_consume(®ion, 2); + sprintf(buf, "%u", num); + RETERR(str_totext(buf, target)); + + RETERR(str_totext(" ", target)); + + sprintf(buf, "%x:%x:%x:%x", + region.base[0]<<8 | region.base[1], + region.base[2]<<8 | region.base[3], + region.base[4]<<8 | region.base[5], + region.base[6]<<8 | region.base[7]); + return (str_totext(buf, target)); +} + +static inline isc_result_t +fromwire_nid(ARGS_FROMWIRE) { + isc_region_t sregion; + + REQUIRE(type == 104); + + UNUSED(type); + UNUSED(options); + UNUSED(rdclass); + UNUSED(dctx); + + isc_buffer_activeregion(source, &sregion); + if (sregion.length != 10) + return (DNS_R_FORMERR); + isc_buffer_forward(source, sregion.length); + return (mem_tobuffer(target, sregion.base, sregion.length)); +} + +static inline isc_result_t +towire_nid(ARGS_TOWIRE) { + + REQUIRE(rdata->type == 104); + REQUIRE(rdata->length == 10); + + UNUSED(cctx); + + return (mem_tobuffer(target, rdata->data, rdata->length)); +} + +static inline int +compare_nid(ARGS_COMPARE) { + isc_region_t region1; + isc_region_t region2; + + REQUIRE(rdata1->type == rdata2->type); + REQUIRE(rdata1->rdclass == rdata2->rdclass); + REQUIRE(rdata1->type == 104); + REQUIRE(rdata1->length == 10); + REQUIRE(rdata2->length == 10); + + dns_rdata_toregion(rdata1, ®ion1); + dns_rdata_toregion(rdata2, ®ion2); + return (isc_region_compare(®ion1, ®ion2)); +} + +static inline isc_result_t +fromstruct_nid(ARGS_FROMSTRUCT) { + dns_rdata_nid_t *nid = source; + + REQUIRE(type == 104); + REQUIRE(source != NULL); + REQUIRE(nid->common.rdtype == type); + REQUIRE(nid->common.rdclass == rdclass); + + UNUSED(type); + UNUSED(rdclass); + + RETERR(uint16_tobuffer(nid->pref, target)); + return (mem_tobuffer(target, nid->nid, sizeof(nid->nid))); +} + +static inline isc_result_t +tostruct_nid(ARGS_TOSTRUCT) { + isc_region_t region; + dns_rdata_nid_t *nid = target; + + REQUIRE(rdata->type == 104); + REQUIRE(target != NULL); + REQUIRE(rdata->length == 10); + + UNUSED(mctx); + + nid->common.rdclass = rdata->rdclass; + nid->common.rdtype = rdata->type; + ISC_LINK_INIT(&nid->common, link); + + dns_rdata_toregion(rdata, ®ion); + nid->pref = uint16_fromregion(®ion); + memcpy(nid->nid, region.base, region.length); + return (ISC_R_SUCCESS); +} + +static inline void +freestruct_nid(ARGS_FREESTRUCT) { + dns_rdata_nid_t *nid = source; + + REQUIRE(source != NULL); + REQUIRE(nid->common.rdtype == 104); + + return; +} + +static inline isc_result_t +additionaldata_nid(ARGS_ADDLDATA) { + + REQUIRE(rdata->type == 104); + REQUIRE(rdata->length == 10); + + UNUSED(rdata); + UNUSED(add); + UNUSED(arg); + + return (ISC_R_SUCCESS); +} + +static inline isc_result_t +digest_nid(ARGS_DIGEST) { + isc_region_t r; + + REQUIRE(rdata->type == 104); + REQUIRE(rdata->length == 10); + + dns_rdata_toregion(rdata, &r); + + return ((digest)(arg, &r)); +} + +static inline isc_boolean_t +checkowner_nid(ARGS_CHECKOWNER) { + + REQUIRE(type == 104); + + UNUSED(name); + UNUSED(type); + UNUSED(rdclass); + UNUSED(wildcard); + + return (ISC_TRUE); +} + +static inline isc_boolean_t +checknames_nid(ARGS_CHECKNAMES) { + + REQUIRE(rdata->type == 104); + REQUIRE(rdata->length == 10); + + UNUSED(rdata); + UNUSED(owner); + UNUSED(bad); + + return (ISC_TRUE); +} + +static inline int +casecompare_nid(ARGS_COMPARE) { + return (compare_nid(rdata1, rdata2)); +} + +#endif /* RDATA_GENERIC_NID_104_C */ diff --git a/lib/dns/rdata/generic/nid_104.h b/lib/dns/rdata/generic/nid_104.h new file mode 100644 index 0000000000..0f1b18a9a7 --- /dev/null +++ b/lib/dns/rdata/generic/nid_104.h @@ -0,0 +1,27 @@ +/* + * Copyright (C) 2012 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. + */ + +/* */ +#ifndef GENERIC_NID_104_H +#define GENERIC_NID_104_H 1 + +typedef struct dns_rdata_nid { + dns_rdatacommon_t common; + isc_uint16_t pref; + unsigned char nid[8]; +} dns_rdata_nid_t; + +#endif /* GENERIC_NID_104_H */