< draft-olaf-dnsext-dnssec-wildcard-optimization-01.txt		draft-olaf-dnsext-dnssec-wildcard-optimization-02.txt >
	DNSEXT (Independent submission) O. Kolkman		DNSEXT (Independent submission) O. Kolkman
	Internet-Draft RIPE NCC		Internet-Draft RIPE NCC
	Expires: March 2, 2003 J. Ihren		Expires: July 4, 2003 J. Ihren
	Autonomica		Autonomica
	R. Arends		R. Arends
	A.R.E.N.D.S.		Telematica Instituut
	September 2002		January 3, 2003
	DNSSEC Wildcard Optimization		DNSSEC Wildcard Optimization
	draft-olaf-dnsext-dnssec-wildcard-optimization-01.txt		draft-olaf-dnsext-dnssec-wildcard-optimization-02.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 2, 2003.		This Internet-Draft will expire on July 4, 2003.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	Abstract		Abstract
	Secure denial of the existence of wildcards may lead to a large		Secure denial of the existence of wildcards may lead to a large
	number of NXT RRs and associated SIG RRs in DNS responses, even in		number of NXT Resource Records and associated SIG Resource Records in
	the common case when wildcards are not present in the zone. This		DNS responses, even in the common case when wildcards are not present
	optimization uses one bit from the NXT type array to signal that		in the zone. This optimization uses one bit from the NXT type array
	there is no closer wildcard in the zone for a given query name. This		to signal that there is no closer wildcard in the zone for a given
	reduces the packet size and the need for executing slow, and		query name. This reduces the packet size and the need for executing
	complicated, code paths in common queries. In cases where there are		slow, and complicated, code paths in the case when queries are made
	no wildcard RRs in the zone (i.e. the root zone) only one NXT RR and		to zones which have the bit set at zone signing time. In cases where
	corresponding SIG is needed for denial of existence of the wildcard.		there are no wildcard RRs in the zone (e.g. the root zone) only one
			NXT RR and corresponding SIG is needed for denial of existence of
			both a full match and any possible wildcard matches.
	The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",		The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
	"RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be		"RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
	interpreted as described in RFC2119.		interpreted as described in RFC2119.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 RFC2535 Wildcard Processing . . . . . . . . . . . . . . . . 3		1.1 RFC2535 Wildcard Processing . . . . . . . . . . . . . . . . 3
	1.2 Signalling the Existence of a Wildcard . . . . . . . . . . . 3		1.2 Optimizations . . . . . . . . . . . . . . . . . . . . . . . 3
	2. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . 4		1.3 Complexities . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1 Server Side . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Definition of the NOWILD bit . . . . . . . . . . . . . . . . 4
	2.1.1 Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 4		2.1 Algorithms to set the bit . . . . . . . . . . . . . . . . . 4
	2.1.2 Server Responses . . . . . . . . . . . . . . . . . . . . . . 4		2.1.1 Trivial Algorithm . . . . . . . . . . . . . . . . . . . . . 4
	2.1.3 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1.2 'Advanced' Algorithm . . . . . . . . . . . . . . . . . . . . 4
	2.2 Resolver Side . . . . . . . . . . . . . . . . . . . . . . . 5		3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . 5
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6		3.1 Server Side . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Security Considerations . . . . . . . . . . . . . . . . . . 6		3.1.1 Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Internationalization Considerations . . . . . . . . . . . . 6		3.1.2 Server Responses . . . . . . . . . . . . . . . . . . . . . . 5
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		3.1.3 Dynamic DNS considerations . . . . . . . . . . . . . . . . . 6
	7. Document Changes . . . . . . . . . . . . . . . . . . . . . . 6		3.2 Resolver Side . . . . . . . . . . . . . . . . . . . . . . . 6
	7.1 draft 00->01 . . . . . . . . . . . . . . . . . . . . . . . . 6		3.2.1 RFC2535 compatibility . . . . . . . . . . . . . . . . . . . 7
	Normative References . . . . . . . . . . . . . . . . . . . . 7		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . 7
	A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8		6. Internationalization Considerations . . . . . . . . . . . . 7
	A.1 Zone without wildcards . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	A.1.1 Optimized proof . . . . . . . . . . . . . . . . . . . . . . 8		8. Document Changes . . . . . . . . . . . . . . . . . . . . . . 7
	A.1.2 RFC2535 proof . . . . . . . . . . . . . . . . . . . . . . . 8		8.1 draft 00->01 . . . . . . . . . . . . . . . . . . . . . . . . 7
	A.2 Zone with wildcards . . . . . . . . . . . . . . . . . . . . 9		8.2 draft 01->02 . . . . . . . . . . . . . . . . . . . . . . . . 8
	A.2.1 Optimized proof . . . . . . . . . . . . . . . . . . . . . . 10		Normative References . . . . . . . . . . . . . . . . . . . . 8
	A.2.2 NXDOMAIN with additional proof for no wildcard . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
	A.2.3 Another Optimized Proof . . . . . . . . . . . . . . . . . . 11		A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	A.2.4 Denial of Existence of Closer Match . . . . . . . . . . . . 11		A.1 Zone without wildcards . . . . . . . . . . . . . . . . . . . 9
	A.2.5 The NXT 'next name' Proving Existence of a Wildcard . . . . 12		A.1.1 Optimized proof . . . . . . . . . . . . . . . . . . . . . . 9
	Full Copyright Statement . . . . . . . . . . . . . . . . . . 13		A.1.2 RFC2535 proof . . . . . . . . . . . . . . . . . . . . . . . 10
			A.2 Zone with wildcards . . . . . . . . . . . . . . . . . . . . 11
			A.2.1 Optimized proof . . . . . . . . . . . . . . . . . . . . . . 12
			A.2.2 NXDOMAIN with additional proof for no wildcard . . . . . . . 12
			A.2.3 Another Optimized Proof . . . . . . . . . . . . . . . . . . 12
			A.2.4 Denial of Existence of Closer Match . . . . . . . . . . . . 13
			Full Copyright Statement . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	Wildcards make authenticated denial of existence complex. Many zones		Wildcards make authenticated denial of existence complex. Many zones
	do not contain wildcards but still incur a penalty. If the NXT RR		do not contain wildcards but still incur a penalty. If the NXT RR
	contains an indication that a wildcard match can not exist then less		contains an indication that a wildcard match can not exist then less
	DNSSEC related RRs and less computation are needed to authoritatively		DNSSEC related RRs and less computation are needed to authoritatively
	deny the existence of a name in the zone.		deny the existence of a name in the zone.
	1.1 RFC2535 Wildcard Processing		1.1 RFC2535 Wildcard Processing
	RFC2535 [1] specifies that the non-existence of a match against a		RFC2535 [3] specifies that the non-existence of a match against a
	wildcard is proven by a set of relevant NXT records. In practice		wildcard is proven by a set of relevant NXT records. In practice
	this will result to at least 2 NXT RRs and corresponding SIGs being		this will result to at least 2 NXT RRs and corresponding SIGs being
	returned. There are cases where the denial of the existence of		returned. Even in zones that do not use wildcards this will lead to
	wildcards will need many more than 2 NXT RRs. Even in zones that do		complex answers for which the resolvers will need to follow NXT
	not use wildcards this will lead to complex answers for which the		chains and which are hard to troubleshoot by operators.
	resolvers will need to follow NXT chains and which are hard to
	troubleshoot by operators.
	1.2 Signalling the Existence of a Wildcard		1.2 Optimizations
			With the solution proposed herein the following optimizations are
			realized:
			o Both servers and resolvers can bypass slow and complicated code
			paths in the common case where no wildcards are present in a
			secured zone.
			o Packet size of answers reduce in most common cases; for the root
			zone the authority section only contains one NXT RR with
			associated SIGs instead of two NXT RRs with associated SIGs.
			o The common case answers are easier to interpret by human operators
			troubleshooting responses;
			1.3 Complexities
			With the solution proposed herein the following complexities are
			added:
			o Increased code complexity; the proposed optimization leads to a
			small increase in the amount of code i.e. a few conditional
			statements branching off the algorithm proofing the non-existence
			of wildcard.
			Note that authoritative server code can be designed without support
			for secured wildcard RRs, these servers will not have the added
			complexity but will also not be able to serve zones with wildcards.
			2. Definition of the NOWILD bit
	The NXT RR, used to the prove the non-existence of data, uses a type		The NXT RR, used to the prove the non-existence of data, uses a type
	bit-map to track which types are available for a given name. We		bit-map to track which types are available for a given name. We
	propose to use one bit (see section Section 3) in the type bitmap to		propose to use one bit (see section Section 4) in the type bitmap to
	signal if a wildcard is available in a zone. We refer to this bit as		signal that no wildcard match is possible for the part of the the
	the "NOWILD-bit".		zone's namespace covered by the NXT RR. We refer to this bit as the
			"NOWILD-bit".
	If the NOWILD-bit is set to 1 then the NXT RR signals that there is		If the NOWILD-bit in a NXT RR is set to 1 then there is no wildcard
	no wildcard match possible against the query name, only if the bit is		expansion possible for any of the possible names between and
	set to 0 further processing needs to be done. For zones without		including the ownername and the NXT-dname of that NXT RR.
	wildcards the NOWILD-bit MAY always be set to 1.
	The following optimizations are realized:		By setting the bit the zone-owner makes a statement about the non-
			existence of possible wildcards. It is important that the zone owner
			applies the proper algorithm to set the bit. Two possible algorithms
			are presented below.
	o Servers and resolvers will only have to execute a slow and		2.1 Algorithms to set the bit
	somewhat complicated code paths if wildcard are present in the
	zone.
	o Packet size of answers reduce in most common cases; for the root		Any algorithm that sets the NOWILD bit in the NXT RRs in a zone MUST
	zone the authority section only contains one NXT RR with		NOT set the bit if a wildcard match is possible for any of the
	associated SIGs instead of two NXT RRs with associated SIGs.		possible names between and including the ownername and the NXT-dname
			of a NXT RR. Any algorithm MAY set the bit if the negation of the
			above is true i.e. where there is no wildcard expansion possible for
			any of the names spanned by the NXT RR.
	o In case of absence of wildcards-matches answers will be easier to		When an algorithm as above is applied a NXT RR that proves the non-
	interpret by human operators troubleshooting responses;		existence of a full match of the QNAME will also prove, when it's
			NOWILD-bit is set to 1, that there is no match of the QNAME to any
			wildcard that may exist in the zone
	2. DNSSEC Protocol Changes		2.1.1 Trivial Algorithm
			The most trivial algorithm is to set the bit in all NXT RRs in a zone
			if there are no wildcards in that zone and to clear it if there is
			any wildcard in the zone.
			2.1.2 'Advanced' Algorithm
			Now for a somewhat complicated algorithm.
			Represent the ownername and the NXT-dname in a set of labels like:
			'label(j).label(j-1).label(j-2) ... label(0).'. The NOWILD bit can
			than be set if for both the ownername and the NXT-dname there is no
			wildcard name '*.label(i).label(i-1) ... label(0).' in the zone for
			all i < j. In other words the NOWILD is set to 0 if -- while
			ignoring the possible existence of a domain name between the
			ownername and the wildcard domain -- there exists a wildcard that
			would match QNAME=ownername or QNAME=NXT-dname.
			For ownernames for which the above does not apply the NOWILD bit can
			be set to 1.
			3. DNSSEC Protocol Changes
	This is an update to the RFC2535 protocol. Resolvers MUST implement		This is an update to the RFC2535 protocol. Resolvers MUST implement
	these changes. Servers MAY implement these changes.		these changes. Servers MAY implement these changes.
	2.1 Server Side		3.1 Server Side
	2.1.1 Zone Signing		3.1.1 Zone Signing
	Servers that implement the optimization MAY perform the following		Servers that implement the optimization MAY perform the following
	actions at zone signing time.		actions at zone signing time.
	At zone signing time, when the NXT RRs are generated, the NOWILD-bit		At zone signing time an algorithm that sets the bit according to the
	MUST be set to 0 if for an ownername 'label(j).label(j-1).label(j-2)		above definition.
	... label(0).' there is no wildcard name '*.label(i).label(i-1) ...
	label(0).' in the zone for all i < j. In other words the label is
	set to 0 if there exists a wildcard that would match QNAME=ownername
	while ignoring the possible existence of a domain name between the
	ownername and the wildcard domain. For all other ownernames the bit
	MUST be set to 1.
	If, because of implementation or policy issues, the algorithm in the
	previous paragraph is not applied then the bit MUST be set to 0 for
	all NXT RRs in the zone. Servers that do do not implement the
	optimization have already set their NOWILD bit to 0 by virtue of the
	requirements of RFC2535 section 5.2.
	When the algorithm is applied a NXT RR that proves the non-existence		If, because of implementation or policy issues, the algorithm is not
	of a full match of the QNAME will also prove, when it's NOWILD-bit is		applied then the bit MUST be set to 0 for all NXT RRs in the zone.
	set to 1, that there is no match of the QNAME to any wildcard that		Servers that do do not implement the optimization have already set
	may exist in the zone		their NOWILD bit to 0 by virtue of the requirements of RFC2535
			section 5.2.
	2.1.2 Server Responses		3.1.2 Server Responses
	When queried for a name for which there is no match, i.e. no full		When queried for a name for which there is no match, i.e. no full
	and no wildcard match, in the zone:		and no wildcard match, in the zone:
	o Servers MUST return the NXT RR that proves the non-existence of		o Servers MUST return the NXT RR that proves the non-existence of
	the query name in the NXDOMAIN response. If there is no match for		the query name in the NXDOMAIN response. If there is no match for
	a wildcard and the NOWILD-bit is set to 1 at signing time and the		a wildcard and the NOWILD-bit is set to 1 at signing time and the
	one NXT RR is sufficient. If the NOWILD-bit for the NXT RR that		one NXT RR is sufficient. If the NOWILD-bit for the NXT RR that
	proves non-existence of the query name is set to 0 then NXT RRs		proves non-existence of the query name is set to 0 then NXT RRs
	that prove the non-existence of possible wildcard matches MUST be		that prove the non-existence of possible wildcard matches MUST be
	skipping to change at page 5, line 11 ¶		skipping to change at page 6, line 6 ¶
	When queried for a name for which there is a match in the zone:		When queried for a name for which there is a match in the zone:
	o If the match is an exact match than no NXT RRs are returned in the		o If the match is an exact match than no NXT RRs are returned in the
	additional section.		additional section.
	o Servers for zones that contain one or more wildcards MUST return		o Servers for zones that contain one or more wildcards MUST return
	the NXT RRs that prove the non-existence of the exact match. They		the NXT RRs that prove the non-existence of the exact match. They
	must also provide proof that there is no closer match for the		must also provide proof that there is no closer match for the
	QNAME than the match returned in the answer section.		QNAME than the match returned in the answer section.
	The proof algorithm for non-existence of wildcards, an exact match or		This proof algorithm for non-existence of wildcards, an exact match
	closer matches conforms to RFC2535.		or closer matches conforms to RFC2535.
	2.1.3 Dynamic DNS		3.1.3 Dynamic DNS considerations
	When dynamically adding or removing a name that does not contains		When dynamically adding or removing a name that does not contains
	wildcards, the 'next name' for the name immediately above the		wildcards, the 'next name' for the name immediately above the
	inserted, or deleted name needs to be updated. The NOWILD bit of the		inserted, or deleted name needs to be updated. The NOWILD bit of the
	inserted name is to be set according to the procedure as described in		inserted name is to be set according to the algorithm as described in
	Section 2.1.1. Except for setting the NOWILD bit this is similar to		Section 2.1. Except for setting the NOWILD bit this is similar to
	the RFC2535 procedure.		the RFC2535 procedure.
	If a name containing a wildcard is deleted from a zone one has to		If a name containing a wildcard is deleted from a zone one has to
	verify if, for all names in the zone with the bit set to 0, the		verify if, for all names in the zone with the bit set to 0, the
	NOWILD bit can be toggled. If a name containing a wildcard is added		NOWILD bit can be toggled. If a name containing a wildcard is added
	one has to verify if, for all the names in the zone, the bit needs to		one has to verify if, for all the names in the zone, the bit needs to
	be set to 0.		be set to 0.
	The NOWILD bit is not to be modified during an update of a name that		The NOWILD bit is not to be modified during an update of a name that
	already exists in the zone.		already exists in the zone.
	Dynamic updates of names that contain wildcards may lead to		Dynamic updates of names that contain wildcards may lead to
	performance penalties for large dynamic zones and one MAY therefore		performance penalties for large dynamic zones and one may therefore
	choose not to perform the NOWILD optimization for dynamic zones.		choose not to perform the NOWILD optimization for dynamic zones.
	2.2 Resolver Side		3.2 Resolver Side
	When receiving an answer to a query a resolver MUST assess if the		When receiving an answer to a query a resolver MUST assess if the
	answer is a result of a wildcard match. If the result is an exact		answer is a result of a wildcard match. If the result is an exact
	match then there will be no NXT RRs in the authority section.		match then there will be no NXT RRs in the authority section.
	If the answer is a wildcard match then the resolver will need to		If the answer is a wildcard match then the resolver will need to
	verify that the exact name does not exist. The NXT RRs in the		verify that the exact name does not exist. The NXT RRs in the
	additional section, which per definition have their NOWILD-bit set to		additional section, which per definition have their NOWILD-bit set to
	0, will need to prove that there is no closer match. ( conforming to		0, will need to prove that there is no closer match. ( conforming to
	RFC2535).		RFC2535).
	If the response is NXDOMAIN (i.e. no match at all) then the resolver		If the response is NXDOMAIN (i.e. no match at all) then the resolver
	MUST verify if the NXT RR proves the non-existence of the exact match		MUST verify if the NXT RR proves the non-existence of the exact match
	in the zone. No further NXT RRs are needed if the NXT RR has it's		in the zone. No further NXT RRs are needed if the NXT RR has it's
	NOWILD-bit set to 1. A DNS packet containing an NXDOMAIN response		NOWILD-bit set to 1. A DNS packet containing an NXDOMAIN response
	accompanied by a NXT RR that has it's NOWILD-bit set to 0 will need		accompanied by a NXT RR that has it's NOWILD-bit set to 0 will need
	to contain proof that there are no wildcard matches against the QNAME		to contain proof that there are no wildcard matches against the QNAME
	(conforming to RFC2535 ).		(conforming to RFC2535 ).
	The NXT data and the NOWILD-bit together supply the proof on the non-		3.2.1 RFC2535 compatibility
	existence of a wildcard. There is one situation where the NOWILD-bit
	is set to 1 but the NXT's 'next name' proves that there is a
	wildcard. This is when the 'next name' itself contains a wildcard.
	Resolvers that verify NXDOMAIN replies MUST verify the NXT 'next
	name' first before the NOWILD-bit. Also see example Appendix A.2.5.
	The fact that resolvers that obtain an answer with a NXT RR's NOWILD		A verifier, that does not have this technology implemented, will not
	set to 1 do not receive additional proof for the non-existence of		obtain sufficient proof to assess the non existence of wildcard from
	wildcards is incompatible with RFC2535.		servers that have implemented the optimizations. Although it is
			possible for a verifier to obtain the proof by a number of additional
			queries it can not be expected that a verifier will actually do that.
	3. IANA Considerations		This optimization is therefore incompatible with RFC2535 style denial
			of existence.
			4. IANA Considerations
	Although there is no RR record associated the NOWILD-bit. The value		Although there is no RR record associated the NOWILD-bit. The value
	of the bit must be registered as a DNS RR-type. To not cause the NXT		of the bit must be registered as a DNS RR-type. To not cause the NXT
	type bitmap to grow beyond 4 octets unnecessary we propose to reuse		type bitmap to grow beyond 4 octets unnecessarily we propose to reuse
	type code 31 (the EID type code is undocumented).		type code 31 (the EID type code is undocumented).
	4. Security Considerations		5. Security Considerations
	The draft provides an optimization for wildcard handling. Resolvers		The draft provides an optimization for wildcard handling. Resolvers
	MUST verify for the denial of existence of matches or the denial of		MUST verify the denial of existence of matches or the denial of
	existence of closer matches when an answer is returned and the		existence of closer matches when an answer is returned and the
	NOWILD-bit is set to 0.		NOWILD-bit is set to 0.
	5. Internationalization Considerations		6. Internationalization Considerations
	There are no internationalization considerations.		There are no internationalization considerations.
	6. Acknowledgements		7. Acknowledgements
	Olafur Gudmundsson, Daniel Karrenberg and Ed Lewis for providing		Olafur Gudmundsson, Daniel Karrenberg, Matt Larson, Ed Lewis, Ted
			Lindgreen, Daniel Massey, Scott Rose and Sam Weiler for providing
	critique and input on earlier versions of this document.		critique and input on earlier versions of this document.
	7. Document Changes		8. Document Changes
	7.1 draft 00->01		8.1 draft 00->01
	Reordered and reworded the 'protocol changes' section. We tried		Reordered and reworded the 'protocol changes' section. We tried
	to make the fact that resolvers must and servers may implement		to make the fact that resolvers must and servers may implement
	this optimization more explicit.		this optimization more explicit.
	Change from using the SIG bit to another bit in the NXT type-		Change from using the SIG bit to another bit in the NXT type-
	bitmap, changed the name of the bit and added IANA considerations.		bitmap, changed the name of the bit and added IANA considerations.
			Note that the meaning of the bit being set and cleared are changed
	Note that the meaning of the bit being set and unset are changed
	because of the default setting. Because of the fact that we want		because of the default setting. Because of the fact that we want
	to maintain backward compatibility with servers that do not		to maintain backward compatibility with servers that do not
	implement this bit and the bit in the typemap is currently set to		implement this bit and the bit in the typemap is currently set to
	0 the default behaviour should be follow old-style NXT proof.		0 the default behaviour should be follow old-style NXT proof.
	Corrected mistakes in the examples.		Corrected mistakes in the examples.
	Various style and spelling corrections.		Various style and spelling corrections.
			8.2 draft 01->02
			Restructured the document somewhat by explicitly defining the meaning
			from the bit and describing (some of the algorithms) to set the bit
			in a separate section.
			The algorithm described in 00 and 01 was broken for the case that
			there are multiple labels sorting before the '*'.
			Sanitized the examples. The existence of a 'non-terminating' label
			in the NXT response often (maybe always) shortcuts possible matches
			between the QNAME and other relevant possible wildcard entries (See
			Appendix A.1.2).
	Normative References		Normative References
	[1] Eastlake, D., "Domain Name System Security Extensions", RFC		[1] Gudmundsson, O., "Delegation Signer Resource Record", draft-
			ietf-dnsext-delegation-signer-12 (work in progress), December
			2002.
			[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
			Levels", BCP 14, RFC 2119, March 1997.
			[3] Eastlake, D., "Domain Name System Security Extensions", RFC
	2535, March 1999.		2535, March 1999.
	Authors' Addresses		Authors' Addresses
	Olaf M. Kolkman		Olaf M. Kolkman
	RIPE NCC		RIPE NCC
	Singel 256		Singel 256
	1016 AB Amsterdam		1016 AB Amsterdam
	NL		NL
	skipping to change at page 7, line 31 ¶		skipping to change at page 9, line 4 ¶
	Olaf M. Kolkman		Olaf M. Kolkman
	RIPE NCC		RIPE NCC
	Singel 256		Singel 256
	1016 AB Amsterdam		1016 AB Amsterdam
	NL		NL
	Phone: +31 20 535 4444		Phone: +31 20 535 4444
	EMail: olaf@ripe.net		EMail: olaf@ripe.net
	URI: http://www.ripe.net/		URI: http://www.ripe.net/
	Johan Ihren		Johan Ihren
	Autonomica		Autonomica
	Bellmansgatan 30		Bellmansgatan 30
	SE-118 47 Stockholm		SE-118 47 Stockholm
	SE		SE
	EMail: johani@autonomica.se		EMail: johani@autonomica.se
	Roy Arends		Roy Arends
	A.R.E.N.D.S.		Telematica Instituut
	Bankastraat 41-e		Drienerlolaan 5
	1094 EB Amsterdam		7522 NB Enschede
	NL		NL
	Phone: +31206931681		EMail: roy.arends@telin.nl
	EMail: Roy@logmess.com
	Appendix A. Examples		Appendix A. Examples
	A.1 Zone without wildcards		A.1 Zone without wildcards
	In the following example zone file there are no wildcards. All		In the following example zone file there are no wildcards. All
	NOWILD bits are set to 1. The actual SIG RRs and the KEY RRs are		NOWILD bits are set to 1. The actual SIG RRs and the KEY RRs are
	left out from the zone data and type bitmaps for clarity only.		left out from the zone data and type bitmaps for clarity only.
	$ORIGIN example.		$ORIGIN example.
	skipping to change at page 10, line 7 ¶		skipping to change at page 11, line 17 ¶
	In the following example zone file there is a wildcard. Some NOWILD		In the following example zone file there is a wildcard. Some NOWILD
	bits are set to 1, others for which there is no wildcard in the zone		bits are set to 1, others for which there is no wildcard in the zone
	if the leftmost labels are chopped off, have there NOWILD-bit set to		if the leftmost labels are chopped off, have there NOWILD-bit set to
	0. The actual SIG RRs and the KEY RRs at the apex are left out for		0. The actual SIG RRs and the KEY RRs at the apex are left out for
	clarity. The queries for which a wildcard match is returned will		clarity. The queries for which a wildcard match is returned will
	have the NOWILD-bit set to 0, there proof for the non-existing closer		have the NOWILD-bit set to 0, there proof for the non-existing closer
	match is to be supplied and checked by the resolver.		match is to be supplied and checked by the resolver.
	$ORIGIN example.		$ORIGIN example.
	@ IN SOA		@ IN SOA
	@ NXT a SOA NXT NOWILD ; NOWILD-bit set to 1		@ NXT a SOA NXT SIG NOWILD ; NOWILD-bit set to 1
	a A 10.0.0.1		a A 10.0.0.1
	a NXT a.b A NXT NOWILD ; NOWILD-bit set to 1		a NXT a.b A NXT SIG NOWILD ; NOWILD-bit set to 1
	a.b A 10.0.0.2		a.b A 10.0.0.2
	a.b NXT *.c A NXT NOWILD ; NOWILD-bit set to 1		a.b NXT *.c A NXT SIG NOWILD ; NOWILD-bit set to 1
	*.c A 10.0.0.3		*.c A 10.0.0.3
	*.c NXT a.c A NXT SIG ; NOWILD-bit set to 0		*.c NXT a.c A NXT SIG ; NOWILD-bit set to 0
	a.c A 10.0.0.4		a.c A 10.0.0.4
	a.c NXT a.b.c A NXT SIG ; NOWILD-bit set to 0		a.c NXT a.b.c A NXT SIG ; NOWILD-bit set to 0
	a.b.c A 10.0.0.5		a.b.c A 10.0.0.5
	a.b.c NXT f A NXT SIG ; NOWILD-bit set to 0		a.b.c NXT f A NXT SIG ; NOWILD-bit set to 0
	f A 10.0.0.6		f A 10.0.0.6
	f NXT @ A NXT NOWILD ; NOWILD-bit set to 1		f NXT @ A NXT SIG NOWILD ; NOWILD-bit set to 1
			In the above example 'a.b.c NXT f' has NOWILD=0 because a.b.c is a
			possible expansion of '*.c'. 'a.b NXT *.c' has NOWILD=0 because
			there are names in the namespace that is spanned by the NXT RR that
			match the *.c wildcard. For instance '!.c', a valid domain name
			which sorts canonically before '*.c' and after 'a.b'.
	A.2.1 Optimized proof		A.2.1 Optimized proof
	QNAME= c.a.a.example. QTYPE=A		QNAME= c.a.a.example. QTYPE=A
	RCODE=NXDOMAIN		RCODE=NXDOMAIN
	;; Authority		;; Authority
	example. SOA		example. SOA
	SIG SOA		SIG SOA
	a.example. NXT a.b.example. A NXT SIG NOWILD		a.example. NXT a.b.example. A NXT SIG NOWILD
	skipping to change at page 10, line 41 ¶		skipping to change at page 12, line 25 ¶
	; match and no wildcards that match		; match and no wildcards that match
	; QNAME		; QNAME
	SIG NXT		SIG NXT
	;; Additional		;; Additional
	(... skipped ... )		(... skipped ... )
	A.2.2 NXDOMAIN with additional proof for no wildcard		A.2.2 NXDOMAIN with additional proof for no wildcard
	The following example contains a NXDOMAIN answer and the proof that		The following example contains a NXDOMAIN answer and the proof that
	there is no wildcard match.		there is no wildcard match. The NXT RR proving the non-existence of
			a matching wildcard needs to be supplied because the NOWILD bit is
			not set on the entry that proves an exact match
	QNAME= e.example. QTYPE=A		QNAME= e.example. QTYPE=A
	RCODE=NXDOMAIN		RCODE=NXDOMAIN
	;; Authority		;; Authority
	example.example SOA		example.example SOA
	SIG SOA		SIG SOA
	a.b.c.example. NXT f.example. A NXT SIG ; NOWILD-bit set to 0,		a.b.c.example. NXT f.example. A NXT SIG ; NOWILD-bit set to 0,
	; proves no full match		; proves no full match
	SIG NXT		SIG NXT
	skipping to change at page 12, line 10 ¶		skipping to change at page 13, line 29 ¶
	The following example contains an answer with wildcard expansion and		The following example contains an answer with wildcard expansion and
	the proof that there is no closer match. This is similar to a		the proof that there is no closer match. This is similar to a
	RFC2535 proof of non-existence.		RFC2535 proof of non-existence.
	QNAME= d.b.c.example. QTYPE=A		QNAME= d.b.c.example. QTYPE=A
	RCODE=ANSWER		RCODE=ANSWER
	;; Answer		;; Answer
	d.b.c.example. A 10.0.0.3 ; expansion of *.c		d.b.c.example. A 10.0.0.3 ; expansion of *.c
	SIG A (labelcount=2) ; labelcount proofs wildcard		SIG A (labelcount=2) ; labelcount proofs
	; example		; wildcard expansion
	;; Authority		;; Authority
	example.example. SOA		example.example. SOA
	SIG SOA		SIG SOA
	a.b.c.example. NXT f.example. A NXT SIG ; NOWILD-bit set to 0,		a.b.c.example. NXT f.example. A NXT SIG ; NOWILD-bit set to 0,
	; proves no exact match,		; proves no exact match,
	SIG NXT		SIG NXT
	a.c.example. NXT a.b.c.example. A NXT SIG ; NOWILD-bit set to 0		a.c.example. NXT a.b.c.example. A NXT SIG ; NOWILD-bit set to 0
	; proves non-existence of		; proves non-existence of
	; *.b.c.example.		; *.b.c.example.
	; No further proofs needed		; No further proofs needed
	;; Additional		;; Additional
	(... skipped ... )		(... skipped ... )
	A.2.5 The NXT 'next name' Proving Existence of a Wildcard
	In the zone above the a.b NXT RR has it's NOWILD-bit set to 1. If
	one would query for '#.c' which canonically orders between a.b and
	*.c one would get back "a.b NXT *.c". A attacker can use the this
	NXT RR in a malformed NXDOMAIN response.
	QNAME= #.c.example. QTYPE=A
	RCODE=NXDOMAIN ; Black hat answer !!!!
	;; Authority
	example.example SOA
	SIG SOA
	a.b.example. NXT *.c.example. A NXT NOWILD ; NOWILD-bit set to 1
	; but *.c exists
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
End of changes. 52 change blocks.
	143 lines changed or deleted		207 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/