I set up the DNS Server -> Zones -> DNS Template and it is working perfect when I add a new siteworx account, every record is the same as I added to the template:
The problem is when I add a domain alias in the SOA record the contact email has to be postmaster@, but interworx is creating the contact email as hostmaster@ in SOA.
I did not find any config for this, is there any way to change the dns template for the domain aliases?
Sorry if I did not understand well, what do I have to do? I don’t have ipv6 addresses and I’m not using it.
I only have problem with the one SOA record in the dns template. As you can see, in my template the contact email is set to: postmaster@. When I add a domain alias, interworx is creating in the dns a hostmaster@ SOA record what is wrong.
sorry if I did not write down correct, I still have this problem and I can’t find a solution. Do you think it’s a global IW bug, other IW users also have this problem?
Thank you for sending a mail and request the fix, I hope it will be fixed soon.
Yes, sorry I’ve sent an email with this post link so I’m sure it will be read.
I think it happens on all IW as I tried it, and it produced same result.
I think best option would be to manually change it once setup, and hopefully might be resolved in next update.
Do you mind me asking though, why is it important to show postmaster as apposed to hostmaster, I know SSL changed the email rules but was not aware of other DNS rules imposing postmaster.
I hope that’s alright and you don’t mind me asking.
It’s not problem to ask! In Hungary, before every .hu domain registration the dns records is checked and verified by the top level registrator. If there is a hostmaster@ address in the SOA record I’ll get error because IW creating only postmaster@ email address, so every time I add a domain alias I have to correct the SOA record in my dns.
It’s not very urgent to fix this in my server, I can wait for the IW update.
I was pondering whether to create a new thread or to “hijack” this one, but I guess it will help others too, if I add my question here:
First, the above problem seems to have been fixed, at least when I enter hostmaster@ourdomain.com in the DNS template it is used on account creation. Or did I get the problem wrong?
Anyway, what I don’t get is the @{domain} part, since that would result in the SOA record showing hostmaster@customersdomain.com instead of hostmaster@ourdomain.com or hostmaster@nameserverdomain.com (the latter is the right one according to RFC, as the E-Mailadress of the Nameserver Admin is meant, right?).
So, as written above, I changed the DNS template to hostmaster@ourdomain.com and am fine with it, but wanted to check with you guys why iworx-cp is doing this differently by default.
And while we’re at it, there’s another thing I don’t get:
We are using our iworx-server as 1st nameserver and have set 2 nameservers from our hosting partner as 2nd and 3rd, working as slaves. Works fine, as far as our first test show. But when a new siteworx account is created, the primary nameserver setting in the DNS template’s SOA record is ignored and the 2nd nameserver is used instead.
The default would be {domain} again, as can be seen in the screenshot in the first post. But even if I change it to ns1.ourdomain.com the SOA record for a newly created account is pointing to ns2.hostersdomain.com. What am I doing wrong or do I simply get this all wrong?
Sorry, the issue Garbo posted was in reference to adding domain alias, and I believe it is still outstanding to be fixed, although I have not retried.
If you don’t mind I’ll have to have a think about your post, as I’m not sure why it would use ns2 as primary, and ideally I like to try on our systems to see if it does same. It could be round robin or I could be wrong and not fully understood your post fully yet, age sorry.
I’d have to look up rfc to see latest revision but my understanding was it had to show a correct working address for zone, not NS.
I hope you don’t mind my thoughts and sorry if I’m wrong
John are right, my problem is only appears when I add a domain alias, after that interworx creating a wrong DNS SOA record.
The problem is still exist, I hope it will be fixed.
you are right, according to RFC the SOA record has to show a correct working address for zone, but imho it means how to reach the Zone-C, not the Admin-C. And the Zone-C is usually not reachable under the accounts/customers domain but the hosters domain. The default setting hostmaster@{domain} creates hostmaster@customerdomain.com which doesn’t make sense to me.
Garbos issue was imho simply with the change to postmaster@{domain} being ignored and hostmaster@{domain} being used, but if I set postmaster@{domain} it works for me, i.e stays postmaster@customerdomain.com
Regarding SOA nameserver record, I just tried the default setting {domain} and that results in ns2.hosterdomain.com too. So whatever I enter there is ignored and it always seems to use the second NS.
Many thanks, a good clear explaination, far better then I could have written.
I’m thinking it is set this way then as it is a shared host system, with resellers who can set there own NS as defaults, as can siteworx users, who become the person in charge of their own dns zones.
I could be wrong though sorry, I’ll have to think about it a little more sorry
If I understand what you are saying right, you mean hostmaster@{domain} is working like it is, because resellers and also users could be the nameserver admins. That’s ok, and I can change that globally and resellers/customers could change it back, if the need arises.
So the only thing not working is changing the SOA primary nameserver setting (Overwriting the {domain} setting in the SOA template is ignored and the 2nd NS is used, no matter what I enter). Is this a bug? Should I adress this via ticket?
I would try setting the name servers directly at the siteworx account, or reseller account as I’m thinking it might be here where’s it’s defaulting too.
I had hoped I might have had time to test my theory, sorry.
If this still does not resolve the issue, I would be inclined to open a support ticket, IW are excellent at reviewing, and will explain everything.
I hope this helps, and sorry, sometimes I need time to fully understand exactly the issue, and it’s potential cause, which is sometimes not a bug, but a setting.