What you're experiencing is a side-effect of the dig command. The
Are you sure about that?
Yes. If you have access to a DNS content server, why not create a TXT record
with semi-colons and see what you see on the other side of dig.
I did ask a co-worker who writes DNS code
about this, and he was quite skeptical about dig being the problem.
Is there a bug report from ISC?
I think the presumption that dig renders RRs in the raw, is incorrect. It
renders RRs in a way it thinks is of use to the reader, and in the case of TXT
it's doing some escaping. So it's not a bug so much as a feature, I expect.
I have, and it shows up there too.
Examples would be nice. Also, if you pull down the commands and CPAN modules on
http://domainkeys.sourceforge.net you'll find a dk_validate_policy perl program
that dumps the TXT in the raw.
Contrast:
$ dig _domainkey.yahoo.com txt
; <<>> DiG 9.2.2 <<>> _domainkey.yahoo.com txt
;; ANSWER SECTION:
_domainkey.yahoo.com. 4657 IN TXT "t=y\; o=~\;
n=http://antispam.yahoo.com/domainkeys";
with:
$ dnsqr txt _domainkey.yahoo.com
answer: _domainkey.yahoo.com 4650 16
0t=y;\040o=~;\040n=http://antispam.yahoo.com/domainkeys
That is exactly what is causing it. I was just thinking it would be
nicer to simply look at the "v=dk1" in these cases instead of
counting on a parsing error. Given the number of mistakes I'm seeing
with lots of other records, this would be a nice-to-have until there
is a dedicated RR.
Policy is waaaay nacent. I'd be surprised if the simplistic policy as expressed
in the DK drafts survives - I certainly view it as a stop-gap until smart
people can come up with better.
Mark.