Re: [DNSOP] [dnsext] DNS vulnerabilities
its hard to distinguish an implementation error and a DNS protocol error, so yes, it might be a very good idea to triage your failures properly. /bill On Sat, Oct 26, 2013 at 01:28:10AM +0200, Hosnieh Rafiee wrote: Hi Bill, Thanks for your message. are your new collection, DNS vulnerabilities, configuration mistakes, or implementation faults? Currently I collected some information regarding DNS vulnerabilities and some about configuration mistakes. But I haven't included anything regarding implementation faults yet. I guess it is also good to have a section about this. Any thought? ---smile-- Hosnieh . success is a journey, not a destination.. You cannot change your destination overnight, but you can change your direction ... Focus on the journey ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] DNS vulnerabilities
are your new collection, DNS vulnerabilities, configuration mistakes, or implementation faults? /bill On Sat, Oct 26, 2013 at 01:16:29AM +0200, Hosnieh Rafiee wrote: Hello, I have gathered some vulnerabilities in the current DNS security approaches such as DNSSEC and etc. We think it is useful to have a survey of existing vulnerabilities or any new vulnerabilities so that we can address those issues in other standard RFC. This is why we plan to write a new informational draft. There is currently one old RFC that address the DNS vulnerabilities: http://tools.ietf.org/html/rfc3833 So, we welcome any ideas about this work. Thanks, Best, Hosnieh ___ dnsext mailing list dns...@ietf.org https://www.ietf.org/mailman/listinfo/dnsext ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] timekeeping and DNSSEC
On Sat, Oct 26, 2013 at 01:11:26PM +0100, Jim Reid wrote: On 26 Oct 2013, at 12:59, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: a serious vulnerability of, so called, DNSSEC is lack of secure time. some security novices innocently believed GPS time were automagically secure. That is, so far, there is no way to have really secure DNSSEC. Rubbish! If good timekeeping matters so much to DNSSEC, there are plenty of sources of reliable time. For most people, NTP will be good enough. The paranoid might choose Secure NTP. The really paranoid will have multiple time sources other than GPS: eg the radio clocks operated by many national standards institutes and/or the EU, Russian and Chinese(?) equivalents of GPS. The really, really paranoid will operate their own atomic clocks. In Ohta-sans world, secure hinges on being idempotent from the silicon, the assembler, compiler, binaries and data. If any of these attributes is or can be compromised - its not secure. DNSSEC depends on time e.g. not idempotent == not secure. What really is happening is that DNSSEC is a risk management tool. DNSSEC can measureably reduce the risk of bad data. It does introduce new risk, in the form of timeing attacks, but the tradeoffs generally are presented as acceptable to most folk. /bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On Mon, Feb 13, 2012 at 09:33:05AM +0100, Stephane Bortzmeyer wrote: On Mon, Feb 06, 2012 at 07:12:56PM +, bmann...@vacation.karoshi.com bmann...@vacation.karoshi.com wrote a message of 49 lines which said: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Root Name Server Operational Requirements Author(s) : Root Server System Advisory Committee Filename: draft-rssac-dnsop-rfc2870bis-04.txt Section 3.2.1 : I do not understand why you need synced time for DNSSEC. The root name servers do not generate signatures. but they do use TSIG. And historically, channel protection via TSIG or SIG(0) was considered part of the DNSSEC tool box. Granted that DNSSEC perception has changed over the years. but the need for sync'ed clocks is becuase of TSIG. Section 3.2.1 : Several root name servers, such as B, reply to ICMP echo requests, which I think is a good thing, but it seems disallowed in your document. -I- think its a good idea, but others would prefer less transparency Section 4.2 : This advice directly contradicts RFC 6382. Do you plan to reclassify it as Historic? It meaning RFC 6382? Not really. The draft was an attempt to document current practice - with some leanings toward future directions. Section 5.1 : Announcement of planned outages also keeps other operators from investigated a scheduled maintenance window. My english parser broke here. Should I upgrade it or should you rewrite the sentence? investigated should be investigating. e.g. if you don't tell anyone you are doing maintance work, observers will presume the worst and start to debug why the L root has gone offline. (For the record, I agree with most of Joe Abley's remarks on high-level issues with this document.) There are some strong argumetns for simply stating operational goals/principles vs documenting practice. I beleive that we are working on a mission statement /bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [rssac] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On Thu, Feb 09, 2012 at 01:17:52PM -0800, Joe Abley wrote: Hi Bill, On 2012-02-06, at 14:12, bmann...@vacation.karoshi.com bmann...@vacation.karoshi.com wrote: Thanks to Warren, Ed, John D., David C. and Kato-san for their comments/corrections. Any more? I see you added some text based on our conversation in sunny Christchurch, thanks for that. As promised, here's a summary of that conversation for the list(s). [elided] In summary, I think the document should be substantially reorganised. This makes it difficult to provide a meaningful line-by-line critique. However, I am very happy to put my money where my mouth is and copy-edit/reorganise along the lines I'm thinking if that seems like a useful way to explain myself. I don't think the -04 draft, even with copy-editing, is useful to publish as-is. Joe I had a similar conversation with Terry (check the thread archives). Effectively what you propose is a clean slate instead of building off existing work and actual practice. I think that is a fabulou idea but it has a couple of caveats: ) it will take considerable time to reach consensus within the operator community, let alone the large community. ) it will not reflect actual practice but an ideal to be achieved. I think that starting work on such a draft is a great idea -BUT- in the mean time do not let perfect get in the way of good enough. I beleive Terry agreed with that line of thnking. Of the existing Operators, A, B, E, G, H, J, L, and M have made positive comments and worked on upgrading this base text provided by one of the Operators. Is your opinion / argument strong enough to stop work on this draft? That said, I'd love to see a revamped version, if youhave the time to copy-edit/reorgnize the document. /bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments on draft-rssac-dnsop-rfc2870bis-04.txt
Hello Paul. First off, this is an RSSAC document so it is not clear why you think someone from the root opserator community should do the copy editing. The paragraph at the end of section 1 (the isn't really 2119 language text) is quite cute and will cause you a world of pain and delay. You have de-capped everything, so remove the paragraph. (Unless you're just trying to make John Klensin even grumpier, which is also quite cute but will also cause you a world of pain and delay). IETF tools complains when that text is removed. Will see if there is a clean way around it. The intro to section 3 says: The servers need both physical and protocol security as well as unambiguous authentication of their responses. Physical security focuses on the machines and their locations, Protocol security and response authentication are covered by Internet Protocol standards. However, there are three subsections, the middle being network security. Further, much of the protocol security is covered by by transport layer security, not IP security. Proposed new wording: The servers need to be protected by physical and protocol security for their administration and communications. They also need to be protected by network security to reduce their vulnerability to attack. Physical security focuses on the machines and their locations, network security focuses on the way that the root servers are connected to the Internet, and protocol security focuses on administrative communication with the servers as well as integrity protection for the messages from the servers to the public. Going back to the document to see which parts you quoted and which were your suggested changes. Will fold in the intent of your suggestion. The text in 3.2.5 doesn't make sense. NTP can't be on the list if the operator is expected to get time updates in as secure manner as possible. A proposed rewording would be to just remove that phrase because you describe what operationally is needed to use NTP in a non-crypto secure manner. or ... update the text to describe secure NTP - which is not uniformly used. or the use of local clocks. For the author reference, consider adding the URL http://www.root-servers.org/, given that mail to the address listed will often be automatically lost. (Bonus points for updating that page to eliminate the decade-old presentations and just leave the news!) again, this is an RSSAC work product, not just root-operators. and the URL listed is not uniformly used by all operators. so will likely just leave it as RSSAC. That said, if URLs are accepted in author references (and I have to admit not seeing that used previously) then a link to the RSSAC page might be in order. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments on draft-rssac-dnsop-rfc2870bis-04.txt
On Mon, Feb 06, 2012 at 05:52:12PM -0500, Paul Hoffman wrote: On Feb 6, 2012, at 5:19 PM, bmann...@vacation.karoshi.com wrote: First off, this is an RSSAC document so it is not clear why you think someone from the root opserator community should do the copy editing. There is a large/complete overlap between the RSSAC and the root server operators. Many of the companies that operate root servers have staff doing many things, such as technical writing. Some have copy editors. The fact that ICANN has not done a copy edit pass on the document after five rounds says that maybe you should look to others. Waiting for ICANN to do this might be futile, given that it doesn't involve making policy. You are mistaken. while all root server operators are part of RSSAC, RSSAC is a much larger community with membership from all the RIRs, ISOC, Research Facilities, and Governments. I'll note that ISOC, through the IAB has a presence on RSSAC. Perhaps we could have ISOC provide copy editing? The text in 3.2.5 doesn't make sense. NTP can't be on the list if the operator is expected to get time updates in as secure manner as possible. A proposed rewording would be to just remove that phrase because you describe what operationally is needed to use NTP in a non-crypto secure manner. or ... update the text to describe secure NTP - which is not uniformly used. or the use of local clocks. You can't say can use NTP and in as secure manner as possible: they don't match. then you recommend we strike SNTP from the document? There are ways to harden and NTP only system without going completely to a secured NTP (SNTP) system. And from my experience, if one takes proper precautions and prudent design choices one can deploy a resistant NTP strucuture without the crypto overhead on the SNTP datagrams or channels. So I am confident that we can, in fact, say with a straight face say that servers should use NTP or SNTP in as secure a mnner as practical/possible. Its being done. You can use URLs in author references. However, the RSSAC web page is mostly worthless unless you like bureaucratic history. The root-servers.org page is useful. If you don't want to provide a useful URL, that's fine. again, RSSAC is not just the root operators. If you want us to include a tangentially related URL, we could just as easily use www.ietf.org as www.root-servers.org in as far as the RSSAC represents either of those groups. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft of RFC 2870-bis for consideration
will fold them in, thanks. /bill On Sun, Feb 05, 2012 at 11:34:06AM -0500, Warren Kumari wrote: Nits and notes: Abstract: O: The DNS is considered a crucial part of that technical infrastrcuture. P: The DNS is considered a crucial part of that technical infrastructure. C: s/infrastrcuture/infrastructure/ -- typo. Background: O: ...servers to enable robust dand resilientb P: ...servers to enable robust and resilientb C: s/dand/and/ -- typo. 1.4: O: ...temporary simulatneous loss of manyb P: ...temporary simultaneous loss of manyb C: s/simulatneous/simultaneous/ -- typo. 3.2.1: O: ...for TSIG and DNSSEC syncronizationb P: ...for TSIG and DNSSEC synchronizationb C: s/syncronization/synchronization/ -- typo. 3.2.6: O: Servers must log in UTC to facilitate log comparison. C: Seems a little strong -- If I want to log in fortnights since lunar eclipse, that's my business -- as long as I'm willing to convert the log to UTC before handing it to be analyzed. 3.2.8: O: The server should be protected from attacks based on source routing. The server must not soley rely on address- or name-based authentication. C: Seems like it should have more text. Not entirely sure what is being said here. also: s/soley/solely/ -- typo. 3.3.6: O: ...based on the currnet update cycleb P: ...based on the current update cycleb C: s/currnet/current/ -- typo. 3.3.10: O: These monitoring processes could be automated. P: These monitoring processes should be automated. 4.2: C: See draft-mcpherson-unique-origin-as-00 (expired). Neither supporting nor opposing the draft, just mentioning it. 5.1: O: ... a scheduled maintaince windowb P: ... a scheduled maintenance windowb C: s/maintaince/maintenance/ --typo. W On Feb 1, 2012, at 7:11 AM, bmann...@vacation.karoshi.com wrote: The Root Server System Advisory Committee of ICANN has been working on a revision to RFC 2870. It is currently posted as: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Root Name Server Operational Requirements Author(s) : Root Server System Advisory Committee Filename: draft-rssac-dnsop-rfc2870bis-03.txt Pages : 9 Date: 2012-01-31 As the Internet has become critical to the world's social and economic infrastructure, attention has focused on the correct, safe, reliable, and secure operation of the Internet infrastructure itself. The DNS is considered a crucial part of that technical infrastrcuture. The root domain and its authoritative name servers are a part of that technical infrastructure. The primary focus of this document is to provide guidelines for secure, stable, and resilient authoritative name service for the root zone. Additionally it will look into some specifics for the operation of the name servers. Other operators of authoritative name servers such as those for generic top-level domains (gTLDs), country code top-level domains (ccTLDs) and other zones may also find it useful. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rssac-dnsop-rfc2870bis-03.txt Your comments would be appreciated. /bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft of RFC 2870-bis for consideration
thanks! will fold in accordingly. /bill On Sun, Feb 05, 2012 at 07:40:49PM -0800, David Conrad wrote: Bill, Comments/nits/etc. Regards, -drc Last sentence of Abstract: ... zones may also find it useful. Might suggest ... zones may also find this document useful. --- 1. Background, second sentence: The Internet Assigned Numbers Authority (IANA) publishes ... Should be: The Internet Assigned Numbers Authority functions operator (IANA) publishes ... --- 1. Background, next sentence: ... refer to the many ways a root operator provisions to provide root name service known by its letter, ... Since the naming convention of the root servers isn't introduced to this point (or discussed later or even germane to the discussion), I'd suggest dropping known by its letter, --- 1. Background, last sentence of first paragraph: Typo dand. --- The sub-points of section 1 aren't really introduced, they just sort of show up. Perhaps before 1.1, putting something like At a high level, the root servers operate under the following general characteristics: or somesuch. --- 1.2 For legacy reasons, some of the root servers have also served other important zones, In the future, the data served by root servers may change after careful review by RSSAC and ICANN. The second comma should probably be a period. The use of a past-tense verb suggests that some of the root servers are not now serving other important zones. Since those root servers still serve those zones, it would be clearer to state: For legacy reasons, some of the root servers serve other important zones. In the future ... --- 1.4 The domain name system has proven to be sufficiently robust that the temporary simulatneous loss of many of the root server instances does not significantly affect secure and stable operation of the Internet. [citeation] I'm not sure the ambiguous term many is warranted, particularly without a citation. Perhaps loss of a number of and has not ... affected instead of does not ... affect since that suggests loss occurs with some frequency. Also typo: simultaneous. --- 1.5 Authentication, validation, and security of these data and the communications channels they transit are be considered possible attack vectors. are to be or should be and I think you want the term vulnerabilities, not attack vectors. --- 1.5 ... equal-cost multipath routing and Anycast routing. (Anycast is discussed further in Section 4.) Probably should provide a citation to the documents that define anycast here, e.g., RFC 3258 (as opposed to later). --- For simplicity, this document uses the term server to refer to however many hosts a root operator provisions to provide root name service at a single address per address family. Duplicative of wording in the first paragraph of this section. --- 2. The Servers Themselves Given there is no mechanism for enforcement, these aren't requirements. They are better termed suggestions or perhaps couched in terms of best current practices. --- 2.1 Not phrased as an imperative. It also isn't clear as to whether this is discussing the root server _system_ or an individual root server operator's implementation of their part of the system. Assuming the former, perhaps: In order to improve overall robustness, the root server system SHOULD utilize heterogeneous hardware, operating systems, network topology, and name serving software across the root name servers. --- 2.2 Not phrased as an imperative. Perhaps: While there are no accepted, formal test suites for standards compliance, the maintainers of software used on root servers SHOULD take all reasonable actions to ensure their DNS server software correctly implements the IETF standards for authoritative DNS, including RFC1035[2], RFC2181[3], RFC4035[14] and others that conform to the IETF's then-current documented expectations. --- 2.3 ... each server must be able ... s/must/SHOULD/ --- 2.4 Connectivity to the Internet should be as diverse as possible. Expansion/clarification of this sentence would probably be helpful. Diversity in terms of what? --- 2.5 s/must/SHOULD/ Also, I might quibble about overgeneralizing. There are authoritative name servers that cache responses in order to improve performance. As the root zone grows, this may become more important. It might be prudent to clarify what sort of caching this suggestion is recommending against. --- 2.6 s/must/SHOULD/ Also, clarification of valid IP address is probably warranted, e.g., allocated IP address. I think it appropriate for root servers to NOT respond to queries from (e.g.) IPv4 10/8 or anything in IPv6 outside of the current FP. --- 2.8 s/must/SHOULD/ --- 3.1 s/will/SHOULD/ --- 3.1.1 s/must/SHOULD/ --- 3.1.2 s/must/SHOULD/ --- 3.1.3 s/must/SHOULD/ --- 3.1.4 s/must/SHOULD/ --- 3.2.1 routing
Re: [DNSOP] draft of RFC 2870-bis for consideration
thanks. will fold in your comments. /bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft of RFC 2870-bis for consideration
The Root Server System Advisory Committee of ICANN has been working on a revision to RFC 2870. It is currently posted as: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Root Name Server Operational Requirements Author(s) : Root Server System Advisory Committee Filename: draft-rssac-dnsop-rfc2870bis-03.txt Pages : 9 Date: 2012-01-31 As the Internet has become critical to the world's social and economic infrastructure, attention has focused on the correct, safe, reliable, and secure operation of the Internet infrastructure itself. The DNS is considered a crucial part of that technical infrastrcuture. The root domain and its authoritative name servers are a part of that technical infrastructure. The primary focus of this document is to provide guidelines for secure, stable, and resilient authoritative name service for the root zone. Additionally it will look into some specifics for the operation of the name servers. Other operators of authoritative name servers such as those for generic top-level domains (gTLDs), country code top-level domains (ccTLDs) and other zones may also find it useful. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rssac-dnsop-rfc2870bis-03.txt Your comments would be appreciated. /bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Further observationon AS112 ipv4 cull
On Thu, Jul 28, 2011 at 02:11:41PM -0400, Warren Kumari wrote: On Jul 27, 2011, at 10:08 PM, William F. Maton Sotomayor wrote: On Tue, 26 Jul 2011, George Michaelson wrote: I would support this latter approach William: I think we should seek WG adoption of three drafts 1) the michaelson as112-ipv6 draft, aiming for at least one 01 spin to a small set of non-controversial V6 delegations, moving to WGLC and IANA asap. 2) your as112-ipv4-cull draft, but shorn of the operational aspects, likewise rapid movement to WGLC and IANA For the consideration of members of DNSOP to adopt as a working group item, -01 of my draft has been submitted. 3) an AS112 operational draft more in the nature of 6304/5/bis This one will follow a little later, I suspect more expanded than before. I would like to ask for WG adoption of AS112-IPv6 on that basis. +1, especially since some as112 natives are getting restless. I made a suggestion at the mic in the f2f meeting, and then on the as112 operators list -- there seems to be some support for it there, so I'm now doing it onlistb How about simply making AS112 omniscient (know the answers for *all* space)? As decisions to have AS112 answer / not answer for zones get made, delegations can simply be added and removed. Obviously this would require synthesizing answers[0], and these servers cannot be used for answering recursive queries (and a few other minor issues) but this will (as far as I can see) solve the lameness / coordination issues... W [0]: Yes, yes i *did* feel dirty writing thatb . Thanks, wfms ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org been there, done that. before ICANN existed, I ran the RFC 1918 auth servers. put in a wild card TXT Please read RFC 1918 to any/every query. 20min later after the university pres had fielded calls fm industry about being hacked- we removed the wildcard... until leaking DNS queris fm private netsinto the Internetcan be stopped, you can't reliably anwer the queries. /bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] dns interface to whois? (Re: Taking Back the DNS )
On Mon, Nov 22, 2010 at 09:58:02PM +, Paul Vixie wrote: Date: Mon, 22 Nov 2010 20:36:17 + From: bmann...@vacation.karoshi.com we tried this a couple time last decade with limited success. (pre SRV). it would work, if and only if there were general agreement by the zone admins to actually keep up w/ the data. while i expect that it would be a gateway rather than a data transform, and while i agree that if it's a data transform then it should be done often enough to not get out of date, i note that i'm asking a different question than would it work. i'm wondering if there's enough interest to have it be worth writing it up as a dns schema so that interested producers and consumers of this information in this form can have a standard rendezvous (qname format) and delivery system (TXT formats). that's not would it work. it's could it ever be useful to anybody. well, at least two schemas have been proposed and there was limited uptake either time. perhaps times have changed. i am not trying to get input on technical feasibility since i think that's pretty obvious. nor am i trying to get input on governance like should registries be required by icann to implement it or should icann implement it for root, arpa, and other non-delegated zones. just is there interest. well, one thing that kind of makes sense is where to anchor such records... two choices - a WKA such as in-addr.arpa, ip6.int, enum.arpa et.al. or place the entries at each delegation point and sweep the tree periodically to build a stale cache of data... --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt
On Mon, Oct 04, 2010 at 11:14:20AM -0400, Joe Abley wrote: On 2010-10-04, at 11:11, Eric Rescorla wrote: Carefully specified, perhaps, but what you're saying here also makes me think it was also incorrectly specified, since, as I said, the technique I described is well-known, and failing to do so leads to precisely the complications that are at issue here. Regardless of what you think of it, what we have is what we have. Specifying a trust anchor publication strategy that works with something different seems a little pointless. i think the correct point is, this work documents what _was_ done, eg. a historical fact. It also lays out what the authors think is best practice, given the current constraints. Its kind of tough to argue w/ someones beliefs. Facts - yes, beliefs - not so much. If there are factual errors in what occured, those can and should be corrected. So, rather than designing a bunch of kludgy workarounds, it would be better to ask what the right thing to do is, even if that requires changing some preexisting document. Workarounds to what? I have not heard a clear description of a problem yet, just a lot of possible solutions. And yet, you were part of a team that spent hundreds of thousands of dollars and several man-years working on a solution to a, as you state above, to a problem without a clear statement? I'd susggest that there might be better ways to do key management and that EKR might have some good ideas on the subject. But thats _future_ work. --bill Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC4641bis - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration
On Thu, Jul 08, 2010 at 11:39:33AM +0200, Olaf Kolkman wrote: I observe though that 4641 is mainly written from the perspective of a 'zone-owner' and that I am not quite sure where to give specific advice to administrators of recursive nameservers. So before text is drafted there is an explicit question to the WG on whether this document should contain a section that gives guidance to recursive nameserver operators? is there also a distinction between a zone owner and its authoritative nameservers? If the document is primarly oriented toward a zone owner then references to nameserver administrators should be; a) kept to a minimum, and b) clearly stated at the head of the docuement, the focus of the advice, e.g. to zone owners. 2. There are also multiple ways in which the auth nameserver operators will manage key rollover. Authoritative operators should free to decide if they want to manage their keys in a RFC5011 manner or not. RFC4641bis should place no restriction on authoritative servers. Hmmm. Currently the document does not restrict auth servers but it does give recommendations such as (in version 02 in the 1 but last paragraph of 3.1.2: It is therefore recommended to regularly roll KSKs if and only if those rollovers can be tracked using automated RFC5011 type mechanisms. Note the way this is phrased doesn't even say that 5011 is the magic bullet. Question to the WG: is the document in any way restrictive on not using 5011, or is its consideration for advising RFC5011 to strong? there have been some arguements about the periodicity of key rolls. Unless this document can have a clearly defenseable position for recommending regular rollovers and having such tied to RFC 5011, it might be wise to decouple this work from RFC 5011... unless this work really depends on RFC 5011 use. (3. With RFC5011 we now have some confusion in the current RFCs about the status of the SEP bit. RFC4034 describes the SEP bit as follows Bit 15 of the Flags field is the Secure Entry Point flag, described in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a key intended for use as a secure entry point. This flag is only intended to be a hint to zone signing or debugging software as to the intended use of this DNSKEY record; validators MUST NOT alter their behaviour during the signature validation process in any way based on the setting of this bit. RFC4041 RFC4041 recommends In this document, we assume a one-to-one mapping between KSK and SEP keys and we assume the SEP flag to be set on all KSKs This clearly alters RFC 4034 and gives some meaning to the SEP bit. s/4041/4641/ My understanding about the SEP bit is reflected in the RFC 4034 text. In 4061, the authors have exceeded the definition in 4034 and based their work on that assumption... which doesn't appear to be valid :) RFC5011 RFC5011 describes a method for securely managing key rollover via the use of the SEP bit and the addition of a revoke bit. This clearly redefines the original meaning of the SEP bit in RFC4034. Could 4641bis or something mention 1. RFC3757 is not obsolete 2. RFC3757 is updated by RFC5011 RFC 5011 describes A method, not THE ONLY method. One is or should be free to interpret the SEP as defined in RFC 4034. I do not think that this (non standards track document) should tinker with the status of any standards track document. Besides I believe that what is in 4034 says: SEP is not interpreted during the validation but can be used as a hint for operational matters (and then mentions debugging and zonesigning). Agreed. The SEP bit is described in [RFC3757] and updated in RFC5011. However, it plays no part in the validation process. It may only be used in the automated key rollover process as described in RFC5011.) While chewing on section 3.1 yesterday and today it seemed that having a separate section on the use of SEP is appropriate. On this work is in progress. (I updated http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration) --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-mekking-dnsop-auto-cpsync-00
thanks for this. :) --bill On Tue, Jun 29, 2010 at 03:19:54PM +0200, Matthijs Mekking wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FYI, I have submitted this draft on the topic of automatic update of DS (and other records). Best regards, Matthijs Mekking NLnet Labs - Original Message Subject: New Version Notification for draft-mekking-dnsop-auto-cpsync-00 Date: Tue, 29 Jun 2010 06:12:35 -0700 (PDT) From: IETF I-D Submission Tool idsubmiss...@ietf.org To: matth...@nlnetlabs.nl A new version of I-D, draft-mekking-dnsop-auto-cpsync-00.txt has been successfully submitted by Matthijs Mekking and posted to the IETF repository. Filename: draft-mekking-dnsop-auto-cpsync Revision: 00 Title: Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE Creation_date: 2010-06-29 WG ID: Independent Submission Number_of_pages: 6 Abstract: This document proposes a way to synchronise existing trust anchors automatically between a child zone and its parent. The algorithm can be used for other Resource Records that are required to delegate from a parent to a child such as NS and glue records. The IETF Secretariat. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMKfL6AAoJEA8yVCPsQCW5MA8IALsVN2C0raqTybHDtdWqkS19 uOeKyTP7HvJXXYNbRwbITjDzTyx1aFWuNV+JGou16vlXyJY4gK0Ob3Y6P9aum/L3 LvCD/6ekPDL4VxwoJFwq1GsudBnNGN9UeO8IK1R2gNmraEiGAcJ7imovc5+YW5wy Ihk0t5hEAfhgk/2Nr6pguZBxfz2bbpAyBBaZd0uyLBszwnKNWKLVoWxDpBhfOwgA MOWB9owHodjRa6yrJlNJ0IBvdwhC+SyIWyptAwRR810wE3slzYS8xOk1Uvd7a8lF cVeint1z/KxFCPvY69UsnFoOpmgrNwG6cmw8Zg5SEfDpHlswfsbn2BNSo6B07FE= =0u03 -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13
On Thu, Jun 17, 2010 at 01:15:06PM +0200, Peter Koch wrote: (2) is covered in the IANA considerations section but while that section refers to a formal policy it does not offer guidance for review. We should capture the considerations from the most recent as well as previous discussions like this: Additions to the registry will not have and instantly relieving effect on those authoritative servers otherwise targetted with the queries to locally served zones, it can be expected that implementations will refresh the list of zones to serve occasionally or based on their update cycles. For the same reason it can not be expected that deletions from the registry will allow the removed domain name to be resolved on the public Internet any time after such removal. ANY TIME?? ever? how about ... deletions from the registry will allow the domain names to be resolved on the public Internet at some reasonable time after removal from the registry. Regarding (3), while it is useful to seed the registry as broad as possible, it is safe to err on the side of refusal that to poison a prefix by essentially making it non-reverse-mappable. That said, there is consensus to drop section 4.7 and not to add the ORCHID prefix (resp. its reverse mapping domain name) to the registry. On a more editorial side, the document should state its threefold purpose in the introduction. The -14 version should then be ready to go to the AD together with the two AS112 drafts as a bundle, meking the cross references resolvable. -Peter (with hat and Stephen's advice) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13
On Mon, Jun 14, 2010 at 07:51:14PM -0700, Paul Hoffman wrote: At 12:12 PM +1000 6/15/10, Mark Andrews wrote: In message p06240867c8385b270...@[10.20.30.158], Paul Hoffman writes: At 4:23 PM -0400 6/11/10, Derek Diget wrote: Raising hand timidly In this group!? :-) Instead of listing the zones in section 4 (which then will get hard coded into implementations), follow section 6 and register the zones in the new/to-be-created IANA assignment registry. This will force implementations to go look at the assignment registry and maybe more aware of the dynamic nature of some of these zones. As the draft is now, some implementors probably will stop reading after section 5. :( Good call. +1 The zone listed are intended to be stable enough in usage that they can be frozen in code. Zones added to the registry should be of a similar level of stability. It would be a very rare event for a zone to be removed from the registry and it would take decades, if ever, that the zone would be untainted. Probably true, but not relevant to the discussion. The idea is to force implementers to look at the registry so that they see *future* additions to it, even if they get there from reading this RFC-to-be. --Paul Hoffman, Director --VPN Consortium I'll note in passing that the Martian prefix list took less than 30 days to be declared valid to use prefixes and it has taken decades to eradicate them as Martians (by killing off code which chose to freeze them because of the stability of classful addressing)... there are still vestigages of this cruft around. I can not and do not share Marks naive presumptions about the stability of prefix use. Guess I've been burned by that assumption twice - don't want to be bit by it a third time. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BIND use of compiled defaults
On Tue, Jun 08, 2010 at 02:52:01PM +1000, Mark Andrews wrote: The zones are consistant with RFC5735 and with operational practice. So the question - how common do we expect /32 delegations to become in futur e? From IN-ADDR.ARPA or from some other zone to handle /25-/32 sized delegations without using the techniques in RFC2317? I know there are people that argue that one shouldn't do RFC2317 style delegations so for the latter I would say a lot. For the former I don't expect any unless we create special purpose blocks smaller than /24. if you allow 255.255.255.255.in-addr.arpa. -AS A ZONE- then i am much more confortable shreding a /24 into 255 component zones - RFC2317 is designed to do a cut in the in-addr.arpa space on non-octet alined boundaries and since you have demo'd (other than me) the use of a zone cut on octet bounds lt /24, I'm a happy camper. --bill Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones and the former IP6.INT.
as the admin for ip6.int. the IPv6 wg declared that ip6.int should be terminated on 6/6/06 - along with the 6bone. David Conrad removed the delegation shortly there after, even though there are still resolvers which look for that delegation instead of the ip6.arpa zone - which functions as its replacement. I had proposed using the DNAME construct to allow the 10+ years of resolver code that was/is using ip6.int to continue to function well ... but this idea was rejected by the IANA. --bill On Tue, Apr 06, 2010 at 03:22:59PM +0200, Alfred Hvnes wrote: Folks, skimming over your most recent Locally-served DNS Zones I-D, draft-ietf-dnsop-default-local-zones-11, I got stuck in section 5. The 4th paragraph of that section in the draft says: | This document also ignores IP6.INT. IP6.INT has been wound up with | only legacy resolvers now generating reverse queries under IP6.INT | [RFC4159]. I had some vague recollection that IP6.INT had gone out of service quite some time ago, and started over to verify that. A copy of the INT zone is no more made available online via FTP, but I have checked all authoritative name servers for INT., and they indeed all consistently respond with NXDOMAIN to any query for IP6.INT. Recollection starts to leak after 4 years, and for an uninitiated reader, the phrase has been wound up seems to be rather ambiguous. I'd prefer the draft to state the facts more precisely so that the conclusion drawn can be better understood. Proposed strawman replacement for above clause: |This document also ignores IP6.INT, which initially hosted the IPv6 |reverse DNS tree but does not exist any more, after it had been |demissed by [RFC4159]. IP6.INT has been wound up with only legacy |resolvers now generating reverse queries under IP6.INT. Kind regards, Alfred. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] FYI: DNSOPS presentation
On Wed, Mar 31, 2010 at 11:26:53PM -0700, Christopher Morrow wrote: On Wed, Mar 31, 2010 at 1:55 PM, Dan Wing dw...@cisco.com wrote: But Remi's point is that those same systems (running Windows XP and IE6) using 6rd will be denied the ability to access content via IPv6. Which removes an incentive for ISPs to add 6rd (and offload the NAT44 they may soon have to install). I'm not sure this is true: o the end-station sends a dns query to the ISP recursive resolver o the recursive resolver uses whichever protocol is 'best' for the lookup (assuming something like BIND's NS RTT caching happens in the majority of cases) o if the query goes over ipv6, is for a , a response could be returned o if the query goes over ipv4, is for a , no response is returned and presumably a follow-up A query happens. Igor/Yahoo are proposing that recursive resolvers which have v6 transport use it and be rewarded for doing so... if they have a longer/worse path over ipv6 there's a good chance the user experience will also suffer, so the users should use v4. but the ISP recursive resolver has no clue what the end-station (stub) is going to do with the result of the lookup. nor does if have any idea what proxies or forwarders are in the interviening path between it and the stub. it might look at the transport it received the query on (from the stub), cache that information, and then recursively ask the authoritative servers for the data (using whichever transport is best for the specific lookup to the authoritative server in question), then send the response back to the stub - weighting the response data based on the transport the stub asked the query on. regardless of how I (the stub) ask the recursive my question, (via IPv4, IPv6, DECNETPhaseV, NCP, bisync...) the recursive should give me what i ask for ... if i want answers then give me answers, even if you get the query over LU6.2. Don't confuse DNS data with transport. --bill -chris -chris ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [f...@cisco.com: RFC 5006 status]
- Forwarded message from Fred Baker f...@cisco.com - This is a structured question for the community. Jari Arkko tells us that he is getting requests from various sources to take RFC 5006 to Proposed Standard. It is now experimental. http://www.ietf.org/rfc/rfc5006.txt 5006 IPv6 Router Advertisement Option for DNS Configuration. J. Jeong, Ed., S. Park, L. Beloeil, S. Madanapalli. September 2007. (Format: TXT=26136 bytes) (Status: EXPERIMENTAL) (1) Please take a look at the document in the next few days; if you have comments on it (eg, you think it should be changed in some way), please comment to v6ops. (2) Vendors, please advise on implementations. Are there any? Has interoperability been demonstrated? (3) Operators, enterprise and/or service provider, please advise on deployment experience. I'm adding a brief discussion to the agenda Monday morning with a view to getting a quick thumbs-up/thumbs-down to advise Jari, who can then take that to 6man later in the week if appropriate. BTW, I have had a flurry of email related to the agenda. The current agenda may be found at http://www.ietf.org/proceedings/10mar/agenda/v6ops.html - End forwarded message - morning folks... any thoughts on this draft changing status? --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] bar-bof - DSauto?
On Thu, Mar 04, 2010 at 08:11:13AM -0500, Edward Lewis wrote: At 4:30 + 3/4/10, bmann...@vacation.karoshi.com wrote: I'd like to suggest monday - 1500-1700 We can talk then, but the wheels were in motion to put it on Wednesday. The reason for that was the crowd coming for the Escrow BoF has a good grip on the requirements (which is needed before figuring out the mechanism). great! i suspect that both slots would be productive. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] automatic update of DS records
On Tue, Mar 02, 2010 at 10:04:46AM +0100, Wolfgang Nagele wrote: Hi, granted that this discussion is important and folks interested in this might be at the IETF77, could we either have a bof (formal) or a small lunch mtg during the week of IETF77? I'd be glad to attend. There has been interest in this at least since IETF75. Anyway, a BoF is a good idea. I will not be in Anaheim since the DURZ roll-out for K is in that week. However Matthijs (in CC) has done the heavy lifting on the current draft and is going to be there and he agreed to attend the BoF. Cheers, Wolfgang long before IETf75... :) looks like a BOF is out of the question (too late) .. will have to be informal. and good luck w/ the DURZ --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] automatic update of DS records
On Tue, Mar 02, 2010 at 08:05:38PM +, Alex Bligh wrote: Ed, --On 2 March 2010 14:39:45 -0500 Edward Lewis ed.le...@neustar.biz wrote: Telling someone one to change the name server from ns1.example.tld. to newdns.example. or 127.0.10.2 to 192.0.2.3 is easier than saying change something from: 94DC01F2763CCB12F4B66AC63910830BC34082F6FE95CD75DAA3C5B37F99DD81 to: 6CDE2DE97F1D07B23134440F19682E7519ADDAE180E20B1B1EC52E7F58B2831D So, if the registrar is running DNS, then he pushes the DS keys directly using EPP or whatever. And the problem arises, if I understand it right, when someone other than the registrar (or for that matter the registry) is generating the information that goes in the DS record. And whilst nameservers (for instance) are likely to be static, this is relatively volatile. My concern is that whatever automatic update mechanism you choose has to use some greater level of security than merely relying on the zone being signed. So to pick a trivial example _DSKEY IN TXT [blob] isn't going work, because if you are changing the DS key because you fear your keys may have been compromised, that can be compromised too. I may be having a failure of imagination but I don't immediately see how without some external authentication (yet another key) you can securely automatedly push DS key changes about. -- hum... maybe I should be hounding Ed on this... but I think we should draw a bright line... we are (imho) talking about pushing DS records from child to parent. entirely w/in the perview of the DNS protocol/wg. for non-DNSprotocol players (registries/registrars/registrants) that use EPP or its varients for pushing DNS data around - thats not w/in scope. at least for this WG's consideration. --bill ___ 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 01:40:53PM +1300, Jay Daley wrote: there is a problem w/ cut/paste ... surely we could do better than that? I'm sure we could and an automated update of DS records is a good idea. But my point is that in the absence of a similar automated mechanism for NS records we use cut and paste and it works fine and there is nothing about DS records that is any more complicated so cut and paste would work fine there too. Jay the trick there is that an NS update is somewhat humanly parsable. if a cut/paste cocks up, its fairly easy to tell. in my limited experience, DS records are not quite as humanly parsable and a cut/paste error is more likely to slip through. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Hues
On Tue, Feb 23, 2010 at 07:09:12AM -0800, Todd Glassey wrote: As I have said, there is no difference between this and the Jim Crow actions which separated blacks from the white population in then US and the application of the concept of racially unfit parties as Trolls within the IETF, which also of course brings us to the question of how many people of color are management within the IETF?. Have a nice day. Todd Glassey Why thank you, I will. And the same to you. In answer to your question; how many people of color are management within the IETF? I think I have an answer for you. All of them. No person that I am aware of in the ietf management chain are transparent - all reflect light at various points on the spectrum. With this information, you may now make the claim that the IETF management is opaque, lacking transparency... and you would be technically correct. any other little questions bothering you that we might help with? --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
thanks paul. That might be draft-hoffman-dnssec-ecdsa. I let it expire earlier this month because the DNSEXT WG is still not clear on the allowable statuses for crypto documents, but have today revived it based on your comment. If you don't consider this to be a good draft, I am quite open to suggestions for improvement! --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Priming query transport selection
On Wed, Jan 13, 2010 at 09:53:16PM +, Jim Reid wrote: On 13 Jan 2010, at 21:35, Alex Bligh wrote: You've eliminated TCP fallback for non-DNSSEC supporting clients. So add that to the list: [6] TCP (no EDNS0) if [5] fails. dnssec is just the first extention to reliably tickle the size/frag issues with large UDP responses. Whatever you blokes come up w/ please don't make it feature specific. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Computerworld apparently has changed DNS protocol
On Wed, Nov 04, 2009 at 11:09:53AM -0800, Nicholas Weaver wrote: Question: Have people been able to estimate how large the signed root zone response will be? I'm assuming its below the magic 1500B level for standard queries. Is this correct? Oh, and one thing to watch out for: Some IP stacks I've noticed will set DF on UDP datagrams, if the datagram is too small to require fragmentation onto the local network! Add this to the list of things DNS operators need to watch out for when turning on DNSSEC. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop David Conrad, ICANN maven and one-time IANA manager, posted some numbers from their DNSSEC testbed a month or so back. Responses were just under 1800 bytes. The current deployment plan is to stage things to push out large responses early - prior to having any actual DNSSEC usable data ... ostensibly to flush out DNSmtu problems. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] Computerworld apparently has changed DNS protocol
cool eh? although I suspect she ment responses. --bill On Wed, Nov 04, 2009 at 07:58:41PM +0100, Alfred Hvnes 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
Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00
On Wed, Oct 21, 2009 at 08:32:49AM +0100, ray.bel...@nominet.org.uk wrote: Mark, I din't think this is true given how the proposed protocol works. For a start, you often cannot fetch the DNSKEY RR for ARPA before running the protocol. Indeed LOCAL.ARPA would need to be unsigned. That needs to be added to the draft. Since (as Bill points out) LOCAL.ARPA would be served much like RFC 1918 space there's no way it could be signed and have the DS key present in the parent, because there will be numerous separate instances of LOCAL.ARPA. well... there are these cases where an island of trust gets its DS keys treated as a SEP and folks configure them anyway. and I'm sure we can get some kind folks to ensure that no one -EVER- shares a trusted keys file with others. just saying. --bill In any event the seeding query needs to be sent without the DO bit set, since (some) CPE proxies are known to interfere with that. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00
On Tue, Oct 20, 2009 at 07:38:19PM -0400, Joe Abley wrote: On 2009-10-20, at 19:29, Mark Andrews wrote: ARPA will soon be signed, so I don't think this is much to worry about. If the powers that be finally agree to make NXDOMAIN/NODATA synthesis the default in the upcoming minor DNSSEC revision, this will also help to cut down the number of requests. And LOCAL.ARPA would need to be a unsigned delegation. Could you explain this? The draft under discussion specifies that LOCAL.ARPA is not to be delegated at all, so your sentence above confuses me. Think ... kind of like RFC 1918 prefixes are not supposed to be advertized. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] RSST study is out
http://www.icann.org/en/committees/dns-root/root-scaling-study-report-31aug09-en.pdf --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Key Management and Provisioningl was Re: .PR ...
a few of us actually did a little work in this area three or four years ago - did working proof of concepts - and were promptly ignored. (the claim was - this work was premature) --bill On Tue, Sep 08, 2009 at 01:23:51PM -0400, Edward Lewis wrote: At 13:13 -0400 9/8/09, Paul Wouters wrote: At least for TLD's, we expect this to be fixed in December with a signed root. The root may be signed by then. But I have not seen plans for an interface for the TLDs to use to submit key material. I am not sure what appliance or software setup '.pr' uses, but it should have never allowed to finish the key rollover with the bad key in the ISC DLV. Avoiding addressing just the symptoms, I will say that the most annoying part in documenting SEP supercession is that we have to wave our hands at that point and say when we notice that the $parent has changed the DS record we proceed to the next step. Besides this hand waving, it's impossible to script this into a test plan. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments about draft-morris-dnsop-dnssec-key-timing
On Tue, May 19, 2009 at 02:38:01PM +0100, John Dickinson wrote: Sz sez... Please don't change this. Making finer distinctions in one document, clearly defined, is one thing. But please don't try to change terminology we're finally starting to get people to use; it's been (and continues to be) hard enough to get them to stop talking about one key and the singular act of signing. This was kind of my idea - so maybe I can explain my thinking a bit. I am wondering if this document should restrict itself purely to considering keys and say nothing about what is signed by those keys. Therefore, it would not use the KSK and ZSK terminology. You could have keys with the following set of properties: - how they are rolled (pre-publish or double key) - the SEP bit on or off - bit 7 (zone key bit always set) - bit 8 revoked bit - protocol == 3 - an algorithm - a size - is this key intended to be pointed to by a DS RR? - is the zone operator doing RFC5011? are you going to focus on the key, its intended/expected use or something else (the signatures or the items covered by the signatures...) Some of these properties impact on, or are altered by, timing considerations. for the key... timing is immaterial. only the signature has a temporal consideration. unless you want to equate key visability with time. Some combinations of these properties make useful keys and it may well be best practice to use them to sign particular RRSets. However, I wonder if this draft is the place to comment on that issue - would it be better in a BCP. This draft could just consider the timing considerations for keys with particular (anticipated to be useful) sets of properties and be pointed to by a BCP which says which properties a good KSK, ZSK or anotherSK should have and what RRSets they actually sign. John --- John Dickinson http://www.jadickinson.co.uk I am riding from Lands end to John O'Groats to raise money for Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance
On Tue, May 12, 2009 at 04:28:01PM -0400, Paul Wouters wrote: On Tue, 12 May 2009, Olafur Gudmundsson wrote: Section 3: Priming can occur when the validating resolver starts, but a validating resolver SHOULD defer priming of individual trust anchors until each is first needed for verification. I disagree with this as a SHOULD; may want to is much more appropriate. I see nothing wrong with wanting to get the first round of crypto out of the way at startup. Good point, How about s/SHOULD/MAY want to/ ? I think that would be COULD then i think i am going to weigh in on th eother side of the coin here. I'd posit s/SHOULD/SHOULD NOT/ ... Is there any good reason why validation and resolution need to be in lock-step? --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] dns data exchanged between host and local dns-sever
On Thu, Apr 30, 2009 at 02:15:48PM +0800, madi wrote: Hi, Stephane. To give a countermeasure, the response from a recursive sever might as well be cached in form of both plaintext and ciphertext which is generated by the very recursive server. Thatbcursive server and authoritative name-server is secured by DNSSEC, a similar course should be followed by the recursive sever right after the DNSSEC verification. this presumes that the query to the authoritiative server is not intercepted and replied to by a rogue nameserver -first- the primary benefit to DNSSEC is that it protects the integrity of the data - regardless of where it is coming from. if the cache is corrupted/poisoned, the data will fail to validate - and depending on your validator response - will fail resolution. what is missing/needed here is a way for a validator to mark a recursive server as bad and find/select an alternate server... which is outside the scope of the DNSSEC design. Once the requester, a PC typically, gets the response in dual forms, it can then verify the correlation between them. If so, even the attacker has poisoned the DNS information cache, yet the two forms of poisoned cache, plaintext and ciphertext, could not be in accordance with each other. Consequently, the verification to them by a requester will never pass and then the phishing would be avoided. DNSSEC already does this. With respect to the generation and the distribution of the key for the ciphertext mentioned above, further deliberation is needed. Any critical will be appreciated. 2009-04-30 madi ed;6d::o Stephane Bortzmeyer ei f6i4o 2009-04-23 19:40:15 f6d;6d::o Scott Rose f i o m...@cnnic.cn; dnsop d8;io Re: dns data exchanged between host and local dns-sever On Thu, Apr 23, 2009 at 07:10:13AM -0400, Scott Rose sco...@nist.gov wrote a message of 65 lines which said: Those are the DNS protocol mechanisms in place. There is also lower level security technologies such as IPsec that could be used between stub clients and recursive servers that don't rely on DNSSEC at all. TSIG, IPsec and friends have all the same issue: they check that the response does come from the intended resolver, not that the response is authentic. At a time where any hotel provides Internet access with a lying resolver, this is probably not sufficient. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Key sizes
Yo Joe, many moons back, it was pointed out to me by some cryto folks that there is an interesting relationship btwn key length and signature duration. One could make the argument that for persistent delegations, you might want to ensure longer length keys and possibly longer duration signatures than you might have for a DHCP lease whos's lifetime is 20 minutes. e.g. a leaf assignment that lasts no longer than 20 minutes might not justify the operational cost of a 4096bit key generation/propogation, while a well-known TLD (.JOE) might well justify a 4096bit key. you might say that key length should/could be inversely proporational to the delegation placement in the namespace. but you knew this. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] dns data exchanged between host and local dns-sever
On Thu, Apr 23, 2009 at 06:32:38PM +0800, i),h?* wrote: Hi, folks. As we all know, DNSSEC provides origin authentication and integrity assurance services for DNS data exchanged between DNS resolver and name-sever, while DNSSEC fails to give a means by which the DNS queries or responses transmitted between a host and a recursive server could be guaranteed integrity and authentication. For example, a malicious attacker might hijack the DNS query form a host and fake a response which will help he commit phishing. So I wonder, is there someone having a certain solution, more exactly a software implementation on host, to protect against such attack? 2009-04-23 m...@cnnic.cn As mentioned elsewhere, TSiG, GSS-TSiG, and IPSEC are all forms of channel security. The unfortunate truth is, these are unwieldy when managing large numbers of connections. for a slightly more scaleable solution, you might consider SIG(0). - All of these are defined in RFC's and there are several interoperable implementations. Other channel security ideas that are floating around (but have nto gained traction in the IETF or market) are: EDNS-PING DNS-CURVE --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] dns data exchanged between host and local dns-sever
On Thu, Apr 23, 2009 at 12:52:37PM -0400, Edward Lewis wrote: At 8:43 -0700 4/23/09, David Conrad wrote: root servers). However the point is that you need to do the validation someplace you can talk securely to. The easiest answer is to simply do the validation on the same host. I figure stub resolvers were needed when cpu/bandwidth/memory were a bit more expensive than now. It seems a shame to constrain our architecture to the '80s... OTOH, for the one of the same reasons DHCP is so popular, that is centralized local management, it is desirable (in some instances) to have the validation done in the commons and not in end hosts. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis locus of control. i happen to agree w/ David here. there really is no serious technical hurdle for moving a full-bore DNS IMR into most platforms these days (modulo the RFIDs and some of the IoT stuff). the upsides are huge for mobility, ad-hoc, and temporally disconnected networks. the downsides are the LEOS (protecting our security), and the Shylocks who need to collect what remains of the lunch money. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] MX 0 . standard way of saying we don't do email ?
On Fri, Apr 10, 2009 at 04:19:03PM -0400, Edward Lewis wrote: At 13:04 -0700 4/10/09, SM wrote: This message ( http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00944.html ) and some other messages on the ietf-smtp mailing list could be read as a lack of support for the draft. Don't confuse disinterest with disapproval. ;) -- come on ed, just 'cause you disapproved of sub-typing TXT records... --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt
On Tue, Mar 10, 2009 at 10:27:21AM +0100, Stephane Bortzmeyer wrote: On Mon, Mar 09, 2009 at 01:04:42PM -0400, Andrew Sullivan a...@shinkuro.com wrote a message of 59 lines which said: John's view is that the original alphabetic restriction in 1123 was indeed intended as a restriction, I was not there at the creation but I find it worrying to rely on the recollection of one specific person. The alphabetic-only rule in RFC 1123 is just a side note, never detailed, and presented as a fact (which it was at this time), not as a mandatory restriction. we -could- ask the author of RFC 1123. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02
On Tue, Mar 10, 2009 at 08:35:40AM +1100, Mark Andrews wrote: In message 200903091515.n29ffetp055...@stora.ogud.com, Olafur Gudmundsson wri tes: --===0733757033== Content-Type: multipart/alternative; boundary==_777355448==.ALT --=_777355448==.ALT Content-Type: text/plain; charset=us-ascii; format=flowed At 13:46 06/08/2008, Paul Hoffman wrote: Greetings again. The end of section 2 of this document says: Another advantage of configuring a trust anchor using a DS record is that the entire hash of the public key in the DS RDATA need not necessarily be specified. A validating resolver MAY support configuration using a truncated DS hash value as a human-factors convenience: shorter strings are easier to type and less prone to error when entered manually. Even with a truncated hash configured, a validating resolver can still verify that the corresponding DNSKEY is present in the trust anchor zone's apex DNSKEY RRSet. RFC 2104 [RFC2104] offers guidance on acceptable truncation lengths. This is not correct. You cannot say here is the SHA-256 hash of a value and then give less than 256 bits of the hash. If you wanted to do this, you need to define the truncated hash and use that new hash algorithm. So far, none of these truncated hashes have been defined for DNSSEC, although ones could be defined. Further, it is somewhat optimistic (and possibly sadistic) to think that a user can type Base64 by hand for more than maybe ten characters. This document should assume that the user is using copy-and-paste, and therefore using the full 256 bits of the hash is just as easy as using a truncated hash. If not, new, inherently weaker, truncated hash algorithms need to be defined. --Paul Hoffman, Director --VPN Consortium _ You are not the first person to bring this issue up, and upon reflection we have dropped truncation discussion. Olafur On a related issue DS - DNSKEY translations cannot be performed until the DNSKEY is published in the zone. The use of DS prevents pre-publishing of keys. I can see no real reason to recommend that DS records be published in preference to DNSKEY records. DNSKEY - DS is a conversion that can be at anytime. This make DNSKEY a better manditory record to publish. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop if the child produces the DS, then the TTL is preserved. if the parent produces the DS, then the TTL is not. i'd think that would be a reason to use DS as the record to publish. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02
On Tue, Mar 10, 2009 at 12:55:51PM +1100, Mark Andrews wrote: In message f7c89744-a1ca-4fd6-b793-2f4e337e3...@verisign.com, David Blacka wr ites: On Mar 9, 2009, at 5:35 PM, Mark Andrews wrote: On a related issue DS - DNSKEY translations cannot be performed until the DNSKEY is published in the zone. The use of DS prevents pre-publishing of keys. Huh? You can generate a DS from the DNSKEY record that you have generated but not yet published, so you can pre-publish the DS just as soon as you could pre-publish your DNSKEY. As for actually *using* the DS as a trust anchor, you can't use either the DS or the DNSKEY prior to actually publishing and *using* the DNSKEY. Or maybe I just don't understand your point. When you pre-publish a DS you prevent implementations that use DNSKEYs from taking advantage of that pre-publication. sounds like an implementation bugll --bill When you pre-prepublish DNSKEYs implementations that use DS or DNSKEYs can taking advantage of that pre-publication. I can see no real reason to recommend that DS records be published in preference to DNSKEY records. They are small and easier to eyeball as correct. DNSKEY - DS is a conversion that can be at anytime. This make DNSKEY a better manditory record to publish. I don't follow. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt
does this mean my chances for ^B. are nil? :) --bill On Sat, Mar 07, 2009 at 12:07:01PM +0100, Patrik Fdltstrvm wrote: On 6 mar 2009, at 21.54, Edward Lewis wrote: And, from what I have heard, I believe display issues is at the heart of the problem. I'm sure Patrik is active in the IDNABIS WG. So if it is an issue, he'd have spoken about it. Yes, active there, following this list. Still, seriously, all this aside, I doubt we will ever want manpages.5 as a domain name. I think regarding digits in TLDs (or rather, non-letters), this is the right time when one definitely should have the basic rule to not add something until it breaks, but instead, only add things we do know will not create any harm. And I think within those basic rules, we should just say no to digits in TLDs. Anywhere. Or rather, every character in a U-label in a TLD have to have an explicit directionality. I think it is time to not have a general rule lets add something if not proven that adding will create harm, but instead lets add something only if proven that it absolutely not does create any harm, and then have the people that want certain dangerous characters in there explain why it is safe. Patrik ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Potential root impact of draft-wing-behave-learn-prefix-00
On Thu, Nov 20, 2008 at 12:14:45PM +0100, Florian Weimer wrote: I came across the following in some IPv6-related draft and thought I'd share it. |3.1. Using DNS to Learn IPv6 Prefix and Length | | In order for an IPv6 host to determine if a NAT64 is present on its | network, it sends a DNS query. Because a host doesn't always know | its network's default domain name, the procedure described below | provides a way for the host to learn it in order to authorize that | network's address family translator: | | 1. Send a DNS query for _aft_prefix, without a domain name. | If this does not return an IPv6 address it means a address family | translator is not present and processing MUST stop. [...] | 3. If validation of this information is not necessary, then: | | a. Send a DNS TXT query for _aft_prefix, without the domain | name, to learn the number of bits of the prefix. | [...] | Discussion: without a domain name, it is unavoidable that root | nameservers will see this query. Need to think about ways to | reduce the effect of those queries (e.g., make them authoritative | and return all 0's which will get cached). So they are aware that this is broken. Let's hope that this type of service discovery through a fraction DNS root doesn't make its way into the final standard. would they complain if the roots actually provided an authoritative answer (other than NXDOMAIN) at some point in the future? --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Thu, Aug 28, 2008 at 12:04:15AM -0400, Brian Dickson wrote: The DS may be provided by the operator of the subordinate zone, or built by the parent operator, most likely the latter. thats an interesting premise. why do you think this will be the case? (I would posit that the folks generating the DNSKEY will also want to generate the DS hash on their known, trusted signing tools instead of trusting the parent w/ the DNSKEY materials) Brian --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Fri, Aug 29, 2008 at 10:23:53AM +1000, Mark Andrews wrote: - The parent is already trusted with DNSSEC tools, since the parent is signing the parent's zone (including the DS record!) assuming facts not in evidence. there is active discussion about having unsigned zones w/ DS records included. Well you are not talking about DNSSEC 4035 then. Such DS records are just noise to DNSSEC 4035. Well, i never said I was talking abt DNSSEC 4035. (what is that anyway? DNSSEC as defiend by RFC 4035?) I was talking about who generates DS rr's. Brian postualates the parent is always ready and willing to do so, I disagree, based on empirical evidence. --bill Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
http://publicsuffix/learn/ has more info (and I've just checked in another update, which should be visible in the next day or so. There's a human in the update loop). Gerv ___ that URL does not resolve in the way you might expect. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: Considerations for the use of DNS Reverse Mapping
I'm going to ask this question here too.. are we talking about the DNS or are we talking about an applications use of data published in the DNS? i see this draft in the context of the historical DNS ... it is a mapping service, a name to an address AND an address to a name. the mapping service is OPTIONAL ... the Internet does not now (and should NEVER) depend on this service being available for any other service to work. I think a key point here is that -reciprocity- is and should be highly valued feature of DNS provisioning. that said, if one provisions mapping in one direction, it should also be provided in the other. e.g. label1 == address1 implies address1 == label1 so, if it is legal to have this construct: label == address1 == address2 ... == addressN then this construct should also be legal: address == name1 == name2 ... == nameN what we have is a mess label1 == address1918 address1918 == lable8 which, while technicallu legal, violates the spirit of the lema posited above, as does; label35 == address1918 and address1918 has no matching label. we now return you to your SMTP coloured discussion. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-licanhuang-dnsop-urnresolution-00
On Wed, Dec 05, 2007 at 02:10:52AM +, Lican Huang wrote: If SEARCH outside DNS were full power, then DNS would disappear soon. And all DNS registrar companies would broken out. perhaps you are right. at this point we don't have enough data. What is the difference between www.microsoft.com and www.jksdfjsdfdfsdf.com if they represent for the same address of http page? We can browser the micorsoft's web page through the link of the SEARCH output easily. But if microsoft company used www.jksdfjsdfdfsdf.com for its domain name, then what useful this kind of DNS would exist? at what poiint in time did the string microsoft gain any sort of human memorable meaning? what would have been the result if Bill Gates named his new company jksdfjsdfdfsdf? 25 years later, it would be a globally recognizable mark and you would be arguing over other strings. My opion is that in the future if DNS would survive, DNS must have some reform. you are entitled to your opinion. others are entitled to thier opinions as well. you seem to have failed, this time, to persuade people that adding search to the DNS is a wise prudent thing for the evolution of the protocol. im my own case, having implemented rudimentary search in the DNS - i can't recommend it for anyting other than as an interesting academic exercise. the pieces you have written drafts about fail to include a key, critical component of a DNS with Search capability. Still, an interesting stab at a perceived problem. It might make more sense if you actually had all the required peices documented. --bill [EMAIL PROTECTED] wrote: On Tue, Dec 04, 2007 at 04:27:06AM +, Lican Huang wrote: When Ipv4 addresses will be Exhausted in the near future and the next generation Intenert( Ipv6) will take over, DNS names will also be exhausted soon with the increase of hosts and users. Lenny Foner has pointed other disadvantage in the today's DNS. Please see the section of What's broken? in the article of Lenny Foner in http://www.cfp2000.org/workshop/materials/projects-dns.html. Full IPv4 utilization and increasing use of IPv6 is completely orthonginal to DNS label exaustion. Some have argued that all the good names are taken; e.g. the DNS is exausted. This was first proposed in 1996 (to my memory) yet more than a decade later, we see that the domain name system is robust and growing. With the inherent hierarchical structure of the DNS lable, the mathmatical upper bound is pretty high and we are no where near DNS name exaustion. If you have actual data indicating otherwise, I'd love to see the studies. Domain Names in DNS must have some human-understanding meaning it, otherwise, we can just use IP addresses or numerials for the names. In other words, if we use human-not-understanding Names in DNS, the DNS system can be throwed away. The draft namespace is different with the today's DNS namespace. But, due to the exhaustion of Names in DNS in the near future, The DNS will add new domains. Why adding new domain names with semantic meaning in the future? DNS names do not -HAVE- to have human understandable components. In many cases, this is highly desired -BUT- is not required for use. And yes, numeric literals have been used in the past. Use of the IP address instead of the name is one of the failures of application design. The IP address indicates WHERE a node is in the Internet topology, not the identity of the node. The Name is the indicator of the node IDENTITY. the DNS maps names to addresses and makes no assurance as to the human friendliness of the name or the reachability of the address. Your assertion that the DNS system can be thowed away is vacuously true. If you find it non-useful, there is no requirement for you to use it. Many people use the DNS to get a lable, memorable or not, and then use other tools to map that lable into something meaningful... e.g. SEARCH. It does not invalidate the use of the DNS in any way. This draft can be used for search the locatons of the resources if the DNS using classified hierarchical Domain Names. I think I prefer SEARCH to be outside the DNS (having actually built a varient of the DNS which supported regular expression expansion of the ? and * characters...) Your milage will vary. --bill Mohsen Souissi wrote: I have read the I-D as well and I second Joe's point of view and his arguments below. Mohsen. On 03 Dec, Joe Abley wrote: | Hi, | | I have read your draft, draft-licanhuang-dnsop-urnresolution-00. | | The question was raised just now in the dnsop working group meeting in | Vancouver as to whether the content of this draft was suitable for | adoption as a working group item. The question was triggered
Re: [DNSOP] draft-licanhuang-dnsop-urnresolution-00
On Tue, Dec 04, 2007 at 04:27:06AM +, Lican Huang wrote: When Ipv4 addresses will be Exhausted in the near future and the next generation Intenert( Ipv6) will take over, DNS names will also be exhausted soon with the increase of hosts and users. Lenny Foner has pointed other disadvantage in the today's DNS. Please see the section of What's broken? in the article of Lenny Foner in http://www.cfp2000.org/workshop/materials/projects-dns.html. Full IPv4 utilization and increasing use of IPv6 is completely orthonginal to DNS label exaustion. Some have argued that all the good names are taken; e.g. the DNS is exausted. This was first proposed in 1996 (to my memory) yet more than a decade later, we see that the domain name system is robust and growing. With the inherent hierarchical structure of the DNS lable, the mathmatical upper bound is pretty high and we are no where near DNS name exaustion. If you have actual data indicating otherwise, I'd love to see the studies. Domain Names in DNS must have some human-understanding meaning it, otherwise, we can just use IP addresses or numerials for the names. In other words, if we use human-not-understanding Names in DNS, the DNS system can be throwed away. The draft namespace is different with the today's DNS namespace. But, due to the exhaustion of Names in DNS in the near future, The DNS will add new domains. Why adding new domain names with semantic meaning in the future? DNS names do not -HAVE- to have human understandable components. In many cases, this is highly desired -BUT- is not required for use. And yes, numeric literals have been used in the past. Use of the IP address instead of the name is one of the failures of application design. The IP address indicates WHERE a node is in the Internet topology, not the identity of the node. The Name is the indicator of the node IDENTITY. the DNS maps names to addresses and makes no assurance as to the human friendliness of the name or the reachability of the address. Your assertion that the DNS system can be thowed away is vacuously true. If you find it non-useful, there is no requirement for you to use it. Many people use the DNS to get a lable, memorable or not, and then use other tools to map that lable into something meaningful... e.g. SEARCH. It does not invalidate the use of the DNS in any way. This draft can be used for search the locatons of the resources if the DNS using classified hierarchical Domain Names. I think I prefer SEARCH to be outside the DNS (having actually built a varient of the DNS which supported regular expression expansion of the ? and * characters...) Your milage will vary. --bill Mohsen Souissi [EMAIL PROTECTED] wrote: I have read the I-D as well and I second Joe's point of view and his arguments below. Mohsen. On 03 Dec, Joe Abley wrote: | Hi, | | I have read your draft, draft-licanhuang-dnsop-urnresolution-00. | | The question was raised just now in the dnsop working group meeting in | Vancouver as to whether the content of this draft was suitable for | adoption as a working group item. The question was triggered by the | presence of dnsop in the draft name. | | I have read your document. I do not believe it is a suitable basis for | a dnsop working group item. Specifically: | | 1. The document describes a namespace which is substantially different | form what is available in the DNS today. The existing DNS namespace is | not addressed at all. | | 2. The document seems to address an extension to (or an application | for) the protocol described in draft-licanhuang-dnsop-distributeddns, | which (to this reader) seems clearly not to be the DNS, at least any | conventional meaning of that term. - Support the World Aids Awareness campaign this month with Yahoo! for Good ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 LOA?
On Wed, Nov 28, 2007 at 08:15:51AM -0500, Joe Abley wrote: On 27-Nov-2007, at 10:23, Paul Vixie wrote: [EMAIL PROTECTED] (Warren Kumari) writes: ... What do people think about setting up a legal entity called RSTOA that would then perform some very simple checks before handing out a LOA? RSTOA is an existing unincorporated association. you can ask it to do this kind of thing. just find any root name server operator and make your case. (a convenient list of same can be found at http://www.root-servers.org/ .) So, would it be possible for one or more of the root server operators to prepare a generic-yet-official-looking LOA on suitable letterhead and perhaps stash it on www.root-servers.org somewhere? Such an LOA would probably be less remarkable to your average transit provider; the response to here's a signed LOA as a PDF is certainly likely to be more useful in practice than here's an un-signed ASCII text file filled with legal boilerplate which really is an LOA, honest. I can suggest the kind of text I think is needed off-line if that seems useful. [I copy the list on this so that it doesn't appear that the thread ended over-abruptly in the archive.] Joe ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop Sure... It should be there shortly. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: L-Root address change [Re: [DNSOP] AS112 for TLDs]
On Wed, Nov 28, 2007 at 10:58:17AM -0500, Matt Larson wrote: On Wed, 28 Nov 2007, Peter Koch wrote: On Tue, Nov 27, 2007 at 02:35:29PM -0800, John Crain wrote: Currently about 60% New IP to 40% old IP... and rising slowly So clearly a lot of folks still need to up date their hints files :( part of that traffic will be due to old hints files, but priming was actually supposed to accelerate the migration. 40% of total L traffic seems a bit much for 1/13 of the priming traffic? Why old root server IP addresses recieve so much traffic is a great mystery and has been for several years. We addressed this in 2004 in the Life and Times of J-root presentation for NANOG 32: http://www.nanog.org/mtg-0410/pdf/kosters.pdf Note that at the time, I fingerprinted the responsive queriers and many were late-model BIND, all of which are known to prime. As I write this, J root's old IP address is receiving 1000 queries per second and that's over five years after we changed its address. Perhaps this is some sort of DNS equivlanet to cosmic background radiation, dating back the beginning of the Internet? Matt and perhaps more interesting, the old address for B showed a tapering off of traffic and then an INCREASE last year. Old L and J got their numbers less than a decade ago. ... so i would not go back as far as the begining of the Internet. Old B has been around for quite a while longer. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: L-Root address change [Re: [DNSOP] AS112 for TLDs]
On Wed, Nov 28, 2007 at 05:15:59PM +0100, bert hubert wrote: On Wed, Nov 28, 2007 at 04:07:59PM +, [EMAIL PROTECTED] wrote: and perhaps more interesting, the old address for B showed a tapering off of traffic and then an INCREASE last year. Old L and J got their numbers less than a decade ago. ... so i would not go back as far as the begining of the Internet. Old B has been around for quite a while longer. The increase in traffic might easily be due to more favourable connectivity to 'B', which would lead many resolver implementations to shift more queries to it. Bert old B topolgy didnt change... :) --bill ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: B-Root address change [Re: [DNSOP] AS112 for TLDs]
On Wed, Nov 28, 2007 at 05:28:47PM +0100, bert hubert wrote: On Wed, Nov 28, 2007 at 04:22:41PM +, [EMAIL PROTECTED] wrote: The increase in traffic might easily be due to more favourable connectivity to 'B', which would lead many resolver implementations to shift more queries to it. Bert old B topolgy didnt change... :) Admittedly, you have a far better view of the internet than I do :-) - But I'm not ruling out changes *other* people made to their networks. Also, perhaps the other roots just became less attractive. Bert the increase in queries occured after we stopped running a nameserver on the address and more than a year after the public announcement and change in the hints files. not saying other topology change didn't have the effects you describe, it just seems odd. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Always registering the IP address of the name servers during a delegation?
On Tue, Nov 27, 2007 at 01:18:04PM -0500, Edward Lewis wrote: At 5:59 PM + 11/27/07, [EMAIL PROTECTED] wrote: so WHO is the owner of that IP data, the zone admin for example.org or the machine admin for ns1.example.org? The zone admin for sure. It is the registration of the domain name that is specifying the address records of the name servers. then we have a small issue... you as zone admin, can't dictate which IP's i must use on my machines, since you don't control my connectivity. as zone admin, your job is to provide accurate mapping betwn lable and address ... the extent of your influence is over the lables used, not their IP addresses. The reason I say for sure comes from an experience of Harald Alvestrand. (I can't find a URL referencing the problem.) Some years ago one of his slave servers was in a domain whose registration expired and was taken up by a different registrant. Had he registered the IP address of the slave he intended to be using, it would have been easier to debug why every Nth query seemed to get answered incorrectly. historically, the HOST has had an independent admin, precisely because they control the IP's used by the machine, not the zone admin. Historically, we didn't worry about domain name registrations changing hands. Historically, we did worry. We also worried about changes in topology. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Think glocally. Act confused. ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Always registering the IP address of the name servers during a delegation?
On Tue, Nov 27, 2007 at 01:03:59PM -0800, David Conrad wrote: Bill, i have a zone, example.org and chose the following nameservers: moe.rice.edu ns.isi.edu PDC.example.org as the admin of PDC.example.org, I know what IP addresses are assigned and can change them on whim. However, It is the Height of Arrogance to presume I can tell the rice.edu or isi.edu people what IP addresses to use on their machines. Presumably (assuming we're talking about professionally run infrastructure), there is an agreement between the zone administrator and the providers of secondary services. The IP addresses in use for the secondary service should be part of that agreement. Regards, -drc there may be some debate as to how much information is subject to contractual binding. I would hate to be bound to a multiyear contract w/ CSC for nameservice that tied me to one of their old IP blocks. Net 10 is used in so many more places these days. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 LOA?
On Mon, Nov 26, 2007 at 01:26:00PM -0500, Warren Kumari wrote: On Nov 26, 2007, at 11:48 AM, Joe Abley wrote: I don't have strong feelings about whether the LOA in an RFC idea is plausible, or even good, but I thought I'd throw it out anyway. If there was consensus that such a document was worthwhile, I'd happy to do the legwork (and it'd be sufficiently brief in content and purpose that I could imagine it being thrown up to the IESG fairly swiftly). I think it sounds like an excellent idea -- I think that you may still have some issues getting providers to accept it, but hopefully way fewer issues than you would otherwise... The other option would be to actually create a legal entity called Root Server Technical Operations Assn and have some way of automatically generating LOA's (maybe a web form that generates a PDF!), but this sounds like it may be a bad idea... W Comments and opinions welcome :-) Joe humph I think this is a surefire way to poison this prefix forever. if the IETF is the body holding the delegation, then they would be able to sign the ROA... otherwise, the body holding the prefix (paying the bills) will be signing the ROA... the system is not prepared to deal w/ anonymous roll/shell accounts. (see the RBN mess) so, i'm not persuaded that this si a smart or wise idea. its hardcoding another special use prefix in millions of places all over the net. that said, i;m sure it will be seen as a provident/prudent way forward and there will be herds of folks lining up in support. good luck :) --bill ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-01
On Fri, Jun 08, 2007 at 02:57:35PM +1000, Mark Andrews wrote: I also concur with the various protests against using . for the RNAME, and would suggest instead nobody.localhost. along with a ref to 2606. That should be sufficiently clear to any human who looks at it, and also meets the goal of not providing any useful data to a spam bot. Not nobody.invalid.? [EMAIL PROTECTED] is likely to be a real mailbox. [EMAIL PROTECTED] should bounce. why do you think so? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-01
On Thu, Jun 07, 2007 at 07:18:01AM -0400, Joe Abley wrote: On 7-Jun-2007, at 01:20, Mark Andrews wrote: Show me the xml. There should be a way to do a table. t list t0.IN-ADDR.ARPA /* IPv4 THIS NETWORK *//t t127.IN-ADDR.ARPA /* IPv4 LOOP-BACK NETWORK *//t t254.169.IN-ADDR.ARPA /* IPv4 LINK LOCAL *//t t2.0.192.IN-ADDR.ARPA /* IPv4 TEST NET *//t t255.255.255.255.IN-ADDR.ARPA /* IPv4 BROADCAST *//t /list /t There is a way to do a table: texttable ttcolZone/ttcolttcolDescription/ttcol c0.IN-ADDR.ARPA/c/cIPv4 THIS NETWORK/c c127.IN-ADDR.ARPA/ccIPv4 LOOP-BACK NETWORK/c c254.169.IN-ADDR.ARPA/ccIPv4 LINK LOCAL/c c2.0.192.IN-ADDR.ARPA/ccIPv4 TEST NET/c c255.255.255.255.IN-ADDR.ARPA/ccIPv4 BROADCAST/c /texttable There are details in http://xml.resource.org/authoring/draft-mrose- writing-rfcs.html (see section 2.3.1.4). JoeA to borrow a phrase: I'm too young for nroff and too old for xml... I'm generation V(i)! --bill ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?
On Thu, Jun 07, 2007 at 10:24:41AM -0400, Andrew Sullivan wrote: On Thu, Jun 07, 2007 at 10:20:33AM -0400, Thierry Moreau wrote: OK, 0.02 worth of unsupported personal attacks against me. Out of topic. Counter-productive. Not worth replying. Perhaps the next time you think something is not worth replying to, you could follow that conclusion with what would seem to be the obvious non-action? A -- Andrew Sullivan 204-4141 Yonge Street actually, the key point here is that apparently a number of (good) people are avoiding the IETF process because they believe their ideas, intended to be partof open standards development, are being patented by others and then used as leverage to force particular outcomes. Such beliefs are corrosive and distructive to the IETF process and it is not clear how such concerns could be avoided in todays environment. So work is being done outside the IETF, where there is trust. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Best Practice document on local copy of the root zone?
On Sat, Feb 10, 2007 at 09:50:43PM +0100, Paul Wouters wrote: On Sat, 10 Feb 2007, Pekka Savola wrote: As Bert mentioned in the next message, the risk of outdated (and therefor out-of-sync) roots is real. I just compared the root zone as RedHat shipped it on Fri 07 Sep 2001, with the root zone as published on root-servers.org, and only B and J are different. So even using a 6 year old root zone will work fine in the case of a flat out successfull attack against all root servers. I will buy a beer for everyone on this list who doesn't have 6 year old or newer root zone lying around within two hops of their desktop. Paul really? there have been several new TLDs added in the past few years and dozens of glue changes. I'd posit that the root zone of six years ago is quite a bit different than the root zone of today. and if B J are different that A,C-I,K-M, then this should only be due to rounding error of a few hours. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
