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

From: Ondřej Surý <[email-masked]>
Date: Fri, 23 Mar 2018 12:11:50 +0000

Heya,

this is a first attempt to start reducing the load on DNS Implementors and actually remove the stuff from DNS that’s not used and not needed anymore.

There’s github for the draft: https://github.com/oerdnj/draft-sury-dnsop-deprecate-obsolete-resource-records <https://github.com/oerdnj/draft-sury-dnsop-deprecate-obsolete-resource-records>

Ondrej
--
Ondřej Surý
[email-masked]

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
> Date: 23 March 2018 at 12:09:19 GMT
> To: "Ondrej Sury" <[email-masked]>
> 
> 
> A new version of I-D, draft-sury-deprecate-obsolete-resource-records-00.txt
> has been successfully submitted by Ondrej Sury and posted to the
> IETF repository.
> 
> Name:		draft-sury-deprecate-obsolete-resource-records
> Revision:	00
> Title:		Deprecating obsolete DNS Resource Records
> Document date:	2018-03-22
> Group:		Individual Submission
> Pages:		4
> URL:            https://www.ietf.org/internet-drafts/draft-sury-deprecate-obsolete-resource-records-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-sury-deprecate-obsolete-resource-records/
> Htmlized:       https://tools.ietf.org/html/draft-sury-deprecate-obsolete-resource-records-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-sury-deprecate-obsolete-resource-records
> 
> 
> Abstract:
>   This document deprecates Resource Records that are neither being used
>   for anything meanigful nor already made obsolete by other RFCs.  This
>   document updates [RFC1035].
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Martin Hoffmann <[email-masked]>
Date: Fri, 23 Mar 2018 13:41:40 +0100

Ondřej Surý <[email-masked]> wrote:
>
> this is a first attempt to start reducing the load on DNS
> Implementors and actually remove the stuff from DNS that’s
> not used and not needed anymore.

You might want to consider also updating RFC 3597, either to
specifically remove those record types from being “well-known”
or at least to have a reference in that RFC’s update list in
the index to point people to the updated list of what is allowed
to use name compression in the record data.

On a more nit-picky note: Unless I am missing something, your
motivation, i.e., confusion due to name compression, doesn’t
justify obsoleting WKS -- not that anyone would possibly miss
it.

Kind regards,
Martin

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 23 Mar 2018 13:48:03 +0100

Other candidates: MD, NXT, MAILA - They are obsolete too according to 
the IANA DNS parameters.

Also, if you want to deprecate MB, MG, you might want to consider 
deprecating MAILB too.

- Matthijs

On 23-03-18 13:11, Ondřej Surý wrote:
> Heya,
> 
> this is a first attempt to start reducing the load on DNS Implementors 
> and actually remove the stuff from DNS that’s not used and not needed 
> anymore.
> 
> There’s github for the draft: 
> https://github.com/oerdnj/draft-sury-dnsop-deprecate-obsolete-resource-records
> 
> Ondrej
> --
> Ondřej Surý
> [email-masked] <mailto:[email-masked]>
> 
>> Begin forwarded message:
>>
>> *From: [email-masked] <mailto:[email-masked]>
>> *Subject: **New Version Notification for 
>> draft-sury-deprecate-obsolete-resource-records-00.txt*
>> *Date: *23 March 2018 at 12:09:19 GMT
>> *To: *"Ondrej Sury" <[email-masked] <mailto:[email-masked]>>
>>
>>
>> A new version of I-D, 
>> draft-sury-deprecate-obsolete-resource-records-00.txt
>> Name:draft-sury-deprecate-obsolete-resource-records
>> Revision:00
>> Title:Deprecating obsolete DNS Resource Records
>> Document date:2018-03-22
>> Group:Individual Submission
>> Pages:4
>> URL: 
>> https://www.ietf.org/internet-drafts/draft-sury-deprecate-obsolete-resource-records-00.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-sury-deprecate-obsolete-resource-records/
>> Htmlized: 
>> https://tools.ietf.org/html/draft-sury-deprecate-obsolete-resource-records-00
>> Htmlized: 
>> https://datatracker.ietf.org/doc/html/draft-sury-deprecate-obsolete-resource-records
>>
>>
>> Abstract:
>> until the htmlized version and diff are available at tools.ietf.org 
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
> 
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Mukund Sivaraman <[email-masked]>
Date: Fri, 23 Mar 2018 18:33:21 +0530

On Fri, Mar 23, 2018 at 01:48:03PM +0100, Matthijs Mekking wrote:
> Other candidates: MD, NXT, MAILA - They are obsolete too according to the
> IANA DNS parameters.
> 

There are a few more that are/were in use which are not even listed.
E.g, "A" was used outside IN class.

		Mukund

---

From: Bob Harold <[email-masked]>
Date: Fri, 23 Mar 2018 10:18:37 -0400

On Fri, Mar 23, 2018 at 8:11 AM, Ondřej Surý <[email-masked]> wrote:

> Heya,
>
> this is a first attempt to start reducing the load on DNS Implementors and
> actually remove the stuff from DNS that’s not used and not needed anymore.
>
> There’s github for the draft: https://github.com/oerdnj/draft-sury-dnsop-
> deprecate-obsolete-resource-records
>
> Ondrej
> --
> Ondřej Surý
> [email-masked]
>
> Begin forwarded message:
>
> *From: [email-masked]
> *To: *"Ondrej Sury" <[email-masked]>
>
>
> URL:            https://www.ietf.org/internet-drafts/draft-
> sury-deprecate-obsolete-resource-records-00.txt
I don't mind deprecating unused types.  But I don't understand how an
unused type can affect compression.  I can only imagine it having an effect
if the type actually exists in a packet, which means that it is 'in use'.

Do you mean 'types that have DNS records, and hosts query for those
records, but we think they are not really used'  ?

-- 
Bob Harold

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 23 Mar 2018 16:05:30 +0000

No, I don’t mean that. While in theory you can call an aquarium with dead fish and algae “in use” and tell your neighbors that you have fish and have a green thumb, it wouldn’t be necessarily an accurate assessment of the situation. Similarly, an occasional user that tries things doesn’t make those experimental RRTYPEs to be “in use”.

What I mean is to make DNS simpler by kicking out stuff that has no use in existing protocols.

Ondřej 
--
Ondřej Surý — ISC

> On 23 Mar 2018, at 14:18, Bob Harold <[email-masked]> wrote:
> 
> 
>> There’s github for the draft: https://github.com/oerdnj/draft-sury-dnsop-deprecate-obsolete-resource-records
>> 
>> Ondrej
>> --
>> Ondřej Surý
>> [email-masked]
>> 
>>> Begin forwarded message:
>>> 
> I don't mind deprecating unused types.  But I don't understand how an unused type can affect compression.  I can only imagine it having an effect if the type actually exists in a packet, which means that it is 'in use'.
> 
> Do you mean 'types that have DNS records, and hosts query for those records, but we think they are not really used'  ?
> 
> -- 
> Bob Harold
>

---

From: Bob Harold <[email-masked]>
Date: Fri, 23 Mar 2018 12:51:52 -0400

On Fri, Mar 23, 2018 at 12:05 PM, Ondřej Surý <[email-masked]> wrote:

> No, I don’t mean that. While in theory you can call an aquarium with dead
> fish and algae “in use” and tell your neighbors that you have fish and have
> a green thumb, it wouldn’t be necessarily an accurate assessment of the
> situation. Similarly, an occasional user that tries things doesn’t make
> those experimental RRTYPEs to be “in use”.
>
Ok, sorry to sound mean.  But I think 'not in use' needs to be defined in
the rfc so we all understand it the same.  How do we decide when something
in no longer in use?  Perhaps there is no quantitative measurement and we
just have to make a judgement call.

"no known practical usage" ?
"no known use that will break anything if removed" ?
"use is so low that the the advantage of removing exceeds the advantage of
continuing to support it" ?
"there is very little use and we don't think removing it will cause a
problem" ?

-- 
Bob Harold

>> There’s github for the draft: https://github.com/oerd
>> nj/draft-sury-dnsop-deprecate-obsolete-resource-records
>>
>> Ondrej
>> --
>> Ondřej Surý
>> [email-masked]
>>
>> Begin forwarded message:
>>
>> URL:            https://www.ietf.org/internet-drafts/draft-sury-
>> deprecate-obsolete-resource-records-00.txt

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 23 Mar 2018 17:03:05 +0000

Thanks, now I understand what you are asking for;), so what about:

“No existing Internet Standard uses these Resource Records and there no know practical usage in the public Internet.”

Ondřej
--
Ondřej Surý — ISC

> On 23 Mar 2018, at 16:51, Bob Harold <[email-masked]> wrote:
> 
> 
> Ok, sorry to sound mean.  But I think 'not in use' needs to be defined in the rfc so we all understand it the same.  How do we decide when something in no longer in use?  Perhaps there is no quantitative measurement and we just have to make a judgement call.
> 
> "use is so low that the the advantage of removing exceeds the advantage of continuing to support it" ?
> "there is very little use and we don't think removing it will cause a problem" ?
> 
> -- 
> Bob Harold
> 
>

---

From: Bob Harold <[email-masked]>
Date: Fri, 23 Mar 2018 13:23:39 -0400

On Fri, Mar 23, 2018 at 1:03 PM, Ondřej Surý <[email-masked]> wrote:

> “No existing Internet Standard uses these Resource Records and there no
> know practical usage in the public Internet.”
>
> Ondřej
> --
> Ondřej Surý — ISC
>
>
Works for me, thanks!

-- 
Bob Harold

>>> URL:            https://www.ietf.org/internet-drafts/draft-sury-d
>>> eprecate-obsolete-resource-records-00.txt

---

From: Paul Vixie <[email-masked]>
Date: Fri, 23 Mar 2018 10:55:23 -0700

> know practical usage in the public Internet.”

i think this is overbroad. if we aren't also sure that it's not being 
used in some private network somewhere, we should not tell implementers 
to remove support. a lot of private networks use internet protocols and 
implementations to support their local apps and users.

mf, mg, mb, and mail1 are i think still in use on some as/400 intranets.

when i removed UID and GID from BIND it was because there was no RFC, 
not because i wasn't fully aware of some older athena implementations 
still in use at that time which used these instead of TXT.

ideally we'd put out an extended call for comments about anything we'd 
like to remove if it ever worked to anyone's knowledge. if it never 
worked, like extended label types in EDNS, they can just be removed.

this is how we handled IQUERY deprecation and i think it went well.

-- 
P Vixie

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 23 Mar 2018 18:11:27 +0000

I strongly disagree. The DNS protocol deserve cleanup. Deprecating RRTYPEs doesn’t mean the will stop working on the day the RFC is published, neither are people going to backport the removal of RRTYPEs to existing DNS software releases.

It just means - whatever ancient stuff you are using - you are on your own now. It’s same as with the stuff that never got the RFC. You can you whatever you want, it will be your responsibility (and costs), not the implementors. So, the people can keep their old system running, they just can’t expect the current DNS to interoperate with them.

Paul, sorry, but the argument “but I know of people running” ancient systems can’t be used at every attempt to cleanup the kitchensink protocol that DNS is right now.

Ondrej 
--
Ondřej Surý — ISC

> On 23 Mar 2018, at 17:55, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Ondřej Surý wrote:
> i think this is overbroad. if we aren't also sure that it's not being used in some private network somewhere, we should not tell implementers to remove support. a lot of private networks use internet protocols and implementations to support their local apps and users.
> 
> when i removed UID and GID from BIND it was because there was no RFC, not because i wasn't fully aware of some older athena implementations still in use at that time which used these instead of TXT.
> 
> ideally we'd put out an extended call for comments about anything we'd like to remove if it ever worked to anyone's knowledge. if it never worked, like extended label types in EDNS, they can just be removed.
>

---

From: Paul Vixie <[email-masked]>
Date: Fri, 23 Mar 2018 11:26:19 -0700

Ondřej Surý wrote:
> I strongly disagree. The DNS protocol deserve cleanup. Deprecating
> RRTYPEs doesn’t mean the will stop working on the day the RFC is
> published, neither are people going to backport the removal of
> RRTYPEs to existing DNS software releases.
>
> It just means - whatever ancient stuff you are using - you are on
> your own now. It’s same as with the stuff that never got the RFC.

so anyone supporting an older internal network using modern tools has to 
stop upgrading their tooling. that's not constructive for anybody. all 
of us will be less safe if these tools become non-upgradeable.

> Paul, sorry, but the argument “but I know of people running” ancient
> systems can’t be used at every attempt to cleanup the kitchensink
> protocol that DNS is right now.

ondrej, if you're looking for stuff to kill that nobody is using and 
that needlessly fattens the camel, there's a lot of lower hanging fruit.

to say it's complicated, let's simplify it, and oh by the way we need to 
add a CNAME to support the never-workable RFC 5011 plan we adopted in 
ignorance many years back, in the same breath, confuses me.

-- 
P Vixie

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 23 Mar 2018 18:32:07 +0000

What’s so wrong of using TYPExxx for these if you absolutely need them to run the ancient technology while at the same time running the latest version of BIND (or your favorite DNS server)?

Your argument feels like strawman to me. And I am not the one sitting on a pile of passive DNS data, so I can’t pull the numbers...

We are not taking the ability to put random TYPEnnn records into the zone, we are just saying the tools just won’t understand them anymore. Again nothing is going to break on the day one.

Ondrej
--
Ondřej Surý — ISC

> On 23 Mar 2018, at 18:26, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Ondřej Surý wrote:
> so anyone supporting an older internal network using modern tools has to stop upgrading their tooling. that's not constructive for anybody. all of us will be less safe if these tools become non-upgradeable.
> 
> ondrej, if you're looking for stuff to kill that nobody is using and that needlessly fattens the camel, there's a lot of lower hanging fruit.
> 
> to say it's complicated, let's simplify it, and oh by the way we need to add a CNAME to support the never-workable RFC 5011 plan we adopted in ignorance many years back, in the same breath, confuses me.
> 
> -- 
> P Vixie
>

---

From: Paul Vixie <[email-masked]>
Date: Fri, 23 Mar 2018 11:39:46 -0700

Ondřej Surý wrote:
> What’s so wrong of using TYPExxx for these if you absolutely need
> them to run the ancient technology while at the same time running the
> latest version of BIND (or your favorite DNS server)?

because i am loathe to break existing working configurations. when isc 
changed the value of allow-query to be LAN only, it took years to do as 
safely as we knew how, and even so there was some breakage.

> Your argument feels like strawman to me. And I am not the one sitting
> on a pile of passive DNS data, so I can’t pull the numbers...

we don't see a lot of intranet data, so that would not be dispositive. 
however, i urge you to reconsider your strawman-ish feelings. we are 
forever rebuilding the airplane in flight. the long tail matters.

> We are not taking the ability to put random TYPEnnn records into the
> zone, we are just saying the tools just won’t understand them
> anymore. Again nothing is going to break on the day one.

as long as people know what they're doing and are willing to convert 
their zones using tools unspecified, that's true. but you are chewing on 
the narrowest part of bert's camel here, at some risk, little gain.

-- 
P Vixie

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 23 Mar 2018 19:18:25 +0000

The configurations change all the time, I am sorry, but your argument doesn’t have a technical merit.

We really do need to start removing obsolete stuff from DNS, and I believe this is a good start.

Ondřej 
--
Ondřej Surý — ISC

> On 23 Mar 2018, at 18:39, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Ondřej Surý wrote:
> because i am loathe to break existing working configurations. when isc changed the value of allow-query to be LAN only, it took years to do as safely as we knew how, and even so there was some breakage.
> 
> we don't see a lot of intranet data, so that would not be dispositive. however, i urge you to reconsider your strawman-ish feelings. we are forever rebuilding the airplane in flight. the long tail matters.
> 
> as long as people know what they're doing and are willing to convert their zones using tools unspecified, that's true. but you are chewing on the narrowest part of bert's camel here, at some risk, little gain.
> 
> -- 
> P Vixie
>

---

From: P Vix <[email-masked]>
Date: Fri, 23 Mar 2018 19:24:16 +0000

Did you hear the part about doing it the way we did when deprecation iquery? There's a discovery and decision process that involves the broader community.

Technical merit was provided. Sad that I can't think of a way to do it more clearly.

On March 23, 2018 7:18:25 PM UTC, "Ondřej Surý" <[email-masked]> wrote:
>> because i am loathe to break existing working configurations. when
>isc changed the value of allow-query to be LAN only, it took years to
>do as safely as we knew how, and even so there was some breakage.
>> 
>> we don't see a lot of intranet data, so that would not be
>dispositive. however, i urge you to reconsider your strawman-ish
>feelings. we are forever rebuilding the airplane in flight. the long
>tail matters.
>> 
>their zones using tools unspecified, that's true. but you are chewing
>on the narrowest part of bert's camel here, at some risk, little gain.
>> 
>> -- 
>> P Vixie
>> 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Dick Franks <[email-masked]>
Date: Fri, 23 Mar 2018 23:06:06 +0000

> actually remove the stuff from DNS that’s not used and not needed anymore.

I have no quarrel with the overall effect of this proposal, but the
justifications are necessarily different for each category identified in
RFC1035.

          3.3.4. MD RDATA format (Obsolete)
          3.3.5. MF RDATA format (Obsolete)

These were already obsolete when RFC1035 was published and arguably should
never have appeared at all.
If these have not already been deprecated somewhere else, there is no
plausible argument against doing so now.

          3.3.3. MB RDATA format (EXPERIMENTAL)
          3.3.6. MG RDATA format (EXPERIMENTAL)
          3.3.7. MINFO RDATA format (EXPERIMENTAL)
          3.3.8. MR RDATA format (EXPERIMENTAL)

After 30 years, it seem clear that the "experiment" produced little or
nothing of lasting value.  Plenty of word have been wasted in the past
about open-ended experiments and unpublished results.  Deprecating these
RRTYPES would put a formal end to the "experiment".  Any counter-argument
needs to be justified by evidence of continuing use in the global internet,
and made by the parties directly affected.  The "someone might be using it
somewhere ..." argument is far from convincing.

          3.4.2. WKS RDATA format

WKS is IPv4-specific, so the choice is ether to wait until IPv4 itself
becomes deprecated, or to dispose of it now in the same manner as MB, MG
etc.

          3.2.3. QTYPE values

The intended meaning of MAILA is uncertain, but it is already declared by
RFC1035 to be obsolete.

MAILB is a specific request for MB, MG, and MR records.

Both should also be deprecated by this document.

--DIck

---

From: Jared Mauch <[email-masked]>
Date: Sat, 24 Mar 2018 08:49:58 -0400

> We are not taking the ability to put random TYPEnnn records into the zone, we are just saying the tools just won’t understand them anymore. Again nothing is going to break on the day one.

	Ondrej,

	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 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 [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Joe Abley <[email-masked]>
Date: Sat, 24 Mar 2018 06:48:35 -0700

> rrtypes that say they may be going away so folks can see the impact.

I'm actually surprised to see that support for rarely-used RRTypes is
really upsetting the camel.

A combinatorial explosion of annoying workarounds for the inability of
middleboxes or upstream authority servers to implement EDNS(0)
properly seems like a much more plausible camel irritant to me. I'm
sure there are many more like that.

I can see why you could strip out lines of code by eliminating the
need to parse the canonical formatting of WKS and friends, but I'm
surprised that it's a notable source of complexity. It is, after all,
complexity that I heard is causing the camel strain, not just lines of
code.

If future-BIND stops parsing an archaic RRType that I happen to use,
I'm going to have to change whatever code or processes that depend on
it. Maybe someone (ISC, even) is going to publish a filter that will
turn all the old RRs in canonical syntax into TYPExxxx representation,
and back again. New RRTypes might then need to get implemented in both
BIND (because presumably they are camel-friendly) and also in the
filter or filters, because perhaps we are targeting multiple
nameserver implementations with our zone file.

This all sounds like we're just sharing the complexity around. It
doesn't sound any simpler. Maybe it's a silly example? I don't know.
Could be. But I think brushing the grains RRType parsing dust off the
camel is not going to do much for its posture.

Joe

---

From: Jim Reid <[email-masked]>
Date: Sat, 24 Mar 2018 14:58:55 +0000

> On 24 Mar 2018, at 13:48, Joe Abley <[email-masked]> wrote:
> 
> But I think brushing the grains RRType parsing dust off the

+1.

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.
That way, an implementer can delete the crufty code -- or not write any -- and still do the right thing (sort of) if their server sees one of these RRtypes in the wild.

If there are corner cases where codes were allocated for an organisation-specific purpose* and the organisation can confirm the type codes are no longer used or needed, these could be dropped from the DNS. In some respects, old DNS type codes are like pre-RIR IPv4 allocations and we’re just stuck with those legacy choices.

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’m thinking of things like Telnic’s NINFO and RKEY*. I have no idea if those two are actually used these days and would prefer not to find out. Although they seemed a reasonable idea at the time, I’ve disowned these wayward stepchildren. And .tel FWIW.

---

From: Ondřej Surý <[email-masked]>
Date: Sat, 24 Mar 2018 16:23:25 +0100

Joe,

it’s actually not the complexity in BIND (although I view everything as extra complexity), it’s the interop for new players that need to implement every piece of rusty junk that's in the protocol to be interoperable.

While it seems to be attractive to keep the existing open-source tetrapoly (insert your favorite Greek numerical prefix), the fact is that new implementations do pop up from time to time, and if we can reduce the protocol a little bit, so they can actually implement what’s important, that would be the noble goal here.

Let me repeat again - we are speaking about stuff that was declared either OBSOLETE or EXPERIMENTAL already in RFC1035.

I’ll elaborate more about why I think we locked ourselves into this when I am not typing on small phone screen in reply to Jared’s message later today.

Cheers,
Ondrej

--
Ondřej Surý — ISC

> On 24 Mar 2018, at 14:48, Joe Abley <[email-masked]> wrote:
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 24 Mar 2018 17:22:49 +0000

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.

This would be grossly misguided.  Perhaps time to reread:

    https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08

As for removing parsing code from tools, I sympathise with the view
that this does not remove much complexity that matters.  The
complexity we really should care about is wire (protocol) complexity,
not tool complexity.  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.

That said, legacy code has some costs, and one should attempt to
eventually shed bits nobody uses. So while I agre that the priorities
are elsewhere, this too is something one might eventually pay
attention to.  So I am not opposed to dropping parser support for
essentially unused types.  It just needs to be down with care,
first issue deprecation warnings for a few releases, then if there
are few enough complaints, remove support.

-- 
	Viktor.

---

From: Matthew Pounsett <[email-masked]>
Date: Sat, 24 Mar 2018 14:54:05 -0400

On 24 March 2018 at 09:48, Joe Abley <[email-masked]> wrote:

> +1

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.

---

From: Ondřej Surý <[email-masked]>
Date: Sat, 24 Mar 2018 21:20:06 +0100

> It might be a different story if one of those zombie RRtypes required additional processing. None spring to mind though.

But (most of) those I picked actually *DO*:

a) compression is allowed, so compliant and non-compliant servers can’t speak together, because non-compliant will just store junk in the RDATA when received from compliant server;
b) the RDATA needs to be understood and lowercased for canonical form when DNSSEC signing; again you need to *implement* this in DNSSEC Validator as it would cause validation failures if you don't

And all this extra work must be done for RR Types that are unused in current protocols. The implementation for these M* types isn’t just wire<->human readable translation.

Ondrej
--
Ondřej Surý
[email-masked]

---

From: Mukund Sivaraman <[email-masked]>
Date: Sun, 25 Mar 2018 03:25:45 +0530

Hi Ondrej

> But (most of) those I picked actually *DO*:

In the case of RR types, "additional processing" means type specific
behaviors that do not usually apply to other types. For example, CNAME
has additional processing. The following processing is common to 1035
types.

> And all this extra work must be done for RR Types that are unused in current protocols. The implementation for these M* types isn’t just wire<->human readable translation.

These types can go in any future 1035 bis draft, in support of what
you're asking because they are obsolete.

But as it stands, RR types (except additional processing) are typically
implemented in software as an RDATA interface with type specific
implementations. Removing these types will mean rm -f'ing some
implementation files/classes, which certainly reduces the quantity of
code but does not affect complexity of the nameserver as other types
require similar common RDATA processing anyway. In this regard, other
commenters are right in observing that it doesn't affect complexity
significantly.

Any proposal that has a draft written can get an RRTYPE assignment
approved and these appear from time to time - it doesn't affect
complexity unless there's additional processing.

Some things to think about for DNS complexity:

* Obsoleting CLIENT-SUBNET.. as mentioned on a BIND ticket,
  CLIENT-SUBNET flies in the face of where DNS is headed (towards more
  privacy). If every user used the resolver on their own network,
  there'd be no need for this facility. It's only when forwarders and
  caches (that are arguably anti-privacy) from outside the network come
  into play, that CLIENT-SUBNET becomes necessary. We as DNS community
  should push towards validating resolvers closer to devices.

  This is even without discussing CLIENT-SUBNET's design issues, for
  which alone it can go. There is a LOT unwritten in CLIENT-SUBNET RFC.

* TSIG extras: In TCP continuation (multiple DNS messages such as
  during AXFR), TSIG allows some intermediate messages to be sent
  unsigned without TSIG RR, and a following TSIG RR to cover all such
  intermediate messages. There is no need for such a thing in today's
  world. BIND and Knot do not generate such TSIG signed continuations
  with gaps (though BIND can parse them), whereas NSD does generate
  them. It is just an extra variant to save little space that adds
  implementation complexity.

* TSIG extra extra: TSIG allows truncated MACs which just is ugly.  Some
  DNS messages may overflow the PMTU or the client-specified EDNS UDP
  buffer size if the full MAC is specified vs. the truncated MAC but
  this is such a corner case with little benefit compared to complexity
  of handling this facility, checking truncated limits, etc. And extra
  BADTRUNC rcode, etc.

* Revising the DNS message format would be a no-no, but there're
  redundancies there (repeating owner names [even if they can be
  compressed], class, type, TTL, possibility of TTL mismatch among RRs
  of a set, etc.). RR class is extra complexity for the most case on the
  internet. RRs can be out of order of sets.. it is ugly to parse. DNS
  message processing/rendering is inefficient due to the redundancies.

* Name compression (aggressively done) is inefficient and takes up a
  significant portion of runtime, and there has been a lot of to and fro
  on type-specific rules. RFC 1123 requires name compression, but one
  might as well abandon it and put out names in full, esp. over
  TCP. It'll eat more bytes, but not much compared to Youtube and
  software updates.

* All these new additional answer / additional section multi-RR
  proposals.. if you ask me, I don't want it in our DNS implementation.

-----

Language in RFCs of the time of 1034/1035 is underspecified. We're
counting pages, but one way to reduce confusion about the protocol is to
_add_ more details and write a bis using 1034/1035 + ncache + edns +
clarifications, etc. with modern language and extra detail.

As an example, I was asked by a colleage a couple of days ago if any
RFCs required that, if the answer section of a reply had:

(1) a valid answer RRset matching the RR type that was queried, and
(2) _other_ RRs that are unrelated,

then should the reply message be discarded?

While this may be classified to be "common sense", this case does not
appear to be specified, and it was a valid enough question for someone
to ask about it. RFC 1034 has ambiguous language which can be
misconstrued to mean anything:

> Step 4 involves analyzing responses.  The resolver should be highly
> paranoid in its parsing of responses.

However, back in its day, the synthesized CNAME for DNAME replies would
be totally meaningless if there was a type mismatch and a resolver
implementation of that day threw away a response if an unrelated (and
back in the day unknown) DNAME type was found in the response.

There are details in DNS implementation code on how to handle cases that
are not specified in RFCs. A modern document should specify more
behaviors clearly, which would increase its page count, but also
increase understanding.

		Mukund

---

From: Ondřej Surý <[email-masked]>
Date: Sun, 25 Mar 2018 07:19:08 +0200

Thanks Dick, this is very helpful suggestion and I’ll use it.

Ondrej
--
Ondřej Surý
[email-masked]

> On 24 Mar 2018, at 00:06, Dick Franks <[email-masked]> wrote:
> 
> 
> I have no quarrel with the overall effect of this proposal, but the justifications are necessarily different for each category identified in RFC1035.
> 
> These were already obsolete when RFC1035 was published and arguably should never have appeared at all.
> If these have not already been deprecated somewhere else, there is no plausible argument against doing so now. 
> 
> 
> After 30 years, it seem clear that the "experiment" produced little or nothing of lasting value.  Plenty of word have been wasted in the past about open-ended experiments and unpublished results.  Deprecating these RRTYPES would put a formal end to the "experiment".  Any counter-argument needs to be justified by evidence of continuing use in the global internet, and made by the parties directly affected.  The "someone might be using it somewhere ..." argument is far from convincing.
> 
> 
>           3.4.2. WKS RDATA format
> 
> WKS is IPv4-specific, so the choice is ether to wait until IPv4 itself becomes deprecated, or to dispose of it now in the same manner as MB, MG etc.
> 
> 
>           3.2.3. QTYPE values
> 
> The intended meaning of MAILA is uncertain, but it is already declared by RFC1035 to be obsolete.
>

---

From: Ondřej Surý <[email-masked]>
Date: Sun, 25 Mar 2018 07:57:32 +0200

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 <[email-masked]> wrote:
> 

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 <[email-masked]> 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 <[email-masked]> wrote:
> 

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.

> 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.

> 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 <[email-masked]> wrote:
> 

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

> On 24 Mar 2018, at 18:22, Viktor Dukhovni <[email-masked]> wrote:
> 

> One might say that *new* tools may skip

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ý
[email-masked]

---

From: Ondřej Surý <[email-masked]>
Date: Sun, 25 Mar 2018 08:08:59 +0200

> On 24 Mar 2018, at 22:55, Mukund Sivaraman <[email-masked]> wrote:
> 
> Hi Ondrej
> 

I knew somebody would notice my “hyperbole”.

> Some things to think about for DNS complexity:

These are harder to tackle, and I thought beginning with something simple would be … simple.

>  which alone it can go. There is a LOT unwritten in CLIENT-SUBNET RFC.

ECS is optional feature and DNS vendors could decide whether the want to implement ECS or not.

>  implementation complexity.

I agree that making this simpler would be a good thing, but we’ll have to "not generate, but accept” first approach here.

>  of handling this facility, checking truncated limits, etc. And extra

Ack.

>  message processing/rendering is inefficient due to the redundancies.

BCP perhaps?  E.g. write BCP on how to generate good DNS message?

>  TCP. It'll eat more bytes, but not much compared to Youtube and

A document that would say that DNS Compression might or might not happen aggressively would be useful. But then perhaps it would just add more RFCs to read, when some implementors do just read wireshark...

> misconstrued to mean anything:

I think this is required, but it also requires a funding for somebody to lead the effort, because most of us here have a day-to-day job that have higher priorities than creating new WG, rewriting old DNS standard and then arguing for years, which _is_ going to happen :).

Ondrej
--
Ondřej Surý
[email-masked]

---

From: Evan Hunt <[email-masked]>
Date: Sun, 25 Mar 2018 08:05:58 +0000

> really upsetting the camel.

It's an interesting object lesson in the complexity of unloading camels,
though.  (Perhaps it's time to add something about "the eye of a needle" to
our camel metaphor.)

> sure there are many more like that.

Wholeheartedly agree, and efforts to address this are under way.

> camel is not going to do much for its posture.

I think it would help if there were more clarity on what exactly is being
proposed, other than adding the words "obsolete" or "deprecated" to a list
of RRtypes on a website somewhere. The draft didn't seem to have
particularly clear guidance to implementers.

These RR types have text representations and wire format representations,
which from a complexity standpoint seem quite harmless to implement.  There
are the old annoying rules about name compression and sorting, which do add
some complexity, but are already implemented in all the existing codebases.
I don't see how the IETF can mandate that they be removed, nor am I sure
it's particuilarly worth doing.  We can make them optional to implement in
the future, though.  Perhaps that's all Ondrej has in mind?

(With respect to BIND, if these types are declared obsolete by the working
group, then my inclination would be to a log a message saying so if you
tried to load them in a zone, same as with SPF.  In a future relase I might
start treating them as opague types when rendering to wire format, but
would probably retain the ability to parse them and display them as text.)

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 25 Mar 2018 14:19:56 +0100

> particularly clear guidance to implementers.

Fully agree. I would hope that such guidance gets into the draft before 
it moves forwards.
> which from a complexity standpoint seem quite harmless to implement.

Yes.

> There

...and probably needs to be kept for the future to interoperate with the 
current code bases.

> it's particuilarly worth doing.

Right.

> We can make them optional to implement in
> the future, though.

...except that, if some implementer reads this document as meaning that 
they don't have to handle the listed RRtypes in any special way, they 
could get nailed when interoperating with implementations that handle 
the compression correctly.

> Perhaps that's all Ondrej has in mind?

Only he can say. :-)

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Sun, 25 Mar 2018 11:27:36 -0400 (EDT)

> particularly clear guidance to implementers.

I agree.

And I don't see much point in obsoleting simple defines and logging
unknown RRtypes.

Paul

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 26 Mar 2018 10:07:47 +0200

> really upsetting the camel.

To me this deprecating obsolete records is more an exercise of picking 
the low hanging fruit. Start with an easy task, gain experience for more 
difficult "unloading the camel".

Best regards,
   Matthijs

---

From: Paul Vixie <[email-masked]>
Date: Mon, 26 Mar 2018 01:12:17 -0700

> difficult "unloading the camel".

that was done, with deprecate-iquery. we now know how to do this.

but, we have got to stop saying things like "i don't see this protocol 
feature used in the queries hitting my feature, therefore it's not 
important any more." the internet, and the private intranets beyond the 
edge of the internet, is a big place.

the fat part of this camel may not be the oldest dna, either.

-- 
P Vixie

---

From: Shane Kerr <[email-masked]>
Date: Mon, 26 Mar 2018 08:23:00 +0000

All,

>> really upsetting the camel.

I'm not that surprised. It's pretty close to a bike shed topic; everyone
can understand it, it is not *that* important, and so everyone can have
an opinion that is basically as valid as any other. ;-)

> difficult "unloading the camel".

I agree with Matthijs here.

I think Paul's advice of looking at prior work in deprecating unused (or
harmful) bits of the DNS protocol makes sense. Since the way software is
deployed and used is not exactly the same now as it was in 2002, so we
actually have to repeat the exercise and see how stuff breaks now (or
not... I mean... MB?).

Cheers,

--
Shane

---

From: Evan Hunt <[email-masked]>
Date: Mon, 26 Mar 2018 11:44:19 +0000

On Sun, Mar 25, 2018 at 02:19:56PM +0100, Paul Hoffman wrote:
> ....except that, if some implementer reads this document as meaning that 

I'm not sure that's a major concern though. If you receive an MB RRset
and you don't implement that type, or if you do but your impelementation
assumes the rdata won't be compressed and it is, then you could just treat
it as an opaque TYPE7 RRset.  We do have experience with interoperation
between servers that implement different sets of rrtypes.

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 26 Mar 2018 14:05:12 +0200

> On 25 Mar 2018, at 17:27, Paul Wouters <[email-masked]> wrote:
> 

Paul,

I think that modifying (or removing stuff from) the DNS standard(s) MUST NOT be driven by “how simple it is”, but “how useful it is”.

This would just lead into the situation that we would have two categories: “oh, that's too simple to remove” and “oh, that’s too difficult to remove” and nothing in between.

Ondrej
--
Ondřej Surý
[email-masked]

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 26 Mar 2018 14:09:14 +0200

> On 25 Mar 2018, at 15:19, Paul Hoffman <[email-masked]> wrote:
> 
> ...except that, if some implementer reads this document as meaning that they don't have to handle the listed RRtypes in any special way, they could get nailed when interoperating with implementations that handle the compression correctly.

That’s one of the goals of the document - saying: “it’s ok to not implement those RR Types, and it’s ok to break if you receive them"

> particularly clear guidance to implementers.

Correct, and I was also seeking more feedback from the DNS people on that matter.

Currently, there are RR Types already marked as “OBSOLETE” in the IANA registry without clear understanding what that does really mean.  I guess the document might be able to specify what “OBSOLETE” means for RR Types (in the line of ^^^ “it’s ok to …”.)

Ondrej
--
Ondřej Surý
[email-masked]

---

From: Evan Hunt <[email-masked]>
Date: Mon, 26 Mar 2018 12:45:44 +0000

On Mon, Mar 26, 2018 at 02:09:14PM +0200, Ondřej Surý wrote:
> That’s one of the goals of the document - saying: “it’s ok to not
> implement those RR Types, and it’s ok to break if you receive them"

We need to state clearly what is meant by "ok to break".

I described my preferred approach as an implementer upthread. Let me
state it again more formally and let people knock it down:

0. types will be flagged as obsolete/deprecated in the IANA registry,
   and the following guidance is given to DNS implementors in the handling
   of obsolete/deprecated RR types:

1. auth servers SHOULD log a warning when loading zones that contain
   obsolete/deprecated rrtypes.

2. responders SHOULD NOT compress rdata when rendering obsolete/deprecated
   type records to wire format.

3. queriers which receive obsolete/deprecated type records MAY interpret
   them as unknown type records (rfc 3597), and MUST NOT interfere with
   their transmission.

   3a. note that the choice to parse obsolete/deprecated MAY be contingent
       on whether the rdata is compressed: an obsolete type record MAY be
       parsed as a known type if its rdata is uncompressed, but as an
       unknown type otherwise.

4. validators and signers SHOULD treat rdata for obsolete/deprecated types
   as opaque with respect to canonical RR ordering and deduplication

---

From: Tony Finch <[email-masked]>
Date: Mon, 26 Mar 2018 14:39:36 +0100

> some complexity, but are already implemented in all the existing codebases.

There's the particularly special case of WKS which has weird collision
logic - RFC 2136 section 3.4.2.2. It's extra weird that this was specified
in 1997 when WKS was deprecated in 1989 - RFC 1101 and RFC 1123.

I fear that this will make it hard to delete WKS code because that may
introduce interop bugs if a new server bindly allows colliding WKS records
that an old server objects to.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Irish Sea: South 4, increasing 5 to 7, then veering west later. Slight or
moderate. Rain at times. Good, occasionally poor.

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 26 Mar 2018 16:12:28 +0200

> On 26 Mar 2018, at 15:39, Tony Finch <[email-masked]> wrote:
> 

Good catch. WKS would then probably need a separate document that would also remove it from RFC 2136.

But it’s funny that we should not remove a record while this was already written in 1989:

      An application SHOULD NOT rely on the ability to locate a WKS
      record containing an accurate listing of all services at a
      particular host address, since the WKS RR type is not often used
      by Internet sites.  To confirm that a service is present, simply
      attempt to use it.

While the special processing was added to RFC 2136 (9 years later) is really beyond my understanding :(.

Ondrej
--
Ondřej Surý
[email-masked]

---

From: Michael Casadevall <[email-masked]>
Date: Mon, 26 Mar 2018 10:22:30 -0400

> We need to state clearly what is meant by "ok to break".

I think to be more specifically, the end goal should be the ability to
treat obsolete record types as RFC 3597 and remove special casing for
them. That way, new resolvers simply have to implement 3597 and not
worry about associated edge cases with the obsolete types.

>    type records to wire format.

The problem here is that right up until the point the camel declares
these RRtypes dead, the specification specifically allows them to be
compressed.

Specifically quoting RFC 3597 here:
   To avoid such corruption, servers MUST NOT compress domain names
   embedded in the RDATA of types that are class-specific or not well-
   known.  This requirement was stated in [RFC1123] without defining the
   term "well-known"; it is hereby specified that only the RR types
   defined in [RFC1035] are to be considered "well-known".

By definition, the types are in RFC1035; they're well known and thus
compressible. One DNS server may serve a given record uncompressed,
while the next one down the pipe compresses it depending on it's
implementation.

This came up earlier in the thread, but PowerDNS has an open bug about
this and the MB type due to BIND sending the record compressed, and
PowerDNS not recognizing it: https://github.com/PowerDNS/pdns/issues/5687

>    as opaque with respect to canonical RR ordering and deduplication

On the whole, I'm in favor of removing cruft from the specs wherever
possible, but I'm starting to question if decommissioning RRtypes
qualifies as low hanging fruit.

If we actually want to decommission these RRtypes, and building off your
starting point, I think the reasonable course of action needs to be this:

 1. Authoritative servers SHOULD warn when loading zones with obsolete
record types

 2. Resolvers MUST never send obsolete RRtypes in a compressed format.

 3. Signers MUST treat rdata as opaque

 4. Obsolete RRtypes MUST never be treated as a known-type with respect
to the wire protocol

 5. Resolvers MAY support legacy compression for received data for
backward compatibility if desired, but SHOULD warn if such information
is received. Compressed records MUST never be re-transmitted.

 6. Validators MAY attempt to to use legacy RR ordering and
de-duplication should validation. If legacy validation is required, the
validator SHOULD warn that it was needed to validate the RRSIGs.

In effect, we're basically saying, these RRtypes are now RFC 3597, with
the caveat that it's OK to try and use them as legacy says but it's not
required.

By specifically allowing resolvers to understand compressed records, but
never send them, it allows for the case that there may be people using
these RRtypes, but sets the standard going forward to treat them as RFC
3597. The special case of allowing compressed versions to be accepted
allows for backwards compatibility and notifying where things still need
to be updated.

Then it's essentially a matter of writing a new RFC that describes how
to handle sun-setting a RRtype, and what RRtypes have been put out to
pasture formally. Everyone can understand uncompressed RRtypes, and by
forcing decompression, and those who want to use these for legacy
RRtypes can.

New resolvers don't need to worry about it, and as resolvers get
upgraded, the special case in 5 goes away. For the small handful of
people actually using these types, life continues as long as their
resolver maintains legacy receiving support. New resolvers can just
treat them as RFC 3597.

Plus we now have a procedure if we want to obsolete any other RRtypes.

Michael

---

From: Dick Franks <[email-masked]>
Date: Mon, 26 Mar 2018 15:36:22 +0100

> in 1997 when WKS was deprecated in 1989 - RFC 1101 and RFC 1123.

Getting rid of extraneous weird logic is the primary objective.

> that an old server objects to.

There are no compressible domain names in WKS.  RFC3597 unknown type
representation
does not change the meaning or otherwise damage the rdata.

Intermediate nameservers unaware of WKS, pass it along as as an unknown
type.

The end-points, if there still are any, are free to continue using WKS by
mutual agreement.

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 26 Mar 2018 16:45:27 +0200

Michael,

while I generally agree with your “let’s write a I-D on how to deprecate old RR Types in general”, I would like to keep this document focused on MB, MG, MR, MINFO.

I’ll kick out WKS into a separate document, and add MAILB, MAILA, MD and MF in.

I would appreciate that in this discussion, instead of saying “RR Types” we should talk about specific RR Types we want to remove from DNS. Saying “removing RR Types” is scary. Saying “removing MB RR Type” is less scary as most people even don’t remember what it was used for.

Cheers,
--
Ondřej Surý
[email-masked]

> On 26 Mar 2018, at 16:22, Michael Casadevall <[email-masked]> wrote:
> 
> 
>

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 26 Mar 2018 16:47:14 +0200

Joe,

do you expect this will be needed for the RR Types I have proposed to be removed? I am specifically trying to not create a generic mechanism to remove any RR Type, just those under MAILA, MAILB umbrella and MINFO.

Ondrej
--
Ondřej Surý
[email-masked]

---

From: Jim Reid <[email-masked]>
Date: Mon, 26 Mar 2018 15:47:55 +0100

> b) the RDATA needs to be understood and lowercased for canonical form when DNSSEC signing; again you need to *implement* this in DNSSEC Validator as it would cause validation failures if you don't

Fair enough Ondřej. Though I suspect the number of servers that sign or validate MAILA records  (or whatever) can be counted on the number of ears on one hand. :-)

FWIW the sort of additional processing I had in mind were things comparable to resolvers chasing CNAMEs or DNAME rewriting.

---

From: Evan Hunt <[email-masked]>
Date: Mon, 26 Mar 2018 14:57:29 +0000

> worry about associated edge cases with the obsolete types.

Thank you, that's what I was trying to say, you said it better.

> these RRtypes dead, the specification specifically allows them to be

But it's always allowed them not to be compressed, too. The trouble
PowerDNS had was because it wasn't expecting compression, but I would
expect the opposite problem (failing because something *didn't* compress)
to be rarer.

>  2. Resolvers MUST never send obsolete RRtypes in a compressed format.

Problem here: If the resolver is treating the record as opaque, then it
can only send it along in whatever format it was received in, so this
requirement doesn't work as written. But I think what you mean is that
even if the resolver is able to parse compressed rdata, it MUST NOT
compress when sending the answer along to its own client. This is
re-stated in point 5, below.

> is received. Compressed records MUST never be re-transmitted.

You use MUSTs where I used SHOULDs, but I think we're both pointing
in the same direction.

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 26 Mar 2018 17:18:29 +0200

Thanks to you both.

I updated the draft with Evan’s text and merged some of Michael’s text to:

Cheers,
--
Ondřej Surý
[email-masked]

> On 26 Mar 2018, at 16:57, Evan Hunt <[email-masked]> wrote:
>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 26 Mar 2018 08:19:29 -0700

Ondřej Surý wrote:
...
> I think that modifying (or removing stuff from) the DNS standard(s)
> MUST NOT be driven by “how simple it is”, but “how useful it is”.
>
> This would just lead into the situation that we would have two
> categories: “oh, that's too simple to remove” and “oh, that’s too
> difficult to remove” and nothing in between.

the dichotomy presented here is false. interoperability is a priority. 
the observations that you aren't using some feature, and that noone you 
know is using that feature, do not support a conclusion that the feature 
is not in use. the internet is bigger than what you can measure.

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Mon, 26 Mar 2018 08:28:11 -0700

> While the special processing was added to RFC 2136 (9 years later)
> isreally beyond my understanding :(.

host requirements was not a DNS document. it removed nothing from the 
DNS. rather, it removed the burden on service responders to list their 
service in WKS, by telling service initiators not to look for it.

-- 
P Vixie

---

From: Michael Casadevall <[email-masked]>
Date: Mon, 26 Mar 2018 11:33:50 -0400

> expect the opposite problem (failing because something *didn't* compress)

Right, it just happens the DNS compression is common. RFC 3597-compliant
resolvers will just take whatever blob they get and kick it along.
Anything with specific support for these types realistically are going
to support the uncompressed variants limiting interop issues.

> re-stated in point 5, below.

Ah, misthink. You got my intent right, but it should be specifically
written as such.

2. Resolvers MUST never generate obsolete RRtypes in a compressed
format. If (in line with below) the resolver receives a record in
compressed form, it MUST be decompressed before being sent to downstream
resolvers as though. Resolvers SHOULD warn that they are unpacking
records in transit.

How's that sound? I'm still somewhat iffy on my understanding of DNSSEC
RRSIG canonical forms, but if I understood the RFCs correctly, the
uncompressed record should match the canonical form the RRSIG validates
against to which in turn is identical to RFC 3597 (aside from WKS,
although RFC 2136 suggests it only applies in the case of DNS update and
not validation)

It specifically states you're allowed to understand, but thou must not
speak. If there's a DNSSEC concern, it should be noted though I don't
think it's a showstopper in and of itself. As previously stated, I very
much doubt these records are commonly if ever signed.

> You use MUSTs where I used SHOULDs, but I think we're both pointing

My thought process here with MUST is we're basically saying that
compressing these types is no longer valid behavior. You can understand
it for backwards compatibility, but if you're compliant with this new
RFC, you're basically asserting you will not generate compressed
responses. It also somewhat aids the process of the special case
disappearing from the internet.

I see no reason why we should allow them unless someone can come up with
an actual usecase (I haven't had a chance to read RFC 2136 in-depth but
it looks like it should work just fine with uncompressed records).
Michael

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 26 Mar 2018 17:37:01 +0200

No, I am claiming that no current Internet standard is using those records and they were already marked as EXPERIMENTAL or OBSOLETE 30 years ago.

Ondřej 

--
Ondřej Surý — ISC

> On 26 Mar 2018, at 17:19, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Ondřej Surý wrote:
> ...
> the dichotomy presented here is false. interoperability is a priority. the observations that you aren't using some feature, and that noone you know is using that feature, do not support a conclusion that the feature is not in use. the internet is bigger than what you can measure.
> 
> -- 
> P Vixie
>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 26 Mar 2018 08:42:54 -0700

Ondřej Surý wrote:
> No, I am claiming that no current Internet standard is using those
> records and they were already marked as EXPERIMENTAL or OBSOLETE 30
> years ago.

the original specification of these RR types is still in effect, 
regardless of whether any other specification currently specifies 
whether to use them.

i don't entirely disagree that the Internet System definition ought to 
be a window, adding new things and deleting old things as it marches 
down the years.

but if you want to deprecate something that somebody somewhere may still 
be using, then it's because the definition for it is still in effect -- 
thus neither experimental nor obsolete as you begin.

the process for doing so is more than reaching consensus on this working 
group. figure out a schedule that includes outreach.

-- 
P Vixie

---

From: Richard Gibson <[email-masked]>
Date: Mon, 26 Mar 2018 14:05:08 -0400

TSIGs cover "A whole and complete DNS message in wire format, before the 
TSIG RR has been added to the additional data section and before the DNS 
Message Header's ARCOUNT field has been incremented to contain the TSIG 
RR" (RFC 2845 section 3.4.1), and would therefore be sensitive to 
decompression.

---

From: Michael Casadevall <[email-masked]>
Date: Mon, 26 Mar 2018 14:33:29 -0400

> RR" (RFC 2845 section 3.4.1), and would therefore be sensitive to

I'll go through the TSIG specification in-depth tomorrow, but is that
actually a problem? More specifically, is there a case where a DNS
server is signing TSIG records when it doesn't control the wire
representation of what's being sent?

If it is, then that's a rather large one.

I brought up RRSIG came to mind because a DNS server may be relaying
information it's unable to change/modify (i.e., a signed zone with a
MAILA record). Since RRSIGs sign the canonical form of the record, the
actual wire representation shouldn't matter if I understand the spec
correctly (i.e. compressed/decompressed); an uncompressed MAILA record
would essentially be equivalent to any other RFC 3597 record.

If I'm completely off base here, let me know. I'll follow up with my
findings, but I'm guessing someone will beat me to it.
Michael

---

From: Dick Franks <[email-masked]>
Date: Mon, 26 Mar 2018 19:44:15 +0100

On 26 March 2018 at 16:42, Paul Vixie <[email-masked]> wrote:

> regardless of whether any other specification currently specifies whether
> to use them.
>
> i don't entirely disagree that the Internet System definition ought to be
> a window, adding new things and deleting old things as it marches down the
> years.
>

This hypothetical somebody somewhere has already had 30 years warning that
these RR's will disappear or be replaced by something better.

Deprecation signals end of life, end of support, end of story.

To speak of outreach in this particular case is a nonsense; your
hypothetical friend has been ignoring the real world for 30 years, and
nothing drops into his mailbox these days.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 26 Mar 2018 14:36:32 -0700

Dick Franks wrote:
>
> On 26 March 2018 at 16:42, Paul Vixie <[email-masked]
> <mailto:[email-masked]>> wrote:
>...
>
> This hypothetical somebody somewhere has already had 30 years warning
> that these RR's will disappear or be replaced by something better.
>

i've had my symbolics 3640 online quite a bit in the last 30 years, and 
it still makes WKS queries, and i have used WKS responses to control it. 
the software still works as well as it was designed to do, but the 
vendor is long out of business. however, read on.

please see down-thread where deprecation turns out to be both 
undesirable for the reasons i've given, and additive to developmental 
complexity since there would be _more_ DNS RFC's to read, and suboptimal 
compared to declaring a core subset of DNS technology as "mandatory to 
implement" and simply leaving WKS (and its hypothetical friends) out of 
that core subset.

-- 
P Vixie

---

From: Dick Franks <[email-masked]>
Date: Tue, 27 Mar 2018 02:36:29 +0100

On 26 March 2018 at 22:36, Paul Vixie <[email-masked]> wrote:

> i've had my symbolics 3640 online quite a bit in the last 30 years, and it
> still makes WKS queries, and i have used WKS responses to control it. the
> software still works as well as it was designed to do, but the vendor is
> long out of business. however, read on.
>

It still works because the end-points understand WKS.  There is no need for
the other nameservers en route to parse the rdata beyond knowing how long
it is.

Ondřej already decided to remove WKS from further consideration.

The focus of this draft is on MB, MG, etc. not the general case of RR
retirement.

please see down-thread where deprecation turns out to be both undesirable
> for the reasons i've given, and additive to developmental complexity since
> there would be _more_ DNS RFC's to read, and suboptimal compared to
> declaring a core subset of DNS technology as "mandatory to implement" and
> simply leaving WKS (and its hypothetical friends) out of that core subset.
>

I fail to see how this changes the number of RFCs to be read.

Nobody has yet defined a core subset; all we have is a camel-load of DNS
technology most of which appears to be "mandatory to implement",
and a mountain of RFCs which are very unlikely to be 100% consistent with
each other.

Expelling one or more items from the "mandatory" set necessarily involves
writing an RFC to add to this mountain, and sometimes obsoleting an old one.

The result is a smaller set of "mandatory to implement" DNS technology.

Repeat this process until nobody can make a good case for further
expulsions;  what remains is the core subset.

Right now, neither you, nor anyone else, can have more than the foggiest
idea what that eventual core subset will look like.

But one thing is certain, if we continue bickering about crap like WKS and
MB, we will make no progress at all.

--
Dick

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 27 Mar 2018 09:27:06 +0200

> On 26 Mar 2018, at 23:36, Paul Vixie <[email-masked]> wrote:
> 
> i've had my symbolics 3640 online quite a bit in the last 30 years, 

This is certainly a fair piece of computer archaelogy, But it is similar to the situation if a museum would insist on providing narrow-wide tracks across the country infrastructure because they have this fine steam engine that still runs. It’s fine to keep your “narrow-wide tracks” in your backyard, but it’s unreasonable to insist that you must be able to run your John Bull coast-to-coast.

> and it still makes WKS queries, and i have used WKS responses to control it. the software still works as well as it was designed to do, but the vendor is long out of business. however, read on.

And it would still be able to issue TYPE7 queries and get answers. There’s neither WKS nor TYPE7 mnemonics on the wire, there’s just \007. I very much doubt that you do changes to the WKS record on a regular basis.

I understand that this whole DNS thing is drive by our “pet projects” needs, but this is a museum piece and not something that should shape the DNS standard in year 2018.

What I am proposing is reasonable - editing WKS records in hexeditor is reasonable tradeoff to getting rid of stuff that was already dead 30 years ago.

Cheers,
Ondrej

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 27 Mar 2018 09:34:07 +0200

> On 27 Mar 2018, at 03:36, Dick Franks <[email-masked]> wrote:
> 
>> please see down-thread where deprecation turns out to be both undesirable for the reasons i've given, and additive to developmental complexity since there would be _more_ DNS RFC's to read, and suboptimal compared to declaring a core subset of DNS technology as "mandatory to implement" and simply leaving WKS (and its hypothetical friends) out of that core subset.
> 
> Nobody has yet defined a core subset; all we have is a camel-load of DNS technology most of which appears to be "mandatory to implement",
> and a mountain of RFCs which are very unlikely to be 100% consistent with each other.
> 
> Expelling one or more items from the "mandatory" set necessarily involves writing an RFC to add to this mountain, and sometimes obsoleting an old one.
> 
> Repeat this process until nobody can make a good case for further expulsions;  what remains is the core subset.

I concur with Dick here. Unless we strip the “core” first, we would be either unable to finish the work because we would endlessly bicker about what to put and what to leave out; or we would end up with even worse superset of what we already have.

Stripping down the existing RFCs one-by-one, then just documenting what we already have without changing the content and producing the one “core” document obsoleting 1034,1035 is reasonable approach that could lead to an actionable work plan.

Ondrej
--
Ondřej Surý
[email-masked]

---

From: Robert Edmonds <[email-masked]>
Date: Wed, 28 Mar 2018 17:43:29 -0400

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

Whatever the long gone original experiments that NULL was intended for
that are alluded to in STD 13, NULL has some present day operational
utility in that it's explicitly defined as carrying as much arbitrary
data as can fit, and NULL RRs can be used with RFC 3597 generic syntax
without squatting on a code point.

It has no presentation format and is not allowed in master zone files so
presumably it is also the easiest RR type to implement.

-- 
Robert Edmonds

---

From: Evan Hunt <[email-masked]>
Date: Wed, 28 Mar 2018 21:58:46 +0000

> presumably it is also the easiest RR type to implement.

I just learned from Geoff Huston a few days ago that his test servers
use NULL RR's when they need to construct large responses.

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 29 Mar 2018 01:06:02 +0000

> On Mar 24, 2018, at 10:57 PM, Ondřej Surý <[email-masked]> wrote:
> 

Or, maybe everyone's recent favorite, RFC 8145:

5.1.  Query Format

   A Key Tag query consists of a standard DNS query of type NULL and of
   class IN [RFC1035].

DW

---

From: william manning <[email-masked]>
Date: Wed, 28 Mar 2018 23:26:45 -0700

concur with Pauls assertions wrt "long tail".  Picking on specific RR types
to remove is a high maintenance method to put the camel on a diet.
Laudable but maybe not worth the efforts needed to clean up the installed
base.  Perhaps these two ideas might be a better way to simplify things.
1) remove additional section processing for any proposed RR types & then
rework existing rr's that require ASP.   2) dynamically loadable rr's types
(harder in resolvers but so worth the flexablity)

ymmv of course.

/Wm

---

From: william manning <[email-masked]>
Date: Wed, 28 Mar 2018 23:30:23 -0700

my mailbox is not filled with crap from spammers, if that is what you
mean.  it's not empty either. :)
if you want to kill off NSAP-PTR, I'd support that.

/Wm

On Mon, Mar 26, 2018 at 11:44 AM, Dick Franks <[email-masked]> wrote:

>> to use them..