Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-03.txt

Mark Andrews <marka@isc.org> Wed, 19 July 2017 03:17 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF28012783A for <dnsop@ietfa.amsl.com>; Tue, 18 Jul 2017 20:17:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 I1jIJcN0qv1j for <dnsop@ietfa.amsl.com>; Tue, 18 Jul 2017 20:17:00 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42407126D05 for <dnsop@ietf.org>; Tue, 18 Jul 2017 20:17:00 -0700 (PDT)
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)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 6EF0624AE08; Wed, 19 Jul 2017 03:15:35 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E0A6116004C; Wed, 19 Jul 2017 03:15:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CC6AC160054; Wed, 19 Jul 2017 03:15:39 +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 KiAlwVh8nNnm; Wed, 19 Jul 2017 03:15:39 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 2EA1F16004C; Wed, 19 Jul 2017 03:15:39 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 05E1B7EA7FA6; Wed, 19 Jul 2017 13:15:36 +1000 (AEST)
To: Petr Špaček <petr.spacek@nic.cz>
Cc: dnsop@ietf.org
From: Mark Andrews <marka@isc.org>
References: <149912520399.16222.12738253224617069728@ietfa.amsl.com> <89e8d29c-1692-732c-df3b-8b7915415629@nic.cz> <5C0034DB-657E-4191-86CC-05B06F11EEAF@fugue.com> <77d0bc67-d6c3-de37-e88b-6b3612cf3d3e@nic.cz>
In-reply-to: Your message of "Tue, 18 Jul 2017 15:02:47 +0200." <77d0bc67-d6c3-de37-e88b-6b3612cf3d3e@nic.cz>
Date: Wed, 19 Jul 2017 13:15:35 +1000
Message-Id: <20170719031536.05E1B7EA7FA6@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fEh7uurKWwM5P7Wuu_7eVO6kVOY>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-03.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 19 Jul 2017 03:17:02 -0000

In message <77d0bc67-d6c3-de37-e88b-6b3612cf3d3e@nic.cz>, =?UTF-8?B?UGV0ciDFoHBhxI1law==?= writes:
> On 11.7.2017 13:23, Ted Lemon wrote:
> > On Jul 11, 2017, at 3:17 AM, Petr paek <petr.spacek@nic.cz
> > <mailto:petr.spacek@nic.cz>> wrote:
> >> I feel that implications from switch to non-RR format are
> underestimated
> >> and following e-mail attempts to explain why I believe it is a bad
> idea.
> >> Please accept my apology for such long e-mail.
> >
> > Petr, with all due respect, I did not see a counter-proposal here, and
> > your comments seem to reflect a misunderstanding of what
> > session-signaling is.
> >
> > In fact, the opposite of what you said is true: if this were done as a
> > normal query with EDNS0-like encapsulation, _then_ we would see
> > problems, because session signaling messages would look more like DNS
> > queries, and less like control messages.  This is not a desirable
> quality.
> >
> > It's true that, for example, the DNS packet compression format would
> > have to deal with this specially, but that would also be true if this
> > were done EDNS0-style.   It's true that packet dumpers would have to
> > deal with this specially, but that's also true if it's done EDNS0-style.
> >   Etc.
>
> Let me clarify that I'm not insisting specifically on EDNS0. From my
> perspective anything which does not deviate from current wire format is
> okay.
>
>
> > It may be that there is a good point in your argument somewhere, but at
> > the moment, I don't see one.   E.g., in your python example, yes, if
> > this were an RR, not being able to plop it into your RR-handling switch
> > would suck.   But it's not an RR, doesn't have the semantics of an RR,
> > and if you plop it into your RR-handling switch, you're probably getting
> > the semantics wrong.
>
> This might be key to the the misunderstanding:
>
> I'm not talking about semantics at all. What I object to is the proposed
> wire format, not the semantics. The fact that bytes are stored in format
> compatible with RR (RFC 1035 section 4.1.3) is not related to its
> semantics.
>
> > So if you want to make this case, I think you need to be more specific
> > about why this is a problem: when I think about how to implement this
> > (which I have done, because I'm using it for dnssd), what you are
> > advocating seems harder, not easier, than what is currently being
> proposed.
> I'm trying to explain that deviance from RR format (RFC 1035 section
> 4.1.3) will force parties in the DNS ecosystem to implement support for
> the new wire format even though they are not interested in session
> signaling at all.

Hogwash.  Servers which are unaware of the opcode will return NOTIMP
or FORMERR depending on how forward thinking the developer was.

If you have a packet dumper YOU ALREADY HAVE TO ACCOUNT FOR THIS.
There are ZERO guarentees that a packet addresses to/from port 53
is a DNS packet.  If your packet dumper can't handle these then
it is already broken.

If you are just proxying DNS messages this should be transparent. If
the proxy is parsing the message then it returns NOTIMP or FORMERR.

> For a lot of cases it would be sufficient if SS data could be treated as
> one of many "unknown RR types" (RFC 3597). For example tools for
> statistics would work, the capture formats would not need special
> extensions for SS, etc.
>
> We can discuss this in depth during dnsop session today.
>
> --
> Petr paek  @  CZ.NIC
>
> _______________________________________________
> 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