Re: [DNSOP] Question on RRtypes in RFC 4034 Section 6.2

Mark Andrews <marka@isc.org> Wed, 09 December 2015 10:50 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6164C1A0406 for <dnsop@ietfa.amsl.com>; Wed, 9 Dec 2015 02:50:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.611
X-Spam-Level:
X-Spam-Status: No, score=-6.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bnb2lO6i9Wbf for <dnsop@ietfa.amsl.com>; Wed, 9 Dec 2015 02:50:54 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4631A03ED for <dnsop@ietf.org>; Wed, 9 Dec 2015 02:50:54 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 47B8F3493A5; Wed, 9 Dec 2015 10:50:52 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DA2E3160043; Wed, 9 Dec 2015 10:53:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C6502160074; Wed, 9 Dec 2015 10:53:19 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iCHJvIMjbZ6j; Wed, 9 Dec 2015 10:53:19 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 7CBB1160043; Wed, 9 Dec 2015 10:53:19 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 779EE3EFB3BE; Wed, 9 Dec 2015 21:50:49 +1100 (EST)
To: đź”’Roy Arends <roy@dnss.ec>
From: Mark Andrews <marka@isc.org>
References: <alpine.LFD.2.20.1512081004020.18633@bofh.nohats.ca> <20151208193856.GA5997@mycre.ws> <alpine.LFD.2.20.1512081440270.27931@bofh.nohats.ca> <20151208203736.3F62F3EF0E88@rock.dv.isc.org> <35C15C68-B6DB-4970-B816-9295C123E8AE@dnss.ec>
In-reply-to: Your message of "Wed, 09 Dec 2015 07:31:02 -0000." <35C15C68-B6DB-4970-B816-9295C123E8AE@dnss.ec>
Date: Wed, 09 Dec 2015 21:50:49 +1100
Message-Id: <20151209105049.779EE3EFB3BE@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/3FBhHiqPnmt7m616LaYCcZNhNoc>
Cc: dnsop <dnsop@ietf.org>, Paul Wouters <paul@nohats.ca>
Subject: Re: [DNSOP] Question on RRtypes in RFC 4034 Section 6.2
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Dec 2015 10:50:56 -0000

In message <35C15C68-B6DB-4970-B816-9295C123E8AE@dnss.ec>, =?utf-8?Q?=F0=9F=94=92Roy_Arends?= writes:
> We'd end up adding stuff to a response in order to make it shorter.

We'd end up changing a 0x00 to a 0x01 in the OPT record.

> Is there a clear benefit (shorter responses)? Can you show me a few real
> world examples?

Every DNSSEC answer would be potentially shorter.  The signer field
can be compressed as can the domain names in all these types.

hip ipseckey key lp nsec nxt rrsig sig talink nsap-ptr
dnskey cdnskey


> Thanks
>
> Roy
>
> > On 8 Dec 2015, at 20:37, Mark Andrews <marka@isc.org> wrote:
> >
> >
> > In message <alpine.LFD.2.20.1512081440270.27931@bofh.nohats.ca>, Paul
> Wouters wr
> > ites:
> >>
> >>> Subject: Re: [DNSOP] Question on RRtypes in RFC 4034 Section 6.2
> >>
> >> Thanks everyone for the useful comments. It's all clear to me now.
> >>
> >> Paul
> >
> > Additionally if we ever wanted to enable compression for new types
> > we could use EDNS to signal that the client understands a expand
> > set of types and one could use case sensitive compression to preserve
> > the original case of the name in the rdata which would allow DNSSEC
> > to work to work on the expanded names without having to update every
> > client in the world first.
> >
> > e.g.
> >    EDNS(1) could indicate the client understands the rdata
> >    for all the types allocated as of 12:00 Dec 8, 2016.
> >
> >    EDNS(2) could indicate the client understands the rdata
> >        for all the types allocated as of 12:00 Dec 8, 2020.
> >
> > We all should be doing case sensitive compression already as that
> > really is part and parcel of preserving the original case as required
> > by RFC 103[45].
> >
> > I'm actually tempted to say we should do this just to get rid of
> > the stupid firewalls that think that it is a good idea to drop EDNS
> > != EDNS(0) requests.
> >
> >> _______________________________________________
> >> DNSOP mailing list
> >> DNSOP@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dnsop
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> >
> > _______________________________________________
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org