[DNSOP] an editorial review of draft-ietf-dnsop-respsize-13
It has been pointed out that the DNS Referral Response Size Issues I-D should not be left going to final expiry, and I have performed a new review of the last version, draft-ietf-dnsop-respsize-13. I only found a small number of remaining editorial nits -- either formerly overlooked or newly introduced. You might want to take the opportunity of the notes below to refresh the draft. (1) Section 1 (1.1) 1st paragraph a) The object of the first sentence lacks an article; the should be supplied. b) In a few places, the draft uses very terse forms of precise citations, which better should be expanded a bit for readability; the first occurrence of this is here as well: (see [RFC1035] 4.2.1)should say (see [RFC1035], Section 4.2.1) or even better (see Section 4.2.1 of [RFC1035]) . Chosing the latter form, the corrections will accumulate to: | The original DNS standard limited UDP message size to 512 octets (see | [RFC1035] 4.2.1). Even though this limitation was due to the required minimum IP reassembly limit for IPv4, it became a hard DNS protocol limit and is not implicitly relaxed by changes in a network layer protocol, for example to IPv6. --- v | The original DNS standard limited the UDP message size to 512 octets | (see Section 4.2.1 of [RFC1035]). Even though this limitation was due to the required minimum IP reassembly limit for IPv4, it became a hard DNS protocol limit and is not implicitly relaxed by changes in a network layer protocol, for example to IPv6. (1.2) 2nd paragraph Again, please expand the reference (see [RFC2671] 2.3, 4.5) in the same way as above. (1.3) 4th paragraph Again, a definite article is missing, and also whitespace is missing in front of a citation -- both in the first sentence. Please adjust: | While more than twelve years passed since the publication of EDNS0 vv ^ | document[RFC2671], approximately 65% of the clients support it as observed at a root name server and this fraction has not changed in recent few years. The long tail of EDNS deployment may eventually be measured in decades. --- | While more than twelve years passed since the publication of the vvv | EDNS0 document [RFC2671], approximately 65% of the clients support it as observed at a root name server and this fraction has not changed in recent few years. The long tail of EDNS deployment may eventually be measured in decades. (2) Section 2.3 (2.1) 2nd paragraph When used as a noun, DNS should be written with the definite article: | While DNS distinguishes between necessary and optional resource records, [...] --- v | While the DNS distinguishes between necessary and optional resource records, [...] (2.2) last paragraph There are two grammar flaws in the text. a) s/independent to/independent of/ b) I assume that ... the DNS server _might_ just see ... is the needed verb that you had in mind. So please correct: | The glue record order should be independent to the version of IP used v^^ | in the query because the DNS server just see a query from an intermediate server rather than the query from the original client. --- | The glue record order should be independent of the version of IP used vvv ^^ | in the query because the DNS server might just see a query from an intermediate server rather than the query from the original client. (3) Section 3, last paragraph According to the RFC Editor explanations of the most frequent flaws in grammar and style (see RFC Editor educational presentation material from all recent IETF meetings), which is inappropriate in Technical English and should be replaced by that here: We're assuming 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 which ^^ results in larger query names be deployed significantly in advance of EDNS, then new measurements and new estimates will have to be made. --- We're assuming 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. (4) Section 4 (4.1) 2nd paragraph, last sentence Similar to the above case in Section 1, the text here contains a too terse detailed citation that should be expanded: | [...] See [RFC1996] 2 for more information about stealth servers. ---
Re: [DNSOP] an editorial review of draft-ietf-dnsop-respsize-13
Paul, thanks for your expedite response to my review comments. Please see a few inline follow-up remarks below. I have deleted all parts that don't need further elaboration. (1) Section 1 (1.1) 1st paragraph [...] b) In a few places, the draft uses very terse forms of precise citations, which better should be expanded a bit for readability; the first occurrence of this is here as well: (see [RFC1035] 4.2.1)should say (see [RFC1035], Section 4.2.1) or even better (see Section 4.2.1 of [RFC1035]) . i don't agree. we'll make the change, since we're not going to stand on minutiae, but for the record this is your personal style preference not an objective style guide reference. i would actually prefer [RFC1035 4.2.1] since terseness is to me virtuous. again: you're over reaching here, but, we'll make the change for you anyway. I have observed various instances of the RFC Editor changing RFC , Section yy to Section yy of RFC , and accommodating the preferred style helps to minimize changes of a document at the RFC Editor and thereby to speed up RFC Editor processing of a draft (and less changes for the authors to review in AUTH48), so if an opportunity exists, I try to accommodate RFC Editor preferences in advance and suggest doing so to others. [...] this, though: (2) Section 2.3 (2.1) 2nd paragraph When used as a noun, DNS should be written with the definite article: | While DNS distinguishes between necessary and optional resource records, [...] --- v | While the DNS distinguishes between necessary and optional resource records, [...] The Domain Name System as abbreviated to the acronym DNS is a proper noun. we do not write The IP even though we would write The Internet Protocol. similarly for TCP, UDP, NFS, and so on. I indeed found and observed that a few *P acronyms have attained that kind of personality during long usage (e.g. IP, TCP), but that System (as the trailing 'S' in the acronyms under consideration) has not found similar assimilation -- the nouns DNS, NFS, AFS, UMTS, etc. are (still?) usually spelled out in spoken language, at least by people with not so much focus on a specific technology. Further, perhaps non-native speakers of English generally prefer to spell out acronyms -- in particular those in a foreign language -- much more frequently than you may be used to do. But, agreed, opinions may vary. [...] (4) Section 4 [...] (4.2) 5th paragraph Here, a comma is missing in front of the (correct) bare which: More than one address record across protocol families is less likely to lead to or encounter truncation, partly because multiprotocol clients, which are required to handle larger RRsets such as RRs, | are more likely to speak EDNS which can use a larger UDP response size limit, and partly because the resource records (A and ) are in different RRsets and are therefore divisible from each other. --- More than one address record across protocol families is less likely to lead to or encounter truncation, partly because multiprotocol clients, which are required to handle larger RRsets such as RRs, | are more likely to speak EDNS, which can use a larger UDP response ^ size limit, and partly because the resource records (A and ) are in different RRsets and are therefore divisible from each other. ok. though the construct xxx, which yyy, which zzz is itself rather awkward. o.k. -- how about this to make it less awkward: ... multiprotocol clients, which are required to handle larger RRsets such as RRs, | are more likely to speak EDNS in order to be able to use larger UDP | response sizes, and partly because ... [...] (5) Final remark: Depending on the timeline of progress of the drafts, you might want to prepare for a _selective_ reference update from RFC 2671 to RFC 2671bis; this needs some care: - the first ref. to [RFC2671], in the 2nd para of Section 1 should be updated to RFC 2671bis, but - the second ref. to [RFC2671], in the 4th para of Section 1 (see above) should better be left bound to the original document and then changed to clarify the context: | While more than twelve years passed since the publication of the | original EDNS0 document [RFC2671], approximately 65% of the clients ^ support it as observed at a root name server and this fraction has not changed in recent few years. The long tail of EDNS deployment may eventually be measured in decades. Hence, [RFC2671bis] needs to be added to the Informative References without deleting the ref. [RFC2671]. we depend upon the rfc editor to make such last minute changes since they depend on the order of publication of rfc's. Well, rfc2671bis is in the IESG and it seems likely that the IESG Comments and the
Re: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (A)
Matthijs, thanks for dealing with my comments so expeditiously. (This extends to the other review comments as well.) Please see a few follow-up remarks inline below. On 11 Apr 2012 15:47:33 +0200, Matthijs Mekking wrote: Hi, On 04/05/2012 12:41 AM, Alfred Hönes wrote: After a long delay, I have revisited the DNSSEC Operational Practices, Version 2 I-D and performed a full review from scratch for the most recent draft version, draft-ietf-dnsop-rfc4641bis-10. A very long delay, the wglc ended somewhere last year... For convenience, and to accommodate message size limitations, I have split my review comments into 3 parts: (A) Technical flaws, (B) Editorial flaws, and (C) Editorial nits Only the first two parts will be sent to the dnsop list, the bulky third part is given as fodder to the authors only. Here we go with part (A); please consider to provide feedback for the items below on the list. I have omitted all items that I have adopted without feedback necessary. In other words, all omitted items will make the next version of the document. So will I, again. (A) Technical flaws ... (A.4) Section 3.4.1/3.4.2 -- additional considerations wrt ECDSA Given the pressure by important governmental/international stakeholders in support of Elliptic Curve (EC) cryptography and the large amount of DNS response packet space consumed by RSA (and DSA) keys and signatures, I strongly recommend to give the reader a glimpse of perspective on ECDSA usage with DNSSEC; draft-ietf-dnsext-ecdsa currently is in the RFC Editor queue in state RFC-Editor and already supported by major DNS implementations. A glimpse perhaps, but we (the editors) think your suggested is too strong. Also, we think that there is too little experience with ECDSA to make good observations. Which major DNS implementations are you referring to that have already implemented ECDSA? Admittedly, major DNS implementors would have been better than majot DNS implementations at this stage. However, quoting from NIST SP 800-81r1, Secure Domain Name System (DNSSEC) Deployment Guide, (April 2010), page 9-4: [...] The migration path for USG DNSSEC operation will be to ECDSA (or similar) from RSA/SHA-1 and RSA/SHA-256 before Septhember 30th, 2015. ... and from the same document, on page 9-6: The use of RSA in DNSSEC is approved until the year 2015. By this time, it is expected that Elliptic Curve Cryptigraphy will be specified in the DNSSEC. USG DNSSEC administrations should plan to migrate to the use of ECDSA (or similar) when it becomes available in DNSSEC components. ... one can see that there are strong market forces at work. The commercial pressure to qualify for USG (U.S. Government) use of networking components and software will likely lead to widespread support soon. There's nothing like (or similar) in view currently as an alternative. The repeated, IMHO non-rational fear of actual applicability of patent claims is not justified; the EC groups chosen have been selected carefully to make it possible to avoid the specific optimizations for GF(2^n) based EC computations that in fact *might* be covered by some patent claims -- see RFC 6090 for the detailed report that all we need is based on academic publications that predate the said patent applications. For instance, it would IMO make sense to add at the end of Section 3.4.1 or 3.4.2 a new paragraph like this: | Operators concerned with performance and key/signature size issues | related to RSA and DSA usage with DNSSEC should follow the ongoing | standardization -- and consequential implementation -- progress for | the use of digital signature algorithms based on Elliptic Curve (EC) | Cryptography with DNSSEC, which promises much shorter key and | signature sizes than RSA/DSA for equivalent cryptographic strenght. | In particular, the use of ECDSA with DNSSEC is now specified | [RFC.ietf-dnsext-ecdsa] and is expected to be available for use in | the foreseeable future. We would like to say that ECDSA is out of scope for Version 2 of DNSSEC Operational Practices. We suggest the following text at the end of 3.4.1, which summarizes ECDSA and will not be discussed here. Also at the moment of publication, digital signature algorithms based on Elliptic Curve (EC) Cryptography with DNSSEC [] are being standardized and implemented. The use of EC has benefits in terms of size. On the other hand, one has to balance that against the amount of validating resolver implementation that will not recognize EC signatures and thus treat the zone as insecure. Beyond the observation of this trade-off, we will not discuss further considerations. Agreed. The idea was to raise awareness among the reader community for upcoming important developments, not to perform an evaluation, and this aim is achieved
Re: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (B)
Matthijs, again thanks for your quick and detailed response and action. A few selected follow-up remark can be found inline below. On 11 Apr 2012 15:48:26 +0200, Matthijs Mekking wrote: On 04/05/2012 12:48 AM, Alfred Hönes wrote: Here we go with part (B); if deemed necessary, please consider to provide feedback for the items below on the list. Again, all items that are adopted without feedback necessary have been omitted from this reply. And I additionally dropped those items where I'm satisfied with your response and do not see the need to add more thoughts. (B) Editorial flaws ... (B.3) Section 1.2 -- clarification With respect to item (B.1) above, I suggest to even better clarify the definition of Signature validity period in Section 1.2 (1st bullet): OLD: | o Signature validity period The period that a signature is valid. | It starts at the time specified in the signature inception field | of the RRSIG RR and ends at the time specified in the expiration | field of the RRSIG RR. NEW: | o Signature validity period The time interval during which a | signature is valid. It starts at the (absolute) time specified in | the signature inception field of the RRSIG RR and ends at the | (absolute) time specified in the expiration field of the RRSIG RR. I don't see why this should be changed. Do you prefer interval over period? Do you want the clarify that the times are absolute? This is a non-issue in my opinion. Well, the issue is that RFCs 4033 and 4034, after initially using the precise term, signature validity interval, have switched to use the misnomer signature validity period, and we are stuck with that unfortunate usage for consistency with RFCs 4033/4034. Period is used in Re-Sign Period Refresh Period in this draft in the proper sense of a period - a recurring, floating interval that relates to the reciprocal value, a frequency. Therefore I still believe that it is worth emphasizing here, early in the document, that period in signature validity period is different, actually being a fixed time interval that, once passed, will not recur. The suggested two additions of parenthetical absolute [time] seem to be a suitable way to do that with a very small textual footprint. ... (B.6) Section 4.1.5, list items below Figure 5 -- clarifications (c) In subsequent list items, I suggest to clarify the text -- where becessary -- by making the distinction between old and newer data more explicit, and -- in two instances -- an indication of the possibility of more than one DNSKEY RR (as in the Figure, due to the split KSK/ZSK scheme used) should be indicated by talking about the DNSKEY RRset: | new DNSKEY: After the cache data has expired, the new key can be added to the zone. --- v | new DNSKEY: After the old cache data has expired, the new key can be added to the zone. What is an old cache? I suggest After the old data has expired from cache here. The proposed text did say old cache data, not old cache. :-) But the wording you suggest is fine as well; I just tried to a change with a smaller footprint. | DNSKEY removal: After the cache data for the DS has expired, the old | algorithm can be removed. This time the key needs to be removed | first, before removing the signatures. --- v | DNSKEY removal: After the cache data for the old DS has expired, the old DS RRset Agreed. | old algorithm can be removed. This time the old key needs to be v ^ | removed first, before removing the old signatures. ... Best regards, Matthijs Best regards, Alfred. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] a review of draft-ietf-dnsop-dnssec-dps-framework-06
Hello, in my attempt to catch up with DNS related work in the IETF, I now also have reviewed the most recent version of the DNSSEC DPS draft, draft-ietf-dnsop-dnssec-dps-framework-06. I did not find any serious issues or inconsistencies in the memo, and in general, it looks almost ready for bringing it to the IESG for publication as an Informational RFC. However, I found a couple of editorial nits and opportunities to make the language and use of terminology more precise and consistent within the memo and among existing DNS[SEC] related IETF documents, and just sent a report on these editorials to the draft authors. They might want to sum up the resulting changes on the list, but I did not want to bother list readers with the details. Kind regards, Alfred. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (A)
After a long delay, I have revisited the DNSSEC Operational Practices, Version 2 I-D and performed a full review from scratch for the most recent draft version, draft-ietf-dnsop-rfc4641bis-10. For convenience, and to accommodate message size limitations, I have split my review comments into 3 parts: (A) Technical flaws, (B) Editorial flaws, and (C) Editorial nits Only the first two parts will be sent to the dnsop list, the bulky third part is given as fodder to the authors only. Here we go with part (A); please consider to provide feedback for the items below on the list. (A) Technical flaws (A.1) Normative set of documents defining DNSSEC In Section 1, 1st para, the draft says: This document describes how to run a DNS Security (DNSSEC)-enabled environment. It is intended for operators who have knowledge of the | DNS (see RFC 1034 [RFC1034] and RFC 1035 [RFC1035]) and want to | deploy DNSSEC (RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 | [RFC4035]). [...] However, the DNSSEC WG once has made the decision to include some other documents into the list of what should be regarded as the integral set of core documents defining DNSSEC[bis]. IIRC, that decision has been made in late 2009, and consequentially it has been recorded in the AXFR RFC (see section 2, page 7 of RFC 5936). These additions are: - RFC 4509 , - RFC 5155 , - RFC 5702 , and - draft-ietf-dnsext-dnssec-bis-updates (now at draft version -16 and expected to be submitted to the IESG very soon, likely in parallel to this memo). Therefore, I suggest to amend the above see list in the draft by adding these four documents, and accordingly to promote the References to them to Normative (the dnssec-bis-updates I-D needs to be added to the References). (A.2) Section 1.1 -- improper/imprecise description of key usage Section 1.1 improperly talks about public key usage in _key exchanges_. However, in the context of DNSSEC, the public part of asymmetric key pairs are used for _signature verification_ , and only that usage is relevant for this document. So please change: OLD: [...] It is also assumed that the reader understands that the public part of the key pair is published in the DNSKEY Resource Record and that it is the | public part that is used in key exchanges. ^ NEW: [...] It is also assumed that the reader understands that the public part of the key pair is published in the DNSKEY Resource Record and that it is the | public part that is used in signature verification. ^^ (A.3) Section 3.4.1 -- improved section title In Section 3.4, | 3.4. Cryptographic Considerations ... I suggest to make the title of Section 3.4.1 more precise. OLD: | 3.4.1. Key Algorithm NEW: | 3.4.1. Signature Algorithm or: | 3.4.1. Digital Signature Algorithm or: | 3.4.1. Digital Signature and Hash Algorithms (A.4) Section 3.4.1/3.4.2 -- additional considerations wrt ECDSA Given the pressure by important governmental/international stakeholders in support of Elliptic Curve (EC) cryptography and the large amount of DNS response packet space consumed by RSA (and DSA) keys and signatures, I strongly recommend to give the reader a glimpse of perspective on ECDSA usage with DNSSEC; draft-ietf-dnsext-ecdsa currently is in the RFC Editor queue in state RFC-Editor and already supported by major DNS implementations. For instance, it would IMO make sense to add at the end of Section 3.4.1 or 3.4.2 a new paragraph like this: | Operators concerned with performance and key/signature size issues | related to RSA and DSA usage with DNSSEC should follow the ongoing | standardization -- and consequential implementation -- progress for | the use of digital signature algorithms based on Elliptic Curve (EC) | Cryptography with DNSSEC, which promises much shorter key and | signature sizes than RSA/DSA for equivalent cryptographic strenght. | In particular, the use of ECDSA with DNSSEC is now specified | [RFC.ietf-dnsext-ecdsa] and is expected to be available for use in | the foreseeable future. (A.5) Section 4.1.1.2, 2nd bullet below Figure 3 and 2nd-to-last para For completeness and consistency with other parts of the document, I strongly recommend to expand on the present text and explicitly mention the propagation delay that needs to be taken into consideration, beyond the TTL-based cache expiry period. (See also the dnsop-dnssec-key-timing draft.) a) 2nd bullet OLD: new DNSKEY: At the New DNSKEY stage (SOA serial 1) DNSKEY_Z_11 is introduced into the key set and all the data in the zone is signed with DNSKEY_Z_10 and DNSKEY_Z_11. The rollover period will need | to continue until all data from version 0 of the zone has expired from remote
Re: [DNSOP] Batch Multiple Query Packet
On 27 Feb 2012 13:35:45 -0500, Hector Santos wrote: I am interesting to find information about past or possible current interest regarding the support of a Batch single call of multiple query packets. If it doesn't already exist or not considered in the past as an unfeasible concept, I am interest in seeing if this is something worth pursuing. Below are a few comments, and pointers to references, to my past, humble contributions to a possible solution for the issue at hands. In response to a draft that suggested a form of A+ query type, which was submitted/refreshed for the Hiroshima IETF meeting, draft-li-dnsext-ipv4-ipv6-02, on 09 Nov 2009 I have submitted a more versatile proposal to the DNSEXT WG's list [1], which was only one possible variant (for brevity) for a RR Group Query (RRGQ) to query for a group of RRtypes with the same QNAME and QCLASS using an EDNS option to indicate the Data RRtypes wanted. The distinguishing idea was to build in some kind of integrity of RRsets using feedback signaling that allows to indicate empty RRsets (nodata indication per RRtype); caches that do not know the entire RRset of an RRtype asked for do not send a partial RRset but indicate that the response does not answer for such RRtype. The initially posted single variant made use of a Pseudo-RRtype as draft-li-dnsext-ipv4-ipv6, but another potential variant of RRGQ that uses a traditiona Data RRtype in the query section (plus the same EDNS option to indicate the desired Data RRtypes) has been explained later, near the end of a follow-up message [2]. Among the possible applications motivating the proposal and mentioned in the thread were DNSBLs and mail policy records (as you mention). This proposal has been discussed on the list during the Hiroshima IETF timeframe (see the thread started with [1], and shortly in the DNSEXT session in Hiroshima. However, unfortunately I never happened to fully write up this idea as an I-D, but Ray Bellis' dnsext-multy-qtypes draft revives it now (with some variation in the encoding of the EDNS option). This solution -- although not perfect or optimally coded in the present DNS protocol (with EDNS) -- might have the potential to find enough traction to allow relatively fast deployment, eased by its property that it has save fallback to traditional behavior with servers that support EDNS0. The obstacle to fast automatic fallback with responders that do not support EDNS0 due to the rule in RFC 2671[bis] that such responders MUST signal FormErr to query messages carrying an EDNS OPT RR -- unlike in the case of unknown EDNS options (that are to be ignored) is likely to be less of a problem now, because the increase in response sizes expected, and corresponding normative requirements to support EDNS0, for IPv6 and DNSSEC, has lead to now widespread support for EDNS0. So stakeholders interested in a tractable solution who do not want to wait for some future dns-ng allowing this (and much more) in some optimal way are invited to chime in and follow up in the discussion of draft-bellis-dnsext-multi-qtypes on the dnsext list! References to ancient messages on RRGQ -- once sent to the late namedroppers list, and now archived in the dnsext list archive: [1] http://www.ietf.org/mail-archive/web/dnsext/current/msg05291.html [2] http://www.ietf.org/mail-archive/web/dnsext/current/msg05305.html Please follow the entire thread to evaluate the raised point-of-views. Recent messages on multi-qtypes : http://www.ietf.org/mail-archive/web/dnsext/current/msg12398.html http://www.ietf.org/mail-archive/web/dnsext/current/msg12403.html Kind regards, Alfred Hönes. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] A quick review of draft-cheshire-dnsext-special-names-02
The referenced draft seems strongly related to DNSOP as well, but to avoid cross-posting, here's only the initial part of my review just posted to the dnsext mailing list. start of forwarded message Hi, I've performed a quick review of the DNSEXT-related I-D, draft-cheshire-dnsext-special-names-02 and would like to submit a few notes. (A) Significant issues (A.1) Firstly, I'm surprised by the non-trivial overlap of this work with RFC 6303 and the IANA Registry created by it, the AS112 RFCs, and the ongoing work-in-progress to address more emerging overload reasons for the authoritative root/infrastructure DNS servers by extending the scope of the AS112 project, registering more special domain names in that Locally Served DNS Zones IANA registry, and specifying that they be treated as specified in RFC 6303. The present draft not even quotes RFC 6303 for Sect. 5.1, where the largest overlap with RFC 6303 occurs. (I have not yet studied in detail inhowfar the new specification in that section is compatible or collides with the normative behavior specified in RFC 6303.) [...snip...] end of forwarded message To see the full review, please refer to the copy archived in the DNSEXT list archive: http://www.IETF.ORG/mail-archive/web/dnsext/current/msg12376.html Kind regards, Alfred Hönes. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] End of Life Notice for ITAR / State of ARPA.
It is now going to be two weeks since the IANA ITAR has been factually decommissioned, but still the last entry that has been removed from the ITAR, the DS record for the ARPA. zone, has not been placed into the root zone -- as confirmed by today's TLD DNSSEC Report: http://stats.research.icann.org/dns/tld_report/ . Isn't that a shame, another discredit of bureaucracy ? I agree that the planned decommissionning was not an emergency, but couldn't it be expected that, after the final date had been published *four* weeks ago, the procedures for the ITAR and the Root zone could have been reasonably coordinated? Kind regards, Alfred. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
Folks, Widespread diverse restrictions in devices/implementations/applications with an expected residual lifetime in the order of a another decade _are_ technical restrictions, not policy. All work on DNS I have followed in the recent years always was under the umbrella of conserving compatibility with deployed systems, and the costs for doing that indeed sometimes were really high. This was justified. Robustness has to remain the guiding principle when tuning the DNS. One of the obligations we have in the IETF is, IMHO, to take care of transparency, to avoid introducing fragility that hampers communication between users all over the world. That's an engineering aspect, and hence a technical aspect, not policy. We are faced with a scenario where some few voices want to open the doors wide to challenge the force of storms. Isn't is better engineering practice to keep the door almost closed, open it only a small slot wide -- just so much as current needs have been identified --, and observe what happens, before undertaking the next step? If the storm breathes in and destroys your ... (here: ability for all to communicate using all assigned domain names), you likely won't be able to close the door back far enough to restitute something resembling the status quo ante! Andrew Sullivan spoke: I think Joe's pragmatic approach is the right one: document right now that whatever the restrictions might historically have been, we are quite explicitly going to permit at the very least one class of labels. +1 If people feel strongly that in fact the TLD label restriction never was there and should not be, then once this document is published you all can go out and write the draft, TLD label character restrictions considered harmful, and pursue the publication of that as an RFC. In the meantime, we have at least a technical document that makes clear that certain things are permitted. +1 Looking through another pair of glasses, this seems to be a simple application of the robustness principle: - be conservative in what you send (frequently: MUST set to 0, unless future specs say otherwise, and here: be conservative in what labels are allowed to be placed in the public DNS), but - be liberal in what you accept (frequently: MUST ignore the value, to allow for future extensions, and here: educate implementers that they should get rid of restrictions that prohibit future extension of the set of possible labels to be expected) If you want to define an extension later for the 'originating' side, it is prudent to check for adherence to the be liberal principle on the 'consumer' side before you do it. Kind regards, Alfred. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-jabley-dnssec-trust-anchor-00 -- a quick review
a Certificate Extension, whereas this section talks about an Attribute. It looks like the latter is actually implemented, although the kind of CN specified would have been sufficient to identify the Subject, and thus packing the resourceRecord into a certificate extension (which would also be signed by the certificate issuer). [ Note: I don't know how well existing systems deal with unknown attributes in the Subject name -- the RFC 5280 profile contains a specific list of attribute types that SHOULD be supported --, but I would have assumed that a new certificate extension would have had a better chance of being accepted by CAs. ] To avoid possible confusion, I propose to clarify both parts of the document. In Section 2.2, as the ASN.1 type that actually is being specified and amended is RelativeDistinguishedName in the rdnSequence CHOICE of the Subject Name (cf. RFC 5280, Sect. 4.1.2.4 4.1.2.6), it might be worth changing: | Each CSR will have a Subject with following attributes: --- vv | Each CSR will have a Subject with following RelativeDistinguishedName attributes: (5) Section 3 -- additional note Accidentally, shortly before the submission of the draft (and based on the predecessor ICANN draft), I have filed an enhancement request for the IANA web site to make the entire Root zone material (including the trust anchors) accessible via hyperlinks on common pages where an average user would perhaps expect to find such pointers. The RFC Editor traditionally does not like detailed IANA URLs in RFC text. Therefore, having proper, annotated links down to the various files on a central page on the IANA site would also help a great deal in case the RFC Editor refuses to accept the URLs in sect. 3.1/3.2. (6) Section 4, 1st paragraph -- nit Near the end of the paragraph: s/which/that/ . (7) Appendix C (7a) -- full-fledged ANS-1 module ? The utility of the information would be improved very much if you could turn the ASN.1 fragments into a valid ASN.1 module that can be imported into ASN.1 tools. (7b) -- misleading headline As mentioned above, the headline is very confusing; the remainder of the I-D (including the body of this Appendix) doen't look like you want to define a Delegation Signer Extension. If that's indeed the intent, please change: |Appendix C. ASN.1 for Delegation Signer Extension --- |Appendix C. ASN.1 for the resourceRecord Distinguished Name Attribute or, if you follow (7a), simply: |Appendix C. ASN.1 Module (7c) -- normative reference needed A short sentence should be added -- details depending on the actual content, wrt (7a) -- that refers to the ASN.1 specification used. I guess ITU-T X.680 and X.681 will suffice; both should be granted a Normative Ref. (8) Appendix E The text paragraph in Appendix E ... This document, once published in the RFC series, is intended to provide a stable reference for DNS implementors and future document authors, and a clear specification that will aid effective and secure dissemination of DNSSEC trust anchors to the operators of DNSSEC validators. ... provides essential information to the reader and should not be subject to removal by the RFC Editor, but moved into another suitable part of the draft. If my recommendation in item (2c) above is followed, this is accomplished and the paragraph here can be dropped. Kind regards, Alfred Hönes. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] New Version Notification - draft-gudmundsson-dnsext-srv-clarify-01.txt (fwd)
My apologies for cross-posting, but this is inherently a cross-wg and cross-area topic: The revised draft contains clarifications for DNS service discovery using SRV RRs and suggests methods to deal with the restrictions imposed by draft-ietf-tsvwg-iana-ports. It is intended that both drafts will eventually be published in a coordinated manner. Abstract The DNS SRV record has been specified in RFC 2052 and RFC 2782 for use in dynamic service discovery for a domain. These two RFCs did not clearly specify an IANA registry for the names of the services and their underlying protocols. This document clarifies RFC 2782 regarding the formation and use of the Service Prefix in the owner name of SRV records, based on the unified IANA registry for Service Names and Transport Protocol Port Numbers. Kind regards, Alfred Hönes. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ - Forwarded message from internet-dr...@ietf.org - From: internet-dr...@ietf.org Message-Id: 20100630180001.dec133a6...@core3.amsl.com Date: Wed, 30 Jun 2010 11:00:01 -0700 (PDT) Subject: New Version Notification - draft-gudmundsson-dnsext-srv-clarify-01.txt New version (-01) has been submitted for draft-gudmundsson-dnsext-srv-clarify-01.txt. http://www.ietf.org/internet-drafts/draft-gudmundsson-dnsext-srv-clarify-01.txt Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-gudmundsson-dnsext-srv-clarify-01 IETF Secretariat. - End of forwarded message from internet-dr...@ietf.org - ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action:draft-ietf-dnsop-default-local-zones-12.txt
I see my previous concerns fully addressed by the -12. Thanks Joe for the much better replacement text! (Admittedly, I've been too conservative, in an attempt to preserve as much of the previous language in that paragraph as possible.) So this should now actually be fodder for the IESG to digest, isn't it? Kind regards, Alfred. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNS trickery and RFC 5841 -- was: Re: Misguided IPv4-IPv6 DNS trickery
[[ Apologies for cross-posting; this turns into scope of DNSEXT ... ]] Since most DNS queries are carried over UDP and hence cannot make use of RFC 5841, I suggest that we standardize an equivalent EDNS option, preferably with the same (inofficial) option number of 25. Then, BIG content providers and DNS service providers can start crafting DNS responses depending on the option content -- a much more general solution of the problem of the day. :-) Kind regards, Alfred. P.S.: The above RFC number obviously is an obfuscated _relative_ date, based on the birth year (1952) of some important folks, not the 1970-based epoch as in common operating systems. Please read 5841 as an encoding of 2010-04-01. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft on newzone_notify
I do think that it belongs in dnsext rather than dnsop - did you decide to move based on feedback from the working group chairs? Shane, at least _my_ argument was an encouragement to consider whether (or not) the underlying problem could/should be better addressed under the umbrella of the nameserver management protocol effort in DNSOP (i.e. _not_ in-band in the DNS protocol). If that makes sense, the topic falls into the bailiwick of DNSOP. Thus it seems a good idea to discuss the problem statement in DNSOP before deciding which road to go with a solution. BR, Alfred. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 and IPv6
At Mon, 8 Mar 2010 09:27:20 -0500 (EST), William F. Maton Sotomayor wrote: ... Given that the other two drafts on AS112 are already along the path to getting considered beyond the WGLC, would it be prudent to generate a third draft specific to these issues? Nicely said. This indeed again raises the question where these drafts actually are. If we don't understand that, it is difficult to answer such questions. And *I* don't understand, actually; I thought they ought to have passed the IESG since months, but the datatracker does not even indicate Publication requested. Where's the problem? Kind regards, Alfred. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] automatic update of DS records
On Wed, Mar 03, 2010 at 11:28:36AM +0100, Jaap Akkerhuis wrote: Antoin says: So there's one more logical entity involved; most likely this way: jaap ___ did i miss something? Antoin sez that where? That's been me, in my response to Antoin: http://www.IETF.ORG/mail-archive/web/dnsop/current/msg08108.html BR, Alfred. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] automatic update of DS records
To avoid further confusion on who said ... snip snip snip ... The last message was from Jaap Akkerhuis, who said: Oops, apparently Alfred said so. But who sais what is irrelevat on the discussion. The oint I was making is that there should not be a fixed aministrative model. jaap However, I didn't suggest that either. I noted that there is an additional logical entity to consider (i.e., if you properly unsplice the roles), painted an extension to Antoin's picture to show where it most likely lives in his entity map, and then continued with pointing out that there are alternatives for the direct contractual relationships. In fact, I see a parallel to the SIP trapezoid: The direct (RTP) media path between the communication peers corresponds to DNS transactions between the child and parent DNS operators, and the SIP signalling path through n proxies and intermediaries corresponds to the chain of organizatorial entities and relationships in our picture. In both cases, the 'signalling' transactions carried out in the 'upper arc' control what eventually happens in the 'bottom arc'. In both cases, what most matters eventually is the timing in the conceptional 'bottom arc'. The possible diversity in the upper arc seems to be an argument in favor of a solution employing direct communication in the bottom arc. It _may_ be that studying this parallelism (and the experiences with the SIP trapezoid) in more detail could result in useful insight(s) -- but please don't overstress this comparison! Kind regards, Alfred. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] automatic update of DS records
At Tue, 2 Mar 2010 16:53:53 +0100, Antoin Verschuren wrote:
The path is usualy even more complicated.
I've identified this stream of contractual relationships in a
registration process:
registry-registrar-reseller-registrant-dns_operator
(some roles may be duplicated or absent, some market players
may perform 2 or more roles at once, ...
...
Don't we talk about pushing the information from the child
to the parent?
So there's one more logical entity involved; most likely this way:
vvv v
dns_op(parent)-registry-registrar-reseller-registrant-dns_op(child)
The dns_op(child) might alternatively have a direct contractual
relationship with the reseller, registrar, or even registry instead
-- depending on business model, regulation, location in the DNS tree,
etc.
Many of {registrant, reseller, registrar} will not be interested
in tracing or even seeing the DNSSEC 'anchor' data passing by,
or might not even be on the administrative path naturally
being taken by the data (in the alternative cases).
The only party doubtlessly interested in such seems to be the
responsible for the parent zone content, i.e. the registry.
But that does not exclude a priori direct in-band communication
between dns_op(child) and dns_op(parent), with a 'gating' function
located at the registry for the actual updates at the parent
(similar to the way how NTIA acts on the root zone).
Thus one _possible_ communication model might be:
dns_op(parent) registry registrar reseller registrant dns_op(child)
^\__b___/ |
|a |
`---'
o a could be in-band with good authentication and integrity protection
(or RFC 1149/2549, if needed/preferred),
o b could be EPP (+ suitable extension); and
o the workflow management within dns_op(parent) is a local matter.
Kind regards,
Alfred.
--
+++
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: a...@tr-sys.de |
+++
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] Re: Priming query transport selection
Danny Mayer wrote, in a response sent to me, referring to Olafur Gudmundsson's text proposal quoted in my posting on Jan 13: Proposed replacement text: |2.1. Parameters of a Priming Query | | A priming query MUST use a QNAME of . and a QTYPE of NS, QCLASS | of IN, with RD bit set to 0, the source port of the query should | be randomly selected [RFC5452]. | | A DNSSEC aware resolver SHOULD sent the priming query over TCP. | If TCP is refused a different server SHOULD be tried, after 3 tries | the resolver SHOULD fall back on UDP. | | A DNSSEC ignorant but EDNS0 capable, resolver SHOULD issue the | priming query over UDP, ENDS0 option MUST be included with buffer | size of 1220 or larger. If the UDP query times out TCP SHOULD be | tried. | | An EDNS0 ignorant resolver MUST issue the priming query over UDP. ... I'm not sure I understand the point to this part. Since this is a draft and you would be talking about the next versions of resolvers that would be expect to support this (as opposed to existing ones) why would you expect there to be any future resolver ignorant of DNSSEC? Aren't we trying to make DNSSEC mandatory for future resolvers? Danny Danny, Please note that the quoted block of text wasn't mine, so maybe your message ought to have be addressed primarily to its author. But never mind. It has arrived there and on the lists. The primary goals of my posting were to point out that: - limiting the recommended priming query discussion and advice in teh Priming Query draft by a perspective on 1024-bit RSA keys and signatures is too narrow-headed if the advice shall last for more than a very small couple of years, and - with respect to message size issues and efficiency, DNSEXT should resume work on ECC keys and signatures for DNSSEC ASAP. Regarding your argument agaibst Olafur's suggested text, I fear there will be lots of resolvers for many years that cannot reasonably be expected to be DNSSEC aware, i.e. performing DNSSEC validation. I do not want to touch on policy issues -- whether CPE and end systems are in a better place for providing useful trust by performing DNSSEC validation than typical large-scale caching resolvers provided and maintained by ISPs. However: DNSSEC is a huge code addition, in particular for embedded TCP/IP implementations; the proliferation of signature algorithms we are starting to admit will make things even more complicated. In contrast, EDNS0 is a rather tiny addition providing general utility and it indeed really should be supported by such implementations. Therefore, I believe that we should give valid advice for such small-scale implementions as well -- they'll depend on working priming queries in any case. As pointed out by other folks in another current thread on DNSOP, BCP documents should not restrict the advice they are giving to a single mainstream scenario when the topic is more general in nature, but better cover various important scenarios. Thus, I indeed recommend to keep appropriate advice for DNSSEC unaware resolvers in the Priming Query draft. Kind regards, Alfred. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Priming query transport selection
I apologize for cross-posting due to topical overlap. Please confine follow-up messages to the appropriate list. In the message to DNSOP regarding draft-ietf-dnsop-resolver-priming-02 archived at http://www.IETF.ORG/mail-archive/web/dnsop/current/msg07843.html, Olafur Gudmundsson scratched at a topic of interest to namedroppers as well; he wrote: ... Background: 26 signed glue records will require about 5K answer if each RRSet is signed by a single 1024 bit RSA key. This will never fit into an ENDS0 answer as number of implementations have 4096 byte hard limit on answer size. Did you read the News these days? An international team lead by the BSI (the German NSA) and others has solved the RSA-768 challenge, and experts reportedly expect, due to significant progresses, that RSA-1024 will be solved in a rather short time, likely by the end of this year or so! This means that we should immediately plan operationally for widespread use of 2048-bit RSA keys in the near future. As of today all the root servers instances that my host reached answered a TCP query. Proposed replacement text: |2.1. Parameters of a Priming Query | | A priming query MUST use a QNAME of . and a QTYPE of NS, QCLASS | of IN, with RD bit set to 0, the source port of the query should | be randomly selected [RFC5452]. | | A DNSSEC aware resolver SHOULD sent the priming query over TCP. | If TCP is refused a different server SHOULD be tried, after 3 tries | the resolver SHOULD fall back on UDP. | | A DNSSEC ignorant but EDNS0 capable, resolver SHOULD issue the | priming query over UDP, ENDS0 option MUST be included with buffer | size of 1220 or larger. If the UDP query times out TCP SHOULD be | tried. | | An EDNS0 ignorant resolver MUST issue the priming query over UDP. ... I therefore support the proposal suggested by Olafur: Recommend that DNSSEC aware resolvers SHOULD issue priming queries immediately over TCP, and not waste time and bandwidth with an initial query over UDP (that will be truncated with certainty). Even UDP with EDNS0 and 4k message size limit (which most likely will need fragmentation and have trouble with firewalls) will not provide a workable solution for a reasonable life time (of RFCs and deployed equipment) and should only be tried as a fallback. Those not liking DNS over TCP might wish to convince the IEEE to quickly double the Ethernet frame size in the interim (in deployed networks as well, of course!) and the IETF to bump the IPv4 512-byte UDP margin. :-) Additionally: Work on the use of Elliptic Curve Signatures with DNSSEC urgently needs to be resumed *now* (in DNSEXT). EC keys and signatures will roughly be shorter than RSA keys and signatures by a *factor* of 4..8, for comparable levels of security. Kind regards, Alfred. P.S: Olafur: s/ENDS0/EDNS0/g ! :-) ^^^^ [ BTW, one of my favorite personal typos, as well! ] -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-jabley-reverse-servers-00
I have studied the draft proposing a new 'regular' naming scheme for the IN-ADDR.ARPA. and IP6.ARPA. zone, draft-jabley-reverse-servers-00 , and fully support this proposal. Nits I found in the draft: (1) Abstract | ... These zones contain data which facilitates reverse mapping ... ---^^^ | ... These zones contain data which facilitate reverse mapping ... ^^ (2) Section 1, 2th para This document specifies a dedicated and stable set of nameserver | names for each of the IN-ADDR.ARP and IP6.ARPA zones. ---^^ This document specifies a dedicated and stable set of nameserver | names for each of the IN-ADDR.ARPA and IP6.ARPA zones. ^^^ (3) Appendix B.2.2 There are a couple of copyedit flaws, missing necessary changes relative to B.2.1, in particular: - all instances of IN-ADDR.ARP should be IP6.ARPA; - the parenthetical clause in the 2nd bullet #1, (which is not authoritative for the IN-ADDR.ARPA zone), is irrelevant in this context and should be deleted. [ please check ] Kind regards, Alfred. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Computerworld apparently has changed DNS protocol
Interesting News! There must be a hidden trick to introduce DNS Jumbograms we just forgot to mention In a press article [1] entitled Root zone changes may shake up Net in Africa, Computerworld wrote: | From January 2010, ICANN will implement DNSSEC -- using a technique | also known as root signing -- on the root zone, which will affect | the performance of the Internet. Currently, queries from domain | servers to the root are 512 kilobytes or less, but DNSSEC will make ^^^ | them larger because it introduces new signatures and keys as part ^^^ | of the security features. :-} [1] http://www.computerworld.com/s/article/9140123/Root_zone_changes_may_shake_up_Net_in_Africa ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] Computerworld apparently has changed DNS protocol
Bill Manning wrote: cool eh? although I suspect she ment responses. --bill Yet responses usually did not go *to* the root servers so far. I'm getting confused.:-) :-) Did anybody ever have a prejudice against journalists? -- reconsider, please! :-) Alfred. P.S.: Disclosing that the writer was female seemed politically incorrect to me, so I purposely avoided this detail. On Wed, Nov 04, 2009 at 07:58:41PM +0100, Alfred Hönes wrote: Interesting News! There must be a hidden trick to introduce DNS Jumbograms we just forgot to mention In a press article [1] entitled Root zone changes may shake up Net in Africa, Computerworld wrote: | From January 2010, ICANN will implement DNSSEC -- using a technique | also known as root signing -- on the root zone, which will affect | the performance of the Internet. Currently, queries from domain | servers to the root are 512 kilobytes or less, but DNSSEC will make ^^^ | them larger because it introduces new signatures and keys as part ^^^ | of the security features. :-} [1] http://www.computerworld.com/s/article/9140123/Root_zone_changes_may_shake_up_Net_in_Africa ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-resolver-priming-02
Peter and Matt, hello again!
Thanks for reviving the Resolver Priming draft, and amending and
restructuring some of the text to enhance the readability and
completenes of the reasoning, in
draft-ietf-dnsop-resolver-priming-02.
(You politely have chosen to not mention these improvements in the
document history. :-) )
However, it looks like my previous comments on the -02 version
(once ack'ed) have been missed in the recent edits.
Below are (A) a few more general comments, followed by (B) notes
on the editorial nits (still) present in the memo.
(A) General comments
(A.1) DISCUSS item in 2.3
| [[Is it OK to send multiple priming queries to multiple targets in
| parallel?]]
The more conservative, yet perhaps less user friendly approach
would be to not allow multiple parallel queries.
However, I am not aware of similar restrictions in any DNS related
RFCs for any kind of queries. Since we apparently do not have
such rules for other queries to root servers, there would need to
be strong reasons for interdicting multiple parallel queries.
Priming queries can reasonably be expected to be much less frequent
than other queries that make it to the root servers, so this in fact
might not be an issue at all.
(A.2) Section 4, 3rd para -- OBE !
vvv
| [[At the time of writing, all but one root name server were
authoritative for ROOT-SERVERS.NET., even though only a subset
received an official delegation.]]
At IETF 72, the root server operators had promised to rectify this
irregularity; as can be seen now, the first inconsistency indeed
has been done in the meantime. So please change the 1st line:
vvv
| [[At the time of writing, all root name server were authoritative for
ROOT-SERVERS.NET., even though only a subset received an official
delegation.]]
Note: The subset mentioned is {A,F,J,K}.ROOT-SERVERS.NET.
Since the whole para is under the premise At the time of writing,
I suggest to give this information as well, as a service to readers
of the memo.
(A.3) Section 3.1 -- additional discussion
To mitigate the effects of SBELT information becoming outdated
over time, as described in Section 4, it might be contemplated
to 'update' the SBELT information with information obtained in
authoritative responses. It remains unclear from Section 3.1
whether such use of priming (or other) responses should be admitted
and under which conditions. The strongmost condition would be to
require having received and validated signed data -- as soon as
DNSSEC signatures for the root zone are available --, but one could
consider declaring receipt of the same information from multiple
(n ... tbd!) root servers as sufficient to allow an auto-update
of the SBELT.
(B) Editorials
(B.1) Section 1, below the quotes fron RFC 1034
Typo:s/seperates/separates/
^ ^
(B.2) Section 2.3, 1st para -- punctuation
For enhanced readability, I suggest inserting a comma as follows:
[...]. For resending the priming query to a
| different server the random selection SHOULD also be used.
---
[...]. For resending the priming query to a
| different server, the random selection SHOULD also be used.
^
(B.3) Sections 3.1, 3.3, 4
I suggest to use titlecase fo the special terms related to DNS packets,
as these consist of plain english words, and thus titlecase should
serve to help avoid possible ambiguities:
answer section -- Answer Section(2x)
authority section -- Authority Section
additional section -- Additional Section(6x)
(B.4) Section 3.3, 1st para -- punctuation
As above:
[...]. To ensure equal
| availability the A and RRSets should have identical TTL values
at the authoritative source. [...]
---v
[...]. To ensure equal
| availability, the A and RRSets should have identical TTL values
at the authoritative source. [...]
(B.5) Section 4, 2nd para -- missing verb
All DNS root name servers need to be able to provide for all
| addresses of all root name servers. This can easily achieved by
making all root name servers authoritative for the zone containing
the servers' names.
---
All DNS root name servers need to be able to provide for all
| addresses of all root name servers. This can easily be achieved by
making all root name servers authoritative for the zone containing
the servers' names.
MfG/Kind regards,
Alfred Hönes.
--
+++
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: a...@tr-sys.de
Re: [DNSOP] [dnsext] Re: DNAME-bis issues (was: new draft about idn tld variant implementation)
On Oct 21 2009, Chris Thomson wrote: On Oct 21 2009, Andrew Sullivan wrote: Dear colleagues, On Wed, Oct 21, 2009 at 05:54:18PM +1100, Mark Andrews wrote: DNAME's placement is the same as any ordinary resource record (e.g. MX, TXT). There is nothing special about where DNAME can or can't be used. While that is true, quite plainly the current dname-bis draft doesn't leave everyone with that impression. We need proposed text to make the intent clearer. Can someone please propose it? Given the emergence of this issue, the document is clearly not ready for advancement, and it needs to be fixed before we send it on. We really need Alfred Hönes to comment on this, as he was the one who acquired the wrong impression. ... I'll try, also elaborating on thoughts only exchanged off-list so far (last week). First my apologies for not being able to return to this discussion earlier. And maybe I was a bit overshooting in the first instance, too much focussed on the aspects I try to clarify below. Let me first discuss the more generic questions underlying the 'variant' domain (TLD or other) draft and discussion. The basic topic where we started from last week is a delegation. With regard to the root zone (and any other registry-like zone), owner and delegation are not only technical terms related to DNS database and protocol details, but also are contractual and legal terms, and so a lot of care needs to be taken in using these terms. This has repercussions to the protocol and database layer; for instance, in a DNSSEC signed zone the owner of the zone will sign the records there, and will be kept accountable for their content. For brevity, I'll designate the discussed DNAME at the root as an instance of a pseudo-delegation below (vs. normal delegation). For a normal delegation, the NS RRset in the delegating zone indeed is owned (in the legal sense!) by the parent zone owner; it is subject to the contractual relationship between the owner of the parent zone and the owner of the delegated zone. The NS RRset at the zone cut is handed over to the parent zone in a technical, contractual and legal sense. (Note that the owner of a zone is free to publish a different NS RRset for the zone at the apex of the zone itself than what he has handed over to the parent -- but he should strongly consider the consequences.) Hence, consistently DNSSEC signs the delegation NS RRs in the parent zone and thereby documents the legal ownership as well. Consequently, any other RRs for the delegated zone, if copied into the parent zone are not signed under DNSSEC there -- independent of their use as glue RRs in the narrow sense (address RRs for the name servers specified in the delegating NS RRs) or not. Since with DNAME queries for the owner name (technical!) of a DNAME RR will be answered from the zone where that DNAME RR is located, any other RRs with the same owner (technically!) name must be co-located in the same zone and hence fall technically under the authority (legally) of the owner (in legal terms) of the parent zone. This is entirely consistent with DNSSEC signing authority for all RRsets at the owner name (technically) of the DNAME RR being with the owner (legally and technically) of the 'hosting' zone of the DNAME RR. Many owners (legally) of TLDs and other registry-like zones place various RRs not directly related to the delegation (in the technical sense) at the zone apex for the delegated zone. For instance, I've seen TXT and NAPTR RRs recently there, but other RR types might be likely too. In the case of a 'pseudo-delegation' with DNAME in the parent zone these RRsets all would need to be stored in the latter, for instance in the root zone. Without DNSSEC, doing so and maintaining these RRs might be regarded as an OM issue that could be organized on a contractual base, overriding to some extent the basic legal split of responsibility. But with a DNSSEC signed parent zone, the sibling RRsets of the DNAME would become subject of the parent zone signing policy and practice; I seriously doubt that this would be practical; furthermore, it is likely that the DNSSEC signature over such RRsets would be taken under some legislation as a strong sign of ownership and hence accountability of the parent zone owner for the content of these RRsets. This seems to be in perfect accordance with the DNSSEC trust model. Even more, the user of an 'alias' domain name will want to gain full legal authority of this name and consequently also will be held accountable for it; delegating registration-like domains will most likely not want to become accountable for these names. For a 'normal' delegation, there's a visible 'proof' of ownership for the delegation by the SOA RR at the apex of the delegated zone, which might legally serve as a strong indication of ownership of the delegation -- there's a pointer to layer 8 and above in the SOA in the form of the RNAME element in the SOA RDATA. A DNAME RR however
[DNSOP] draft-yao-dnsop-idntld-implementation-00 and DNAME
Authors: I fear that Sections 3 ff. of draft-yao-dnsop-idntld-implementation-00 have entirely missed the evolution of the dnesext-rfc2672-dname draft. The Understand DNAME bit, and hence the dependence on EDNS has been removed in June, and it has been reinforced that support for DNAME does not require support for EDNS0 (although recent empirical data have shown that ENDS0 support is almost pervasive for authoritative servers and recursive resolvers in these days, and, as you know, IPv6 makes EDNS0 effectively mandatory, and DNSSEC does the same). This clarification of RFC 2672 has the support of major implementors and implementations. I suppose that this evolution has made moot much of the discussion in your draft. So please could you revise it based on the current understanding of DNAME ? Namedroppers: What's the state of draft-ietf-dnsext-rfc2672bis-dname ? IIRC, there was no substantial discussion on the list since -17 has been posted in September. Are the chairs now working on bringing that draft to the IESG? DNSOP folks: Are there sound empirical data on DNAME support at large? Reportedly, DNAME already is in heavy use in ENUM deployments. I've never heard complaints from ENUM folks about issues with DNAME -- or did I miss smething? Kind regards, Alfred Hönes. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new draft about idn tld variants implementation
Another point: The draft is speaking abut DNAME _in_ the root. According to my surficial knowledge, DNAME RRs 'live' at the _apex_ of the zone that shall be redirected, not at the delegation point -- or did I miss something? Within each zone, there may be at most one DNAME RR, and if so, it must be at the apex of the zone. So if you have a variant TLD, this variant would need to be delegated from the root zone (via NS RRs as usual) anyway, and the owner / DNS operator of the delegated variant TLD (ICANN should perhaps ensure that's the same one as for the 'original' TLD!) simply publishes a tiny zone with the DNAME RR. From the point of view of the root zone, there's no difference in the 'look and feel' of an 'original' TLD and a variant TLD. Most likely however, the name servers for the variants would be the same as for the basic TLD. But the owner / DNS operator of the 'original' TLD and its variants is entirely free to manage the equivalence of these domains in any feasable way, one of it being DNAME; however, if they have server software that can perform the aliasing 'on the fly' from a database, they could use that. It is a contractual matter between ICANN and the TLD owner to ensure that the equivalence is maintained under all circumstances, not a DNS protocol issue. Or is it the intent to have the variant TLS zones all be served by the root servers as well, to which you oppose ? I've not heard about such proposal, but admittedly I did not care much about such questions in the past. If ICANN would decide to have the DNAME-based variant TLD zones (those tiny zones with only the SOA, the DNAME, and maybe a few other RRs) be served within the root server organization, they would not necessarily have to do that with the original root servers; they also could deploy additional servers for this purpose and delegate the variant TLDs to these servers. Even if the variant zones were to be served by the original root servers, there would have to be delegations (to the same servers) via NS RRs, insn't it? Kind regards, Alfred Hönes. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new draft about idn tld variants implementation
On Oct 16 2009, Chris Thompson wrote: On Oct 16 2009, Alfred Hönes wrote: Another point: The draft is speaking abut DNAME _in_ the root. According to my surficial knowledge, DNAME RRs 'live' at the _apex_ of the zone that shall be redirected, not at the delegation point -- or did I miss something? Within each zone, there may be at most one DNAME RR, and if so, it must be at the apex of the zone. That's just wrong. DNAMEs can occur anywhere within a zone (including at the apex, but not restricted to it), and there can be as many as you like within a zone, subject only to the constraint that no RR has a name subordinate to that of a DNAME. I don't think so. Here's a full section from draft-ietf-dnsext-rfc2672bis-dname-17 (expected to be shipped to the IESG soon) : 2.3. DNAME Apex not Redirected itself Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its owner name; the owner name of a DNAME is not redirected itself. The domain name that owns a DNAME record is allowed to have other resource record types at that domain name, except DNAMEs, CNAMEs or other types that have restrictions on what they can co-exist with. | DNAME RRs are not allowed at the parent side of a delegation point | but are allowed at a zone apex. There still is a need to have the customary SOA and NS resource records at the zone apex. This means that DNAME does not mirror a zone completely, as it does not mirror the zone apex. These rules also allow DNAME records to be queried through RFC 1034 [RFC1034] compliant, DNAME-unaware caches. That's been uncontroversial consensus in DNSEXT, with full support of DNS implementers, IIRC. The last paragraph is at the heart of the matter, and it should mitigate the concerns in the tld-variant draft! (So *if* you have one at the apex, *then* you can't have any others, certainly.) True. A zone that *does* have a DNAME at the apex (and nothing else but SOA and NS records) ... ... or TXT or whatever you like or need -- don't forget DNSSEC RRs! ... is positively crying out to have the DNAME pulled up into that parent zone, *replacing* the delegation there. ... This is just moot! ... (I've got reverse zones I would love that to happen to, if only the parent zone administrators would co-operate...) They are well advised to not do that! -- Chris Thompson University of Cambridge Computing Service, Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. Best regards, Alfred. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-iab-idn-encoding-00
[[ Sorry for cross-posting. ]] All, in July the IAB has posted an I-D on IAB Thoughts on Encodings for Internationalized Domain Names, draft-iab-idn-encoding-00, and solicited feedback. That draft is closely related to the DNS related WGs as well. After very quickly skimming over that memo, it looks like the description of DNS labels and the resulting restrictions is incomplete in several respect, for instance: - No distinction is made between the 'normal' labels from STD 13 and other label types (currently there aren't other label types supported by active standards, but the future might change that). - No mention is made of case-insensitive treatment of DNS labels of standard type in resolvers and authorities. - No mention is made of the 0x20 hack, the deployment of which (be it standardized or not) will prohibit future deviation from the ASCII-only case-insensitive label regime we have, e.g. when potentially allowing full UTF-8 or UTF-16. - The impact of potential normalization needs (as an extension of case-insensitive comparison of ASCII labels to Unicode) of authoritative server and recursive resolver behavior is not discussed. I got the impression that the DNS related text in this IAB draft might deserve detailed review from DNS experts -- both on dnsop and namedroppers, but I have not found any discussion on that memo. Kind regards, Alfred. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] Why ZSK rollover is a Bad Idea
I already have posted a response to the original analysis by EKR, which has much overlap with the comments sent to this list by Olaf. Please see the original URL for the thread there, including my reasoning about operational impact and human factors: http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html [[ Now switching to DNSOP as well. ]] Kind regards, Alfred. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] latest revisions of AS112 drafts -- editorials
I'd like to mention the remaining few minor editorials I found still present in the re-posted AS112 drafts. [[ No new draft version(s) needed; that can be fixed by the RFC-Editor or during AUTH48 ! ]] a) First paragraph of 'Abstract' of both drafts: Please use common spelling in the prose: RFC1918 -- RFC 1918 b) help-help draft, Section 2, 2nd paragraph: Please s/to be be/to be/ Kind regards, Alfred. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-morris-dnsop-dnssec-key-timing-00
Hello, I have studied your I-D, draft-morris-dnsop-dnssec-key-timing-00 and find it a very useful exposition. I have (A) one point for discussion and (B) a few nits to polish. (A) The draft generally assumes a single active key used for zone signing (or as a KSK for secure delegation). IIRC, the core DNSSEC specifications call out for one set of signatures *per algorithm supported in a zone*. Since currently crypto algorithm agility is a hot topic (e.g. transition to SHA-2 and ECDSA), it should be worth being considered in the draft. The important detail is that, due to long transition phases to be expected for validating resolvers, there will be long periods of coexistence of signatures for secure zones that are deemed worth the algorithm transition, and hence the common operational need for more than one 'active' key. My first impression is that the algorithms in the draft could be (and should be) easily applied unchanged *per signature algorithm*. Is that true? Thoughts? (B) Editorial nits: (1) Figure captions I suggest to make the figure captions more compact and use the common RFC style; for instance: | Timeline for a ZSK rollover. | |Figure 1 --- |Figure 1: Timeline for a ZSK rollover. (2) Section 2.3.2, 2md para s/takes in to account/takes into account/ ^ (3) Section 3.1, difference #1 s/a excessive amount/an excessive amount/ ^ ^^ (4) Section 3.1, 2nd para below the numbered differences s/the time take to publish/the time taken to publish/ ^ (5) Section 3.1, 'Event 1' s/may find its convenient/may find it convenient/ ^^^ ^^ (6) Section 3.1, 'Event 4' Please add the missing trailing period. (7) Section 4, implication #2 s/longer that the key lifetime/longer than the key lifetime/ ^^ Kind regards, Alfred Hönes. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-dnssec-trust-anchor-03
Generally: Thumbs up for this version! However, one legacy nit has been left untouched. In Section 5, 2nd para: s/number trust anchors/number of trust anchors/! ^ (No new draft version needed, wait for opportunity to fix!) Kind regards, Alfred. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updates to AS 112 WG drafts -- solicitation for progress
Hello all, First, my thanks to William F. Maton Sotomayor for taking up this long-lasting thread and reviving the AS112 drafts. I have followed up to both new AS112 drafts, draft-ietf-dnsop-as112-ops-02 and draft-ietf-dnsop-as112-under-attack-help-help-02, and I heartly recommend the WG to now undertake all necessary steps to quickly bring these documents to RFC publication. I do not believe that IPv6 considerations should now hold off these drafts even more. I would diagnose considerable unfairness in the WG against the authors if, after being silent for so many months, this issue would now be raised as a show-stopper. The description in the drafts necessarily is a snapshot in time, and any document on operational considerations could be held off indefinitely by a sustained requirement to add the next generation of considerations. Further, I oppose to attempts to mix in forgery resilience aspects into these documents. These are orthogonal to the topic of these drafts and dealt with in a separate effort. We should not blow up every other document with the never ending discussion on the lazyness of operators in the implementation of efficient RPF in access networks, to raise the hurdles for source address spoofing; doing so would be an effective means to totally stall the WG process. I share the opinion of the authors that the 'fading of comments' after -01 was a clear indication that all interested folks did agree with the drafts, and hence that WG consensus on the drafts should have been declared or finally determined formally. All comments I once had sent in have been acted upon gracefully, and I only found two tiny nits in -help-help-02, which can easily be fixed during RFC Editor processing: - in the first paragraph of the Abstract, common spelling prcatice in RFC prose suggests to s/RFC1918/RFC 1918/ ; - in the last paragraph of Section 1, s/to be be/to be/ . Thus, I'd like to ask the chairs to now quickly proceed with both documents. The updates to -02 have been clerical, and hence, if in your opinion WGLC has been carried out last year, go ahead; otherwise, please issue a short WGLC. Since draft-ietf-dnsop-default-local-zones is an essential complementary document, I repeat my request to go ahead with that draft as well. I heartfully await an immediate one-week WGLC on all three drafts so that the outcome can be discussed at IETF, if necessary. The WG charter has milestones for forwarding to the IESG of all these documents by September 2007 (!). The WG would gradually loose its credibility if it proves continued inability to show progress on chartered work items. Kind regards, Alfred Hönes. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] New Version Notification for draft-mcgrew-tss-02 (fwd)
This tools might be of interest for implementors of DNSSEC, e.g. the folks wanting to distibute control over the future Root Zone primary Key Signing Keys between the RIRs and ICANN/IANA. The new version should hopefully be ready for implementation. - Forwarded message from IETF I-D Submission Tool - From: IETF I-D Submission Tool idsubmiss...@ietf.org Message-Id: 20090309204424.ad5f73a6...@core3.amsl.com Date: Mon, 9 Mar 2009 13:44:24 -0700 (PDT) Subject: New Version Notification for draft-mcgrew-tss-02 A new version of I-D, draft-mcgrew-tss-02.txt has been successfuly submitted by David McGrew and posted to the IETF repository. Filename:draft-mcgrew-tss Revision:02 Title: Threshold Secret Sharing Creation_date: 2009-03-09 WG ID: Independent Submission Number_of_pages: 26 Abstract: Threshold secret sharing (TSS) provides a way to generate N shares from a value, so that any M of those shares can be used to reconstruct the original value, but any M-1 shares provide no information about that value. This method can provide shared access control on key material and other secrets that must be strongly protected. This note defines a threshold secret sharing method based on polynomial interpolation in GF(256) and a format for the storage and transmission of shares. It also provides usage guidance, describes how to test an implementation, and supplies test cases. The IETF Secretariat. - End of forwarded message from IETF I-D Submission Tool - Kind regards, Alfred. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action:draft-ietf-dnsop-default-local-zones-07
Hi Mark, it would have been appreciated even more if you could have updated a couple of references in the re-post of the Local Zones draft; doing so would hopefully have decreased the likelihood of the need for another update cycle before the next step (sure, I'm an insane optimist, still expecting such next step to occur, even soon!) Details: o RFC 2434 has been onsoleted by the new BCP 26, RFC 5226, and that one has changed the IANA policy terms; therefore, please replace IETF Consensus by IETF Review in Section 6; o for [I-D.draft-ietf-dnsop-as112-ops], the -01 version had been posted in November 2007, and it is awaiting a move ahead of the WG ; o for [I-D.draft-ietf-dnsop-as112-under-attack-help-help], the -01 version also had been posted in November 2007, and it is also patiently awaiting a move ahead of the lazy WG ; o for RFC 3330, the 'canonical' update is on its way: draft-iana-rfc3330bis-06 has been posted this week, the GEN AD is following up for the IESG; thus, it might be reasonable to switch to the updated document as a ref. Question to the WG : -- Are there any convincing reasons for *not* advancing that draft in a reasonable timeframe now? If not, I'd like to urge the chairs to undertake appropriate steps. Serious note: Should anyone be in doubt -- these are chartered DNSOP work items: The milestone in the charter for this draft to IESG for BCP once was set at September 2007. Similarly, the milestones for the AS112 docs (mentioned above) to IESG (for Informational / FYI, i.e. Informational as well) were set to December/September 2007, respectively. All that had been confirmed in Dublin, IIRC. Kind regards, Alfred Hönes. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV Protocol Label Registry
Folks, I apologize for cross-posting, but a post to DNSOP has touched a topic arguably in scope for DNSEXT, the 'home' of RFC 2782. At Sun, 18 Jan 2009 22:47:05 -0800, SM s...@resistor.net wrote: Hello, RFC 2782 defines the following format for the SRV RR: _Service._Proto.Name RFC 3263 defines SRV lookups of _sip._tcp.example.com. Can _sip be registered in a Label registry as a protocol that provides services such as _bip._sip.example.com? No -- currently ! :-( Unfortunately, at present, it can't, for the simple reason that RFC 2782 had overlooked establishing such IANA Registry, and nobody had undertaken this effort since! :-) Because of recurring need observed in various WGs for having such registry, shortly before IETF 73, Olafur Gudmunsson has started such effort with draft-gudmundsson-dns-srv-registry-00. I have contributed a bunch of material as possible additions to that draft, providing evidence of existing usage defined in RFCs, which reveals that until now, the following _protocol labels already have been defined in the IETF, besides the 'classical' names (tcp, udp): _ipv6, _xmpp, _http, _ldap, _ocsp . IMHO, the scope of the draft needs to be expanded significantly, and I have proposed changes and additions to the -00 draft before IETF 73. The DNS-SD community already had established a web page serving a similar purpose, and draft-cheshire-dnsext-dns-sd-05, as a by-product, aims at establishing a similar registry based on that web page (see the Refs there). IMO, the scope of that inofficial registry also would need to be expanded, and precision added. Furthermore, RFC 3861 has established a very specialized registry that conceivably could also be merged with a more general service registry; at least, it must be coordinated to avoid collisions. The proper strategy to structure the IANA Service Label [Pair] registry, formalize the registration procedure, and establish the initial registry content still remains to be worked out, and this effort also needs to be coordinated with the IANA Considerations for the Port Number IANA Registry draft being discussed in TSVWG, because it should most preferably be avoided that confusion can result from two independent service registries. I support Olafur's vision that a properly and thoughtfully founded Service Label IANA Registry might help overcome the significant restrictions posed by the rather small Port Number namespace, and might some time take over the role of a more general and versatile service registry -- for those protocols and services that reasonably can make use of DNS SRV and do not have reasons for binding to a fixed server port. Regards, -sm ___ DNSOP mailing list DNSOP at ietf.org https://www.ietf.org/mailman/listinfo/dnsop Best regards, Alfred Hönes. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-resolver-priming-01
Hello Peter and Matt,
eventually, I found the time to take a closer look at the
latest version of your Resolver Priming I-D,
draft-ietf-dnsop-resolver-priming-01,
and again would like to submit a few comments, most of which
are editorial in nature.
Items (4) and (7) ff. should be of interest for the WG discussion.
(The message is copied to the list therefore.)
(1) Section 1, 2nd text paragraph -- typo
| Today's practice generally seperates serving and resolving ...
--- ^
| Today's practice generally separates serving and resolving ...
^
(2) Section 2.1 -- nit
For clarity, I suggest to add a comma in the last sentence:
v
| [...] For resending the priming query to a different server, the
random selection SHOULD also be used.
(3) General (in particular Sections 3, 3.2, and 4) -- terminology/case
I suggest to spell the established terms for the parts of DNS
messages in headline case:
Answer Section / Authority Section / Additional Section
^ ^ ^ ^ ^ ^
(4) Section 3.1 Use of the Priming Response
The draft simply says:
A resolver MAY use the priming response as it would use any other
data fed to its cache. However, it SHOULD NOT use the SBELT
information directly in any responses it hands out.
After some consideration, this perhaps also means that the priming
response SHOULD NOT be fed back into the SBELT -- which otherwise
would be a possible option for use of the priming response.
For clarity, I suggest to make that explicit in the text.
Further, it might be useful to recommend [rate limited] logging of
(or sending notifications to the resolver operator) the occurrence
of changes in the priming response vs. the SBELT information, to give
the resolver operator a trigger/opportunity to verify the changes
and, if approved, update the SBELT configuration information (or the
code of the resolver if it is compiled in) accordingly, for improved
resilience in the future.
(5) Section 3.2, 1st paragraph -- nit
Again, for clarity, I suggest to add a comma in the 3rd sentence:
[...]. To ensure equal
| availability, the A and RRSets should have identical TTL values
^
at the authoritative source. [...]
(6) Section 4, 2nd paragraph -- nit
I recommend to insert be in the second sentence:
| [...]. This can easily be achieved by
making all root name servers authoritative for the zone containing
the servers' names.
(7) Section 4, 3rd paragraph -- ATTENTION to ROOT SERVER OPERATORS !
The draft says:
[[At the time of writing, all but one root name server were
authoritative for ROOT-SERVERS.NET., even though only a subset
received an official delegation.]]
For clarity:
a) L.ROOT-SERVERS.NET is the single one root server not pretending
to be authoritative for ROOT-SERVERS.NET.
b) The subset that has received an official delegation consists of
{A,F.J.K}.ROOT-SERVERS.NET.
At the DNSOP session in Dublin (IETF 72), root server operators have
indicated that in fact *all* root servers should be authoritative,
via official delegation, for ROOT-SERVERS.NET., and they have
indicated their intend to perform the necessary updates as soon
as feasible; but these changes have not happened yet.
I suggest to update the draft text accordingly and keep track of the
changes to happen.
(8) Section 4, 5th paragraph
The draft says:
[[Do the TTLs for the root NS RRSet and address RRSets in the root
and the ROOT-SERVERS.NET. zones need to be aligned? In real life
responses, the address RRSet's TTL values vary by implementation.]]
Again, at IETF72 root server operators have indicated that indeed
these TTL values SHOULD be aligned, and promised to take the necessary
operational measures to ensure that in the future.
I suggest to update the draft text accordingly.
(9) Section 6
I recommend that the consensus of the root server operators indicated
at IETF72 on the discussion items (7) and (8) above be submitted to
the IANA for incorporation in their root server policy and guidelines.
Kind regards,
Alfred.
--
+++
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: [EMAIL PROTECTED] |
+++
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
