Subject: Re: Q20: expanding wildcards in the authority section

From: Erik Rozendaal <[email-masked]>
Date: Thu, 04 Dec 2003 13:49:17 +0100

Olaf M. Kolkman wrote:
> 
>   Q20: Expansion of wild cards in the authority section.
> 
>       Default action, based on sense of the room at IETF58, is to not
>       expand the owner names of e.g. wildcard  NSEC RRs.
>      
>       If there is no further prohibitive objections by December 8 this 
>       will be taken as consensus of the working group.

I find this rather inconsistent with the normal behavior of wildcards. 
Currently wildcard owner names are always expanded to match the SNAME.

The current NSD DNSSEC implementation expands the wildcard NSEC record. 
However, changing it to not expand the wildcard is not a big deal.  But I'd 
still prefer consistent wildcard behavior when the wildcard matches the SNAME.

So (in order of preference) I'd like:

1. The wildcard MUST always be expanded when it matches SNAME.
2. The wildcard MUST NOT be expanded for NSEC records in the authority 
section even if it matches SNAME.
3. The wildcard MAY/SHOULD/SHOULD NOT be expanded.

Option 3 has additional complications for the client/resolver and would not 
be a good idea in my opinion.

I prefer option 1 but do not mind option 2.

Erik

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Fri, 05 Dec 2003 00:41:00 +1100

> I prefer option 1 but do not mind option 2.

	Say you have

	QNAME c.example.
	QTYPE A
	
	And you get the following back:

	(expanded *)
	RCODE=NOERROR Answer count=0
	c.example. NSEC b.example. TXT NSEC RRSIG
	c.example. RRSIG ...
	b.example. NSEC d.example. A NSEC RRSIG
	b.example. RRSIG ...

	(unexpanded *)
	RCODE=NOERROR Answer count=0
	*.example. NSEC b.example. TXT NSEC RRSIG
	*.example. RRSIG ...
	b.example. NSEC d.example. A NSEC RRSIG
	b.example. RRSIG ...

	The tests the validator has to go through for NOERROR NODATA
	are:

	Does QNAME exist? ****
	Yes: Is it a empty node
	     Yes: SUCCESS
	     No: Does the type exist at the node?
		 Yes: FAIL
		 No: SUCCESS
	No: Does a wildcard exist?  ****
	    Yes: Does the type exist in the wildcard? ****
		 Yes: FAIL
	         No: SUCCESS
	     No: FAIL
	
	Which of the above two answers makes it easier to answer the
	**** questions?

	Mark

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Erik Rozendaal <[email-masked]>
Date: Thu, 04 Dec 2003 15:21:57 +0100

> 	b.example. NSEC d.example. A NSEC RRSIG

Although the c.example. NSEC record looks a little funny, checking the 
RRSIG will show that the "true" owner name of the NSEC record is *.example. 
  So the same information is present whether the * is expanded or not.  And 
because checking RRSIGs is required anyway there is no additional processing.

Also note that querying for

QNAME c.example.
QTYPE NSEC

will also return

c.example NSEC b.example. TXT NSEC RRSIG
c.example RRSIG ....

but this time in the answer section.  And again the client will know the 
record was generated from a wildcard record.

> 	Which of the above two answers makes it easier to answer the

Given that the client knows a name was generated from a wildcard I do not 
see any differences in the difficulties of answering the above questions.

But your explanation does make it clearer to me why unexpanded wildcards 
were chosen, even though I still slightly prefer expanded wildcards.

Erik

---

From: Erik Rozendaal <[email-masked]>
Date: Thu, 04 Dec 2003 16:55:25 +0100

> were chosen, even though I still slightly prefer expanded wildcards.

Actually, I think I've changed my mind and I prefer not expanding wildcards 
for NSEC records in the authority section.

Consider a zone with the following RRs:

*.wc. IN NSEC xx TXT NSEC RRSIG
*.wc. IN RRSIG ...
xx.   IN NSEC yy TXT NSEC RRSIG
xx.   IN RRSIG ...

and the query

QNAME: foo.wc
QTYPE: A

Answer with expanded wildcard:

*.wc IN NSEC xx. TXT NSEC RRSIG
*.wc IN RRSIG ...
foo.wc IN NSEC xx. TXT NSEC RRSIG
foo.wc IN RRSIG ...

In this case the same RRset is included twice: the first time to prove the 
non-existance of foo.wc (no expansion of wildcard because the wildcard is 
not used as a match for QNAME) and the second time to show the QTYPE does 
not exist at the matched wildcard.  Of course, only one of these is really 
necessary but then we need to decide whether to include the expanded or 
unexpanded version in this particular case.

Answer without expanded wildcard:

*.wc IN NSEC xx. TXT NSEC RRSIG
*.wc IN RRSIG ...

In this case the RRset only needs to be included once and there is no 
(potential) ambiguity.

So I'll go with the current draft specification as it is (not expanding 
wildcards).

Erik