Subject: [dnsext] the method of avoiding signal in bname

From: "Jiankang YAO" <[email-masked]>
Date: Fri, 13 Aug 2010 01:12:08 +0800

Dear all,

I proposed the following method for bname to avoid the signaling:

if the query is not dnssec query:

   If the owner name of the bname is the suffix of the name queryed but
   different, 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.  This will help the client to reach the correct DNS data.

   If the owner name of the bname is same with the name queryed, when
   preparing a response, a server performing a BNAME substitution will
   not include the relevant BNAME RR in the answer section unless the
   type queryed is BNAME.  A CNAME RR will be synthesized and included
   in the answer section unless the type queryed is BNAME or the query
   is the DNSSEC query.

if the query is the dnssec query:

only the bname is returned to the resolvers from the servers.

this assumes that: if the resolvers does not recognize the bname but want dnssec, the synthesized
cname is not useful for them.
if the resolvers does  recognize the bname and want dnssec, the resolvers can do the 
next query without the synthesized
cname.

through the method above, there will never issue cname and bname together with the same owner name.

if  bname still needs the alias algorithm, it will follow the difiniton of draft-yao-dnsext-alias-algorithm-00.txt to avoid adding
too many alias algorithms for the new rrtypes.

any comments are welcome.

thanks a lot.

Jiankang Yao

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 13 Aug 2010 11:05:45 +0200

> if bname still needs the alias algorithm, it will follow the difiniton
> of draft-yao-dnsext-alias-algorithm-00.txt to avoid adding

You cannot avoid the signaling for the BNAME.  You still need the 
signaling for the BNAME support in the DNSSEC-validating resolver.

You need to treat the non-BNAME aware DNSSEC validating resolver as your 
case number #1.  And then you have a unsolvable problem with chained 
resolvers.  Because downstream BNAME-aware resolver will not be able to 
see BNAME record after the upstream resolver has a synthesized CNAME in 
the cache.  I think this won't fly [RFC1925].

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: Paul Vixie <[email-masked]>
Date: Fri, 13 Aug 2010 15:30:48 +0000

> Date: Fri, 13 Aug 2010 11:05:45 +0200
> From: Ondřej Surý <[email-masked]>
> 

i agree with this.  BNAME-awareness would have to be signalled or else the
initiator would only see synthesized CNAME.  in this we'd be "like DNAME".

> the cache.  I think this won't fly [RFC1925].

i don't know that it won't fly, but it's a deeper problem than DNAME had
and may help us all understand why DNAME only affects its children not its
owner.  in any case, what you're saying would apply equally to C+D, for
reasons i've stated about correct current assumptions in the installed base.

---

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

On 13.8.2010 17:00, Mark Andrews wrote:
> In message<[email-masked]>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= writes:
> NSEC3 doesn't work through chained nameservers that don't support NSEC3
> but we still deployed NSEC3.
>
> DNSSEC doesn't work through chained nameserves that don't support DNSSEC
> but we still deployed DNSSEC.
>
> Now you are saying that we can't deploy BNAME because it won't work through
> chained nameservers that don't support BNAME.  Sorry that just doesn't pass
> the laugh test as a reason to block it.  Way too many counter examples here.

Mark, please read the original Yao's proposal to know what "this" means 
before you turn your mean-mode on next time.  I am not arguing against 
BNAME in general, I am merely saying that "the method of avoiding signal 
in bname" as proposed in this email is flawed and you probably want to 
send BNAME along with synthesized CNAME.

Ondrej

---

From: "Jiankang YAO" <[email-masked]>
Date: Sat, 14 Aug 2010 00:18:16 +0800

----- Original Message ----- 
From: "Ondřej Surý" <[email-masked]>
To: "Mark Andrews" <[email-masked]>
Cc: "Jiankang YAO" <[email-masked]>; <[email-masked]>
Sent: Friday, August 13, 2010 11:58 PM
Subject: Re: [dnsext] the method of avoiding signal in bname

> send BNAME along with synthesized CNAME.

We appreciate the Constructive Proposal or suggestion or comments to improve the bname.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 13 Aug 2010 18:16:40 +0200

On 13.8.2010 17:30, Paul Vixie wrote:
>> You need to treat the non-BNAME aware DNSSEC validating resolver as
>> your case number #1.  And then you have a unsolvable problem with
>> chained resolvers.  Because downstream BNAME-aware resolver will
>> not be able to see BNAME record after the upstream resolver has a
>> synthesized CNAME in the cache.  I think this won't fly [RFC1925].
>
> i don't know that it won't fly, but it's a deeper problem than DNAME
> had and may help us all understand why DNAME only affects its
> children not its owner.

I agree it's a deeper problem.

> in any case, what you're saying would apply equally to C+D, for

Yes.  And I think you cannot avoid a situation where you will see a
CNAME and xNAME together in the same cache (or answer section).

Maybe (and really maybe as I haven't put much thought into it) this
could be somehow combined with RD=1 bit.

Ie. RD=1 DO=0 will see only synthesized CNAMEs.  Applies both to C+D and B.

So for:

-=-=-=-=- C+DNAME -=-=-=-=-

Q=<owner> IN A

RD=* DO=* <owner> CNAME

Q=www.<owner> IN A

RD=1 DO=0 www.<owner> sCNAME
RD=0 DO=0 www.<owner> sCNAME
RD=1 DO=1 www.<owner> sCNAME+<owner> DNAME
RD=0 DO=1 <owner> DNAME

(That would mean that the RD=0 DO=1 must do DNAME processing, so the 
other option is keep status quo and for DO=1 send sCNAME along with DNAME.)

-=-=-=-=- BNAME -=-=-=-=-

Q=<owner> IN A

RD=1 DO=0 BO=0 <owner> sCNAME
RD=* DO=* BO=0 <owner> sCNAME+BNAME
RD=0 DO=* BO=1 <owner> BNAME
RD=1 DO=* BO=1 <owner> sCNAME+BNAME

Q=www.<owner> IN A

RD=1 DO=0 BO=0 www.<owner> sCNAME
RD=* DO=* BO=0 www.<owner> sCNAME + <owner> BNAME
RD=0 DO=* BO=1 <owner> BNAME
RD=1 DO=* BO=1 www.<owner> CNAME + <owner> BNAME

(Again the RD=0 BO=1 needs resolver side processing...)

O.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 14 Aug 2010 17:02:10 +1000

> send BNAME along with synthesized CNAME.

And if the intermediate server doesn't understand BNAME it will be
dropped.  Today servers that don't understand DNAME just drop the
DNAME as it doesn't match the query.  BNAME will be similar.  It's
just a waste of bits sending BNAME if the client doesn't understand
it.

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

---

From: "YAO Jiankang" <[email-masked]>
Date: Mon, 16 Aug 2010 11:59:56 +0800

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 16, 2010 11:25 AM
Subject: Re: [dnsext] the method of avoiding signal in bname

> This assumption is totally without justification and doesn't match
> reality.  I have DNSSEC turned on today.  I don't *just* want answers
> that validate as secure.  What I want to do is to reject invalid
> answers to the best of my ability.  That means that I accept there
> will be cases where I can't validate a answer as secure, but will
> have to treat it as insecure, even though it is signed.
> 

your point is reasonable.

so it means that we have to do signal for bname in dnssec?

are there some methods of avoding the signal for bname in dnssec?

>
> If I need to have a particular zone treated as secure and it uses
> a algorithm that I don't currently support I will upgrade as needed.
>

---

From: Mark Andrews <[email-masked]>
Date: Mon, 16 Aug 2010 15:04:42 +1000

In message <[email-masked]> <030001cb3cf7$7d2a8b80$096ff1da@yaojk>, "
> your point is reasonable.

Thanks

> so it means that we have to do signal for bname in dnssec?

Yes as far as I can see.

> are there some methods of avoding the signal for bname in dnssec?

None that I've been able to work out.

Mark