Subject: [dnsext] C+D vs. B

From: Paul Vixie <[email-masked]>
Date: Fri, 13 Aug 2010 18:07:48 +0000

the following code exists in a deployed (commercial, closed-source)
recursive dns server.  (which i wrote during a sabbatical in 2003.)

	...

	/* Cache error means there can't be a CNAME.  This happens
	 * when we have no root hints at all.
	 */
	if (dom == NULL)
	        break;

	/* If QTYPE is CNAME then return it rather than following it.
	 */
	if (qtype == ns_t_cname)
	        break;

	/* If there's no CNAME in cache but there's any other type
	 * (unexpired), then there cannot be a CNAME and we're done.
	 * Note: this is an optimization to avoid dns_cache_findtype.
	 */
	anytype = (dns_cache_anytype(dom, now.tv_sec) != NULL);
	if ((dns_dom_getflags(dom) & DNS_DOM_ISALIAS) == 0 &&
	    anytype)
	        break;

	/* Handle CNAME (if it exists) chaining. */
	switch (dns_cache_findtype(dc, dom, qclass, ns_t_cname,
				   FALSE, &rrset, now.tv_sec))
	{
		...

i've mentioned this a couple times here, but i thought a real code example
would help illustrate why C+D would need signalling.  the above code is
correct, and must never be exposed to the C+D data pattern, because that
data pattern would violate this code's assumptions, making it incorrect.
one of our duties as protocol stewards is to not invalidate existing
correct implementations.  (sometimes we also have to avoid invalidating
existing incorrect implementations, but this is not one of those times.)

on my drive to work today i realized there's an even deeper problem, which
is that DNAME can coexist with lots of other types.  DNAME-at-apex is for
example how we handled the IP6.INT problem:

	http://ftp.isc.org/isc/pubs/tn/isc-tn-2002-1.txt

when we talk about C+D we're really talking about C+D+other, where "other"
is all the things that DNAME can presently coexist with.  which means, when
we talk about C+D we're really talking about C+anything.  

i'd like C+anything.  it should have been there from day 1.  it's what a lot
of people think (incorrectly, until they try it and it doesn't work) that
wildcards mean.

but C+anything will require signalling, to protect existing (correct)
implementations from a data pattern that they reasonably assumed could
never exist.

if we're voting, i'd like C+anything because it would be useful for many
things, but as an implementor and operator, i'd find B easier and cleaner.
(both approaches mean the same thing and both need signalling, but B is
a new code point whereas C+D adds meaning to existing code points.)

---

From: Florian Weimer <[email-masked]>
Date: Mon, 16 Aug 2010 07:38:59 +0000

* Mark Andrews:

> C+D mean C+D or D+other but not C+D+other (excluding DNSSEC).

I think this means you have to create all your aliases in their
respective parent zones.  Is this desirable?

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 18 Aug 2010 15:02:15 +0200

On 16.8.2010 16:38, Mark Andrews wrote:
> In message<[email-masked]>, Florian Weimer writes:
>> * Mark Andrews:
>>
>>>> when we talk about C+D we're really talking about C+D+other, where "othe=
>> r"
>>>> is all the things that DNAME can presently coexist with.  which means, w=
>> hen
>>>> we talk about C+D we're really talking about C+anything.=20=20
>>>

Personally I don't see that as a big problem.  But I speak with just .CZ 
registry hat on.

> C+D is a delegation alternative.
> B is a delegation alternative.
>
> B is not allowed at a apex (or where there is other data) as it
> acts like C.
>
> C+D+SOA+NS would allow for the child to add C+D at the apex but that
> isn't part of the current C+D proposal.

So... can we have B+SOA+NS (and +DNSKEY+NSEC+RRSIG)?  That would be less 
controversial than adding support for C+SOA+NS.  On the other hand - 
maybe separate C+NS+SOA would be great to have as well (not only because 
you can see that in the wild).  Allowing C+D is just an added bonus.

O.
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------