Re: FUCANN Fully UnCentrallized Authority for Naming and Numbers
Frob the Builder wrote: >> The problem comes when the server a domain points to is the map >>for several domains, say via Virtual Hosts or selected forwarding. Many servers >>use this if they're on a dedicated web-hoster, or for subdomains. > > Ahah, because the 'physical' server uses the URL to map to 'virtual' > servers. > You're right, the Rev 1.0 plan doesn't handle that. This only applies to HTTP requests though, AFAIK. The easiest work around, I figure, is a translation proxy that you run (locally) and channel all requests through. This proxy could look up the virtual mapping from a local domain to a "legacy" domain and vice versa. Not big on proxies myself, so not sure how feasible it'd be to either build a custom one, or to adapt an existing one. Off to look through Squid... .g -- "...not much (legal) material is out there that's full of graphics and in a consumer-friendly format to create the need for DSL." - Jack Valenti http://www.exmosis.net/"Sometimes I use Google instead of pants."
Re: FUCANN Fully UnCentrallized Authority for Naming and Numbers
> This is fine if you assume a one-to-one mapping of the original domain names to > IP addresses. The problem comes when the server a domain points to is the map > for several domains, say via Virtual Hosts or selected forwarding. Many servers > use this if they're on a dedicated web-hoster, or for subdomains. Without the The function of FUCANN is to do away with mapping monopoly. If you want my.shit or amazon.com to point to 22.33.44.55, that's what my.shit and amazon.com will resolve to. If you *then* use 22.33.44.55 to send a packet via a particular protocol (say, http), then it's up to http client to send the full URL (containg target host symbolic name among other stuff) and up to demon listening on 22.33.44.55:80 to resolve that name to a particular virtual domain. Nothing to do with FUCANN, wich operates on L3/4. If the particular server does not run "amazon.com" virtual domain it's the problem that the server owner should deal with. FUCANN is about distributing naming authority, not about pointing to unsuspecting targets. = end (of original message) Y-a*h*o-o (yes, they scan for this) spam follows: Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/
Re: FUCANN Fully UnCentrallized Authority for Naming and Numbers
At 08:04 PM 4/4/02 +0100, Graham Lally wrote: >Hey Frob, all. > >Been kicking this concept around my head for a while, but never really thought >about it seriously. Interested in taking it further and seeing what can be done >with it though. Practical usage aside (a separate issue), here are some >technical comments... We thank you for your thoughts. >Frob the Builder wrote: >> Users' FU Root Server list "froots.txt" contains lists of URLs. The >> URLs point to "fhosts.txt" files which are in the format of the >> standard "hosts" file, i.e., >> 12.34.56.78 foo.bar >This is fine if you assume a one-to-one mapping of the original domain names to >IP addresses. The problem comes when the server a domain points to is the map >for several domains, say via Virtual Hosts or selected forwarding. Many servers >use this if they're on a dedicated web-hoster, or for subdomains. Without the >ability to differentiate between the intended sites, the practicality of fucann >becomes significantly impaired, if based solely on clients' hosts files. Ahah, because the 'physical' server uses the URL to map to 'virtual' servers. You're right, the Rev 1.0 plan doesn't handle that. E.g., We find that Yahoo.com gripes when referred to by a FUCANN alias: Unknown Yahoo URL or The URL ``http://www.yahoo.foo/'' is not a valid Yahoo! URL. You probably want the following URL: http://yahoo.foo/ Perhaps a future version will allow the specification of strings to present to the physical server, e.g., 12.34.56.78 goodstuff.joe# FUCANN2.0: www.virtualname.com >> Anyone can be a FU Root Server and there is no global conflict >> resolution. The end-user performs conflict resolution when he orders >> the name of Root Servers in his local "froots.txt" file. > >Conflict resolution is fine, but in rev 1.0, revolution conflict is introduced >instead: If 2 of the sources in your froots.txt file contain 2 of the same host >entries (but for different mappings) and you want one from one and one from the >other, then more advanced conflict sorting is needed, perhaps from within a >simple client for the purpose... 208! (D0'h!) One would need a GUI to get Joe Sixpack to even consider this burning of brain cycles, though he can be expected to grok the issue natively. "Can we build it?" "Yes, FUCANN!" -with apologies to Bob the Builder (tm)
Re: FUCANN Fully UnCentrallized Authority for Naming and Numbers
Hey Frob, all. Been kicking this concept around my head for a while, but never really thought about it seriously. Interested in taking it further and seeing what can be done with it though. Practical usage aside (a separate issue), here are some technical comments... Frob the Builder wrote: > FUCANN > Fully Un-Centalized Authority for Naming and Numbers (*) > Rev 1.0 [...] > Users' FU Root Server list "froots.txt" contains lists of URLs. The > URLs point to "fhosts.txt" files which are in the format of the > standard "hosts" file, i.e., > 12.34.56.78 foo.bar > Note that fhosts.txt files can override even government names, e.g., >12.34.56.79 amazon.com > because the hosts file (into which they are merged) is consulted first. This is fine if you assume a one-to-one mapping of the original domain names to IP addresses. The problem comes when the server a domain points to is the map for several domains, say via Virtual Hosts or selected forwarding. Many servers use this if they're on a dedicated web-hoster, or for subdomains. Without the ability to differentiate between the intended sites, the practicality of fucann becomes significantly impaired, if based solely on clients' hosts files. > Anyone can be a FU Root Server and there is no global conflict > resolution. The end-user performs conflict resolution when he orders > the name of Root Servers in his local "froots.txt" file. Conflict resolution is fine, but in rev 1.0, revolution conflict is introduced instead: If 2 of the sources in your froots.txt file contain 2 of the same host entries (but for different mappings) and you want one from one and one from the other, then more advanced conflict sorting is needed, perhaps from within a simple client for the purpose... However, I'd be interested in experimenting with the idea, and have installed the various win32 ports, host-editing bat files, and set up My First Fhost File... If anyone fancies discussing this further, get in touch... .g -- "Rather than form a federation with Microsoft and work with what we had already created, there was this notion that the world should be offered an alternative" - Craig "MS CTO" Mundie
Re: *****SPAM***** FUCANN Fully UnCentrallized Authority for Naming and Numbers
Hmm, SpamAssassin rated your post as somewhat naughty. Should probably bump up the threshold from default 5 to 6, but you might want to consider below for your future posts. On Wed, 3 Apr 2002, Frob the Builder wrote: > SPAM: Start SpamAssassin results -- > SPAM: This mail is probably spam. The original message has been altered > SPAM: so you can recognise or block similar unwanted mail in future. > SPAM: See http://spamassassin.org/tag/ for more details. > SPAM: > SPAM: Content analysis details: (5.2 hits, 5 required) > SPAM: Hit! (2.5 points) BODY: Uses a dotted-decimal IP address in URL > SPAM: Hit! (2.7 points) BODY: A WHOLE LINE OF YELLING DETECTED > SPAM: > SPAM: End of SpamAssassin results -
FUCANN Fully UnCentrallized Authority for Naming and Numbers
At 02:16 AM 4/3/02 -0800, Bill Stewart wrote:
>At 05:51 AM 04/02/2002 -0800, Major Variola (ret) wrote:
>>And Morloch: your replacing DNS (as a vulnerable point of
>>failure/control) is a good idea.
>>you'll have to write a browser plug-in, or background daemon that
>>modifies the resolver's behavior, or extendable resolver. You could
>>append to Windows (et al) "hosts" file, and the normal resolver would
>>pick that up. I'm surprised there are no attempts to do that, but
then,
>>there's the Network (aka FAX) Effect operating here. Does that
>>baptista.god fellow write code?
>
>Doesn't take much in the way of code - most Windoze versions are
>willing to let you tell them up to three DNS servers to use,
>though sometimes on dialup connections you'll have to haggle with them
>about whether to accept DNS server addresses from the dialup
>instead of your dedicated ones. That means that as long as you've
>got some DNS server other than 127.0.0.1 to resolve queries for you,
>you can simply point your PC there.
Very good. (BTW, kinda a neat trick for sleazeware to replace the first
DNS
so that it can sell redirected name services..) There is the common
problem that
the DNS owners can track your queries, but your solution requires only a
single change.
(Too bad the bozo who got busted for selling .usa names didn't run a
server, he might
have had a legal chance.)
Nonetheless, here's a first draft of a proposal for the Fully
UnCentrallized Authority for Naming
and Numbers using the local host table. It includes a DOS script which
uses wget and some utilities.
FUCANN
Fully Un-Centalized Authority for Naming and Numbers (*)
Rev 1.0
First, a parable:
You arrive in a place where you can't read the language. The tourist
maps have been printed by a nasty government with a monopoly on
map-making. You want to eat, but all the business names on the
tourist map that are in your language are those approved by the
map-maker.
So you get a trusted friend to give you an overlay, a clear foil
labelled with *his* names and recommendations. You read his label for
"noodle shop" on the foil and then mark the location on the tourist
map. You find a taxi and point to the tourist map where your friend's
overlay said the good food is.
"Tourist map" = government DNS. "Taxis" = routers. "Street
addresses" = IP addresses. "Overlay foils" from your friend are the
FU Naming System host table overlays. Friends = FUNS "root servers".
You can overlay several foils, from different friends. The last one
you overlay overrules lower foils. Since you choose your friends, and
the order you query them, you are the authority over your own name
space.
One friend edits his foils by hand. Another lets anyone add to his
foils, and further allows "hierarchical" editing because when someone
adds "noodleshop" to his foil, they get a password allowing only them
to refine their definitions --thin.noodleshop, wide.noodleshop, etc.
Of course, if a more trusted friend, whose foil overlays the first's,
overrides a name, you see the more trusted name.
Problem: DNS is run by governments, subject to "social malfunction"
(censorship).
Solution: use an naming system where the user chooses whose namespaces
he overlays. Everyone is ICANN.
Implementation: PCs, Macs, etc have a local "hosts" file which is
consulted by the OS's name resolver before the resolver queries the
government DNS. By adding IP & name pairs to this hosts file, we
override government naming authority with that of our own choosing.
This resembles the old Sun "Yellow Pages" hosttab replication ("NIS"
after BT thrashed Sun about "YP").
A Client runs a FUCANN Daemon which periodically queries hosts listed in
a local FUCANN Root Server List "froots.txt". Root Servers listed later
in froots.txt override earlier FRoot Servers. Users edit their
froots.txt file using any text editor.
Users' FU Root Server list "froots.txt" contains lists of URLs. The
URLs point to "fhosts.txt" files which are in the format of the
standard "hosts" file, i.e.,
12.34.56.78 foo.bar
Note that fhosts.txt files can override even government names, e.g.,
12.34.56.79 amazon.com
because the hosts file (into which they are merged) is consulted first.
Anyone can be a FU Root Server and there is no global conflict
resolution. The end-user performs conflict resolution when he orders
the name of Root Servers in his local "froots.txt" file.
This allows anyone to create their own top level domains, merely by
listing names in their exported fhosts.txt file. It is up to each
Root Server to resolve any conflicts in their fhosts.txt file
---either by deciding manually, or a first-come first-served scheme
(with authentication for name-refinements if they want, allowing
DNS-like hierarchical management), etc.
A local Fdaemon does this loop forever:
For each URL in froots.txt,
retrieve the fhosts.txt file
Merge it, uniquely, with the local hosts file
Sleep
froots.txt file:
http://www
