下载文档原格式
关于strongSwan的leftrightIdid用作peer的身份验证和接入控制。
有四种类型：The ID by which a peer is identifying itself during IKE can by any of the ID types IPV[46]_ADDR, FQDN, RFC822_ADDR or DER_ASN1_DN. If one of the first three ID types is used, then the accompanying X.509 certificate of the peer must contain a matching subjectAltName field of the type ipAddress (IP:), dnsName (DNS:) or rfc822Name (email:), respectively. With the fourth typeDER_ASN1_DN the identifier must completely match the subject field of the peer's certificate.(1)ip地址类型：当peer的ip地址是可知的，则可以不定义rightid(2)FQDN类型：rightid=@(3)email类型：rightid=********************(4)DN类型：rightid="C=CH, O=strongSwan IPsec, CN=" C代表country, O代表organization, CN代表comman name如果id是前三种，则证书中的subjectAltName必须是IP: DNS: 或email:.如果id是第四种，则证书中的subject field必须填写DN的值。
If not all peers in possession of a X.509 certificate signed by a specificcertificate authority shall be given access to the Linux security gateway,then either a subset of them can be barred by listing the serial numbers oftheir certificates in a certificate revocation list (CRL) as specified insection 5.2 or as an alternative, access can be controlled by explicitlyputting a roadwarrior entry for each eligible peer into ipsec.conf.如想对peers做access控制，有两种办法，一是添加CRL，而是用rightid值，明确给出可访问的peer的id。
Network Working Group T. Hardie Request for Comments: 3258 Nominum, Inc. Category: Informational April 2002 Distributing Authoritative Name Servers via Shared Unicast Addresses Status of this MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2002). All Rights Reserved. AbstractThis memo describes a set of practices intended to enable anauthoritative name server operator to provide access to a singlenamed server in multiple locations. The primary motivation for thedevelopment and deployment of these practices is to increase thedistribution of Domain Name System (DNS) servers to previouslyunder-served areas of the network topology and to reduce the latency for DNS query responses in those areas.1. IntroductionThis memo describes a set of practices intended to enable anauthoritative name server operator to provide access to a singlenamed server in multiple locations. The primary motivation for thedevelopment and deployment of these practices is to increase thedistribution of DNS servers to previously under-served areas of thenetwork topology and to reduce the latency for DNS query responses in those areas. This document presumes a one-to-one mapping betweennamed authoritative servers and administrative entities (operators). This document contains no guidelines or recommendations for cachingname servers. The shared unicast system described here is specificto IPv4; applicability to IPv6 is an area for further study. Itshould also be noted that the system described here is related tothat described in [ANYCAST], but it does not require dedicatedaddress space, routing changes, or the other elements of a fullanycast infrastructure which that document describes.Hardie Informational [Page 1]2. Architecture2.1 Server RequirementsOperators of authoritative name servers may wish to refer to[SECONDARY] and [ROOT] for general guidance on appropriate practicefor authoritative name servers. In addition to proper configuration as a standard authoritative name server, each of the hostsparticipating in a shared-unicast system should be configured withtwo network interfaces. These interfaces may be either two physical interfaces or one physical interface mapped to two logicalinterfaces. One of the network interfaces should use the IPv4 shared unicast address associated with the authoritative name server. Theother interface, referred to as the administrative interface below,should use a distinct IPv4 address specific to that host. The hostshould respond to DNS queries only on the shared-unicast interface.In order to provide the most consistent set of responses from themesh of anycast hosts, it is good practice to limit responses on that interface to zones for which the host is authoritative.2.2 Zone file deliveryIn order to minimize the risk of man-in-the-middle attacks, zonefiles should be delivered to the administrative interface of theservers participating in the mesh. Secure file transfer methods and strong authentication should be used for all transfers. If the hosts in the mesh make their zones available for zone transfer, theadministrative interfaces should be used for those transfers as well, in order to avoid the problems with potential routing changes for TCP traffic noted in section 2.5 below.2.3 SynchronizationAuthoritative name servers may be loosely or tightly synchronized,depending on the practices set by the operating organization. Asnoted below in section 4.1.2, lack of synchronization among serversusing the same shared unicast address could create problems for some users of this service. In order to minimize that risk, switch-overs from one data set to another data set should be coordinated as muchas possible. The use of synchronized clocks on the participatinghosts and set times for switch-overs provides a basic level ofcoordination. A more complete coordination process would involve:a) receipt of zones at a distribution hostb) confirmation of the integrity of zones receivedc) distribution of the zones to all of the servers in the meshd) confirmation of the integrity of the zones at each serverHardie Informational [Page 2]e) coordination of the switchover times for the servers in themeshf) institution of a failure process to ensure that servers thatdid not receive correct data or could not switchover to the new data ceased to respond to incoming queries until the problemcould be resolved.Depending on the size of the mesh, the distribution host may also be a participant; for authoritative servers, it may also be the host on which zones are generated.This document presumes that the usual DNS failover methods are theonly ones used to ensure reachability of the data for clients. Itdoes not advise that the routes be withdrawn in the case of failure; it advises instead that the DNS process shutdown so that servers onother addresses are queried. This recommendation reflects a choicebetween performance and operational complexity. While it would bepossible to have some process withdraw the route for a specificserver instance when it is not available, there is considerableoperational complexity involved in ensuring that this occursreliably. Given the existing DNS failover methods, the marginalimprovement in performance will not be sufficient to justify theadditional complexity for most uses.2.4 Server PlacementThough the geographic diversity of server placement helps reduce the effects of service disruptions due to local problems, it is diversity of placement in the network topology which is the driving forcebehind these distribution practices. Server placement shouldemphasize that diversity. Ideally, servers should be placedtopologically near the points at which the operator exchanges routes and traffic with other networks.2.5 RoutingThe organization administering the mesh of servers sharing a unicast address must have an autonomous system number and speak BGP to itspeers. To those peers, the organization announces a route to thenetwork containing the shared-unicast address of the name server.The organization’s border routers must then deliver the trafficdestined for the name server to the nearest instantiation. Routingto the administrative interfaces for the servers can use the normalrouting methods for the administering organization.One potential problem with using shared unicast addresses is thatrouters forwarding traffic to them may have more than one availableroute, and those routes may, in fact, reach different instances of Hardie Informational [Page 3]the shared unicast address. Applications like the DNS, whosecommunication typically consists of independent request-responsemessages each fitting in a single UDP packet present no problem.Other applications, in which multiple packets must reach the sameendpoint (e.g., TCP) may fail or present unworkable performancecharacteristics in some circumstances. Split-destination failuresmay occur when a router does per-packet (or round-robin) loadsharing, a topology change occurs that changes the relative metricsof two paths to the same anycast destination, etc.Four things mitigate the severity of this problem. The first is that UDP is a fairly high proportion of the query traffic to name servers. The second is that the aim of this proposal is to diversifytopological placement; for most users, this means that thecoordination of placement will ensure that new instances of a nameserver will be at a significantly different cost metric from existing instances. Some set of users may end up in the middle, but thatshould be relatively rare. The third is that per packet load sharing is only one of the possible load sharing mechanisms, and othermechanisms are increasing in popularity.Lastly, in the case where the traffic is TCP, per packet load sharing is used, and equal cost routes to different instances of a nameserver are available, any DNS implementation which measures theperformance of servers to select a preferred server will quicklyprefer a server for which this problem does not occur. For the DNSfailover mechanisms to reliably avoid this problem, however, thoseusing shared unicast distribution mechanisms must take care that all of the servers for a specific zone are not participants in the sameshared-unicast mesh. To guard even against the case where multiplemeshes have a set of users affected by per packet load sharing along equal cost routes, organizations implementing these practices should always provide at least one authoritative server which is not aparticipant in any shared unicast mesh. Those deploying shared-unicast meshes should note that any specific host may becomeunreachable to a client should a server fail, a path fail, or theroute to that host be withdrawn. These error conditions are,however, not specific to shared-unicast distributions, but wouldoccur for standard unicast hosts.Since ICMP response packets might go to a different member of themesh than that sending a packet, packets sent with a shared unicastsource address should also avoid using path MTU discovery.Appendix A. contains an ASCII diagram of an example of a simpleimplementation of this system. In it, the odd numbered routersdeliver traffic to the shared-unicast interface network and filtertraffic from the administrative network; the even numbered routers Hardie Informational [Page 4]deliver traffic to the administrative network and filter traffic from the shared-unicast network. These are depicted as separate routersfor the ease this gives in explanation, but they could easily beseparate interfaces on the same router. Similarly, a local NTPsource is depicted for synchronization, but the level ofsynchronization needed would not require that source to be eitherlocal or a stratum one NTP server.3. Administration3.1 Points of ContactA single point of contact for reporting problems is crucial to thecorrect administration of this system. If an external user of thesystem needs to report a problem related to the service, there mustbe no ambiguity about whom to contact. If internal monitoring doesnot indicate a problem, the contact may, of course, need to work with the external user to identify which server generated the error.4. Security ConsiderationsAs a core piece of Internet infrastructure, authoritative nameservers are common targets of attack. The practices outlined hereincrease the risk of certain kinds of attacks and reduce the risk of others.4.1 Increased Risks4.1.1 Increase in physical serversThe architecture outlined in this document increases the number ofphysical servers, which could increase the possibility that a server mis-configuration will occur which allows for a security breach. In general, the entity administering a mesh should ensure that patchesand security mechanisms applied to a single member of the mesh areappropriate for and applied to all of the members of a mesh."Genetic diversity" (code from different code bases) can be a useful security measure in avoiding attacks based on vulnerabilities in aspecific code base; in order to ensure consistency of responses from a single named server, however, that diversity should be applied todifferent shared-unicast meshes or between a mesh and a relatedunicast authoritative server.4.1.2 Data synchronization problemsThe level of systemic synchronization described above should beaugmented by synchronization of the data present at each of theservers. While the DNS itself is a loosely coupled system, debugging Hardie Informational [Page 5]problems with data in specific zones would be far more difficult iftwo different servers sharing a single unicast address might returndifferent responses to the same query. For example, if the dataassociated with has changed and the administrators of the domain are testing for the changes at the authoritative name servers, they should not need to check eachinstance of a named authoritative server. The use of NTP to provide a synchronized time for switch-over eliminates some aspects of thisproblem, but mechanisms to handle failure during the switchover arerequired. In particular, a server which cannot make the switchovermust not roll-back to a previous version; it must cease to respond to queries so that other servers are queried.4.1.3 Distribution risksIf the mechanism used to distribute zone files among the servers isnot well secured, a man-in-the-middle attack could result in theinjection of false information. Digital signatures will alleviatethis risk, but encrypted transport and tight access lists are anecessary adjunct to them. Since zone files will be distributed tothe administrative interfaces of meshed servers, the access controllist for distribution of the zone files should include theadministrative interface of the server or servers, rather than their shared unicast addresses.4.2 Decreased RisksThe increase in number of physical servers reduces the likelihoodthat a denial-of-service attack will take out a significant portionof the DNS infrastructure. The increase in servers also reduces the effect of machine crashes, fiber cuts, and localized disasters byreducing the number of users dependent on a specific machine.5. AcknowledgmentsMasataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak,Mark Andrews, Robert Elz, Geoff Huston, Bill Norton, Akira Kato,Suzanne Woolf, Bernard Aboba, Casey Ajalat, and Gunnar Lindberg allprovided input and commentary on this work. The editor wishes toremember in particular the contribution of the late Scott Tucker,whose extensive systems experience and plain common sense bothcontributed greatly to the editor’s own deployment experience and are missed by all who knew him.Hardie Informational [Page 6]6. References[SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection and Operation of Secondary DNS Servers", BCP 16, RFC2182, July 1997.[ROOT] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root Name Server Operational Requirements", BCP 40, RFC 2870, June 2000.[ANYCAST] Patridge, C., Mendez, T. and W. Milliken, "HostAnycasting Service", RFC 1546, November 1993.Hardie Informational [Page 7]Appendix A.__________________Peer 1-| |Peer 2-| |Peer 3-| Switch |Transit| | _________ _________etc | |--|Router1|---|----|----------|Router2|---WAN-| | | --------- | | --------- | | | | | | | | | | | ------------------ [NTP] [DNS] | | | | | __________________ | Peer 1-| | | Peer 2-| | | Peer 3-| Switch | | Transit| | _________ _________ | etc | |--|Router3|---|----|----------|Router4|---WAN-| | | --------- | | --------- | | | | | | | | | | | ------------------ [NTP] [DNS] | | | | | __________________ | Peer 1-| | | Peer 2-| | | Peer 3-| Switch | | Transit| | _________ _________ | etc | |--|Router5|---|----|----------|Router6|---WAN-| | | --------- | | --------- | | | | | | | | | | | ------------------ [NTP] [DNS] | | | | Hardie Informational [Page 8]| __________________ | Peer 1-| | | Peer 2-| | | Peer 3-| Switch | | Transit| | _________ _________ | etc | |--|Router7|---|----|----------|Router8|---WAN-| | | --------- | | ---------| | | || | | |------------------ [NTP] [DNS]Hardie Informational [Page 9]7. Editor’s AddressTed HardieNominum, Inc.2385 Bay Road.Redwood City, CA 94063Phone: 1.650.381.6226EMail: Ted.Hardie@Hardie Informational [Page 10]RFC 3258 Distributing Authoritative Name Servers April 2002 8. Full Copyright StatementCopyright (C) The Internet Society (2002). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked 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 ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Hardie Informational [Page 11]。
下一代DNS系统Foundation介绍（Nominum）DNS（Domain Name System）是Internet中一个非常重要的部分，在TCP/IP 的世界中，都是以IP 地址识别主机，虽然这种表示方法适合路由器等来使用，但是并不适合人们去记忆，因此，一般来说，网络中的主机都被指定了一个独一无二的名称，也就是域名（Domain Name）。
然而这又带来了另外一个问题，这些名称不易为路由器等处理，也不含可找到主机的位置信息。
所以需要一种系统在IP地址和机器的名称间建立一种对应关系，DNS系统也就应运而生了。
当然在早期的时候，并没有很复杂，只是在一台中央授权机器上建立名称与IP地址的对应关系。
到了80年代中期，DNS才真正发展起来，目前在全球所采用的DNS大多都是由ISC （Internet Software Consortium）发布的BIND（Berkeley Internet Name Domain）。
但是由于先天性的原因，BIND系统有着很多无法克服的问题。
全球领先的DNS方案提供商Nominum 在其经验和倾听了很多用户意见的基础上，推出了下一代的DNS系统Foundation，按功能划分，该系统包括CNS（Caching Name Server）、ANS（Authoritative Name Server）和FMC （Foundation Management Center），目前已经被世界众多知名电信公司和企业所采用。
一 BIND的问题作为一款公开代码的DNS服务程序，BIND在现行的DNS的系统中，得到了的非常广泛的使用。
Nominum公司在2000年九月向ISC发布了BIND 9.0，到2003中期，大约三分之一的主要英特网连接的DNS 服务器都运行BIND 9。
BIND 9 被事实证明的确比BIND 8更好，包括提高了安全性、可维护性、以及向对BIND 8的兼容性等。
但是随着网络迅速的发展，人们不断的发现BIND已经不适应在如今复杂的网络环境下提供DNS服务了。
Generic Routing Encapsulation (GRE)一般路由封装协议Status of this Memo备忘录状态This document specifies an Internet standards track protocol for theInternet community, and requests discussion and suggestions forimprovements.该文档特指一个关于网络通信的Internet标准追踪协议，并要求讨论和改进建议。
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 (2000). All Rights Reserved.版权所有（C）因特网协会（2000）。
保留所有权利。
Abstract摘要This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol.这个文档制定了一个协议，用于一个任意的网络层协议承载另一个任意网络层协议的封装。
1. IntroductionA number of different proposals [RFC1234, RFC1226] currently exist for the encapsulation of one protocol over another protocol.目前有许多不同的建议说明书用于一个协议承载另一个协议的封装。
许可证错误原因对照表FLEXnet Licensing Error Codes Error Code Descriptions-1 Cannot find license file.-2 Invalid license file syntax.-3 No license server system for this feature.-4 Licensed number of users already reached.-5 No such feature exists.-6 No TCP/IP port number in license file and FLEXnet Licensing service does not exist. (pre-v6 only-7 No socket connection to license server manager service.-8 Invalid (inconsistent license key or signature.The license key/signature and data for the feature do not match. Thisusually happens when a license file has been altered.-9 Invalid host.The hostid of this system does not match the hostid specified in thelicense file.-10 Feature has expired.-11 Invalid date format in license file.-12 Invalid returned data from license server system.-13 No SERVER lines in license file.-14 Cannot find SERVER host name in network database.The lookup for the host name on the SERVER line in the license filefailed. This often happens when NIS or DNS or the hosts file isincorrect. Workaround: Use IP address (e.g., 123.456.789.123 insteadof host name.-15 Cannot connect to license server system.The server (lmgrd has not been started yet, or the wrong[email=port@host]port@host[/email]or license file is being used, or the TCP/IP port or host name in thelicense file has been changed.-16 Cannot read data from license server system.-17 Cannot write data to license server system.-18 License server system does not support this feature.-19 Error in select system call.-21 License file does not support this version.-22 Feature checkin failure detected at license server system.-23 License server system temporarily busy (new server connecting .-24 Users are queued for this feature.-25 License server system does not support this version of this feature.-26 Request for more licenses than this feature supports.-29 Cannot find ethernet device.-30 Cannot read license file.-31 Feature start date is in the future.-32 No such attribute.-33 Bad encryption handshake with vendor daemon.-34 Clock difference too large between client and license server system. -35 In the queue for this feature.-36 Feature database corrupted in vendor daemon.-37 Duplicate selection mismatch for this feature. Obsolete with v8.0+ vendor daemon.-38 User/host on EXCLUDE list for feature.-39 User/host not on INCLUDE list for feature.-40 Cannot allocate dynamic memory.-41 Feature was never checked out.-42 Invalid parameter.-47 Clock setting check not available in vendor daemon.-52 Vendor daemon did not respond within timeout interval.-53 Checkout request rejected by vendor-defined checkout filter.-54 No FEATURESET line in license file.-55 Incorrect FEATURESET line in license file.-56 Cannot compute FEATURESET data from license file.-571 socket( call failed.-59 Message checksum failure.-60 License server system message checksum failure.-61 Cannot read license file data from license server system.-62 Network software (TCP/IP not available.-63 You are not a license administrator.-64 lmremove request before the minimum lmremove interval.-67 No licenses available to borrow.-68 License BORROW support not enabled.-69 FLOAT_OK can’t run standalone on license server system.-71 Invalid TZ environment variable.-73 Local checkout filter rejected request.-74 Attempt to read beyond end of license file path.-751 SYS$SETIMR call failed (VMS .-76 Internal FLEXnet Licensing error—please report to Macrovision Corporation.-77 Bad version number must be floating-point number with no letters.-82 Invalid PACKAGE line in license file.-83 FLEXnet Licensing version of client newer than server.-84 USER_BASED license has no specified users - see license server system log.-85 License server system d oesn’t support this request.-87 Checkout exceeds MAX specified in options file.-88 System clock has been set back.-89 This platform not authorized by license.-90 Future license file format or misspelling in license file.The file was issued for a later version of FLEXnet Licensing than thisprogram understands.-91 Encryption seeds are non-unique.-92 Feature removed during lmreread, or wrong SERVER line hostid.-93 This feature is available in a different license pool.This is a warning condition. The server has pooled one or moreINCREMENT lines into a single pool, and the request was made on an INCREMENT line that has been pooled.-94 Attempt to generate license with incompatible attributes.-95 Network connect to THIS_HOST failed.Change this_host on the SERVER line in the license file to theactual host name.-96 License server machine is down or not responding.See the system administrator about starting the server, or make sure thatyou’re referring to the right host (see LM_LICENSE_FILE environmen tvariable .-97 The desired vendor daemon is down.1 Check the lmgrd log file, or2 Try lmreread.-98 This FEATURE line can’t be converted to decimal format.-99 The decimal format license is typed incorrectly.-100 Cannot remove a linger license.-101 All licenses are reserved for others.The system administrator has reserved all the licenses for others. Reservations are made in the options file. The server must be restartedfor options file changes to take effect.-102 A FLEXid borrow error occurred.-103 Terminal Server remote client not allowed.-104 Cannot borrow that long.-106 License server system out of network connections.The vendor daemon can't handle any more users. See the debug log forfurther information.-110 Cannot read dongle: check dongle or driver.Either the dongle is unattached, or the necessary software driver for this dongle type is not installed.-112 Missing dongle driver.In order to read the FLEXid hostid, the correct driver must be installed. These drivers are available from your software vendor.-114 SIGN= keyword required, but missing from license certificate. You need to obtain a SIGN= version of this license from your vendor.-115 Error in Public Key package.-116 TRL not supported for this platform.-117 BORROW failed.-118 BORROW period expired.-119 lmdown and lmreread must be run on license server machine.-120 Cannot lmdown the server when licenses are borrowed.-121 FLOAT_OK requires exactly one FLEXid hostid.-122 Unable to delete local borrow info.-123 Returning a borrowed license early is not supported. Contact the vendor for further details.-124 Error returning borrowed license.-125 A PACKAGE component must be specified.-126 Composite hostid not initialized.-127 A item needed for the composite hostid is missing or invalid.-128 Error, borrowed license doesn't match any known server license.-135 Error enabling the event log.-136 Event logging is disabled.-137 Error writing to the event log.-139 Communications timeout.-140 Bad message command.-141 Error writing to socket. Peer has closed socket.-142 Error, cannot generate version specific license tied to a single hostid, which is composite.-143 Version-specific signatures are not supported for uncounted licenses.-144 License template contains redundant signature specifiers.-145 Bad V71_LK signature.-146 Bad V71_SIGN signature.-147 Bad V80_LK signature.-148 Bad V80_SIGN signature.-149 Bad V81_LK signature.-150 Bad V81_SIGN signature.-151 Bad V81_SIGN2 signature.-152 Bad V84_LK signature.-153 Bad V84_SIGN signature.-154 Bad V84_SIGN2 signature.-155 License key required but missing from the license certificate. The application requires a license key in the license certificate. You need toobtain a license key version of this certificate from your vendor.-156 Invalid signature specified with the AUTH= keyword.-500 Invalid server port number.-501 Invalid value in license where an integer was expected.-502 Invalid value supplied for count.-503 Invalid hostid supplied in license.-504 Invalid hostid type supplied.-505 Bad feature line syntax.-506 Internal FLEXnet Licensing error.-507 Bad date format in license file.-508 Bad SERVER line.-509 Bad license string.-510 Server's feature doesn't authenticate on client side.-511 No license checked out.-512 License already checked out.-513 Error list returned.-514 No certicom module available.-515 Wrong or incomplete certicom module.-516 SIGN or SIGN2 required in license certificate.-517 Feature object has no license sources.-518 An Identical license is already checked out on this license source.-519 This license has an asynchronously-queued checkout pending.-521 Library for native hostid couldn't be loaded-522 Already connected to another vendor daemon.-523 No such user, host, or display.-524 Shutdown of license server system failed.-525 Shutdown failed — already connected to license server system.-526 Invalid license source string.-527 Log file switch error.------------------------------------------------------------------------------------------------------译成中文(简体)FLEXnet许可错误代码错误代码说明-1找不到许可证文件。
Network Working Group J. Schlyter, Ed. Request for Comments: 3845 August 2004 Updates: 3755, 2535Category: Standards TrackDNS Security (DNSSEC) NextSECure (NSEC) RDATA FormatStatus of this MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited. Copyright NoticeCopyright (C) The Internet Society (2004).AbstractThis document redefines the wire format of the "Type Bit Map" fieldin the DNS NextSECure (NSEC) resource record RDATA format to coverthe full resource record (RR) type space.Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 22. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 2 2.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . 3 2.1.1. The Next Domain Name Field . . . . . . . . . . . 3 2.1.2. The List of Type Bit Map(s) Field . . . . . . . 3 2.1.3. Inclusion of Wildcard Names in NSEC RDATA . . . 4 2.2. The NSEC RR Presentation Format . . . . . . . . . . . . 42.3. NSEC RR Example . . . . . . . . . . . . . . . . . . . . 53. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54. Security Considerations . . . . . . . . . . . . . . . . . . . 55. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . 65.2. Informative References . . . . . . . . . . . . . . . . . 66. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67. Author’s Address . . . . . . . . . . . . . . . . . . . . . . . 68. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7 Schlyter, Ed. Standards Track [Page 1]1. IntroductionThe DNS [6][7] NSEC [5] Resource Record (RR) is used forauthenticated proof of the non-existence of DNS owner names andtypes. The NSEC RR is based on the NXT RR as described in RFC 2535[2], and is similar except for the name and typecode. The RDATAformat for the NXT RR has the limitation in that the RDATA could only carry information about the existence of the first 127 types. RFC2535 did reserve a bit to specify an extension mechanism, but themechanism was never actually defined.In order to avoid needing to develop an extension mechanism into adeployed base of DNSSEC aware servers and resolvers once the first127 type codes are allocated, this document redefines the wire format of the "Type Bit Map" field in the NSEC RDATA to cover the full RRtype space.This document introduces a new format for the type bit map. Theproperties of the type bit map format are that it can cover the full possible range of typecodes, that it is relatively economical in the amount of space it uses for the common case of a few types with anowner name, that it can represent owner names with all possible types present in packets of approximately 8.5 kilobytes, and that therepresentation is simple to implement. Efficient searching of thetype bitmap for the presence of certain types is not a requirement.For convenience and completeness, this document presents the syntaxand semantics for the NSEC RR based on the specification in RFC 2535 [2] and as updated by RFC 3755 [5], thereby not introducing changesexcept for the syntax of the type bit map.This document updates RFC 2535 [2] and RFC 3755 [5].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 BCP 14, RFC 2119 [1].2. The NSEC Resource RecordThe NSEC resource record lists two separate things: the owner name of the next RRset in the canonical ordering of the zone, and the set of RR types present at the NSEC RR’s owner name. The complete set ofNSEC RRs in a zone indicate which RRsets exist in a zone, and form a chain of owner names in the zone. This information is used toprovide authenticated denial of existence for DNS data, as described in RFC 2535 [2].The type value for the NSEC RR is 47.Schlyter, Ed. Standards Track [Page 2]The NSEC RR RDATA format is class independent and defined for allclasses.The NSEC RR SHOULD have the same TTL value as the SOA minimum TTLfield. This is in the spirit of negative caching [8].2.1. NSEC RDATA Wire FormatThe RDATA of the NSEC RR is as shown below:1 1 1 1 1 1 1 1 1 12 2 2 2 2 2 2 2 2 23 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ Next Domain Name /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ List of Type Bit Map(s) /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+2.1.1. The Next Domain Name FieldThe Next Domain Name field contains the owner name of the next RR in the canonical ordering of the zone. The value of the Next DomainName field in the last NSEC record in the zone is the name of thezone apex (the owner name of the zone’s SOA RR).A sender MUST NOT use DNS name compression on the Next Domain Namefield when transmitting an NSEC RR.Owner names of RRsets that are not authoritative for the given zone(such as glue records) MUST NOT be listed in the Next Domain Nameunless at least one authoritative RRset exists at the same ownername.2.1.2. The List of Type Bit Map(s) FieldThe RR type space is split into 256 window blocks, each representing the low-order 8 bits of the 16-bit RR type space. Each block thathas at least one active RR type is encoded using a single octetwindow number (from 0 to 255), a single octet bitmap length (from 1to 32) indicating the number of octets used for the window block’sbitmap, and up to 32 octets (256 bits) of bitmap.Window blocks are present in the NSEC RR RDATA in increasingnumerical order."|" denotes concatenationType Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + Schlyter, Ed. Standards Track [Page 3]Each bitmap encodes the low-order 8 bits of RR types within thewindow block, in network bit order. The first bit is bit 0. Forwindow block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS), and so forth. For window block 1, bit 1corresponds to RR type 257, and bit 2 to RR type 258. If a bit isset to 1, it indicates that an RRset of that type is present for the NSEC RR’s owner name. If a bit is set to 0, it indicates that noRRset of that type is present for the NSEC RR’s owner name.Since bit 0 in window block 0 refers to the non-existing RR type 0,it MUST be set to 0. After verification, the validator MUST ignorethe value of bit 0 in window block 0.Bits representing Meta-TYPEs or QTYPEs, as specified in RFC 2929 [3] (section 3.1), or within the range reserved for assignment only toQTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear inzone data. If encountered, they must be ignored upon reading.Blocks with no types present MUST NOT be included. Trailing zerooctets in the bitmap MUST be omitted. The length of each block’sbitmap is determined by the type code with the largest numericalvalue within that block, among the set of RR types present at theNSEC RR’s owner name. Trailing zero octets not specified MUST beinterpreted as zero octets.2.1.3. Inclusion of Wildcard Names in NSEC RDATAIf a wildcard owner name appears in a zone, the wildcard label ("*") is treated as a literal symbol and is treated the same as any otherowner name for purposes of generating NSEC RRs. Wildcard owner names appear in the Next Domain Name field without any wildcard expansion. RFC 2535 [2] describes the impact of wildcards on authenticateddenial of existence.2.2. The NSEC RR Presentation FormatThe presentation format of the RDATA portion is as follows:The Next Domain Name field is represented as a domain name.The List of Type Bit Map(s) Field is represented as a sequence of RR type mnemonics. When the mnemonic is not known, the TYPErepresentation as described in RFC 3597 [4] (section 5) MUST be used. Schlyter, Ed. Standards Track [Page 4]2.3. NSEC RR ExampleThe following NSEC RR identifies the RRsets associated with. and the next authoritative name after.. 86400 IN NSEC . A MX RRSIG NSECTYPE1234The first four text fields specify the name, TTL, Class, and RR type (NSEC). The entry . is the next authoritative nameafter . in canonical order. The A, MX, RRSIG, NSEC, and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, andTYPE1234 RRsets associated with the name .The RDATA section of the NSEC RR above would be encoded as:0x04 ’h’ ’o’ ’s’ ’t’0x07 ’e’ ’x’ ’a’ ’m’ ’p’ ’l’ ’e’0x03 ’c’ ’o’ ’m’ 0x000x00 0x06 0x40 0x01 0x00 0x00 0x00 0x030x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x000x00 0x00 0x00 0x00 0x00 0x00 0x00 0x000x00 0x00 0x00 0x00 0x00 0x00 0x00 0x000x00 0x00 0x00 0x00 0x20Assuming that the resolver can authenticate this NSEC record, itcould be used to prove that does not exist, or could be used to prove that there is no AAAA record associated with. Authenticated denial of existence is discussed in RFC 2535 [2].3. IANA ConsiderationsThis document introduces no new IANA considerations, because all ofthe protocol parameters used in this document have already beenassigned by RFC 3755 [5].4. Security ConsiderationsThe update of the RDATA format and encoding does not affect thesecurity of the use of NSEC RRs.Schlyter, Ed. Standards Track [Page 5]5. References5.1. Normative References[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[2] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.[3] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,September 2000.[4] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)Types", RFC 3597, September 2003.[5] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004.5.2. Informative References[6] Mockapetris, P., "Domain names - concepts and facilities", STD13, RFC 1034, November 1987.[7] Mockapetris, P., "Domain names - implementation andspecification", STD 13, RFC 1035, November 1987.[8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.6. AcknowledgementsThe encoding described in this document was initially proposed byMark Andrews. Other encodings where proposed by David Blacka andMichael Graff.7. Author’s AddressJakob Schlyter (editor)NIC-SEBox 5774Stockholm SE-114 87SwedenEMail: jakob@nic.seURI: http://www.nic.se/Schlyter, Ed. Standards Track [Page 6]8. Full Copyright StatementCopyright (C) The Internet Society (2004).This document is subject to the rights, licenses and restrictionscontained in BCP 78, and except as set forth therein, the authorsretain all their rights.This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HEREPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS ORIMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OFTHE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual PropertyThe IETF takes no position regarding the validity or scope of anyIntellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; nor does it represent that it hasmade any independent effort to identify any such rights. Information on the IETF’s procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.Copies of IPR disclosures made to the IETF Secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of thisspecification can be obtained from the IETF on-line IPR repository at /ipr.The IETF invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. Please address the information to the IETF at ietf-ipr@.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Schlyter, Ed. Standards Track [Page 7]。
Network Working Group A. Gulbrandsen Request for Comments: 2782 Troll Technologies Obsoletes: 2052 P. Vixie Category: Standards Track Internet Software Consortium L. Esibov Microsoft Corp. February 2000 A DNS RR for specifying the location of services (DNS SRV)Status of this MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2000). All Rights Reserved.AbstractThis document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain.Overview and rationaleCurrently, one must either know the exact address of a server tocontact it, or broadcast a question.The SRV RR allows administrators to use several servers for a single domain, to move services from host to host with little fuss, and todesignate some hosts as primary servers for a service and others asbackups.Clients ask for a specific service/protocol for a specific domain(the word domain is used here in the strict RFC 1034 sense), and get back the names of any available servers.Note that where this document refers to "address records", it means A RR’s, AAAA RR’s, or their most modern equivalent.Gulbrandsen, et al. Standards Track [Page 1]DefinitionsThe key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"used in this document are to be interpreted as specified in [BCP 14]. Other terms used in this document are defined in the DNSspecification, RFC 1034.Applicability StatementIn general, it is expected that SRV records will be used by clientsfor applications where the relevant protocol specification indicates that clients should use the SRV record. Such specification MUSTdefine the symbolic name to be used in the Service field of the SRVrecord as described below. It also MUST include securityconsiderations. Service SRV records SHOULD NOT be used in the absence of such specification.Introductory exampleIf a SRV-cognizant LDAP client wants to discover a LDAP server thatsupports TCP protocol and provides LDAP service for the domain., it does a lookup of_ldap._as described in [ARM]. The example zone file near the end of thismemo contains answering RRs for an SRV query.Note: LDAP is chosen as an example for illustrative purposes only,and the LDAP examples used in this document should not be considered a definitive statement on the recommended way for LDAP to use SRVrecords. As described in the earlier applicability section, consultthe appropriate LDAP documents for the recommended procedures.The format of the SRV RRHere is the format of the SRV RR, whose DNS type code is 33:_Service._ TTL Class SRV Priority Weight Port Target(There is an example near the end of this document.)ServiceThe symbolic name of the desired service, as defined in Assigned Numbers [STD 2] or locally. An underscore (_) is prepended tothe service identifier to avoid collisions with DNS labels that occur in nature.Gulbrandsen, et al. Standards Track [Page 2]Some widely used services, notably POP, don’t have a singleuniversal name. If Assigned Numbers names the serviceindicated, that name is the only name which is legal for SRVlookups. The Service is case insensitive.ProtoThe symbolic name of the desired protocol, with an underscore(_) prepended to prevent collisions with DNS labels that occurin nature. _TCP and _UDP are at present the most useful values for this field, though any name defined by Assigned Numbers orlocally may be used (as for Service). The Proto is caseinsensitive.NameThe domain this RR refers to. The SRV RR is unique in that the name one searches for is not this name; the example near the end shows this clearly.TTLStandard DNS meaning [RFC 1035].ClassStandard DNS meaning [RFC 1035]. SRV records occur in the INClass.PriorityThe priority of this target host. A client MUST attempt tocontact the target host with the lowest-numbered priority it can reach; target hosts with the same priority SHOULD be tried in an order defined by the weight field. The range is 0-65535. This is a 16 bit unsigned integer in network byte order.WeightA server selection mechanism. The weight field specifies arelative weight for entries with the same priority. Largerweights SHOULD be given a proportionately higher probability of being selected. The range of this number is 0-65535. This is a 16 bit unsigned integer in network byte order. Domainadministrators SHOULD use Weight 0 when there isn’t any serverselection to do, to make the RR easier to read for humans (less noisy). In the presence of records containing weights greaterthan 0, records with weight 0 should have a very small chance of being selected.In the absence of a protocol whose specification calls for theuse of other weighting information, a client arranges the SRVRRs of the same Priority in the order in which target hosts, Gulbrandsen, et al. Standards Track [Page 3]specified by the SRV RRs, will be contacted. The followingalgorithm SHOULD be used to order the SRV RRs of the samepriority:To select a target to be contacted next, arrange all SRV RRs(that have not been ordered yet) in any order, except that allthose with weight 0 are placed at the beginning of the list.Compute the sum of the weights of those RRs, and with each RRassociate the running sum in the selected order. Then choose auniform random number between 0 and the sum computed(inclusive), and select the RR whose running sum value is thefirst in the selected order which is greater than or equal tothe random number selected. The target host specified in theselected SRV RR is the next one to be contacted by the client.Remove this SRV RR from the set of the unordered SRV RRs andapply the described algorithm to the unordered SRV RRs to select the next target host. Continue the ordering process until there are no unordered SRV RRs. This process is repeated for eachPriority.PortThe port on this target host of this service. The range is 0-65535. This is a 16 bit unsigned integer in network byte order. This is often as specified in Assigned Numbers but need not be. TargetThe domain name of the target host. There MUST be one or moreaddress records for this name, the name MUST NOT be an alias (in the sense of RFC 1034 or RFC 2181). Implementors are urged, but not required, to return the address record(s) in the Additional Data section. Unless and until permitted by future standardsaction, name compression is not to be used for this field.A Target of "." means that the service is decidedly notavailable at this domain.Domain administrator adviceExpecting everyone to update their client applications when the first server publishes a SRV RR is futile (even if desirable). ThereforeSRV would have to coexist with address record lookups for existingprotocols, and DNS administrators should try to provide addressrecords to support old clients:- Where the services for a single domain are spread over severalhosts, it seems advisable to have a list of address records atthe same DNS node as the SRV RR, listing reasonable (if perhaps Gulbrandsen, et al. Standards Track [Page 4]suboptimal) fallback hosts for Telnet, NNTP and other protocols likely to be used with this name. Note that some programs only try the first address they get back from e.g. gethostbyname(),and we don’t know how widespread this behavior is.- Where one service is provided by several hosts, one can eitherprovide address records for all the hosts (in which case theround-robin mechanism, where available, will share the loadequally) or just for one (presumably the fastest).- If a host is intended to provide a service only when the mainserver(s) is/are down, it probably shouldn’t be listed inaddress records.- Hosts that are referenced by backup address records must use the port number specified in Assigned Numbers for the service.- Designers of future protocols for which "secondary servers" isnot useful (or meaningful) may choose to not use SRV’s supportfor secondary servers. Clients for such protocols may use orignore SRV RRs with Priority higher than the RR with the lowest Priority for a domain.Currently there’s a practical limit of 512 bytes for DNS replies.Until all resolvers can handle larger responses, domainadministrators are strongly advised to keep their SRV replies below512 bytes.All round numbers, wrote Dr. Johnson, are false, and these numbersare very round: A reply packet has a 30-byte overhead plus the nameof the service ("_ldap._" for instance); each SRV RRadds 20 bytes plus the name of the target host; each NS RR in the NS section is 15 bytes plus the name of the name server host; andfinally each A RR in the additional data section is 20 bytes or so,and there are A’s for each SRV and NS RR mentioned in the answer.This size estimate is extremely crude, but shouldn’t underestimatethe actual answer size by much. If an answer may be close to thelimit, using a DNS query tool (e.g. "dig") to look at the actualanswer is a good idea.The "Weight" fieldWeight, the server selection field, is not quite satisfactory, butthe actual load on typical servers changes much too quickly to bekept around in DNS caches. It seems to the authors that offeringadministrators a way to say "this machine is three times as fast asthat one" is the best that can practically be done.Gulbrandsen, et al. Standards Track [Page 5]The only way the authors can see of getting a "better" load figure is asking a separate server when the client selects a server andcontacts it. For short-lived services an extra step in theconnection establishment seems too expensive, and for long-livedservices, the load figure may well be thrown off a minute after theconnection is established when someone else starts or finishes aheavy job.Note: There are currently various experiments at providing relativenetwork proximity estimation, available bandwidth estimation, andsimilar services. Use of the SRV record with such facilities, and in particular the interpretation of the Weight field when thesefacilities are used, is for further study. Weight is only intendedfor static, not dynamic, server selection. Using SRV weight fordynamic server selection would require assigning unreasonably shortTTLs to the SRV RRs, which would limit the usefulness of the DNScaching mechanism, thus increasing overall network load anddecreasing overall reliability. Server selection via SRV is onlyintended to express static information such as "this server has afaster CPU than that one" or "this server has a much better networkconnection than that one".The Port numberCurrently, the translation from service name to port number happensat the client, often using a file such as /etc/services.Moving this information to the DNS makes it less necessary to update these files on every single computer of the net every time a newservice is added, and makes it possible to move standard services out of the "root-only" port range on unix.Usage rulesA SRV-cognizant client SHOULD use this procedure to locate a list of servers and connect to the preferred one:Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,QTYPE=SRV.If the reply is NOERROR, ANCOUNT>0 and there is at least oneSRV RR which specifies the requested Service and Protocol inthe reply:If there is precisely one SRV RR, and its Target is "."(the root domain), abort.Gulbrandsen, et al. Standards Track [Page 6]Else, for all such RR’s, build a list of (Priority, Weight, Target) tuplesSort the list by priority (lowest number first)Create a new empty listFor each distinct priority levelWhile there are still elements left at this prioritylevelSelect an element as specified above, in thedescription of Weight in "The format of the SRVRR" Section, and move it to the tail of the newlistFor each element in the new listquery the DNS for address records for the Target oruse any such records found in the Additional Datasection of the earlier SRV response.for each address record found, try to connect to the(protocol, address, service).elseDo a lookup for QNAME=target, QCLASS=IN, QTYPE=Afor each address record found, try to connect to the(protocol, address, service)Notes:- Port numbers SHOULD NOT be used in place of the symbolic serviceor protocol names (for the same reason why variant names cannotbe allowed: Applications would have to do two or more lookups).- If a truncated response comes back from an SRV query, the rulesdescribed in [RFC 2181] shall apply.- A client MUST parse all of the RR’s in the reply.- If the Additional Data section doesn’t contain address recordsfor all the SRV RR’s and the client may want to connect to thetarget host(s) involved, the client MUST look up the addressrecord(s). (This happens quite often when the address recordhas shorter TTL than the SRV or NS RR’s.)Gulbrandsen, et al. Standards Track [Page 7]- Future protocols could be designed to use SRV RR lookups as themeans by which clients locate their servers.Fictional exampleThis example uses fictional service "foobar" as an aid inunderstanding SRV records. If ever service "foobar" is implemented,it is not intended that it will necessarily use SRV records. This is (part of) the zone file for , a still-unused domain:$ORIGIN .@ SOA . . (1995032001 3600 3600 604800 86400 )NS .NS .NS .; foobar - use old-slow-box or new-fast-box if either is; available, make three quarters of the logins go to; new-fast-box._foobar._tcp SRV 0 1 9 .SRV 0 3 9 .; if neither old-slow-box or new-fast-box is up, switch to; using the sysdmin’s box and the serverSRV 1 0 9 .SRV 1 0 9 .server A 172.30.79.10old-slow-box A 172.30.79.11sysadmins-box A 172.30.79.12new-fast-box A 172.30.79.13; NO other services are supported*._tcp SRV 0 0 0 .*._udp SRV 0 0 0 .Gulbrandsen, et al. Standards Track [Page 8]In this example, a client of the "foobar" service in the"." domain needs an SRV lookup of"_foobar._." and possibly A lookups of "new-fast-." and/or the other hosts named. The size of the SRV reply is approximately 365 bytes:30 bytes general overhead20 bytes for the query string, "_foobar._."130 bytes for 4 SRV RR’s, 20 bytes each plus the lengths of "new- fast-box", "old-slow-box", "server" and "sysadmins-box" -"" in the query section is quoted here and doesn’tneed to be counted again.75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server", "." and "ns2" - again, "." is quoted and only needs to be counted once.120 bytes for the 6 address records (assuming IPv4 only) mentioned by the SRV and NS RR’s.IANA ConsiderationsThe IANA has assigned RR type value 33 to the SRV RR. No other IANA services are required by this document.Changes from RFC 2052This document obsoletes RFC 2052. The major change from thatprevious, experimental, version of this specification is that now the protocol and service labels are prepended with an underscore, tolower the probability of an accidental clash with a similar name used for unrelated purposes. Aside from that, changes are only intendedto increase the clarity and completeness of the document. Thisdocument especially clarifies the use of the Weight field of the SRV records.Security ConsiderationsThe authors believe this RR to not cause any new security problems.Some problems become more visible, though.- The ability to specify ports on a fine-grained basis obviouslychanges how a router can filter packets. It becomes impossibleto block internal clients from accessing specific externalservices, slightly harder to block internal users from runningunauthorized services, and more important for the routeroperations and DNS operations personnel to cooperate.- There is no way a site can keep its hosts from being referencedas servers. This could lead to denial of service.Gulbrandsen, et al. Standards Track [Page 9]- With SRV, DNS spoofers can supply false port numbers, as well ashost names and addresses. Because this vulnerability existsalready, with names and addresses, this is not a newvulnerability, merely a slightly extended one, with littlepractical effect.ReferencesSTD 2: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.RFC 1034: Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.RFC 1035: Mockapetris, P., "Domain names - Implementation andSpecification", STD 13, RFC 1035, November 1987.RFC 974: Partridge, C., "Mail routing and the domain system", STD14, RFC 974, January 1986.BCP 14: Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNSSpecification", RFC 2181, July 1997.RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network Services", BCP 17, RFC 2219, October 1997.BCP 14: Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.ARM: Armijo, M., Esibov, L. and P. Leach, "Discovering LDAPServices with DNS", Work in Progress.KDC-DNS: Hornstein, K. and J. Altman, "Distributing Kerberos KDC and Realm Information with DNS", Work in Progress.Gulbrandsen, et al. Standards Track [Page 10]AcknowledgementsThe algorithm used to select from the weighted SRV RRs of equalpriority is adapted from one supplied by Dan Bernstein.Authors’ AddressesArnt GulbrandsenTroll TechWaldemar Thranes gate 98BN-0175 Oslo, NorwayFax: +47 22806380Phone: +47 22806390EMail: arnt@troll.noPaul VixieInternet Software Consortium950 Charter StreetRedwood City, CA 94063Phone: +1 650 779 7001Levon EsibovMicrosoft CorporationOne Microsoft WayRedmond, WA 98052EMail: levone@Gulbrandsen, et al. Standards Track [Page 11]Full Copyright StatementCopyright (C) The Internet Society (2000). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked 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 ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Gulbrandsen, et al. Standards Track [Page 12]。
