Mixed format addresses
Bill Fenner
|fen...@postscript.cs.psu.edu (Bill Fenner) writes:
|| Because the whole concept of the DNS was that everyone would get registered,
|| if only with an MX. Since registration in the .US domain is free and easy, a
|| registering your own domain name is free and slightly more difficult, there's
|| no excuse for any UUCP-only site not to have a domain name.
|
|"registration in the .us domain is...easy" ??
Yup.
|The nearest MX'er would be a long distance connect for whoever
|provided the service.
An MX'er doesn't necessarily have to be directly connected to the site it is
MX'ing for. Any Internet site that can get mail to you *somehow* can be your
MX'er.
Bill
Bill Fenner
|In <Byw7M...@cs.psu.edu> fen...@postscript.cs.psu.edu (Bill Fenner) writes:
|>There is no way to register yourself as an Internet->UUCP gateway
|
|Wouldn't:
| *.UUCP. IN MX 500 my.host.domain.
|in the DNS do this?
No; you shouldn't put top-level records in your own name server. They might
or might not end up getting picked up by the top-level name servers. Plus,
if they did get picked up by the root name servers, do you really want *every*
piece of mail from the Internet to the .UUCP pseudo-domain going through your
machine? (Hint: psuvax1 stopped being the BITNET->.UUCP gateway because it
was getting overloaded, and BITNET is orders of magnitude smaller than the
Internet...)
Bill
David Keegel
>In article <N-9KrAE...@boombox.apana.org.au> d...@boombox.apana.org.au writes:
>|In <Byw7M...@cs.psu.edu> fen...@postscript.cs.psu.edu (Bill Fenner) writes:
>|>There is no way to register yourself as an Internet->UUCP gateway
>|
>|Wouldn't:
>| *.UUCP. IN MX 500 my.host.domain.
>|in the DNS do this?
>No; you shouldn't put top-level records in your own name server.
I never said you'd put it in your nameserver, you get it put into the
DNS (officially). Ie: that line would just appear as is (subsitute
my.host.domain for whatever deluded host thinks it wants to be an
InterNet->.UUCP gateway) in the root zone file at nic.ddn.mil.
Of course, if there is more than one deluded site which thinks it
wants to be advertised as Internet->.UUCP gateway, just add a few more
lines, as long as they all agree on the pref so that MX-based mailers
will share the load between them.
>if they did get picked up by the root name servers, do you really want *every*
>piece of mail from the Internet to the .UUCP pseudo-domain going through your
>machine?
Hey, I never said you'd want to -- the question was, "can you do it?"
If we assume that there are n (0<n<10) sites that are prepared to accept
all mail from Internet to .UUCP which is not otherwise handled (a BIG
assumption, I know) this could, technically, be done. Can we agree
that it is theoretically possible to advertise inet->.uucp in the DNS?
I guess a technical reason why it would be a bad idea is that there are
probably some Internet sites out there whose mailers are misconfigured
enough to check MXes before handling local uucp traffic (not that they
should be asking the DNS to resolve a *.UUCP name in the first place!).
--
David Keegel Home: <d...@boombox.apana.org.au> Tel: +61 3 593-1460
Willard Dawson
> Hey, I never said you'd want to -- the question was, "can you do it?"
>
> If we assume that there are n (0<n<10) sites that are prepared to accept
> all mail from Internet to .UUCP which is not otherwise handled (a BIG
> assumption, I know) this could, technically, be done. Can we agree
> that it is theoretically possible to advertise inet->.uucp in the DNS?
I think so.
> I guess a technical reason why it would be a bad idea is that there are
> probably some Internet sites out there whose mailers are misconfigured
> enough to check MXes before handling local uucp traffic (not that they
> should be asking the DNS to resolve a *.UUCP name in the first place!).
There are indeed some Internet sites configured in just such a manner,
or, rather, there were just a few days ago. Perhaps they've all been
paying attention and have fixed their mis-configurations? One in
particular, at pa.dec.com. I've been corresponding with a DEC person,
who was supposedly pursuing the problem, but I've not been watching to
see whether they've made any recent changes, so I don't know how they
stand.
For what it's worth, I've come across the same problem, mailer software
querying DNS on host.UUCP, on several "Internet" hosts. If we accept
the statement (from more than one participant on these newsgroups) that
.UUCP is INVALID (typically shouted, as if that would make it somehow
more logical), the Internet hosts surely have no business in querying
DNS for that domain, yes?
We likely all agree on that one. But, how do we make that information
common knowledge?
>
> --
> David Keegel Home: <d...@boombox.apana.org.au> Tel: +61 3 593-1460
--
daw...@willard.UUCP (Willard Dawson)
gatech!vdbsan!willard!dawson
emory!uumind!willard!dawson
Willard's House BBS, Atlanta, GA -- +1 (404) 664 8814
Alan P Barrett
In article <e539VB...@willard.UUCP>,
daw...@willard.UUCP (Willard Dawson) writes:
> For what it's worth, I've come across the same problem, mailer software
> querying DNS on host.UUCP, on several "Internet" hosts. If we accept
> the statement (from more than one participant on these newsgroups) that
> .UUCP is INVALID (typically shouted, as if that would make it somehow
> more logical), the Internet hosts surely have no business in querying
> DNS for that domain, yes?
An Internet host cannot *know* that .UUCP in invalid unless it either
queries the DNS and gets back an error indication
or has special-case information somehow installed in its configuration.
A good argument can be made for avoiding special-case information, and
Internet hosts that believe such an argument have every right to query
the DNS for *everything*, including .UUCP sites. They will, of course,
get back an error indication, which will tell them that the domain is
invalid, and they will accordingly bounce the improperly addressed mail.
> We likely all agree on that one.
Apparently not.
--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: bar...@ee.und.ac.za Bang: m2xenix!undeed!barrett
Melvin Klassen
> ... various stuff ...
Private E-mail to him produces the "bounce" message:
---
Subject: Returned mail: unknown mailer error 255
Date: Thu, 24 Dec 92 13:44:49 -0500
From: MAILER...@mathcs.emory.edu (Mail Delivery Subsystem)
----- Transcript of session follows -----
uux failed. code -1
554 <daw...@willard.waffle.atl.ga.us>... unknown mailer error 255
----- Unsent message follows -----
From: kla...@sol.UVic.CA (Melvin Klassen)
Subject: Re: Mixed format addresses
In article <e539VB...@willard.UUCP> you write:
>We likely all agree on that one. But, how do we make that information
>common knowledge?
Well, define UUCP as a valid-domain,
and put it into the top-level name-servers.
Then, every query will return an **authoritative** "not found" result.
A "smart" name-server will put the "not found" response into its cache,
and will never bother the root name-server for a long time!
David Keegel
>For what it's worth, I've come across the same problem, mailer software
>querying DNS on host.UUCP, on several "Internet" hosts. If we accept
>the statement (from more than one participant on these newsgroups) that
>.UUCP is INVALID (typically shouted, as if that would make it somehow
>more logical), the Internet hosts surely have no business in querying
>DNS for that domain, yes?
I wouldn't say that ".UUCP" is invalid. But I would agree that Internet
hosts have no business querying the DNS for whatever.uucp.
>We likely all agree on that one. But, how do we make that information
>common knowledge?
I guessed it was common knowledge among "larger" (whatever that means)
internet sites. Or at least the well-behaved ones. If for no other
reason than to reduce traffic to the root nameservers (gee, wouldn't
it be nice if BIND cached negative information like "UUCP. -- unknown
domain".)
If this (not querying *.UUCP) is not well known, comp.mail[.something]
would be the appropriate forum to discuss it, surely?
Although perhaps using a different Subject might help. :-)
--
<David....@apana.org.au> <werple!tuple!boombox!djk> Tel: +61 3 593-1460
aka: d...@boombox.apana.org.au, d...@cs.mu.oz.au. Formerly: d...@bby.com.au.
David Keegel
>In article <e539VB...@willard.UUCP>,
>daw...@willard.UUCP (Willard Dawson) writes:
>> For what it's worth, I've come across the same problem, mailer software
>> querying DNS on host.UUCP, on several "Internet" hosts. If we accept
>> the statement (from more than one participant on these newsgroups) that
>> .UUCP is INVALID (typically shouted, as if that would make it somehow
>> more logical), the Internet hosts surely have no business in querying
>> DNS for that domain, yes?
>An Internet host cannot *know* that .UUCP in invalid unless it either
> queries the DNS and gets back an error indication
>or has special-case information somehow installed in its configuration.
What I have seen is special casing for top level UUCP and BITNET
domains. I think munnari.oz.au is a really well set up machine for
Internet mail. It has a class for fake top-level domains for which
it won't query the DNS (including UUCP and BITNET). Any postmasters
who want a smart mail node would do well to follow suit.
>A good argument can be made for avoiding special-case information, and
>Internet hosts that believe such an argument have every right to query
>the DNS for *everything*, including .UUCP sites. They will, of course,
>get back an error indication, which will tell them that the domain is
>invalid, and they will accordingly bounce the improperly addressed mail.
It depends on whether you want to be able to talk to the other networks
which are connected to The Matrix on *their* terms, rather than The
Internet's terms. Their is a good argument for saying it's up to the
postmaster individually to decide whether to support well known but not
DNSed addresses or whether it isn't worth the bother.
This is how you get the situation where some sites can send to *.uucp
but some sites cannot, and this is A Good Thing. Because that way
there is an incentive for people to get out of the .UUCP domain so we
may not need to support it (for global routing) in five years time.
>> We likely all agree on that one.
>Apparently not.
Based on what I could tell about the South African link (this may be
old news, are you still connected to PSG?) you can use all the bandwidth
you can get. If you can stop your internet hosts querying root name
servers for .UUCP mail addresses it might improve your RTT & throughput.
In other words, if you don't agree about the "theoretical" arguments
about what should be done about .UUCP (now & long term), consider the
practical argument about reducing traffic.
David Keegel
>Then, every query will return an **authoritative** "not found" result.
>A "smart" name-server will put the "not found" response into its cache,
>and will never bother the root name-server for a long time!
Last time I looked, BIND didn't support caching negative information.
If it does (or you have DNS server code which does!), do tell.
Stuart Lynne
>In <1hbmn9...@daisy.ee.und.ac.za> bar...@daisy.ee.und.ac.za (Alan P Barrett) writes:
>>In article <e539VB...@willard.UUCP>,
>>daw...@willard.UUCP (Willard Dawson) writes:
>but some sites cannot, and this is A Good Thing. Because that way
>there is an incentive for people to get out of the .UUCP domain so we
>may not need to support it (for global routing) in five years time.
But we said that five years ago! (No smiley either.)
This strategy doesn't seem to be working.
--
Stuart Lynne <s...@wimsey.com> ......................... UNIX Facsimile Software
Wimsey Information Technologies ................... moderator biz.sco.binaries
uucp login:nuucp passwd:nuucp .................... ftp.wimsey.com:~ftp/ls-lR.Z
PD Software for SCO UNIX .................... ftp.wimsey.com:~ftp/pub/wimseypd
Karl_Kl...@cs.cmu.edu
>but some sites cannot, and this is A Good Thing. Because that way
>there is an incentive for people to get out of the .UUCP domain so we
>may not need to support it (for global routing) in five years time.
But we said that five years ago! (No smiley either.)
This strategy doesn't seem to be working.
The strategy in question has in fact not been implemented in the first
place. There is far too much ad hoc support for .uucp out there, with
the result that there has been no real incentive offered. One cannot
complain of the failure of a strategy which has not been truly tried.
To provide such an incentive, the ad hoc support would have to
disappear completely, in a hurry, and without backward compatibility.
Then we would see whether such an incentive works.
Leslie Mikesell
>There is far too much ad hoc support for .uucp out there, with
>the result that there has been no real incentive offered.
Perhaps not everyone shares the opinion that there is only one email system
and that users within it have no reason to want to connect to anyone
outside of it.
Les Mikesell
l...@chinet.chi.il.us
David Keegel
>In article <8lbPrA9...@boombox.apana.org.au> David....@apana.org.au writes:
>>but some sites cannot, and this is A Good Thing. Because that way
>>there is an incentive for people to get out of the .UUCP domain so we
>>may not need to support it (for global routing) in five years time.
>But we said that five years ago! (No smiley either.)
I don't have statistics to hand about the size of the UUCP maps, or
the .UUCP "domain" or the .US domain, but here are some stats from the
last 300 postings I have (about one week's worth) to comp.bbs.waffle,
where this thread originated and which probably has (one of?) the
largest proportion of small UUCP sites around Usenet (ie: sites most
likely to be in .UUCP).
Top-level domains by posting:
1 at 89 com
9 au 50 us
20 ca 43 edu
89 com 36 uucp
3 de 34 org
43 edu 20 ca
2 fi 9 au
1 jp 6 nz
2 net 3 de
1 nl 2 fi
6 nz 2 net
34 org 2 za
1 uk 1 at
50 us 1 jp
36 uucp 1 nl
2 za 1 uk
Top-level domains by poster (all posts by the same person counted once):
1 at 41 com
4 au 21 us
11 ca 14 org
41 com 13 edu
3 de 12 uucp
13 edu 11 ca
2 fi 4 au
1 jp 3 de
1 net 3 nz
1 nl 2 fi
3 nz 2 za
14 org 1 at
1 uk 1 jp
21 us 1 net
12 uucp 1 nl
2 za 1 uk
>This strategy doesn't seem to be working.
Do you have a better one? Should there be a strategy at all?
Willard Dawson
> In article <?@willard.UUCP> daw...@willard.UUCP (Willard Dawson) writes:
> > ... various stuff ...
> Private E-mail to him produces the "bounce" message:
> ---
> Subject: Returned mail: unknown mailer error 255
> Date: Thu, 24 Dec 92 13:44:49 -0500
> From: MAILER...@mathcs.emory.edu (Mail Delivery Subsystem)
> ----- Transcript of session follows -----
> uux failed. code -1
> 554 <daw...@willard.waffle.atl.ga.us>... unknown mailer error 255
So, what prompted you to try the old .waffle.atl.ga.us domain? That
is being replaced with more congenial .alt.ga.us, and mail to the FQDN
willard.atl.ga.us should work, soon if not now.
> ----- Unsent message follows -----
> From: kla...@sol.UVic.CA (Melvin Klassen)
> Subject: Re: Mixed format addresses
>
> In article <e539VB...@willard.UUCP> you write:
> >We likely all agree on that one. But, how do we make that information
> >common knowledge?
>
> Well, define UUCP as a valid-domain,
> and put it into the top-level name-servers.
> Then, every query will return an **authoritative** "not found" result.
> A "smart" name-server will put the "not found" response into its cache,
> and will never bother the root name-server for a long time!
How will that help? You'll still NOT deliver mail to valid sites. If
you're going to suggest that .UUCP be made a valid Internet domain, then
there should be some mechanism worked out to allow DNS to route mail to
a site in the .UUCP domain. No, DNS doesn't do that now.
Seems like we could munge something that would not break existing DNS/
SMTP software, but that would rather add functionality. That those don't
do these things now is not really a point to be considered. It's the
future of email we're scheming. If we can manage to agree that the
Internet, and other networks, do indeed have a future, we might also come
to terms with the idea that some people are going to think it a neat idea
to be able to send mail from sites on one network to another in a
predictable fashion.
The Internet has, in the past, taken the easy way out on this one, only
attempting to define mail delivery to sites that are provably on the
Internet. That, IMO, is rather short-sighted. "Good enough," perhaps.
Not, I say.
Willard Dawson
> [Redirecting away from comp.bbs.waffle]
>
> In article <e539VB...@willard.UUCP>,
> daw...@willard.UUCP (Willard Dawson) writes:
> > For what it's worth, I've come across the same problem, mailer software
> > querying DNS on host.UUCP, on several "Internet" hosts. If we accept
> > the statement (from more than one participant on these newsgroups) that
> > .UUCP is INVALID (typically shouted, as if that would make it somehow
> > more logical), the Internet hosts surely have no business in querying
> > DNS for that domain, yes?
>
> An Internet host cannot *know* that .UUCP in invalid unless it either
> queries the DNS and gets back an error indication
> or has special-case information somehow installed in its configuration.
Except that .UUCP is not a valid top-level domain (is it?). I don't have
all the RFC's, so I don't know from personal knowledge, but I've been
told that.
> A good argument can be made for avoiding special-case information, and
> Internet hosts that believe such an argument have every right to query
> the DNS for *everything*, including .UUCP sites.
If .UUCP is not a part of the Internet, and if DNS only applies to intra-
domain routing, what sense does it make to query DNS for site.UUCP?
> They will, of course,
> get back an error indication, which will tell them that the domain is
> invalid, and they will accordingly bounce the improperly addressed mail.
Which is inconsistent, given that other sites on the Internet can send to
site.UUCP.
> > We likely all agree on that one.
>
> Apparently not.
Yes, I apparently spoke too soon.
Alan P Barrett
daw...@willard.UUCP (Willard Dawson) writes:
> bar...@daisy.ee.und.ac.za (Alan P Barrett) writes:
> > An Internet host cannot *know* that .UUCP in invalid unless it either
> > queries the DNS and gets back an error indication
> > or has special-case information somehow installed in its configuration.
>
> Except that .UUCP is not a valid top-level domain (is it?). I don't have
> all the RFC's, so I don't know from personal knowledge, but I've been
> told that.
I am going to try repeating myself using different words, because your
comment indicates that I did not make myself sufficiently clear.
.UUCP is not a valid top-level domain. You know that and I know that.
But an Internet host cannot know that unless either
(a) it learns that .UUCP addresses are invalid by asking the DNS,
or
(b) it has some information stored somewhere outside the DNS, telling
it that .UUCP addresses should not be looked up in the DNS.
Option (b) has several further possible refinements: (i) The special
information may tell the host to reject all .UUCP mail, or (ii) to punt
all .UUCP mail to a smart host, or (iii) to look up the .UUCP addresses
in one or more places outside the DNS and take decisions based on the
results of the lookups.
I get the impression that you think that there is some other method --
let's call it (c) -- distinct from (a) and (b), but I don't know what
it might be.
> > A good argument can be made for avoiding special-case information, and
> > Internet hosts that believe such an argument have every right to query
> > the DNS for *everything*, including .UUCP sites.
>
> If .UUCP is not a part of the Internet, and if DNS only applies to intra-
> domain routing, what sense does it make to query DNS for site.UUCP?
The DNS is the Internet's official name registry. That being the case,
I think that it is perfectly acceptable for the administrator of an
Internet host to decide that mail to destinations not registered in the
DNS will be rejected. Such an administrator may elect to use method (a)
[ask the DNS] or method (b)(i) [special knowledge that .UUCP mail must be
rejected]. Many administrators elect to use method (a), and I consider
this to quite reasonable, although it's not what I would do myself.
If option (a) is chosen then the DNS will be the only method available
to the host for checking whether a .UUCP address is valid. Asking the
DNS makes sense if that is the only method available.
I am not saying that a host SHOULD use method (a) [ask the DNS about
.UUCP sites], I am merely arguing against what I perceive to be your
position that method (b) [special knowledge outside the DNS] or method
(c) [if such a method exists] are the only acceptable methods.
I happen to be one of the folk who believes that storing special
knowledge about .UUCP outside the DNS is not such a bad thing, and I
use such special information -- methods (b)(ii) or (b)(iii) -- on all
the hosts under my control. I figure that, if the .UUCP domain is ever
officially added to the DNS, I will easily be able to remove the special
information, and switch to method (a).
Chuck Karish
> Assume for a second that every UUCP-only site out there had a
>registered MX. What sort of other routing concerns are there?
There's no easy way to bypass a forwarding host whose
modem pool isn't working. Mail to MX clients arrives
just fine in the spool on the forwarding host, and
waits until UUCP comes back.
Having multiple forwarders adds reliability on the
Internet side, but it doesn't help when the problem
is on the UUCP side.
--
Chuck Karish kar...@mindcraft.com
(415) 323-9000 x117 kar...@pangea.stanford.edu
Stuart Lynne
>inherently a multi-platform, multi-transport task, providing a common
>routing mechanism for everyone is quite difficult.
> Assume for a second that every UUCP-only site out there had a
>registered MX. What sort of other routing concerns are there?
Not too many. And you don't need MX records for all uucp sites. For example
van-bc, aka wimsey.com forwards mail to about 80 UUCP sites. About a dozen
of those have their own FQDN's with an MX record pointing to wimsey.com. But
the rest just use XXXX.wimsey.com where XXXX is their uucp node name. There
is one MX record for wimsey.com which catches all of these.
For all uucp sites to use FDQN's it is simply necessary for them to make private
arrangements with an Internet site to do forwarding. Or they can be in a sub-domain
of a domain that has arranged forwarding with an Internet site and arrange their
forwarding privately with the site that does exchange mail with the Internet site.
The big difference is that you don't really have to broadcast the details of these
arrangements to the world. Your FDQN simply has to be able to be forwarded on the
Internet to the place that does have the details.
For my local UUCP connections and van-bc users the incidence of .UUCP use or bang
path routing seems to be in decline (at least for other than local sites). Less than
2% of messages appear to be routed outside of our local mail exchange to a uucp
site.
David Keegel
>If
>you're going to suggest that .UUCP be made a valid Internet domain, then
>there should be some mechanism worked out to allow DNS to route mail to
>a site in the .UUCP domain. No, DNS doesn't do that now.
[[ Nit picking (sorry): "a valid DNS domain" would be a better way of
phrasing it since none (or almost none) of the nodes in .UUCP would
be on The Internet. The DNS doesn't route mail -- DNS is a database
(albeit widely distributed). Of course since the DNS contains the
information needed to route mail around The Internet, your meaning
is clear. ]]
>Seems like we could munge something that would not break existing DNS/
>SMTP software, but that would rather add functionality. That those don't
>do these things now is not really a point to be considered. It's the
>future of email we're scheming. If we can manage to agree that the
>Internet, and other networks, do indeed have a future, we might also come
>to terms with the idea that some people are going to think it a neat idea
>to be able to send mail from sites on one network to another in a
>predictable fashion.
Hooks are provided by/in the DNS to solve this problem in a number
of ways -- the problem is largely a human one.
For instance if one or more sites were prepared to accept (& deliver!)
all mail from the Internet to UUCP sites which the Internet sending node
did not know how to route itself, this could be implemented with a set
of *.UUCP MXes (as I've mentioned before).
Or if some programmer type was prepared to write a script/program which
takes the UUCP maps as input and writes out a text file with MXes the
DNS could read as the authoritative data for .UUCP., and some Internet
site was prepared to run this on a regular basis to advertise MXes for
individual .UUCP sites in the DNS, this should also solve the "problem".
Note that since in this second scenario the "hard work" is a text->
text translation and therefore can be some by someone without access
to (or intimate knowledge of) either The Internet (even an internet)
or the UUCP network.
Of course, this assumes that the adminstrators of the root domain (the
NIC) are prepared to delegate the .UUCP domain for this purpose. Again
largely a human (political?) problem rather than a technical one.
>The Internet has, in the past, taken the easy way out on this one, only
>attempting to define mail delivery to sites that are provably on the
>Internet. That, IMO, is rather short-sighted. "Good enough," perhaps.
>Not, I say.
There is absolutely no need to be on The Internet, but (if you want to
receive mail from it or through it) there is a need to be `advertised'
on The Internet. This means having an MX record in the DNS.
I don't think The Internet has taken "the easy way out". They designed
a system (the DNS) which would not only serve their needs (as IP-connected
hosts) but also allow easy specification of a gateway (or a few equivalent
gateways) for foreign networks.
For instance, from memory, all mail to Papua New Guinea (.PG) is delivered
to an Internet host (munnari.oz.au) in Melbourne, Australia and then sent
using a network (protocol) called ACSnet from there to PNG.
Perhaps it was arrogant of The Internet to have designed a system which
could encompass all the electronic mail networks of the world which *The
Internet* maintains, and which *forces* a us...@dom.ain syntax. But the
reality is that The Internet *is* the backbone for world e-mail (as far
as I'm concerned anyway), and some network has to have a mechanism for
delivering mail to all other networks.
The difficulty with *.UUCP (and perhaps *.BITNET) is that there are lots
of gateways between it and the Internet and no one has set up a reasonable
way for Internet hosts to choose the appropriate gateway (unless they run
pathalias, but there are problems with that too because the Internet is
not store-and-forward with a small set of neighbors like UUCP or ACSnet).
Richard McCombs KB5SNF
s...@wimsey.bc.ca (Stuart Lynne) writes:
> In article <2fg1H...@atlantis.psu.edu> ba...@pop.psu.edu (David Barr) writes
> :
>>In article <H9TkwB...@willard.UUCP> daw...@willard.UUCP (Willard Dawson)
> writes:
>
>>inherently a multi-platform, multi-transport task, providing a common
>>routing mechanism for everyone is quite difficult.
>
>> Assume for a second that every UUCP-only site out there had a
>>registered MX. What sort of other routing concerns are there?
>
> Not too many. And you don't need MX records for all uucp sites. For example
> van-bc, aka wimsey.com forwards mail to about 80 UUCP sites. About a dozen
> of those have their own FQDN's with an MX record pointing to wimsey.com. But
> the rest just use XXXX.wimsey.com where XXXX is their uucp node name. There
> is one MX record for wimsey.com which catches all of these.
One problem though if a uucp node is going to be know at all by a short
node name then they need to register in the maps even if they are a
leaf, if you are going to list them in your map entry, because it screws
up the maps. Notice the bang path listed in my signature, but the system
I connect to is in Fort Worth, Texas not Vancover, British Columbia.
--
Internet: ri...@ricksys.lonestar.org, bo...@cleveland.freenet.edu
UUCP: ...!rwsys!ricksys!rick, {backbones}!ricksys.lonestar.org!rick
BITNET: bo836%cleveland.freenet.edu@cunyvm Fidonet: Richard McCombs @ 1:385/6
David Keegel
>.UUCP is not a valid top-level domain.
... as far as The Internet is concerned.
>The DNS is the Internet's official name registry.
which also has information about non-Internet mail addresses, where
the owners of those addresses have wanted hosts on The Internet to be
able to send mail to them. If I didn't know anything about it, I
would assume that the "Internet's official name registry" is some
thing which only contains information about Internet hosts.
The Internet is a network which uses DNS to decide what mail is sent
where. The UUCP network (whatever it's called) uses the UUCP maps.
Within their networks, these are both valid.
The reasons UUCP only sites should care what is in the DNS are:
* The Internet is better inter-connected (more of a "backbone").
* The DNS is designed to handle foreign networks/domains/hosts
where the UUCP maps are not (they can be added, ad hoc, but
they don't "fit" in a nice way).
As a matter of interest, some Internet only sites do care what's
in the UUCP maps. For instance, in Australia, due to the earlier
success of ACSnet, the largest UUCP network in the country (as far
as I can tell) is APANA with about 50 nodes. Yet the UUCP maps
for Australia (which include about 20% of APANA) are about 60k.
My guess is about 20% of those nodes would talk UUCP externally.
Bill Fenner
|bar...@daisy.ee.und.ac.za (Alan P Barrett) writes:
|>.UUCP is not a valid top-level domain.
|
|... as far as The Internet is concerned.
Which is all that matters, since the DNS is an Internet construct. If you
want to call something a "domain name", then it had better be in the DNS, or
you're wrong.
That's why I (try to, I often forget to) refer to it as "the .UUCP
pseudo-domain".
Bill
Don Lewis
>I guessed it was common knowledge among "larger" (whatever that means)
>internet sites. Or at least the well-behaved ones. If for no other
>reason than to reduce traffic to the root nameservers (gee, wouldn't
>it be nice if BIND cached negative information like "UUCP. -- unknown
>domain".)
Even if BIND had negative caching, it wouldn't help much in this case.
The problem is that there wouldn't be any queries for just "UUCP". Your
local name server would forward queries for foo.UUCP and bar.UUCP to
the root servers, which would return a no such domain response. Your
local server would cache this information for foo.UUCP and bar.UUCP,
but when it received a query for baz.UUCP, it would still forward it
to the root servers.
--
Don "Truck" Lewis Phone: +1 916 478-8284 Silicon Systems
Internet: gd...@ssi1.com FAX: +1 916 478-8290 138 New Mohawk Road
UUCP: {uunet,tektronix!gvgpsa.gvg.tek.com}!ssigv!gdonl Nevada City, CA 95959