Bash : command line with optional arguments

Your quoting is wrong. When you write $CMD with no quotes, the value of $CMD is broken up into “words” at each whitespace sequence¹ (the words can contain any non-whitespace character including punctuation), and then each word undergoes globbing (i.e. wildcard expansion). Note that quotes in the value of CMD, in particular, are untouched: quotes have a meaning in the syntax of shell scripts but not in variable substitution. After this, the first word becomes the name of the command to execute, and subsequent words are the command's arguments.

In your example, assuming $KEYNAME is somekeyname and $HZID is somehzid, then the command and arguments are:

./dnscurl.pl
--keyname
$KEYNAME
--
-X
POST
-H
"Content-Type:
text/xml;
charset=UTF-8"
--upload-file
/tmp/file.xml
https://route53.amazonaws.com/2010-10-01/hostedzone/somehzid/rrset

Note that text/xml; appears as the first non-option argument; clearly the Perl script passes that argument down to curl. The -- in the argument list is unrelated to your problem.

There's no way to stuff a command line into a variable. A (simple) variable is the wrong tool for that: it contains a string, but a command line is a list of strings (the command, and its arguments). You can stuff a command name and its argument into an array variable:

CMD=(./dnscurl.pl --keyname "$KEYNAME"  --
     -X POST -H "Content-Type: text/xml; charset=UTF-8"
     --upload-file /tmp/file.xml
     "https://route53.amazonaws.com/2010-10-01/hostedzone/$HZID/rrset")
RESULT=$("${CMD[@]}")

The strange-looking syntax "${CMD[@]}" expands the array variable CMD to the list of words in the array. The double quotes prevent expansion of words inside the array, and [@] is needed for historical reasons to tell the shell that you want to expand an array.

Another way to remember a command line, or an arbitrary shell snippet, for later use, is a function.

cmd () {
    ./dnscurl.pl --keyname "$KEYNAME"  -- \
                 -X POST -H "Content-Type: text/xml; charset=UTF-8" \
                 --upload-file /tmp/file.xml \
                 "https://route53.amazonaws.com/2010-10-01/hostedzone/$HZID/rrset"
}
RESULT=$(cmd)

¹ _{More precisely, according to the value of IFS.}

You're interpreting the man page wrong. Firstly, the part about -- signalling the end of options is irrelevant to what you're trying to do. The -c overrides the rest of the command line from that point on, so that it's no longer going through bash's option handling at all, meaning that the -- would be passed through to the command, not handled by bash as an end of options marker.

The second mistake is that extra arguments are assigned as positional parameters to the shell process that's launched, not passed as arguments to the command. So, what you're trying to do could be done as one of:

/bin/bash -c 'echo "$0" "$1"' foo bar
/bin/bash -c 'echo "$@"' bash foo bar

In the first case, passing echo the parameters $0 and $1 explicitly, and in the second case, using "$@" to expand as normal as "all positional parameters except $0". Note that in that case we have to pass something to be used as $0 as well; I've chosen "bash" since that's what $0 would normally be, but anything else would work.

As for the reason it's done this way, instead of just passing any arguments you give directly to the command you list: note that the documentation says "commands are read from string", plural. In other words, this scheme allows you to do:

/bin/bash -c 'mkdir "$1"; cd "$1"; touch "$2"' bash dir file

But, note that a better way to meet your original goal might be to use env rather than bash:

/usr/bin/env -- "ls" "-l"

If you don't need any of the features that a shell is providing, there's no reason to use it - using env in this case will be faster, simpler, and less typing. And you don't have to think as hard to make sure it will safely handle filenames containing shell metacharacters or whitespace.