Subject: Re: [dnsext] Bundling of Domain Names and DNAME

From: Ondřej Surý <[email-masked]>
Date: Tue, 23 Feb 2010 14:54:13 +0100

Hi,

jumping on the discussion train very lately, so I have used Ed's email 
since it sums things very nicely.

I would like to slightly shift the paradigm which is used here.  Whole 
debate circles around IDN(A), but the DNAME can in the registry can be 
used without IDN at all.

Current semantics of DNAME makes whole DNAME idea quite unusable for 
almost anything, but very special cases, since without redirection at 
the owner you need to keep in sync records in the zone apex, which makes 
it very complicated and hard to understand for end users.

On 8.12.2009 18:03, Edward Lewis wrote:
> I've seen earlier posts and am still working my way through them, but
> this one has comments that I can't understand.
>
> At 2:08 +1100 12/9/09, Mark Andrews wrote:
>
>> Extending DNAME this way breaks the ability of a zone owner to
>> redirect themselves. It forces the redirection to be done in the
>> parent zone.
>
> In trying to understand what is meant by that comment, let's look at the
> three ways DNAME could appear relative to a zone cut.
>
> 1.) Above the zone cut:
[...]
> 2.) Inside a zone, i.e., not at the apex:
>
> $ORIGIN tld.
>
> xn--12345.tld. DNAME xn-54321.net.
> ;;
> xn--54321.tld. NS ns1.nameserver.example.net.
> xn--54321.tld. NS ns2.nameserver.example.net.
>
> In this case, any record types other than SOA, CNAME and NS can be
> present at the DNAME owner.
>
> xn--12345.tld. DNAME xn-54321.net.
> xn--12345.tld. TXT "text string from parent"
> xn--12345.tld. MX 10 mailserver.example.net.
> xn--12345.tld. MX 25 backupserver.example.net.
>
> In the existing rules, queries for xn--12345.tld./(DNAME, TXT, MX and
> ANY) will be sourced from the above, and NoError/NoData for all other
> types. The proposed new rule would later the latter to say "source the
> answer from whatever is at the DNAME target."
 >
> So there is redirection at the parent here, at least as far as I
> understand redirection.

+1

Would it really be a problem if we define that DNAME, which is not in 
the zone apex, would behave as C+DNAME?

Then the registry could allow to put DNAME records in TLD zone like:

sury.cz.		IN	DNAME	rfc1925.org.

and query to "IN MX sury.cz" then could return

sury.cz.		IN	DNAME	rfc1925.org.
sury.cz.		IN	CNAME	rfc1925.org.
rfc1925.org.		IN	MX	10 mail.rfc1925.org.

but query "IN A pagan.sury.cz" would also work:

sury.cz.		IN	DNAME	rfc1925.org.
pagan.sury.cz.		IN	CNAME	pagan.rfc1925.org.
pagan.rfc1925.org	IN	A	89.187.130.14

This could also prevent horrible things like you could sometimes see in 
the real world:

$ dig IN A idos.cz @ns.dmz.cd.cz
;; ANSWER SECTION:
idos.cz.		IN	CNAME	idos.timetable.cz.
idos.timetable.cz.	IN	CNAME	cluster.timetable.cz.
cluster.timetable.cz.	IN	A	77.93.209.54
cluster.timetable.cz.	IN	A	77.93.209.53

With current semantics you are unable to create redirections for both 
domain.tld and www.domain.tld, which leads to such a hacks in the DNS.

> 3.) At the apex of a zone:

If the DNAME is in the zone apex the authoritative server will not 
redirect (create dummy CNAME) OWNER to DNAME target.  I think this could 
be clearly defined.

>> If we need different semantics, create a new type and use it.
>
> The proposal is based on what has happened to the CNAME definition. We
> didn't create a new type for that.

This new proposal would render DNAME obsolete, so it looks to me it's 
much better to extend the semantics of DNAME in DNAMEbis proposal.

So the real question is: what problem does the extended semantics as 
proposed by Ed create?

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 24 Feb 2010 09:46:23 +1100

It is much better to keep the semantincs of DNAME exactly as they
are.  There are millions of nameservers out there that handle DNAME
correctly today.  DNAME is in use today.  You would break all the
zones using DNAME if you change its sematics.

If you want different semantics create a new record which signals
the different semantics.  That is what the BNAME proposal does.  It
creates a new type which redirects itself and the names under it.

See https://datatracker.ietf.org/doc/draft-yao-dnsext-bname/

The proposal still needs a lot of work but is going in the right
direction.
* DNSSEC integration.
* Signaling BNAME understanding.

I also think we should do BNAME regardless of whether it meets idn's
needs.  BNAME would work in the RFC2311 solution space whereas DNAME
doesn't.  Back when were were deciding DNAME's semantics there was
a discussion about whether it should affect the owner or not.  We
really should have just created two types then rather than trying
to pick one.

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

---

From: David Conrad <[email-masked]>
Date: Tue, 23 Feb 2010 15:13:08 -0800

On Feb 23, 2010, at 2:46 PM, Mark Andrews wrote:
> DNAME is in use today.  You would break all the zones using DNAME if you change its sematics.

People are actually using DNAME?

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Tue, 23 Feb 2010 23:33:18 +0000

> Date: Tue, 23 Feb 2010 14:54:13 +0100
> From: Ondřej Surý <[email-masked]>
> 
> Would it really be a problem if we define that DNAME, which is not in the
> zone apex, would behave as C+DNAME?

in that someone somewhere could be depending on current behaviour, and it's
just as easy to add BNAME as to change DNAME, yes, that would be a problem.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 24 Feb 2010 10:49:58 +1100

In message <[email-masked]>, David Conrad
 writes:
> > DNAME is in use today.  You would break all the zones using DNAME if =
> you change its sematics.
> 
yes.

---

From: [email-masked]
Date: Wed, 24 Feb 2010 01:50:58 +0000

> People are actually using DNAME?

	sure ... but we are generally of no influence.  the general rule seems to be
	that if .lt 15% of a population is using a feature its ok to rip it out.

--bill

---

From: David Conrad <[email-masked]>
Date: Tue, 23 Feb 2010 18:07:11 -0800

On Feb 23, 2010, at 5:50 PM, [email-masked] wrote:
> 	sure ...

The question I should've asked:

People are actually using DNAME in production in a way that would adversely affect their operations if it were deprecated and removed from DNS server implementations?

And how can you tell?

> but we are generally of no influence.  the general rule seems to be

Can you point me to your data that shows 15% of the DNS using population is using DNAME?

Regards,
-drc

---

From: "YAO Jiankang" <[email-masked]>
Date: Wed, 24 Feb 2010 13:57:51 +0800

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "Ondrej Surý" <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>; "Niall O'Reilly" <[email-masked]>; <[email-masked]>; <[email-masked]>; "Vaggelis Segredakis" <[email-masked]>; "'Sotiris Panaretou'" <[email-masked]>
Sent: Wednesday, February 24, 2010 6:46 AM
Subject: Re: [dnsext] Bundling of Domain Names and DNAME 

> needs. 

+1.

cname mapping itself;
dname mapping descendant;
bname mapping both itself and its descendant.

without bname, the mapping or redirection mechanism is not complete.

the bname can  used by both IDN bundle names and other ASCII names.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 24 Feb 2010 08:59:52 +0100

> really should have just created two types then rather than trying

Mark,

thanks for the pointer.  I see I am very behind in dnsext mailling list.

My thought behind this was that (our) registry could provide additional 
service for registrants and allow them to put BNAME to TLD instead of 
just delegation.  But it needs deeper analysis of the impact on DNS 
servers before any decision is made.

Ondrej

---

From: Chris Thompson <[email-masked]>
Date: 24 Feb 2010 15:56:05 +0000

>People are actually using DNAME?

You bet your life we are - and you can expect some of us to resist
a gratuitous change of spec that breaks our existing uses of it, up
to IETF level.

We use DNAMEs, both at zone apex and otherwise, in IPv4 reverse zones
to consolidate the data from many small ranges in a sub-domain of the
corresponding forward zone, e.g.

$ dig +noall +answer +nottl +nocl -x 128.232.144.42
144.232.128.in-addr.arpa. DNAME 144.232.128.in-addr.arpa.cam.ac.uk.
42.144.232.128.in-addr.arpa. CNAME 42.144.232.128.in-addr.arpa.cam.ac.uk.
42.144.232.128.in-addr.arpa.cam.ac.uk. PTR dhcp-128-232-144-42.eduroam.csx.cam.ac.uk.

$ dig +noall +answer +nottl +nocl -x 192.153.213.254
213.153.192.in-addr.arpa. DNAME 213.153.192.in-addr.arpa.cam.ac.uk.
254.213.153.192.in-addr.arpa. CNAME 254.213.153.192.in-addr.arpa.cam.ac.uk.
254.213.153.192.in-addr.arpa.cam.ac.uk. PTR gw-808.net.cam.ac.uk.

(The second is a zone-apex DNAME which we would in principle like to
be pulled back into the parent zone.) I know there are others doing
similar things with IPv6 reverse zones.

I support the BNAME idea, incidentally (well, the concept - I'm not too
keen on the mnemonic...).

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 24 Feb 2010 12:07:30 -0500

> the bname can  used by both IDN bundle names and other ASCII names.

What should the design criteria for Redirection RR type be ?

In the evaluation of BNAME proposal as a strawman in the the
Redirection space here are some questions to start the discussion

What can BNAME point to:
	any name
	only delegations

Should we allow BNAME chains, or should BNAME point directly at target.

Can we have BNAME -> DNAME -> BNAME -> CNAME ?
	(or some other mix of [BCD]name(s)

What backwards compatability should protocol provide?

Should the protocol provide indicatator of BNAME support?

	Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 24 Feb 2010 12:11:50 -0500

> corresponding forward zone, e.g.

A more appropriate question is:
If DNAME specification is changed to allow followup to DNAME target
if Qtype does not exist at the location of the DNAME record,
will that negativly affect existing DNAME use?

	Olafur

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Feb 2010 09:41:56 +1100

> will that negativly affect existing DNAME use?

Yes.  You will then have the same problem as CNAME and other data
produces in caches.  Just don't go there.  A record that synthesises
a CNAME has all the problems of CNAME and other data for the owner
name of the synthesised CNAME as CNAME has.
 
> 	Olafur

BNAME can be made RFC 1034 cache friendly (only the CNAME is seen
by the non-BNAME aware caches, requires BNAME aware clients to
signal awareness (EDNS option?)).  BNAME can be made DNSSEC friendly
(the zone in only signed with BNAME aware algorithm identifiers).
BNAME can be declared to not co-exist with other records (DNSSEC
aside) removing the "CNAME and other data" problems with caches.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Feb 2010 11:56:55 +1100

> Redirection space here are some questions to start the discussion

Any name.

> Should we allow BNAME chains, or should BNAME point directly at target.

BNAME SHOULD not point to other BNAMEs or CNAMEs but this advisary.
This fits with RFC 1034's basic requirements.

> 	(or some other mix of [BCD]name(s)

Yes, but it is not desirable.
 
> What backwards compatability should protocol provide?

If the client does not indicate BNAME support it *only* sees the
CNAME records in the response.  Direct queries for BNAME return
BNAME.

A zone containing a BNAME record MUST NOT be signed with any of the
existing DNSSEC algorithm identifiers.  i.e. it will be treated as
insecure by all existing validators.  Future DNSSEC algorithm
identifiers will indicate BNAME awareness, similar to the way NSEC3
awareness is signaled using DNSSEC algorithm identifiers.

> Should the protocol provide indicatator of BNAME support?

Yes.