home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / protocol / tcpip / domains / 912 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  2.2 KB
  1. Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!usenet.ins.cwru.edu!agate!spool.mu.edu!olivea!charnel!psgrain!ee.und.ac.za!tplinfm
  2. From: barrett@lucy.ee.und.ac.za (Alan Barrett)
  3. Newsgroups: comp.protocols.tcp-ip.domains
  4. Subject: Re: Bind & Dialup IP
  5. Message-ID: <1k5ftfINNm50@lucy.ee.und.ac.za>
  6. Date: 27 Jan 93 08:08:15 GMT
  7. References: <1jspatINNbqa@hp4at.eunet.co.at>
  8. Distribution: inet
  9. Organization: Elec. Eng., Univ. Natal, Durban, S. Africa
  10. Lines: 36
  11. NNTP-Posting-Host: lucy.ee.und.ac.za
  12.  
  13. In article <1jspatINNbqa@hp4at.eunet.co.at>,
  14. mah@ic.co.at writes:
  15. > I'm looking for people's experience/opinions/setup recommendations on
  16. > DNS operation at a dialup-on-demand IP site.
  17.  
  18. An interesting problem.  I have some ideas, but no answers.
  19.  
  20. > I'd like to have our dialupIP subscribers use DNS, so they can use
  21. > FQDN's instead of adresses for e.g. ftp. This works fine but has the
  22. > disadvantage of causing a dialup by nameserver traffic also for other
  23. > non obvious reasons. E.g. the reverse lookups generated by many
  24. > applications cause a dialup just for this query.
  25.  
  26. Most of the isolated systems could be configured to use a single host
  27. as a forwarder, and this forwarder system could be authoritative for
  28. all the zones that refer to hosts in the isolated area.  That should
  29. cope with the forward and the in-addr.arpa lookups generated by one of
  30. the isolated hosts asking about another of the isolated hosts.
  31.  
  32. > Another aspect: If the subscriber site has an authoritative NS for
  33. > their zone and we run secondaries, we could do a zone transfer only
  34. > if the site is connected but not when our nameserver thinks he needs
  35. > a xfer. We dont want to dial the subscriber in general, and not for a
  36. > zone xfer in particular.
  37.  
  38. You could use a wrapper around named-xfer to handle this.  Rename
  39. named-xfer to named-xfer.real, and write a wrapper named-xfer that does
  40. whatever magic is needed to check whether the desired primary server is
  41. connected.  If it is not connected, then check whether the zone is
  42. about to expire, and if it is still reasonably fresh then exit with the
  43. appropriate error status.  If the server is connected, or if the zone
  44. is getting stale, then exec named-xfer.real
  45.  
  46. --apb
  47. Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
  48. RFC822: barrett@ee.und.ac.za
  49.