Re: [DNSOP] I-D Action: draft-wkumari-dnsop-alt-tld-00.txt
On Thu, Feb 13, 2014 at 10:58:38AM -0500, Andrew Sullivan a...@anvilwalrusden.com wrote a message of 18 lines which said: - why not just register a URN namespace and use it as they see fit? Why didn't they do that in the first place? Some did. For instance, the magnet people. (Although they apparently did not register the URI scheme they are using...) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-as112-dname-01.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 : AS112 Redirection using DNAME Authors : Joe Abley Brian Dickson Warren Kumari George Michaelson Filename: draft-ietf-dnsop-as112-dname-01.txt Pages : 21 Date: 2014-02-14 Abstract: Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites. Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called reverse lookups) corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site. It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it. The AS112 project does not accommodate the addition and removal of DNS zones elegantly. Since additional zones of definitively local significance are known to exist, this presents a problem. This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-dname/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsop-as112-dname-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-as112-dname-01 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] AS112 bits and pieces
Hi all, We've just submitted draft-ietf-dnsop-as112-dname-01 draft-jabley-dnsop-rfc6304bis-00 which together specify an approach to extend the current AS112 project to be able to sink queries from arbitrary zones, whilst still supporting existing AS112 semantics. We hope to present a brief overview of the approach in London. Reactions and reviews of the two documents would be most welcome! Thanks, Joe Begin forwarded message: From: internet-dra...@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-as112-dname-01.txt Date: 14 February 2014 at 08:46:10 EST To: i-d-annou...@ietf.org Cc: dnsop@ietf.org 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 : AS112 Redirection using DNAME Authors : Joe Abley Brian Dickson Warren Kumari George Michaelson Filename: draft-ietf-dnsop-as112-dname-01.txt Pages : 21 Date: 2014-02-14 Abstract: Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites. Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called reverse lookups) corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site. It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it. The AS112 project does not accommodate the addition and removal of DNS zones elegantly. Since additional zones of definitively local significance are known to exist, this presents a problem. This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-dname/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsop-as112-dname-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-as112-dname-01 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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 bits and pieces
Joe Abley jab...@hopcount.ca wrote: Reactions and reviews of the two documents would be most welcome! The as112-dname draft still does not mention the glibc DNAME logging bug. https://www.ietf.org/mail-archive/web/dnsop/current/msg10638.html Typo: flexibl Apart from that, looks OK :-) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 bits and pieces
On 2014-02-14, at 16:02, Tony Finch d...@dotat.at wrote: Joe Abley jab...@hopcount.ca wrote: Reactions and reviews of the two documents would be most welcome! The as112-dname draft still does not mention the glibc DNAME logging bug. Oops, sorry for missing that, and thanks for the reminder. In other news, you may have noticed that I just posted a -02, hot on the heels of the -01. I received some useful advice regarding the IANA Considerations section, and felt that it was worth making changes sooner rather than later. Thanks for the review of -01! Joe signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 bits and pieces
On Fri, 14 Feb 2014, Tony Finch wrote: Joe Abley jab...@hopcount.ca wrote: Reactions and reviews of the two documents would be most welcome! The as112-dname draft still does not mention the glibc DNAME logging bug. Which Linux distro, or a set of Linux distros? Some seaches yield various bug reports related to DNAME over the last few years in a couple of distros. https://www.ietf.org/mail-archive/web/dnsop/current/msg10638.html Typo: flexibl Apart from that, looks OK :-) +1 Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop wfms ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] CGA-TSIG - new version
Thanks for the information you've provided, I improved the document according to comments and found out that the report also has a few problems which is due to the fact that it misinterpreted the of CGA-TSIG document. Here I explain the problems or the reasons of choices: - CGA-TSIG cannot use MAC as a signature field. The purpose was that to have all the CGA data in one section instead of trying to find them in different sections of TSIG. - sizes of length encoding: It is one byte. It is enough for any key sizes. If you also check the checksum field in the packets, you will find out that it is only 8 bits or one byte. In the emails I explained to you that it is the multiple of 8. In no RFC you can find out that the value is the length of data in bits. It is always the length of data in bytes. But how you showed in your report is that you consider the number of bits and not bytes so you had the following example 2048/8=256 (now you only converted the number of bits to bytes) so you needed to divide it by another 8 that is 256/8=32 and this is the value you set to length. If you even consider the key size 7680, then the length will be only 120. nd - old signature only contains time signed. The reason is to avoid increasing the packet length I appreciate further comments and would like more people review it so that we can go ahead with this document. Thanks, Hosnieh A new version of I-D, draft-rafiee-intarea-cga-tsig-07.txt has been successfully submitted by Hosnieh Rafiee and posted to the IETF repository. Name: draft-rafiee-intarea-cga-tsig Revision: 07 Title: Secure DNS Authentication using CGA/SSAS Algorithm in IPv6 Document date: 2014-02-15 Group: Individual Submission Pages: 26 URL: http://www.ietf.org/internet-drafts/draft-rafiee-intarea-cga-tsig-07.txt Status: https://datatracker.ietf.org/doc/draft-rafiee-intarea-cga-tsig/ Htmlized: http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-07 Diff: http://www.ietf.org/rfcdiff?url2=draft-rafiee-intarea-cga-tsig-07 Abstract: This document describes a new mechanism that can be used to reduce the need for human intervention during DNS authentication and secure DNS authentication in various scenarios such as the DNS authentication of resolvers to stub resolvers, authentication during zone transfers, authentication of root DNS servers to recursive DNS servers, and authentication during the FQDN (RFC 4703) update. Especially in the last scenario, i.e., FQDN, if the node uses the Neighbor Discovery Protocol (NDP) (RFC 4861, RFC 4862), unlike the Dynamic Host Configuration Protocol (DHCP) (RFC 3315), the node has no way of updating his FQDN records on the DNS and has no means for a secure authentication with the DNS server. While this is a major problem in NDP-enabled networks, this is a minor problem in DHCPv6. This is because the DHCP server updates the FQDN records on behalf of the nodes on the network. This document also introduces a possible algorithm for DNS data confidentiality. -Original Message- From: dnsext [mailto:dnsext-boun...@ietf.org] On Behalf Of Marc Buijsman Sent: Thursday, January 16, 2014 3:45 PM To: dns...@ietf.org Cc: Jeroen van der Ham Subject: [dnsext] CGA-TSIG research report Dear working group members, For my master's thesis I have performed an investigation at NLnet Labs on CGA-TSIG as a solution to the last mile problem of DNS. The version of the CGA-TSIG proposal that I reviewed is the current latest version at http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-06. During the course of my research I have already had some contact with Ms. Rafiee. In order to do a verification of the CGA-TSIG proposal I have created a proof of concept implementation in NLnet Labs' ldns library. Since the scope of the project was limited to the last mile problem it only includes the code required for this purpose, but the implementation could easily be extended to support other applications (like zone transfers). I have found that CGA-TSIG has potential to be an adequate solution to the last mile problem on IPv6 networks, although some future research is needed with regard to bootstrapping the authentication. As a result, I would hereby like to refer you to my report which can be found at http://www.nlnetlabs.nl/downloads/publications/report-rp2-buijsman.pdf. I have outlined my results in section 4.2 which contains suggestions on how I believe the CGA-TSIG draft could be clarified and otherwise improved. I hope my suggestions will be adopted in the next version of the draft. The PoC code can be found in the online Git repository of NLnet Labs at http://git.nlnetlabs.nl/ldns/?h=cga-tsig. I hope my work will be helpful in standardising CGA-TSIG. Yours sincerely, Marc Buijsman ___ dnsext mailing list dns...@ietf.org
[DNSOP] I-D Action: draft-ietf-dnsop-resolver-priming-04.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 : Initializing a DNS Resolver with Priming Queries Authors : Peter Koch Matt Larson Filename: draft-ietf-dnsop-resolver-priming-04.txt Pages : 9 Date: 2014-02-14 Abstract: This document describes the initial queries a DNS resolver is supposed to emit to initialize its cache with a current NS RRSet for the root zone as well as the necessary address information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-resolver-priming-04 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] draft-hzhwm-start-tls-for-dns-00: Starting TLS over DNS
We recently posted draft-hzhwm-start-tls-for-dns-00 (Starting TLS over DNS) to explore one proposal to add standard TLS over standard DNS to improve privacy. http://tools.ietf.org/html/draft-hzhwm-start-tls-for-dns-00 This topic may be of interest to DNSOP and PERPASS. Some of the authors will be at the London IETF and can discuss it at the DNS privacy BOF if there is interest. An obvious concern about combining DNS and TLS is the performance implications, both for client latency and server state. The above i-d focuses only on the protocol parts, but we have a separate technical report at ftp://ftp.isi.edu/isi-pubs/tr-688.pdf that evaluates these questions. We would love feedback on either document. thanks -Zi Hu ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hzhwm-start-tls-for-dns-00: Starting TLS over DNS
Zi Hu wrote: We recently posted draft-hzhwm-start-tls-for-dns-00 (Starting TLS over DNS) to explore one proposal to add standard TLS over standard DNS to improve privacy. http://tools.ietf.org/html/draft-hzhwm-start-tls-for-dns-00 This topic may be of interest to DNSOP and PERPASS. Some of the authors will be at the London IETF and can discuss it at the DNS privacy BOF if there is interest. ... this is good work. i recommend it be adopted by the working group, and i will act as a reviewer. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
