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

2018-05-03 Thread Ondřej Surý 
> 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) 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
> 
> 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. :-)

On a sunny day, while casually strolling the BIND source code, I found this:

case dns_rdatatype_maila:
case dns_rdatatype_mailb:
query_error(client, DNS_R_NOTIMP, __LINE__);
return;

So, again, making this _official_ and actually obsolete types that even BIND 
doesn’t implement, somehow still makes sense to me.

Ondrej
--
Ondřej Surý
ond...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-28 Thread william manning 
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:
>>
>>> 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.
>
>
>
> 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.
>
>
>
>
>> --
>> P Vixie
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-28 Thread william manning 
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

On Mon, Mar 26, 2018 at 2:36 PM, Paul Vixie  wrote:

>
>
> Dick Franks wrote:
>
>>
>> On 26 March 2018 at 16:42, Paul Vixie > > 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.
>>
>> 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.
>>
>
> 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
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-28 Thread Wessels, Duane 

> 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 and of
   class IN [RFC1035].


DW

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-28 Thread Evan Hunt 
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, 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.

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.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-28 Thread Robert Edmonds 
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 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-27 Thread Ondřej Surý 
> 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 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.

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ý
ond...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-27 Thread Ondřej Surý 
> 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 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-26 Thread Dick Franks 
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. 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-26 Thread Paul Vixie 



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.

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.


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-26 Thread Dick Franks 
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,
> 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.



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.




> --
> P Vixie
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-26 Thread Michael Casadevall 


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.1), and would therefore be sensitive to
> decompression.
> 

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-26 Thread Richard Gibson 
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.



On 03/26/2018 11:33 AM, Michael Casadevall wrote:

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.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-26 Thread Paul Vixie 



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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-26 Thread Ondřej Surý 
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 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
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-26 Thread Michael Casadevall 


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 them to be
>> compressed.
> 
> 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.
> 

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.

>>  1. Authoritative servers SHOULD warn when loading zones with obsolete
>> record types
>>
>>  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.
> 

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.

>>  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.
> 
> You use MUSTs where I used SHOULDs, but I think we're both pointing
> in the same direction.
> 

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-26 Thread Paul Vixie 



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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-26 Thread Ondřej Surý 
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: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 associated edge cases with the obsolete types.
> 
> Thank you, that's what I was trying to say, you said it better.
> 
>>> 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 them to be
>> compressed.
> 
> 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.
> 
>> 1. Authoritative servers SHOULD warn when loading zones with obsolete
>> record types
>> 
>> 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.
> 
>> 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.
> 
> You use MUSTs where I used SHOULDs, but I think we're both pointing
> in the same direction.
> 
> -- 
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-26 Thread Evan Hunt 
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 associated edge cases with the obsolete types.

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

> > 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 them to be
> compressed.

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.

>  1. Authoritative servers SHOULD warn when loading zones with obsolete
> record types
> 
>  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.

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

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

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-26 Thread Jim Reid 
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 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

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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-26 Thread Ondřej Surý 
> 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 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.

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ý
ond...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-26 Thread Ondřej Surý 
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ý
ond...@isc.org

> On 26 Mar 2018, at 16:22, Michael Casadevall  wrote:
> 
> 
> 
> 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 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.
> 
>> 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.
>> 
> 
> 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
> 
>> 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
>> 
> 
> 
> 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.
> 
> The

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

2018-03-26 Thread Michael Casadevall 


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

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

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

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


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinf

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

2018-03-26 Thread Evan Hunt 
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

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-26 Thread Ondřej Surý 
> 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 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"

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

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ý
ond...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-26 Thread Ondřej Surý 
> 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 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ý
ond...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-26 Thread Evan Hunt 
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 compression correctly.

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.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-25 Thread Paul Hoffman 

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


Fully agree. I would hope that such guidance gets into the draft before 
it moves forwards.


These RR types have text representations and wire format 
representations,

which from a complexity standpoint seem quite harmless to implement.


Yes.


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.


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


I don't see how the IETF can mandate that they be removed, nor am I 
sure

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-24 Thread Ondřej Surý 
> 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 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.

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.

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

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

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

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

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

Ack.

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

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

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

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

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

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ý
ond...@isc.org


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-24 Thread Ondřej Surý 
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 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  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  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  wrote:
> 
> On Sat, Mar 24, 2018 at 02:58:55PM +, 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  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 impac

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

2018-03-24 Thread Ondřej Surý 
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 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
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-24 Thread Mukund Sivaraman 
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" 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.

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

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 as

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

2018-03-24 Thread Ondřej Surý 
> 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ý
ond...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-03-23 Thread Martin Hoffmann 
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-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 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop