Register
Blog
Invisible DNS Entries Earlier today, Google announced a new feature for their millions of Google Apps customers to sign their outgoing messages with DKIM. DKIM works by validating outbound mail with digital signatures, which are stored as a TXT record on the domain, used to verify senders' identities and recognize potential spam. Google (and many other email providers) also support the much more widely-used Sender Policy Framework (SPF) to verify senders and identify spam. SPF also requires the addition of a TXT record. The problem: .tel does not support hidden TXT records. That means that if we want to use these features on our domains, these (ugly) records, such as [v=DKIM1; k=rsa; t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOK861e3Ym estv7aW1HCaZaID4QUIngg166FKaV6roemnt1XCyIiiFnRjdAX D7R4kHJLUJaOoDatGmFd2oZh4AAsY4SG8JP+mE6yrjVyPOA3rR yRlS0LEWKpF6NKtPtZS7iaQu5Ma0kt/OXSpCcbcKCg7vL/Bv2RWu2vfwTtBI/QIDAQAB"], will be rendered by the web proxy and visible to all visitors. Since I've switched my primary email address to my .tel, it's very important for me to be able to use these technologies to ensure that my emails are signed, validated, and not marked as spam. But I also don't want to ruin the look of my root .tel page to do so. For .tel to be taken seriously, I believe it has to add seamless support for these technologies that are being increasingly widely adopted, or it risks being left behind of more progressive competitors. UPDATE Upon further research, I've found that for DKIM, the TXT record must actually be stored in selector._domainkey.domain.tel. I added it programatically via an authenticated SOAP request, and it worked perfectly. Since the TXT record isn't stored in the root domain.tel, it doesn't appear on the proxy-rendered root domain page. Good news! However, SPF still does call for a TXT record on the root domain, which will cause a visual display of this record in the rendered HTML. Technically, the use of TXT records for SPF is deprecated in favor of the SPF record type, 99, but as of the time of this writing, TXT is much more widely-used for SPF, since many DNS providers, including .tel, don't yet support SPF (type 99) DNS records. However, henri mentioned that they are planning on adding support for it soon. |
I think we also need this to support Google Site Verification strings. Mark |
Agreed. I actually meant to write that too but forgot before posting. |
FYI, in case anyone's interested, I just set up DKIM in Google Apps on my .tel domain. This is how to get it working: UPDATE! This is not the ideal way to get DKIM with Google Apps working. It should be done programmatically via a SOAP request (see the top part of this post for details). I'm leaving the below instructions intact, but please be aware that if you follow them DKIM verification may fail. This is because creating the subdirectory in the control panel generates more than one TXT record forselector._domainkey.yourdomain.tel, and according to the DKIM spec, there should only be a single TXT record there. 1. Log into the Google Apps Admin Panel > Advanced tools > Set up email authentication (DKIM). 2. Click 'Generate new record'. 3. Select whatever prefix you want, or keep the default 'google'. 4. In a new window/tab, log into the TelHosting panel. 5. Make a _domainkey.my.tel subdirectory. 6. Make a google._domainkey.my.tel subdirectory (or if you selected a different prefix, use that instead of 'google'). 7. Add the Google-generated 'TXT record value' to the "Text header" field of google._domainkey.my.tel 8. After waiting a few minutes for the DNS records to propagate, go back to to Google Apps Admin Panel and click 'Start authentication'. Google should now be digitally signing all your messages. However, it would still be great to be able to add SPF and Google Site Verification DNS records without them appearing on the proxy-rendered root page. |
Thanks Rgolds for an interesting question. At the moment, we use several structured TXT records that are processed specially and sometimes not displayed - TSM (system), TKW (keywords), TLB (labels). Anything else is not structured, and therefore considered a simple description to be displayed on the page. To move away from this model, we need to migrate to a different data format and change system logic, which will take time. I've just confirmed with engineering that this is on our roadmap for 2011. Thank you for understanding. |
Great to hear this is on the 2011 roadmap, nadya! Because some of my emails have been marked as spam recently, I've been forced to add an SPF record (actually, an SPF-formatted TXT record) to my root domain, http://goldstein.tel (which you can see looks pretty bad), and change my main page to http://ryan.goldstein.tel. That brings me to my next point - as mentioned in the SPF Wiki, "Use of TXT records for SPF as a transitional mechanism, although still common in 2010, is deprecated." In fact, the proper usage of SPF is not in a TXT record, but in a separate "SPF" DNS record, type 99. For .tel to truly stay on the cutting edge, and be more appealing to potential registrants, it will support the proper SPF record type - which may actually be easier for your engineers to implement without appearing visibly on the proxy-rendered page. Thanks again, nadya. -Ryan |
Hi rgolds, Storing an SPF record is not a problem, it is implemented today. It's not supported in the control panel as is not a user-facing function really, but try a script and store the SPF via the API. Some registrars might block this record type, so it's worth a try. |
FYI, I was able to get DKIM/DomainKeys working properly by sending the following authenticated SOAP request: Code:
[size] For anyone interested, to get DKIM/DomainKeys working yourself, change 'domainName' from "goldstein.tel" to your .tel, the selector in 'owner' from "google._domainkey" to "your-selector._domainkey", and put your own DKIM parameters between Now, I just have one remaining question. How would I add an SPF Record (not TXT, but SPF, type 99) to my root domain? My registrar is name.com. I tried the following request... Code: [/size]
[size] ... but typ:spf is not supported (the error message I got states that the only elements supported are 'txt', 'naptr', 'srv', 'mx', 'loc', 'ninfo', 'generic', and 'adsense'). I just tried contacting name.com support, but I was hoping to get an answer here. Is my SOAP request just malformed, or does name.com simply not support SPF Records? Thanks, -Ryan[/size] |
Hey Ryan, we're looking into this. It may be a case of security overkill, easily fixable with an update. Technically I believe that your SOAP request looks fine. It doesn't care at all about the content of the record, so that's up to you to. |
Thanks henri. The issue doesn't appear to be with the content of the record, but with the type of record (SPF, type 99, RFC). The request works if I replace with But obviously, this would store the content in a TXT record, not in an SPF record as desired. (Additionally, any stored TXT records are rendered by the proxy and appear as a text header, which seems to me to be a bug, but that behavior has existed for years. That's the only reason I want to use an SPF record instead of TXT; I don't want anyone who goes to goldstein.tel to see "v=spf1..." at the top of the page.) |
That's correct, as I said it is not yet supported but we'll get that done. In the meantime, I *think* you can handle it by doing something like below: Quote: But good luck making the binary representation Basically you can get any record in there, even those not supported, by using the above.[/size] |
I tried using an ASCII-to-binary converter (i.e. converting "v=spf1 include:_spf.google.com -all" to 1s and 0s - is that what I'm supposed to do?) and sending that as So it does seem like you're right, that this is a case of security overkill, arbitrarily restricting this DNS record type. Hopefully an update can be pushed soon to allow this type, and hopefully it will work after that! Regardless, thanks very much for your help, henri. |
Ok try the below, it _should_ work. It uses the generic concept of a DNS record, which allows specifically for implementing unknown record types in a generic manner. The representation of the generic record is defined under RFC 3597 Section 5. It starts with "\#", then a space, then the number of characters in the record (in your case 35), then a space, and then the hex value of all the ascii characters. I took the 35 characters you want to insert: "v=spf1 include:_spf.google.com -all" and converted them to hex using a Perl one-liner: Quote:
And then I prepended "\# 35" and inserted it all in there. Here's the result. Let me know if it works. I know it's convoluted, and a "clean" solution will be here ASAP, but in the meantime, let this post hopefully serve as an example of how to create any generic DNS record. And if it doesn't work, we'll fix it so it does work too. Quote: [/size] |
I received the following error when trying your request: Quote:
So I changed Quote: [/size]
So I then converted the "\# 35..." string to base64 using an encoder, and submitted that. I got the error: Quote: [/size]
Any ideas? Once again, thanks so much for all your help![/size] |
Quote:
Ok that's a documentation discrepancy. Thanks for catching it. The docs say "data", not "rdata". Nadya will follow up to see which of the docs or code is wrong. Quote: [/size]
Ok, I think that makes sense. It wants it to be base64 encoded, but I don't see why it does, since it'll already be encoded using the RFC 3597 implementation. That's something I'll look into as well. No need to doubly encode. And finally, the last issue makes sense as well. Not allowing unknown record types means not allowing the creation of generics bypassing that block. We're going to revisit that soonest and properly support SPF and open up generics.[/size] |
Hi, sorry about the documentation error, we'll get this fixed. On a separate note and not to discourage anyone, there's also a Developer forum available for techy questions like these. Please visithttp://dev.telnic.org when appropriate for the benefit of the global .tel community. Thank you. |
Quote:
Sorry for the bump; just wondering if there have been any updates. I'm still anxiously awaiting being able to add SPF records properly (i.e. without them appearing visually on the rendered page). Thanks, -Ryan[/size] |
Hi rgolds, We have recently released an update that does not display TXT records of the SPF type so you should be able to use this function without displaying your SPF record on your .tel page. |
Confirmed working, thanks so much! Have a great weekend. |
