> On 26 Mar 2018, at 16:47, Jim Reid wrote:
>
> On 24 Mar 2018, at 20:20, Ondřej Surý wrote:
>>
>>> 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) compress
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 wrote:
>
> On 26 March 2018 at 16:42, Paul Vixie wrote:
>
>>
>>
>> Ondřej Surý wrote:
>>
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
> On Mar 24, 2018, at 10:57 PM, Ondřej Surý wrote:
>
> It’s interesting that there’s some NULL RR Type usage in your zones, I
> suppose that some experiments.
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 a
On Wed, Mar 28, 2018 at 05:43:29PM -0400, Robert Edmonds wrote:
> 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,
Ondřej Surý wrote:
> 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
> On 27 Mar 2018, at 03:36, Dick Franks 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
> On 26 Mar 2018, at 23:36, Paul Vixie 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 infrastru
On 26 March 2018 at 22:36, Paul Vixie 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.
Dick Franks wrote:
On 26 March 2018 at 16:42, Paul Vixie mailto:p...@redbarn.org>> wrote:
...
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
On 26 March 2018 at 16:42, Paul Vixie wrote:
>
>
> 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
On 03/26/2018 02:05 PM, Richard Gibson wrote:
> 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
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
decompressi
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 specif
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 wrote:
>
>
>
> Ondřej Surý wrote:
> ...
>> I think that modifying (or removin
On 03/26/2018 10:57 AM, Evan Hunt wrote:
>>> 2. responders SHOULD NOT compress rdata when rendering obsolete/deprecated
>>>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 t
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
difficul
Thanks to you both.
I updated the draft with Evan’s text and merged some of Michael’s text to:
https://github.com/oerdnj/draft-sury-dnsop-deprecate-obsolete-resource-records
Cheers,
--
Ondřej Surý
ond...@isc.org
> On 26 Mar 2018, at 16:57, Evan Hunt wrote:
>
> On Mon, Mar 26, 2018 at 10:22:30
On Mon, Mar 26, 2018 at 10:22:30AM -0400, Michael Casadevall wrote:
> 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 as
On 24 Mar 2018, at 20:20, Ondřej Surý wrote:
>
>> 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 ca
> 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 TYPE representation,
> and back a
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 discussio
On 03/26/2018 08:45 AM, Evan Hunt wrote:
> 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
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 i
> On 25 Mar 2018, at 15:19, Paul Hoffman wrote:
>
>> 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 inte
> On 25 Mar 2018, at 17:27, Paul Wouters wrote:
>
> And I don't see much point in obsoleting simple defines and logging
> unknown RRtypes.
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 jus
On Sun, Mar 25, 2018 at 02:19:56PM +0100, Paul Hoffman 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 compressi
On 25 Mar 2018, at 9:05, Evan Hunt wrote:
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 impleme
> On 24 Mar 2018, at 22:55, Mukund Sivaraman wrote:
>
> Hi Ondrej
>
> On Sat, Mar 24, 2018 at 09:20:06PM +0100, Ondřej Surý wrote:
>>> 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
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 wrote:
>
> Obsoleted RRtypes shouldn’t overload the camel enough to matter. It might be
> a different story if one of those zombie RRtypes req
Thanks Dick, this is very helpful suggestion and I’ll use it.
Ondrej
--
Ondřej Surý
ond...@isc.org
> On 24 Mar 2018, at 00:06, Dick Franks wrote:
>
>
> On 23 March 2018 at 12:11, Ondřej Surý wrote:
>
> this is a first attempt to start reducing the load on DNS Implementors and
> actually rem
Hi Ondrej
On Sat, Mar 24, 2018 at 09:20:06PM +0100, Ondřej Surý wrote:
> > 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*:
In the case of RR types, "additional processing
> 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
Ondřej Surý 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-kno
34 matches
Mail list logo
