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 <j...@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 <m...@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 <ja...@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-d...@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-d...@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ý ond...@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 ja...@puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only mine. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
