http://blog.gmane.org/gmane.ietf.dnsext hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.dnsext/22432 <pre>The IESG has approved the following document: - 'Signaling Cryptographic Algorithm Understanding in DNSSEC' (draft-ietf-dnsext-dnssec-algo-signal-10.txt) as Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal/ Technical Summary The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support. Working Group Summary The DNSEXT WG members reviewed and commented on previous revisions of the document. All substantive comments were reviewed and the document updated accordingly. Most reviewe</pre> The IESG 2013-05-17T21:10:48 http://comments.gmane.org/gmane.ietf.dnsext/22430 <pre>During IESG review some subtle issues were raised with the DNSSEC algorithm signaling draft that resulted in an RFC editor note being added to the document. I'm writing this note to apprise the working group of the changes that were made. My expectation is that the working group will not see any of these changes as substantially changing the document in a way that would influence the outcome of the last call, but they are not merely editorial, so it seemed appropriate to give the working group a shot at them. The complete editor's note is here: http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal/writeup/ The particular change to which I want to draw your attention relate to the question of what it means for a resolver to be a validating resolver. The document as submitted by the working group allowed for the possibility that a validating resolver might not set the DO bit; this then led to an ambiguity in section 5 about the processing of the three new options. The text as submitted </pre> Ted Lemon 2013-05-11T15:25:28 http://comments.gmane.org/gmane.ietf.dnsext/22403 <pre>Dear ietf and dnsext, I apologies for posting this ahead of the wg last call. Over many years at attempting to change the course of the SPF process, this effort appears to have been futile. It seems many even feel the present spfbis document represents current practices. It does not, from the perspective of macros. I have written an I-D that I fully expect SPF proponents will denounce and so I have left that wg alone. Here is a draft written in hopes of placing these concerns into a broader scope-- http://tools.ietf.org/html/draft-otis-ipv6-email-authent-00 Two references in this draft did not carry over in the same manner as in the tcl script? Until remedied, here are the links missing in this i-d: [I-D.otis-spf-dos-exploit] http://tools.ietf.org/html/draft-otis-spf-dos-exploit-01 [v6-BGP-Rpts] http://bgp.potaroo.net/v6/as6447/ SPF can pose serious threats, that when confronted, few solutions are available. I have been able to convince some of the larger providers of this concern, who in retur</pre> Douglas Otis 2013-05-03T19:04:53 http://comments.gmane.org/gmane.ietf.dnsext/22393 <pre>Folk may be interested in the following Open Source project: https://sourceforge.net/projects/omnidiscovery/ The code is not 100% complete but it does support many of the most commonly used DNS RRs right now. The synthesizer generates code to parse/emit DNS RRs from an abstract description file. Here are the first three entries: RRA1"Host address""RFC1035" IPv4Address RRNS2"Authoritative name server" "RFC1035" DomainNSDNAME RRMD3"Mail destination" "RFC1035" DomainMADNAME Obsolete [100+ other RR definitions omitted] This abstract description is then used to produce an API to allow applications to handle the RRs in any language someone cares to write a back end for. The synthesizer is implemented in Goedel which is an open source synthesizer for writing synthesizers. At present the only output language supported is C#. The reason I am doing C# is that there isn't a good library for DNS API support out there right now and that is the language I prefer to work in. Gen</pre> Phillip Hallam-Baker 2013-05-03T14:44:23 http://comments.gmane.org/gmane.ietf.dnsext/22360 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without</pre> johnsonhammond2< at >hushmail.com 2013-04-27T17:06:07 http://comments.gmane.org/gmane.ietf.dnsext/22254 <pre>Hi all Draft for DNS-like OID system has been submitted: https://datatracker.ietf.org/doc/draft-torres-dnsext-oid/ Please comment on it. Do not hesitate to be harsh if needed. Thanks Noel Torres er Envite ------------------------- A: Because it breaks the logical flow of discussion. Q: Why is top posting bad? _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> Noel David Torres Taño 2013-04-24T23:29:56 http://comments.gmane.org/gmane.ietf.dnsext/22250 <pre>The following errata report has been submitted for RFC6891, "Extension Mechanisms for DNS (EDNS(0))". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6891&amp;eid=3604 -------------------------------------- Type: Editorial Reported by: Olafur Gudmundsson &lt;ogud&lt; at &gt;ogud.com&gt; Section: 9.1 Original Text ------------- 9.1. OPT Option Code Allocation Procedure OPT Option Codes are assigned by Expert Review. Assignment of Option Codes should be liberal, but duplicate functionality is to be avoided. Corrected Text -------------- 9.1. DNS EDNS0 Option Code Changes This document modifies the name of the existing registry DNS EDNS0 Options to DNS EDNS0 Option Codes (OPT) and updates the registration procedures to Expert Review. Assignment of Option Codes should be liberal, but duplicate functionality is to be avoided. Notes ----- In the publication process fixing this one minor mistake in clarifying the name of the re</pre> RFC Errata System 2013-04-24T14:26:49 http://comments.gmane.org/gmane.ietf.dnsext/22249 <pre>Hello, Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE: 'IANA is requested to add an annotation to the SPF RRTYPE saying "(OBSOLETE - use TXT)" in the DNS Parameters registry.' Is the annotation in the DNS Parameters registry correct? Regards, S. Moonesamy (as document shepherd) _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> S Moonesamy 2013-04-23T22:03:45 http://comments.gmane.org/gmane.ietf.dnsext/22182 <pre>I've been asked to take this document on as AD sponsored individual submission. http://tools.ietf.org/html/draft-jabley-dnsext-eui48-eui64-rrtypes-02 If there's anyone who has strenuous objections to that, please let me know. joel _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> joel jaeggli 2013-04-14T15:55:52 http://comments.gmane.org/gmane.ietf.dnsext/22170 <pre> The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Signaling Cryptographic Algorithm Understanding in DNSSEC' &lt;draft-ietf-dnsext-dnssec-algo-signal-09.txt&gt; as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf&lt; at &gt;ietf.org mailing lists by 2013-04-03. Exceptionally, comments may be sent to iesg&lt; at &gt;ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support. The file can be obtained via http://</pre> The IESG 2013-03-20T18:27:13 http://comments.gmane.org/gmane.ietf.dnsext/22158 <pre>Hi all I'm Noel Torres, sysadmin from Spain. I have readed in the charter that this WG will be shut down soon. Did I do bad by subscribing? Regards ------------------------- A: Because it breaks the logical flow of discussion. Q: Why is top posting bad? _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> Noel David Torres Taño 2013-03-17T12:58:46 http://comments.gmane.org/gmane.ietf.dnsext/22155 <pre>The IESG has approved the following document: - 'Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status' (draft-ietf-dnsext-dnssec-algo-imp-status-04.txt) as Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact person is Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-imp-status/ Technical Summary The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms that it lacks the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this doc</pre> The IESG 2013-03-14T14:58:54 http://comments.gmane.org/gmane.ietf.dnsext/22152 <pre>The IESG has approved the following document: - 'Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status' (draft-ietf-dnsext-dnssec-algo-imp-status-04.txt) as Best Current Practice This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-imp-status/ Technical Summary The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms that it lacks the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implem</pre> The IESG 2013-03-13T15:05:16 http://comments.gmane.org/gmane.ietf.dnsext/22151 <pre>The IESG has approved the following document: - 'Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status' (draft-ietf-dnsext-dnssec-algo-imp-status-04.txt) as Best Current Practice This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-imp-status/ Technical Summary The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms that it lacks the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implem</pre> The IESG 2013-03-13T15:05:16 http://comments.gmane.org/gmane.ietf.dnsext/22136 <pre>The following errata report has been submitted for RFC5155, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5155&amp;eid=3544 -------------------------------------- Type: Technical Reported by: Andy Newton &lt;andy&lt; at &gt;arin.net&gt; Section: 3.3 Original Text ------------- The Next Hashed Owner Name field is represented as an unpadded sequence of case-insensitive base32 digits, without whitespace. Corrected Text -------------- The Next Hashed Owner Name field is represented as an unpadded sequence of case-insensitive base32hex digits, without whitespace Notes ----- RFC 4648 Section 7 says: 'This encoding may be referred to as "base32hex". This encoding should not be regarded as the same as the "base32" encoding and should not be referred to as only "base32".' There are many spots in RFC 5155 that use the term base32 where base32hex is the appropriate term. Section 3.3 abov</pre> RFC Errata System 2013-03-10T18:16:07 http://comments.gmane.org/gmane.ietf.dnsext/22123 <pre>As mentioned earlier, I would like to use the URI scheme for discovery. But I need a little more information that the current format allows: http://tools.ietf.org/html/draft-faltstrom-uri-06 The URI of the target, enclosed in double-quote characters ('"'). Resolution of the URI is according to the definitions for the Scheme of the URI. The URI is encoded as one or more &lt;character-string&gt; RFC1035 section &lt;http://tools.ietf.org/html/rfc1035#section-3.3&gt; 3.3 &lt;http://tools.ietf.org/html/draft-faltstrom-uri-06#section-3.3&gt; [RFC1035 &lt;http://tools.ietf.org/html/rfc1035&gt;]. It occurred to me that since a URI must not contain a space character, it would be possible to add the optional parameters I would like to add for discovery by simply changing the format of the target field as follows: target = uri [ ' ' parameters] So a domain might be specified as follows: _foo._wk.example.com URI 10 10 URI "http://host1.example.com/" _foo._wk.example.com URI 10 10 URI "http://host2.example.com/ v=2.1" </pre> Phillip Hallam-Baker 2013-02-13T19:08:07 http://comments.gmane.org/gmane.ietf.dnsext/22117 <pre> The following errata report has been submitted for RFC5155, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5155&amp;eid=3479 -------------------------------------- Type: Technical Reported by: Andy Newton &lt;andy&lt; at &gt;arin.net&gt; Section: Apendix A Original Text ------------- The example in Appendix A has an NSEC3 next hashed owner name field with the non-base 32 characters 9, 0, and 1. Corrected Text -------------- The example should be changed so that the field in question is valid base 32. Notes ----- Instructions: ------------- This errata 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 (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5155 (draft-ietf-dnsext-nsec3-13) -----</pre> RFC Errata System 2013-02-07T21:50:59 http://comments.gmane.org/gmane.ietf.dnsext/22102 <pre>Over the years several people have proposed a record that would be used to specify a public suffix. For example: .com PUBLIC .co.uk PUBLIC .ac.uk PUBLIC .net PUBLIC The idea here being to provide a mechanism in the DNS to advertise the fact that a zone is considered to be a public delegation point and that features such as Cookies, JavaScript, CA cert issue, etc. can then avoid security issues that arise from the assumption that the domains A.X.Y and B.X.Y or X.Y are in the same 'zone of trust'. DNS deployment constraints mean that it is not possible for applications to use this information directly as there is no guarantee that the application will have access to the necessary records. So each application would still need to maintain a public suffix list but it would be a public suffix list that can be maintained using an automatic script run as part of the build process rather than a list that is maintained by hand and in the most error prone way imaginable. I do not want to get i</pre> Phillip Hallam-Baker 2013-02-01T16:30:26 http://comments.gmane.org/gmane.ietf.dnsext/22101 <pre>I have a question related to the recent errata for RFC5155 on empty non terminal: http://www.rfc-editor.org/errata_search.php?rfc=5155&amp;eid=3441 What if the empty non terminal is a wildcard? For example, example. ;; zone origin, has SOA, NS, matching NSEC3 etc ;; x.example. ;; empty, covered by opt-out NSEC3 ;; *.x.example. ;; empty and wildcard, covered by opt-out NSEC3 child.*.x.example. IN NS ns.example.com. ;; insecure, no DS, opt-out and query is y.x.example./A. What should be returned in this case? Section 7.2.5 of RFC5155 states: If there is a wildcard match for QNAME, but QTYPE is not present at that name, the response MUST include a closest encloser proof for QNAME and MUST include the NSEC3 RR that matches the wildcard. This combination proves both that QNAME itself does not exist and that a wildcard that matches QNAME does exist. Note that the closest encloser to QNAME MUST be the immediate ancestor of the wildcard RR (if this is not the case, then something has gone w</pre> JINMEI Tatuya / 神明達哉 2013-02-01T04:55:36 http://comments.gmane.org/gmane.ietf.dnsext/22099 <pre>The IESG has approved the following document: - 'Extension Mechanisms for DNS (EDNS(0))' (draft-ietf-dnsext-rfc2671bis-edns0-10.txt) as Internet Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2671bis-edns0/ Technical Summary The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward compatible mechanisms for allowing the protocol to grow. This document updates the EDNS0 specification (RFC 2671) based on feedback from deployment experience in several implementations. It also closes the IANA registry for extended labels created as part of RFC 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain Name System") which depends on</pre> The IESG 2013-01-25T14:07:08 http://comments.gmane.org/gmane.ietf.dnsext/22096 <pre>Greetings again. There are a few DNS application programming interfaces (APIs) available that cover things like DNSSEC and non-address records, but none that have garnered much interest from the application developers who should be their primary audience. To remedy that, I have created a new design for such an API. I did that outside the IETF, of course, given the IETF's general "we don't do APIs" stance and the oft-stated desire to shut down this WG sooner rather than later. Please see http://www.vpnc.org/getdns-api/ for the current API proposal and description of the design principles I used to put it together. I am still seeking input from application developers to say what they would really want to see in an API, and from DNS people to say which parts of the DNS should be exposed in what ways to application developers. At some point in the not-distant-future, I will call the design "finished" and hopefully someone will want to implement it. Please don't discuss the design on the DSNEXT WG mailing list;</pre> Paul Hoffman 2013-01-21T16:08:04 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.dnsext