DNS forgery at DH?


#1

Is there a DNS expert that can check this test for me?

I picked some innocent victim’s domain and simply add it to my panel. Now, nsLookup says:

1 spellbetter.com ALL
Query sent to ns2.dreamhost.com
1 spellbetter.com SOA 14400
ns1.dreamhost.com hostmaster.dreamhost.com

Am I absolutely 100% correct in taking this to mean that DH DNS is claiming to be the domain’s Server of Authority, and falsely so?


#2

Not sure where you are seeing that response to DH servers. I checked the Whois info at http://www.dnsstuff.com/tools/whois.ch?ip=spellbetter.com and it doesn’t show any such change.

I suppose that if you did a ping through telnet/ssh on a DH server looking up that name that you added to the panel it would check it’s own DNS servers first which might list your information about where the website is - but that will not make global changes.

-Matttail


#3

[quote]Not sure where you are seeing that response to DH servers.

[/quote]

I’m seeing that response /from/ DH servers in Trumphurst NSLookup for Windows.

[quote]I checked the Whois info at http://www.dnsstuff.com/tools/
whois.ch?ip=spellbetter.com and it doesn’t show any such change.

[/quote]

As expected - that query is not directed at the DH nameserver carrying the forgery.


#4

Sure - if you query DH’s authoritative nameservers directly. However, almost none of DH’s machines use the authoritative nameservers to resolve names, and the domain spellbetter.com isn’t delegated to any of DH’s nameservers by the authoritative nameserver for its TLD (com.).

So yes, but who cares? And how would you suggest that DH prevents people from adding domains they don’t own?


#5

[quote]So yes, but who cares?

[/quote]

I care, because I found a bogus DH DNS record intercepting my mail to an external domain.

[quote]And how would you suggest that DH prevents people from adding domains they don’t own?

[/quote]

Make addition conditional on verification via the domain owner address.


#6

I agree with Chris wholeheartedly. Here is an interesting example. I was planning on moving my main site to dreamhost months ago. So, I added my site to dreamhost as Chris did. But never changed the nameservers through dotster.

All was well, but so many clients kept telling me, “I sent you an email.” but I never got them. Here’s the tricky part that I don’t understand. I did finally change over the nameservers to dreamhost in May, when my hosting ended w/my other hosting company. When I went in and checked my email on my dreamhost account…lo and behold, there was those messages from 3 months ago that never arrived. Yes, I did set up my emails when I thought I was moving my account here…but never actually moved my account to the dreamhost nameservers.

so, I added my domain, set up the emails, and never changed the nameservers (because I didn’t want my site to be down at the time.) And, the clients I had lost the emails from were all on Dreamhosts servers…including all of the announcements from dreamhost. Is that scary … yes. Was it supposed to happen…who knows.


#7

Dreamhost’s DNS servers think they’re speaking on behalf of your domain to the rest of the Internet. The Internet at large isn’t listening, unless your domain registrar told them to, but Dreamhost’s DNS servers sure are convinced. That’s the way it’s supposed to work.

The Internet keeps working and the problem is limited to Dreamhost’s corner of it. But that’s not really enough because it will affect, in one fashion or another, everyone using Dreamhost. Perhaps Dreamhost should keep every zone inactive until the domain is properly set to use DH’s name servers.


#8

wow, iri, i think you need to write a book. : )

I actually understand what you are saying. For the first time!

Note to self, go find Iri’s wiki articles.

It was a shocker, and I did send in a support request to dreamhost about losing and getting emails in wrong places. It makes sense though. It was my error, but like Chris said, it could be done to unsuspecting sites. Say, I take your site, and add it as a domain in my webid. Now, I looked at your site, and set up the emails…what happens then. I never did actually login before I changed the nameservers to properly point to dreamhost…but ??? Those emails were sent to my dreamhost account, but I was at the time hosting at another provider. Could I really intercept the emails?

Here is where my edit begins >> But, some of my emails from the other host provider after I initially added my site to dreamhost, but months before I actually changed the nameservers, these emails went to some of my clients who asked why the emails were going to them. Now, the best part is, I think we actually still have those emails on record and when they occured…exact times and dates.

these clients are not in my main account w/dreamhost, but another account. But, I think I had initially added my domain to their webid account. Hope this makes sense.


#9

Not really. Just a few things… Webmail, IIRC, and announcement list mail. Mail sent from customer mail machines via SMTP, customer web machines, etc. wouldn’t be affected. And it would be fairly trivial to “fix” this problem on the webmail machines and most other places.

This isn’t a new problem, and the fix is simple… separate caching-only and authoritative nameservers. This is already the case on most DH machines, and I imagine if you write support with information about this, someone will take care of it.

Be specific about where exactly you’re seeing the problem (i.e., webmail, discussion list mail, whatever).

Not really possible to coordinate properly for a seamless transitions. Plus, the registrars for some TLDs check whether a nameserver is responding authoritatively for a zone before letting someone assign the domain to a given nameserver.

I don’t think requiring confirmation from the domain’s contact address is viable either. Even just the volume of support inquiries and other problems this would generate would be a huge problem.

There are some basic checks in place to prevent people from adding AOL, Hotmail, etc.


#10

[quote]Not really possible to coordinate properly for a seamless transitions.

[/quote]

Seamless transitions are no possible anyway. At least the above suggestion would reduce the seaminess.


#11

[quote]Say, I take your site, and add it as a domain in my webid. Now, I looked
at your site, and set up the emails… … Could I really intercept the emails?

[/quote]

Yes you could.


#12

[quote]Dreamhost’s DNS servers think they’re speaking on behalf
of your domain to the rest of the Internet. …
That’s the way it’s supposed to work.

[/quote]

Perhaps, but that’s not the cause of the problem I reported.

[quote]The Internet at large isn’t listening,

[/quote]

The problem is that DHs mail servers are listening - to bogus domain records.


#13

[quote]Not really. Just a few things… Webmail, IIRC, and announcement list mail. Mail sent from customer mail machines via SMTP, customer web machines, etc. wouldn’t be affected. And it would be fairly trivial to “fix” this problem on the webmail machines and most other places.

This isn’t a new problem, and the fix is simple… separate caching-only and authoritative nameservers. This is already the case on most DH machines, and I imagine if you write support with information about this, someone will take care of it.[/quote]
It has broader ramifications as long as the mail servers defer to the local nameserver that thinks it’s authoritative.

Where does the caching-only nameserver go to find a domain: the nameserver on DH’s network who thinks it’s the authoritative nameserver, or the one on the Internet that is? It should go see the one on that’s listed as the nameserver for the domain, but it sounds like it won’t. I would imagine that the mail servers use a caching-only nameserver. The mail servers are convinced that the authoritative nameserver is the one on DH’s network. Why?

Perhaps because you don’t want to cause external traffic if you can help it so you cut corners and just tell the nameservers to use local info if it is available regardless of whether that local server should be speaking for the domain or not?

I cordially invite you to acquaint yourself with ZoneEdit’s procedures :slight_smile:

Yup yup.


#14

The latter. Other than forwarding queries for internal (rfc1918) space, the caching-only nameservers don’t slave to, or forward queries to the authoritative nameservers.

[william@mitch]% dig spellbetter.com +sh @ns1.dreamhost.com soa
ns1.dreamhost.com. hostmaster.dreamhost.com. 2005060701 17092 1800 1814400 3600
[william@mitch]% dig spellbetter.com +sh @ns-cache01.sd.dreamhost.com soa
octagon.interface.co.uk. administrator.interface.com. 2000091142 28800 7200 86400 14400

Actually, they’re not, with a few possible exceptions.

I think what you’re actually seeing here is not a DNS issue, but that once a domain has been added, and the mail servers are configured to accept mail for that domain, they will accept it without consulting the DNS (as it should be). So any other users in the same cluster of mail machines would have their mail intercepted.

The only really good way to fix this is to use different servers for auth-smtp and not allow auth SMTP at all for the mail servers which accept mail for a domain. In other words, POP / IMAP / outbound SMTP machines would not be configured to accept mail, but inbound MXs would. Currently, all the mail servers in a group of machines are configured identically, so that they can switch functions and / or serve multiple functions.

So fixing it is possible, but it’s questionable whether it’s worth the effort.


#15

[quote]Actually, they’re not, with a few possible exceptions.

I think what you’re actually seeing here is not a DNS issue, but that once a domain has been added, and the mail servers are configured to accept mail for that domain, they will accept it without consulting the DNS (as it should be). So any other users in the same cluster of mail machines would have their mail intercepted.[/quote]
Fair enough. What you say makes sense.

The last sentence makes sense too. However…

…I do not agree with. It is definitely worth the effort. The chance for interception and grief is a non-zero, and this leaves Dreamhost mail-users vulnerable. While no sane person would transmit trade secrets unsecured over Dreamhost mail servers, the sane people are a minority in the world and this kind of thing could lead to a bad information leak.

You could configure the mail servers so that they do not begin accepting incoming mail to a domain until they’re the MX for that domain. A simple delay-and-verify stage. That should be a fairly trivial change to domain creation process. It’s a hack, but I think it’d work.


#16

What happens then, when a disgruntled dreamhost user decides to take it out on another DH user? Better yet, they are both on the same servers? Disgruntled user 1 adds user 2’s domain to his tab. Is this possible? What would happen? (other than they would probably lose their site alltogether and any chance of ever hosting w/DH again, but what if they don’t care?)


#17

No.

DH servers wouldn’t allow adding of a domain already present.

It’d only work on mail sent to a third-party domain by user 2. The user 1 could fool user 2 into believing that they’re sending mail to that third-party while in effect user 1 is catching the mail. Say, you’re feeling cheeky and add citibank.com domain to your account. From there you can get all mail sent to @citibank.com addresses by DH users. Mail sent to user 2 would go through normally.


#18

Update: DH Support said

[quote]This issue has been recently fixed.

[/quote]

I replied

[quote]Not reproduced here. e.g. the message below

[/quote]

DH Support replied

[quote]This behavior is what is expected and does not constitute a security
flaw. The spellbetter.com is set up in our system with ‘mail’ service so
our server is configured to accept email for it. When you send out a
message using our server as your outgoing mail server, it sees that
message and delivers it as it is configured to do. If you send mail out
from any other mail server other than our own the mail will be properly
routed as expected. Turning off the ‘mail’ service for the domain will
make our server take the domain out of their configurations and they will
not accept mail for it any more.

[/quote]

So, the situtation is that one DH user can intercept other DH users’ mail to external domain X by just adding that domain to his panel. Which according to DH “does not constitute a security flaw”.

I have to say I am somewhat disappointed.


#19

Nah. Still above average. They did address the other issue.

Of course after a vulnerability has been pointed out and proof-of-concept presented … then it moves to the realm of boneheadedness. But hey, what works for Microsoft works for Dreamhost!


#20

[quote]They did address the other issue.

[/quote]

Eh, what other issue? The only issue I had here was the interception of mail.

[quote]But hey, what works for Microsoft works for Dreamhost!

[/quote]

Get thee behind me… :wink: