[DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : BULK DNS Resource Records
Authors : John Woodworth
  Dean Ballew
  Shashwath Bindinganaveli Raghavan
  David C Lawrence
Filename: draft-woodworth-bulk-rr-07.txt
Pages   : 16
Date: 2017-10-30

Abstract:
   The BULK DNS resource record type defines a method of pattern-based
   creation of DNS resource records based on numeric substrings of query
   names.  The intent of BULK is to simplify generic assignments in a
   memory-efficient way that can be easily shared between the primary
   and secondary nameservers for a zone.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-woodworth-bulk-rr-07
https://datatracker.ietf.org/doc/html/draft-woodworth-bulk-rr-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-woodworth-bulk-rr-07


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [DNSOP] Agenda topics for IETF100

[Francis Dupont]

Need a short slot (5 mn) about the revision of TSIG specs just
submitted as draft-dupont-dnsop-rfc2845bis-00.txt

Thanks

francis.dup...@fdupont.fr

PS: there are in fact only a few since IETF99: just the work is in
progress and should one day become a WG item. IMHO today the main
difference is the draft exists so contributions and comments should
be easier...

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

[DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : Serving Stale Data to Improve DNS Resiliency
Authors : David C Lawrence
  Warren Kumari
Filename: draft-ietf-dnsop-serve-stale-00.txt
Pages   : 10
Date: 2017-10-30

Abstract:
   This draft defines a method for recursive resolvers to use stale DNS
   data to avoid outages when authoritative nameservers cannot be
   reached to refresh expired data.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale-00
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-serve-stale-00


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [DNSOP] [Technical Errata Reported] RFC6781 (5174)

[Warren Kumari]

Thanks! Verified.

W

On Mon, Oct 30, 2017 at 2:24 AM, Matthijs Mekking
 wrote:
> Hi,
>
> This errata appears to be valid. In addition, the following text must also
> be corrected, from:
>
>The rest of the zone data has the same signature as the SOA record,
>i.e., an RRSIG created with DNSKEY_K_14.
>
> to:
>
>The rest of the zone data has the same signature as the SOA record,
>i.e., an RRSIG created with DNSKEY_K_15.
>
> Best regards,
>   Matthijs
>
>
> On 29-10-17 13:12, RFC Errata System wrote:
>>
>> The following errata report has been submitted for RFC6781,
>> "DNSSEC Operational Practices, Version 2".
>>
>> --
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata/eid5174
>>
>> --
>> Type: Technical
>> Reported by: Andreas Cudok 
>>
>> Section: Appendix B.
>>
>> Original Text
>> -
>> is reduced to the following representation:
>>
>>  SOA_2005092303
>>  RRSIG_Z_14(SOA_2005092303)
>>  DNSKEY_K_14
>>  DNSKEY_Z_15
>>  RRSIG_K_14(DNSKEY)
>>  RRSIG_Z_15(DNSKEY)
>>
>> Corrected Text
>> --
>> is reduced to the following representation:
>>
>>  SOA_2005092303
>>  RRSIG_Z_14(SOA_2005092303)
>>  DNSKEY_Z_14
>>  DNSKEY_K_15
>>  RRSIG_Z_14(DNSKEY)
>>  RRSIG_K_15(DNSKEY)
>>
>> Notes
>> -
>>
>>
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>>
>> --
>> RFC6781 (draft-ietf-dnsop-rfc4641bis-13)
>> --
>> Title   : DNSSEC Operational Practices, Version 2
>> Publication Date: December 2012
>> Author(s)   : O. Kolkman, W. Mekking, R. Gieben
>> Category: INFORMATIONAL
>> Source  : Domain Name System Operations
>> Area: Operations and Management
>> Stream  : IETF
>> Verifying Party : IESG
>>
>> ___
>> 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

[DNSOP] [Errata Verified] RFC6781 (5174)

[RFC Errata System]

The following errata report has been verified for RFC6781,
"DNSSEC Operational Practices, Version 2". 

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5174

--
Status: Verified
Type: Technical

Reported by: Andreas Cudok 
Date Reported: 2017-10-29
Verified by: Warren Kumari (Ops AD) (IESG)

Section: Appendix B.

Original Text
-
   is reduced to the following representation:

SOA_2005092303
RRSIG_Z_14(SOA_2005092303)
DNSKEY_K_14
DNSKEY_Z_15
RRSIG_K_14(DNSKEY)
RRSIG_Z_15(DNSKEY)

The rest of the zone data has the same signature as the SOA record,
   i.e., an RRSIG created with DNSKEY_K_14.


Corrected Text
--
   is reduced to the following representation:

SOA_2005092303
RRSIG_Z_14(SOA_2005092303)
DNSKEY_Z_14
DNSKEY_K_15
RRSIG_Z_14(DNSKEY)
RRSIG_K_15(DNSKEY)

The rest of the zone data has the same signature as the SOA record,
   i.e., an RRSIG created with DNSKEY_K_15.

Notes
-
Note: K and Z were swapped. 


--
RFC6781 (draft-ietf-dnsop-rfc4641bis-13)
--
Title   : DNSSEC Operational Practices, Version 2
Publication Date: December 2012
Author(s)   : O. Kolkman, W. Mekking, R. Gieben
Category: INFORMATIONAL
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

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

[DNSOP] I-D Action: draft-tale-dnsop-serve-stale-02.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : Serving Stale Data to Improve DNS Resiliency
Authors : David C Lawrence
  Warren Kumari
Filename: draft-tale-dnsop-serve-stale-02.txt
Pages   : 10
Date: 2017-10-30

Abstract:
   This draft defines a method for recursive resolvers to use stale DNS
   data to avoid outages when authoritative nameservers cannot be
   reached to refresh expired data.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-02
https://datatracker.ietf.org/doc/html/draft-tale-dnsop-serve-stale-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-tale-dnsop-serve-stale-02


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[DNSOP] Agenda topics for IETF100

[tjw ietf]

All

Please submit any request for presenting at IETF100 to the chairs.  We'll
be working on a draft agenda in the interim.

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

Re: [DNSOP] draft-huston-kskroll-sentinel - naming format?

[Evan Hunt]

> I see that this draft uses a syntax similar to RFC 8145 Trust Anchor
> Telemetry RFC (which uses _ta-) albeit without the leading
> underscore, i.e. .ta-.
> 
> I'd like to propose instead ._ta.
> 
> This would allow _ta to be registered as a standalone entry in the
> underscore label registry, whilst also avoid the risk of collisions with
> "plain" labels that happen to match ta-
> 
> FWIW, I think in retrospect that RFC 8145 should have taken a similar
> approach too.

IIRC we discussed it, and were concerned that _ta. could be cached as
nonexistent by servers implementing QNAME minimization.

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

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

[DNSOP] draft-huston-kskroll-sentinel - naming format?

[Ray Bellis]

I see that this draft uses a syntax similar to RFC 8145 Trust Anchor
Telemetry RFC (which uses _ta-) albeit without the leading
underscore, i.e. .ta-.

I'd like to propose instead ._ta.

This would allow _ta to be registered as a standalone entry in the
underscore label registry, whilst also avoid the risk of collisions with
"plain" labels that happen to match ta-

FWIW, I think in retrospect that RFC 8145 should have taken a similar
approach too.

Ray


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

Re: [DNSOP] Multiple question drafts?

[Stephane Bortzmeyer]

On Mon, Oct 30, 2017 at 03:33:00PM +,
 Ray Bellis  wrote 
 a message of 24 lines which said:

> Multiple answers:

Also draft-fujiwara-dnsop-additional-answers

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

[DNSOP] Multiple question drafts?

[Ray Bellis]

WG chairs

Could you please let me / the WG know where we stand with the various
drafts describing ways to accommodate multiple questions and/or answers
in a single request?

Multiple questions:

-  draft-bellis-dnsext-multi-qtypes
-  draft-yao-dnsop-accompanying-questions

Multiple answers:

-  draft-vavrusa-dnsop--for-free-00
-  draft-wkumari-dnsop-multiple-responses

thanks,

Ray

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

[DNSOP] draft-fujiwara-dnsop-additional-answers-00.txt

[fujiwara]

Hello,

I submitted another multiple response proposal.

  https://tools.ietf.org/html/draft-fujiwara-dnsop-additional-answers-00

It is similar to draft-wkumari-dnsop-multiple-responses, however, it
proposes authoritative DNS server software developers choose
additional resource records.

# Many implementations (For example, BIND 9 and NSD) add MX mail
# exchange A/ or SRV Target A/ in MX or SRV responses.

And the draft proposes to append NSEC/NSEC3 RR if additional RR type
does not exist. Validating resolvers can generate NODATA response by
RFC 8198.

It also contains comparison of multiple responses proposals in Appendix.

Please read and comment it.

Regards,

--
Kazunori Fujiwara, JPRS 

 Subject: I-D Action: draft-fujiwara-dnsop-additional-answers-00.txt
 From: internet-dra...@ietf.org
 To: 
 Date: Sat, 28 Oct 2017 09:57:24 -0700
 Archived-At: 



A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Returning additional answers in DNS responses
Author  : Kazunori Fujiwara
Filename: draft-fujiwara-dnsop-additional-answers-00.txt
Pages   : 9
Date: 2017-10-28

Abstract:
   This document proposes to document the ability to provide multiple
   answers in single DNS response.  For example, authoritative servers
   may add a NSEC resource record or A/ resource records of the
   query name.  This is especially useful as, in many cases, the entity
   making the request has no a priori knowledge of what other questions
   it will need to ask.  It is already possible (an authoritative server
   MAY already sends what it wants in the additional section).  This
   document does not propose any protocol changes, just explanations of
   an already acceptable practice.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-additional-answers/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-fujiwara-dnsop-additional-answers-00
https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-additional-answers-00


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [DNSOP] New I-D for OCSP over DNS

[Shane Kerr]

Dr. Pala,

Dr. Pala:
> Hello all,
> 
> As suggested by some people from other WGs, I just wanted to cross-post
> this message here since the proposal heavily rely on DNS and can be
> leveraged in many different environments (e.g., Server and Client
> (browsers) authentication, document validation, IoT identities, etc.)
> and we would like to receive feedback from anybody who might be
> interested in the topic.
> 
> *Context. *We are currently working on specifying how to use DNS as a
> transport protocol for revocation information for digital certificates.
> In particular, we are working on how to leverage the distributed nature
> of DNS to efficiently (and possibly at a lower operational costs)
> distribute OCSP (Online Certificate Status Protocol) responses to
> applications/devices/etc.
> 
> *Current Status.* We started this work sometime ago but never really had
> the time to finish it. Now it seems we can focus more on the topic and
> would like to discuss this work in a more public venue. We have recently
> updated the two competing I-D we submitted sometime ago into the latest
> reference I-D that is available here:
> 
>     https://datatracker.ietf.org/doc/draft-pala-odin/
> 
> Please feel free to contact us for any help (you might require or you
> might provide), feedback, etc.

I had a quick look and have a few comments/suggestions.

Some minor points, and then on to major issues

Section 6.3, "Time Validity" might be tricky. Someone reading the
specification may infer that authoritative DNS servers are supposed to
look at the OSCP record and clamp TTL to the expiration of the OCSP
response. While there is some precedence for this (in RRSIG records),
those are limited to cryptography that is for the DNS itself.

My recommendation here is that it be made clear that as an operational
matter that operators ensure that the records are published in a way
that the TTL is low enough that they expire from caches before the OCSP
response expiration.

Section 7.2, "Use of TXT Records" may hit a problem similar to what
happened with the SPF record. In SPF (a mail authentication &
authorization technology), early implementations used TXT records. The
DNS community encouraged a switch to a "real" RRTYPE for this. However,
what ended up happening is that implementations had to support SPF *and*
TXT records. This was extra work and even extra packets on the wire, and
eventually the next SPF revision deprecated the SPF type.

If the OSCPRR is not yet widely deployed, I would suggest at the very
least changing "MAY use TXT records" to "SHOULD NOT use TXT records". If
it is widely deployed, then... ug. ;)

Now on to the big stuff. :)

I think that more work needs to be done explaining why DNS is a more
efficient delivery mechanism than HTTP or some other technology. If the
idea is that resolvers provide "free" caching close to the user then
this may be reasonable. If the idea is that DNS is a simple UDP
protocol, then this may quite possibly backfire when you stick largish
cryptographic blobs into the DNS responses; DNS is probably less
efficient than HTTP then because you'll get UDP responses that tell you
to switch to TCP... instead of starting with TCP in the first place.

Next, I think you may want to consider more security implications in
pressing the DNS infrastructure into service as a critical component of
a PKI infrastructure.

Unlike HTTP, most DNS traffic is not encrypted (there are not even any
drafts proposing a solution in the resolver-to-authoritative server
space). This means that, for example, an attacker who gains access to
DNS logs may not be able to infer clients who have not updated their
revocation lists in a way that was not previously possible.

None of this means that the proposal is a bad idea, just that more text
would make it more convincing.

Cheers,

--
Shane

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