kre@cs.mu.oz.au (Robert Elz) (04/09/90)
In article <1990Apr6.070313.29203@mlb.semi.harris.com>, del@thrush.mlb.semi.harris.com (Don Lewis) writes: > It would help a lot if there was a nifty form to fill out to register > your in-addr.arpa domain. But there is ... its IN-ADDR-TEMPLATE.TXT available form the NETINFO: directory of NIC.DDN.MIL (A copy is also in netinfo/in-addr.template on munnari.oz.au) kre
philipp@GIPSI.GIPSI.FR (Philippe Prindeville) (04/10/90)
What about providing a set of tools (scripts) for autoconfiguring this stuff? Most (if not all) of the IN-ADDR.ARPA files can be generated by an intelligent script, since the data is already in the regular domain file (ie. names to addresses). It could probably generate the network records (a la 1101). -Philip
emv@math.lsa.umich.edu (Edward Vielmetti) (04/13/90)
In article <83269@uunet.UU.NET> revell@uunet.UU.NET (James R Revell Jr) writes: In article <1990Apr5.171053.14081@terminator.cc.umich.edu>, bryan@terminator.cc.umich.edu (Bryan Beecher) writes: >How does one convince an organization that their part of in-addr.arpa >is set-up incorrectly and that they need to do something about it? How about adopting a policy similar to what we taken at uunet. We refuse to allow FTP access by any site that doesn't have it's reverse servers configured. We find that this usually has enough impact to make the site set things up right. Ah yes, the old "denial of service" attack. Is the ftpd that uunet is running available somewhere? The FTP refusal doesn't seem to be in the one that's in networking/ftpd.*. If you want to bounce some more connections, refuse them from people who don't have the RFC 1101 "reverse pointer for the .0 address" scheme to identify their network, that'll wipe out all but a few die-hards in Ohio and at Apple more or less. --Ed Edward Vielmetti, U of Michigan math dept. emv@math.lsa.umich.edu