Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

Ondřej Surý <ondrej@isc.org> Sun, 25 March 2018 05:57 UTC

Return-Path: <ondrej@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 A6F4E127136 for <dnsop@ietfa.amsl.com>; Sat, 24 Mar 2018 22:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 4pTKZJBRLxMQ for <dnsop@ietfa.amsl.com>; Sat, 24 Mar 2018 22:57:38 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7330126B6E for <dnsop@ietf.org>; Sat, 24 Mar 2018 22:57:38 -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.pao1.isc.org (Postfix) with ESMTPS id 2BE923AB03D for <dnsop@ietf.org>; Sun, 25 Mar 2018 05:57:37 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E75DF160052 for <dnsop@ietf.org>; Sun, 25 Mar 2018 05:57:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D2A37160070 for <dnsop@ietf.org>; Sun, 25 Mar 2018 05:57:35 +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 Q_ZXthANcQGm for <dnsop@ietf.org>; Sun, 25 Mar 2018 05:57:35 +0000 (UTC)
Received: from [10.10.0.181] (40.20.broadband5.iol.cz [88.100.20.40]) by zmx1.isc.org (Postfix) with ESMTPSA id 32B19160052 for <dnsop@ietf.org>; Sun, 25 Mar 2018 05:57:35 +0000 (UTC)
From: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= <ondrej@isc.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Sun, 25 Mar 2018 07:57:32 +0200
References: <152180695934.17546.2068402636242578841.idtracker@ietfa.amsl.com> <9CEA4F8F-4E71-4508-A088-103DD58F88E1@isc.org> <CA+nkc8DhXEEhiDqwHuA-_zNQc0n=rTZ-VZ6X8-0w-tY_0SC0eA@mail.gmail.com> <40ABB9EB-58EC-48FF-8117-60EE0E7006EF@isc.org> <CA+nkc8BfMKRUHuW+3EzOCeZHfmu1jeOgfVcszTbTYh9k2VTBcA@mail.gmail.com> <002DCABB-24CE-42FA-8DA6-2A458E5F89A1@isc.org> <5AB53F8B.9070504@redbarn.org> <7CF21F70-9419-4D6A-B555-FC229F90E8A9@isc.org> <5AB546CB.3030408@redbarn.org> <CCAE4014-67F8-4E73-A893-AA06B83E880B@isc.org> <20180324124958.GA29255@puck.nether.net>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <20180324124958.GA29255@puck.nether.net>
Message-Id: <806DE1A0-97E3-440A-AA8B-44314174D5C6@isc.org>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/C58WL_m0O47S4xDDRINsfiyPB4E>
Subject: Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.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: Sun, 25 Mar 2018 05:57:43 -0000

Hi,

I’ll conflate more emails into one, as it seems there is a repeating pattern. I would also prefer if somebody

> On 24 Mar 2018, at 15:58, Jim Reid <jim@rfc1035.com>; wrote:
> 
> Obsoleted RRtypes shouldn’t overload the camel enough to matter. It might be a different story if one of those zombie RRtypes required additional processing. None spring to mind though.


I am already tired of camel analogy, but there’s the other thing Bert talked about: that the DNS vendors need to grow spine and not implement every little thing.

Any new protocol and RR Type must jump through many hoops (Expert Review, WG Review, …), but the stuff that’s already in isn’t subject to any reconsideration if it was a good idea, and it just stays in.

On the other hand, the deprecation of SSLv2, then SSLv3 in quick succession has caused much more operational troubles. I know that the (in)security properties is what makes the differences, but this is just a reminder that we do and can remove old stuff from the Internet.

> On 24 Mar 2018, at 19:54, Matthew Pounsett <matt@conundrum.com>; wrote:
> 
> Speaking from experience, having spent a few dozen hours so far on some client code, the code necessary to implement an additional RRType is trivial by comparison to literally anything else in the protocol, including such (supposedly) trivial operations as reading and writing zone files.  I've got nothing against deprecating RRTypes that we know aren't in use, but it doesn't seem like a particularly high priority.


This document is sort of litmus paper test, whether we (not necessarily the dnsop WG) can actually remove old cruft from the DNS. The removal of RR Types I proposed is dead simple because of the reasons outlined below.

> On 24 Mar 2018, at 13:49, Jared Mauch <jared@puck.nether.net>; wrote:
> 
> 	I think the issue here is just because it's not commonly seen on the
> public internet, doesn't mean it's not used.  We don't use DHCP to configure
> p2p links on routers, this doesn't mean that DHCP can go away, it's used
> elsewhere.

I am proposing to deprecate RR Types that were either (see Dick Franks’ email for more):

a) declared OBSOLETE by RFC 1035 30 years ago
b) declared EXPERIMENTAL by RFC 1035 30 years ago
c) Adding NXT already marked as OBSOLETE by RFC 3755 also might work

There might be other RR Types that might get identified as a step in a wrong direction (as Jim Reid suggested or perhaps something from RFC 1183, RFC 1706), but I would rather stay with these simple cases.

To use, the numbers from your zones:

> num.type.MD=0
> num.type.MF=0
> num.type.MB=0
> num.type.MG=0
> num.type.MR=0

> num.type.WKS=0
> num.type.MINFO=0


So, the I-D that I am proposing would have absolutely no impact on you.

It’s interesting that there’s some NULL RR Type usage in your zones, I suppose that some experiments.

And removal of NXT would require some cleaning up:

> num.type.NXT=780

I strongly believe this is old cruft as there are no current tools that could the zone sign with pre-DNSSECbis records. So, this is more of subject to DNS archaeology then decision based process.

> On 24 Mar 2018, at 18:22, Viktor Dukhovni <ietf-dane@dukhovni.org>; wrote:
> 
> On Sat, Mar 24, 2018 at 02:58:55PM +0000, Jim Reid wrote:
> 
>> IMO there's no need to do this in the protocol unless there is convincing
>> proof that nobody anywhere is using a now-obsolete RRtype. An RFC saying
>> a server could return FORMERR (or whatever) when it gets a query for one
>> of these dead/zombie QTYPEs might be OK I suppose.
> 
> Absolutely no!  *THAT* would add substantial run-time complexity
> for no reason, achieving the opposite of any simplification that
> might result from dropping support for the RRtype. If there's no
> such data in your zone, return NODATA or NXDOMAIN as appropriate.
> If there is such data, return that data.


I concur. I am not proposing to hard-fail, only "soft-fail".

> On 24 Mar 2018, at 18:22, Viktor Dukhovni <ietf-dane@dukhovni.org>; wrote:
> 

> One might say that *new* tools may skip
> implementing obsolete RRtypes, and that users should avoid new
> uses of obsolete RRtypes, but there's not IMHO much impetus
> for removing support from existing tools.

This is the problem. You can’t just do that, because it is causing operational problems because of name compression in RDATA and RDATA canonicalisation (RFC 4034 Section 6.2). Here’s the example that triggered me to write the I-D: https://github.com/PowerDNS/pdns/issues/5687

Regards,
Ondrej
--
Ondřej Surý
ondrej@isc.org


> 	I think what Paul is trying to point out is the same thing, some
> enterprises may still be using it internally.  Just because we
> don't use the RR type in isc.org, nether.net, akamai.com doesn't mean
> nobody is using it for their internal networks.  We should attempt to
> determine who may be using it.  This can be done by logging or a survey
> of folks doing slave zones, etc.
> 
> 	isc/bind can and perhaps should implement logging for these
> rrtypes that say they may be going away so folks can see the impact.
> 
> 	ISC/bind also have a history of doing this with the warn & fail
> directives in the named.conf file, which would be a great way to expose
> these types of items.  check-old-rrtype (warn|fail|ignore) or something
> similar would be useful to an actual operator.
> 
> 	here's some data on rrtypes seen in my nameserver.
> 
> 	- Jared
> 
> server0.queries=109159256
> server1.queries=100199925
> num.queries=209359181
> num.type.TYPE0=27
> num.type.A=98905962
> num.type.NS=3428038
> num.type.MD=0
> num.type.MF=0
> num.type.CNAME=949771
> num.type.SOA=807788
> num.type.MB=0
> num.type.MG=0
> num.type.MR=0
> num.type.NULL=28
> num.type.WKS=0
> num.type.PTR=8847792
> num.type.HINFO=1178
> num.type.MINFO=0
> num.type.MX=4110956
> num.type.TXT=1164968
> num.type.RP=0
> num.type.AFSDB=2018
> num.type.X25=0
> num.type.ISDN=0
> num.type.RT=0
> num.type.NSAP=0
> num.type.SIG=0
> num.type.KEY=0
> num.type.PX=0
> num.type.AAAA=64526576
> num.type.LOC=2288
> num.type.NXT=780
> num.type.TYPE31=108
> num.type.SRV=2194823
> num.type.NAPTR=18707
> num.type.KX=0
> num.type.CERT=6
> num.type.TYPE38=238830
> num.type.DNAME=9
> num.type.OPT=0
> num.type.APL=0
> num.type.DS=177999
> num.type.SSHFP=4846
> num.type.IPSECKEY=0
> num.type.RRSIG=20178
> num.type.NSEC=281
> num.type.DNSKEY=2261055
> num.type.DHCID=0
> num.type.NSEC3=0
> num.type.NSEC3PARAM=2596
> num.type.TLSA=22176
> num.type.TYPE53=8
> num.type.CDS=2267
> num.type.CDNSKEY=2027
> num.type.OPENPGPKEY=0
> num.type.CSYNC=0
> num.type.TYPE65=2
> num.type.TYPE92=9
> num.type.SPF=109981
> num.type.NID=0
> num.type.L32=0
> num.type.L64=0
> num.type.LP=0
> num.type.EUI48=0
> num.type.EUI64=0
> num.type.TYPE127=5
> num.type.TYPE143=1
> num.type.TYPE165=1
> num.type.TYPE191=335
> num.type.TYPE222=3
> num.type.TYPE223=27
> num.type.TYPE239=29
> num.type.TYPE240=2
> num.type.TYPE243=2
> num.type.TYPE246=1
> num.type.TYPE247=41
> num.type.TYPE251=26458
> num.type.TYPE252=3312
> num.type.TYPE253=42
> num.type.TYPE254=29
> num.type.TYPE255=21357118
> num.opcode.QUERY=209248548
> num.opcode.NOTIFY=80330
> num.class.IN=209324746
> num.class.CH=4132
> num.rcode.NOERROR=138257521
> num.rcode.FORMERR=417
> num.rcode.SERVFAIL=132820
> num.rcode.NXDOMAIN=25011450
> num.rcode.NOTIMP=56046
> num.rcode.REFUSED=36625841
> num.rcode.YXDOMAIN=0
> num.rcode.NOTAUTH=4
> num.edns=189357953
> num.ednserr=307
> num.udp=171926848
> num.udp6=28159814
> num.tcp=9107734
> num.tcp6=164785
> num.answer_wo_aa=703271
> num.rxerr=0
> num.txerr=6
> num.raxfr=54
> num.truncated=12595885
> num.dropped=2592
> zone.master=70
> zone.slave=9350
> 
> 
> -- 
> Jared Mauch  | pgp key available via finger from jared@puck.nether.net
> clue++;      | http://puck.nether.net/~jared/  My statements are only mine.