are they three nodes ot is it one?
i would have to say yes,
Bye <=-
Besides, I've yet to come across a program that amkes any use of
that field in the nodelist other than to simply display it. ;-) It's
more for human readability than anything else.
my FrontDoor sure makes use of it... i've settings to call systems
with speeds above and below certain thresholds... i can even set up certain modem inits based on the speed field, if i need to...
On Jul 14, 2002 Jasen Betts wrote to Peter Knapper:
My current messages have been aimed at something completely new
JUST for IP nodes, leave the PSTN side of things alone as they
are
Leave them broken? why?
The current Nodelist is NOT broken to me.
you are not all of fidonet...
It is not broken for me either. Seeing that the current nodelist
format has kept Fidonet running for at over 10 years, including
supporting IP nodes, I don't think you could say it is broken.
Granted, although the current format does support IP nodes, it is
a kludge and what we are looking for here is a more ideal
solution. If we can use standard Internet protocols and services
then I believe that is the correct way to go. No point in
inventing our own protocols and services which, in reality, nobody
is going to code up
That's a good thing, but you're still relying on a nodelist of
sorts, all you've trimmed from it are the capability flags. if
you're a dedicated anarchist you may want to to a less structured
model like gnutella for instance. - something like that could
probably be modified for ftn
Gnutella-type models are based on content, not nodes.
Is this about some *Cs disallowing certain nodelist entries
(mainly those notconforming to FTS0005) they claim to do this
because those "bad" entries cause problems with some systems.
And why is this a bad thing?
This is why I want to transform the nodelist into something that
can contany any useful information and is fututre proof and easy
to extend. then the won't have a technical argument against those
nodes.
Totally disagree, a technical argument should be the only argument
used to disallow nodes. If a node is causing problems on the
network, they should be denied access to the network until they
fix the problem
Of course it does. If the node is NOT listed as crash, then its
the callers fault for attempting to do so when they are not
supposed to. If I am unable to send mail direct to a node (for
whatever reason), then I Host Route it via the NC/HUB
There are HUBS (and NCs and atleast one RC) with no published
POTS connection.
I believe that every Host node (and a host node does not have to
be the NC)
should have a POTS connection and should have the
capability to get a netmail to any of the nodes in the net.
RCs don't have to route mail to their nets
Bye <=-
Malcolm Miles has found a solution that looks like it fits the
bill nicely.
manually? The nodelist is distributed automatically (it says so
in P4 so it must be true :)
If we are using the Internet, why not go and get the info, rather
than waiting for it to arrive?
The nodelist had to be manually distributed when Fidoent was PSTN based, however as it moves to an IP base, we have a chance to make it work
much better by doing this automatically using the DNS..
why do you want to cut the off-internet nodes off from the
nodelist?
I dont. The Nodelist will still continue for all the PSTN nodes
left in the network. The Nodelist is not really needed by IP
Nodes, except when communicating with PSTN nodes. Hhowever even
that could be handled by a PSTN <> IP Gateway that used some
intelligence on behalf of the traffic using it
doing without it does have its merits. but really withpout the
nodelist it's not fidonet. (says that in p4 too)
The reality is that any FTN node can communicate with any other
FTN node, provided they know how to contact each other (IE phone
numbers). No Nodelist is actually needed
If you must (and my prefernce is to have no such entry at all),
all you need is a simple indicator against a node number, that a
specific DNS entry should be the reference point for ALL further
communication with that node
We can't add anything to the SLF nodelist it's full already.
No its not, it had 37,000 entries in it at its peak,
All an ION node entry needs is A PVT listing,
Remote copy of what? If they are PSTN, then all the info they need
should be in the Nodelist. If they are IP, then they can use the
DNS for it
Bye <=----
Hi Jasen,
A new format YES, but as an addition to the current nodelist, NOT
a replacement
Why not duplicate the nodelist information in the new file, it
would make its use easier ...
Because its not needed.
Leave them broken? why?
The current Nodelist is NOT broken to me.
you are not all of fidonet...
I never said I was, however I am a member who has no problems with
the current Nodelist data, I just understand that it will not
always work for some.
(do you really want me to list my gripes with what is again?)
Well never having seen your previous comments I have no idea what
you are talking about. If you are talking about the way people
have mangled Nodelist entries to do something they wanted and
"broke" the way the Nodelist works for others, then I am not
surprised.
but I see no way that this plan of yours can benefit users of
existing software.
Its not designed to, it is only for IP nodes, the PSTN segment
always has the nodelist to satisfy their needs
like the nodelist? like echomail routing? you're relying on
others every day when you use fidonet.
So minimise the amount you have to repy on them.
One thing a lot of people forget is that just about the entire
Fidonet Backbone is moved using IP these days. All these IP nodes
work using something other than Nodelist info. Amazing how they
manage to do this without using the Nodelist.......;-)
And this is not somethoing than cold be implemented overnight.
Exactly the reason why it needs to be worked out properly and
agreed with as many Fidonet people as possible, before something
is started
The nodelist is already in the control for the *C structure, it's
their main reason for existing (as i read P4), if they kick you
out of the nodelist a server on ypur PC will do you not good
whatsoever.
Something somewhere has to define what makes up Fidonet so others
can get a feel for what Fidonet really is. The Nodelist is the
current master list. The Nodelist and the DNS records could be the
furture master list..
If you get kicked out of the Nodelist, then you have exactly the
same procedures available to rectify that (via a Policy complaint
to the *C structure)
The end node then has the ability to manage THEIR membership as
they wish, OR use a "shared" server
Is this about some *Cs disallowing certain nodelist entries
(mainly those notconforming to FTS0005) they claim to do this
because those "bad" entries cause problems with some systems.
Nothing like that at all, its just another option for distributing responsibility
don't worry about that, it's alreadly lost.
No it isn't. It just needs putting back on the rails by giving
those that made the "invalid" changes the option to correct the
mistakes
No. The Mailer uses the Nodelist to perform the action defined by
the Operator. The decision to Host Route, Network Route, Crash or
Hold mail, is all with the Sysop. It is up to the Sysops(s) to
ensure their system has the best chance possible of succeeding
however the present nodelist doesn't evem provide a way fr a
If I wish to crash a Netmail to someone, and a crash poll fails
for a reason I can't determine remotely, I then Host Route that
Netmail. The most likely reason for Crash failing that I have
found, is because the Nodelist entry is not strictly telling the
truth for some reason. This is becoming more and more of the real situation these days, which is why I usually Route all my Netmail,
I don't usually bother to even try Crashing it
There are HUBS (and NCs and atleast one RC) with no published
POTS connection.
Then (IMHO) strictly speaking, it sounds like the *C above them is
not doing their job, an *C should ALWAYS be PSTN contactable
somehow to be compliant with P4.
I believe this is most important
for NC's, and also why it can be a huge bone of contention with
some people. I also understand that some Zones may view this
differently
how's a mailer supposed to know that it's the same destination
with just a different "name"
But its not the same destination, its a different node number.
< text deleted >
some of them _may_ be one sysop running multiple fido systems but
most of them appear to me to be the same BBS but with too many
connections to list on a single nodleist line (either line
length, flags conflict, or some other cruft is forcing them to
list multiple times)
Initial appearances can be very deceptive. A different type of
modem may require different flags to be shown, or hours of service
for different reasons.
I'm aware of 1900 others.
Have you considered that you may be too picky over other peoples
reasons for doing this?
As I described above, and they are being used like that.
Bye <=----
I'm not against change if:
1. It will do some good. 2. There is software to support the new
format. 3. There is a way to support the old software currently in
use.
Bye <=----
On (15 Jul 02) Malcolm Miles wrote to Frank Vest...
Hello Malcolm,
True, but those originate from the Internet. As I described, the spam would originate from a Fidonet Node in the Fidonet Nodelist operating Fidonet mailer and no way to stop them since they added their own
Nodes listing to the Fidonet Nodelist. Yes, the *C could remove the listing, but the Node just adds it back in.... and the battle rages.
"It's out!"
"It's in!!"
"It's OUT!!!"
"It's IN!!!!!"
Bye <=-
"spam bots" could be made to "harvest" Node addresses for spam
purposes. In reality, harvesting would not be needed. Just grab a
copy of the Nodelist, add yourself into it and spam away. :(
It is happening already. I throw away hundreds of Fidonet-
addressed spam daily at my Internet gateway.
True, but those originate from the Internet. As I described,
the spam would originate from a Fidonet Node in the Fidonet
Nodelist operating Fidonet mailer and no way to stop them
since they added their own Nodes listing to the Fidonet
Nodelist. Yes, the *C could remove the listing, but the Node
just adds it back in.... and the battle rages.
there would be a lock mechanism... has to be... and the
"controlling commitee" (if you will) would have that
capability...
In the Internet world, the control is in large part by the
ISP and you pay the ISP for access. Fidonet has no such t
hing... therefore, there would be no controlling committee
except the *Cs and they would have little power with a
Nodelist that is open to addition by anyone. My biggest
fear for Fidonet is that it will be opened up to the
point that anyone can just add themselves into Fidonet
without any questions asked.
If Fidonet is not careful, it could become a place that is
little different from the Internet is regards to spam. Much
like the spammers, a person could jump from Node number to
Node number. Having the ability for "anyone off the street"
to add themselves into the Fidonet nodelist is not a good
thing for Fidonet.
Anyway, this is getting off the topic of a Nodelist format.
:-)
Besides, I've yet to come across a program that
amkes any use of that field in the nodelist other
than to simply display it. ;-) It's more for human
readability than anything else.
my FrontDoor sure makes use of it... i've settings
to call systems with speeds above and below certain
thresholds... i can even set up certain modem inits
based on the speed field, if i need to...
Considering the nodelist can only contain speeds up to 9600
(yes, I know Zone 1 does it's own thing ;-) ),
the other modem flags are far more useful for that.
I also need to seperate calls according to the receivers
capability (ISDN, V34, V32, etc.) and I do it with those
flags.
Considering the nodelist can only contain speeds up to 9600
where do you get that "can only contain" from??
the other modem flags are far more useful for that.
that's all fine and good... however, if i never want to directly
contact a system that can only do 9600, then i can block that or whatever...
I also need to seperate calls according to the receivers
capability (ISDN, V34, V32, etc.) and I do it with those
flags.
show me which of those flags is the one that indicates 9600?
my POINT in this was to prove to you that the SPEED field ~is~ useful
and not there just for human convienience...
Requiring Hosts to be POTS capable is unlikely to be a permanent
solution unless IP nodes can exist without a host.
The main problem I see with multi-listed systems is the mailer being
able to recognise it as multi-listed and pick the most appropriate
node so send the mail to.
Malcolm Miles has found a solution that looks like it fits the
bill nicely.
Yeah it does indeed.
PSTN nodes would still need the weekly nodediff, as would those
Iinternat capable nodes using existing software.
could PSTN nodes could have DNS entries without having IP addresses
(I expect malcolm knows the answer to this), that could help.
True, but those originate from the Internet. As I described, the spam would originate from a Fidonet Node in the Fidonet Nodelist operating Fidonet mailer and no way to stop them since they added their own
Nodes listing to the Fidonet Nodelist. Yes, the *C could remove the listing, but the Node just adds it back in.... and the battle rages.
"It's out!"
"It's in!!"
"It's OUT!!!"
"It's IN!!!!!"
Only give the *C authority to add/remove entries, let the node modify their entry but not add new ones.
could PSTN nodes could have DNS entries without having IP addresses
(I expect malcolm knows the answer to this), that could help.
Doesn't make any sense. The DNS is a mechanism for
converting names to IP addresses. No IP address, no need for a DNS entry.
show me which of those flags is the one that indicates 9600? i,
too, can make adjustments based on the flags..
;S V29 CCITT V.29 9600 bps half duplex
;S V32 CCITT V.32 9600 bps full duplex
;S V32b ITU-T V.32 bis 14400 bps full duplex
;S V32T V.32 Terbo
;S VFC V.Fast Class
;S V90C ITU-T V.90 modem Client
;S V90S ITU-T V.90 Server.
;S HST USR Courier HST
;S H14 USR Courier HST 14.4
;S H16 USR Courier HST 16.8
;S H96 Hayes V9600
;S CSP Compucom Speedmodem
;S ZYX Zyxel series
;S Z19 Zyxel 19,200 modem protocol
;S X2C US Robotics x2 client.
;S X2S US Robotics x2 server.
;S MAX Microcom AX/96xx series
Bye <=-
On Jul 16, 2002 Jasen Betts wrote to Peter Knapper:
Malcolm Miles has found a solution that looks like it fits the
bill nicely.
Yeah it does indeed.
Now all we have to do is find some developers that will include
the proposal in their product. There is virtually zero development
being done on Fidonet software except for some in Russia. I am
sure that the Russian developers don't read this echo
PSTN nodes would still need the weekly nodediff, as would those
Iinternat capable nodes using existing software.
All nodes would still need the nodelist as it defines who belongs
to Fidonet. Sysop details, location, status (down, hold) would
only be included in the nodelist
Bye <=-
On Jul 16, 2002 Jasen Betts wrote to Peter Knapper:
Requiring Hosts to be POTS capable is unlikely to be a permanent
solution unless IP nodes can exist without a host.
Why not? The PSTN system is not going to go away in the future.
Requiring a host node to have a phone line that can receive calls
at ZMH is not an onerous requirement. If all nodes in a net are
IP-capable then the net can be quite large so fewer hosts in a
region/zone would be required than today
The main problem I see with multi-listed systems is the mailer
being able to recognise it as multi-listed and pick the most
appropriate node so send the mail to.
It is not the mailer's responsibility to determine which node a
message should be sent to. It is the mailer's responsibility to
select the most appropriate transport mechanism to use to send a
message to a particular node
Bye <=-
single JB>> field and put the modem speed in there too.Here I've grouped all the flags for each connection into a
That would work. Like I said, the format of the new list is not a
problem and is expandable. The old list is generated from the new list
and has no way to be wrong...
depends what you mean by "wrong"... a certain zone 1 sysop who I meantioned earlier has some ususual ideas about what comprises a valid nodelist entry.
if the conversion program is done right.
The new list could have a flag at position 11 that indicated the type
of connection.. IE: ION for Internet only - no POTS. IPN for Internet
and POTS. Then the other flags could tell what "protocol" is available
at that Node. IE: IBN for binkp and so on.
no. that's not what I mean at all. one connectio-type flag per
connection. if they're posts only they start with a pots
connection-type flag and omit the IP flag, if they're IP only then
they omit the POTS connection.
,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
IP,IP.or.url.com,CM_MO_LO_IBN_ITN,
POTS,<phone number or unlisted>,33600_V34_V42b_CM_XA
,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
POTS,<phone number or unlisted>,33600_V34_V42b_CM_XA
,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
IP,IP.or.url.com,CM_MO_LO_IBN_ITN,
the fact that you can't fit all the information from this into a
regular nodelist isn't a problem. users of the conversion software
would set up some rules about which connection types they prefer and
the software would examine the fileds and spit out a SLF nodeline with
the most suitable
connection type listed (or possibly PVT etc if nothing was suitable)
I think that with the old nodelist being generated from the new list, there will be a lot of problems solved. :-)
yeah. but not all of them. uncontactable hubs and some other strange
zone 1 inventions won't be deterred by a new nodelist and will come
out of the converter just as bogus .... unless we put some
tricks in the converter (like replacing connection info of the bogus
hub with that of their netmail feed, (or that of a local, or global,
IP gateway)
Why not? The PSTN system is not going to go away in the future.Requiring Hosts to be POTS capable is unlikely to be a permanent
solution unless IP nodes can exist without a host.
it;s already gone. making rules in this echo won't force the existing IP-only or uncontactable zone 1 hosts to install phone lines and
modems.
Requiring a host node to have a phone line that can receive calls
at ZMH is not an onerous requirement. If all nodes in a net are
IP-capable then the net can be quite large so fewer hosts in a
region/zone would be required than today
yeah, that requires reorganisation and loss of political power and the
Z1 people take the politics seriously - what else can explain their
two echomail distribution systems.
that will likely remain as many are on dialup connections and unless fidonet also sets up a ddns, there's few ways for one to have a static domain name for a dynamic dialup...
The translation software would make the old style list and take only
what is required for that list from the new style. No matter what the
Node put in the new style, the old style would almost certianly be correct... I think.
Of course, nothing is fool proof. :-))
Ah ha! I think I see what you mean. The new style list would have two
or three lines for each Node
. The first line would always be the
"basic" Node information. The next line(s) would depend on the type of connection capabilities and be designated by either the POTS or IP
flag, or both, as needed? If I got this thought my thick head right?
This would work just fine with me... Probably be easier to read and translate to boot.
I was thinking that the *Cs would be the ones running the conversion program to generate the old style list for distribution along with the
new list... IE:
New Style List = nodeip.*
Old Style from conversion program = nodelist.* (just as always).
yeah. but not all of them. uncontactable hubs and some other strange
zone 1 inventions won't be deterred by a new nodelist and will come
out of the converter just as bogus ....
Remember, Nothing is fool proof because fools are so ingenious. :-))
Actually, you are right. There will still be some problems, but it
might be easier to deal with those problems... I dunno.
Bye <=-
The translation software would make the old style list and take only
what is required for that list from the new style. No matter what the
Node put in the new style, the old style would almost certianly be correct... I think.
Maybe syntatically correct... there'd still be uncontactable hosts,
etc, so it wouldn't be functionally correct.
Ah ha! I think I see what you mean. The new style list would have two
or three lines for each Node
nah, one line, I just split them that way for easier reading. (I
should have said) the POTS section has the same number of commas as
the IP section or any other type or connection, so if old(future) sofrware finds something it doesn't understand it knows to just skip
3 commas and there'll be another connection to look at (or a new line with a new node).
. The first line would always be the
"basic" Node information. The next line(s) would depend on the type of connection capabilities and be designated by either the POTS or IP
flag, or both, as needed? If I got this thought my thick head right?
Pretty much, but also ISDN atleast where where it's incompatible with POTS PACNet too if it's still running, even packet radio if someone's
got X25 fido software and there's no rules against it...
This would work just fine with me... Probably be easier to read and translate to boot.
I hadn't thought of that but, having a reminder (int the form of connection-type keyword) every three fields would reduce the "forest
of commas" problem
I was thinking that the *Cs would be the ones running the conversion program to generate the old style list for distribution along with the
new list... IE:
they could but the node in their net may be sing different software
and therfore want different information in their nodelist.
those with IP nodes would want IP numbers, those with modems would
want phone numbers, those with a different brand of modem might want a different phone number etc...
And for each of these nodes the NC has to keep a current nodelist and
then build a new one, compare the two and then produce a diff.
Doesn't make any sense. The DNS is a mechanism for converting
names to IP addresses. No IP address, no need for a DNS entry.
show me which of those flags is the one that indicates 9600? i,
too, can make adjustments based on the flags..
the following flags mean 9600 or faster
;S V29 CCITT V.29 9600 bps half duplex
;S V32 CCITT V.32 9600 bps full duplex
;S V32b ITU-T V.32 bis 14400 bps full duplex
;S V32T V.32 Terbo
;S VFC V.Fast Class
;S V90C ITU-T V.90 modem Client
;S V90S ITU-T V.90 Server.
;S HST USR Courier HST
;S H14 USR Courier HST 14.4
;S H16 USR Courier HST 16.8
;S H96 Hayes V9600
;S CSP Compucom Speedmodem
;S ZYX Zyxel series
;S Z19 Zyxel 19,200 modem protocol
;S X2C US Robotics x2 client.
;S X2S US Robotics x2 server.
;S MAX Microcom AX/96xx series
dunno which ones your hardware is compatible with though.
nah noded using existing software still need all the
info they needed yesterday and if they don't know
how to get it from a DNS they'll need to get it from
the nodelist... after a while most nodes will probably
upgrade their software... but when?
Requiring a host node to have a phone line that can
receive calls at ZMH is not an onerous requirement.
If all nodes in a net are IP-capable then the net can
be quite large so fewer hosts in a region/zone would
be required than today
yeah, that requires reorganisation and loss of political
power and the Z1 people take the politics seriously -
what else can explain their two echomail distribution
systems.
It is not the mailer's responsibility to determine
which node a message should be sent to. It is the
mailer's responsibility to select the most appropriate
transport mechanism to use to send a message to a
particular node
yeah, what's a node if the same system is in the
nodelist three times with three different phone
numbers (maybe with different brands of modem) but
all attached to the same messagebase is it one node
or three?
Well... My thought was that since the person operating the
conversion program decides which fields to put in what
order in the old style list, it would be hard to make the
old style list incorrect (wrong).
Of course, nothing is fool proof. :-))
Ah ha! I think I see what you mean. The new style list
would have two or three lines for each Node. The first
line would always be the "basic" Node information. The
next line(s) would depend on the type of connection
capabilities and be designated by either the POTS or IP
flag, or both, as needed? If I got this thought my
thick head right?
I was thinking that the *Cs would be the ones running
the conversion program to generate the old style list
for distribution along with the new list... IE:
that will likely remain as many are on dialup connections
and unless fidonet also sets up a ddns, there's few ways
for one to have a static domain name for a dynamic dialup...
You can point your fidonet.net (or whatever) to your selected DynDNS-provider with a CNAME. All DNS-resolvers follow CNAMEs
until they find an A-record, so dynamic IPs and dialups is not
a problem, if you don't mind using existing DynDNS-providers.
Ah ha! I think I see what you mean. The new style list
would have two or three lines for each Node. The first
line would always be the "basic" Node information. The
next line(s) would depend on the type of connection
capabilities and be designated by either the POTS or IP
flag, or both, as needed? If I got this thought my
thick head right?
hummm... that's sounding like my 2nd proposal...
I was thinking that the *Cs would be the ones running
the conversion program to generate the old style list
for distribution along with the new list... IE:
no need for the *Cs to be involved in the conversion process at all... only those with machines incapable of executing the conversion
software would need _someone_ to convert the new list to the old list
for them...
nah noded using existing software still need all the info they
needed yesterday and if they don't know how to get it from a DNS
they'll need to get it from the nodelist... after a while most
nodes will probably upgrade their software... but when?
i can't see a commodore64 on the net doing these lookups... there
are still some in existance and active as full nodes... at least
to my knowledge, anyway..
heck, i'm sure there are also trs-80s still out there as well as
amigas and other non-PC (PC == personal computer) systems..
Bye <=----
what's a node if the same system is in the nodelist three
times with three different phone numbers (maybe with different
brands of modem) but all attached to the same messagebase is it
one node or three?
a messagebase does NOT a node make...
Bye <=-
no need for the *Cs to be involved in the conversion process at
all... only those with machines incapable of executing the
conversion software would need _someone_ to convert the new list
to the old list for them..
Bye <=-
what's a node if the same system is in the nodelist three
times with three different phone numbers (maybe with different
brands of modem) but all attached to the same messagebase is it
one node or three?
a messagebase does NOT a node make...
true, do you intend to answer the question? I'll rephrase it
in more general language, if three SLF nodelist lines are
functionally equivalent as far as the handling of mail, FREQs
etc sent to them but inly differ in their conection mechanisms
(mailer type, transport mendiam, etc) are they three nodes ot
is it one?
On a technical basis, Fidonet should operate as follows.... One Zone
and one Net. When that Net becomes full, start another Net. Fill
On a technical basis, Fidonet should operate as follows.... One Zone
and one Net. When that Net becomes full, start another Net. Fill
Didn't you just say "one zone and one net"?
I've got a better idea: 64bit integers.
Your net numbers will _never_ run out, unless air particles themselves start getting IP addresses.
On a technical basis, Fidonet should operate as
follows.... One Zone and one Net. When that Net
becomes full, start another Net. Fill
Didn't you just say "one zone and one net"?
I've got a better idea: 64bit integers.
Your net numbers will _never_ run out, unless
air particles themselves start getting IP
addresses.
True, but not within Fidonet specs... I think.
are they three nodes ot is it one?
i would have to say yes,
Bye <=-
Didn't you just say "one zone and one net"?
True, but not within Fidonet specs... I think.
are they three nodes ot is it one?
i would have to say yes,
yes=3 or yes=1 ? or yes="that's an unfair question"
Didn't you just say "one zone and one net"?
True, but not within Fidonet specs... I think.
Oh. I thought you people were making up new specs.
Thought it was kinda dumbassed to still old fidonet software for
the new specs..
Bye <=-
Bye <=-
You can point your fidonet.net (or whatever) to your selected DynDNS-provider with a CNAME. All DNS-resolvers follow CNAMEs
until they find an A-record, so dynamic IPs and dialups is not
a problem, if you don't mind using existing DynDNS-providers.
true... very true... until you run into some system that insists on IP number instead of domain name... i'm thinking of a situation where one wants to go the other way...
You can point your fidonet.net (or whatever) to your selected
DynDNS-provider with a CNAME. All DNS-resolvers follow CNAMEs
until they find an A-record, so dynamic IPs and dialups is not
a problem, if you don't mind using existing DynDNS-providers.
true... very true... until you run into some system that
insists on IP number instead of domain name... i'm thinking of
a situation where one wants to go the other way...
I don't get your point here about situations where one would
want to go the other way around. Please explain. :)
could PSTN nodes could have DNS entries without having IP addresses
(I expect malcolm knows the answer to this), that could help.
It could make sense if it could be used by IP only nodes to find an
IP ==> PSTN Gateway to reach the target PSTN node.
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,029 |
| Nodes: | 17 (0 / 17) |
| Uptime: | 30:09:52 |
| Calls: | 503,735 |
| Calls today: | 25 |
| Files: | 159,107 |
| D/L today: |
11,839 files (1,792M bytes) |
| Messages: | 445,010 |
| Posted today: | 3 |