1 / 8

Requirements for running a local WHOIS service

Requirements for running a local WHOIS service. DB SIG Apricot 15, Taipei, Taiwan 26 February 2003. Problem. Current requirements for mirroring of WHOIS data in APNIC region not well defined Existing agreements pre-date APNIC conversion to RPSL

symona
Download Presentation

Requirements for running a local WHOIS service

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements for running a local WHOIS service DB SIG Apricot 15, Taipei, Taiwan 26 February 2003

  2. Problem • Current requirements for mirroring of WHOIS data in APNIC region not well defined • Existing agreements pre-date APNIC conversion to RPSL • Should be formalized, and applicable to all APNIC members with resource management needs

  3. Goals • Clarify operational and policy issues to permit more widespread use of mirrored WHOIS services • Enhance member services • Improve information held on behalf of wider Internet community

  4. Technical requirements • WHOIS services must be RPSL • The new APNIC WHOIS enforces strict RPSL compliance checks • Must support NRTM data exchange method • Updates will propagate in near real time • If used for IRR, must support RPSS/related authentication model • Required for cross-registry authentication

  5. Policy Requirements • Should meet community standards for data accuracy, detail • Existing APNIC customer assignment/allocation requirements • Records must be in English • Should not refer to data outside of allocation/assignment held by member • Will break wider trust model

  6. Other RIRs • ARIN • Runs Rwhois, a referral model • Not RPSL based • LACNIC, RIPE • No equivalent activity at this time • Wider community • IRR: analogous services, loosely federated • Doesn’t handle assignment & allocation data

  7. Benefits • Faster turnaround for data update • NRTM propagates <1min • Local procedures can be used • Based on existing APNIC templates • Shared DNS reverse zone management • Use domain: objects to update zone • Global IRR improvements • Routing objects can refer to other DB

  8. Issues • Scaling: seeking information from RIPE-NCC on software and hardware issues • APNIC will re-resource services to meet load • Existing agreements with NIR • All existing arrangements will persist • Would like to discuss options with NIR community • ERX data will be included after transfer

More Related