okTurtles | 24 Apr 23:53 2014

DNSChain 0.1.0 adds DANE/TLSA support for blockchain + canonical DNS

Hi list!

Just published this to NPM and thought it might interest this list.

DNSChain is a DNS + HTTP(S) + Blockchain-proxy hybrid server designed to serve as a decentralized and distributed secure replacement for Certificate Authorities and X.509 PKI.

It's also designed to act as a secure public key distribution system for both websites and identity systems.

Today, with the help of various contributors, we released version 0.1.0:

  • New Features:
    • DANE/TLSA support for BOTH canonical DNS and blockchain DNS!
    • Added NO_OLD_DNS option for oldDNSMethod (refuses all non-blockchain queries)
  • Improvements:
    • Redesigned dns.coffee and improved its structure
    • Accurate ttl values now returned for namecoin DNS queries based on expires_in field
    • Updated contributors, code and config examples in README.md
    • Improved EDNS support
    • Improved handling of ANY queries
    • Updated dependencies to latest versions
    • native-dns is now fetched from the dnschain branch of our fork.
    • Comments added all over the place (to native-dns & related projects also!)
    • Many other code improvements both to DNSChain and the NodeJS native-dns module
    • Some performance improvements
  • Fixes:
    • Fixed broken grunt example
    • Fixed some uncaught exceptions (issues #1 and #2)
    • Fixed broken NAPTR support
  • Changes:
    • DNSChain license is now MPL-2.0 (applies to version 0.1.0 onward)
    • Default logging level is now info

It's compatible with most UNIX-like systems (including OS X) and can be installed via the NPM package manager or manually via Git.

Free public servers (including ones that support DNSCrypt), along with instructions for installing and running DNSChain, is available on its GitHub page:


Cheers,
Greg Slepak

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Dan Wing | 23 Apr 15:47 2014

DNS over DTLS (DNSoD)

For discussion.

   DNS queries and responses are visible to network elements on the path
   between the DNS client and its server.  These queries and responses
   can contain privacy-sensitive information which is valuable to
   protect.  An active attacker can send bogus responses causing
   misdirection of the subsequent connection.

   To counter passive listening and active attacks, this document
   proposes the use of Datagram Transport Layer Security (DTLS) for DNS,
   to protect against passive listeners and certain active attacks.  As
   DNS needs to remain fast, this proposal also discusses mechanisms to
   reduce DTLS round trips and reduce DTLS handshake size.  The proposed
   mechanism runs over the default DNS port and can also run over an
   alternate port.

http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls

-d

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Andrew Sullivan | 21 Apr 19:59 2014

draft-ietf-dnsop-respsize-15

Dear colleagues,

I read draft-ietf-dnsop-respsize-15.  I have a few comments.  These
are primarily editorial or even nits.  By and large, I think this
draft is fine and ready to go and we should Just Publish It.  We're
supposed to be an operations WG, and I don't think every bit of advice
needs to be absolutely perfect before we send it, so long as we are
sure we are offering good advice.  Note that I have _not_ checked the
arithmetic in the document.  I did once before some time ago, and it
was right then.

I think the expansion for DO is "DNSSEC OK" and the reference likely
should be RFC 3225.

RRset (or RRSet) should refer to 2181.  1035 actually didn't define
this.  There is a definition of RRSet in 2181 and RRset in 2136, but I
guess 2181 is preferable since it was an explicit clarification of DNS
protocols.

   The EDNS protocol extension starting with version 0 permits larger
   responses by mutual agreement of the initiator and responder (see
   Section 4.3 and Section 6.2 of [RFC6891]), and it is recommended to
   support EDNS.  

I read that as having an antecedent for "it" of "the EDNS protocol
extension", which is clearly not what is meant.  Perhaps

   The EDNS protocol extension starting with version 0 permits larger
   responses by mutual agreement of the initiator and responder (see
   Section 4.3 and Section 6.2 of [RFC6891]).  For practical reasons,
   DNS servers and resolvers are recommended to support EDNS.

The most recent measurements in the document are from 2012.  Is there
anything more recent?  Does it matter?

   Even in scenarios where EDNS support in initiators and responders can
   be assumed, e.g. in the case of messages exchanged using DNSSEC, or
   at some future time where EDNS deployment can be considered
   ubiquitous, there will still be cases when MTU limitations or IP
   fragmentation/reassembly problems in firewalls and other middleboxes
   will cause EDNS failures which lead to non-extended DNS retries.  

That sentence is kind of hard to follow.  Perhaps

   Even in scenarios where EDNS support in initiators and responders
   can be assumed (e.g. in the case of messages exchanged using
   DNSSEC, or at some future time where EDNS deployment can be
   considered ubiquitous), there will still be cases when MTU
   limitations or IP fragmentation/reassembly problems in firewalls
   and other middleboxes will cause EDNS failures; such cases will
   lead to non-extended DNS retries.

I don't understand this sentence:

   Anycast [RFC3258] [RFC4786] is a useful technique for improving
   performance and below the zone cut being described by a delegation is
   responses.

The paragraph

   We assume a medium query name size of 64 since that is the typical
   size seen in trace data at the time of this writing.  If
   Internationalized Domain Name (IDN) or any other technology that
   results in larger query names be deployed significantly in advance of
   EDNS, then new measurements and new estimates will have to be made.

suggests that re-measurement is necessary in the face of IDNA.  Does
this mean it's time to do that measurement, since in fact we have a
number of IDNA TLDs now?

Best regards,

A

--

-- 
Andrew Sullivan
ajs <at> anvilwalrusden.com

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

internet-drafts | 17 Apr 19:11 2014
Picon

I-D Action: draft-ietf-dnsop-delegation-trust-maintainance-11.txt


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 Working Group of the IETF.

        Title           : Automating DNSSEC Delegation Trust Maintenance
        Authors         : Warren Kumari
                          Olafur Gudmundsson
                          George Barwood
	Filename        : draft-ietf-dnsop-delegation-trust-maintainance-11.txt
	Pages           : 20
	Date            : 2014-04-17

Abstract:
   This document describes a method to allow DNS operators to more
   easily update DNSSEC Key Signing Keys using the DNS as communication
   channel.  The technique described is aimed at delegations in which it
   is currently hard to move information from the child to parent.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-delegation-trust-maintainance-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-delegation-trust-maintainance-11

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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Tim Wicinski | 17 Apr 00:58 2014
Picon

Final shepherding comments for draft-ietf-dnsop-delegation-trust-maintainance-10


https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

All

Please take a look at version -10 of this draft. I believe that the 
authors have addressed all the issues that were raised during the very 
comment period.

I believe that draft-ietf-dnsop-delegation-trust-maintainance-10 has 
reach working group consensus.  I urge folks to give it one last look 
and if there is anything you wish to raise, please raise directly, 
otherwise silence is agreement.

I want to thank all the individuals who contributed comments and feedback.

tim

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

internet-drafts | 16 Apr 18:32 2014
Picon

I-D Action: draft-ietf-dnsop-delegation-trust-maintainance-10.txt


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 Working Group of the IETF.

        Title           : Automating DNSSEC Delegation Trust Maintenance
        Authors         : Warren Kumari
                          Olafur Gudmundsson
                          George Barwood
	Filename        : draft-ietf-dnsop-delegation-trust-maintainance-10.txt
	Pages           : 20
	Date            : 2014-04-16

Abstract:
   This document describes a method to allow DNS operators to more
   easily update DNSSEC Key Signing Keys using the DNS as communication
   channel.  This document does not address the initial configuration of
   trust anchors for a domain.  The technique described is aimed at
   delegations in which it is currently hard to move information from
   the child to parent.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-delegation-trust-maintainance-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-delegation-trust-maintainance-10

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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

internet-drafts | 16 Apr 14:03 2014
Picon

I-D Action: draft-ietf-dnsop-delegation-trust-maintainance-09.txt


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 Working Group of the IETF.

        Title           : Automating DNSSEC Delegation Trust Maintenance
        Authors         : Warren Kumari
                          Olafur Gudmundsson
                          George Barwood
	Filename        : draft-ietf-dnsop-delegation-trust-maintainance-09.txt
	Pages           : 20
	Date            : 2014-04-16

Abstract:
   This document describes a method to allow DNS operators to more
   easily update DNSSEC Key Signing Keys using the DNS as communication
   channel.  This document does not address the initial configuration of
   trust anchors for a domain.  The technique described is aimed at
   delegations in which it is currently hard to move information from
   the child to parent.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-delegation-trust-maintainance-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-delegation-trust-maintainance-09

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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

internet-drafts | 15 Apr 22:28 2014
Picon

I-D Action: draft-ietf-dnsop-delegation-trust-maintainance-08.txt


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 Working Group of the IETF.

        Title           : Automating DNSSEC Delegation Trust Maintenance
        Authors         : Warren Kumari
                          Olafur Gudmundsson
                          George Barwood
	Filename        : draft-ietf-dnsop-delegation-trust-maintainance-08.txt
	Pages           : 20
	Date            : 2014-04-15

Abstract:
   This document describes a method to allow DNS operators to more
   easily update DNSSEC Key Signing Keys using the DNS as communication
   channel.  This document does not address the initial configuration of
   trust anchors for a domain.  The technique described is aimed at
   delegations in which it is currently hard to move information from
   the child to parent.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-delegation-trust-maintainance-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-delegation-trust-maintainance-08

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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Mark Andrews | 15 Apr 07:57 2014

EDNS version 1


	http://www.ietf.org/id/draft-andrews-edns1-00.txt

--

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: marka <at> isc.org

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

internet-drafts | 14 Apr 22:44 2014
Picon

I-D Action: draft-ietf-dnsop-delegation-trust-maintainance-07.txt


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 Working Group of the IETF.

        Title           : Automating DNSSEC Delegation Trust Maintenance
        Authors         : Warren Kumari
                          Olafur Gudmundsson
                          George Barwood
	Filename        : draft-ietf-dnsop-delegation-trust-maintainance-07.txt
	Pages           : 20
	Date            : 2014-04-14

Abstract:
   This document describes a method to allow DNS operators to more
   easily update DNSSEC Key Signing Keys using the DNS as communication
   channel.  This document does not address the initial configuration of
   trust anchors for a domain.  The technique described is aimed at
   delegations in which it is currently hard to move information from
   the child to parent.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-delegation-trust-maintainance-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-delegation-trust-maintainance-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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Daniel Migault | 14 Apr 21:41 2014
Picon

draft-mglt-dnsop-search-list-processing-00.txt

Hi folks,

Please find draft-mglt-dnsop-search-list-processing-00.txt [1]  This draft comes in the context of generic TLD with possible naming collision. In order to keep naming resolution stable and reliable, it describes 1) how resolver should generate their search list, 2) how resolver should  distinguish a name resolution that needs to be associated with a search list and 3) how a resolver should perform a resolution involving search list.

Feel free to comment/review.

BR,
Daniel

[1] http://tools.ietf.org/html/draft-mglt-dnsop-search-list-processing-00

--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Gmane