Custom nameservers not possible?


#1

I am currently having a hard time trying to get some custom nameservers set up for a domain I have registered with DH.

ns1.vps.mydomain.com -> My VPS (not DH) IP
ns2.vps.mydomain.com -> My VPS (not DH) IP

So far the response from support has been to

  1. change the nameserver for mydomain on the ‘edit whois’ page (not what I was after)

  2. Try make an A record manually (will this work if my domain isn’t registered as a nameserver?) but they weren’t sure if that would work.

I’m REALLY confused right now, registering private nameservers with other registrars is incredibly easy.

Any help is most appreciated.

Mike


#2

This thread should shine some light on your issue.


#3

I’ve also played around with this (http://discussion.dreamhost.com/thread-133962-post-148934.html#pid148934) and it does work, but you have to watch out for a few things. I’m not confident enough in my understanding of DNS to make these changes on my most important site, but I’ve done it on low traffic sites and it works well.

Note that it’s still impossible to completely hide the actual host because if you follow the requirements and and an A record pointing at DH’s name servers, then you can just do:

host -C mydomain.com
Nameserver ns1.mydomain.com:
        mydomain.com has SOA record ns1.dreamhost.com. hostmaster.dreamhost.com. 2012011201 17668 1800 1814400 14400

If you don’t add the A record, it seems to work, but as noted in the discussion linked above, it will cause problems in some situations.

Also, if you want to hide your host, others can still visit sites like onthesamehost.com and figure out the host quite easily. In the end, I decided the value of the vanity nameserver was not really worth it as those that would notice are also those that are smart enough to know the ways to find out who the host really is.


#4

I also suppose that maybe four people care about your vanity domain. Nobody else will notice, and so long as your site works well, does it really matter?

Yes, I’ve had vanity domains in the past. Just figured one day that it really didn’t make a difference.


#5

I’m commenting not because I see any point in “vanity domains” but because it’s interesting to find out how these things work.

So … how about routing your domain through cloudflare.com?

That should make it harder for people to discover who the real host is (in fact, how would they discover it? Doing “host -C” just returns cloudflare)

Also, normally, I guess, “custom nameservers” would tend to make things less efficient; whereas this approach makes things more efficient (or at least, should).

~Tom


#6

If someone knows enough about being concerned about one’s host, they can check the IP number if the nameserver doesn’t deliver a clue about the identity.


#7

“they can check the IP number” … yes, but how do they get hold of this IP number, short of filing a DMCA takedown request?


#8

And checking the following, among other alternatives:

http://www.intodns.com/

It’s not hard.


#9

I just tried this with CloudFlare, and it gives me an SOA of Dreamhost. How have you configured Cloudflare? I set up a vanity NS pointed at DH’s NSs with A & glue records, but I still see DH with host -C


#10

Hi. Probably I should’ve been clearer with my comment. I’m not talking about redirecting a vanity NS through Cloudflare, but about redirecting an ordinary website through Cloudflare in order to achieve “hiding the host”. I’m commenting on,

For example, how do you find out who the host really is of

whereisthisdomainhosted.co.cc

~Tom


#11

Dreamhost. Don’t forget to remove the direct subdomain if you want to hide. I’m not sure if you can remove it though because CF needs to give you a way to access your server directly. Any changes to subdomains should be available in the publicly available DNS tables.

That was educational though. Thanks for the challenge. Further ideas can be found here: http://calderonpale.com/blog/nmaping-hosts-behind-cloudflares-service

Basically, you’d need to edit all of your DNS settings to hide behind proxies. Since DH sets up standard settings for ftp. mail. media. etc which you can’t edit, then someone patient enough should be able to figure it out. You might try asking Support to change those default settings, or you’d need to make sure CF intercepts every one.

[code]
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> direct.whereisthisdomainhosted.co.cc
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57031
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;direct.whereisthisdomainhosted.co.cc. IN A

;; ANSWER SECTION:
direct.whereisthisdomainhosted.co.cc. 300 IN A 69.163.148.143

;; Query time: 330 msec
;; SERVER: 128.242.54.18#53(128.242.54.18)
;; WHEN: Thu Feb 2 18:08:09 2012
;; MSG SIZE rcvd: 70[/code]

[code]
[Querying whois.arin.net]
[whois.arin.net]

Query terms are ambiguous. The query is assumed to be:

“n 69.163.148.143”

Use “?” to get help.

The following results may also be obtained via:

http://whois.arin.net/rest/nets;q=69.163.148.143?showDetails=true&showARIN=false&ext=netref2

NetRange: 69.163.128.0 - 69.163.255.255
CIDR: 69.163.128.0/17
OriginAS: AS26347
NetName: DREAMHOST-BLK9
NetHandle: NET-69-163-128-0-1
Parent: NET-69-0-0-0-0
NetType: Direct Allocation
Comment: ** For abuse issues, please contact abuse@dreamhost.com **
RegDate: 2009-03-27
Updated: 2009-10-02
Ref: http://whois.arin.net/rest/net/NET-69-163-128-0-1

OrgName: New Dream Network, LLC
OrgId: NDN
Address: 417 Associated Rd.
Address: PMB #257
City: Brea
StateProv: CA
PostalCode: 92821
Country: US
RegDate: 2001-04-17
Updated: 2009-03-25
Ref: http://whois.arin.net/rest/org/NDN

OrgNOCHandle: ZD69-ARIN
OrgNOCName: Network Operations
OrgNOCPhone: +1-714-706-4182
OrgNOCEmail: netops@dreamhost.com
OrgNOCRef: http://whois.arin.net/rest/poc/ZD69-ARIN

OrgTechHandle: MNA53-ARIN
OrgTechName: Nagel, Mark
OrgTechPhone: +1-714-706-4182
OrgTechEmail: mna47-arin@dreamhost.com
OrgTechRef: http://whois.arin.net/rest/poc/MNA53-ARIN

OrgAbuseHandle: DAT5-ARIN
OrgAbuseName: DreamHost Abuse Team
OrgAbusePhone: +1-714-706-4182
OrgAbuseEmail: abuse@dreamhost.com
OrgAbuseRef: http://whois.arin.net/rest/poc/DAT5-ARIN

RTechHandle: ZD69-ARIN
RTechName: Network Operations
RTechPhone: +1-714-706-4182
RTechEmail: netops@dreamhost.com
RTechRef: http://whois.arin.net/rest/poc/ZD69-ARIN

RNOCHandle: ZD69-ARIN
RNOCName: Network Operations
RNOCPhone: +1-714-706-4182
RNOCEmail: netops@dreamhost.com
RNOCRef: http://whois.arin.net/rest/poc/ZD69-ARIN

RAbuseHandle: DAT5-ARIN
RAbuseName: DreamHost Abuse Team
RAbusePhone: +1-714-706-4182
RAbuseEmail: abuse@dreamhost.com
RAbuseRef: http://whois.arin.net/rest/poc/DAT5-ARIN

ARIN WHOIS data and services are subject to the Terms of Use

available at: https://www.arin.net/whois_tou.html[/code]


#12

Interesting … and thank you for taking the challenge!

Well here’s my nonexpert summary of what we’ve learned so far.

Bobocat guessed that I might have forgotten to remove or rename the ‘direct’ subdomain which Cloudflare supplies by default … and he was right. He simply handed the string ‘direct.whereisthisdomainhosted.co.cc’ to one of his villainous Linux tools, and received back an IP number belonging to Dreamhost.

Actually, I had noticed, and unfortunately ignored, a remark in Cloudflare’s website which says that users can edit the name ‘direct’ to something else. Now I understand that the reason why people might want to do this is to make it unguessable.

Anyway, now I’ve removed the ‘direct’ subdomain altogether from the Cloudflare dashboard. This is OK because I can still maintain the site at Dreamhost by doing ‘psftp myusername@quirkydreamhostservername.dreamhost.com’.

Also, I don’t have any mail or ftp entries at Cloudflare; the only subdomain in the zone file there is ‘www’. Presumably this means I can’t use the domain for email.

By the way, I did remember to remove quickstart.html. If I hadn’t done that, then anyone who guessed that the site was hosted at Dreamhost could have confirmed it easily by pointing their browser at whereisthisdomainhosted.co.cc/quickstart.html

Well, if anyone is still interested, the challenge is still open: is the new hardened version of the site host-hidden (short of legal intervention such as DMCA takedown requests)?

There are some remarks in bobocat’s reply which I don’t understand. For example, “Any changes to subdomains should be available in the publicly available DNS tables” … does this mean that it’s already too late, and there will always be a lingering reference somewhere to the ‘direct’ subdomain? Could I have avoided this by not letting Cloudflare create a ‘direct’ subdomain in the first place?


#13

I stand corrected. It used to be possible to snoop around for CNAME records, but admins have wised up and restricted access.

So now that you’ve changed the default CF passthrough and set it to handle all other default domains set up by DH (ftp, mail, media, etc), it seems to be well hidden to my amateur eyes. I’m not sure, however, how easy it would be to set up a DNS server and then use your own admin rights to snoop through the databases. That’s beyond my skill level and free time availability.

The problem for me, however, is that CF is not an ideal way to hide a host from the public because CF can, and does, show up sometimes when you don’t want it too, unless you are paying them something.

Update: try this and let me know what you see: host -t axfr whereisthisdomainhosted.co.cc jack.ns.cloudflare.com

I did it from Dreamhost, so it may be because of that, but the response mentioned Dreamhost in the error:

[code]$ host -t axfr whereisthisdomainhosted.co.cc jack.ns.cloudflare.com
Trying “whereisthisdomainhosted.co.cc
; Transfer failed.
Trying "whereisthisdomainhosted.co.cc.dreamhost.com"
Using domain server:
Name: jack.ns.cloudflare.com
Address: 2400:cb00:2049:1::adf5:3b79#53
Aliases:

Host whereisthisdomainhosted.co.cc.dreamhost.com not found: 5(REFUSED)
Received 61 bytes from 2400:cb00:2049:1::adf5:3b79#53 in 20 ms
; Transfer failed.
[/code]

Also:

$ host -l -t any whereisthisdomainhosted.co.cc ;; communications error to 208.113.192.17#53: end of file ;; communications error to 208.113.192.17#53: end of file ;; connection timed out; no servers could be reached $ host 208.113.192.17 17.192.113.208.in-addr.arpa domain name pointer ip-208-113-192-17.dreamhost.com.

Again, I’m on a Windoze machine today so I have to try this from Dreamhost, which may be why I’m getting clues pointing back to Dreamhost. You should check these yourself on a non-Dreamhost account.


#14

I can’t do quite what you ask, because Dreamhost is the only place where I have an account that gives shell access.

However, straining to remember what I was taught at school about doing scientific experiments, I reckoned that if I couldn’t vary one thing (the location of the account), then I should vary another thing (the probed-for domain-name)

thus I substituted “utterlyrandomdomain.org” for “whereisthisdomainhosted.co.cc” … and got very much what you got:

[code]$ host -t axfr utterlyrandomdomain.org jack.ns.cloudflare.com
Trying “utterlyrandomdomain.org
; Transfer failed.
Trying "utterlyrandomdomain.org.dreamhost.com"
Using domain server:
Name: jack.ns.cloudflare.com
Address: 2400:cb00:2049:1::adf5:3b79#53
Aliases:

Host utterlyrandomdomain.org.dreamhost.com not found: 5(REFUSED)
Received 55 bytes from 2400:cb00:2049:1::adf5:3b79#53 in 26 ms
; Transfer failed.
$[/code]

also,

$ host -l -t any utterlyrandomdomain.org ;; communications error to 66.33.216.129#53: end of file ;; communications error to 66.33.216.129#53: end of file ;; connection timed out; no servers could be reached $ host 66.33.216.129 129.216.33.66.in-addr.arpa domain name pointer ns-cache02.sd.dreamhost.com. $

~Tom