RW>> Not sure what binkp.net is...but:

 ml> binkp.net is what was quickly put in place to replace fidonet.net when
 ml> its domain registration expired and the owner couldn't get in to pay
 ml> up the subscription... loosing fidonet.net would have really hurt
 ml> fidonet's internet side operations...

 MvdV> One of the reasons I never embraced f5555.n280.z2.fidonet.net is
 MvdV> that it depends on one person. Fidonet is not a legal entity, so
 MvdV> the domain must be registered by a private person. If that person
 MvdV> dies, looses interest or leaves Fidonet with slamming doors,
 MvdV> there is a problem.

or if they loose the access credentials as happened with fidonet.net...

 MvdV> Shifting to binkp.net is no good for those with legacy software
 MvdV> that is not configurable. Plus that the basic problem -
 MvdV> dependency on one person - remains. 

existing legacy software can be patched... we know this from makenl and bluewave ;)

 MvdV> To my surprise I find that f5555.n280.z2.binkp.net exists. I
 MvdV> never asked for that, I can only assume someone scanned the
 MvdV> nodelist and derived a zone file for binkp.net from it. Makes me
 MvdV> wonder why. 

why? to be able to continue providing the service...

 MvdV> The added value is zero as all the information is already in the 
 MvdV> nodelist.

really? the whole idea was to not have to list domains in the nodelist with
all the problems that might have come with them... and the problem did come
and still remain but that's another story... in any case, once you know the
zone, net, node and point numbers, then looking up that system's ip
information is a simple domain lookup away...

there is a "manager" for each zone's dns zone and NCs are or can
be the managers for their nets... this way each section is easily
maintained and kept up to date like the nodelist... one can even make use
of the dns SRV (or SVR?) records and denote certain ports for contact...

)\/(ark