I guess the cat's outta the bag now, isn't it!

Couple of things:

We are utilizing TXT records, just like domainkeys, and spf, sshfp, et. al. We will be releasing an RFC with the format soon. (But it's very simple) We personally are using a custom developed authoritative name server written in Erlang - for various reasons including scalability, high availability, and because no nameserver available can handle the dynamic nature of our service. (And I just like flexing my Erlang muscles =) We can service thousands of concurrent requests per second currently on extremely limited hardware.

Using an IP address is just as obtuse as a bitcoin address (which is a huge barrier to adoption), and really isn't the point of this service. You lose the address labeling/generation aspect - which is essential to running a business that accepts bitcoin. In other words, I'm not going to tell a new client I met at a tradeshow and sold something to to send payment to xxx.xxx.xxx.xxx, and nobody is going to remember an IP address off the top of their head - that's exactly why we have DNS.

DNSSEC is a long way off for the com and net TLDs. It's also a pain in the ass to implement and adminstration is non-trivial. We're using GPG signing - it's more robust, far easier to implement, and available today. Signing responses prevents any possibility of falling victim to all currently practical DNS attack vectors. (Along with the standard means to address spoofing...random ports and IDs, etc...)

Unfortuantely, libresolv is not available on Win32 platforms (without Cygwin), so we are using a boost library for DNS resolution. This will be implemented as a seperate application that bitcoin/bitcoind will call out to, or you can use by hand. Also there is a fallback mechanism in place: every DNS record also gets an A record that points to our webserver, so if you put the address into a web browser, you will be shown a (pretty) page with the BTC address and a QR representation of the address. Perfect for the eventual advent of mobile payment clients. (That we also plan on offering!)

IMO, there would be little reason not to trust a well-known 3rd party - as the responses are easily verifiable (in real time, you'll know very quickly if you've missed a payment). You can trust a third party with hosting your address records just as much as you can trust Paypal, LibertyReserves, myBitcoin, mtGox, your bank, or anyone really...but if you're that worried, in the future we plan on releasing our entire system as FOSS - so you can host your own after an apt-get and a bit of configuration.

As noagendamarket mentioned, we are finishing completion of this in the very near term and we will be having a public beta very shortly. We will be releasing an "RFC" and client specifications for our system in tandem so that people writing their own clients, e.g. mybitcoin.com, mtgox and everyone else can interop with our service (and any others) - hopefully the community can standardise on some format. ( Ours is very similar to existing RFCs like it so there should be no problems with using what we have )

Of course hosting your own records on your domain is simple and easy, and we encourage people who are able to do so. However, in addition to our basic hosting services, we will be offering full merchant systems with all the bells and whistles that go along with that; dynamic address generation, redundant, highly available, distributed servers (we're talking 5+ nines here), SLAs, APIs, backend portals to manage your orders and invoicing, and everything else you'd expect from an enterprise level SaaS - some time shortly after our public beta period. Currently we are working on a very, very custom (e)bitcoind that will enable even more functionality.

In other words - we got this covered. Stay tuned. =)