keld@diku.dk (Keld J|rn Simonsen) (05/27/90)
Well, we run a DNS for 142.129.in-addr.arpa here in Denmark, which is registered in the NIC DNS. I know of another B-class reverse domain serving Denmark also being registered with NIC, and I am quite sure there are B-class in-addr.arpa domains in the rest of Scandinavia registered officially with NIC. So it is not true that you cannot get non-USA reverse domains registered with NIC. Several anon ftp servers, including uunet.uu.net will not let you in without a valid in-addr.arpa PTR RR. Keld Simonsen, DKnet keld@dkuug.dk
jh@tut.fi (Juha Heinanen) (05/28/90)
In article <1990May26.232814.11095@diku.dk> keld@diku.dk (Keld J|rn Simonsen) writes:
So it is not true that you cannot get non-USA reverse
domains registered with NIC.
Keld,
You missed the point which was that so far NIC has not accepted
non-connected nets under the in-addr.arpa domain.
--
-- Juha Heinanen, Tampere Univ. of Technology, Finland
jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)emv@math.lsa.umich.edu (Edward Vielmetti) (05/28/90)
So it is not true that you cannot get non-USA reverse
domains registered with NIC.
You missed the point which was that so far NIC has not accepted
non-connected nets under the in-addr.arpa domain.
worse yet -- when a non-connected net gets connected status, the NIC
doesn't insist on them getting an in-addr.arpa domain as a condition
of their connectedness. they ask but don't enforce. this explains
some current brokenness in Italy.
--Ed
Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
comp.archives moderatorphilipp@GIPSI.GIPSI.FR (Philippe Prindeville) (05/29/90)
You can get them registered, but only if they are officially connected. It is the stuff after the "but..." that is the trouble. -Philip
huntting@sel.bldrdoc.gov (Brad Huntting) (05/29/90)
If the NIC would franchise authority for network numbers, It could
allow them to be distributed on a *local* connectivity basis instead
of global.
Thus (for example) an Albanian network authority would be given
the 234.in-addr.arpa domain (and maybe some others), keep the
SOA for it (on a well connected node), and give out IP numbers
234.xxx.yyy.0 to local interests.
Delegating other nameservers for the in-addr domain based on region
could improve BIND performance, and reduce network traffic in general.
For example, all (new) class C nets in Lebanon Kansas will start with
128, and the nameservers for 128.in-addr.arpa are also in Lebanon.
This assumes most of the hosts in Lebanon are near each other (in the
network sense).
This would distribute some of the load of the in-addr.arpa domain
away from the root, and cut down on unnecessary long haul queries.
Root nameservers would be queried less often for near by reverse
mapping.
brad
huntting@boulder.colorado.edu
huntting@sel.bldrdoc.govsmart@ditmela.oz (Robert Smart) (05/30/90)
In article <21626@boulder.Colorado.EDU> huntting@sel.bldrdoc.gov (Brad Huntting) writes: > > This would distribute some of the load of the in-addr.arpa domain > away from the root, and cut down on unnecessary long haul queries. > It may be a bit late for Brad's scheme. I have an alternative. Context: We are all familiar with schemes which tunnel IP packets through other networks: DECNET, LU 6.2, and many more. Recently someone (Phil Karn?) proposed a scheme for tunnelling IP packets over an IP network. The objective in that case was to reconnect a Class A network which had multiple links to the Internet and had become internally partitioned. I have an alternative use for such a scheme. There are many situations where we would like to contact the nearest host with property X. X might be "holds the GNU software" or "is an e-mail gateway to BITNET" or "is a nameserver for IN-ADDR.ARPA". Now one thing the Internet already knows how to do is find the shortest route from us to a particular network. So I propose that we create logical networks which are actually spread across the Internet and are internally connected by IP over IP tunneling. Let's suppose that all BITNET gateways are on network 193.1.1. There are various ways we could find the nearest host in this network. We could send an echo request to 193.1.1.255 but that might be unfriendly. We could try to contact 193.1.1.0 assuming that that means any host in 193.1.1. We could set it up so that clients contact 193.1.1.1 and the first host that that arrives at will pretend to be 193.1.1.1 -- but having multiple hosts pretending to be the same host seems unwise. Use of host number 0 to mean "any host in this network" seems like the best idea to me, but I could well be ignorant of problems that this would cause. You need a mechanism for the caller to convert the 193.1.1.0 destination address to the address of the actual destination once a response has been received: it mustn't keep using 193.1.1.0 or subsequent packets might go to a different host. Incidentally it would be nice if IP in IP tunneling could be done at the IP level, and not have to go up to the UDP level. This can be achieved if we add a new IP type field (alongside TCP and UDP) for IP-IN-IP. Actually for some of the proposed applications there would be no need for these logical networks to be internally connected, but breaking IP semantics to that extent seems dubious. Bob Smart <smart@mel.dit.csiro.au>