Subject: [dnsext] draft-yao-dnsext-bname-03.txt

From: [email-masked]
Date: Wed, 07 Jul 2010 20:24:21 +0900 (JST)

My comments for draft-yao-dnsext-bname-03.txt:

1. The draft does not explain CNAME+BNAME problem.

The same comments are already discussed in this list.

RFC 2181 section 10.1 "CNAME resource records" states
"+ one or more records exist, none being CNAME records,".
But section 4.1 step 3.a generates answers which contain CNAME RR and
BNAME RR for the same owner name.

I think you should write some text which updates/violates RFC 2181 and 1034.
Or introduce some singaling mechanisim described by Paul Vixie.

 <[email-masked]>
 http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg01321.html

# But if we introduce DNAME_OK bit, DNAME+CNAME approach is implementable.

2. examples needed.

 Please see draft-ietf-dnsext-rfc2672bis-dname-19 section 2.2.

 I want to see zone file example in appendix section.

3. about DNSSEC+BNAME

   I considered DNSSEC+BNAME without new DNSSEC algorithm numbers.
   It's just an idea.

(a) BNAME + online signing approach solves BNAME DNSSEC problem.

    Synthesized CNAME's RRSIG is easy to generate.
    Synthesized owner name value region is clear,
    NSEC or NSEC3 RRs can be calculated.

    BNAME RR is used by some TLDs and they will use their own DNS
    servers, the performance problem is solved by new software and new
    hardware (and it does not affect root servers).

(b) Static zone file case without NEW DNSSEC algorithm.

    Assue the BNAME zone does not contain another RRs (BNAME only).
    Assume BNAME_OK flag in query (like DNSSEC_OK bit).
    Assume NSEC3 + Optout.

    Prepare two zones and they share same DNSKEY.
      one is BNAME OK zone. (BNAME_ZONE)
      the other is ZONE APEX + NSEC3 outout zone. (Synthesized_ZONE)

    If the server receives queries with BNAME_OK,
    the server answers from BNAME_ZONE.

    If the server receives queries without BNAME_OK,
    the server answers synthesized CNAME
    with DNSSEC RRs from Synthesized_ZONE.
    Without BNAME_OK bit, the synthesized CNAME cannot be verified.

    The problem is that this method cannot be used with NSEC zone.

4. Why do you consider RSASHA256/RSASHA512 instead of RSASHA1 ?

Regards,

--
Kazunori Fujiwara, JPRS <[email-masked]>

---

From: "Jiankang YAO" <[email-masked]>
Date: Thu, 8 Jul 2010 10:09:10 +0800

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 07, 2010 7:24 PM
Subject: [dnsext] draft-yao-dnsext-bname-03.txt

> BNAME RR for the same owner name.

My understanding of RFC 2181 section 10.1 is that you can not configure other recourds except dnssec RRs in the zone if there is a cname.

but the CNAME RR related to BNAME RR is synthetized. there is not a real CNAME RR in the zone.

I think that RFC 2181 section 10.1 does not prohibit that we can provide a cname in the answer section.

> I want to see zone file example in appendix section.

ok, will consider to add it.

> 4. Why do you consider RSASHA256/RSASHA512 instead of RSASHA1 ?

 RSASHA256/RSASHA512  is also a possible option.

I think that  RSASHA1is more popular than RSASHA256/RSASHA512 in dnssec.

currently, we give RSASHA1 the bname alias name. in future, if all servers and resolvers support bname, algorithimic alias name may not be necessary.
so you can choose any algorithim for bname.

rfc5702#section-8.1 suggests that we use sha2.

---

From: [email-masked]
Date: Tue, 20 Jul 2010 19:34:50 +0900 (JST)

> From: "Jiankang YAO" <[email-masked]>
> Date: Thu, 8 Jul 2010 10:09:10 +0800

> My understanding of RFC 2181 section 10.1 is that you can not configure other recourds except dnssec RRs in the zone if there is a cname.

RFC 2181 section 10.1 describes DNS protocol.
It says one or more records (includes DNAME or BNAME) exist at a owner name,
none being CNAME records at the same owner name in DNS packet.

If not, we need to classify RFC 2181 section 10.1.

> but the CNAME RR related to BNAME RR is synthetized. there is not a real CNAME RR in the zone.

BNAME-unaware Resolvers cannot distinct a real CNAME and a synthesized CNAME.
BNAME-unaware resolvers find a ownername has CNAME and BNAME (as unknown RR)
and they may treat it is a violation.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 20 Jul 2010 08:20:57 -0700

On 7/20/10 3:34 AM, [email-masked] wrote:
> > From: "Jiankang YAO" <[email-masked]> Date: Thu, 8 Jul 2010
> > 10:09:10 +0800
> >> RFC 2181 section 10.1 "CNAME resource records" states "+ one or
> >> more records exist, none being CNAME records,". But section 4.1
> >> step 3.a generates answers which contain CNAME RR and BNAME RR
> >> for the same owner name.
> >
> > My understanding of RFC 2181 section 10.1 is that you can not
> > configure other records except dnssec RRs in the zone if there is
> > a cname.
>
>  RFC 2181 section 10.1 describes DNS protocol. It says one or more
>  records (includes DNAME or BNAME) exist at a owner name, none being
>  CNAME records at the same owner name in DNS packet.
>
>  BNAME-unaware Resolvers cannot distinct a real CNAME and a
>  synthesized CNAME. BNAME-unaware resolvers find a ownername has CNAME
>  and BNAME (as unknown RR) and they may treat it is a violation.

This was said at the last meetings as well.  Judging by John's strong 
assertions, don't expect targets found in a resource record, such as an 
MX, PTR, SRV record are always accepted when below a BNAME.  It remains 
problematic from the standpoint of a recipient refusing an aliased 
target in a MX record.  There is new draft defining methods for using 
TLS to authenticate clients, that restates not allowing  CNAMEs.  It 
seems important to know who is communicating for both directions, 
without chasing a rabbit down its hole.

As said on this list from the outset, there must be warnings that names 
below BNAMEs have limitations.  These limitations are likely to remain 
going forward.  Be upfront about these target related limitations.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Tue, 20 Jul 2010 08:20:57 -0700

-Doug

---

From: [email-masked]
Date: Tue, 20 Jul 2010 19:34:50 +0900 (JST)

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 21 Jul 2010 10:01:23 +0800

----- Original Message ----- 
From: "Douglas Otis" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 20, 2010 11:20 PM
Subject: Re: [dnsext] draft-yao-dnsext-bname-03.txt

> target in a MX record.  

this is the software configuration problem.
if the  recipient configure a MX alias in the DNS, it is strange that he does not configure the software to accep it.

>There is new draft defining methods for using

---

From: [email-masked]
Date: Wed, 21 Jul 2010 12:55:48 +0900 (JST)

> From: Douglas Otis <[email-masked]>
> assertions, don't expect targets found in a resource record, such as
> an MX, PTR, SRV record are always accepted when below a BNAME.  It
> remains problematic from the standpoint of a recipient refusing an
> aliased target in a MX record.  There is new draft defining methods
> for using TLS to authenticate clients, that restates not allowing
> CNAMEs.  It seems important to know who is communicating for both
> directions, without chasing a rabbit down its hole.

There are two problems.

First is that a owner name has CNAME RR + DNAME or BNAME RR in a response.
It is described in RFC 2181 Section 10.1 "CNAME resource record".

Second is the domainname of MX, NS RDATA value.

But DNAME/BNAME case, redirect domain name's NS or MX RR can be
configured not to contain DNAME/BNANE ownername.

> if the  recipient configure a MX alias in the DNS, it is strange that he does not configure the software to accep it.

I agree. The second problem is a configuration error.
But first problem is not resolved.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 Jul 2010 15:43:08 +1000

> It is described in RFC 2181 Section 10.1 "CNAME resource record".

Which becomes a non-issue if you signal BNAME awareness and send a CNAME
or a BNAME but never both.

> > if the  recipient configure a MX alias in the DNS, it is strange that he do
> es not configure the software to accep it.
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Florian Weimer <[email-masked]>
Date: Wed, 21 Jul 2010 13:47:52 +0000

* Jiankang YAO:

> this is the software configuration problem.  if the recipient
> configure a MX alias in the DNS, it is strange that he does not
> configure the software to accep it.

Other MTAs reject mail because the MX name is not canonical.
Such checks are applied to both sender and recipient addresses.
It is not a local configuration issue.  Existing RFCs arguably
make it acceptable to reject mail for these reasons (because
using non-canonical names is a protocol violation, and that
restriction probably made sense at some point).

-- 
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: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 21 Jul 2010 10:47:17 -0400

Its even worse than that.

Mail systems will reject mail according to criteria that are opaque
and inconsistent. Spam has made what was once an open protocol into a
black art. One of the main reasons I use gmail is that I know that
they have a very high probability of being able to deliver the
message.

Mail servers are a very bad choice of application to make
generalizations from as a result. cnames have the use restrictions
they do because they make sense for cnames. That does not mean that we
have to apply the same restrictions for bnames just for symmetry.

The real question here is whether it is possible to somehow extend the
DNS protocol and infrastructure to reduce the amount of data that must
be queried and cached when we have two names for what is essentially
the same DNS sub tree.

The protocol is a no-brainer, done. The devil is in the infrastructure.

The approach proposed looks pretty sensible to me. bname is not going
to be a facility that most DNS infrastructure understands for quite
some time. So there is going to have to be some form of 'fixup'. There
are going to be bname aware clients/caches and bname-unaware
clients/caches. And that might be a simple expansion or might have to
be a little more elaborate to take care of corner-cases which email
might turn out to be.

There is inevitably going to be a series of corner cases thrown up by
DNSSEC if the client attempts to perform end-to-end verification and
the cache is bname aware but not the client. What that says to me is
that we better hurry up and do this fast or else there is going to be
infrastructure built up that has to be worked round.

But one consequence of bname that I think has to be taken on board is
that it is not going to be possible to edit the zone files by hand.
This is of course already the case for people using DNSSEC. But if
bname is going to be used on any scale where it is going to make
sense, the shadow domain tree to support legacy clients is going to
have to be generated automatically.

-- 
Website: http://hallambaker.com/

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 Jul 2010 12:53:45 +1000

> restriction probably made sense at some point).

The restictions are against aliases (cnames are just one form of
aliasing) and are there to allow MX processing to work without
having to lookup the addresses records of every mail exchanger in
the MX RRset to work out whether you should attempt to forward the
email, store it or generate a error message when delivery is not
to be performed.  The restriction is there because SMTP is a store
and forward protocol.

SRV inherited the restriction but it is really only needed for those
protocols that are store and forward or which the name of the server
is to be used to authenticate the connection.  SMTP clients are
also supposed to use the mail exchanger name to authenticate the
connection by checking the name given by the server but most don't
leading to successful mitm attacks.

Mark

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 28 Jul 2010 19:14:12 +0800

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 21, 2010 1:43 PM
Subject: Re: [dnsext] draft-yao-dnsext-bname-03.txt 

.....
> or a BNAME but never both.

dname also issues a synthesised cname with dname together.

so bname, dname and c+d all might require some signaling.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 Jul 2010 21:33:45 +1000

You will normally have

foo DNAME bla
xxx.foo CNAME xxx.bla

You don't have a CNAME and a DNAME with the same ownername in the
response.  The obvious exception would be with a DNAME to point
immediately above itself with CNAME + DNAME.

foo.example DNAME example
xxx.foo.example CNAME xxx.example
xxx.example CNAME <cname_target>

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 28 Jul 2010 15:49:21 +0200

On 28.7.2010 13:14, Jiankang YAO wrote:
> From: "Mark Andrews"<[email-masked]>
> To:<[email-masked]>
> Cc:<[email-masked]>;<[email-masked]>;<[email-masked]>

As already mentioned today.  C+DNAME doesn't need any additional 
signaling - DNAME signaling is enough.  E.g. any resolver supporting 
DNAME will support C+DNAME out of the box.

BNAME does need additional signaling, thus it needs modifications on 
both the resolver and the authoritative side.

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Jul 2010 00:08:31 +1000

> both the resolver and the authoritative side.

The resolver doesn't NEED modification.  It just won't be as efficient
or be able to validate without signaling.   Note the current draft is
still missing many of the agreeded on changes.

Mark

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 28 Jul 2010 22:31:31 +0800

----- Original Message ----- 
From: "Ondřej Surý" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>
Cc: <[email-masked]>; "Mark Andrews" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 28, 2010 9:49 PM
Subject: Re: [dnsext] signaling of bname, dname or c+dname

> DNAME will support C+DNAME out of the box.

actually, dname need signalling, but current dname has no such signalling mechanism.

the serious problem for C+DNAME is that eithor dname or cname will get unresolvable if both are put together in the no-changed dns servers.

you told the users that c+dname can be togther, in fact, if they appear to be together, there will have a dns resloution problem.

the case of cname together with DNSSEC RRSIG is different with the case of cname with dname.
you set a rule which said that cname can not be with rrsig together, if they happen to be together, it will be no problem, you just broke a rule.

you set a rule which said that cname can not be with dname together, if they happen to be together, it will have a problem, you  not only broke a rule,
but also get a punishment (causing cname or dname to be unresolvable).

> both the resolver and the authoritative side.

the situation of dname and bname is same when it first comes to serve the users.

if dname does not need to update the resolver, why bname need it?
if bname need it, the dname need it too.

the mechanism of the domain name children for both dname and bname is almost same.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 28 Jul 2010 16:41:05 +0200

On 28.7.2010 16:31, Jiankang YAO wrote:
>
> ----- Original Message ----- From: "Ondřej Surý"<[email-masked]>
> To: "Jiankang YAO"<[email-masked]> Cc:<[email-masked]>; "Mark
> Andrews"<[email-masked]>;<[email-masked]>;<[email-masked]>
>
>
>>> ----- Original Message ----- From: "Mark Andrews"<[email-masked]>
>>> To:<[email-masked]>
>>>>> First is that a owner name has CNAME RR + DNAME or BNAME RR
>>>>> in a response. It is described in RFC 2181 Section 10.1
>>>>> "CNAME resource record".
>>>>
>>>> Which becomes a non-issue if you signal BNAME awareness and
>>>> send a CNAME or a BNAME but never both.
>>>>
>>>
>> signaling - DNAME signaling is enough.  E.g. any resolver
>> supporting DNAME will support C+DNAME out of the box.
>
> the serious problem for C+DNAME is that eithor dname or cname will
> get unresolvable if both are put together in the no-changed dns
> servers.

The owner of the zone must ensure that he uses compliant authoritative 
servers.  I don't believe this poses any serious problem.

And it has been already tested that it's not a problem on a resolver 
side (Bind 9.6.x, 9.7.x, Unbound 1.4.x, PowerDNS, OpenDNS, Google DNS 
all work just fine).

If you have a test case which proves otherwise please present a real 
test case.

> you told the users that c+dname can be togther, in fact, if they
> appear to be together, there will have a dns resloution problem.

What problem are you talking about?  Examples and real cases please. 
Speaking about hypothetical problems will get us nowhere.

> the case of cname together with DNSSEC RRSIG is different with the
> case of cname with dname. you set a rule which said that cname can
> not be with rrsig together, if they happen to be together, it will be
> no problem, you just broke a rule.

I am sorry, but I don't understand what you are trying to say.  Could 
you please elaborate more?

> you set a rule which said that cname can not be with dname together,
> if they happen to be together, it will have a problem, you  not only
> broke a rule, but also get a punishment (causing cname or dname to be
> unresolvable).

I believe this is not the case.  If you can prove otherwise, please 
present a real test case when it breaks.

>> BNAME does need additional signaling, thus it needs modifications
>> on both the resolver and the authoritative side.
>>
>
>
> if dname does not need to update the resolver, why bname need it? if
> bname need it, the dname need it too.

Because DNAME is already supported in DNSSEC-aware resolvers.

Ondrej

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 28 Jul 2010 16:43:46 +0200

On 28.7.2010 16:08, Mark Andrews wrote:
> In message<[email-masked]>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= writes:

Ok. What I meant was that resolver needs signaling for full support of 
BNAME.  You are right that for "normal" operations the resolver doesn't 
need signaling.  But we may argue that "normal" could start to mean 
"including the validation", now when the root is signed.

But yeah, my bad for the inaccurate wording on my side in the first place.

Ondrej

---

From: [email-masked]
Date: Wed, 28 Jul 2010 23:50:03 +0900 (JST)

> From: Ondřej Surý <[email-masked]>

DNAME does not have signaling.

DNAME itself does not need signaling because it does not generate
CNAME whose owner name is same as DNAME's owner name.

draft-ietf-dnsext-rfc2672bis-dname-15 has "Understand-DNAME" bit,
but current draft does not define "Understand-DNAME" bit.
RFC 2672 does not define DNAME signaling.

DNAME+CNAME breaks RFC 1034/2181. It needs new signaling.
If new resolver support DNAME+CNAME, authoritative server can respond
DNAME+CNAME at one owner name.
Otherwise, authoritative server must respond CNAME only.

> both the resolver and the authoritative side.

Same as DNAME+CNAME.

BNAME+CNAME breaks RFC 1034/2181. It needs new signaling.
If new resolver support BNAME, authoritative server can respond BNAME.
Otherwise, authoritative server must respond CNAME only.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 28 Jul 2010 17:15:21 +0200

On 28.7.2010 16:50, [email-masked] wrote:
>> From: Ondřej Surý<[email-masked]>

The draft says that "Validators Must Understand DNAME".

> DNAME+CNAME breaks RFC 1034/2181. It needs new signaling.

The question is if it breaks just the standard, or if it breaks anything 
real.  I think this is important distinction.

> DNAME+CNAME at one owner name.

What would be the query which gets answered by DNAME+CNAME?

If the query is:

1) '<owner> IN A' will be answered by CNAME

2) 'something.<owner> IN A' will be answered by DNAME (and synthetized 
CNAME)

> Otherwise, authoritative server must respond CNAME only.

That's not true according to RFC2672 and according to RFC2672bis:

The 3.1 section of the draft says:

    When preparing a response, a server performing a DNAME substitution
    will in all cases include the relevant DNAME RR in the answer
    section.

Ondrej

---

From: [email-masked]
Date: Thu, 29 Jul 2010 00:37:48 +0900 (JST)

> The question is if it breaks just the standard, or if it breaks
> anything real.  I think this is important distinction.

It breaks the standard.
It may break some implementations.

There may exist implementations which reject or cause failure if they
receive a ownername has both CNAME and DNAME (or CNAME and BNAME).

You cannot prove all implementation can handle DNAME+CNAME in one ownername.

There may be some private implementations. We cannot know them.

> 1) '<owner> IN A' will be answered by CNAME

Assume DNAME+CNAME signaling is implemented.
Assume the query is for a domain name <owner> which has DNAME RR + CNAME RR.

If a new resolver support DNAME+CNAME, authoritative server responds
'<owner> IN DNAME + <owner> IN CNAME' in one response.

If the resolver does not support DNAME+CNAME, authoritative server
cannot send '<owner> IN DNAME + <owner> IN CNAME' because it breaks rfc
1034/2181, then the server can send CNAME only '<owner> IN CNAME'.

> 2) 'something.<owner> IN A' will be answered by DNAME (and synthetized

Authoritative server responds
 '<owner> IN DNAME' + 'something.<owner> IN DNAME something.<dname>'.

>    will in all cases include the relevant DNAME RR in the answer

Sorry, I omitted words.

If the query is for "<owner>" and the resolver does not support
"DNAME+CNAME", authoritative server cannot respond '<owner> IN DNAME +
<owner> IN CNAME' because it breaks rfc 1034/2181, then the server can
send CNAME only '<owner> IN CNAME'.

If the query is for "something.<owner>", authoritative server responds
'<owner> IN DNAME' + 'something.<owner> IN DNAME something.<dname>'.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Jul 2010 16:23:46 +0000

> From: Mark Andrews <[email-masked]>
> Date: Thu, 29 Jul 2010 00:08:31 +1000
> 

not having been at the meeting, i will wait to see the new draft before i
comment on this new C+D proposal.

hopefully it will account for code paths like:

if (cname is present) {
   # assume nothing else
}

and:

if (cname not present) {
   # assume no cname
}

...which i know i've written in currently-deployed code and i suspect that
others have also done.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Jul 2010 16:52:10 +0000

> Date: Wed, 28 Jul 2010 23:50:03 +0900 (JST)
> From: [email-masked]
> ...
> ...

+1.

which is why i think BNAME is the better proposal, since it also needs new
signalling, but the signalling only controls the interpretation of a new RR
type, rather than also changing the interpretation of an existing RR type.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Jul 2010 16:56:42 +0000

> Date: Wed, 28 Jul 2010 17:15:21 +0200

+1, as before.

> real.  I think this is important distinction.

i don't.  code which assumes (presence(CNAME) != presence(~CNAME)) is not
broken, but it will be made to be broken if we change the meaning of CNAME
to allow DNAME to co-exist.  as protocol stewards we should not have to
prove that such code exists, unless there is no easy alternative and we
really just have to redefine the rules for existing bit patterns.

an easy alternative exists: BNAME.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 28 Jul 2010 10:14:24 -0700

> an easy alternative exists: BNAME.

Question:  What is the desired behavior for CNAME + DNAME?

It should be possible to build a test name to see if this behavior works or not with the actual code out there.

---

From: Tony Finch <[email-masked]>
Date: Wed, 28 Jul 2010 18:30:53 +0100

>    # assume nothing else

DNSSEC?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FAIR ISLE: NORTHWEST 3 OR 4, INCREASING 5 AT TIMES. SLIGHT OR MODERATE, BUT
ROUGH FOR A TIME IN WEST. RAIN OR SHOWERS, FOG PATCHES AT FIRST. MODERATE OR
GOOD, OCCASIONALLY VERY POOR AT FIRST.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Jul 2010 17:47:49 +0000

> Date: Wed, 28 Jul 2010 18:30:53 +0100
> From: Tony Finch <[email-masked]>
> 

nobody sees DNSSEC's data patterns unless they set the DO bit, so, this is
not a counter-example.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Jul 2010 07:38:45 +1000

> hopefully it will account for code paths like:

Which only becomes a issue if the qtype is DNAME.
 
>    # assume no cname

Which is only a problem for qtype CNAME and there is a cached DNAME.

> ...which i know i've written in currently-deployed code and i suspect that

In both cases you won't look for the other until you upgrade the code. DNAME
however will continue to work with a CNAME in the cache.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Jul 2010 23:29:42 +0000

> Date: Thu, 29 Jul 2010 07:38:45 +1000
> 

in each case, i was considering the assumptions that an implementation
can make when parsing a response that contains both, or when searching
through a cache that contains both.  how things get into that response
or how they get into the cache is outside the scope of "correctness".

> > ...which i know i've written in currently-deployed code and i suspect
> > that others have also done.
> 
> In both cases you won't look for the other until you upgrade the
> code. DNAME however will continue to work with a CNAME in the cache.

i'd like us to not change the meaning of a record (cname in this case)
without a signalling bit (so that only people who understand the new
meaning will ever see the new bit pattern.)  ergo, the BNAME proposal.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 29 Jul 2010 08:36:24 +0200

> It should be possible to build a test name to see if this behavior works or not with the actual code out there.

It's already there: dname.cz

For contents of the zone:
# dig IN AXFR dname.cz @{cool,ignum}.nic.cz

O.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 29 Jul 2010 08:52:11 +0200

> really just have to redefine the rules for existing bit patterns.

I think that we are missing important point in this discussion.  We are 
not going to break every existing CNAME out there.  Nor the C+DNAME will 
get a widespread adoption at every existing site.

And even if there is a code which happens to receive CNAME and DNAME 
together somehow, it will be broken only on those new sites.

And there are only two ways how that could happen:

- the app in question implements a strict cache
- you ask for IN ANY at owner node (which is already broken by DNSSEC)

> an easy alternative exists: BNAME.

I would doubt that this is the easy alternative.  From deployment 
perspective it's much harder to deploy this.

BTW according to the current I-D (draft-yao-dnsext-bname-03) it will 
break the applications in the exactly same way and even easier:

    When preparing a response, a server performing a BNAME substitution
    will in all cases include the relevant BNAME RR in the answer
    section.  A CNAME RR is synthesized and included in the answer
    section.

So BNAME definitely needs signaling to send either BNAME or syntethized 
CNAME, but never both.

<owner> IN <any_type>

Then you'll always get:

<owner> IN BNAME <target>
<owner> IN CNAME <target>

Ondrej

---

From: Paul Vixie <[email-masked]>
Date: Thu, 29 Jul 2010 19:32:50 +0000

> Date: Thu, 29 Jul 2010 08:52:11 +0200

no harder than dname, surely?

> ... BNAME definitely needs signaling to send either BNAME or syntethized
> CNAME, but never both.

agreed.