This commit was manufactured by cvs2git to create tag 'v9_2_3'.

doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt

@@ -1,393 +0,0 @@
-
-
-
-INTERNET-DRAFT                                      Andreas Gustafsson
-draft-ietf-dnsext-axfr-clarify-05.txt                     Nominum Inc.
-                                                         November 2002
-
-
-               DNS Zone Transfer Protocol Clarifications
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-Abstract
-
-   In the Domain Name System, zone data is replicated among
-   authoritative DNS servers by means of the "zone transfer" protocol,
-   also known as the "AXFR" protocol.  This memo clarifies, updates, and
-   adds missing detail to the original AXFR protocol specification in
-   RFC1034.
-
-1. Introduction
-
-   The original definition of the DNS zone transfer protocol consists of
-   a single paragraph in [RFC1034] section 4.3.5 and some additional
-   notes in [RFC1035] section 6.3.  It is not sufficiently detailed to
-   serve as the sole basis for constructing interoperable
-   implementations.  This document is an attempt to provide a more
-   complete definition of the protocol.  Where the text in RFC1034
-   conflicts with existing practice, the existing practice has been
-   codified in the interest of interoperability.
-
-
-
-
-Expires May 2003                                                [Page 1]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-2. The zone transfer request
-
-   To initiate a zone transfer, the slave server sends a zone transfer
-   request to the master server over a reliable transport such as TCP.
-   The form of this request is specified in sufficient detail in RFC1034
-   and needs no further clarification.
-
-   Implementers are advised that one server implementation in widespread
-   use sends AXFR requests where the TCP message envelope size exceeds
-   the DNS request message size by two octets.
-
-3. The zone transfer response
-
-   If the master server is unable or unwilling to provide a zone
-   transfer, it MUST respond with a single DNS message containing an
-   appropriate RCODE other than NOERROR.  If the master is not
-   authoritative for the requested zone, the RCODE SHOULD be 9
-   (NOTAUTH).
-
-   Slave servers should note that some master server implementations
-   will simply close the connection when denying the slave access to the
-   zone.  Therefore, slaves MAY interpret an immediate graceful close of
-   the TCP connection as equivalent to a "Refused" response (RCODE 5).
-
-   If a zone transfer can be provided, the master server sends one or
-   more DNS messages containing the zone data as described below.
-
-3.1. Multiple answers per message
-
-   The zone data in a zone transfer response is a sequence of answer
-   RRs.  These RRs are transmitted in the answer section(s) of one or
-   more DNS response messages.
-
-   The AXFR protocol definition in RFC1034 does not make a clear
-   distinction between response messages and answer RRs.  Historically,
-   DNS servers always transmitted a single answer RR per message.  This
-   encoding is wasteful due to the overhead of repeatedly sending DNS
-   message headers and the loss of domain name compression
-   opportunities.  To improve efficiency, some newer servers support a
-   mode where multiple RRs are transmitted in a single DNS response
-   message.
-
-   A master MAY transmit multiple answer RRs per response message up to
-   the largest number that will fit within the 65535 byte limit on TCP
-
-
-
-Expires May 2003                                                [Page 2]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   DNS message size.  In the case of a small zone, this can cause the
-   entire transfer to be transmitted in a single response message.
-
-   Slaves MUST accept messages containing any number of answer RRs.  For
-   compatibility with old slaves, masters that support sending multiple
-   answers per message SHOULD be configurable to revert to the
-   historical mode of one answer per message, and the configuration
-   SHOULD be settable on a per-slave basis.
-
-3.2. DNS message header contents
-
-   RFC1034 does not specify the contents of the DNS message header of
-   the zone transfer response messages.  The header of each message MUST
-   be as follows:
-
-       ID      Copy from request
-       QR      1
-       OPCODE  QUERY
-       AA      1, but MAY be 0 when RCODE is not NOERROR
-       TC      0
-       RD      Copy from request, or 0
-       RA      Set according to availability of recursion, or 0
-       Z       0
-       AD      0
-       CD      0
-       RCODE   NOERROR on success, error code otherwise
-
-   The slave MUST check the RCODE in each message and abort the transfer
-   if it is not NOERROR.  It SHOULD check the ID of the first message
-   received and abort the transfer if it does not match the ID of the
-   request.  The ID SHOULD be ignored in subsequent messages, and fields
-   other than RCODE and ID SHOULD be ignored in all messages, to ensure
-   interoperability with certain older implementations which transmit
-   incorrect or arbitrary values in these fields.
-
-3.3. Additional section and SIG processing
-
-   Zone transfer responses are not subject to any kind of additional
-   section processing or automatic inclusion of SIG records.  SIG RRs in
-   the zone data are treated exactly the same as any other RR type.
-
-3.4. The question section
-
-   RFC1034 does not specify whether zone transfer response messages have
-   a question section or not.  The initial message of a zone transfer
-   response SHOULD have a question section identical to that in the
-   request.  Subsequent messages SHOULD NOT have a question section,
-   though the final message MAY.  The receiving slave server MUST accept
-
-
-
-Expires May 2003                                                [Page 3]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   any combination of messages with and without a question section.
-
-3.5. The authority section
-
-   The master server MUST transmit messages with an empty authority
-   section.  Slaves MUST ignore any authority section contents they may
-   receive from masters that do not comply with this requirement.
-
-3.6. The additional section
-
-   The additional section MAY contain additional RRs such as transaction
-   signatures.  The slave MUST ignore any unexpected RRs in the
-   additional section.  It MUST NOT treat additional section RRs as zone
-   data.
-
-4. Zone data
-
-   The purpose of the zone transfer mechanism is to exactly replicate at
-   each slave the set of RRs associated with a particular zone at its
-   primary master.  An RR is associated with a zone by being loaded from
-   the master file of that zone at the primary master server, or by some
-   other, equivalent method for configuring zone data.
-
-   This replication shall be complete and unaltered, regardless of how
-   many and which intermediate masters/slaves are involved, and
-   regardless of what other zones those intermediate masters/slaves do
-   or do not serve, and regardless of what data may be cached in
-   resolvers associated with the intermediate masters/slaves.
-
-   Therefore, in a zone transfer the master MUST send exactly those
-   records that are associated with the zone, whether or not their owner
-   names would be considered to be "in" the zone for purposes of
-   resolution, and whether or not they would be eligible for use as glue
-   in responses.  The transfer MUST NOT include any RRs that are not
-   associated with the zone, such as RRs associated with zones other
-   than the one being transferred or present in the cache of the local
-   resolver, even if their owner names are in the zone being transferred
-   or are pointed to by NS records in the zone being transferred.
-
-   The slave MUST associate the RRs received in a zone transfer with the
-   specific zone being transferred, and maintain that association for
-   purposes of acting as a master in outgoing transfers.
-
-5. Transmission order
-
-   RFC1034 states that "The first and last messages must contain the
-   data for the top authoritative node of the zone".  This is not
-   consistent with existing practice.  All known master implementations
-
-
-
-Expires May 2003                                                [Page 4]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   send, and slave implementations expect to receive, the zone's SOA RR
-   as the first and last record of the transfer.
-
-   Therefore, the quoted sentence is hereby superseded by the sentence
-   "The first and last RR transmitted must be the SOA record of the
-   zone".
-
-   The initial and final SOA record MUST be identical, with the possible
-   exception of case and compression.  In particular, they MUST have the
-   same serial number.  The slave MUST consider the transfer to be
-   complete when, and only when, it has received the message containing
-   the second SOA record.
-
-   The transmission order of all other RRs in the zone is undefined.
-   Each of them SHOULD be transmitted only once, and slaves MUST ignore
-   any duplicate RRs received.
-
-6. Security Considerations
-
-   The zone transfer protocol as defined in [RFC1034] and clarified by
-   this memo does not have any built-in mechanisms for the slave to
-   securely verify the identity of the master server and the integrity
-   of the transferred zone data.  The use of a cryptographic mechanism
-   for ensuring authenticity and integrity, such as TSIG [RFC2845],
-   IPSEC, or TLS, is RECOMMENDED.
-
-   The zone transfer protocol allows read-only public access to the
-   complete zone data.  Since data in the DNS is public by definition,
-   this is generally acceptable.  Sites that wish to avoid disclosing
-   their full zone data MAY restrict zone transfer access to authorized
-   slaves.
-
-   These clarifications are not believed to themselves introduce any new
-   security problems, nor to solve any existing ones.
-
-Acknowledgements
-
-   Many people have contributed input and commentary to earlier versions
-   of this document, including but not limited to Bob Halley, Dan
-   Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz,
-   Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
-   Trenholme, and Brian Wellington.
-
-References
-
-   [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
-   November 1987.
-
-
-
-
-Expires May 2003                                                [Page 5]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   [RFC1035] - Domain Names - Implementation and Specifications, P.
-   Mockapetris, November 1987.
-
-   [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
-   S. Bradner, BCP 14, March 1997.
-
-   [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG).  P.
-   Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
-
-Author's Address
-
-   Andreas Gustafsson
-   Nominum Inc.
-   2385 Bay Rd
-   Redwood City, CA 94063
-   USA
-
-   Phone: +1 650 381 6004
-
-   Email: gson@nominum.com
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000 - 2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implmentation may be prepared, copied, published and
-   distributed, in whole or in part, without restriction of any kind,
-   provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-
-
-
-Expires May 2003                                                [Page 6]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires May 2003                                                [Page 7]
-
-

doc/rfc/rfc3197.txt

@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Austein
-Request for Comments: 3197                                 InterNetShare
-Category: Informational                                    November 2001
-
-
-             Applicability Statement for DNS MIB Extensions
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   This document explains why, after more than six years as proposed
-   standards, the DNS Server and Resolver MIB extensions were never
-   deployed, and recommends retiring these MIB extensions by moving them
-   to Historical status.
-
-1. History
-
-   The road to the DNS MIB extensions was paved with good intentions.
-
-   In retrospect, it's obvious that the working group never had much
-   agreement on what belonged in the MIB extensions, just that we should
-   have some.  This happened during the height of the craze for MIB
-   extensions in virtually every protocol that the IETF was working on
-   at the time, so the question of why we were doing this in the first
-   place never got a lot of scrutiny.  Very late in the development
-   cycle we discovered that much of the support for writing the MIB
-   extensions in the first place had come from people who wanted to use
-   SNMP SET operations to update DNS zones on the fly.  Examination of
-   the security model involved, however, led us to conclude that this
-   was not a good way to do dynamic update and that a separate DNS
-   Dynamic Update protocol would be necessary.
-
-   The MIB extensions started out being fairly specific to one
-   particular DNS implementation (BIND-4.8.3); as work progressed, the
-   BIND-specific portions were rewritten to be as implementation-neutral
-   as we knew how to make them, but somehow every revision of the MIB
-   extensions managed to create new counters that just happened to
-   closely match statistics kept by some version of BIND.  As a result,
-   the MIB extensions ended up being much too big, which raised a number
-
-
-
-Austein                      Informational                      [Page 1]
-
-RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
-
-
-   of concerns with the network management directorate, but the WG
-   resisted every attempt to remove any of these variables.  In the end,
-   large portions of the MIB extensions were moved into optional groups
-   in an attempt to get the required subset down to a manageable size.
-
-   The DNS Server and Resolver MIB extensions were one of the first
-   attempts to write MIB extensions for a protocol usually considered to
-   be at the application layer.  Fairly early on it became clear that,
-   while it was certainly possible to write MIB extensions for DNS, the
-   SMI was not really designed with this sort of thing in mind.  A case
-   in point was the attempt to provide direct indexing into the caches
-   in the resolver MIB extensions: while arguably the only sane way to
-   do this for a large cache, this required much more complex indexing
-   clauses than is usual, and ended up running into known length limits
-   for object identifiers in some SNMP implementations.
-
-   Furthermore, the lack of either real proxy MIB support in SNMP
-   managers or a standard subagent protocol meant that there was no
-   reasonable way to implement the MIB extensions in the dominant
-   implementation (BIND).  When the AgentX subagent protocol was
-   developed a few years later, we initially hoped that this would
-   finally clear the way for an implementation of the DNS MIB
-   extensions, but by the time AgentX was a viable protocol it had
-   become clear that nobody really wanted to implement these MIB
-   extensions.
-
-   Finally, the MIB extensions took much too long to produce.  In
-   retrospect, this should have been a clear warning sign, particularly
-   when the WG had clearly become so tired of the project that the
-   authors found it impossible to elicit any comments whatsoever on the
-   documents.
-
-2. Lessons
-
-   Observations based on the preceding list of mistakes, for the benefit
-   of anyone else who ever attempts to write DNS MIB extensions again:
-
-   -  Define a clear set of goals before writing any MIB extensions.
-      Know who the constituency is and make sure that what you write
-      solves their problem.
-
-   -  Keep the MIB extensions short, and don't add variables just
-      because somebody in the WG thinks they'd be a cool thing to
-      measure.
-
-   -  If some portion of the task seems to be very hard to do within the
-      SMI, that's a strong hint that SNMP is not the right tool for
-      whatever it is that you're trying to do.
-
-
-
-Austein                      Informational                      [Page 2]
-
-RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
-
-
-   -  If the entire project is taking too long, perhaps that's a hint
-      too.
-
-3. Recommendation
-
-   In view of the community's apparent total lack of interest in
-   deploying these MIB extensions, we recommend that RFCs 1611 and 1612
-   be reclassified as Historical documents.
-
-4. Security Considerations
-
-   Re-classifying an existing MIB document from Proposed Standard to
-   Historic should not have any negative impact on security for the
-   Internet.
-
-5. IANA Considerations
-
-   Getting rid of the DNS MIB extensions should not impose any new work
-   on IANA.
-
-6. Acknowledgments
-
-   The author would like to thank all the people who were involved in
-   this project over the years for their optimism and patience,
-   misguided though it may have been.
-
-7. References
-
-   [DNS-SERVER-MIB]     Austein, R. and J. Saperia, "DNS Server MIB
-                        Extensions", RFC 1611, May 1994.
-
-   [DNS-RESOLVER-MIB]   Austein, R. and J. Saperia, "DNS Resolver MIB
-                        Extensions", RFC 1612, May 1994.
-
-   [DNS-DYNAMIC-UPDATE] Vixie, P., Thomson, S., Rekhter, Y. and J.
-                        Bound, "Dynamic Updates in the Domain Name
-                        System (DNS UPDATE)", RFC 2136, April 1997.
-
-   [AGENTX]             Daniele, M., Wijnen, B., Ellison, M., and D.
-                        Francisco, "Agent Extensibility (AgentX)
-                        Protocol Version 1", RFC 2741, January 2000.
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 3]
-
-RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
-
-
-8. Author's Address
-
-   Rob Austein
-   InterNetShare, Incorporated
-   325M Sharon Park Drive, Suite 308
-   Menlo Park, CA  94025
-   USA
-
-   EMail: sra@hactrn.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 4]
-
-RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
-
-
-9. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 5]
-

doc/rfc/rfc3425.txt

@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Lawrence
-Request for Comments: 3425                                       Nominum
-Updates: 1035                                              November 2002
-Category: Standards Track
-
-
-                           Obsoleting IQUERY
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   The IQUERY method of performing inverse DNS lookups, specified in RFC
-   1035, has not been generally implemented and has usually been
-   operationally disabled where it has been implemented.  Both reflect a
-   general view in the community that the concept was unwise and that
-   the widely-used alternate approach of using pointer (PTR) queries and
-   reverse-mapping records is preferable.  Consequently, this document
-   deprecates the IQUERY operation, declaring it entirely obsolete.
-   This document updates RFC 1035.
-
-1 - Introduction
-
-   As specified in RFC 1035 (section 6.4), the IQUERY operation for DNS
-   queries is used to look up the name(s) which are associated with the
-   given value.  The value being sought is provided in the query's
-   answer section and the response fills in the question section with
-   one or more 3-tuples of type, name and class.
-
-   As noted in [RFC1035], section 6.4.3, inverse query processing can
-   put quite an arduous burden on a server.  A server would need to
-   perform either an exhaustive search of its database or maintain a
-   separate database that is keyed by the values of the primary
-   database.  Both of these approaches could strain system resource use,
-   particularly for servers that are authoritative for millions of
-   names.
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 1]
-
-RFC 3425                   Obsoleting IQUERY               November 2002
-
-
-   Response packets from these megaservers could be exceptionally large,
-   and easily run into megabyte sizes.  For example, using IQUERY to
-   find every domain that is delegated to one of the nameservers of a
-   large ISP could return tens of thousands of 3-tuples in the question
-   section.  This could easily be used to launch denial of service
-   attacks.
-
-   Operators of servers that do support IQUERY in some form (such as
-   very old BIND 4 servers) generally opt to disable it.  This is
-   largely due to bugs in insufficiently-exercised code, or concerns
-   about exposure of large blocks of names in their zones by probes such
-   as inverse MX queries.
-
-   IQUERY is also somewhat inherently crippled by being unable to tell a
-   requester where it needs to go to get the information that was
-   requested.  The answer is very specific to the single server that was
-   queried.  This is sometimes a handy diagnostic tool, but apparently
-   not enough so that server operators like to enable it, or request
-   implementation where it is lacking.
-
-   No known clients use IQUERY to provide any meaningful service.  The
-   only common reverse mapping support on the Internet, mapping address
-   records to names, is provided through the use of pointer (PTR)
-   records in the in-addr.arpa tree and has served the community well
-   for many years.
-
-   Based on all of these factors, this document recommends that the
-   IQUERY operation for DNS servers be officially obsoleted.
-
-2 - Requirements
-
-   The key word "SHOULD" in this document is to be interpreted as
-   described in BCP 14, RFC 2119, namely that there may exist valid
-   reasons to ignore a particular item, but the full implications must
-   be understood and carefully weighed before choosing a different
-   course.
-
-3 - Effect on RFC 1035
-
-   The effect of this document is to change the definition of opcode 1
-   from that originally defined in section 4.1.1 of RFC 1035, and to
-   entirely supersede section 6.4 (including subsections) of RFC 1035.
-
-   The definition of opcode 1 is hereby changed to:
-
-      "1               an inverse query (IQUERY) (obsolete)"
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 2]
-
-RFC 3425                   Obsoleting IQUERY               November 2002
-
-
-   The text in section 6.4 of RFC 1035 is now considered obsolete.  The
-   following is an applicability statement regarding the IQUERY opcode:
-
-   Inverse queries using the IQUERY opcode were originally described as
-   the ability to look up the names that are associated with a
-   particular Resource Record (RR).  Their implementation was optional
-   and never achieved widespread use.  Therefore IQUERY is now obsolete,
-   and name servers SHOULD return a "Not Implemented" error when an
-   IQUERY request is received.
-
-4 - Security Considerations
-
-   Since this document obsoletes an operation that was once available,
-   it is conceivable that someone was using it as the basis of a
-   security policy.  However, since the most logical course for such a
-   policy to take in the face of a lack of positive response from a
-   server is to deny authentication/authorization, it is highly unlikely
-   that removing support for IQUERY will open any new security holes.
-
-   Note that if IQUERY is not obsoleted, securing the responses with DNS
-   Security (DNSSEC) is extremely difficult without out-on-the-fly
-   digital signing.
-
-5 - IANA Considerations
-
-   The IQUERY opcode of 1 should be permanently retired, not to be
-   assigned to any future opcode.
-
-6 - Acknowledgments
-
-   Olafur Gudmundsson instigated this action.  Matt Crawford, John
-   Klensin, Erik Nordmark and Keith Moore contributed some improved
-   wording in how to handle obsoleting functionality described by an
-   Internet Standard.
-
-7 - References
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
-              3", BCP 9, RFC 2026, October 1996.
-
-   [RFC2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 3]
-
-RFC 3425                   Obsoleting IQUERY               November 2002
-
-
-8 - Author's Address
-
-   David C Lawrence
-   Nominum, Inc.
-   2385 Bay Rd
-   Redwood City CA 94063
-   USA
-
-   Phone: +1.650.779.6042
-   EMail: tale@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 4]
-
-RFC 3425                   Obsoleting IQUERY               November 2002
-
-
-9 - Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 5]
-

lib/bind/port/cygwin/include/asm/socket.h

@@ -1,12 +0,0 @@
-#ifndef _cygwin_asm_socket_h
-#define _cygwin_asm_socket_h
-
-#include_next <asm/socket.h>
-
-/* This is a lame cop-out, but cygwin's SIOCGIFCONF doesn't define
-   IFF_POINTOPOINT, so this should never happen anyway. */
-#ifndef SIOCGIFDSTADDR
-# define SIOCGIFDSTADDR SIOCGIFADDR
-#endif
-
-#endif

lib/bind/port/cygwin/include/assert.h

@@ -1,2 +0,0 @@
-#include <stdio.h>
-#include_next <assert.h>

lib/bind/port/cygwin/include/paths.h

@@ -1,2 +0,0 @@
-#define _PATH_DEVNULL "/dev/null"
-

lib/bind/port/cygwin/include/sys/cdefs.h

@@ -1,144 +0,0 @@
-/*
- * ++Copyright++ 1991, 1993
- * -
- * Copyright (c) 1991, 1993
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- * -
- * Portions Copyright (c) 1993 by Digital Equipment Corporation.
- * 
- * Permission to use, copy, modify, and distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies, and that
- * the name of Digital Equipment Corporation not be used in advertising or
- * publicity pertaining to distribution of the document or software without
- * specific, written prior permission.
- * 
- * THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
- * WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
- * CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
- * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
- * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
- * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
- * SOFTWARE.
- * -
- * --Copyright--
- */
-
-/*
- *	@(#)cdefs.h	8.1 (Berkeley) 6/2/93
- *	$Id: cdefs.h,v 1.1 2002/12/27 03:13:51 marka Exp $
- */
-
-#ifndef	_CDEFS_H_
-#define	_CDEFS_H_
-
-#if defined(__cplusplus)
-#define	__BEGIN_DECLS	extern "C" {
-#define	__END_DECLS	};
-#else
-#define	__BEGIN_DECLS
-#define	__END_DECLS
-#endif
-
-/*
- * The __CONCAT macro is used to concatenate parts of symbol names, e.g.
- * with "#define OLD(foo) __CONCAT(old,foo)", OLD(foo) produces oldfoo.
- * The __CONCAT macro is a bit tricky -- make sure you don't put spaces
- * in between its arguments.  __CONCAT can also concatenate double-quoted
- * strings produced by the __STRING macro, but this only works with ANSI C.
- */
-#if defined(__STDC__) || defined(__cplusplus)
-#define	__P(protos)	protos		/* full-blown ANSI C */
-#define	__CONCAT(x,y)	x ## y
-#define	__STRING(x)	#x
-
-#define	__const		const		/* define reserved names to standard */
-#define	__signed	signed
-#define	__volatile	volatile
-#if defined(__cplusplus)
-#define	__inline	inline		/* convert to C++ keyword */
-#else
-#ifndef __GNUC__
-#define	__inline			/* delete GCC keyword */
-#endif /* !__GNUC__ */
-#endif /* !__cplusplus */
-
-#else	/* !(__STDC__ || __cplusplus) */
-#define	__P(protos)	()		/* traditional C preprocessor */
-#define	__CONCAT(x,y)	x/**/y
-#define	__STRING(x)	"x"
-
-#ifndef __GNUC__
-#define	__const				/* delete pseudo-ANSI C keywords */
-#define	__inline
-#define	__signed
-#define	__volatile
-/*
- * In non-ANSI C environments, new programs will want ANSI-only C keywords
- * deleted from the program and old programs will want them left alone.
- * When using a compiler other than gcc, programs using the ANSI C keywords
- * const, inline etc. as normal identifiers should define -DNO_ANSI_KEYWORDS.
- * When using "gcc -traditional", we assume that this is the intent; if
- * __GNUC__ is defined but __STDC__ is not, we leave the new keywords alone.
- */
-#ifndef	NO_ANSI_KEYWORDS
-#define	const				/* delete ANSI C keywords */
-#define	inline
-#define	signed
-#define	volatile
-#endif
-#endif	/* !__GNUC__ */
-#endif	/* !(__STDC__ || __cplusplus) */
-
-/*
- * GCC1 and some versions of GCC2 declare dead (non-returning) and
- * pure (no side effects) functions using "volatile" and "const";
- * unfortunately, these then cause warnings under "-ansi -pedantic".
- * GCC2 uses a new, peculiar __attribute__((attrs)) style.  All of
- * these work for GNU C++ (modulo a slight glitch in the C++ grammar
- * in the distribution version of 2.5.5).
- */
-#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
-#define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
-#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
-#define	__dead		__volatile
-#define	__pure		__const
-#endif
-#endif
-
-/* Delete pseudo-keywords wherever they are not available or needed. */
-#ifndef __dead
-#define	__dead
-#define	__pure
-#endif
-
-#endif /* !_CDEFS_H_ */

lib/bind/port/cygwin/include/sys/socket.h

@@ -1,10 +0,0 @@
-#ifndef _cygwin_sys_socket_h
-#define _cygwin_sys_socket_h
-
-#include_next <sys/socket.h>
-
-#ifndef IFF_POINTOPOINT
-# define IFF_POINTOPOINT 0x10
-#endif
-
-#endif

lib/bind/port/cygwin/include/sys/wait.h

@@ -1,9 +0,0 @@
-#ifndef _cygwin_sys_wait_h
-
-#include_next <sys/wait.h>
-
-#if !defined (WCOREDUMP)
-# define WCOREDUMP(x) (((x) & 0x80) == 0x80)
-#endif
-
-#endif