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

From: Ondřej Surý <[email-masked]>
Date: Thu, 15 Apr 2010 16:21:18 +0200

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

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

Ondrej

-------- Original Message --------
Subject: New Version Notification for draft-sury-dnsext-cname-dname-00
Date: Thu, 15 Apr 2010 07:16:25 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]

A new version of I-D, draft-sury-dnsext-cname-dname-00.txt has been 
successfully submitted by Ondrej Sury and posted to the IETF repository.

Filename:	 draft-sury-dnsext-cname-dname
Revision:	 00
Title:		 CNAME+DNAME Name Redirection
Creation_date:	 2010-04-15
WG ID:		 Independent Submission
Number_of_pages: 5

Abstract:
This document proposes a modification to CNAME record to coexist with
DNAME record, which provides redirection for a sub-tree of the domain
name tree in the DNS system.  By allowing this cooexistence, DNS
system will have a way how to create a sub-tree redirection together
with record owner.  This would allow parent zones to create full
domain aliases.

The IETF Secretariat.

-- 
  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: Fri, 16 Apr 2010 09:26:19 +1000

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

> 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().

; <<>> DiG 9.3.6-P1 <<>> www.idos.cz @ns.dmz.cd.cz +norec
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57649
;; flags: qr aa ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.idos.cz.			IN	A

;; ANSWER SECTION:
www.idos.cz.		14400	IN	CNAME	idos.timetable.cz.
idos.timetable.cz.	91	IN	CNAME	cluster.timetable.cz.
cluster.timetable.cz.	195	IN	A	77.93.209.54
cluster.timetable.cz.	195	IN	A	77.93.209.53

;; Query time: 344 msec
;; SERVER: 81.19.46.20#53(81.19.46.20)
;; WHEN: Fri Apr 16 08:35:47 2010
;; MSG SIZE  rcvd: 112

; <<>> DiG 9.3.6-P1 <<>> any idos.cz @ns.dmz.cd.cz
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46373
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;idos.cz.			IN	ANY

;; ANSWER SECTION:
idos.cz.		14400	IN	NS	mail.dmz.cd.cz.
idos.cz.		14400	IN	NS	ns.dmz.cd.cz.
idos.cz.		14400	IN	CNAME	idos.timetable.cz.
idos.cz.		14400	IN	SOA	ns.dmz.cd.cz. hostmaster.dmz.cd.cz. 2008062337 3600 900 604800 14400

;; ADDITIONAL SECTION:
mail.dmz.cd.cz.		14400	IN	A	81.19.46.25
mail.dmz.cd.cz.		14400	IN	A	81.19.46.24
ns.dmz.cd.cz.		14400	IN	A	81.19.46.19
ns.dmz.cd.cz.		14400	IN	A	81.19.46.20

;; Query time: 344 msec
;; SERVER: 81.19.46.20#53(81.19.46.20)
;; WHEN: Fri Apr 16 08:38:29 2010
;; MSG SIZE  rcvd: 208

; <<>> DiG 9.3.6-P1 <<>> ns idos.cz +norec @ns.dmz.cd.cz
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38001
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;idos.cz.			IN	NS

;; ANSWER SECTION:
idos.cz.		14400	IN	CNAME	idos.timetable.cz.

;; Query time: 340 msec
;; SERVER: 81.19.46.20#53(81.19.46.20)
;; WHEN: Fri Apr 16 08:39:31 2010
;; MSG SIZE  rcvd: 54

> Ondrej

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

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Apr 2010 00:24:00 +0000

> ;; WHEN: Fri Apr 16 08:35:47 2010

the proper response by a full resolver who received an answer like this
would be to process the first CNAME, throw everything else away, and
restart the query at the target of the CNAME.  i'm amazed when i see
out-of-zone CNAME responses on the wire like this, even when the server is
authoritative for both zones.  (yes, i know BIND sends the same thing, but
i consider it a bug now that we've survived kaminsky's Summer of Fear.)

---

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

> i consider it a bug now that we've survived kaminsky's Summer of Fear.)

[note the Subject: change]

And a stub needs the full response.  Changing the algorithm to only
restart the query if RD is set and recursion is permitted may be
one way to address this.

Mark

---

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

On 16.4.2010 01:26, Mark Andrews wrote:
> In message<[email-masked]>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= writes:
>> Hi,
>>

What I am trying to point out, that we are not changing any existing 
"behaviour" _in the wild_.  We are just changing the specs, but existing 
DNS resolvers behaviour will stay same.

But I differ from your view.  My opinion is that we could change 
existing behaviour if it doesn't have any regressions and it will 
improve/simplify existing state of things.

> lib/dns/rbtdb.c:cname_and_other_data().

Point taken.  dname.cz nameservers are running patched bind (thanks for 
the patch) and open XFR from any.

If anybody wants more test cases or some record to be added, just ping me.

I'll add DNSSEC later today.  Right now the contents of the zone is:

dname.cz.		60 IN SOA cool.nic.cz. hostmaster.udp53.cz. (
				3          ; serial
				604800     ; refresh (1 week)
				86400      ; retry (1 day)
				2419200    ; expire (4 weeks)
				604800     ; minimum (1 week)
				)
dname.cz.		60 IN NS cool.nic.cz.
dname.cz.		60 IN NS ignum.nic.cz.
bar.dname.cz.		60 IN CNAME foo.dname.cz.
bar.dname.cz.		60 IN DNAME foo.dname.cz.
foo.dname.cz.		60 IN MX 10 blackhole.nic.cz.
www.foo.dname.cz.	60 IN A	217.31.205.50
www.foo.dname.cz.	60 IN AAAA 2001:1488:0:3::2
nic.dname.cz.		60 IN CNAME nic.cz.
nic.dname.cz.		60 IN DNAME nic.cz.
udp53.dname.cz.		60 IN CNAME udp53.cz.
udp53.dname.cz.		60 IN DNAME udp53.cz.

I have also configured website at conficker.nic.cz to also accept 
conficker.nic.dname.cz and eyechart.nic.dname.cz, if you want to test 
your browser/stub/resolver combo.

Ondrej

---

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

George,

On 18.4.2010 08:02, George Barwood wrote:
> Ondrej
> I have looked at this proposal.

Thanks for your comments.

> I think maybe you need to clarify
> what is returned in response to DNAME and ANY queries with owner matching
> the DNAME record ( answer : only the CNAME is returned, I think ).

Well, I think that existing behaviour is already OK:

ondrej@ookami:~$ dig IN ANY bar.dname.cz @cool.nic.cz
bar.dname.cz.		CNAME	foo.dname.cz.
bar.dname.cz.		DNAME	foo.dname.cz.

ondrej@ookami:~$ dig IN DNAME bar.dname.cz @cool.nic.cz
bar.dname.cz.		DNAME	foo.dname.cz.

ondrej@ookami:~$ dig IN CNAME bar.dname.cz @cool.nic.cz
bar.dname.cz.		CNAME	foo.dname.cz.

But I agree that it deserves clarification.

> Also, is it the case that the CNAME and DNAME MUST agree,

I don't understand what you mean here, can you clarify?

>  NSEC, NSEC3

CNAME and DNAME bits are set in NSEC and NSEC3.  I don't think that this 
changes anything from current state.

> However, from a zone administration point of view, BNAME is simpler.

Is it?  I would agree that BNAME would be simpler if it would replace 
CNAME and DNAME, and not complement them.  BNAME alone is simpler, but 
CNAME+DNAME+BNAME is not (at least in my eyes).

But after all it's just matter of presentation layer - the registrar 
could offer the registrant an option to create full alias and it would 
expand to CNAME+DNAME in the provisioning system.

> I therefore suggest the possibility of BNAME in the unsigned zone file,
> BNAME+CNAME+DNAME in the signed zone file and CNAME+DNAME on the wire
> as an interim measure, allowing compatibility with existing validating
> resolvers until BNAME is implemented by clients.
[...stripped the table...]

I have looked at your table and it seems to me that you have 
demonstrated that there is no real need for BNAME, if you can easily 
replace it with CNAME+DNAME combo.

But I understand your point, I am just not convinced that it's a right 
way to go.

Ondrej

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 22 Apr 2010 17:01:56 +0200

On 22.4.2010 16:46, George Barwood wrote:
>
> ----- Original Message -----
> From: "Ondřej Surý"<[email-masked]>
> To: "George Barwood"<[email-masked]>
> Cc:<[email-masked]>
> Sent: Thursday, April 22, 2010 2:41 PM
> Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00
>
>
>> George,
>>
> Well we disagree here a bit. I was expecting  just the CNAME to be returned in every case,
> my thinking is that the CNAME matching takes precedence over everything else, and
> once the CNAME is found, no other processing is performed.

Nope, that would be different behaviour for RRSIG/NSEC/NSEC3 and DNAME. 
  Try:

$ dig +norec IN ANY www.udp53.cz @rfc1034.udp53.cz.
[...]
$ dig +norec IN CNAME www.udp53.cz @rfc1034.udp53.cz.
[...]
$ dig +norec IN RRSIG www.udp53.cz @rfc1034.udp53.cz.
[...]
$ dig +norec IN NSEC www.udp53.cz @rfc1034.udp53.cz.
[...]

Answers are stripped to not clutter this list.

> I mean is it legal to have
>
> bar.dname.cz CNAME foo1.dname.cz.
> bar.dname.cz. DNAME foo2.dname.cz.

Yes, why not?  There could be possible a warning in named-checkzone (and 
other check tools), but it's perfectly legal in my view.

> Right, that is certainly an option. Which is better is a matter of judgement.
> If we were starting from scratch, BNAME would be best.

Ok, we agree on that.

 > From where we are, I don't know.

Well, my proposal is just two hunk patch in bind9 and I guess for nsd 
(and others) it would be same amount of work.  It's compatible with 
current resolvers (althought more testing is needed).

BNAME proposal needs new RRTYPE allocated by IANA and implemented in all 
resolvers (with new logic) and all authoritative servers.

> I was only proposing this as a possibility to be considered.
> I'm not expressing an opinion on which way is best.

Ok, thanks for all your comments.

> I would like to see a "clean" solution, even if it takes a long while to get there.

Here it depends what each of us consider to be "clean" :).  I don't mind 
changing protocol if it maintains backwards compatibility and I still 
consider it to be "clean".

Ondrej

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Apr 2010 10:31:27 +1000

> current resolvers (althought more testing is needed).

Except it isn't a two hunk patch.   It was a two hunk patch to make
named act correctly as a *authoritative* server.

The resolver side of named also needs to be changed to support the
new sematics of CNAME.   Given what I saw on the authoritative side
I'm not sure that I could succesfully validate signed answers from
a forwarder.

Mark

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 23 Apr 2010 10:08:45 +0200

On 23.4.2010 02:31, Mark Andrews wrote:
> In message<[email-masked]>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?=
> writes:
>> Well, my proposal is just two hunk patch in bind9 and I guess for
>> nsd (and others) it would be same amount of work.  It's compatible
>> with current resolvers (althought more testing is needed).
>

True, but at least Bind and Unbound work fine just as they are.

> new sematics of CNAME.

I'll do more extensive testing with all free resolvers (which support
DNAME) next week (I have vacation today and on Monday).  If somebody can
test Microsoft DNS resolver and CNS, it would be great.

> Given what I saw on the authoritative side I'm not sure that I could
> successfully validate signed answers from a forwarder.

Ok, let's give it a try.

target.dname.cz. IN CNAME ccccc.dname.cz.
target.dname.cz. IN DNAME ddddd.dname.cz.

dname.cz zone is signed and DS is published in .CZ.

I am using DNS-OARC resolvers (.20 is BIND 9, .21 is Unbound).

Dig options are: +noall +comment +adflag

ondrej@ookami:~$ dig IN A target.dname.cz @149.20.64.20
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13559
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0

ondrej@ookami:~$ dig IN A target.dname.cz @149.20.64.21
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64158
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0

ondrej@ookami:~$ dig IN A www.target.dname.cz @149.20.64.20
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60920
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 0

ondrej@ookami:~$ dig IN A www.target.dname.cz @149.20.64.21
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16900
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 0

So it looks like those two common existing implementation are already
ready for CNAME+DNAME.

And that's exacly  my point - with very simple change in CNAME semantics
we can get full alias in the DNS tree, which is already supported by
majority of DNS servers in the wild (at least those supporting DNAME).

I am sure that this will break something somewhere, but those place
would be broken with BNAME as well.  But BNAME has to be implemented
everywhere - authoritative DNS, resolvers, firewalls, etc.

Don't get me wrong, I think that BNAME is fine proposal, but I think
that we have much simpler option right before us.  Also it not something
new, we did change semantics of CNAME before, because of DNSSEC, so I am
not proposing revolution, just merging of two existing working principles.

O.

---

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 23 Apr 2010 16:58:49 +0800

----- Original Message ----- 
From: "Ondřej Surý" <[email-masked]>
To: "Mark Andrews" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 23, 2010 4:08 PM
Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00

> majority of DNS servers in the wild (at least those supporting DNAME).

the CNAME is the basic record. many protocols base on it.

if you want to break CNAME,  you are trying to shake the basis of DNS.

if you build a rule, 1000 users have followed it and you may update or modify the rule.

if you build a rule, 1000,000,000 users have followed it and you should be CAUTION when you wish to update or modify the rule.

if a new Record is submitted, someone may choose to follow or not.
but if you change the basic rule, you must push each of 1000,000,000 users  to follow it.

how to decide it, we should consider the trade off.

Jiankang Yao

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 23 Apr 2010 11:37:37 +0200

> the CNAME is the basic record. many protocols base on it.

That's not true.  No protocol I know except DNS rely on CNAME.  All 
other protocols asks for A,AAAA (usually via getaddrinfo via your 
resolver), MX, SRV, etc.  I am not aware of any protocol directly asking 
for CNAME records.

> if you want to break CNAME,  you are trying to shake the basis of DNS.

I am not breaking CNAME.  If you think I am breaking CNAME please prove 
it or stop saying that.  I am enhancing CNAME semantics to allow 
coexistence with DNAME.  CNAME and DNAME don't share same alias space. 
Also there is no change by default - it could only affect other party in 
case you also add DNAME.

> but if you change the basic rule, you must push each of 1000,000,000 users  to follow it.

Sorry, but no, that's not true either.  This could possibly break some 
authoritative and/or recursive DNS server.  But in a way which is 
exactly same as adding new RRTYPE - since nobody is forced to add 
CNAME+DNAME to it's zone.  And I have already proven that it doesn't 
break Bind 9 or Unbound functioning as resolvers, and that's mainly 
because there are already much worse scenarios in DNS tree - as I have 
also shown with idos.cz case.  And I am willing to retest more resolvers 
(including older versions of Bind9), I just don't have a time for it 
right now.

It will have no impact on common end user - because in normal 
circumstances CNAME is not used directly - it's handled by resolvers.

Also loosening CNAME rules will not break anything for 1.000.000.000 
users already using CNAMEs.  It will only affect:

1) users adding CNAME+DNAME to their zones
2) users using such zones

But that's not different from BNAME.

I know I am touching the very basics of DNS and I also consider RFC1034 
and RFC1034 to be sacred :-), but please let's work with facts, test 
cases, test scenarios etc.  If you feel that CNAME+DNAME proposal breaks 
anything, please provide a test case.  I would be first to say we should 
drop CNAME+DNAME if there is a serious breakage somewhere, but we should 
not reject the proposal based on Fear, Uncertainty, Doubt (tm).

Also anybody is free to use experimental dname.cz zone, I am willing to 
add any combination of records to the zone, so you can test whatever 
protocol and test case you want.  I could add simplified/mandarIDN f.e. 
if you want.

BTW let me show you something, try pasting these into your browser:

www.cnnic.测试.dname.cz
www.cnnic.測試.dname.cz

in punycode:
www.cnnic.xn--0zwm56d.dname.cz
www.cnnic.xn--g6w251d.dname.cz

And check your mail log for rejected mail sent to:

[email-masked]
and
[email-masked]

I put those two email addresses to Bcc:, so we don't keep them in next 
conversation.

Ondrej

Ondrej

---

From: "Yao Jiankang" <[email-masked]>
Date: Fri, 23 Apr 2010 20:43:02 +0800

----- Original Message ----- 
From: "Ondřej Surý" <[email-masked]>
To: "YAO Jiankang" <[email-masked]>
Cc: "Mark Andrews" <[email-masked]>; <[email-masked]>
Sent: Friday, April 23, 2010 5:37 PM
Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00

> resolver), MX, SRV, etc.  I am not aware of any protocol directly asking 

but many prtotocols will deal with the CNAME issues. 

for example RFC 2821 5321
> coexistence with DNAME.  

whether you use "breaking" or "enhancing", the fact is that you will change some rules set for CNAME.

>CNAME and DNAME don't share same alias space. 
> authoritative and/or recursive DNS server. 

here, you'd better say "you are enhancing..." instead of  saying "break some authoritative ......"
:)

Jiankang Yao

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 23 Apr 2010 18:41:15 +0200

On 23.4.2010 14:43, Yao Jiankang wrote:
> To: "YAO Jiankang"<[email-masked]>
> Cc: "Mark Andrews"<[email-masked]>;<[email-masked]>
> but many protocols will deal with the CNAME issues.
>

I think that this part of SMTP standard is wrong.  Users (applications 
or end users) of DNS should not resolve CNAMEs on their own.  It should 
be handled either by full resolver or stub resolver in standard system 
library.

Anyway the only breakage which could happen (AFAIK) is when:

a) MTA implements a query cache
b) the query cache is very strict on CNAMEs
c) mail is sent to target.dname.cz and CNAME for target.dname.cz is 
stored in the cache
d) mail is sent to www.target.dname.cz and the query cache tries to 
store everything received (including the DNAME) into the query cache.

=> error is reported when storing the DNAME record into the query cache

But I dare to say that such implementation of dns client is broken.

In normal circumstances all cases will be handled by DNAME compatibility 
layer (ie. returning autogenerated CNAMEs), so I still don't see where 
the breakage can be.

Again I checked my MTA source code - postfix - there is not query cache 
in the code, there is no handling of DNAMEs, so I don't see how any 
breakage could occur by allowing CNAME+DNAME to live together.

> whether you use "breaking" or "enhancing",
> the fact is that you will change some rules set for CNAME.

I do, and I could change "enhancing" to "changing/modifying", but I am 
convinced that this change will have no bad impact on general internet, 
and I am not breaking CNAME in any way.

Ondrej

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Apr 2010 13:07:28 -0400

On Fri, Apr 23, 2010 at 06:41:15PM +0200, Ondřej Surý wrote:
> or end users) of DNS should not resolve CNAMEs on their own.  

Woah, nelly.  Let's not put ourselves in the position of telling other
applications what they should or should not be doing with data in the
DNS, if for no other reason than that it runs exactly opposite to
years of other advice.

> But I dare to say that such implementation of dns client is broken.

Why is it broken?  The CNAME rules say nothing else should be at the
CNAME.  Your proposal violates that rule.  You can't then say that
someone checking that the CNAME doesn't have anything else at that
name is actually broken: it isn't, at least today.

I'm not saying we shouldn't make this change to CNAME and DNAME, but
let us not dismiss the objection that we're making a change by begging
the question.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 23 Apr 2010 21:19:49 +0200

On 23.4.2010 19:07, Andrew Sullivan wrote:
>> I think that this part of SMTP standard is wrong.  Users
>> (applications or end users) of DNS should not resolve CNAMEs on
>> their own.
>
> Woah, nelly.  Let's not put ourselves in the position of telling
> other applications what they should or should not be doing with data
> in the DNS, if for no other reason than that it runs exactly opposite
> to years of other advice.

Ok, point taken.  Take that as just my opinion how should that generally
work.  And I am not trying to push that into CNAME+DNAME.

>> a) MTA implements a query cache b) the query cache is very strict
>> on CNAMEs c) mail is sent to target.dname.cz and CNAME for
>> target.dname.cz is stored in the cache d) mail is sent to
>> www.target.dname.cz and the query cache tries to store everything
>> received (including the DNAME) into the query cache.
>>
> Why is it broken?

Because it breaks Postel's principle, and because it does too much for a
DNS-user application.  So maybe not 'broken' per se, but too fragile.

> The CNAME rules say nothing else should be at the CNAME.  Your
> proposal violates that rule.

What about RRSIG/NSEC(3)?  We have already broken that rule.

> You can't then say that someone checking that the CNAME doesn't have
> anything else at that name is actually broken: it isn't, at least
> today.

Well, maybe we just differ in view, what "broken" mean.  For me "broken" 
means more "suboptimal", for you it is more "incorrect".

So I will avoid using word "broken" in this context again.

> let us not dismiss the objection that we're making a change by
> begging the question.

Maybe I was too zealous.  If we take the approach "SMTP is CNAME aware, 
be careful here" and not "SMTP is CNAME aware, let's not touch CNAME", 
then I am perfectly OK with the way to go.

Ondrej

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Apr 2010 15:52:53 -0400

> What about RRSIG/NSEC(3)?  We have already broken that rule.

But we have something else that tells you whether you get the
RRSIG/NSEC(3), and that's the DO bit.  If you don't set the DO bit,
then you don't get those additional RRs, and if you are checking and
insisting on nothing else being at the owner name of that CNAME, you
won't blow up.

> then I am perfectly OK with the way to go.

I think what we have to do is present this and the BNAME alternatives
to the rest of the IETF community, with an indication of our
preferences.  I am really not trying to discourage work here.  I just
want to make sure we don't oversell anything.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 23 Apr 2010 17:13:15 -0700

On Fri, Apr 23, 2010 at 12:52 PM, Andrew Sullivan <[email-masked]> wrote:
> RRSIG/NSEC(3), and that's the DO bit.

Not entirely true.  DNSSEC caches still include RRSIG/NSEC in response
to ANY queries that omit the DO bit even if the answer includes a
CNAME record.

---

From: Doug Barton <[email-masked]>
Date: Sat, 24 Apr 2010 18:41:01 -0700

On 04/24/10 17:48, George Barwood wrote:
> 
> ----- Original Message ----- From: "Andrew Sullivan"
> <[email-masked]> To: <[email-masked]> Sent: Friday,
> April 23, 2010 8:52 PM Subject: Re: [dnsext] Fwd: New Version
> Notification fordraft-sury-dnsext-cname-dname-00
> 
> I don't seem to have received the original message, so I'm not quite
> sure who said this.
> 
> But this is a "should" not a "must",

It's a pre-2119 "should," so you can't read !must there without
examining the context.

> so in fact the standard
> explicitly allows for other records to be present at a CNAME.
> 
> The actual passage is this: ( RFC 1034, section 3.6.2 )
> 
> << If a CNAME RR is present at a node, no other data should be 
> present; this ensures that the data for a canonical name and its
> aliases cannot be different.  This rule also insures that a cached
> CNAME can be used without checking with an authoritative server for
> other RR types. >>

IMO the context (including, but not limited to the 2nd half of the
sentence) clearly indicates that it really means "must" here.

Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

---

From: Mark Andrews <[email-masked]>
Date: Sun, 25 Apr 2010 14:05:44 +1000

In message <C56A196657C644EAA3D49A8036B1AF48@local>, "George Barwood" writes:
> From: "Doug Barton" <[email-masked]>
> To: "George Barwood" <[email-masked]>
> Cc: "Andrew Sullivan" <[email-masked]>; <[email-masked]>
> Sent: Sunday, April 25, 2010 2:41 AM
> Subject: Re: [dnsext] Fwd: New Version Notification fordraft-sury-dnsext-cname-dname-00
> 
> 
> Well 2199 says http://tools.ietf.org/html/rfc1122#page-12
> 
>        "Adaptability to change must be designed into all levels of
>          Internet host software.  As a simple example, consider a
>          protocol specification that contains an enumeration of values
>          for a particular header field -- e.g., a type field, a port
>          number, or an error code; this enumeration must be assumed to
>          be incomplete.  Thus, if a protocol specification defines four
>          possible error codes, the software must not break when a fifth
>          code shows up.  An undefined code might be logged (see below),
>          but it must not cause a failure."
> 
> This is a typical example of an undefined condition, and DNSSEC post-dates 2199 by
> a long time, so surely 2199 applies?
> 
> The principle is that receivers MUST NOT fail when they encounter an undefined
> code or condition ( they can log it ). I accept that implementors often get this wrong, but
> the principle seems clear ( and plain common sense ).
> 
> - George

George when you change how existing records work (this proposal
changes both CNAME and DNAME) you run the risk of breaking things.
If this change goes through then when one makes a DNAME query and
the is a CNAME at the QNAME you no longer know whether to follow
the CNAME or not to answer the query.  Do you follow old rules or
new rules?  Which did the client expect?

With BNAME, especially with the changes I've been suggesting from the
begining, you don't have that problem.  A cache sees a CNAME or it
sees a BNAME, it never sees both.  Asking a non-BNAME aware cache for
a BNAME gets a CNAME.  Asking a BNAME aware cache for a BNAME from a
non-BNAME aware client gets a CNAME.  Only when you ask for a BNAME
from BNAME aware client to a BNAME aware server do you get a BNAME.

Mark

---

From: Alex Bligh <[email-masked]>
Date: Sun, 25 Apr 2010 09:04:25 +0100

--On 25 April 2010 06:56:26 +0100 George Barwood 
<[email-masked]> wrote:

> Like NSEC and RRSIG queries, there is never a reason for a client to
> make an explicit query for a DNAME. It is quite ok for the result of such
> a  query to be undefined

That will make debugging interesting.

-- 
Alex Bligh