An internal DSL is just a particular idiom of writing code in the host language. So a Ruby internal DSL is Ruby code, just written in particular style which gives a more language-like feel. As such they are often called Fluent Interfaces or Embedded DSLs. An external DSL is a completely separate language that is parsed into data that the host language can understand.
I see DSLs as having two main benefits.... The most interesting benefit, however, is that a well designed DSL can be understandable by business people, allowing them to directly comprehend the code that implements their business rules.
Like minicomputers of old, I can program my microwave by entering programs on its keypad. Unlike minicomputers of old, those programs are not Turing Complete. My microwave has a domain specific language which allows me to control the amount of microwaves it emits and the length of time it emits those microwaves. There are some complications; you have to get the order of operations right (first time, then power), and the syntax for entering times is slightly complex (two-digit values are in base 10, while three digit values are in base 60). Yet it's also simple enough that non-programmers can use the device regularly without realizing that they're writing simple programs.
Now imagine that they had to program my microwave by using a fluent interface written in a general purpose host language. Suddenly the two-digit/three-digit assumption for base switching is inappropriate; there may or may not be a time context in which to interpret numbers, for one thing, and a leading zero may imply the use of octal as it does in many C-like languages.
While there may be an easy and obvious way to reheat chicken parmesan with this fluent interface, there may be multiple effective ways to count the time, and the syntax and semantics of seemingly equivalent programs may differ in efficacy, efficiency, and side effects. Of course, it may be easier to reheat pizza, where a minute at half power and thirty seconds on full power is most effective -- you could make a separate function to reheat three slices. (I wish I could.)
You can get the same effect both ways. The important consideration is of benefits and drawbacks.
Martin is completely right that using the language of the domain effectively can help communicate domain concepts clearly between business people and technical people, but I believe he's wrong that a so-called "internal DSL" is effective at doing so.
Because (as people who dislike Perl oft expound) understanding a piece of code requires you to understand the operations and idioms used in the code.
To understand a SQL query containing a join (a declarative domain specific language for managing relational data), you need to understand (some portion of) the relational model. You don't have to understand the indexing algorithm used to select matching rows or the storage format of rows in relations in a persistent medium.
To understand the related procedural code to perform the same query without using SQL, you have to understand the indexing algorithm and the storage format -- or at least how to use API calls to perform those operations. The possible implementation decisions and semantics are much broader.
If Moose had a declarative, compile-time language for declaring classes and attributes, you could compare it to the existing "language", which relies on Perl parsing rules and quoting rules and may rely on order of compilation rules in some contexts.
While I agree that a reasonably skilled participant in a domain may be able to get a rough impression of the business logic expressed in a so-called "internal DSL" -- certainly enough that she may be able to debug blatant logic errors -- the knowledge of the host language's semantics is necessary for a direct comprehension of the implications embedded in that pidgin. You still have an API Town mailing address, no matter how much you want to pretend you live in the wonderful Land of I Can Writed a DSL (unless you want to claim that we're all born with an intrinsic understanding of Ruby's variable/method scoping/shadowing rules and the difference between a Symbol and a String, like some sort of Jungean glossalaia).