Subject: Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same")

From: "zhanglikun" <[email-masked]>
Date: Thu, 12 Aug 2010 21:28:37 +0800

I don't plan to add more arguments for the provision way, since the
complexity it brings when comes to multiple-labels domain equivalence, which
has been mentioned by former emails, it's o(a^n),  instead xName is o(n) .

Now let me go back to c+dname VS bname.

If one zone has records:
a.net.  cname  a.cn.
a.net.  dname  b.com.

user do the query with the following sequence:
dig  a.net.  cname
dig  a.net.  dname

if the cache isn't aware of the new c+dname rules, will the second query
will chase down to b.com.? it will try to chase down a dname record
belonging to a.cn. rather than b.com.  Except the c+dname has one rule: the
rdata part of should be same.

anther, when doing update, you have to be very careful to decide whether to
remove/add c+dname or just one of them.
Last, c+dname will double zone size, compared with bname.

My point is +1 for bname.

Anyway, this topic recall me to the added voice saying no to DNAME long
before(five years ago or more), somebody said he had a complete dislike for
the DNAME, not just the document but also the idea, even though the DNAME
had born.  :)

Thanks
Likun Zhang

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 13 Aug 2010 15:52:41 +0200

On 12.8.2010 15:28, zhanglikun wrote:
> If one zone has records: a.net.  cname  a.cn. a.net.  dname  b.com.
>
> user do the query with the following sequence: dig  a.net.  cname
> dig a.net.  dname
>
> if the cache isn't aware of the new c+dname rules, will the second
> query will chase down to b.com.?
 > It will try to chase down a dname record belonging to a.cn. rather
 > than b.com.

Yes, but Wouter and I have already mentioned that the workaround is to 
query for anything below the owner.  (Sorry for using your email user 
part for testing purposes, I was out of ideas how to name it.)

$ dig +noall +answer IN CNAME zhanglikun.dname.cz @127.0.0.2
zhanglikun.dname.cz.	60	IN	CNAME	target1.dname.cz.

$ dig +noall +answer IN DNAME zhanglikun.dname.cz @127.0.0.2
zhanglikun.dname.cz.	55	IN	CNAME	target1.dname.cz.
target1.dname.cz.	60	IN	DNAME	ccccc.dname.cz.

So yes, you are right here.  However the important is what happens if 
you resolver <anything>.<owner>:

$ dig +noall +answer IN DNAME www.zhanglikun.dname.cz @127.0.0.2
zhanglikun.dname.cz.	60	IN	DNAME	target2.dname.cz.
www.zhanglikun.dname.cz. 0	IN	CNAME	www.target2.dname.cz.
target2.dname.cz.	60	IN	DNAME	ddddd.dname.cz.
www.target2.dname.cz.	0	IN	CNAME	www.ddddd.dname.cz.

This works even when you have chained caches (tested unbound and bind9 
as downstream, bind9 as upstream).

> Except the c+dname has one rule: the rdata part of should be same.

There is no such rule.

> another, when doing update, you have to be very careful to decide
> whether to remove/add c+dname or just one of them.

Yes, you have to be careful when you edit your zone.  What's the new 
thing here?

> Last, c+dname will double zone size, compared with bname.

Common...  right now the registry put at least 2 or more NS records (and 
glue).

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
  -------------------------------------------