• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

DNS Zone Serial #'s

Some people are purists and they like to have their networks and servers RFC compliant. Some people like to spend their time focussing on other things. Some people such as myself have to account to my customers. My cusomters also use DNSReport. They get the funny message. We can't repeat the same "it doesn't matter" to them 500 times. We prefer to have a system that is RFC compliant. So what we are requesting from SWSoft, is it's an easy change, is to make their BIND implementation RFC compliant. Sure it's not a must, but it will certainly make my life easier.
 
Originally posted by eugenevdm
Some people are purists and they like to have their networks and servers RFC compliant. Some people like to spend their time focussing on other things. Some people such as myself have to account to my customers. My cusomters also use DNSReport. They get the funny message. We can't repeat the same "it doesn't matter" to them 500 times. We prefer to have a system that is RFC compliant. So what we are requesting from SWSoft, is it's an easy change, is to make their BIND implementation RFC compliant. Sure it's not a must, but it will certainly make my life easier.
Click to expand...

I'm 1000% agree with you, also I'm customer.
 
I have a feeling that nothing anybody says here will make anyone change his mind.

Anyway, take in the consideration that it's a "recommended format", not a set rule. RFC just makes a recommnedation here. It's up to the admin (or in this case, up to SWsoft) to follow the recommendation or use some other format that he finds more suitable.

Sites like DNSreport sure are useful, but they are not the ones that make the world go around. What would you do if DNSreport suddenly started reporting that some other perfectly normal setting "might be a problem", etc etc, would you go and immediately change all your DNS server settings or would you use your own head and think about it first?

Anyway, I wouldn't mind if SWsoft changed the DNS serial format either, but they aren't violating any RFC if they don't and that's fine with me.
 
The most important fact here is: customers, own customers, for example I don't have a big trouble with serial number BUT my 150 customer yes, they have a problem because then often visit DNSStuff and they verify everything.

Plesk sells Control Panel for 30 domains, 100 domains, 300 domains, unlimited domains; but these domains are customers (at least in most of cases)!

Now, for necessity it's very important to solve this warning with serial number...
 
Glad to know I'm not alone on this one. I hope the next revision, 8.1 I guess, will solve this issue.. It's not adversely effecting anything - true - but it's be nice to have everything pass in DNSSTUFF :)
 
In SSH, how do we change the format of the SOA to the RFC recommended YYYYMMDDnn?
 
Not following RFC makes some things hard to do:
I have a hosting not in Plesk. Then I move it to plesk but leave secondary dns as it was before. When I move it to Plesk serial number turns to be less than it was according to RFC. And my secondary doesn't update (serial is not bigger than it was!).
I believe only this is enough for the possibility to manual (or just following rfc) change to the serial number.
 
1. The RFC is a recommendation, not a requirement. Not following it is not breaking compliance, it's breaking the recommendation. Please stop getting this mixed up, as it is confusing other users as well.

2. Changing your DNS Serial (be it a running serial from plesk or a date format that is as the RFC recommends) w/o an update, and w/o utilizing the Plesk system DOES cause problems on more than one level. Please be aware of this, as it can cause you additional problems with your DNS systems. Yes, you can get away with it, but you CAN run into a LOT of trouble if you do ONE thing wrong.

3. Users unfamiliar with zonefiles should not consider manually changing the dns serials to meet RFC recommendations. I'm sure the people at SW-Soft are working on offering an option to allow the Admin and/or Client to select which method they'd prefer to use. If you mess something up, they will charge you their hourly rate to fix it. It wont be cheap, you will regret it. You've been warned.

4. Serge, you can fix your secondary DNS Server to read the new DNS by clearing that zonefile completely and doing a restart. It'll force the zone to reload from scratch, and it'll pull the data from the serial, instead of the date format. Any future updates to the Plesk DNS will automatically fall down (if you have it listed in Plesk as a secondary), allowing automatic updates of your secondary servers to work properly.

5. Thank you for listening to my mini-rant. I'll vote +1 for the DNS Date Format, as it IS recommended in the RFC Documents, but until it's supported, I'll deal with the Serial...
 
There is a simple fix for Bind users of 7.6.1 on Windows. (I do not know if this is the same on Linux flavors.) Add SOA_SERIAL_MODE YYYYMMDDnn to your misc table in the PSA database. Unfortunately I have not been able to get this to work with MS DNS but can find no documentation stating that it is just for Bind either.
 
OK it now seems we have some progress. I searched 'SOA_SERIAL_MODE' in Google and found this SWSoft documentation with exact instructions on how to fix this for Plesk Windows:

http://download1.swsoft.com/Plesk/Plesk7.6/Windows/Docs/plesk-7.6-win-admins-guide/22369.htm

Changing DNS Zone Serial Number Format

RIPE recommends using YYYYMMDDNN format, where YYYY is year (four digits), MM is month (two digits), DD is day of month (two digits) and nn is version per day (two digits).

To change DNS zone serial number format:...
Click to expand...

It seems even though SWSoft never bothered to reply to this forum they have been secretly looking at it from their labs and have decided to implement it for Plesk Windows. So perhaps it's on the schedule for Plesk Linux. If it's on the same time schedule for the implementation of AWStats it could still be a while :D but nevertheless there is hope. Wouldn't it be nice if SWSoft actually responded to these forums more often :)
 
This is a problem for me, as well.

I handled all my DNS manually before a recent server change. When moving to a server with Plesk 8.0, my Secondary DNS (using YYYYMMDDXX) has stalled (3 weeks now), and my Secondary DNS provider is reluctant to delete the Zone file, telling me to change back to the RFC. I've informed them that Plesk doesn't support that method, but have yet to receive a response from them. So I'm back here, hoping that someone has found a solution to this problem.

I'm kinda stuck, aside from manually changing the serial, and restarting the bind daemon, every time I make a change in Plesk.
 
Originally posted by Gigi
Sorry for my english, I'm french :eek:

http://download1.swsoft.com/Plesk/Plesk7.6/Windows/Docs/plesk-7.6-win-admins-guide/22369.htm
It's not work with Plesk 8.0.1 for Linux :(

I wish to manage .fr domain name... it's necessary that the serial is with YYYYMMDDnn format and that the e-mail address in the file zone is with postmaster.domainname.fr.

A solution for me ?

Thanks ;)
Click to expand...

We set up a dedicated DNS server ( PowerDNS ) that imports zones from plesk with a simple perl script!

It works good ( at least for us )
 
Originally posted by darksir
This is a problem for me, as well.

I handled all my DNS manually before a recent server change. When moving to a server with Plesk 8.0, my Secondary DNS (using YYYYMMDDXX) has stalled (3 weeks now), and my Secondary DNS provider is reluctant to delete the Zone file, telling me to change back to the RFC. I've informed them that Plesk doesn't support that method, but have yet to receive a response from them. So I'm back here, hoping that someone has found a solution to this problem.
Click to expand...

Ok you need to get rid of your secondairy dns provider real quick, stalling for three weeks is impossible, that means they overide the soa settings of plesk.

Zonefiles also have a ttl !!

RFC are recommendations, i don't see the problem why this serial issue is such a big deal.
 
I'm setting up the zones on my box as masters and asking my ISP to setup slaves for the zone. The ISP uses the date format for the serial numbers. Plesk is using some number that is numerically less than the current date. This implies that the slave zones will never be updated as their serial number is "more current" than the masters.

This is why standards are important -- interoperability between users and organizations. Please change to the date format or give us a way to select the format we wish to use.

A very simple workaround would work in my case. If I could change the base serial number to some value that is higher than the date, I would have a solution. Something like: 3000000000 would work. Can this be updated in the psa database?
 
While I entirely agree that Plesk should use the standard format of the date, followed by the rev number (2007022301, for example), the number they are using is not random, but is the seconds since the epoch.

Unfortunately, this number is smaller than the more standard date notation.

This screws us up when we are moving customers from our older servers to Plesk servers, because the older servers have a serial number that is larger than the Plesk. I have to go into the secondaries each time we move a customer and make it forget all about the domain.

Greg, your ISP is wrong, however. They should be able to have both types of serial numbers co-exist without problems. The slave server should know a serial for each of the domains. It isn't one master serial. The only time it should be an issue is when the domain is moving from a master server that used the "correct" serial format. Then, propagation will take, at the very least, the TTL amount of time to transfer, if not longer.

Originally posted by Greg Sims
I'm setting up the zones on my box as masters and asking my ISP to setup slaves for the zone. The ISP uses the date format for the serial numbers. Plesk is using some number that is numerically less than the current date. This implies that the slave zones will never be updated as their serial number is "more current" than the masters.

This is why standards are important -- interoperability between users and organizations. Please change to the date format or give us a way to select the format we wish to use.

A very simple workaround would work in my case. If I could change the base serial number to some value that is higher than the date, I would have a solution. Something like: 3000000000 would work. Can this be updated in the psa database?
Click to expand...
 
Originally posted by CruzMark
Greg, your ISP is wrong, however. They should be able to have both types of serial numbers co-exist without problems. The slave server should know a serial for each of the domains. It isn't one master serial. The only time it should be an issue is when the domain is moving from a master server that used the "correct" serial format. Then, propagation will take, at the very least, the TTL amount of time to transfer, if not longer.
Click to expand...

Thanks for the feedback on this Cruzmark. There is more to the story than what I originally posted. The zones for my domains were originally created as masters by the ISP (in error). This created a set of zone files that had date format serial nubmers (the standard for the ISP). The ISP switched the zones from master to secondary and kept the date format zone serial numbers in the process. I then brought my plesk server up as master for all the zones. The ISP secondary zones never updated as the ISP zone serial numbers were larger than mine.

The ISP finally changed their secondary zone serial numbers to be a smaller number than the plesk server and the problem was resolved.

I believe standards help with inter-operability and this is a case in point. plesk should change to the date format serial number so they are compatable with a larger number of dns servers on the Internet.

Thanks for getting accurate information into this thread for the next person that runs into this kind of problem.

Greg
 
You must log in or register to reply here.

Similar threads

K
Resolved How to change DNS zone serial number?
Replies
3
Views
939
AYamshanov
AYamshanov
M
Resolved Slave DNS manager do not transfer new domain zone
Replies
4
Views
1K
MariuszB
M
C
Issue DKIM and SPF do not align with RFC5322. Then DMARC result is fail.
Replies
2
Views
702
cmartinez127
C
P
Resolved memcached PHP extension for PHP support instruction error
Replies
13
Views
988
Peter Debik
P
K
Forwarded to devs Environment variable for DNS related update events always passes new domain back
Replies
2
Views
306
Peter Debik
P
Back
Top