Hal9000 Posted March 11, 2012 Share Posted March 11, 2012 Hello! In the "Domain Registrars" configuration, under the "Other Settings" tab, I have the "Tick this box to use clients details for the Billing/Admin/Tech contacts" unchecked. However, clients are able to edit admin/billing/tech contacts for their domains, but I don't want this. Is there a way I can prevent this? I tampered with the template a bit to hide the forms, but then submit fails because of missing form elements... 0 Quote Link to comment Share on other sites More sharing options...
bear Posted March 11, 2012 Share Posted March 11, 2012 clients are able to edit admin/billing/tech contacts for their domains, but I don't want this. Don't they own the domains? Seems to me they should be able to edit as they prefer, unless this is a free domain they shouldn't be able to move? 0 Quote Link to comment Share on other sites More sharing options...
tallship Posted March 11, 2012 Share Posted March 11, 2012 Don't they own the domains? Seems to me they should be able to edit as they prefer, unless this is a free domain they shouldn't be able to move? That's what I was thinking. There used to be a business model years ago where certain hosting providers would register a working domain for the purposes of hosting your brand, yet it was nevertheless their domain, and not that of the customers. This was back in the early to late nineties, and many of these 'full service' hosting houses had thousands of domains registered and to some degree, control of any attached branding, um... leverage actually Many of these relationships evolved into some of the earliest forms of *cybersquatting*. As you can see, the potential for blackmail is prominent in this type of relationship where the provider owns all rights to the domain that the customer builds a brand upon Anyway, and on the other hand, I can certainly see why someone might want to prohibit the *Technical Contact* fields in the WHOIS from being populated with anything other than that which the registrar specifies, if the registrar is the actual operator of the DNS Servers. The reason being, is that this is part of being RFC compliant. According to standards, the *Technical Contact* for ANY domain registered is supposed to be the person or role account that is actually the [hands on] administrator of the DNS servers themselves. IOW. It is quite reasonable to actually expect that the ability for the client to adjust the Technical Contact WHOIS data would be prohibited, if the domain admin/registrant isn't actually the administrator of those DNS Servers. In reality, this means the person responsible for loading the zonefile. And the domain registrant isn't necessarily (or usually, in todays world) the person who actually is actually manipulating the DNS zonefile. Basically, it works best like this. If the client is asking for the provider to provide the DNS, then according to the RFCs, it is someone, or a role account, in the ISP who should be listed. If the user goes outside the purvue of the Reseller/Registrar/ISP for their DNS services, then they should have complete control over all the WHOIS records for their domain. huh? Well here's the rub. The technical contact is supposed to be a technical contact, who doesn't have to care whether the registration is current - her only job is making sure the designated DNS servers are answering AUTH for the zone. If the provider is running the DNS, and something goes wrong with the DNS service there, then it does absolutely no good at all to contact the registrant - because they can do nothing about it anyway. And that's what the technical contact is for.It's the person you (another admin) call when their DNS is messed up. The problem is that this very important distinction has been lost in the naive assumption that things, "just run" - because sometimes they don't. I believe that part of the reason that this particular specified standard is not strictly adhered to is because the WHOIS data isn't keyed the same way it was back in the days when there only a few hundred, or thousand, DNS servers out there. Back then, when nic.ddn.mil and internic.net were the stuff, entire DNS operations were related to persons or role accounts that provided these services. Ever since ICANN exited the birth canal and emasculated NetSol, the keys on these DNS admins associating certain roles or people to IP addresses dedicated to DNS operations has been abandoned. If your DNS borks, do you really want every Manny Moe and Jack to call you up expecting an answer as to the problem? And that's why the *Technical Contact* is supposed to be the person whose boogers are rubbed into the keyboard of the actual DNS server, and why the OP's request certainly qualifies as an actionable development item. Expanding on that, it appears that the OP is asking for much more than that, however. It seems the OP is asking to prevent the client from altering their own WHOIS records. If that's the case, the OP should realize that it is outside their jurisdiction to prevent the domain registrant from specifying that registrants WHOIS records (with the exception of the *Technical Contact*). Unless of course, the business model is that which I referred to above, where the provider actually registers the domain for themselves on behalf of their clients intent to operate under this domain... But in this case the domain is actually registered to the provider - not the subscriber. Here's an early excerpt of the concept from RFC 1032: (3) The NIC handle of the technical contact for the domain. Alternately, the person's name, title, mailing address, phone number, organization, and network mailbox. This is the contact point for problems concerning the domain or zone, as well as for updating information about the domain or zone. In this world of being served by big DNS houses like OpenDNS and ZoneEdit and DynDNS, and GoDaddy, etc., it stands to reason that there's even morereason to automatically LOCK and ASSOCIATE the Technical Contact record of any domain's WHOIS record with the actual *Technical Contact* that administers those particular servers. This doesn't prevent the Admin contact from having total control over her domain registration - it only prevents her from changing the Technical Contact information to any other person or role than those who are actually responsible for those DNS servers - if they are known through a NIC record - which they aren't any longer, sadly enough. After all, the Admin Contact / Registrant change the designated DNS servers anytime they want, but if someone else is the DNS administrator for that machine, then the Admin Contact / Registrant shouldn't be able to affect contact records for those DNS Servers. But Alas, they are. . 0 Quote Link to comment Share on other sites More sharing options...
penguin Posted March 11, 2012 Share Posted March 11, 2012 You can remove these from the form, however the other option is to use a custom registrar module. Which registry are you using? 0 Quote Link to comment Share on other sites More sharing options...
Hal9000 Posted March 12, 2012 Author Share Posted March 12, 2012 I guess all of the replies here make sense. I guess I will have to live with that. After all, customers can change their DNS servers and host the domain somewhere else, in which case I would not be the technical contact anyhow. Since my registrar uses contact handles, I will just modify my self-written module to force my contat handle IF they use my nameservers. Actually, the way the module is written right now, my customers would be able to modify my contact handle. lol 0 Quote Link to comment Share on other sites More sharing options...
Hal9000 Posted March 12, 2012 Author Share Posted March 12, 2012 Btw I easlly "fixed" the thing by modifying my _GetContactDetails function of the registrar module in that it no longer returns the technical contact. That way it doesn't appear in the client area anymore. 0 Quote Link to comment Share on other sites More sharing options...
bear Posted March 12, 2012 Share Posted March 12, 2012 Btw I easlly "fixed" the thing by modifying my _GetContactDetails function of the registrar module in that it no longer returns the technical contact. That way it doesn't appear in the client area anymore. That file is ioncube encrypted in mine. Can you explain how you're able to edit that? 0 Quote Link to comment Share on other sites More sharing options...
Hal9000 Posted March 12, 2012 Author Share Posted March 12, 2012 That file is ioncube encrypted in mine. Can you explain how you're able to edit that? i wrote my own module, that's why 0 Quote Link to comment Share on other sites More sharing options...
othellotech Posted March 12, 2012 Share Posted March 12, 2012 or you could just ignore those contacts in the .tpl file (which then stops the end-user accessing them, but still allows admins to do so) 0 Quote Link to comment Share on other sites More sharing options...
Hal9000 Posted March 12, 2012 Author Share Posted March 12, 2012 or you could just ignore those contacts in the .tpl file (which then stops the end-user accessing them, but still allows admins to do so) i did like that at first, but when submitting the form it complained about missing fields... maybe i did something wrong, whatever... 0 Quote Link to comment Share on other sites More sharing options...
jonium Posted December 4, 2020 Share Posted December 4, 2020 I have the same problem described here, for .it domains at registrations we put our nameservers and our tech contact because we manage them. How to disallow client to change the Tech contacts only? Is it possible to do it based on .it tld ? 0 Quote Link to comment Share on other sites More sharing options...
jonium Posted December 9, 2020 Share Posted December 9, 2020 On 3/12/2012 at 7:13 PM, Hal9000 said: i did like that at first, but when submitting the form it complained about missing fields... maybe i did something wrong, whatever... Hi Hal9000, did you fix this issue? How to do? 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.