Can't delete entry from DNS zone

vanderaj

New member
Joined
Oct 7, 2007
Messages
1
Location
Columbia, MD
Hi there,

I've been struggling to get DA to create a correct SPF record for about 2 years now. I've tried everything, including ... something which we use in the web application security field - I urlencoded the string hoping that would work.

Well, it sucks to be me right now. I can't delete this string. The value in the HTML input is now completely bogus, and I can't delete the bad SPF record.

What I have is:

Code:
<input type=checkbox name=txtrecs0 value="name=aussieveedubbers.com.&value=&#61spf&#49&#37&#50&#48a&#37&#50&#48mx&#37&#50&#48a&#58mail.aussieveedubbers.com&#37&#50&#48&#126all">

The problem is that since DA creates its HTML in a non-XHTML compliant way, with no quotes and strangely encodes them (it seems to be using HTML entities for all non-ASCII characters, which should be nice and safe. Except now, the value string contains HTML entities, and DA fails miserably to delete that line.

The way it should look is:

Code:
<input type="checkbox" name="txtrecs0" value="1" />

Browsers will only submit this via POST when they have been checked:

txtrecs0=1

There's no reason to send ANY value other than a unique integer like 1 ... 2.. 3 ... 4. The value is totally irrelevant and using user supplied data is literally begging to be attacked. If DA is trusting this data in any way, it may create a direct object reference attack all the way through to XSS or SQL injection attacks, depending on how DA interprets this data. At the moment, all it is doing is giving me a DoS for e-mail.

I'd suggest moving to an indirect object reference map instead of user-supplied data. It's faster to validate (it'll be an integer), it's faster to check for attacks (if you send out 1..10 as values, and get 'z or 12, then you know you've been attacked), and it'll work no matter what sort of hairbrained rubbish I enter for the DNS record.

Lastly, can DA be updated to include the ability to accept a string for the SPF record and honor it? At the moment, any TXT record is sent out like this:

"v=spf1" "a" "mx" "~all"

which fails with EPERM with ALL the SPF record testers, and thus about 30-40% of the mail servers on the planet reject mail from my domain (before I stuffed up my own zone).

Can this be fixed? How do I delete this entry? I'm running 1.31 on FreeBSD 5.3. I do not have root access and have no idea who does.

thanks,
Andrew
 
You've managed to totally lose me.

My SPF record shows up as:
Code:
"v=spf1 a mx ip4:4.79.140.157 ?all"
and that appears to work fine. I don't know what SPF record tester you're using (please tell us) but my email gets accepted, as does email for most of us.

The bad news is that if DirectAdmin won't allow you to delete the mx (actually txt) record, then you're stuck unless your upstream provider can do it for you.

You write that you're running FreeBSD 5.3, which seems to indicate the server is yours. But if it is, then you should have root access. If not, then your hosting provider should. Or if your hosting provider is a reseller, then their hosting provider should.

At worst case, whomever built the server for you should.

Jeff
 
Back
Top