Subj : proposed new nodelist
To : Peter Knapper
From : Johannes Lundberg
Date : Sat Jul 20 2002 03:46 pm
HK> it does not indicate what services are available and on
HK> what ports they reside.
pk> Ahhh, but it CAN, and even more, it can then allow the mapping of those
pk> services to the apprpriate place by using some external glue to handle
pk> it...
I thought a bit of this. Using sub-domains for services/transport-protocols
work quite well? IE, to find out if host 2:206/149 has binkp-access, you simply
resolve 'binkp.f149.n206.z2.fidonet.net'. And to list the services available,
you do a zone transfer on f149.n206.z2.fidonet.net. Port specification could
be solved with a record looking like 'p4001.binkp.f149...'. The old BinkD
@fidonet.net way would still work, as the f149-record would point to the right
IP already. And new software developers would be instructed in using the new
format.
Comments?
(This could also be done using a IN HINFO-record in the DNS, to avoid zone
transfers)
pk> A feature being offered by some Dynamic DNS environments, links an HTTP
pk> URL to a persons home PC, however because that persons ISP prohibits them
pk> running an HTTP server on port 80, the DDNS reference for that web server
pk> points to what I will call a "port mapper", and that task automatically
pk> intercepts that Port 80 request and maps that to the customers real Web
pk> Server which is actually available on a different port.
This is indeed quite nice, but if you don't want to modify the existing IP
protocols (like BinkP), you will have a proxy forwarding all the traffic to the
right IP. And this would probably require huge amounths of bandwidth on the
proxy.
Changing the existing protocols, and having the proxy just saying 'He is
actually at IP 193.13.9.98, port 4001' would work. But in that case, I think it
would be better to skip using DNS, and having our own noderesolver-server
instead, who's prodiving the correct information from the beginning.
