New DNS system

[#1]

From today's EOD

Quote

MikeG - documentation for new auth dns system

Is this the re-write that was going to happen :mumble mumble: years ago & got 'deferred'?
Will you be able to handle SRV records now?
Might be able to bring my domains back 'home'.

[#2]

I don't think it's enhancements of that type (no changes to the records it serves), it's a rebuild of the platform to be more resilient.
Full details here: http://community.plus.net/blog/2008/03/13/about-the-plusnet-authoritative-dns-system/

[#3]

You could be right, although it's a change of software as well & gives a starting point from which to offer more facilities, whereas I think the current system had reached a dead end some time ago.

[#4]

Hi Simon,
I'm working on two projects concurrently at the moment, Auth DNS being the lower priority one, but work is definitely ploughing on.  As for added features, you're right in saying that the software platform is changing.
With regards to hosting different record types, it may sound strange but this isn't related... however once the new system is in place it will make it easier for us to offer different record types using our existing backend systems.
As it stands, the current system reads some config from a database which is populated by our internal Workplace system.  It then writes out various config files, and the servers process these.
From a very high level, even with the new system the process is the same, except the interactions will be via a database rather than files.  The Workplace side of things (and the portal) will still need to be changed before we can offer different record types, because that's the part that populates the main database that ultimately the new system will read from.
If that doesn't make sense, just say and I'll try to clarify...
Cheers,
Mike.

[#5]

It does make sense, because after I wrote the first post in this thread I re-read what Duncan Scotland had written back in 2003 when the subject first came up. He had said something similar - it's not the DNS servers where the problem lies - that could handle the required records ok. The problem is that your internal backend systems that refresh the DNS servers don't deal with those records & thus would keep overwriting any manual change made on the DNS zone file.
It hadn't really sunk in that the same problem still existed, or I wouldn't have asked the question. I see now that I had confused DNS & DCS.
That's quite impressive slippage - the estimate then for the re-write of the domain control system was completion by Christmas 03.
Hence the diplomatic 'mumble' in the first post. 
It's not a problem - I have learned a bit more myself over the intervening years & the use we make of our domains has changed. It's probably sensible that they are hosted elsewhere for other reasons now, even if it were technically possible to move them back.

[#6]

Hi,
The problem is, that when something is not explicitly 'broken', a project will never get priority when there is more work needs doing than there is time for people to do the work.  Auth DNS is one such project; our current system 'works', not as great as we'd like, but its not currently breaking things for people so it takes a lower priority than something that does.
The AuthDNS rebuild project has taken various forms over the years, I can think of four engineers that have been assigned to it (including myself before) but it's getting the time assigned to it now as it moves up the priority list as we fix more and more things that are broken.  Several of the engineers here have been campaigning internally to redo the DCS and DNS systems as we would love to have something more manageable - but other things have taken priority.
I can say that people in the Application Development department (i.e., the people who code Workplace and the portal) are keen to use this new interface, one of the PUG items that has been requested a lot is an easy way to modify your reverse DNS records - this is trivial with the new system and probably wouldn't require much development work.  Basing everything on stored procedures makes it very easy to write an API and once the developers have an API to work with, the amount of work required to make changes their end is reduced too.
Cheers,
Mike.

[#7]

Quote from: Gricey

The problem is, that when something is not explicitly 'broken', a project will never get priority when there is more work needs doing than there is time for people to do the work.

Yes, we've got a few like that ourselves.   
Good to know that the first phase is happening - it will certainly put you in a better position for the future.

[#8]

The PUGIT item for the rDNS work is here:
http://usergroup.plus.net/pugit/view.php?id=116