Subject: Re: [dnsext] draft-andrews-dnsext-multi-match-label-00

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Aug 2010 13:59:34 +1000

In message <[email-masked]>, Joe Abley writes
:
> Mark,
> 
> On 2010-07-30, at 11:44, Mark Andrews wrote:
> 
> > FYI
> 
> Am I reading this correctly: your idea requires clients to support EDNS1?
> 
> 
> Joe

It requires signaling between the client and server.  Bumping the EDNS
version is a reasonable way to do that.

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Aug 2010 14:05:42 +1000

In message <B31CA0A7810440BDAD74BDF26162A4E0@local>, "George Barwood" writes:
> I have quickly read the draft ( http://tools.ietf.org/id/draft-andrews-dnsext-multi-match-label-00.txt ).
> 
> It's certainly an ingenious and interesting idea, and may have some
> advantages, such as minimising the total number of zones and signatures.
> 
> However I dislike the redundancy and potential inconsistencies that can
> occur.
> 
> With multi-match labels (if I have understood correctly), every child zone
> would have to be updated in order that  cn and xn--fiqs8s ( or whatever )
> are equivalent everywhere, which seems bad to me.

The child servers would support this or would manually replicate the zones.
 
> With the BNAME or CNAME+DNAME approach, once the desired redirection has
> been specified, names below are guarunteed to "work", and no further action
> is required.

BNAME or CNAME+DNAME also turn one "zone" into a zone of cnames which
has its own set of issues.

> So I'm not convinced this is a good idea.
> 
> George

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 04 Aug 2010 12:07:18 -0400

This draft ignores the main lesson from bit labels fiasco:
No new label type is useful until the whole installed base is updated to 
support it.
EDNSx version change does not work as EDNS is only hop by hop and
the problems are going to show up in the middle rather than at the edges.
This is the main reason why edns0-bis is closing the label type registry.

	Olafur

On 02/08/2010 11:59 PM, Mark Andrews wrote:
> In message<[email-masked]>, Joe Abley writes
> :
>> Mark,
>>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Aug 2010 17:55:54 +1000

> No new label type is useful until the whole installed base is updated to 

No.  These labels are NOT used in questions (IXFR/AXFR excluded).
They are only in replies and only when the client signals that they
understand them otherwise you get RFC 1035 labels.

> This is the main reason why edns0-bis is closing the label type registry.

Hop by hop signalling is fine for this.  If a cache understands it will get
MML's in the reply.  It can still generate RFC 1035 labels for the non MML
aware clients.

If the cache doesn't understand MML's then it will get RFC 1035 labels and
a MML aware validator won't be able to validate through it.  This is similar
to NSEC3 where the cache needs to be NSEC3 aware to validate through it.

Mark