Subject: Re: DNSSEC wildcard optimization.

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 23 Oct 2002 16:58:17 -0400 (EDT)

On Wed, 23 Oct 2002, Olaf Kolkman wrote:

>
>
>  * 1. Overloading the SIG bit, in my mind is a "BAD" idea.
>  * I think it is a better design for humans and software to explicitly
>  * state that wild card may apply in the gap between the left hand side
>  * name and the right hand side name of an NXT. We have plenty of bits
>  * to use including the following undocumented type codes
>  *     EID             31 Endpoint Identifier                    [Patton]
>  *     NIMLOC          32 Nimrod Locator                         [Patton]
>  *     ATMA            34 ATM Address                         [Dobrowski]
>  *     SINK            40 SINK                                 [Eastlake]
>  *
>
>
> By introducing a new type one looses the packet size optimization as described
> in section 1.2:
>
> <quote>
>    o  Packet size of answers reduce in most common cases; for the root
>       zone the authority section only contains 1 NXT RR with associated
>       SIGs instead of two NXT RRs with associated SIGs.
> </quote>
>
> Note that the extra NXT RR without the optimization of the new RR-TYPE
> will need to come with 1 or more SIG RRs. I think that that warrants
> the 'overloading' of the SIG in the  NXT bitmap.
>

This does not follow, the same rules apply,
if WILD is set there is possibly matching Wild card
	==> requires multiple NXT if qname does not match name on NXT.
if WILD not set there is no wildcard match possible thus no need for
	more NXT's

> Out of curiosity: Why is overloading the SIG bit a "BAD" idea? Why is it
> worse than overloading the NXT bit?
>
It is not as bad because no NXT bit implies that the NXT matching rules
have changed, in this case the the NXT bitmap is expressing if other
NXT's are needed.

>
>  * 2. I think the bit should have a more explicit name say "WILD" or "WILDC",
>  * NTAS looks like misspelled NAT.
>
> Agreed, seems the DNS protocol is running out of acronyms :-).  What
> about NOWILD, if it is set there are no wildcards, which is more
> intuitive than WILD. I welcome other ideas.

I think it is better to say "Something else may match" than "Nothing else
matches", personal preference.

>
>
>  * 3. The document does not address at all the issues for dynamic zones
>  * that have wild cards. In this case a creation/deletion of a name can
>  * require the resigning of many NXT records.
>
> I will add a section on dynamic zones. In short:
>
> When adding a regular name dynamically you do not need to
> modify/generate more NXT rrs than in the non-optimized set. You just
> need to change the previous NXT nxt-name to point to the name just
> inserted and you will have to do determine if the NTAS bit needs to be
> set for the new RR.
>
> If one adds wildcards dynamically then you have to possibly modify a

s+add wildcards+adds/deletes wildcard sets+

> larger number of NXT RRs. Those NXT RR can be identified as described
> in the 2nd paragraph of section 2.
>
> If adding wildcards dynamically is allowed by the protocol (an I don't
> think there are any restrictions there) then I guess there is a choice
> to not set the optimization bit at all for the zone and that choice
> needs to be made explicit in the draft.

yes it is allowed.

>
>  *
>  * 4. RFC1035 wild card algorithm is unclear and needs clarification,
>  * publishing this protocol change without fixing the specification is not
>  * prudent, and I encourage the authors on taking on the clarification effort.
>  *
>
> Agreed.
>
>
>  * 5. There is a significant misunderstanding in the community on how
>  * wildcards apply.
>
> I agree with that, I remember it took me a long time to fully
> understand what was happening, and it is still a difficult topic to
> explain clearly during courses. But the understanding and (ab)use of
> wildcards are outside the scope of the draft. The draft assumes that
> wildcards and DNSSEC go hand-in-hand.
>

>  *
>  * 6. Overall, IFF wildcards are needed then something like this will help
>  * DNSSEC a lot.
>
> Has the discussion on that conditional ever converged?
>

It degenerates into a flame war each time :-(
Someone needs to take the time to write
"The case against wildcards in DNS" or "How to live happily without
DNS wildcards"

We need to determine REAL SOON if this effort is important enough to
be included in the Opt-in/DS/AD-secure flag day (or any subset of them).

	Olafur

--
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: Edward Lewis <[email-masked]>
Date: Fri, 25 Oct 2002 09:31:40 -0400

At 5:34 -0700 10/25/02, David Conrad wrote:

let your = "Olaf"

>I do not disagree that your draft can provide optimizations.  My concern is
>that the corner cases not addressed in your draft (e.g., ddns) will require
>additional iterations before we can be confident it doesn't have weird side
>effects.  Should the new DNSSEC wait for those iterations to complete?

I've thought about dynamic update.  Whether an NXT RR is generated by 
a static signer or a dynamic update signer, the environment is the 
same.  (Especially because during a dynamic update process, the zone 
is temporarily static as the operation is considered atomic.)

CNAME's aren't an issue - no matter how it is implemented.  The 
generation of the no wildcard indication is done statically, and not 
in the motion of a query/response activity.

>I'm also worried about _any_ additional complexity within the server --
>optimizing tends to add special cases and code shortcuts.  DNSSEC is already
>far too complex, as we all know.

Without having implemented anything, the complexity rises:
1) In the static signer, having to do a wildcard "search"
2) In the dynamic update signer, the same as above

Complexity is argurable in:
1) The server, checks for the no-wildcard indication but may no 
longer have to perform the wildcard search
2) The resolver, the same as above - but the savings are greater as 
there's also no need to worry about validating the NXT's proving 
there's no wildcard.
3) The protocol, the indicator format is an issue to me still, and 
causes some repercussions that I still think need addressing.  But 
the average message will have to contain fewer records (no NXT to 
prove the no-wildcard case).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Paul Vixie <[email-masked]>
Date: Fri, 25 Oct 2002 16:30:49 +0000

> ...  Should the new DNSSEC wait for those iterations to complete?

<sarcasm>
Why not?  It waits for every other good idea anybody thinks of at the
last possible second before "deployment".
</sarcasm>