Hello mark,   
      
   On Wednesday March 21 2012 13:18, you wrote to me:   
      
    RW>>> Not sure what binkp.net is...but:   
      
    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.   
      
    ml> existing legacy software can be patched... we know this from makenl   
    ml> and bluewave ;)   
      
   Unpractical and messy.   
      
    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   
    MvdV>> me wonder why.   
      
    ml> why? to be able to continue providing the service...   
      
   What service? Who does it serve?   
      
    MvdV>> The added value is zero as all the information is already in   
    MvdV>> the nodelist.   
      
    ml> really?   
      
   Yes of course. f5555.n280.z2.binkp.net is a CNAME entry for fido.vlist.eu. The   
   only source that information could have come from is the nodelist. Because I   
   never had any contact with the keeper of binkp.net or his delegates and i am   
   100% sure that my NC and RC didn't either.   
      
    ml>  the whole idea was to not have to list domains in the nodelist   
      
   Is that so?   
      
    ml> with all the problems that might have come with them... and the   
    ml> problem did come and still remain but that's another story... in any   
    ml> case, once you know the zone, net, node and point numbers, then   
    ml> looking up that system's ip information is a simple domain lookup   
    ml> away...   
      
   Again: what is the added value of extracting the host name fido.vlist.eu from   
   the nodelist - the primary source of information - and use that for the DNS   
   lookup instead of composing the f.n.z.binkp.net hostname from the fidonet   
   address, getting the CNAME record that points to the same hostname as the one   
   in the nodelist and do a DNS lookup for that?   
      
   What is the added value of the extra step?   
      
    ml> there is a "manager" for each zone's dns zone and NCs are or can be   
    ml> the managers for their nets...   
      
   There is no such "manager" for R28.   
      
    ml>  this way each section is easily maintained and kept up to date like   
    ml> the nodelist...   
      
   But what is the added value of the information is already in the nodelist?   
      
    ml> one can even make use of the dns SRV (or SVR?) records and denote   
    ml> certain ports for contact...   
      
   The nodelist provides for providing port info as well.   
      
      
   Cheers, Michiel   
      
   --- GoldED+/W32-MINGW 1.1.5-b20110320   
    * Origin: http://www.vlist.org (2:280/5555)