Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Apr 2010 11:45:06 +1000

Mark Andrews writes:
> In message <[email-masked]>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= writes
> :
> > Hi,
> > 
> > I hereby present the "other" solution to name sameness (we all call it 
> > CNAME+DNAME, aren't we?).  It's little bit competing with BNAME 
> > proposal, but it should be simpler to implement.  It doesn't introduce 
> > new RTYPE, it just loosens the singleton rule of CNAME to allow DNAME 
> > for the same name (we did this before with NSEC+RRSIG, remember?)
> 
> It doesn't matter if it can be made to work with some resolvers.
> It is just plain out a bad idea to change the behaviour of existing
> records unless you really have no choice.  With DNSSEC there was
> no choice because you want to secure the CNAME record.  There is a
> choice here however.
> 
> > Just FYI, try digging idos.cz (or jizdnirady.cz) before you start 
> > writing this email and think if this proposal really breaks existing 
> > behaviour (if the existing resolvers are able to cope with this).
> 
> Where's the DNAME in the response?  If you want us to believe that
> it works the DNAME needs to be returned.  For good measure it also
> has to work with a signed zone.  It's relatively easy to change
> named to allow a DNAME and CNAME to co-exist see
> lib/dns/rbtdb.c:cname_and_other_data().

Needed one other conditional needed to be changed to make the
authoritative side provide consistent signed results.  None of this
however is to say I think this is a good idea but if you want to
experiment then you need to do a proper experiment.

And if one is relaxing CNAME and other data rules then NS and SOA
are also obvious candidates.

Mark

Index: lib/dns/rbtdb.c
===================================================================
RCS file: /proj/cvs/prod/bind9/lib/dns/rbtdb.c,v
retrieving revision 1.300
diff -u -r1.300 rbtdb.c
--- lib/dns/rbtdb.c	26 Feb 2010 00:18:06 -0000	1.300
+++ lib/dns/rbtdb.c	16 Apr 2010 01:28:10 -0000
@@ -3679,7 +3679,8 @@
 	 * We don't check for RRSIG, because we don't store RRSIG records
 	 * directly.
 	 */
-	if (type == dns_rdatatype_key || type == dns_rdatatype_nsec)
+	if (type == dns_rdatatype_key || type == dns_rdatatype_nsec ||
+	    type == dns_rdatatype_dname)
 		cname_ok = ISC_FALSE;
 
 	/*
@@ -5513,6 +5514,7 @@
 			if (rdtype != dns_rdatatype_key &&
 			    rdtype != dns_rdatatype_sig &&
 			    rdtype != dns_rdatatype_nsec &&
+			    rdtype != dns_rdatatype_dname &&
 			    rdtype != dns_rdatatype_rrsig) {
 				/*
 				 * Is it active and extant?
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Matthew Dempsky <[email-masked]>
Date: Thu, 15 Apr 2010 19:44:14 -0700

> are also obvious candidates.

And DS?

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Apr 2010 13:03:19 +1000

In message <[email-masked]>, Ma
> > are also obvious candidates.

No.  DS only co-exists with delegating NS's.  If it wasn't obvious
that is NS and SOA at the apex of a zone.  CNAME at a delegation
would not be visible.

The cache might see DS/NS/SOA/CNAME/DNAME all co-existing together
but the authorative side would not under this regime.

Mark

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 16 Apr 2010 00:42:17 -0700

> but the authorative side would not under this regime.

Ah, got it.  I didn't catch that we were talking about authoritative
only, rather than in-general what records might need to coexist at an
owner name with CNAME records.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 22 Apr 2010 15:44:51 +0200

> are also obvious candidates.

Sounds interesting.  I am little afraid that this could have bigger 
impact than just allowing CNAME+DNAME.  But let me think of it for some 
time and I'll try to do some testing.

Another thing I am afraid of is that allowing CNAME+DNAME in the zone 
apex is "too radical" for dnsext, so it might kill the lighter proposal 
for CNAME+DNAME.  You can always put CNAME+DNAME to a parent zone.

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/R&D manager
  -------------------------------------------
  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
  -------------------------------------------