As it happens, you can calculate this pretty accurately in AnyDice, it's just a bit tricky to do so efficiently.
A naïve implementation would look something like this:
function: DICE:d to reach TARGET:n from START:n {
if START >= TARGET { result: 0 }
result: 1 + [DICE to reach TARGET from START + ([lowest 1 of DICE] < START)]
}
set "maximum function depth" to 20
output [2d6 to reach 6 from 2]
Unfortunately, if you actually run this code, you'll notice that the resulting graph is obviously truncated at the maximum recursion limit — and worse, trying to increase that limit much above 30 or so will cause the code to time out. The problem is that the calculation is basically branching into two cases at each step, depending on whether the roll is over or under the threshold, and so the calculation time needed to reach n rolls deep grows exponentially as a function of n.
To get around that issue, we can make the code a little more clever:
function: DICE:d to roll below N:n {
result: 1 + ([lowest 1 of DICE] >= N) * [DICE to roll below N]
}
function: DICE:d to reach TARGET:n from START:n {
if START >= TARGET { result: 0 }
result: [DICE to roll below START] + [DICE to reach TARGET from START+1]
}
set "maximum function depth" to 100
output [2d6 to reach 6 from 2]
With this method, we're first using a helper function to calculate the number of rolls needed to get one extra coin, and adding that to the number of rolls needed to reach the target after that. This way, the main function only needs to recurse 1 + TARGET - START times, and while the helper function does recurse deeper, there's no branching involved in the calculation, so the computation time only scales linearly with the number of rolls.
The only downside of this optimized program is that the effects of the (still finite) recursion limit are no longer so clearly visible: whereas the naïve version simply stops rolling dice entirely after n iterations (leading to an obvious peak at n rolls), the optimized version will, in effect, assume that the n-th roll at any given number of coins is always a success, thus subtly skewing the probabilities for events involving n or more rolls.
Fortunately, we can simply cut off that biased tail from the results, e.g. like this:
set "maximum function depth" to 102
output [minimum of 100 and [2d6 to reach 6 from 2]]
This way, all cases where reaching the target would take 100 rolls or more will simply be lumped under "100 rolls" in the output, just as with the naïve code. As long as the recursion depth limit is at least 2 levels higher than the cutoff (to account for the main function call and the inner [lowest 1 of D]), the probabilities below the cutoff will be accurate. (You can verify this by increasing the limit and observing that the results don't change.)
Anyway, the results will look like this (with a cutoff of 50 rolls):
You can easily increase the limit up to, say, 500 rolls, but then the interesting parts of the graph will be squeezed (even more) against the left edge of the screen. A cutoff of 25 to 50 rolls or so looks a lot more readable.
