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 reviewers feel that the proposed extensions would be harmless to the protocol and would be useful for measuring cryptographic algorithm implementation uptake in clients. A minority of the reviewers questioned the need for such signalling. No reviewers flagged the existence of the proposed EDNS0 extension create interoperability or deployment problems. Document Quality The document does not change any protocol or change client or server processing in any significant way, but proposes a new option to EDNS(0) to aid authoritative DNS zone administrators to measure cryptograpic algorithm code in clients. Personnel Patrik F_______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </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 by the working group said that the server doesn't process the options if the DO bit isn't set. The question was raised: what if a validating resolver doesn't set the DO bit for a particular query? Don't we still care, in principle, what algorithms it supports? The clarifying change is the change to section 3.1.1: a validating stub resolver is now defined for the purposes of the document as one that sets the DO bit. The actual piece of software running on the host may sometimes set the DO bit and sometimes not, but we only _treat_ it as a validating resolver if it does. If this sounds like an interesting point to you, please check out the editor's note and see how it affects the draft. If we don't hear any substantive objection by midweek, I will release the document for publication with the editor's note as is. There are a number of editorial changes in the editor's note as well; the changes that pertain to this question are specifically those that address 3.1.1 and 3.2.1. _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </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 returned offered assurances the macro extensions in their SPF libraries are removed and in doing so have not seen any problems. This is a serious effort at addressing a security concern, please read this draft from that perspective. Regards, Douglas Otis _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </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. Generating C, Objective C or Java would be fairly straightforward. I don't plan to support anything beyond posibly doing C. The code has been tested on Windows, OSX and Linux (under Mono). It works the same on all platforms to the extent that it works. Writing support for DNS RR types is pretty much a template filling operation. If someone wanted to they could use Goedel to fill in the templates that BIND has in its code. As you will see above, the obsolete MD RR has a description but it is marked as obsolete. This allows the code generator to be used to generate a 'fat' API for use implementing a tool like digg and a thin API that only supports the exact calls required for some embedded device. The synth could even be used to generate a HTML or Windows Forms interface for managing DNS RRs. Working this way does not actually save a lot of time on a project like this but it does improve accuracy a great deal and thus reduces maintenance. Using the synth effectively reduces the number of code paths at issue. So if you can get the code to work at all and pass a modest number of test cases it is very likely correct. Adding extra RR types takes 5 mins. </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 any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </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 registry fell through the cracks, the consequence of this is that IANA needs this errata to clarify the registry name. 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. -------------------------------------- RFC6891 (draft-ietf-dnsext-rfc2671bis-edns0-10) -------------------------------------- Title : Extension Mechanisms for DNS (EDNS(0)) Publication Date : April 2013 Author(s) : J. Damas, M. Graff, P. Vixie Category : INTERNET STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </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://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </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 document assigns one. The document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933. Working Group Summary The intended effect of this draft was originally captured in draft-ietf-dnsext-dnssec-registry-fixes-08, which made a novel and controversial use of the IANA registry. That approach was too controversial, and so the WG split the document into two parts. This draft is one of them. The present approach was far less controversial than the previous one, and nobody has raised any objection to the current text. Document Quality The draft does not specify a protocol of any kind, but it does make a recommendation in favour of some algorithms that are so far not widely deployed. The discussion of dnssec-registry-fixes led to the approach instantiated in this draft. Personnel Andrew Sullivan is the Document Shepherd, and Ralph Droms is the Responsible Area Director. RFC Editor Note Please make the following two changes: In section 2.2: OLD: 2.2. Algorithm Implementation Status Assignment Rationale The status of RSASHA1-NSEC3-SHA1 is set to Recommended to Implement as many deployments use NSEC3. The status of RSA/SHA-256 and RSA/ NEW: 2.2. Algorithm Implementation Status Assignment Rationale RSASHA1 has an implementation status of Must Implement, consistent with [RFC4034]. RSAMD5 has an implementation status of Must Not Implement because of known weaknesses in MD5. The status of RSASHA1-NSEC3-SHA1 is set to Recommended to Implement as many deployments use NSEC3. The status of RSA/SHA-256 and RSA/ END In the IANA considerations: OLD: Because this document establishes the implementation status of every algorithm, it should be listed as a reference for the entire registry. NEW: Because this document establishes the implementation status of every algorithm, it should be listed as a reference for the registry itself (leaving in place the individual entries for the algorithms referring to the documents that specify them). END _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </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 implementation status, this document assigns one. The document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933. Working Group Summary The intended effect of this draft was originally captured in draft-ietf-dnsext-dnssec-registry-fixes-08, which made a novel and controversial use of the IANA registry. That approach was too controversial, and so the WG split the document into two parts. This draft is one of them. The present approach was far less controversial than the previous one, and nobody has raised any objection to the current text. Document Quality The draft does not specify a protocol of any kind, but it does make a recommendation in favour of some algorithms that are so far not widely deployed. The discussion of dnssec-registry-fixes led to the approach instantiated in this draft. Personnel Andrew Sullivan is the Document Shepherd, and Ralph Droms is the Responsible Area Director. RFC Editor Note Please make the following two changes: In section 2.2: OLD: 2.2. Algorithm Implementation Status Assignment Rationale The status of RSASHA1-NSEC3-SHA1 is set to Recommended to Implement as many deployments use NSEC3. The status of RSA/SHA-256 and RSA/ NEW: 2.2. Algorithm Implementation Status Assignment Rationale RSASHA1 has an implementation status of Must Implement, consistent with [RFC4034]. RSAMD5 has an implementation status of Must Not Implement because of known weaknesses in MD5. The status of RSASHA1-NSEC3-SHA1 is set to Recommended to Implement as many deployments use NSEC3. The status of RSA/SHA-256 and RSA/ END In the IANA considerations: OLD: Because this document establishes the implementation status of every algorithm, it should be listed as a reference for the entire registry. NEW: Because this document establishes the implementation status of every algorithm, it should be listed as a reference for the registry itself (leaving in place the individual entries for the algorithms referring to the documents that specify them). END _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </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 implementation status, this document assigns one. The document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933. Working Group Summary The intended effect of this draft was originally captured in draft-ietf-dnsext-dnssec-registry-fixes-08, which made a novel and controversial use of the IANA registry. That approach was too controversial, and so the WG split the document into two parts. This draft is one of them. The present approach was far less controversial than the previous one, and nobody has raised any objection to the current text. Document Quality The draft does not specify a protocol of any kind, but it does make a recommendation in favour of some algorithms that are so far not widely deployed. The discussion of dnssec-registry-fixes led to the approach instantiated in this draft. Personnel Andrew Sullivan is the Document Shepherd, and Ralph Droms is the Responsible Area Director. RFC Editor Note Please make the following two changes: In section 2.2: OLD: 2.2. Algorithm Implementation Status Assignment Rationale The status of RSASHA1-NSEC3-SHA1 is set to Recommended to Implement as many deployments use NSEC3. The status of RSA/SHA-256 and RSA/ NEW: 2.2. Algorithm Implementation Status Assignment Rationale RSASHA1 has an implementation status of Must Implement, consistent with [RFC4034]. RSAMD5 has an implementation status of Must Not Implement because of known weaknesses in MD5. The status of RSASHA1-NSEC3-SHA1 is set to Recommended to Implement as many deployments use NSEC3. The status of RSA/SHA-256 and RSA/ END In the IANA considerations: OLD: Because this document establishes the implementation status of every algorithm, it should be listed as a reference for the entire registry. NEW: Because this document establishes the implementation status of every algorithm, it should be listed as a reference for the registry itself (leaving in place the individual entries for the algorithms referring to the documents that specify them). END _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </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 above is the most important, but Section 1.1 uses the term as well Section 3 paragraph 4 and Section 3.2 paragraph 8. 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) -------------------------------------- Title : DNS Security (DNSSEC) Hashed Authenticated Denial of Existence Publication Date : March 2008 Author(s) : B. Laurie, G. Sisson, R. Arends, D. Blacka Category : PROPOSED STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </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" The first is a regular URI specification without any parameter. The second add in a version parameter to tell a client which version of the protocol that service supports. In most cases we only really need to know if the service supports a minimum version of the protocol. But there might be occasions where the service required clients support a minimum protocol version, particularly in the case of an incompatible protocol upgrade, this might be supported by a 'mv' parameter for minimum version: _foo._wk.example.com URI 10 10 URI "http://host3.example.com/ v=2.1 mv=2.0" The main advantage to this approach is that it allows the URI scheme to be used to express all the information relevant to a client discovery decision, either explicitly or by reference. I see two routes to achieving this functionality 1) Redefine URI as outlined above Pro: It is compatible, does not need new code for those already implementing URI in servers Con: It might be seen as breaking the principle that a change to the format Con: If there is implementation of the URI scheme, records with parameters could cause things to break 2) Define another record as outlined above Pro: Guarantees nothing breaks Con: Will need new code Con: Means there are 3 SRV like discovery schemes instead of just 2. </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) -------------------------------------- Title : DNS Security (DNSSEC) Hashed Authenticated Denial of Existence Publication Date : March 2008 Author(s) : B. Laurie, G. Sisson, R. Arends, D. Blacka Category : PROPOSED STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </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 into a discussion of the design decisions made by Netscape without any consultation fifteen years ago at this point. The public suffix list was a design botch then and it is a design botch now. It is also legacy that we cannot change. The choice therefore is whether we live with the current situation where there are multiple unofficial public suffix lists or move to a scheme which at least permits the information to be published by the authoritative source for the domain in question. The forcing function that I believe is going to make the current situation untenable is the introduction of new TLDs by ICANN. I do not believe that the current system of unofficial public prefix lists with multiple maintainers is capable of reacting to change. It only works at all because the changes to the public prefixes have been gradual and most have been zones that have a two level hierarchy going to a flat TLD scheme. Has anyone written a draft to propose such a record or is interested in helping to make such a proposal? Since the objective is to expose a single bit of information per domain, the design space is not large. I see only two real design options. Option 1: All zones are considered private by default unless the zone publishes PUBLIC record in that zone which makes it a public delegation point. Con: This requires all TLDs to comply before the registry is effective. Option 2: The PUBLIC record takes an integer parameter as follows: PUBLIC 0 : Domain is NOT a public suffix PUBLIC 1 : Domain in which it is published is public suffix, default for subdomains is not public suffix PUBLIC 2 : Domain in which it is published is public suffix, default for subdomains is public sufix A domain is a public suffix if and only if * There is a PUBLIC RR with the parameter 1 or 2 published in the domain OR * There is no PUBLIC RR published in the domain AND (it is a TLD OR the parent domain has a PUBLIC RR with a parameter of 2) In the second option it would be sufficient for the small number of second level public delegation points to publish the appropriate records and for ICANN to require new TLDs to take the appropriate action if they are supporting public delegation points at levels lower than the TLD. The proposal could even be tweaked further to explicitly grandfather existing domains, though the public suffix list is actually rather large. Consider the Mozilla version: http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1 </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 wrong). In this case, the closest encloser proof is NSEC3 that matches example. and NSEC3 that covers x.example (that would have Opt-Out). But there's no "NSEC3 RR that matches the wildcard". Also, the closest (provable) encloser to QNAME (= example.) is not the immediate ancestor of the wildcard (RR), which is x.example. Is this case included in the discussion that led to the errata? I re-read the dnsext archive but couldn't be sure (as far as I can see the wildcard-related discussions at that time were about different issues than this one). Or is this case excluded by some other rules? --- JINMEI, Tatuya Internet Systems Consortium, Inc. _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </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 the existence of extended labels. The main contribution of RFC2671 was to allow larger DNS messages over UDP, beween cooperating parties, this is crucial for DNSSEC and other modern DNS uses. Working Group Summary Working group is solidly behind this document. Document Quality There are many implemenations of this specification, the working group wish is that this be published as Internet Standard. This document is the cummulation of fair ammount of work and experience. During the WG process most of the changes in the document were stylistic and presentation ones rather than technical. These are the responses to the questions from RFC 6410 regarding publication as an Internet Standard. (1) There are at least two independent interoperating implementations with widespread deployment and successful operational experience. There are MANY implementations, as a matter of fact almost all DNS implementations support ENDS0, there is great interoperability. The only issues that we have discovered are that some implementations have strange ideas (non-RFC1035 compliant) as what to return when seeing ENDS0 option in message. This is covered in this document. (2) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones. There are no errata filed against RFC2671 and RFC2671bis takes into account most of the issues that RFC2671 underspecified. (3) There are no unused features in the specification that greatly increase implementation complexity. Correct. (4) If the technology required to implement the specification requires patented or otherwise controlled technology, then the set of implementations must demonstrate at least two independent, separate and successful uses of the licensing process. The technology required to implement the specification requires no patented or otherwise controlled technology. Personnel Olafur Gudmundsson (ogud at ogud.com) is the document shepherd. Ralph Droms &lt;rdroms.ietf&lt; at &gt;gmail.com&gt; is the Responsible AD. _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </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; it is really not appropriate here. I just wanted to alert folks of this work. --Paul Hoffman _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> Paul Hoffman 2013-01-21T16:08:04 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.dnsext