diff --git a/contrib/query-loc-0.3.0/ADDRESSES b/contrib/query-loc-0.3.0/ADDRESSES
new file mode 100644
index 0000000000..370fde0681
--- /dev/null
+++ b/contrib/query-loc-0.3.0/ADDRESSES
@@ -0,0 +1,18 @@
+The following machines, at least today seem to have LOC
+records:
+
+*.cpod.fr (for instance www.cpod.fr)
+130.104.3.*
+195.202.193.*
+Melanie.Tolna.Net
+204.92.254.*
+mail.vitts.com
+alink.net
+caida.org
+ckdhr.com
+distributed.net (rc5stats.distributed.net)
+nikhef.nl
+yahoo.com
+nic.af
+
+$Id: ADDRESSES,v 1.1 2005/04/01 05:34:59 marka Exp $
diff --git a/contrib/query-loc-0.3.0/ALGO b/contrib/query-loc-0.3.0/ALGO
new file mode 100644
index 0000000000..4695dc14c7
--- /dev/null
+++ b/contrib/query-loc-0.3.0/ALGO
@@ -0,0 +1,48 @@
+Just for info, can be out of date.
+
+
+RFC 1876, 5.2, specially 5.2.3
+
+Important points:
+
+- LOC RRs are always attached to a *name*.
+- we can have two (or more) RRs for one address, one more specific than the other
+
+main
+ if (host is a name) 
+	getLOCbyname
+ else # host is an IP address	
+	gethostbyaddr
+	if (name) 
+		getLOCbyname
+		# If there is none, do not search. We assume the above was sufficient	       # (But check 5.2.2)
+	else
+		getLOCbyaddress
+
+getLOCbyname (host) 
+	get LOC for host
+	if (it exists)
+		OK
+	else
+		get all A records of the name
+		foreach A record
+			getLOCbyaddress
+			OK at the first one found 
+				# we assume they are consistent
+		END
+
+getLOCbyaddress (address)
+	# May receive a mask. Otherwise, deduce it from the class
+	makeNetAddress
+	getLOCbynetwork
+
+getLOCbynetwork
+	get PTR and A for it
+	if (exist)
+		getLOCbyname
+	******* DIFFICULT : we have to manage a stack. See the code
+		makeNetAddress (level--)
+		getLOCbynetwork
+	else
+		END
+	
diff --git a/contrib/query-loc-0.3.0/INSTALL b/contrib/query-loc-0.3.0/INSTALL
new file mode 100644
index 0000000000..5f31e7bd08
--- /dev/null
+++ b/contrib/query-loc-0.3.0/INSTALL
@@ -0,0 +1,9 @@
+Type './configure', then 'make' and (as root if necessary) 'make
+install'.
+
+It requires a recent libresolv, with loc_ntoa, but use an alternative
+which I provide, if not found.
+
+Tested on Linux (i386 and Alpha), Solaris (Sparc) and Digital Unix (Alpha).
+
+$Id: INSTALL,v 1.1 2005/04/01 05:34:59 marka Exp $
diff --git a/contrib/query-loc-0.3.0/Makefile.in b/contrib/query-loc-0.3.0/Makefile.in
new file mode 100644
index 0000000000..82075c308b
--- /dev/null
+++ b/contrib/query-loc-0.3.0/Makefile.in
@@ -0,0 +1,40 @@
+# $Id: Makefile.in,v 1.1 2005/04/01 05:34:59 marka Exp $
+CC=@CC@
+CFLAGS=@CFLAGS@ 
+LIBS=@LIBS@
+DESTDIR=@prefix@
+BINDIR=@prefix@/bin
+MANDIR=@prefix@/share/man/man1
+DISTRIB= README INSTALL ALGO USAGE ADDRESSES Makefile.in configure configure.in config.h.in install-sh loc.h loc.c query-loc.c loc_ntoa.c query-loc.1
+OBJS=query-loc.o loc.o @LOC_NTOA@
+VERSION=`grep VERSION loc.h | cut -d ' ' -f 3 | sed s/\"//g`
+
+all: query-loc
+
+query-loc: $(OBJS)
+	$(CC) -o $@ $(OBJS) $(LIBS)
+
+%.o: %.c loc.h
+	$(CC) $(CFLAGS) -c $<
+
+clean:
+	rm -f *.o query-loc *~ 
+
+distclean: clean
+	rm -f config.h config.cache config.log config.status Makefile
+
+distrib: clean
+	./reconf
+	@(echo Query-Loc is version ${VERSION}; \
+	mkdir query-loc-${VERSION}; \
+	cp $(DISTRIB) query-loc-${VERSION};\
+	tar cvf query-loc-${VERSION}.tar query-loc-${VERSION}; \
+	rm -rf query-loc-${VERSION}; \
+	gzip -v -9 -f query-loc-${VERSION}.tar);
+
+install:
+	@INSTALL@ -m 0755 query-loc $(BINDIR)
+	if [ ! -d $(MANDIR) ]; then \
+		mkdir $(MANDIR); \
+	fi
+	@INSTALL@ -m 0644 query-loc.1 $(MANDIR)
diff --git a/contrib/query-loc-0.3.0/README b/contrib/query-loc-0.3.0/README
new file mode 100644
index 0000000000..fc49c7397e
--- /dev/null
+++ b/contrib/query-loc-0.3.0/README
@@ -0,0 +1,20 @@
+   query-loc: a program to retrieve and display the location
+   information in the DNS. 
+
+   It uses the algorithms described in
+   RFC 1876 (and RFC 1101 to get the network names).
+   You can find examples of networks wchich implement this scheme
+   in the ADDRESSES file.
+
+   It is under the General Public Licence (GPL, which
+   you can fetch from <http://www.gnu.org/copyleft/gpl.html>.
+
+   Copyright Stéphane Bortzmeyer <bortzmeyer@debian.org>, 1998.
+
+   Thanks to Paul Vixie for the RFC and its encouragements. Thanks
+   to Björn Augustsson  for the xtraceroute program 
+   <http://www.dtek.chalmers.se/~d3august/xt/>.
+
+$Id: README,v 1.1 2005/04/01 05:34:59 marka Exp $
+
+
diff --git a/contrib/query-loc-0.3.0/USAGE b/contrib/query-loc-0.3.0/USAGE
new file mode 100644
index 0000000000..233d6ca144
--- /dev/null
+++ b/contrib/query-loc-0.3.0/USAGE
@@ -0,0 +1,8 @@
+query-loc [-v] [-d nnn] host-name-or-address
+
+Examples of hosts with LOCation info (quite uncommon, if you know more, 
+please tell me):
+
+- Everything in the 193.105.79.0 network, such as www.humanite.presse.fr
+- Everything in the 192.88.144 network, such as www.kei.com
+
diff --git a/contrib/query-loc-0.3.0/config.h.in b/contrib/query-loc-0.3.0/config.h.in
new file mode 100644
index 0000000000..d90187ce3b
--- /dev/null
+++ b/contrib/query-loc-0.3.0/config.h.in
@@ -0,0 +1,69 @@
+/* config.h.in.  Generated from configure.in by autoheader.  */
+/* $Id: config.h.in,v 1.1 2005/04/01 05:35:00 marka Exp $ */
+
+
+/* Define to 1 if you have the <inttypes.h> header file. */
+#undef HAVE_INTTYPES_H
+
+/* Define to 1 if you have the `resolv' library (-lresolv). */
+#undef HAVE_LIBRESOLV
+
+/* Define to 1 if you have the <memory.h> header file. */
+#undef HAVE_MEMORY_H
+
+/* Define to 1 if you have the <stdint.h> header file. */
+#undef HAVE_STDINT_H
+
+/* Define to 1 if you have the <stdlib.h> header file. */
+#undef HAVE_STDLIB_H
+
+/* Define to 1 if you have the <strings.h> header file. */
+#undef HAVE_STRINGS_H
+
+/* Define to 1 if you have the <string.h> header file. */
+#undef HAVE_STRING_H
+
+/* Define to 1 if you have the <sys/stat.h> header file. */
+#undef HAVE_SYS_STAT_H
+
+/* Define to 1 if you have the <sys/types.h> header file. */
+#undef HAVE_SYS_TYPES_H
+
+/* Define to 1 if you have the <unistd.h> header file. */
+#undef HAVE_UNISTD_H
+
+/* Define to the address where bug reports for this package should be sent. */
+#undef PACKAGE_BUGREPORT
+
+/* Define to the full name of this package. */
+#undef PACKAGE_NAME
+
+/* Define to the full name and version of this package. */
+#undef PACKAGE_STRING
+
+/* Define to the one symbol short name of this package. */
+#undef PACKAGE_TARNAME
+
+/* Define to the version of this package. */
+#undef PACKAGE_VERSION
+
+/* The size of a `char', as computed by sizeof. */
+#undef SIZEOF_CHAR
+
+/* The size of a `int', as computed by sizeof. */
+#undef SIZEOF_INT
+
+/* The size of a `long', as computed by sizeof. */
+#undef SIZEOF_LONG
+
+/* The size of a `short', as computed by sizeof. */
+#undef SIZEOF_SHORT
+
+/* Define to 1 if you have the ANSI C header files. */
+#undef STDC_HEADERS
+
+/* Define to empty if `const' does not conform to ANSI C. */
+#undef const
+
+/* Is there a loc_ntoa on this system?  */
+#undef HAVE_LOC_NTOA
diff --git a/contrib/query-loc-0.3.0/configure b/contrib/query-loc-0.3.0/configure
new file mode 100755
index 0000000000..d77cf76ca5
--- /dev/null
+++ b/contrib/query-loc-0.3.0/configure
@@ -0,0 +1,6436 @@
+#! /bin/sh
+# Guess values for system-dependent variables and create Makefiles.
+# Generated by GNU Autoconf 2.59.
+#
+# Copyright (C) 2003 Free Software Foundation, Inc.
+# This configure script is free software; the Free Software Foundation
+# gives unlimited permission to copy, distribute and modify it.
+## --------------------- ##
+## M4sh Initialization.  ##
+## --------------------- ##
+
+# Be Bourne compatible
+if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
+  emulate sh
+  NULLCMD=:
+  # Zsh 3.x and 4.x performs word splitting on ${1+"$@"}, which
+  # is contrary to our usage.  Disable this feature.
+  alias -g '${1+"$@"}'='"$@"'
+elif test -n "${BASH_VERSION+set}" && (set -o posix) >/dev/null 2>&1; then
+  set -o posix
+fi
+DUALCASE=1; export DUALCASE # for MKS sh
+
+# Support unset when possible.
+if ( (MAIL=60; unset MAIL) || exit) >/dev/null 2>&1; then
+  as_unset=unset
+else
+  as_unset=false
+fi
+
+
+# Work around bugs in pre-3.0 UWIN ksh.
+$as_unset ENV MAIL MAILPATH
+PS1='$ '
+PS2='> '
+PS4='+ '
+
+# NLS nuisances.
+for as_var in \
+  LANG LANGUAGE LC_ADDRESS LC_ALL LC_COLLATE LC_CTYPE LC_IDENTIFICATION \
+  LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER \
+  LC_TELEPHONE LC_TIME
+do
+  if (set +x; test -z "`(eval $as_var=C; export $as_var) 2>&1`"); then
+    eval $as_var=C; export $as_var
+  else
+    $as_unset $as_var
+  fi
+done
+
+# Required to use basename.
+if expr a : '\(a\)' >/dev/null 2>&1; then
+  as_expr=expr
+else
+  as_expr=false
+fi
+
+if (basename /) >/dev/null 2>&1 && test "X`basename / 2>&1`" = "X/"; then
+  as_basename=basename
+else
+  as_basename=false
+fi
+
+
+# Name of the executable.
+as_me=`$as_basename "$0" ||
+$as_expr X/"$0" : '.*/\([^/][^/]*\)/*$' \| \
+	 X"$0" : 'X\(//\)$' \| \
+	 X"$0" : 'X\(/\)$' \| \
+	 .     : '\(.\)' 2>/dev/null ||
+echo X/"$0" |
+    sed '/^.*\/\([^/][^/]*\)\/*$/{ s//\1/; q; }
+  	  /^X\/\(\/\/\)$/{ s//\1/; q; }
+  	  /^X\/\(\/\).*/{ s//\1/; q; }
+  	  s/.*/./; q'`
+
+
+# PATH needs CR, and LINENO needs CR and PATH.
+# Avoid depending upon Character Ranges.
+as_cr_letters='abcdefghijklmnopqrstuvwxyz'
+as_cr_LETTERS='ABCDEFGHIJKLMNOPQRSTUVWXYZ'
+as_cr_Letters=$as_cr_letters$as_cr_LETTERS
+as_cr_digits='0123456789'
+as_cr_alnum=$as_cr_Letters$as_cr_digits
+
+# The user is always right.
+if test "${PATH_SEPARATOR+set}" != set; then
+  echo "#! /bin/sh" >conf$$.sh
+  echo  "exit 0"   >>conf$$.sh
+  chmod +x conf$$.sh
+  if (PATH="/nonexistent;."; conf$$.sh) >/dev/null 2>&1; then
+    PATH_SEPARATOR=';'
+  else
+    PATH_SEPARATOR=:
+  fi
+  rm -f conf$$.sh
+fi
+
+
+  as_lineno_1=$LINENO
+  as_lineno_2=$LINENO
+  as_lineno_3=`(expr $as_lineno_1 + 1) 2>/dev/null`
+  test "x$as_lineno_1" != "x$as_lineno_2" &&
+  test "x$as_lineno_3"  = "x$as_lineno_2"  || {
+  # Find who we are.  Look in the path if we contain no path at all
+  # relative or not.
+  case $0 in
+    *[\\/]* ) as_myself=$0 ;;
+    *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  test -r "$as_dir/$0" && as_myself=$as_dir/$0 && break
+done
+
+       ;;
+  esac
+  # We did not find ourselves, most probably we were run as `sh COMMAND'
+  # in which case we are not to be found in the path.
+  if test "x$as_myself" = x; then
+    as_myself=$0
+  fi
+  if test ! -f "$as_myself"; then
+    { echo "$as_me: error: cannot find myself; rerun with an absolute path" >&2
+   { (exit 1); exit 1; }; }
+  fi
+  case $CONFIG_SHELL in
+  '')
+    as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in /bin$PATH_SEPARATOR/usr/bin$PATH_SEPARATOR$PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for as_base in sh bash ksh sh5; do
+	 case $as_dir in
+	 /*)
+	   if ("$as_dir/$as_base" -c '
+  as_lineno_1=$LINENO
+  as_lineno_2=$LINENO
+  as_lineno_3=`(expr $as_lineno_1 + 1) 2>/dev/null`
+  test "x$as_lineno_1" != "x$as_lineno_2" &&
+  test "x$as_lineno_3"  = "x$as_lineno_2" ') 2>/dev/null; then
+	     $as_unset BASH_ENV || test "${BASH_ENV+set}" != set || { BASH_ENV=; export BASH_ENV; }
+	     $as_unset ENV || test "${ENV+set}" != set || { ENV=; export ENV; }
+	     CONFIG_SHELL=$as_dir/$as_base
+	     export CONFIG_SHELL
+	     exec "$CONFIG_SHELL" "$0" ${1+"$@"}
+	   fi;;
+	 esac
+       done
+done
+;;
+  esac
+
+  # Create $as_me.lineno as a copy of $as_myself, but with $LINENO
+  # uniformly replaced by the line number.  The first 'sed' inserts a
+  # line-number line before each line; the second 'sed' does the real
+  # work.  The second script uses 'N' to pair each line-number line
+  # with the numbered line, and appends trailing '-' during
+  # substitution so that $LINENO is not a special case at line end.
+  # (Raja R Harinath suggested sed '=', and Paul Eggert wrote the
+  # second 'sed' script.  Blame Lee E. McMahon for sed's syntax.  :-)
+  sed '=' <$as_myself |
+    sed '
+      N
+      s,$,-,
+      : loop
+      s,^\(['$as_cr_digits']*\)\(.*\)[$]LINENO\([^'$as_cr_alnum'_]\),\1\2\1\3,
+      t loop
+      s,-$,,
+      s,^['$as_cr_digits']*\n,,
+    ' >$as_me.lineno &&
+  chmod +x $as_me.lineno ||
+    { echo "$as_me: error: cannot create $as_me.lineno; rerun with a POSIX shell" >&2
+   { (exit 1); exit 1; }; }
+
+  # Don't try to exec as it changes $[0], causing all sort of problems
+  # (the dirname of $[0] is not the place where we might find the
+  # original and so on.  Autoconf is especially sensible to this).
+  . ./$as_me.lineno
+  # Exit status is that of the last command.
+  exit
+}
+
+
+case `echo "testing\c"; echo 1,2,3`,`echo -n testing; echo 1,2,3` in
+  *c*,-n*) ECHO_N= ECHO_C='
+' ECHO_T='	' ;;
+  *c*,*  ) ECHO_N=-n ECHO_C= ECHO_T= ;;
+  *)       ECHO_N= ECHO_C='\c' ECHO_T= ;;
+esac
+
+if expr a : '\(a\)' >/dev/null 2>&1; then
+  as_expr=expr
+else
+  as_expr=false
+fi
+
+rm -f conf$$ conf$$.exe conf$$.file
+echo >conf$$.file
+if ln -s conf$$.file conf$$ 2>/dev/null; then
+  # We could just check for DJGPP; but this test a) works b) is more generic
+  # and c) will remain valid once DJGPP supports symlinks (DJGPP 2.04).
+  if test -f conf$$.exe; then
+    # Don't use ln at all; we don't have any links
+    as_ln_s='cp -p'
+  else
+    as_ln_s='ln -s'
+  fi
+elif ln conf$$.file conf$$ 2>/dev/null; then
+  as_ln_s=ln
+else
+  as_ln_s='cp -p'
+fi
+rm -f conf$$ conf$$.exe conf$$.file
+
+if mkdir -p . 2>/dev/null; then
+  as_mkdir_p=:
+else
+  test -d ./-p && rmdir ./-p
+  as_mkdir_p=false
+fi
+
+as_executable_p="test -f"
+
+# Sed expression to map a string onto a valid CPP name.
+as_tr_cpp="eval sed 'y%*$as_cr_letters%P$as_cr_LETTERS%;s%[^_$as_cr_alnum]%_%g'"
+
+# Sed expression to map a string onto a valid variable name.
+as_tr_sh="eval sed 'y%*+%pp%;s%[^_$as_cr_alnum]%_%g'"
+
+
+# IFS
+# We need space, tab and new line, in precisely that order.
+as_nl='
+'
+IFS=" 	$as_nl"
+
+# CDPATH.
+$as_unset CDPATH
+
+
+# Name of the host.
+# hostname on some systems (SVR3.2, Linux) returns a bogus exit status,
+# so uname gets run too.
+ac_hostname=`(hostname || uname -n) 2>/dev/null | sed 1q`
+
+exec 6>&1
+
+#
+# Initializations.
+#
+ac_default_prefix=/usr/local
+ac_config_libobj_dir=.
+cross_compiling=no
+subdirs=
+MFLAGS=
+MAKEFLAGS=
+SHELL=${CONFIG_SHELL-/bin/sh}
+
+# Maximum number of lines to put in a shell here document.
+# This variable seems obsolete.  It should probably be removed, and
+# only ac_max_sed_lines should be used.
+: ${ac_max_here_lines=38}
+
+# Identity of this package.
+PACKAGE_NAME=
+PACKAGE_TARNAME=
+PACKAGE_VERSION=
+PACKAGE_STRING=
+PACKAGE_BUGREPORT=
+
+ac_unique_file="query-loc.c"
+# Factoring default headers for most tests.
+ac_includes_default="\
+#include <stdio.h>
+#if HAVE_SYS_TYPES_H
+# include <sys/types.h>
+#endif
+#if HAVE_SYS_STAT_H
+# include <sys/stat.h>
+#endif
+#if STDC_HEADERS
+# include <stdlib.h>
+# include <stddef.h>
+#else
+# if HAVE_STDLIB_H
+#  include <stdlib.h>
+# endif
+#endif
+#if HAVE_STRING_H
+# if !STDC_HEADERS && HAVE_MEMORY_H
+#  include <memory.h>
+# endif
+# include <string.h>
+#endif
+#if HAVE_STRINGS_H
+# include <strings.h>
+#endif
+#if HAVE_INTTYPES_H
+# include <inttypes.h>
+#else
+# if HAVE_STDINT_H
+#  include <stdint.h>
+# endif
+#endif
+#if HAVE_UNISTD_H
+# include <unistd.h>
+#endif"
+
+ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA CPP EGREP LOC_NTOA LIBOBJS LTLIBOBJS'
+ac_subst_files=''
+
+# Initialize some variables set by options.
+ac_init_help=
+ac_init_version=false
+# The variables have the same names as the options, with
+# dashes changed to underlines.
+cache_file=/dev/null
+exec_prefix=NONE
+no_create=
+no_recursion=
+prefix=NONE
+program_prefix=NONE
+program_suffix=NONE
+program_transform_name=s,x,x,
+silent=
+site=
+srcdir=
+verbose=
+x_includes=NONE
+x_libraries=NONE
+
+# Installation directory options.
+# These are left unexpanded so users can "make install exec_prefix=/foo"
+# and all the variables that are supposed to be based on exec_prefix
+# by default will actually change.
+# Use braces instead of parens because sh, perl, etc. also accept them.
+bindir='${exec_prefix}/bin'
+sbindir='${exec_prefix}/sbin'
+libexecdir='${exec_prefix}/libexec'
+datadir='${prefix}/share'
+sysconfdir='${prefix}/etc'
+sharedstatedir='${prefix}/com'
+localstatedir='${prefix}/var'
+libdir='${exec_prefix}/lib'
+includedir='${prefix}/include'
+oldincludedir='/usr/include'
+infodir='${prefix}/info'
+mandir='${prefix}/man'
+
+ac_prev=
+for ac_option
+do
+  # If the previous option needs an argument, assign it.
+  if test -n "$ac_prev"; then
+    eval "$ac_prev=\$ac_option"
+    ac_prev=
+    continue
+  fi
+
+  ac_optarg=`expr "x$ac_option" : 'x[^=]*=\(.*\)'`
+
+  # Accept the important Cygnus configure options, so we can diagnose typos.
+
+  case $ac_option in
+
+  -bindir | --bindir | --bindi | --bind | --bin | --bi)
+    ac_prev=bindir ;;
+  -bindir=* | --bindir=* | --bindi=* | --bind=* | --bin=* | --bi=*)
+    bindir=$ac_optarg ;;
+
+  -build | --build | --buil | --bui | --bu)
+    ac_prev=build_alias ;;
+  -build=* | --build=* | --buil=* | --bui=* | --bu=*)
+    build_alias=$ac_optarg ;;
+
+  -cache-file | --cache-file | --cache-fil | --cache-fi \
+  | --cache-f | --cache- | --cache | --cach | --cac | --ca | --c)
+    ac_prev=cache_file ;;
+  -cache-file=* | --cache-file=* | --cache-fil=* | --cache-fi=* \
+  | --cache-f=* | --cache-=* | --cache=* | --cach=* | --cac=* | --ca=* | --c=*)
+    cache_file=$ac_optarg ;;
+
+  --config-cache | -C)
+    cache_file=config.cache ;;
+
+  -datadir | --datadir | --datadi | --datad | --data | --dat | --da)
+    ac_prev=datadir ;;
+  -datadir=* | --datadir=* | --datadi=* | --datad=* | --data=* | --dat=* \
+  | --da=*)
+    datadir=$ac_optarg ;;
+
+  -disable-* | --disable-*)
+    ac_feature=`expr "x$ac_option" : 'x-*disable-\(.*\)'`
+    # Reject names that are not valid shell variable names.
+    expr "x$ac_feature" : ".*[^-_$as_cr_alnum]" >/dev/null &&
+      { echo "$as_me: error: invalid feature name: $ac_feature" >&2
+   { (exit 1); exit 1; }; }
+    ac_feature=`echo $ac_feature | sed 's/-/_/g'`
+    eval "enable_$ac_feature=no" ;;
+
+  -enable-* | --enable-*)
+    ac_feature=`expr "x$ac_option" : 'x-*enable-\([^=]*\)'`
+    # Reject names that are not valid shell variable names.
+    expr "x$ac_feature" : ".*[^-_$as_cr_alnum]" >/dev/null &&
+      { echo "$as_me: error: invalid feature name: $ac_feature" >&2
+   { (exit 1); exit 1; }; }
+    ac_feature=`echo $ac_feature | sed 's/-/_/g'`
+    case $ac_option in
+      *=*) ac_optarg=`echo "$ac_optarg" | sed "s/'/'\\\\\\\\''/g"`;;
+      *) ac_optarg=yes ;;
+    esac
+    eval "enable_$ac_feature='$ac_optarg'" ;;
+
+  -exec-prefix | --exec_prefix | --exec-prefix | --exec-prefi \
+  | --exec-pref | --exec-pre | --exec-pr | --exec-p | --exec- \
+  | --exec | --exe | --ex)
+    ac_prev=exec_prefix ;;
+  -exec-prefix=* | --exec_prefix=* | --exec-prefix=* | --exec-prefi=* \
+  | --exec-pref=* | --exec-pre=* | --exec-pr=* | --exec-p=* | --exec-=* \
+  | --exec=* | --exe=* | --ex=*)
+    exec_prefix=$ac_optarg ;;
+
+  -gas | --gas | --ga | --g)
+    # Obsolete; use --with-gas.
+    with_gas=yes ;;
+
+  -help | --help | --hel | --he | -h)
+    ac_init_help=long ;;
+  -help=r* | --help=r* | --hel=r* | --he=r* | -hr*)
+    ac_init_help=recursive ;;
+  -help=s* | --help=s* | --hel=s* | --he=s* | -hs*)
+    ac_init_help=short ;;
+
+  -host | --host | --hos | --ho)
+    ac_prev=host_alias ;;
+  -host=* | --host=* | --hos=* | --ho=*)
+    host_alias=$ac_optarg ;;
+
+  -includedir | --includedir | --includedi | --included | --include \
+  | --includ | --inclu | --incl | --inc)
+    ac_prev=includedir ;;
+  -includedir=* | --includedir=* | --includedi=* | --included=* | --include=* \
+  | --includ=* | --inclu=* | --incl=* | --inc=*)
+    includedir=$ac_optarg ;;
+
+  -infodir | --infodir | --infodi | --infod | --info | --inf)
+    ac_prev=infodir ;;
+  -infodir=* | --infodir=* | --infodi=* | --infod=* | --info=* | --inf=*)
+    infodir=$ac_optarg ;;
+
+  -libdir | --libdir | --libdi | --libd)
+    ac_prev=libdir ;;
+  -libdir=* | --libdir=* | --libdi=* | --libd=*)
+    libdir=$ac_optarg ;;
+
+  -libexecdir | --libexecdir | --libexecdi | --libexecd | --libexec \
+  | --libexe | --libex | --libe)
+    ac_prev=libexecdir ;;
+  -libexecdir=* | --libexecdir=* | --libexecdi=* | --libexecd=* | --libexec=* \
+  | --libexe=* | --libex=* | --libe=*)
+    libexecdir=$ac_optarg ;;
+
+  -localstatedir | --localstatedir | --localstatedi | --localstated \
+  | --localstate | --localstat | --localsta | --localst \
+  | --locals | --local | --loca | --loc | --lo)
+    ac_prev=localstatedir ;;
+  -localstatedir=* | --localstatedir=* | --localstatedi=* | --localstated=* \
+  | --localstate=* | --localstat=* | --localsta=* | --localst=* \
+  | --locals=* | --local=* | --loca=* | --loc=* | --lo=*)
+    localstatedir=$ac_optarg ;;
+
+  -mandir | --mandir | --mandi | --mand | --man | --ma | --m)
+    ac_prev=mandir ;;
+  -mandir=* | --mandir=* | --mandi=* | --mand=* | --man=* | --ma=* | --m=*)
+    mandir=$ac_optarg ;;
+
+  -nfp | --nfp | --nf)
+    # Obsolete; use --without-fp.
+    with_fp=no ;;
+
+  -no-create | --no-create | --no-creat | --no-crea | --no-cre \
+  | --no-cr | --no-c | -n)
+    no_create=yes ;;
+
+  -no-recursion | --no-recursion | --no-recursio | --no-recursi \
+  | --no-recurs | --no-recur | --no-recu | --no-rec | --no-re | --no-r)
+    no_recursion=yes ;;
+
+  -oldincludedir | --oldincludedir | --oldincludedi | --oldincluded \
+  | --oldinclude | --oldinclud | --oldinclu | --oldincl | --oldinc \
+  | --oldin | --oldi | --old | --ol | --o)
+    ac_prev=oldincludedir ;;
+  -oldincludedir=* | --oldincludedir=* | --oldincludedi=* | --oldincluded=* \
+  | --oldinclude=* | --oldinclud=* | --oldinclu=* | --oldincl=* | --oldinc=* \
+  | --oldin=* | --oldi=* | --old=* | --ol=* | --o=*)
+    oldincludedir=$ac_optarg ;;
+
+  -prefix | --prefix | --prefi | --pref | --pre | --pr | --p)
+    ac_prev=prefix ;;
+  -prefix=* | --prefix=* | --prefi=* | --pref=* | --pre=* | --pr=* | --p=*)
+    prefix=$ac_optarg ;;
+
+  -program-prefix | --program-prefix | --program-prefi | --program-pref \
+  | --program-pre | --program-pr | --program-p)
+    ac_prev=program_prefix ;;
+  -program-prefix=* | --program-prefix=* | --program-prefi=* \
+  | --program-pref=* | --program-pre=* | --program-pr=* | --program-p=*)
+    program_prefix=$ac_optarg ;;
+
+  -program-suffix | --program-suffix | --program-suffi | --program-suff \
+  | --program-suf | --program-su | --program-s)
+    ac_prev=program_suffix ;;
+  -program-suffix=* | --program-suffix=* | --program-suffi=* \
+  | --program-suff=* | --program-suf=* | --program-su=* | --program-s=*)
+    program_suffix=$ac_optarg ;;
+
+  -program-transform-name | --program-transform-name \
+  | --program-transform-nam | --program-transform-na \
+  | --program-transform-n | --program-transform- \
+  | --program-transform | --program-transfor \
+  | --program-transfo | --program-transf \
+  | --program-trans | --program-tran \
+  | --progr-tra | --program-tr | --program-t)
+    ac_prev=program_transform_name ;;
+  -program-transform-name=* | --program-transform-name=* \
+  | --program-transform-nam=* | --program-transform-na=* \
+  | --program-transform-n=* | --program-transform-=* \
+  | --program-transform=* | --program-transfor=* \
+  | --program-transfo=* | --program-transf=* \
+  | --program-trans=* | --program-tran=* \
+  | --progr-tra=* | --program-tr=* | --program-t=*)
+    program_transform_name=$ac_optarg ;;
+
+  -q | -quiet | --quiet | --quie | --qui | --qu | --q \
+  | -silent | --silent | --silen | --sile | --sil)
+    silent=yes ;;
+
+  -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
+    ac_prev=sbindir ;;
+  -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
+  | --sbi=* | --sb=*)
+    sbindir=$ac_optarg ;;
+
+  -sharedstatedir | --sharedstatedir | --sharedstatedi \
+  | --sharedstated | --sharedstate | --sharedstat | --sharedsta \
+  | --sharedst | --shareds | --shared | --share | --shar \
+  | --sha | --sh)
+    ac_prev=sharedstatedir ;;
+  -sharedstatedir=* | --sharedstatedir=* | --sharedstatedi=* \
+  | --sharedstated=* | --sharedstate=* | --sharedstat=* | --sharedsta=* \
+  | --sharedst=* | --shareds=* | --shared=* | --share=* | --shar=* \
+  | --sha=* | --sh=*)
+    sharedstatedir=$ac_optarg ;;
+
+  -site | --site | --sit)
+    ac_prev=site ;;
+  -site=* | --site=* | --sit=*)
+    site=$ac_optarg ;;
+
+  -srcdir | --srcdir | --srcdi | --srcd | --src | --sr)
+    ac_prev=srcdir ;;
+  -srcdir=* | --srcdir=* | --srcdi=* | --srcd=* | --src=* | --sr=*)
+    srcdir=$ac_optarg ;;
+
+  -sysconfdir | --sysconfdir | --sysconfdi | --sysconfd | --sysconf \
+  | --syscon | --sysco | --sysc | --sys | --sy)
+    ac_prev=sysconfdir ;;
+  -sysconfdir=* | --sysconfdir=* | --sysconfdi=* | --sysconfd=* | --sysconf=* \
+  | --syscon=* | --sysco=* | --sysc=* | --sys=* | --sy=*)
+    sysconfdir=$ac_optarg ;;
+
+  -target | --target | --targe | --targ | --tar | --ta | --t)
+    ac_prev=target_alias ;;
+  -target=* | --target=* | --targe=* | --targ=* | --tar=* | --ta=* | --t=*)
+    target_alias=$ac_optarg ;;
+
+  -v | -verbose | --verbose | --verbos | --verbo | --verb)
+    verbose=yes ;;
+
+  -version | --version | --versio | --versi | --vers | -V)
+    ac_init_version=: ;;
+
+  -with-* | --with-*)
+    ac_package=`expr "x$ac_option" : 'x-*with-\([^=]*\)'`
+    # Reject names that are not valid shell variable names.
+    expr "x$ac_package" : ".*[^-_$as_cr_alnum]" >/dev/null &&
+      { echo "$as_me: error: invalid package name: $ac_package" >&2
+   { (exit 1); exit 1; }; }
+    ac_package=`echo $ac_package| sed 's/-/_/g'`
+    case $ac_option in
+      *=*) ac_optarg=`echo "$ac_optarg" | sed "s/'/'\\\\\\\\''/g"`;;
+      *) ac_optarg=yes ;;
+    esac
+    eval "with_$ac_package='$ac_optarg'" ;;
+
+  -without-* | --without-*)
+    ac_package=`expr "x$ac_option" : 'x-*without-\(.*\)'`
+    # Reject names that are not valid shell variable names.
+    expr "x$ac_package" : ".*[^-_$as_cr_alnum]" >/dev/null &&
+      { echo "$as_me: error: invalid package name: $ac_package" >&2
+   { (exit 1); exit 1; }; }
+    ac_package=`echo $ac_package | sed 's/-/_/g'`
+    eval "with_$ac_package=no" ;;
+
+  --x)
+    # Obsolete; use --with-x.
+    with_x=yes ;;
+
+  -x-includes | --x-includes | --x-include | --x-includ | --x-inclu \
+  | --x-incl | --x-inc | --x-in | --x-i)
+    ac_prev=x_includes ;;
+  -x-includes=* | --x-includes=* | --x-include=* | --x-includ=* | --x-inclu=* \
+  | --x-incl=* | --x-inc=* | --x-in=* | --x-i=*)
+    x_includes=$ac_optarg ;;
+
+  -x-libraries | --x-libraries | --x-librarie | --x-librari \
+  | --x-librar | --x-libra | --x-libr | --x-lib | --x-li | --x-l)
+    ac_prev=x_libraries ;;
+  -x-libraries=* | --x-libraries=* | --x-librarie=* | --x-librari=* \
+  | --x-librar=* | --x-libra=* | --x-libr=* | --x-lib=* | --x-li=* | --x-l=*)
+    x_libraries=$ac_optarg ;;
+
+  -*) { echo "$as_me: error: unrecognized option: $ac_option
+Try \`$0 --help' for more information." >&2
+   { (exit 1); exit 1; }; }
+    ;;
+
+  *=*)
+    ac_envvar=`expr "x$ac_option" : 'x\([^=]*\)='`
+    # Reject names that are not valid shell variable names.
+    expr "x$ac_envvar" : ".*[^_$as_cr_alnum]" >/dev/null &&
+      { echo "$as_me: error: invalid variable name: $ac_envvar" >&2
+   { (exit 1); exit 1; }; }
+    ac_optarg=`echo "$ac_optarg" | sed "s/'/'\\\\\\\\''/g"`
+    eval "$ac_envvar='$ac_optarg'"
+    export $ac_envvar ;;
+
+  *)
+    # FIXME: should be removed in autoconf 3.0.
+    echo "$as_me: WARNING: you should use --build, --host, --target" >&2
+    expr "x$ac_option" : ".*[^-._$as_cr_alnum]" >/dev/null &&
+      echo "$as_me: WARNING: invalid host type: $ac_option" >&2
+    : ${build_alias=$ac_option} ${host_alias=$ac_option} ${target_alias=$ac_option}
+    ;;
+
+  esac
+done
+
+if test -n "$ac_prev"; then
+  ac_option=--`echo $ac_prev | sed 's/_/-/g'`
+  { echo "$as_me: error: missing argument to $ac_option" >&2
+   { (exit 1); exit 1; }; }
+fi
+
+# Be sure to have absolute paths.
+for ac_var in exec_prefix prefix
+do
+  eval ac_val=$`echo $ac_var`
+  case $ac_val in
+    [\\/$]* | ?:[\\/]* | NONE | '' ) ;;
+    *)  { echo "$as_me: error: expected an absolute directory name for --$ac_var: $ac_val" >&2
+   { (exit 1); exit 1; }; };;
+  esac
+done
+
+# Be sure to have absolute paths.
+for ac_var in bindir sbindir libexecdir datadir sysconfdir sharedstatedir \
+	      localstatedir libdir includedir oldincludedir infodir mandir
+do
+  eval ac_val=$`echo $ac_var`
+  case $ac_val in
+    [\\/$]* | ?:[\\/]* ) ;;
+    *)  { echo "$as_me: error: expected an absolute directory name for --$ac_var: $ac_val" >&2
+   { (exit 1); exit 1; }; };;
+  esac
+done
+
+# There might be people who depend on the old broken behavior: `$host'
+# used to hold the argument of --host etc.
+# FIXME: To remove some day.
+build=$build_alias
+host=$host_alias
+target=$target_alias
+
+# FIXME: To remove some day.
+if test "x$host_alias" != x; then
+  if test "x$build_alias" = x; then
+    cross_compiling=maybe
+    echo "$as_me: WARNING: If you wanted to set the --build type, don't use --host.
+    If a cross compiler is detected then cross compile mode will be used." >&2
+  elif test "x$build_alias" != "x$host_alias"; then
+    cross_compiling=yes
+  fi
+fi
+
+ac_tool_prefix=
+test -n "$host_alias" && ac_tool_prefix=$host_alias-
+
+test "$silent" = yes && exec 6>/dev/null
+
+
+# Find the source files, if location was not specified.
+if test -z "$srcdir"; then
+  ac_srcdir_defaulted=yes
+  # Try the directory containing this script, then its parent.
+  ac_confdir=`(dirname "$0") 2>/dev/null ||
+$as_expr X"$0" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
+	 X"$0" : 'X\(//\)[^/]' \| \
+	 X"$0" : 'X\(//\)$' \| \
+	 X"$0" : 'X\(/\)' \| \
+	 .     : '\(.\)' 2>/dev/null ||
+echo X"$0" |
+    sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{ s//\1/; q; }
+  	  /^X\(\/\/\)[^/].*/{ s//\1/; q; }
+  	  /^X\(\/\/\)$/{ s//\1/; q; }
+  	  /^X\(\/\).*/{ s//\1/; q; }
+  	  s/.*/./; q'`
+  srcdir=$ac_confdir
+  if test ! -r $srcdir/$ac_unique_file; then
+    srcdir=..
+  fi
+else
+  ac_srcdir_defaulted=no
+fi
+if test ! -r $srcdir/$ac_unique_file; then
+  if test "$ac_srcdir_defaulted" = yes; then
+    { echo "$as_me: error: cannot find sources ($ac_unique_file) in $ac_confdir or .." >&2
+   { (exit 1); exit 1; }; }
+  else
+    { echo "$as_me: error: cannot find sources ($ac_unique_file) in $srcdir" >&2
+   { (exit 1); exit 1; }; }
+  fi
+fi
+(cd $srcdir && test -r ./$ac_unique_file) 2>/dev/null ||
+  { echo "$as_me: error: sources are in $srcdir, but \`cd $srcdir' does not work" >&2
+   { (exit 1); exit 1; }; }
+srcdir=`echo "$srcdir" | sed 's%\([^\\/]\)[\\/]*$%\1%'`
+ac_env_build_alias_set=${build_alias+set}
+ac_env_build_alias_value=$build_alias
+ac_cv_env_build_alias_set=${build_alias+set}
+ac_cv_env_build_alias_value=$build_alias
+ac_env_host_alias_set=${host_alias+set}
+ac_env_host_alias_value=$host_alias
+ac_cv_env_host_alias_set=${host_alias+set}
+ac_cv_env_host_alias_value=$host_alias
+ac_env_target_alias_set=${target_alias+set}
+ac_env_target_alias_value=$target_alias
+ac_cv_env_target_alias_set=${target_alias+set}
+ac_cv_env_target_alias_value=$target_alias
+ac_env_CC_set=${CC+set}
+ac_env_CC_value=$CC
+ac_cv_env_CC_set=${CC+set}
+ac_cv_env_CC_value=$CC
+ac_env_CFLAGS_set=${CFLAGS+set}
+ac_env_CFLAGS_value=$CFLAGS
+ac_cv_env_CFLAGS_set=${CFLAGS+set}
+ac_cv_env_CFLAGS_value=$CFLAGS
+ac_env_LDFLAGS_set=${LDFLAGS+set}
+ac_env_LDFLAGS_value=$LDFLAGS
+ac_cv_env_LDFLAGS_set=${LDFLAGS+set}
+ac_cv_env_LDFLAGS_value=$LDFLAGS
+ac_env_CPPFLAGS_set=${CPPFLAGS+set}
+ac_env_CPPFLAGS_value=$CPPFLAGS
+ac_cv_env_CPPFLAGS_set=${CPPFLAGS+set}
+ac_cv_env_CPPFLAGS_value=$CPPFLAGS
+ac_env_CPP_set=${CPP+set}
+ac_env_CPP_value=$CPP
+ac_cv_env_CPP_set=${CPP+set}
+ac_cv_env_CPP_value=$CPP
+
+#
+# Report the --help message.
+#
+if test "$ac_init_help" = "long"; then
+  # Omit some internal or obsolete options to make the list less imposing.
+  # This message is too long to be a string in the A/UX 3.1 sh.
+  cat <<_ACEOF
+\`configure' configures this package to adapt to many kinds of systems.
+
+Usage: $0 [OPTION]... [VAR=VALUE]...
+
+To assign environment variables (e.g., CC, CFLAGS...), specify them as
+VAR=VALUE.  See below for descriptions of some of the useful variables.
+
+Defaults for the options are specified in brackets.
+
+Configuration:
+  -h, --help              display this help and exit
+      --help=short        display options specific to this package
+      --help=recursive    display the short help of all the included packages
+  -V, --version           display version information and exit
+  -q, --quiet, --silent   do not print \`checking...' messages
+      --cache-file=FILE   cache test results in FILE [disabled]
+  -C, --config-cache      alias for \`--cache-file=config.cache'
+  -n, --no-create         do not create output files
+      --srcdir=DIR        find the sources in DIR [configure dir or \`..']
+
+_ACEOF
+
+  cat <<_ACEOF
+Installation directories:
+  --prefix=PREFIX         install architecture-independent files in PREFIX
+			  [$ac_default_prefix]
+  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
+			  [PREFIX]
+
+By default, \`make install' will install all the files in
+\`$ac_default_prefix/bin', \`$ac_default_prefix/lib' etc.  You can specify
+an installation prefix other than \`$ac_default_prefix' using \`--prefix',
+for instance \`--prefix=\$HOME'.
+
+For better control, use the options below.
+
+Fine tuning of the installation directories:
+  --bindir=DIR           user executables [EPREFIX/bin]
+  --sbindir=DIR          system admin executables [EPREFIX/sbin]
+  --libexecdir=DIR       program executables [EPREFIX/libexec]
+  --datadir=DIR          read-only architecture-independent data [PREFIX/share]
+  --sysconfdir=DIR       read-only single-machine data [PREFIX/etc]
+  --sharedstatedir=DIR   modifiable architecture-independent data [PREFIX/com]
+  --localstatedir=DIR    modifiable single-machine data [PREFIX/var]
+  --libdir=DIR           object code libraries [EPREFIX/lib]
+  --includedir=DIR       C header files [PREFIX/include]
+  --oldincludedir=DIR    C header files for non-gcc [/usr/include]
+  --infodir=DIR          info documentation [PREFIX/info]
+  --mandir=DIR           man documentation [PREFIX/man]
+_ACEOF
+
+  cat <<\_ACEOF
+_ACEOF
+fi
+
+if test -n "$ac_init_help"; then
+
+  cat <<\_ACEOF
+
+Some influential environment variables:
+  CC          C compiler command
+  CFLAGS      C compiler flags
+  LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
+              nonstandard directory <lib dir>
+  CPPFLAGS    C/C++ preprocessor flags, e.g. -I<include dir> if you have
+              headers in a nonstandard directory <include dir>
+  CPP         C preprocessor
+
+Use these variables to override the choices made by `configure' or to help
+it to find libraries and programs with nonstandard names/locations.
+
+_ACEOF
+fi
+
+if test "$ac_init_help" = "recursive"; then
+  # If there are subdirs, report their specific --help.
+  ac_popdir=`pwd`
+  for ac_dir in : $ac_subdirs_all; do test "x$ac_dir" = x: && continue
+    test -d $ac_dir || continue
+    ac_builddir=.
+
+if test "$ac_dir" != .; then
+  ac_dir_suffix=/`echo "$ac_dir" | sed 's,^\.[\\/],,'`
+  # A "../" for each directory in $ac_dir_suffix.
+  ac_top_builddir=`echo "$ac_dir_suffix" | sed 's,/[^\\/]*,../,g'`
+else
+  ac_dir_suffix= ac_top_builddir=
+fi
+
+case $srcdir in
+  .)  # No --srcdir option.  We are building in place.
+    ac_srcdir=.
+    if test -z "$ac_top_builddir"; then
+       ac_top_srcdir=.
+    else
+       ac_top_srcdir=`echo $ac_top_builddir | sed 's,/$,,'`
+    fi ;;
+  [\\/]* | ?:[\\/]* )  # Absolute path.
+    ac_srcdir=$srcdir$ac_dir_suffix;
+    ac_top_srcdir=$srcdir ;;
+  *) # Relative path.
+    ac_srcdir=$ac_top_builddir$srcdir$ac_dir_suffix
+    ac_top_srcdir=$ac_top_builddir$srcdir ;;
+esac
+
+# Do not use `cd foo && pwd` to compute absolute paths, because
+# the directories may not exist.
+case `pwd` in
+.) ac_abs_builddir="$ac_dir";;
+*)
+  case "$ac_dir" in
+  .) ac_abs_builddir=`pwd`;;
+  [\\/]* | ?:[\\/]* ) ac_abs_builddir="$ac_dir";;
+  *) ac_abs_builddir=`pwd`/"$ac_dir";;
+  esac;;
+esac
+case $ac_abs_builddir in
+.) ac_abs_top_builddir=${ac_top_builddir}.;;
+*)
+  case ${ac_top_builddir}. in
+  .) ac_abs_top_builddir=$ac_abs_builddir;;
+  [\\/]* | ?:[\\/]* ) ac_abs_top_builddir=${ac_top_builddir}.;;
+  *) ac_abs_top_builddir=$ac_abs_builddir/${ac_top_builddir}.;;
+  esac;;
+esac
+case $ac_abs_builddir in
+.) ac_abs_srcdir=$ac_srcdir;;
+*)
+  case $ac_srcdir in
+  .) ac_abs_srcdir=$ac_abs_builddir;;
+  [\\/]* | ?:[\\/]* ) ac_abs_srcdir=$ac_srcdir;;
+  *) ac_abs_srcdir=$ac_abs_builddir/$ac_srcdir;;
+  esac;;
+esac
+case $ac_abs_builddir in
+.) ac_abs_top_srcdir=$ac_top_srcdir;;
+*)
+  case $ac_top_srcdir in
+  .) ac_abs_top_srcdir=$ac_abs_builddir;;
+  [\\/]* | ?:[\\/]* ) ac_abs_top_srcdir=$ac_top_srcdir;;
+  *) ac_abs_top_srcdir=$ac_abs_builddir/$ac_top_srcdir;;
+  esac;;
+esac
+
+    cd $ac_dir
+    # Check for guested configure; otherwise get Cygnus style configure.
+    if test -f $ac_srcdir/configure.gnu; then
+      echo
+      $SHELL $ac_srcdir/configure.gnu  --help=recursive
+    elif test -f $ac_srcdir/configure; then
+      echo
+      $SHELL $ac_srcdir/configure  --help=recursive
+    elif test -f $ac_srcdir/configure.ac ||
+	   test -f $ac_srcdir/configure.in; then
+      echo
+      $ac_configure --help
+    else
+      echo "$as_me: WARNING: no configuration information is in $ac_dir" >&2
+    fi
+    cd "$ac_popdir"
+  done
+fi
+
+test -n "$ac_init_help" && exit 0
+if $ac_init_version; then
+  cat <<\_ACEOF
+
+Copyright (C) 2003 Free Software Foundation, Inc.
+This configure script is free software; the Free Software Foundation
+gives unlimited permission to copy, distribute and modify it.
+_ACEOF
+  exit 0
+fi
+exec 5>config.log
+cat >&5 <<_ACEOF
+This file contains any messages produced by compilers while
+running configure, to aid debugging if configure makes a mistake.
+
+It was created by $as_me, which was
+generated by GNU Autoconf 2.59.  Invocation command line was
+
+  $ $0 $@
+
+_ACEOF
+{
+cat <<_ASUNAME
+## --------- ##
+## Platform. ##
+## --------- ##
+
+hostname = `(hostname || uname -n) 2>/dev/null | sed 1q`
+uname -m = `(uname -m) 2>/dev/null || echo unknown`
+uname -r = `(uname -r) 2>/dev/null || echo unknown`
+uname -s = `(uname -s) 2>/dev/null || echo unknown`
+uname -v = `(uname -v) 2>/dev/null || echo unknown`
+
+/usr/bin/uname -p = `(/usr/bin/uname -p) 2>/dev/null || echo unknown`
+/bin/uname -X     = `(/bin/uname -X) 2>/dev/null     || echo unknown`
+
+/bin/arch              = `(/bin/arch) 2>/dev/null              || echo unknown`
+/usr/bin/arch -k       = `(/usr/bin/arch -k) 2>/dev/null       || echo unknown`
+/usr/convex/getsysinfo = `(/usr/convex/getsysinfo) 2>/dev/null || echo unknown`
+hostinfo               = `(hostinfo) 2>/dev/null               || echo unknown`
+/bin/machine           = `(/bin/machine) 2>/dev/null           || echo unknown`
+/usr/bin/oslevel       = `(/usr/bin/oslevel) 2>/dev/null       || echo unknown`
+/bin/universe          = `(/bin/universe) 2>/dev/null          || echo unknown`
+
+_ASUNAME
+
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  echo "PATH: $as_dir"
+done
+
+} >&5
+
+cat >&5 <<_ACEOF
+
+
+## ----------- ##
+## Core tests. ##
+## ----------- ##
+
+_ACEOF
+
+
+# Keep a trace of the command line.
+# Strip out --no-create and --no-recursion so they do not pile up.
+# Strip out --silent because we don't want to record it for future runs.
+# Also quote any args containing shell meta-characters.
+# Make two passes to allow for proper duplicate-argument suppression.
+ac_configure_args=
+ac_configure_args0=
+ac_configure_args1=
+ac_sep=
+ac_must_keep_next=false
+for ac_pass in 1 2
+do
+  for ac_arg
+  do
+    case $ac_arg in
+    -no-create | --no-c* | -n | -no-recursion | --no-r*) continue ;;
+    -q | -quiet | --quiet | --quie | --qui | --qu | --q \
+    | -silent | --silent | --silen | --sile | --sil)
+      continue ;;
+    *" "*|*"	"*|*[\[\]\~\#\$\^\&\*\(\)\{\}\\\|\;\<\>\?\"\']*)
+      ac_arg=`echo "$ac_arg" | sed "s/'/'\\\\\\\\''/g"` ;;
+    esac
+    case $ac_pass in
+    1) ac_configure_args0="$ac_configure_args0 '$ac_arg'" ;;
+    2)
+      ac_configure_args1="$ac_configure_args1 '$ac_arg'"
+      if test $ac_must_keep_next = true; then
+	ac_must_keep_next=false # Got value, back to normal.
+      else
+	case $ac_arg in
+	  *=* | --config-cache | -C | -disable-* | --disable-* \
+	  | -enable-* | --enable-* | -gas | --g* | -nfp | --nf* \
+	  | -q | -quiet | --q* | -silent | --sil* | -v | -verb* \
+	  | -with-* | --with-* | -without-* | --without-* | --x)
+	    case "$ac_configure_args0 " in
+	      "$ac_configure_args1"*" '$ac_arg' "* ) continue ;;
+	    esac
+	    ;;
+	  -* ) ac_must_keep_next=true ;;
+	esac
+      fi
+      ac_configure_args="$ac_configure_args$ac_sep'$ac_arg'"
+      # Get rid of the leading space.
+      ac_sep=" "
+      ;;
+    esac
+  done
+done
+$as_unset ac_configure_args0 || test "${ac_configure_args0+set}" != set || { ac_configure_args0=; export ac_configure_args0; }
+$as_unset ac_configure_args1 || test "${ac_configure_args1+set}" != set || { ac_configure_args1=; export ac_configure_args1; }
+
+# When interrupted or exit'd, cleanup temporary files, and complete
+# config.log.  We remove comments because anyway the quotes in there
+# would cause problems or look ugly.
+# WARNING: Be sure not to use single quotes in there, as some shells,
+# such as our DU 5.0 friend, will then `close' the trap.
+trap 'exit_status=$?
+  # Save into config.log some information that might help in debugging.
+  {
+    echo
+
+    cat <<\_ASBOX
+## ---------------- ##
+## Cache variables. ##
+## ---------------- ##
+_ASBOX
+    echo
+    # The following way of writing the cache mishandles newlines in values,
+{
+  (set) 2>&1 |
+    case `(ac_space='"'"' '"'"'; set | grep ac_space) 2>&1` in
+    *ac_space=\ *)
+      sed -n \
+	"s/'"'"'/'"'"'\\\\'"'"''"'"'/g;
+	  s/^\\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\\)=\\(.*\\)/\\1='"'"'\\2'"'"'/p"
+      ;;
+    *)
+      sed -n \
+	"s/^\\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\\)=\\(.*\\)/\\1=\\2/p"
+      ;;
+    esac;
+}
+    echo
+
+    cat <<\_ASBOX
+## ----------------- ##
+## Output variables. ##
+## ----------------- ##
+_ASBOX
+    echo
+    for ac_var in $ac_subst_vars
+    do
+      eval ac_val=$`echo $ac_var`
+      echo "$ac_var='"'"'$ac_val'"'"'"
+    done | sort
+    echo
+
+    if test -n "$ac_subst_files"; then
+      cat <<\_ASBOX
+## ------------- ##
+## Output files. ##
+## ------------- ##
+_ASBOX
+      echo
+      for ac_var in $ac_subst_files
+      do
+	eval ac_val=$`echo $ac_var`
+	echo "$ac_var='"'"'$ac_val'"'"'"
+      done | sort
+      echo
+    fi
+
+    if test -s confdefs.h; then
+      cat <<\_ASBOX
+## ----------- ##
+## confdefs.h. ##
+## ----------- ##
+_ASBOX
+      echo
+      sed "/^$/d" confdefs.h | sort
+      echo
+    fi
+    test "$ac_signal" != 0 &&
+      echo "$as_me: caught signal $ac_signal"
+    echo "$as_me: exit $exit_status"
+  } >&5
+  rm -f core *.core &&
+  rm -rf conftest* confdefs* conf$$* $ac_clean_files &&
+    exit $exit_status
+     ' 0
+for ac_signal in 1 2 13 15; do
+  trap 'ac_signal='$ac_signal'; { (exit 1); exit 1; }' $ac_signal
+done
+ac_signal=0
+
+# confdefs.h avoids OS command line length limits that DEFS can exceed.
+rm -rf conftest* confdefs.h
+# AIX cpp loses on an empty file, so make sure it contains at least a newline.
+echo >confdefs.h
+
+# Predefined preprocessor variables.
+
+cat >>confdefs.h <<_ACEOF
+#define PACKAGE_NAME "$PACKAGE_NAME"
+_ACEOF
+
+
+cat >>confdefs.h <<_ACEOF
+#define PACKAGE_TARNAME "$PACKAGE_TARNAME"
+_ACEOF
+
+
+cat >>confdefs.h <<_ACEOF
+#define PACKAGE_VERSION "$PACKAGE_VERSION"
+_ACEOF
+
+
+cat >>confdefs.h <<_ACEOF
+#define PACKAGE_STRING "$PACKAGE_STRING"
+_ACEOF
+
+
+cat >>confdefs.h <<_ACEOF
+#define PACKAGE_BUGREPORT "$PACKAGE_BUGREPORT"
+_ACEOF
+
+
+# Let the site file select an alternate cache file if it wants to.
+# Prefer explicitly selected file to automatically selected ones.
+if test -z "$CONFIG_SITE"; then
+  if test "x$prefix" != xNONE; then
+    CONFIG_SITE="$prefix/share/config.site $prefix/etc/config.site"
+  else
+    CONFIG_SITE="$ac_default_prefix/share/config.site $ac_default_prefix/etc/config.site"
+  fi
+fi
+for ac_site_file in $CONFIG_SITE; do
+  if test -r "$ac_site_file"; then
+    { echo "$as_me:$LINENO: loading site script $ac_site_file" >&5
+echo "$as_me: loading site script $ac_site_file" >&6;}
+    sed 's/^/| /' "$ac_site_file" >&5
+    . "$ac_site_file"
+  fi
+done
+
+if test -r "$cache_file"; then
+  # Some versions of bash will fail to source /dev/null (special
+  # files actually), so we avoid doing that.
+  if test -f "$cache_file"; then
+    { echo "$as_me:$LINENO: loading cache $cache_file" >&5
+echo "$as_me: loading cache $cache_file" >&6;}
+    case $cache_file in
+      [\\/]* | ?:[\\/]* ) . $cache_file;;
+      *)                      . ./$cache_file;;
+    esac
+  fi
+else
+  { echo "$as_me:$LINENO: creating cache $cache_file" >&5
+echo "$as_me: creating cache $cache_file" >&6;}
+  >$cache_file
+fi
+
+# Check that the precious variables saved in the cache have kept the same
+# value.
+ac_cache_corrupted=false
+for ac_var in `(set) 2>&1 |
+	       sed -n 's/^ac_env_\([a-zA-Z_0-9]*\)_set=.*/\1/p'`; do
+  eval ac_old_set=\$ac_cv_env_${ac_var}_set
+  eval ac_new_set=\$ac_env_${ac_var}_set
+  eval ac_old_val="\$ac_cv_env_${ac_var}_value"
+  eval ac_new_val="\$ac_env_${ac_var}_value"
+  case $ac_old_set,$ac_new_set in
+    set,)
+      { echo "$as_me:$LINENO: error: \`$ac_var' was set to \`$ac_old_val' in the previous run" >&5
+echo "$as_me: error: \`$ac_var' was set to \`$ac_old_val' in the previous run" >&2;}
+      ac_cache_corrupted=: ;;
+    ,set)
+      { echo "$as_me:$LINENO: error: \`$ac_var' was not set in the previous run" >&5
+echo "$as_me: error: \`$ac_var' was not set in the previous run" >&2;}
+      ac_cache_corrupted=: ;;
+    ,);;
+    *)
+      if test "x$ac_old_val" != "x$ac_new_val"; then
+	{ echo "$as_me:$LINENO: error: \`$ac_var' has changed since the previous run:" >&5
+echo "$as_me: error: \`$ac_var' has changed since the previous run:" >&2;}
+	{ echo "$as_me:$LINENO:   former value:  $ac_old_val" >&5
+echo "$as_me:   former value:  $ac_old_val" >&2;}
+	{ echo "$as_me:$LINENO:   current value: $ac_new_val" >&5
+echo "$as_me:   current value: $ac_new_val" >&2;}
+	ac_cache_corrupted=:
+      fi;;
+  esac
+  # Pass precious variables to config.status.
+  if test "$ac_new_set" = set; then
+    case $ac_new_val in
+    *" "*|*"	"*|*[\[\]\~\#\$\^\&\*\(\)\{\}\\\|\;\<\>\?\"\']*)
+      ac_arg=$ac_var=`echo "$ac_new_val" | sed "s/'/'\\\\\\\\''/g"` ;;
+    *) ac_arg=$ac_var=$ac_new_val ;;
+    esac
+    case " $ac_configure_args " in
+      *" '$ac_arg' "*) ;; # Avoid dups.  Use of quotes ensures accuracy.
+      *) ac_configure_args="$ac_configure_args '$ac_arg'" ;;
+    esac
+  fi
+done
+if $ac_cache_corrupted; then
+  { echo "$as_me:$LINENO: error: changes in the environment can compromise the build" >&5
+echo "$as_me: error: changes in the environment can compromise the build" >&2;}
+  { { echo "$as_me:$LINENO: error: run \`make distclean' and/or \`rm $cache_file' and start over" >&5
+echo "$as_me: error: run \`make distclean' and/or \`rm $cache_file' and start over" >&2;}
+   { (exit 1); exit 1; }; }
+fi
+
+ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+if test -n "$ac_tool_prefix"; then
+  # Extract the first word of "${ac_tool_prefix}gcc", so it can be a program name with args.
+set dummy ${ac_tool_prefix}gcc; ac_word=$2
+echo "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_prog_CC+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -n "$CC"; then
+  ac_cv_prog_CC="$CC" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_CC="${ac_tool_prefix}gcc"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+fi
+fi
+CC=$ac_cv_prog_CC
+if test -n "$CC"; then
+  echo "$as_me:$LINENO: result: $CC" >&5
+echo "${ECHO_T}$CC" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+fi
+if test -z "$ac_cv_prog_CC"; then
+  ac_ct_CC=$CC
+  # Extract the first word of "gcc", so it can be a program name with args.
+set dummy gcc; ac_word=$2
+echo "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_prog_ac_ct_CC+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -n "$ac_ct_CC"; then
+  ac_cv_prog_ac_ct_CC="$ac_ct_CC" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_ac_ct_CC="gcc"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+fi
+fi
+ac_ct_CC=$ac_cv_prog_ac_ct_CC
+if test -n "$ac_ct_CC"; then
+  echo "$as_me:$LINENO: result: $ac_ct_CC" >&5
+echo "${ECHO_T}$ac_ct_CC" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+  CC=$ac_ct_CC
+else
+  CC="$ac_cv_prog_CC"
+fi
+
+if test -z "$CC"; then
+  if test -n "$ac_tool_prefix"; then
+  # Extract the first word of "${ac_tool_prefix}cc", so it can be a program name with args.
+set dummy ${ac_tool_prefix}cc; ac_word=$2
+echo "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_prog_CC+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -n "$CC"; then
+  ac_cv_prog_CC="$CC" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_CC="${ac_tool_prefix}cc"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+fi
+fi
+CC=$ac_cv_prog_CC
+if test -n "$CC"; then
+  echo "$as_me:$LINENO: result: $CC" >&5
+echo "${ECHO_T}$CC" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+fi
+if test -z "$ac_cv_prog_CC"; then
+  ac_ct_CC=$CC
+  # Extract the first word of "cc", so it can be a program name with args.
+set dummy cc; ac_word=$2
+echo "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_prog_ac_ct_CC+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -n "$ac_ct_CC"; then
+  ac_cv_prog_ac_ct_CC="$ac_ct_CC" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_ac_ct_CC="cc"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+fi
+fi
+ac_ct_CC=$ac_cv_prog_ac_ct_CC
+if test -n "$ac_ct_CC"; then
+  echo "$as_me:$LINENO: result: $ac_ct_CC" >&5
+echo "${ECHO_T}$ac_ct_CC" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+  CC=$ac_ct_CC
+else
+  CC="$ac_cv_prog_CC"
+fi
+
+fi
+if test -z "$CC"; then
+  # Extract the first word of "cc", so it can be a program name with args.
+set dummy cc; ac_word=$2
+echo "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_prog_CC+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -n "$CC"; then
+  ac_cv_prog_CC="$CC" # Let the user override the test.
+else
+  ac_prog_rejected=no
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    if test "$as_dir/$ac_word$ac_exec_ext" = "/usr/ucb/cc"; then
+       ac_prog_rejected=yes
+       continue
+     fi
+    ac_cv_prog_CC="cc"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+if test $ac_prog_rejected = yes; then
+  # We found a bogon in the path, so make sure we never use it.
+  set dummy $ac_cv_prog_CC
+  shift
+  if test $# != 0; then
+    # We chose a different compiler from the bogus one.
+    # However, it has the same basename, so the bogon will be chosen
+    # first if we set CC to just the basename; use the full file name.
+    shift
+    ac_cv_prog_CC="$as_dir/$ac_word${1+' '}$@"
+  fi
+fi
+fi
+fi
+CC=$ac_cv_prog_CC
+if test -n "$CC"; then
+  echo "$as_me:$LINENO: result: $CC" >&5
+echo "${ECHO_T}$CC" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+fi
+if test -z "$CC"; then
+  if test -n "$ac_tool_prefix"; then
+  for ac_prog in cl
+  do
+    # Extract the first word of "$ac_tool_prefix$ac_prog", so it can be a program name with args.
+set dummy $ac_tool_prefix$ac_prog; ac_word=$2
+echo "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_prog_CC+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -n "$CC"; then
+  ac_cv_prog_CC="$CC" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_CC="$ac_tool_prefix$ac_prog"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+fi
+fi
+CC=$ac_cv_prog_CC
+if test -n "$CC"; then
+  echo "$as_me:$LINENO: result: $CC" >&5
+echo "${ECHO_T}$CC" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+    test -n "$CC" && break
+  done
+fi
+if test -z "$CC"; then
+  ac_ct_CC=$CC
+  for ac_prog in cl
+do
+  # Extract the first word of "$ac_prog", so it can be a program name with args.
+set dummy $ac_prog; ac_word=$2
+echo "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_prog_ac_ct_CC+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -n "$ac_ct_CC"; then
+  ac_cv_prog_ac_ct_CC="$ac_ct_CC" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_ac_ct_CC="$ac_prog"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+fi
+fi
+ac_ct_CC=$ac_cv_prog_ac_ct_CC
+if test -n "$ac_ct_CC"; then
+  echo "$as_me:$LINENO: result: $ac_ct_CC" >&5
+echo "${ECHO_T}$ac_ct_CC" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+  test -n "$ac_ct_CC" && break
+done
+
+  CC=$ac_ct_CC
+fi
+
+fi
+
+
+test -z "$CC" && { { echo "$as_me:$LINENO: error: no acceptable C compiler found in \$PATH
+See \`config.log' for more details." >&5
+echo "$as_me: error: no acceptable C compiler found in \$PATH
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; }
+
+# Provide some information about the compiler.
+echo "$as_me:$LINENO:" \
+     "checking for C compiler version" >&5
+ac_compiler=`set X $ac_compile; echo $2`
+{ (eval echo "$as_me:$LINENO: \"$ac_compiler --version </dev/null >&5\"") >&5
+  (eval $ac_compiler --version </dev/null >&5) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }
+{ (eval echo "$as_me:$LINENO: \"$ac_compiler -v </dev/null >&5\"") >&5
+  (eval $ac_compiler -v </dev/null >&5) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }
+{ (eval echo "$as_me:$LINENO: \"$ac_compiler -V </dev/null >&5\"") >&5
+  (eval $ac_compiler -V </dev/null >&5) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }
+
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+int
+main ()
+{
+
+  ;
+  return 0;
+}
+_ACEOF
+ac_clean_files_save=$ac_clean_files
+ac_clean_files="$ac_clean_files a.out a.exe b.out"
+# Try to create an executable without -o first, disregard a.out.
+# It will help us diagnose broken compilers, and finding out an intuition
+# of exeext.
+echo "$as_me:$LINENO: checking for C compiler default output file name" >&5
+echo $ECHO_N "checking for C compiler default output file name... $ECHO_C" >&6
+ac_link_default=`echo "$ac_link" | sed 's/ -o *conftest[^ ]*//'`
+if { (eval echo "$as_me:$LINENO: \"$ac_link_default\"") >&5
+  (eval $ac_link_default) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; then
+  # Find the output, starting from the most likely.  This scheme is
+# not robust to junk in `.', hence go to wildcards (a.*) only as a last
+# resort.
+
+# Be careful to initialize this variable, since it used to be cached.
+# Otherwise an old cache value of `no' led to `EXEEXT = no' in a Makefile.
+ac_cv_exeext=
+# b.out is created by i960 compilers.
+for ac_file in a_out.exe a.exe conftest.exe a.out conftest a.* conftest.* b.out
+do
+  test -f "$ac_file" || continue
+  case $ac_file in
+    *.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.o | *.obj )
+	;;
+    conftest.$ac_ext )
+	# This is the source file.
+	;;
+    [ab].out )
+	# We found the default executable, but exeext='' is most
+	# certainly right.
+	break;;
+    *.* )
+	ac_cv_exeext=`expr "$ac_file" : '[^.]*\(\..*\)'`
+	# FIXME: I believe we export ac_cv_exeext for Libtool,
+	# but it would be cool to find out if it's true.  Does anybody
+	# maintain Libtool? --akim.
+	export ac_cv_exeext
+	break;;
+    * )
+	break;;
+  esac
+done
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+{ { echo "$as_me:$LINENO: error: C compiler cannot create executables
+See \`config.log' for more details." >&5
+echo "$as_me: error: C compiler cannot create executables
+See \`config.log' for more details." >&2;}
+   { (exit 77); exit 77; }; }
+fi
+
+ac_exeext=$ac_cv_exeext
+echo "$as_me:$LINENO: result: $ac_file" >&5
+echo "${ECHO_T}$ac_file" >&6
+
+# Check the compiler produces executables we can run.  If not, either
+# the compiler is broken, or we cross compile.
+echo "$as_me:$LINENO: checking whether the C compiler works" >&5
+echo $ECHO_N "checking whether the C compiler works... $ECHO_C" >&6
+# FIXME: These cross compiler hacks should be removed for Autoconf 3.0
+# If not cross compiling, check that we can run a simple program.
+if test "$cross_compiling" != yes; then
+  if { ac_try='./$ac_file'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+    cross_compiling=no
+  else
+    if test "$cross_compiling" = maybe; then
+	cross_compiling=yes
+    else
+	{ { echo "$as_me:$LINENO: error: cannot run C compiled programs.
+If you meant to cross compile, use \`--host'.
+See \`config.log' for more details." >&5
+echo "$as_me: error: cannot run C compiled programs.
+If you meant to cross compile, use \`--host'.
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; }
+    fi
+  fi
+fi
+echo "$as_me:$LINENO: result: yes" >&5
+echo "${ECHO_T}yes" >&6
+
+rm -f a.out a.exe conftest$ac_cv_exeext b.out
+ac_clean_files=$ac_clean_files_save
+# Check the compiler produces executables we can run.  If not, either
+# the compiler is broken, or we cross compile.
+echo "$as_me:$LINENO: checking whether we are cross compiling" >&5
+echo $ECHO_N "checking whether we are cross compiling... $ECHO_C" >&6
+echo "$as_me:$LINENO: result: $cross_compiling" >&5
+echo "${ECHO_T}$cross_compiling" >&6
+
+echo "$as_me:$LINENO: checking for suffix of executables" >&5
+echo $ECHO_N "checking for suffix of executables... $ECHO_C" >&6
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; then
+  # If both `conftest.exe' and `conftest' are `present' (well, observable)
+# catch `conftest.exe'.  For instance with Cygwin, `ls conftest' will
+# work properly (i.e., refer to `conftest.exe'), while it won't with
+# `rm'.
+for ac_file in conftest.exe conftest conftest.*; do
+  test -f "$ac_file" || continue
+  case $ac_file in
+    *.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.o | *.obj ) ;;
+    *.* ) ac_cv_exeext=`expr "$ac_file" : '[^.]*\(\..*\)'`
+	  export ac_cv_exeext
+	  break;;
+    * ) break;;
+  esac
+done
+else
+  { { echo "$as_me:$LINENO: error: cannot compute suffix of executables: cannot compile and link
+See \`config.log' for more details." >&5
+echo "$as_me: error: cannot compute suffix of executables: cannot compile and link
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; }
+fi
+
+rm -f conftest$ac_cv_exeext
+echo "$as_me:$LINENO: result: $ac_cv_exeext" >&5
+echo "${ECHO_T}$ac_cv_exeext" >&6
+
+rm -f conftest.$ac_ext
+EXEEXT=$ac_cv_exeext
+ac_exeext=$EXEEXT
+echo "$as_me:$LINENO: checking for suffix of object files" >&5
+echo $ECHO_N "checking for suffix of object files... $ECHO_C" >&6
+if test "${ac_cv_objext+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+int
+main ()
+{
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.o conftest.obj
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; then
+  for ac_file in `(ls conftest.o conftest.obj; ls conftest.*) 2>/dev/null`; do
+  case $ac_file in
+    *.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg ) ;;
+    *) ac_cv_objext=`expr "$ac_file" : '.*\.\(.*\)'`
+       break;;
+  esac
+done
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+{ { echo "$as_me:$LINENO: error: cannot compute suffix of object files: cannot compile
+See \`config.log' for more details." >&5
+echo "$as_me: error: cannot compute suffix of object files: cannot compile
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; }
+fi
+
+rm -f conftest.$ac_cv_objext conftest.$ac_ext
+fi
+echo "$as_me:$LINENO: result: $ac_cv_objext" >&5
+echo "${ECHO_T}$ac_cv_objext" >&6
+OBJEXT=$ac_cv_objext
+ac_objext=$OBJEXT
+echo "$as_me:$LINENO: checking whether we are using the GNU C compiler" >&5
+echo $ECHO_N "checking whether we are using the GNU C compiler... $ECHO_C" >&6
+if test "${ac_cv_c_compiler_gnu+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+int
+main ()
+{
+#ifndef __GNUC__
+       choke me
+#endif
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_compiler_gnu=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_compiler_gnu=no
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_cv_c_compiler_gnu=$ac_compiler_gnu
+
+fi
+echo "$as_me:$LINENO: result: $ac_cv_c_compiler_gnu" >&5
+echo "${ECHO_T}$ac_cv_c_compiler_gnu" >&6
+GCC=`test $ac_compiler_gnu = yes && echo yes`
+ac_test_CFLAGS=${CFLAGS+set}
+ac_save_CFLAGS=$CFLAGS
+CFLAGS="-g"
+echo "$as_me:$LINENO: checking whether $CC accepts -g" >&5
+echo $ECHO_N "checking whether $CC accepts -g... $ECHO_C" >&6
+if test "${ac_cv_prog_cc_g+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+int
+main ()
+{
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_prog_cc_g=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_cv_prog_cc_g=no
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+echo "$as_me:$LINENO: result: $ac_cv_prog_cc_g" >&5
+echo "${ECHO_T}$ac_cv_prog_cc_g" >&6
+if test "$ac_test_CFLAGS" = set; then
+  CFLAGS=$ac_save_CFLAGS
+elif test $ac_cv_prog_cc_g = yes; then
+  if test "$GCC" = yes; then
+    CFLAGS="-g -O2"
+  else
+    CFLAGS="-g"
+  fi
+else
+  if test "$GCC" = yes; then
+    CFLAGS="-O2"
+  else
+    CFLAGS=
+  fi
+fi
+echo "$as_me:$LINENO: checking for $CC option to accept ANSI C" >&5
+echo $ECHO_N "checking for $CC option to accept ANSI C... $ECHO_C" >&6
+if test "${ac_cv_prog_cc_stdc+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  ac_cv_prog_cc_stdc=no
+ac_save_CC=$CC
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include <stdarg.h>
+#include <stdio.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+/* Most of the following tests are stolen from RCS 5.7's src/conf.sh.  */
+struct buf { int x; };
+FILE * (*rcsopen) (struct buf *, struct stat *, int);
+static char *e (p, i)
+     char **p;
+     int i;
+{
+  return p[i];
+}
+static char *f (char * (*g) (char **, int), char **p, ...)
+{
+  char *s;
+  va_list v;
+  va_start (v,p);
+  s = g (p, va_arg (v,int));
+  va_end (v);
+  return s;
+}
+
+/* OSF 4.0 Compaq cc is some sort of almost-ANSI by default.  It has
+   function prototypes and stuff, but not '\xHH' hex character constants.
+   These don't provoke an error unfortunately, instead are silently treated
+   as 'x'.  The following induces an error, until -std1 is added to get
+   proper ANSI mode.  Curiously '\x00'!='x' always comes out true, for an
+   array size at least.  It's necessary to write '\x00'==0 to get something
+   that's true only with -std1.  */
+int osf4_cc_array ['\x00' == 0 ? 1 : -1];
+
+int test (int i, double x);
+struct s1 {int (*f) (int a);};
+struct s2 {int (*f) (double a);};
+int pairnames (int, char **, FILE *(*)(struct buf *, struct stat *, int), int, int);
+int argc;
+char **argv;
+int
+main ()
+{
+return f (e, argv, 0) != argv[0]  ||  f (e, argv, 1) != argv[1];
+  ;
+  return 0;
+}
+_ACEOF
+# Don't try gcc -ansi; that turns off useful extensions and
+# breaks some systems' header files.
+# AIX			-qlanglvl=ansi
+# Ultrix and OSF/1	-std1
+# HP-UX 10.20 and later	-Ae
+# HP-UX older versions	-Aa -D_HPUX_SOURCE
+# SVR4			-Xc -D__EXTENSIONS__
+for ac_arg in "" -qlanglvl=ansi -std1 -Ae "-Aa -D_HPUX_SOURCE" "-Xc -D__EXTENSIONS__"
+do
+  CC="$ac_save_CC $ac_arg"
+  rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_prog_cc_stdc=$ac_arg
+break
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+fi
+rm -f conftest.err conftest.$ac_objext
+done
+rm -f conftest.$ac_ext conftest.$ac_objext
+CC=$ac_save_CC
+
+fi
+
+case "x$ac_cv_prog_cc_stdc" in
+  x|xno)
+    echo "$as_me:$LINENO: result: none needed" >&5
+echo "${ECHO_T}none needed" >&6 ;;
+  *)
+    echo "$as_me:$LINENO: result: $ac_cv_prog_cc_stdc" >&5
+echo "${ECHO_T}$ac_cv_prog_cc_stdc" >&6
+    CC="$CC $ac_cv_prog_cc_stdc" ;;
+esac
+
+# Some people use a C++ compiler to compile C.  Since we use `exit',
+# in C++ we need to declare it.  In case someone uses the same compiler
+# for both compiling C and C++ we need to have the C++ compiler decide
+# the declaration of exit, since it's the most demanding environment.
+cat >conftest.$ac_ext <<_ACEOF
+#ifndef __cplusplus
+  choke me
+#endif
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  for ac_declaration in \
+   '' \
+   'extern "C" void std::exit (int) throw (); using std::exit;' \
+   'extern "C" void std::exit (int); using std::exit;' \
+   'extern "C" void exit (int) throw ();' \
+   'extern "C" void exit (int);' \
+   'void exit (int);'
+do
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_declaration
+#include <stdlib.h>
+int
+main ()
+{
+exit (42);
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  :
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+continue
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_declaration
+int
+main ()
+{
+exit (42);
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  break
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+done
+rm -f conftest*
+if test -n "$ac_declaration"; then
+  echo '#ifdef __cplusplus' >>confdefs.h
+  echo $ac_declaration      >>confdefs.h
+  echo '#endif'             >>confdefs.h
+fi
+
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+
+if test "$GCC" = "yes"; then
+	CFLAGS="${CFLAGS} -Wall"
+fi
+ac_aux_dir=
+for ac_dir in $srcdir $srcdir/.. $srcdir/../..; do
+  if test -f $ac_dir/install-sh; then
+    ac_aux_dir=$ac_dir
+    ac_install_sh="$ac_aux_dir/install-sh -c"
+    break
+  elif test -f $ac_dir/install.sh; then
+    ac_aux_dir=$ac_dir
+    ac_install_sh="$ac_aux_dir/install.sh -c"
+    break
+  elif test -f $ac_dir/shtool; then
+    ac_aux_dir=$ac_dir
+    ac_install_sh="$ac_aux_dir/shtool install -c"
+    break
+  fi
+done
+if test -z "$ac_aux_dir"; then
+  { { echo "$as_me:$LINENO: error: cannot find install-sh or install.sh in $srcdir $srcdir/.. $srcdir/../.." >&5
+echo "$as_me: error: cannot find install-sh or install.sh in $srcdir $srcdir/.. $srcdir/../.." >&2;}
+   { (exit 1); exit 1; }; }
+fi
+ac_config_guess="$SHELL $ac_aux_dir/config.guess"
+ac_config_sub="$SHELL $ac_aux_dir/config.sub"
+ac_configure="$SHELL $ac_aux_dir/configure" # This should be Cygnus configure.
+
+# Find a good install program.  We prefer a C program (faster),
+# so one script is as good as another.  But avoid the broken or
+# incompatible versions:
+# SysV /etc/install, /usr/sbin/install
+# SunOS /usr/etc/install
+# IRIX /sbin/install
+# AIX /bin/install
+# AmigaOS /C/install, which installs bootblocks on floppy discs
+# AIX 4 /usr/bin/installbsd, which doesn't work without a -g flag
+# AFS /usr/afsws/bin/install, which mishandles nonexistent args
+# SVR4 /usr/ucb/install, which tries to use the nonexistent group "staff"
+# OS/2's system install, which has a completely different semantic
+# ./install, which can be erroneously created by make from ./install.sh.
+echo "$as_me:$LINENO: checking for a BSD-compatible install" >&5
+echo $ECHO_N "checking for a BSD-compatible install... $ECHO_C" >&6
+if test -z "$INSTALL"; then
+if test "${ac_cv_path_install+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  # Account for people who put trailing slashes in PATH elements.
+case $as_dir/ in
+  ./ | .// | /cC/* | \
+  /etc/* | /usr/sbin/* | /usr/etc/* | /sbin/* | /usr/afsws/bin/* | \
+  ?:\\/os2\\/install\\/* | ?:\\/OS2\\/INSTALL\\/* | \
+  /usr/ucb/* ) ;;
+  *)
+    # OSF1 and SCO ODT 3.0 have their own names for install.
+    # Don't use installbsd from OSF since it installs stuff as root
+    # by default.
+    for ac_prog in ginstall scoinst install; do
+      for ac_exec_ext in '' $ac_executable_extensions; do
+	if $as_executable_p "$as_dir/$ac_prog$ac_exec_ext"; then
+	  if test $ac_prog = install &&
+	    grep dspmsg "$as_dir/$ac_prog$ac_exec_ext" >/dev/null 2>&1; then
+	    # AIX install.  It has an incompatible calling convention.
+	    :
+	  elif test $ac_prog = install &&
+	    grep pwplus "$as_dir/$ac_prog$ac_exec_ext" >/dev/null 2>&1; then
+	    # program-specific install script used by HP pwplus--don't use.
+	    :
+	  else
+	    ac_cv_path_install="$as_dir/$ac_prog$ac_exec_ext -c"
+	    break 3
+	  fi
+	fi
+      done
+    done
+    ;;
+esac
+done
+
+
+fi
+  if test "${ac_cv_path_install+set}" = set; then
+    INSTALL=$ac_cv_path_install
+  else
+    # As a last resort, use the slow shell script.  We don't cache a
+    # path for INSTALL within a source directory, because that will
+    # break other packages using the cache if that directory is
+    # removed, or if the path is relative.
+    INSTALL=$ac_install_sh
+  fi
+fi
+echo "$as_me:$LINENO: result: $INSTALL" >&5
+echo "${ECHO_T}$INSTALL" >&6
+
+# Use test -z because SunOS4 sh mishandles braces in ${var-val}.
+# It thinks the first close brace ends the variable substitution.
+test -z "$INSTALL_PROGRAM" && INSTALL_PROGRAM='${INSTALL}'
+
+test -z "$INSTALL_SCRIPT" && INSTALL_SCRIPT='${INSTALL}'
+
+test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
+
+
+
+
+echo "$as_me:$LINENO: checking for res_query in -lresolv" >&5
+echo $ECHO_N "checking for res_query in -lresolv... $ECHO_C" >&6
+if test "${ac_cv_lib_resolv_res_query+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  ac_check_lib_save_LIBS=$LIBS
+LIBS="-lresolv  $LIBS"
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+/* Override any gcc2 internal prototype to avoid an error.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+/* We use char because int might match the return type of a gcc2
+   builtin and then its argument prototype would still apply.  */
+char res_query ();
+int
+main ()
+{
+res_query ();
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_lib_resolv_res_query=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_cv_lib_resolv_res_query=no
+fi
+rm -f conftest.err conftest.$ac_objext \
+      conftest$ac_exeext conftest.$ac_ext
+LIBS=$ac_check_lib_save_LIBS
+fi
+echo "$as_me:$LINENO: result: $ac_cv_lib_resolv_res_query" >&5
+echo "${ECHO_T}$ac_cv_lib_resolv_res_query" >&6
+if test $ac_cv_lib_resolv_res_query = yes; then
+  cat >>confdefs.h <<_ACEOF
+#define HAVE_LIBRESOLV 1
+_ACEOF
+
+  LIBS="-lresolv $LIBS"
+
+fi
+
+
+ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+echo "$as_me:$LINENO: checking how to run the C preprocessor" >&5
+echo $ECHO_N "checking how to run the C preprocessor... $ECHO_C" >&6
+# On Suns, sometimes $CPP names a directory.
+if test -n "$CPP" && test -d "$CPP"; then
+  CPP=
+fi
+if test -z "$CPP"; then
+  if test "${ac_cv_prog_CPP+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+      # Double quotes because CPP needs to be expanded
+    for CPP in "$CC -E" "$CC -E -traditional-cpp" "/lib/cpp"
+    do
+      ac_preproc_ok=false
+for ac_c_preproc_warn_flag in '' yes
+do
+  # Use a header file that comes with gcc, so configuring glibc
+  # with a fresh cross-compiler works.
+  # Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
+  # <limits.h> exists even on freestanding compilers.
+  # On the NeXT, cc -E runs the code through the compiler's parser,
+  # not just through cpp. "Syntax error" is here to catch this case.
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#ifdef __STDC__
+# include <limits.h>
+#else
+# include <assert.h>
+#endif
+		     Syntax error
+_ACEOF
+if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
+  (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } >/dev/null; then
+  if test -s conftest.err; then
+    ac_cpp_err=$ac_c_preproc_warn_flag
+    ac_cpp_err=$ac_cpp_err$ac_c_werror_flag
+  else
+    ac_cpp_err=
+  fi
+else
+  ac_cpp_err=yes
+fi
+if test -z "$ac_cpp_err"; then
+  :
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+  # Broken: fails on valid input.
+continue
+fi
+rm -f conftest.err conftest.$ac_ext
+
+  # OK, works on sane cases.  Now check whether non-existent headers
+  # can be detected and how.
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include <ac_nonexistent.h>
+_ACEOF
+if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
+  (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } >/dev/null; then
+  if test -s conftest.err; then
+    ac_cpp_err=$ac_c_preproc_warn_flag
+    ac_cpp_err=$ac_cpp_err$ac_c_werror_flag
+  else
+    ac_cpp_err=
+  fi
+else
+  ac_cpp_err=yes
+fi
+if test -z "$ac_cpp_err"; then
+  # Broken: success on invalid input.
+continue
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+  # Passes both tests.
+ac_preproc_ok=:
+break
+fi
+rm -f conftest.err conftest.$ac_ext
+
+done
+# Because of `break', _AC_PREPROC_IFELSE's cleaning code was skipped.
+rm -f conftest.err conftest.$ac_ext
+if $ac_preproc_ok; then
+  break
+fi
+
+    done
+    ac_cv_prog_CPP=$CPP
+
+fi
+  CPP=$ac_cv_prog_CPP
+else
+  ac_cv_prog_CPP=$CPP
+fi
+echo "$as_me:$LINENO: result: $CPP" >&5
+echo "${ECHO_T}$CPP" >&6
+ac_preproc_ok=false
+for ac_c_preproc_warn_flag in '' yes
+do
+  # Use a header file that comes with gcc, so configuring glibc
+  # with a fresh cross-compiler works.
+  # Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
+  # <limits.h> exists even on freestanding compilers.
+  # On the NeXT, cc -E runs the code through the compiler's parser,
+  # not just through cpp. "Syntax error" is here to catch this case.
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#ifdef __STDC__
+# include <limits.h>
+#else
+# include <assert.h>
+#endif
+		     Syntax error
+_ACEOF
+if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
+  (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } >/dev/null; then
+  if test -s conftest.err; then
+    ac_cpp_err=$ac_c_preproc_warn_flag
+    ac_cpp_err=$ac_cpp_err$ac_c_werror_flag
+  else
+    ac_cpp_err=
+  fi
+else
+  ac_cpp_err=yes
+fi
+if test -z "$ac_cpp_err"; then
+  :
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+  # Broken: fails on valid input.
+continue
+fi
+rm -f conftest.err conftest.$ac_ext
+
+  # OK, works on sane cases.  Now check whether non-existent headers
+  # can be detected and how.
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include <ac_nonexistent.h>
+_ACEOF
+if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
+  (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } >/dev/null; then
+  if test -s conftest.err; then
+    ac_cpp_err=$ac_c_preproc_warn_flag
+    ac_cpp_err=$ac_cpp_err$ac_c_werror_flag
+  else
+    ac_cpp_err=
+  fi
+else
+  ac_cpp_err=yes
+fi
+if test -z "$ac_cpp_err"; then
+  # Broken: success on invalid input.
+continue
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+  # Passes both tests.
+ac_preproc_ok=:
+break
+fi
+rm -f conftest.err conftest.$ac_ext
+
+done
+# Because of `break', _AC_PREPROC_IFELSE's cleaning code was skipped.
+rm -f conftest.err conftest.$ac_ext
+if $ac_preproc_ok; then
+  :
+else
+  { { echo "$as_me:$LINENO: error: C preprocessor \"$CPP\" fails sanity check
+See \`config.log' for more details." >&5
+echo "$as_me: error: C preprocessor \"$CPP\" fails sanity check
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; }
+fi
+
+ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+
+
+echo "$as_me:$LINENO: checking for egrep" >&5
+echo $ECHO_N "checking for egrep... $ECHO_C" >&6
+if test "${ac_cv_prog_egrep+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if echo a | (grep -E '(a|b)') >/dev/null 2>&1
+    then ac_cv_prog_egrep='grep -E'
+    else ac_cv_prog_egrep='egrep'
+    fi
+fi
+echo "$as_me:$LINENO: result: $ac_cv_prog_egrep" >&5
+echo "${ECHO_T}$ac_cv_prog_egrep" >&6
+ EGREP=$ac_cv_prog_egrep
+
+
+echo "$as_me:$LINENO: checking for ANSI C header files" >&5
+echo $ECHO_N "checking for ANSI C header files... $ECHO_C" >&6
+if test "${ac_cv_header_stdc+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include <stdlib.h>
+#include <stdarg.h>
+#include <string.h>
+#include <float.h>
+
+int
+main ()
+{
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_header_stdc=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_cv_header_stdc=no
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+
+if test $ac_cv_header_stdc = yes; then
+  # SunOS 4.x string.h does not declare mem*, contrary to ANSI.
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include <string.h>
+
+_ACEOF
+if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
+  $EGREP "memchr" >/dev/null 2>&1; then
+  :
+else
+  ac_cv_header_stdc=no
+fi
+rm -f conftest*
+
+fi
+
+if test $ac_cv_header_stdc = yes; then
+  # ISC 2.0.2 stdlib.h does not declare free, contrary to ANSI.
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include <stdlib.h>
+
+_ACEOF
+if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
+  $EGREP "free" >/dev/null 2>&1; then
+  :
+else
+  ac_cv_header_stdc=no
+fi
+rm -f conftest*
+
+fi
+
+if test $ac_cv_header_stdc = yes; then
+  # /bin/cc in Irix-4.0.5 gets non-ANSI ctype macros unless using -ansi.
+  if test "$cross_compiling" = yes; then
+  :
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include <ctype.h>
+#if ((' ' & 0x0FF) == 0x020)
+# define ISLOWER(c) ('a' <= (c) && (c) <= 'z')
+# define TOUPPER(c) (ISLOWER(c) ? 'A' + ((c) - 'a') : (c))
+#else
+# define ISLOWER(c) \
+		   (('a' <= (c) && (c) <= 'i') \
+		     || ('j' <= (c) && (c) <= 'r') \
+		     || ('s' <= (c) && (c) <= 'z'))
+# define TOUPPER(c) (ISLOWER(c) ? ((c) | 0x40) : (c))
+#endif
+
+#define XOR(e, f) (((e) && !(f)) || (!(e) && (f)))
+int
+main ()
+{
+  int i;
+  for (i = 0; i < 256; i++)
+    if (XOR (islower (i), ISLOWER (i))
+	|| toupper (i) != TOUPPER (i))
+      exit(2);
+  exit (0);
+}
+_ACEOF
+rm -f conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } && { ac_try='./conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  :
+else
+  echo "$as_me: program exited with status $ac_status" >&5
+echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+( exit $ac_status )
+ac_cv_header_stdc=no
+fi
+rm -f core *.core gmon.out bb.out conftest$ac_exeext conftest.$ac_objext conftest.$ac_ext
+fi
+fi
+fi
+echo "$as_me:$LINENO: result: $ac_cv_header_stdc" >&5
+echo "${ECHO_T}$ac_cv_header_stdc" >&6
+if test $ac_cv_header_stdc = yes; then
+
+cat >>confdefs.h <<\_ACEOF
+#define STDC_HEADERS 1
+_ACEOF
+
+fi
+
+          ac_config_headers="$ac_config_headers config.h"
+
+# On IRIX 5.3, sys/types and inttypes.h are conflicting.
+
+
+
+
+
+
+
+
+
+for ac_header in sys/types.h sys/stat.h stdlib.h string.h memory.h strings.h \
+		  inttypes.h stdint.h unistd.h
+do
+as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh`
+echo "$as_me:$LINENO: checking for $ac_header" >&5
+echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6
+if eval "test \"\${$as_ac_Header+set}\" = set"; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+
+#include <$ac_header>
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  eval "$as_ac_Header=yes"
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+eval "$as_ac_Header=no"
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+echo "$as_me:$LINENO: result: `eval echo '${'$as_ac_Header'}'`" >&5
+echo "${ECHO_T}`eval echo '${'$as_ac_Header'}'`" >&6
+if test `eval echo '${'$as_ac_Header'}'` = yes; then
+  cat >>confdefs.h <<_ACEOF
+#define `echo "HAVE_$ac_header" | $as_tr_cpp` 1
+_ACEOF
+
+fi
+
+done
+
+
+if test "${ac_cv_header_resolv_h+set}" = set; then
+  echo "$as_me:$LINENO: checking for resolv.h" >&5
+echo $ECHO_N "checking for resolv.h... $ECHO_C" >&6
+if test "${ac_cv_header_resolv_h+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+fi
+echo "$as_me:$LINENO: result: $ac_cv_header_resolv_h" >&5
+echo "${ECHO_T}$ac_cv_header_resolv_h" >&6
+else
+  # Is the header compilable?
+echo "$as_me:$LINENO: checking resolv.h usability" >&5
+echo $ECHO_N "checking resolv.h usability... $ECHO_C" >&6
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+#include <resolv.h>
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_header_compiler=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_header_compiler=no
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+echo "$as_me:$LINENO: result: $ac_header_compiler" >&5
+echo "${ECHO_T}$ac_header_compiler" >&6
+
+# Is the header present?
+echo "$as_me:$LINENO: checking resolv.h presence" >&5
+echo $ECHO_N "checking resolv.h presence... $ECHO_C" >&6
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include <resolv.h>
+_ACEOF
+if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
+  (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } >/dev/null; then
+  if test -s conftest.err; then
+    ac_cpp_err=$ac_c_preproc_warn_flag
+    ac_cpp_err=$ac_cpp_err$ac_c_werror_flag
+  else
+    ac_cpp_err=
+  fi
+else
+  ac_cpp_err=yes
+fi
+if test -z "$ac_cpp_err"; then
+  ac_header_preproc=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+  ac_header_preproc=no
+fi
+rm -f conftest.err conftest.$ac_ext
+echo "$as_me:$LINENO: result: $ac_header_preproc" >&5
+echo "${ECHO_T}$ac_header_preproc" >&6
+
+# So?  What about this header?
+case $ac_header_compiler:$ac_header_preproc:$ac_c_preproc_warn_flag in
+  yes:no: )
+    { echo "$as_me:$LINENO: WARNING: resolv.h: accepted by the compiler, rejected by the preprocessor!" >&5
+echo "$as_me: WARNING: resolv.h: accepted by the compiler, rejected by the preprocessor!" >&2;}
+    { echo "$as_me:$LINENO: WARNING: resolv.h: proceeding with the compiler's result" >&5
+echo "$as_me: WARNING: resolv.h: proceeding with the compiler's result" >&2;}
+    ac_header_preproc=yes
+    ;;
+  no:yes:* )
+    { echo "$as_me:$LINENO: WARNING: resolv.h: present but cannot be compiled" >&5
+echo "$as_me: WARNING: resolv.h: present but cannot be compiled" >&2;}
+    { echo "$as_me:$LINENO: WARNING: resolv.h:     check for missing prerequisite headers?" >&5
+echo "$as_me: WARNING: resolv.h:     check for missing prerequisite headers?" >&2;}
+    { echo "$as_me:$LINENO: WARNING: resolv.h: see the Autoconf documentation" >&5
+echo "$as_me: WARNING: resolv.h: see the Autoconf documentation" >&2;}
+    { echo "$as_me:$LINENO: WARNING: resolv.h:     section \"Present But Cannot Be Compiled\"" >&5
+echo "$as_me: WARNING: resolv.h:     section \"Present But Cannot Be Compiled\"" >&2;}
+    { echo "$as_me:$LINENO: WARNING: resolv.h: proceeding with the preprocessor's result" >&5
+echo "$as_me: WARNING: resolv.h: proceeding with the preprocessor's result" >&2;}
+    { echo "$as_me:$LINENO: WARNING: resolv.h: in the future, the compiler will take precedence" >&5
+echo "$as_me: WARNING: resolv.h: in the future, the compiler will take precedence" >&2;}
+    (
+      cat <<\_ASBOX
+## ------------------------------------------ ##
+## Report this to the AC_PACKAGE_NAME lists.  ##
+## ------------------------------------------ ##
+_ASBOX
+    ) |
+      sed "s/^/$as_me: WARNING:     /" >&2
+    ;;
+esac
+echo "$as_me:$LINENO: checking for resolv.h" >&5
+echo $ECHO_N "checking for resolv.h... $ECHO_C" >&6
+if test "${ac_cv_header_resolv_h+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  ac_cv_header_resolv_h=$ac_header_preproc
+fi
+echo "$as_me:$LINENO: result: $ac_cv_header_resolv_h" >&5
+echo "${ECHO_T}$ac_cv_header_resolv_h" >&6
+
+fi
+if test $ac_cv_header_resolv_h = yes; then
+  :
+else
+  { { echo "$as_me:$LINENO: error: \"No headers for name service applications\"" >&5
+echo "$as_me: error: \"No headers for name service applications\"" >&2;}
+   { (exit 1); exit 1; }; }
+fi
+
+
+if test "${ac_cv_header_arpa_nameser_h+set}" = set; then
+  echo "$as_me:$LINENO: checking for arpa/nameser.h" >&5
+echo $ECHO_N "checking for arpa/nameser.h... $ECHO_C" >&6
+if test "${ac_cv_header_arpa_nameser_h+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+fi
+echo "$as_me:$LINENO: result: $ac_cv_header_arpa_nameser_h" >&5
+echo "${ECHO_T}$ac_cv_header_arpa_nameser_h" >&6
+else
+  # Is the header compilable?
+echo "$as_me:$LINENO: checking arpa/nameser.h usability" >&5
+echo $ECHO_N "checking arpa/nameser.h usability... $ECHO_C" >&6
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+#include <arpa/nameser.h>
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_header_compiler=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_header_compiler=no
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+echo "$as_me:$LINENO: result: $ac_header_compiler" >&5
+echo "${ECHO_T}$ac_header_compiler" >&6
+
+# Is the header present?
+echo "$as_me:$LINENO: checking arpa/nameser.h presence" >&5
+echo $ECHO_N "checking arpa/nameser.h presence... $ECHO_C" >&6
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include <arpa/nameser.h>
+_ACEOF
+if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
+  (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } >/dev/null; then
+  if test -s conftest.err; then
+    ac_cpp_err=$ac_c_preproc_warn_flag
+    ac_cpp_err=$ac_cpp_err$ac_c_werror_flag
+  else
+    ac_cpp_err=
+  fi
+else
+  ac_cpp_err=yes
+fi
+if test -z "$ac_cpp_err"; then
+  ac_header_preproc=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+  ac_header_preproc=no
+fi
+rm -f conftest.err conftest.$ac_ext
+echo "$as_me:$LINENO: result: $ac_header_preproc" >&5
+echo "${ECHO_T}$ac_header_preproc" >&6
+
+# So?  What about this header?
+case $ac_header_compiler:$ac_header_preproc:$ac_c_preproc_warn_flag in
+  yes:no: )
+    { echo "$as_me:$LINENO: WARNING: arpa/nameser.h: accepted by the compiler, rejected by the preprocessor!" >&5
+echo "$as_me: WARNING: arpa/nameser.h: accepted by the compiler, rejected by the preprocessor!" >&2;}
+    { echo "$as_me:$LINENO: WARNING: arpa/nameser.h: proceeding with the compiler's result" >&5
+echo "$as_me: WARNING: arpa/nameser.h: proceeding with the compiler's result" >&2;}
+    ac_header_preproc=yes
+    ;;
+  no:yes:* )
+    { echo "$as_me:$LINENO: WARNING: arpa/nameser.h: present but cannot be compiled" >&5
+echo "$as_me: WARNING: arpa/nameser.h: present but cannot be compiled" >&2;}
+    { echo "$as_me:$LINENO: WARNING: arpa/nameser.h:     check for missing prerequisite headers?" >&5
+echo "$as_me: WARNING: arpa/nameser.h:     check for missing prerequisite headers?" >&2;}
+    { echo "$as_me:$LINENO: WARNING: arpa/nameser.h: see the Autoconf documentation" >&5
+echo "$as_me: WARNING: arpa/nameser.h: see the Autoconf documentation" >&2;}
+    { echo "$as_me:$LINENO: WARNING: arpa/nameser.h:     section \"Present But Cannot Be Compiled\"" >&5
+echo "$as_me: WARNING: arpa/nameser.h:     section \"Present But Cannot Be Compiled\"" >&2;}
+    { echo "$as_me:$LINENO: WARNING: arpa/nameser.h: proceeding with the preprocessor's result" >&5
+echo "$as_me: WARNING: arpa/nameser.h: proceeding with the preprocessor's result" >&2;}
+    { echo "$as_me:$LINENO: WARNING: arpa/nameser.h: in the future, the compiler will take precedence" >&5
+echo "$as_me: WARNING: arpa/nameser.h: in the future, the compiler will take precedence" >&2;}
+    (
+      cat <<\_ASBOX
+## ------------------------------------------ ##
+## Report this to the AC_PACKAGE_NAME lists.  ##
+## ------------------------------------------ ##
+_ASBOX
+    ) |
+      sed "s/^/$as_me: WARNING:     /" >&2
+    ;;
+esac
+echo "$as_me:$LINENO: checking for arpa/nameser.h" >&5
+echo $ECHO_N "checking for arpa/nameser.h... $ECHO_C" >&6
+if test "${ac_cv_header_arpa_nameser_h+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  ac_cv_header_arpa_nameser_h=$ac_header_preproc
+fi
+echo "$as_me:$LINENO: result: $ac_cv_header_arpa_nameser_h" >&5
+echo "${ECHO_T}$ac_cv_header_arpa_nameser_h" >&6
+
+fi
+if test $ac_cv_header_arpa_nameser_h = yes; then
+  :
+else
+  { { echo "$as_me:$LINENO: error: \"No headers for name service applications\"" >&5
+echo "$as_me: error: \"No headers for name service applications\"" >&2;}
+   { (exit 1); exit 1; }; }
+fi
+
+
+if test "${ac_cv_header_sys_time_h+set}" = set; then
+  echo "$as_me:$LINENO: checking for sys/time.h" >&5
+echo $ECHO_N "checking for sys/time.h... $ECHO_C" >&6
+if test "${ac_cv_header_sys_time_h+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+fi
+echo "$as_me:$LINENO: result: $ac_cv_header_sys_time_h" >&5
+echo "${ECHO_T}$ac_cv_header_sys_time_h" >&6
+else
+  # Is the header compilable?
+echo "$as_me:$LINENO: checking sys/time.h usability" >&5
+echo $ECHO_N "checking sys/time.h usability... $ECHO_C" >&6
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+#include <sys/time.h>
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_header_compiler=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_header_compiler=no
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+echo "$as_me:$LINENO: result: $ac_header_compiler" >&5
+echo "${ECHO_T}$ac_header_compiler" >&6
+
+# Is the header present?
+echo "$as_me:$LINENO: checking sys/time.h presence" >&5
+echo $ECHO_N "checking sys/time.h presence... $ECHO_C" >&6
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include <sys/time.h>
+_ACEOF
+if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
+  (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } >/dev/null; then
+  if test -s conftest.err; then
+    ac_cpp_err=$ac_c_preproc_warn_flag
+    ac_cpp_err=$ac_cpp_err$ac_c_werror_flag
+  else
+    ac_cpp_err=
+  fi
+else
+  ac_cpp_err=yes
+fi
+if test -z "$ac_cpp_err"; then
+  ac_header_preproc=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+  ac_header_preproc=no
+fi
+rm -f conftest.err conftest.$ac_ext
+echo "$as_me:$LINENO: result: $ac_header_preproc" >&5
+echo "${ECHO_T}$ac_header_preproc" >&6
+
+# So?  What about this header?
+case $ac_header_compiler:$ac_header_preproc:$ac_c_preproc_warn_flag in
+  yes:no: )
+    { echo "$as_me:$LINENO: WARNING: sys/time.h: accepted by the compiler, rejected by the preprocessor!" >&5
+echo "$as_me: WARNING: sys/time.h: accepted by the compiler, rejected by the preprocessor!" >&2;}
+    { echo "$as_me:$LINENO: WARNING: sys/time.h: proceeding with the compiler's result" >&5
+echo "$as_me: WARNING: sys/time.h: proceeding with the compiler's result" >&2;}
+    ac_header_preproc=yes
+    ;;
+  no:yes:* )
+    { echo "$as_me:$LINENO: WARNING: sys/time.h: present but cannot be compiled" >&5
+echo "$as_me: WARNING: sys/time.h: present but cannot be compiled" >&2;}
+    { echo "$as_me:$LINENO: WARNING: sys/time.h:     check for missing prerequisite headers?" >&5
+echo "$as_me: WARNING: sys/time.h:     check for missing prerequisite headers?" >&2;}
+    { echo "$as_me:$LINENO: WARNING: sys/time.h: see the Autoconf documentation" >&5
+echo "$as_me: WARNING: sys/time.h: see the Autoconf documentation" >&2;}
+    { echo "$as_me:$LINENO: WARNING: sys/time.h:     section \"Present But Cannot Be Compiled\"" >&5
+echo "$as_me: WARNING: sys/time.h:     section \"Present But Cannot Be Compiled\"" >&2;}
+    { echo "$as_me:$LINENO: WARNING: sys/time.h: proceeding with the preprocessor's result" >&5
+echo "$as_me: WARNING: sys/time.h: proceeding with the preprocessor's result" >&2;}
+    { echo "$as_me:$LINENO: WARNING: sys/time.h: in the future, the compiler will take precedence" >&5
+echo "$as_me: WARNING: sys/time.h: in the future, the compiler will take precedence" >&2;}
+    (
+      cat <<\_ASBOX
+## ------------------------------------------ ##
+## Report this to the AC_PACKAGE_NAME lists.  ##
+## ------------------------------------------ ##
+_ASBOX
+    ) |
+      sed "s/^/$as_me: WARNING:     /" >&2
+    ;;
+esac
+echo "$as_me:$LINENO: checking for sys/time.h" >&5
+echo $ECHO_N "checking for sys/time.h... $ECHO_C" >&6
+if test "${ac_cv_header_sys_time_h+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  ac_cv_header_sys_time_h=$ac_header_preproc
+fi
+echo "$as_me:$LINENO: result: $ac_cv_header_sys_time_h" >&5
+echo "${ECHO_T}$ac_cv_header_sys_time_h" >&6
+
+fi
+if test $ac_cv_header_sys_time_h = yes; then
+  :
+else
+  { { echo "$as_me:$LINENO: error: \"Mandatory header missing on your system\"" >&5
+echo "$as_me: error: \"Mandatory header missing on your system\"" >&2;}
+   { (exit 1); exit 1; }; }
+fi
+
+
+if test "${ac_cv_header_unistd_h+set}" = set; then
+  echo "$as_me:$LINENO: checking for unistd.h" >&5
+echo $ECHO_N "checking for unistd.h... $ECHO_C" >&6
+if test "${ac_cv_header_unistd_h+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+fi
+echo "$as_me:$LINENO: result: $ac_cv_header_unistd_h" >&5
+echo "${ECHO_T}$ac_cv_header_unistd_h" >&6
+else
+  # Is the header compilable?
+echo "$as_me:$LINENO: checking unistd.h usability" >&5
+echo $ECHO_N "checking unistd.h usability... $ECHO_C" >&6
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+#include <unistd.h>
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_header_compiler=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_header_compiler=no
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+echo "$as_me:$LINENO: result: $ac_header_compiler" >&5
+echo "${ECHO_T}$ac_header_compiler" >&6
+
+# Is the header present?
+echo "$as_me:$LINENO: checking unistd.h presence" >&5
+echo $ECHO_N "checking unistd.h presence... $ECHO_C" >&6
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include <unistd.h>
+_ACEOF
+if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
+  (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } >/dev/null; then
+  if test -s conftest.err; then
+    ac_cpp_err=$ac_c_preproc_warn_flag
+    ac_cpp_err=$ac_cpp_err$ac_c_werror_flag
+  else
+    ac_cpp_err=
+  fi
+else
+  ac_cpp_err=yes
+fi
+if test -z "$ac_cpp_err"; then
+  ac_header_preproc=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+  ac_header_preproc=no
+fi
+rm -f conftest.err conftest.$ac_ext
+echo "$as_me:$LINENO: result: $ac_header_preproc" >&5
+echo "${ECHO_T}$ac_header_preproc" >&6
+
+# So?  What about this header?
+case $ac_header_compiler:$ac_header_preproc:$ac_c_preproc_warn_flag in
+  yes:no: )
+    { echo "$as_me:$LINENO: WARNING: unistd.h: accepted by the compiler, rejected by the preprocessor!" >&5
+echo "$as_me: WARNING: unistd.h: accepted by the compiler, rejected by the preprocessor!" >&2;}
+    { echo "$as_me:$LINENO: WARNING: unistd.h: proceeding with the compiler's result" >&5
+echo "$as_me: WARNING: unistd.h: proceeding with the compiler's result" >&2;}
+    ac_header_preproc=yes
+    ;;
+  no:yes:* )
+    { echo "$as_me:$LINENO: WARNING: unistd.h: present but cannot be compiled" >&5
+echo "$as_me: WARNING: unistd.h: present but cannot be compiled" >&2;}
+    { echo "$as_me:$LINENO: WARNING: unistd.h:     check for missing prerequisite headers?" >&5
+echo "$as_me: WARNING: unistd.h:     check for missing prerequisite headers?" >&2;}
+    { echo "$as_me:$LINENO: WARNING: unistd.h: see the Autoconf documentation" >&5
+echo "$as_me: WARNING: unistd.h: see the Autoconf documentation" >&2;}
+    { echo "$as_me:$LINENO: WARNING: unistd.h:     section \"Present But Cannot Be Compiled\"" >&5
+echo "$as_me: WARNING: unistd.h:     section \"Present But Cannot Be Compiled\"" >&2;}
+    { echo "$as_me:$LINENO: WARNING: unistd.h: proceeding with the preprocessor's result" >&5
+echo "$as_me: WARNING: unistd.h: proceeding with the preprocessor's result" >&2;}
+    { echo "$as_me:$LINENO: WARNING: unistd.h: in the future, the compiler will take precedence" >&5
+echo "$as_me: WARNING: unistd.h: in the future, the compiler will take precedence" >&2;}
+    (
+      cat <<\_ASBOX
+## ------------------------------------------ ##
+## Report this to the AC_PACKAGE_NAME lists.  ##
+## ------------------------------------------ ##
+_ASBOX
+    ) |
+      sed "s/^/$as_me: WARNING:     /" >&2
+    ;;
+esac
+echo "$as_me:$LINENO: checking for unistd.h" >&5
+echo $ECHO_N "checking for unistd.h... $ECHO_C" >&6
+if test "${ac_cv_header_unistd_h+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  ac_cv_header_unistd_h=$ac_header_preproc
+fi
+echo "$as_me:$LINENO: result: $ac_cv_header_unistd_h" >&5
+echo "${ECHO_T}$ac_cv_header_unistd_h" >&6
+
+fi
+if test $ac_cv_header_unistd_h = yes; then
+  :
+else
+  { { echo "$as_me:$LINENO: error: \"Mandatory header missing on your system\"" >&5
+echo "$as_me: error: \"Mandatory header missing on your system\"" >&2;}
+   { (exit 1); exit 1; }; }
+fi
+
+
+
+
+echo "$as_me:$LINENO: checking if libnsl is mandatory" >&5
+echo $ECHO_N "checking if libnsl is mandatory... $ECHO_C" >&6
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include <sys/types.h>
+             #include <netinet/in.h>
+             #include <arpa/nameser.h>
+             #include <resolv.h>
+             union
+             {
+                HEADER hdr;
+                u_char buf[4096]; /* With RFC 2671, otherwise 512 is enough */
+             }
+             response;
+             char *domain;
+             int requested_type;
+int
+main ()
+{
+res_query(domain,
+		  C_IN,
+		  requested_type,
+		  (u_char *) & response,
+		  sizeof (response))
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  	echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+	echo "$as_me:$LINENO: result: yes" >&5
+echo "${ECHO_T}yes" >&6; LIBS="${LIBS} -lnsl"
+fi
+rm -f conftest.err conftest.$ac_objext \
+      conftest$ac_exeext conftest.$ac_ext
+
+echo "$as_me:$LINENO: checking loc_ntoa" >&5
+echo $ECHO_N "checking loc_ntoa... $ECHO_C" >&6
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include <resolv.h>
+int
+main ()
+{
+	u_char *cp; char *result; loc_ntoa(cp, result)
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  	echo "$as_me:$LINENO: result: yes" >&5
+echo "${ECHO_T}yes" >&6; cat >>confdefs.h <<\_ACEOF
+#define HAVE_LOC_NTOA 1
+_ACEOF
+
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+	echo "$as_me:$LINENO: result: no, using the alternative" >&5
+echo "${ECHO_T}no, using the alternative" >&6; LOC_NTOA=loc_ntoa.o
+fi
+rm -f conftest.err conftest.$ac_objext \
+      conftest$ac_exeext conftest.$ac_ext
+
+
+echo "$as_me:$LINENO: checking for an ANSI C-conforming const" >&5
+echo $ECHO_N "checking for an ANSI C-conforming const... $ECHO_C" >&6
+if test "${ac_cv_c_const+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+int
+main ()
+{
+/* FIXME: Include the comments suggested by Paul. */
+#ifndef __cplusplus
+  /* Ultrix mips cc rejects this.  */
+  typedef int charset[2];
+  const charset x;
+  /* SunOS 4.1.1 cc rejects this.  */
+  char const *const *ccp;
+  char **p;
+  /* NEC SVR4.0.2 mips cc rejects this.  */
+  struct point {int x, y;};
+  static struct point const zero = {0,0};
+  /* AIX XL C 1.02.0.0 rejects this.
+     It does not let you subtract one const X* pointer from another in
+     an arm of an if-expression whose if-part is not a constant
+     expression */
+  const char *g = "string";
+  ccp = &g + (g ? g-g : 0);
+  /* HPUX 7.0 cc rejects these. */
+  ++ccp;
+  p = (char**) ccp;
+  ccp = (char const *const *) p;
+  { /* SCO 3.2v4 cc rejects this.  */
+    char *t;
+    char const *s = 0 ? (char *) 0 : (char const *) 0;
+
+    *t++ = 0;
+  }
+  { /* Someone thinks the Sun supposedly-ANSI compiler will reject this.  */
+    int x[] = {25, 17};
+    const int *foo = &x[0];
+    ++foo;
+  }
+  { /* Sun SC1.0 ANSI compiler rejects this -- but not the above. */
+    typedef const int *iptr;
+    iptr p = 0;
+    ++p;
+  }
+  { /* AIX XL C 1.02.0.0 rejects this saying
+       "k.c", line 2.27: 1506-025 (S) Operand must be a modifiable lvalue. */
+    struct s { int j; const int *ap[3]; };
+    struct s *b; b->j = 5;
+  }
+  { /* ULTRIX-32 V3.1 (Rev 9) vcc rejects this */
+    const int foo = 10;
+  }
+#endif
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_c_const=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_cv_c_const=no
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+echo "$as_me:$LINENO: result: $ac_cv_c_const" >&5
+echo "${ECHO_T}$ac_cv_c_const" >&6
+if test $ac_cv_c_const = no; then
+
+cat >>confdefs.h <<\_ACEOF
+#define const
+_ACEOF
+
+fi
+
+echo "$as_me:$LINENO: checking for long" >&5
+echo $ECHO_N "checking for long... $ECHO_C" >&6
+if test "${ac_cv_type_long+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+if ((long *) 0)
+  return 0;
+if (sizeof (long))
+  return 0;
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_type_long=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_cv_type_long=no
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+echo "$as_me:$LINENO: result: $ac_cv_type_long" >&5
+echo "${ECHO_T}$ac_cv_type_long" >&6
+
+echo "$as_me:$LINENO: checking size of long" >&5
+echo $ECHO_N "checking size of long... $ECHO_C" >&6
+if test "${ac_cv_sizeof_long+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test "$ac_cv_type_long" = yes; then
+  # The cast to unsigned long works around a bug in the HP C Compiler
+  # version HP92453-01 B.11.11.23709.GP, which incorrectly rejects
+  # declarations like `int a3[[(sizeof (unsigned char)) >= 0]];'.
+  # This bug is HP SR number 8606223364.
+  if test "$cross_compiling" = yes; then
+  # Depending upon the size, compute the lo and hi bounds.
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (long))) >= 0)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_lo=0 ac_mid=0
+  while :; do
+    cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (long))) <= $ac_mid)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_hi=$ac_mid; break
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_lo=`expr $ac_mid + 1`
+		    if test $ac_lo -le $ac_mid; then
+		      ac_lo= ac_hi=
+		      break
+		    fi
+		    ac_mid=`expr 2 '*' $ac_mid + 1`
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+  done
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (long))) < 0)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_hi=-1 ac_mid=-1
+  while :; do
+    cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (long))) >= $ac_mid)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_lo=$ac_mid; break
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_hi=`expr '(' $ac_mid ')' - 1`
+		       if test $ac_mid -le $ac_hi; then
+			 ac_lo= ac_hi=
+			 break
+		       fi
+		       ac_mid=`expr 2 '*' $ac_mid`
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+  done
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_lo= ac_hi=
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+# Binary search between lo and hi bounds.
+while test "x$ac_lo" != "x$ac_hi"; do
+  ac_mid=`expr '(' $ac_hi - $ac_lo ')' / 2 + $ac_lo`
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (long))) <= $ac_mid)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_hi=$ac_mid
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_lo=`expr '(' $ac_mid ')' + 1`
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+done
+case $ac_lo in
+?*) ac_cv_sizeof_long=$ac_lo;;
+'') { { echo "$as_me:$LINENO: error: cannot compute sizeof (long), 77
+See \`config.log' for more details." >&5
+echo "$as_me: error: cannot compute sizeof (long), 77
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; } ;;
+esac
+else
+  if test "$cross_compiling" = yes; then
+  { { echo "$as_me:$LINENO: error: internal error: not reached in cross-compile" >&5
+echo "$as_me: error: internal error: not reached in cross-compile" >&2;}
+   { (exit 1); exit 1; }; }
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+long longval () { return (long) (sizeof (long)); }
+unsigned long ulongval () { return (long) (sizeof (long)); }
+#include <stdio.h>
+#include <stdlib.h>
+int
+main ()
+{
+
+  FILE *f = fopen ("conftest.val", "w");
+  if (! f)
+    exit (1);
+  if (((long) (sizeof (long))) < 0)
+    {
+      long i = longval ();
+      if (i != ((long) (sizeof (long))))
+	exit (1);
+      fprintf (f, "%ld\n", i);
+    }
+  else
+    {
+      unsigned long i = ulongval ();
+      if (i != ((long) (sizeof (long))))
+	exit (1);
+      fprintf (f, "%lu\n", i);
+    }
+  exit (ferror (f) || fclose (f) != 0);
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } && { ac_try='./conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_sizeof_long=`cat conftest.val`
+else
+  echo "$as_me: program exited with status $ac_status" >&5
+echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+( exit $ac_status )
+{ { echo "$as_me:$LINENO: error: cannot compute sizeof (long), 77
+See \`config.log' for more details." >&5
+echo "$as_me: error: cannot compute sizeof (long), 77
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; }
+fi
+rm -f core *.core gmon.out bb.out conftest$ac_exeext conftest.$ac_objext conftest.$ac_ext
+fi
+fi
+rm -f conftest.val
+else
+  ac_cv_sizeof_long=0
+fi
+fi
+echo "$as_me:$LINENO: result: $ac_cv_sizeof_long" >&5
+echo "${ECHO_T}$ac_cv_sizeof_long" >&6
+cat >>confdefs.h <<_ACEOF
+#define SIZEOF_LONG $ac_cv_sizeof_long
+_ACEOF
+
+
+echo "$as_me:$LINENO: checking for int" >&5
+echo $ECHO_N "checking for int... $ECHO_C" >&6
+if test "${ac_cv_type_int+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+if ((int *) 0)
+  return 0;
+if (sizeof (int))
+  return 0;
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_type_int=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_cv_type_int=no
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+echo "$as_me:$LINENO: result: $ac_cv_type_int" >&5
+echo "${ECHO_T}$ac_cv_type_int" >&6
+
+echo "$as_me:$LINENO: checking size of int" >&5
+echo $ECHO_N "checking size of int... $ECHO_C" >&6
+if test "${ac_cv_sizeof_int+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test "$ac_cv_type_int" = yes; then
+  # The cast to unsigned long works around a bug in the HP C Compiler
+  # version HP92453-01 B.11.11.23709.GP, which incorrectly rejects
+  # declarations like `int a3[[(sizeof (unsigned char)) >= 0]];'.
+  # This bug is HP SR number 8606223364.
+  if test "$cross_compiling" = yes; then
+  # Depending upon the size, compute the lo and hi bounds.
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (int))) >= 0)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_lo=0 ac_mid=0
+  while :; do
+    cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (int))) <= $ac_mid)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_hi=$ac_mid; break
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_lo=`expr $ac_mid + 1`
+		    if test $ac_lo -le $ac_mid; then
+		      ac_lo= ac_hi=
+		      break
+		    fi
+		    ac_mid=`expr 2 '*' $ac_mid + 1`
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+  done
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (int))) < 0)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_hi=-1 ac_mid=-1
+  while :; do
+    cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (int))) >= $ac_mid)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_lo=$ac_mid; break
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_hi=`expr '(' $ac_mid ')' - 1`
+		       if test $ac_mid -le $ac_hi; then
+			 ac_lo= ac_hi=
+			 break
+		       fi
+		       ac_mid=`expr 2 '*' $ac_mid`
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+  done
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_lo= ac_hi=
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+# Binary search between lo and hi bounds.
+while test "x$ac_lo" != "x$ac_hi"; do
+  ac_mid=`expr '(' $ac_hi - $ac_lo ')' / 2 + $ac_lo`
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (int))) <= $ac_mid)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_hi=$ac_mid
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_lo=`expr '(' $ac_mid ')' + 1`
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+done
+case $ac_lo in
+?*) ac_cv_sizeof_int=$ac_lo;;
+'') { { echo "$as_me:$LINENO: error: cannot compute sizeof (int), 77
+See \`config.log' for more details." >&5
+echo "$as_me: error: cannot compute sizeof (int), 77
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; } ;;
+esac
+else
+  if test "$cross_compiling" = yes; then
+  { { echo "$as_me:$LINENO: error: internal error: not reached in cross-compile" >&5
+echo "$as_me: error: internal error: not reached in cross-compile" >&2;}
+   { (exit 1); exit 1; }; }
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+long longval () { return (long) (sizeof (int)); }
+unsigned long ulongval () { return (long) (sizeof (int)); }
+#include <stdio.h>
+#include <stdlib.h>
+int
+main ()
+{
+
+  FILE *f = fopen ("conftest.val", "w");
+  if (! f)
+    exit (1);
+  if (((long) (sizeof (int))) < 0)
+    {
+      long i = longval ();
+      if (i != ((long) (sizeof (int))))
+	exit (1);
+      fprintf (f, "%ld\n", i);
+    }
+  else
+    {
+      unsigned long i = ulongval ();
+      if (i != ((long) (sizeof (int))))
+	exit (1);
+      fprintf (f, "%lu\n", i);
+    }
+  exit (ferror (f) || fclose (f) != 0);
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } && { ac_try='./conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_sizeof_int=`cat conftest.val`
+else
+  echo "$as_me: program exited with status $ac_status" >&5
+echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+( exit $ac_status )
+{ { echo "$as_me:$LINENO: error: cannot compute sizeof (int), 77
+See \`config.log' for more details." >&5
+echo "$as_me: error: cannot compute sizeof (int), 77
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; }
+fi
+rm -f core *.core gmon.out bb.out conftest$ac_exeext conftest.$ac_objext conftest.$ac_ext
+fi
+fi
+rm -f conftest.val
+else
+  ac_cv_sizeof_int=0
+fi
+fi
+echo "$as_me:$LINENO: result: $ac_cv_sizeof_int" >&5
+echo "${ECHO_T}$ac_cv_sizeof_int" >&6
+cat >>confdefs.h <<_ACEOF
+#define SIZEOF_INT $ac_cv_sizeof_int
+_ACEOF
+
+
+echo "$as_me:$LINENO: checking for short" >&5
+echo $ECHO_N "checking for short... $ECHO_C" >&6
+if test "${ac_cv_type_short+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+if ((short *) 0)
+  return 0;
+if (sizeof (short))
+  return 0;
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_type_short=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_cv_type_short=no
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+echo "$as_me:$LINENO: result: $ac_cv_type_short" >&5
+echo "${ECHO_T}$ac_cv_type_short" >&6
+
+echo "$as_me:$LINENO: checking size of short" >&5
+echo $ECHO_N "checking size of short... $ECHO_C" >&6
+if test "${ac_cv_sizeof_short+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test "$ac_cv_type_short" = yes; then
+  # The cast to unsigned long works around a bug in the HP C Compiler
+  # version HP92453-01 B.11.11.23709.GP, which incorrectly rejects
+  # declarations like `int a3[[(sizeof (unsigned char)) >= 0]];'.
+  # This bug is HP SR number 8606223364.
+  if test "$cross_compiling" = yes; then
+  # Depending upon the size, compute the lo and hi bounds.
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (short))) >= 0)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_lo=0 ac_mid=0
+  while :; do
+    cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (short))) <= $ac_mid)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_hi=$ac_mid; break
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_lo=`expr $ac_mid + 1`
+		    if test $ac_lo -le $ac_mid; then
+		      ac_lo= ac_hi=
+		      break
+		    fi
+		    ac_mid=`expr 2 '*' $ac_mid + 1`
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+  done
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (short))) < 0)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_hi=-1 ac_mid=-1
+  while :; do
+    cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (short))) >= $ac_mid)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_lo=$ac_mid; break
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_hi=`expr '(' $ac_mid ')' - 1`
+		       if test $ac_mid -le $ac_hi; then
+			 ac_lo= ac_hi=
+			 break
+		       fi
+		       ac_mid=`expr 2 '*' $ac_mid`
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+  done
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_lo= ac_hi=
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+# Binary search between lo and hi bounds.
+while test "x$ac_lo" != "x$ac_hi"; do
+  ac_mid=`expr '(' $ac_hi - $ac_lo ')' / 2 + $ac_lo`
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (short))) <= $ac_mid)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_hi=$ac_mid
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_lo=`expr '(' $ac_mid ')' + 1`
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+done
+case $ac_lo in
+?*) ac_cv_sizeof_short=$ac_lo;;
+'') { { echo "$as_me:$LINENO: error: cannot compute sizeof (short), 77
+See \`config.log' for more details." >&5
+echo "$as_me: error: cannot compute sizeof (short), 77
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; } ;;
+esac
+else
+  if test "$cross_compiling" = yes; then
+  { { echo "$as_me:$LINENO: error: internal error: not reached in cross-compile" >&5
+echo "$as_me: error: internal error: not reached in cross-compile" >&2;}
+   { (exit 1); exit 1; }; }
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+long longval () { return (long) (sizeof (short)); }
+unsigned long ulongval () { return (long) (sizeof (short)); }
+#include <stdio.h>
+#include <stdlib.h>
+int
+main ()
+{
+
+  FILE *f = fopen ("conftest.val", "w");
+  if (! f)
+    exit (1);
+  if (((long) (sizeof (short))) < 0)
+    {
+      long i = longval ();
+      if (i != ((long) (sizeof (short))))
+	exit (1);
+      fprintf (f, "%ld\n", i);
+    }
+  else
+    {
+      unsigned long i = ulongval ();
+      if (i != ((long) (sizeof (short))))
+	exit (1);
+      fprintf (f, "%lu\n", i);
+    }
+  exit (ferror (f) || fclose (f) != 0);
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } && { ac_try='./conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_sizeof_short=`cat conftest.val`
+else
+  echo "$as_me: program exited with status $ac_status" >&5
+echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+( exit $ac_status )
+{ { echo "$as_me:$LINENO: error: cannot compute sizeof (short), 77
+See \`config.log' for more details." >&5
+echo "$as_me: error: cannot compute sizeof (short), 77
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; }
+fi
+rm -f core *.core gmon.out bb.out conftest$ac_exeext conftest.$ac_objext conftest.$ac_ext
+fi
+fi
+rm -f conftest.val
+else
+  ac_cv_sizeof_short=0
+fi
+fi
+echo "$as_me:$LINENO: result: $ac_cv_sizeof_short" >&5
+echo "${ECHO_T}$ac_cv_sizeof_short" >&6
+cat >>confdefs.h <<_ACEOF
+#define SIZEOF_SHORT $ac_cv_sizeof_short
+_ACEOF
+
+
+echo "$as_me:$LINENO: checking for char" >&5
+echo $ECHO_N "checking for char... $ECHO_C" >&6
+if test "${ac_cv_type_char+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+if ((char *) 0)
+  return 0;
+if (sizeof (char))
+  return 0;
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_type_char=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_cv_type_char=no
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+echo "$as_me:$LINENO: result: $ac_cv_type_char" >&5
+echo "${ECHO_T}$ac_cv_type_char" >&6
+
+echo "$as_me:$LINENO: checking size of char" >&5
+echo $ECHO_N "checking size of char... $ECHO_C" >&6
+if test "${ac_cv_sizeof_char+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test "$ac_cv_type_char" = yes; then
+  # The cast to unsigned long works around a bug in the HP C Compiler
+  # version HP92453-01 B.11.11.23709.GP, which incorrectly rejects
+  # declarations like `int a3[[(sizeof (unsigned char)) >= 0]];'.
+  # This bug is HP SR number 8606223364.
+  if test "$cross_compiling" = yes; then
+  # Depending upon the size, compute the lo and hi bounds.
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (char))) >= 0)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_lo=0 ac_mid=0
+  while :; do
+    cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (char))) <= $ac_mid)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_hi=$ac_mid; break
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_lo=`expr $ac_mid + 1`
+		    if test $ac_lo -le $ac_mid; then
+		      ac_lo= ac_hi=
+		      break
+		    fi
+		    ac_mid=`expr 2 '*' $ac_mid + 1`
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+  done
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (char))) < 0)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_hi=-1 ac_mid=-1
+  while :; do
+    cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (char))) >= $ac_mid)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_lo=$ac_mid; break
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_hi=`expr '(' $ac_mid ')' - 1`
+		       if test $ac_mid -le $ac_hi; then
+			 ac_lo= ac_hi=
+			 break
+		       fi
+		       ac_mid=`expr 2 '*' $ac_mid`
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+  done
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_lo= ac_hi=
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+# Binary search between lo and hi bounds.
+while test "x$ac_lo" != "x$ac_hi"; do
+  ac_mid=`expr '(' $ac_hi - $ac_lo ')' / 2 + $ac_lo`
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+static int test_array [1 - 2 * !(((long) (sizeof (char))) <= $ac_mid)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_hi=$ac_mid
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_lo=`expr '(' $ac_mid ')' + 1`
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+done
+case $ac_lo in
+?*) ac_cv_sizeof_char=$ac_lo;;
+'') { { echo "$as_me:$LINENO: error: cannot compute sizeof (char), 77
+See \`config.log' for more details." >&5
+echo "$as_me: error: cannot compute sizeof (char), 77
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; } ;;
+esac
+else
+  if test "$cross_compiling" = yes; then
+  { { echo "$as_me:$LINENO: error: internal error: not reached in cross-compile" >&5
+echo "$as_me: error: internal error: not reached in cross-compile" >&2;}
+   { (exit 1); exit 1; }; }
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+long longval () { return (long) (sizeof (char)); }
+unsigned long ulongval () { return (long) (sizeof (char)); }
+#include <stdio.h>
+#include <stdlib.h>
+int
+main ()
+{
+
+  FILE *f = fopen ("conftest.val", "w");
+  if (! f)
+    exit (1);
+  if (((long) (sizeof (char))) < 0)
+    {
+      long i = longval ();
+      if (i != ((long) (sizeof (char))))
+	exit (1);
+      fprintf (f, "%ld\n", i);
+    }
+  else
+    {
+      unsigned long i = ulongval ();
+      if (i != ((long) (sizeof (char))))
+	exit (1);
+      fprintf (f, "%lu\n", i);
+    }
+  exit (ferror (f) || fclose (f) != 0);
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } && { ac_try='./conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_sizeof_char=`cat conftest.val`
+else
+  echo "$as_me: program exited with status $ac_status" >&5
+echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+( exit $ac_status )
+{ { echo "$as_me:$LINENO: error: cannot compute sizeof (char), 77
+See \`config.log' for more details." >&5
+echo "$as_me: error: cannot compute sizeof (char), 77
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; }
+fi
+rm -f core *.core gmon.out bb.out conftest$ac_exeext conftest.$ac_objext conftest.$ac_ext
+fi
+fi
+rm -f conftest.val
+else
+  ac_cv_sizeof_char=0
+fi
+fi
+echo "$as_me:$LINENO: result: $ac_cv_sizeof_char" >&5
+echo "${ECHO_T}$ac_cv_sizeof_char" >&6
+cat >>confdefs.h <<_ACEOF
+#define SIZEOF_CHAR $ac_cv_sizeof_char
+_ACEOF
+
+
+
+          ac_config_files="$ac_config_files Makefile"
+cat >confcache <<\_ACEOF
+# This file is a shell script that caches the results of configure
+# tests run on this system so they can be shared between configure
+# scripts and configure runs, see configure's option --config-cache.
+# It is not useful on other systems.  If it contains results you don't
+# want to keep, you may remove or edit it.
+#
+# config.status only pays attention to the cache file if you give it
+# the --recheck option to rerun configure.
+#
+# `ac_cv_env_foo' variables (set or unset) will be overridden when
+# loading this file, other *unset* `ac_cv_foo' will be assigned the
+# following values.
+
+_ACEOF
+
+# The following way of writing the cache mishandles newlines in values,
+# but we know of no workaround that is simple, portable, and efficient.
+# So, don't put newlines in cache variables' values.
+# Ultrix sh set writes to stderr and can't be redirected directly,
+# and sets the high bit in the cache file unless we assign to the vars.
+{
+  (set) 2>&1 |
+    case `(ac_space=' '; set | grep ac_space) 2>&1` in
+    *ac_space=\ *)
+      # `set' does not quote correctly, so add quotes (double-quote
+      # substitution turns \\\\ into \\, and sed turns \\ into \).
+      sed -n \
+	"s/'/'\\\\''/g;
+	  s/^\\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\\)=\\(.*\\)/\\1='\\2'/p"
+      ;;
+    *)
+      # `set' quotes correctly as required by POSIX, so do not add quotes.
+      sed -n \
+	"s/^\\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\\)=\\(.*\\)/\\1=\\2/p"
+      ;;
+    esac;
+} |
+  sed '
+     t clear
+     : clear
+     s/^\([^=]*\)=\(.*[{}].*\)$/test "${\1+set}" = set || &/
+     t end
+     /^ac_cv_env/!s/^\([^=]*\)=\(.*\)$/\1=${\1=\2}/
+     : end' >>confcache
+if diff $cache_file confcache >/dev/null 2>&1; then :; else
+  if test -w $cache_file; then
+    test "x$cache_file" != "x/dev/null" && echo "updating cache $cache_file"
+    cat confcache >$cache_file
+  else
+    echo "not updating unwritable cache $cache_file"
+  fi
+fi
+rm -f confcache
+
+test "x$prefix" = xNONE && prefix=$ac_default_prefix
+# Let make expand exec_prefix.
+test "x$exec_prefix" = xNONE && exec_prefix='${prefix}'
+
+# VPATH may cause trouble with some makes, so we remove $(srcdir),
+# ${srcdir} and @srcdir@ from VPATH if srcdir is ".", strip leading and
+# trailing colons and then remove the whole line if VPATH becomes empty
+# (actually we leave an empty line to preserve line numbers).
+if test "x$srcdir" = x.; then
+  ac_vpsub='/^[	 ]*VPATH[	 ]*=/{
+s/:*\$(srcdir):*/:/;
+s/:*\${srcdir}:*/:/;
+s/:*@srcdir@:*/:/;
+s/^\([^=]*=[	 ]*\):*/\1/;
+s/:*$//;
+s/^[^=]*=[	 ]*$//;
+}'
+fi
+
+DEFS=-DHAVE_CONFIG_H
+
+ac_libobjs=
+ac_ltlibobjs=
+for ac_i in : $LIBOBJS; do test "x$ac_i" = x: && continue
+  # 1. Remove the extension, and $U if already installed.
+  ac_i=`echo "$ac_i" |
+	 sed 's/\$U\././;s/\.o$//;s/\.obj$//'`
+  # 2. Add them.
+  ac_libobjs="$ac_libobjs $ac_i\$U.$ac_objext"
+  ac_ltlibobjs="$ac_ltlibobjs $ac_i"'$U.lo'
+done
+LIBOBJS=$ac_libobjs
+
+LTLIBOBJS=$ac_ltlibobjs
+
+
+
+: ${CONFIG_STATUS=./config.status}
+ac_clean_files_save=$ac_clean_files
+ac_clean_files="$ac_clean_files $CONFIG_STATUS"
+{ echo "$as_me:$LINENO: creating $CONFIG_STATUS" >&5
+echo "$as_me: creating $CONFIG_STATUS" >&6;}
+cat >$CONFIG_STATUS <<_ACEOF
+#! $SHELL
+# Generated by $as_me.
+# Run this file to recreate the current configuration.
+# Compiler output produced by configure, useful for debugging
+# configure, is in config.log if it exists.
+
+debug=false
+ac_cs_recheck=false
+ac_cs_silent=false
+SHELL=\${CONFIG_SHELL-$SHELL}
+_ACEOF
+
+cat >>$CONFIG_STATUS <<\_ACEOF
+## --------------------- ##
+## M4sh Initialization.  ##
+## --------------------- ##
+
+# Be Bourne compatible
+if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
+  emulate sh
+  NULLCMD=:
+  # Zsh 3.x and 4.x performs word splitting on ${1+"$@"}, which
+  # is contrary to our usage.  Disable this feature.
+  alias -g '${1+"$@"}'='"$@"'
+elif test -n "${BASH_VERSION+set}" && (set -o posix) >/dev/null 2>&1; then
+  set -o posix
+fi
+DUALCASE=1; export DUALCASE # for MKS sh
+
+# Support unset when possible.
+if ( (MAIL=60; unset MAIL) || exit) >/dev/null 2>&1; then
+  as_unset=unset
+else
+  as_unset=false
+fi
+
+
+# Work around bugs in pre-3.0 UWIN ksh.
+$as_unset ENV MAIL MAILPATH
+PS1='$ '
+PS2='> '
+PS4='+ '
+
+# NLS nuisances.
+for as_var in \
+  LANG LANGUAGE LC_ADDRESS LC_ALL LC_COLLATE LC_CTYPE LC_IDENTIFICATION \
+  LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER \
+  LC_TELEPHONE LC_TIME
+do
+  if (set +x; test -z "`(eval $as_var=C; export $as_var) 2>&1`"); then
+    eval $as_var=C; export $as_var
+  else
+    $as_unset $as_var
+  fi
+done
+
+# Required to use basename.
+if expr a : '\(a\)' >/dev/null 2>&1; then
+  as_expr=expr
+else
+  as_expr=false
+fi
+
+if (basename /) >/dev/null 2>&1 && test "X`basename / 2>&1`" = "X/"; then
+  as_basename=basename
+else
+  as_basename=false
+fi
+
+
+# Name of the executable.
+as_me=`$as_basename "$0" ||
+$as_expr X/"$0" : '.*/\([^/][^/]*\)/*$' \| \
+	 X"$0" : 'X\(//\)$' \| \
+	 X"$0" : 'X\(/\)$' \| \
+	 .     : '\(.\)' 2>/dev/null ||
+echo X/"$0" |
+    sed '/^.*\/\([^/][^/]*\)\/*$/{ s//\1/; q; }
+  	  /^X\/\(\/\/\)$/{ s//\1/; q; }
+  	  /^X\/\(\/\).*/{ s//\1/; q; }
+  	  s/.*/./; q'`
+
+
+# PATH needs CR, and LINENO needs CR and PATH.
+# Avoid depending upon Character Ranges.
+as_cr_letters='abcdefghijklmnopqrstuvwxyz'
+as_cr_LETTERS='ABCDEFGHIJKLMNOPQRSTUVWXYZ'
+as_cr_Letters=$as_cr_letters$as_cr_LETTERS
+as_cr_digits='0123456789'
+as_cr_alnum=$as_cr_Letters$as_cr_digits
+
+# The user is always right.
+if test "${PATH_SEPARATOR+set}" != set; then
+  echo "#! /bin/sh" >conf$$.sh
+  echo  "exit 0"   >>conf$$.sh
+  chmod +x conf$$.sh
+  if (PATH="/nonexistent;."; conf$$.sh) >/dev/null 2>&1; then
+    PATH_SEPARATOR=';'
+  else
+    PATH_SEPARATOR=:
+  fi
+  rm -f conf$$.sh
+fi
+
+
+  as_lineno_1=$LINENO
+  as_lineno_2=$LINENO
+  as_lineno_3=`(expr $as_lineno_1 + 1) 2>/dev/null`
+  test "x$as_lineno_1" != "x$as_lineno_2" &&
+  test "x$as_lineno_3"  = "x$as_lineno_2"  || {
+  # Find who we are.  Look in the path if we contain no path at all
+  # relative or not.
+  case $0 in
+    *[\\/]* ) as_myself=$0 ;;
+    *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  test -r "$as_dir/$0" && as_myself=$as_dir/$0 && break
+done
+
+       ;;
+  esac
+  # We did not find ourselves, most probably we were run as `sh COMMAND'
+  # in which case we are not to be found in the path.
+  if test "x$as_myself" = x; then
+    as_myself=$0
+  fi
+  if test ! -f "$as_myself"; then
+    { { echo "$as_me:$LINENO: error: cannot find myself; rerun with an absolute path" >&5
+echo "$as_me: error: cannot find myself; rerun with an absolute path" >&2;}
+   { (exit 1); exit 1; }; }
+  fi
+  case $CONFIG_SHELL in
+  '')
+    as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in /bin$PATH_SEPARATOR/usr/bin$PATH_SEPARATOR$PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for as_base in sh bash ksh sh5; do
+	 case $as_dir in
+	 /*)
+	   if ("$as_dir/$as_base" -c '
+  as_lineno_1=$LINENO
+  as_lineno_2=$LINENO
+  as_lineno_3=`(expr $as_lineno_1 + 1) 2>/dev/null`
+  test "x$as_lineno_1" != "x$as_lineno_2" &&
+  test "x$as_lineno_3"  = "x$as_lineno_2" ') 2>/dev/null; then
+	     $as_unset BASH_ENV || test "${BASH_ENV+set}" != set || { BASH_ENV=; export BASH_ENV; }
+	     $as_unset ENV || test "${ENV+set}" != set || { ENV=; export ENV; }
+	     CONFIG_SHELL=$as_dir/$as_base
+	     export CONFIG_SHELL
+	     exec "$CONFIG_SHELL" "$0" ${1+"$@"}
+	   fi;;
+	 esac
+       done
+done
+;;
+  esac
+
+  # Create $as_me.lineno as a copy of $as_myself, but with $LINENO
+  # uniformly replaced by the line number.  The first 'sed' inserts a
+  # line-number line before each line; the second 'sed' does the real
+  # work.  The second script uses 'N' to pair each line-number line
+  # with the numbered line, and appends trailing '-' during
+  # substitution so that $LINENO is not a special case at line end.
+  # (Raja R Harinath suggested sed '=', and Paul Eggert wrote the
+  # second 'sed' script.  Blame Lee E. McMahon for sed's syntax.  :-)
+  sed '=' <$as_myself |
+    sed '
+      N
+      s,$,-,
+      : loop
+      s,^\(['$as_cr_digits']*\)\(.*\)[$]LINENO\([^'$as_cr_alnum'_]\),\1\2\1\3,
+      t loop
+      s,-$,,
+      s,^['$as_cr_digits']*\n,,
+    ' >$as_me.lineno &&
+  chmod +x $as_me.lineno ||
+    { { echo "$as_me:$LINENO: error: cannot create $as_me.lineno; rerun with a POSIX shell" >&5
+echo "$as_me: error: cannot create $as_me.lineno; rerun with a POSIX shell" >&2;}
+   { (exit 1); exit 1; }; }
+
+  # Don't try to exec as it changes $[0], causing all sort of problems
+  # (the dirname of $[0] is not the place where we might find the
+  # original and so on.  Autoconf is especially sensible to this).
+  . ./$as_me.lineno
+  # Exit status is that of the last command.
+  exit
+}
+
+
+case `echo "testing\c"; echo 1,2,3`,`echo -n testing; echo 1,2,3` in
+  *c*,-n*) ECHO_N= ECHO_C='
+' ECHO_T='	' ;;
+  *c*,*  ) ECHO_N=-n ECHO_C= ECHO_T= ;;
+  *)       ECHO_N= ECHO_C='\c' ECHO_T= ;;
+esac
+
+if expr a : '\(a\)' >/dev/null 2>&1; then
+  as_expr=expr
+else
+  as_expr=false
+fi
+
+rm -f conf$$ conf$$.exe conf$$.file
+echo >conf$$.file
+if ln -s conf$$.file conf$$ 2>/dev/null; then
+  # We could just check for DJGPP; but this test a) works b) is more generic
+  # and c) will remain valid once DJGPP supports symlinks (DJGPP 2.04).
+  if test -f conf$$.exe; then
+    # Don't use ln at all; we don't have any links
+    as_ln_s='cp -p'
+  else
+    as_ln_s='ln -s'
+  fi
+elif ln conf$$.file conf$$ 2>/dev/null; then
+  as_ln_s=ln
+else
+  as_ln_s='cp -p'
+fi
+rm -f conf$$ conf$$.exe conf$$.file
+
+if mkdir -p . 2>/dev/null; then
+  as_mkdir_p=:
+else
+  test -d ./-p && rmdir ./-p
+  as_mkdir_p=false
+fi
+
+as_executable_p="test -f"
+
+# Sed expression to map a string onto a valid CPP name.
+as_tr_cpp="eval sed 'y%*$as_cr_letters%P$as_cr_LETTERS%;s%[^_$as_cr_alnum]%_%g'"
+
+# Sed expression to map a string onto a valid variable name.
+as_tr_sh="eval sed 'y%*+%pp%;s%[^_$as_cr_alnum]%_%g'"
+
+
+# IFS
+# We need space, tab and new line, in precisely that order.
+as_nl='
+'
+IFS=" 	$as_nl"
+
+# CDPATH.
+$as_unset CDPATH
+
+exec 6>&1
+
+# Open the log real soon, to keep \$[0] and so on meaningful, and to
+# report actual input values of CONFIG_FILES etc. instead of their
+# values after options handling.  Logging --version etc. is OK.
+exec 5>>config.log
+{
+  echo
+  sed 'h;s/./-/g;s/^.../## /;s/...$/ ##/;p;x;p;x' <<_ASBOX
+## Running $as_me. ##
+_ASBOX
+} >&5
+cat >&5 <<_CSEOF
+
+This file was extended by $as_me, which was
+generated by GNU Autoconf 2.59.  Invocation command line was
+
+  CONFIG_FILES    = $CONFIG_FILES
+  CONFIG_HEADERS  = $CONFIG_HEADERS
+  CONFIG_LINKS    = $CONFIG_LINKS
+  CONFIG_COMMANDS = $CONFIG_COMMANDS
+  $ $0 $@
+
+_CSEOF
+echo "on `(hostname || uname -n) 2>/dev/null | sed 1q`" >&5
+echo >&5
+_ACEOF
+
+# Files that config.status was made for.
+if test -n "$ac_config_files"; then
+  echo "config_files=\"$ac_config_files\"" >>$CONFIG_STATUS
+fi
+
+if test -n "$ac_config_headers"; then
+  echo "config_headers=\"$ac_config_headers\"" >>$CONFIG_STATUS
+fi
+
+if test -n "$ac_config_links"; then
+  echo "config_links=\"$ac_config_links\"" >>$CONFIG_STATUS
+fi
+
+if test -n "$ac_config_commands"; then
+  echo "config_commands=\"$ac_config_commands\"" >>$CONFIG_STATUS
+fi
+
+cat >>$CONFIG_STATUS <<\_ACEOF
+
+ac_cs_usage="\
+\`$as_me' instantiates files from templates according to the
+current configuration.
+
+Usage: $0 [OPTIONS] [FILE]...
+
+  -h, --help       print this help, then exit
+  -V, --version    print version number, then exit
+  -q, --quiet      do not print progress messages
+  -d, --debug      don't remove temporary files
+      --recheck    update $as_me by reconfiguring in the same conditions
+  --file=FILE[:TEMPLATE]
+		   instantiate the configuration file FILE
+  --header=FILE[:TEMPLATE]
+		   instantiate the configuration header FILE
+
+Configuration files:
+$config_files
+
+Configuration headers:
+$config_headers
+
+Report bugs to <bug-autoconf@gnu.org>."
+_ACEOF
+
+cat >>$CONFIG_STATUS <<_ACEOF
+ac_cs_version="\\
+config.status
+configured by $0, generated by GNU Autoconf 2.59,
+  with options \\"`echo "$ac_configure_args" | sed 's/[\\""\`\$]/\\\\&/g'`\\"
+
+Copyright (C) 2003 Free Software Foundation, Inc.
+This config.status script is free software; the Free Software Foundation
+gives unlimited permission to copy, distribute and modify it."
+srcdir=$srcdir
+INSTALL="$INSTALL"
+_ACEOF
+
+cat >>$CONFIG_STATUS <<\_ACEOF
+# If no file are specified by the user, then we need to provide default
+# value.  By we need to know if files were specified by the user.
+ac_need_defaults=:
+while test $# != 0
+do
+  case $1 in
+  --*=*)
+    ac_option=`expr "x$1" : 'x\([^=]*\)='`
+    ac_optarg=`expr "x$1" : 'x[^=]*=\(.*\)'`
+    ac_shift=:
+    ;;
+  -*)
+    ac_option=$1
+    ac_optarg=$2
+    ac_shift=shift
+    ;;
+  *) # This is not an option, so the user has probably given explicit
+     # arguments.
+     ac_option=$1
+     ac_need_defaults=false;;
+  esac
+
+  case $ac_option in
+  # Handling of the options.
+_ACEOF
+cat >>$CONFIG_STATUS <<\_ACEOF
+  -recheck | --recheck | --rechec | --reche | --rech | --rec | --re | --r)
+    ac_cs_recheck=: ;;
+  --version | --vers* | -V )
+    echo "$ac_cs_version"; exit 0 ;;
+  --he | --h)
+    # Conflict between --help and --header
+    { { echo "$as_me:$LINENO: error: ambiguous option: $1
+Try \`$0 --help' for more information." >&5
+echo "$as_me: error: ambiguous option: $1
+Try \`$0 --help' for more information." >&2;}
+   { (exit 1); exit 1; }; };;
+  --help | --hel | -h )
+    echo "$ac_cs_usage"; exit 0 ;;
+  --debug | --d* | -d )
+    debug=: ;;
+  --file | --fil | --fi | --f )
+    $ac_shift
+    CONFIG_FILES="$CONFIG_FILES $ac_optarg"
+    ac_need_defaults=false;;
+  --header | --heade | --head | --hea )
+    $ac_shift
+    CONFIG_HEADERS="$CONFIG_HEADERS $ac_optarg"
+    ac_need_defaults=false;;
+  -q | -quiet | --quiet | --quie | --qui | --qu | --q \
+  | -silent | --silent | --silen | --sile | --sil | --si | --s)
+    ac_cs_silent=: ;;
+
+  # This is an error.
+  -*) { { echo "$as_me:$LINENO: error: unrecognized option: $1
+Try \`$0 --help' for more information." >&5
+echo "$as_me: error: unrecognized option: $1
+Try \`$0 --help' for more information." >&2;}
+   { (exit 1); exit 1; }; } ;;
+
+  *) ac_config_targets="$ac_config_targets $1" ;;
+
+  esac
+  shift
+done
+
+ac_configure_extra_args=
+
+if $ac_cs_silent; then
+  exec 6>/dev/null
+  ac_configure_extra_args="$ac_configure_extra_args --silent"
+fi
+
+_ACEOF
+cat >>$CONFIG_STATUS <<_ACEOF
+if \$ac_cs_recheck; then
+  echo "running $SHELL $0 " $ac_configure_args \$ac_configure_extra_args " --no-create --no-recursion" >&6
+  exec $SHELL $0 $ac_configure_args \$ac_configure_extra_args --no-create --no-recursion
+fi
+
+_ACEOF
+
+
+
+
+
+cat >>$CONFIG_STATUS <<\_ACEOF
+for ac_config_target in $ac_config_targets
+do
+  case "$ac_config_target" in
+  # Handling of arguments.
+  "Makefile" ) CONFIG_FILES="$CONFIG_FILES Makefile" ;;
+  "config.h" ) CONFIG_HEADERS="$CONFIG_HEADERS config.h" ;;
+  *) { { echo "$as_me:$LINENO: error: invalid argument: $ac_config_target" >&5
+echo "$as_me: error: invalid argument: $ac_config_target" >&2;}
+   { (exit 1); exit 1; }; };;
+  esac
+done
+
+# If the user did not use the arguments to specify the items to instantiate,
+# then the envvar interface is used.  Set only those that are not.
+# We use the long form for the default assignment because of an extremely
+# bizarre bug on SunOS 4.1.3.
+if $ac_need_defaults; then
+  test "${CONFIG_FILES+set}" = set || CONFIG_FILES=$config_files
+  test "${CONFIG_HEADERS+set}" = set || CONFIG_HEADERS=$config_headers
+fi
+
+# Have a temporary directory for convenience.  Make it in the build tree
+# simply because there is no reason to put it here, and in addition,
+# creating and moving files from /tmp can sometimes cause problems.
+# Create a temporary directory, and hook for its removal unless debugging.
+$debug ||
+{
+  trap 'exit_status=$?; rm -rf $tmp && exit $exit_status' 0
+  trap '{ (exit 1); exit 1; }' 1 2 13 15
+}
+
+# Create a (secure) tmp directory for tmp files.
+
+{
+  tmp=`(umask 077 && mktemp -d -q "./confstatXXXXXX") 2>/dev/null` &&
+  test -n "$tmp" && test -d "$tmp"
+}  ||
+{
+  tmp=./confstat$$-$RANDOM
+  (umask 077 && mkdir $tmp)
+} ||
+{
+   echo "$me: cannot create a temporary directory in ." >&2
+   { (exit 1); exit 1; }
+}
+
+_ACEOF
+
+cat >>$CONFIG_STATUS <<_ACEOF
+
+#
+# CONFIG_FILES section.
+#
+
+# No need to generate the scripts if there are no CONFIG_FILES.
+# This happens for instance when ./config.status config.h
+if test -n "\$CONFIG_FILES"; then
+  # Protect against being on the right side of a sed subst in config.status.
+  sed 's/,@/@@/; s/@,/@@/; s/,;t t\$/@;t t/; /@;t t\$/s/[\\\\&,]/\\\\&/g;
+   s/@@/,@/; s/@@/@,/; s/@;t t\$/,;t t/' >\$tmp/subs.sed <<\\CEOF
+s,@SHELL@,$SHELL,;t t
+s,@PATH_SEPARATOR@,$PATH_SEPARATOR,;t t
+s,@PACKAGE_NAME@,$PACKAGE_NAME,;t t
+s,@PACKAGE_TARNAME@,$PACKAGE_TARNAME,;t t
+s,@PACKAGE_VERSION@,$PACKAGE_VERSION,;t t
+s,@PACKAGE_STRING@,$PACKAGE_STRING,;t t
+s,@PACKAGE_BUGREPORT@,$PACKAGE_BUGREPORT,;t t
+s,@exec_prefix@,$exec_prefix,;t t
+s,@prefix@,$prefix,;t t
+s,@program_transform_name@,$program_transform_name,;t t
+s,@bindir@,$bindir,;t t
+s,@sbindir@,$sbindir,;t t
+s,@libexecdir@,$libexecdir,;t t
+s,@datadir@,$datadir,;t t
+s,@sysconfdir@,$sysconfdir,;t t
+s,@sharedstatedir@,$sharedstatedir,;t t
+s,@localstatedir@,$localstatedir,;t t
+s,@libdir@,$libdir,;t t
+s,@includedir@,$includedir,;t t
+s,@oldincludedir@,$oldincludedir,;t t
+s,@infodir@,$infodir,;t t
+s,@mandir@,$mandir,;t t
+s,@build_alias@,$build_alias,;t t
+s,@host_alias@,$host_alias,;t t
+s,@target_alias@,$target_alias,;t t
+s,@DEFS@,$DEFS,;t t
+s,@ECHO_C@,$ECHO_C,;t t
+s,@ECHO_N@,$ECHO_N,;t t
+s,@ECHO_T@,$ECHO_T,;t t
+s,@LIBS@,$LIBS,;t t
+s,@CC@,$CC,;t t
+s,@CFLAGS@,$CFLAGS,;t t
+s,@LDFLAGS@,$LDFLAGS,;t t
+s,@CPPFLAGS@,$CPPFLAGS,;t t
+s,@ac_ct_CC@,$ac_ct_CC,;t t
+s,@EXEEXT@,$EXEEXT,;t t
+s,@OBJEXT@,$OBJEXT,;t t
+s,@INSTALL_PROGRAM@,$INSTALL_PROGRAM,;t t
+s,@INSTALL_SCRIPT@,$INSTALL_SCRIPT,;t t
+s,@INSTALL_DATA@,$INSTALL_DATA,;t t
+s,@CPP@,$CPP,;t t
+s,@EGREP@,$EGREP,;t t
+s,@LOC_NTOA@,$LOC_NTOA,;t t
+s,@LIBOBJS@,$LIBOBJS,;t t
+s,@LTLIBOBJS@,$LTLIBOBJS,;t t
+CEOF
+
+_ACEOF
+
+  cat >>$CONFIG_STATUS <<\_ACEOF
+  # Split the substitutions into bite-sized pieces for seds with
+  # small command number limits, like on Digital OSF/1 and HP-UX.
+  ac_max_sed_lines=48
+  ac_sed_frag=1 # Number of current file.
+  ac_beg=1 # First line for current file.
+  ac_end=$ac_max_sed_lines # Line after last line for current file.
+  ac_more_lines=:
+  ac_sed_cmds=
+  while $ac_more_lines; do
+    if test $ac_beg -gt 1; then
+      sed "1,${ac_beg}d; ${ac_end}q" $tmp/subs.sed >$tmp/subs.frag
+    else
+      sed "${ac_end}q" $tmp/subs.sed >$tmp/subs.frag
+    fi
+    if test ! -s $tmp/subs.frag; then
+      ac_more_lines=false
+    else
+      # The purpose of the label and of the branching condition is to
+      # speed up the sed processing (if there are no `@' at all, there
+      # is no need to browse any of the substitutions).
+      # These are the two extra sed commands mentioned above.
+      (echo ':t
+  /@[a-zA-Z_][a-zA-Z_0-9]*@/!b' && cat $tmp/subs.frag) >$tmp/subs-$ac_sed_frag.sed
+      if test -z "$ac_sed_cmds"; then
+	ac_sed_cmds="sed -f $tmp/subs-$ac_sed_frag.sed"
+      else
+	ac_sed_cmds="$ac_sed_cmds | sed -f $tmp/subs-$ac_sed_frag.sed"
+      fi
+      ac_sed_frag=`expr $ac_sed_frag + 1`
+      ac_beg=$ac_end
+      ac_end=`expr $ac_end + $ac_max_sed_lines`
+    fi
+  done
+  if test -z "$ac_sed_cmds"; then
+    ac_sed_cmds=cat
+  fi
+fi # test -n "$CONFIG_FILES"
+
+_ACEOF
+cat >>$CONFIG_STATUS <<\_ACEOF
+for ac_file in : $CONFIG_FILES; do test "x$ac_file" = x: && continue
+  # Support "outfile[:infile[:infile...]]", defaulting infile="outfile.in".
+  case $ac_file in
+  - | *:- | *:-:* ) # input from stdin
+	cat >$tmp/stdin
+	ac_file_in=`echo "$ac_file" | sed 's,[^:]*:,,'`
+	ac_file=`echo "$ac_file" | sed 's,:.*,,'` ;;
+  *:* ) ac_file_in=`echo "$ac_file" | sed 's,[^:]*:,,'`
+	ac_file=`echo "$ac_file" | sed 's,:.*,,'` ;;
+  * )   ac_file_in=$ac_file.in ;;
+  esac
+
+  # Compute @srcdir@, @top_srcdir@, and @INSTALL@ for subdirectories.
+  ac_dir=`(dirname "$ac_file") 2>/dev/null ||
+$as_expr X"$ac_file" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
+	 X"$ac_file" : 'X\(//\)[^/]' \| \
+	 X"$ac_file" : 'X\(//\)$' \| \
+	 X"$ac_file" : 'X\(/\)' \| \
+	 .     : '\(.\)' 2>/dev/null ||
+echo X"$ac_file" |
+    sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{ s//\1/; q; }
+  	  /^X\(\/\/\)[^/].*/{ s//\1/; q; }
+  	  /^X\(\/\/\)$/{ s//\1/; q; }
+  	  /^X\(\/\).*/{ s//\1/; q; }
+  	  s/.*/./; q'`
+  { if $as_mkdir_p; then
+    mkdir -p "$ac_dir"
+  else
+    as_dir="$ac_dir"
+    as_dirs=
+    while test ! -d "$as_dir"; do
+      as_dirs="$as_dir $as_dirs"
+      as_dir=`(dirname "$as_dir") 2>/dev/null ||
+$as_expr X"$as_dir" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
+	 X"$as_dir" : 'X\(//\)[^/]' \| \
+	 X"$as_dir" : 'X\(//\)$' \| \
+	 X"$as_dir" : 'X\(/\)' \| \
+	 .     : '\(.\)' 2>/dev/null ||
+echo X"$as_dir" |
+    sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{ s//\1/; q; }
+  	  /^X\(\/\/\)[^/].*/{ s//\1/; q; }
+  	  /^X\(\/\/\)$/{ s//\1/; q; }
+  	  /^X\(\/\).*/{ s//\1/; q; }
+  	  s/.*/./; q'`
+    done
+    test ! -n "$as_dirs" || mkdir $as_dirs
+  fi || { { echo "$as_me:$LINENO: error: cannot create directory \"$ac_dir\"" >&5
+echo "$as_me: error: cannot create directory \"$ac_dir\"" >&2;}
+   { (exit 1); exit 1; }; }; }
+
+  ac_builddir=.
+
+if test "$ac_dir" != .; then
+  ac_dir_suffix=/`echo "$ac_dir" | sed 's,^\.[\\/],,'`
+  # A "../" for each directory in $ac_dir_suffix.
+  ac_top_builddir=`echo "$ac_dir_suffix" | sed 's,/[^\\/]*,../,g'`
+else
+  ac_dir_suffix= ac_top_builddir=
+fi
+
+case $srcdir in
+  .)  # No --srcdir option.  We are building in place.
+    ac_srcdir=.
+    if test -z "$ac_top_builddir"; then
+       ac_top_srcdir=.
+    else
+       ac_top_srcdir=`echo $ac_top_builddir | sed 's,/$,,'`
+    fi ;;
+  [\\/]* | ?:[\\/]* )  # Absolute path.
+    ac_srcdir=$srcdir$ac_dir_suffix;
+    ac_top_srcdir=$srcdir ;;
+  *) # Relative path.
+    ac_srcdir=$ac_top_builddir$srcdir$ac_dir_suffix
+    ac_top_srcdir=$ac_top_builddir$srcdir ;;
+esac
+
+# Do not use `cd foo && pwd` to compute absolute paths, because
+# the directories may not exist.
+case `pwd` in
+.) ac_abs_builddir="$ac_dir";;
+*)
+  case "$ac_dir" in
+  .) ac_abs_builddir=`pwd`;;
+  [\\/]* | ?:[\\/]* ) ac_abs_builddir="$ac_dir";;
+  *) ac_abs_builddir=`pwd`/"$ac_dir";;
+  esac;;
+esac
+case $ac_abs_builddir in
+.) ac_abs_top_builddir=${ac_top_builddir}.;;
+*)
+  case ${ac_top_builddir}. in
+  .) ac_abs_top_builddir=$ac_abs_builddir;;
+  [\\/]* | ?:[\\/]* ) ac_abs_top_builddir=${ac_top_builddir}.;;
+  *) ac_abs_top_builddir=$ac_abs_builddir/${ac_top_builddir}.;;
+  esac;;
+esac
+case $ac_abs_builddir in
+.) ac_abs_srcdir=$ac_srcdir;;
+*)
+  case $ac_srcdir in
+  .) ac_abs_srcdir=$ac_abs_builddir;;
+  [\\/]* | ?:[\\/]* ) ac_abs_srcdir=$ac_srcdir;;
+  *) ac_abs_srcdir=$ac_abs_builddir/$ac_srcdir;;
+  esac;;
+esac
+case $ac_abs_builddir in
+.) ac_abs_top_srcdir=$ac_top_srcdir;;
+*)
+  case $ac_top_srcdir in
+  .) ac_abs_top_srcdir=$ac_abs_builddir;;
+  [\\/]* | ?:[\\/]* ) ac_abs_top_srcdir=$ac_top_srcdir;;
+  *) ac_abs_top_srcdir=$ac_abs_builddir/$ac_top_srcdir;;
+  esac;;
+esac
+
+
+  case $INSTALL in
+  [\\/$]* | ?:[\\/]* ) ac_INSTALL=$INSTALL ;;
+  *) ac_INSTALL=$ac_top_builddir$INSTALL ;;
+  esac
+
+  # Let's still pretend it is `configure' which instantiates (i.e., don't
+  # use $as_me), people would be surprised to read:
+  #    /* config.h.  Generated by config.status.  */
+  if test x"$ac_file" = x-; then
+    configure_input=
+  else
+    configure_input="$ac_file.  "
+  fi
+  configure_input=$configure_input"Generated from `echo $ac_file_in |
+				     sed 's,.*/,,'` by configure."
+
+  # First look for the input files in the build tree, otherwise in the
+  # src tree.
+  ac_file_inputs=`IFS=:
+    for f in $ac_file_in; do
+      case $f in
+      -) echo $tmp/stdin ;;
+      [\\/$]*)
+	 # Absolute (can't be DOS-style, as IFS=:)
+	 test -f "$f" || { { echo "$as_me:$LINENO: error: cannot find input file: $f" >&5
+echo "$as_me: error: cannot find input file: $f" >&2;}
+   { (exit 1); exit 1; }; }
+	 echo "$f";;
+      *) # Relative
+	 if test -f "$f"; then
+	   # Build tree
+	   echo "$f"
+	 elif test -f "$srcdir/$f"; then
+	   # Source tree
+	   echo "$srcdir/$f"
+	 else
+	   # /dev/null tree
+	   { { echo "$as_me:$LINENO: error: cannot find input file: $f" >&5
+echo "$as_me: error: cannot find input file: $f" >&2;}
+   { (exit 1); exit 1; }; }
+	 fi;;
+      esac
+    done` || { (exit 1); exit 1; }
+
+  if test x"$ac_file" != x-; then
+    { echo "$as_me:$LINENO: creating $ac_file" >&5
+echo "$as_me: creating $ac_file" >&6;}
+    rm -f "$ac_file"
+  fi
+_ACEOF
+cat >>$CONFIG_STATUS <<_ACEOF
+  sed "$ac_vpsub
+$extrasub
+_ACEOF
+cat >>$CONFIG_STATUS <<\_ACEOF
+:t
+/@[a-zA-Z_][a-zA-Z_0-9]*@/!b
+s,@configure_input@,$configure_input,;t t
+s,@srcdir@,$ac_srcdir,;t t
+s,@abs_srcdir@,$ac_abs_srcdir,;t t
+s,@top_srcdir@,$ac_top_srcdir,;t t
+s,@abs_top_srcdir@,$ac_abs_top_srcdir,;t t
+s,@builddir@,$ac_builddir,;t t
+s,@abs_builddir@,$ac_abs_builddir,;t t
+s,@top_builddir@,$ac_top_builddir,;t t
+s,@abs_top_builddir@,$ac_abs_top_builddir,;t t
+s,@INSTALL@,$ac_INSTALL,;t t
+" $ac_file_inputs | (eval "$ac_sed_cmds") >$tmp/out
+  rm -f $tmp/stdin
+  if test x"$ac_file" != x-; then
+    mv $tmp/out $ac_file
+  else
+    cat $tmp/out
+    rm -f $tmp/out
+  fi
+
+done
+_ACEOF
+cat >>$CONFIG_STATUS <<\_ACEOF
+
+#
+# CONFIG_HEADER section.
+#
+
+# These sed commands are passed to sed as "A NAME B NAME C VALUE D", where
+# NAME is the cpp macro being defined and VALUE is the value it is being given.
+#
+# ac_d sets the value in "#define NAME VALUE" lines.
+ac_dA='s,^\([	 ]*\)#\([	 ]*define[	 ][	 ]*\)'
+ac_dB='[	 ].*$,\1#\2'
+ac_dC=' '
+ac_dD=',;t'
+# ac_u turns "#undef NAME" without trailing blanks into "#define NAME VALUE".
+ac_uA='s,^\([	 ]*\)#\([	 ]*\)undef\([	 ][	 ]*\)'
+ac_uB='$,\1#\2define\3'
+ac_uC=' '
+ac_uD=',;t'
+
+for ac_file in : $CONFIG_HEADERS; do test "x$ac_file" = x: && continue
+  # Support "outfile[:infile[:infile...]]", defaulting infile="outfile.in".
+  case $ac_file in
+  - | *:- | *:-:* ) # input from stdin
+	cat >$tmp/stdin
+	ac_file_in=`echo "$ac_file" | sed 's,[^:]*:,,'`
+	ac_file=`echo "$ac_file" | sed 's,:.*,,'` ;;
+  *:* ) ac_file_in=`echo "$ac_file" | sed 's,[^:]*:,,'`
+	ac_file=`echo "$ac_file" | sed 's,:.*,,'` ;;
+  * )   ac_file_in=$ac_file.in ;;
+  esac
+
+  test x"$ac_file" != x- && { echo "$as_me:$LINENO: creating $ac_file" >&5
+echo "$as_me: creating $ac_file" >&6;}
+
+  # First look for the input files in the build tree, otherwise in the
+  # src tree.
+  ac_file_inputs=`IFS=:
+    for f in $ac_file_in; do
+      case $f in
+      -) echo $tmp/stdin ;;
+      [\\/$]*)
+	 # Absolute (can't be DOS-style, as IFS=:)
+	 test -f "$f" || { { echo "$as_me:$LINENO: error: cannot find input file: $f" >&5
+echo "$as_me: error: cannot find input file: $f" >&2;}
+   { (exit 1); exit 1; }; }
+	 # Do quote $f, to prevent DOS paths from being IFS'd.
+	 echo "$f";;
+      *) # Relative
+	 if test -f "$f"; then
+	   # Build tree
+	   echo "$f"
+	 elif test -f "$srcdir/$f"; then
+	   # Source tree
+	   echo "$srcdir/$f"
+	 else
+	   # /dev/null tree
+	   { { echo "$as_me:$LINENO: error: cannot find input file: $f" >&5
+echo "$as_me: error: cannot find input file: $f" >&2;}
+   { (exit 1); exit 1; }; }
+	 fi;;
+      esac
+    done` || { (exit 1); exit 1; }
+  # Remove the trailing spaces.
+  sed 's/[	 ]*$//' $ac_file_inputs >$tmp/in
+
+_ACEOF
+
+# Transform confdefs.h into two sed scripts, `conftest.defines' and
+# `conftest.undefs', that substitutes the proper values into
+# config.h.in to produce config.h.  The first handles `#define'
+# templates, and the second `#undef' templates.
+# And first: Protect against being on the right side of a sed subst in
+# config.status.  Protect against being in an unquoted here document
+# in config.status.
+rm -f conftest.defines conftest.undefs
+# Using a here document instead of a string reduces the quoting nightmare.
+# Putting comments in sed scripts is not portable.
+#
+# `end' is used to avoid that the second main sed command (meant for
+# 0-ary CPP macros) applies to n-ary macro definitions.
+# See the Autoconf documentation for `clear'.
+cat >confdef2sed.sed <<\_ACEOF
+s/[\\&,]/\\&/g
+s,[\\$`],\\&,g
+t clear
+: clear
+s,^[	 ]*#[	 ]*define[	 ][	 ]*\([^	 (][^	 (]*\)\(([^)]*)\)[	 ]*\(.*\)$,${ac_dA}\1${ac_dB}\1\2${ac_dC}\3${ac_dD},gp
+t end
+s,^[	 ]*#[	 ]*define[	 ][	 ]*\([^	 ][^	 ]*\)[	 ]*\(.*\)$,${ac_dA}\1${ac_dB}\1${ac_dC}\2${ac_dD},gp
+: end
+_ACEOF
+# If some macros were called several times there might be several times
+# the same #defines, which is useless.  Nevertheless, we may not want to
+# sort them, since we want the *last* AC-DEFINE to be honored.
+uniq confdefs.h | sed -n -f confdef2sed.sed >conftest.defines
+sed 's/ac_d/ac_u/g' conftest.defines >conftest.undefs
+rm -f confdef2sed.sed
+
+# This sed command replaces #undef with comments.  This is necessary, for
+# example, in the case of _POSIX_SOURCE, which is predefined and required
+# on some systems where configure will not decide to define it.
+cat >>conftest.undefs <<\_ACEOF
+s,^[	 ]*#[	 ]*undef[	 ][	 ]*[a-zA-Z_][a-zA-Z_0-9]*,/* & */,
+_ACEOF
+
+# Break up conftest.defines because some shells have a limit on the size
+# of here documents, and old seds have small limits too (100 cmds).
+echo '  # Handle all the #define templates only if necessary.' >>$CONFIG_STATUS
+echo '  if grep "^[	 ]*#[	 ]*define" $tmp/in >/dev/null; then' >>$CONFIG_STATUS
+echo '  # If there are no defines, we may have an empty if/fi' >>$CONFIG_STATUS
+echo '  :' >>$CONFIG_STATUS
+rm -f conftest.tail
+while grep . conftest.defines >/dev/null
+do
+  # Write a limited-size here document to $tmp/defines.sed.
+  echo '  cat >$tmp/defines.sed <<CEOF' >>$CONFIG_STATUS
+  # Speed up: don't consider the non `#define' lines.
+  echo '/^[	 ]*#[	 ]*define/!b' >>$CONFIG_STATUS
+  # Work around the forget-to-reset-the-flag bug.
+  echo 't clr' >>$CONFIG_STATUS
+  echo ': clr' >>$CONFIG_STATUS
+  sed ${ac_max_here_lines}q conftest.defines >>$CONFIG_STATUS
+  echo 'CEOF
+  sed -f $tmp/defines.sed $tmp/in >$tmp/out
+  rm -f $tmp/in
+  mv $tmp/out $tmp/in
+' >>$CONFIG_STATUS
+  sed 1,${ac_max_here_lines}d conftest.defines >conftest.tail
+  rm -f conftest.defines
+  mv conftest.tail conftest.defines
+done
+rm -f conftest.defines
+echo '  fi # grep' >>$CONFIG_STATUS
+echo >>$CONFIG_STATUS
+
+# Break up conftest.undefs because some shells have a limit on the size
+# of here documents, and old seds have small limits too (100 cmds).
+echo '  # Handle all the #undef templates' >>$CONFIG_STATUS
+rm -f conftest.tail
+while grep . conftest.undefs >/dev/null
+do
+  # Write a limited-size here document to $tmp/undefs.sed.
+  echo '  cat >$tmp/undefs.sed <<CEOF' >>$CONFIG_STATUS
+  # Speed up: don't consider the non `#undef'
+  echo '/^[	 ]*#[	 ]*undef/!b' >>$CONFIG_STATUS
+  # Work around the forget-to-reset-the-flag bug.
+  echo 't clr' >>$CONFIG_STATUS
+  echo ': clr' >>$CONFIG_STATUS
+  sed ${ac_max_here_lines}q conftest.undefs >>$CONFIG_STATUS
+  echo 'CEOF
+  sed -f $tmp/undefs.sed $tmp/in >$tmp/out
+  rm -f $tmp/in
+  mv $tmp/out $tmp/in
+' >>$CONFIG_STATUS
+  sed 1,${ac_max_here_lines}d conftest.undefs >conftest.tail
+  rm -f conftest.undefs
+  mv conftest.tail conftest.undefs
+done
+rm -f conftest.undefs
+
+cat >>$CONFIG_STATUS <<\_ACEOF
+  # Let's still pretend it is `configure' which instantiates (i.e., don't
+  # use $as_me), people would be surprised to read:
+  #    /* config.h.  Generated by config.status.  */
+  if test x"$ac_file" = x-; then
+    echo "/* Generated by configure.  */" >$tmp/config.h
+  else
+    echo "/* $ac_file.  Generated by configure.  */" >$tmp/config.h
+  fi
+  cat $tmp/in >>$tmp/config.h
+  rm -f $tmp/in
+  if test x"$ac_file" != x-; then
+    if diff $ac_file $tmp/config.h >/dev/null 2>&1; then
+      { echo "$as_me:$LINENO: $ac_file is unchanged" >&5
+echo "$as_me: $ac_file is unchanged" >&6;}
+    else
+      ac_dir=`(dirname "$ac_file") 2>/dev/null ||
+$as_expr X"$ac_file" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
+	 X"$ac_file" : 'X\(//\)[^/]' \| \
+	 X"$ac_file" : 'X\(//\)$' \| \
+	 X"$ac_file" : 'X\(/\)' \| \
+	 .     : '\(.\)' 2>/dev/null ||
+echo X"$ac_file" |
+    sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{ s//\1/; q; }
+  	  /^X\(\/\/\)[^/].*/{ s//\1/; q; }
+  	  /^X\(\/\/\)$/{ s//\1/; q; }
+  	  /^X\(\/\).*/{ s//\1/; q; }
+  	  s/.*/./; q'`
+      { if $as_mkdir_p; then
+    mkdir -p "$ac_dir"
+  else
+    as_dir="$ac_dir"
+    as_dirs=
+    while test ! -d "$as_dir"; do
+      as_dirs="$as_dir $as_dirs"
+      as_dir=`(dirname "$as_dir") 2>/dev/null ||
+$as_expr X"$as_dir" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
+	 X"$as_dir" : 'X\(//\)[^/]' \| \
+	 X"$as_dir" : 'X\(//\)$' \| \
+	 X"$as_dir" : 'X\(/\)' \| \
+	 .     : '\(.\)' 2>/dev/null ||
+echo X"$as_dir" |
+    sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{ s//\1/; q; }
+  	  /^X\(\/\/\)[^/].*/{ s//\1/; q; }
+  	  /^X\(\/\/\)$/{ s//\1/; q; }
+  	  /^X\(\/\).*/{ s//\1/; q; }
+  	  s/.*/./; q'`
+    done
+    test ! -n "$as_dirs" || mkdir $as_dirs
+  fi || { { echo "$as_me:$LINENO: error: cannot create directory \"$ac_dir\"" >&5
+echo "$as_me: error: cannot create directory \"$ac_dir\"" >&2;}
+   { (exit 1); exit 1; }; }; }
+
+      rm -f $ac_file
+      mv $tmp/config.h $ac_file
+    fi
+  else
+    cat $tmp/config.h
+    rm -f $tmp/config.h
+  fi
+done
+_ACEOF
+
+cat >>$CONFIG_STATUS <<\_ACEOF
+
+{ (exit 0); exit 0; }
+_ACEOF
+chmod +x $CONFIG_STATUS
+ac_clean_files=$ac_clean_files_save
+
+
+# configure is writing to config.log, and then calls config.status.
+# config.status does its own redirection, appending to config.log.
+# Unfortunately, on DOS this fails, as config.log is still kept open
+# by configure, so config.status won't be able to write to it; its
+# output is simply discarded.  So we exec the FD to /dev/null,
+# effectively closing config.log, so it can be properly (re)opened and
+# appended to by config.status.  When coming back to configure, we
+# need to make the FD available again.
+if test "$no_create" != yes; then
+  ac_cs_success=:
+  ac_config_status_args=
+  test "$silent" = yes &&
+    ac_config_status_args="$ac_config_status_args --quiet"
+  exec 5>/dev/null
+  $SHELL $CONFIG_STATUS $ac_config_status_args || ac_cs_success=false
+  exec 5>>config.log
+  # Use ||, not &&, to avoid exiting from the if with $? = 1, which
+  # would make configure fail if this is the last instruction.
+  $ac_cs_success || { (exit 1); exit 1; }
+fi
+
+
+
+
diff --git a/contrib/query-loc-0.3.0/configure.in b/contrib/query-loc-0.3.0/configure.in
new file mode 100644
index 0000000000..f25a6a2544
--- /dev/null
+++ b/contrib/query-loc-0.3.0/configure.in
@@ -0,0 +1,65 @@
+dnl Process this file with autoconf to produce a configure script.
+AC_RELEASE("$Id: configure.in,v 1.1 2005/04/01 05:35:00 marka Exp $")
+AC_INIT(query-loc.c)
+
+dnl Checks for programs.
+AC_PROG_CC
+if test "$GCC" = "yes"; then
+	CFLAGS="${CFLAGS} -Wall"
+fi
+AC_PROG_INSTALL
+
+dnl Checks for libraries.
+AC_CHECK_LIB(resolv, res_query)
+
+dnl Checks for header files.
+AC_HEADER_STDC
+AC_CONFIG_HEADER(config.h)
+AC_CHECK_HEADER(resolv.h, , AC_MSG_ERROR("No headers for name service applications"))
+AC_CHECK_HEADER(arpa/nameser.h, , AC_MSG_ERROR("No headers for name service applications"))
+AC_CHECK_HEADER(sys/time.h, , AC_MSG_ERROR("Mandatory header missing on your system"))
+AC_CHECK_HEADER(unistd.h, , AC_MSG_ERROR("Mandatory header missing on your system"))
+
+
+dnl This one is only useful for Solaris?
+AC_MSG_CHECKING(if libnsl is mandatory)
+AC_TRY_LINK([#include <sys/types.h>
+             #include <netinet/in.h>
+             #include <arpa/nameser.h>
+             #include <resolv.h>
+             union
+             {
+                HEADER hdr;	
+                u_char buf[4096]; /* With RFC 2671, otherwise 512 is enough */
+             }
+             response;
+             char *domain;
+             int requested_type;	], 
+	[res_query(domain,
+		  C_IN,		
+		  requested_type,	
+		  (u_char *) & response,	
+		  sizeof (response)) ], dnl
+	[AC_MSG_RESULT(no)], dnl
+	[AC_MSG_RESULT(yes); LIBS="${LIBS} -lnsl"]) 
+
+dnl Check for the loc_ntoa macro/function
+AC_MSG_CHECKING(loc_ntoa)
+AC_TRY_LINK([#include <resolv.h>], dnl
+	[u_char *cp; char *result; loc_ntoa(cp, result)], dnl
+	[AC_MSG_RESULT(yes); AC_DEFINE(HAVE_LOC_NTOA)], dnl
+	[AC_MSG_RESULT([no, using the alternative]); LOC_NTOA=loc_ntoa.o]) 
+AC_SUBST(LOC_NTOA)
+
+dnl Checks for typedefs, structures, and compiler characteristics.
+AC_C_CONST
+AC_CHECK_SIZEOF(long)
+AC_CHECK_SIZEOF(int)
+AC_CHECK_SIZEOF(short)
+AC_CHECK_SIZEOF(char)
+
+dnl Misc.
+AC_OUTPUT(Makefile)
+
+
+
diff --git a/contrib/query-loc-0.3.0/install-sh b/contrib/query-loc-0.3.0/install-sh
new file mode 100755
index 0000000000..e9de23842d
--- /dev/null
+++ b/contrib/query-loc-0.3.0/install-sh
@@ -0,0 +1,251 @@
+#!/bin/sh
+#
+# install - install a program, script, or datafile
+# This comes from X11R5 (mit/util/scripts/install.sh).
+#
+# Copyright 1991 by the Massachusetts Institute of Technology
+#
+# Permission to use, copy, modify, distribute, and sell this software and its
+# documentation for any purpose is hereby granted without fee, provided that
+# the above copyright notice appear in all copies and that both that
+# copyright notice and this permission notice appear in supporting
+# documentation, and that the name of M.I.T. not be used in advertising or
+# publicity pertaining to distribution of the software without specific,
+# written prior permission.  M.I.T. makes no representations about the
+# suitability of this software for any purpose.  It is provided "as is"
+# without express or implied warranty.
+#
+# Calling this script install-sh is preferred over install.sh, to prevent
+# `make' implicit rules from creating a file called install from it
+# when there is no Makefile.
+#
+# This script is compatible with the BSD install script, but was written
+# from scratch.  It can only install one file at a time, a restriction
+# shared with many OS's install programs.
+
+
+# set DOITPROG to echo to test this script
+
+# Don't use :- since 4.3BSD and earlier shells don't like it.
+doit="${DOITPROG-}"
+
+
+# put in absolute paths if you don't have them in your path; or use env. vars.
+
+mvprog="${MVPROG-mv}"
+cpprog="${CPPROG-cp}"
+chmodprog="${CHMODPROG-chmod}"
+chownprog="${CHOWNPROG-chown}"
+chgrpprog="${CHGRPPROG-chgrp}"
+stripprog="${STRIPPROG-strip}"
+rmprog="${RMPROG-rm}"
+mkdirprog="${MKDIRPROG-mkdir}"
+
+transformbasename=""
+transform_arg=""
+instcmd="$mvprog"
+chmodcmd="$chmodprog 0755"
+chowncmd=""
+chgrpcmd=""
+stripcmd=""
+rmcmd="$rmprog -f"
+mvcmd="$mvprog"
+src=""
+dst=""
+dir_arg=""
+
+while [ x"$1" != x ]; do
+    case $1 in
+	-c) instcmd="$cpprog"
+	    shift
+	    continue;;
+
+	-d) dir_arg=true
+	    shift
+	    continue;;
+
+	-m) chmodcmd="$chmodprog $2"
+	    shift
+	    shift
+	    continue;;
+
+	-o) chowncmd="$chownprog $2"
+	    shift
+	    shift
+	    continue;;
+
+	-g) chgrpcmd="$chgrpprog $2"
+	    shift
+	    shift
+	    continue;;
+
+	-s) stripcmd="$stripprog"
+	    shift
+	    continue;;
+
+	-t=*) transformarg=`echo $1 | sed 's/-t=//'`
+	    shift
+	    continue;;
+
+	-b=*) transformbasename=`echo $1 | sed 's/-b=//'`
+	    shift
+	    continue;;
+
+	*)  if [ x"$src" = x ]
+	    then
+		src=$1
+	    else
+		# this colon is to work around a 386BSD /bin/sh bug
+		:
+		dst=$1
+	    fi
+	    shift
+	    continue;;
+    esac
+done
+
+if [ x"$src" = x ]
+then
+	echo "install:	no input file specified"
+	exit 1
+else
+	true
+fi
+
+if [ x"$dir_arg" != x ]; then
+	dst=$src
+	src=""
+	
+	if [ -d $dst ]; then
+		instcmd=:
+		chmodcmd=""
+	else
+		instcmd=mkdir
+	fi
+else
+
+# Waiting for this to be detected by the "$instcmd $src $dsttmp" command
+# might cause directories to be created, which would be especially bad 
+# if $src (and thus $dsttmp) contains '*'.
+
+	if [ -f $src -o -d $src ]
+	then
+		true
+	else
+		echo "install:  $src does not exist"
+		exit 1
+	fi
+	
+	if [ x"$dst" = x ]
+	then
+		echo "install:	no destination specified"
+		exit 1
+	else
+		true
+	fi
+
+# If destination is a directory, append the input filename; if your system
+# does not like double slashes in filenames, you may need to add some logic
+
+	if [ -d $dst ]
+	then
+		dst="$dst"/`basename $src`
+	else
+		true
+	fi
+fi
+
+## this sed command emulates the dirname command
+dstdir=`echo $dst | sed -e 's,[^/]*$,,;s,/$,,;s,^$,.,'`
+
+# Make sure that the destination directory exists.
+#  this part is taken from Noah Friedman's mkinstalldirs script
+
+# Skip lots of stat calls in the usual case.
+if [ ! -d "$dstdir" ]; then
+defaultIFS='	
+'
+IFS="${IFS-${defaultIFS}}"
+
+oIFS="${IFS}"
+# Some sh's can't handle IFS=/ for some reason.
+IFS='%'
+set - `echo ${dstdir} | sed -e 's@/@%@g' -e 's@^%@/@'`
+IFS="${oIFS}"
+
+pathcomp=''
+
+while [ $# -ne 0 ] ; do
+	pathcomp="${pathcomp}${1}"
+	shift
+
+	if [ ! -d "${pathcomp}" ] ;
+        then
+		$mkdirprog "${pathcomp}"
+	else
+		true
+	fi
+
+	pathcomp="${pathcomp}/"
+done
+fi
+
+if [ x"$dir_arg" != x ]
+then
+	$doit $instcmd $dst &&
+
+	if [ x"$chowncmd" != x ]; then $doit $chowncmd $dst; else true ; fi &&
+	if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dst; else true ; fi &&
+	if [ x"$stripcmd" != x ]; then $doit $stripcmd $dst; else true ; fi &&
+	if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dst; else true ; fi
+else
+
+# If we're going to rename the final executable, determine the name now.
+
+	if [ x"$transformarg" = x ] 
+	then
+		dstfile=`basename $dst`
+	else
+		dstfile=`basename $dst $transformbasename | 
+			sed $transformarg`$transformbasename
+	fi
+
+# don't allow the sed command to completely eliminate the filename
+
+	if [ x"$dstfile" = x ] 
+	then
+		dstfile=`basename $dst`
+	else
+		true
+	fi
+
+# Make a temp file name in the proper directory.
+
+	dsttmp=$dstdir/#inst.$$#
+
+# Move or copy the file name to the temp name
+
+	$doit $instcmd $src $dsttmp &&
+
+	trap "rm -f ${dsttmp}" 0 &&
+
+# and set any options; do chmod last to preserve setuid bits
+
+# If any of these fail, we abort the whole thing.  If we want to
+# ignore errors from any of these, just make sure not to ignore
+# errors from the above "$doit $instcmd $src $dsttmp" command.
+
+	if [ x"$chowncmd" != x ]; then $doit $chowncmd $dsttmp; else true;fi &&
+	if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dsttmp; else true;fi &&
+	if [ x"$stripcmd" != x ]; then $doit $stripcmd $dsttmp; else true;fi &&
+	if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dsttmp; else true;fi &&
+
+# Now rename the file to the real destination.
+
+	$doit $rmcmd -f $dstdir/$dstfile &&
+	$doit $mvcmd $dsttmp $dstdir/$dstfile 
+
+fi &&
+
+
+exit 0
diff --git a/contrib/query-loc-0.3.0/loc.c b/contrib/query-loc-0.3.0/loc.c
new file mode 100644
index 0000000000..502ed11bad
--- /dev/null
+++ b/contrib/query-loc-0.3.0/loc.c
@@ -0,0 +1,566 @@
+#include "loc.h"
+
+/* $Id: loc.c,v 1.1 2005/04/01 05:35:00 marka Exp $ */
+
+/* Global variables */
+
+short rr_errno;
+
+/*
+   Prints the actual usage
+ */
+void
+usage ()
+{
+  (void) fprintf (stderr,
+		  "Usage: %s: [-v] [-d nnn] hostname\n", progname);
+  exit (2);
+}
+
+/*
+   Panics
+ */
+void
+panic (message)
+     char *message;
+{
+  (void) fprintf (stderr,
+		  "%s: %s\n", progname, message);
+  exit (2);
+}
+
+/*
+   ** IN_ADDR_ARPA -- Convert dotted quad string to reverse in-addr.arpa
+   ** ------------------------------------------------------------------
+   **
+   **   Returns:
+   **           Pointer to appropriate reverse in-addr.arpa name
+   **           with trailing dot to force absolute domain name.
+   **           NULL in case of invalid dotted quad input string.
+ */
+
+#ifndef ARPA_ROOT
+#define ARPA_ROOT "in-addr.arpa"
+#endif
+
+char *
+in_addr_arpa (dottedquad)
+     char *dottedquad;		/* input string with dotted quad */
+{
+  static char addrbuf[4 * 4 + sizeof (ARPA_ROOT) + 2];
+  unsigned int a[4];
+  register int n;
+
+  n = sscanf (dottedquad, "%u.%u.%u.%u", &a[0], &a[1], &a[2], &a[3]);
+  switch (n)
+    {
+    case 4:
+      (void) sprintf (addrbuf, "%u.%u.%u.%u.%s.",
+	     a[3] & 0xff, a[2] & 0xff, a[1] & 0xff, a[0] & 0xff, ARPA_ROOT);
+      break;
+
+    case 3:
+      (void) sprintf (addrbuf, "%u.%u.%u.%s.",
+		      a[2] & 0xff, a[1] & 0xff, a[0] & 0xff, ARPA_ROOT);
+      break;
+
+    case 2:
+      (void) sprintf (addrbuf, "%u.%u.%s.",
+		      a[1] & 0xff, a[0] & 0xff, ARPA_ROOT);
+      break;
+
+    case 1:
+      (void) sprintf (addrbuf, "%u.%s.",
+		      a[0] & 0xff, ARPA_ROOT);
+      break;
+
+    default:
+      return (NULL);
+    }
+
+  while (--n >= 0)
+    if (a[n] > 255)
+      return (NULL);
+
+  return (addrbuf);
+}
+
+/* 
+   Returns a human-readable version of the LOC information or
+   NULL if it failed. Argument is a name (of a network or a machine)
+   and a boolean telling is it is a network name or a machine name.
+ */
+char *
+getlocbyname (name, is_network)
+     const char *name;
+     short is_network;
+{
+  char *result;
+  struct list_in_addr *list, *p;
+  result = findRR (name, T_LOC);
+  if (result != NULL)
+    {
+      if (debug >= 2)
+	printf ("LOC record found for the name %s\n", name);
+      return result;
+    }
+  else
+    {
+      if (!is_network)
+	{
+	  list = findA (name);
+	  if (debug >= 2)
+	    printf ("No LOC record found for the name %s, trying addresses\n", name);
+	  if (list != NULL)
+	    {
+	      for (p = list; p != NULL; p = p->next)
+		{
+		  if (debug >= 2)
+		    printf ("Trying address %s\n", inet_ntoa (p->addr));
+		  result = getlocbyaddr (p->addr, NULL);
+		  if (result != NULL)
+		    return result;
+		}
+	      return NULL;
+	    }
+	  else
+	    {
+	      if (debug >= 2)
+		printf ("   No A record found for %s\n", name);
+	      return NULL;
+	    }
+	}
+      else
+	{
+	  if (debug >= 2)
+	    printf ("No LOC record found for the network name %s\n", name);
+	  return NULL;
+	}
+    }
+}
+
+/* 
+   Returns a human-readable version of the LOC information or
+   NULL if it failed. Argument is an IP address.
+ */
+char *
+getlocbyaddr (addr, mask)
+     const struct in_addr addr;
+     const struct in_addr *mask;
+{
+  struct in_addr netaddr;
+  u_int32_t a;
+  struct in_addr themask;
+  char *text_addr, *text_mask;
+
+  if (mask == NULL)
+    {
+      themask.s_addr = (u_int32_t) 0;
+    }
+  else
+    {
+      themask = *mask;
+    }
+
+  text_addr = (char *) malloc (256);
+  text_mask = (char *) malloc (256);
+  strcpy (text_addr, inet_ntoa (addr));
+  strcpy (text_mask, inet_ntoa (themask));
+
+  if (debug >= 2)
+    printf ("Testing address %s/%s\n", text_addr, text_mask);
+  if (mask == NULL)
+    {
+      a = ntohl (addr.s_addr);
+      if (IN_CLASSA (a))
+	{
+	  netaddr.s_addr = htonl (a & IN_CLASSA_NET);
+	}
+      else if (IN_CLASSB (a))
+	{
+	  netaddr.s_addr = htonl (a & IN_CLASSB_NET);
+	}
+      else if (IN_CLASSC (a))
+	{
+	  netaddr.s_addr = htonl (a & IN_CLASSC_NET);
+	}
+      else
+	{
+	  /* Error */
+	}
+      return getlocbynet (in_addr_arpa (inet_ntoa (netaddr)), addr, mask);
+    }
+  else
+    {
+      netaddr.s_addr = addr.s_addr & themask.s_addr;
+      return getlocbynet (in_addr_arpa (inet_ntoa (netaddr)), addr, mask);
+    }
+}
+
+/* 
+   Returns a human-readable LOC.
+   Argument is a network name in the 0.z.y.x.in-addr.arpa format
+   and the original address
+ */
+char *
+getlocbynet (name, addr, mask)
+     char *name;
+     struct in_addr addr;
+     struct in_addr *mask;
+{
+  char *network;
+  char *result, *result_int;
+  struct list_in_addr *list;
+  if (debug >= 2)
+    printf ("Testing network %s\n", name);
+  network = findRR (name, T_PTR);
+  if (network == NULL)
+    {
+      if (debug >= 2)
+	printf ("No name for network %s\n", name);
+      return NULL;
+    }
+  else
+    {
+      result = getlocbyname (network, TRUE);
+      list = findA (network);
+      if (list == NULL)
+	{
+	  return result;
+	}
+      else if ((mask != NULL) &&
+	       ((mask->s_addr) == (list->addr.s_addr)))
+	{
+	  /* Already checked */
+	  return result;
+	}
+      else
+	{
+	  result_int = getlocbyaddr (addr, &list->addr);
+	  if (result_int == NULL)
+	    return result;
+	  else
+	    return result_int;
+	}
+    }
+}
+
+/* 
+   The code for these two functions is stolen from the examples in Liu and Albitz
+   book "DNS and BIND" (O'Reilly).
+ */
+
+/****************************************************************
+ * skipName -- This routine skips over a domain name.  If the   *
+ *     domain name expansion fails, it crashes.                 *
+ *     dn_skipname() is probably not on your manual             *
+ *     page; it is similar to dn_expand() except that it just   *
+ *     skips over the name.  dn_skipname() is in res_comp.c if  *
+ *     you need to find it.                                     *
+ ****************************************************************/
+int
+skipName (cp, endOfMsg)
+     u_char *cp;
+     u_char *endOfMsg;
+{
+  int n;
+
+  if ((n = dn_skipname (cp, endOfMsg)) < 0)
+    {
+      panic ("dn_skipname failed\n");
+    }
+  return (n);
+}
+
+/****************************************************************
+ * skipToData -- This routine advances the cp pointer to the    *
+ *     start of the resource record data portion.  On the way,  *
+ *     it fills in the type, class, ttl, and data length        *
+ ****************************************************************/
+int
+skipToData (cp, type, class, ttl, dlen, endOfMsg)
+     u_char *cp;
+     u_short *type;
+     u_short *class;
+     u_int32_t *ttl;
+     u_short *dlen;
+     u_char *endOfMsg;
+{
+  u_char *tmp_cp = cp;		/* temporary version of cp */
+
+  /* Skip the domain name; it matches the name we looked up */
+  tmp_cp += skipName (tmp_cp, endOfMsg);
+
+  /*
+   * Grab the type, class, and ttl.  GETSHORT and GETLONG
+   * are macros defined in arpa/nameser.h.
+   */
+  GETSHORT (*type, tmp_cp);
+  GETSHORT (*class, tmp_cp);
+  GETLONG (*ttl, tmp_cp);
+  GETSHORT (*dlen, tmp_cp);
+
+  return (tmp_cp - cp);
+}
+
+
+/* 
+   Returns a human-readable version of a DNS RR (resource record)
+   associated with the name 'domain'.
+   If it does not find, ir returns NULL and sets rr_errno to explain why.
+
+   The code for this function is stolen from the examples in Liu and Albitz
+   book "DNS and BIND" (O'Reilly).
+ */
+char *
+findRR (domain, requested_type)
+     char *domain;
+     int requested_type;
+{
+  char *result, *message;
+
+  union
+    {
+      HEADER hdr;		/* defined in resolv.h */
+      u_char buf[PACKETSZ];	/* defined in arpa/nameser.h */
+    }
+  response;			/* response buffers */
+short found = 0;  
+int responseLen;		/* buffer length */
+
+  u_char *cp;			/* character pointer to parse DNS packet */
+  u_char *endOfMsg;		/* need to know the end of the message */
+  u_short class;		/* classes defined in arpa/nameser.h */
+  u_short type;			/* types defined in arpa/nameser.h */
+  u_int32_t ttl;		/* resource record time to live */
+  u_short dlen;			/* size of resource record data */
+
+  int i, count, dup;		/* misc variables */
+
+  char *ptrList[1];
+  int ptrNum = 0;
+  struct in_addr addr;
+
+  result = (char *) malloc (256);
+  message = (char *) malloc (256);
+  /* 
+   * Look up the records for the given domain name.
+   * We expect the domain to be a fully qualified name, so
+   * we use res_query().  If we wanted the resolver search 
+   * algorithm, we would have used res_search() instead.
+   */
+  if ((responseLen =
+       res_query (domain,	/* the domain we care about   */
+		  C_IN,		/* Internet class records     */
+		  requested_type,	/* Look up name server records */
+		  (u_char *) & response,	/*response buffer */
+		  sizeof (response)))	/*buffer size    */
+      < 0)
+    {				/*If negative    */
+      rr_errno = h_errno;
+      return NULL;
+    }
+
+  /*
+   * Keep track of the end of the message so we don't 
+   * pass it while parsing the response.  responseLen is 
+   * the value returned by res_query.
+   */
+  endOfMsg = response.buf + responseLen;
+
+  /*
+   * Set a pointer to the start of the question section, 
+   * which begins immediately AFTER the header.
+   */
+  cp = response.buf + sizeof (HEADER);
+
+  /*
+   * Skip over the whole question section.  The question 
+   * section is comprised of a name, a type, and a class.  
+   * QFIXEDSZ (defined in arpa/nameser.h) is the size of 
+   * the type and class portions, which is fixed.  Therefore, 
+   * we can skip the question section by skipping the 
+   * name (at the beginning) and then advancing QFIXEDSZ.
+   * After this calculation, cp points to the start of the 
+   * answer section, which is a list of NS records.
+   */
+  cp += skipName (cp, endOfMsg) + QFIXEDSZ;
+
+  count = ntohs (response.hdr.ancount) +
+    ntohs (response.hdr.nscount);
+  while ((--count >= 0)		/* still more records     */
+	 && (cp < endOfMsg))
+    {				/* still inside the packet */
+
+
+      /* Skip to the data portion of the resource record */
+      cp += skipToData (cp, &type, &class, &ttl, &dlen, endOfMsg);
+
+      if (type == requested_type)
+	{
+	  switch (requested_type)
+	    {
+	    case (T_LOC):
+	      loc_ntoa (cp, result);
+	      return result;
+	      break;
+	    case (T_PTR):
+	      ptrList[ptrNum] = (char *) malloc (MAXDNAME);
+	      if (ptrList[ptrNum] == NULL)
+		{
+		  panic ("Malloc failed");
+		}
+
+	      if (dn_expand (response.buf,	/* Start of the packet   */
+			     endOfMsg,	/* End of the packet     */
+			     cp,	/* Position in the packet */
+			     (u_char *) ptrList[ptrNum],	/* Result    */
+			     MAXDNAME)	/* size of ptrList buffer */
+		  < 0)
+		{		/* Negative: error    */
+		  panic ("dn_expand failed");
+		}
+
+	      /*
+	       * Check the name we've just unpacked and add it to 
+	       * the list if it is not a duplicate.
+	       * If it is a duplicate, just ignore it.
+	       */
+	      for (i = 0, dup = 0; (i < ptrNum) && !dup; i++)
+		dup = !strcasecmp (ptrList[i], ptrList[ptrNum]);
+	      if (dup)
+		free (ptrList[ptrNum]);
+	      else
+		ptrNum++;
+	      strcpy (result, ptrList[0]);
+	      return result;
+	      break;
+	    case (T_A):
+	      bcopy ((char *) cp, (char *) &addr, INADDRSZ);
+	      strcat (result, " ");
+	      strcat (result, inet_ntoa (addr));
+	      found = 1;
+	      break;
+	    default:
+	      sprintf (message, "Unexpected type %u", requested_type);
+	      panic (message);
+	    }
+	}
+
+      /* Advance the pointer over the resource record data */
+      cp += dlen;
+
+    }				/* end of while */
+  if (found) 
+  return result;
+else
+return NULL;
+}
+
+struct list_in_addr *
+findA (domain)
+     char *domain;
+{
+
+  struct list_in_addr *result, *end;
+
+  union
+    {
+      HEADER hdr;		/* defined in resolv.h */
+      u_char buf[PACKETSZ];	/* defined in arpa/nameser.h */
+    }
+  response;			/* response buffers */
+  int responseLen;		/* buffer length */
+
+  u_char *cp;			/* character pointer to parse DNS packet */
+  u_char *endOfMsg;		/* need to know the end of the message */
+  u_short class;		/* classes defined in arpa/nameser.h */
+  u_short type;			/* types defined in arpa/nameser.h */
+  u_int32_t ttl;		/* resource record time to live */
+  u_short dlen;			/* size of resource record data */
+
+  int count;			/* misc variables */
+
+  struct in_addr addr;
+
+  end = NULL;
+  result = NULL;
+
+  /* 
+   * Look up the records for the given domain name.
+   * We expect the domain to be a fully qualified name, so
+   * we use res_query().  If we wanted the resolver search 
+   * algorithm, we would have used res_search() instead.
+   */
+  if ((responseLen =
+       res_query (domain,	/* the domain we care about   */
+		  C_IN,		/* Internet class records     */
+		  T_A,
+		  (u_char *) & response,	/*response buffer */
+		  sizeof (response)))	/*buffer size    */
+      < 0)
+    {				/*If negative    */
+      rr_errno = h_errno;
+      return NULL;
+    }
+
+  /*
+   * Keep track of the end of the message so we don't 
+   * pass it while parsing the response.  responseLen is 
+   * the value returned by res_query.
+   */
+  endOfMsg = response.buf + responseLen;
+
+  /*
+   * Set a pointer to the start of the question section, 
+   * which begins immediately AFTER the header.
+   */
+  cp = response.buf + sizeof (HEADER);
+
+  /*
+   * Skip over the whole question section.  The question 
+   * section is comprised of a name, a type, and a class.  
+   * QFIXEDSZ (defined in arpa/nameser.h) is the size of 
+   * the type and class portions, which is fixed.  Therefore, 
+   * we can skip the question section by skipping the 
+   * name (at the beginning) and then advancing QFIXEDSZ.
+   * After this calculation, cp points to the start of the 
+   * answer section, which is a list of NS records.
+   */
+  cp += skipName (cp, endOfMsg) + QFIXEDSZ;
+
+  count = ntohs (response.hdr.ancount) +
+    ntohs (response.hdr.nscount);
+  while ((--count >= 0)		/* still more records     */
+	 && (cp < endOfMsg))
+    {				/* still inside the packet */
+
+
+      /* Skip to the data portion of the resource record */
+      cp += skipToData (cp, &type, &class, &ttl, &dlen, endOfMsg);
+
+      if (type == T_A)
+	{
+	  bcopy ((char *) cp, (char *) &addr, INADDRSZ);
+	  if (end == NULL)
+	    {
+	      result = (void *) malloc (sizeof (struct list_in_addr));
+	      result->addr = addr;
+	      result->next = NULL;
+	      end = result;
+	    }
+	  else
+	    {
+	      end->next = (void *) malloc (sizeof (struct list_in_addr));
+	      end = end->next;
+	      end->addr = addr;
+	      end->next = NULL;
+	    }
+	}
+
+      /* Advance the pointer over the resource record data */
+      cp += dlen;
+
+    }				/* end of while */
+  return result;
+}
diff --git a/contrib/query-loc-0.3.0/loc.h b/contrib/query-loc-0.3.0/loc.h
new file mode 100644
index 0000000000..f794acbe33
--- /dev/null
+++ b/contrib/query-loc-0.3.0/loc.h
@@ -0,0 +1,78 @@
+/* $Id: loc.h,v 1.1 2005/04/01 05:35:00 marka Exp $ */
+
+#define VERSION "0.3.0"
+
+#include "config.h"
+
+/* Probably too many inclusions but this is to keep 'gcc -Wall' happy... */
+#include <stdio.h>
+#include <stdlib.h>
+#include <sys/types.h>
+#include <netdb.h>
+#include <sys/socket.h>
+#include <netinet/in.h>
+#include <arpa/inet.h>
+#include <sys/time.h>
+#include <errno.h>
+#include <unistd.h>
+#include <string.h>
+#include <signal.h>
+#include <arpa/nameser.h>
+#include <resolv.h>
+
+#ifndef FALSE
+#define FALSE 0
+#endif
+#ifndef TRUE
+#define TRUE 1
+#endif
+
+#if SIZEOF_LONG == 4
+#define u_int32_t unsigned long
+#ifndef int32_t 
+#define int32_t   long
+#endif
+#else
+#define u_int32_t unsigned int
+#ifndef int32_t 
+#define int32_t   int
+#endif
+#endif
+
+#if SIZEOF_CHAR == 1
+#define u_int8_t unsigned char
+#ifndef int8_t 
+#define int8_t   char
+#endif
+#else 
+#if SIZEOF_SHORT == 1
+#define u_int8_t unsigned short
+#ifndef int8_t 
+#define int8_t   short
+#endif
+#else
+#error "No suitable native type for storing bytes"
+#endif
+#endif
+
+#ifndef INADDR_NONE
+#define INADDR_NONE (in_addr_t)-1
+#endif
+
+struct list_in_addr
+  {
+    struct in_addr addr;
+    void *next;
+  };
+
+void usage ();
+void panic ();
+
+char *getlocbyname ();
+char *getlocbyaddr ();
+char *getlocbynet ();
+char *findRR ();
+struct list_in_addr *findA ();
+
+extern char *progname;
+extern short debug;
diff --git a/contrib/query-loc-0.3.0/loc_ntoa.c b/contrib/query-loc-0.3.0/loc_ntoa.c
new file mode 100644
index 0000000000..21eada3e31
--- /dev/null
+++ b/contrib/query-loc-0.3.0/loc_ntoa.c
@@ -0,0 +1,248 @@
+/* Stolen from BIND */
+
+/*
+ * Copyright (c) 1985
+ *    The Regents of the University of California.  All rights reserved.
+ * 
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. All advertising materials mentioning features or use of this software
+ *    must display the following acknowledgement:
+ * 	This product includes software developed by the University of
+ * 	California, Berkeley and its contributors.
+ * 4. Neither the name of the University nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ * 
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Portions Copyright (c) 1993 by Digital Equipment Corporation.
+ * 
+ * Permission to use, copy, modify, and 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, and that
+ * the name of Digital Equipment Corporation not be used in advertising or
+ * publicity pertaining to distribution of the document or software without
+ * specific, written prior permission.
+ * 
+ * THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+ * WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+ * CORPORATION 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.
+ */
+
+/*
+ * Portions Copyright (c) 1995 by International Business Machines, Inc.
+ *
+ * International Business Machines, Inc. (hereinafter called IBM) grants
+ * permission under its copyrights to use, copy, modify, and distribute this
+ * Software with or without fee, provided that the above copyright notice and
+ * all paragraphs of this notice appear in all copies, and that the name of IBM
+ * not be used in connection with the marketing of any product incorporating
+ * the Software or modifications thereof, without specific, written prior
+ * permission.
+ *
+ * To the extent it has a right to do so, IBM grants an immunity from suit
+ * under its patents, if any, for the use, sale or manufacture of products to
+ * the extent that such products are used for performing Domain Name System
+ * dynamic updates in TCP/IP networks by means of the Software.  No immunity is
+ * granted for any product per se or for any other function of any product.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", AND IBM DISCLAIMS ALL WARRANTIES,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+ * PARTICULAR PURPOSE.  IN NO EVENT SHALL IBM BE LIABLE FOR ANY SPECIAL,
+ * DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER ARISING
+ * OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE, EVEN
+ * IF IBM IS APPRISED OF THE POSSIBILITY OF SUCH DAMAGES.
+ */
+
+/*
+ * Portions Copyright (c) 1996-1999 by Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and 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 INTERNET SOFTWARE CONSORTIUM DISCLAIMS
+ * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE
+ * CONSORTIUM 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.
+ */
+
+#include <sys/types.h>
+#include <sys/param.h>
+#include <sys/socket.h>
+
+#include <netinet/in.h>
+#include <arpa/inet.h>
+#include <arpa/nameser.h>
+
+#include <ctype.h>
+#include <errno.h>
+#include <math.h>
+#include <netdb.h>
+#include <resolv.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <time.h>
+
+#include "loc.h"
+
+const char *precsize_ntoa();
+
+/* takes an on-the-wire LOC RR and formats it in a human readable format. */
+const char *
+loc_ntoa(binary, ascii)
+	const u_char *binary;
+	char *ascii;
+{
+	static char *error = "?";
+	static char tmpbuf[sizeof
+"1000 60 60.000 N 1000 60 60.000 W -12345678.00m 90000000.00m 90000000.00m 90000000.00m"];
+	const u_char *cp = binary;
+
+	int latdeg, latmin, latsec, latsecfrac;
+	int longdeg, longmin, longsec, longsecfrac;
+	char northsouth, eastwest;
+	int altmeters, altfrac, altsign;
+
+	const u_int32_t referencealt = 100000 * 100;
+
+	int32_t latval, longval, altval;
+	u_int32_t templ;
+	u_int8_t sizeval, hpval, vpval, versionval;
+    
+	char *sizestr, *hpstr, *vpstr;
+
+	versionval = *cp++;
+
+	if (ascii == NULL)
+		ascii = tmpbuf;
+
+	if (versionval) {
+		(void) sprintf(ascii, "; error: unknown LOC RR version");
+		return (ascii);
+	}
+
+	sizeval = *cp++;
+
+	hpval = *cp++;
+	vpval = *cp++;
+
+	GETLONG(templ, cp);
+	latval = (templ - ((unsigned)1<<31));
+
+	GETLONG(templ, cp);
+	longval = (templ - ((unsigned)1<<31));
+
+	GETLONG(templ, cp);
+	if (templ < referencealt) { /* below WGS 84 spheroid */
+		altval = referencealt - templ;
+		altsign = -1;
+	} else {
+		altval = templ - referencealt;
+		altsign = 1;
+	}
+
+	if (latval < 0) {
+		northsouth = 'S';
+		latval = -latval;
+	} else
+		northsouth = 'N';
+
+	latsecfrac = latval % 1000;
+	latval = latval / 1000;
+	latsec = latval % 60;
+	latval = latval / 60;
+	latmin = latval % 60;
+	latval = latval / 60;
+	latdeg = latval;
+
+	if (longval < 0) {
+		eastwest = 'W';
+		longval = -longval;
+	} else
+		eastwest = 'E';
+
+	longsecfrac = longval % 1000;
+	longval = longval / 1000;
+	longsec = longval % 60;
+	longval = longval / 60;
+	longmin = longval % 60;
+	longval = longval / 60;
+	longdeg = longval;
+
+	altfrac = altval % 100;
+	altmeters = (altval / 100) * altsign;
+
+	if ((sizestr = strdup(precsize_ntoa(sizeval))) == NULL)
+		sizestr = error;
+	if ((hpstr = strdup(precsize_ntoa(hpval))) == NULL)
+		hpstr = error;
+	if ((vpstr = strdup(precsize_ntoa(vpval))) == NULL)
+		vpstr = error;
+
+	sprintf(ascii,
+	      "%d %.2d %.2d.%.3d %c %d %.2d %.2d.%.3d %c %d.%.2dm %sm %sm %sm",
+		latdeg, latmin, latsec, latsecfrac, northsouth,
+		longdeg, longmin, longsec, longsecfrac, eastwest,
+		altmeters, altfrac, sizestr, hpstr, vpstr);
+
+	if (sizestr != error)
+		free(sizestr);
+	if (hpstr != error)
+		free(hpstr);
+	if (vpstr != error)
+		free(vpstr);
+
+	return (ascii);
+}
+
+static unsigned int poweroften[10] = {1, 10, 100, 1000, 10000, 100000,
+				      1000000,10000000,100000000,1000000000};
+
+/* takes an XeY precision/size value, returns a string representation. */
+const char *
+precsize_ntoa(prec)
+	u_int8_t prec;
+{
+	static char retbuf[sizeof "90000000.00"];	/* XXX nonreentrant */
+	unsigned long val;
+	int mantissa, exponent;
+
+	mantissa = (int)((prec >> 4) & 0x0f) % 10;
+	exponent = (int)((prec >> 0) & 0x0f) % 10;
+
+	val = mantissa * poweroften[exponent];
+
+	(void) sprintf(retbuf, "%ld.%.2ld", val/100, val%100);
+	return (retbuf);
+}
+
diff --git a/contrib/query-loc-0.3.0/query-loc.1 b/contrib/query-loc-0.3.0/query-loc.1
new file mode 100644
index 0000000000..97eb4362c0
--- /dev/null
+++ b/contrib/query-loc-0.3.0/query-loc.1
@@ -0,0 +1,55 @@
+.\"                                      Hey, EMACS: -*- nroff -*-
+.\" First parameter, NAME, should be all caps
+.\" Second parameter, SECTION, should be 1-8, maybe w/ subsection
+.\" other parameters are allowed: see man(7), man(1)
+.TH QUERY-LOC SECTION "January 11, 2005"
+.\" Please adjust this date whenever revising the manpage.
+.\"
+.\" Some roff macros, for reference:
+.\" .nh        disable hyphenation
+.\" .hy        enable hyphenation
+.\" .ad l      left justify
+.\" .ad b      justify to both left and right margins
+.\" .nf        disable filling
+.\" .fi        enable filling
+.\" .br        insert line break
+.\" .sp <n>    insert n+1 empty lines
+.\" for manpage-specific macros, see man(7)
+.SH NAME
+query-loc \- to retrieve and display the location information in the DNS
+.SH SYNOPSIS
+.B query-loc
+.RI [-v] [-d nnn] " host"
+.SH DESCRIPTION
+This manual page documents briefly the
+.B query-loc
+command.
+.PP
+.\" TeX users may be more comfortable with the \fB<whatever>\fP and
+.\" \fI<whatever>\fP escape sequences to invode bold face and italics, 
+.\" respectively.
+\fBquery-loc\fP is a program to retrieve and display the location
+information in the DNS. 
+
+It uses the algorithms described in
+RFC 1876 (and RFC 1101 to get the network names).
+You can find examples of networks wchich implement this scheme
+in the ADDRESSES file.
+ 
+.SH OPTIONS
+.TP
+.B \-v
+Verbose mode. 
+.TP
+.B \-d nnn
+Debug mode. Displays the RFC's algorithm
+
+.SH BUGS
+
+Very few hosts have location information.
+
+.SH AUTHOR
+This manual page was written by Stephane Bortzmeyer
+<bortzmeyer@debian.org>.
+
+.\" $Id: query-loc.1,v 1.1 2005/04/01 05:35:01 marka Exp $
diff --git a/contrib/query-loc-0.3.0/query-loc.c b/contrib/query-loc-0.3.0/query-loc.c
new file mode 100644
index 0000000000..6af57d42b8
--- /dev/null
+++ b/contrib/query-loc-0.3.0/query-loc.c
@@ -0,0 +1,98 @@
+#include        "loc.h"
+
+/* $Id: query-loc.c,v 1.1 2005/04/01 05:35:01 marka Exp $ */
+
+/* Global variables */
+char *progname;
+short debug;
+
+int
+main (argc, argv)
+     int argc;
+     char *argv[];
+{
+  extern char *optarg;
+  extern int optind;
+
+  short verbose = FALSE;
+  char *host;
+
+  char ch;
+
+  char *loc = NULL;
+  struct in_addr addr;
+  struct hostent *hp;
+
+  progname = argv[0];
+  while ((ch = getopt (argc, argv, "vd:")) != EOF)
+    {
+      switch (ch)
+	{
+	case 'v':
+	  verbose = TRUE;
+	  break;
+	case 'd':
+	  debug = atoi (optarg);
+	  if (debug <= 0)
+	    {
+	      (void) fprintf (stderr,
+			      "%s: illegal debug value.\n", progname);
+	      exit (2);
+	    }
+	  break;
+	default:
+	  usage ();
+	}
+    }
+  argc -= optind;
+  argv += optind;
+  if (argc != 1)
+    {
+      usage ();
+    }
+  if (verbose || debug)
+    {
+      printf ("\nThis is %s, version %s.\n\n", progname, VERSION);
+    }
+  host = argv[0];
+  (void) res_init ();
+
+  if ((addr.s_addr = inet_addr (host)) == INADDR_NONE)
+    {
+      if (debug >= 1)
+	printf ("%s is a name\n", host);
+      loc = getlocbyname (host, FALSE);
+    }
+  else
+    {
+      if (debug >= 1)
+	printf ("%s is an IP address ", host);
+      hp = (struct hostent *) gethostbyaddr
+	((char *) &addr, sizeof (addr), AF_INET);
+      if (hp)
+	{
+	  if (debug >= 1)
+	    printf ("and %s is its official name\n",
+		    hp->h_name);
+	  loc = getlocbyname (hp->h_name, FALSE);
+	}
+      else
+	{
+	  if (debug >= 1)
+	    printf ("which has no name\n");
+	  loc = getlocbyaddr (addr, NULL);
+	}
+    }
+  if (loc == NULL)
+    {
+      printf ("No LOCation found for %s\n", host);
+      exit (1);
+    }
+  else
+    {
+      if (verbose || debug)
+	printf ("LOCation for %s is ", host);
+      printf ("%s\n", loc);
+      exit (0);
+    }
+}
diff --git a/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-05.txt b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-05.txt
new file mode 100644
index 0000000000..c0b8a6a0cd
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-05.txt
@@ -0,0 +1,466 @@
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+OBSOLETES: RFC 2536                               Donald E. Eastlake 3rd
+                                                   Motorola Laboratories
+Expires: September 2005                                       March 2005
+
+
+            DSA Keying and Signature Information in the DNS
+            --- ------ --- --------- ----------- -- --- ---
+               <draft-ietf-dnsext-rfc2536bis-dsa-05.txt>
+                         Donald E. Eastlake 3rd
+
+
+Status of This Document
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   or will be disclosed, and any of which I become aware will be
+   disclosed, in accordance with RFC 3668.
+
+   Distribution of this document is unlimited. Comments should be sent
+   to the DNS extensions working group mailing list
+   <namedroppers@ops.ietf.org>.
+
+   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 a "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
+
+
+Abstract
+
+   The standard method of encoding US Government Digital Signature
+   Algorithm keying and signature information for use in the Domain Name
+   System is specified.
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society 2005. All Rights Reserved.
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 1]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Abstract...................................................1
+      Copyright Notice...........................................1
+
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+      2. DSA Keying Information..................................3
+      3. DSA Signature Information...............................4
+      4. Performance Considerations..............................4
+      5. Security Considerations.................................5
+      6. IANA Considerations.....................................5
+      Copyright and Disclaimer...................................5
+
+      Normative References.......................................7
+      Informative References.....................................7
+      Authors Address............................................8
+      Expiration and File Name...................................8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 2]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   other information [RFC 1034, 1035]. The DNS has been extended to
+   include digital signatures and cryptographic keys as described in
+   [RFC intro, proto, records] and additional work is underway which
+   would require the storage of keying and signature information in the
+   DNS.
+
+   This document describes how to encode US Government Digital Signature
+   Algorithm (DSA) keys and signatures in the DNS.  Familiarity with the
+   US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
+
+
+
+2. DSA Keying Information
+
+   When DSA public keys are stored in the DNS, the structure of the
+   relevant part of the RDATA part of the RR being used is the fields
+   listed below in the order given.
+
+   The period of key validity is not included in this data but is
+   indicated separately, for example by an RR such as RRSIG which signs
+   and authenticates the RR containing the keying information.
+
+        Field     Size
+        -----     ----
+         T         1  octet
+         Q        20  octets
+         P        64 + T*8  octets
+         G        64 + T*8  octets
+         Y        64 + T*8  octets
+
+   As described in [FIPS 186-2] and [Schneier], T is a key size
+   parameter chosen such that 0 <= T <= 8.  (The meaning if the T octet
+   is greater than 8 is reserved and the remainder of the data may have
+   a different format in that case.)  Q is a prime number selected at
+   key generation time such that 2**159 < Q < 2**160. Thus Q is always
+   20 octets long and, as with all other fields, is stored in "big-
+   endian" network order.  P, G, and Y are calculated as directed by the
+   [FIPS 186-2] key generation algorithm [Schneier].  P is in the range
+   2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long.  G
+   and Y are quantities modulo P and so can be up to the same length as
+   P and are allocated fixed size fields with the same number of octets
+   as P.
+
+   During the key generation process, a random number X must be
+   generated such that 1 <= X <= Q-1.  X is the private key and is used
+   in the final step of public key generation where Y is computed as
+
+
+D. Eastlake 3rd                                                 [Page 3]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+        Y = G**X mod P
+
+
+
+3. DSA Signature Information
+
+   The portion of the RDATA area used for US Digital Signature Algorithm
+   signature information is shown below with fields in the order they
+   are listed and the contents of each multi-octet field in "big-endian"
+   network order.
+
+        Field     Size
+        -----     ----
+         T         1 octet
+         R        20 octets
+         S        20 octets
+
+   First, the data signed must be determined.  Then the following steps
+   are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
+   specified in the public key [Schneier]:
+
+        hash = SHA-1 ( data )
+
+        Generate a random K such that 0 < K < Q.
+
+        R = ( G**K mod P ) mod Q
+
+        S = ( K**(-1) * (hash + X*R) ) mod Q
+
+   For information on the SHA-1 hash function see [FIPS 180-1] and [RFC
+   3174].
+
+   Since Q is 160 bits long, R and S can not be larger than 20 octets,
+   which is the space allocated.
+
+   T is copied from the public key.  It is not logically necessary in
+   the SIG but is present so that values of T > 8 can more conveniently
+   be used as an escape for extended versions of DSA or other algorithms
+   as later standardized.
+
+
+
+4. Performance Considerations
+
+   General signature generation speeds are roughly the same for RSA [RFC
+   3110] and DSA.  With sufficient pre-computation, signature generation
+   with DSA is faster than RSA.  Key generation is also faster for DSA.
+   However, signature verification is an order of magnitude slower than
+   RSA when the RSA public exponent is chosen to be small, as is
+   recommended for some applications.
+
+
+D. Eastlake 3rd                                                 [Page 4]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+   Current DNS implementations are optimized for small transfers,
+   typically less than 512 bytes including DNS overhead.  Larger
+   transfers will perform correctly and extensions have been
+   standardized [RFC 2671] to make larger transfers more efficient, it
+   is still advisable at this time to make reasonable efforts to
+   minimize the size of RR sets containing keying and/or signature
+   inforamtion consistent with adequate security.
+
+
+
+5. Security Considerations
+
+   Keys retrieved from the DNS should not be trusted unless (1) they
+   have been securely obtained from a secure resolver or independently
+   verified by the user and (2) this secure resolver and secure
+   obtainment or independent verification conform to security policies
+   acceptable to the user.  As with all cryptographic algorithms,
+   evaluating the necessary strength of the key is essential and
+   dependent on local policy.
+
+   The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
+   current DSA standard may limit the security of DSA.  For particular
+   applications, implementors are encouraged to consider the range of
+   available algorithms and key sizes.
+
+   DSA assumes the ability to frequently generate high quality random
+   numbers.  See [random] for guidance.  DSA is designed so that if
+   biased rather than random numbers are used, high bandwidth covert
+   channels are possible.  See [Schneier] and more recent research.  The
+   leakage of an entire DSA private key in only two DSA signatures has
+   been demonstrated.  DSA provides security only if trusted
+   implementations, including trusted random number generation, are
+   used.
+
+
+
+6. IANA Considerations
+
+   Allocation of meaning to values of the T parameter that are not
+   defined herein (i.e., > 8 ) requires an IETF standards actions.  It
+   is intended that values unallocated herein be used to cover future
+   extensions of the DSS standard.
+
+
+
+Copyright and Disclaimer
+
+   Copyright (C) The Internet Society 2005.  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.
+
+
+D. Eastlake 3rd                                                 [Page 5]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 6]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+Normative References
+
+   [FIPS 180-1] - U.S. Federal Information Processing Standard: Secure
+   Hash Standard, April 1995.
+
+   [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
+   Signature Standard, 27 January 2000.
+
+   [RFC records] - "Resource Records for the DNS Security Extensions",
+   R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in
+   progress, draft-ietf-dnsext-dnssec-records- *.txt.
+
+
+
+Informative References
+
+   [random] - "Randomness Recommendations for Security", D. Eastlake, S.
+   Crocker, J. Schiller, work in progress, draft-eastlake-
+   randomness2-*.txt currently in RFC Editor's queue.
+
+   [RFC 1034] - "Domain names - concepts and facilities", P.
+   Mockapetris, 11/01/1987.
+
+   [RFC 1035] - "Domain names - implementation and specification", P.
+   Mockapetris, 11/01/1987.
+
+   [RFC intro] - "DNS Security Introduction and Requirements", R.
+   Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in progress,
+   draft-ietf-dnsext-dnssec-intro-*.txt.
+
+   [RFC protocol] - "Protocol Modifications for the DNS Security
+   Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose,
+   work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt.
+
+   [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
+   1999.
+
+   [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
+   (DNS)", D.  Eastlake 3rd. May 2001.
+
+   [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
+   Jones, September 2001.
+
+   [Schneier] - "Applied Cryptography Second Edition: protocols,
+   algorithms, and source code in C" (second edition), Bruce Schneier,
+   1996, John Wiley and Sons, ISBN 0-471-11709-9.
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 7]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+Authors Address
+
+   Donald E. Eastlake 3rd
+   Motorola Labortories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Telephone:   +1-508-786-7554(w)
+   EMail:       Donald.Eastlake@motorola.com
+
+
+
+Expiration and File Name
+
+   This draft expires in September 2005.
+
+   Its file name is draft-ietf-dnsext-rfc2536bis-dsa-05.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 8]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-05.txt b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-05.txt
new file mode 100644
index 0000000000..1ce669c9b1
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-05.txt
@@ -0,0 +1,581 @@
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+OBSOLETES: RFC 2539                               Donald E. Eastlake 3rd
+                                                   Motorola Laboratories
+Expires: September 2005                                       March 2005
+
+
+
+
+        Storage of Diffie-Hellman Keying Information in the DNS
+        ------- -- -------------- ------ ----------- -- --- ---
+               <draft-ietf-dnsext-rfc2539bis-dhk-05.txt>
+
+
+
+Status of This Document
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   or will be disclosed, and any of which I become aware will be
+   disclosed, in accordance with RFC 3668.
+
+   Distribution of this document is unlimited. Comments should be sent
+   to the DNS extensions working group mailing list
+   <namedroppers@ops.ietf.org>.
+
+   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 a "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
+
+
+Abstract
+
+   The standard method for encoding Diffie-Hellman keys in the Domain
+   Name System is specified.
+
+
+
+Copyright
+
+   Copyright (C) The Internet Society 2005.
+
+
+
+D. Eastlake 3rd                                                 [Page 1]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+Acknowledgements
+
+   Part of the format for Diffie-Hellman keys and the description
+   thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
+   and Hemma Prafullchandra.  In addition, the following persons
+   provided useful comments that were incorporated into the predecessor
+   of this document: Ran Atkinson, Thomas Narten.
+
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Abstract...................................................1
+      Copyright..................................................1
+
+      Acknowledgements...........................................2
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+      1.1 About This Document....................................3
+      1.2 About Diffie-Hellman...................................3
+      2. Encoding Diffie-Hellman Keying Information..............4
+      3. Performance Considerations..............................5
+      4. IANA Considerations.....................................5
+      5. Security Considerations.................................5
+      Copyright and Disclaimer...................................5
+
+      Normative References.......................................7
+      Informative Refences.......................................7
+      Author Address.............................................7
+      Expiration and File Name...................................8
+
+      Appendix A: Well known prime/generator pairs...............9
+      A.1. Well-Known Group 1:  A 768 bit prime..................9
+      A.2. Well-Known Group 2:  A 1024 bit prime.................9
+      A.3. Well-Known Group 3:  A 1536 bit prime................10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 2]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   similar information [RFC 1034, 1035]. The DNS has been extended to
+   include digital signatures and cryptographic keys as described in
+   [RFC intro, proto, records] and additonal work is underway which
+   would use the storage of keying information in the DNS.
+
+
+
+1.1 About This Document
+
+   This document describes how to store Diffie-Hellman keys in the DNS.
+   Familiarity with the Diffie-Hellman key exchange algorithm is assumed
+   [Schneier, RFC 2631].
+
+
+
+1.2 About Diffie-Hellman
+
+   Diffie-Hellman requires two parties to interact to derive keying
+   information which can then be used for authentication.  Thus Diffie-
+   Hellman is inherently a key agreement algorithm. As a result, no
+   format is defined for Diffie-Hellman "signature information".  For
+   example, assume that two parties have local secrets "i" and "j".
+   Assume they each respectively calculate X and Y as follows:
+
+        X = g**i ( mod p )
+
+        Y = g**j ( mod p )
+
+   They exchange these quantities and then each calculates a Z as
+   follows:
+
+        Zi = Y**i ( mod p )
+
+        Zj = X**j ( mod p )
+
+   Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
+   secret between the two parties that an adversary who does not know i
+   or j will not be able to learn from the exchanged messages (unless
+   the adversary can derive i or j by performing a discrete logarithm
+   mod p which is hard for strong p and g).
+
+   The private key for each party is their secret i (or j).  The public
+   key is the pair p and g, which must be the same for the parties, and
+   their individual X (or Y).
+
+   For further information about Diffie-Hellman and precautions to take
+
+
+D. Eastlake 3rd                                                 [Page 3]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+   in deciding on a p and g, see [RFC 2631].
+
+
+
+2. Encoding Diffie-Hellman Keying Information
+
+   When Diffie-Hellman keys appear within the RDATA portion of a RR,
+   they are encoded as shown below.
+
+   The period of key validity is not included in this data but is
+   indicated separately, for example by an RR such as RRSIG which signs
+   and authenticates the RR containing the keying information.
+
+                            1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |           KEY flags           |    protocol   |  algorithm=2  |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |     prime length (or flag)    |  prime (p) (or special)       /
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       /  prime (p)  (variable length) |       generator length        |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       | generator (g) (variable length)                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |     public value length       | public value (variable length)/
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       /  public value (g^i mod p)    (variable length)                |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Prime length is the length of the Diffie-Hellman prime (p) in bytes
+   if it is 16 or greater.  Prime contains the binary representation of
+   the Diffie-Hellman prime with most significant byte first (i.e., in
+   network order). If "prime length" field is 1 or 2, then the "prime"
+   field is actually an unsigned index into a table of 65,536
+   prime/generator pairs and the generator length SHOULD be zero.  See
+   Appedix A for defined table entries and Section 4 for information on
+   allocating additional table entries.  The meaning of a zero or 3
+   through 15 value for "prime length" is reserved.
+
+   Generator length is the length of the generator (g) in bytes.
+   Generator is the binary representation of generator with most
+   significant byte first.  PublicValueLen is the Length of the Public
+   Value (g**i (mod p)) in bytes.  PublicValue is the binary
+   representation of the DH public value with most significant byte
+   first.
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 4]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+3. Performance Considerations
+
+   Current DNS implementations are optimized for small transfers,
+   typically less than 512 bytes including DNS overhead.  Larger
+   transfers will perform correctly and extensions have been
+   standardized [RFC 2671] to make larger transfers more efficient. But
+   it is still advisable at this time to make reasonable efforts to
+   minimize the size of RR sets containing keying information consistent
+   with adequate security.
+
+
+
+4. IANA Considerations
+
+   Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
+   an IETF consensus as defined in [RFC 2434].
+
+   Well known prime/generator pairs number 0x0000 through 0x07FF can
+   only be assigned by an IETF standards action. [RFC 2539], the
+   Proposed Standard predecessor of this document, assigned 0x0001
+   through 0x0002. This document additionally assigns 0x0003.  Pairs
+   number 0s0800 through 0xBFFF can be assigned based on RFC
+   documentation. Pairs number 0xC000 through 0xFFFF are available for
+   private use and are not centrally coordinated. Use of such private
+   pairs outside of a closed environment may result in conflicts and/or
+   security failures.
+
+
+
+5. Security Considerations
+
+   Keying information retrieved from the DNS should not be trusted
+   unless (1) it has been securely obtained from a secure resolver or
+   independently verified by the user and (2) this secure resolver and
+   secure obtainment or independent verification conform to security
+   policies acceptable to the user.  As with all cryptographic
+   algorithms, evaluating the necessary strength of the key is important
+   and dependent on security policy.
+
+   In addition, the usual Diffie-Hellman key strength considerations
+   apply. (p-1)/2 should also be prime, g should be primitive mod p, p
+   should be "large", etc. See [RFC 2631, Schneier].
+
+
+
+Copyright and Disclaimer
+
+   Copyright (C) The Internet Society 2005.  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.
+
+
+D. Eastlake 3rd                                                 [Page 5]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 6]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+Normative References
+
+   [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
+   1999.
+
+   [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
+   in RFCs", T.  Narten, H. Alvestrand, October 1998.
+
+   [RFC records] - "Resource Records for the DNS Security Extensions",
+   R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in
+   progress, draft-ietf-dnsext-dnssec-records- *.txt.
+
+
+
+Informative Refences
+
+   [RFC 1034] - "Domain names - concepts and facilities", P.
+   Mockapetris, November 1987.
+
+   [RFC 1035] - "Domain names - implementation and specification", P.
+   Mockapetris, November 1987.
+
+   [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
+   System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
+
+   [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
+   1999.
+
+   [RFC intro] - "DNS Security Introduction and Requirements", R.
+   Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in progress,
+   draft-ietf-dnsext-dnssec-intro-*.txt.
+
+   [RFC protocol] - "Protocol Modifications for the DNS Security
+   Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose,
+   work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt.
+
+   [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
+   Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
+   and Sons.
+
+
+
+Author Address
+
+   Donald E. Eastlake 3rd
+   Motorola Laboratories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Telephone:   +1-508-786-7554
+
+
+D. Eastlake 3rd                                                 [Page 7]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+   EMail:       Donald.Eastlake@motorola.com
+
+
+
+Expiration and File Name
+
+   This draft expires in September 2005.
+
+   Its file name is draft-ietf-dnsext-rfc2539bis-dhk-05.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 8]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+Appendix A: Well known prime/generator pairs
+
+   These numbers are copied from the IPSEC effort where the derivation of
+   these values is more fully explained and additional information is
+   available.
+   Richard Schroeppel performed all the mathematical and computational
+   work for this appendix.
+
+
+
+A.1. Well-Known Group 1:  A 768 bit prime
+
+   The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }.  Its
+   decimal value is
+          155251809230070893513091813125848175563133404943451431320235
+          119490296623994910210725866945387659164244291000768028886422
+          915080371891804634263272761303128298374438082089019628850917
+          0691316593175367469551763119843371637221007210577919
+
+   Prime modulus: Length (32 bit words): 24, Data (hex):
+            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+            E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
+
+   Generator: Length (32 bit words): 1, Data (hex): 2
+
+
+
+A.2. Well-Known Group 2:  A 1024 bit prime
+
+   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
+   Its decimal value is
+         179769313486231590770839156793787453197860296048756011706444
+         423684197180216158519368947833795864925541502180565485980503
+         646440548199239100050792877003355816639229553136239076508735
+         759914822574862575007425302077447712589550957937778424442426
+         617334727629299387668709205606050270810842907692932019128194
+         467627007
+
+   Prime modulus:  Length (32 bit words): 32, Data (hex):
+            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+            E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+            EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
+            FFFFFFFF FFFFFFFF
+
+   Generator: Length (32 bit words): 1, Data (hex): 2
+
+
+
+D. Eastlake 3rd                                                 [Page 9]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+A.3. Well-Known Group 3:  A 1536 bit prime
+
+   The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] +  741804 }.
+   Its decimal value is
+            241031242692103258855207602219756607485695054850245994265411
+            694195810883168261222889009385826134161467322714147790401219
+            650364895705058263194273070680500922306273474534107340669624
+            601458936165977404102716924945320037872943417032584377865919
+            814376319377685986952408894019557734611984354530154704374720
+            774996976375008430892633929555996888245787241299381012913029
+            459299994792636526405928464720973038494721168143446471443848
+            8520940127459844288859336526896320919633919
+
+   Prime modulus Length (32 bit words): 48, Data (hex):
+              FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+              29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+              EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+              E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+              EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
+              C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
+              83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+              670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
+
+   Generator: Length (32 bit words):  1, Data (hex): 2
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 10]
+
+
diff --git a/doc/rfc/rfc4033.txt b/doc/rfc/rfc4033.txt
new file mode 100644
index 0000000000..7f0a464773
--- /dev/null
+++ b/doc/rfc/rfc4033.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group                                          R. Arends
+Request for Comments: 4033                          Telematica Instituut
+Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
+           3755, 3757, 3845                                          ISC
+Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
+         3007, 3597, 3226                                       VeriSign
+Category: Standards Track                                      D. Massey
+                                               Colorado State University
+                                                                 S. Rose
+                                                                    NIST
+                                                              March 2005
+
+
+               DNS Security Introduction and Requirements
+
+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 (2005).
+
+Abstract
+
+   The Domain Name System Security Extensions (DNSSEC) add data origin
+   authentication and data integrity to the Domain Name System.  This
+   document introduces these extensions and describes their capabilities
+   and limitations.  This document also discusses the services that the
+   DNS security extensions do and do not provide.  Last, this document
+   describes the interrelationships between the documents that
+   collectively describe DNSSEC.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 1]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Definitions of Important DNSSEC Terms  . . . . . . . . . . .   3
+   3.  Services Provided by DNS Security  . . . . . . . . . . . . .   7
+       3.1.  Data Origin Authentication and Data Integrity  . . . .   7
+       3.2.  Authenticating Name and Type Non-Existence . . . . . .   9
+   4.  Services Not Provided by DNS Security  . . . . . . . . . . .   9
+   5.  Scope of the DNSSEC Document Set and Last Hop Issues . . . .   9
+   6.  Resolver Considerations  . . . . . . . . . . . . . . . . . .  10
+   7.  Stub Resolver Considerations . . . . . . . . . . . . . . . .  11
+   8.  Zone Considerations  . . . . . . . . . . . . . . . . . . . .  12
+       8.1.  TTL Values vs. RRSIG Validity Period . . . . . . . . .  13
+       8.2.  New Temporal Dependency Issues for Zones . . . . . . .  13
+   9.  Name Server Considerations . . . . . . . . . . . . . . . . .  13
+   10. DNS Security Document Family . . . . . . . . . . . . . . . .  14
+   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  15
+   12. Security Considerations  . . . . . . . . . . . . . . . . . .  15
+   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  17
+   14. References . . . . . . . . . . . . . . . . . . . . . . . . .  17
+       14.1. Normative References . . . . . . . . . . . . . . . . .  17
+       14.2. Informative References . . . . . . . . . . . . . . . .  18
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  20
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  21
+
+1.  Introduction
+
+   This document introduces the Domain Name System Security Extensions
+   (DNSSEC).  This document and its two companion documents ([RFC4034]
+   and [RFC4035]) update, clarify, and refine the security extensions
+   defined in [RFC2535] and its predecessors.  These security extensions
+   consist of a set of new resource record types and modifications to
+   the existing DNS protocol ([RFC1035]).  The new records and protocol
+   modifications are not fully described in this document, but are
+   described in a family of documents outlined in Section 10.  Sections
+   3 and 4 describe the capabilities and limitations of the security
+   extensions in greater detail.  Section 5 discusses the scope of the
+   document set.  Sections 6, 7, 8, and 9 discuss the effect that these
+   security extensions will have on resolvers, stub resolvers, zones,
+   and name servers.
+
+   This document and its two companions obsolete [RFC2535], [RFC3008],
+   [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and
+   [RFC3845].  This document set also updates but does not obsolete
+   [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225],
+   [RFC3007], [RFC3597], and the portions of [RFC3226] that deal with
+   DNSSEC.
+
+
+
+
+Arends, et al.              Standards Track                     [Page 2]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   The DNS security extensions provide origin authentication and
+   integrity protection for DNS data, as well as a means of public key
+   distribution.  These extensions do not provide confidentiality.
+
+2.  Definitions of Important DNSSEC Terms
+
+   This section defines a number of terms used in this document set.
+   Because this is intended to be useful as a reference while reading
+   the rest of the document set, first-time readers may wish to skim
+   this section quickly, read the rest of this document, and then come
+   back to this section.
+
+   Authentication Chain: An alternating sequence of DNS public key
+      (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of
+      signed data, with each link in the chain vouching for the next.  A
+      DNSKEY RR is used to verify the signature covering a DS RR and
+      allows the DS RR to be authenticated.  The DS RR contains a hash
+      of another DNSKEY RR and this new DNSKEY RR is authenticated by
+      matching the hash in the DS RR.  This new DNSKEY RR in turn
+      authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in
+      this set may be used to authenticate another DS RR, and so forth
+      until the chain finally ends with a DNSKEY RR whose corresponding
+      private key signs the desired DNS data.  For example, the root
+      DNSKEY RRset can be used to authenticate the DS RRset for
+      "example."  The "example." DS RRset contains a hash that matches
+      some "example." DNSKEY, and this DNSKEY's corresponding private
+      key signs the "example." DNSKEY RRset.  Private key counterparts
+      of the "example." DNSKEY RRset sign data records such as
+      "www.example." and DS RRs for delegations such as
+      "subzone.example."
+
+   Authentication Key: A public key that a security-aware resolver has
+      verified and can therefore use to authenticate data.  A
+      security-aware resolver can obtain authentication keys in three
+      ways.  First, the resolver is generally configured to know about
+      at least one public key; this configured data is usually either
+      the public key itself or a hash of the public key as found in the
+      DS RR (see "trust anchor").  Second, the resolver may use an
+      authenticated public key to verify a DS RR and the DNSKEY RR to
+      which the DS RR refers.  Third, the resolver may be able to
+      determine that a new public key has been signed by the private key
+      corresponding to another public key that the resolver has
+      verified.  Note that the resolver must always be guided by local
+      policy when deciding whether to authenticate a new public key,
+      even if the local policy is simply to authenticate any new public
+      key for which the resolver is able verify the signature.
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 3]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   Authoritative RRset: Within the context of a particular zone, an
+      RRset is "authoritative" if and only if the owner name of the
+      RRset lies within the subset of the name space that is at or below
+      the zone apex and at or above the cuts that separate the zone from
+      its children, if any.  All RRsets at the zone apex are
+      authoritative, except for certain RRsets at this domain name that,
+      if present, belong to this zone's parent.  These RRset could
+      include a DS RRset, the NSEC RRset referencing this DS RRset (the
+      "parental NSEC"), and RRSIG RRs associated with these RRsets, all
+      of which are authoritative in the parent zone.  Similarly, if this
+      zone contains any delegation points, only the parental NSEC RRset,
+      DS RRsets, and any RRSIG RRs associated with these RRsets are
+      authoritative for this zone.
+
+   Delegation Point: Term used to describe the name at the parental side
+      of a zone cut.  That is, the delegation point for "foo.example"
+      would be the foo.example node in the "example" zone (as opposed to
+      the zone apex of the "foo.example" zone).  See also zone apex.
+
+   Island of Security: Term used to describe a signed, delegated zone
+      that does not have an authentication chain from its delegating
+      parent.  That is, there is no DS RR containing a hash of a DNSKEY
+      RR for the island in its delegating parent zone (see [RFC4034]).
+      An island of security is served by security-aware name servers and
+      may provide authentication chains to any delegated child zones.
+      Responses from an island of security or its descendents can only
+      be authenticated if its authentication keys can be authenticated
+      by some trusted means out of band from the DNS protocol.
+
+   Key Signing Key (KSK): An authentication key that corresponds to a
+      private key used to sign one or more other authentication keys for
+      a given zone.  Typically, the private key corresponding to a key
+      signing key will sign a zone signing key, which in turn has a
+      corresponding private key that will sign other zone data.  Local
+      policy may require that the zone signing key be changed
+      frequently, while the key signing key may have a longer validity
+      period in order to provide a more stable secure entry point into
+      the zone.  Designating an authentication key as a key signing key
+      is purely an operational issue: DNSSEC validation does not
+      distinguish between key signing keys and other DNSSEC
+      authentication keys, and it is possible to use a single key as
+      both a key signing key and a zone signing key.  Key signing keys
+      are discussed in more detail in [RFC3757].  Also see zone signing
+      key.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 4]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   Non-Validating Security-Aware Stub Resolver: A security-aware stub
+      resolver that trusts one or more security-aware recursive name
+      servers to perform most of the tasks discussed in this document
+      set on its behalf.  In particular, a non-validating security-aware
+      stub resolver is an entity that sends DNS queries, receives DNS
+      responses, and is capable of establishing an appropriately secured
+      channel to a security-aware recursive name server that will
+      provide these services on behalf of the security-aware stub
+      resolver.  See also security-aware stub resolver, validating
+      security-aware stub resolver.
+
+   Non-Validating Stub Resolver: A less tedious term for a
+      non-validating security-aware stub resolver.
+
+   Security-Aware Name Server: An entity acting in the role of a name
+      server (defined in section 2.4 of [RFC1034]) that understands the
+      DNS security extensions defined in this document set.  In
+      particular, a security-aware name server is an entity that
+      receives DNS queries, sends DNS responses, supports the EDNS0
+      ([RFC2671]) message size extension and the DO bit ([RFC3225]), and
+      supports the RR types and message header bits defined in this
+      document set.
+
+   Security-Aware Recursive Name Server: An entity that acts in both the
+      security-aware name server and security-aware resolver roles.  A
+      more cumbersome but equivalent phrase would be "a security-aware
+      name server that offers recursive service".
+
+   Security-Aware Resolver: An entity acting in the role of a resolver
+      (defined in section 2.4 of [RFC1034]) that understands the DNS
+      security extensions defined in this document set.  In particular,
+      a security-aware resolver is an entity that sends DNS queries,
+      receives DNS responses, supports the EDNS0 ([RFC2671]) message
+      size extension and the DO bit ([RFC3225]), and is capable of using
+      the RR types and message header bits defined in this document set
+      to provide DNSSEC services.
+
+   Security-Aware Stub Resolver: An entity acting in the role of a stub
+      resolver (defined in section 5.3.1 of [RFC1034]) that has enough
+      of an understanding the DNS security extensions defined in this
+      document set to provide additional services not available from a
+      security-oblivious stub resolver.  Security-aware stub resolvers
+      may be either "validating" or "non-validating", depending on
+      whether the stub resolver attempts to verify DNSSEC signatures on
+      its own or trusts a friendly security-aware name server to do so.
+      See also validating stub resolver, non-validating stub resolver.
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 5]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   Security-Oblivious <anything>: An <anything> that is not
+      "security-aware".
+
+   Signed Zone: A zone whose RRsets are signed and that contains
+      properly constructed DNSKEY, Resource Record Signature (RRSIG),
+      Next Secure (NSEC), and (optionally) DS records.
+
+   Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR.  A
+      validating security-aware resolver uses this public key or hash as
+      a starting point for building the authentication chain to a signed
+      DNS response.  In general, a validating resolver will have to
+      obtain the initial values of its trust anchors via some secure or
+      trusted means outside the DNS protocol.  Presence of a trust
+      anchor also implies that the resolver should expect the zone to
+      which the trust anchor points to be signed.
+
+   Unsigned Zone: A zone that is not signed.
+
+   Validating Security-Aware Stub Resolver: A security-aware resolver
+      that sends queries in recursive mode but that performs signature
+      validation on its own rather than just blindly trusting an
+      upstream security-aware recursive name server.  See also
+      security-aware stub resolver, non-validating security-aware stub
+      resolver.
+
+   Validating Stub Resolver: A less tedious term for a validating
+      security-aware stub resolver.
+
+   Zone Apex: Term used to describe the name at the child's side of a
+      zone cut.  See also delegation point.
+
+   Zone Signing Key (ZSK): An authentication key that corresponds to a
+      private key used to sign a zone.  Typically, a zone signing key
+      will be part of the same DNSKEY RRset as the key signing key whose
+      corresponding private key signs this DNSKEY RRset, but the zone
+      signing key is used for a slightly different purpose and may
+      differ from the key signing key in other ways, such as validity
+      lifetime.  Designating an authentication key as a zone signing key
+      is purely an operational issue; DNSSEC validation does not
+      distinguish between zone signing keys and other DNSSEC
+      authentication keys, and it is possible to use a single key as
+      both a key signing key and a zone signing key.  See also key
+      signing key.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 6]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+3.  Services Provided by DNS Security
+
+   The Domain Name System (DNS) security extensions provide origin
+   authentication and integrity assurance services for DNS data,
+   including mechanisms for authenticated denial of existence of DNS
+   data.  These mechanisms are described below.
+
+   These mechanisms require changes to the DNS protocol.  DNSSEC adds
+   four new resource record types: Resource Record Signature (RRSIG),
+   DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure
+   (NSEC).  It also adds two new message header bits: Checking Disabled
+   (CD) and Authenticated Data (AD).  In order to support the larger DNS
+   message sizes that result from adding the DNSSEC RRs, DNSSEC also
+   requires EDNS0 support ([RFC2671]).  Finally, DNSSEC requires support
+   for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a
+   security-aware resolver can indicate in its queries that it wishes to
+   receive DNSSEC RRs in response messages.
+
+   These services protect against most of the threats to the Domain Name
+   System described in [RFC3833].  Please see Section 12 for a
+   discussion of the limitations of these extensions.
+
+3.1.  Data Origin Authentication and Data Integrity
+
+   DNSSEC provides authentication by associating cryptographically
+   generated digital signatures with DNS RRsets.  These digital
+   signatures are stored in a new resource record, the RRSIG record.
+   Typically, there will be a single private key that signs a zone's
+   data, but multiple keys are possible.  For example, there may be keys
+   for each of several different digital signature algorithms.  If a
+   security-aware resolver reliably learns a zone's public key, it can
+   authenticate that zone's signed data.  An important DNSSEC concept is
+   that the key that signs a zone's data is associated with the zone
+   itself and not with the zone's authoritative name servers.  (Public
+   keys for DNS transaction authentication mechanisms may also appear in
+   zones, as described in [RFC2931], but DNSSEC itself is concerned with
+   object security of DNS data, not channel security of DNS
+   transactions.  The keys associated with transaction security may be
+   stored in different RR types.  See [RFC3755] for details.)
+
+   A security-aware resolver can learn a zone's public key either by
+   having a trust anchor configured into the resolver or by normal DNS
+   resolution.  To allow the latter, public keys are stored in a new
+   type of resource record, the DNSKEY RR.  Note that the private keys
+   used to sign zone data must be kept secure and should be stored
+   offline when practical.  To discover a public key reliably via DNS
+   resolution, the target key itself has to be signed by either a
+   configured authentication key or another key that has been
+
+
+
+Arends, et al.              Standards Track                     [Page 7]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   authenticated previously.  Security-aware resolvers authenticate zone
+   information by forming an authentication chain from a newly learned
+   public key back to a previously known authentication public key,
+   which in turn either has been configured into the resolver or must
+   have been learned and verified previously.  Therefore, the resolver
+   must be configured with at least one trust anchor.
+
+   If the configured trust anchor is a zone signing key, then it will
+   authenticate the associated zone; if the configured key is a key
+   signing key, it will authenticate a zone signing key.  If the
+   configured trust anchor is the hash of a key rather than the key
+   itself, the resolver may have to obtain the key via a DNS query.  To
+   help security-aware resolvers establish this authentication chain,
+   security-aware name servers attempt to send the signature(s) needed
+   to authenticate a zone's public key(s) in the DNS reply message along
+   with the public key itself, provided that there is space available in
+   the message.
+
+   The Delegation Signer (DS) RR type simplifies some of the
+   administrative tasks involved in signing delegations across
+   organizational boundaries.  The DS RRset resides at a delegation
+   point in a parent zone and indicates the public key(s) corresponding
+   to the private key(s) used to self-sign the DNSKEY RRset at the
+   delegated child zone's apex.  The administrator of the child zone, in
+   turn, uses the private key(s) corresponding to one or more of the
+   public keys in this DNSKEY RRset to sign the child zone's data.  The
+   typical authentication chain is therefore
+   DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
+   DS->DNSKEY subchains.  DNSSEC permits more complex authentication
+   chains, such as additional layers of DNSKEY RRs signing other DNSKEY
+   RRs within a zone.
+
+   A security-aware resolver normally constructs this authentication
+   chain from the root of the DNS hierarchy down to the leaf zones based
+   on configured knowledge of the public key for the root.  Local
+   policy, however, may also allow a security-aware resolver to use one
+   or more configured public keys (or hashes of public keys) other than
+   the root public key, may not provide configured knowledge of the root
+   public key, or may prevent the resolver from using particular public
+   keys for arbitrary reasons, even if those public keys are properly
+   signed with verifiable signatures.  DNSSEC provides mechanisms by
+   which a security-aware resolver can determine whether an RRset's
+   signature is "valid" within the meaning of DNSSEC.  In the final
+   analysis, however, authenticating both DNS keys and data is a matter
+   of local policy, which may extend or even override the protocol
+   extensions defined in this document set.  See Section 5 for further
+   discussion.
+
+
+
+
+Arends, et al.              Standards Track                     [Page 8]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+3.2.  Authenticating Name and Type Non-Existence
+
+   The security mechanism described in Section 3.1 only provides a way
+   to sign existing RRsets in a zone.  The problem of providing negative
+   responses with the same level of authentication and integrity
+   requires the use of another new resource record type, the NSEC
+   record.  The NSEC record allows a security-aware resolver to
+   authenticate a negative reply for either name or type non-existence
+   with the same mechanisms used to authenticate other DNS replies.  Use
+   of NSEC records requires a canonical representation and ordering for
+   domain names in zones.  Chains of NSEC records explicitly describe
+   the gaps, or "empty space", between domain names in a zone and list
+   the types of RRsets present at existing names.  Each NSEC record is
+   signed and authenticated using the mechanisms described in Section
+   3.1.
+
+4.  Services Not Provided by DNS Security
+
+   DNS was originally designed with the assumptions that the DNS will
+   return the same answer to any given query regardless of who may have
+   issued the query, and that all data in the DNS is thus visible.
+   Accordingly, DNSSEC is not designed to provide confidentiality,
+   access control lists, or other means of differentiating between
+   inquirers.
+
+   DNSSEC provides no protection against denial of service attacks.
+   Security-aware resolvers and security-aware name servers are
+   vulnerable to an additional class of denial of service attacks based
+   on cryptographic operations.  Please see Section 12 for details.
+
+   The DNS security extensions provide data and origin authentication
+   for DNS data.  The mechanisms outlined above are not designed to
+   protect operations such as zone transfers and dynamic update
+   ([RFC2136], [RFC3007]).  Message authentication schemes described in
+   [RFC2845] and [RFC2931] address security operations that pertain to
+   these transactions.
+
+5.  Scope of the DNSSEC Document Set and Last Hop Issues
+
+   The specification in this document set defines the behavior for zone
+   signers and security-aware name servers and resolvers in such a way
+   that the validating entities can unambiguously determine the state of
+   the data.
+
+   A validating resolver can determine the following 4 states:
+
+   Secure: The validating resolver has a trust anchor, has a chain of
+      trust, and is able to verify all the signatures in the response.
+
+
+
+Arends, et al.              Standards Track                     [Page 9]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   Insecure: The validating resolver has a trust anchor, a chain of
+      trust, and, at some delegation point, signed proof of the
+      non-existence of a DS record.  This indicates that subsequent
+      branches in the tree are provably insecure.  A validating resolver
+      may have a local policy to mark parts of the domain space as
+      insecure.
+
+   Bogus: The validating resolver has a trust anchor and a secure
+      delegation indicating that subsidiary data is signed, but the
+      response fails to validate for some reason: missing signatures,
+      expired signatures, signatures with unsupported algorithms, data
+      missing that the relevant NSEC RR says should be present, and so
+      forth.
+
+   Indeterminate: There is no trust anchor that would indicate that a
+      specific portion of the tree is secure.  This is the default
+      operation mode.
+
+   This specification only defines how security-aware name servers can
+   signal non-validating stub resolvers that data was found to be bogus
+   (using RCODE=2, "Server Failure"; see [RFC4035]).
+
+   There is a mechanism for security-aware name servers to signal
+   security-aware stub resolvers that data was found to be secure (using
+   the AD bit; see [RFC4035]).
+
+   This specification does not define a format for communicating why
+   responses were found to be bogus or marked as insecure.  The current
+   signaling mechanism does not distinguish between indeterminate and
+   insecure states.
+
+   A method for signaling advanced error codes and policy between a
+   security-aware stub resolver and security-aware recursive nameservers
+   is a topic for future work, as is the interface between a security-
+   aware resolver and the applications that use it.  Note, however, that
+   the lack of the specification of such communication does not prohibit
+   deployment of signed zones or the deployment of security aware
+   recursive name servers that prohibit propagation of bogus data to the
+   applications.
+
+6.  Resolver Considerations
+
+   A security-aware resolver has to be able to perform cryptographic
+   functions necessary to verify digital signatures using at least the
+   mandatory-to-implement algorithm(s).  Security-aware resolvers must
+   also be capable of forming an authentication chain from a newly
+   learned zone back to an authentication key, as described above.  This
+   process might require additional queries to intermediate DNS zones to
+
+
+
+Arends, et al.              Standards Track                    [Page 10]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   obtain necessary DNSKEY, DS, and RRSIG records.  A security-aware
+   resolver should be configured with at least one trust anchor as the
+   starting point from which it will attempt to establish authentication
+   chains.
+
+   If a security-aware resolver is separated from the relevant
+   authoritative name servers by a recursive name server or by any sort
+   of intermediary device that acts as a proxy for DNS, and if the
+   recursive name server or intermediary device is not security-aware,
+   the security-aware resolver may not be capable of operating in a
+   secure mode.  For example, if a security-aware resolver's packets are
+   routed through a network address translation (NAT) device that
+   includes a DNS proxy that is not security-aware, the security-aware
+   resolver may find it difficult or impossible to obtain or validate
+   signed DNS data.  The security-aware resolver may have a particularly
+   difficult time obtaining DS RRs in such a case, as DS RRs do not
+   follow the usual DNS rules for ownership of RRs at zone cuts.  Note
+   that this problem is not specific to NATs: any security-oblivious DNS
+   software of any kind between the security-aware resolver and the
+   authoritative name servers will interfere with DNSSEC.
+
+   If a security-aware resolver must rely on an unsigned zone or a name
+   server that is not security aware, the resolver may not be able to
+   validate DNS responses and will need a local policy on whether to
+   accept unverified responses.
+
+   A security-aware resolver should take a signature's validation period
+   into consideration when determining the TTL of data in its cache, to
+   avoid caching signed data beyond the validity period of the
+   signature.  However, it should also allow for the possibility that
+   the security-aware resolver's own clock is wrong.  Thus, a
+   security-aware resolver that is part of a security-aware recursive
+   name server will have to pay careful attention to the DNSSEC
+   "checking disabled" (CD) bit ([RFC4034]).  This is in order to avoid
+   blocking valid signatures from getting through to other
+   security-aware resolvers that are clients of this recursive name
+   server.  See [RFC4035] for how a secure recursive server handles
+   queries with the CD bit set.
+
+7.  Stub Resolver Considerations
+
+   Although not strictly required to do so by the protocol, most DNS
+   queries originate from stub resolvers.  Stub resolvers, by
+   definition, are minimal DNS resolvers that use recursive query mode
+   to offload most of the work of DNS resolution to a recursive name
+   server.  Given the widespread use of stub resolvers, the DNSSEC
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 11]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   architecture has to take stub resolvers into account, but the
+   security features needed in a stub resolver differ in some respects
+   from those needed in a security-aware iterative resolver.
+
+   Even a security-oblivious stub resolver may benefit from DNSSEC if
+   the recursive name servers it uses are security-aware, but for the
+   stub resolver to place any real reliance on DNSSEC services, the stub
+   resolver must trust both the recursive name servers in question and
+   the communication channels between itself and those name servers.
+   The first of these issues is a local policy issue: in essence, a
+   security-oblivious stub resolver has no choice but to place itself at
+   the mercy of the recursive name servers that it uses, as it does not
+   perform DNSSEC validity checks on its own.  The second issue requires
+   some kind of channel security mechanism; proper use of DNS
+   transaction authentication mechanisms such as SIG(0) ([RFC2931]) or
+   TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec.
+   Particular implementations may have other choices available, such as
+   operating system specific interprocess communication mechanisms.
+   Confidentiality is not needed for this channel, but data integrity
+   and message authentication are.
+
+   A security-aware stub resolver that does trust both its recursive
+   name servers and its communication channel to them may choose to
+   examine the setting of the Authenticated Data (AD) bit in the message
+   header of the response messages it receives.  The stub resolver can
+   use this flag bit as a hint to find out whether the recursive name
+   server was able to validate signatures for all of the data in the
+   Answer and Authority sections of the response.
+
+   There is one more step that a security-aware stub resolver can take
+   if, for whatever reason, it is not able to establish a useful trust
+   relationship with the recursive name servers that it uses: it can
+   perform its own signature validation by setting the Checking Disabled
+   (CD) bit in its query messages.  A validating stub resolver is thus
+   able to treat the DNSSEC signatures as trust relationships between
+   the zone administrators and the stub resolver itself.
+
+8.  Zone Considerations
+
+   There are several differences between signed and unsigned zones.  A
+   signed zone will contain additional security-related records (RRSIG,
+   DNSKEY, DS, and NSEC records).  RRSIG and NSEC records may be
+   generated by a signing process prior to serving the zone.  The RRSIG
+   records that accompany zone data have defined inception and
+   expiration times that establish a validity period for the signatures
+   and the zone data the signatures cover.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 12]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+8.1.  TTL Values vs. RRSIG Validity Period
+
+   It is important to note the distinction between a RRset's TTL value
+   and the signature validity period specified by the RRSIG RR covering
+   that RRset.  DNSSEC does not change the definition or function of the
+   TTL value, which is intended to maintain database coherency in
+   caches.  A caching resolver purges RRsets from its cache no later
+   than the end of the time period specified by the TTL fields of those
+   RRsets, regardless of whether the resolver is security-aware.
+
+   The inception and expiration fields in the RRSIG RR ([RFC4034]), on
+   the other hand, specify the time period during which the signature
+   can be used to validate the covered RRset.  The signatures associated
+   with signed zone data are only valid for the time period specified by
+   these fields in the RRSIG RRs in question.  TTL values cannot extend
+   the validity period of signed RRsets in a resolver's cache, but the
+   resolver may use the time remaining before expiration of the
+   signature validity period of a signed RRset as an upper bound for the
+   TTL of the signed RRset and its associated RRSIG RR in the resolver's
+   cache.
+
+8.2.  New Temporal Dependency Issues for Zones
+
+   Information in a signed zone has a temporal dependency that did not
+   exist in the original DNS protocol.  A signed zone requires regular
+   maintenance to ensure that each RRset in the zone has a current valid
+   RRSIG RR.  The signature validity period of an RRSIG RR is an
+   interval during which the signature for one particular signed RRset
+   can be considered valid, and the signatures of different RRsets in a
+   zone may expire at different times.  Re-signing one or more RRsets in
+   a zone will change one or more RRSIG RRs, which will in turn require
+   incrementing the zone's SOA serial number to indicate that a zone
+   change has occurred and re-signing the SOA RRset itself.  Thus,
+   re-signing any RRset in a zone may also trigger DNS NOTIFY messages
+   and zone transfer operations.
+
+9.  Name Server Considerations
+
+   A security-aware name server should include the appropriate DNSSEC
+   records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries
+   from resolvers that have signaled their willingness to receive such
+   records via use of the DO bit in the EDNS header, subject to message
+   size limitations.  Because inclusion of these DNSSEC RRs could easily
+   cause UDP message truncation and fallback to TCP, a security-aware
+   name server must also support the EDNS "sender's UDP payload"
+   mechanism.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 13]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   If possible, the private half of each DNSSEC key pair should be kept
+   offline, but this will not be possible for a zone for which DNS
+   dynamic update has been enabled.  In the dynamic update case, the
+   primary master server for the zone will have to re-sign the zone when
+   it is updated, so the private key corresponding to the zone signing
+   key will have to be kept online.  This is an example of a situation
+   in which the ability to separate the zone's DNSKEY RRset into zone
+   signing key(s) and key signing key(s) may be useful, as the key
+   signing key(s) in such a case can still be kept offline and may have
+   a longer useful lifetime than the zone signing key(s).
+
+   By itself, DNSSEC is not enough to protect the integrity of an entire
+   zone during zone transfer operations, as even a signed zone contains
+   some unsigned, nonauthoritative data if the zone has any children.
+   Therefore, zone maintenance operations will require some additional
+   mechanisms (most likely some form of channel security, such as TSIG,
+   SIG(0), or IPsec).
+
+10.  DNS Security Document Family
+
+   The DNSSEC document set can be partitioned into several main groups,
+   under the larger umbrella of the DNS base protocol documents.
+
+   The "DNSSEC protocol document set" refers to the three documents that
+   form the core of the DNS security extensions:
+
+   1.  DNS Security Introduction and Requirements (this document)
+
+   2.  Resource Records for DNS Security Extensions [RFC4034]
+
+   3.  Protocol Modifications for the DNS Security Extensions [RFC4035]
+
+   Additionally, any document that would add to or change the core DNS
+   Security extensions would fall into this category.  This includes any
+   future work on the communication between security-aware stub
+   resolvers and upstream security-aware recursive name servers.
+
+   The "Digital Signature Algorithm Specification" document set refers
+   to the group of documents that describe how specific digital
+   signature algorithms should be implemented to fit the DNSSEC resource
+   record format.  Each document in this set deals with a specific
+   digital signature algorithm.  Please see the appendix on "DNSSEC
+   Algorithm and Digest Types" in [RFC4034] for a list of the algorithms
+   that were defined when this core specification was written.
+
+   The "Transaction Authentication Protocol" document set refers to the
+   group of documents that deal with DNS message authentication,
+   including secret key establishment and verification.  Although not
+
+
+
+Arends, et al.              Standards Track                    [Page 14]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   strictly part of the DNSSEC specification as defined in this set of
+   documents, this group is noted because of its relationship to DNSSEC.
+
+   The final document set, "New Security Uses", refers to documents that
+   seek to use proposed DNS Security extensions for other security
+   related purposes.  DNSSEC does not provide any direct security for
+   these new uses but may be used to support them.  Documents that fall
+   in this category include those describing the use of DNS in the
+   storage and distribution of certificates ([RFC2538]).
+
+11.  IANA Considerations
+
+   This overview document introduces no new IANA considerations.  Please
+   see [RFC4034] for a complete review of the IANA considerations
+   introduced by DNSSEC.
+
+12.  Security Considerations
+
+   This document introduces DNS security extensions and describes the
+   document set that contains the new security records and DNS protocol
+   modifications.  The extensions provide data origin authentication and
+   data integrity using digital signatures over resource record sets.
+   This section discusses the limitations of these extensions.
+
+   In order for a security-aware resolver to validate a DNS response,
+   all zones along the path from the trusted starting point to the zone
+   containing the response zones must be signed, and all name servers
+   and resolvers involved in the resolution process must be
+   security-aware, as defined in this document set.  A security-aware
+   resolver cannot verify responses originating from an unsigned zone,
+   from a zone not served by a security-aware name server, or for any
+   DNS data that the resolver is only able to obtain through a recursive
+   name server that is not security-aware.  If there is a break in the
+   authentication chain such that a security-aware resolver cannot
+   obtain and validate the authentication keys it needs, then the
+   security-aware resolver cannot validate the affected DNS data.
+
+   This document briefly discusses other methods of adding security to a
+   DNS query, such as using a channel secured by IPsec or using a DNS
+   transaction authentication mechanism such as TSIG ([RFC2845]) or
+   SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC
+   per se.
+
+   A non-validating security-aware stub resolver, by definition, does
+   not perform DNSSEC signature validation on its own and thus is
+   vulnerable both to attacks on (and by) the security-aware recursive
+   name servers that perform these checks on its behalf and to attacks
+   on its communication with those security-aware recursive name
+
+
+
+Arends, et al.              Standards Track                    [Page 15]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   servers.  Non-validating security-aware stub resolvers should use
+   some form of channel security to defend against the latter threat.
+   The only known defense against the former threat would be for the
+   security-aware stub resolver to perform its own signature validation,
+   at which point, again by definition, it would no longer be a
+   non-validating security-aware stub resolver.
+
+   DNSSEC does not protect against denial of service attacks.  DNSSEC
+   makes DNS vulnerable to a new class of denial of service attacks
+   based on cryptographic operations against security-aware resolvers
+   and security-aware name servers, as an attacker can attempt to use
+   DNSSEC mechanisms to consume a victim's resources.  This class of
+   attacks takes at least two forms.  An attacker may be able to consume
+   resources in a security-aware resolver's signature validation code by
+   tampering with RRSIG RRs in response messages or by constructing
+   needlessly complex signature chains.  An attacker may also be able to
+   consume resources in a security-aware name server that supports DNS
+   dynamic update, by sending a stream of update messages that force the
+   security-aware name server to re-sign some RRsets in the zone more
+   frequently than would otherwise be necessary.
+
+   Due to a deliberate design choice, DNSSEC does not provide
+   confidentiality.
+
+   DNSSEC introduces the ability for a hostile party to enumerate all
+   the names in a zone by following the NSEC chain.  NSEC RRs assert
+   which names do not exist in a zone by linking from existing name to
+   existing name along a canonical ordering of all the names within a
+   zone.  Thus, an attacker can query these NSEC RRs in sequence to
+   obtain all the names in a zone.  Although this is not an attack on
+   the DNS itself, it could allow an attacker to map network hosts or
+   other resources by enumerating the contents of a zone.
+
+   DNSSEC introduces significant additional complexity to the DNS and
+   thus introduces many new opportunities for implementation bugs and
+   misconfigured zones.  In particular, enabling DNSSEC signature
+   validation in a resolver may cause entire legitimate zones to become
+   effectively unreachable due to DNSSEC configuration errors or bugs.
+
+   DNSSEC does not protect against tampering with unsigned zone data.
+   Non-authoritative data at zone cuts (glue and NS RRs in the parent
+   zone) are not signed.  This does not pose a problem when validating
+   the authentication chain, but it does mean that the non-authoritative
+   data itself is vulnerable to tampering during zone transfer
+   operations.  Thus, while DNSSEC can provide data origin
+   authentication and data integrity for RRsets, it cannot do so for
+   zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be
+   used to protect zone transfer operations.
+
+
+
+Arends, et al.              Standards Track                    [Page 16]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   Please see [RFC4034] and [RFC4035] for additional security
+   considerations.
+
+13.  Acknowledgements
+
+   This document was created from the input and ideas of the members of
+   the DNS Extensions Working Group.  Although explicitly listing
+   everyone who has contributed during the decade in which DNSSEC has
+   been under development would be impossible, the editors would
+   particularly like to thank the following people for their
+   contributions to and comments on this document set: Jaap Akkerhuis,
+   Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein,
+   David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald
+   Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson,
+   Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip
+   Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson,
+   Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon
+   Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters,
+   Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis,
+   Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ
+   Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob
+   Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz,
+   Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler,
+   Brian Wellington, and Suzanne Woolf.
+
+   No doubt the above list is incomplete.  We apologize to anyone we
+   left out.
+
+14.  References
+
+14.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.
+
+   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
+              Extensions", RFC 2535, March 1999.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+              2671, August 1999.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+              3225, December 2001.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 17]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
+              message size requirements", RFC 3226, December 2001.
+
+   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
+              Resource Record (RR)", RFC 3445, December 2002.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for 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.
+
+14.2.  Informative References
+
+   [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.
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, March 1998.
+
+   [RFC2538]  Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates
+              in the Domain Name System (DNS)", RFC 2538, March 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
+              ( SIG(0)s )", RFC 2931, September 2000.
+
+   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+              Update", RFC 3007, November 2000.
+
+   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
+              Signing Authority", RFC 3008, November 2000.
+
+   [RFC3090]  Lewis, E., "DNS Security Extension Clarification on Zone
+              Status", RFC 3090, March 2001.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, September 2003.
+
+
+
+
+Arends, et al.              Standards Track                    [Page 18]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+              Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
+              (RR)", RFC 3658, December 2003.
+
+   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
+              Signer (DS)", RFC 3755, May 2004.
+
+   [RFC3757]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
+              System KEY (DNSKEY) Resource Record (RR) Secure Entry
+              Point (SEP) Flag", RFC 3757, April 2004.
+
+   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
+              Name System (DNS)", RFC 3833, August 2004.
+
+   [RFC3845]  Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
+              RDATA Format", RFC 3845, August 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 19]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Brouwerijstraat 1
+   7523 XC  Enschede
+   NL
+
+   EMail: roy.arends@telin.nl
+
+
+   Rob Austein
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   EMail: sra@isc.org
+
+
+   Matt Larson
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   USA
+
+   EMail: mlarson@verisign.com
+
+
+   Dan Massey
+   Colorado State University
+   Department of Computer Science
+   Fort Collins, CO 80523-1873
+
+   EMail: massey@cs.colostate.edu
+
+
+   Scott Rose
+   National Institute for Standards and Technology
+   100 Bureau Drive
+   Gaithersburg, MD  20899-8920
+   USA
+
+   EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 20]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   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.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 21]
+
diff --git a/doc/rfc/rfc4034.txt b/doc/rfc/rfc4034.txt
new file mode 100644
index 0000000000..6a12c6b8ef
--- /dev/null
+++ b/doc/rfc/rfc4034.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Network Working Group                                          R. Arends
+Request for Comments: 4034                          Telematica Instituut
+Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
+           3755, 3757, 3845                                          ISC
+Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
+         3007, 3597, 3226                                       VeriSign
+Category: Standards Track                                      D. Massey
+                                               Colorado State University
+                                                                 S. Rose
+                                                                    NIST
+                                                              March 2005
+
+
+            Resource Records for the DNS Security Extensions
+
+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 (2005).
+
+Abstract
+
+   This document is part of a family of documents that describe the DNS
+   Security Extensions (DNSSEC).  The DNS Security Extensions are a
+   collection of resource records and protocol modifications that
+   provide source authentication for the DNS.  This document defines the
+   public key (DNSKEY), delegation signer (DS), resource record digital
+   signature (RRSIG), and authenticated denial of existence (NSEC)
+   resource records.  The purpose and format of each resource record is
+   described in detail, and an example of each resource record is given.
+
+   This document obsoletes RFC 2535 and incorporates changes from all
+   updates to RFC 2535.
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 1]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.1.  Background and Related Documents . . . . . . . . . . .  3
+       1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . .  3
+   2.  The DNSKEY Resource Record . . . . . . . . . . . . . . . . .  4
+       2.1.  DNSKEY RDATA Wire Format . . . . . . . . . . . . . . .  4
+             2.1.1.  The Flags Field. . . . . . . . . . . . . . . .  4
+             2.1.2.  The Protocol Field . . . . . . . . . . . . . .  5
+             2.1.3.  The Algorithm Field. . . . . . . . . . . . . .  5
+             2.1.4.  The Public Key Field . . . . . . . . . . . . .  5
+             2.1.5.  Notes on DNSKEY RDATA Design . . . . . . . . .  5
+       2.2.  The DNSKEY RR Presentation Format. . . . . . . . . . .  5
+       2.3.  DNSKEY RR Example  . . . . . . . . . . . . . . . . . .  6
+   3.  The RRSIG Resource Record  . . . . . . . . . . . . . . . . .  6
+       3.1.  RRSIG RDATA Wire Format. . . . . . . . . . . . . . . .  7
+             3.1.1.  The Type Covered Field . . . . . . . . . . . .  7
+             3.1.2.  The Algorithm Number Field . . . . . . . . . .  8
+             3.1.3.  The Labels Field . . . . . . . . . . . . . . .  8
+             3.1.4.  Original TTL Field . . . . . . . . . . . . . .  8
+             3.1.5.  Signature Expiration and Inception Fields. . .  9
+             3.1.6.  The Key Tag Field. . . . . . . . . . . . . . .  9
+             3.1.7.  The Signer's Name Field. . . . . . . . . . . .  9
+             3.1.8.  The Signature Field. . . . . . . . . . . . . .  9
+       3.2.  The RRSIG RR Presentation Format . . . . . . . . . . . 10
+       3.3.  RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11
+   4.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12
+       4.1.  NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13
+             4.1.1.  The Next Domain Name Field . . . . . . . . . . 13
+             4.1.2.  The Type Bit Maps Field. . . . . . . . . . . . 13
+             4.1.3.  Inclusion of Wildcard Names in NSEC RDATA. . . 14
+       4.2.  The NSEC RR Presentation Format. . . . . . . . . . . . 14
+       4.3.  NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15
+   5.  The DS Resource Record . . . . . . . . . . . . . . . . . . . 15
+       5.1.  DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16
+             5.1.1.  The Key Tag Field. . . . . . . . . . . . . . . 16
+             5.1.2.  The Algorithm Field. . . . . . . . . . . . . . 16
+             5.1.3.  The Digest Type Field. . . . . . . . . . . . . 17
+             5.1.4.  The Digest Field . . . . . . . . . . . . . . . 17
+       5.2.  Processing of DS RRs When Validating Responses . . . . 17
+       5.3.  The DS RR Presentation Format. . . . . . . . . . . . . 17
+       5.4.  DS RR Example. . . . . . . . . . . . . . . . . . . . . 18
+   6.  Canonical Form and Order of Resource Records . . . . . . . . 18
+       6.1.  Canonical DNS Name Order . . . . . . . . . . . . . . . 18
+       6.2.  Canonical RR Form. . . . . . . . . . . . . . . . . . . 19
+       6.3.  Canonical RR Ordering within an RRset. . . . . . . . . 20
+   7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20
+   8.  Security Considerations. . . . . . . . . . . . . . . . . . . 21
+
+
+
+Arends, et al.              Standards Track                     [Page 2]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
+       10.1. Normative References . . . . . . . . . . . . . . . . . 22
+       10.2. Informative References . . . . . . . . . . . . . . . . 23
+   A.  DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24
+       A.1.  DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24
+             A.1.1.  Private Algorithm Types. . . . . . . . . . . . 25
+       A.2.  DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25
+   B.  Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25
+       B.1.  Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29
+
+1.  Introduction
+
+   The DNS Security Extensions (DNSSEC) introduce four new DNS resource
+   record types: DNS Public Key (DNSKEY), Resource Record Signature
+   (RRSIG), Next Secure (NSEC), and Delegation Signer (DS).  This
+   document defines the purpose of each resource record (RR), the RR's
+   RDATA format, and its presentation format (ASCII representation).
+
+1.1.  Background and Related Documents
+
+   This document is part of a family of documents defining DNSSEC, which
+   should be read together as a set.
+
+   [RFC4033] contains an introduction to DNSSEC and definition of common
+   terms; the reader is assumed to be familiar with this document.
+   [RFC4033] also contains a list of other documents updated by and
+   obsoleted by this document set.
+
+   [RFC4035] defines the DNSSEC protocol operations.
+
+   The reader is also assumed to be familiar with the basic DNS concepts
+   described in [RFC1034], [RFC1035], and the subsequent documents that
+   update them, particularly [RFC2181] and [RFC2308].
+
+   This document defines the DNSSEC resource records.  All numeric DNS
+   type codes given in this document are decimal integers.
+
+1.2.  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].
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 3]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+2.  The DNSKEY Resource Record
+
+   DNSSEC uses public key cryptography to sign and authenticate DNS
+   resource record sets (RRsets).  The public keys are stored in DNSKEY
+   resource records and are used in the DNSSEC authentication process
+   described in [RFC4035]: A zone signs its authoritative RRsets by
+   using a private key and stores the corresponding public key in a
+   DNSKEY RR.  A resolver can then use the public key to validate
+   signatures covering the RRsets in the zone, and thus to authenticate
+   them.
+
+   The DNSKEY RR is not intended as a record for storing arbitrary
+   public keys and MUST NOT be used to store certificates or public keys
+   that do not directly relate to the DNS infrastructure.
+
+   The Type value for the DNSKEY RR type is 48.
+
+   The DNSKEY RR is class independent.
+
+   The DNSKEY RR has no special TTL requirements.
+
+2.1.  DNSKEY RDATA Wire Format
+
+   The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1
+   octet Protocol Field, a 1 octet Algorithm Field, and the Public Key
+   Field.
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Flags            |    Protocol   |   Algorithm   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               /
+   /                            Public Key                         /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.1.1.  The Flags Field
+
+   Bit 7 of the Flags field is the Zone Key flag.  If bit 7 has value 1,
+   then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's
+   owner name MUST be the name of a zone.  If bit 7 has value 0, then
+   the DNSKEY record holds some other type of DNS public key and MUST
+   NOT be used to verify RRSIGs that cover RRsets.
+
+   Bit 15 of the Flags field is the Secure Entry Point flag, described
+   in [RFC3757].  If bit 15 has value 1, then the DNSKEY record holds a
+   key intended for use as a secure entry point.  This flag is only
+
+
+
+Arends, et al.              Standards Track                     [Page 4]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   intended to be a hint to zone signing or debugging software as to the
+   intended use of this DNSKEY record; validators MUST NOT alter their
+   behavior during the signature validation process in any way based on
+   the setting of this bit.  This also means that a DNSKEY RR with the
+   SEP bit set would also need the Zone Key flag set in order to be able
+   to generate signatures legally.  A DNSKEY RR with the SEP set and the
+   Zone Key flag not set MUST NOT be used to verify RRSIGs that cover
+   RRsets.
+
+   Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
+   creation of the DNSKEY RR and MUST be ignored upon receipt.
+
+2.1.2.  The Protocol Field
+
+   The Protocol Field MUST have value 3, and the DNSKEY RR MUST be
+   treated as invalid during signature verification if it is found to be
+   some value other than 3.
+
+2.1.3.  The Algorithm Field
+
+   The Algorithm field identifies the public key's cryptographic
+   algorithm and determines the format of the Public Key field.  A list
+   of DNSSEC algorithm types can be found in Appendix A.1
+
+2.1.4.  The Public Key Field
+
+   The Public Key Field holds the public key material.  The format
+   depends on the algorithm of the key being stored and is described in
+   separate documents.
+
+2.1.5.  Notes on DNSKEY RDATA Design
+
+   Although the Protocol Field always has value 3, it is retained for
+   backward compatibility with early versions of the KEY record.
+
+2.2.  The DNSKEY RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Flag field MUST be represented as an unsigned decimal integer.
+   Given the currently defined flags, the possible values are: 0, 256,
+   and 257.
+
+   The Protocol Field MUST be represented as an unsigned decimal integer
+   with a value of 3.
+
+   The Algorithm field MUST be represented either as an unsigned decimal
+   integer or as an algorithm mnemonic as specified in Appendix A.1.
+
+
+
+Arends, et al.              Standards Track                     [Page 5]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The Public Key field MUST be represented as a Base64 encoding of the
+   Public Key.  Whitespace is allowed within the Base64 text.  For a
+   definition of Base64 encoding, see [RFC3548].
+
+2.3.  DNSKEY RR Example
+
+   The following DNSKEY RR stores a DNS zone key for example.com.
+
+   example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
+                                          Cbl+BBZH4b/0PY1kxkmvHjcZc8no
+                                          kfzj31GajIQKY+5CptLr3buXA10h
+                                          WqTkF7H6RfoRqXQeogmMHfpftf6z
+                                          Mv1LyBUgia7za6ZEzOJBOztyvhjL
+                                          742iU/TpPSEDhm2SNKLijfUppn1U
+                                          aNvv4w==  )
+
+   The first four text fields specify the owner name, TTL, Class, and RR
+   type (DNSKEY).  Value 256 indicates that the Zone Key bit (bit 7) in
+   the Flags field has value 1.  Value 3 is the fixed Protocol value.
+   Value 5 indicates the public key algorithm.  Appendix A.1 identifies
+   algorithm type 5 as RSA/SHA1 and indicates that the format of the
+   RSA/SHA1 public key field is defined in [RFC3110].  The remaining
+   text is a Base64 encoding of the public key.
+
+3.  The RRSIG Resource Record
+
+   DNSSEC uses public key cryptography to sign and authenticate DNS
+   resource record sets (RRsets).  Digital signatures are stored in
+   RRSIG resource records and are used in the DNSSEC authentication
+   process described in [RFC4035].  A validator can use these RRSIG RRs
+   to authenticate RRsets from the zone.  The RRSIG RR MUST only be used
+   to carry verification material (digital signatures) used to secure
+   DNS operations.
+
+   An RRSIG record contains the signature for an RRset with a particular
+   name, class, and type.  The RRSIG RR specifies a validity interval
+   for the signature and uses the Algorithm, the Signer's Name, and the
+   Key Tag to identify the DNSKEY RR containing the public key that a
+   validator can use to verify the signature.
+
+   Because every authoritative RRset in a zone must be protected by a
+   digital signature, RRSIG RRs must be present for names containing a
+   CNAME RR.  This is a change to the traditional DNS specification
+   [RFC1034], which stated that if a CNAME is present for a name, it is
+   the only type allowed at that name.  A RRSIG and NSEC (see Section 4)
+   MUST exist for the same name as a CNAME resource record in a signed
+   zone.
+
+
+
+
+Arends, et al.              Standards Track                     [Page 6]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The Type value for the RRSIG RR type is 46.
+
+   The RRSIG RR is class independent.
+
+   An RRSIG RR MUST have the same class as the RRset it covers.
+
+   The TTL value of an RRSIG RR MUST match the TTL value of the RRset it
+   covers.  This is an exception to the [RFC2181] rules for TTL values
+   of individual RRs within a RRset: individual RRSIG RRs with the same
+   owner name will have different TTL values if the RRsets they cover
+   have different TTL values.
+
+3.1.  RRSIG RDATA Wire Format
+
+   The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a
+   1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original
+   TTL field, a 4 octet Signature Expiration field, a 4 octet Signature
+   Inception field, a 2 octet Key tag, the Signer's Name field, and the
+   Signature field.
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        Type Covered           |  Algorithm    |     Labels    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Original TTL                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Signature Expiration                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Signature Inception                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Key Tag            |                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer's Name         /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               /
+   /                            Signature                          /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.1.1.  The Type Covered Field
+
+   The Type Covered field identifies the type of the RRset that is
+   covered by this RRSIG record.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 7]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+3.1.2.  The Algorithm Number Field
+
+   The Algorithm Number field identifies the cryptographic algorithm
+   used to create the signature.  A list of DNSSEC algorithm types can
+   be found in Appendix A.1
+
+3.1.3.  The Labels Field
+
+   The Labels field specifies the number of labels in the original RRSIG
+   RR owner name.  The significance of this field is that a validator
+   uses it to determine whether the answer was synthesized from a
+   wildcard.  If so, it can be used to determine what owner name was
+   used in generating the signature.
+
+   To validate a signature, the validator needs the original owner name
+   that was used to create the signature.  If the original owner name
+   contains a wildcard label ("*"), the owner name may have been
+   expanded by the server during the response process, in which case the
+   validator will have to reconstruct the original owner name in order
+   to validate the signature.  [RFC4035] describes how to use the Labels
+   field to reconstruct the original owner name.
+
+   The value of the Labels field MUST NOT count either the null (root)
+   label that terminates the owner name or the wildcard label (if
+   present).  The value of the Labels field MUST be less than or equal
+   to the number of labels in the RRSIG owner name.  For example,
+   "www.example.com." has a Labels field value of 3, and
+   "*.example.com." has a Labels field value of 2.  Root (".") has a
+   Labels field value of 0.
+
+   Although the wildcard label is not included in the count stored in
+   the Labels field of the RRSIG RR, the wildcard label is part of the
+   RRset's owner name when the signature is generated or verified.
+
+3.1.4.  Original TTL Field
+
+   The Original TTL field specifies the TTL of the covered RRset as it
+   appears in the authoritative zone.
+
+   The Original TTL field is necessary because a caching resolver
+   decrements the TTL value of a cached RRset.  In order to validate a
+   signature, a validator requires the original TTL.  [RFC4035]
+   describes how to use the Original TTL field value to reconstruct the
+   original TTL.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 8]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+3.1.5.  Signature Expiration and Inception Fields
+
+   The Signature Expiration and Inception fields specify a validity
+   period for the signature.  The RRSIG record MUST NOT be used for
+   authentication prior to the inception date and MUST NOT be used for
+   authentication after the expiration date.
+
+   The Signature Expiration and Inception field values specify a date
+   and time in the form of a 32-bit unsigned number of seconds elapsed
+   since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
+   byte order.  The longest interval that can be expressed by this
+   format without wrapping is approximately 136 years.  An RRSIG RR can
+   have an Expiration field value that is numerically smaller than the
+   Inception field value if the expiration field value is near the
+   32-bit wrap-around point or if the signature is long lived.  Because
+   of this, all comparisons involving these fields MUST use "Serial
+   number arithmetic", as defined in [RFC1982].  As a direct
+   consequence, the values contained in these fields cannot refer to
+   dates more than 68 years in either the past or the future.
+
+3.1.6.  The Key Tag Field
+
+   The Key Tag field contains the key tag value of the DNSKEY RR that
+   validates this signature, in network byte order.  Appendix B explains
+   how to calculate Key Tag values.
+
+3.1.7.  The Signer's Name Field
+
+   The Signer's Name field value identifies the owner name of the DNSKEY
+   RR that a validator is supposed to use to validate this signature.
+   The Signer's Name field MUST contain the name of the zone of the
+   covered RRset.  A sender MUST NOT use DNS name compression on the
+   Signer's Name field when transmitting a RRSIG RR.
+
+3.1.8.  The Signature Field
+
+   The Signature field contains the cryptographic signature that covers
+   the RRSIG RDATA (excluding the Signature field) and the RRset
+   specified by the RRSIG owner name, RRSIG class, and RRSIG Type
+   Covered field.  The format of this field depends on the algorithm in
+   use, and these formats are described in separate companion documents.
+
+3.1.8.1.  Signature Calculation
+
+   A signature covers the RRSIG RDATA (excluding the Signature Field)
+   and covers the data RRset specified by the RRSIG owner name, RRSIG
+   class, and RRSIG Type Covered fields.  The RRset is in canonical form
+   (see Section 6), and the set RR(1),...RR(n) is signed as follows:
+
+
+
+Arends, et al.              Standards Track                     [Page 9]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+         signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
+
+            "|" denotes concatenation;
+
+            RRSIG_RDATA is the wire format of the RRSIG RDATA fields
+               with the Signer's Name field in canonical form and
+               the Signature field excluded;
+
+            RR(i) = owner | type | class | TTL | RDATA length | RDATA
+
+               "owner" is the fully qualified owner name of the RRset in
+               canonical form (for RRs with wildcard owner names, the
+               wildcard label is included in the owner name);
+
+               Each RR MUST have the same owner name as the RRSIG RR;
+
+               Each RR MUST have the same class as the RRSIG RR;
+
+               Each RR in the RRset MUST have the RR type listed in the
+               RRSIG RR's Type Covered field;
+
+               Each RR in the RRset MUST have the TTL listed in the
+               RRSIG Original TTL Field;
+
+               Any DNS names in the RDATA field of each RR MUST be in
+               canonical form; and
+
+               The RRset MUST be sorted in canonical order.
+
+   See Sections 6.2 and 6.3 for details on canonical form and ordering
+   of RRsets.
+
+3.2.  The RRSIG RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Type Covered field is represented as an RR type mnemonic.  When
+   the mnemonic is not known, the TYPE representation as described in
+   [RFC3597], Section 5, MUST be used.
+
+   The Algorithm field value MUST be represented either as an unsigned
+   decimal integer or as an algorithm mnemonic, as specified in Appendix
+   A.1.
+
+   The Labels field value MUST be represented as an unsigned decimal
+   integer.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 10]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The Original TTL field value MUST be represented as an unsigned
+   decimal integer.
+
+   The Signature Expiration Time and Inception Time field values MUST be
+   represented either as an unsigned decimal integer indicating seconds
+   since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in
+   UTC, where:
+
+      YYYY is the year (0001-9999, but see Section 3.1.5);
+      MM is the month number (01-12);
+      DD is the day of the month (01-31);
+      HH is the hour, in 24 hour notation (00-23);
+      mm is the minute (00-59); and
+      SS is the second (00-59).
+
+   Note that it is always possible to distinguish between these two
+   formats because the YYYYMMDDHHmmSS format will always be exactly 14
+   digits, while the decimal representation of a 32-bit unsigned integer
+   can never be longer than 10 digits.
+
+   The Key Tag field MUST be represented as an unsigned decimal integer.
+
+   The Signer's Name field value MUST be represented as a domain name.
+
+   The Signature field is represented as a Base64 encoding of the
+   signature.  Whitespace is allowed within the Base64 text.  See
+   Section 2.2.
+
+3.3.  RRSIG RR Example
+
+   The following RRSIG RR stores the signature for the A RRset of
+   host.example.com:
+
+   host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
+                                  20030220173103 2642 example.com.
+                                  oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
+                                  PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
+                                  B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
+                                  GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
+                                  J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
+
+   The first four fields specify the owner name, TTL, Class, and RR type
+   (RRSIG).  The "A" represents the Type Covered field.  The value 5
+   identifies the algorithm used (RSA/SHA1) to create the signature.
+   The value 3 is the number of Labels in the original owner name.  The
+   value 86400 in the RRSIG RDATA is the Original TTL for the covered A
+   RRset.  20030322173103 and 20030220173103 are the expiration and
+
+
+
+
+Arends, et al.              Standards Track                    [Page 11]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   inception dates, respectively.  2642 is the Key Tag, and example.com.
+   is the Signer's Name.  The remaining text is a Base64 encoding of the
+   signature.
+
+   Note that combination of RRSIG RR owner name, class, and Type Covered
+   indicates that this RRSIG covers the "host.example.com" A RRset.  The
+   Label value of 3 indicates that no wildcard expansion was used.  The
+   Algorithm, Signer's Name, and Key Tag indicate that this signature
+   can be authenticated using an example.com zone DNSKEY RR whose
+   algorithm is 5 and whose key tag is 2642.
+
+4.  The NSEC Resource Record
+
+   The NSEC resource record lists two separate things: the next owner
+   name (in the canonical ordering of the zone) that contains
+   authoritative data or a delegation point NS RRset, and the set of RR
+   types present at the NSEC RR's owner name [RFC3845].  The complete
+   set of NSEC RRs in a zone indicates which authoritative RRsets exist
+   in a zone and also form a chain of authoritative owner names in the
+   zone.  This information is used to provide authenticated denial of
+   existence for DNS data, as described in [RFC4035].
+
+   Because every authoritative name in a zone must be part of the NSEC
+   chain, NSEC RRs must be present for names containing a CNAME RR.
+   This is a change to the traditional DNS specification [RFC1034],
+   which stated that if a CNAME is present for a name, it is the only
+   type allowed at that name.  An RRSIG (see Section 3) and NSEC MUST
+   exist for the same name as does a CNAME resource record in a signed
+   zone.
+
+   See [RFC4035] for discussion of how a zone signer determines
+   precisely which NSEC RRs it has to include in a zone.
+
+   The type value for the NSEC RR is 47.
+
+   The NSEC RR is class independent.
+
+   The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
+   field.  This is in the spirit of negative caching ([RFC2308]).
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 12]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+4.1.  NSEC RDATA Wire Format
+
+   The RDATA of the NSEC RR is as shown below:
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                      Next Domain Name                         /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Type Bit Maps                           /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.1.1.  The Next Domain Name Field
+
+   The Next Domain field contains the next owner name (in the canonical
+   ordering of the zone) that has authoritative data or contains a
+   delegation point NS RRset; see Section 6.1 for an explanation of
+   canonical ordering.  The value of the Next Domain Name field in the
+   last NSEC record in the zone is the name of the zone apex (the owner
+   name of the zone's SOA RR).  This indicates that the owner name of
+   the NSEC RR is the last name in the canonical ordering of the zone.
+
+   A sender MUST NOT use DNS name compression on the Next Domain Name
+   field when transmitting an NSEC RR.
+
+   Owner names of RRsets for which the given zone is not authoritative
+   (such as glue records) MUST NOT be listed in the Next Domain Name
+   unless at least one authoritative RRset exists at the same owner
+   name.
+
+4.1.2.  The Type Bit Maps Field
+
+   The Type Bit Maps field identifies the RRset types that exist at the
+   NSEC RR's owner name.
+
+   The RR type space is split into 256 window blocks, each representing
+   the low-order 8 bits of the 16-bit RR type space.  Each block that
+   has at least one active RR type is encoded using a single octet
+   window number (from 0 to 255), a single octet bitmap length (from 1
+   to 32) indicating the number of octets used for the window block's
+   bitmap, and up to 32 octets (256 bits) of bitmap.
+
+   Blocks are present in the NSEC RR RDATA in increasing numerical
+   order.
+
+      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
+
+      where "|" denotes concatenation.
+
+
+
+Arends, et al.              Standards Track                    [Page 13]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   Each bitmap encodes the low-order 8 bits of RR types within the
+   window block, in network bit order.  The first bit is bit 0.  For
+   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
+   to RR type 2 (NS), and so forth.  For window block 1, bit 1
+   corresponds to RR type 257, and bit 2 to RR type 258.  If a bit is
+   set, it indicates that an RRset of that type is present for the NSEC
+   RR's owner name.  If a bit is clear, it indicates that no RRset of
+   that type is present for the NSEC RR's owner name.
+
+   Bits representing pseudo-types MUST be clear, as they do not appear
+   in zone data.  If encountered, they MUST be ignored upon being read.
+
+   Blocks with no types present MUST NOT be included.  Trailing zero
+   octets in the bitmap MUST be omitted.  The length of each block's
+   bitmap is determined by the type code with the largest numerical
+   value, within that block, among the set of RR types present at the
+   NSEC RR's owner name.  Trailing zero octets not specified MUST be
+   interpreted as zero octets.
+
+   The bitmap for the NSEC RR at a delegation point requires special
+   attention.  Bits corresponding to the delegation NS RRset and the RR
+   types for which the parent zone has authoritative data MUST be set;
+   bits corresponding to any non-NS RRset for which the parent is not
+   authoritative MUST be clear.
+
+   A zone MUST NOT include an NSEC RR for any domain name that only
+   holds glue records.
+
+4.1.3.  Inclusion of Wildcard Names in NSEC RDATA
+
+   If a wildcard owner name appears in a zone, the wildcard label ("*")
+   is treated as a literal symbol and is treated the same as any other
+   owner name for the purposes of generating NSEC RRs.  Wildcard owner
+   names appear in the Next Domain Name field without any wildcard
+   expansion.  [RFC4035] describes the impact of wildcards on
+   authenticated denial of existence.
+
+4.2.  The NSEC RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Next Domain Name field is represented as a domain name.
+
+   The Type Bit Maps field is represented as a sequence of RR type
+   mnemonics.  When the mnemonic is not known, the TYPE representation
+   described in [RFC3597], Section 5, MUST be used.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 14]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+4.3.  NSEC RR Example
+
+   The following NSEC RR identifies the RRsets associated with
+   alfa.example.com. and identifies the next authoritative name after
+   alfa.example.com.
+
+   alfa.example.com. 86400 IN NSEC host.example.com. (
+                                   A MX RRSIG NSEC TYPE1234 )
+
+   The first four text fields specify the name, TTL, Class, and RR type
+   (NSEC).  The entry host.example.com. is the next authoritative name
+   after alfa.example.com. in canonical order.  The A, MX, RRSIG, NSEC,
+   and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC,
+   and TYPE1234 RRsets associated with the name alfa.example.com.
+
+   The RDATA section of the NSEC RR above would be encoded as:
+
+            0x04 'h'  'o'  's'  't'
+            0x07 'e'  'x'  'a'  'm'  'p'  'l'  'e'
+            0x03 'c'  'o'  'm'  0x00
+            0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
+            0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
+            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+            0x00 0x00 0x00 0x00 0x20
+
+   Assuming that the validator can authenticate this NSEC record, it
+   could be used to prove that beta.example.com does not exist, or to
+   prove that there is no AAAA record associated with alfa.example.com.
+   Authenticated denial of existence is discussed in [RFC4035].
+
+5.  The DS Resource Record
+
+   The DS Resource Record refers to a DNSKEY RR and is used in the DNS
+   DNSKEY authentication process.  A DS RR refers to a DNSKEY RR by
+   storing the key tag, algorithm number, and a digest of the DNSKEY RR.
+   Note that while the digest should be sufficient to identify the
+   public key, storing the key tag and key algorithm helps make the
+   identification process more efficient.  By authenticating the DS
+   record, a resolver can authenticate the DNSKEY RR to which the DS
+   record points.  The key authentication process is described in
+   [RFC4035].
+
+   The DS RR and its corresponding DNSKEY RR have the same owner name,
+   but they are stored in different locations.  The DS RR appears only
+   on the upper (parental) side of a delegation, and is authoritative
+   data in the parent zone.  For example, the DS RR for "example.com" is
+   stored in the "com" zone (the parent zone) rather than in the
+
+
+
+Arends, et al.              Standards Track                    [Page 15]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   "example.com" zone (the child zone).  The corresponding DNSKEY RR is
+   stored in the "example.com" zone (the child zone).  This simplifies
+   DNS zone management and zone signing but introduces special response
+   processing requirements for the DS RR; these are described in
+   [RFC4035].
+
+   The type number for the DS record is 43.
+
+   The DS resource record is class independent.
+
+   The DS RR has no special TTL requirements.
+
+5.1.  DS RDATA Wire Format
+
+   The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet
+   Algorithm field, a 1 octet Digest Type field, and a Digest field.
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Key Tag             |  Algorithm    |  Digest Type  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               /
+   /                            Digest                             /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+5.1.1.  The Key Tag Field
+
+   The Key Tag field lists the key tag of the DNSKEY RR referred to by
+   the DS record, in network byte order.
+
+   The Key Tag used by the DS RR is identical to the Key Tag used by
+   RRSIG RRs.  Appendix B describes how to compute a Key Tag.
+
+5.1.2.  The Algorithm Field
+
+   The Algorithm field lists the algorithm number of the DNSKEY RR
+   referred to by the DS record.
+
+   The algorithm number used by the DS RR is identical to the algorithm
+   number used by RRSIG and DNSKEY RRs.  Appendix A.1 lists the
+   algorithm number types.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 16]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+5.1.3.  The Digest Type Field
+
+   The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
+   RR.  The Digest Type field identifies the algorithm used to construct
+   the digest.  Appendix A.2 lists the possible digest algorithm types.
+
+5.1.4.  The Digest Field
+
+   The DS record refers to a DNSKEY RR by including a digest of that
+   DNSKEY RR.
+
+   The digest is calculated by concatenating the canonical form of the
+   fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
+   and then applying the digest algorithm.
+
+     digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
+
+      "|" denotes concatenation
+
+     DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
+
+   The size of the digest may vary depending on the digest algorithm and
+   DNSKEY RR size.  As of the time of this writing, the only defined
+   digest algorithm is SHA-1, which produces a 20 octet digest.
+
+5.2.  Processing of DS RRs When Validating Responses
+
+   The DS RR links the authentication chain across zone boundaries, so
+   the DS RR requires extra care in processing.  The DNSKEY RR referred
+   to in the DS RR MUST be a DNSSEC zone key.  The DNSKEY RR Flags MUST
+   have Flags bit 7 set.  If the DNSKEY flags do not indicate a DNSSEC
+   zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be
+   used in the validation process.
+
+5.3.  The DS RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Key Tag field MUST be represented as an unsigned decimal integer.
+
+   The Algorithm field MUST be represented either as an unsigned decimal
+   integer or as an algorithm mnemonic specified in Appendix A.1.
+
+   The Digest Type field MUST be represented as an unsigned decimal
+   integer.
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 17]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The Digest MUST be represented as a sequence of case-insensitive
+   hexadecimal digits.  Whitespace is allowed within the hexadecimal
+   text.
+
+5.4.  DS RR Example
+
+   The following example shows a DNSKEY RR and its corresponding DS RR.
+
+   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
+                                             fwJr1AYtsmx3TGkJaNXVbfi/
+                                             2pHm822aJ5iI9BMzNXxeYCmZ
+                                             DRD99WYwYqUSdjMmmAphXdvx
+                                             egXd/M5+X7OrzKBaMbCVdFLU
+                                             Uh6DhweJBjEVv5f2wwjM9Xzc
+                                             nOf+EPbtG9DMBmADjFDc2w/r
+                                             ljwvFw==
+                                             ) ;  key id = 60485
+
+   dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
+                                              98631FAD1A292118 )
+
+   The first four text fields specify the name, TTL, Class, and RR type
+   (DS).  Value 60485 is the key tag for the corresponding
+   "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
+   used by this "dskey.example.com." DNSKEY RR.  The value 1 is the
+   algorithm used to construct the digest, and the rest of the RDATA
+   text is the digest in hexadecimal.
+
+6.  Canonical Form and Order of Resource Records
+
+   This section defines a canonical form for resource records, a
+   canonical ordering of DNS names, and a canonical ordering of resource
+   records within an RRset.  A canonical name order is required to
+   construct the NSEC name chain.  A canonical RR form and ordering
+   within an RRset are required in order to construct and verify RRSIG
+   RRs.
+
+6.1.  Canonical DNS Name Order
+
+   For the purposes of DNS security, owner names are ordered by treating
+   individual labels as unsigned left-justified octet strings.  The
+   absence of a octet sorts before a zero value octet, and uppercase
+   US-ASCII letters are treated as if they were lowercase US-ASCII
+   letters.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 18]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   To compute the canonical ordering of a set of DNS names, start by
+   sorting the names according to their most significant (rightmost)
+   labels.  For names in which the most significant label is identical,
+   continue sorting according to their next most significant label, and
+   so forth.
+
+   For example, the following names are sorted in canonical DNS name
+   order.  The most significant label is "example".  At this level,
+   "example" sorts first, followed by names ending in "a.example", then
+   by names ending "z.example".  The names within each level are sorted
+   in the same way.
+
+             example
+             a.example
+             yljkjljk.a.example
+             Z.a.example
+             zABC.a.EXAMPLE
+             z.example
+             \001.z.example
+             *.z.example
+             \200.z.example
+
+6.2.  Canonical RR Form
+
+   For the purposes of DNS security, the canonical form of an RR is the
+   wire format of the RR where:
+
+   1.  every domain name in the RR is fully expanded (no DNS name
+       compression) and fully qualified;
+
+   2.  all uppercase US-ASCII letters in the owner name of the RR are
+       replaced by the corresponding lowercase US-ASCII letters;
+
+   3.  if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
+       HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
+       SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
+       the DNS names contained within the RDATA are replaced by the
+       corresponding lowercase US-ASCII letters;
+
+   4.  if the owner name of the RR is a wildcard name, the owner name is
+       in its original unexpanded form, including the "*" label (no
+       wildcard substitution); and
+
+   5.  the RR's TTL is set to its original value as it appears in the
+       originating authoritative zone or the Original TTL field of the
+       covering RRSIG RR.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 19]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+6.3.  Canonical RR Ordering within an RRset
+
+   For the purposes of DNS security, RRs with the same owner name,
+   class, and type are sorted by treating the RDATA portion of the
+   canonical form of each RR as a left-justified unsigned octet sequence
+   in which the absence of an octet sorts before a zero octet.
+
+   [RFC2181] specifies that an RRset is not allowed to contain duplicate
+   records (multiple RRs with the same owner name, class, type, and
+   RDATA).  Therefore, if an implementation detects duplicate RRs when
+   putting the RRset in canonical form, it MUST treat this as a protocol
+   error.  If the implementation chooses to handle this protocol error
+   in the spirit of the robustness principle (being liberal in what it
+   accepts), it MUST remove all but one of the duplicate RR(s) for the
+   purposes of calculating the canonical form of the RRset.
+
+7.  IANA Considerations
+
+   This document introduces no new IANA considerations, as all of the
+   protocol parameters used in this document have already been assigned
+   by previous specifications.  However, since the evolution of DNSSEC
+   has been long and somewhat convoluted, this section attempts to
+   describe the current state of the IANA registries and other protocol
+   parameters that are (or once were) related to DNSSEC.
+
+   Please refer to [RFC4035] for additional IANA considerations.
+
+   DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
+      the SIG, KEY, and NXT RRs, respectively.  [RFC3658] assigned DNS
+      Resource Record Type 43 to DS.  [RFC3755] assigned types 46, 47,
+      and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively.
+      [RFC3755] also marked type 30 (NXT) as Obsolete and restricted use
+      of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction
+      security protocol described in [RFC2931] and to the transaction
+      KEY Resource Record described in [RFC2930].
+
+   DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
+      for DNSSEC Resource Record Algorithm field numbers and assigned
+      values 1-4 and 252-255.  [RFC3110] assigned value 5.  [RFC3755]
+      altered this registry to include flags for each entry regarding
+      its use with the DNS security extensions.  Each algorithm entry
+      could refer to an algorithm that can be used for zone signing,
+      transaction security (see [RFC2931]), or both.  Values 6-251 are
+      available for assignment by IETF standards action ([RFC3755]).
+      See Appendix A for a full listing of the DNS Security Algorithm
+      Numbers entries at the time of this writing and their status for
+      use in DNSSEC.
+
+
+
+
+Arends, et al.              Standards Track                    [Page 20]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+      [RFC3658] created an IANA registry for DNSSEC DS Digest Types and
+      assigned value 0 to reserved and value 1 to SHA-1.
+
+   KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
+      Protocol Values, but [RFC3445] reassigned all values other than 3
+      to reserved and closed this IANA registry.  The registry remains
+      closed, and all KEY and DNSKEY records are required to have a
+      Protocol Octet value of 3.
+
+   Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA
+      registry for the DNSSEC KEY and DNSKEY RR flag bits.  Initially,
+      this registry only contains assignments for bit 7 (the ZONE bit)
+      and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]).
+      As stated in [RFC3755], bits 0-6 and 8-14 are available for
+      assignment by IETF Standards Action.
+
+8.  Security Considerations
+
+   This document describes the format of four DNS resource records used
+   by the DNS security extensions and presents an algorithm for
+   calculating a key tag for a public key.  Other than the items
+   described below, the resource records themselves introduce no
+   security considerations.  Please see [RFC4033] and [RFC4035] for
+   additional security considerations related to the use of these
+   records.
+
+   The DS record points to a DNSKEY RR by using a cryptographic digest,
+   the key algorithm type, and a key tag.  The DS record is intended to
+   identify an existing DNSKEY RR, but it is theoretically possible for
+   an attacker to generate a DNSKEY that matches all the DS fields.  The
+   probability of constructing a matching DNSKEY depends on the type of
+   digest algorithm in use.  The only currently defined digest algorithm
+   is SHA-1, and the working group believes that constructing a public
+   key that would match the algorithm, key tag, and SHA-1 digest given
+   in a DS record would be a sufficiently difficult problem that such an
+   attack is not a serious threat at this time.
+
+   The key tag is used to help select DNSKEY resource records
+   efficiently, but it does not uniquely identify a single DNSKEY
+   resource record.  It is possible for two distinct DNSKEY RRs to have
+   the same owner name, the same algorithm type, and the same key tag.
+   An implementation that uses only the key tag to select a DNSKEY RR
+   might select the wrong public key in some circumstances.  Please see
+   Appendix B for further details.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 21]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The table of algorithms in Appendix A and the key tag calculation
+   algorithms in Appendix B include the RSA/MD5 algorithm for
+   completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as
+   explained in [RFC3110].
+
+9.  Acknowledgements
+
+   This document was created from the input and ideas of the members of
+   the DNS Extensions Working Group and working group mailing list.  The
+   editors would like to express their thanks for the comments and
+   suggestions received during the revision of these security extension
+   specifications.  Although explicitly listing everyone who has
+   contributed during the decade in which DNSSEC has been under
+   development would be impossible, [RFC4033] includes a list of some of
+   the participants who were kind enough to comment on these documents.
+
+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.
+
+   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+              August 1996.
+
+   [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.
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, March 1998.
+
+   [RFC2536]  Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
+              System (DNS)", RFC 2536, March 1999.
+
+   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
+              ( SIG(0)s )", RFC 2931, September 2000.
+
+   [RFC3110]  Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
+              Domain Name System (DNS)", RFC 3110, May 2001.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 22]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
+              Resource Record (RR)", RFC 3445, December 2002.
+
+   [RFC3548]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 3548, July 2003.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, September 2003.
+
+   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
+              (RR)", RFC 3658, December 2003.
+
+   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
+              Signer (DS)", RFC 3755, May 2004.
+
+   [RFC3757]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
+              System KEY (DNSKEY) Resource Record (RR) Secure Entry
+              Point (SEP) Flag", RFC 3757, April 2004.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements", RFC
+              4033, 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
+
+   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
+              Extensions", RFC 2535, March 1999.
+
+   [RFC2537]  Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain
+              Name System (DNS)", RFC 2537, March 1999.
+
+   [RFC2539]  Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the
+              Domain Name System (DNS)", RFC 2539, March 1999.
+
+   [RFC2930]  Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
+              RR)", RFC 2930, September 2000.
+
+   [RFC3845]  Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
+              RDATA Format", RFC 3845, August 2004.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 23]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+Appendix A.  DNSSEC Algorithm and Digest Types
+
+   The DNS security extensions are designed to be independent of the
+   underlying cryptographic algorithms.  The DNSKEY, RRSIG, and DS
+   resource records all use a DNSSEC Algorithm Number to identify the
+   cryptographic algorithm in use by the resource record.  The DS
+   resource record also specifies a Digest Algorithm Number to identify
+   the digest algorithm used to construct the DS record.  The currently
+   defined Algorithm and Digest Types are listed below.  Additional
+   Algorithm or Digest Types could be added as advances in cryptography
+   warrant them.
+
+   A DNSSEC aware resolver or name server MUST implement all MANDATORY
+   algorithms.
+
+A.1.  DNSSEC Algorithm Types
+
+   The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the
+   security algorithm being used.  These values are stored in the
+   "Algorithm number" field in the resource record RDATA.
+
+   Some algorithms are usable only for zone signing (DNSSEC), some only
+   for transaction security mechanisms (SIG(0) and TSIG), and some for
+   both.  Those usable for zone signing may appear in DNSKEY, RRSIG, and
+   DS RRs.  Those usable for transaction security would be present in
+   SIG(0) and KEY RRs, as described in [RFC2931].
+
+                                Zone
+   Value Algorithm [Mnemonic]  Signing  References   Status
+   ----- -------------------- --------- ----------  ---------
+     0   reserved
+     1   RSA/MD5 [RSAMD5]         n      [RFC2537]  NOT RECOMMENDED
+     2   Diffie-Hellman [DH]      n      [RFC2539]   -
+     3   DSA/SHA-1 [DSA]          y      [RFC2536]  OPTIONAL
+     4   Elliptic Curve [ECC]              TBA       -
+     5   RSA/SHA-1 [RSASHA1]      y      [RFC3110]  MANDATORY
+   252   Indirect [INDIRECT]      n                  -
+   253   Private [PRIVATEDNS]     y      see below  OPTIONAL
+   254   Private [PRIVATEOID]     y      see below  OPTIONAL
+   255   reserved
+
+   6 - 251  Available for assignment by IETF Standards Action.
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 24]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+A.1.1.  Private Algorithm Types
+
+   Algorithm number 253 is reserved for private use and will never be
+   assigned to a specific algorithm.  The public key area in the DNSKEY
+   RR and the signature area in the RRSIG RR begin with a wire encoded
+   domain name, which MUST NOT be compressed.  The domain name indicates
+   the private algorithm to use, and the remainder of the public key
+   area is determined by that algorithm.  Entities should only use
+   domain names they control to designate their private algorithms.
+
+   Algorithm number 254 is reserved for private use and will never be
+   assigned to a specific algorithm.  The public key area in the DNSKEY
+   RR and the signature area in the RRSIG RR begin with an unsigned
+   length byte followed by a BER encoded Object Identifier (ISO OID) of
+   that length.  The OID indicates the private algorithm in use, and the
+   remainder of the area is whatever is required by that algorithm.
+   Entities should only use OIDs they control to designate their private
+   algorithms.
+
+A.2.  DNSSEC Digest Types
+
+   A "Digest Type" field in the DS resource record types identifies the
+   cryptographic digest algorithm used by the resource record.  The
+   following table lists the currently defined digest algorithm types.
+
+              VALUE   Algorithm                 STATUS
+                0      Reserved                   -
+                1      SHA-1                   MANDATORY
+              2-255    Unassigned                 -
+
+Appendix B.  Key Tag Calculation
+
+   The Key Tag field in the RRSIG and DS resource record types provides
+   a mechanism for selecting a public key efficiently.  In most cases, a
+   combination of owner name, algorithm, and key tag can efficiently
+   identify a DNSKEY record.  Both the RRSIG and DS resource records
+   have corresponding DNSKEY records.  The Key Tag field in the RRSIG
+   and DS records can be used to help select the corresponding DNSKEY RR
+   efficiently when more than one candidate DNSKEY RR is available.
+
+   However, it is essential to note that the key tag is not a unique
+   identifier.  It is theoretically possible for two distinct DNSKEY RRs
+   to have the same owner name, the same algorithm, and the same key
+   tag.  The key tag is used to limit the possible candidate keys, but
+   it does not uniquely identify a DNSKEY record.  Implementations MUST
+   NOT assume that the key tag uniquely identifies a DNSKEY RR.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 25]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The key tag is the same for all DNSKEY algorithm types except
+   algorithm 1 (please see Appendix B.1 for the definition of the key
+   tag for algorithm 1).  The key tag algorithm is the sum of the wire
+   format of the DNSKEY RDATA broken into 2 octet groups.  First, the
+   RDATA (in wire format) is treated as a series of 2 octet groups.
+   These groups are then added together, ignoring any carry bits.
+
+   A reference implementation of the key tag algorithm is as an ANSI C
+   function is given below, with the RDATA portion of the DNSKEY RR is
+   used as input.  It is not necessary to use the following reference
+   code verbatim, but the numerical value of the Key Tag MUST be
+   identical to what the reference implementation would generate for the
+   same input.
+
+   Please note that the algorithm for calculating the Key Tag is almost
+   but not completely identical to the familiar ones-complement checksum
+   used in many other Internet protocols.  Key Tags MUST be calculated
+   using the algorithm described here rather than the ones complement
+   checksum.
+
+   The following ANSI C reference implementation calculates the value of
+   a Key Tag.  This reference implementation applies to all algorithm
+   types except algorithm 1 (see Appendix B.1).  The input is the wire
+   format of the RDATA portion of the DNSKEY RR.  The code is written
+   for clarity, not efficiency.
+
+   /*
+    * Assumes that int is at least 16 bits.
+    * First octet of the key tag is the most significant 8 bits of the
+    * return value;
+    * Second octet of the key tag is the least significant 8 bits of the
+    * return value.
+    */
+
+   unsigned int
+   keytag (
+           unsigned char key[],  /* the RDATA part of the DNSKEY RR */
+           unsigned int keysize  /* the RDLENGTH */
+          )
+   {
+           unsigned long ac;     /* assumed to be 32 bits or larger */
+           int i;                /* loop index */
+
+           for ( ac = 0, i = 0; i < keysize; ++i )
+                   ac += (i & 1) ? key[i] : key[i] << 8;
+           ac += (ac >> 16) & 0xFFFF;
+           return ac & 0xFFFF;
+   }
+
+
+
+Arends, et al.              Standards Track                    [Page 26]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+B.1.  Key Tag for Algorithm 1 (RSA/MD5)
+
+   The key tag for algorithm 1 (RSA/MD5) is defined differently from the
+   key tag for all other algorithms, for historical reasons.  For a
+   DNSKEY RR with algorithm 1, the key tag is defined to be the most
+   significant 16 bits of the least significant 24 bits in the public
+   key modulus (in other words, the 4th to last and 3rd to last octets
+   of the public key modulus).
+
+   Please note that Algorithm 1 is NOT RECOMMENDED.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 27]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Brouwerijstraat 1
+   7523 XC  Enschede
+   NL
+
+   EMail: roy.arends@telin.nl
+
+
+   Rob Austein
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   EMail: sra@isc.org
+
+
+   Matt Larson
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   USA
+
+   EMail: mlarson@verisign.com
+
+
+   Dan Massey
+   Colorado State University
+   Department of Computer Science
+   Fort Collins, CO 80523-1873
+
+   EMail: massey@cs.colostate.edu
+
+
+   Scott Rose
+   National Institute for Standards and Technology
+   100 Bureau Drive
+   Gaithersburg, MD  20899-8920
+   USA
+
+   EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 28]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   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.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 29]
+
diff --git a/doc/rfc/rfc4035.txt b/doc/rfc/rfc4035.txt
new file mode 100644
index 0000000000..b701cd2f23
--- /dev/null
+++ b/doc/rfc/rfc4035.txt
@@ -0,0 +1,2971 @@
+
+
+
+
+
+
+Network Working Group                                          R. Arends
+Request for Comments: 4035                          Telematica Instituut
+Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
+           3755, 3757, 3845                                          ISC
+Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
+         3007, 3597, 3226                                       VeriSign
+Category: Standards Track                                      D. Massey
+                                               Colorado State University
+                                                                 S. Rose
+                                                                    NIST
+                                                              March 2005
+
+
+         Protocol Modifications for the DNS Security Extensions
+
+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 (2005).
+
+Abstract
+
+   This document is part of a family of documents that describe the DNS
+   Security Extensions (DNSSEC).  The DNS Security Extensions are a
+   collection of new resource records and protocol modifications that
+   add data origin authentication and data integrity to the DNS.  This
+   document describes the DNSSEC protocol modifications.  This document
+   defines the concept of a signed zone, along with the requirements for
+   serving and resolving by using DNSSEC.  These techniques allow a
+   security-aware resolver to authenticate both DNS resource records and
+   authoritative DNS error indications.
+
+   This document obsoletes RFC 2535 and incorporates changes from all
+   updates to RFC 2535.
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 1]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.1.  Background and Related Documents . . . . . . . . . . . .  4
+       1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . .  4
+       2.1.  Including DNSKEY RRs in a Zone . . . . . . . . . . . . .  5
+       2.2.  Including RRSIG RRs in a Zone  . . . . . . . . . . . . .  5
+       2.3.  Including NSEC RRs in a Zone . . . . . . . . . . . . . .  6
+       2.4.  Including DS RRs in a Zone . . . . . . . . . . . . . . .  7
+       2.5.  Changes to the CNAME Resource Record.  . . . . . . . . .  7
+       2.6.  DNSSEC RR Types Appearing at Zone Cuts.  . . . . . . . .  8
+       2.7.  Example of a Secure Zone . . . . . . . . . . . . . . . .  8
+   3.  Serving  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+       3.1.  Authoritative Name Servers . . . . . . . . . . . . . . .  9
+             3.1.1.  Including RRSIG RRs in a Response  . . . . . . . 10
+             3.1.2.  Including DNSKEY RRs in a Response . . . . . . . 11
+             3.1.3.  Including NSEC RRs in a Response . . . . . . . . 11
+             3.1.4.  Including DS RRs in a Response . . . . . . . . . 14
+             3.1.5.  Responding to Queries for Type AXFR or IXFR  . . 15
+             3.1.6.  The AD and CD Bits in an Authoritative Response. 16
+       3.2.  Recursive Name Servers . . . . . . . . . . . . . . . . . 17
+             3.2.1.  The DO Bit . . . . . . . . . . . . . . . . . . . 17
+             3.2.2.  The CD Bit . . . . . . . . . . . . . . . . . . . 17
+             3.2.3.  The AD Bit . . . . . . . . . . . . . . . . . . . 18
+       3.3.  Example DNSSEC Responses . . . . . . . . . . . . . . . . 19
+   4.  Resolving  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+       4.1.  EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19
+       4.2.  Signature Verification Support . . . . . . . . . . . . . 19
+       4.3.  Determining Security Status of Data  . . . . . . . . . . 20
+       4.4.  Configured Trust Anchors . . . . . . . . . . . . . . . . 21
+       4.5.  Response Caching . . . . . . . . . . . . . . . . . . . . 21
+       4.6.  Handling of the CD and AD Bits . . . . . . . . . . . . . 22
+       4.7.  Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22
+       4.8.  Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23
+       4.9.  Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23
+             4.9.1.  Handling of the DO Bit . . . . . . . . . . . . . 24
+             4.9.2.  Handling of the CD Bit . . . . . . . . . . . . . 24
+             4.9.3.  Handling of the AD Bit . . . . . . . . . . . . . 24
+   5.  Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
+       5.1.  Special Considerations for Islands of Security . . . . . 26
+       5.2.  Authenticating Referrals . . . . . . . . . . . . . . . . 26
+       5.3.  Authenticating an RRset with an RRSIG RR . . . . . . . . 28
+             5.3.1.  Checking the RRSIG RR Validity . . . . . . . . . 28
+             5.3.2.  Reconstructing the Signed Data . . . . . . . . . 29
+             5.3.3.  Checking the Signature . . . . . . . . . . . . . 31
+             5.3.4.  Authenticating a Wildcard Expanded RRset
+                     Positive Response. . . . . . . . . . . . . . . . 32
+
+
+
+Arends, et al.              Standards Track                     [Page 2]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+       5.4.  Authenticated Denial of Existence  . . . . . . . . . . . 32
+       5.5.  Resolver Behavior When Signatures Do Not Validate  . . . 33
+       5.6.  Authentication Example . . . . . . . . . . . . . . . . . 33
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
+       9.1.  Normative References . . . . . . . . . . . . . . . . . . 34
+       9.2.  Informative References . . . . . . . . . . . . . . . . . 35
+   A.  Signed Zone Example  . . . . . . . . . . . . . . . . . . . . . 36
+   B.  Example Responses  . . . . . . . . . . . . . . . . . . . . . . 41
+       B.1.  Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41
+       B.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . 43
+       B.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . 44
+       B.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . 44
+       B.5.  Referral to Unsigned Zone  . . . . . . . . . . . . . . . 45
+       B.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46
+       B.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . 47
+       B.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . 48
+   C.  Authentication Examples  . . . . . . . . . . . . . . . . . . . 49
+       C.1.  Authenticating an Answer . . . . . . . . . . . . . . . . 49
+             C.1.1.  Authenticating the Example DNSKEY RR . . . . . . 49
+       C.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . 50
+       C.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . 50
+       C.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . 50
+       C.5.  Referral to Unsigned Zone  . . . . . . . . . . . . . . . 51
+       C.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51
+       C.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . 51
+       C.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . 51
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
+
+1.  Introduction
+
+   The DNS Security Extensions (DNSSEC) are a collection of new resource
+   records and protocol modifications that add data origin
+   authentication and data integrity to the DNS.  This document defines
+   the DNSSEC protocol modifications.  Section 2 of this document
+   defines the concept of a signed zone and lists the requirements for
+   zone signing.  Section 3 describes the modifications to authoritative
+   name server behavior necessary for handling signed zones.  Section 4
+   describes the behavior of entities that include security-aware
+   resolver functions.  Finally, Section 5 defines how to use DNSSEC RRs
+   to authenticate a response.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 3]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+1.1.  Background and Related Documents
+
+   This document is part of a family of documents defining DNSSEC that
+   should be read together as a set.
+
+   [RFC4033] contains an introduction to DNSSEC and definitions of
+   common terms; the reader is assumed to be familiar with this
+   document.  [RFC4033] also contains a list of other documents updated
+   by and obsoleted by this document set.
+
+   [RFC4034] defines the DNSSEC resource records.
+
+   The reader is also assumed to be familiar with the basic DNS concepts
+   described in [RFC1034], [RFC1035], and the subsequent documents that
+   update them; particularly, [RFC2181] and [RFC2308].
+
+   This document defines the DNSSEC protocol operations.
+
+1.2.  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.  Zone Signing
+
+   DNSSEC introduces the concept of signed zones.  A signed zone
+   includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG),
+   Next Secure (NSEC), and (optionally) Delegation Signer (DS) records
+   according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4,
+   respectively.  A zone that does not include these records according
+   to the rules in this section is an unsigned zone.
+
+   DNSSEC requires a change to the definition of the CNAME resource
+   record ([RFC1035]).  Section 2.5 changes the CNAME RR to allow RRSIG
+   and NSEC RRs to appear at the same owner name as does a CNAME RR.
+
+   DNSSEC specifies the placement of two new RR types, NSEC and DS,
+   which can be placed at the parental side of a zone cut (that is, at a
+   delegation point).  This is an exception to the general prohibition
+   against putting data in the parent zone at a zone cut.  Section 2.6
+   describes this change.
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 4]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+2.1.  Including DNSKEY RRs in a Zone
+
+   To sign a zone, the zone's administrator generates one or more
+   public/private key pairs and uses the private key(s) to sign
+   authoritative RRsets in the zone.  For each private key used to
+   create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR
+   containing the corresponding public key.  A zone key DNSKEY RR MUST
+   have the Zone Key bit of the flags RDATA field set (see Section 2.1.1
+   of [RFC4034]).  Public keys associated with other DNS operations MAY
+   be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT
+   be used to verify RRSIGs.
+
+   If the zone administrator intends a signed zone to be usable other
+   than as an island of security, the zone apex MUST contain at least
+   one DNSKEY RR to act as a secure entry point into the zone.  This
+   secure entry point could then be used as the target of a secure
+   delegation via a corresponding DS RR in the parent zone (see
+   [RFC4034]).
+
+2.2.  Including RRSIG RRs in a Zone
+
+   For each authoritative RRset in a signed zone, there MUST be at least
+   one RRSIG record that meets the following requirements:
+
+   o  The RRSIG owner name is equal to the RRset owner name.
+
+   o  The RRSIG class is equal to the RRset class.
+
+   o  The RRSIG Type Covered field is equal to the RRset type.
+
+   o  The RRSIG Original TTL field is equal to the TTL of the RRset.
+
+   o  The RRSIG RR's TTL is equal to the TTL of the RRset.
+
+   o  The RRSIG Labels field is equal to the number of labels in the
+      RRset owner name, not counting the null root label and not
+      counting the leftmost label if it is a wildcard.
+
+   o  The RRSIG Signer's Name field is equal to the name of the zone
+      containing the RRset.
+
+   o  The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
+      zone key DNSKEY record at the zone apex.
+
+   The process for constructing the RRSIG RR for a given RRset is
+   described in [RFC4034].  An RRset MAY have multiple RRSIG RRs
+   associated with it.  Note that as RRSIG RRs are closely tied to the
+   RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS
+
+
+
+Arends, et al.              Standards Track                     [Page 5]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   RR types, do not form RRsets.  In particular, the TTL values among
+   RRSIG RRs with a common owner name do not follow the RRset rules
+   described in [RFC2181].
+
+   An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would
+   add no value and would create an infinite loop in the signing
+   process.
+
+   The NS RRset that appears at the zone apex name MUST be signed, but
+   the NS RRsets that appear at delegation points (that is, the NS
+   RRsets in the parent zone that delegate the name to the child zone's
+   name servers) MUST NOT be signed.  Glue address RRsets associated
+   with delegations MUST NOT be signed.
+
+   There MUST be an RRSIG for each RRset using at least one DNSKEY of
+   each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
+   itself MUST be signed by each algorithm appearing in the DS RRset
+   located at the delegating parent (if any).
+
+2.3.  Including NSEC RRs in a Zone
+
+   Each owner name in the zone that has authoritative data or a
+   delegation point NS RRset MUST have an NSEC resource record.  The
+   format of NSEC RRs and the process for constructing the NSEC RR for a
+   given name is described in [RFC4034].
+
+   The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
+   value field in the zone SOA RR.
+
+   An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
+   RRset at any particular owner name.  That is, the signing process
+   MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not
+   the owner name of any RRset before the zone was signed.  The main
+   reasons for this are a desire for namespace consistency between
+   signed and unsigned versions of the same zone and a desire to reduce
+   the risk of response inconsistency in security oblivious recursive
+   name servers.
+
+   The type bitmap of every NSEC resource record in a signed zone MUST
+   indicate the presence of both the NSEC record itself and its
+   corresponding RRSIG record.
+
+   The difference between the set of owner names that require RRSIG
+   records and the set of owner names that require NSEC records is
+   subtle and worth highlighting.  RRSIG records are present at the
+   owner names of all authoritative RRsets.  NSEC records are present at
+   the owner names of all names for which the signed zone is
+   authoritative and also at the owner names of delegations from the
+
+
+
+Arends, et al.              Standards Track                     [Page 6]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   signed zone to its children.  Neither NSEC nor RRSIG records are
+   present (in the parent zone) at the owner names of glue address
+   RRsets.  Note, however, that this distinction is for the most part
+   visible only during the zone signing process, as NSEC RRsets are
+   authoritative data and are therefore signed.  Thus, any owner name
+   that has an NSEC RRset will have RRSIG RRs as well in the signed
+   zone.
+
+   The bitmap for the NSEC RR at a delegation point requires special
+   attention.  Bits corresponding to the delegation NS RRset and any
+   RRsets for which the parent zone has authoritative data MUST be set;
+   bits corresponding to any non-NS RRset for which the parent is not
+   authoritative MUST be clear.
+
+2.4.  Including DS RRs in a Zone
+
+   The DS resource record establishes authentication chains between DNS
+   zones.  A DS RRset SHOULD be present at a delegation point when the
+   child zone is signed.  The DS RRset MAY contain multiple records,
+   each referencing a public key in the child zone used to verify the
+   RRSIGs in that zone.  All DS RRsets in a zone MUST be signed, and DS
+   RRsets MUST NOT appear at a zone's apex.
+
+   A DS RR SHOULD point to a DNSKEY RR that is present in the child's
+   apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
+   by the corresponding private key.  DS RRs that fail to meet these
+   conditions are not useful for validation, but because the DS RR and
+   its corresponding DNSKEY RR are in different zones, and because the
+   DNS is only loosely consistent, temporary mismatches can occur.
+
+   The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
+   (that is, the NS RRset from the same zone containing the DS RRset).
+
+   Construction of a DS RR requires knowledge of the corresponding
+   DNSKEY RR in the child zone, which implies communication between the
+   child and parent zones.  This communication is an operational matter
+   not covered by this document.
+
+2.5.  Changes to the CNAME Resource Record
+
+   If a CNAME RRset is present at a name in a signed zone, appropriate
+   RRSIG and NSEC RRsets are REQUIRED at that name.  A KEY RRset at that
+   name for secure dynamic update purposes is also allowed ([RFC3007]).
+   Other types MUST NOT be present at that name.
+
+   This is a modification to the original CNAME definition given in
+   [RFC1034].  The original definition of the CNAME RR did not allow any
+   other types to coexist with a CNAME record, but a signed zone
+
+
+
+Arends, et al.              Standards Track                     [Page 7]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   requires NSEC and RRSIG RRs for every authoritative name.  To resolve
+   this conflict, this specification modifies the definition of the
+   CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
+
+2.6.  DNSSEC RR Types Appearing at Zone Cuts
+
+   DNSSEC introduced two new RR types that are unusual in that they can
+   appear at the parental side of a zone cut.  At the parental side of a
+   zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at
+   the owner name.  A DS RR could also be present if the zone being
+   delegated is signed and seeks to have a chain of authentication to
+   the parent zone.  This is an exception to the original DNS
+   specification ([RFC1034]), which states that only NS RRsets could
+   appear at the parental side of a zone cut.
+
+   This specification updates the original DNS specification to allow
+   NSEC and DS RR types at the parent side of a zone cut.  These RRsets
+   are authoritative for the parent when they appear at the parent side
+   of a zone cut.
+
+2.7.  Example of a Secure Zone
+
+   Appendix A shows a complete example of a small signed zone.
+
+3.  Serving
+
+   This section describes the behavior of entities that include
+   security-aware name server functions.  In many cases such functions
+   will be part of a security-aware recursive name server, but a
+   security-aware authoritative name server has some of the same
+   requirements.  Functions specific to security-aware recursive name
+   servers are described in Section 3.2; functions specific to
+   authoritative servers are described in Section 3.1.
+
+   In the following discussion, the terms "SNAME", "SCLASS", and "STYPE"
+   are as used in [RFC1034].
+
+   A security-aware name server MUST support the EDNS0 ([RFC2671])
+   message size extension, MUST support a message size of at least 1220
+   octets, and SHOULD support a message size of 4000 octets.  As IPv6
+   packets can only be fragmented by the source host, a security aware
+   name server SHOULD take steps to ensure that UDP datagrams it
+   transmits over IPv6 are fragmented, if necessary, at the minimum IPv6
+   MTU, unless the path MTU is known.  Please see [RFC1122], [RFC2460],
+   and [RFC3226] for further discussion of packet size and fragmentation
+   issues.
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 8]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   A security-aware name server that receives a DNS query that does not
+   include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
+   treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and
+   MUST NOT perform any of the additional processing described below.
+   Because the DS RR type has the peculiar property of only existing in
+   the parent zone at delegation points, DS RRs always require some
+   special processing, as described in Section 3.1.4.1.
+
+   Security aware name servers that receive explicit queries for
+   security RR types that match the content of more than one zone that
+   it serves (for example, NSEC and RRSIG RRs above and below a
+   delegation point where the server is authoritative for both zones)
+   should behave self-consistently.  As long as the response is always
+   consistent for each query to the name server, the name server MAY
+   return one of the following:
+
+   o  The above-delegation RRsets.
+   o  The below-delegation RRsets.
+   o  Both above and below-delegation RRsets.
+   o  Empty answer section (no records).
+   o  Some other response.
+   o  An error.
+
+   DNSSEC allocates two new bits in the DNS message header: the CD
+   (Checking Disabled) bit and the AD (Authentic Data) bit.  The CD bit
+   is controlled by resolvers; a security-aware name server MUST copy
+   the CD bit from a query into the corresponding response.  The AD bit
+   is controlled by name servers; a security-aware name server MUST
+   ignore the setting of the AD bit in queries.  See Sections 3.1.6,
+   3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.
+
+   A security aware name server that synthesizes CNAME RRs from DNAME
+   RRs as described in [RFC2672] SHOULD NOT generate signatures for the
+   synthesized CNAME RRs.
+
+3.1.  Authoritative Name Servers
+
+   Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT
+   pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name
+   server for a signed zone MUST include additional RRSIG, NSEC, and DS
+   RRs, according to the following rules:
+
+   o  RRSIG RRs that can be used to authenticate a response MUST be
+      included in the response according to the rules in Section 3.1.1.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 9]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   o  NSEC RRs that can be used to provide authenticated denial of
+      existence MUST be included in the response automatically according
+      to the rules in Section 3.1.3.
+
+   o  Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
+      be included in referrals automatically according to the rules in
+      Section 3.1.4.
+
+   These rules only apply to responses where the semantics convey
+   information about the presence or absence of resource records.  That
+   is, these rules are not intended to rule out responses such as RCODE
+   4 ("Not Implemented") or RCODE 5 ("Refused").
+
+   DNSSEC does not change the DNS zone transfer protocol.  Section 3.1.5
+   discusses zone transfer requirements.
+
+3.1.1.  Including RRSIG RRs in a Response
+
+   When responding to a query that has the DO bit set, a security-aware
+   authoritative name server SHOULD attempt to send RRSIG RRs that a
+   security-aware resolver can use to authenticate the RRsets in the
+   response.  A name server SHOULD make every attempt to keep the RRset
+   and its associated RRSIG(s) together in a response.  Inclusion of
+   RRSIG RRs in a response is subject to the following rules:
+
+   o  When placing a signed RRset in the Answer section, the name server
+      MUST also place its RRSIG RRs in the Answer section.  The RRSIG
+      RRs have a higher priority for inclusion than any other RRsets
+      that may have to be included.  If space does not permit inclusion
+      of these RRSIG RRs, the name server MUST set the TC bit.
+
+   o  When placing a signed RRset in the Authority section, the name
+      server MUST also place its RRSIG RRs in the Authority section.
+      The RRSIG RRs have a higher priority for inclusion than any other
+      RRsets that may have to be included.  If space does not permit
+      inclusion of these RRSIG RRs, the name server MUST set the TC bit.
+
+   o  When placing a signed RRset in the Additional section, the name
+      server MUST also place its RRSIG RRs in the Additional section.
+      If space does not permit inclusion of both the RRset and its
+      associated RRSIG RRs, the name server MAY retain the RRset while
+      dropping the RRSIG RRs.  If this happens, the name server MUST NOT
+      set the TC bit solely because these RRSIG RRs didn't fit.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 10]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+3.1.2.  Including DNSKEY RRs in a Response
+
+   When responding to a query that has the DO bit set and that requests
+   the SOA or NS RRs at the apex of a signed zone, a security-aware
+   authoritative name server for that zone MAY return the zone apex
+   DNSKEY RRset in the Additional section.  In this situation, the
+   DNSKEY RRset and associated RRSIG RRs have lower priority than does
+   any other information that would be placed in the additional section.
+   The name server SHOULD NOT include the DNSKEY RRset unless there is
+   enough space in the response message for both the DNSKEY RRset and
+   its associated RRSIG RR(s).  If there is not enough space to include
+   these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
+   NOT set the TC bit solely because these RRs didn't fit (see Section
+   3.1.1).
+
+3.1.3.  Including NSEC RRs in a Response
+
+   When responding to a query that has the DO bit set, a security-aware
+   authoritative name server for a signed zone MUST include NSEC RRs in
+   each of the following cases:
+
+   No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>
+      but does not contain any RRsets that exactly match <SNAME, SCLASS,
+      STYPE>.
+
+   Name Error: The zone does not contain any RRsets that match <SNAME,
+      SCLASS> either exactly or via wildcard name expansion.
+
+   Wildcard Answer: The zone does not contain any RRsets that exactly
+      match <SNAME, SCLASS> but does contain an RRset that matches
+      <SNAME, SCLASS, STYPE> via wildcard name expansion.
+
+   Wildcard No Data: The zone does not contain any RRsets that exactly
+      match <SNAME, SCLASS> and does contain one or more RRsets that
+      match <SNAME, SCLASS> via wildcard name expansion, but does not
+      contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard
+      name expansion.
+
+   In each of these cases, the name server includes NSEC RRs in the
+   response to prove that an exact match for <SNAME, SCLASS, STYPE> was
+   not present in the zone and that the response that the name server is
+   returning is correct given the data in the zone.
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 11]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+3.1.3.1.  Including NSEC RRs: No Data Response
+
+   If the zone contains RRsets matching <SNAME, SCLASS> but contains no
+   RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
+   include the NSEC RR for <SNAME, SCLASS> along with its associated
+   RRSIG RR(s) in the Authority section of the response (see Section
+   3.1.1).  If space does not permit inclusion of the NSEC RR or its
+   associated RRSIG RR(s), the name server MUST set the TC bit (see
+   Section 3.1.1).
+
+   Since the search name exists, wildcard name expansion does not apply
+   to this query, and a single signed NSEC RR suffices to prove that the
+   requested RR type does not exist.
+
+3.1.3.2.  Including NSEC RRs: Name Error Response
+
+   If the zone does not contain any RRsets matching <SNAME, SCLASS>
+   either exactly or via wildcard name expansion, then the name server
+   MUST include the following NSEC RRs in the Authority section, along
+   with their associated RRSIG RRs:
+
+   o  An NSEC RR proving that there is no exact match for <SNAME,
+      SCLASS>.
+
+   o  An NSEC RR proving that the zone contains no RRsets that would
+      match <SNAME, SCLASS> via wildcard name expansion.
+
+   In some cases, a single NSEC RR may prove both of these points.  If
+   it does, the name server SHOULD only include the NSEC RR and its
+   RRSIG RR(s) once in the Authority section.
+
+   If space does not permit inclusion of these NSEC and RRSIG RRs, the
+   name server MUST set the TC bit (see Section 3.1.1).
+
+   The owner names of these NSEC and RRSIG RRs are not subject to
+   wildcard name expansion when these RRs are included in the Authority
+   section of the response.
+
+   Note that this form of response includes cases in which SNAME
+   corresponds to an empty non-terminal name within the zone (a name
+   that is not the owner name for any RRset but that is the parent name
+   of one or more RRsets).
+
+3.1.3.3.  Including NSEC RRs: Wildcard Answer Response
+
+   If the zone does not contain any RRsets that exactly match <SNAME,
+   SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE>
+   via wildcard name expansion, the name server MUST include the
+
+
+
+Arends, et al.              Standards Track                    [Page 12]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   wildcard-expanded answer and the corresponding wildcard-expanded
+   RRSIG RRs in the Answer section and MUST include in the Authority
+   section an NSEC RR and associated RRSIG RR(s) proving that the zone
+   does not contain a closer match for <SNAME, SCLASS>.  If space does
+   not permit inclusion of the answer, NSEC and RRSIG RRs, the name
+   server MUST set the TC bit (see Section 3.1.1).
+
+3.1.3.4.  Including NSEC RRs: Wildcard No Data Response
+
+   This case is a combination of the previous cases.  The zone does not
+   contain an exact match for <SNAME, SCLASS>, and although the zone
+   does contain RRsets that match <SNAME, SCLASS> via wildcard
+   expansion, none of those RRsets matches STYPE.  The name server MUST
+   include the following NSEC RRs in the Authority section, along with
+   their associated RRSIG RRs:
+
+   o  An NSEC RR proving that there are no RRsets matching STYPE at the
+      wildcard owner name that matched <SNAME, SCLASS> via wildcard
+      expansion.
+
+   o  An NSEC RR proving that there are no RRsets in the zone that would
+      have been a closer match for <SNAME, SCLASS>.
+
+   In some cases, a single NSEC RR may prove both of these points.  If
+   it does, the name server SHOULD only include the NSEC RR and its
+   RRSIG RR(s) once in the Authority section.
+
+   The owner names of these NSEC and RRSIG RRs are not subject to
+   wildcard name expansion when these RRs are included in the Authority
+   section of the response.
+
+   If space does not permit inclusion of these NSEC and RRSIG RRs, the
+   name server MUST set the TC bit (see Section 3.1.1).
+
+3.1.3.5.  Finding the Right NSEC RRs
+
+   As explained above, there are several situations in which a
+   security-aware authoritative name server has to locate an NSEC RR
+   that proves that no RRsets matching a particular SNAME exist.
+   Locating such an NSEC RR within an authoritative zone is relatively
+   simple, at least in concept.  The following discussion assumes that
+   the name server is authoritative for the zone that would have held
+   the non-existent RRsets matching SNAME.  The algorithm below is
+   written for clarity, not for efficiency.
+
+   To find the NSEC that proves that no RRsets matching name N exist in
+   the zone Z that would have held them, construct a sequence, S,
+   consisting of the owner names of every RRset in Z, sorted into
+
+
+
+Arends, et al.              Standards Track                    [Page 13]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   canonical order ([RFC4034]), with no duplicate names.  Find the name
+   M that would have immediately preceded N in S if any RRsets with
+   owner name N had existed.  M is the owner name of the NSEC RR that
+   proves that no RRsets exist with owner name N.
+
+   The algorithm for finding the NSEC RR that proves that a given name
+   is not covered by any applicable wildcard is similar but requires an
+   extra step.  More precisely, the algorithm for finding the NSEC
+   proving that no RRsets exist with the applicable wildcard name is
+   precisely the same as the algorithm for finding the NSEC RR that
+   proves that RRsets with any other owner name do not exist.  The part
+   that's missing is a method of determining the name of the non-
+   existent applicable wildcard.  In practice, this is easy, because the
+   authoritative name server has already checked for the presence of
+   precisely this wildcard name as part of step (1)(c) of the normal
+   lookup algorithm described in Section 4.3.2 of [RFC1034].
+
+3.1.4.  Including DS RRs in a Response
+
+   When responding to a query that has the DO bit set, a security-aware
+   authoritative name server returning a referral includes DNSSEC data
+   along with the NS RRset.
+
+   If a DS RRset is present at the delegation point, the name server
+   MUST return both the DS RRset and its associated RRSIG RR(s) in the
+   Authority section along with the NS RRset.
+
+   If no DS RRset is present at the delegation point, the name server
+   MUST return both the NSEC RR that proves that the DS RRset is not
+   present and the NSEC RR's associated RRSIG RR(s) along with the NS
+   RRset.  The name server MUST place the NS RRset before the NSEC RRset
+   and its associated RRSIG RR(s).
+
+   Including these DS, NSEC, and RRSIG RRs increases the size of
+   referral messages and may cause some or all glue RRs to be omitted.
+   If space does not permit inclusion of the DS or NSEC RRset and
+   associated RRSIG RRs, the name server MUST set the TC bit (see
+   Section 3.1.1).
+
+3.1.4.1.  Responding to Queries for DS RRs
+
+   The DS resource record type is unusual in that it appears only on the
+   parent zone's side of a zone cut.  For example, the DS RRset for the
+   delegation of "foo.example" is stored in the "example" zone rather
+   than in the "foo.example" zone.  This requires special processing
+   rules for both name servers and resolvers, as the name server for the
+   child zone is authoritative for the name at the zone cut by the
+   normal DNS rules but the child zone does not contain the DS RRset.
+
+
+
+Arends, et al.              Standards Track                    [Page 14]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   A security-aware resolver sends queries to the parent zone when
+   looking for a needed DS RR at a delegation point (see Section 4.2).
+   However, special rules are necessary to avoid confusing
+   security-oblivious resolvers which might become involved in
+   processing such a query (for example, in a network configuration that
+   forces a security-aware resolver to channel its queries through a
+   security-oblivious recursive name server).  The rest of this section
+   describes how a security-aware name server processes DS queries in
+   order to avoid this problem.
+
+   The need for special processing by a security-aware name server only
+   arises when all the following conditions are met:
+
+   o  The name server has received a query for the DS RRset at a zone
+      cut.
+
+   o  The name server is authoritative for the child zone.
+
+   o  The name server is not authoritative for the parent zone.
+
+   o  The name server does not offer recursion.
+
+   In all other cases, the name server either has some way of obtaining
+   the DS RRset or could not have been expected to have the DS RRset
+   even by the pre-DNSSEC processing rules, so the name server can
+   return either the DS RRset or an error response according to the
+   normal processing rules.
+
+   If all the above conditions are met, however, the name server is
+   authoritative for SNAME but cannot supply the requested RRset.  In
+   this case, the name server MUST return an authoritative "no data"
+   response showing that the DS RRset does not exist in the child zone's
+   apex.  See Appendix B.8 for an example of such a response.
+
+3.1.5.  Responding to Queries for Type AXFR or IXFR
+
+   DNSSEC does not change the DNS zone transfer process.  A signed zone
+   will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
+   records have no special meaning with respect to a zone transfer
+   operation.
+
+   An authoritative name server is not required to verify that a zone is
+   properly signed before sending or accepting a zone transfer.
+   However, an authoritative name server MAY choose to reject the entire
+   zone transfer if the zone fails to meet any of the signing
+   requirements described in Section 2.  The primary objective of a zone
+   transfer is to ensure that all authoritative name servers have
+   identical copies of the zone.  An authoritative name server that
+
+
+
+Arends, et al.              Standards Track                    [Page 15]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   chooses to perform its own zone validation MUST NOT selectively
+   reject some RRs and accept others.
+
+   DS RRsets appear only on the parental side of a zone cut and are
+   authoritative data in the parent zone.  As with any other
+   authoritative RRset, the DS RRset MUST be included in zone transfers
+   of the zone in which the RRset is authoritative data.  In the case of
+   the DS RRset, this is the parent zone.
+
+   NSEC RRs appear in both the parent and child zones at a zone cut and
+   are authoritative data in both the parent and child zones.  The
+   parental and child NSEC RRs at a zone cut are never identical to each
+   other, as the NSEC RR in the child zone's apex will always indicate
+   the presence of the child zone's SOA RR whereas the parental NSEC RR
+   at the zone cut will never indicate the presence of an SOA RR.  As
+   with any other authoritative RRs, NSEC RRs MUST be included in zone
+   transfers of the zone in which they are authoritative data.  The
+   parental NSEC RR at a zone cut MUST be included in zone transfers of
+   the parent zone, and the NSEC at the zone apex of the child zone MUST
+   be included in zone transfers of the child zone.
+
+   RRSIG RRs appear in both the parent and child zones at a zone cut and
+   are authoritative in whichever zone contains the authoritative RRset
+   for which the RRSIG RR provides the signature.  That is, the RRSIG RR
+   for a DS RRset or a parental NSEC RR at a zone cut will be
+   authoritative in the parent zone, and the RRSIG for any RRset in the
+   child zone's apex will be authoritative in the child zone.  Parental
+   and child RRSIG RRs at a zone cut will never be identical to each
+   other, as the Signer's Name field of an RRSIG RR in the child zone's
+   apex will indicate a DNSKEY RR in the child zone's apex whereas the
+   same field of a parental RRSIG RR at the zone cut will indicate a
+   DNSKEY RR in the parent zone's apex.  As with any other authoritative
+   RRs, RRSIG RRs MUST be included in zone transfers of the zone in
+   which they are authoritative data.
+
+3.1.6.  The AD and CD Bits in an Authoritative Response
+
+   The CD and AD bits are designed for use in communication between
+   security-aware resolvers and security-aware recursive name servers.
+   These bits are for the most part not relevant to query processing by
+   security-aware authoritative name servers.
+
+   A security-aware name server does not perform signature validation
+   for authoritative data during query processing, even when the CD bit
+   is clear.  A security-aware name server SHOULD clear the CD bit when
+   composing an authoritative response.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 16]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   A security-aware name server MUST NOT set the AD bit in a response
+   unless the name server considers all RRsets in the Answer and
+   Authority sections of the response to be authentic.  A security-aware
+   name server's local policy MAY consider data from an authoritative
+   zone to be authentic without further validation.  However, the name
+   server MUST NOT do so unless the name server obtained the
+   authoritative zone via secure means (such as a secure zone transfer
+   mechanism) and MUST NOT do so unless this behavior has been
+   configured explicitly.
+
+   A security-aware name server that supports recursion MUST follow the
+   rules for the CD and AD bits given in Section 3.2 when generating a
+   response that involves data obtained via recursion.
+
+3.2.  Recursive Name Servers
+
+   As explained in [RFC4033], a security-aware recursive name server is
+   an entity that acts in both the security-aware name server and
+   security-aware resolver roles.  This section uses the terms "name
+   server side" and "resolver side" to refer to the code within a
+   security-aware recursive name server that implements the
+   security-aware name server role and the code that implements the
+   security-aware resolver role, respectively.
+
+   The resolver side follows the usual rules for caching and negative
+   caching that would apply to any security-aware resolver.
+
+3.2.1.  The DO Bit
+
+   The resolver side of a security-aware recursive name server MUST set
+   the DO bit when sending requests, regardless of the state of the DO
+   bit in the initiating request received by the name server side.  If
+   the DO bit in an initiating query is not set, the name server side
+   MUST strip any authenticating DNSSEC RRs from the response but MUST
+   NOT strip any DNSSEC RR types that the initiating query explicitly
+   requested.
+
+3.2.2.  The CD Bit
+
+   The CD bit exists in order to allow a security-aware resolver to
+   disable signature validation in a security-aware name server's
+   processing of a particular query.
+
+   The name server side MUST copy the setting of the CD bit from a query
+   to the corresponding response.
+
+   The name server side of a security-aware recursive name server MUST
+   pass the state of the CD bit to the resolver side along with the rest
+
+
+
+Arends, et al.              Standards Track                    [Page 17]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   of an initiating query, so that the resolver side will know whether
+   it is required to verify the response data it returns to the name
+   server side.  If the CD bit is set, it indicates that the originating
+   resolver is willing to perform whatever authentication its local
+   policy requires.  Thus, the resolver side of the recursive name
+   server need not perform authentication on the RRsets in the response.
+   When the CD bit is set, the recursive name server SHOULD, if
+   possible, return the requested data to the originating resolver, even
+   if the recursive name server's local authentication policy would
+   reject the records in question.  That is, by setting the CD bit, the
+   originating resolver has indicated that it takes responsibility for
+   performing its own authentication, and the recursive name server
+   should not interfere.
+
+   If the resolver side implements a BAD cache (see Section 4.7) and the
+   name server side receives a query that matches an entry in the
+   resolver side's BAD cache, the name server side's response depends on
+   the state of the CD bit in the original query.  If the CD bit is set,
+   the name server side SHOULD return the data from the BAD cache; if
+   the CD bit is not set, the name server side MUST return RCODE 2
+   (server failure).
+
+   The intent of the above rule is to provide the raw data to clients
+   that are capable of performing their own signature verification
+   checks while protecting clients that depend on the resolver side of a
+   security-aware recursive name server to perform such checks.  Several
+   of the possible reasons why signature validation might fail involve
+   conditions that may not apply equally to the recursive name server
+   and the client that invoked it.  For example, the recursive name
+   server's clock may be set incorrectly, or the client may have
+   knowledge of a relevant island of security that the recursive name
+   server does not share.  In such cases, "protecting" a client that is
+   capable of performing its own signature validation from ever seeing
+   the "bad" data does not help the client.
+
+3.2.3.  The AD Bit
+
+   The name server side of a security-aware recursive name server MUST
+   NOT set the AD bit in a response unless the name server considers all
+   RRsets in the Answer and Authority sections of the response to be
+   authentic.  The name server side SHOULD set the AD bit if and only if
+   the resolver side considers all RRsets in the Answer section and any
+   relevant negative response RRs in the Authority section to be
+   authentic.  The resolver side MUST follow the procedure described in
+   Section 5 to determine whether the RRs in question are authentic.
+   However, for backward compatibility, a recursive name server MAY set
+   the AD bit when a response includes unsigned CNAME RRs if those CNAME
+
+
+
+
+Arends, et al.              Standards Track                    [Page 18]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   RRs demonstrably could have been synthesized from an authentic DNAME
+   RR that is also included in the response according to the synthesis
+   rules described in [RFC2672].
+
+3.3.  Example DNSSEC Responses
+
+   See Appendix B for example response packets.
+
+4.  Resolving
+
+   This section describes the behavior of entities that include
+   security-aware resolver functions.  In many cases such functions will
+   be part of a security-aware recursive name server, but a stand-alone
+   security-aware resolver has many of the same requirements.  Functions
+   specific to security-aware recursive name servers are described in
+   Section 3.2.
+
+4.1.  EDNS Support
+
+   A security-aware resolver MUST include an EDNS ([RFC2671]) OPT
+   pseudo-RR with the DO ([RFC3225]) bit set when sending queries.
+
+   A security-aware resolver MUST support a message size of at least
+   1220 octets, SHOULD support a message size of 4000 octets, and MUST
+   use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR
+   to advertise the message size that it is willing to accept.  A
+   security-aware resolver's IP layer MUST handle fragmented UDP packets
+   correctly regardless of whether any such fragmented packets were
+   received via IPv4 or IPv6.  Please see [RFC1122], [RFC2460], and
+   [RFC3226] for discussion of these requirements.
+
+4.2.  Signature Verification Support
+
+   A security-aware resolver MUST support the signature verification
+   mechanisms described in Section 5 and SHOULD apply them to every
+   received response, except when:
+
+   o  the security-aware resolver is part of a security-aware recursive
+      name server, and the response is the result of recursion on behalf
+      of a query received with the CD bit set;
+
+   o  the response is the result of a query generated directly via some
+      form of application interface that instructed the security-aware
+      resolver not to perform validation for this query; or
+
+   o  validation for this query has been disabled by local policy.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 19]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   A security-aware resolver's support for signature verification MUST
+   include support for verification of wildcard owner names.
+
+   Security-aware resolvers MAY query for missing security RRs in an
+   attempt to perform validation; implementations that choose to do so
+   must be aware that the answers received may not be sufficient to
+   validate the original response.  For example, a zone update may have
+   changed (or deleted) the desired information between the original and
+   follow-up queries.
+
+   When attempting to retrieve missing NSEC RRs that reside on the
+   parental side at a zone cut, a security-aware iterative-mode resolver
+   MUST query the name servers for the parent zone, not the child zone.
+
+   When attempting to retrieve a missing DS, a security-aware
+   iterative-mode resolver MUST query the name servers for the parent
+   zone, not the child zone.  As explained in Section 3.1.4.1,
+   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.  To
+   locate the parent NS RRset, the resolver can start with the
+   delegation name, strip off the leftmost label, and query for an NS
+   RRset by that name.  If no NS RRset is present at that name, the
+   resolver then strips off the leftmost remaining label and retries the
+   query for that name, repeating this process of walking up the tree
+   until it either finds the NS RRset or runs out of labels.
+
+4.3.  Determining Security Status of Data
+
+   A security-aware resolver MUST be able to determine whether it should
+   expect a particular RRset to be signed.  More precisely, a
+   security-aware resolver must be able to distinguish between four
+   cases:
+
+   Secure: An RRset for which the resolver is able to build a chain of
+      signed DNSKEY and DS RRs from a trusted security anchor to the
+      RRset.  In this case, the RRset should be signed and is subject to
+      signature validation, as described above.
+
+   Insecure: An RRset for which the resolver knows that it has no chain
+      of signed DNSKEY and DS RRs from any trusted starting point to the
+      RRset.  This can occur when the target RRset lies in an unsigned
+      zone or in a descendent of an unsigned zone.  In this case, the
+      RRset may or may not be signed, but the resolver will not be able
+      to verify the signature.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 20]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   Bogus: An RRset for which the resolver believes that it ought to be
+      able to establish a chain of trust but for which it is unable to
+      do so, either due to signatures that for some reason fail to
+      validate or due to missing data that the relevant DNSSEC RRs
+      indicate should be present.  This case may indicate an attack but
+      may also indicate a configuration error or some form of data
+      corruption.
+
+   Indeterminate: An RRset for which the resolver is not able to
+      determine whether the RRset should be signed, as the resolver is
+      not able to obtain the necessary DNSSEC RRs.  This can occur when
+      the security-aware resolver is not able to contact security-aware
+      name servers for the relevant zones.
+
+4.4.  Configured Trust Anchors
+
+   A security-aware resolver MUST be capable of being configured with at
+   least one trusted public key or DS RR and SHOULD be capable of being
+   configured with multiple trusted public keys or DS RRs.  Since a
+   security-aware resolver will not be able to validate signatures
+   without such a configured trust anchor, the resolver SHOULD have some
+   reasonably robust mechanism for obtaining such keys when it boots;
+   examples of such a mechanism would be some form of non-volatile
+   storage (such as a disk drive) or some form of trusted local network
+   configuration mechanism.
+
+   Note that trust anchors also cover key material that is updated in a
+   secure manner.  This secure manner could be through physical media, a
+   key exchange protocol, or some other out-of-band means.
+
+4.5.  Response Caching
+
+   A security-aware resolver SHOULD cache each response as a single
+   atomic entry containing the entire answer, including the named RRset
+   and any associated DNSSEC RRs.  The resolver SHOULD discard the
+   entire atomic entry when any of the RRs contained in it expire.  In
+   most cases the appropriate cache index for the atomic entry will be
+   the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
+   form described in Section 3.1.3.2 the appropriate cache index will be
+   the double <QNAME,QCLASS>.
+
+   The reason for these recommendations is that, between the initial
+   query and the expiration of the data from the cache, the
+   authoritative data might have been changed (for example, via dynamic
+   update).
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 21]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   There are two situations for which this is relevant:
+
+   1.  By using the RRSIG record, it is possible to deduce that an
+       answer was synthesized from a wildcard.  A security-aware
+       recursive name server could store this wildcard data and use it
+       to generate positive responses to queries other than the name for
+       which the original answer was first received.
+
+   2.  NSEC RRs received to prove the non-existence of a name could be
+       reused by a security-aware resolver to prove the non-existence of
+       any name in the name range it spans.
+
+   In theory, a resolver could use wildcards or NSEC RRs to generate
+   positive and negative responses (respectively) until the TTL or
+   signatures on the records in question expire.  However, it seems
+   prudent for resolvers to avoid blocking new authoritative data or
+   synthesizing new data on their own.  Resolvers that follow this
+   recommendation will have a more consistent view of the namespace.
+
+4.6.  Handling of the CD and AD Bits
+
+   A security-aware resolver MAY set a query's CD bit in order to
+   indicate that the resolver takes responsibility for performing
+   whatever authentication its local policy requires on the RRsets in
+   the response.  See Section 3.2 for the effect this bit has on the
+   behavior of security-aware recursive name servers.
+
+   A security-aware resolver MUST clear the AD bit when composing query
+   messages to protect against buggy name servers that blindly copy
+   header bits that they do not understand from the query message to the
+   response message.
+
+   A resolver MUST disregard the meaning of the CD and AD bits in a
+   response unless the response was obtained by using a secure channel
+   or the resolver was specifically configured to regard the message
+   header bits without using a secure channel.
+
+4.7.  Caching BAD Data
+
+   While many validation errors will be transient, some are likely to be
+   more persistent, such as those caused by administrative error
+   (failure to re-sign a zone, clock skew, and so forth).  Since
+   requerying will not help in these cases, validating resolvers might
+   generate a significant amount of unnecessary DNS traffic as a result
+   of repeated queries for RRsets with persistent validation failures.
+
+   To prevent such unnecessary DNS traffic, security-aware resolvers MAY
+   cache data with invalid signatures, with some restrictions.
+
+
+
+Arends, et al.              Standards Track                    [Page 22]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   Conceptually, caching such data is similar to negative caching
+   ([RFC2308]), except that instead of caching a valid negative
+   response, the resolver is caching the fact that a particular answer
+   failed to validate.  This document refers to a cache of data with
+   invalid signatures as a "BAD cache".
+
+   Resolvers that implement a BAD cache MUST take steps to prevent the
+   cache from being useful as a denial-of-service attack amplifier,
+   particularly the following:
+
+   o  Since RRsets that fail to validate do not have trustworthy TTLs,
+      the implementation MUST assign a TTL.  This TTL SHOULD be small,
+      in order to mitigate the effect of caching the results of an
+      attack.
+
+   o  In order to prevent caching of a transient validation failure
+      (which might be the result of an attack), resolvers SHOULD track
+      queries that result in validation failures and SHOULD only answer
+      from the BAD cache after the number of times that responses to
+      queries for that particular <QNAME, QTYPE, QCLASS> have failed to
+      validate exceeds a threshold value.
+
+   Resolvers MUST NOT return RRsets from the BAD cache unless the
+   resolver is not required to validate the signatures of the RRsets in
+   question under the rules given in Section 4.2 of this document.  See
+   Section 3.2.2 for discussion of how the responses returned by a
+   security-aware recursive name server interact with a BAD cache.
+
+4.8.  Synthesized CNAMEs
+
+   A validating security-aware resolver MUST treat the signature of a
+   valid signed DNAME RR as also covering unsigned CNAME RRs that could
+   have been synthesized from the DNAME RR, as described in [RFC2672],
+   at least to the extent of not rejecting a response message solely
+   because it contains such CNAME RRs.  The resolver MAY retain such
+   CNAME RRs in its cache or in the answers it hands back, but is not
+   required to do so.
+
+4.9.  Stub Resolvers
+
+   A security-aware stub resolver MUST support the DNSSEC RR types, at
+   least to the extent of not mishandling responses just because they
+   contain DNSSEC RRs.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 23]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+4.9.1.  Handling of the DO Bit
+
+   A non-validating security-aware stub resolver MAY include the DNSSEC
+   RRs returned by a security-aware recursive name server as part of the
+   data that the stub resolver hands back to the application that
+   invoked it, but is not required to do so.  A non-validating stub
+   resolver that seeks to do this will need to set the DO bit in order
+   to receive DNSSEC RRs from the recursive name server.
+
+   A validating security-aware stub resolver MUST set the DO bit,
+   because otherwise it will not receive the DNSSEC RRs it needs to
+   perform signature validation.
+
+4.9.2.  Handling of the CD Bit
+
+   A non-validating security-aware stub resolver SHOULD NOT set the CD
+   bit when sending queries unless it is requested by the application
+   layer, as by definition, a non-validating stub resolver depends on
+   the security-aware recursive name server to perform validation on its
+   behalf.
+
+   A validating security-aware stub resolver SHOULD set the CD bit,
+   because otherwise the security-aware recursive name server will
+   answer the query using the name server's local policy, which may
+   prevent the stub resolver from receiving data that would be
+   acceptable to the stub resolver's local policy.
+
+4.9.3.  Handling of the AD Bit
+
+   A non-validating security-aware stub resolver MAY chose to examine
+   the setting of the AD bit in response messages that it receives in
+   order to determine whether the security-aware recursive name server
+   that sent the response claims to have cryptographically verified the
+   data in the Answer and Authority sections of the response message.
+   Note, however, that the responses received by a security-aware stub
+   resolver are heavily dependent on the local policy of the
+   security-aware recursive name server.  Therefore, there may be little
+   practical value in checking the status of the AD bit, except perhaps
+   as a debugging aid.  In any case, a security-aware stub resolver MUST
+   NOT place any reliance on signature validation allegedly performed on
+   its behalf, except when the security-aware stub resolver obtained the
+   data in question from a trusted security-aware recursive name server
+   via a secure channel.
+
+   A validating security-aware stub resolver SHOULD NOT examine the
+   setting of the AD bit in response messages, as, by definition, the
+   stub resolver performs its own signature validation regardless of the
+   setting of the AD bit.
+
+
+
+Arends, et al.              Standards Track                    [Page 24]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+5.  Authenticating DNS Responses
+
+   To use DNSSEC RRs for authentication, a security-aware resolver
+   requires configured knowledge of at least one authenticated DNSKEY or
+   DS RR.  The process for obtaining and authenticating this initial
+   trust anchor is achieved via some external mechanism.  For example, a
+   resolver could use some off-line authenticated exchange to obtain a
+   zone's DNSKEY RR or to obtain a DS RR that identifies and
+   authenticates a zone's DNSKEY RR.  The remainder of this section
+   assumes that the resolver has somehow obtained an initial set of
+   trust anchors.
+
+   An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
+   RRset.  To authenticate an apex DNSKEY RRset by using an initial key,
+   the resolver MUST:
+
+   1.  verify that the initial DNSKEY RR appears in the apex DNSKEY
+       RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA
+       bit 7) set; and
+
+   2.  verify that there is some RRSIG RR that covers the apex DNSKEY
+       RRset, and that the combination of the RRSIG RR and the initial
+       DNSKEY RR authenticates the DNSKEY RRset.  The process for using
+       an RRSIG RR to authenticate an RRset is described in Section 5.3.
+
+   Once the resolver has authenticated the apex DNSKEY RRset by using an
+   initial DNSKEY RR, delegations from that zone can be authenticated by
+   using DS RRs.  This allows a resolver to start from an initial key
+   and use DS RRsets to proceed recursively down the DNS tree, obtaining
+   other apex DNSKEY RRsets.  If the resolver were configured with a
+   root DNSKEY RR, and if every delegation had a DS RR associated with
+   it, then the resolver could obtain and validate any apex DNSKEY
+   RRset.  The process of using DS RRs to authenticate referrals is
+   described in Section 5.2.
+
+   Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
+   DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
+   RRsets in the zone once the resolver has authenticated a zone's apex
+   DNSKEY RRset.  Section 5.4 shows how the resolver can use
+   authenticated NSEC RRsets from the zone to prove that an RRset is not
+   present in the zone.
+
+   When a resolver indicates support for DNSSEC (by setting the DO bit),
+   a security-aware name server should attempt to provide the necessary
+   DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
+   However, a security-aware resolver may still receive a response that
+   lacks the appropriate DNSSEC RRs, whether due to configuration issues
+   such as an upstream security-oblivious recursive name server that
+
+
+
+Arends, et al.              Standards Track                    [Page 25]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   accidentally interferes with DNSSEC RRs or due to a deliberate attack
+   in which an adversary forges a response, strips DNSSEC RRs from a
+   response, or modifies a query so that DNSSEC RRs appear not to be
+   requested.  The absence of DNSSEC data in a response MUST NOT by
+   itself be taken as an indication that no authentication information
+   exists.
+
+   A resolver SHOULD expect authentication information from signed
+   zones.  A resolver SHOULD believe that a zone is signed if the
+   resolver has been configured with public key information for the
+   zone, or if the zone's parent is signed and the delegation from the
+   parent contains a DS RRset.
+
+5.1.  Special Considerations for Islands of Security
+
+   Islands of security (see [RFC4033]) are signed zones for which it is
+   not possible to construct an authentication chain to the zone from
+   its parent.  Validating signatures within an island of security
+   requires that the validator have some other means of obtaining an
+   initial authenticated zone key for the island.  If a validator cannot
+   obtain such a key, it SHOULD switch to operating as if the zones in
+   the island of security are unsigned.
+
+   All the normal processes for validating responses apply to islands of
+   security.  The only difference between normal validation and
+   validation within an island of security is in how the validator
+   obtains a trust anchor for the authentication chain.
+
+5.2.  Authenticating Referrals
+
+   Once the apex DNSKEY RRset for a signed parent zone has been
+   authenticated, DS RRsets can be used to authenticate the delegation
+   to a signed child zone.  A DS RR identifies a DNSKEY RR in the child
+   zone's apex DNSKEY RRset and contains a cryptographic digest of the
+   child zone's DNSKEY RR.  Use of a strong cryptographic digest
+   algorithm ensures that it is computationally infeasible for an
+   adversary to generate a DNSKEY RR that matches the digest.  Thus,
+   authenticating the digest allows a resolver to authenticate the
+   matching DNSKEY RR.  The resolver can then use this child DNSKEY RR
+   to authenticate the entire child apex DNSKEY RRset.
+
+   Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
+   can be authenticated if all of the following hold:
+
+   o  The DS RR has been authenticated using some DNSKEY RR in the
+      parent's apex DNSKEY RRset (see Section 5.3).
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 26]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   o  The Algorithm and Key Tag in the DS RR match the Algorithm field
+      and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
+      RRset, and, when the DNSKEY RR's owner name and RDATA are hashed
+      using the digest algorithm specified in the DS RR's Digest Type
+      field, the resulting digest value matches the Digest field of the
+      DS RR.
+
+   o  The matching DNSKEY RR in the child zone has the Zone Flag bit
+      set, the corresponding private key has signed the child zone's
+      apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
+      child zone's apex DNSKEY RRset.
+
+   If the referral from the parent zone did not contain a DS RRset, the
+   response should have included a signed NSEC RRset proving that no DS
+   RRset exists for the delegated name (see Section 3.1.4).  A
+   security-aware resolver MUST query the name servers for the parent
+   zone for the DS RRset if the referral includes neither a DS RRset nor
+   a NSEC RRset proving that the DS RRset does not exist (see Section
+   4).
+
+   If the validator authenticates an NSEC RRset that proves that no DS
+   RRset is present for this zone, then there is no authentication path
+   leading from the parent to the child.  If the resolver has an initial
+   DNSKEY or DS RR that belongs to the child zone or to any delegation
+   below the child zone, this initial DNSKEY or DS RR MAY be used to
+   re-establish an authentication path.  If no such initial DNSKEY or DS
+   RR exists, the validator cannot authenticate RRsets in or below the
+   child zone.
+
+   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.
+
+   Note that, for a signed delegation, there are two NSEC RRs associated
+   with the delegated name.  One NSEC RR resides in the parent zone and
+   can be used to prove whether a DS RRset exists for the delegated
+   name.  The second NSEC RR resides in the child zone and identifies
+   which RRsets are present at the apex of the child zone.  The parent
+   NSEC RR and child NSEC RR can always be distinguished because the SOA
+   bit will be set in the child NSEC RR and clear in the parent NSEC RR.
+   A security-aware resolver MUST use the parent NSEC RR when attempting
+   to prove that a DS RRset does not exist.
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 27]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   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.
+
+5.3.  Authenticating an RRset with an RRSIG RR
+
+   A validator can use an RRSIG RR and its corresponding DNSKEY RR to
+   attempt to authenticate RRsets.  The validator first checks the RRSIG
+   RR to verify that it covers the RRset, has a valid time interval, and
+   identifies a valid DNSKEY RR.  The validator then constructs the
+   canonical form of the signed data by appending the RRSIG RDATA
+   (excluding the Signature Field) with the canonical form of the
+   covered RRset.  Finally, the validator uses the public key and
+   signature to authenticate the signed data.  Sections 5.3.1, 5.3.2,
+   and 5.3.3 describe each step in detail.
+
+5.3.1.  Checking the RRSIG RR Validity
+
+   A security-aware resolver can use an RRSIG RR to authenticate an
+   RRset if all of the following conditions hold:
+
+   o  The RRSIG RR and the RRset MUST have the same owner name and the
+      same class.
+
+   o  The RRSIG RR's Signer's Name field MUST be the name of the zone
+      that contains the RRset.
+
+   o  The RRSIG RR's Type Covered field MUST equal the RRset's type.
+
+   o  The number of labels in the RRset owner name MUST be greater than
+      or equal to the value in the RRSIG RR's Labels field.
+
+   o  The validator's notion of the current time MUST be less than or
+      equal to the time listed in the RRSIG RR's Expiration field.
+
+   o  The validator's notion of the current time MUST be greater than or
+      equal to the time listed in the RRSIG RR's Inception field.
+
+   o  The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
+      match the owner name, algorithm, and key tag for some DNSKEY RR in
+      the zone's apex DNSKEY RRset.
+
+   o  The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
+      RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
+      set.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 28]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   It is possible for more than one DNSKEY RR to match the conditions
+   above.  In this case, the validator cannot predetermine which DNSKEY
+   RR to use to authenticate the signature, and it MUST try each
+   matching DNSKEY RR until either the signature is validated or the
+   validator has run out of matching public keys to try.
+
+   Note that this authentication process is only meaningful if the
+   validator authenticates the DNSKEY RR before using it to validate
+   signatures.  The matching DNSKEY RR is considered to be authentic if:
+
+   o  the apex DNSKEY RRset containing the DNSKEY RR is considered
+      authentic; or
+
+   o  the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
+      and the DNSKEY RR either matches an authenticated DS RR from the
+      parent zone or matches a trust anchor.
+
+5.3.2.  Reconstructing the Signed Data
+
+   Once the RRSIG RR has met the validity requirements described in
+   Section 5.3.1, the validator has to reconstruct the original signed
+   data.  The original signed data includes RRSIG RDATA (excluding the
+   Signature field) and the canonical form of the RRset.  Aside from
+   being ordered, the canonical form of the RRset might also differ from
+   the received RRset due to DNS name compression, decremented TTLs, or
+   wildcard expansion.  The validator should use the following to
+   reconstruct the original signed data:
+
+         signed_data = RRSIG_RDATA | RR(1) | RR(2)...  where
+
+            "|" denotes concatenation
+
+            RRSIG_RDATA is the wire format of the RRSIG RDATA fields
+               with the Signature field excluded and the Signer's Name
+               in canonical form.
+
+            RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
+
+               name is calculated according to the function below
+
+               class is the RRset's class
+
+               type is the RRset type and all RRs in the class
+
+               OrigTTL is the value from the RRSIG Original TTL field
+
+               All names in the RDATA field are in canonical form
+
+
+
+
+Arends, et al.              Standards Track                    [Page 29]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+               The set of all RR(i) is sorted into canonical order.
+
+            To calculate the name:
+               let rrsig_labels = the value of the RRSIG Labels field
+
+               let fqdn = RRset's fully qualified domain name in
+                               canonical form
+
+               let fqdn_labels = Label count of the fqdn above.
+
+               if rrsig_labels = fqdn_labels,
+                   name = fqdn
+
+               if rrsig_labels < fqdn_labels,
+                  name = "*." | the rightmost rrsig_label labels of the
+                                fqdn
+
+               if rrsig_labels > fqdn_labels
+                  the RRSIG RR did not pass the necessary validation
+                  checks and MUST NOT be used to authenticate this
+                  RRset.
+
+   The canonical forms for names and RRsets are defined in [RFC4034].
+
+   NSEC RRsets at a delegation boundary require special processing.
+   There are two distinct NSEC RRsets associated with a signed delegated
+   name.  One NSEC RRset resides in the parent zone, and specifies which
+   RRsets are present at the parent zone.  The second NSEC RRset resides
+   at the child zone and identifies which RRsets are present at the apex
+   in the child zone.  The parent NSEC RRset and child NSEC RRset can
+   always be distinguished as only a child NSEC RR will indicate that an
+   SOA RRset exists at the name.  When reconstructing the original NSEC
+   RRset for the delegation from the parent zone, the NSEC RRs MUST NOT
+   be combined with NSEC RRs from the child zone.  When reconstructing
+   the original NSEC RRset for the apex of the child zone, the NSEC RRs
+   MUST NOT be combined with NSEC RRs from the parent zone.
+
+   Note that each of the two NSEC RRsets at a delegation point has a
+   corresponding RRSIG RR with an owner name matching the delegated
+   name, and each of these RRSIG RRs is authoritative data associated
+   with the same zone that contains the corresponding NSEC RRset.  If
+   necessary, a resolver can tell these RRSIG RRs apart by checking the
+   Signer's Name field.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 30]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+5.3.3.  Checking the Signature
+
+   Once the resolver has validated the RRSIG RR as described in Section
+   5.3.1 and reconstructed the original signed data as described in
+   Section 5.3.2, the validator can attempt to use the cryptographic
+   signature to authenticate the signed data, and thus (finally!)
+   authenticate the RRset.
+
+   The Algorithm field in the RRSIG RR identifies the cryptographic
+   algorithm used to generate the signature.  The signature itself is
+   contained in the Signature field of the RRSIG RDATA, and the public
+   key used to verify the signature is contained in the Public Key field
+   of the matching DNSKEY RR(s) (found in Section 5.3.1).  [RFC4034]
+   provides a list of algorithm types and provides pointers to the
+   documents that define each algorithm's use.
+
+   Note that it is possible for more than one DNSKEY RR to match the
+   conditions in Section 5.3.1.  In this case, the validator can only
+   determine which DNSKEY RR is correct by trying each matching public
+   key until the validator either succeeds in validating the signature
+   or runs out of keys to try.
+
+   If the Labels field of the RRSIG RR is not equal to the number of
+   labels in the RRset's fully qualified owner name, then the RRset is
+   either invalid or the result of wildcard expansion.  The resolver
+   MUST verify that wildcard expansion was applied properly before
+   considering the RRset to be authentic.  Section 5.3.4 describes how
+   to determine whether a wildcard was applied properly.
+
+   If other RRSIG RRs also cover this RRset, 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.
+
+   If the resolver accepts the RRset as authentic, the validator MUST
+   set the TTL of the RRSIG RR and each RR in the authenticated RRset to
+   a value no greater than the minimum of:
+
+   o  the RRset's TTL as received in the response;
+
+   o  the RRSIG RR's TTL as received in the response;
+
+   o  the value in the RRSIG RR's Original TTL field; and
+
+   o  the difference of the RRSIG RR's Signature Expiration time and the
+      current time.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 31]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+5.3.4.  Authenticating a Wildcard Expanded RRset Positive Response
+
+   If the number of labels in an RRset's owner name is greater than the
+   Labels field of the covering RRSIG RR, then the RRset and its
+   covering RRSIG RR were created as a result of wildcard expansion.
+   Once the validator has verified the signature, as described in
+   Section 5.3, it must take additional steps to verify the non-
+   existence of an exact match or closer wildcard match for the query.
+   Section 5.4 discusses these steps.
+
+   Note that the response received by the resolver should include all
+   NSEC RRs needed to authenticate the response (see Section 3.1.3).
+
+5.4.  Authenticated Denial of Existence
+
+   A resolver can use authenticated NSEC RRs to prove that an RRset is
+   not present in a signed zone.  Security-aware name servers should
+   automatically include any necessary NSEC RRs for signed zones in
+   their responses to security-aware resolvers.
+
+   Denial of existence is determined by the following rules:
+
+   o  If the requested RR name matches the owner name of an
+      authenticated NSEC RR, then the NSEC RR's type bit map field lists
+      all RR types present at that owner name, and a resolver can prove
+      that the requested RR type does not exist by checking for the RR
+      type in the bit map.  If the number of labels in an authenticated
+      NSEC RR's owner name equals the Labels field of the covering RRSIG
+      RR, then the existence of the NSEC RR proves that wildcard
+      expansion could not have been used to match the request.
+
+   o  If the requested RR name would appear after an authenticated NSEC
+      RR's owner name and before the name listed in that NSEC RR's Next
+      Domain Name field according to the canonical DNS name order
+      defined in [RFC4034], then no RRsets with the requested name exist
+      in the zone.  However, it is possible that a wildcard could be
+      used to match the requested RR owner name and type, so proving
+      that the requested RRset does not exist also requires proving that
+      no possible wildcard RRset exists that could have been used to
+      generate a positive response.
+
+   In addition, security-aware resolvers MUST authenticate the NSEC
+   RRsets that comprise the non-existence proof as described in Section
+   5.3.
+
+   To prove the non-existence of an RRset, the resolver must be able to
+   verify both that the queried RRset does not exist and that no
+   relevant wildcard RRset exists.  Proving this may require more than
+
+
+
+Arends, et al.              Standards Track                    [Page 32]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   one NSEC RRset from the zone.  If the complete set of necessary NSEC
+   RRsets is not present in a response (perhaps due to message
+   truncation), then a security-aware resolver MUST resend the query in
+   order to attempt to obtain the full collection of NSEC RRs necessary
+   to verify the non-existence of the requested RRset.  As with all DNS
+   operations, however, the resolver MUST bound the work it puts into
+   answering any particular query.
+
+   Since a validated NSEC RR proves the existence of both itself and its
+   corresponding RRSIG RR, a validator MUST ignore the settings of the
+   NSEC and RRSIG bits in an NSEC RR.
+
+5.5.  Resolver Behavior When Signatures Do Not Validate
+
+   If for whatever reason none of the RRSIGs can be validated, the
+   response SHOULD be considered BAD.  If the validation was being done
+   to service a recursive query, the name server MUST return RCODE 2 to
+   the originating client.  However, it MUST return the full response if
+   and only if the original query had the CD bit set.  Also see Section
+   4.7 on caching responses that do not validate.
+
+5.6.  Authentication Example
+
+   Appendix C shows an example of the authentication process.
+
+6.  IANA Considerations
+
+   [RFC4034] contains a review of the IANA considerations introduced by
+   DNSSEC.  The following are additional IANA considerations discussed
+   in this document:
+
+   [RFC2535] reserved the CD and AD bits in the message header.  The
+   meaning of the AD bit was redefined in [RFC3655], and the meaning of
+   both the CD and AD bit are restated in this document.  No new bits in
+   the DNS message header are defined in this document.
+
+   [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit
+   and defined its use.  The use is restated but not altered in this
+   document.
+
+7.  Security Considerations
+
+   This document describes how the DNS security extensions use public
+   key cryptography to sign and authenticate DNS resource record sets.
+   Please see [RFC4033] for terminology and general security
+   considerations related to DNSSEC; see [RFC4034] for considerations
+   specific to the DNSSEC resource record types.
+
+
+
+
+Arends, et al.              Standards Track                    [Page 33]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   An active attacker who can set the CD bit in a DNS query message or
+   the AD bit in a DNS response message can use these bits to defeat the
+   protection that DNSSEC attempts to provide to security-oblivious
+   recursive-mode resolvers.  For this reason, use of these control bits
+   by a security-aware recursive-mode resolver requires a secure
+   channel.  See Sections 3.2.2 and 4.9 for further discussion.
+
+   The protocol described in this document attempts to extend the
+   benefits of DNSSEC to security-oblivious stub resolvers.  However, as
+   recovery from validation failures is likely to be specific to
+   particular applications, the facilities that DNSSEC provides for stub
+   resolvers may prove inadequate.  Operators of security-aware
+   recursive name servers will have to pay close attention to the
+   behavior of the applications that use their services when choosing a
+   local validation policy; failure to do so could easily result in the
+   recursive name server accidentally denying service to the clients it
+   is intended to support.
+
+8.  Acknowledgements
+
+   This document was created from the input and ideas of the members of
+   the DNS Extensions Working Group and working group mailing list.  The
+   editors would like to express their thanks for the comments and
+   suggestions received during the revision of these security extension
+   specifications.  Although explicitly listing everyone who has
+   contributed during the decade in which DNSSEC has been under
+   development would be impossible, [RFC4033] includes a list of some of
+   the participants who were kind enough to comment on these documents.
+
+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.
+
+   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
+              Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [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.
+
+
+
+
+Arends, et al.              Standards Track                    [Page 34]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+              2671, August 1999.
+
+   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection", RFC
+              2672, August 1999.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+              3225, December 2001.
+
+   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
+              message size requirements", RFC 3226, December 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 DNS Security Extensions", RFC
+              4034, March 2005.
+
+9.2.  Informative References
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, March 1998.
+
+   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
+              Extensions", RFC 2535, March 1999.
+
+   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+              Update", RFC 3007, November 2000.
+
+   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+              Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 35]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+Appendix A.  Signed Zone Example
+
+   The following example shows a (small) complete signed zone.
+
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+                  3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+                  3600 NS     ns1.example.
+                  3600 NS     ns2.example.
+                  3600 RRSIG  NS 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+                  3600 MX     1 xx.example.
+                  3600 RRSIG  MX 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB
+                              2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE
+                              VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO
+                              6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM
+                              W6OISukd1EQt7a0kygkg+PEDxdI= )
+                  3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
+                  3600 RRSIG  NSEC 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+                  3600 DNSKEY 256 3 5 (
+                              AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
+                              rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
+                              k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
+                              vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
+
+
+
+Arends, et al.              Standards Track                    [Page 36]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
+                              )
+                  3600 DNSKEY 257 3 5 (
+                              AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
+                              LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
+                              syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
+                              RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
+                              Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
+                              )
+                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
+                              20040409183619 9465 example.
+                              ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
+                              xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
+                              XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
+                              hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
+                              NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
+                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
+                              DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
+                              bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
+                              eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
+                              7z5OXogYVaFzHKillDt3HRxHIZM= )
+   a.example.     3600 IN NS  ns1.a.example.
+                  3600 IN NS  ns2.a.example.
+                  3600 DS     57855 5 1 (
+                              B6DCD485719ADCA18E5F3D48A2331627FDD3
+                              636B )
+                  3600 RRSIG  DS 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
+                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
+                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
+                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
+                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
+                  3600 NSEC   ai.example. NS DS RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba
+                              U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2
+                              039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I
+                              BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g
+                              sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )
+   ns1.a.example. 3600 IN A   192.0.2.5
+   ns2.a.example. 3600 IN A   192.0.2.6
+   ai.example.    3600 IN A   192.0.2.9
+                  3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+
+
+
+Arends, et al.              Standards Track                    [Page 37]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
+                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
+                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
+                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
+                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
+                  3600 HINFO  "KLH-10" "ITS"
+                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
+                              e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
+                              ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
+                              AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
+                              FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
+                  3600 AAAA   2001:db8::f00:baa9
+                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
+                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
+                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
+                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
+                              sZM6QjBBLmukH30+w1z3h8PUP2o= )
+                  3600 NSEC   b.example. A HINFO AAAA RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
+                              CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
+                              P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
+                              3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
+                              AhS+JOVfDI/79QtyTI0SaDWcg8U= )
+   b.example.     3600 IN NS  ns1.b.example.
+                  3600 IN NS  ns2.b.example.
+                  3600 NSEC   ns1.example. NS RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+   ns1.b.example. 3600 IN A   192.0.2.7
+   ns2.b.example. 3600 IN A   192.0.2.8
+   ns1.example.   3600 IN A   192.0.2.1
+                  3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
+                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
+                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
+
+
+
+Arends, et al.              Standards Track                    [Page 38]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              v/iVXSYC0b7mPSU+EOlknFpVECs= )
+                  3600 NSEC   ns2.example. A RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
+                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
+                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
+                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
+                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
+   ns2.example.   3600 IN A   192.0.2.2
+                  3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
+                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
+                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
+                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
+                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
+                  3600 NSEC   *.w.example. A RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE
+                              VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb
+                              3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH
+                              l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw
+                              Ymx28EtgIpo9A0qmP08rMBqs1Jw= )
+   *.w.example.   3600 IN MX  1 ai.example.
+                  3600 RRSIG  MX 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
+                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
+                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
+                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
+                              4kX18MMR34i8lC36SR5xBni8vHI= )
+                  3600 NSEC   x.w.example. MX RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
+                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
+                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
+                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
+                              s1InQ2UoIv6tJEaaKkP701j8OLA= )
+   x.w.example.   3600 IN MX  1 xx.example.
+                  3600 RRSIG  MX 5 3 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
+                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
+                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
+                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
+
+
+
+Arends, et al.              Standards Track                    [Page 39]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
+                  3600 NSEC   x.y.w.example. MX RRSIG NSEC
+                  3600 RRSIG  NSEC 5 3 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
+                              vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
+                              mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
+                              NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
+                              IjgiM8PXkBQtxPq37wDKALkyn7Q= )
+   x.y.w.example. 3600 IN MX  1 xx.example.
+                  3600 RRSIG  MX 5 4 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia
+                              t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj
+                              q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq
+                              GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb
+                              +gLcMZBnHJ326nb/TOOmrqNmQQE= )
+                  3600 NSEC   xx.example. MX RRSIG NSEC
+                  3600 RRSIG  NSEC 5 4 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+   xx.example.    3600 IN A   192.0.2.10
+                  3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
+                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
+                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
+                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
+                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )
+                  3600 HINFO  "KLH-10" "TOPS-20"
+                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0
+                              t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq
+                              BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8
+                              3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+
+                              RgNvuwbioFSEuv2pNlkq0goYxNY= )
+                  3600 AAAA   2001:db8::f00:baaa
+                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
+                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
+                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
+                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
+
+
+
+Arends, et al.              Standards Track                    [Page 40]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              xS9cL2QgW7FChw16mzlkH6/vsfs= )
+                  3600 NSEC   example. A HINFO AAAA RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY
+                              9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k
+                              mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi
+                              asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W
+                              GghLahumFIpg4MO3LS/prgzVVWo= )
+
+   The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
+   Flags indicate that each of these DNSKEY RRs is a zone key.  One of
+   these DNSKEY RRs also has the SEP flag set and has been used to sign
+   the apex DNSKEY RRset; this is the key that should be hashed to
+   generate a DS record to be inserted into the parent zone.  The other
+   DNSKEY is used to sign all the other RRsets in the zone.
+
+   The zone includes a wildcard entry, "*.w.example".  Note that the
+   name "*.w.example" is used in constructing NSEC chains, and that the
+   RRSIG covering the "*.w.example" MX RRset has a label count of 2.
+
+   The zone also includes two delegations.  The delegation to
+   "b.example" includes an NS RRset, glue address records, and an NSEC
+   RR; note that only the NSEC RRset is signed.  The delegation to
+   "a.example" provides a DS RR; note that only the NSEC and DS RRsets
+   are signed.
+
+Appendix B.  Example Responses
+
+   The examples in this section show response messages using the signed
+   zone example in Appendix A.
+
+B.1.  Answer
+
+   A successful query to an authoritative server.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   x.w.example.        IN MX
+
+   ;; Answer
+   x.w.example.   3600 IN MX  1 xx.example.
+   x.w.example.   3600 RRSIG  MX 5 3 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
+                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
+                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
+
+
+
+Arends, et al.              Standards Track                    [Page 41]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
+                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
+
+   ;; Authority
+   example.       3600 NS     ns1.example.
+   example.       3600 NS     ns2.example.
+   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+
+   ;; Additional
+   xx.example.    3600 IN A   192.0.2.10
+   xx.example.    3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
+                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
+                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
+                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
+                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )
+   xx.example.    3600 AAAA   2001:db8::f00:baaa
+   xx.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
+                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
+                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
+                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
+                              xS9cL2QgW7FChw16mzlkH6/vsfs= )
+   ns1.example.   3600 IN A   192.0.2.1
+   ns1.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
+                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
+                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
+                              v/iVXSYC0b7mPSU+EOlknFpVECs= )
+   ns2.example.   3600 IN A   192.0.2.2
+   ns2.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
+                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
+                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
+                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
+                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
+
+
+
+
+Arends, et al.              Standards Track                    [Page 42]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+B.2.  Name Error
+
+   An authoritative name error.  The NSEC RRs prove that the name does
+   not exist and that no covering wildcard exists.
+
+   ;; Header: QR AA DO RCODE=3
+   ;;
+   ;; Question
+   ml.example.         IN A
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
+   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
+   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+
+   ;; Additional
+   ;; (empty)
+
+
+
+
+Arends, et al.              Standards Track                    [Page 43]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+B.3.  No Data Error
+
+   A "no data" response.  The NSEC RR proves that the name exists and
+   that the requested RR type does not.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   ns1.example.        IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+   ns1.example.   3600 NSEC   ns2.example. A RRSIG NSEC
+   ns1.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
+                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
+                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
+                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
+                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
+
+   ;; Additional
+   ;; (empty)
+
+B.4.  Referral to Signed Zone
+
+   Referral to a signed zone.  The DS RR contains the data which the
+   resolver will need to validate the corresponding DNSKEY RR in the
+   child zone's apex.
+
+   ;; Header: QR DO RCODE=0
+   ;;
+
+
+
+Arends, et al.              Standards Track                    [Page 44]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   ;; Question
+   mc.a.example.       IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   a.example.     3600 IN NS  ns1.a.example.
+   a.example.     3600 IN NS  ns2.a.example.
+   a.example.     3600 DS     57855 5 1 (
+                              B6DCD485719ADCA18E5F3D48A2331627FDD3
+                              636B )
+   a.example.     3600 RRSIG  DS 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
+                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
+                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
+                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
+                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
+
+   ;; Additional
+   ns1.a.example. 3600 IN A   192.0.2.5
+   ns2.a.example. 3600 IN A   192.0.2.6
+
+B.5.  Referral to Unsigned Zone
+
+   Referral to an unsigned zone.  The NSEC RR proves that no DS RR for
+   this delegation exists in the parent zone.
+
+   ;; Header: QR DO RCODE=0
+   ;;
+   ;; Question
+   mc.b.example.       IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   b.example.     3600 IN NS  ns1.b.example.
+   b.example.     3600 IN NS  ns2.b.example.
+   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
+   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+
+
+
+Arends, et al.              Standards Track                    [Page 45]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   ;; Additional
+   ns1.b.example. 3600 IN A   192.0.2.7
+   ns2.b.example. 3600 IN A   192.0.2.8
+
+B.6.  Wildcard Expansion
+
+   A successful query that was answered via wildcard expansion.  The
+   label count in the answer's RRSIG RR indicates that a wildcard RRset
+   was expanded to produce this response, and the NSEC RR proves that no
+   closer match exists in the zone.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   a.z.w.example.      IN MX
+
+   ;; Answer
+   a.z.w.example. 3600 IN MX  1 ai.example.
+   a.z.w.example. 3600 RRSIG  MX 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
+                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
+                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
+                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
+                              4kX18MMR34i8lC36SR5xBni8vHI= )
+
+   ;; Authority
+   example.       3600 NS     ns1.example.
+   example.       3600 NS     ns2.example.
+   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
+   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+
+   ;; Additional
+   ai.example.    3600 IN A   192.0.2.9
+   ai.example.    3600 RRSIG  A 5 2 3600 20040509183619 (
+
+
+
+Arends, et al.              Standards Track                    [Page 46]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              20040409183619 38519 example.
+                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
+                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
+                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
+                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
+                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
+   ai.example.    3600 AAAA   2001:db8::f00:baa9
+   ai.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
+                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
+                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
+                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
+                              sZM6QjBBLmukH30+w1z3h8PUP2o= )
+
+B.7.  Wildcard No Data Error
+
+   A "no data" response for a name covered by a wildcard.  The NSEC RRs
+   prove that the matching wildcard name does not have any RRs of the
+   requested type and that no closer match exists in the zone.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   a.z.w.example.      IN AAAA
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
+   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+
+
+
+Arends, et al.              Standards Track                    [Page 47]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+   *.w.example.   3600 NSEC   x.w.example. MX RRSIG NSEC
+   *.w.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
+                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
+                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
+                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
+                              s1InQ2UoIv6tJEaaKkP701j8OLA= )
+
+   ;; Additional
+   ;; (empty)
+
+B.8.  DS Child Zone No Data Error
+
+   A "no data" response for a QTYPE=DS query that was mistakenly sent to
+   a name server for the child zone.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   example.            IN DS
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
+   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+
+
+
+Arends, et al.              Standards Track                    [Page 48]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+
+   ;; Additional
+   ;; (empty)
+
+Appendix C.  Authentication Examples
+
+   The examples in this section show how the response messages in
+   Appendix B are authenticated.
+
+C.1.  Authenticating an Answer
+
+   The query in Appendix B.1 returned an MX RRset for "x.w.example.com".
+   The corresponding RRSIG indicates that the MX RRset was signed by an
+   "example" DNSKEY with algorithm 5 and key tag 38519.  The resolver
+   needs the corresponding DNSKEY RR in order to authenticate this
+   answer.  The discussion below describes how a resolver might obtain
+   this DNSKEY RR.
+
+   The RRSIG indicates the original TTL of the MX RRset was 3600, and,
+   for the purpose of authentication, the current TTL is replaced by
+   3600.  The RRSIG labels field value of 3 indicates that the answer
+   was not the result of wildcard expansion.  The "x.w.example.com" MX
+   RRset is placed in canonical form, and, assuming the current time
+   falls between the signature inception and expiration dates, the
+   signature is authenticated.
+
+C.1.1.  Authenticating the Example DNSKEY RR
+
+   This example shows the logical authentication process that starts
+   from the a configured root DNSKEY (or DS RR) and moves down the tree
+   to authenticate the desired "example" DNSKEY RR.  Note that the
+   logical order is presented for clarity.  An implementation may choose
+   to construct the authentication as referrals are received or to
+   construct the authentication chain only after all RRsets have been
+   obtained, or in any other combination it sees fit.  The example here
+   demonstrates only the logical process and does not dictate any
+   implementation rules.
+
+   We assume the resolver starts with a configured DNSKEY RR for the
+   root zone (or a configured DS RR for the root zone).  The resolver
+   checks whether this configured DNSKEY RR is present in the root
+   DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root
+   DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY
+   RRset, and whether the signature lifetime is valid.  If all these
+
+
+
+Arends, et al.              Standards Track                    [Page 49]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   conditions are met, all keys in the DNSKEY RRset are considered
+   authenticated.  The resolver then uses one (or more) of the root
+   DNSKEY RRs to authenticate the "example" DS RRset.  Note that the
+   resolver may have to query the root zone to obtain the root DNSKEY
+   RRset or "example" DS RRset.
+
+   Once the DS RRset has been authenticated using the root DNSKEY, the
+   resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
+   RR that matches one of the authenticated "example" DS RRs.  If such a
+   matching "example" DNSKEY is found, the resolver checks whether this
+   DNSKEY RR has signed the "example" DNSKEY RRset and the signature
+   lifetime is valid.  If these conditions are met, all keys in the
+   "example" DNSKEY RRset are considered authenticated.
+
+   Finally, the resolver checks that some DNSKEY RR in the "example"
+   DNSKEY RRset uses algorithm 5 and has a key tag of 38519.  This
+   DNSKEY is used to authenticate the RRSIG included in the response.
+   If multiple "example" DNSKEY RRs match this algorithm and key tag,
+   then each DNSKEY RR is tried, and the answer is authenticated if any
+   of the matching DNSKEY RRs validate the signature as described above.
+
+C.2.  Name Error
+
+   The query in Appendix B.2 returned NSEC RRs that prove that the
+   requested data does not exist and no wildcard applies.  The negative
+   reply is authenticated by verifying both NSEC RRs.  The NSEC RRs are
+   authenticated in a manner identical to that of the MX RRset discussed
+   above.
+
+C.3.  No Data Error
+
+   The query in Appendix B.3 returned an NSEC RR that proves that the
+   requested name exists, but the requested RR type does not exist.  The
+   negative reply is authenticated by verifying the NSEC RR.  The NSEC
+   RR is authenticated in a manner identical to that of the MX RRset
+   discussed above.
+
+C.4.  Referral to Signed Zone
+
+   The query in Appendix B.4 returned a referral to the signed
+   "a.example." zone.  The DS RR is authenticated in a manner identical
+   to that of the MX RRset discussed above.  This DS RR is used to
+   authenticate the "a.example" DNSKEY RRset.
+
+   Once the "a.example" DS RRset has been authenticated using the
+   "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
+   for some "a.example" DNSKEY RR that matches the DS RR.  If such a
+   matching "a.example" DNSKEY is found, the resolver checks whether
+
+
+
+Arends, et al.              Standards Track                    [Page 50]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
+   the signature lifetime is valid.  If all these conditions are met,
+   all keys in the "a.example" DNSKEY RRset are considered
+   authenticated.
+
+C.5.  Referral to Unsigned Zone
+
+   The query in Appendix B.5 returned a referral to an unsigned
+   "b.example." zone.  The NSEC proves that no authentication leads from
+   "example" to "b.example", and the NSEC RR is authenticated in a
+   manner identical to that of the MX RRset discussed above.
+
+C.6.  Wildcard Expansion
+
+   The query in Appendix B.6 returned an answer that was produced as a
+   result of wildcard expansion.  The answer section contains a wildcard
+   RRset expanded as it would be in a traditional DNS response, and the
+   corresponding RRSIG indicates that the expanded wildcard MX RRset was
+   signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
+   The RRSIG indicates that the original TTL of the MX RRset was 3600,
+   and, for the purpose of authentication, the current TTL is replaced
+   by 3600.  The RRSIG labels field value of 2 indicates that the answer
+   is the result of wildcard expansion, as the "a.z.w.example" name
+   contains 4 labels.  The name "a.z.w.w.example" is replaced by
+   "*.w.example", the MX RRset is placed in canonical form, and,
+   assuming that the current time falls between the signature inception
+   and expiration dates, the signature is authenticated.
+
+   The NSEC proves that no closer match (exact or closer wildcard) could
+   have been used to answer this query, and the NSEC RR must also be
+   authenticated before the answer is considered valid.
+
+C.7.  Wildcard No Data Error
+
+   The query in Appendix B.7 returned NSEC RRs that prove that the
+   requested data does not exist and no wildcard applies.  The negative
+   reply is authenticated by verifying both NSEC RRs.
+
+C.8.  DS Child Zone No Data Error
+
+   The query in Appendix B.8 returned NSEC RRs that shows the requested
+   was answered by a child server ("example" server).  The NSEC RR
+   indicates the presence of an SOA RR, showing that the answer is from
+   the child .  Queries for the "example" DS RRset should be sent to the
+   parent servers ("root" servers).
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 51]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Brouwerijstraat 1
+   7523 XC  Enschede
+   NL
+
+   EMail: roy.arends@telin.nl
+
+
+   Rob Austein
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   EMail: sra@isc.org
+
+
+   Matt Larson
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   USA
+
+   EMail: mlarson@verisign.com
+
+
+   Dan Massey
+   Colorado State University
+   Department of Computer Science
+   Fort Collins, CO 80523-1873
+
+   EMail: massey@cs.colostate.edu
+
+
+   Scott Rose
+   National Institute for Standards and Technology
+   100 Bureau Drive
+   Gaithersburg, MD  20899-8920
+   USA
+
+   EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 52]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   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.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 53]
+