https://www.dnswiki.cn/api.php?action=feedcontributions&feedformat=atom&user=YuDNS-WIKI - 用户贡献 [zh-cn]2026-11-05T16:14:56Z用户贡献MediaWiki 1.41.0https://www.dnswiki.cn/index.php?title=%E5%9B%BD%E5%AE%B6%E3%80%81%E6%88%98%E7%95%A5%E4%B8%8E%E9%80%9F%E5%BA%A6-%E4%B8%AD%E5%9B%BD%E7%94%B5%E4%BF%A1%E8%A1%8C%E4%B8%9A%E4%BA%92%E5%8A%A8%E5%8F%91%E5%B1%95%E5%8F%B2_(1871_-_%E8%87%B3%E4%BB%8A)&diff=223国家、战略与速度-中国电信行业互动发展史 (1871 - 至今)2025-06-25T15:22:37Z<p>Yu：创建页面，内容为“ = '''国家、战略与速度：中国电信行业多维度历史（1871年至今）''' = from dnswiki.cn == '''引言''' == 中国电信行业的发展史，是一部与国家命运紧密相连、由战略意志驱动、以惊人速度演进的宏大叙事。从19世纪末被迫开启的电报时代，到21世纪引领全球的5G浪潮，这条跨越150余年的轨迹，并非简单的技术迭代或市场演化，而是一场围绕主权、安全、发展…”</p>
<hr />
<div><br />
= '''国家、战略与速度：中国电信行业多维度历史（1871年至今）''' =<br />
from dnswiki.cn<br />
<br />
== '''引言''' ==<br />
中国电信行业的发展史，是一部与国家命运紧密相连、由战略意志驱动、以惊人速度演进的宏大叙事。从19世纪末被迫开启的电报时代，到21世纪引领全球的5G浪潮，这条跨越150余年的轨迹，并非简单的技术迭代或市场演化，而是一场围绕主权、安全、发展和竞争展开的持续博弈。本报告将从时间、技术和政策三个维度，系统梳理和剖析中国电信行业的历史脉络，揭示其在不同历史阶段的核心驱动力、关键转折点以及贯穿始终的深层逻辑。报告将论证，中国电信业从诞生之日起，就被赋予了超越商业的战略使命，其发展模式始终在国家主导与市场活力之间寻求一种独特的、动态的平衡。这种模式在早期表现为对国家安全的被动防御，在改革开放后演变为支撑经济增长的主动引擎，而在新世纪则升华为构筑数字社会和参与全球科技竞争的核心平台。理解这段历史，是洞察当代中国产业政策、科技战略乃至国家治理模式的关键。<br />
----<br />
<br />
== '''第一部分：中国电信业的黎明（1871–1949）：战略驱动的开端''' ==<br />
中国电信史的开篇并非源于商业创新或社会需求，而是在外力压迫下，出于国家主权和国防安全的考量而做出的被动反应。这一历史起点深刻地影响了中国电信业的基因，使其从诞生之初就带有强烈的国家战略色彩。这一时期，从抵制外来到主动自办，从官办到“官督商办”再回归官营的演变，奠定了此后一个多世纪国家主导行业发展的基本范式。<br />
<br />
=== '''1.1 外商主导的引入：大北电报公司的叩关''' ===<br />
19世纪下半叶，近代电信技术伴随着西方列强的全球扩张被引入中国。1871年，丹麦大北电报公司（Great Northern Telegraph Company）成为这一进程的开创者，也成为了中国电信主权受到挑战的最初象征 <sup>1</sup>。该公司铺设了从香港经上海至日本长崎的海底电缆，并于该年4月在上海设立了报房 <sup>2</sup>。<br />
<br />
值得注意的是，大北公司的业务开展是在未获清政府明确许可的情况下进行的。当时清政府严禁外国海缆登陆，但大北公司采取了变通手段，秘密将海缆沿黄浦江敷设至上海英租界内，并于1871年6月3日正式对外营业 <sup>4</sup>。这一举动绕开了清政府的管辖，成功地在中国的心脏地带建立了商业运营据点。此后，大北公司与英国大东电报公司达成协议，划分了在华的势力范围：上海以北归大北公司经营，香港至上海之间则由双方共同经营 <sup>3</sup>。<br />
<br />
外国公司未经许可在中国境内开展电信业务，深刻地刺激了清政府的统治精英。这种绕过主权管制的商业行为，在清政府官员眼中，无异于一种技术形式的侵略。它使得电信技术从一开始就与国家主权、领土完整的概念紧密绑定。这种由外部威胁催生的“被动现代化”心态，而非对商业机遇的主动追求，成为中国发展自主电信事业最原始、最强烈的动因。此后百余年间，对“自主可控”的执着追求，其思想源头便在于此。<br />
<br />
=== '''1.2 清政府的回应：从抵制到为国防而战略性接纳''' ===<br />
面对电报这一“奇技淫巧”，清政府最初的态度是抵制和疑虑。反对的理由多种多样，既有迷信层面的担忧，如架设电线会破坏“风水”；也有社会层面的顾虑，认为电报会冲击沿用千年的驿站体系，导致大量驿夫失业，引发社会动荡 <sup>5</sup>。更深层次的则是战略上的恐惧：将关乎军国大事的信息命脉交予“洋人”之手，无异于自缚手脚，机密难保 <sup>6</sup>。<br />
<br />
然而，严酷的军事现实迅速改变了清政府的看法。少数具有远见的官员开始认识到电报在军事指挥和国防建设中的巨大价值。福建巡抚丁日昌是其中的先行者。他力主海防建设，认为电报自主权对国家至关重要。1876年，他通过交涉，从大北公司手中收购了福州至马尾的电报线路，使其成为中国第一条自主经营的电报线 <sup>4</sup>。<br />
<br />
真正的转折点来自于洋务运动的领袖李鸿章。他亲身体会到电报在处理边疆危机（如中俄伊犁争端）和战争（如中法战争）中的巨大优势，称其“神速”的通信能力“于用兵之道，必以神速为贵” <sup>5</sup>。在1885年的中法战争中，他得意地表示：“将帅人告军谋，朝廷发纵指示，皆得相机立断，无少隔阂。中国自古用兵未有如此之神速者” <sup>8</sup>。这种由军事需求驱动的认知转变，是清政府接纳电报技术的关键。<br />
<br />
这一转变清晰地揭示了中国早期电信业的根本属性。它并非作为服务社会大众的公用事业而生，而是作为强化国家机器、巩固国防的战略工具被引入。其最初的网络规划，如连接天津与大沽口炮台，再延伸至京沪，其首要目标是服务于军事调动和政令传达 <sup>5</sup>。从传统的驿站到电报，本质上是国家信息控制体系的一次技术升级，用“电旨”、“电奏”取代了日行数百里的文书传递 <sup>11</sup>。这种“国家优先、军用为本”的顶层设计，为中国电信业的发展烙下了深刻的印记。<br />
<br />
=== '''1.3 政策与管理演进：“官督商办”模式的诞生与回归''' ===<br />
在确立了自办电报的战略方针后，资金问题成为最大的障碍。晚清政府财政拮据，无力承担大规模基础设施建设的巨额开支 <sup>9</sup>。正是在这种背景下，一种极具中国特色的制度创新——“官督商办”模式应运而生。<br />
<br />
# '''官办起步（1880年）：''' 1880年，李鸿章奏请设立津沪电报线，并在天津成立了津沪电报总局，这是一个纯粹的官办机构，旨在完成国家战略任务 <sup>5</sup>。<br />
# '''转向官督商办（1882年）：''' 由于建设资金严重不足，李鸿章一方面从自己的淮军军费中垫款支持，另一方面，在1882年，他授意盛宣怀将电报总局改制为“官督商办”，向社会招募商股 <sup>5</sup>。这一模式下，企业由商人出资经营，但业务方向和高层人事任免仍受政府监督。这是一种务实的妥协，利用民间资本的活力和效率来完成国家急需的基础设施建设，同时确保政府的最终控制权。<br />
# '''回归官营（1902-1908年）：''' 官督商办模式下的电报业务取得了巨大成功，利润丰厚，网络也迅速扩张 <sup>12</sup>。此时，国家对电信业的看法再次转变。以袁世凯为代表的官员认为，“电务为军国要政，应归官办”，不能长期游离于政府的直接控制之外 <sup>12</sup>。于是，从1902年起，清政府开始推动电报业务的国有化进程。至1908年，所有商股被清政府赎回，电报业务完全回归官办，并统一归于新成立的邮传部下属的电政局管理 <sup>12</sup>。<br />
<br />
这一“官办 -> 官督商办 -> 官办”的循环，揭示了中国电信业发展中一个反复出现的模式：当国家有战略意图但缺乏执行能力（尤其是资金）时，会阶段性地向市场和民间力量开放，以换取快速发展；而当该行业发展成熟、利润丰厚且战略地位日益重要时，国家又会倾向于加强直接控制，将其收归国有。这一模式在此后一个世纪的电信改革中仍将反复上演。<br />
<br />
=== '''1.4 早期技术格局：电报、电话与无线电''' ===<br />
在清末民初时期，中国的电信技术版图呈现出多种技术并存但发展不均的局面。<br />
<br />
* '''电报：''' 作为该时期的主导技术，电报网络在“官督商办”模式的推动下迅速扩张。到1911年清朝覆灭前，全国已有176个府级行政单位接通了电报，初步形成了覆盖全国主要城市的通信网络 <sup>10</sup>。<br />
* '''电话：''' 电话的引入同样由外商主导。1882年，大北电报公司在上海设立了中国第一个电话交换所，采用的是需要话务员手动接线的人工交换机 <sup>15</sup>。中国自办的电话局直到1900年才在南京出现 <sup>16</sup>。与电报相比，电话的建设成本更高，技术更复杂，因此发展缓慢，长期局限于少数大城市的富裕阶层和商业机构。<br />
* '''无线电：''' 无线电报技术在20世纪初进入中国，北京于1913年建立了第一个无线电报局 <sup>17</sup>。在民国时期，尤其是在抗日战争和解放战争期间，无线电通信因其无需铺设线路、机动灵活的特点，发挥了至关重要的军事和政治作用。中国共产党在极其艰苦的条件下，从上海的秘密电台和长征路上的“半部电台”起家，建立了自己独立的无线通信体系，为革命的胜利提供了关键保障 <sup>2</sup>。<br />
* '''融入国际体系：''' 随着国内电信网络的发展，中国也开始逐步融入国际电信体系。1920年，中国加入了万国电报联盟（后来的国际电信联盟），标志着中国的电信网络开始与世界接轨 <sup>17</sup>。<br />
<br />
----<br />
<br />
== '''第二部分：计划经济下的奠基（1949–1978）''' ==<br />
中华人民共和国成立后，电信业进入了一个全新的发展阶段。在“一穷二白”的基础上，新政权以强大的国家意志，通过高度集中的“邮电合一”体制，开始了艰苦的奠基工作。这一时期，电信业被完全纳入国家计划经济体系，其发展目标、资源配置和组织架构都服务于国家建设和巩固政权的需要。虽然在技术上与世界先进水平的差距逐渐拉大，但它为后来的改革开放奠定了一个统一的、全国性的组织和网络基础。<br />
<br />
=== '''2.1 政策与体制：“邮电合一”的高度集权''' ===<br />
1949年11月1日，中央人民政府邮电部正式成立，成为新中国电信事业的主管机构 <sup>19</sup>。为实现对国家通信命脉的绝对控制和高效管理，新政权迅速建立了一套高度集中的管理体制。<br />
<br />
1951年，邮政和电信两大业务被正式统一纳入邮电部管理，确立了影响深远的“邮电合一”体制 <sup>19</sup>。在这种模式下，邮电部集政府监管与企业运营于一身，即“政企合一”。从中央到地方，建立了一套垂直管理的邮电局体系，统一负责信件、报刊、电报、电话等所有通信业务。<br />
<br />
这种体制的建立，其首要目标是服务于新政权的巩固和国家一体化建设。在经历了百年动荡和战争之后，将物理通信（邮政）和电子通信（电信）整合在一个强大的中央部委之下，形成了一个强有力的工具，用于政令下达、信息控制和国家动员。效率和效益在当时并非首要考量，确保通信网络完全服务于国家政治和经济计划才是核心。<br />
<br />
然而，这一高度集中的体制也并非一成不变。在随后的政治运动中，其组织架构经历了多次动荡调整。例如，1958年“大跃进”时期，县以下的邮电业务被下放到地方交通部门管理，打破了垂直体系 <sup>19</sup>。1967年“文革”期间，电信业务实行军事管制，而邮政业务则归地方管理 <sup>19</sup>。1969年，邮电部甚至一度被撤销，分拆为邮政总局和电信总局，直到1973年才恢复合并 <sup>7</sup>。这些频繁的、由政治因素驱动的变革表明，电信部门在当时并非一个独立的经济产业，而是国家机器的一个组成部分，其组织形态完全服从于当时的政治需要。<br />
<br />
=== '''2.2 技术基础：在封闭中缓慢起步''' ===<br />
新中国成立之初，电信基础设施极为薄弱。1949年，全国电话普及率不足0.05%，电话用户总数仅26万户，被外国人形容为“几乎没有电话的国家” <sup>16</sup>。在外部封锁和内部资源匮乏的双重压力下，中国走上了一条艰难的自力更生发展之路。<br />
<br />
这一时期的技术发展重点是构建连接全国各大城市的基础通信网络，并努力实现关键设备的国产化 <sup>23</sup>。<br />
<br />
* '''交换技术：''' 电话交换机的国产化是重中之重。在苏联的援助下，中国于1949年启动了对“纵横制”（Crossbar）自动电话交换机的研制工作。纵横制交换机是当时较为先进的机电式自动交换机。经过近十年的努力，1959年，由上海电信研究所等单位联合研制的第一台国产1000门纵横制自动电话交换机在上海吴淞电话局成功开通使用 <sup>15</sup>。这是中国电信技术自主研发的一个重要里程碑，但值得注意的是，纵横制技术在西方国家早已成熟，中国的这一突破实际上是在追赶已经落后的技术。<br />
* '''传输技术：''' 在传输网络方面，主要依靠铺设国产电缆和建设微波通信干线。微波通信因其建设速度快、投资相对较低的优点，成为连接广大地域和复杂地形的重要手段。从20世纪50年代末开始，中国启动了微波通信系统的研究，并在70年代建成了多条960路微波干线，如京-沪-杭线路，能够传输电话、电视节目和传真等业务 <sup>23</sup>。<br />
<br />
在封闭环境下坚持自力更生，虽然培养了一定的本土研发和制造能力，但也付出了沉重的代价。由于与世界主流技术发展脱节，中国的通信技术水平与西方国家的差距被迅速拉大。当西方国家在60、70年代开始迈向电子交换和数字通信时代时，中国仍停留在机电式的纵横制时代。到1978年改革开放前夕，中国的电信技术装备整体上比发达国家落后了二三十年 <sup>26</sup>。全国电话普及率仅为0.38% <sup>16</sup>，通信能力的严重不足，形成了一个巨大的“电信赤字”。这种落后局面，被形象地描述为“外商急、局长苦、市长催、百姓怒” <sup>27</sup>，成为制约国民经济发展的巨大瓶颈，也为80年代电信业的全面改革埋下了伏笔。<br />
----<br />
<br />
== '''第三部分：改革开放的跨越式发展（1978–1998）''' ==<br />
1978年开启的改革开放，将中国电信业从长期的封闭和缓慢发展中解放出来，带入了一个前所未有的高速增长时期。面对通信能力严重滞后于经济发展需求的尖锐矛盾，决策层果断调整政策，以“引进、消化、吸收、创新”的思路，大胆拥抱国外先进技术和市场机制。这二十年，是中国电信业实现技术上“三步并作一步走”的跨越式发展时期，也是从完全垄断走向有限竞争的体制改革破冰时期。<br />
<br />
=== '''3.1 政策转向：“十六字方针”与“三步走”改革''' ===<br />
80年代，打电话难、装电话更难成为普遍的社会问题，严重制约了经济活动和对外开放。为了打破邮电部一家独揽、独资建设的僵局，国家出台了一系列关键政策，为电信业的大发展松绑。<br />
<br />
* '''“十六字方针”：''' 1988年，国务院明确提出了“统筹规划、条块结合、分层负责、联合建设”的方针 <sup>20</sup>。这一政策的核心是打破邮电部对电信建设的资金和权力垄断，允许地方政府、其他部委乃至社会力量参与投资和建设通信设施。这极大地调动了各方积极性，形成了全社会办通信的合力，有效解决了长期困扰电信发展的资金短缺问题。<br />
* '''“三步走”改革蓝图：''' 同年，国务院为邮电体制改革指明了方向，提出了分阶段、渐进式的“三步走”战略 <sup>20</sup>。第一步，实现邮电物资等辅助性机构的政企分开；第二步，逐步实现邮政和电信业务的独立核算；第三步，在条件成熟时，自上而下地实现邮政与电信的彻底分营和政企分开。这个路线图体现了中国改革“摸着石头过河”的审慎风格，它为未来十年的重大体制变革提供了顶层设计和思想准备。<br />
* '''开放增值业务：''' 1993年，在建立社会主义市场经济体制的背景下，国务院正式批准向社会放开无线寻呼、800MHz集群电话、计算机信息服务等九项电信增值业务，首次在电信领域引入了市场竞争 <sup>20</sup>。<br />
<br />
这一系列政策的转变，本质上是一种务实的放权让利。中央政府和邮电部认识到，仅凭自身力量无法满足经济发展对通信基础设施的爆炸性需求 <sup>27</sup>。通过“十六字方针”进行资金和建设权的“去中心化”，通过“三步走”战略规划管理和运营权的逐步分离，成功地为电信业的超常规发展注入了强大的动力。<br />
<br />
=== '''3.2 技术革命（一）- 交换机：从“七国八制”到“巨大中华”的崛起''' ===<br />
80年代初，为了迅速改变电话网络落后的面貌，中国采取了“拿来主义”的策略，大规模引进国外的程控电话交换机。这导致了所谓的“七国八制”局面——来自美国、加拿大、瑞典、德国、比利时、法国、日本七个国家的八种不同制式的交换机，同时在中国市场上存在 <sup>30</sup>。这虽然快速提升了网络的自动化水平，但也使得中国的电信市场完全被外商控制，且网络维护极其复杂。<br />
<br />
正是在这种背景下，中国本土的通信设备制造业开始了艰难的崛起之路，并成功上演了一场“农村包围城市”的逆袭。<br />
<br />
* '''农村市场的机遇：''' 国际巨头们主要聚焦于利润丰厚的城市市场，对于投资回报率低、条件艰苦的广大农村市场兴趣不大。这为刚刚起步的中国本土企业提供了一个宝贵的市场空隙和“练兵场” <sup>30</sup>。<br />
* '''本土企业的突破：'''<br />
<br />
* 以'''华为'''和'''中兴'''为代表的一批民营科技企业，最初通过代理或研发小容量的用户交换机起家。他们敏锐地抓住了农村市场的需求，推出了性价比高、适应性强的农话交换机 <sup>30</sup>。<br />
* 1993年，华为成功研发出C&C08万门数字程控交换机，这是一个里程碑式的产品，标志着国产设备在技术上达到了与国外厂商相抗衡的水平 <sup>31</sup>。<br />
* 1995年，中兴也成功推出了自主研发的ZXJ10大容量局用数字程控交换机，并获得了邮电部的入网许可 <sup>30</sup>。<br />
<br />
* '''“巨大中华”的形成：''' 华为、中兴，加上拥有军方和邮电部背景的巨龙、大唐，共同构成了“巨大中华”的国产设备商阵营 <sup>7</sup>。他们凭借成本优势、灵活的服务和对本土市场的深刻理解，首先在农村市场站稳脚跟，然后逐步向城市市场渗透，最终在90年代末成功打破了“七国八制”的垄断格局，实现了国产设备在本土市场的主导。<br />
<br />
这一过程是中国“以市场换技术”战略的经典案例。一方面，开放市场引进了急需的先进技术，完成了网络的初步现代化；另一方面，利用国内市场的巨大规模和城乡二元结构，为本土企业创造了受保护的成长空间，最终培育出了具备国际竞争力的国家冠军。<br />
<br />
=== '''3.3 技术革命（二）- 传输骨干网：光纤的跨越''' ===<br />
与交换技术的引进和追赶同步，中国的传输网络也经历了一场深刻的革命。<br />
<br />
* '''光纤通信的自主研发：''' 中国的光纤通信研究起步并不晚。1976年，在世界光纤通信尚未大规模实用化时，武汉邮电科学研究院就成功拉制出中国第一根具有实用价值的光纤 <sup>33</sup>。1982年在武汉建成的“八二工程”，是中国第一条实用化的光纤通信线路，标志着中国光纤通信进入实用阶段 <sup>34</sup>。<br />
* '''“八纵八横”光缆网：''' 进入90年代，决策层意识到光纤是未来通信网络的基础，下决心大力发展光纤通信。国家启动了宏伟的“八纵八横”国家光缆骨干网建设计划。该工程提前两年于1998年全面建成，形成了一个覆盖全国、技术先进、容量巨大的光纤传输网络 <sup>25</sup>。<br />
* '''实现技术跨越：''' 这一大规模的战略性投资，使中国的长途传输网直接跳过了许多西方国家经历的铜缆数字微波阶段，一步到位地构建了以光纤为基础的现代化网络。这为21世纪互联网和移动通信的爆发式增长提供了坚实的基础设施保障。<br />
<br />
=== '''3.4 垄断的终结：中国联通与吉通的诞生''' ===<br />
到90年代初，尽管电信业发展迅速，但邮电部及其下属的中国电信仍然是唯一的网络运营商，垄断带来的服务差、价格高等问题日益突出。为了引入竞争，激活市场，政府采取了关键性的举措。<br />
<br />
* '''中国联通（China Unicom）的成立：''' 1994年7月19日，在时任电子工业部部长胡启立等人的大力推动下，由电子部联合铁道部、电力部等实力雄厚的部委共同组建了中国联合通信有限公司 <sup>20</sup>。联通的成立是中国电信业改革的标志性事件，它被赋予了打破中国电信垄断的使命，首次在中国电信市场形成了双寡头竞争的局面。<br />
* '''吉通（Jitong）的成立：''' 同年1月，为服务于国家“三金工程”（金桥、金关、金卡），吉通通信有限公司成立，其核心任务是建设和运营“金桥工程”——国家公用经济信息网，意在与中国电信的ChinaNet（中国公用计算机互联网）展开竞争 <sup>20</sup>。<br />
<br />
然而，这种初期的竞争是一种精心设计的“非对称竞争”。联通和吉通作为新进入者，无论在网络资源、资金实力还是运营经验上，都与强大的中国电信相去甚远 <sup>41</sup>。政府的目的并非要创造一个完全自由竞争的市场，而是通过引入一个（或几个）“可控”的竞争者，来刺激和鞭策垄断的 incumbent，以达到提升服务、降低资费的政策目标，同时又不至于让市场失序。这种“鲶鱼效应”式的改革思路，为下一阶段更彻底的行业重组拉开了序幕。<br />
----<br />
<br />
== '''第四部分：重组与竞争的年代（1998–2008）''' ==<br />
这是中国电信史上最为动荡和深刻变革的十年。在强大的国家意志主导下，原有的“邮电合一”垄断巨头被一系列行政“手术”彻底拆解和重塑。其核心逻辑是，通过结构性的重组，人为地创造出一个多方制衡的竞争格局。这一系列改革的高潮，是形成了电信、网通、移动、联通、铁通、卫通、吉通并存的“七雄争霸”局面。<br />
<br />
=== '''4.1 大分离（1998-2002）：三次关键的体制改革''' ===<br />
这一系列大刀阔斧改革的“操刀手”，是1998年新成立的'''信息产业部（MII）'''。该部由原邮电部和电子工业部合并而成，整合了行业管理、规划和监管职能，成为了一个强有力的、独立的行业监管者。其首要任务，就是执行国务院确定的“政企分开、邮电分营、打破垄断”的改革方针 <sup>20</sup>。<br />
<br />
'''改革一：邮电分家（1998年）'''<br />
<br />
1998年，历史悠久的邮电部被正式撤销。邮政业务被剥离，成立了国家邮政局；电信监管职能划归新成立的信息产业部；而运营职能则完全交由中国邮电电信总局（即中国电信）承担 <sup>20</sup>。这次分离，彻底结束了“邮电合一”的历史，实现了监管机构与运营企业的分离，是电信业走向市场化的关键第一步。<br />
<br />
'''改革二：移动业务剥离，中国移动诞生（1999-2000年）'''<br />
<br />
为打破中国电信在所有业务领域的全面垄断，并促进移动通信市场的专业化发展，信息产业部策划了第二次重大重组。1999年，原中国电信的移动通信业务（主要是GSM网络和用户）、卫星业务和寻呼业务被整体剥离 <sup>19</sup>。<br />
<br />
* '''移动业务'''：以此为基础，于2000年4月20日正式组建了'''中国移动通信集团公司（中国移动）'''，成为一家专注于移动通信的运营商 <sup>7</sup>。<br />
* '''寻呼业务'''：当时已显颓势的全国寻呼业务（国信寻呼）被并入了中国联通 <sup>19</sup>。<br />
* '''卫星业务'''：后来发展成为中国卫通。<br />
<br />
这次“纵向切分”，使得中国电信成为一家只经营固网和数据通信业务的公司，而市场上则出现了一个强大的纯移动业务竞争者——中国移动。<br />
<br />
'''改革三：“南北拆分”（2001-2002年）'''<br />
<br />
在剥离了移动业务后，中国电信在固网和宽带市场仍然占据绝对垄断地位。为了在固网领域也引入有效竞争，信息产业部实施了迄今为止最激进的一次重组——“南北拆分” <sup>20</sup>。<br />
<br />
* '''拆分方案'''：以长江为界，将原中国电信按地域一分为二。<br />
<br />
* '''北方部分'''：北京、天津、河北、山西、内蒙古、辽宁、吉林、黑龙江、河南、山东这10个省（区、市）的电信资产，与此前成立的中国网络通信有限公司（俗称“小网通”）以及经营不善的吉通公司合并，组建了新的'''中国网络通信集团公司（中国网通）''' <sup>19</sup>。<br />
* '''南方部分'''：其余21个省（区、市）的电信资产，则保留“'''中国电信集团公司'''”的名称，成为新的中国电信 <sup>19</sup>。<br />
* 全国长途骨干传输网也按大约30%和70%的比例，分别划归中国网通和中国电信 <sup>19</sup>。<br />
<br />
这次“横向切分”的目标，是在中国固网市场人为地制造出两个实力相当、南北割据但又可以互相进入对方市场竞争的巨头，从而彻底打破固网领域的垄断。<br />
<br />
这些改革清晰地展示了中国政府的政策思路：竞争并非市场自发形成，而是可以通过顶层设计“工程化”地构建出来。从监管与运营分离，到不同业务分离，再到同类业务按地域拆分，每一步都旨在精确地调整市场结构，以达到一个多方制衡的、被管理者认为最优的“有效竞争”状态。<br />
{| class="wikitable"<br />
|时期<br />
|核心机构<br />
|性质/模式<br />
|核心职责<br />
|-<br />
|1880-1902年<br />
|中国电报总局<br />
|官办 -> 官督商办<br />
|建设和运营全国电报网络<br />
|-<br />
|1906-1912年<br />
|邮传部电政司<br />
|官办<br />
|统一管理全国电政<br />
|-<br />
|1949-1998年<br />
|邮电部 (MPT)<br />
|政企合一<br />
|统一规划、建设、运营和监管全国邮政与电信业务<br />
|-<br />
|1998-2008年<br />
|信息产业部 (MII)<br />
|独立的行业监管机构<br />
|制定行业政策，实施电信体制改革，发放牌照，监管市场竞争<br />
|}<br />
<br />
=== '''4.2 “七雄争霸”的格局与互联网的兴起''' ===<br />
经过1998-2002年的一系列重组，到2002年初，中国电信市场形成了前所未有的多元化竞争格局，史称“七雄争霸” <sup>20</sup>。这七家运营商均为国有企业，但背景和实力各异：<br />
<br />
* '''三大巨头'''：中国电信、中国移动、中国联通。<br />
* '''四大新军'''：中国网通、中国铁通（原铁道部通信网络）、中国卫通（卫星通信）、吉通（数据通信）。<br />
<br />
然而，这个看似热闹的格局实则严重失衡。中国移动在移动市场一家独大，而中国电信和中国网通则分别在南方和北方的固网市场占据绝对优势，形成了“南电信，北网通”的局面 <sup>7</sup>。其他几家运营商规模较小，难以构成实质性威胁。<br />
<br />
这一时期，恰逢中国互联网的第一次浪潮。公众接入互联网主要通过两大网络：<br />
<br />
* '''ChinaNet (163网)'''：由原中国电信建设，是中国最早、最大的公用计算机互联网 <sup>55</sup>。<br />
* '''169网'''：最初是作为中国公众多媒体通信网，一个内部网（Intranet）来建设的，后来与163网物理并网，提供不同的接入服务 <sup>57</sup>。<br />
<br />
“南北拆分”的一个重要且非预期的后果，是造成了互联网骨干网的割裂。163品牌归了南方的新电信，而169品牌（后改号）则归了北方的网通 <sup>58</sup>。这导致了严重的“南北互联互通”问题：身处北方的网通用户访问托管在南方电信机房的网站速度缓慢，反之亦然 <sup>59</sup>。这种因行政分割造成的网络瓶颈，影响了用户体验，也增加了企业的运营成本，其后遗症持续多年。<br />
<br />
=== '''4.3 技术战场的博弈：GSM vs CDMA 与“小灵通”现象''' ===<br />
在具体的业务和技术层面，这一时期的竞争同样激烈。<br />
<br />
* '''2G标准之争'''：在移动通信领域，中国移动和中国联通都运营着全球主流的GSM网络。为了形成差异化竞争，并引入技术制衡，2002年，中国联通正式开通了其CDMA网络，使中国进入了GSM与CDMA两大2G标准并存竞争的时代 <sup>7</sup>。<br />
* '''“小灵通”（PHS）的异军突起'''：1999年的重组禁止了中国电信和后来的中国网通经营移动业务，使其眼睁睁看着移动市场利润飙升而无法进入。为了绕开这一政策限制，两大固网巨头引入了日本的PHS（Personal Handy-phone System）技术，并将其包装为“无线市话”，取名“小灵通” <sup>7</sup>。<br />
<br />
“小灵通”利用市话网络，提供有限的移动性，但资费远低于当时的手机。凭借巨大的价格优势，“小灵通”在中国市场获得了意想不到的巨大成功，用户一度接近1亿。这一现象深刻地反映了当时电信市场的结构性矛盾：<br />
<br />
# 它是固网运营商在严格的监管限制下，为进入移动市场而进行的“擦边球”式创新。<br />
# 它的火爆，暴露了当时移动通信资费过高，市场存在巨大的低端需求未被满足。<br />
# 它对中国移动和中国联通构成了巨大的价格压力，迫使其下调资费，客观上惠及了消费者。<br />
# 最终，“小灵通”的成功也凸显了固网和移动业务被人为割裂的不可持续性，为2008年最终走向全业务运营埋下了伏笔。<br />
<br />
----<br />
<br />
== '''第五部分：移动互联网与全业务竞争时代（2008年至今）''' ==<br />
进入2008年，中国电信业再次迎来历史性的转折。为迎接3G时代的到来，并解决此前改革遗留的市场结构性问题，国家主导了新一轮的电信重组，将“七雄”整合为三家势均力敌的全业务运营商。从此，行业进入了以移动互联网为核心，技术代际（3G/4G/5G）竞争为主线，并逐步向云计算、产业互联网等新领域拓展的全新发展阶段。<br />
<br />
=== '''5.1 2008年大重组：为3G时代打造三足鼎立格局''' ===<br />
在3G牌照发放前夜，信息产业部（此时已并入新组建的工业和信息化部）、国家发改委和财政部联合发布公告，启动了第四次电信体制改革。其核心目标是改变中国移动一家独大的失衡局面，打造三家规模和实力相当、拥有固网和移动全业务牌照的运营商，以形成更均衡、更有效的竞争格局 <sup>60</sup>。<br />
<br />
具体的重组方案如下 <sup>62</sup>：<br />
<br />
* '''新中国联通的诞生'''：原'''中国联通'''剥离其CDMA网络后，其剩余的GSM网络业务与原'''中国网通'''的固网业务合并，组建了新的'''中国联合网络通信集团有限公司''' <sup>48</sup>。<br />
* '''中国电信的全业务转型'''：原'''中国电信'''在保留其固网业务的基础上，斥资1100亿元人民币收购了原中国联通的'''CDMA网络及用户'''，从而获得了移动业务牌照，成为全业务运营商。同时，它还并入了'''中国卫通'''的基础电信业务 <sup>63</sup>。<br />
* '''中国移动的固网补强'''：保持移动业务主体不变，同时合并了规模最小的'''中国铁通'''，获得了固网业务牌照和网络资源 <sup>63</sup>。<br />
<br />
这次重组的时机选择，深刻揭示了中国电信业“政策先行、市场跟进”的特点。它并非市场演化的自然结果，而是在3G技术标准分配前，由国家先行设计好的市场结构。政府首先确定了“谁”是未来的玩家，然后才决定给他们分配“什么”样的技术牌照。这确保了即将到来的3G时代，有三家实力均衡的“国家队”来承接不同的技术标准，从而实现国家在产业平衡和技术自主两个层面的战略意图。<br />
{| class="wikitable"<br />
|重组事件<br />
|核心行动<br />
|重组后结构<br />
|政策目标<br />
|-<br />
|'''1999年移动剥离'''<br />
|从原中国电信中剥离移动、卫星、寻呼业务<br />
|成立中国移动（纯移动运营商）；中国电信（纯固网运营商）<br />
|在移动通信领域引入专业化竞争；打破综合性垄断<br />
|-<br />
|'''2002年南北拆分'''<br />
|将原中国电信按地域划分为南北两部分<br />
|北方10省资产与小网通、吉通合并成中国网通；南方21省保留为新中国电信<br />
|打破固网本地网的自然垄断，在固网领域引入有效竞争<br />
|-<br />
|'''2008年三合一重组'''<br />
|联通与网通合并；电信收购联通C网；移动合并铁通<br />
|形成三家拥有移动和固网牌照的全业务运营商：新移动、新电信、新联通<br />
|建立均衡的竞争格局，为3G牌照发放和全业务竞争做准备<br />
|}<br />
<br />
=== '''5.2 3G的博弈（2009年）：TD-SCDMA的战略使命''' ===<br />
2009年1月，三张3G牌照正式发放，其分配方案充满了战略考量 <sup>77</sup>：<br />
<br />
* '''中国移动'''：获得了中国自主研发但技术上最不成熟的'''TD-SCDMA'''标准。<br />
* '''中国联通'''：获得了技术最成熟、全球产业链最完善的'''WCDMA'''标准。<br />
* '''中国电信'''：获得了技术同样成熟但产业链规模次之的'''CDMA2000'''标准。<br />
<br />
这种非对称的牌照分配，对三家运营商的命运产生了深远影响：<br />
<br />
* 对于'''中国移动'''，承担TD-SCDMA是一项沉重的政治任务。尽管作为市场领导者，它却被分配了体验最差的技术标准。为了建设和推广TD-SCDMA网络，中国移动投入了超过2000亿元的巨额资金，但网络速度慢、终端选择少等问题，使其在3G时代的用户体验和品牌形象上备受打击，市场领先优势受到侵蚀 <sup>79</sup>。<br />
* 对于'''中国联通'''，WCDMA牌照是其扭转颓势的“王牌”。凭借成熟的技术和丰富的终端（尤其是率先引入苹果iPhone），联通在3G时代成功吸引了大量高端用户，市场竞争力显著增强。<br />
* 对于'''中国电信'''，通过运营CDMA2000网络，顺利地将其庞大的“小灵通”用户和固网用户转化为3G用户，实现了移动业务的平稳起步和快速发展。<br />
<br />
这次牌照分配清晰地揭示了国家将技术标准作为调控市场和推行产业政策的工具。其双重目标显而易见：其一，通过“抑强扶弱”的方式，削弱中国移动的绝对优势，为联通和电信创造追赶的机会，以维持市场竞争的平衡；其二，也是更重要的，是利用中国移动庞大的体量和市场地位，强行催生和培育一个自主知识产权的3G标准及其产业链 <sup>82</sup>。尽管TD-SCDMA本身在商业上并不成功，但它所积累的技术、人才和产业经验，为后来中国主导的4G标准TD-LTE的成功铺平了道路。这是一种典型的以短期商业利益（中国移动的利润和用户体验）换取长期国家战略利益（掌握核心技术标准）的抉择。<br />
<br />
=== '''5.3 4G的竞速（2013年）：TD-LTE优先的政策倾斜''' ===<br />
进入4G时代，牌照发放的策略发生了180度大转弯，政策的钟摆从“遏制”中国移动转向了“扶持”。<br />
<br />
* '''分步发牌'''：<br />
<br />
* '''2013年12月'''，工信部向三家运营商同时发放了'''TD-LTE'''牌照 <sup>83</sup>。<br />
* 直到一年多以后的'''2015年2月'''，才向中国电信和中国联通发放了它们更为期待的'''FDD-LTE'''牌照 <sup>83</sup>。<br />
<br />
这种“TD-LTE优先”的策略，极大地影响了4G市场的竞争格局：<br />
<br />
* '''中国移动'''获得了巨大的先发优势。由于TD-LTE是TD-SCDMA的平滑演进技术，中国移动可以利用其庞大的3G基站进行快速、低成本的升级，从而迅速建成了覆盖全国的4G网络，一举扭转了3G时代的颓势，重新巩固了市场霸主地位 <sup>85</sup>。<br />
* '''中国联通和中国电信'''的自然演进路径是FDD-LTE。在没有获得FDD-LTE正式牌照的一年多时间里，它们只能以“混合组网试验”的名义进行有限的网络建设，4G发展步伐受到严重掣肘，眼睁睁看着中国移动抢占市场先机 <sup>83</sup>。<br />
<br />
从3G的“抑强扶弱”到4G的“扶强扶优”，监管政策的巨大转变，再次凸显了其高度的战略性和灵活性。4G时代的首要政策目标，是确保中国主导的TD-LTE标准取得全球性的成功。将这张牌照优先交给实力最强、动力最足的中国移动，并为其创造最优越的竞争环境，是实现这一国家战略目标的必然选择。这表明，中国的产业政策并非僵化地支持或打压某家企业，而是动态地利用监管工具，来服务于不同时期最重要的国家战略目标。<br />
<br />
=== '''5.4 5G的引领（2019年）：新玩家与新融合''' ===<br />
在从“1G空白、2G跟随、3G突破、4G同步”的一路追赶后，中国在5G时代首次站到了世界前列，成为全球5G标准的主要贡献者和最大规模网络的建设者 <sup>26</sup>。<br />
<br />
2019年6月6日，工信部正式发放5G商用牌照，比原计划提前了近一年 <sup>90</sup>。获得牌照的除了三大传统运营商外，还增加了一个新的玩家——<br />
<br />
'''中国广播电视网络有限公司（中国广电）''' <sup>90</sup>。<br />
<br />
中国广电的入局，标志着国家推动“三网融合”（电信网、广播电视网、互联网）进入了实质性阶段。它旨在盘活广电系统庞大的有线电视网络资源，并将其与5G移动通信技术相结合，探索媒体与通信融合的新模式，为5G市场引入新的竞争变量。<br />
<br />
=== '''5.5 超越连接：向新增长引擎的战略转型''' ===<br />
随着传统的语音和流量业务市场日趋饱和，竞争日益激烈，三大运营商都面临着沦为低利润“哑管道”（Dumb Pipe）的风险。为了寻找新的增长点，并响应国家“数字经济”、“新基建”等战略，运营商们纷纷开启了从“连接”向“服务”的战略转型。<br />
<br />
* '''“宽带中国”战略'''：2013年，国务院发布“宽带中国”战略，将宽带网络提升为国家战略性公共基础设施，要求加快网络建设和提速降费，为数字经济的发展奠定基础 <sup>94</sup>。<br />
* '''云计算'''：'''中国电信'''将“天翼云”作为其核心战略，凭借其“云网融合”的独特优势，大力拓展政企市场，致力于成为云计算领域的“国家队” <sup>98</sup>。<br />
* '''数字内容与元宇宙'''：'''中国移动'''通过整合其音乐、视频、阅读、游戏、动漫五大内容基地，成立了专业的“咪咕文化科技有限公司”，全面发力数字内容、体育赛事转播和元宇宙等新兴消费领域 <sup>102</sup>。<br />
* '''产业互联网'''：'''中国联通'''则将重点放在产业互联网，依托其5G、物联网和大数据能力，为工业、医疗、交通等垂直行业提供数字化转型解决方案，打造工业互联网平台 <sup>106</sup>。<br />
<br />
这一系列转型，标志着中国电信业角色的再次进化。它不再仅仅是提供连接的基础设施，而是正在成为整个数字社会和产业数字化的核心赋能平台。<br />
{| class="wikitable"<br />
|代际 (时期)<br />
|核心技术<br />
|市场地位<br />
|关键政策/影响<br />
|-<br />
|'''1G''' (1987年起)<br />
|模拟通信 (如TACS)<br />
|'''空白''' (技术完全引进)<br />
|由邮电部引入，开启移动通信时代，但技术和设备被外商垄断<br />
|-<br />
|'''2G''' (1995年起)<br />
|数字通信 (GSM/CDMA)<br />
|'''跟随''' (网络自建，标准跟随)<br />
|联通引入CDMA形成双标准竞争；资费下降，手机开始普及<br />
|-<br />
|'''3G''' (2009年起)<br />
|TD-SCDMA / WCDMA / CDMA2000<br />
|'''突破''' (自主标准成为国际标准之一)<br />
|非对称发牌：移动承担TD-SCDMA，扶持联通/电信，催生自主产业链<br />
|-<br />
|'''4.G''' (2013年起)<br />
|TD-LTE / FDD-LTE<br />
|'''同步''' (自主标准成为全球主流之一)<br />
|“TD-LTE优先”发牌策略，助力中国移动和TD-LTE产业链取得成功<br />
|-<br />
|'''5G''' (2019年起)<br />
|NR (New Radio)<br />
|'''引领''' (标准主导、规模领先)<br />
|广电入局，推动“三网融合”；赋能千行百业，成为数字经济核心<br />
|}<br />
<br />
== '''结论''' ==<br />
纵观中国电信行业150余年的发展史，可以清晰地看到一条由国家战略意志贯穿始终的主线。从晚清为国防而被迫引入电报，到新中国为巩固政权而建立“邮电合一”体制，再到改革开放后为经济发展而推动的历次改革重组，直至今日为抢占全球科技制高点而引领5G和布局新基建，电信业始终是承载国家战略意图的关键领域。<br />
<br />
其发展呈现出几个鲜明的特点：<br />
<br />
# '''国家主导下的周期性演化'''：行业的发展并非线性的市场化进程，而是呈现出“开放-整合-再开放-再整合”的周期性特征。国家在需要快速发展和引入活力时，会通过引入竞争、向市场放权等方式“放开”；而在需要整合力量、实现特定战略目标（如推行自主标准、打造国家冠军）时，则会通过行政主导的重组“收紧”。这种“收放自如”的调控，是中国电信业区别于其他国家发展模式的核心特征。<br />
# '''技术政策服务于国家战略'''：技术标准的选择和牌照的发放，在中国从来不纯粹是技术或市场的考量，而是服务于更宏大产业政策和国家战略的工具。3G时代对中国移动的“压制”和对TD-SCDMA的“强推”，与4G时代对中国移动的“扶持”和对TD-LTE的“倾斜”，是这一逻辑最生动的体现。以短期的市场效率和企业利益为代价，换取长期的技术自主和产业安全，是其一以贯之的战略抉择。<br />
# '''从追赶者到引领者的跨越'''：中国电信业用短短几十年时间，走完了西方国家上百年的路，并实现了从“1G空白”到“5G引领”的惊人跨越。这得益于“以市场换技术”的后发优势，更得益于国家能够集中力量办大事的制度优势，通过超前规划和大规模投资，在光纤网络、移动通信等领域实现了基础设施的跨越式发展。<br />
<br />
展望未来，随着连接业务的饱和，中国电信行业已经进入了新的战略转型期。三大运营商正从传统的通信服务提供商，向集云、网、算、智、安于一体的综合性信息服务商演进。它们的新战场，是云计算、产业互联网、人工智能和数字内容。在这一新征程中，它们不仅是商业实体，更将继续扮演国家推动数字经济发展、保障信息安全、构建“新基建”的战略基石角色。中国电信业的故事，远未结束。<br />
<br />
<br />
==== '''引用的著作''' ====<br />
<br />
# 传承- GN 集团在中国, 访问时间为 六月 25, 2025， <nowiki>https://www.jabra.cn/about/heritage</nowiki><br />
# 中国经济网：走进档案中的中国电信, 访问时间为 六月 25, 2025， <nowiki>http://www.sasac.gov.cn/n4470048/n16518962/n18278651/n18278659/n18278672/c18463867/content.html</nowiki><br />
# 大北公司- 维基百科，自由的百科全书, 访问时间为 六月 25, 2025， <nowiki>https://zh.wikipedia.org/zh-cn/%E5%A4%A7%E5%8C%97%E5%85%AC%E5%8F%B8</nowiki><br />
# 清代第一条电报线路何时建成的？ - 中国电信集团, 访问时间为 六月 25, 2025， <nowiki>http://www.chinatelecom.com.cn/expo/01/202208/t20220809_71198.html</nowiki><br />
# 电报技术向晚清转移的影响因素分析 - SciEngine, 访问时间为 六月 25, 2025， <nowiki>https://www.sciengine.com/doi/pdf/3D84DF3AD60B4F83838CBEB7D89B835A</nowiki><br />
# 排拒与接纳晚清朝野关于自建电报的论争——从中国首条自建电报线问题说起 - 北京师范大学史学理论与史学史研究中心, 访问时间为 六月 25, 2025， <nowiki>https://bnuhh.bnu.edu.cn/lsyj/36007.html</nowiki><br />
# 中国通信的百年沉浮 - 中国科学院半导体研究所, 访问时间为 六月 25, 2025， <nowiki>http://semi.cas.cn/kxcb/kpwz/201806/t20180622_5030037.html</nowiki><br />
# 李鸿章与中国近代电报（四） - 中国电信集团, 访问时间为 六月 25, 2025， <nowiki>http://www.chinatelecom.com.cn/expo/06/202008/t20200814_56098.html</nowiki><br />
# 中国电信集团有限公司, 访问时间为 六月 25, 2025， <nowiki>http://www.chinatelecom.com.cn/expo/06/202008/t20200807_55869.html</nowiki><br />
# 选择性技术引入与早期大合流： 来自晚清有线电报的证据* - 财贸经济, 访问时间为 六月 25, 2025， <nowiki>https://cmjj.ajcass.com/UploadFile/Issue/20160121001/2024/2//20240218092815WU_FILE_0.pdf</nowiki><br />
# 清代的军事征调信息传递 - 中国社会科学网, 访问时间为 六月 25, 2025， <nowiki>https://www.cssn.cn/skgz/bwyc/202412/t20241209_5817536.shtml</nowiki><br />
# 电政总局- 维基百科，自由的百科全书 - Wikipedia, 访问时间为 六月 25, 2025， <nowiki>https://zh.wikipedia.org/zh-cn/%E7%94%B5%E6%94%BF%E6%80%BB%E5%B1%80</nowiki><br />
# 電政總局- 維基百科，自由的百科全書, 访问时间为 六月 25, 2025， <nowiki>https://zh.wikipedia.org/zh-tw/%E7%94%B5%E6%94%BF%E6%80%BB%E5%B1%80</nowiki><br />
# 杨士琦对中国早期电信事业的贡献 - 淮安政协文史网, 访问时间为 六月 25, 2025， <nowiki>http://zx.huaian.gov.cn/col/14066_664815/art/m/17040384/1704784245655iQjsRqyq.html</nowiki><br />
# 从听得见到听得好，电话交换技术的百年演进 - 中国电信集团, 访问时间为 六月 25, 2025， <nowiki>http://www.chinatelecom.com.cn/expo/01/202311/t20231115_78038.html</nowiki><br />
# 中国电话交换机大事简记 - 中国电信集团有限公司, 访问时间为 六月 25, 2025， <nowiki>http://www.chinatelecom.com.cn/expo/05/202110/t20211008_66393.html</nowiki><br />
# 电信业大事，你知道多少？（1912——1949） - 中国电信博物馆, 访问时间为 六月 25, 2025， <nowiki>http://museum.chinatelecom.com.cn/yj/zt/bwgwzbndx/2021bwgbnds/202106/t20210611_61599.html</nowiki><br />
# 皖南事变前后的新四军电台--党史 - 中国共产党新闻- 人民网, 访问时间为 六月 25, 2025， <nowiki>http://cpc.people.com.cn/n1/2024/1105/c443712-40354123.html</nowiki><br />
# 中国电信- 维基百科，自由的百科全书, 访问时间为 六月 25, 2025， <nowiki>https://zh.m.wikipedia.org/wiki/%E4%B8%AD%E9%9B%BB%E4%BF%A1</nowiki><br />
# 中国电信业改革大事记（1949-2009）, 访问时间为 六月 25, 2025， <nowiki>http://www.reformdata.org/2012/1106/1289.shtml</nowiki><br />
# 中国电信- 维基百科，自由的百科全书, 访问时间为 六月 25, 2025， <nowiki>https://zh.wikipedia.org/zh-cn/%E4%B8%AD%E5%9B%BD%E7%94%B5%E4%BF%A1</nowiki><br />
# 通信70年发展大事记_通信世界网, 访问时间为 六月 25, 2025， <nowiki>https://www.cww.net.cn/article?id=458617</nowiki><br />
# 中国电信集团有限公司, 访问时间为 六月 25, 2025， <nowiki>http://www.chinatelecom.com.cn/expo/01/</nowiki><br />
# 中外微波通信研发事项简记 - 中国电信集团, 访问时间为 六月 25, 2025， <nowiki>http://www.chinatelecom.com.cn/expo/05/202207/t20220711_70737.html</nowiki><br />
# 新中国60年报告之十五：邮电通信业发展突飞猛进 - 中国政府网, 访问时间为 六月 25, 2025， <nowiki>https://www.gov.cn/gzdt/2009-09/24/content_1425053.htm</nowiki><br />
# 从通信空白到走向世界前列——共和国通信业发展成就巡礼 - 中国政府网, 访问时间为 六月 25, 2025， <nowiki>https://www.gov.cn/xinwen/2019-09/19/content_5431376.htm</nowiki><br />
# 党领导新中国信息通信业的历史经验与启示_政务要闻, 访问时间为 六月 25, 2025， <nowiki>https://gyxxh.tj.gov.cn/ZWXX5652/ZWYW9055/202112/t20211228_5763166.html</nowiki><br />
# 《传媒观察》｜通信运营商在互联网发展中扮演了什么角色 - 江苏, 访问时间为 六月 25, 2025， <nowiki>https://jsnews.jschina.com.cn/kjwt/202401/t20240111_3347003.shtml</nowiki><br />
# 奋斗百年路启航新征程通信发展大跨越｜体制改革活力激荡 - 中国电信集团有限公司, 访问时间为 六月 25, 2025， <nowiki>http://www.chinatelecom.com.cn/expo/01/202108/t20210818_65653.html</nowiki><br />
# 风起青萍交换机- C114通信网, 访问时间为 六月 25, 2025， <nowiki>https://m.c114.com.cn/w182-447438.html</nowiki><br />
# 奋斗百年路启航新征程通信发展大跨越｜技术创新勇立潮头 - 中国电信集团有限公司, 访问时间为 六月 25, 2025， <nowiki>http://www.chinatelecom.com.cn/expo/01/202108/t20210802_63612.html</nowiki><br />
# 义乌邮电局与华为首台程控式交换机的故事 - 中国电信集团, 访问时间为 六月 25, 2025， <nowiki>http://www.chinatelecom.com.cn/expo/01/202206/t20220606_70087.html</nowiki><br />
# 中国工程院院士赵梓森：“中国光纤之父”的追光之路 - 党员学习专栏, 访问时间为 六月 25, 2025， <nowiki>https://www.sport.gov.cn/n4/n264/n15345/c21011009/content.html</nowiki><br />
# 光纤通信的发展历程以及未来应用, 访问时间为 六月 25, 2025， <nowiki>https://wlzx.hncu.edu.cn/info/1061/1431.htm</nowiki><br />
# 第一根國產光纖（新中國的“第一”）--時政--人民網, 访问时间为 六月 25, 2025， <nowiki>http://politics.people.com.cn/BIG5/n1/2019/1003/c1001-31383809.html</nowiki><br />
# 第一根国产光纤 - 党史- 人民网, 访问时间为 六月 25, 2025， <nowiki>http://dangshi.people.com.cn/n1/2019/1003/c85037-31383865.html</nowiki><br />
# 1994年联通成立：电信改革肇始和深入_CCTV.com_中国中央电视台 - 新闻频道, 访问时间为 六月 25, 2025， <nowiki>http://news.cctv.cn/science/20081008/110382.shtml</nowiki><br />
# 联通：在改革中诞生，传承红色通信基因 - 人民网-上海频道, 访问时间为 六月 25, 2025， <nowiki>http://sh.people.com.cn/n2/2022/0913/c134768-40121719.html</nowiki><br />
# 中国联通：赓续百年奋斗路向新而行新征程, 访问时间为 六月 25, 2025， <nowiki>http://www.sasac.gov.cn/n4470048/n29955503/n31729007/n31729012/c31773598/content.html</nowiki><br />
# 综述：我国启动第四次电信体制改革-电信重组-浙江在线-国内新闻, 访问时间为 六月 25, 2025， <nowiki>https://china.zjol.com.cn/05china/system/2008/05/24/009548920.shtml</nowiki><br />
# 吉通通信- 維基百科，自由的百科全書, 访问时间为 六月 25, 2025， <nowiki>https://zh.wikipedia.org/zh-hk/%E4%B8%AD%E5%9B%BD%E5%90%89%E9%80%9A?oldformat=true</nowiki><br />
# 吉通通信- 维基百科，自由的百科全书, 访问时间为 六月 25, 2025， <nowiki>https://zh.wikipedia.org/zh-cn/%E5%90%89%E9%80%9A%E9%80%9A%E4%BF%A1</nowiki><br />
# 中华人民共和国邮电部 - 维基百科, 访问时间为 六月 25, 2025， <nowiki>https://zh.wikipedia.org/zh-cn/%E4%B8%AD%E5%8D%8E%E4%BA%BA%E6%B0%91%E5%85%B1%E5%92%8C%E5%9B%BD%E9%82%AE%E7%94%B5%E9%83%A8</nowiki><br />
# 中国电信:固话商之变- 经济观察网－ 专业财经新闻网站, 访问时间为 六月 25, 2025， <nowiki>http://www.eeo.com.cn/2009/0831/149808.shtml</nowiki><br />
# 中移动痛苦变阵 - 京华周刊- 人民网, 访问时间为 六月 25, 2025， <nowiki>http://paper.people.com.cn/jhzk/html/2011-06/18/content_959407.htm?div=-1</nowiki><br />
# 中国移动10年成老大：时势、战略、管理- C114通信网, 访问时间为 六月 25, 2025， <nowiki>https://m.c114.com.cn/w220-475644.html</nowiki><br />
# 新闻中国电信切开之后, 访问时间为 六月 25, 2025， <nowiki>http://news.sina.com.cn/richtalk/news/money/9902/022515.html</nowiki><br />
# 中国联合通信有限公司 - 维基百科, 访问时间为 六月 25, 2025， <nowiki>https://zh.wikipedia.org/zh-cn/%E4%B8%AD%E5%9B%BD%E8%81%94%E5%90%88%E9%80%9A%E4%BF%A1%E6%9C%89%E9%99%90%E5%85%AC%E5%8F%B8</nowiki><br />
# 中国电信拆分对电信发展影响的分析 - ZTE, 访问时间为 六月 25, 2025， <nowiki>https://www.zte.com.cn/content/zte-site/www-zte-com-cn/china/about/magazine/zte-communications/2002/2/cn_304/149981.html</nowiki><br />
# 2001年南北拆分最富争议的改革 - C114通信网, 访问时间为 六月 25, 2025， <nowiki>https://m.c114.com.cn/w220-472926.html</nowiki><br />
# 中国电信业十年历经四次重组 - C114通信网, 访问时间为 六月 25, 2025， <nowiki>https://m.c114.com.cn/w220-455620.html</nowiki><br />
# 中國電信- 維基百科，自由的百科全書 - 维基百科 - Wikipedia, 访问时间为 六月 25, 2025， <nowiki>https://zh.wikipedia.org/wiki/%E4%B8%AD%E5%9B%BD%E7%94%B5%E4%BF%A1</nowiki><br />
# 中国电信日| 我们将怎么“看见”和“听见”未来世界 - Hytera, 访问时间为 六月 25, 2025， <nowiki>https://www.hytera.com/uz-uz/media-center/blog-detail.page/china-telecom-day</nowiki><br />
# 电信重组：从右再到左 - C114通信网, 访问时间为 六月 25, 2025， <nowiki>https://m.c114.com.cn/w220-325104.html</nowiki><br />
# 中国公用计算机互联网 - 维基百科, 访问时间为 六月 25, 2025， <nowiki>https://zh.wikipedia.org/zh-cn/%E4%B8%AD%E5%9B%BD%E5%85%AC%E7%94%A8%E8%AE%A1%E7%AE%97%E6%9C%BA%E4%BA%92%E8%81%94%E7%BD%91</nowiki><br />
# 中国互联网骨干网 - 维基百科, 访问时间为 六月 25, 2025， <nowiki>https://zh.wikipedia.org/zh-cn/%E4%B8%AD%E5%9B%BD%E4%BA%92%E8%81%94%E7%BD%91%E9%AA%A8%E5%B9%B2%E7%BD%91</nowiki><br />
# 中国互联网30年·系列述评｜勇当互联网“筑路人” - 西藏自治区网信办, 访问时间为 六月 25, 2025， <nowiki>https://wxb.xzdw.gov.cn/wlcb/cbgz/202404/t20240424_462015.html</nowiki><br />
# 163、169用户上网统一改号16900 - 中国青年报- 中青在线, 访问时间为 六月 25, 2025， <nowiki>http://zqb.cyol.com/content/2003-04/10/content_644970.htm</nowiki><br />
# 电信第五次改革”争议背后的思考 - 新闻- 科学网, 访问时间为 六月 25, 2025， <nowiki>https://news.sciencenet.cn/sbhtmlnews/2011/3/242744.html?id=242744</nowiki><br />
# 中国电信业为什么要重组? - 经济参考报, 访问时间为 六月 25, 2025， <nowiki>http://www.jjckb.cn/zat/2008-02/19/content_85726.htm</nowiki><br />
# 电信业重组启动完成后将发3张3G牌 - 经济参考报 - 新华网, 访问时间为 六月 25, 2025， <nowiki>http://jjckb.xinhuanet.com/zhuanti/2008-05/26/content_99421.htm</nowiki><br />
# 原六家基础电信运营企业重组为三家——中国电信收购中国联通CDMA网(包括资产和用户) - 经济参考报- 新华网, 访问时间为 六月 25, 2025， <nowiki>http://jjckb.xinhuanet.com/zhuanti/2008-05/29/content_99592.htm</nowiki><br />
# 2008年中华人民共和国电信业重组 - 维基百科, 访问时间为 六月 25, 2025， <nowiki>https://zh.wikipedia.org/zh-cn/2008%E5%B9%B4%E4%B8%AD%E5%8D%8E%E4%BA%BA%E6%B0%91%E5%85%B1%E5%92%8C%E5%9B%BD%E7%94%B5%E4%BF%A1%E4%B8%9A%E9%87%8D%E7%BB%84</nowiki><br />
# 电信业重组市场格局有变重组完成后发放三张3G牌照 - 中国质量新闻网, 访问时间为 六月 25, 2025， <nowiki>https://www.cqn.com.cn/zgzlb/content/2008-05/29/content_813994.htm</nowiki><br />
# 中国移动输赢在3G？ - 人民日报, 访问时间为 六月 25, 2025， <nowiki>http://paper.people.com.cn/zgjjzk/html/2008-06/09/content_48738835.htm</nowiki><br />
# 中国联通- 维基百科，自由的百科全书, 访问时间为 六月 25, 2025， <nowiki>https://zh.wikipedia.org/zh-cn/%E4%B8%AD%E5%9B%BD%E8%81%94%E9%80%9A</nowiki><br />
# zh.wikipedia.org, 访问时间为 六月 25, 2025， <nowiki>https://zh.wikipedia.org/zh-hans/%E4%B8%AD%E5%9B%BD%E7%BD%91%E9%80%9A#:~:text=2008%E5%B9%B410%E6%9C%8814,%E9%A6%99%E6%B8%AF%EF%BC%89%E8%82%A1%E4%BB%BD%E6%9C%89%E9%99%90%E5%85%AC%E5%8F%B8%EF%BC%88China</nowiki><br />
# 中国联通和中国网通重组央企户数调整为141户 - 中国政府网, 访问时间为 六月 25, 2025， <nowiki>https://www.gov.cn/ztzl/2009-01/07/content_1198859.htm</nowiki><br />
# 联通网通合并一年内完成整合 - C114通信网, 访问时间为 六月 25, 2025， <nowiki>https://m.c114.com.cn/w16-346620.html</nowiki><br />
# m.c114.com.cn, 访问时间为 六月 25, 2025， <nowiki>https://m.c114.com.cn/w119-330041.html#:~:text=%E4%B8%AD%E5%9B%BD%E8%81%94%E9%80%9A%E5%92%8C%E4%B8%AD%E5%9B%BD%E7%94%B5%E4%BF%A1,%E9%9C%80%E8%A6%81%E5%B0%8F%E8%82%A1%E4%B8%9C%E6%8A%95%E7%A5%A8%E9%80%9A%E8%BF%87%E3%80%82</nowiki><br />
# 中国电信以总价1100亿元收购联通C网 - 新闻频道, 访问时间为 六月 25, 2025， <nowiki>https://news.cctv.com/financial/20080602/109510.shtml</nowiki><br />
# 电信股集体复牌电信三巨头雏形初现 - 经济观察网, 访问时间为 六月 25, 2025， <nowiki>http://m.eeo.com.cn/2008/0603/102148.shtml</nowiki><br />
# 中移铁通- 维基百科，自由的百科全书, 访问时间为 六月 25, 2025， <nowiki>https://zh.wikipedia.org/zh-cn/%E4%B8%AD%E7%A7%BB%E9%93%81%E9%80%9A</nowiki><br />
# 中国移动有限公司- 投资者关系> 公司行动 - China Mobile, 访问时间为 六月 25, 2025， <nowiki>https://www.chinamobileltd.com/sc/ir/corpactions.php</nowiki><br />
# 中移动“通吃”产业链遇尴尬专家称300亿元并购铁通“已晚三秋” - 人民网, 访问时间为 六月 25, 2025， <nowiki>http://money.people.com.cn/stock/n1/2015/1217/c67815-27939636.html</nowiki><br />
# 中国移动329亿收购中国铁通资产7年“爱情长跑”结束有望？ - 观察者, 访问时间为 六月 25, 2025， <nowiki>https://www.guancha.cn/economy/2015_11_27_342875.shtml?web</nowiki><br />
# 经济观察网3G牌照, 访问时间为 六月 25, 2025， <nowiki>http://www.eeo.com.cn/3gpaizhao/index.shtml</nowiki><br />
# 中国电信计划小灵通用户转网 - C114通信网, 访问时间为 六月 25, 2025， <nowiki>https://m.c114.com.cn/w16-379462.html</nowiki><br />
# 中国“鸡肋”的3G标准:一场失败的“爱国实验” - C114通信网, 访问时间为 六月 25, 2025， <nowiki>https://m.c114.com.cn/w176-480318.html</nowiki><br />
# TD式创新_手机财新网, 访问时间为 六月 25, 2025， <nowiki>https://weekly.caixin.com/m/2014-12-05/100759605_all.html</nowiki><br />
# 中国移动否认大规模关停TD-SCDMA基站网友：炒作投资打水漂无知, 访问时间为 六月 25, 2025， <nowiki>https://www.guancha.cn/local/2016_03_14_353908.shtml?web</nowiki><br />
# 《研究简报》第231期举国体制演进如何推动关键技术升级？——中国3G到5G标准的案例研究-北大光华思想力 - 北京大学光华管理学院, 访问时间为 六月 25, 2025， <nowiki>https://www.gsm.pku.edu.cn/thought_leadership/info/1007/3037.htm</nowiki><br />
# 二月互联网热点·电信联通获FDD-LTE牌照 - 中央网信办, 访问时间为 六月 25, 2025， <nowiki>http://www.cac.gov.cn/2015-03/02/c_1114487560.htm</nowiki><br />
# 【纪念日】4G牌照发放一周年_特色频道_财新网 - Caixin, 访问时间为 六月 25, 2025， <nowiki>https://special.caixin.com/event_1204_1-mob/</nowiki><br />
# 工业和信息化部相关负责人解读4G牌照发放 - 中国政府网, 访问时间为 六月 25, 2025， <nowiki>https://www.gov.cn/zhengce/2013-12/04/content_2603752.htm</nowiki><br />
# 4G来了！ - 中国共产党新闻- 人民网, 访问时间为 六月 25, 2025， <nowiki>http://cpc.people.com.cn/n/2013/1205/c83083-23750340.html</nowiki><br />
# 4G争霸 - 中国经济周刊- 人民网, 访问时间为 六月 25, 2025， <nowiki>http://paper.people.com.cn/zgjjzk/html/2013-10/21/content_1315645.htm</nowiki><br />
# 工信部正式发放4G牌照_中国经济网, 访问时间为 六月 25, 2025， <nowiki>http://www.ce.cn/cysc/ztpd/2013/4gnxs/index.shtml</nowiki><br />
# 从1G到5G，看中国的“数智蝶变” - C114通信网, 访问时间为 六月 25, 2025， <nowiki>https://m.c114.com.cn/w241-1196596.html</nowiki><br />
# 我国正式发放5G商用牌照 - 中国政府网, 访问时间为 六月 25, 2025， <nowiki>https://www.gov.cn/xinwen/2019-06/06/content_5397978.htm</nowiki><br />
# 5G牌照发放,对你我意味着什么? - 新华网, 访问时间为 六月 25, 2025， <nowiki>http://www.xinhuanet.com/zgjx/2019-06/11/c_138132839.htm</nowiki><br />
# 深度文章：关于中国5G牌照，你必须看这篇研判！ - 新华网, 访问时间为 六月 25, 2025， <nowiki>http://www.news.cn/sikepro/20210310/C9335F2714B00001757D1DD01E261B43/c.html</nowiki><br />
# 【解局】中国发放5G商用牌照，为何提前了整一年？ - 华尔街见闻, 访问时间为 六月 25, 2025， <nowiki>https://wallstreetcn.com/articles/3541425</nowiki><br />
# 国务院关于印发“宽带中国”战略及实施方案的通知, 访问时间为 六月 25, 2025， <nowiki>https://www.gov.cn/zhengce/zhengceku/2013-08/16/content_5060.htm</nowiki><br />
# 国家发展改革委有关负责人就《“宽带中国”战略及实施方案》答记者问 - 深圳市发展和改革委员会, 访问时间为 六月 25, 2025， <nowiki>http://fgw.sz.gov.cn/gkmlpt/content/5/5739/post_5739655.html</nowiki><br />
# “宽带中国”是否促进了城市的创新能力？, 访问时间为 六月 25, 2025， <nowiki>http://www.szass.com/attachment/0/54/54709/853865.pdf</nowiki><br />
# “宽带中国”政策解读：发展宽带成为国家战略 - 湖南省人民政府, 访问时间为 六月 25, 2025， <nowiki>http://www.hunan.gov.cn/hnszf/xxgk/jd/zcjd/bm/201308/t20130819_4868376.html</nowiki><br />
# 中国电信-天翼云,云网融合,安全可信,专享定制, 访问时间为 六月 25, 2025， <nowiki>https://www.ctyun.cn/</nowiki><br />
# 中国电信：云已经进入“下半场” 天翼云“重新定义”云服务模式-新闻资讯, 访问时间为 六月 25, 2025， <nowiki>https://www.ctyun.cn/newsboard/163819848709701632</nowiki><br />
# 聚焦国云战略擘画智能未来天翼云以创新驱动发展新质生产力, 访问时间为 六月 25, 2025， <nowiki>http://www.sasac.gov.cn/n4470048/n29955503/n30329277/n30329358/c33016619/content.html</nowiki><br />
# 天翼云科技有限公司：深化国企改革，打造云计算领域国家战略支撑力量 - 中国电信集团, 访问时间为 六月 25, 2025， <nowiki>http://www.chinatelecom.com.cn/news/yunjisuanjisuanli/202403/t20240328_81865.html</nowiki><br />
# 咪咕数媒 - 浙江科技大学计算机科学与技术学院, 访问时间为 六月 25, 2025， <nowiki>https://itee.zust.edu.cn/info/1059/1940.htm</nowiki><br />
# 咪咕-以新质内容焕彩美好生活, 访问时间为 六月 25, 2025， <nowiki>https://www.migu.cn/</nowiki><br />
# 中国移动新媒体公司挂牌咪咕文化三大目标 - C114通信网, 访问时间为 六月 25, 2025， <nowiki>https://m.c114.com.cn/w41-877998.html</nowiki><br />
# 拥抱数智化浪潮中国移动咪咕科技创新赋能数字时代美好未来 - 新华网, 访问时间为 六月 25, 2025， <nowiki>http://www.xinhuanet.com/info/20231011/e1defee7266d461493e28ec798ab4c3a/c.html</nowiki><br />
# 中国联通：聚焦战略性新兴产业重点领域发布网络安全现代产业链共链行动计划, 访问时间为 六月 25, 2025， <nowiki>http://www.sasac.gov.cn/n4470048/n26915116/n29140421/n29140461/c29423628/content.html</nowiki><br />
# 强化牵头带动汇聚创新合力中国联通加速下一代互联网产业布局与发展, 访问时间为 六月 25, 2025， <nowiki>http://www.sasac.gov.cn/n4470048/n29955503/n30329277/n30329358/c32963089/content.html</nowiki><br />
# 中国联通智慧工业互联网平台以“产业集群与企业数字化转型升级使能者”为使命 - 政企在线, 访问时间为 六月 25, 2025， <nowiki>https://gec.10010.com/solution/131</nowiki><br />
# 产业互联网业务占比持续提升中国联通前三季度营收超2800亿元 - 证券日报, 访问时间为 六月 25, 2025， <nowiki>http://www.zqrb.cn/gscy/gongsi/2023-10-24/A1698161899695.html</nowiki></div>Yuhttps://www.dnswiki.cn/index.php?title=%E9%A6%96%E9%A1%B5&diff=222首页2025-06-25T15:21:31Z<p>Yu：</p>
<hr />
<div><br />
<br />
= [[国家、战略与速度-中国电信行业互动发展史 (1871 - 至今)]] =<br />
<br />
<br />
== [[DNS技术]] ==<br />
* [[DNS是什么？]]<br />
<br />
* [[DNS-RFC]]<br />
* [[顶级域名（TLD）]]<br />
* [[NAT64与DNS64基本原理概述]]<br />
* [[DNSSEC]]<br />
* [[EDNS]]<br />
* [[名词解释]]<br />
<br />
<br />
== DNS软件 ==<br />
<br />
* [[BIND]]<br />
* PowerDNS<br />
* Unbond<br />
* 其他<br />
<br />
<br />
== DNS安全 ==<br />
<br />
* [[DNSSEC]]<br />
* [[DNS-CVEs]]<br />
<br />
* [[网络安全/系统安全/业务安全]]<br />
<br />
<br />
== [[DNS资讯]] ==<br />
[[新闻-News]]<br />
<br />
[[常用公共DNS]]<br />
<br />
<br />
== [[LINUX]]相关 ==<br />
shell<br />
<br />
* [[超细节！十年码农讲述eBPF和XDP技术！]]<br />
<br />
* [[XDP技术 — Linux网络处理的高速公路]]<br />
<br />
* [[IPv6]]<br />
<br />
<br />
<br />
== 其他技术 ==<br />
cdn<br />
<br />
sdn<br />
<br />
[[OSI七层模型、TCP/IP四层模型]]<br />
<br />
[[安全，加密，TLS]]<br />
<br />
== [[帮助信息]] ==<br />
<br />
[[MediaWiki 设置配置]]<br />
<br />
[[MediaWiki 使用帮助]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<strong>已安装MediaWiki。</strong><br />
<br />
请查阅[https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents 用户指导]以获取使用本wiki软件的信息。</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-RFC&diff=221DNS-RFC2025-05-11T23:56:58Z<p>Yu：/* RFC文件下载： */</p>
<hr />
<div>= '''DNS-related RFCs with Community Annotations''' =<br />
This site is an informal list of RFCs that relate to the DNS. The RFCs have informal annotations that might be useful to DNS implementes and security researchers. The list of DNS-related RFCs and the annotations were collected by ICANN for the benefit of the DNS community. They are not at all a part of the RFC creation process; that process happens completely within the IETF.<br />
<br />
The value of the project is mostly in the in-line annotations. ICANN encourages anyone in the DNS community to contribute annotations to the project. The GitHub repository for the tool can be found here. There are instructions there about how to create annotations.<br />
<br />
This list, and the tool that generated the annotated versions, was sponsored by ICANN's Office of the CTO (OCTO). Please send questions about the tool to octo@icann.org.<br />
<br />
<br />
以下内容是一个与 DNS 相关的 RFC（请求评注文件）非正式列表。<br />
<br />
RFC 文件中带有非正式的注释，这些注释可能对 DNS 实现者和安全研究人员有所帮助。该 DNS 相关 RFC 列表及其注释由 ICANN 收集，旨在服务 DNS 社区。它们并不属于 RFC 创建流程的一部分；该流程完全在 IETF 内部进行。<br />
<br />
本项目的价值主要体现在其中的内嵌注释上。ICANN 鼓励 DNS 社区的任何成员为本项目贡献注释。相关工具的 GitHub 仓库可在此处找到，仓库中提供了创建注释的说明。<br />
<br />
该列表及生成带注释版本的工具由 ICANN 首席技术官办公室（OCTO）赞助。<br />
<br />
'''https://rfc-annotations.research.icann.org/'''<br />
<br />
* [[Basic DNS RFCs]] - 基础DNS相关的RFC文档<br />
<br />
* [[RFCs Related to DNSSEC]] - 与DNS安全扩展（DNSSEC）相关的RFC文档<br />
<br />
* [[RFCs Related to IDNA]] - 与国际化域名（IDNA）相关的RFC文档<br />
<br />
* [[RFCs Related to the Root Service]] - 与根服务器服务相关的RFC文档<br />
<br />
* [[RFCs Related to the Name Registration and Lookup]] - 与域名注册与查询相关的RFC文档<br />
<br />
== '''其他一些DNS相关参考内容''' ==<br />
微软 DNS ： https://learn.microsoft.com/zh-cn/windows/win32/dns/about-dns<br />
<br />
IETF DNSOP： <nowiki>https://datatracker.ietf.org/wg/dnsop/documents/</nowiki><br />
<br />
ISC-KB：<nowiki>https://kb.isc.org/</nowiki><br />
<br />
== '''DNS相关RFC大全下载：''' ==<br />
'''注意：本站文件解压密码：dnswiki.cn'''<br />
<br />
* '''DNS RFC Part 1_Basic DNS RFCS'''<br />
<br />
链接: https://pan.baidu.com/s/10DxJoAia1RHGfJH6IF_wKQ?pwd=yamu <br />
<br />
提取码: yamu <br />
<br />
* '''DNS_RFCs_Part-2_RFCs Related to DNSSEC'''<br />
<br />
链接: https://pan.baidu.com/s/1JiXGcPdnm-bH59IGEBR-7Q?pwd=yamu <br />
<br />
提取码: yamu<br />
<br />
* '''DNS_RFCs_Part-3_RFCs Related to IDNA'''<br />
<br />
链接: https://pan.baidu.com/s/1BremmxSL4kOrwX8jiMvDMA?pwd=yamu <br />
<br />
提取码: yamu <br />
<br />
* '''DNS_RFCs_Part-4_RFCs Related to the Name Registration and Lookup'''<br />
<br />
链接: <nowiki>https://pan.baidu.com/s/1TegPinWZ4RaUA6suAxgzRw?pwd=yamu</nowiki> <br />
<br />
提取码: yamu <br />
<br />
* '''DNS_RFCs_Part-5_RFCs Related to the Root Service'''<br />
<br />
链接: <nowiki>https://pan.baidu.com/s/1VtFdYVXEmLKCDW0Cg9iK0g?pwd=yamu</nowiki> <br />
<br />
提取码: yamu</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-RFC&diff=220DNS-RFC2025-05-09T08:00:56Z<p>Yu：</p>
<hr />
<div>= '''DNS-related RFCs with Community Annotations''' =<br />
This site is an informal list of RFCs that relate to the DNS. The RFCs have informal annotations that might be useful to DNS implementes and security researchers. The list of DNS-related RFCs and the annotations were collected by ICANN for the benefit of the DNS community. They are not at all a part of the RFC creation process; that process happens completely within the IETF.<br />
<br />
The value of the project is mostly in the in-line annotations. ICANN encourages anyone in the DNS community to contribute annotations to the project. The GitHub repository for the tool can be found here. There are instructions there about how to create annotations.<br />
<br />
This list, and the tool that generated the annotated versions, was sponsored by ICANN's Office of the CTO (OCTO). Please send questions about the tool to octo@icann.org.<br />
<br />
<br />
以下内容是一个与 DNS 相关的 RFC（请求评注文件）非正式列表。<br />
<br />
RFC 文件中带有非正式的注释，这些注释可能对 DNS 实现者和安全研究人员有所帮助。该 DNS 相关 RFC 列表及其注释由 ICANN 收集，旨在服务 DNS 社区。它们并不属于 RFC 创建流程的一部分；该流程完全在 IETF 内部进行。<br />
<br />
本项目的价值主要体现在其中的内嵌注释上。ICANN 鼓励 DNS 社区的任何成员为本项目贡献注释。相关工具的 GitHub 仓库可在此处找到，仓库中提供了创建注释的说明。<br />
<br />
该列表及生成带注释版本的工具由 ICANN 首席技术官办公室（OCTO）赞助。<br />
<br />
'''https://rfc-annotations.research.icann.org/'''<br />
<br />
* [[Basic DNS RFCs]] - 基础DNS相关的RFC文档<br />
<br />
* [[RFCs Related to DNSSEC]] - 与DNS安全扩展（DNSSEC）相关的RFC文档<br />
<br />
* [[RFCs Related to IDNA]] - 与国际化域名（IDNA）相关的RFC文档<br />
<br />
* [[RFCs Related to the Root Service]] - 与根服务器服务相关的RFC文档<br />
<br />
* [[RFCs Related to the Name Registration and Lookup]] - 与域名注册与查询相关的RFC文档<br />
<br />
== '''其他一些DNS相关参考内容''' ==<br />
微软 DNS ： https://learn.microsoft.com/zh-cn/windows/win32/dns/about-dns<br />
<br />
IETF DNSOP： <nowiki>https://datatracker.ietf.org/wg/dnsop/documents/</nowiki><br />
<br />
ISC-KB：<nowiki>https://kb.isc.org/</nowiki><br />
<br />
== '''RFC文件下载：''' ==<br />
'''注意：本站文件解压密码：dnswiki.cn'''<br />
<br />
* '''DNS RFC Part 1_Basic DNS RFCS'''<br />
<br />
链接: https://pan.baidu.com/s/10DxJoAia1RHGfJH6IF_wKQ?pwd=yamu <br />
<br />
提取码: yamu <br />
<br />
* '''DNS_RFCs_Part-2_RFCs Related to DNSSEC'''<br />
<br />
链接: https://pan.baidu.com/s/1JiXGcPdnm-bH59IGEBR-7Q?pwd=yamu <br />
<br />
提取码: yamu<br />
<br />
* '''DNS_RFCs_Part-3_RFCs Related to IDNA'''<br />
<br />
链接: https://pan.baidu.com/s/1BremmxSL4kOrwX8jiMvDMA?pwd=yamu <br />
<br />
提取码: yamu <br />
<br />
* '''DNS_RFCs_Part-4_RFCs Related to the Name Registration and Lookup'''<br />
<br />
链接: <nowiki>https://pan.baidu.com/s/1TegPinWZ4RaUA6suAxgzRw?pwd=yamu</nowiki> <br />
<br />
提取码: yamu <br />
<br />
* '''DNS_RFCs_Part-5_RFCs Related to the Root Service'''<br />
<br />
链接: <nowiki>https://pan.baidu.com/s/1VtFdYVXEmLKCDW0Cg9iK0g?pwd=yamu</nowiki> <br />
<br />
提取码: yamu</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-RFC&diff=219DNS-RFC2025-05-09T07:52:31Z<p>Yu：</p>
<hr />
<div>= '''DNS-related RFCs with Community Annotations''' =<br />
This site is an informal list of RFCs that relate to the DNS. The RFCs have informal annotations that might be useful to DNS implementes and security researchers. The list of DNS-related RFCs and the annotations were collected by ICANN for the benefit of the DNS community. They are not at all a part of the RFC creation process; that process happens completely within the IETF.<br />
<br />
The value of the project is mostly in the in-line annotations. ICANN encourages anyone in the DNS community to contribute annotations to the project. The GitHub repository for the tool can be found here. There are instructions there about how to create annotations.<br />
<br />
This list, and the tool that generated the annotated versions, was sponsored by ICANN's Office of the CTO (OCTO). Please send questions about the tool to octo@icann.org.<br />
<br />
<br />
以下内容是一个与 DNS 相关的 RFC（请求评注文件）非正式列表。<br />
<br />
RFC 文件中带有非正式的注释，这些注释可能对 DNS 实现者和安全研究人员有所帮助。该 DNS 相关 RFC 列表及其注释由 ICANN 收集，旨在服务 DNS 社区。它们并不属于 RFC 创建流程的一部分；该流程完全在 IETF 内部进行。<br />
<br />
本项目的价值主要体现在其中的内嵌注释上。ICANN 鼓励 DNS 社区的任何成员为本项目贡献注释。相关工具的 GitHub 仓库可在此处找到，仓库中提供了创建注释的说明。<br />
<br />
该列表及生成带注释版本的工具由 ICANN 首席技术官办公室（OCTO）赞助。<br />
<br />
'''https://rfc-annotations.research.icann.org/'''<br />
<br />
* [[Basic DNS RFCs]] - 基础DNS相关的RFC文档<br />
<br />
* [[RFCs Related to DNSSEC]] - 与DNS安全扩展（DNSSEC）相关的RFC文档<br />
<br />
* [[RFCs Related to IDNA]] - 与国际化域名（IDNA）相关的RFC文档<br />
<br />
* [[RFCs Related to the Root Service]] - 与根服务器服务相关的RFC文档<br />
<br />
* [[RFCs Related to the Name Registration and Lookup]] - 与域名注册与查询相关的RFC文档<br />
<br />
== '''其他一些DNS相关参考内容''' ==<br />
微软 DNS ： https://learn.microsoft.com/zh-cn/windows/win32/dns/about-dns<br />
<br />
IETF DNSOP： <nowiki>https://datatracker.ietf.org/wg/dnsop/documents/</nowiki><br />
<br />
ISC-KB：<nowiki>https://kb.isc.org/</nowiki><br />
<br />
== '''RFC文件下载：''' ==<br />
'''注意：本站文件解压密码：dnswiki.cn'''<br />
<br />
* '''DNS RFC Part 1_Basic DNS RFCS'''<br />
<br />
链接: https://pan.baidu.com/s/10DxJoAia1RHGfJH6IF_wKQ?pwd=yamu <br />
<br />
提取码: yamu <br />
<br />
* '''DNS_RFCs_Part-2_RFCs Related to DNSSEC'''<br />
<br />
链接: https://pan.baidu.com/s/1JiXGcPdnm-bH59IGEBR-7Q?pwd=yamu <br />
<br />
提取码: yamu</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-RFC&diff=218DNS-RFC2025-05-09T07:51:59Z<p>Yu：</p>
<hr />
<div>= '''DNS-related RFCs with Community Annotations''' =<br />
This site is an informal list of RFCs that relate to the DNS. The RFCs have informal annotations that might be useful to DNS implementes and security researchers. The list of DNS-related RFCs and the annotations were collected by ICANN for the benefit of the DNS community. They are not at all a part of the RFC creation process; that process happens completely within the IETF.<br />
<br />
The value of the project is mostly in the in-line annotations. ICANN encourages anyone in the DNS community to contribute annotations to the project. The GitHub repository for the tool can be found here. There are instructions there about how to create annotations.<br />
<br />
This list, and the tool that generated the annotated versions, was sponsored by ICANN's Office of the CTO (OCTO). Please send questions about the tool to octo@icann.org.<br />
<br />
<br />
以下内容是一个与 DNS 相关的 RFC（请求评注文件）非正式列表。<br />
<br />
RFC 文件中带有非正式的注释，这些注释可能对 DNS 实现者和安全研究人员有所帮助。该 DNS 相关 RFC 列表及其注释由 ICANN 收集，旨在服务 DNS 社区。它们并不属于 RFC 创建流程的一部分；该流程完全在 IETF 内部进行。<br />
<br />
本项目的价值主要体现在其中的内嵌注释上。ICANN 鼓励 DNS 社区的任何成员为本项目贡献注释。相关工具的 GitHub 仓库可在此处找到，仓库中提供了创建注释的说明。<br />
<br />
该列表及生成带注释版本的工具由 ICANN 首席技术官办公室（OCTO）赞助。<br />
<br />
'''https://rfc-annotations.research.icann.org/'''<br />
<br />
* [[Basic DNS RFCs]] - 基础DNS相关的RFC文档<br />
<br />
* [[RFCs Related to DNSSEC]] - 与DNS安全扩展（DNSSEC）相关的RFC文档<br />
<br />
* [[RFCs Related to IDNA]] - 与国际化域名（IDNA）相关的RFC文档<br />
<br />
* [[RFCs Related to the Root Service]] - 与根服务器服务相关的RFC文档<br />
<br />
* [[RFCs Related to the Name Registration and Lookup]] - 与域名注册与查询相关的RFC文档<br />
<br />
== '''其他一些DNS相关参考内容''' ==<br />
微软 DNS ： https://learn.microsoft.com/zh-cn/windows/win32/dns/about-dns<br />
<br />
IETF DNSOP： <nowiki>https://datatracker.ietf.org/wg/dnsop/documents/</nowiki><br />
<br />
ISC-KB：<nowiki>https://kb.isc.org/</nowiki><br />
<br />
== '''RFC文件下载：''' ==<br />
'''注意：本站文件解压密码：dnswiki.cn'''<br />
<br />
* '''DNS RFC Part 1_Basic DNS RFCS'''<br />
<br />
链接: <nowiki>https://pan.baidu.com/s/10DxJoAia1RHGfJH6IF_wKQ?pwd=yamu</nowiki> <br />
<br />
提取码: yamu <br />
<br />
* '''DNS_RFCs_Part-2_RFCs Related to DNSSEC'''<br />
<br />
链接: <nowiki>https://pan.baidu.com/s/1JiXGcPdnm-bH59IGEBR-7Q?pwd=yamu</nowiki> <br />
<br />
提取码: yamu</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-RFC&diff=217DNS-RFC2025-05-09T07:36:22Z<p>Yu：</p>
<hr />
<div>= DNS-related RFCs with Community Annotations =<br />
This site is an informal list of RFCs that relate to the DNS. The RFCs have informal annotations that might be useful to DNS implementes and security researchers. The list of DNS-related RFCs and the annotations were collected by ICANN for the benefit of the DNS community. They are not at all a part of the RFC creation process; that process happens completely within the IETF.<br />
<br />
The value of the project is mostly in the in-line annotations. ICANN encourages anyone in the DNS community to contribute annotations to the project. The GitHub repository for the tool can be found here. There are instructions there about how to create annotations.<br />
<br />
This list, and the tool that generated the annotated versions, was sponsored by ICANN's Office of the CTO (OCTO). Please send questions about the tool to octo@icann.org.<br />
<br />
<br />
以下内容是一个与 DNS 相关的 RFC（请求评注文件）非正式列表。<br />
<br />
RFC 文件中带有非正式的注释，这些注释可能对 DNS 实现者和安全研究人员有所帮助。该 DNS 相关 RFC 列表及其注释由 ICANN 收集，旨在服务 DNS 社区。它们并不属于 RFC 创建流程的一部分；该流程完全在 IETF 内部进行。<br />
<br />
本项目的价值主要体现在其中的内嵌注释上。ICANN 鼓励 DNS 社区的任何成员为本项目贡献注释。相关工具的 GitHub 仓库可在此处找到，仓库中提供了创建注释的说明。<br />
<br />
该列表及生成带注释版本的工具由 ICANN 首席技术官办公室（OCTO）赞助。<br />
<br />
'''https://rfc-annotations.research.icann.org/'''<br />
<br />
* [[Basic DNS RFCs]] - 基础DNS相关的RFC文档<br />
<br />
* [[RFCs Related to DNSSEC]] - 与DNS安全扩展（DNSSEC）相关的RFC文档<br />
<br />
* [[RFCs Related to IDNA]] - 与国际化域名（IDNA）相关的RFC文档<br />
<br />
* [[RFCs Related to the Root Service]] - 与根服务器服务相关的RFC文档<br />
<br />
* [[RFCs Related to the Name Registration and Lookup]] - 与域名注册与查询相关的RFC文档<br />
<br />
== 其他一些DNS相关参考内容 ==<br />
微软 DNS ： https://learn.microsoft.com/zh-cn/windows/win32/dns/about-dns<br />
<br />
IETF DNSOP： <nowiki>https://datatracker.ietf.org/wg/dnsop/documents/</nowiki><br />
<br />
ISC-KB：<nowiki>https://kb.isc.org/</nowiki></div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-RFC&diff=216DNS-RFC2025-05-09T07:35:53Z<p>Yu：</p>
<hr />
<div>= DNS-related RFCs with Community Annotations =<br />
This site is an informal list of RFCs that relate to the DNS. The RFCs have informal annotations that might be useful to DNS implementes and security researchers. The list of DNS-related RFCs and the annotations were collected by ICANN for the benefit of the DNS community. They are not at all a part of the RFC creation process; that process happens completely within the IETF.<br />
<br />
The value of the project is mostly in the in-line annotations. ICANN encourages anyone in the DNS community to contribute annotations to the project. The GitHub repository for the tool can be found here. There are instructions there about how to create annotations.<br />
<br />
This list, and the tool that generated the annotated versions, was sponsored by ICANN's Office of the CTO (OCTO). Please send questions about the tool to octo@icann.org.<br />
<br />
<br />
以下内容是一个与 DNS 相关的 RFC（请求评注文件）非正式列表。<br />
<br />
RFC 文件中带有非正式的注释，这些注释可能对 DNS 实现者和安全研究人员有所帮助。该 DNS 相关 RFC 列表及其注释由 ICANN 收集，旨在服务 DNS 社区。它们并不属于 RFC 创建流程的一部分；该流程完全在 IETF 内部进行。<br />
<br />
本项目的价值主要体现在其中的内嵌注释上。ICANN 鼓励 DNS 社区的任何成员为本项目贡献注释。相关工具的 GitHub 仓库可在此处找到，仓库中提供了创建注释的说明。<br />
<br />
该列表及生成带注释版本的工具由 ICANN 首席技术官办公室（OCTO）赞助。<br />
<br />
'''https://rfc-annotations.research.icann.org/'''<br />
<br />
* [[Basic DNS RFCs]] - 基础DNS相关的RFC文档<br />
<br />
* [[RFCs Related to DNSSEC]] - 与DNS安全扩展（DNSSEC）相关的RFC文档<br />
<br />
* [[RFCs Related to IDNA]] - 与国际化域名（IDNA）相关的RFC文档<br />
<br />
* [[RFCs Related to the Root Service]] - 与根服务器服务相关的RFC文档<br />
<br />
* [[RFCs Related to the Name Registration and Lookup]] - 与域名注册与查询相关的RFC文档<br />
<br />
== 其他一些DNS相关参考内容 ==<br />
微软 DNS ： https://learn.microsoft.com/zh-cn/windows/win32/dns/about-dns<br />
<br />
IETF DNSOP： <nowiki>https://datatracker.ietf.org/wg/dnsop/documents/</nowiki><br />
<br />
ISC-KB：<nowiki>https://kb.isc.org/</nowiki><br />
<br />
<nowiki>RFC 1035</nowiki>：域名 - 实现和规范<br />
<br />
<nowiki>RFC 1122</nowiki>：Internet 主机的要求 - 通信层<br />
<br />
<nowiki>RFC 1123</nowiki>：Internet 主机的要求 - 应用程序和支持<br />
<br />
<nowiki>RFC 1876</nowiki>：在域名系统中表达位置信息的方法<br />
<br />
<nowiki>RFC 1995</nowiki>：DNS 中的增量区域传输<br />
<br />
<nowiki>RFC 1996</nowiki>：区域更改提示通知机制 (DNS 通知)<br />
<br />
<nowiki>RFC 2136</nowiki>：域名系统 (DNS 更新) 中的动态汇报<br />
<br />
<nowiki>RFC 2181</nowiki>：DNS 规范的说明<br />
<br />
<nowiki>RFC 2308</nowiki>：DNS 查询的负缓存 (DNS NCACHE)<br />
<br />
<nowiki>RFC 2535</nowiki>：域名系统安全扩展<br />
<br />
<nowiki>RFC 2782</nowiki>：用于指定服务位置的 DNS RR (DNS SRV)<br />
<br />
<nowiki>RFC 2845</nowiki>：DNS (TSIG) 的密钥事务身份验证<br />
<br />
<nowiki>RFC 2915</nowiki>：命名机构指针 (NAPTR) DNS 资源记录<br />
<br />
<nowiki>RFC 2930</nowiki>：为 DNS (TKEY RR) 建立机密密钥<br />
<br />
<nowiki>RFC 2931</nowiki>：DNS 请求和事务签名 ( SIG (0) s )<br />
<br />
<nowiki>RFC 3110</nowiki>：域名系统中的 RSA/SHA-1 SIG 和 RSA KEY (DNS)<br />
<br />
<nowiki>RFC 3445</nowiki>：限制 KEY 资源记录的范围 (RR)<br />
<br />
<nowiki>RFC 3596</nowiki>：支持 IP 版本 6 的 DNS 扩展<br />
<br />
<nowiki>RFC 3645</nowiki>：用于 DNS (GSS-TSIG) 的密钥事务身份验证的通用安全服务算法</div>Yuhttps://www.dnswiki.cn/index.php?title=%E7%BD%91%E7%BB%9C%E5%AE%89%E5%85%A8/%E7%B3%BB%E7%BB%9F%E5%AE%89%E5%85%A8/%E4%B8%9A%E5%8A%A1%E5%AE%89%E5%85%A8&diff=115网络安全/系统安全/业务安全2024-04-16T07:17:25Z<p>Yu：</p>
<hr />
<div>{| class="wikitable"<br />
!<br />
!项目<br />
!<br />
!描述<br />
!<br />
!防护方法<br />
!渗透方法<br />
|-<br />
|网络系统安全<br />
|网络端口<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|<br />
|系统漏洞<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|基线合规安全<br />
|<br />
|<br />
|Trivy<br />
|<br />
|<br />
|<br />
|-<br />
|<br />
|<br />
|<br />
|OpenVAS<br />
|<br />
|<br />
|<br />
|-<br />
|<br />
|<br />
|<br />
|Clair、<br />
|<br />
|<br />
|<br />
|-<br />
|<br />
|<br />
|<br />
|Anchore、OpenSCAP<br />
|<br />
|<br />
|<br />
|-<br />
|WEB应用安全<br />
|[[WEB应用渗透]]<br />
|XSS<br />
|XSS 攻击全称跨站脚本攻击（Cross-Site Scripting），简单的说就是攻击者通过在目标网站上注入恶意脚本并运行，获取用户的敏感信息如 Cookie、SessionID 等，影响网站与用户数据安全。<br />
XSS 攻击更偏向前端的范畴，但后端在保存数据的时候也需要对数据进行安全过滤。<br />
<br />
原因<br />
<br />
当攻击者通过某种方式向浏览器页面注入了恶意代码，并且浏览器执行了这些代码。<br />
|Nikto、Nessus Essentials<br />
|一个基本的思路是渲染前端页面（不管是客户端渲染还是服务器端渲染）或者动态插入 HTML 片段时，任何数据都不可信任，都要先做 HTML 过滤，然后再渲染。<br />
|<br />
|-<br />
|<br />
|<br />
|CSRF 攻击<br />
|CSRF 攻击全称跨站请求伪造（Cross-site Request Forgery），简单的说就是攻击者盗用了你的身份，以你的名义发送恶意请求。<br />
原因<br />
<br />
一个典型的 CSRF 攻击有着如下的流程：<br />
<br />
* 受害者登录 <code>a.com</code>，并保留了登录凭证（Cookie）<br />
* 攻击者引诱受害者访问了 <code>b.com</code><br />
* <code>b.com</code> 向 <code>a.com</code> 发送了一个请求：<code>a.com/act=xx</code>（浏览器会默认携带 <code>a.com</code> 的 Cookie）<br />
* <code>a.com</code> 接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求<br />
* <code>a.com</code> 以受害者的名义执行了 <code>act=xx</code><br />
* 攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让 <code>a.com</code> 执行了自己定义的操作<br />
|<br />
|解决方案<br />
防止 CSRF 攻击需要在服务器端入手，基本的思路是能正确识别是否是用户发起的请求。<br />
|<br />
|-<br />
|<br />
|<br />
|DDoS 攻击<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|<br />
|<br />
|XXE 漏洞<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|<br />
|<br />
|JSON 劫持<br />
|https://zhuanlan.zhihu.com/p/55689478<br />
|<br />
|<br />
|<br />
|-<br />
|<br />
|弱口令（弱密码）<br />
|<br />
|通常所说的弱口令是指常用的一些密码（比如123456）和一些应用程序的默认密码，但实际上任何有规律的密码都可以称作弱密码，可能随着机器学习的发展，大多数密码都可以称作弱密码，因为人设置密码的规律是有迹可循的。<br />
|<br />
|<br />
|<br />
|-<br />
|<br />
|SQL注入<br />
|<br />
|SQL 注入就是通过给 web 应用接口传入一些特殊字符，达到欺骗服务器执行恶意的 SQL 命令。<br />
SQL 注入漏洞属于后端的范畴，但前端也可做体验上的优化。<br />
<br />
原因，当使用外部不可信任的数据作为参数进行数据库的增、删、改、查时，如果未对外部数据进行过滤，就会产生 SQL 注入漏洞。<br />
|<br />
|<br />
|<br />
|-<br />
|<br />
|远程命令<br />
|<br />
|(代码)执行(命令注入）<br />
|<br />
|<br />
|<br />
|-<br />
|<br />
|目录遍历<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|<br />
|任意文件上传<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
=== WEB应用渗透-网络漏洞扫描器有： ===<br />
Nessus、NeXpose、OpenVAS等<br />
<br />
WEB应用渗透-Kali系统工具集<br />
<br />
<br />
<br />
[[Web漏洞之XSS(跨站脚本攻击)详解]]<br />
<br />
<br />
十二个常见的Web安全漏洞总结及防范措施-https://blog.csdn.net/chenlijian/article/details/115006677<br />
<br />
WEB应用常见15种安全漏洞一览-https://zhuanlan.zhihu.com/p/55689478<br />
<br />
* 云平台扫描引擎：Cloud Custodian<br />
* AWS 扫描引擎：Prowler<br />
* 漏洞扫描引擎：Nuclei<br />
<br />
<br />
<br />
您可以使用以下配置合规工具在 Red Hat Enterprise Linux 中执行完全自动化的合规审计。这些工具基于安全内容自动化协议(SCAP)标准，专为自动定制合规策略而设计。<br />
<br />
; SCAP 工作台<br />
: <code>scap-workbench</code> 图形工具旨在对单个本地或远程系统执行配置和漏洞扫描。您还可以根据这些扫描和评估，使用它来生成安全报告。<br />
; OpenSCAP<br />
: 带有 <code>oscap</code> 命令行工具的 <code>OpenSCAP</code> 库旨在对本地系统执行配置和漏洞扫描，以验证配置合规内容，并根据这些扫描和评估生成报告和指南。<br />
<br />
<br />
=== AWVS ===<br />
Acunetix Web Vulnerability Scanner（简称AWVS）是一款知名的网络漏洞扫描工具，它通过网络爬虫测试你的网站安全，检测流行安全漏洞，如SQL注入，XSS，目录遍历，命令注入等。<br />
<br />
=== OpenVAS ===<br />
OpenVAS是开放式漏洞评估系统，也可以说它是一个包含着相关工具的网络扫描器。其核心部件是一个服务器，包括一套网络漏洞测试程序，可以检测远程系统、应用程序中的安全问题，识别远程主机、Web应用存在的各种漏洞；<br />
<br />
Nessus曾将是业内开源漏洞扫描工具的标准，在Nessus商业化不在开放源代码后，在它的原始项目中分支出OpenVAS开源项目，经过多年的发展，OpenVAS已经成为当前最好的开源漏洞扫描器，功能非常强大；OpenVAS使用NVT脚本（漏洞库）对多种远程系统(包括Windows、Linux、UNIX以及Web应用程序等)的安全问题进行检测。<br />
<br />
<br />
MSF概述<br />
<br />
Metasploit就是一个漏洞框架（The Metasploit Framework），是一个免费、可下载的框架，通过它可以很容易地获取、开发并对计算机软件漏洞实施攻击。它本身附带数2000多个已知软件漏洞的专业级漏洞攻击工具，目前最流行、最强大、最具扩展性的渗透测试平台软件，2003年由HD Moore发布第一版，2007年用ruby语言重写，MSF默认集成在Kali Linux之中。<br />
<br />
<br />
'''APPScan'''<br />
<br />
IBM AppScan是一款非常好用且功能强大的Web 应用安全测试工具，曾以 Watchfire AppScan 的名称享誉业界，Rational AppScan 可自动化 Web 应用的安全漏洞评估工作，能扫描和检测所有常见的 Web 应用安全漏洞，例如 SQL 注入（SQL-injection）、跨站点脚本攻击（cross-site scripting）、缓冲区溢出（buffer overflow）及最新的 Flash/Flex 应用及 Web 2.0 应用曝露等方面安全漏洞的扫描。<br />
<br />
<br />
'''Nikto'''<br />
<br />
https://zhuanlan.zhihu.com/p/124246499<br />
<br />
是一个开源的WEB扫描评估软件，可以对Web服务器进行多项安全测试，能在230多种服务器上扫描出 2600多种有潜在危险的文件、CGI及其他问题。Nikto可以扫描指定主机的WEB类型、主机名、指定目录、特定CGI漏洞、返回主机允许的 http模式等。<br />
<br />
Nikto是一款开源的Web服务器扫描程序，它可以对Web服务器的多种项目(包括3500个潜在的危险文件/CGI，以及超过900个服务器版本，还有250多个服务器上的版本特定问题)进行全面的测试。Nikto可以在短时间内扫描服务器的多个端口，Nikto因其效率和服务器强化功能而受到青睐。<br />
<br />
<br />
'''Xray'''<br />
<br />
Xray是一款功能强大的安全评估工具，检测速度快（发包速度快，漏洞检测算法高效）；支持范围广（大至 OWASP Top 10 通用漏洞检测，小至各种 CMS 框架 POC，均可以支持）；编写代码的人员素质高, 通过 Code Review、单元测试、集成测试等多层验证来提高代码可靠性。<br />
<br />
<br />
<br />
==== nmap简介 ====<br />
'''nmap是一款非常强大的主机发现和端口扫描工具，而且nmap运用自带的脚本，还能完成漏洞检测，同时支持多平台。'''<br />
<br />
<br />
<br />
Arachni、XssPy、w3af、Nikto、Wfuzz、OWASP ZAP、Wapiti、OWASP Xenotix XSS、Golismero、Grabber、SQLmap、Vega<br />
<br />
{| class="wikitable"<br />
|'''工具名称'''<br />
|'''主要特点'''<br />
|-<br />
|Vulnerability Manager Plus<br />
|为应用程序定制补丁程序<br />
<br />
检测零日漏洞<br />
<br />
可审计已过期的软件<br />
<br />
可给出修复建议<br />
<br />
自定义扫描配置<br />
|-<br />
|Tripwire IP360<br />
|应用灵活、便捷<br />
<br />
完整的网络资产扫描<br />
<br />
漏洞风险评分<br />
<br />
资产发现<br />
|-<br />
|Nessus vulnerability scanner<br />
|可进行特定目标分析<br />
<br />
敏感数据发现<br />
<br />
恶意软件检测<br />
满足PCI DSS要求<br />
|-<br />
|Comodo HackerProof<br />
|可用于日常性漏洞扫描<br />
<br />
基于Web的管理工具<br />
<br />
带有PCI扫描工具<br />
|-<br />
|Nexpose community<br />
|基于实际风险的评分<br />
<br />
可与Metasploit集成<br />
<br />
强大的分析报告功能<br />
<br />
自适应安全性分析<br />
|-<br />
|OpenVAS Vulnerability Scanner<br />
|目标IP地址识别<br />
<br />
任务命名<br />
<br />
强大的授权(凭据)扫描<br />
<br />
支持计划调度扫描<br />
|-<br />
|Nikto<br />
|支持对身份验证的代理<br />
<br />
Cookie支持<br />
<br />
支持用户名枚举<br />
<br />
可提供过期组件列表<br />
|-<br />
|Wireshark<br />
|实时捕获和离线分析<br />
<br />
支持对协议的深入检查<br />
<br />
支持VoIP分析<br />
<br />
支持读/写捕获文件<br />
<br />
支持着色规则检测<br />
|-<br />
|Aircrack-ng<br />
|分析WiFi网络的弱点<br />
<br />
识别对WiFi设备的捕获和注入<br />
<br />
嗅探无线数据包<br />
<br />
恢复丢失的密钥<br />
|-<br />
|Retina network security scanner<br />
|扫描完整的网络环境<br />
<br />
发现应用程序缺陷<br />
<br />
可结合威胁安全情报分析<br />
|}<br />
'''01'''<br />
<br />
'''Vulnerability Manager Plus'''<br />
<br />
Vulnerability Manager Plus漏洞扫描工具是由ManageEngine公司开发，集成了威胁管理和漏洞扫描功能，可以为安全工程师提供全面的漏洞检测和实时缓解解决方案。由于该工具在应用功能上的全面性，因此受到了很多渗透测试工程师们的喜爱。Vulnerability Manager Plus的一个重要特点是，其在整个漏洞扫描过程中，从漏洞检测到漏洞修复的功能设计都是精简的。此外，自动扫描、影响评估、软件风险评估、安全错误配置、补丁、零日漏洞缓解扫描以及Web服务器渗透测试和加固都是vulnerability Manager Plus的应用亮点。<br />
<br />
'''传送门：'''<br />
<br />
'''<nowiki>https://www.manageengine.com/vulnerability-management/?utm_source=GBHackers&utm_medium=Website&utm_campaign=VMP-VulScaTools</nowiki>'''<br />
<br />
'''02'''<br />
<br />
'''Tripwire IP360'''<br />
<br />
Tripwire IP360是目前全球市场上应用最广泛的漏洞评估扫描工具之一，能够用户识别网络上的多种内容，包括本地部署、云和容器资产。该工具允许企业IT部门使用代理访问他们的资产，并减少代理扫描。它还可以与主流的漏洞管理方案集成，使IT管理员和安全专业人员能够拥有全面的风险管理方法。<br />
<br />
'''传送门：'''<br />
<br />
'''<nowiki>https://www.tripwire.com/products/tripwire-ip360</nowiki>'''<br />
<br />
'''03'''<br />
<br />
'''OpenVAS Vulnerability Scanner'''<br />
<br />
OpenVAS漏洞扫描器是一款开源的漏洞扫描与分析工具，具有较全面的漏洞检测能力，可以帮助用户IT部门全面扫描服务器、应用和网络设备中的开放端口、错误配置和漏洞，并查找IP地址和任何开放的服务。扫描完成后，该工具将会自动生成一个完整的检查分析报告，并以电子邮件的形式发送，以便用户进行进一步研究和更正。<br />
<br />
OpenVAS还可以从外部服务器上操作，让企业从攻击者的角度出发，从而识别暴露的端口或服务并及时处理它们。如果用户已经拥有内部事件响应或检测系统，那么OpenVAS可以作为一种网络渗透测试工具，来帮助用户改进网络监控。<br />
<br />
'''传送门：'''<br />
<br />
'''<nowiki>https://www.openvas.org/</nowiki>'''<br />
<br />
'''04'''<br />
<br />
'''Nessus Vulnerability Scanner'''<br />
<br />
Tenable推出的Nessus Vulnerability Scanne可以帮助安全工程师全面发现监测操作系统，应用补丁、恶意软件、广告软件删除工具和错误配置。Nessus拥有一个主动的安全程序，能够在黑客利用漏洞渗透网络之前及时识别漏洞，并阻止远程代码执行漏洞。它能够覆盖大多数网络设备，包括虚拟、物理和云基础设施。早在2020年，Tenable就已经被Gartner提名为“漏洞评估同行洞察选择”（Peer Insights Choice for vulnerability assessment）。<br />
<br />
'''传送门：'''<br />
<br />
'''<nowiki>https://www.tenable.com/products/nessus/nessus-professional</nowiki>'''<br />
<br />
'''05'''<br />
<br />
'''Nexpose community'''<br />
<br />
Nexpose community是由Rapid7公司开发的漏洞扫描工具，它也是一个开源解决方案，能够较全面满足大多数网络系统的安全检查要求。<br />
<br />
对IT管理员来说，该解决方案具有较好的通用性，并可以集成到Metasploit框架中，对各种类型访问网络的新设备进行安全检测和扫描。它还能够监视暴露在现实世界中的漏洞，并根据威胁的后果进行优先级分析，为威胁提供了风险评分，范围在1-1000之间，从而大幅提升漏洞管理的效率。目前，Nexpose可以为用户提供一年的免费试用期限。<br />
<br />
'''传送门：'''<br />
<br />
'''<nowiki>https://www.rapid7.com/products/nexpose/</nowiki>'''<br />
<br />
'''06'''<br />
<br />
'''Nikto'''<br />
<br />
Nikto也是一款可以免费在线试用的强大漏洞扫描工具，因其具有的扫描便捷和服务器加固功能而成为很多用户的首选工具。它可以帮助用户了解服务器与网络系统的功能表现，检查其应用软件的版本更新，在web服务器上执行测试以识别威胁和恶意软件的存在，并扫描不同的协议，如HTTPS、httpd、HTTP等。Nikto还可以在非常短的时间内扫描服务器的多个端口。<br />
<br />
'''传送门：'''<br />
<br />
'''<nowiki>https://www.kali.org/tools/nikto/</nowiki>'''<br />
<br />
'''07'''<br />
<br />
'''Retina Network Security Scanner'''<br />
<br />
Retina vulnerability scanner是一个基于Web网页的开源软件，覆盖多个平台，提供完整的跨平台漏洞评估工具列表和安全性，主要功能包括了漏洞扫描与修补、合规性检测、配置检查和报告分析等。目前，Retina vulnerability scanner可以有效扫描常见的数据库、工作站、服务器和web应用程序，并完全支持VCenter集成和应用程序扫描虚拟环境。<br />
<br />
'''传送门：'''<br />
<br />
'''<nowiki>https://www.beyondtrust.com/vulnerability-management</nowiki>'''<br />
<br />
'''08'''<br />
<br />
'''Wireshark'''<br />
<br />
Wireshark是目前公认为最好的网络协议分析器之一。它可以在Linux、macOS和Windows设备上成功运行，也由此被许多政府机构、企业、医疗保健广泛应用于网络安全分析。一旦Wireshark识别出威胁，便会将其脱机以进行更具体的安全检查。<br />
<br />
Wireshark的其他亮点还包括提供了标准的三窗格（three-pane）数据包浏览器；可以使用GUI浏览网络数据、具有强大的显示过滤器、提供VoIP分析、对Kerberos、WEP、SSL/TLS等协议的解密支持等等。用户可以通过学习完整的Wireshark培训教程，以提高网络扫描技能。<br />
<br />
'''传送门：'''<br />
<br />
'''<nowiki>https://www.wireshark.org/</nowiki>'''<br />
<br />
'''09'''<br />
<br />
'''Aircrack-ng'''<br />
<br />
Aircrack-ng是帮助企业组织检测WiFi网络安全漏洞的强大工具。它可以用于无线网络安全审计，并提供WiFi安全和控制方面的建议。Aircrack-ng可以通过捕获数据包来处理丢失的密钥。目前，Aircrack-ng支持的操作系统包括NetBSD、Windows、OS X、Linux和Solaris。<br />
<br />
'''传送门：'''<br />
<br />
'''<nowiki>https://www.aircrack-ng.org/</nowiki>'''<br />
<br />
'''10'''<br />
<br />
'''Comodo HackerProof'''<br />
<br />
Comodo HackerProof是一款领先的自动化漏洞扫描程序，具有强大的漏洞检测功能，可以让企业每天开展漏洞扫描工作。该工具的应用特点是包含了PCI扫描选项，防止drive-by攻击选项，以及有助于下一代网站扫描的站点检查器技术。此外，Comodo HackerProof还为用户提供了一个指标，用于增加他们在扫描过程中的安全感。<br />
<br />
'''传送门：'''<br />
<br />
'''<nowiki>https://www.comodo.com/hackerproof/</nowiki>'''<br />
<br />
原文链接：<br />
<br />
<nowiki>https://gbhackers.com/vulnerability-scanner-tools/</nowiki><br />
<br />
<br />
<br />
<br />
== 1. Arachni ==<br />
Arachni是一款基于Ruby框架构建的高性能安全扫描程序，适用于现代Web应用程序。它可用于Mac，Windows和Linux的便携式二进制文件<br />
<br />
Arachnin能适用于下面的平台和语言<br />
<br />
* Windows, Solaris, Linux, BSD, Unix<br />
* Nginx, Apache, Tomcat, IIS, Jetty<br />
* Java, Ruby, Python, ASP, PHP<br />
* Django, Rails, CherryPy, CakePHP, <nowiki>http://ASP.NET</nowiki> MVC, Symfony<br />
<br />
漏洞检测有下面这些：<br />
<br />
* NoSQL/Blind/SQL/Code/LDAP/Command/XPath injection<br />
* Cross-site request forgery<br />
* Path traversal<br />
* Local/Remote File inclusions<br />
* Response splitting<br />
* Cross-site scripting<br />
* Unvalidated DOM redirects<br />
* Source code disclosure<br />
<br />
可以选择使用HTML，XML，文本，JSON，YAML等格式的审计报告,Arachni可以利用插件将扫描范围扩展到下一个级别<br />
<br />
== 2. XssPy ==<br />
一个基于Python的XSS（跨站脚本）漏洞扫描器<br />
<br />
== 3. w3af ==<br />
w3af,从2006开始使用python开发的开源项目，可以用在window和linux环境下。<br />
<br />
w3af可以将有效载荷注入到标题，URL，cookie，查询字符串，后期数据等，以利用Web应用程序进行审计。它支持各种记录方法进行报告。例如：<br />
<br />
* CSV<br />
* HTML<br />
* Console<br />
* Text<br />
* XML<br />
* Email<br />
<br />
更多的功能可利用插件库<br />
<br />
== 4. Nikto ==<br />
Netsparker赞助的开源项目旨在发现Web服务器的配置错误，插件和网页漏洞。Nikto对6500多个风险项目进行综合测试。<br />
<br />
它支持HTTP代理，SSL，或NTLM身份验证等，并可以定义每个目标扫描的最大执行时间。<br />
<br />
Nikola也可以在Kali Linux中使用<br />
<br />
它看起来很有希望用于Intranet解决方案来查找Web服务器的安全风险<br />
<br />
== 5. Wfuzz ==<br />
Wfuzz（Web Fuzzer）是针对渗透测试的应用程序评估工具。您可以对任何字段的HTTP请求中的数据进行模糊处理，以利用该Web应用程序并审核Web应用程序。Wfuzz需要在要运行扫描的计算机上安装Python。<br />
<br />
== 6. OWASP ZAP ==<br />
ZAP（Zet Attack Proxy）是全球数百名志愿者积极更新的着名渗透测试工具之一。它是跨平台的基于Java的工具，可以在Raspberry Pi上运行。ZIP位于浏览器和Web应用程序之间，用于拦截和检查消息<br />
<br />
下面的一些值得一提的是ZAP的功能。<br />
<br />
* Fuzzer<br />
* Automated & passive scanner<br />
* Supports multiple scripting languages<br />
* Forced browsing<br />
<br />
强烈建议查看OWASP ZAP教程视频来学习<br />
<br />
== 7. Wapiti ==<br />
Wapiti扫描给定目标的网页，并寻找脚本和表单来注入数据，看看是否有漏洞。它不是一个源代码安全检查，而是执行黑盒扫描。<br />
<br />
它支持GET和POST HTTP方法，HTTP和HTTPS代理，多个认证等。<br />
<br />
== 8. Vega ==<br />
Vega由Subgraph开发，Subgraph是一个用Java编写的多平台支持工具，用于查找XSS，SQLi，RFI和许多其他漏洞。维加有良好的图形用户界面，并能够通过登录到具有给定凭据的应用程序来执行自动扫描。<br />
<br />
如果您是开发人员，则可以利用vega API创建新的攻击模块<br />
<br />
== 9. SQLmap ==<br />
利用SQLmap可以对数据库执行渗透测试来发现缺陷。<br />
<br />
它适用于任何操作系统上的Python 2.6或2.7。如果你正在寻找SQL注入和利用数据库，那么sqlmap会有帮助。<br />
<br />
== 10. Grabber ==<br />
它是基于Python的小工具，并且做得很不错。一些Grabber的功能是：<br />
<br />
* JavaScript源代码分析器 跨站点脚本，<br />
* SQL注入，<br />
* 盲注SQL PHP应用程序测试使用PHP-SAT<br />
<br />
== 11. Golismero ==<br />
管理和运行Wfuzz，DNS recon，sqlmap，OpenVas，机器人分析器等一些流行安全工具的框架。<br />
<br />
Golismero非常棒，它可以巩固来自其他工具的测试反馈，并合并显示一个单一的结果。<br />
<br />
== 12. OWASP Xenotix XSS ==<br />
OWASP的Xenotix XSS是一个用于查找和利用跨站点脚本的高级框架。它内置了三个智能模糊器，用于快速扫描和改进结果。<br />
<br />
它有数百个功能，我们可以看看这里列出的所有。<br />
<br />
网络安全对于在线业务至关重要，我希望上面列出的免费/开源漏洞扫描程序可以帮助您找到风险，以便在有人利用此漏洞之前减轻风险</div>Yuhttps://www.dnswiki.cn/index.php?title=%E9%A6%96%E9%A1%B5&diff=49首页2024-03-04T09:15:06Z<p>Yu：/* DNS软件 */</p>
<hr />
<div>== DNS ==<br />
*[[DNS是什么？]]<br />
<br />
*[[DNS历史]]<br />
<br />
*[[DNS记录类型]]<br />
<br />
<br />
<br />
== DNS技术 ==<br />
* [[DNS技术]]<br />
<br />
* [[DNS-RFC]]<br />
<br />
== DNS软件 ==<br />
*[[DNS 软件]]<br />
<br />
**[[BIND]]<br />
<br />
*** [[test]]<br />
<br />
**[[PowerDNS]]<br />
<br />
**[[PowerDNS]]<br />
<br />
== DNS安全 ==<br />
[[新闻-News]]<br />
<br />
[[DNS-CVEs]]<br />
<br />
== wiki 帮助 ==<br />
*表格<br />
https://www.mediawiki.org/wiki/Help:Tables/zh<br />
<br />
<br />
<br />
<br />
<strong>已安装MediaWiki。</strong><br />
<br />
请查阅[https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents 用户指导]以获取使用本wiki软件的信息。<br />
<br />
== 入门 ==<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings MediaWiki配置设置列表]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ/zh-hans MediaWiki常见问题]<br />
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki发布邮件列表]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources 本地化MediaWiki到您的语言]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam 了解如何在您的wiki上打击破坏]</div>Yuhttps://www.dnswiki.cn/index.php?title=%E9%A6%96%E9%A1%B5&diff=48首页2024-03-04T09:14:42Z<p>Yu：/* DNS软件 */</p>
<hr />
<div>== DNS ==<br />
*[[DNS是什么？]]<br />
<br />
*[[DNS历史]]<br />
<br />
*[[DNS记录类型]]<br />
<br />
<br />
<br />
== DNS技术 ==<br />
* [[DNS技术]]<br />
<br />
* [[DNS-RFC]]<br />
<br />
== DNS软件 ==<br />
*[[DNS 软件]]<br />
<br />
**[[BIND]]<br />
<br />
**[[PowerDNS]]<br />
<br />
**[[PowerDNS]]<br />
<br />
== DNS安全 ==<br />
[[新闻-News]]<br />
<br />
[[DNS-CVEs]]<br />
<br />
== wiki 帮助 ==<br />
*表格<br />
https://www.mediawiki.org/wiki/Help:Tables/zh<br />
<br />
<br />
<br />
<br />
<strong>已安装MediaWiki。</strong><br />
<br />
请查阅[https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents 用户指导]以获取使用本wiki软件的信息。<br />
<br />
== 入门 ==<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings MediaWiki配置设置列表]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ/zh-hans MediaWiki常见问题]<br />
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki发布邮件列表]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources 本地化MediaWiki到您的语言]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam 了解如何在您的wiki上打击破坏]</div>Yuhttps://www.dnswiki.cn/index.php?title=%E9%A6%96%E9%A1%B5&diff=47首页2024-03-04T09:14:22Z<p>Yu：/* DNS技术 */</p>
<hr />
<div>== DNS ==<br />
*[[DNS是什么？]]<br />
<br />
*[[DNS历史]]<br />
<br />
*[[DNS记录类型]]<br />
<br />
<br />
<br />
== DNS技术 ==<br />
* [[DNS技术]]<br />
<br />
* [[DNS-RFC]]<br />
<br />
== DNS软件 ==<br />
#[[DNS 软件]]<br />
<br />
**[[BIND]]<br />
<br />
**[[PowerDNS]]<br />
<br />
**[[PowerDNS]]<br />
<br />
== DNS安全 ==<br />
[[新闻-News]]<br />
<br />
[[DNS-CVEs]]<br />
<br />
== wiki 帮助 ==<br />
*表格<br />
https://www.mediawiki.org/wiki/Help:Tables/zh<br />
<br />
<br />
<br />
<br />
<strong>已安装MediaWiki。</strong><br />
<br />
请查阅[https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents 用户指导]以获取使用本wiki软件的信息。<br />
<br />
== 入门 ==<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings MediaWiki配置设置列表]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ/zh-hans MediaWiki常见问题]<br />
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki发布邮件列表]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources 本地化MediaWiki到您的语言]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam 了解如何在您的wiki上打击破坏]</div>Yuhttps://www.dnswiki.cn/index.php?title=CVE-2023-5680&diff=46CVE-2023-56802024-03-04T09:02:52Z<p>Yu：创建页面，内容为“CVE: CVE-2023-5680 Title: Cleaning an ECS-enabled cache may cause excessive CPU load Document version: 2.0 Posting date: 13 February 2024 Program impacted: BIND 9 Versions affected: BIND Supported Preview Edition 9.11.3-S1 -> 9.11.37-S1 9.16.8-S1 -> 9.16.45-S1 9.18.11-S1 -> 9.18.21-S1 (Versions prior to 9.11.37-S1 were not assessed.) Severity: Medium Exploitable: Remotely Description: If a resolver cache has a very large number of ECS records stored…”</p>
<hr />
<div>CVE: CVE-2023-5680<br />
<br />
Title: Cleaning an ECS-enabled cache may cause excessive CPU load<br />
<br />
Document version: 2.0<br />
<br />
Posting date: 13 February 2024<br />
<br />
Program impacted: BIND 9<br />
<br />
Versions affected:<br />
<br />
BIND Supported Preview Edition<br />
<br />
9.11.3-S1 -> 9.11.37-S1<br />
9.16.8-S1 -> 9.16.45-S1<br />
9.18.11-S1 -> 9.18.21-S1<br />
(Versions prior to 9.11.37-S1 were not assessed.)<br />
<br />
Severity: Medium<br />
<br />
Exploitable: Remotely<br />
<br />
Description:<br />
<br />
If a resolver cache has a very large number of ECS records stored for the same name, the process of cleaning the cache database node for this name can significantly impair query performance.<br />
<br />
Impact:<br />
<br />
By sending specific queries to a resolver, an attacker can degrade named's query-handling performance. In the worst-case scenario, a resolver can become entirely unresponsive.<br />
<br />
CVSS Score: 5.3<br />
<br />
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L<br />
<br />
For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L&version=3.1.<br />
<br />
Workarounds:<br />
<br />
There is no workaround for this issue other than disabling the ECS feature entirely.<br />
<br />
Active exploits:<br />
<br />
We are not aware of any active exploits.<br />
<br />
Solution:<br />
<br />
Upgrade to the patched release most closely related to your current version of BIND 9:<br />
<br />
BIND Supported Preview Edition is a special feature preview branch of BIND provided to eligible ISC support customers.<br />
<br />
9.16.48-S1<br />
9.18.24-S1<br />
Acknowledgments:<br />
<br />
ISC would like to thank Yann Kerherve and Ask Bjørn Hansen for bringing this vulnerability to our attention.<br />
<br />
Document revision history:<br />
<br />
1.0 Early Notification, 10 January 2024<br />
1.1 Revised Early Notification, 15 January 2024<br />
1.2 Revised the list of fixed versions, 11 February 2024<br />
2.0 Public disclosure, 13 February 2024<br />
Related documents:<br />
<br />
See our BIND 9 Security Vulnerability Matrix for a complete listing of security vulnerabilities and versions affected.<br />
<br />
Do you still have questions? Questions regarding this advisory should be mailed to bind-security@isc.org or posted as confidential GitLab issues at https://gitlab.isc.org/isc-projects/bind9/-/issues/new?issue[confidential]=true.<br />
<br />
Note:<br />
<br />
ISC patches only currently supported versions. When possible we indicate EOL versions affected. For current information on which versions are actively supported, please see https://www.isc.org/download/.<br />
<br />
ISC Security Vulnerability Disclosure Policy:<br />
<br />
Details of our current security advisory policy and practice can be found in the ISC Software Defect and Security Vulnerability Disclosure Policy at https://kb.isc.org/docs/aa-00861.<br />
<br />
The Knowledgebase article https://kb.isc.org/docs/cve-2023-5680 is the complete and official security advisory document.<br />
<br />
Legal Disclaimer:<br />
<br />
Internet Systems Consortium (ISC) is providing this notice on an "AS IS" basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors.</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-CVEs&diff=45DNS-CVEs2024-03-04T09:02:35Z<p>Yu：</p>
<hr />
<div>[[CVE-2023-50387]] : KeyTrap - Extreme CPU consumption in DNSSEC validator<br />
<br />
[[CVE-2023-50868]] : Preparing an NSEC3 closest encloser proof can exhaust CPU resources<br />
<br />
[[CVE-2023-6516]]: Specific recursive query patterns may lead to an out-of-memory condition<br />
<br />
[[CVE-2023-5680]]: Cleaning an ECS-enabled cache may cause excessive CPU load</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-CVEs&diff=44DNS-CVEs2024-03-04T09:02:24Z<p>Yu：</p>
<hr />
<div>[[CVE-2023-50387]] : KeyTrap - Extreme CPU consumption in DNSSEC validator<br />
[[CVE-2023-50868]] : Preparing an NSEC3 closest encloser proof can exhaust CPU resources<br />
[[CVE-2023-6516]]: Specific recursive query patterns may lead to an out-of-memory condition<br />
[[CVE-2023-5680]]: Cleaning an ECS-enabled cache may cause excessive CPU load</div>Yuhttps://www.dnswiki.cn/index.php?title=CVE-2023-6516&diff=43CVE-2023-65162024-03-04T09:01:35Z<p>Yu：创建页面，内容为“CVE: CVE-2023-6516 Title: Specific recursive query patterns may lead to an out-of-memory condition Document version: 2.0 Posting date: 13 February 2024 Program impacted: BIND 9 Versions affected: BIND 9.16.0 -> 9.16.45 BIND Supported Preview Edition 9.16.8-S1 -> 9.16.45-S1 Severity: High Exploitable: Remotely Description: To keep its cache database efficient, named running as a recursive resolver occasionally attempts to clean up the database. It use…”</p>
<hr />
<div>CVE: CVE-2023-6516<br />
<br />
Title: Specific recursive query patterns may lead to an out-of-memory condition<br />
<br />
Document version: 2.0<br />
<br />
Posting date: 13 February 2024<br />
<br />
Program impacted: BIND 9<br />
<br />
Versions affected:<br />
<br />
BIND<br />
<br />
9.16.0 -> 9.16.45<br />
BIND Supported Preview Edition<br />
<br />
9.16.8-S1 -> 9.16.45-S1<br />
Severity: High<br />
<br />
Exploitable: Remotely<br />
<br />
Description:<br />
<br />
To keep its cache database efficient, named running as a recursive resolver occasionally attempts to clean up the database. It uses several methods, including some that are asynchronous: a small chunk of memory pointing to the cache element that can be cleaned up is first allocated and then queued for later processing. It was discovered that if the resolver is continuously processing query patterns triggering this type of cache-database maintenance, named may not be able to handle the cleanup events in a timely manner. This in turn enables the list of queued cleanup events to grow infinitely large over time, allowing the configured max-cache-size limit to be significantly exceeded.<br />
<br />
Impact:<br />
<br />
By exploiting this flaw, an attacker can cause the amount of memory used by a named resolver to go well beyond the configured max-cache-size limit. The effectiveness of the attack depends on a number of environmental factors, but in the worst case the attacker can exhaust all available memory on the host running named, leading to a denial-of-service condition.<br />
<br />
CVSS Score: 7.5<br />
<br />
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H<br />
<br />
For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H&version=3.1.<br />
<br />
Workarounds:<br />
<br />
No workarounds known.<br />
<br />
Active exploits:<br />
<br />
We are not aware of any active exploits.<br />
<br />
Solution:<br />
<br />
Upgrade to the patched release most closely related to your current version of BIND 9:<br />
<br />
9.16.48<br />
BIND Supported Preview Edition is a special feature preview branch of BIND provided to eligible ISC support customers.<br />
<br />
9.16.48-S1<br />
Acknowledgments:<br />
<br />
ISC would like to thank Infoblox for bringing this vulnerability to our attention.<br />
<br />
Document revision history:<br />
<br />
1.0 Early Notification, 10 January 2024<br />
1.1 Revised Early Notification, 15 January 2024<br />
1.2 Revised the list of fixed versions, 11 February 2024<br />
2.0 Public disclosure, 13 February 2024<br />
Related documents:<br />
<br />
See our BIND 9 Security Vulnerability Matrix for a complete listing of security vulnerabilities and versions affected.<br />
<br />
Do you still have questions? Questions regarding this advisory should be mailed to bind-security@isc.org or posted as confidential GitLab issues at https://gitlab.isc.org/isc-projects/bind9/-/issues/new?issue[confidential]=true.<br />
<br />
Note:<br />
<br />
ISC patches only currently supported versions. When possible we indicate EOL versions affected. For current information on which versions are actively supported, please see https://www.isc.org/download/.<br />
<br />
ISC Security Vulnerability Disclosure Policy:<br />
<br />
Details of our current security advisory policy and practice can be found in the ISC Software Defect and Security Vulnerability Disclosure Policy at https://kb.isc.org/docs/aa-00861.<br />
<br />
The Knowledgebase article https://kb.isc.org/docs/cve-2023-6516 is the complete and official security advisory document.<br />
<br />
Legal Disclaimer:<br />
<br />
Internet Systems Consortium (ISC) is providing this notice on an "AS IS" basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors.</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-CVEs&diff=42DNS-CVEs2024-03-04T09:01:23Z<p>Yu：</p>
<hr />
<div>[[CVE-2023-50387]] : KeyTrap - Extreme CPU consumption in DNSSEC validator<br />
<br />
[[CVE-2023-50868]] : Preparing an NSEC3 closest encloser proof can exhaust CPU resources<br />
<br />
[[CVE-2023-6516]]: Specific recursive query patterns may lead to an out-of-memory condition</div>Yuhttps://www.dnswiki.cn/index.php?title=CVE-2023-50868&diff=41CVE-2023-508682024-03-04T09:00:41Z<p>Yu：创建页面，内容为“CVE: CVE-2023-50868 Title: Preparing an NSEC3 closest encloser proof can exhaust CPU resources Document version: 2.0 Posting date: 13 February 2024 Program impacted: BIND 9 Versions affected: BIND 9.0.0 -> 9.16.46 9.18.0 -> 9.18.22 9.19.0 -> 9.19.20 (Versions prior to 9.11.37 were not assessed.) BIND Supported Preview Edition 9.9.3-S1 -> 9.16.46-S1 9.18.11-S1 -> 9.18.22-S1 (Versions prior to 9.11.37-S1 were not assessed.) Severity: High Exploitable:…”</p>
<hr />
<div>CVE: CVE-2023-50868<br />
<br />
Title: Preparing an NSEC3 closest encloser proof can exhaust CPU resources<br />
<br />
Document version: 2.0<br />
<br />
Posting date: 13 February 2024<br />
<br />
Program impacted: BIND 9<br />
<br />
Versions affected:<br />
<br />
BIND<br />
<br />
9.0.0 -> 9.16.46<br />
9.18.0 -> 9.18.22<br />
9.19.0 -> 9.19.20<br />
(Versions prior to 9.11.37 were not assessed.)<br />
<br />
BIND Supported Preview Edition<br />
<br />
9.9.3-S1 -> 9.16.46-S1<br />
9.18.11-S1 -> 9.18.22-S1<br />
(Versions prior to 9.11.37-S1 were not assessed.)<br />
<br />
Severity: High<br />
<br />
Exploitable: Remotely<br />
<br />
Description:<br />
<br />
The processing of responses coming from DNSSEC-signed zones using NSEC3 can cause CPU exhaustion on a DNSSEC-validating resolver.<br />
<br />
Impact:<br />
<br />
By flooding the target resolver with queries exploiting this flaw an attacker can significantly impair the resolver's performance, effectively denying legitimate clients access to the DNS resolution service.<br />
<br />
CVSS Score: 7.5<br />
<br />
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H<br />
<br />
For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H&version=3.1.<br />
<br />
Workarounds:<br />
<br />
Although this is not recommended, disabling DNSSEC validation entirely will remove the vulnerability. We instead strongly advise installing one of the versions of BIND listed below, in which an exceptionally complex DNSSEC validation will no longer impede other server workload.<br />
<br />
We also recommend that authoritative server operators follow Best Current Practice document RFC 9276 ("Guidance for NSEC3 Parameter Settings"). Failure to adopt the RFC 9276 guidance may lead to future problems when DNS resolvers start to enforce the recommendations more strictly.<br />
<br />
Active exploits:<br />
<br />
This flaw was discovered in internal testing. We are not aware of any active exploits.<br />
<br />
Solution:<br />
<br />
Upgrade to the patched release most closely related to your current version of BIND 9:<br />
<br />
9.16.48<br />
9.18.24<br />
9.19.21<br />
BIND Supported Preview Edition is a special feature preview branch of BIND provided to eligible ISC support customers.<br />
<br />
9.16.48-S1<br />
9.18.24-S1<br />
Document revision history:<br />
<br />
1.0 Early Notification, 6 February 2024<br />
1.1 Revised the list of fixed versions, 11 February 2024<br />
1.2 Expanded Description, Impact, and Workarounds sections, 12 February 2024<br />
2.0 Public disclosure, 13 February 2024<br />
Related documents:<br />
<br />
See our BIND 9 Security Vulnerability Matrix for a complete listing of security vulnerabilities and versions affected.<br />
<br />
Do you still have questions? Questions regarding this advisory should be mailed to bind-security@isc.org or posted as confidential GitLab issues at https://gitlab.isc.org/isc-projects/bind9/-/issues/new?issue[confidential]=true.<br />
<br />
Note:<br />
<br />
ISC patches only currently supported versions. When possible we indicate EOL versions affected. For current information on which versions are actively supported, please see https://www.isc.org/download/.<br />
<br />
ISC Security Vulnerability Disclosure Policy:<br />
<br />
Details of our current security advisory policy and practice can be found in the ISC Software Defect and Security Vulnerability Disclosure Policy at https://kb.isc.org/docs/aa-00861.<br />
<br />
The Knowledgebase article https://kb.isc.org/docs/cve-2023-50868 is the complete and official security advisory document.<br />
<br />
Legal Disclaimer:<br />
<br />
Internet Systems Consortium (ISC) is providing this notice on an "AS IS" basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors.</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-CVEs&diff=40DNS-CVEs2024-03-04T09:00:19Z<p>Yu：</p>
<hr />
<div>[[CVE-2023-50387]] : KeyTrap - Extreme CPU consumption in DNSSEC validator<br />
<br />
[[CVE-2023-50868]] : Preparing an NSEC3 closest encloser proof can exhaust CPU resources</div>Yuhttps://www.dnswiki.cn/index.php?title=CVE-2023-50387&diff=39CVE-2023-503872024-03-04T08:59:06Z<p>Yu：创建页面，内容为“ CVE: CVE-2023-50387 Title: KeyTrap - Extreme CPU consumption in DNSSEC validator Document version: 2.0 Posting date: 13 February 2024 Program impacted: BIND 9 Versions affected: BIND 9.0.0 -> 9.16.46 9.18.0 -> 9.18.22 9.19.0 -> 9.19.20 (Versions prior to 9.11.37 were not assessed.) BIND Supported Preview Edition 9.9.3-S1 -> 9.16.46-S1 9.18.11-S1 -> 9.18.22-S1 (Versions prior to 9.11.37-S1 were not assessed.) Severity: High Exploitable: Remotely Des…”</p>
<hr />
<div><br />
CVE: CVE-2023-50387<br />
<br />
Title: KeyTrap - Extreme CPU consumption in DNSSEC validator<br />
<br />
Document version: 2.0<br />
<br />
Posting date: 13 February 2024<br />
<br />
Program impacted: BIND 9<br />
<br />
Versions affected:<br />
<br />
BIND<br />
<br />
9.0.0 -> 9.16.46<br />
9.18.0 -> 9.18.22<br />
9.19.0 -> 9.19.20<br />
(Versions prior to 9.11.37 were not assessed.)<br />
<br />
BIND Supported Preview Edition<br />
<br />
9.9.3-S1 -> 9.16.46-S1<br />
9.18.11-S1 -> 9.18.22-S1<br />
(Versions prior to 9.11.37-S1 were not assessed.)<br />
<br />
Severity: High<br />
<br />
Exploitable: Remotely<br />
<br />
Description:<br />
<br />
The processing of responses coming from specially crafted DNSSEC-signed zones can cause CPU exhaustion on a DNSSEC-validating resolver.<br />
<br />
Impact:<br />
<br />
By flooding the target resolver with queries exploiting this flaw an attacker can significantly impair the resolver's performance, effectively denying legitimate clients access to the DNS resolution service.<br />
<br />
CVSS Score: 7.5<br />
<br />
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H<br />
<br />
For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H&version=3.1.<br />
<br />
Workarounds:<br />
<br />
Although this is not recommended, disabling DNSSEC validation entirely will remove the vulnerability. We instead strongly advise installing one of the versions of BIND listed below, in which an exceptionally complex DNSSEC validation will no longer impede other server workload.<br />
<br />
Active exploits:<br />
<br />
We are not aware of any active exploits.<br />
<br />
Solution:<br />
<br />
Upgrade to the patched release most closely related to your current version of BIND 9:<br />
<br />
9.16.48<br />
9.18.24<br />
9.19.21<br />
BIND Supported Preview Edition is a special feature preview branch of BIND provided to eligible ISC support customers.<br />
<br />
9.16.48-S1<br />
9.18.24-S1<br />
Acknowledgments:<br />
<br />
ISC would like to thank Elias Heftrig, Haya Schulmann, Niklas Vogel, and Michael Waidner from the German National Research Center for Applied Cybersecurity ATHENE for bringing this vulnerability to our attention.<br />
<br />
Document revision history:<br />
<br />
1.0 Early Notification, 6 February 2024<br />
1.1 Revised the list of fixed versions, 11 February 2024<br />
1.2 Expanded Description, Impact, and Workarounds sections, 12 February 2024<br />
2.0 Public disclosure, 13 February 2024<br />
Related documents:<br />
<br />
See our BIND 9 Security Vulnerability Matrix for a complete listing of security vulnerabilities and versions affected.<br />
<br />
Do you still have questions? Questions regarding this advisory should be mailed to bind-security@isc.org or posted as confidential GitLab issues at https://gitlab.isc.org/isc-projects/bind9/-/issues/new?issue[confidential]=true.<br />
<br />
Note:<br />
<br />
ISC patches only currently supported versions. When possible we indicate EOL versions affected. For current information on which versions are actively supported, please see https://www.isc.org/download/.<br />
<br />
ISC Security Vulnerability Disclosure Policy:<br />
<br />
Details of our current security advisory policy and practice can be found in the ISC Software Defect and Security Vulnerability Disclosure Policy at https://kb.isc.org/docs/aa-00861.<br />
<br />
The Knowledgebase article https://kb.isc.org/docs/cve-2023-50387 is the complete and official security advisory document.<br />
<br />
Legal Disclaimer:<br />
<br />
Internet Systems Consortium (ISC) is providing this notice on an "AS IS" basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors.</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-CVEs&diff=38DNS-CVEs2024-03-04T08:58:58Z<p>Yu：创建页面，内容为“CVE-2023-50387 : KeyTrap - Extreme CPU consumption in DNSSEC validator”</p>
<hr />
<div>[[CVE-2023-50387]] : KeyTrap - Extreme CPU consumption in DNSSEC validator</div>Yuhttps://www.dnswiki.cn/index.php?title=%E9%A6%96%E9%A1%B5&diff=37首页2024-03-04T08:56:10Z<p>Yu：</p>
<hr />
<div>== DNS ==<br />
*[[DNS是什么？]]<br />
<br />
*[[DNS历史]]<br />
<br />
*[[DNS记录类型]]<br />
<br />
<br />
<br />
== DNS技术 ==<br />
# [[DNS技术]]<br />
<br />
## [[DNS-RFC]]<br />
<br />
<br />
== DNS软件 ==<br />
#[[DNS 软件]]<br />
<br />
**[[BIND]]<br />
<br />
**[[PowerDNS]]<br />
<br />
**[[PowerDNS]]<br />
<br />
== DNS安全 ==<br />
[[新闻-News]]<br />
<br />
[[DNS-CVEs]]<br />
<br />
== wiki 帮助 ==<br />
*表格<br />
https://www.mediawiki.org/wiki/Help:Tables/zh<br />
<br />
<br />
<br />
<br />
<strong>已安装MediaWiki。</strong><br />
<br />
请查阅[https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents 用户指导]以获取使用本wiki软件的信息。<br />
<br />
== 入门 ==<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings MediaWiki配置设置列表]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ/zh-hans MediaWiki常见问题]<br />
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki发布邮件列表]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources 本地化MediaWiki到您的语言]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam 了解如何在您的wiki上打击破坏]</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-RFC&diff=36DNS-RFC2024-03-04T08:38:42Z<p>Yu：</p>
<hr />
<div># 基础DNS相关RFC<br />
<br />
* [[RFC 1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES]]<br />
* [[RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION]]<br />
<br />
== Basic DNS RFCs ==<br />
<br />
RFC Title Date Status Latest Ann.<br />
1034 Domain names - concepts and facilities November 1987 Internet Standard 2022-08-15<br />
1035 Domain names - implementation and specification November 1987 Internet Standard 2022-08-15<br />
1123 Requirements for Internet Hosts - Application and Support October 1989 Internet Standard <br />
1536 Common DNS Implementation Errors and Suggested Fixes October 1993 Informational <br />
1912 Common DNS Operational and Configuration Errors February 1996 Informational <br />
1982 Serial Number Arithmetic August 1996 Proposed Standard 2022-08-15<br />
1995 Incremental Zone Transfer in DNS August 1996 Proposed Standard 2022-08-15<br />
1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) August 1996 Proposed Standard 2022-08-15<br />
2136 Dynamic Updates in the Domain Name System (DNS UPDATE) April 1997 Proposed Standard 2022-08-15<br />
2181 Clarifications to the DNS Specification July 1997 Proposed Standard 2022-08-15<br />
2308 Negative Caching of DNS Queries (DNS NCACHE) March 1998 Proposed Standard 2022-08-15<br />
2930 Secret Key Establishment for DNS (TKEY RR) September 2000 Proposed Standard 2022-08-15<br />
2931 DNS Request and Transaction Signatures ( SIG(0)s ) September 2000 Proposed Standard 2022-08-15<br />
3597 Handling of Unknown DNS Resource Record (RR) Types September 2003 Proposed Standard 2022-08-15<br />
3901 DNS IPv6 Transport Operational Guidelines September 2004 Best Current Practice <br />
4343 Domain Name System (DNS) Case Insensitivity Clarification January 2006 Proposed Standard 2022-08-15<br />
4472 Operational Considerations and Issues with IPv6 DNS April 2006 Informational <br />
4501 Domain Name System Uniform Resource Identifiers May 2006 Proposed Standard <br />
4592 The Role of Wildcards in the Domain Name System July 2006 Proposed Standard 2022-08-15<br />
5001 DNS Name Server Identifier (NSID) Option August 2007 Proposed Standard 2022-08-15<br />
5358 Preventing Use of Recursive Nameservers in Reflector Attacks October 2008 Best Current Practice <br />
5452 Measures for Making DNS More Resilient against Forged Answers January 2009 Proposed Standard 2022-08-15<br />
5625 DNS Proxy Implementation Guidelines August 2009 Best Current Practice <br />
5936 DNS Zone Transfer Protocol (AXFR) June 2010 Proposed Standard 2022-08-15<br />
5966 DNS Transport over TCP - Implementation Requirements August 2010 Proposed Standard; Obsoleted by RFC 7766 <br />
6303 Locally Served DNS Zones July 2011 Best Current Practice <br />
6604 xNAME RCODE and Status Bits Clarification April 2012 Proposed Standard 2022-08-15<br />
6672 DNAME Redirection in the DNS June 2012 Proposed Standard 2022-08-15<br />
6698 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA August 2012 Proposed Standard 2022-08-15<br />
6761 Special-Use Domain Names February 2013 Proposed Standard <br />
6762 Multicast DNS February 2013 Proposed Standard <br />
6891 Extension Mechanisms for DNS (EDNS(0)) April 2013 Internet Standard 2022-08-15<br />
6895 Domain Name System (DNS) IANA Considerations April 2013 Best Current Practice <br />
7218 Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE) April 2014 Proposed Standard <br />
7477 Child-to-Parent Synchronization in DNS March 2015 Proposed Standard 2022-08-15<br />
7534 AS112 Nameserver Operations May 2015 Informational <br />
7671 The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance October 2015 Proposed Standard <br />
7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) October 2015 Proposed Standard <br />
7673 Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records October 2015 Proposed Standard <br />
7686 The ".onion" Special-Use Domain Name October 2015 Proposed Standard <br />
7719 DNS Terminology December 2015 Informational; Obsoleted by RFC 8499 <br />
7766 DNS Transport over TCP - Implementation Requirements March 2016 Proposed Standard 2022-08-15<br />
7816 DNS Query Name Minimisation to Improve Privacy March 2016 Experimental; Obsoleted by RFC 9156 <br />
7828 The edns-tcp-keepalive EDNS0 Option April 2016 Proposed Standard 2022-08-15<br />
7858 Specification for DNS over Transport Layer Security (TLS) May 2016 Proposed Standard 2022-08-15<br />
7871 Client Subnet in DNS Queries May 2016 Informational <br />
7873 Domain Name System (DNS) Cookies May 2016 Proposed Standard <br />
7901 CHAIN Query Requests in DNS June 2016 Experimental <br />
7929 DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP August 2016 Experimental 2022-08-15<br />
8020 NXDOMAIN: There Really Is Nothing Underneath November 2016 Proposed Standard <br />
8094 DNS over Datagram Transport Layer Security (DTLS) February 2017 Experimental <br />
8162 Using Secure DNS to Associate Certificates with Domain Names for S/MIME May 2017 Experimental <br />
8427 Representing DNS Messages in JSON July 2018 Informational <br />
8467 Padding Policies for Extension Mechanisms for DNS (EDNS(0)) October 2018 Experimental <br />
8482 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY January 2019 Proposed Standard <br />
8483 Yeti DNS Testbed October 2018 Informational <br />
8484 DNS Queries over HTTPS (DoH) October 2018 Proposed Standard 2022-08-15<br />
8490 DNS Stateful Operations March 2019 Proposed Standard <br />
8499 DNS Terminology January 2019 Best Current Practice <br />
8501 Reverse DNS in IPv6 for Internet Service Providers November 2018 Informational <br />
8552 Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves March 2019 Best Current Practice <br />
8618 Compacted-DNS (C-DNS): A Format for DNS Packet Capture September 2019 Proposed Standard <br />
8767 Serving Stale Data to Improve DNS Resiliency March 2020 Proposed Standard <br />
8906 A Common Operational Problem in DNS Servers: Failure to Communicate September 2020 Best Current Practice <br />
8932 Recommendations for DNS Privacy Service Operators October 2020 Best Current Practice <br />
8945 Secret Key Transaction Authentication for DNS (TSIG) November 2020 Internet Standard 2022-08-15<br />
8976 Message Digest for DNS Zones February 2021 Proposed Standard <br />
9018 Interoperable Domain Name System (DNS) Server Cookies April 2021 Proposed Standard <br />
9076 DNS Privacy Considerations July 2021 Informational <br />
9103 DNS Zone Transfer over TLS August 2021 Proposed Standard 2022-08-15<br />
9108 YANG Types for DNS Classes and Resource Record Types September 2021 Proposed Standard <br />
9156 DNS Query Name Minimisation to Improve Privacy November 2021 Proposed Standard 2018-07-16<br />
9210 DNS Transport over TCP - Operational Requirements March 2022 Best Current Practice <br />
9250 DNS over Dedicated QUIC Connections May 2022 Proposed Standard <br />
<br />
<br />
== RFCs Related to DNSSEC ==<br />
<br />
RFC Title Date Status Latest Ann.<br />
9364 DNS Security Extensions (DNSSEC) February 2023 Best Current Practice <br />
3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) May 2001 Proposed Standard 2022-08-15<br />
4033 DNS Security Introduction and Requirements March 2005 Proposed Standard 2022-08-15<br />
4034 Resource Records for the DNS Security Extensions March 2005 Proposed Standard 2022-08-15<br />
4035 Protocol Modifications for the DNS Security Extensions March 2005 Proposed Standard 2022-08-15<br />
3757 Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag April 2004 Proposed Standard; Obsoleted by RFC 4033, RFC 4034, RFC 4035 <br />
4470 Minimally Covering NSEC Records and DNSSEC On-line Signing April 2006 Proposed Standard 2022-08-15<br />
4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) May 2006 Proposed Standard 2022-08-15<br />
4955 DNS Security (DNSSEC) Experiments July 2007 Proposed Standard <br />
4986 Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover August 2007 Informational <br />
5011 Automated Updates of DNS Security (DNSSEC) Trust Anchors September 2007 Internet Standard 2022-08-15<br />
5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence March 2008 Proposed Standard 2022-08-15<br />
5702 Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC October 2009 Proposed Standard 2022-08-15<br />
6014 Cryptographic Algorithm Identifier Allocation for DNSSEC November 2010 Proposed Standard <br />
6605 Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC April 2012 Proposed Standard 2022-08-15<br />
6781 DNSSEC Operational Practices, Version 2 December 2012 Informational <br />
6840 Clarifications and Implementation Notes for DNS Security (DNSSEC) February 2013 Proposed Standard 2022-08-15<br />
6944 Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status April 2013 Proposed Standard; Obsoleted by RFC 8624 <br />
7129 Authenticated Denial of Existence in the DNS February 2014 Informational <br />
7344 Automating DNSSEC Delegation Trust Maintenance September 2014 Proposed Standard 2022-08-15<br />
7583 DNSSEC Key Rollover Timing Considerations October 2015 Informational 2022-08-15<br />
7958 DNSSEC Trust Anchor Publication for the Root Zone August 2016 Informational <br />
8027 DNSSEC Roadblock Avoidance November 2016 Best Current Practice <br />
8078 Managing DS Records from the Parent via CDS/CDNSKEY March 2017 Proposed Standard 2022-08-15<br />
8080 Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC February 2017 Proposed Standard 2022-08-15<br />
8145 Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) April 2017 Proposed Standard <br />
8198 Aggressive Use of DNSSEC-Validated Cache July 2017 Proposed Standard 2022-08-15<br />
8624 Algorithm Implementation Requirements and Usage Guidance for DNSSEC June 2019 Proposed Standard 2022-08-15<br />
9077 NSEC and NSEC3: TTLs and Aggressive Use July 2021 Proposed Standard <br />
9157 Revised IANA Considerations for DNSSEC December 2021 Proposed Standard <br />
9276 Guidance for NSEC3 Parameter Settings August 2022 Best Current Practice <br />
<br />
<br />
== RFCs Related to IDNA ==<br />
RFC Title Date Status Latest Ann.<br />
3454 Preparation of Internationalized Strings ("stringprep") December 2002 Proposed Standard; Obsoleted by RFC 7564 <br />
3490 Internationalizing Domain Names in Applications (IDNA) March 2003 Proposed Standard; Obsoleted by RFC 5890, RFC 5891 <br />
3491 Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) March 2003 Proposed Standard; Obsoleted by RFC 5891 <br />
3492 Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) March 2003 Proposed Standard 2022-08-15<br />
3743 Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean April 2004 Informational <br />
4690 Review and Recommendations for Internationalized Domain Names (IDNs) September 2006 Informational <br />
5890 Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework August 2010 Proposed Standard <br />
5891 Internationalized Domain Names in Applications (IDNA): Protocol August 2010 Proposed Standard 2022-08-15<br />
5892 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) August 2010 Proposed Standard <br />
5893 Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA) August 2010 Proposed Standard <br />
5894 Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale August 2010 Informational <br />
5895 Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008 September 2010 Informational <br />
7564 PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols May 2015 Proposed Standard; Obsoleted by RFC 8264 <br />
8264 PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols October 2017 Proposed Standard <br />
8753 Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions April 2020 Proposed Standard <br />
<br />
<br />
<br />
== RFCs Related to the Root Service ==<br />
RFC Title Date Status Latest Ann.<br />
7108 A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes January 2014 Informational <br />
7706 Decreasing Access Time to Root Servers by Running One on Loopback November 2015 Informational; Obsoleted by RFC 8806 <br />
7720 DNS Root Name Service Protocol and Deployment Requirements December 2015 Best Current Practice <br />
7958 DNSSEC Trust Anchor Publication for the Root Zone August 2016 Informational <br />
8109 Initializing a DNS Resolver with Priming Queries March 2017 Best Current Practice <br />
8806 Running a Root Server Local to a Resolver June 2020 Informational 2020-06-01<br />
<br />
<br />
== RFCs Related to the Name Registration and Lookup ==<br />
RFC Title Date Status Latest Ann.<br />
7482 Registration Data Access Protocol (RDAP) Query Format March 2015 Proposed Standard; Obsoleted by RFC 9082 <br />
7483 JSON Responses for the Registration Data Access Protocol (RDAP) March 2015 Proposed Standard; Obsoleted by RFC 9083 <br />
7484 Finding the Authoritative Registration Data (RDAP) Service March 2015 Proposed Standard; Obsoleted by RFC 9224 <br />
8056 Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping January 2017 Proposed Standard <br />
8063 Key Relay Mapping for the Extensible Provisioning Protocol February 2017 Proposed Standard <br />
8334 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) March 2018 Proposed Standard <br />
8495 Allocation Token Extension for the Extensible Provisioning Protocol (EPP) November 2018 Proposed Standard <br />
8521 Registration Data Access Protocol (RDAP) Object Tagging November 2018 Best Current Practice <br />
8543 Extensible Provisioning Protocol (EPP) Organization Mapping March 2019 Proposed Standard <br />
8544 Organization Extension for the Extensible Provisioning Protocol (EPP) April 2019 Proposed Standard <br />
8590 Change Poll Extension for the Extensible Provisioning Protocol (EPP) May 2019 Proposed Standard <br />
8748 Registry Fee Extension for the Extensible Provisioning Protocol (EPP) March 2020 Proposed Standard <br />
8807 Login Security Extension for the Extensible Provisioning Protocol (EPP) August 2020 Proposed Standard <br />
8909 Registry Data Escrow Specification November 2020 Proposed Standard <br />
8977 Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging January 2021 Proposed Standard <br />
8982 Registration Data Access Protocol (RDAP) Partial Response February 2021 Proposed Standard <br />
9022 Domain Name Registration Data (DNRD) Objects Mapping May 2021 Proposed Standard <br />
9038 Extensible Provisioning Protocol (EPP) Unhandled Namespaces May 2021 Proposed Standard <br />
9082 Registration Data Access Protocol (RDAP) Query Format June 2021 Internet Standard <br />
9083 JSON Responses for the Registration Data Access Protocol (RDAP) June 2021 Internet Standard <br />
9154 Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer December 2021 Proposed Standard <br />
9167 Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP) December 2021 Proposed Standard <br />
9224 Finding the Authoritative Registration Data Access Protocol (RDAP) Service March 2022 Internet Standard <br />
<br />
<br />
<br />
<br />
<br />
<br />
RFC 1034：域名 - 概念和设施<br />
RFC 1035：域名 - 实现和规范<br />
RFC 1122：Internet 主机的要求 - 通信层<br />
RFC 1123：Internet 主机的要求 - 应用程序和支持<br />
RFC 1876：在域名系统中表达位置信息的方法<br />
RFC 1995：DNS 中的增量区域传输<br />
RFC 1996：区域更改提示通知机制 (DNS 通知)<br />
RFC 2136：域名系统 (DNS 更新) 中的动态汇报<br />
RFC 2181：DNS 规范的说明<br />
RFC 2308：DNS 查询的负缓存 (DNS NCACHE)<br />
RFC 2535：域名系统安全扩展<br />
RFC 2782：用于指定服务位置的 DNS RR (DNS SRV)<br />
RFC 2845：DNS (TSIG) 的密钥事务身份验证<br />
RFC 2915：命名机构指针 (NAPTR) DNS 资源记录<br />
RFC 2930：为 DNS (TKEY RR) 建立机密密钥<br />
RFC 2931：DNS 请求和事务签名 ( SIG (0) s )<br />
RFC 3110：域名系统中的 RSA/SHA-1 SIG 和 RSA KEY (DNS)<br />
RFC 3445：限制 KEY 资源记录的范围 (RR)<br />
RFC 3596：支持 IP 版本 6 的 DNS 扩展<br />
RFC 3645：用于 DNS (GSS-TSIG) 的密钥事务身份验证的通用安全服务算法<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
# 基础DNS相关RFC<br />
<br />
<br />
<br />
第一行为标题<br />
<br />
{| class="wikitable"<br />
! 1 !! 2<br />
|-<br />
| 2 || 2<br />
|}<br />
<br />
<br />
第一行无标题<br />
<br />
{| class="wikitable"<br />
| 1 || 2<br />
|-<br />
| 2 || 2<br />
|}</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-RFC&diff=21DNS-RFC2024-03-04T05:55:03Z<p>Yu：</p>
<hr />
<div># 基础DNS相关RFC<br />
<br />
* [[RFC 1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES]]<br />
* [[RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION]]<br />
<br />
<br />
# 基础DNS相关RFC<br />
<br />
<br />
<br />
第一行为标题<br />
<br />
{| class="wikitable"<br />
! 1 !! 2<br />
|-<br />
| 2 || 2<br />
|}<br />
<br />
<br />
第一行无标题<br />
<br />
{| class="wikitable"<br />
| 1 || 2<br />
|-<br />
| 2 || 2<br />
|}</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-RFC&diff=20DNS-RFC2024-03-04T05:53:40Z<p>Yu：</p>
<hr />
<div># 基础DNS相关RFC<br />
<br />
* [[RFC 1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES]]<br />
* [[RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION]]<br />
<br />
<br />
# 基础DNS相关RFC<br />
<br />
<br />
<br />
{| class="wikitable"<br />
! 1 !! 2<br />
|-<br />
| 2 || 2<br />
|}</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-RFC&diff=19DNS-RFC2024-03-04T05:53:00Z<p>Yu：</p>
<hr />
<div># 基础DNS相关RFC<br />
<br />
* [[RFC 1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES]]<br />
* [[RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION]]<br />
<br />
<br />
# 基础DNS相关RFC<br />
<br />
<br />
<br />
{| class="wikitable"<br />
!sdfasdf !! <br />
sdfasd|-<br />
| 123123 || <br />
asdfasdfas|}</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-RFC&diff=18DNS-RFC2024-03-04T05:52:39Z<p>Yu：</p>
<hr />
<div># 基础DNS相关RFC<br />
<br />
* [[RFC 1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES]]<br />
* [[RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION]]<br />
<br />
<br />
# 基础DNS相关RFC<br />
<br />
<br />
<br />
{| class="wikitable"<br />
! !! <br />
|-<br />
| 123123 || <br />
asdfasdfas|}</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-RFC&diff=17DNS-RFC2024-03-04T05:52:21Z<p>Yu：</p>
<hr />
<div># 基础DNS相关RFC<br />
<br />
* [[RFC 1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES]]<br />
* [[RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION]]<br />
<br />
<br />
# 基础DNS相关RFC<br />
<br />
<br />
<br />
{| class="wikitable"<br />
! !! <br />
|-<br />
| 123123 |12312312| <br />
|}</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-RFC&diff=16DNS-RFC2024-03-04T05:52:02Z<p>Yu：</p>
<hr />
<div># 基础DNS相关RFC<br />
<br />
* [[RFC 1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES]]<br />
* [[RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION]]<br />
<br />
<br />
# 基础DNS相关RFC<br />
<br />
<br />
<br />
{| class="wikitable"<br />
! !! <br />
|-<br />
| || <br />
|}</div>Yuhttps://www.dnswiki.cn/index.php?title=%E9%A6%96%E9%A1%B5&diff=15首页2024-03-04T05:36:30Z<p>Yu：</p>
<hr />
<div>*[[DNS-RFC]]<br />
<br />
*[[DNS 软件]]<br />
<br />
<br />
**[[BIND]]<br />
<br />
**[[PowerDNS]]<br />
<br />
**[[PowerDNS]]<br />
<br />
<br />
<strong>已安装MediaWiki。</strong><br />
<br />
请查阅[https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents 用户指导]以获取使用本wiki软件的信息。<br />
<br />
== 入门 ==<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings MediaWiki配置设置列表]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ/zh-hans MediaWiki常见问题]<br />
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki发布邮件列表]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources 本地化MediaWiki到您的语言]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam 了解如何在您的wiki上打击破坏]<br />
<br />
<br />
<br />
kjhkh<br />
<br />
<br />
jhk<br />
<br />
kjk<br />
kjhk<br />
<br />
kjhkjh<br />
<br />
hhjkhk<br />
<br />
kjhkh<br />
jhk<br />
<br />
kjk<br />
<br />
kjhk<br />
<br />
kjhkjh<br />
<br />
hhjkhk<br />
<br />
kjhkh<br />
<br />
jhk<br />
<br />
kjk<br />
<br />
kjhk<br />
<br />
kjhkjh<br />
<br />
hhjkhk<br />
<br />
kjhkh<br />
<br />
jhk<br />
<br />
kjk<br />
<br />
kjhk<br />
<br />
kjhkjh<br />
<br />
hhjkhk</div>Yuhttps://www.dnswiki.cn/index.php?title=RFC_1035_-_DOMAIN_NAMES_-_IMPLEMENTATION_AND_SPECIFICATION&diff=14RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION2024-03-04T05:34:31Z<p>Yu：创建页面，内容为“[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page] Updated by: 1101, 1183, 1348, 1876, 1982, 1995, 1996, INTERNET STANDARD 2065, 2136, 2181, 2137, 2308, 2535, 2673, 2845, 3425, 3658, 4033, 4034, 4035, 4343, 5936, 5966, 6604, 7766, 8482, 8490, 8767 Errata Exist Network Working Group…”</p>
<hr />
<div>[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page] <br />
<br />
Updated by: 1101, 1183, 1348, 1876, 1982, 1995, 1996, INTERNET STANDARD<br />
2065, 2136, 2181, 2137, 2308, 2535, 2673, <br />
2845, 3425, 3658, 4033, 4034, 4035, 4343, <br />
5936, 5966, 6604, 7766, 8482, 8490, 8767 Errata Exist<br />
Network Working Group P. Mockapetris<br />
Request for Comments: 1035 ISI<br />
November 1987<br />
Obsoletes: RFCs 882, 883, 973<br />
<br />
DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION<br />
<br />
<br />
1. STATUS OF THIS MEMO<br />
<br />
This RFC describes the details of the domain system and protocol, and<br />
assumes that the reader is familiar with the concepts discussed in a<br />
companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].<br />
<br />
The domain system is a mixture of functions and data types which are an<br />
official protocol and functions and data types which are still<br />
experimental. Since the domain system is intentionally extensible, new<br />
data types and experimental behavior should always be expected in parts<br />
of the system beyond the official protocol. The official protocol parts<br />
include standard queries, responses and the Internet class RR data<br />
formats (e.g., host addresses). Since the previous RFC set, several<br />
definitions have changed, so some previous definitions are obsolete.<br />
<br />
Experimental or obsolete features are clearly marked in these RFCs, and<br />
such information should be used with caution.<br />
<br />
The reader is especially cautioned not to depend on the values which<br />
appear in examples to be current or complete, since their purpose is<br />
primarily pedagogical. Distribution of this memo is unlimited.<br />
<br />
Table of Contents<br />
<br />
1. STATUS OF THIS MEMO 1<br />
2. INTRODUCTION 3<br />
2.1. Overview 3<br />
2.2. Common configurations 4<br />
2.3. Conventions 7<br />
2.3.1. Preferred name syntax 7<br />
2.3.2. Data Transmission Order 8<br />
2.3.3. Character Case 9<br />
2.3.4. Size limits 10<br />
3. DOMAIN NAME SPACE AND RR DEFINITIONS 10<br />
3.1. Name space definitions 10<br />
3.2. RR definitions 11<br />
3.2.1. Format 11<br />
3.2.2. TYPE values 12<br />
3.2.3. QTYPE values 12<br />
3.2.4. CLASS values 13<br />
<br />
<br />
<br />
Mockapetris [Page 1]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
3.2.5. QCLASS values 13<br />
3.3. Standard RRs 13<br />
3.3.1. CNAME RDATA format 14<br />
3.3.2. HINFO RDATA format 14<br />
3.3.3. MB RDATA format (EXPERIMENTAL) 14<br />
3.3.4. MD RDATA format (Obsolete) 15<br />
3.3.5. MF RDATA format (Obsolete) 15<br />
3.3.6. MG RDATA format (EXPERIMENTAL) 16<br />
3.3.7. MINFO RDATA format (EXPERIMENTAL) 16<br />
3.3.8. MR RDATA format (EXPERIMENTAL) 17<br />
3.3.9. MX RDATA format 17<br />
3.3.10. NULL RDATA format (EXPERIMENTAL) 17<br />
3.3.11. NS RDATA format 18<br />
3.3.12. PTR RDATA format 18<br />
3.3.13. SOA RDATA format 19<br />
3.3.14. TXT RDATA format 20<br />
3.4. ARPA Internet specific RRs 20<br />
3.4.1. A RDATA format 20<br />
3.4.2. WKS RDATA format 21<br />
3.5. IN-ADDR.ARPA domain 22<br />
3.6. Defining new types, classes, and special namespaces 24<br />
4. MESSAGES 25<br />
4.1. Format 25<br />
4.1.1. Header section format 26<br />
4.1.2. Question section format 28<br />
4.1.3. Resource record format 29<br />
4.1.4. Message compression 30<br />
4.2. Transport 32<br />
4.2.1. UDP usage 32<br />
4.2.2. TCP usage 32<br />
5. MASTER FILES 33<br />
5.1. Format 33<br />
5.2. Use of master files to define zones 35<br />
5.3. Master file example 36<br />
6. NAME SERVER IMPLEMENTATION 37<br />
6.1. Architecture 37<br />
6.1.1. Control 37<br />
6.1.2. Database 37<br />
6.1.3. Time 39<br />
6.2. Standard query processing 39<br />
6.3. Zone refresh and reload processing 39<br />
6.4. Inverse queries (Optional) 40<br />
6.4.1. The contents of inverse queries and responses 40<br />
6.4.2. Inverse query and response example 41<br />
6.4.3. Inverse query processing 42<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 2]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
6.5. Completion queries and responses 42<br />
7. RESOLVER IMPLEMENTATION 43<br />
7.1. Transforming a user request into a query 43<br />
7.2. Sending the queries 44<br />
7.3. Processing responses 46<br />
7.4. Using the cache 47<br />
8. MAIL SUPPORT 47<br />
8.1. Mail exchange binding 48<br />
8.2. Mailbox binding (Experimental) 48<br />
9. REFERENCES and BIBLIOGRAPHY 50<br />
Index 54<br />
<br />
2. INTRODUCTION<br />
<br />
2.1. Overview<br />
<br />
The goal of domain names is to provide a mechanism for naming resources<br />
in such a way that the names are usable in different hosts, networks,<br />
protocol families, internets, and administrative organizations.<br />
<br />
From the user's point of view, domain names are useful as arguments to a<br />
local agent, called a resolver, which retrieves information associated<br />
with the domain name. Thus a user might ask for the host address or<br />
mail information associated with a particular domain name. To enable<br />
the user to request a particular type of information, an appropriate<br />
query type is passed to the resolver with the domain name. To the user,<br />
the domain tree is a single information space; the resolver is<br />
responsible for hiding the distribution of data among name servers from<br />
the user.<br />
<br />
From the resolver's point of view, the database that makes up the domain<br />
space is distributed among various name servers. Different parts of the<br />
domain space are stored in different name servers, although a particular<br />
data item will be stored redundantly in two or more name servers. The<br />
resolver starts with knowledge of at least one name server. When the<br />
resolver processes a user query it asks a known name server for the<br />
information; in return, the resolver either receives the desired<br />
information or a referral to another name server. Using these<br />
referrals, resolvers learn the identities and contents of other name<br />
servers. Resolvers are responsible for dealing with the distribution of<br />
the domain space and dealing with the effects of name server failure by<br />
consulting redundant databases in other servers.<br />
<br />
Name servers manage two kinds of data. The first kind of data held in<br />
sets called zones; each zone is the complete database for a particular<br />
"pruned" subtree of the domain space. This data is called<br />
authoritative. A name server periodically checks to make sure that its<br />
zones are up to date, and if not, obtains a new copy of updated zones<br />
<br />
<br />
<br />
Mockapetris [Page 3]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
from master files stored locally or in another name server. The second<br />
kind of data is cached data which was acquired by a local resolver.<br />
This data may be incomplete, but improves the performance of the<br />
retrieval process when non-local data is repeatedly accessed. Cached<br />
data is eventually discarded by a timeout mechanism.<br />
<br />
This functional structure isolates the problems of user interface,<br />
failure recovery, and distribution in the resolvers and isolates the<br />
database update and refresh problems in the name servers.<br />
<br />
2.2. Common configurations<br />
<br />
A host can participate in the domain name system in a number of ways,<br />
depending on whether the host runs programs that retrieve information<br />
from the domain system, name servers that answer queries from other<br />
hosts, or various combinations of both functions. The simplest, and<br />
perhaps most typical, configuration is shown below:<br />
<br />
Local Host | Foreign<br />
|<br />
+---------+ +----------+ | +--------+<br />
| | user queries | |queries | | |<br />
| User |-------------->| |---------|->|Foreign |<br />
| Program | | Resolver | | | Name |<br />
| |<--------------| |<--------|--| Server |<br />
| | user responses| |responses| | |<br />
+---------+ +----------+ | +--------+<br />
| A |<br />
cache additions | | references |<br />
V | |<br />
+----------+ |<br />
| cache | |<br />
+----------+ |<br />
<br />
User programs interact with the domain name space through resolvers; the<br />
format of user queries and user responses is specific to the host and<br />
its operating system. User queries will typically be operating system<br />
calls, and the resolver and its cache will be part of the host operating<br />
system. Less capable hosts may choose to implement the resolver as a<br />
subroutine to be linked in with every program that needs its services.<br />
Resolvers answer user queries with information they acquire via queries<br />
to foreign name servers and the local cache.<br />
<br />
Note that the resolver may have to make several queries to several<br />
different foreign name servers to answer a particular user query, and<br />
hence the resolution of a user query may involve several network<br />
accesses and an arbitrary amount of time. The queries to foreign name<br />
servers and the corresponding responses have a standard format described<br />
<br />
<br />
<br />
Mockapetris [Page 4]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
in this memo, and may be datagrams.<br />
<br />
Depending on its capabilities, a name server could be a stand alone<br />
program on a dedicated machine or a process or processes on a large<br />
timeshared host. A simple configuration might be:<br />
<br />
Local Host | Foreign<br />
|<br />
+---------+ |<br />
/ /| |<br />
+---------+ | +----------+ | +--------+<br />
| | | | |responses| | |<br />
| | | | Name |---------|->|Foreign |<br />
| Master |-------------->| Server | | |Resolver|<br />
| files | | | |<--------|--| |<br />
| |/ | | queries | +--------+<br />
+---------+ +----------+ |<br />
<br />
Here a primary name server acquires information about one or more zones<br />
by reading master files from its local file system, and answers queries<br />
about those zones that arrive from foreign resolvers.<br />
<br />
The DNS requires that all zones be redundantly supported by more than<br />
one name server. Designated secondary servers can acquire zones and<br />
check for updates from the primary server using the zone transfer<br />
protocol of the DNS. This configuration is shown below:<br />
<br />
Local Host | Foreign<br />
|<br />
+---------+ |<br />
/ /| |<br />
+---------+ | +----------+ | +--------+<br />
| | | | |responses| | |<br />
| | | | Name |---------|->|Foreign |<br />
| Master |-------------->| Server | | |Resolver|<br />
| files | | | |<--------|--| |<br />
| |/ | | queries | +--------+<br />
+---------+ +----------+ |<br />
A |maintenance | +--------+<br />
| +------------|->| |<br />
| queries | |Foreign |<br />
| | | Name |<br />
+------------------|--| Server |<br />
maintenance responses | +--------+<br />
<br />
In this configuration, the name server periodically establishes a<br />
virtual circuit to a foreign name server to acquire a copy of a zone or<br />
to check that an existing copy has not changed. The messages sent for<br />
<br />
<br />
<br />
Mockapetris [Page 5]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
these maintenance activities follow the same form as queries and<br />
responses, but the message sequences are somewhat different.<br />
<br />
The information flow in a host that supports all aspects of the domain<br />
name system is shown below:<br />
<br />
Local Host | Foreign<br />
|<br />
+---------+ +----------+ | +--------+<br />
| | user queries | |queries | | |<br />
| User |-------------->| |---------|->|Foreign |<br />
| Program | | Resolver | | | Name |<br />
| |<--------------| |<--------|--| Server |<br />
| | user responses| |responses| | |<br />
+---------+ +----------+ | +--------+<br />
| A |<br />
cache additions | | references |<br />
V | |<br />
+----------+ |<br />
| Shared | |<br />
| database | |<br />
+----------+ |<br />
A | |<br />
+---------+ refreshes | | references |<br />
/ /| | V |<br />
+---------+ | +----------+ | +--------+<br />
| | | | |responses| | |<br />
| | | | Name |---------|->|Foreign |<br />
| Master |-------------->| Server | | |Resolver|<br />
| files | | | |<--------|--| |<br />
| |/ | | queries | +--------+<br />
+---------+ +----------+ |<br />
A |maintenance | +--------+<br />
| +------------|->| |<br />
| queries | |Foreign |<br />
| | | Name |<br />
+------------------|--| Server |<br />
maintenance responses | +--------+<br />
<br />
The shared database holds domain space data for the local name server<br />
and resolver. The contents of the shared database will typically be a<br />
mixture of authoritative data maintained by the periodic refresh<br />
operations of the name server and cached data from previous resolver<br />
requests. The structure of the domain data and the necessity for<br />
synchronization between name servers and resolvers imply the general<br />
characteristics of this database, but the actual format is up to the<br />
local implementor.<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 6]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
Information flow can also be tailored so that a group of hosts act<br />
together to optimize activities. Sometimes this is done to offload less<br />
capable hosts so that they do not have to implement a full resolver.<br />
This can be appropriate for PCs or hosts which want to minimize the<br />
amount of new network code which is required. This scheme can also<br />
allow a group of hosts can share a small number of caches rather than<br />
maintaining a large number of separate caches, on the premise that the<br />
centralized caches will have a higher hit ratio. In either case,<br />
resolvers are replaced with stub resolvers which act as front ends to<br />
resolvers located in a recursive server in one or more name servers<br />
known to perform that service:<br />
<br />
Local Hosts | Foreign<br />
|<br />
+---------+ |<br />
| | responses |<br />
| Stub |<--------------------+ |<br />
| Resolver| | |<br />
| |----------------+ | |<br />
+---------+ recursive | | |<br />
queries | | |<br />
V | |<br />
+---------+ recursive +----------+ | +--------+<br />
| | queries | |queries | | |<br />
| Stub |-------------->| Recursive|---------|->|Foreign |<br />
| Resolver| | Server | | | Name |<br />
| |<--------------| |<--------|--| Server |<br />
+---------+ responses | |responses| | |<br />
+----------+ | +--------+<br />
| Central | |<br />
| cache | |<br />
+----------+ |<br />
<br />
In any case, note that domain components are always replicated for<br />
reliability whenever possible.<br />
<br />
2.3. Conventions<br />
<br />
The domain system has several conventions dealing with low-level, but<br />
fundamental, issues. While the implementor is free to violate these<br />
conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in<br />
ALL behavior observed from other hosts.<br />
<br />
2.3.1. Preferred name syntax<br />
<br />
The DNS specifications attempt to be as general as possible in the rules<br />
for constructing domain names. The idea is that the name of any<br />
existing object can be expressed as a domain name with minimal changes.<br />
<br />
<br />
<br />
Mockapetris [Page 7]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
However, when assigning a domain name for an object, the prudent user<br />
will select a name which satisfies both the rules of the domain system<br />
and any existing rules for the object, whether these rules are published<br />
or implied by existing programs.<br />
<br />
For example, when naming a mail domain, the user should satisfy both the<br />
rules of this memo and those in RFC-822. When creating a new host name,<br />
the old rules for HOSTS.TXT should be followed. This avoids problems<br />
when old software is converted to use domain names.<br />
<br />
The following syntax will result in fewer problems with many<br />
<br />
applications that use domain names (e.g., mail, TELNET).<br />
<br />
<domain> ::= <subdomain> | " "<br />
<br />
<subdomain> ::= <label> | <subdomain> "." <label><br />
<br />
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]<br />
<br />
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str><br />
<br />
<let-dig-hyp> ::= <let-dig> | "-"<br />
<br />
<let-dig> ::= <letter> | <digit><br />
<br />
<letter> ::= any one of the 52 alphabetic characters A through Z in<br />
upper case and a through z in lower case<br />
<br />
<digit> ::= any one of the ten digits 0 through 9<br />
<br />
Note that while upper and lower case letters are allowed in domain<br />
names, no significance is attached to the case. That is, two names with<br />
the same spelling but different case are to be treated as if identical.<br />
<br />
The labels must follow the rules for ARPANET host names. They must<br />
start with a letter, end with a letter or digit, and have as interior<br />
characters only letters, digits, and hyphen. There are also some<br />
restrictions on the length. Labels must be 63 characters or less.<br />
<br />
For example, the following strings identify hosts in the Internet:<br />
<br />
A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA<br />
<br />
2.3.2. Data Transmission Order<br />
<br />
The order of transmission of the header and data described in this<br />
document is resolved to the octet level. Whenever a diagram shows a<br />
<br />
<br />
<br />
Mockapetris [Page 8]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
group of octets, the order of transmission of those octets is the normal<br />
order in which they are read in English. For example, in the following<br />
diagram, the octets are transmitted in the order they are numbered.<br />
<br />
0 1<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| 1 | 2 |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| 3 | 4 |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| 5 | 6 |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
<br />
Whenever an octet represents a numeric quantity, the left most bit in<br />
the diagram is the high order or most significant bit. That is, the bit<br />
labeled 0 is the most significant bit. For example, the following<br />
diagram represents the value 170 (decimal).<br />
<br />
0 1 2 3 4 5 6 7<br />
+-+-+-+-+-+-+-+-+<br />
|1 0 1 0 1 0 1 0|<br />
+-+-+-+-+-+-+-+-+<br />
<br />
Similarly, whenever a multi-octet field represents a numeric quantity<br />
the left most bit of the whole field is the most significant bit. When<br />
a multi-octet quantity is transmitted the most significant octet is<br />
transmitted first.<br />
<br />
2.3.3. Character Case<br />
<br />
For all parts of the DNS that are part of the official protocol, all<br />
comparisons between character strings (e.g., labels, domain names, etc.)<br />
are done in a case-insensitive manner. At present, this rule is in<br />
force throughout the domain system without exception. However, future<br />
additions beyond current usage may need to use the full binary octet<br />
capabilities in names, so attempts to store domain names in 7-bit ASCII<br />
or use of special bytes to terminate labels, etc., should be avoided.<br />
<br />
When data enters the domain system, its original case should be<br />
preserved whenever possible. In certain circumstances this cannot be<br />
done. For example, if two RRs are stored in a database, one at x.y and<br />
one at X.Y, they are actually stored at the same place in the database,<br />
and hence only one casing would be preserved. The basic rule is that<br />
case can be discarded only when data is used to define structure in a<br />
database, and two names are identical when compared in a case<br />
insensitive manner.<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 9]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
Loss of case sensitive data must be minimized. Thus while data for x.y<br />
and X.Y may both be stored under a single location x.y or X.Y, data for<br />
a.x and B.X would never be stored under A.x, A.X, b.x, or b.X. In<br />
general, this preserves the case of the first label of a domain name,<br />
but forces standardization of interior node labels.<br />
<br />
Systems administrators who enter data into the domain database should<br />
take care to represent the data they supply to the domain system in a<br />
case-consistent manner if their system is case-sensitive. The data<br />
distribution system in the domain system will ensure that consistent<br />
representations are preserved.<br />
<br />
2.3.4. Size limits<br />
<br />
Various objects and parameters in the DNS have size limits. They are<br />
listed below. Some could be easily changed, others are more<br />
fundamental.<br />
<br />
labels 63 octets or less<br />
<br />
names 255 octets or less<br />
<br />
TTL positive values of a signed 32 bit number.<br />
<br />
UDP messages 512 octets or less<br />
<br />
3. DOMAIN NAME SPACE AND RR DEFINITIONS<br />
<br />
3.1. Name space definitions<br />
<br />
Domain names in messages are expressed in terms of a sequence of labels.<br />
Each label is represented as a one octet length field followed by that<br />
number of octets. Since every domain name ends with the null label of<br />
the root, a domain name is terminated by a length byte of zero. The<br />
high order two bits of every length octet must be zero, and the<br />
remaining six bits of the length field limit the label to 63 octets or<br />
less.<br />
<br />
To simplify implementations, the total length of a domain name (i.e.,<br />
label octets and label length octets) is restricted to 255 octets or<br />
less.<br />
<br />
Although labels can contain any 8 bit values in octets that make up a<br />
label, it is strongly recommended that labels follow the preferred<br />
syntax described elsewhere in this memo, which is compatible with<br />
existing host naming conventions. Name servers and resolvers must<br />
compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII<br />
with zero parity. Non-alphabetic codes must match exactly.<br />
<br />
<br />
<br />
Mockapetris [Page 10]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
3.2. RR definitions<br />
<br />
3.2.1. Format<br />
<br />
All RRs have the same top level format shown below:<br />
<br />
1 1 1 1 1 1<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| |<br />
/ /<br />
/ NAME /<br />
| |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| TYPE |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| CLASS |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| TTL |<br />
| |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| RDLENGTH |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|<br />
/ RDATA /<br />
/ /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
<br />
where:<br />
<br />
NAME an owner name, i.e., the name of the node to which this<br />
resource record pertains.<br />
<br />
TYPE two octets containing one of the RR TYPE codes.<br />
<br />
CLASS two octets containing one of the RR CLASS codes.<br />
<br />
TTL a 32 bit signed integer that specifies the time interval<br />
that the resource record may be cached before the source<br />
of the information should again be consulted. Zero<br />
values are interpreted to mean that the RR can only be<br />
used for the transaction in progress, and should not be<br />
cached. For example, SOA records are always distributed<br />
with a zero TTL to prohibit caching. Zero values can<br />
also be used for extremely volatile data.<br />
<br />
RDLENGTH an unsigned 16 bit integer that specifies the length in<br />
octets of the RDATA field.<br />
<br />
<br />
<br />
Mockapetris [Page 11]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
RDATA a variable length string of octets that describes the<br />
resource. The format of this information varies<br />
according to the TYPE and CLASS of the resource record.<br />
<br />
3.2.2. TYPE values<br />
<br />
TYPE fields are used in resource records. Note that these types are a<br />
subset of QTYPEs.<br />
<br />
TYPE value and meaning<br />
<br />
A 1 a host address<br />
<br />
NS 2 an authoritative name server<br />
<br />
MD 3 a mail destination (Obsolete - use MX)<br />
<br />
MF 4 a mail forwarder (Obsolete - use MX)<br />
<br />
CNAME 5 the canonical name for an alias<br />
<br />
SOA 6 marks the start of a zone of authority<br />
<br />
MB 7 a mailbox domain name (EXPERIMENTAL)<br />
<br />
MG 8 a mail group member (EXPERIMENTAL)<br />
<br />
MR 9 a mail rename domain name (EXPERIMENTAL)<br />
<br />
NULL 10 a null RR (EXPERIMENTAL)<br />
<br />
WKS 11 a well known service description<br />
<br />
PTR 12 a domain name pointer<br />
<br />
HINFO 13 host information<br />
<br />
MINFO 14 mailbox or mail list information<br />
<br />
MX 15 mail exchange<br />
<br />
TXT 16 text strings<br />
<br />
3.2.3. QTYPE values<br />
<br />
QTYPE fields appear in the question part of a query. QTYPES are a<br />
superset of TYPEs, hence all TYPEs are valid QTYPEs. In addition, the<br />
following QTYPEs are defined:<br />
<br />
<br />
<br />
Mockapetris [Page 12]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
AXFR 252 A request for a transfer of an entire zone<br />
<br />
MAILB 253 A request for mailbox-related records (MB, MG or MR)<br />
<br />
MAILA 254 A request for mail agent RRs (Obsolete - see MX)<br />
<br />
* 255 A request for all records<br />
<br />
3.2.4. CLASS values<br />
<br />
CLASS fields appear in resource records. The following CLASS mnemonics<br />
and values are defined:<br />
<br />
IN 1 the Internet<br />
<br />
CS 2 the CSNET class (Obsolete - used only for examples in<br />
some obsolete RFCs)<br />
<br />
CH 3 the CHAOS class<br />
<br />
HS 4 Hesiod [Dyer 87]<br />
<br />
3.2.5. QCLASS values<br />
<br />
QCLASS fields appear in the question section of a query. QCLASS values<br />
are a superset of CLASS values; every CLASS is a valid QCLASS. In<br />
addition to CLASS values, the following QCLASSes are defined:<br />
<br />
* 255 any class<br />
<br />
3.3. Standard RRs<br />
<br />
The following RR definitions are expected to occur, at least<br />
potentially, in all classes. In particular, NS, SOA, CNAME, and PTR<br />
will be used in all classes, and have the same format in all classes.<br />
Because their RDATA format is known, all domain names in the RDATA<br />
section of these RRs may be compressed.<br />
<br />
<domain-name> is a domain name represented as a series of labels, and<br />
terminated by a label with zero length. <character-string> is a single<br />
length octet followed by that number of characters. <character-string><br />
is treated as binary information, and can be up to 256 characters in<br />
length (including the length octet).<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 13]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
3.3.1. CNAME RDATA format<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
/ CNAME /<br />
/ /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
CNAME A <domain-name> which specifies the canonical or primary<br />
name for the owner. The owner name is an alias.<br />
<br />
CNAME RRs cause no additional section processing, but name servers may<br />
choose to restart the query at the canonical name in certain cases. See<br />
the description of name server logic in [RFC-1034] for details.<br />
<br />
3.3.2. HINFO RDATA format<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
/ CPU /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
/ OS /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
CPU A <character-string> which specifies the CPU type.<br />
<br />
OS A <character-string> which specifies the operating<br />
system type.<br />
<br />
Standard values for CPU and OS can be found in [RFC-1010].<br />
<br />
HINFO records are used to acquire general information about a host. The<br />
main use is for protocols such as FTP that can use special procedures<br />
when talking between machines or operating systems of the same type.<br />
<br />
3.3.3. MB RDATA format (EXPERIMENTAL)<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
/ MADNAME /<br />
/ /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
MADNAME A <domain-name> which specifies a host which has the<br />
specified mailbox.<br />
<br />
<br />
<br />
Mockapetris [Page 14]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
MB records cause additional section processing which looks up an A type<br />
RRs corresponding to MADNAME.<br />
<br />
3.3.4. MD RDATA format (Obsolete)<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
/ MADNAME /<br />
/ /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
MADNAME A <domain-name> which specifies a host which has a mail<br />
agent for the domain which should be able to deliver<br />
mail for the domain.<br />
<br />
MD records cause additional section processing which looks up an A type<br />
record corresponding to MADNAME.<br />
<br />
MD is obsolete. See the definition of MX and [RFC-974] for details of<br />
the new scheme. The recommended policy for dealing with MD RRs found in<br />
a master file is to reject them, or to convert them to MX RRs with a<br />
preference of 0.<br />
<br />
3.3.5. MF RDATA format (Obsolete)<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
/ MADNAME /<br />
/ /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
MADNAME A <domain-name> which specifies a host which has a mail<br />
agent for the domain which will accept mail for<br />
forwarding to the domain.<br />
<br />
MF records cause additional section processing which looks up an A type<br />
record corresponding to MADNAME.<br />
<br />
MF is obsolete. See the definition of MX and [RFC-974] for details ofw<br />
the new scheme. The recommended policy for dealing with MD RRs found in<br />
a master file is to reject them, or to convert them to MX RRs with a<br />
preference of 10.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 15]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
3.3.6. MG RDATA format (EXPERIMENTAL)<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
/ MGMNAME /<br />
/ /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
MGMNAME A <domain-name> which specifies a mailbox which is a<br />
member of the mail group specified by the domain name.<br />
<br />
MG records cause no additional section processing.<br />
<br />
3.3.7. MINFO RDATA format (EXPERIMENTAL)<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
/ RMAILBX /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
/ EMAILBX /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
RMAILBX A <domain-name> which specifies a mailbox which is<br />
responsible for the mailing list or mailbox. If this<br />
domain name names the root, the owner of the MINFO RR is<br />
responsible for itself. Note that many existing mailing<br />
lists use a mailbox X-request for the RMAILBX field of<br />
mailing list X, e.g., Msgroup-request for Msgroup. This<br />
field provides a more general mechanism.<br />
<br />
<br />
EMAILBX A <domain-name> which specifies a mailbox which is to<br />
receive error messages related to the mailing list or<br />
mailbox specified by the owner of the MINFO RR (similar<br />
to the ERRORS-TO: field which has been proposed). If<br />
this domain name names the root, errors should be<br />
returned to the sender of the message.<br />
<br />
MINFO records cause no additional section processing. Although these<br />
records can be associated with a simple mailbox, they are usually used<br />
with a mailing list.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 16]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
3.3.8. MR RDATA format (EXPERIMENTAL)<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
/ NEWNAME /<br />
/ /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
NEWNAME A <domain-name> which specifies a mailbox which is the<br />
proper rename of the specified mailbox.<br />
<br />
MR records cause no additional section processing. The main use for MR<br />
is as a forwarding entry for a user who has moved to a different<br />
mailbox.<br />
<br />
3.3.9. MX RDATA format<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| PREFERENCE |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
/ EXCHANGE /<br />
/ /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
PREFERENCE A 16 bit integer which specifies the preference given to<br />
this RR among others at the same owner. Lower values<br />
are preferred.<br />
<br />
EXCHANGE A <domain-name> which specifies a host willing to act as<br />
a mail exchange for the owner name.<br />
<br />
MX records cause type A additional section processing for the host<br />
specified by EXCHANGE. The use of MX RRs is explained in detail in<br />
[RFC-974].<br />
<br />
3.3.10. NULL RDATA format (EXPERIMENTAL)<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
/ <anything> /<br />
/ /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
Anything at all may be in the RDATA field so long as it is 65535 octets<br />
or less.<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 17]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
NULL records cause no additional section processing. NULL RRs are not<br />
allowed in master files. NULLs are used as placeholders in some<br />
experimental extensions of the DNS.<br />
<br />
3.3.11. NS RDATA format<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
/ NSDNAME /<br />
/ /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
NSDNAME A <domain-name> which specifies a host which should be<br />
authoritative for the specified class and domain.<br />
<br />
NS records cause both the usual additional section processing to locate<br />
a type A record, and, when used in a referral, a special search of the<br />
zone in which they reside for glue information.<br />
<br />
The NS RR states that the named host should be expected to have a zone<br />
starting at owner name of the specified class. Note that the class may<br />
not indicate the protocol family which should be used to communicate<br />
with the host, although it is typically a strong hint. For example,<br />
hosts which are name servers for either Internet (IN) or Hesiod (HS)<br />
class information are normally queried using IN class protocols.<br />
<br />
3.3.12. PTR RDATA format<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
/ PTRDNAME /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
PTRDNAME A <domain-name> which points to some location in the<br />
domain name space.<br />
<br />
PTR records cause no additional section processing. These RRs are used<br />
in special domains to point to some other location in the domain space.<br />
These records are simple data, and don't imply any special processing<br />
similar to that performed by CNAME, which identifies aliases. See the<br />
description of the IN-ADDR.ARPA domain for an example.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 18]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
3.3.13. SOA RDATA format<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
/ MNAME /<br />
/ /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
/ RNAME /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| SERIAL |<br />
| |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| REFRESH |<br />
| |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| RETRY |<br />
| |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| EXPIRE |<br />
| |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| MINIMUM |<br />
| |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
MNAME The <domain-name> of the name server that was the<br />
original or primary source of data for this zone.<br />
<br />
RNAME A <domain-name> which specifies the mailbox of the<br />
person responsible for this zone.<br />
<br />
SERIAL The unsigned 32 bit version number of the original copy<br />
of the zone. Zone transfers preserve this value. This<br />
value wraps and should be compared using sequence space<br />
arithmetic.<br />
<br />
REFRESH A 32 bit time interval before the zone should be<br />
refreshed.<br />
<br />
RETRY A 32 bit time interval that should elapse before a<br />
failed refresh should be retried.<br />
<br />
EXPIRE A 32 bit time value that specifies the upper limit on<br />
the time interval that can elapse before the zone is no<br />
longer authoritative.<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 19]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
MINIMUM The unsigned 32 bit minimum TTL field that should be<br />
exported with any RR from this zone.<br />
<br />
SOA records cause no additional section processing.<br />
<br />
All times are in units of seconds.<br />
<br />
Most of these fields are pertinent only for name server maintenance<br />
operations. However, MINIMUM is used in all query operations that<br />
retrieve RRs from a zone. Whenever a RR is sent in a response to a<br />
query, the TTL field is set to the maximum of the TTL field from the RR<br />
and the MINIMUM field in the appropriate SOA. Thus MINIMUM is a lower<br />
bound on the TTL field for all RRs in a zone. Note that this use of<br />
MINIMUM should occur when the RRs are copied into the response and not<br />
when the zone is loaded from a master file or via a zone transfer. The<br />
reason for this provison is to allow future dynamic update facilities to<br />
change the SOA RR with known semantics.<br />
<br />
<br />
3.3.14. TXT RDATA format<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
/ TXT-DATA /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
TXT-DATA One or more <character-string>s.<br />
<br />
TXT RRs are used to hold descriptive text. The semantics of the text<br />
depends on the domain where it is found.<br />
<br />
3.4. Internet specific RRs<br />
<br />
3.4.1. A RDATA format<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| ADDRESS |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
ADDRESS A 32 bit Internet address.<br />
<br />
Hosts that have multiple Internet addresses will have multiple A<br />
records.<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 20]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
A records cause no additional section processing. The RDATA section of<br />
an A line in a master file is an Internet address expressed as four<br />
decimal numbers separated by dots without any imbedded spaces (e.g.,<br />
"10.2.0.52" or "192.0.5.6").<br />
<br />
3.4.2. WKS RDATA format<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| ADDRESS |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| PROTOCOL | |<br />
+--+--+--+--+--+--+--+--+ |<br />
| |<br />
/ <BIT MAP> /<br />
/ /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
ADDRESS An 32 bit Internet address<br />
<br />
PROTOCOL An 8 bit IP protocol number<br />
<br />
<BIT MAP> A variable length bit map. The bit map must be a<br />
multiple of 8 bits long.<br />
<br />
The WKS record is used to describe the well known services supported by<br />
a particular protocol on a particular internet address. The PROTOCOL<br />
field specifies an IP protocol number, and the bit map has one bit per<br />
port of the specified protocol. The first bit corresponds to port 0,<br />
the second to port 1, etc. If the bit map does not include a bit for a<br />
protocol of interest, that bit is assumed zero. The appropriate values<br />
and mnemonics for ports and protocols are specified in [RFC-1010].<br />
<br />
For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port<br />
25 (SMTP). If this bit is set, a SMTP server should be listening on TCP<br />
port 25; if zero, SMTP service is not supported on the specified<br />
address.<br />
<br />
The purpose of WKS RRs is to provide availability information for<br />
servers for TCP and UDP. If a server supports both TCP and UDP, or has<br />
multiple Internet addresses, then multiple WKS RRs are used.<br />
<br />
WKS RRs cause no additional section processing.<br />
<br />
In master files, both ports and protocols are expressed using mnemonics<br />
or decimal numbers.<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 21]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
3.5. IN-ADDR.ARPA domain<br />
<br />
The Internet uses a special domain to support gateway location and<br />
Internet address to host mapping. Other classes may employ a similar<br />
strategy in other domains. The intent of this domain is to provide a<br />
guaranteed method to perform host address to host name mapping, and to<br />
facilitate queries to locate all gateways on a particular network in the<br />
Internet.<br />
<br />
Note that both of these services are similar to functions that could be<br />
performed by inverse queries; the difference is that this part of the<br />
domain name space is structured according to address, and hence can<br />
guarantee that the appropriate data can be located without an exhaustive<br />
search of the domain space.<br />
<br />
The domain begins at IN-ADDR.ARPA and has a substructure which follows<br />
the Internet addressing structure.<br />
<br />
Domain names in the IN-ADDR.ARPA domain are defined to have up to four<br />
labels in addition to the IN-ADDR.ARPA suffix. Each label represents<br />
one octet of an Internet address, and is expressed as a character string<br />
for a decimal value in the range 0-255 (with leading zeros omitted<br />
except in the case of a zero octet which is represented by a single<br />
zero).<br />
<br />
Host addresses are represented by domain names that have all four labels<br />
specified. Thus data for Internet address 10.2.0.52 is located at<br />
domain name 52.0.2.10.IN-ADDR.ARPA. The reversal, though awkward to<br />
read, allows zones to be delegated which are exactly one network of<br />
address space. For example, 10.IN-ADDR.ARPA can be a zone containing<br />
data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for<br />
MILNET. Address nodes are used to hold pointers to primary host names<br />
in the normal domain space.<br />
<br />
Network numbers correspond to some non-terminal nodes at various depths<br />
in the IN-ADDR.ARPA domain, since Internet network numbers are either 1,<br />
2, or 3 octets. Network nodes are used to hold pointers to the primary<br />
host names of gateways attached to that network. Since a gateway is, by<br />
definition, on more than one network, it will typically have two or more<br />
network nodes which point at it. Gateways will also have host level<br />
pointers at their fully qualified addresses.<br />
<br />
Both the gateway pointers at network nodes and the normal host pointers<br />
at full address nodes use the PTR RR to point back to the primary domain<br />
names of the corresponding hosts.<br />
<br />
For example, the IN-ADDR.ARPA domain will contain information about the<br />
ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's<br />
<br />
<br />
<br />
Mockapetris [Page 22]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU. Assuming that ISI<br />
gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-<br />
GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4<br />
and a name GW.LCS.MIT.EDU, the domain database would contain:<br />
<br />
10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.<br />
10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.<br />
18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.<br />
26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.<br />
22.0.2.10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.<br />
103.0.0.26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.<br />
77.0.0.10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.<br />
4.0.10.18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.<br />
103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.<br />
6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.<br />
<br />
Thus a program which wanted to locate gateways on net 10 would originate<br />
a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA. It<br />
would receive two RRs in response:<br />
<br />
10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.<br />
10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.<br />
<br />
The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-<br />
GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of<br />
these gateways.<br />
<br />
A resolver which wanted to find the host name corresponding to Internet<br />
host address 10.0.0.6 would pursue a query of the form QTYPE=PTR,<br />
QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:<br />
<br />
6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.<br />
<br />
Several cautions apply to the use of these services:<br />
- Since the IN-ADDR.ARPA special domain and the normal domain<br />
for a particular host or gateway will be in different zones,<br />
the possibility exists that that the data may be inconsistent.<br />
<br />
- Gateways will often have two names in separate domains, only<br />
one of which can be primary.<br />
<br />
- Systems that use the domain database to initialize their<br />
routing tables must start with enough gateway information to<br />
guarantee that they can access the appropriate name server.<br />
<br />
- The gateway data only reflects the existence of a gateway in a<br />
manner equivalent to the current HOSTS.TXT file. It doesn't<br />
replace the dynamic availability information from GGP or EGP.<br />
<br />
<br />
<br />
Mockapetris [Page 23]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
3.6. Defining new types, classes, and special namespaces<br />
<br />
The previously defined types and classes are the ones in use as of the<br />
date of this memo. New definitions should be expected. This section<br />
makes some recommendations to designers considering additions to the<br />
existing facilities. The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the<br />
forum where general discussion of design issues takes place.<br />
<br />
In general, a new type is appropriate when new information is to be<br />
added to the database about an existing object, or we need new data<br />
formats for some totally new object. Designers should attempt to define<br />
types and their RDATA formats that are generally applicable to all<br />
classes, and which avoid duplication of information. New classes are<br />
appropriate when the DNS is to be used for a new protocol, etc which<br />
requires new class-specific data formats, or when a copy of the existing<br />
name space is desired, but a separate management domain is necessary.<br />
<br />
New types and classes need mnemonics for master files; the format of the<br />
master files requires that the mnemonics for type and class be disjoint.<br />
<br />
TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes<br />
respectively.<br />
<br />
The present system uses multiple RRs to represent multiple values of a<br />
type rather than storing multiple values in the RDATA section of a<br />
single RR. This is less efficient for most applications, but does keep<br />
RRs shorter. The multiple RRs assumption is incorporated in some<br />
experimental work on dynamic update methods.<br />
<br />
The present system attempts to minimize the duplication of data in the<br />
database in order to insure consistency. Thus, in order to find the<br />
address of the host for a mail exchange, you map the mail domain name to<br />
a host name, then the host name to addresses, rather than a direct<br />
mapping to host address. This approach is preferred because it avoids<br />
the opportunity for inconsistency.<br />
<br />
In defining a new type of data, multiple RR types should not be used to<br />
create an ordering between entries or express different formats for<br />
equivalent bindings, instead this information should be carried in the<br />
body of the RR and a single type used. This policy avoids problems with<br />
caching multiple types and defining QTYPEs to match multiple types.<br />
<br />
For example, the original form of mail exchange binding used two RR<br />
types one to represent a "closer" exchange (MD) and one to represent a<br />
"less close" exchange (MF). The difficulty is that the presence of one<br />
RR type in a cache doesn't convey any information about the other<br />
because the query which acquired the cached information might have used<br />
a QTYPE of MF, MD, or MAILA (which matched both). The redesigned<br />
<br />
<br />
<br />
Mockapetris [Page 24]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
service used a single type (MX) with a "preference" value in the RDATA<br />
section which can order different RRs. However, if any MX RRs are found<br />
in the cache, then all should be there.<br />
<br />
4. MESSAGES<br />
<br />
4.1. Format<br />
<br />
All communications inside of the domain protocol are carried in a single<br />
format called a message. The top level format of message is divided<br />
into 5 sections (some of which are empty in certain cases) shown below:<br />
<br />
+---------------------+<br />
| Header |<br />
+---------------------+<br />
| Question | the question for the name server<br />
+---------------------+<br />
| Answer | RRs answering the question<br />
+---------------------+<br />
| Authority | RRs pointing toward an authority<br />
+---------------------+<br />
| Additional | RRs holding additional information<br />
+---------------------+<br />
<br />
The header section is always present. The header includes fields that<br />
specify which of the remaining sections are present, and also specify<br />
whether the message is a query or a response, a standard query or some<br />
other opcode, etc.<br />
<br />
The names of the sections after the header are derived from their use in<br />
standard queries. The question section contains fields that describe a<br />
question to a name server. These fields are a query type (QTYPE), a<br />
query class (QCLASS), and a query domain name (QNAME). The last three<br />
sections have the same format: a possibly empty list of concatenated<br />
resource records (RRs). The answer section contains RRs that answer the<br />
question; the authority section contains RRs that point toward an<br />
authoritative name server; the additional records section contains RRs<br />
which relate to the query, but are not strictly answers for the<br />
question.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 25]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
4.1.1. Header section format<br />
<br />
The header contains the following fields:<br />
<br />
1 1 1 1 1 1<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| ID |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| QDCOUNT |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| ANCOUNT |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| NSCOUNT |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| ARCOUNT |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
ID A 16 bit identifier assigned by the program that<br />
generates any kind of query. This identifier is copied<br />
the corresponding reply and can be used by the requester<br />
to match up replies to outstanding queries.<br />
<br />
QR A one bit field that specifies whether this message is a<br />
query (0), or a response (1).<br />
<br />
OPCODE A four bit field that specifies kind of query in this<br />
message. This value is set by the originator of a query<br />
and copied into the response. The values are:<br />
<br />
0 a standard query (QUERY)<br />
<br />
1 an inverse query (IQUERY)<br />
<br />
2 a server status request (STATUS)<br />
<br />
3-15 reserved for future use<br />
<br />
AA Authoritative Answer - this bit is valid in responses,<br />
and specifies that the responding name server is an<br />
authority for the domain name in question section.<br />
<br />
Note that the contents of the answer section may have<br />
multiple owner names because of aliases. The AA bit<br />
<br />
<br />
<br />
Mockapetris [Page 26]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
corresponds to the name which matches the query name, or<br />
the first owner name in the answer section.<br />
<br />
TC TrunCation - specifies that this message was truncated<br />
due to length greater than that permitted on the<br />
transmission channel.<br />
<br />
RD Recursion Desired - this bit may be set in a query and<br />
is copied into the response. If RD is set, it directs<br />
the name server to pursue the query recursively.<br />
Recursive query support is optional.<br />
<br />
RA Recursion Available - this be is set or cleared in a<br />
response, and denotes whether recursive query support is<br />
available in the name server.<br />
<br />
Z Reserved for future use. Must be zero in all queries<br />
and responses.<br />
<br />
RCODE Response code - this 4 bit field is set as part of<br />
responses. The values have the following<br />
interpretation:<br />
<br />
0 No error condition<br />
<br />
1 Format error - The name server was<br />
unable to interpret the query.<br />
<br />
2 Server failure - The name server was<br />
unable to process this query due to a<br />
problem with the name server.<br />
<br />
3 Name Error - Meaningful only for<br />
responses from an authoritative name<br />
server, this code signifies that the<br />
domain name referenced in the query does<br />
not exist.<br />
<br />
4 Not Implemented - The name server does<br />
not support the requested kind of query.<br />
<br />
5 Refused - The name server refuses to<br />
perform the specified operation for<br />
policy reasons. For example, a name<br />
server may not wish to provide the<br />
information to the particular requester,<br />
or a name server may not wish to perform<br />
a particular operation (e.g., zone<br />
<br />
<br />
<br />
Mockapetris [Page 27]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
transfer) for particular data.<br />
<br />
6-15 Reserved for future use.<br />
<br />
QDCOUNT an unsigned 16 bit integer specifying the number of<br />
entries in the question section.<br />
<br />
ANCOUNT an unsigned 16 bit integer specifying the number of<br />
resource records in the answer section.<br />
<br />
NSCOUNT an unsigned 16 bit integer specifying the number of name<br />
server resource records in the authority records<br />
section.<br />
<br />
ARCOUNT an unsigned 16 bit integer specifying the number of<br />
resource records in the additional records section.<br />
<br />
4.1.2. Question section format<br />
<br />
The question section is used to carry the "question" in most queries,<br />
i.e., the parameters that define what is being asked. The section<br />
contains QDCOUNT (usually 1) entries, each of the following format:<br />
<br />
1 1 1 1 1 1<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| |<br />
/ QNAME /<br />
/ /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| QTYPE |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| QCLASS |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
QNAME a domain name represented as a sequence of labels, where<br />
each label consists of a length octet followed by that<br />
number of octets. The domain name terminates with the<br />
zero length octet for the null label of the root. Note<br />
that this field may be an odd number of octets; no<br />
padding is used.<br />
<br />
QTYPE a two octet code which specifies the type of the query.<br />
The values for this field include all codes valid for a<br />
TYPE field, together with some more general codes which<br />
can match more than one type of RR.<br />
<br />
<br />
<br />
Mockapetris [Page 28]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
QCLASS a two octet code that specifies the class of the query.<br />
For example, the QCLASS field is IN for the Internet.<br />
<br />
4.1.3. Resource record format<br />
<br />
The answer, authority, and additional sections all share the same<br />
format: a variable number of resource records, where the number of<br />
records is specified in the corresponding count field in the header.<br />
Each resource record has the following format:<br />
1 1 1 1 1 1<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| |<br />
/ /<br />
/ NAME /<br />
| |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| TYPE |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| CLASS |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| TTL |<br />
| |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| RDLENGTH |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|<br />
/ RDATA /<br />
/ /<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
where:<br />
<br />
NAME a domain name to which this resource record pertains.<br />
<br />
TYPE two octets containing one of the RR type codes. This<br />
field specifies the meaning of the data in the RDATA<br />
field.<br />
<br />
CLASS two octets which specify the class of the data in the<br />
RDATA field.<br />
<br />
TTL a 32 bit unsigned integer that specifies the time<br />
interval (in seconds) that the resource record may be<br />
cached before it should be discarded. Zero values are<br />
interpreted to mean that the RR can only be used for the<br />
transaction in progress, and should not be cached.<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 29]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
RDLENGTH an unsigned 16 bit integer that specifies the length in<br />
octets of the RDATA field.<br />
<br />
RDATA a variable length string of octets that describes the<br />
resource. The format of this information varies<br />
according to the TYPE and CLASS of the resource record.<br />
For example, the if the TYPE is A and the CLASS is IN,<br />
the RDATA field is a 4 octet ARPA Internet address.<br />
<br />
4.1.4. Message compression<br />
<br />
In order to reduce the size of messages, the domain system utilizes a<br />
compression scheme which eliminates the repetition of domain names in a<br />
message. In this scheme, an entire domain name or a list of labels at<br />
the end of a domain name is replaced with a pointer to a prior occurance<br />
of the same name.<br />
<br />
The pointer takes the form of a two octet sequence:<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
| 1 1| OFFSET |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
The first two bits are ones. This allows a pointer to be distinguished<br />
from a label, since the label must begin with two zero bits because<br />
labels are restricted to 63 octets or less. (The 10 and 01 combinations<br />
are reserved for future use.) The OFFSET field specifies an offset from<br />
the start of the message (i.e., the first octet of the ID field in the<br />
domain header). A zero offset specifies the first byte of the ID field,<br />
etc.<br />
<br />
The compression scheme allows a domain name in a message to be<br />
represented as either:<br />
<br />
- a sequence of labels ending in a zero octet<br />
<br />
- a pointer<br />
<br />
- a sequence of labels ending with a pointer<br />
<br />
Pointers can only be used for occurances of a domain name where the<br />
format is not class specific. If this were not the case, a name server<br />
or resolver would be required to know the format of all RRs it handled.<br />
As yet, there are no such cases, but they may occur in future RDATA<br />
formats.<br />
<br />
If a domain name is contained in a part of the message subject to a<br />
length field (such as the RDATA section of an RR), and compression is<br />
<br />
<br />
<br />
Mockapetris [Page 30]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
used, the length of the compressed name is used in the length<br />
calculation, rather than the length of the expanded name.<br />
<br />
Programs are free to avoid using pointers in messages they generate,<br />
although this will reduce datagram capacity, and may cause truncation.<br />
However all programs are required to understand arriving messages that<br />
contain pointers.<br />
<br />
For example, a datagram might need to use the domain names F.ISI.ARPA,<br />
FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the<br />
message, these domain names might be represented as:<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
20 | 1 | F |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
22 | 3 | I |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
24 | S | I |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
26 | 4 | A |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
28 | R | P |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
30 | A | 0 |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
40 | 3 | F |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
42 | O | O |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
44 | 1 1| 20 |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
64 | 1 1| 26 |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
92 | 0 | |<br />
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<br />
<br />
The domain name for F.ISI.ARPA is shown at offset 20. The domain name<br />
FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to<br />
concatenate a label for FOO to the previously defined F.ISI.ARPA. The<br />
domain name ARPA is defined at offset 64 using a pointer to the ARPA<br />
component of the name F.ISI.ARPA at 20; note that this pointer relies on<br />
ARPA being the last label in the string at 20. The root domain name is<br />
<br />
<br />
<br />
Mockapetris [Page 31]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
defined by a single octet of zeros at 92; the root domain name has no<br />
labels.<br />
<br />
4.2. Transport<br />
<br />
The DNS assumes that messages will be transmitted as datagrams or in a<br />
byte stream carried by a virtual circuit. While virtual circuits can be<br />
used for any DNS activity, datagrams are preferred for queries due to<br />
their lower overhead and better performance. Zone refresh activities<br />
must use virtual circuits because of the need for reliable transfer.<br />
<br />
The Internet supports name server access using TCP [RFC-793] on server<br />
port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP<br />
port 53 (decimal).<br />
<br />
4.2.1. UDP usage<br />
<br />
Messages sent using UDP user server port 53 (decimal).<br />
<br />
Messages carried by UDP are restricted to 512 bytes (not counting the IP<br />
or UDP headers). Longer messages are truncated and the TC bit is set in<br />
the header.<br />
<br />
UDP is not acceptable for zone transfers, but is the recommended method<br />
for standard queries in the Internet. Queries sent using UDP may be<br />
lost, and hence a retransmission strategy is required. Queries or their<br />
responses may be reordered by the network, or by processing in name<br />
servers, so resolvers should not depend on them being returned in order.<br />
<br />
The optimal UDP retransmission policy will vary with performance of the<br />
Internet and the needs of the client, but the following are recommended:<br />
<br />
- The client should try other servers and server addresses<br />
before repeating a query to a specific address of a server.<br />
<br />
- The retransmission interval should be based on prior<br />
statistics if possible. Too aggressive retransmission can<br />
easily slow responses for the community at large. Depending<br />
on how well connected the client is to its expected servers,<br />
the minimum retransmission interval should be 2-5 seconds.<br />
<br />
More suggestions on server selection and retransmission policy can be<br />
found in the resolver section of this memo.<br />
<br />
4.2.2. TCP usage<br />
<br />
Messages sent over TCP connections use server port 53 (decimal). The<br />
message is prefixed with a two byte length field which gives the message<br />
<br />
<br />
<br />
Mockapetris [Page 32]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
length, excluding the two byte length field. This length field allows<br />
the low-level processing to assemble a complete message before beginning<br />
to parse it.<br />
<br />
Several connection management policies are recommended:<br />
<br />
- The server should not block other activities waiting for TCP<br />
data.<br />
<br />
- The server should support multiple connections.<br />
<br />
- The server should assume that the client will initiate<br />
connection closing, and should delay closing its end of the<br />
connection until all outstanding client requests have been<br />
satisfied.<br />
<br />
- If the server needs to close a dormant connection to reclaim<br />
resources, it should wait until the connection has been idle<br />
for a period on the order of two minutes. In particular, the<br />
server should allow the SOA and AXFR request sequence (which<br />
begins a refresh operation) to be made on a single connection.<br />
Since the server would be unable to answer queries anyway, a<br />
unilateral close or reset may be used instead of a graceful<br />
close.<br />
<br />
5. MASTER FILES<br />
<br />
Master files are text files that contain RRs in text form. Since the<br />
contents of a zone can be expressed in the form of a list of RRs a<br />
master file is most often used to define a zone, though it can be used<br />
to list a cache's contents. Hence, this section first discusses the<br />
format of RRs in a master file, and then the special considerations when<br />
a master file is used to create a zone in some name server.<br />
<br />
5.1. Format<br />
<br />
The format of these files is a sequence of entries. Entries are<br />
predominantly line-oriented, though parentheses can be used to continue<br />
a list of items across a line boundary, and text literals can contain<br />
CRLF within the text. Any combination of tabs and spaces act as a<br />
delimiter between the separate items that make up an entry. The end of<br />
any line in the master file can end with a comment. The comment starts<br />
with a ";" (semicolon).<br />
<br />
The following entries are defined:<br />
<br />
<blank>[<comment>]<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 33]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
$ORIGIN <domain-name> [<comment>]<br />
<br />
$INCLUDE <file-name> [<domain-name>] [<comment>]<br />
<br />
<domain-name><rr> [<comment>]<br />
<br />
<blank><rr> [<comment>]<br />
<br />
Blank lines, with or without comments, are allowed anywhere in the file.<br />
<br />
Two control entries are defined: $ORIGIN and $INCLUDE. $ORIGIN is<br />
followed by a domain name, and resets the current origin for relative<br />
domain names to the stated name. $INCLUDE inserts the named file into<br />
the current file, and may optionally specify a domain name that sets the<br />
relative domain name origin for the included file. $INCLUDE may also<br />
have a comment. Note that a $INCLUDE entry never changes the relative<br />
origin of the parent file, regardless of changes to the relative origin<br />
made within the included file.<br />
<br />
The last two forms represent RRs. If an entry for an RR begins with a<br />
blank, then the RR is assumed to be owned by the last stated owner. If<br />
an RR entry begins with a <domain-name>, then the owner name is reset.<br />
<br />
<rr> contents take one of the following forms:<br />
<br />
[<TTL>] [<class>] <type> <RDATA><br />
<br />
[<class>] [<TTL>] <type> <RDATA><br />
<br />
The RR begins with optional TTL and class fields, followed by a type and<br />
RDATA field appropriate to the type and class. Class and type use the<br />
standard mnemonics, TTL is a decimal integer. Omitted class and TTL<br />
values are default to the last explicitly stated values. Since type and<br />
class mnemonics are disjoint, the parse is unique. (Note that this<br />
order is different from the order used in examples and the order used in<br />
the actual RRs; the given order allows easier parsing and defaulting.)<br />
<br />
<domain-name>s make up a large share of the data in the master file.<br />
The labels in the domain name are expressed as character strings and<br />
separated by dots. Quoting conventions allow arbitrary characters to be<br />
stored in domain names. Domain names that end in a dot are called<br />
absolute, and are taken as complete. Domain names which do not end in a<br />
dot are called relative; the actual domain name is the concatenation of<br />
the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as<br />
an argument to the master file loading routine. A relative name is an<br />
error when no origin is available.<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 34]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
<character-string> is expressed in one or two ways: as a contiguous set<br />
of characters without interior spaces, or as a string beginning with a "<br />
and ending with a ". Inside a " delimited string any character can<br />
occur, except for a " itself, which must be quoted using \ (back slash).<br />
<br />
Because these files are text files several special encodings are<br />
necessary to allow arbitrary data to be loaded. In particular:<br />
<br />
of the root.<br />
<br />
@ A free standing @ is used to denote the current origin.<br />
<br />
\X where X is any character other than a digit (0-9), is<br />
used to quote that character so that its special meaning<br />
does not apply. For example, "\." can be used to place<br />
a dot character in a label.<br />
<br />
\DDD where each D is a digit is the octet corresponding to<br />
the decimal number described by DDD. The resulting<br />
octet is assumed to be text and is not checked for<br />
special meaning.<br />
<br />
( ) Parentheses are used to group data that crosses a line<br />
boundary. In effect, line terminations are not<br />
recognized within parentheses.<br />
<br />
; Semicolon is used to start a comment; the remainder of<br />
the line is ignored.<br />
<br />
5.2. Use of master files to define zones<br />
<br />
When a master file is used to load a zone, the operation should be<br />
suppressed if any errors are encountered in the master file. The<br />
rationale for this is that a single error can have widespread<br />
consequences. For example, suppose that the RRs defining a delegation<br />
have syntax errors; then the server will return authoritative name<br />
errors for all names in the subzone (except in the case where the<br />
subzone is also present on the server).<br />
<br />
Several other validity checks that should be performed in addition to<br />
insuring that the file is syntactically correct:<br />
<br />
1. All RRs in the file should have the same class.<br />
<br />
2. Exactly one SOA RR should be present at the top of the zone.<br />
<br />
3. If delegations are present and glue information is required,<br />
it should be present.<br />
<br />
<br />
<br />
Mockapetris [Page 35]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
4. Information present outside of the authoritative nodes in the<br />
zone should be glue information, rather than the result of an<br />
origin or similar error.<br />
<br />
5.3. Master file example<br />
<br />
The following is an example file which might be used to define the<br />
ISI.EDU zone.and is loaded with an origin of ISI.EDU:<br />
<br />
@ IN SOA VENERA Action\.domains (<br />
20 ; SERIAL<br />
7200 ; REFRESH<br />
600 ; RETRY<br />
3600000; EXPIRE<br />
60) ; MINIMUM<br />
<br />
NS A.ISI.EDU.<br />
NS VENERA<br />
NS VAXA<br />
MX 10 VENERA<br />
MX 20 VAXA<br />
<br />
A A 26.3.0.103<br />
<br />
VENERA A 10.1.0.52<br />
A 128.9.0.32<br />
<br />
VAXA A 10.2.0.27<br />
A 128.9.0.33<br />
<br />
<br />
$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT<br />
<br />
Where the file <SUBSYS>ISI-MAILBOXES.TXT is:<br />
<br />
MOE MB A.ISI.EDU.<br />
LARRY MB A.ISI.EDU.<br />
CURLEY MB A.ISI.EDU.<br />
STOOGES MG MOE<br />
MG LARRY<br />
MG CURLEY<br />
<br />
Note the use of the \ character in the SOA RR to specify the responsible<br />
person mailbox "Action.domains@E.ISI.EDU".<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 36]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
6. NAME SERVER IMPLEMENTATION<br />
<br />
6.1. Architecture<br />
<br />
The optimal structure for the name server will depend on the host<br />
operating system and whether the name server is integrated with resolver<br />
operations, either by supporting recursive service, or by sharing its<br />
database with a resolver. This section discusses implementation<br />
considerations for a name server which shares a database with a<br />
resolver, but most of these concerns are present in any name server.<br />
<br />
6.1.1. Control<br />
<br />
A name server must employ multiple concurrent activities, whether they<br />
are implemented as separate tasks in the host's OS or multiplexing<br />
inside a single name server program. It is simply not acceptable for a<br />
name server to block the service of UDP requests while it waits for TCP<br />
data for refreshing or query activities. Similarly, a name server<br />
should not attempt to provide recursive service without processing such<br />
requests in parallel, though it may choose to serialize requests from a<br />
single client, or to regard identical requests from the same client as<br />
duplicates. A name server should not substantially delay requests while<br />
it reloads a zone from master files or while it incorporates a newly<br />
refreshed zone into its database.<br />
<br />
6.1.2. Database<br />
<br />
While name server implementations are free to use any internal data<br />
structures they choose, the suggested structure consists of three major<br />
parts:<br />
<br />
- A "catalog" data structure which lists the zones available to<br />
this server, and a "pointer" to the zone data structure. The<br />
main purpose of this structure is to find the nearest ancestor<br />
zone, if any, for arriving standard queries.<br />
<br />
- Separate data structures for each of the zones held by the<br />
name server.<br />
<br />
- A data structure for cached data. (or perhaps separate caches<br />
for different classes)<br />
<br />
All of these data structures can be implemented an identical tree<br />
structure format, with different data chained off the nodes in different<br />
parts: in the catalog the data is pointers to zones, while in the zone<br />
and cache data structures, the data will be RRs. In designing the tree<br />
framework the designer should recognize that query processing will need<br />
to traverse the tree using case-insensitive label comparisons; and that<br />
<br />
<br />
<br />
Mockapetris [Page 37]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
in real data, a few nodes have a very high branching factor (100-1000 or<br />
more), but the vast majority have a very low branching factor (0-1).<br />
<br />
One way to solve the case problem is to store the labels for each node<br />
in two pieces: a standardized-case representation of the label where all<br />
ASCII characters are in a single case, together with a bit mask that<br />
denotes which characters are actually of a different case. The<br />
branching factor diversity can be handled using a simple linked list for<br />
a node until the branching factor exceeds some threshold, and<br />
transitioning to a hash structure after the threshold is exceeded. In<br />
any case, hash structures used to store tree sections must insure that<br />
hash functions and procedures preserve the casing conventions of the<br />
DNS.<br />
<br />
The use of separate structures for the different parts of the database<br />
is motivated by several factors:<br />
<br />
- The catalog structure can be an almost static structure that<br />
need change only when the system administrator changes the<br />
zones supported by the server. This structure can also be<br />
used to store parameters used to control refreshing<br />
activities.<br />
<br />
- The individual data structures for zones allow a zone to be<br />
replaced simply by changing a pointer in the catalog. Zone<br />
refresh operations can build a new structure and, when<br />
complete, splice it into the database via a simple pointer<br />
replacement. It is very important that when a zone is<br />
refreshed, queries should not use old and new data<br />
simultaneously.<br />
<br />
- With the proper search procedures, authoritative data in zones<br />
will always "hide", and hence take precedence over, cached<br />
data.<br />
<br />
- Errors in zone definitions that cause overlapping zones, etc.,<br />
may cause erroneous responses to queries, but problem<br />
determination is simplified, and the contents of one "bad"<br />
zone can't corrupt another.<br />
<br />
- Since the cache is most frequently updated, it is most<br />
vulnerable to corruption during system restarts. It can also<br />
become full of expired RR data. In either case, it can easily<br />
be discarded without disturbing zone data.<br />
<br />
A major aspect of database design is selecting a structure which allows<br />
the name server to deal with crashes of the name server's host. State<br />
information which a name server should save across system crashes<br />
<br />
<br />
<br />
Mockapetris [Page 38]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
includes the catalog structure (including the state of refreshing for<br />
each zone) and the zone data itself.<br />
<br />
6.1.3. Time<br />
<br />
Both the TTL data for RRs and the timing data for refreshing activities<br />
depends on 32 bit timers in units of seconds. Inside the database,<br />
refresh timers and TTLs for cached data conceptually "count down", while<br />
data in the zone stays with constant TTLs.<br />
<br />
A recommended implementation strategy is to store time in two ways: as<br />
a relative increment and as an absolute time. One way to do this is to<br />
use positive 32 bit numbers for one type and negative numbers for the<br />
other. The RRs in zones use relative times; the refresh timers and<br />
cache data use absolute times. Absolute numbers are taken with respect<br />
to some known origin and converted to relative values when placed in the<br />
response to a query. When an absolute TTL is negative after conversion<br />
to relative, then the data is expired and should be ignored.<br />
<br />
6.2. Standard query processing<br />
<br />
The major algorithm for standard query processing is presented in<br />
[RFC-1034].<br />
<br />
When processing queries with QCLASS=*, or some other QCLASS which<br />
matches multiple classes, the response should never be authoritative<br />
unless the server can guarantee that the response covers all classes.<br />
<br />
When composing a response, RRs which are to be inserted in the<br />
additional section, but duplicate RRs in the answer or authority<br />
sections, may be omitted from the additional section.<br />
<br />
When a response is so long that truncation is required, the truncation<br />
should start at the end of the response and work forward in the<br />
datagram. Thus if there is any data for the authority section, the<br />
answer section is guaranteed to be unique.<br />
<br />
The MINIMUM value in the SOA should be used to set a floor on the TTL of<br />
data distributed from a zone. This floor function should be done when<br />
the data is copied into a response. This will allow future dynamic<br />
update protocols to change the SOA MINIMUM field without ambiguous<br />
semantics.<br />
<br />
6.3. Zone refresh and reload processing<br />
<br />
In spite of a server's best efforts, it may be unable to load zone data<br />
from a master file due to syntax errors, etc., or be unable to refresh a<br />
zone within the its expiration parameter. In this case, the name server<br />
<br />
<br />
<br />
Mockapetris [Page 39]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
should answer queries as if it were not supposed to possess the zone.<br />
<br />
If a master is sending a zone out via AXFR, and a new version is created<br />
during the transfer, the master should continue to send the old version<br />
if possible. In any case, it should never send part of one version and<br />
part of another. If completion is not possible, the master should reset<br />
the connection on which the zone transfer is taking place.<br />
<br />
6.4. Inverse queries (Optional)<br />
<br />
Inverse queries are an optional part of the DNS. Name servers are not<br />
required to support any form of inverse queries. If a name server<br />
receives an inverse query that it does not support, it returns an error<br />
response with the "Not Implemented" error set in the header. While<br />
inverse query support is optional, all name servers must be at least<br />
able to return the error response.<br />
<br />
6.4.1. The contents of inverse queries and responses Inverse<br />
queries reverse the mappings performed by standard query operations;<br />
while a standard query maps a domain name to a resource, an inverse<br />
query maps a resource to a domain name. For example, a standard query<br />
might bind a domain name to a host address; the corresponding inverse<br />
query binds the host address to a domain name.<br />
<br />
Inverse queries take the form of a single RR in the answer section of<br />
the message, with an empty question section. The owner name of the<br />
query RR and its TTL are not significant. The response carries<br />
questions in the question section which identify all names possessing<br />
the query RR WHICH THE NAME SERVER KNOWS. Since no name server knows<br />
about all of the domain name space, the response can never be assumed to<br />
be complete. Thus inverse queries are primarily useful for database<br />
management and debugging activities. Inverse queries are NOT an<br />
acceptable method of mapping host addresses to host names; use the IN-<br />
ADDR.ARPA domain instead.<br />
<br />
Where possible, name servers should provide case-insensitive comparisons<br />
for inverse queries. Thus an inverse query asking for an MX RR of<br />
"Venera.isi.edu" should get the same response as a query for<br />
"VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should<br />
produce the same result as an inverse query for "IBM-pc unix". However,<br />
this cannot be guaranteed because name servers may possess RRs that<br />
contain character strings but the name server does not know that the<br />
data is character.<br />
<br />
When a name server processes an inverse query, it either returns:<br />
<br />
1. zero, one, or multiple domain names for the specified<br />
resource as QNAMEs in the question section<br />
<br />
<br />
<br />
Mockapetris [Page 40]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
2. an error code indicating that the name server doesn't support<br />
inverse mapping of the specified resource type.<br />
<br />
When the response to an inverse query contains one or more QNAMEs, the<br />
owner name and TTL of the RR in the answer section which defines the<br />
inverse query is modified to exactly match an RR found at the first<br />
QNAME.<br />
<br />
RRs returned in the inverse queries cannot be cached using the same<br />
mechanism as is used for the replies to standard queries. One reason<br />
for this is that a name might have multiple RRs of the same type, and<br />
only one would appear. For example, an inverse query for a single<br />
address of a multiply homed host might create the impression that only<br />
one address existed.<br />
<br />
6.4.2. Inverse query and response example The overall structure<br />
of an inverse query for retrieving the domain name that corresponds to<br />
Internet address 10.1.0.52 is shown below:<br />
<br />
+-----------------------------------------+<br />
Header | OPCODE=IQUERY, ID=997 |<br />
+-----------------------------------------+<br />
Question | <empty> |<br />
+-----------------------------------------+<br />
Answer | <anyname> A IN 10.1.0.52 |<br />
+-----------------------------------------+<br />
Authority | <empty> |<br />
+-----------------------------------------+<br />
Additional | <empty> |<br />
+-----------------------------------------+<br />
<br />
This query asks for a question whose answer is the Internet style<br />
address 10.1.0.52. Since the owner name is not known, any domain name<br />
can be used as a placeholder (and is ignored). A single octet of zero,<br />
signifying the root, is usually used because it minimizes the length of<br />
the message. The TTL of the RR is not significant. The response to<br />
this query might be:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 41]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
+-----------------------------------------+<br />
Header | OPCODE=RESPONSE, ID=997 |<br />
+-----------------------------------------+<br />
Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |<br />
+-----------------------------------------+<br />
Answer | VENERA.ISI.EDU A IN 10.1.0.52 |<br />
+-----------------------------------------+<br />
Authority | <empty> |<br />
+-----------------------------------------+<br />
Additional | <empty> |<br />
+-----------------------------------------+<br />
<br />
Note that the QTYPE in a response to an inverse query is the same as the<br />
TYPE field in the answer section of the inverse query. Responses to<br />
inverse queries may contain multiple questions when the inverse is not<br />
unique. If the question section in the response is not empty, then the<br />
RR in the answer section is modified to correspond to be an exact copy<br />
of an RR at the first QNAME.<br />
<br />
6.4.3. Inverse query processing<br />
<br />
Name servers that support inverse queries can support these operations<br />
through exhaustive searches of their databases, but this becomes<br />
impractical as the size of the database increases. An alternative<br />
approach is to invert the database according to the search key.<br />
<br />
For name servers that support multiple zones and a large amount of data,<br />
the recommended approach is separate inversions for each zone. When a<br />
particular zone is changed during a refresh, only its inversions need to<br />
be redone.<br />
<br />
Support for transfer of this type of inversion may be included in future<br />
versions of the domain system, but is not supported in this version.<br />
<br />
6.5. Completion queries and responses<br />
<br />
The optional completion services described in RFC-882 and RFC-883 have<br />
been deleted. Redesigned services may become available in the future.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 42]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
7. RESOLVER IMPLEMENTATION<br />
<br />
The top levels of the recommended resolver algorithm are discussed in<br />
[RFC-1034]. This section discusses implementation details assuming the<br />
database structure suggested in the name server implementation section<br />
of this memo.<br />
<br />
7.1. Transforming a user request into a query<br />
<br />
The first step a resolver takes is to transform the client's request,<br />
stated in a format suitable to the local OS, into a search specification<br />
for RRs at a specific name which match a specific QTYPE and QCLASS.<br />
Where possible, the QTYPE and QCLASS should correspond to a single type<br />
and a single class, because this makes the use of cached data much<br />
simpler. The reason for this is that the presence of data of one type<br />
in a cache doesn't confirm the existence or non-existence of data of<br />
other types, hence the only way to be sure is to consult an<br />
authoritative source. If QCLASS=* is used, then authoritative answers<br />
won't be available.<br />
<br />
Since a resolver must be able to multiplex multiple requests if it is to<br />
perform its function efficiently, each pending request is usually<br />
represented in some block of state information. This state block will<br />
typically contain:<br />
<br />
- A timestamp indicating the time the request began.<br />
The timestamp is used to decide whether RRs in the database<br />
can be used or are out of date. This timestamp uses the<br />
absolute time format previously discussed for RR storage in<br />
zones and caches. Note that when an RRs TTL indicates a<br />
relative time, the RR must be timely, since it is part of a<br />
zone. When the RR has an absolute time, it is part of a<br />
cache, and the TTL of the RR is compared against the timestamp<br />
for the start of the request.<br />
<br />
Note that using the timestamp is superior to using a current<br />
time, since it allows RRs with TTLs of zero to be entered in<br />
the cache in the usual manner, but still used by the current<br />
request, even after intervals of many seconds due to system<br />
load, query retransmission timeouts, etc.<br />
<br />
- Some sort of parameters to limit the amount of work which will<br />
be performed for this request.<br />
<br />
The amount of work which a resolver will do in response to a<br />
client request must be limited to guard against errors in the<br />
database, such as circular CNAME references, and operational<br />
problems, such as network partition which prevents the<br />
<br />
<br />
<br />
Mockapetris [Page 43]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
resolver from accessing the name servers it needs. While<br />
local limits on the number of times a resolver will retransmit<br />
a particular query to a particular name server address are<br />
essential, the resolver should have a global per-request<br />
counter to limit work on a single request. The counter should<br />
be set to some initial value and decremented whenever the<br />
resolver performs any action (retransmission timeout,<br />
retransmission, etc.) If the counter passes zero, the request<br />
is terminated with a temporary error.<br />
<br />
Note that if the resolver structure allows one request to<br />
start others in parallel, such as when the need to access a<br />
name server for one request causes a parallel resolve for the<br />
name server's addresses, the spawned request should be started<br />
with a lower counter. This prevents circular references in<br />
the database from starting a chain reaction of resolver<br />
activity.<br />
<br />
- The SLIST data structure discussed in [RFC-1034].<br />
<br />
This structure keeps track of the state of a request if it<br />
must wait for answers from foreign name servers.<br />
<br />
7.2. Sending the queries<br />
<br />
As described in [RFC-1034], the basic task of the resolver is to<br />
formulate a query which will answer the client's request and direct that<br />
query to name servers which can provide the information. The resolver<br />
will usually only have very strong hints about which servers to ask, in<br />
the form of NS RRs, and may have to revise the query, in response to<br />
CNAMEs, or revise the set of name servers the resolver is asking, in<br />
response to delegation responses which point the resolver to name<br />
servers closer to the desired information. In addition to the<br />
information requested by the client, the resolver may have to call upon<br />
its own services to determine the address of name servers it wishes to<br />
contact.<br />
<br />
In any case, the model used in this memo assumes that the resolver is<br />
multiplexing attention between multiple requests, some from the client,<br />
and some internally generated. Each request is represented by some<br />
state information, and the desired behavior is that the resolver<br />
transmit queries to name servers in a way that maximizes the probability<br />
that the request is answered, minimizes the time that the request takes,<br />
and avoids excessive transmissions. The key algorithm uses the state<br />
information of the request to select the next name server address to<br />
query, and also computes a timeout which will cause the next action<br />
should a response not arrive. The next action will usually be a<br />
transmission to some other server, but may be a temporary error to the<br />
<br />
<br />
<br />
Mockapetris [Page 44]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
client.<br />
<br />
The resolver always starts with a list of server names to query (SLIST).<br />
This list will be all NS RRs which correspond to the nearest ancestor<br />
zone that the resolver knows about. To avoid startup problems, the<br />
resolver should have a set of default servers which it will ask should<br />
it have no current NS RRs which are appropriate. The resolver then adds<br />
to SLIST all of the known addresses for the name servers, and may start<br />
parallel requests to acquire the addresses of the servers when the<br />
resolver has the name, but no addresses, for the name servers.<br />
<br />
To complete initialization of SLIST, the resolver attaches whatever<br />
history information it has to the each address in SLIST. This will<br />
usually consist of some sort of weighted averages for the response time<br />
of the address, and the batting average of the address (i.e., how often<br />
the address responded at all to the request). Note that this<br />
information should be kept on a per address basis, rather than on a per<br />
name server basis, because the response time and batting average of a<br />
particular server may vary considerably from address to address. Note<br />
also that this information is actually specific to a resolver address /<br />
server address pair, so a resolver with multiple addresses may wish to<br />
keep separate histories for each of its addresses. Part of this step<br />
must deal with addresses which have no such history; in this case an<br />
expected round trip time of 5-10 seconds should be the worst case, with<br />
lower estimates for the same local network, etc.<br />
<br />
Note that whenever a delegation is followed, the resolver algorithm<br />
reinitializes SLIST.<br />
<br />
The information establishes a partial ranking of the available name<br />
server addresses. Each time an address is chosen and the state should<br />
be altered to prevent its selection again until all other addresses have<br />
been tried. The timeout for each transmission should be 50-100% greater<br />
than the average predicted value to allow for variance in response.<br />
<br />
Some fine points:<br />
<br />
- The resolver may encounter a situation where no addresses are<br />
available for any of the name servers named in SLIST, and<br />
where the servers in the list are precisely those which would<br />
normally be used to look up their own addresses. This<br />
situation typically occurs when the glue address RRs have a<br />
smaller TTL than the NS RRs marking delegation, or when the<br />
resolver caches the result of a NS search. The resolver<br />
should detect this condition and restart the search at the<br />
next ancestor zone, or alternatively at the root.<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 45]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
- If a resolver gets a server error or other bizarre response<br />
from a name server, it should remove it from SLIST, and may<br />
wish to schedule an immediate transmission to the next<br />
candidate server address.<br />
<br />
7.3. Processing responses<br />
<br />
The first step in processing arriving response datagrams is to parse the<br />
response. This procedure should include:<br />
<br />
- Check the header for reasonableness. Discard datagrams which<br />
are queries when responses are expected.<br />
<br />
- Parse the sections of the message, and insure that all RRs are<br />
correctly formatted.<br />
<br />
- As an optional step, check the TTLs of arriving data looking<br />
for RRs with excessively long TTLs. If a RR has an<br />
excessively long TTL, say greater than 1 week, either discard<br />
the whole response, or limit all TTLs in the response to 1<br />
week.<br />
<br />
The next step is to match the response to a current resolver request.<br />
The recommended strategy is to do a preliminary matching using the ID<br />
field in the domain header, and then to verify that the question section<br />
corresponds to the information currently desired. This requires that<br />
the transmission algorithm devote several bits of the domain ID field to<br />
a request identifier of some sort. This step has several fine points:<br />
<br />
- Some name servers send their responses from different<br />
addresses than the one used to receive the query. That is, a<br />
resolver cannot rely that a response will come from the same<br />
address which it sent the corresponding query to. This name<br />
server bug is typically encountered in UNIX systems.<br />
<br />
- If the resolver retransmits a particular request to a name<br />
server it should be able to use a response from any of the<br />
transmissions. However, if it is using the response to sample<br />
the round trip time to access the name server, it must be able<br />
to determine which transmission matches the response (and keep<br />
transmission times for each outgoing message), or only<br />
calculate round trip times based on initial transmissions.<br />
<br />
- A name server will occasionally not have a current copy of a<br />
zone which it should have according to some NS RRs. The<br />
resolver should simply remove the name server from the current<br />
SLIST, and continue.<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 46]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
7.4. Using the cache<br />
<br />
In general, we expect a resolver to cache all data which it receives in<br />
responses since it may be useful in answering future client requests.<br />
However, there are several types of data which should not be cached:<br />
<br />
- When several RRs of the same type are available for a<br />
particular owner name, the resolver should either cache them<br />
all or none at all. When a response is truncated, and a<br />
resolver doesn't know whether it has a complete set, it should<br />
not cache a possibly partial set of RRs.<br />
<br />
- Cached data should never be used in preference to<br />
authoritative data, so if caching would cause this to happen<br />
the data should not be cached.<br />
<br />
- The results of an inverse query should not be cached.<br />
<br />
- The results of standard queries where the QNAME contains "*"<br />
labels if the data might be used to construct wildcards. The<br />
reason is that the cache does not necessarily contain existing<br />
RRs or zone boundary information which is necessary to<br />
restrict the application of the wildcard RRs.<br />
<br />
- RR data in responses of dubious reliability. When a resolver<br />
receives unsolicited responses or RR data other than that<br />
requested, it should discard it without caching it. The basic<br />
implication is that all sanity checks on a packet should be<br />
performed before any of it is cached.<br />
<br />
In a similar vein, when a resolver has a set of RRs for some name in a<br />
response, and wants to cache the RRs, it should check its cache for<br />
already existing RRs. Depending on the circumstances, either the data<br />
in the response or the cache is preferred, but the two should never be<br />
combined. If the data in the response is from authoritative data in the<br />
answer section, it is always preferred.<br />
<br />
8. MAIL SUPPORT<br />
<br />
The domain system defines a standard for mapping mailboxes into domain<br />
names, and two methods for using the mailbox information to derive mail<br />
routing information. The first method is called mail exchange binding<br />
and the other method is mailbox binding. The mailbox encoding standard<br />
and mail exchange binding are part of the DNS official protocol, and are<br />
the recommended method for mail routing in the Internet. Mailbox<br />
binding is an experimental feature which is still under development and<br />
subject to change.<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 47]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
The mailbox encoding standard assumes a mailbox name of the form<br />
"<local-part>@<mail-domain>". While the syntax allowed in each of these<br />
sections varies substantially between the various mail internets, the<br />
preferred syntax for the ARPA Internet is given in [RFC-822].<br />
<br />
The DNS encodes the <local-part> as a single label, and encodes the<br />
<mail-domain> as a domain name. The single label from the <local-part><br />
is prefaced to the domain name from <mail-domain> to form the domain<br />
name corresponding to the mailbox. Thus the mailbox HOSTMASTER@SRI-<br />
NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA. If the<br />
<local-part> contains dots or other special characters, its<br />
representation in a master file will require the use of backslash<br />
quoting to ensure that the domain name is properly encoded. For<br />
example, the mailbox Action.domains@ISI.EDU would be represented as<br />
Action\.domains.ISI.EDU.<br />
<br />
8.1. Mail exchange binding<br />
<br />
Mail exchange binding uses the <mail-domain> part of a mailbox<br />
specification to determine where mail should be sent. The <local-part><br />
is not even consulted. [RFC-974] specifies this method in detail, and<br />
should be consulted before attempting to use mail exchange support.<br />
<br />
One of the advantages of this method is that it decouples mail<br />
destination naming from the hosts used to support mail service, at the<br />
cost of another layer of indirection in the lookup function. However,<br />
the addition layer should eliminate the need for complicated "%", "!",<br />
etc encodings in <local-part>.<br />
<br />
The essence of the method is that the <mail-domain> is used as a domain<br />
name to locate type MX RRs which list hosts willing to accept mail for<br />
<mail-domain>, together with preference values which rank the hosts<br />
according to an order specified by the administrators for <mail-domain>.<br />
<br />
In this memo, the <mail-domain> ISI.EDU is used in examples, together<br />
with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for<br />
ISI.EDU. If a mailer had a message for Mockapetris@ISI.EDU, it would<br />
route it by looking up MX RRs for ISI.EDU. The MX RRs at ISI.EDU name<br />
VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host<br />
addresses.<br />
<br />
8.2. Mailbox binding (Experimental)<br />
<br />
In mailbox binding, the mailer uses the entire mail destination<br />
specification to construct a domain name. The encoded domain name for<br />
the mailbox is used as the QNAME field in a QTYPE=MAILB query.<br />
<br />
Several outcomes are possible for this query:<br />
<br />
<br />
<br />
Mockapetris [Page 48]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
1. The query can return a name error indicating that the mailbox<br />
does not exist as a domain name.<br />
<br />
In the long term, this would indicate that the specified<br />
mailbox doesn't exist. However, until the use of mailbox<br />
binding is universal, this error condition should be<br />
interpreted to mean that the organization identified by the<br />
global part does not support mailbox binding. The<br />
appropriate procedure is to revert to exchange binding at<br />
this point.<br />
<br />
2. The query can return a Mail Rename (MR) RR.<br />
<br />
The MR RR carries new mailbox specification in its RDATA<br />
field. The mailer should replace the old mailbox with the<br />
new one and retry the operation.<br />
<br />
3. The query can return a MB RR.<br />
<br />
The MB RR carries a domain name for a host in its RDATA<br />
field. The mailer should deliver the message to that host<br />
via whatever protocol is applicable, e.g., b,SMTP.<br />
<br />
4. The query can return one or more Mail Group (MG) RRs.<br />
<br />
This condition means that the mailbox was actually a mailing<br />
list or mail group, rather than a single mailbox. Each MG RR<br />
has a RDATA field that identifies a mailbox that is a member<br />
of the group. The mailer should deliver a copy of the<br />
message to each member.<br />
<br />
5. The query can return a MB RR as well as one or more MG RRs.<br />
<br />
This condition means the the mailbox was actually a mailing<br />
list. The mailer can either deliver the message to the host<br />
specified by the MB RR, which will in turn do the delivery to<br />
all members, or the mailer can use the MG RRs to do the<br />
expansion itself.<br />
<br />
In any of these cases, the response may include a Mail Information<br />
(MINFO) RR. This RR is usually associated with a mail group, but is<br />
legal with a MB. The MINFO RR identifies two mailboxes. One of these<br />
identifies a responsible person for the original mailbox name. This<br />
mailbox should be used for requests to be added to a mail group, etc.<br />
The second mailbox name in the MINFO RR identifies a mailbox that should<br />
receive error messages for mail failures. This is particularly<br />
appropriate for mailing lists when errors in member names should be<br />
reported to a person other than the one who sends a message to the list.<br />
<br />
<br />
<br />
Mockapetris [Page 49]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
New fields may be added to this RR in the future.<br />
<br />
<br />
9. REFERENCES and BIBLIOGRAPHY<br />
<br />
[Dyer 87] S. Dyer, F. Hsu, "Hesiod", Project Athena<br />
Technical Plan - Name Service, April 1987, version 1.9.<br />
<br />
Describes the fundamentals of the Hesiod name service.<br />
<br />
[IEN-116] J. Postel, "Internet Name Server", IEN-116,<br />
USC/Information Sciences Institute, August 1979.<br />
<br />
A name service obsoleted by the Domain Name System, but<br />
still in use.<br />
<br />
[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",<br />
Communications of the ACM, October 1986, volume 29, number<br />
10.<br />
<br />
[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network<br />
Information Center, SRI International, December 1977.<br />
<br />
[RFC-768] J. Postel, "User Datagram Protocol", RFC-768,<br />
USC/Information Sciences Institute, August 1980.<br />
<br />
[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793,<br />
USC/Information Sciences Institute, September 1981.<br />
<br />
[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT,<br />
September 1981.<br />
<br />
Suggests introduction of a hierarchy in place of a flat<br />
name space for the Internet.<br />
<br />
[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805,<br />
USC/Information Sciences Institute, February 1982.<br />
<br />
[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD<br />
Internet Host Table Specification", RFC-810, Network<br />
Information Center, SRI International, March 1982.<br />
<br />
Obsolete. See RFC-952.<br />
<br />
[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames<br />
Server", RFC-811, Network Information Center, SRI<br />
International, March 1982.<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 50]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
Obsolete. See RFC-953.<br />
<br />
[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,<br />
Network Information Center, SRI International, March<br />
1982.<br />
<br />
[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for<br />
Internet User Applications", RFC-819, Network<br />
Information Center, SRI International, August 1982.<br />
<br />
Early thoughts on the design of the domain system.<br />
Current implementation is completely different.<br />
<br />
[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821,<br />
USC/Information Sciences Institute, August 1980.<br />
<br />
[RFC-830] Z. Su, "A Distributed System for Internet Name Service",<br />
RFC-830, Network Information Center, SRI International,<br />
October 1982.<br />
<br />
Early thoughts on the design of the domain system.<br />
Current implementation is completely different.<br />
<br />
[RFC-882] P. Mockapetris, "Domain names - Concepts and<br />
Facilities," RFC-882, USC/Information Sciences<br />
Institute, November 1983.<br />
<br />
Superceeded by this memo.<br />
<br />
[RFC-883] P. Mockapetris, "Domain names - Implementation and<br />
Specification," RFC-883, USC/Information Sciences<br />
Institute, November 1983.<br />
<br />
Superceeded by this memo.<br />
<br />
[RFC-920] J. Postel and J. Reynolds, "Domain Requirements",<br />
RFC-920, USC/Information Sciences Institute,<br />
October 1984.<br />
<br />
Explains the naming scheme for top level domains.<br />
<br />
[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host<br />
Table Specification", RFC-952, SRI, October 1985.<br />
<br />
Specifies the format of HOSTS.TXT, the host/address<br />
table replaced by the DNS.<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 51]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",<br />
RFC-953, SRI, October 1985.<br />
<br />
This RFC contains the official specification of the<br />
hostname server protocol, which is obsoleted by the DNS.<br />
This TCP based protocol accesses information stored in<br />
the RFC-952 format, and is used to obtain copies of the<br />
host table.<br />
<br />
[RFC-973] P. Mockapetris, "Domain System Changes and<br />
Observations", RFC-973, USC/Information Sciences<br />
Institute, January 1986.<br />
<br />
Describes changes to RFC-882 and RFC-883 and reasons for<br />
them.<br />
<br />
[RFC-974] C. Partridge, "Mail routing and the domain system",<br />
RFC-974, CSNET CIC BBN Labs, January 1986.<br />
<br />
Describes the transition from HOSTS.TXT based mail<br />
addressing to the more powerful MX system used with the<br />
domain system.<br />
<br />
[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS<br />
service on a TCP/UDP transport: Concepts and Methods",<br />
RFC-1001, March 1987.<br />
<br />
This RFC and RFC-1002 are a preliminary design for<br />
NETBIOS on top of TCP/IP which proposes to base NetBIOS<br />
name service on top of the DNS.<br />
<br />
[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS<br />
service on a TCP/UDP transport: Detailed<br />
Specifications", RFC-1002, March 1987.<br />
<br />
[RFC-1010] J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,<br />
USC/Information Sciences Institute, May 1987.<br />
<br />
Contains socket numbers and mnemonics for host names,<br />
operating systems, etc.<br />
<br />
[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031,<br />
November 1987.<br />
<br />
Describes a plan for converting the MILNET to the DNS.<br />
<br />
[RFC-1032] M. Stahl, "Establishing a Domain - Guidelines for<br />
Administrators", RFC-1032, November 1987.<br />
<br />
<br />
<br />
Mockapetris [Page 52]<br />
<br />
RFC 1035 Domain Implementation and Specification November 1987<br />
<br />
<br />
Describes the registration policies used by the NIC to<br />
administer the top level domains and delegate subzones.<br />
<br />
[RFC-1033] M. Lottor, "Domain Administrators Operations Guide",<br />
RFC-1033, November 1987.<br />
<br />
A cookbook for domain administrators.<br />
<br />
[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET<br />
Name Server", Computer Networks, vol 6, nr 3, July 1982.<br />
<br />
Describes a name service for CSNET which is independent<br />
from the DNS and DNS use in the CSNET.</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-RFC&diff=13DNS-RFC2024-03-04T05:34:05Z<p>Yu：</p>
<hr />
<div># 基础DNS相关RFC<br />
<br />
* [[RFC 1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES]]<br />
* [[RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION]]<br />
<br />
<br />
# 基础DNS相关RFC</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-RFC&diff=12DNS-RFC2024-03-04T05:33:17Z<p>Yu：</p>
<hr />
<div># 基础DNS相关RFC<br />
<br />
* [[RFC 1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES]]<br />
<br />
<br />
# 基础DNS相关RFC</div>Yuhttps://www.dnswiki.cn/index.php?title=RFC_1034_-_DOMAIN_NAMES_-_CONCEPTS_AND_FACILITIES&diff=11RFC 1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES2024-03-04T05:32:48Z<p>Yu：创建页面，内容为“Network Working Group P. Mockapetris Request for Comments: 1034 ISI Obsoletes: RFCs 882, 883, 973 November 1987 DOMAIN NAMES - CONCEPTS AND FACILITIES…”</p>
<hr />
<div>Network Working Group P. Mockapetris <br />
Request for Comments: 1034 ISI <br />
Obsoletes: RFCs 882, 883, 973 November 1987 <br />
<br />
<br />
DOMAIN NAMES - CONCEPTS AND FACILITIES <br />
<br />
<br />
<br />
1. STATUS OF THIS MEMO <br />
<br />
This RFC is an introduction to the Domain Name System (DNS), and omits <br />
many details which can be found in a companion RFC, "Domain Names - <br />
Implementation and Specification" [RFC-1035]. That RFC assumes that the <br />
reader is familiar with the concepts discussed in this memo. <br />
<br />
A subset of DNS functions and data types constitute an official <br />
protocol. The official protocol includes standard queries and their <br />
responses and most of the Internet class data formats (e.g., host <br />
addresses). <br />
<br />
However, the domain system is intentionally extensible. Researchers are <br />
continuously proposing, implementing and experimenting with new data <br />
types, query types, classes, functions, etc. Thus while the components <br />
of the official protocol are expected to stay essentially unchanged and <br />
operate as a production service, experimental behavior should always be <br />
expected in extensions beyond the official protocol. Experimental or <br />
obsolete features are clearly marked in these RFCs, and such information <br />
should be used with caution. <br />
<br />
The reader is especially cautioned not to depend on the values which <br />
appear in examples to be current or complete, since their purpose is <br />
primarily pedagogical. Distribution of this memo is unlimited. <br />
<br />
2. INTRODUCTION <br />
<br />
This RFC introduces domain style names, their use for Internet mail and <br />
host address support, and the protocols and servers used to implement <br />
domain name facilities. <br />
<br />
2.1. The history of domain names <br />
<br />
The impetus for the development of the domain system was growth in the <br />
Internet: <br />
<br />
- Host name to address mappings were maintained by the Network <br />
Information Center (NIC) in a single file (HOSTS.TXT) which <br />
was FTPed by all hosts [RFC-952, RFC-953]. The total network <br />
<br />
<br />
<br />
Mockapetris [Page 1] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
bandwidth consumed in distributing a new version by this <br />
scheme is proportional to the square of the number of hosts in <br />
the network, and even when multiple levels of FTP are used, <br />
the outgoing FTP load on the NIC host is considerable. <br />
Explosive growth in the number of hosts didn't bode well for <br />
the future. <br />
<br />
- The network population was also changing in character. The <br />
timeshared hosts that made up the original ARPANET were being <br />
replaced with local networks of workstations. Local <br />
organizations were administering their own names and <br />
addresses, but had to wait for the NIC to change HOSTS.TXT to <br />
make changes visible to the Internet at large. Organizations <br />
also wanted some local structure on the name space. <br />
<br />
- The applications on the Internet were getting more <br />
sophisticated and creating a need for general purpose name <br />
service. <br />
<br />
<br />
The result was several ideas about name spaces and their management <br />
[IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a <br />
common thread was the idea of a hierarchical name space, with the <br />
hierarchy roughly corresponding to organizational structure, and names <br />
using "." as the character to mark the boundary between hierarchy <br />
levels. A design using a distributed database and generalized resources <br />
was described in [RFC-882, RFC-883]. Based on experience with several <br />
implementations, the system evolved into the scheme described in this <br />
memo. <br />
<br />
The terms "domain" or "domain name" are used in many contexts beyond the <br />
DNS described here. Very often, the term domain name is used to refer <br />
to a name with structure indicated by dots, but no relation to the DNS. <br />
This is particularly true in mail addressing [Quarterman 86]. <br />
<br />
2.2. DNS design goals <br />
<br />
The design goals of the DNS influence its structure. They are: <br />
<br />
- The primary goal is a consistent name space which will be used <br />
for referring to resources. In order to avoid the problems <br />
caused by ad hoc encodings, names should not be required to <br />
contain network identifiers, addresses, routes, or similar <br />
information as part of the name. <br />
<br />
- The sheer size of the database and frequency of updates <br />
suggest that it must be maintained in a distributed manner, <br />
with local caching to improve performance. Approaches that <br />
<br />
<br />
<br />
Mockapetris [Page 2] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
attempt to collect a consistent copy of the entire database <br />
will become more and more expensive and difficult, and hence <br />
should be avoided. The same principle holds for the structure <br />
of the name space, and in particular mechanisms for creating <br />
and deleting names; these should also be distributed. <br />
<br />
top ICANNDNS RFC Annotations project<br />
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.<br />
<br />
This RFC is included in the DNS RFCs annotation project whose home page is here.<br />
<br />
GLOBAL UPDATED<br />
Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181, RFC2308, RFC2535, RFC4033, RFC4034, RFC4035, RFC4035, RFC4343, RFC4592, RFC5936, RFC8020, RFC8482, RFC8767<br />
GLOBAL POTENTIALLY UPDATED<br />
Potentially updated by draft-ietf-dnsop-glue-is-not-optional (Active)<br />
GLOBAL HAS ERRATA<br />
Has errata: #564, #565, #755, #1074, #4229, #4230, #4269, #4270, #4511, #4740, #4893, #4943, #5316, #6460, #6461, #6462, #7111<br />
GLOBAL Stephan Garland(Editorial Erratum #7111) [Verified]<br />
based on outdated version<br />
insure<br />
<br />
It should say:<br />
ensure<br />
<br />
Section 3.6.2 uses both ensure and insure to mean the same thing, which<br />
is to guarantee or make certain. Sections 4.1, 4.2.2, and 5.3.3 all use<br />
the insure form.<br />
<br />
Generally, insure is used in the financial sense, with making certain<br />
being a secondary definition. At the very least, consistency in the same<br />
paragraph of 3.6.2 would be cleaner.<br />
GLOBAL V. Risk, ISC.orgBIND 9 implementation note2022-08-15<br />
This RFC is implemented in BIND 9.18 (all versions).<br />
<br />
GLOBAL P. Hoffman, ICANNMany RFCs say they update RFC 1034, but don't<br />
Many of the RFCs that are listed as updating RFC 1034 actually just mention it, but don't actually update anything here. For example, many of them simply define new RRtypes, which is not really an update to RFC 1034, just to the IANA registry it created. The RFCs that do update RFC 1034 are listed throughout this document.<br />
<br />
- Where there tradeoffs between the cost of acquiring data, the <br />
speed of updates, and the accuracy of caches, the source of <br />
the data should control the tradeoff. <br />
<br />
- The costs of implementing such a facility dictate that it be <br />
generally useful, and not restricted to a single application. <br />
We should be able to use names to retrieve host addresses, <br />
mailbox data, and other as yet undetermined information. All <br />
data associated with a name is tagged with a type, and queries <br />
can be limited to a single type. <br />
<br />
- Because we want the name space to be useful in dissimilar <br />
networks and applications, we provide the ability to use the <br />
same name space with different protocol families or <br />
management. For example, host address formats differ between <br />
protocols, though all protocols have the notion of address. <br />
The DNS tags all data with a class as well as the type, so <br />
that we can allow parallel use of different formats for data <br />
of type address. <br />
<br />
- We want name server transactions to be independent of the <br />
communications system that carries them. Some systems may <br />
wish to use datagrams for queries and responses, and only <br />
establish virtual circuits for transactions that need the <br />
reliability (e.g., database updates, long transactions); other <br />
systems will use virtual circuits exclusively. <br />
<br />
- The system should be useful across a wide spectrum of host <br />
capabilities. Both personal computers and large timeshared <br />
hosts should be able to use the system, though perhaps in <br />
different ways. <br />
<br />
line-117 John Kristoff(Editorial Erratum #1074) [Verified]<br />
based on outdated version<br />
Section 2.2 says:<br />
- Where there tradeoffs between the cost of acquiring data, the<br />
It should say:<br />
- Where there are tradeoffs between the cost of acquiring data, the<br />
2.3. Assumptions about usage <br />
<br />
The organization of the domain system derives from some assumptions <br />
about the needs and usage patterns of its user community and is designed <br />
to avoid many of the the complicated problems found in general purpose <br />
database systems. <br />
<br />
The assumptions are: <br />
<br />
- The size of the total database will initially be proportional <br />
<br />
<br />
<br />
Mockapetris [Page 3] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
to the number of hosts using the system, but will eventually <br />
grow to be proportional to the number of users on those hosts <br />
as mailboxes and other information are added to the domain <br />
system. <br />
<br />
- Most of the data in the system will change very slowly (e.g., <br />
mailbox bindings, host addresses), but that the system should <br />
be able to deal with subsets that change more rapidly (on the <br />
order of seconds or minutes). <br />
<br />
- The administrative boundaries used to distribute <br />
responsibility for the database will usually correspond to <br />
organizations that have one or more hosts. Each organization <br />
that has responsibility for a particular set of domains will <br />
provide redundant name servers, either on the organization's <br />
own hosts or other hosts that the organization arranges to <br />
use. <br />
<br />
- Clients of the domain system should be able to identify <br />
trusted name servers they prefer to use before accepting <br />
referrals to name servers outside of this "trusted" set. <br />
<br />
- Access to information is more critical than instantaneous <br />
updates or guarantees of consistency. Hence the update <br />
process allows updates to percolate out through the users of <br />
the domain system rather than guaranteeing that all copies are <br />
simultaneously updated. When updates are unavailable due to <br />
network or host failure, the usual course is to believe old <br />
information while continuing efforts to update it. The <br />
general model is that copies are distributed with timeouts for <br />
refreshing. The distributor sets the timeout value and the <br />
recipient of the distribution is responsible for performing <br />
the refresh. In special situations, very short intervals can <br />
be specified, or the owner can prohibit copies. <br />
<br />
- In any system that has a distributed database, a particular <br />
name server may be presented with a query that can only be <br />
answered by some other server. The two general approaches to <br />
dealing with this problem are "recursive", in which the first <br />
server pursues the query for the client at another server, and <br />
"iterative", in which the server refers the client to another <br />
server and lets the client pursue the query. Both approaches <br />
have advantages and disadvantages, but the iterative approach <br />
is preferred for the datagram style of access. The domain <br />
system requires implementation of the iterative approach, but <br />
allows the recursive approach as an option. <br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 4] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
The domain system assumes that all data originates in master files <br />
scattered through the hosts that use the domain system. These master <br />
files are updated by local system administrators. Master files are text <br />
files that are read by a local name server, and hence become available <br />
through the name servers to users of the domain system. The user <br />
programs access name servers through standard programs called resolvers. <br />
<br />
The standard format of master files allows them to be exchanged between <br />
hosts (via FTP, mail, or some other mechanism); this facility is useful <br />
when an organization wants a domain, but doesn't want to support a name <br />
server. The organization can maintain the master files locally using a <br />
text editor, transfer them to a foreign host which runs a name server, <br />
and then arrange with the system administrator of the name server to get <br />
the files loaded. <br />
<br />
Each host's name servers and resolvers are configured by a local system <br />
administrator [RFC-1033]. For a name server, this configuration data <br />
includes the identity of local master files and instructions on which <br />
non-local master files are to be loaded from foreign servers. The name <br />
server uses the master files or copies to load its zones. For <br />
resolvers, the configuration data identifies the name servers which <br />
should be the primary sources of information. <br />
<br />
The domain system defines procedures for accessing the data and for <br />
referrals to other name servers. The domain system also defines <br />
procedures for caching retrieved data and for periodic refreshing of <br />
data defined by the system administrator. <br />
<br />
The system administrators provide: <br />
<br />
- The definition of zone boundaries. <br />
<br />
- Master files of data. <br />
<br />
- Updates to master files. <br />
<br />
- Statements of the refresh policies desired. <br />
<br />
The domain system provides: <br />
<br />
- Standard formats for resource data. <br />
<br />
- Standard methods for querying the database. <br />
<br />
- Standard methods for name servers to refresh local data from <br />
foreign name servers. <br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 5] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
2.4. Elements of the DNS <br />
<br />
The DNS has three major components: <br />
<br />
- The DOMAIN NAME SPACE and RESOURCE RECORDS, which are <br />
specifications for a tree structured name space and data <br />
associated with the names. Conceptually, each node and leaf <br />
of the domain name space tree names a set of information, and <br />
query operations are attempts to extract specific types of <br />
information from a particular set. A query names the domain <br />
name of interest and describes the type of resource <br />
information that is desired. For example, the Internet <br />
uses some of its domain names to identify hosts; queries for <br />
address resources return Internet host addresses. <br />
<br />
- NAME SERVERS are server programs which hold information about <br />
the domain tree's structure and set information. A name <br />
server may cache structure or set information about any part <br />
of the domain tree, but in general a particular name server <br />
has complete information about a subset of the domain space, <br />
and pointers to other name servers that can be used to lead to <br />
information from any part of the domain tree. Name servers <br />
know the parts of the domain tree for which they have complete <br />
information; a name server is said to be an AUTHORITY for <br />
these parts of the name space. Authoritative information is <br />
organized into units called ZONEs, and these zones can be <br />
automatically distributed to the name servers which provide <br />
redundant service for the data in a zone. <br />
<br />
- RESOLVERS are programs that extract information from name <br />
servers in response to client requests. Resolvers must be <br />
able to access at least one name server and use that name <br />
server's information to answer a query directly, or pursue the <br />
query using referrals to other name servers. A resolver will <br />
typically be a system routine that is directly accessible to <br />
user programs; hence no protocol is necessary between the <br />
resolver and the user program. <br />
<br />
These three components roughly correspond to the three layers or views <br />
of the domain system: <br />
<br />
- From the user's point of view, the domain system is accessed <br />
through a simple procedure or OS call to a local resolver. <br />
The domain space consists of a single tree and the user can <br />
request information from any section of the tree. <br />
<br />
- From the resolver's point of view, the domain system is <br />
composed of an unknown number of name servers. Each name <br />
<br />
<br />
<br />
Mockapetris [Page 6] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
server has one or more pieces of the whole domain tree's data, <br />
but the resolver views each of these databases as essentially <br />
static. <br />
<br />
- From a name server's point of view, the domain system consists <br />
of separate sets of local information called zones. The name <br />
server has local copies of some of the zones. The name server <br />
must periodically refresh its zones from master copies in <br />
local files or foreign name servers. The name server must <br />
concurrently process queries that arrive from resolvers. <br />
<br />
section-2.3 Jean-Philippe Paradis(Editorial Erratum #4269) [Held for Document Update]<br />
based on outdated version<br />
The organization of the domain system derives from some assumptions<br />
about the needs and usage patterns of its user community and is designed<br />
to avoid many of the the complicated problems found in general purpose<br />
database systems.<br />
It should say:<br />
The organization of the domain system derives from some assumptions<br />
about the needs and usage patterns of its user community and is designed<br />
to avoid many of the complicated problems found in general purpose<br />
database systems.<br />
Just a duplicate "the".<br />
In the interests of performance, implementations may couple these <br />
functions. For example, a resolver on the same machine as a name server <br />
might share a database consisting of the the zones managed by the name <br />
server and the cache managed by the resolver. <br />
<br />
3. DOMAIN NAME SPACE and RESOURCE RECORDS <br />
<br />
line-342 Jean-Philippe Paradis(Editorial Erratum #4270) [Held for Document Update]<br />
based on outdated version<br />
In the interests of performance, implementations may couple these<br />
functions. For example, a resolver on the same machine as a name server<br />
might share a database consisting of the the zones managed by the name<br />
server and the cache managed by the resolver.<br />
It should say:<br />
In the interests of performance, implementations may couple these<br />
functions. For example, a resolver on the same machine as a name server<br />
might share a database consisting of the zones managed by the name<br />
server and the cache managed by the resolver.<br />
Just a duplicate "the".<br />
3.1. Name space specifications and terminology <br />
<br />
The domain name space is a tree structure. Each node and leaf on the <br />
tree corresponds to a resource set (which may be empty). The domain <br />
system makes no distinctions between the uses of the interior nodes and <br />
leaves, and this memo uses the term "node" to refer to both. <br />
<br />
Each node has a label, which is zero to 63 octets in length. Brother <br />
nodes may not have the same label, although the same label can be used <br />
for nodes which are not brothers. One label is reserved, and that is <br />
the null (i.e., zero length) label used for the root. <br />
<br />
The domain name of a node is the list of the labels on the path from the <br />
node to the root of the tree. By convention, the labels that compose a <br />
domain name are printed or read left to right, from the most specific <br />
(lowest, farthest from the root) to the least specific (highest, closest <br />
to the root). <br />
<br />
Internally, programs that manipulate domain names should represent them <br />
as sequences of labels, where each label is a length octet followed by <br />
an octet string. Because all domain names end at the root, which has a <br />
null string for a label, these internal representations can use a length <br />
byte of zero to terminate a domain name. <br />
<br />
line-349 P. Hoffman, ICANNRFC 8020 clarifies empty non-terminals and zone cuts<br />
RFC8020 extensively describes how zone cuts are determined, particularly in the presence of empty non-terminals. It says "This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist."<br />
<br />
Section 3.1 of RFC 8020 says:<br />
This document clarifies possible ambiguities in [RFC1034] that did<br />
not clearly distinguish Empty Non-Terminal (ENT) names ([RFC7719])<br />
from nonexistent names, and it refers to subsequent documents that<br />
do. ENTs are nodes in the DNS that do not have resource record sets<br />
associated with them but have descendant nodes that do. The correct<br />
response to ENTs is NODATA (i.e., a response code of NOERROR and an<br />
empty answer section). Additional clarifying language on these<br />
points is provided in Section 7.16 of [RFC2136] and in Sections 2.2.2<br />
and 2.2.3 of [RFC4592].<br />
By convention, domain names can be stored with arbitrary case, but <br />
domain name comparisons for all present domain functions are done in a <br />
case-insensitive manner, assuming an ASCII character set, and a high <br />
order zero bit. This means that you are free to create a node with <br />
label "A" or a node with label "a", but not both as brothers; you could <br />
refer to either using "a" or "A". When you receive a domain name or <br />
<br />
<br />
<br />
Mockapetris [Page 7] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
label, you should preserve its case. The rationale for this choice is <br />
that we may someday need to add full binary domain names for new <br />
services; existing services would not be changed. <br />
<br />
When a user needs to type a domain name, the length of each label is <br />
omitted and the labels are separated by dots ("."). Since a complete <br />
domain name ends with the root label, this leads to a printed form which <br />
ends in a dot. We use this property to distinguish between: <br />
<br />
- a character string which represents a complete domain name <br />
(often called "absolute"). For example, "poneria.ISI.EDU." <br />
<br />
- a character string that represents the starting labels of a <br />
domain name which is incomplete, and should be completed by <br />
local software using knowledge of the local domain (often <br />
called "relative"). For example, "poneria" used in the <br />
ISI.EDU domain. <br />
<br />
Relative names are either taken relative to a well known origin, or to a <br />
list of domains used as a search list. Relative names appear mostly at <br />
the user interface, where their interpretation varies from <br />
implementation to implementation, and in master files, where they are <br />
relative to a single origin domain name. The most common interpretation <br />
uses the root "." as either the single origin or as one of the members <br />
of the search list, so a multi-label relative name is often one where <br />
the trailing dot has been omitted to save typing. <br />
<br />
To simplify implementations, the total number of octets that represent a <br />
domain name (i.e., the sum of all label octets and label lengths) is <br />
limited to 255. <br />
<br />
A domain is identified by a domain name, and consists of that part of <br />
the domain name space that is at or below the domain name which <br />
specifies the domain. A domain is a subdomain of another domain if it <br />
is contained within that domain. This relationship can be tested by <br />
seeing if the subdomain's name ends with the containing domain's name. <br />
For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ". <br />
<br />
3.2. Administrative guidelines on use <br />
<br />
As a matter of policy, the DNS technical specifications do not mandate a <br />
particular tree structure or rules for selecting labels; its goal is to <br />
be as general as possible, so that it can be used to build arbitrary <br />
applications. In particular, the system was designed so that the name <br />
space did not have to be organized along the lines of network <br />
boundaries, name servers, etc. The rationale for this is not that the <br />
name space should have no implied semantics, but rather that the choice <br />
of implied semantics should be left open to be used for the problem at <br />
<br />
<br />
<br />
Mockapetris [Page 8] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
hand, and that different parts of the tree can have different implied <br />
semantics. For example, the IN-ADDR.ARPA domain is organized and <br />
distributed by network and host address because its role is to translate <br />
from network or host numbers to names; NetBIOS domains [RFC-1001, RFC- <br />
1002] are flat because that is appropriate for that application. <br />
<br />
However, there are some guidelines that apply to the "normal" parts of <br />
the name space used for hosts, mailboxes, etc., that will make the name <br />
space more uniform, provide for growth, and minimize problems as <br />
software is converted from the older host table. The political <br />
decisions about the top levels of the tree originated in RFC-920. <br />
Current policy for the top levels is discussed in [RFC-1032]. MILNET <br />
conversion issues are covered in [RFC-1031]. <br />
<br />
Lower domains which will eventually be broken into multiple zones should <br />
provide branching at the top of the domain so that the eventual <br />
decomposition can be done without renaming. Node labels which use <br />
special characters, leading digits, etc., are likely to break older <br />
software which depends on more restrictive choices. <br />
<br />
3.3. Technical guidelines on use <br />
<br />
Before the DNS can be used to hold naming information for some kind of <br />
object, two needs must be met: <br />
<br />
- A convention for mapping between object names and domain <br />
names. This describes how information about an object is <br />
accessed. <br />
<br />
- RR types and data formats for describing the object. <br />
<br />
These rules can be quite simple or fairly complex. Very often, the <br />
designer must take into account existing formats and plan for upward <br />
compatibility for existing usage. Multiple mappings or levels of <br />
mapping may be required. <br />
<br />
For hosts, the mapping depends on the existing syntax for host names <br />
which is a subset of the usual text representation for domain names, <br />
together with RR formats for describing host addresses, etc. Because we <br />
need a reliable inverse mapping from address to host name, a special <br />
mapping for addresses into the IN-ADDR.ARPA domain is also defined. <br />
<br />
line-373 P. Hoffman, ICANNRFC 4343 clarifies what is meant by upper-case and lower-case<br />
All of RFC4343 is relevant to any discussion of the case of characters.<br />
<br />
For mailboxes, the mapping is slightly more complex. The usual mail <br />
address <local-part>@<mail-domain> is mapped into a domain name by <br />
converting <local-part> into a single label (regardles of dots it <br />
contains), converting <mail-domain> into a domain name using the usual <br />
text format for domain names (dots denote label breaks), and <br />
concatenating the two to form a single domain name. Thus the mailbox <br />
<br />
<br />
<br />
Mockapetris [Page 9] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by <br />
HOSTMASTER.SRI-NIC.ARPA. An appreciation for the reasons behind this <br />
design also must take into account the scheme for mail exchanges [RFC- <br />
974]. <br />
<br />
The typical user is not concerned with defining these rules, but should <br />
understand that they usually are the result of numerous compromises <br />
between desires for upward compatibility with old usage, interactions <br />
between different object definitions, and the inevitable urge to add new <br />
features when defining the rules. The way the DNS is used to support <br />
some object is often more crucial than the restrictions inherent in the <br />
DNS. <br />
<br />
3.4. Example name space <br />
<br />
The following figure shows a part of the current domain name space, and <br />
is used in many examples in this RFC. Note that the tree is a very <br />
small subset of the actual name space. <br />
<br />
| <br />
| <br />
+---------------------+------------------+ <br />
| | | <br />
MIL EDU ARPA <br />
| | | <br />
| | | <br />
+-----+-----+ | +------+-----+-----+ <br />
| | | | | | | <br />
BRL NOSC DARPA | IN-ADDR SRI-NIC ACC <br />
| <br />
+--------+------------------+---------------+--------+ <br />
| | | | | <br />
UCI MIT | UDEL YALE <br />
| ISI <br />
| | <br />
+---+---+ | <br />
| | | <br />
LCS ACHILLES +--+-----+-----+--------+ <br />
| | | | | | <br />
XX A C VAXA VENERA Mockapetris <br />
<br />
In this example, the root domain has three immediate subdomains: MIL, <br />
EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named <br />
XX.LCS.MIT.EDU. All of the leaves are also domains. <br />
<br />
3.5. Preferred name syntax <br />
<br />
The DNS specifications attempt to be as general as possible in the rules <br />
<br />
<br />
<br />
Mockapetris [Page 10] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
for constructing domain names. The idea is that the name of any <br />
existing object can be expressed as a domain name with minimal changes. <br />
However, when assigning a domain name for an object, the prudent user <br />
will select a name which satisfies both the rules of the domain system <br />
and any existing rules for the object, whether these rules are published <br />
or implied by existing programs. <br />
<br />
For example, when naming a mail domain, the user should satisfy both the <br />
rules of this memo and those in RFC-822. When creating a new host name, <br />
the old rules for HOSTS.TXT should be followed. This avoids problems <br />
when old software is converted to use domain names. <br />
<br />
The following syntax will result in fewer problems with many <br />
applications that use domain names (e.g., mail, TELNET). <br />
<br />
<domain> ::= <subdomain> | " " <br />
<br />
<subdomain> ::= <label> | <subdomain> "." <label> <br />
<br />
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ] <br />
<br />
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> <br />
<br />
<let-dig-hyp> ::= <let-dig> | "-" <br />
<br />
<let-dig> ::= <letter> | <digit> <br />
<br />
<letter> ::= any one of the 52 alphabetic characters A through Z in <br />
upper case and a through z in lower case <br />
<br />
<digit> ::= any one of the ten digits 0 through 9 <br />
<br />
line-483 Chlisin(Editorial Erratum #564) [Verified]<br />
based on outdated version<br />
The usual mail address <local-part>@<mail-domain> is mapped into a<br />
domain name by converting <local-part> into a single label<br />
(regardles of dots it contains), converting <mail-domain> into a<br />
domain name using the usual text format for domain names (dots<br />
denote label breaks), and concatenating the two to form a single<br />
domain name. <br />
It should say:<br />
The usual mail address <local-part>@<mail-domain> is mapped into a<br />
domain name by converting <local-part> into a single label<br />
(regardless of dots it contains), converting <mail-domain> into a<br />
domain name using the usual text format for domain names (dots<br />
denote label breaks), and concatenating the two to form a single<br />
domain name.<br />
Note that while upper and lower case letters are allowed in domain <br />
names, no significance is attached to the case. That is, two names with <br />
the same spelling but different case are to be treated as if identical. <br />
<br />
The labels must follow the rules for ARPANET host names. They must <br />
start with a letter, end with a letter or digit, and have as interior <br />
characters only letters, digits, and hyphen. There are also some <br />
restrictions on the length. Labels must be 63 characters or less. <br />
<br />
For example, the following strings identify hosts in the Internet: <br />
<br />
A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA <br />
<br />
3.6. Resource Records <br />
<br />
A domain name identifies a node. Each node has a set of resource <br />
<br />
<br />
<br />
Mockapetris [Page 11] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
information, which may be empty. The set of resource information <br />
associated with a particular name is composed of separate resource <br />
records (RRs). The order of RRs in a set is not significant, and need <br />
not be preserved by name servers, resolvers, or other parts of the DNS. <br />
<br />
When we talk about a specific RR, we assume it has the following: <br />
<br />
owner which is the domain name where the RR is found. <br />
<br />
type which is an encoded 16 bit value that specifies the type <br />
of the resource in this resource record. Types refer to <br />
abstract resources. <br />
<br />
This memo uses the following types: <br />
<br />
A a host address <br />
<br />
CNAME identifies the canonical name of an <br />
alias <br />
<br />
HINFO identifies the CPU and OS used by a host <br />
<br />
line-583 P. Hoffman, ICANNRFC 4343 clarifies what is meant by upper-case and lower-case<br />
All of RFC4343 is relevant to any discussion of the case of characters.<br />
<br />
MX identifies a mail exchange for the <br />
domain. See [RFC-974 for details. <br />
<br />
NS <br />
the authoritative name server for the domain <br />
<br />
PTR <br />
a pointer to another part of the domain name space <br />
<br />
SOA <br />
identifies the start of a zone of authority] <br />
<br />
class which is an encoded 16 bit value which identifies a <br />
protocol family or instance of a protocol. <br />
<br />
This memo uses the following classes: <br />
<br />
IN the Internet system <br />
<br />
CH the Chaos system <br />
<br />
line-628 Han Ge Xin(Editorial Erratum #4511) [Held for Document Update]<br />
based on outdated version<br />
identifies a mail exchange for the domain. See [RFC-974 for details.<br />
It should say:<br />
identifies a mail exchange for the domain. See [RFC-974] for details.<br />
Just missing the "]"<br />
TTL which is the time to live of the RR. This field is a 32 <br />
bit integer in units of seconds, an is primarily used by <br />
resolvers when they cache RRs. The TTL describes how <br />
long a RR can be cached before it should be discarded. <br />
<br />
<br />
<br />
<br />
Mockapetris [Page 12] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
RDATA which is the type and sometimes class dependent data <br />
which describes the resource: <br />
<br />
A For the IN class, a 32 bit IP address <br />
<br />
For the CH class, a domain name followed <br />
by a 16 bit octal Chaos address. <br />
<br />
CNAME a domain name. <br />
<br />
MX a 16 bit preference value (lower is <br />
better) followed by a host name willing <br />
to act as a mail exchange for the owner <br />
domain. <br />
<br />
NS a host name. <br />
<br />
PTR a domain name. <br />
<br />
SOA several fields. <br />
<br />
The owner name is often implicit, rather than forming an integral part <br />
of the RR. For example, many name servers internally form tree or hash <br />
structures for the name space, and chain RRs off nodes. The remaining <br />
RR parts are the fixed header (type, class, TTL) which is consistent for <br />
all RRs, and a variable part (RDATA) that fits the needs of the resource <br />
being described. <br />
<br />
The meaning of the TTL field is a time limit on how long an RR can be <br />
kept in a cache. This limit does not apply to authoritative data in <br />
zones; it is also timed out, but by the refreshing policies for the <br />
zone. The TTL is assigned by the administrator for the zone where the <br />
data originates. While short TTLs can be used to minimize caching, and <br />
a zero TTL prohibits caching, the realities of Internet performance <br />
suggest that these times should be on the order of days for the typical <br />
host. If a change can be anticipated, the TTL can be reduced prior to <br />
the change to minimize inconsistency during the change, and then <br />
increased back to its former value following the change. <br />
<br />
The data in the RDATA section of RRs is carried as a combination of <br />
binary strings and domain names. The domain names are frequently used <br />
as "pointers" to other data in the DNS. <br />
<br />
3.6.1. Textual expression of RRs <br />
<br />
RRs are represented in binary form in the packets of the DNS protocol, <br />
and are usually represented in highly encoded form when stored in a name <br />
server or resolver. In this memo, we adopt a style similar to that used <br />
<br />
<br />
<br />
Mockapetris [Page 13] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
in master files in order to show the contents of RRs. In this format, <br />
most RRs are shown on a single line, although continuation lines are <br />
possible using parentheses. <br />
<br />
The start of the line gives the owner of the RR. If a line begins with <br />
a blank, then the owner is assumed to be the same as that of the <br />
previous RR. Blank lines are often included for readability. <br />
<br />
Following the owner, we list the TTL, type, and class of the RR. Class <br />
and type use the mnemonics defined above, and TTL is an integer before <br />
the type field. In order to avoid ambiguity in parsing, type and class <br />
mnemonics are disjoint, TTLs are integers, and the type mnemonic is <br />
always last. The IN class and TTL values are often omitted from examples <br />
in the interests of clarity. <br />
<br />
The resource data or RDATA section of the RR are given using knowledge <br />
of the typical representation for the data. <br />
<br />
For example, we might show the RRs carried in a message as: <br />
<br />
ISI.EDU. MX 10 VENERA.ISI.EDU. <br />
MX 10 VAXA.ISI.EDU. <br />
VENERA.ISI.EDU. A 128.9.0.32 <br />
A 10.1.0.52 <br />
VAXA.ISI.EDU. A 10.2.0.27 <br />
A 128.9.0.33 <br />
<br />
The MX RRs have an RDATA section which consists of a 16 bit number <br />
followed by a domain name. The address RRs use a standard IP address <br />
format to contain a 32 bit internet address. <br />
<br />
This example shows six RRs, with two RRs at each of three domain names. <br />
<br />
Similarly we might see: <br />
<br />
XX.LCS.MIT.EDU. IN A 10.0.0.44 <br />
CH A MIT.EDU. 2420 <br />
<br />
This example shows two addresses for XX.LCS.MIT.EDU, each of a different <br />
class. <br />
<br />
3.6.2. Aliases and canonical names <br />
<br />
In existing systems, hosts and other resources often have several names <br />
that identify the same resource. For example, the names C.ISI.EDU and <br />
USC-ISIC.ARPA both identify the same host. Similarly, in the case of <br />
mailboxes, many organizations provide many names that actually go to the <br />
same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU, <br />
<br />
<br />
<br />
Mockapetris [Page 14] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
and PVM@ISI.EDU all go to the same mailbox (although the mechanism <br />
behind this is somewhat complicated). <br />
<br />
Most of these systems have a notion that one of the equivalent set of <br />
names is the canonical or primary name and all others are aliases. <br />
<br />
The domain system provides such a feature using the canonical name <br />
(CNAME) RR. A CNAME RR identifies its owner name as an alias, and <br />
specifies the corresponding canonical name in the RDATA section of the <br />
line-649 P. Hoffman, ICANNRFC 8767 allows caching of records past their TTL<br />
The abstract of RFC8767 says: "This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data." The reason this updates RFC 1034 is that the definition of TTL in RFC 1034 says "The TTL describes how long a RR can be cached before it should be discarded." RFC 8767 softens that "should" and describes various scenarios when it is acceptable to serve stale data.<br />
<br />
RR. If a CNAME RR is present at a node, no other data should be <br />
present; this ensures that the data for a canonical name and its aliases <br />
cannot be different. This rule also insures that a cached CNAME can be <br />
used without checking with an authoritative server for other RR types. <br />
<br />
CNAME RRs cause special action in DNS software. When a name server <br />
fails to find a desired RR in the resource set associated with the <br />
domain name, it checks to see if the resource set consists of a CNAME <br />
record with a matching class. If so, the name server includes the CNAME <br />
record in the response and restarts the query at the domain name <br />
specified in the data field of the CNAME record. The one exception to <br />
this rule is that queries which match the CNAME type are not restarted. <br />
<br />
line-780 P. Hoffman, ICANNRFC 4034 changes what else can exist with a CNAME, namely RRSIG RRs<br />
Section 3 of RFC4034 says:<br />
Because every authoritative RRset in a zone must be protected by a<br />
digital signature, RRSIG RRs must be present for names containing a<br />
CNAME RR. This is a change to the traditional DNS specification<br />
[RFC1034], which stated that if a CNAME is present for a name, it is<br />
the only type allowed at that name. A RRSIG and NSEC (see Section 4)<br />
MUST exist for the same name as a CNAME resource record in a signed<br />
zone.<br />
Similar wording is found in Section 2.5 of RFC4035.<br />
<br />
For example, suppose a name server was processing a query with for USC- <br />
ISIC.ARPA, asking for type A information, and had the following resource <br />
records: <br />
<br />
USC-ISIC.ARPA IN CNAME C.ISI.EDU <br />
<br />
C.ISI.EDU IN A 10.0.0.52 <br />
<br />
Both of these RRs would be returned in the response to the type A query, <br />
while a type CNAME or * query should return just the CNAME. <br />
<br />
Domain names in RRs which point at another name should always point at <br />
the primary name and not the alias. This avoids extra indirections in <br />
accessing information. For example, the address to name RR for the <br />
above host should be: <br />
<br />
52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU <br />
<br />
rather than pointing at USC-ISIC.ARPA. Of course, by the robustness <br />
principle, domain software should not fail when presented with CNAME <br />
chains or loops; CNAME chains should be followed and CNAME loops <br />
signalled as an error. <br />
<br />
line-793 John Kristoff(Editorial Erratum #1074) [Verified]<br />
based on outdated version<br />
Section 3.6.2 says:<br />
For example, suppose a name server was processing a query with for USC-<br />
It should say:<br />
For example, suppose a name server was processing a query for USC-<br />
3.7. Queries <br />
<br />
Queries are messages which may be sent to a name server to provoke a <br />
<br />
<br />
<br />
Mockapetris [Page 15] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
response. In the Internet, queries are carried in UDP datagrams or over <br />
TCP connections. The response by the name server either answers the <br />
question posed in the query, refers the requester to another set of name <br />
servers, or signals some error condition. <br />
<br />
In general, the user does not generate queries directly, but instead <br />
makes a request to a resolver which in turn sends one or more queries to <br />
name servers and deals with the error conditions and referrals that may <br />
result. Of course, the possible questions which can be asked in a query <br />
does shape the kind of service a resolver can provide. <br />
<br />
DNS queries and responses are carried in a standard message format. The <br />
message format has a header containing a number of fixed fields which <br />
are always present, and four sections which carry query parameters and <br />
RRs. <br />
<br />
The most important field in the header is a four bit field called an <br />
opcode which separates different queries. Of the possible 16 values, <br />
one (standard query) is part of the official protocol, two (inverse <br />
query and status query) are options, one (completion) is obsolete, and <br />
the rest are unassigned. <br />
<br />
The four sections are: <br />
<br />
Question Carries the query name and other query parameters. <br />
<br />
Answer Carries RRs which directly answer the query. <br />
<br />
Authority Carries RRs which describe other authoritative servers. <br />
May optionally carry the SOA RR for the authoritative <br />
data in the answer section. <br />
<br />
Additional Carries RRs which may be helpful in using the RRs in the <br />
other sections. <br />
<br />
Note that the content, but not the format, of these sections varies with <br />
header opcode. <br />
<br />
3.7.1. Standard queries <br />
<br />
A standard query specifies a target domain name (QNAME), query type <br />
(QTYPE), and query class (QCLASS) and asks for RRs which match. This <br />
type of query makes up such a vast majority of DNS queries that we use <br />
the term "query" to mean standard query unless otherwise specified. The <br />
QTYPE and QCLASS fields are each 16 bits long, and are a superset of <br />
defined types and classes. <br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 16] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
The QTYPE field may contain: <br />
<br />
<any type> matches just that type. (e.g., A, PTR). <br />
<br />
AXFR special zone transfer QTYPE. <br />
<br />
MAILB matches all mail box related RRs (e.g. MB and MG). <br />
<br />
* matches all RR types. <br />
<br />
The QCLASS field may contain: <br />
<br />
<any class> matches just that class (e.g., IN, CH). <br />
<br />
* matches aLL RR classes. <br />
<br />
Using the query domain name, QTYPE, and QCLASS, the name server looks <br />
for matching RRs. In addition to relevant records, the name server may <br />
return RRs that point toward a name server that has the desired <br />
information or RRs that are expected to be useful in interpreting the <br />
relevant RRs. For example, a name server that doesn't have the <br />
requested information may know a name server that does; a name server <br />
that returns a domain name in a relevant RR may also return the RR that <br />
binds that domain name to an address. <br />
<br />
line-816 P. Hoffman, ICANNRFC 2181 updates the use of the SOA record<br />
Section 7.1 of RFC2181 says:<br />
RFC1034, in section 3.7, indicates that the authority section of an<br />
authoritative answer may contain the SOA record for the zone from<br />
which the answer was obtained. When discussing negative caching,<br />
RFC1034 section 4.3.4 refers to this technique but mentions the<br />
additional section of the response. The former is correct, as is<br />
implied by the example shown in section 6.2.5 of RFC1034. SOA<br />
records, if added, are to be placed in the authority section.<br />
For example, a mailer tying to send mail to Mockapetris@ISI.EDU might <br />
ask the resolver for mail information about ISI.EDU, resulting in a <br />
query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN. The response's answer <br />
section would be: <br />
<br />
ISI.EDU. MX 10 VENERA.ISI.EDU. <br />
MX 10 VAXA.ISI.EDU. <br />
<br />
while the additional section might be: <br />
<br />
VAXA.ISI.EDU. A 10.2.0.27 <br />
A 128.9.0.33 <br />
VENERA.ISI.EDU. A 10.1.0.52 <br />
A 128.9.0.32 <br />
<br />
Because the server assumes that if the requester wants mail exchange <br />
information, it will probably want the addresses of the mail exchanges <br />
soon afterward. <br />
<br />
Note that the QCLASS=* construct requires special interpretation <br />
regarding authority. Since a particular name server may not know all of <br />
the classes available in the domain system, it can never know if it is <br />
authoritative for all classes. Hence responses to QCLASS=* queries can <br />
<br />
<br />
<br />
Mockapetris [Page 17] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
never be authoritative. <br />
<br />
3.7.2. Inverse queries (Optional) <br />
<br />
Name servers may also support inverse queries that map a particular <br />
resource to a domain name or domain names that have that resource. For <br />
example, while a standard query might map a domain name to a SOA RR, the <br />
corresponding inverse query might map the SOA RR back to the domain <br />
name. <br />
<br />
Implementation of this service is optional in a name server, but all <br />
name servers must at least be able to understand an inverse query <br />
message and return a not-implemented error response. <br />
<br />
The domain system cannot guarantee the completeness or uniqueness of <br />
inverse queries because the domain system is organized by domain name <br />
rather than by host address or any other resource type. Inverse queries <br />
are primarily useful for debugging and database maintenance activities. <br />
<br />
Inverse queries may not return the proper TTL, and do not indicate cases <br />
where the identified RR is one of a set (for example, one address for a <br />
host having multiple addresses). Therefore, the RRs returned in inverse <br />
queries should never be cached. <br />
<br />
Inverse queries are NOT an acceptable method for mapping host addresses <br />
to host names; use the IN-ADDR.ARPA domain instead. <br />
<br />
A detailed discussion of inverse queries is contained in [RFC-1035]. <br />
<br />
3.8. Status queries (Experimental) <br />
<br />
To be defined. <br />
<br />
3.9. Completion queries (Obsolete) <br />
<br />
The optional completion services described in RFCs 882 and 883 have been <br />
deleted. Redesigned services may become available in the future, or the <br />
opcodes may be reclaimed for other use. <br />
<br />
4. NAME SERVERS <br />
<br />
4.1. Introduction <br />
<br />
Name servers are the repositories of information that make up the domain <br />
database. The database is divided up into sections called zones, which <br />
are distributed among the name servers. While name servers can have <br />
several optional functions and sources of data, the essential task of a <br />
name server is to answer queries using data in its zones. By design, <br />
<br />
<br />
<br />
Mockapetris [Page 18] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
name servers can answer queries in a simple manner; the response can <br />
always be generated using only local data, and either contains the <br />
answer to the question or a referral to other name servers "closer" to <br />
the desired information. <br />
<br />
A given zone will be available from several name servers to insure its <br />
availability in spite of host or communication link failure. By <br />
administrative fiat, we require every zone to be available on at least <br />
two servers, and many zones have more redundancy than that. <br />
<br />
A given name server will typically support one or more zones, but this <br />
gives it authoritative information about only a small section of the <br />
domain tree. It may also have some cached non-authoritative data about <br />
other parts of the tree. The name server marks its responses to queries <br />
so that the requester can tell whether the response comes from <br />
authoritative data or not. <br />
<br />
4.2. How the database is divided into zones <br />
<br />
The domain database is partitioned in two ways: by class, and by "cuts" <br />
made in the name space between nodes. <br />
<br />
The class partition is simple. The database for any class is organized, <br />
delegated, and maintained separately from all other classes. Since, by <br />
convention, the name spaces are the same for all classes, the separate <br />
classes can be thought of as an array of parallel namespace trees. Note <br />
that the data attached to nodes will be different for these different <br />
parallel classes. The most common reasons for creating a new class are <br />
the necessity for a new data format for existing types or a desire for a <br />
separately managed version of the existing name space. <br />
<br />
Within a class, "cuts" in the name space can be made between any two <br />
adjacent nodes. After all cuts are made, each group of connected name <br />
space is a separate zone. The zone is said to be authoritative for all <br />
names in the connected region. Note that the "cuts" in the name space <br />
may be in different places for different classes, the name servers may <br />
be different, etc. <br />
<br />
These rules mean that every zone has at least one node, and hence domain <br />
name, for which it is authoritative, and all of the nodes in a <br />
particular zone are connected. Given, the tree structure, every zone <br />
has a highest node which is closer to the root than any other node in <br />
the zone. The name of this node is often used to identify the zone. <br />
<br />
It would be possible, though not particularly useful, to partition the <br />
name space so that each domain name was in a separate zone or so that <br />
all nodes were in a single zone. Instead, the database is partitioned <br />
at points where a particular organization wants to take over control of <br />
<br />
<br />
<br />
Mockapetris [Page 19] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
a subtree. Once an organization controls its own zone it can <br />
unilaterally change the data in the zone, grow new tree sections <br />
connected to the zone, delete existing nodes, or delegate new subzones <br />
under its zone. <br />
<br />
If the organization has substructure, it may want to make further <br />
internal partitions to achieve nested delegations of name space control. <br />
In some cases, such divisions are made purely to make database <br />
maintenance more convenient. <br />
<br />
4.2.1. Technical considerations <br />
<br />
The data that describes a zone has four major parts: <br />
<br />
- Authoritative data for all nodes within the zone. <br />
<br />
- Data that defines the top node of the zone (can be thought of <br />
as part of the authoritative data). <br />
<br />
- Data that describes delegated subzones, i.e., cuts around the <br />
bottom of the zone. <br />
<br />
- Data that allows access to name servers for subzones <br />
(sometimes called "glue" data). <br />
<br />
All of this data is expressed in the form of RRs, so a zone can be <br />
completely described in terms of a set of RRs. Whole zones can be <br />
transferred between name servers by transferring the RRs, either carried <br />
in a series of messages or by FTPing a master file which is a textual <br />
representation. <br />
<br />
The authoritative data for a zone is simply all of the RRs attached to <br />
all of the nodes from the top node of the zone down to leaf nodes or <br />
nodes above cuts around the bottom edge of the zone. <br />
<br />
Though logically part of the authoritative data, the RRs that describe <br />
the top node of the zone are especially important to the zone's <br />
management. These RRs are of two types: name server RRs that list, one <br />
per RR, all of the servers for the zone, and a single SOA RR that <br />
describes zone management parameters. <br />
<br />
line-906 anonymous(Editorial Erratum #4893) [Held for Document Update]<br />
based on outdated version<br />
For example, a mailer tying to send mail to Mockapetris@ISI.EDU might<br />
ask the resolver for mail information about ISI.EDU, resulting in a<br />
query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN.<br />
It should say:<br />
For example, a mailer trying to send mail to Mockapetris@ISI.EDU might<br />
ask the resolver for mail information about ISI.EDU, resulting in a<br />
query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN.<br />
Trying, not tying.<br />
The RRs that describe cuts around the bottom of the zone are NS RRs that <br />
name the servers for the subzones. Since the cuts are between nodes, <br />
these RRs are NOT part of the authoritative data of the zone, and should <br />
be exactly the same as the corresponding RRs in the top node of the <br />
subzone. Since name servers are always associated with zone boundaries, <br />
NS RRs are only found at nodes which are the top node of some zone. In <br />
the data that makes up a zone, NS RRs are found at the top node of the <br />
<br />
<br />
<br />
Mockapetris [Page 20] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
zone (and are authoritative) and at cuts around the bottom of the zone <br />
(where they are not authoritative), but never in between. <br />
<br />
One of the goals of the zone structure is that any zone have all the <br />
data required to set up communications with the name servers for any <br />
subzones. That is, parent zones have all the information needed to <br />
access servers for their children zones. The NS RRs that name the <br />
servers for subzones are often not enough for this task since they name <br />
the servers, but do not give their addresses. In particular, if the <br />
name of the name server is itself in the subzone, we could be faced with <br />
the situation where the NS RRs tell us that in order to learn a name <br />
server's address, we should contact the server using the address we wish <br />
to learn. To fix this problem, a zone contains "glue" RRs which are not <br />
part of the authoritative data, and are address RRs for the servers. <br />
These RRs are only necessary if the name server's name is "below" the <br />
cut, and are only used as part of a referral response. <br />
<br />
4.2.2. Administrative considerations <br />
<br />
When some organization wants to control its own domain, the first step <br />
is to identify the proper parent zone, and get the parent zone's owners <br />
to agree to the delegation of control. While there are no particular <br />
technical constraints dealing with where in the tree this can be done, <br />
there are some administrative groupings discussed in [RFC-1032] which <br />
deal with top level organization, and middle level zones are free to <br />
create their own rules. For example, one university might choose to use <br />
a single zone, while another might choose to organize by subzones <br />
line-1087 P. Hoffman, ICANNRFC 4035 changes what else can exist with a zone cut, namely NSEC and DS RRs<br />
Section 2.6 of RFC4035 says:<br />
DNSSEC introduced two new RR types that are unusual in that they can<br />
appear at the parental side of a zone cut. At the parental side of a<br />
zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at<br />
the owner name. A DS RR could also be present if the zone being<br />
delegated is signed and seeks to have a chain of authentication to<br />
the parent zone. This is an exception to the original DNS<br />
specification ([RFC1034]), which states that only NS RRsets could<br />
appear at the parental side of a zone cut.<br />
<br />
This specification updates the original DNS specification to allow<br />
NSEC and DS RR types at the parent side of a zone cut. These RRsets<br />
are authoritative for the parent when they appear at the parent side<br />
of a zone cut.<br />
dedicated to individual departments or schools. [RFC-1033] catalogs <br />
available DNS software an discusses administration procedures. <br />
<br />
Once the proper name for the new subzone is selected, the new owners <br />
should be required to demonstrate redundant name server support. Note <br />
that there is no requirement that the servers for a zone reside in a <br />
host which has a name in that domain. In many cases, a zone will be <br />
more accessible to the internet at large if its servers are widely <br />
distributed rather than being within the physical facilities controlled <br />
by the same organization that manages the zone. For example, in the <br />
current DNS, one of the name servers for the United Kingdom, or UK <br />
domain, is found in the US. This allows US hosts to get UK data without <br />
using limited transatlantic bandwidth. <br />
<br />
As the last installation step, the delegation NS RRs and glue RRs <br />
necessary to make the delegation effective should be added to the parent <br />
zone. The administrators of both zones should insure that the NS and <br />
glue RRs which mark both sides of the cut are consistent and remain so. <br />
<br />
4.3. Name server internals <br />
<br />
<br />
<br />
<br />
Mockapetris [Page 21] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
4.3.1. Queries and responses <br />
<br />
The principal activity of name servers is to answer standard queries. <br />
Both the query and its response are carried in a standard message format <br />
which is described in [RFC-1035]. The query contains a QTYPE, QCLASS, <br />
and QNAME, which describe the types and classes of desired information <br />
and the name of interest. <br />
<br />
The way that the name server answers the query depends upon whether it <br />
is operating in recursive mode or not: <br />
<br />
- The simplest mode for the server is non-recursive, since it <br />
can answer queries using only local information: the response <br />
contains an error, the answer, or a referral to some other <br />
server "closer" to the answer. All name servers must <br />
implement non-recursive queries. <br />
<br />
- The simplest mode for the client is recursive, since in this <br />
mode the name server acts in the role of a resolver and <br />
returns either an error or the answer, but never referrals. <br />
This service is optional in a name server, and the name server <br />
may also choose to restrict the clients which can use <br />
recursive mode. <br />
<br />
Recursive service is helpful in several situations: <br />
<br />
- a relatively simple requester that lacks the ability to use <br />
anything other than a direct answer to the question. <br />
<br />
- a request that needs to cross protocol or other boundaries and <br />
can be sent to a server which can act as intermediary. <br />
<br />
- a network where we want to concentrate the cache rather than <br />
having a separate cache for each client. <br />
<br />
Non-recursive service is appropriate if the requester is capable of <br />
pursuing referrals and interested in information which will aid future <br />
requests. <br />
<br />
The use of recursive mode is limited to cases where both the client and <br />
the name server agree to its use. The agreement is negotiated through <br />
the use of two bits in query and response messages: <br />
<br />
- The recursion available, or RA bit, is set or cleared by a <br />
name server in all responses. The bit is true if the name <br />
server is willing to provide recursive service for the client, <br />
regardless of whether the client requested recursive service. <br />
That is, RA signals availability rather than use. <br />
<br />
<br />
<br />
Mockapetris [Page 22] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
line-1128 Sun Congyou(Editorial Erratum #4229) [Held for Document Update]<br />
based on outdated version<br />
[RFC-1033] catalogs available DNS software an discusses administration <br />
procedures.<br />
It should say:<br />
[RFC-1033] catalogs available DNS software and discusses administration <br />
procedures.<br />
- Queries contain a bit called recursion desired or RD. This <br />
bit specifies specifies whether the requester wants recursive <br />
service for this query. Clients may request recursive service <br />
from any name server, though they should depend upon receiving <br />
it only from servers which have previously sent an RA, or <br />
servers which have agreed to provide service through private <br />
agreement or some other means outside of the DNS protocol. <br />
<br />
The recursive mode occurs when a query with RD set arrives at a server <br />
which is willing to provide recursive service; the client can verify <br />
that recursive mode was used by checking that both RA and RD are set in <br />
the reply. Note that the name server should never perform recursive <br />
service unless asked via RD, since this interferes with trouble shooting <br />
of name servers and their databases. <br />
<br />
If recursive service is requested and available, the recursive response <br />
to a query will be one of the following: <br />
<br />
- The answer to the query, possibly preface by one or more CNAME <br />
RRs that specify aliases encountered on the way to an answer. <br />
<br />
- A name error indicating that the name does not exist. This <br />
may include CNAME RRs that indicate that the original query <br />
name was an alias for a name which does not exist. <br />
<br />
- A temporary error indication. <br />
<br />
If recursive service is not requested or is not available, the non- <br />
recursive response will be one of the following: <br />
<br />
- An authoritative name error indicating that the name does not <br />
exist. <br />
<br />
- A temporary error indication. <br />
<br />
- Some combination of: <br />
<br />
RRs that answer the question, together with an indication <br />
whether the data comes from a zone or is cached. <br />
<br />
A referral to name servers which have zones which are closer <br />
ancestors to the name than the server sending the reply. <br />
<br />
- RRs that the name server thinks will prove useful to the <br />
requester. <br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 23] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
line-1211 "Yin Shuming"(Editorial Erratum #565) [Verified]<br />
based on outdated version<br />
This bit specifies specifies whether the requester wants recursive service <br />
for this query. Clients may.....<br />
It should say:<br />
This bit specifies whether the requester wants recursive service<br />
for this query. Clients may.....<br />
4.3.2. Algorithm <br />
<br />
The actual algorithm used by the name server will depend on the local OS <br />
and data structures used to store RRs. The following algorithm assumes <br />
that the RRs are organized in several tree structures, one for each <br />
zone, and another for the cache: <br />
<br />
1. Set or clear the value of recursion available in the response <br />
depending on whether the name server is willing to provide <br />
recursive service. If recursive service is available and <br />
requested via the RD bit in the query, go to step 5, <br />
otherwise step 2. <br />
<br />
2. Search the available zones for the zone which is the nearest <br />
ancestor to QNAME. If such a zone is found, go to step 3, <br />
otherwise step 4. <br />
<br />
3. Start matching down, label by label, in the zone. The <br />
matching process can terminate several ways: <br />
<br />
a. If the whole of QNAME is matched, we have found the <br />
node. <br />
<br />
If the data at the node is a CNAME, and QTYPE doesn't <br />
match CNAME, copy the CNAME RR into the answer section <br />
of the response, change QNAME to the canonical name in <br />
the CNAME RR, and go back to step 1. <br />
<br />
Otherwise, copy all RRs which match QTYPE into the <br />
answer section and go to step 6. <br />
<br />
b. If a match would take us out of the authoritative data, <br />
we have a referral. This happens when we encounter a <br />
node with NS RRs marking cuts along the bottom of a <br />
zone. <br />
<br />
Copy the NS RRs for the subzone into the authority <br />
section of the reply. Put whatever addresses are <br />
available into the additional section, using glue RRs <br />
if the addresses are not available from authoritative <br />
data or the cache. Go to step 4. <br />
<br />
c. If at some label, a match is impossible (i.e., the <br />
corresponding label does not exist), look to see if a <br />
the "*" label exists. <br />
<br />
If the "*" label does not exist, check whether the name <br />
we are looking for is the original QNAME in the query <br />
<br />
<br />
<br />
Mockapetris [Page 24] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
or a name we have followed due to a CNAME. If the name <br />
is original, set an authoritative name error in the <br />
response and exit. Otherwise just exit. <br />
<br />
If the "*" label does exist, match RRs at that node <br />
against QTYPE. If any match, copy them into the answer <br />
section, but set the owner of the RR to be QNAME, and <br />
not the node with the "*" label. Go to step 6. <br />
<br />
4. Start matching down in the cache. If QNAME is found in the <br />
cache, copy all RRs attached to it that match QTYPE into the <br />
answer section. If there was no delegation from <br />
authoritative data, look for the best one from the cache, and <br />
put it in the authority section. Go to step 6. <br />
<br />
5. Using the local resolver or a copy of its algorithm (see <br />
resolver section of this memo) to answer the query. Store <br />
the results, including any intermediate CNAMEs, in the answer <br />
section of the response. <br />
<br />
line-1266 P. Hoffman, ICANNRFC 8482 allows for minimal responses for ANY queries<br />
RFC8482 gives guidance on what the proper response to and query for type ANY would be. In particular, Section 7 of RFC 8482 updates the processing instructions in RFC 1034 for ANY queries.<br />
<br />
6. Using local data only, attempt to add other RRs which may be <br />
useful to the additional section of the query. Exit. <br />
<br />
4.3.3. Wildcards <br />
<br />
In the previous algorithm, special treatment was given to RRs with owner <br />
names starting with the label "*". Such RRs are called wildcards. <br />
Wildcard RRs can be thought of as instructions for synthesizing RRs. <br />
When the appropriate conditions are met, the name server creates RRs <br />
with an owner name equal to the query name and contents taken from the <br />
wildcard RRs. <br />
<br />
This facility is most often used to create a zone which will be used to <br />
forward mail from the Internet to some other mail system. The general <br />
idea is that any name in that zone which is presented to server in a <br />
query will be assumed to exist, with certain properties, unless explicit <br />
evidence exists to the contrary. Note that the use of the term zone <br />
here, instead of domain, is intentional; such defaults do not propagate <br />
across zone boundaries, although a subzone may choose to achieve that <br />
appearance by setting up similar defaults. <br />
<br />
The contents of the wildcard RRs follows the usual rules and formats for <br />
RRs. The wildcards in the zone have an owner name that controls the <br />
query names they will match. The owner name of the wildcard RRs is of <br />
the form "*.<anydomain>", where <anydomain> is any domain name. <br />
<anydomain> should not contain other * labels, and should be in the <br />
authoritative data of the zone. The wildcards potentially apply to <br />
descendants of <anydomain>, but not to <anydomain> itself. Another way <br />
<br />
<br />
<br />
Mockapetris [Page 25] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
to look at this is that the "*" label always matches at least one whole <br />
label and sometimes more, but always whole labels. <br />
<br />
Wildcard RRs do not apply: <br />
<br />
- When the query is in another zone. That is, delegation cancels <br />
the wildcard defaults. <br />
<br />
line-1341 Robert Edmonds(Technical Erratum #4740) [Verified]<br />
based on outdated version<br />
6. Using local data only, attempt to add other RRs which may be<br />
useful to the additional section of the query. Exit.<br />
It should say:<br />
6. Using local data only, attempt to add other RRs which may be<br />
useful to the additional section of the response. Exit.<br />
Changed "query" to "response".<br />
Section 4.3.2 describes the algorithm used by nameservers to answer queries. I.e., a nameserver receives a query from a client, and then it performs this algorithm in order to construct a response to send to the client.<br />
<br />
Steps 1, 3, and 5 of this algorithm talk about setting fields or bits in the response, or about adding resource records to the answer section of the response, but then step 6 says to add resource records to the additional section of the *query*. This doesn't make any sense, because the server is constructing a response to a query that it's already received. "Response" must have been intended instead.<br />
<br />
- When the query name or a name between the wildcard domain and <br />
the query name is know to exist. For example, if a wildcard <br />
RR has an owner name of "*.X", and the zone also contains RRs <br />
attached to B.X, the wildcards would apply to queries for name <br />
Z.X (presuming there is no explicit information for Z.X), but <br />
not to B.X, A.B.X, or X. <br />
<br />
line-1384 Sun Congyou(Editorial Erratum #4230) [Held for Document Update]<br />
based on outdated version<br />
- When the query name or a name between the wildcard domain and<br />
the query name is know to exist.<br />
It should say:<br />
- When the query name or a name between the wildcard domain and<br />
the query name is known to exist.<br />
A * label appearing in a query name has no special effect, but can be <br />
used to test for wildcards in an authoritative zone; such a query is the <br />
only way to get a response containing RRs with an owner name with * in <br />
it. The result of such a query should not be cached. <br />
<br />
Note that the contents of the wildcard RRs are not modified when used to <br />
synthesize RRs. <br />
<br />
To illustrate the use of wildcard RRs, suppose a large company with a <br />
large, non-IP/TCP, network wanted to create a mail gateway. If the <br />
company was called X.COM, and IP/TCP capable gateway machine was called <br />
A.X.COM, the following RRs might be entered into the COM zone: <br />
<br />
X.COM MX 10 A.X.COM <br />
<br />
*.X.COM MX 10 A.X.COM <br />
<br />
A.X.COM A 1.2.3.4 <br />
A.X.COM MX 10 A.X.COM <br />
<br />
*.A.X.COM MX 10 A.X.COM <br />
<br />
This would cause any MX query for any domain name ending in X.COM to <br />
return an MX RR pointing at A.X.COM. Two wildcard RRs are required <br />
since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM <br />
subtree by the explicit data for A.X.COM. Note also that the explicit <br />
MX data at X.COM and A.X.COM is required, and that none of the RRs above <br />
would match a query name of XX.COM. <br />
<br />
line-1391 Mukund Sivaraman(Technical Erratum #5316) [Held for Document Update]<br />
based on outdated version<br />
A * label appearing in a query name has no special effect, but can be<br />
used to test for wildcards in an authoritative zone; such a query is the<br />
only way to get a response containing RRs with an owner name with * in<br />
it. The result of such a query should not be cached.<br />
It should say:<br />
A * label appearing in a query name has no special effect, but can be<br />
used to test for wildcards in an authoritative zone; such a query is the<br />
only way to get a response containing RRs with an owner name with * in<br />
it. The result of such a query should not be used to synthesize RRs.<br />
It is perfectly OK for an RR with a wildcard label '*' to be cached as long as it's not used to synthesize any RRs on a caching resolver. The DNS implementations BIND and Unbound both cache such RRsets with wildcard label in the owner name.<br />
WK (OpsAD): Please see thread https://www.ietf.org/mail-archive/web/dnsop/current/msg22563.html for additional information.<br />
<br />
4.3.4. Negative response caching (Optional) <br />
<br />
The DNS provides an optional service which allows name servers to <br />
distribute, and resolvers to cache, negative results with TTLs. For <br />
<br />
<br />
<br />
Mockapetris [Page 26] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
example, a name server can distribute a TTL along with a name error <br />
indication, and a resolver receiving such information is allowed to <br />
assume that the name does not exist during the TTL period without <br />
consulting authoritative data. Similarly, a resolver can make a query <br />
with a QTYPE which matches multiple types, and cache the fact that some <br />
of the types are not present. <br />
<br />
line-1420 P. Hoffman, ICANNRFC 2181 updates the use of the SOA record<br />
Section 7.1 of RFC2181 says:<br />
RFC1034, in section 3.7, indicates that the authority section of an<br />
authoritative answer may contain the SOA record for the zone from<br />
which the answer was obtained. When discussing negative caching,<br />
RFC1034 section 4.3.4 refers to this technique but mentions the<br />
additional section of the response. The former is correct, as is<br />
implied by the example shown in section 6.2.5 of RFC1034. SOA<br />
records, if added, are to be placed in the authority section.<br />
line-1420 P. Hoffman, ICANNRFC 2308 updates the method for negative caching<br />
RFC2308 is a major restatement and update to how negative caching should be implemented. Its abstract begins:<br />
[RFC1034] provided a description of how to cache negative responses.<br />
It however had a fundamental flaw in that it did not allow a name<br />
server to hand out those cached responses to other resolvers, thereby<br />
greatly reducing the effect of the caching. This document addresses<br />
issues raise in the light of experience and replaces [RFC1034 Section<br />
4.3.4].<br />
This feature can be particularly important in a system which implements <br />
naming shorthands that use search lists beacuse a popular shorthand, <br />
which happens to require a suffix toward the end of the search list, <br />
will generate multiple name errors whenever it is used. <br />
<br />
The method is that a name server may add an SOA RR to the additional <br />
section of a response when that response is authoritative. The SOA must <br />
be that of the zone which was the source of the authoritative data in <br />
the answer section, or name error if applicable. The MINIMUM field of <br />
the SOA controls the length of time that the negative result may be <br />
cached. <br />
<br />
Note that in some circumstances, the answer section may contain multiple <br />
owner names. In this case, the SOA mechanism should only be used for <br />
the data which matches QNAME, which is the only authoritative data in <br />
this section. <br />
<br />
Name servers and resolvers should never attempt to add SOAs to the <br />
additional section of a non-authoritative response, or attempt to infer <br />
results which are not directly stated in an authoritative response. <br />
There are several reasons for this, including: cached information isn't <br />
usually enough to match up RRs and their zone names, SOA RRs may be <br />
cached due to direct SOA queries, and name servers are not required to <br />
output the SOAs in the authority section. <br />
<br />
This feature is optional, although a refined version is expected to <br />
become part of the standard protocol in the future. Name servers are <br />
not required to add the SOA RRs in all authoritative responses, nor are <br />
resolvers required to cache negative results. Both are recommended. <br />
All resolvers and recursive name servers are required to at least be <br />
able to ignore the SOA RR when it is present in a response. <br />
<br />
Some experiments have also been proposed which will use this feature. <br />
The idea is that if cached data is known to come from a particular zone, <br />
and if an authoritative copy of the zone's SOA is obtained, and if the <br />
zone's SERIAL has not changed since the data was cached, then the TTL of <br />
the cached data can be reset to the zone MINIMUM value if it is smaller. <br />
This usage is mentioned for planning purposes only, and is not <br />
recommended as yet. <br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 27] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
4.3.5. Zone maintenance and transfers <br />
<br />
Part of the job of a zone administrator is to maintain the zones at all <br />
of the name servers which are authoritative for the zone. When the <br />
inevitable changes are made, they must be distributed to all of the name <br />
servers. While this distribution can be accomplished using FTP or some <br />
other ad hoc procedure, the preferred method is the zone transfer part <br />
of the DNS protocol. <br />
<br />
The general model of automatic zone transfer or refreshing is that one <br />
of the name servers is the master or primary for the zone. Changes are <br />
coordinated at the primary, typically by editing a master file for the <br />
zone. After editing, the administrator signals the master server to <br />
load the new zone. The other non-master or secondary servers for the <br />
zone periodically check for changes (at a selectable interval) and <br />
obtain new zone copies when changes have been made. <br />
<br />
line-1438 John Kristoff(Editorial Erratum #1074) [Verified]<br />
based on outdated version<br />
Section 4.3.4 says:<br />
This feature can be particularly important in a system which implements<br />
naming short shorts that use search lists beacuse a popular shorthand,<br />
This feature can be particularly important in a system which implements<br />
naming short shorts that use search lists because a popular shorthand,<br />
To detect changes, secondaries just check the SERIAL field of the SOA <br />
for the zone. In addition to whatever other changes are made, the <br />
SERIAL field in the SOA of the zone is always advanced whenever any <br />
change is made to the zone. The advancing can be a simple increment, or <br />
could be based on the write date and time of the master file, etc. The <br />
purpose is to make it possible to determine which of two copies of a <br />
zone is more recent by comparing serial numbers. Serial number advances <br />
and comparisons use sequence space arithmetic, so there is a theoretic <br />
limit on how fast a zone can be updated, basically that old copies must <br />
die out before the serial number covers half of its 32 bit range. In <br />
practice, the only concern is that the compare operation deals properly <br />
with comparisons around the boundary between the most positive and most <br />
negative 32 bit numbers. <br />
<br />
The periodic polling of the secondary servers is controlled by <br />
parameters in the SOA RR for the zone, which set the minimum acceptable <br />
polling intervals. The parameters are called REFRESH, RETRY, and <br />
EXPIRE. Whenever a new zone is loaded in a secondary, the secondary <br />
waits REFRESH seconds before checking with the primary for a new serial. <br />
If this check cannot be completed, new checks are started every RETRY <br />
seconds. The check is a simple query to the primary for the SOA RR of <br />
the zone. If the serial field in the secondary's zone copy is equal to <br />
the serial returned by the primary, then no changes have occurred, and <br />
the REFRESH interval wait is restarted. If the secondary finds it <br />
line-1503 P. Hoffman, ICANNRFC 1982 has a better definition of serial number arithmetic<br />
RFC1982 clarifies how serial number arithmetic should be performed. The abstract says "The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood. This memo supplies the missing definition."<br />
<br />
impossible to perform a serial check for the EXPIRE interval, it must <br />
assume that its copy of the zone is obsolete an discard it. <br />
<br />
line-1527 Shane Kerr(Editorial Erratum #4943) [Verified]<br />
based on outdated version<br />
it must assume that its copy of the zone is obsolete an discard it.<br />
It should say:<br />
it must assume that its copy of the zone is obsolete and discard it.<br />
Fix typo; "an" should be "and".<br />
When the poll shows that the zone has changed, then the secondary server <br />
must request a zone transfer via an AXFR request for the zone. The AXFR <br />
may cause an error, such as refused, but normally is answered by a <br />
sequence of response messages. The first and last messages must contain <br />
<br />
<br />
<br />
Mockapetris [Page 28] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
the data for the top authoritative node of the zone. Intermediate <br />
messages carry all of the other RRs from the zone, including both <br />
authoritative and non-authoritative RRs. The stream of messages allows <br />
the secondary to construct a copy of the zone. Because accuracy is <br />
essential, TCP or some other reliable protocol must be used for AXFR <br />
requests. <br />
<br />
Each secondary server is required to perform the following operations <br />
against the master, but may also optionally perform these operations <br />
against other secondary servers. This strategy can improve the transfer <br />
process when the primary is unavailable due to host downtime or network <br />
problems, or when a secondary server has better network access to an <br />
"intermediate" secondary than to the primary. <br />
<br />
5. RESOLVERS <br />
<br />
5.1. Introduction <br />
<br />
Resolvers are programs that interface user programs to domain name <br />
servers. In the simplest case, a resolver receives a request from a <br />
user program (e.g., mail programs, TELNET, FTP) in the form of a <br />
subroutine call, system call etc., and returns the desired information <br />
in a form compatible with the local host's data formats. <br />
<br />
The resolver is located on the same machine as the program that requests <br />
the resolver's services, but it may need to consult name servers on <br />
other hosts. Because a resolver may need to consult several name <br />
servers, or may have the requested information in a local cache, the <br />
amount of time that a resolver will take to complete can vary quite a <br />
bit, from milliseconds to several seconds. <br />
<br />
A very important goal of the resolver is to eliminate network delay and <br />
name server load from most requests by answering them from its cache of <br />
prior results. It follows that caches which are shared by multiple <br />
processes, users, machines, etc., are more efficient than non-shared <br />
caches. <br />
<br />
5.2. Client-resolver interface <br />
<br />
5.2.1. Typical functions <br />
<br />
The client interface to the resolver is influenced by the local host's <br />
conventions, but the typical resolver-client interface has three <br />
functions: <br />
<br />
1. Host name to host address translation. <br />
<br />
This function is often defined to mimic a previous HOSTS.TXT <br />
<br />
<br />
<br />
Mockapetris [Page 29] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
based function. Given a character string, the caller wants <br />
one or more 32 bit IP addresses. Under the DNS, it <br />
translates into a request for type A RRs. Since the DNS does <br />
not preserve the order of RRs, this function may choose to <br />
sort the returned addresses or select the "best" address if <br />
the service returns only one choice to the client. Note that <br />
a multiple address return is recommended, but a single <br />
address may be the only way to emulate prior HOSTS.TXT <br />
services. <br />
<br />
2. Host address to host name translation <br />
<br />
This function will often follow the form of previous <br />
functions. Given a 32 bit IP address, the caller wants a <br />
character string. The octets of the IP address are reversed, <br />
used as name components, and suffixed with "IN-ADDR.ARPA". A <br />
type PTR query is used to get the RR with the primary name of <br />
the host. For example, a request for the host name <br />
corresponding to IP address 1.2.3.4 looks for PTR RRs for <br />
domain name "4.3.2.1.IN-ADDR.ARPA". <br />
<br />
3. General lookup function <br />
<br />
This function retrieves arbitrary information from the DNS, <br />
and has no counterpart in previous systems. The caller <br />
supplies a QNAME, QTYPE, and QCLASS, and wants all of the <br />
matching RRs. This function will often use the DNS format <br />
for all RR data instead of the local host's, and returns all <br />
RR content (e.g., TTL) instead of a processed form with local <br />
quoting conventions. <br />
<br />
When the resolver performs the indicated function, it usually has one of <br />
the following results to pass back to the client: <br />
<br />
- One or more RRs giving the requested data. <br />
<br />
In this case the resolver returns the answer in the <br />
appropriate format. <br />
<br />
- A name error (NE). <br />
<br />
This happens when the referenced name does not exist. For <br />
example, a user may have mistyped a host name. <br />
<br />
- A data not found error. <br />
<br />
This happens when the referenced name exists, but data of the <br />
appropriate type does not. For example, a host address <br />
<br />
<br />
<br />
Mockapetris [Page 30] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
function applied to a mailbox name would return this error <br />
since the name exists, but no address RR is present. <br />
<br />
It is important to note that the functions for translating between host <br />
names and addresses may combine the "name error" and "data not found" <br />
error conditions into a single type of error return, but the general <br />
function should not. One reason for this is that applications may ask <br />
first for one type of information about a name followed by a second <br />
request to the same name for some other type of information; if the two <br />
errors are combined, then useless queries may slow the application. <br />
<br />
5.2.2. Aliases <br />
<br />
While attempting to resolve a particular request, the resolver may find <br />
that the name in question is an alias. For example, the resolver might <br />
find that the name given for host name to address translation is an <br />
alias when it finds the CNAME RR. If possible, the alias condition <br />
should be signalled back from the resolver to the client. <br />
<br />
In most cases a resolver simply restarts the query at the new name when <br />
it encounters a CNAME. However, when performing the general function, <br />
the resolver should not pursue aliases when the CNAME RR matches the <br />
query type. This allows queries which ask whether an alias is present. <br />
For example, if the query type is CNAME, the user is interested in the <br />
CNAME RR itself, and not the RRs at the name it points to. <br />
<br />
Several special conditions can occur with aliases. Multiple levels of <br />
aliases should be avoided due to their lack of efficiency, but should <br />
not be signalled as an error. Alias loops and aliases which point to <br />
non-existent names should be caught and an error condition passed back <br />
to the client. <br />
<br />
5.2.3. Temporary failures <br />
<br />
In a less than perfect world, all resolvers will occasionally be unable <br />
to resolve a particular request. This condition can be caused by a <br />
resolver which becomes separated from the rest of the network due to a <br />
link failure or gateway problem, or less often by coincident failure or <br />
unavailability of all servers for a particular domain. <br />
<br />
It is essential that this sort of condition should not be signalled as a <br />
name or data not present error to applications. This sort of behavior <br />
is annoying to humans, and can wreak havoc when mail systems use the <br />
DNS. <br />
<br />
While in some cases it is possible to deal with such a temporary problem <br />
by blocking the request indefinitely, this is usually not a good choice, <br />
particularly when the client is a server process that could move on to <br />
<br />
<br />
<br />
Mockapetris [Page 31] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
other tasks. The recommended solution is to always have temporary <br />
failure as one of the possible results of a resolver function, even <br />
though this may make emulation of existing HOSTS.TXT functions more <br />
difficult. <br />
<br />
5.3. Resolver internals <br />
<br />
Every resolver implementation uses slightly different algorithms, and <br />
typically spends much more logic dealing with errors of various sorts <br />
line-1530 P. Hoffman, ICANNRFC 5936 re-specifies how AXFR works<br />
RFC5936 is a complete re-definition of AXFR. Its abstract says: "The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism."<br />
<br />
than typical occurances. This section outlines a recommended basic <br />
strategy for resolver operation, but leaves details to [RFC-1035]. <br />
<br />
5.3.1. Stub resolvers <br />
<br />
One option for implementing a resolver is to move the resolution <br />
function out of the local machine and into a name server which supports <br />
recursive queries. This can provide an easy method of providing domain <br />
service in a PC which lacks the resources to perform the resolver <br />
function, or can centralize the cache for a whole local network or <br />
organization. <br />
<br />
All that the remaining stub needs is a list of name server addresses <br />
that will perform the recursive requests. This type of resolver <br />
presumably needs the information in a configuration file, since it <br />
probably lacks the sophistication to locate it in the domain database. <br />
The user also needs to verify that the listed servers will perform the <br />
recursive service; a name server is free to refuse to perform recursive <br />
services for any or all clients. The user should consult the local <br />
system administrator to find name servers willing to perform the <br />
service. <br />
<br />
This type of service suffers from some drawbacks. Since the recursive <br />
requests may take an arbitrary amount of time to perform, the stub may <br />
have difficulty optimizing retransmission intervals to deal with both <br />
lost UDP packets and dead servers; the name server can be easily <br />
overloaded by too zealous a stub if it interprets retransmissions as new <br />
requests. Use of TCP may be an answer, but TCP may well place burdens <br />
on the host's capabilities which are similar to those of a real <br />
resolver. <br />
<br />
5.3.2. Resources <br />
<br />
In addition to its own resources, the resolver may also have shared <br />
access to zones maintained by a local name server. This gives the <br />
resolver the advantage of more rapid access, but the resolver must be <br />
careful to never let cached information override zone data. In this <br />
discussion the term "local information" is meant to mean the union of <br />
the cache and such shared zones, with the understanding that <br />
<br />
<br />
<br />
Mockapetris [Page 32] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
authoritative data is always used in preference to cached data when both <br />
are present. <br />
<br />
The following resolver algorithm assumes that all functions have been <br />
converted to a general lookup function, and uses the following data <br />
structures to represent the state of a request in progress in the <br />
resolver: <br />
<br />
SNAME the domain name we are searching for. <br />
<br />
STYPE the QTYPE of the search request. <br />
<br />
SCLASS the QCLASS of the search request. <br />
<br />
SLIST a structure which describes the name servers and the <br />
zone which the resolver is currently trying to query. <br />
This structure keeps track of the resolver's current <br />
best guess about which name servers hold the desired <br />
information; it is updated when arriving information <br />
changes the guess. This structure includes the <br />
equivalent of a zone name, the known name servers for <br />
the zone, the known addresses for the name servers, and <br />
history information which can be used to suggest which <br />
server is likely to be the best one to try next. The <br />
zone name equivalent is a match count of the number of <br />
labels from the root down which SNAME has in common with <br />
the zone being queried; this is used as a measure of how <br />
"close" the resolver is to SNAME. <br />
<br />
SBELT a "safety belt" structure of the same form as SLIST, <br />
which is initialized from a configuration file, and <br />
lists servers which should be used when the resolver <br />
doesn't have any local information to guide name server <br />
selection. The match count will be -1 to indicate that <br />
no labels are known to match. <br />
<br />
CACHE A structure which stores the results from previous <br />
responses. Since resolvers are responsible for <br />
discarding old RRs whose TTL has expired, most <br />
implementations convert the interval specified in <br />
arriving RRs to some sort of absolute time when the RR <br />
is stored in the cache. Instead of counting the TTLs <br />
down individually, the resolver just ignores or discards <br />
old RRs when it runs across them in the course of a <br />
search, or discards them during periodic sweeps to <br />
reclaim the memory consumed by old RRs. <br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 33] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
5.3.3. Algorithm <br />
<br />
The top level algorithm has four steps: <br />
<br />
1. See if the answer is in local information, and if so return <br />
it to the client. <br />
<br />
2. Find the best servers to ask. <br />
<br />
3. Send them queries until one returns a response. <br />
<br />
4. Analyze the response, either: <br />
<br />
a. if the response answers the question or contains a name <br />
error, cache the data as well as returning it back to <br />
the client. <br />
<br />
b. if the response contains a better delegation to other <br />
servers, cache the delegation information, and go to <br />
step 2. <br />
<br />
c. if the response shows a CNAME and that is not the <br />
answer itself, cache the CNAME, change the SNAME to the <br />
canonical name in the CNAME RR and go to step 1. <br />
<br />
d. if the response shows a servers failure or other <br />
bizarre contents, delete the server from the SLIST and <br />
go back to step 3. <br />
<br />
Step 1 searches the cache for the desired data. If the data is in the <br />
cache, it is assumed to be good enough for normal use. Some resolvers <br />
have an option at the user interface which will force the resolver to <br />
ignore the cached data and consult with an authoritative server. This <br />
is not recommended as the default. If the resolver has direct access to <br />
a name server's zones, it should check to see if the desired data is <br />
present in authoritative form, and if so, use the authoritative data in <br />
preference to cached data. <br />
<br />
Step 2 looks for a name server to ask for the required data. The <br />
general strategy is to look for locally-available name server RRs, <br />
starting at SNAME, then the parent domain name of SNAME, the <br />
grandparent, and so on toward the root. Thus if SNAME were <br />
Mockapetris.ISI.EDU, this step would look for NS RRs for <br />
Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root). <br />
These NS RRs list the names of hosts for a zone at or above SNAME. Copy <br />
the names into SLIST. Set up their addresses using local data. It may <br />
be the case that the addresses are not available. The resolver has many <br />
choices here; the best is to start parallel resolver processes looking <br />
<br />
<br />
<br />
Mockapetris [Page 34] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
for the addresses while continuing onward with the addresses which are <br />
available. Obviously, the design choices and options are complicated <br />
and a function of the local host's capabilities. The recommended <br />
priorities for the resolver designer are: <br />
<br />
1. Bound the amount of work (packets sent, parallel processes <br />
started) so that a request can't get into an infinite loop or <br />
start off a chain reaction of requests or queries with other <br />
implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED <br />
SOME DATA. <br />
<br />
2. Get back an answer if at all possible. <br />
<br />
3. Avoid unnecessary transmissions. <br />
<br />
4. Get the answer as quickly as possible. <br />
<br />
If the search for NS RRs fails, then the resolver initializes SLIST from <br />
the safety belt SBELT. The basic idea is that when the resolver has no <br />
idea what servers to ask, it should use information from a configuration <br />
file that lists several servers which are expected to be helpful. <br />
Although there are special situations, the usual choice is two of the <br />
root servers and two of the servers for the host's domain. The reason <br />
for two of each is for redundancy. The root servers will provide <br />
eventual access to all of the domain space. The two local servers will <br />
allow the resolver to continue to resolve local names if the local <br />
network becomes isolated from the internet due to gateway or link <br />
failure. <br />
<br />
In addition to the names and addresses of the servers, the SLIST data <br />
structure can be sorted to use the best servers first, and to insure <br />
that all addresses of all servers are used in a round-robin manner. The <br />
sorting can be a simple function of preferring addresses on the local <br />
network over others, or may involve statistics from past events, such as <br />
previous response times and batting averages. <br />
<br />
Step 3 sends out queries until a response is received. The strategy is <br />
to cycle around all of the addresses for all of the servers with a <br />
timeout between each transmission. In practice it is important to use <br />
all addresses of a multihomed host, and too aggressive a retransmission <br />
policy actually slows response when used by multiple resolvers <br />
contending for the same name server and even occasionally for a single <br />
resolver. SLIST typically contains data values to control the timeouts <br />
and keep track of previous transmissions. <br />
<br />
Step 4 involves analyzing responses. The resolver should be highly <br />
paranoid in its parsing of responses. It should also check that the <br />
response matches the query it sent using the ID field in the response. <br />
<br />
<br />
<br />
Mockapetris [Page 35] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
The ideal answer is one from a server authoritative for the query which <br />
either gives the required data or a name error. The data is passed back <br />
to the user and entered in the cache for future use if its TTL is <br />
greater than zero. <br />
<br />
If the response shows a delegation, the resolver should check to see <br />
that the delegation is "closer" to the answer than the servers in SLIST <br />
are. This can be done by comparing the match count in SLIST with that <br />
computed from SNAME and the NS RRs in the delegation. If not, the reply <br />
is bogus and should be ignored. If the delegation is valid the NS <br />
delegation RRs and any address RRs for the servers should be cached. <br />
The name servers are entered in the SLIST, and the search is restarted. <br />
<br />
If the response contains a CNAME, the search is restarted at the CNAME <br />
unless the response has the data for the canonical name or if the CNAME <br />
is the answer itself. <br />
<br />
Details and implementation hints can be found in [RFC-1035]. <br />
<br />
6. A SCENARIO <br />
<br />
In our sample domain space, suppose we wanted separate administrative <br />
control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones. We might <br />
allocate name servers as follows: <br />
<br />
<br />
|(C.ISI.EDU,SRI-NIC.ARPA <br />
| A.ISI.EDU) <br />
+---------------------+------------------+ <br />
| | | <br />
MIL EDU ARPA <br />
|(SRI-NIC.ARPA, |(SRI-NIC.ARPA, | <br />
| A.ISI.EDU | C.ISI.EDU) | <br />
+-----+-----+ | +------+-----+-----+ <br />
| | | | | | | <br />
BRL NOSC DARPA | IN-ADDR SRI-NIC ACC <br />
| <br />
+--------+------------------+---------------+--------+ <br />
| | | | | <br />
UCI MIT | UDEL YALE <br />
|(XX.LCS.MIT.EDU, ISI <br />
|ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU, <br />
+---+---+ | A.ISI.EDU) <br />
| | | <br />
LCS ACHILLES +--+-----+-----+--------+ <br />
| | | | | | <br />
XX A C VAXA VENERA Mockapetris <br />
<br />
<br />
<br />
<br />
Mockapetris [Page 36] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
In this example, the authoritative name server is shown in parentheses <br />
at the point in the domain tree at which is assumes control. <br />
<br />
Thus the root name servers are on C.ISI.EDU, SRI-NIC.ARPA, and <br />
A.ISI.EDU. The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU. The <br />
EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU. Note that servers <br />
may have zones which are contiguous or disjoint. In this scenario, <br />
C.ISI.EDU has contiguous zones at the root and EDU domains. A.ISI.EDU <br />
has contiguous zones at the root and MIL domains, but also has a non- <br />
contiguous zone at ISI.EDU. <br />
<br />
6.1. C.ISI.EDU name server <br />
<br />
C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN <br />
class, and would have zones for these domains. The zone data for the <br />
root domain might be: <br />
<br />
. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( <br />
870611 ;serial <br />
1800 ;refresh every 30 min <br />
300 ;retry every 5 min <br />
604800 ;expire after a week <br />
86400) ;minimum of a day <br />
NS A.ISI.EDU. <br />
NS C.ISI.EDU. <br />
NS SRI-NIC.ARPA. <br />
<br />
MIL. 86400 NS SRI-NIC.ARPA. <br />
86400 NS A.ISI.EDU. <br />
<br />
EDU. 86400 NS SRI-NIC.ARPA. <br />
86400 NS C.ISI.EDU. <br />
<br />
SRI-NIC.ARPA. A 26.0.0.73 <br />
A 10.0.0.51 <br />
MX 0 SRI-NIC.ARPA. <br />
HINFO DEC-2060 TOPS20 <br />
<br />
ACC.ARPA. A 26.6.0.65 <br />
HINFO PDP-11/70 UNIX <br />
MX 10 ACC.ARPA. <br />
<br />
USC-ISIC.ARPA. CNAME C.ISI.EDU. <br />
<br />
73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. <br />
65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA. <br />
51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. <br />
52.0.0.10.IN-ADDR.ARPA. PTR C.ISI.EDU. <br />
<br />
<br />
<br />
Mockapetris [Page 37] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU. <br />
<br />
A.ISI.EDU. 86400 A 26.3.0.103 <br />
C.ISI.EDU. 86400 A 10.0.0.52 <br />
<br />
This data is represented as it would be in a master file. Most RRs are <br />
single line entries; the sole exception here is the SOA RR, which uses <br />
"(" to start a multi-line RR and ")" to show the end of a multi-line RR. <br />
Since the class of all RRs in a zone must be the same, only the first RR <br />
in a zone need specify the class. When a name server loads a zone, it <br />
forces the TTL of all authoritative RRs to be at least the MINIMUM field <br />
of the SOA, here 86400 seconds, or one day. The NS RRs marking <br />
delegation of the MIL and EDU domains, together with the glue RRs for <br />
the servers host addresses, are not part of the authoritative data in <br />
the zone, and hence have explicit TTLs. <br />
<br />
Four RRs are attached to the root node: the SOA which describes the root <br />
zone and the 3 NS RRs which list the name servers for the root. The <br />
data in the SOA RR describes the management of the zone. The zone data <br />
is maintained on host SRI-NIC.ARPA, and the responsible party for the <br />
zone is HOSTMASTER@SRI-NIC.ARPA. A key item in the SOA is the 86400 <br />
second minimum TTL, which means that all authoritative data in the zone <br />
has at least that TTL, although higher values may be explicitly <br />
specified. <br />
<br />
The NS RRs for the MIL and EDU domains mark the boundary between the <br />
root zone and the MIL and EDU zones. Note that in this example, the <br />
lower zones happen to be supported by name servers which also support <br />
the root zone. <br />
<br />
The master file for the EDU zone might be stated relative to the origin <br />
EDU. The zone data for the EDU domain might be: <br />
<br />
EDU. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( <br />
870729 ;serial <br />
1800 ;refresh every 30 minutes <br />
300 ;retry every 5 minutes <br />
604800 ;expire after a week <br />
86400 ;minimum of a day <br />
) <br />
NS SRI-NIC.ARPA. <br />
NS C.ISI.EDU. <br />
<br />
UCI 172800 NS ICS.UCI <br />
172800 NS ROME.UCI <br />
ICS.UCI 172800 A 192.5.19.1 <br />
ROME.UCI 172800 A 192.5.19.31 <br />
<br />
<br />
<br />
<br />
Mockapetris [Page 38] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
ISI 172800 NS VAXA.ISI <br />
172800 NS A.ISI <br />
172800 NS VENERA.ISI.EDU. <br />
VAXA.ISI 172800 A 10.2.0.27 <br />
172800 A 128.9.0.33 <br />
VENERA.ISI.EDU. 172800 A 10.1.0.52 <br />
172800 A 128.9.0.32 <br />
A.ISI 172800 A 26.3.0.103 <br />
<br />
UDEL.EDU. 172800 NS LOUIE.UDEL.EDU. <br />
172800 NS UMN-REI-UC.ARPA. <br />
LOUIE.UDEL.EDU. 172800 A 10.0.0.96 <br />
172800 A 192.5.39.3 <br />
<br />
YALE.EDU. 172800 NS YALE.ARPA. <br />
YALE.EDU. 172800 NS YALE-BULLDOG.ARPA. <br />
<br />
MIT.EDU. 43200 NS XX.LCS.MIT.EDU. <br />
43200 NS ACHILLES.MIT.EDU. <br />
XX.LCS.MIT.EDU. 43200 A 10.0.0.44 <br />
ACHILLES.MIT.EDU. 43200 A 18.72.0.8 <br />
<br />
Note the use of relative names here. The owner name for the ISI.EDU. is <br />
stated using a relative name, as are two of the name server RR contents. <br />
line-1715 Ivan Panchenko(Editorial Erratum #6460) [Verified]<br />
based on outdated version<br />
than typical occurances. This section outlines a recommended basic<br />
It should say:<br />
than typical occurrences. This section outlines a recommended basic<br />
Misspelled "occurrences".<br />
Relative and absolute domain names may be freely intermixed in a master <br />
<br />
6.2. Example standard queries <br />
<br />
The following queries and responses illustrate name server behavior. <br />
Unless otherwise noted, the queries do not have recursion desired (RD) <br />
in the header. Note that the answers to non-recursive queries do depend <br />
on the server being asked, but do not depend on the identity of the <br />
requester. <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 39] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A <br />
<br />
The query would look like: <br />
<br />
+---------------------------------------------------+ <br />
Header | OPCODE=SQUERY | <br />
+---------------------------------------------------+ <br />
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A | <br />
+---------------------------------------------------+ <br />
Answer | <empty> | <br />
+---------------------------------------------------+ <br />
Authority | <empty> | <br />
+---------------------------------------------------+ <br />
Additional | <empty> | <br />
+---------------------------------------------------+ <br />
<br />
The response from C.ISI.EDU would be: <br />
<br />
+---------------------------------------------------+ <br />
Header | OPCODE=SQUERY, RESPONSE, AA | <br />
+---------------------------------------------------+ <br />
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A | <br />
+---------------------------------------------------+ <br />
Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 | <br />
| 86400 IN A 10.0.0.51 | <br />
+---------------------------------------------------+ <br />
Authority | <empty> | <br />
+---------------------------------------------------+ <br />
Additional | <empty> | <br />
+---------------------------------------------------+ <br />
<br />
The header of the response looks like the header of the query, except <br />
that the RESPONSE bit is set, indicating that this message is a <br />
response, not a query, and the Authoritative Answer (AA) bit is set <br />
indicating that the address RRs in the answer section are from <br />
authoritative data. The question section of the response matches the <br />
question section of the query. <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 40] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
If the same query was sent to some other server which was not <br />
authoritative for SRI-NIC.ARPA, the response might be: <br />
<br />
+---------------------------------------------------+ <br />
Header | OPCODE=SQUERY,RESPONSE | <br />
+---------------------------------------------------+ <br />
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A | <br />
+---------------------------------------------------+ <br />
Answer | SRI-NIC.ARPA. 1777 IN A 10.0.0.51 | <br />
| 1777 IN A 26.0.0.73 | <br />
+---------------------------------------------------+ <br />
Authority | <empty> | <br />
+---------------------------------------------------+ <br />
Additional | <empty> | <br />
+---------------------------------------------------+ <br />
<br />
This response is different from the previous one in two ways: the header <br />
does not have AA set, and the TTLs are different. The inference is that <br />
the data did not come from a zone, but from a cache. The difference <br />
between the authoritative TTL and the TTL here is due to aging of the <br />
data in a cache. The difference in ordering of the RRs in the answer <br />
section is not significant. <br />
<br />
6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=* <br />
<br />
A query similar to the previous one, but using a QTYPE of *, would <br />
receive the following response from C.ISI.EDU: <br />
<br />
+---------------------------------------------------+ <br />
Header | OPCODE=SQUERY, RESPONSE, AA | <br />
+---------------------------------------------------+ <br />
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | <br />
+---------------------------------------------------+ <br />
Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 | <br />
| A 10.0.0.51 | <br />
| MX 0 SRI-NIC.ARPA. | <br />
| HINFO DEC-2060 TOPS20 | <br />
+---------------------------------------------------+ <br />
Authority | <empty> | <br />
+---------------------------------------------------+ <br />
Additional | <empty> | <br />
+---------------------------------------------------+ <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 41] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
If a similar query was directed to two name servers which are not <br />
authoritative for SRI-NIC.ARPA, the responses might be: <br />
<br />
+---------------------------------------------------+ <br />
Header | OPCODE=SQUERY, RESPONSE | <br />
+---------------------------------------------------+ <br />
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | <br />
+---------------------------------------------------+ <br />
Answer | SRI-NIC.ARPA. 12345 IN A 26.0.0.73 | <br />
| A 10.0.0.51 | <br />
+---------------------------------------------------+ <br />
Authority | <empty> | <br />
+---------------------------------------------------+ <br />
Additional | <empty> | <br />
+---------------------------------------------------+ <br />
<br />
and <br />
<br />
+---------------------------------------------------+ <br />
Header | OPCODE=SQUERY, RESPONSE | <br />
+---------------------------------------------------+ <br />
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | <br />
+---------------------------------------------------+ <br />
Answer | SRI-NIC.ARPA. 1290 IN HINFO DEC-2060 TOPS20 | <br />
+---------------------------------------------------+ <br />
Authority | <empty> | <br />
+---------------------------------------------------+ <br />
Additional | <empty> | <br />
+---------------------------------------------------+ <br />
<br />
Neither of these answers have AA set, so neither response comes from <br />
authoritative data. The different contents and different TTLs suggest <br />
that the two servers cached data at different times, and that the first <br />
server cached the response to a QTYPE=A query and the second cached the <br />
response to a HINFO query. <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 42] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX <br />
<br />
This type of query might be result from a mailer trying to look up <br />
routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA. <br />
The response from C.ISI.EDU would be: <br />
<br />
+---------------------------------------------------+ <br />
Header | OPCODE=SQUERY, RESPONSE, AA | <br />
+---------------------------------------------------+ <br />
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX | <br />
+---------------------------------------------------+ <br />
Answer | SRI-NIC.ARPA. 86400 IN MX 0 SRI-NIC.ARPA.| <br />
+---------------------------------------------------+ <br />
Authority | <empty> | <br />
+---------------------------------------------------+ <br />
Additional | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 | <br />
| A 10.0.0.51 | <br />
+---------------------------------------------------+ <br />
<br />
This response contains the MX RR in the answer section of the response. <br />
The additional section contains the address RRs because the name server <br />
at C.ISI.EDU guesses that the requester will need the addresses in order <br />
to properly use the information carried by the MX. <br />
<br />
6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS <br />
<br />
C.ISI.EDU would reply to this query with: <br />
<br />
+---------------------------------------------------+ <br />
Header | OPCODE=SQUERY, RESPONSE, AA | <br />
+---------------------------------------------------+ <br />
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS | <br />
+---------------------------------------------------+ <br />
Answer | <empty> | <br />
+---------------------------------------------------+ <br />
Authority | <empty> | <br />
+---------------------------------------------------+ <br />
Additional | <empty> | <br />
+---------------------------------------------------+ <br />
<br />
The only difference between the response and the query is the AA and <br />
RESPONSE bits in the header. The interpretation of this response is <br />
that the server is authoritative for the name, and the name exists, but <br />
no RRs of type NS are present there. <br />
<br />
6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A <br />
<br />
If a user mistyped a host name, we might see this type of query. <br />
<br />
<br />
<br />
Mockapetris [Page 43] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
C.ISI.EDU would answer it with: <br />
<br />
+---------------------------------------------------+ <br />
Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE | <br />
+---------------------------------------------------+ <br />
Question | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A | <br />
+---------------------------------------------------+ <br />
Answer | <empty> | <br />
+---------------------------------------------------+ <br />
Authority | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. | <br />
| 870611 1800 300 604800 86400 | <br />
+---------------------------------------------------+ <br />
Additional | <empty> | <br />
+---------------------------------------------------+ <br />
<br />
This response states that the name does not exist. This condition is <br />
signalled in the response code (RCODE) section of the header. <br />
<br />
The SOA RR in the authority section is the optional negative caching <br />
information which allows the resolver using this response to assume that <br />
the name will not exist for the SOA MINIMUM (86400) seconds. <br />
<br />
6.2.6. QNAME=BRL.MIL, QTYPE=A <br />
<br />
If this query is sent to C.ISI.EDU, the reply would be: <br />
<br />
+---------------------------------------------------+ <br />
Header | OPCODE=SQUERY, RESPONSE | <br />
+---------------------------------------------------+ <br />
Question | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A | <br />
+---------------------------------------------------+ <br />
Answer | <empty> | <br />
+---------------------------------------------------+ <br />
Authority | MIL. 86400 IN NS SRI-NIC.ARPA. | <br />
| 86400 NS A.ISI.EDU. | <br />
+---------------------------------------------------+ <br />
Additional | A.ISI.EDU. A 26.3.0.103 | <br />
| SRI-NIC.ARPA. A 26.0.0.73 | <br />
| A 10.0.0.51 | <br />
+---------------------------------------------------+ <br />
<br />
This response has an empty answer section, but is not authoritative, so <br />
it is a referral. The name server on C.ISI.EDU, realizing that it is <br />
not authoritative for the MIL domain, has referred the requester to <br />
servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative <br />
for the MIL domain. <br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 44] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A <br />
<br />
The response to this query from A.ISI.EDU would be: <br />
<br />
+---------------------------------------------------+ <br />
Header | OPCODE=SQUERY, RESPONSE, AA | <br />
+---------------------------------------------------+ <br />
Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A | <br />
+---------------------------------------------------+ <br />
Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. | <br />
| C.ISI.EDU. 86400 IN A 10.0.0.52 | <br />
+---------------------------------------------------+ <br />
Authority | <empty> | <br />
+---------------------------------------------------+ <br />
Additional | <empty> | <br />
+---------------------------------------------------+ <br />
<br />
Note that the AA bit in the header guarantees that the data matching <br />
QNAME is authoritative, but does not say anything about whether the data <br />
for C.ISI.EDU is authoritative. This complete reply is possible because <br />
A.ISI.EDU happens to be authoritative for both the ARPA domain where <br />
USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is <br />
found. <br />
<br />
If the same query was sent to C.ISI.EDU, its response might be the same <br />
as shown above if it had its own address in its cache, but might also <br />
be: <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 45] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
+---------------------------------------------------+ <br />
Header | OPCODE=SQUERY, RESPONSE, AA | <br />
+---------------------------------------------------+ <br />
Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A | <br />
+---------------------------------------------------+ <br />
Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. | <br />
+---------------------------------------------------+ <br />
Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. | <br />
| NS A.ISI.EDU. | <br />
| NS VENERA.ISI.EDU. | <br />
+---------------------------------------------------+ <br />
Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 | <br />
| 172800 A 128.9.0.33 | <br />
| VENERA.ISI.EDU. 172800 A 10.1.0.52 | <br />
| 172800 A 128.9.0.32 | <br />
| A.ISI.EDU. 172800 A 26.3.0.103 | <br />
+---------------------------------------------------+ <br />
<br />
This reply contains an authoritative reply for the alias USC-ISIC.ARPA, <br />
plus a referral to the name servers for ISI.EDU. This sort of reply <br />
isn't very likely given that the query is for the host name of the name <br />
server being asked, but would be common for other aliases. <br />
<br />
6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME <br />
<br />
If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would <br />
be: <br />
<br />
+---------------------------------------------------+ <br />
Header | OPCODE=SQUERY, RESPONSE, AA | <br />
+---------------------------------------------------+ <br />
line-2115 John Kristoff(Technical Erratum #755) [Held for Document Update]<br />
based on outdated version<br />
Section 6.1. ends this way:<br />
<br />
Relative and absolute domain names may be freely intermixed in a<br />
master<br />
<br />
which is incomplete. It's unclear exactly how that sentence may have<br />
been intended to end, but minimally I would suggeste it at least<br />
terminated with 'file.'.<br />
Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A | <br />
+---------------------------------------------------+ <br />
Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. | <br />
+---------------------------------------------------+ <br />
Authority | <empty> | <br />
+---------------------------------------------------+ <br />
Additional | <empty> | <br />
+---------------------------------------------------+ <br />
<br />
Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name <br />
server doesn't attempt to look up anything for C.ISI.EDU. (Except <br />
possibly for the additional section.) <br />
<br />
6.3. Example resolution <br />
<br />
The following examples illustrate the operations a resolver must perform <br />
for its client. We assume that the resolver is starting without a <br />
<br />
<br />
<br />
Mockapetris [Page 46] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
cache, as might be the case after system boot. We further assume that <br />
the system is not one of the hosts in the data and that the host is <br />
located somewhere on net 26, and that its safety belt (SBELT) data <br />
structure has the following information: <br />
<br />
Match count = -1 <br />
SRI-NIC.ARPA. 26.0.0.73 10.0.0.51 <br />
A.ISI.EDU. 26.3.0.103 <br />
<br />
This information specifies servers to try, their addresses, and a match <br />
count of -1, which says that the servers aren't very close to the <br />
target. Note that the -1 isn't supposed to be an accurate closeness <br />
measure, just a value so that later stages of the algorithm will work. <br />
<br />
The following examples illustrate the use of a cache, so each example <br />
assumes that previous requests have completed. <br />
<br />
6.3.1. Resolve MX for ISI.EDU. <br />
<br />
Suppose the first request to the resolver comes from the local mailer, <br />
which has mail for PVM@ISI.EDU. The mailer might then ask for type MX <br />
RRs for the domain name ISI.EDU. <br />
<br />
The resolver would look in its cache for MX RRs at ISI.EDU, but the <br />
empty cache wouldn't be helpful. The resolver would recognize that it <br />
needed to query foreign servers and try to determine the best servers to <br />
query. This search would look for NS RRs for the domains ISI.EDU, EDU, <br />
and the root. These searches of the cache would also fail. As a last <br />
resort, the resolver would use the information from the SBELT, copying <br />
it into its SLIST structure. <br />
<br />
At this point the resolver would need to pick one of the three available <br />
addresses to try. Given that the resolver is on net 26, it should <br />
choose either 26.0.0.73 or 26.3.0.103 as its first choice. It would <br />
then send off a query of the form: <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 47] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
+---------------------------------------------------+ <br />
Header | OPCODE=SQUERY | <br />
+---------------------------------------------------+ <br />
Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | <br />
+---------------------------------------------------+ <br />
Answer | <empty> | <br />
+---------------------------------------------------+ <br />
Authority | <empty> | <br />
+---------------------------------------------------+ <br />
Additional | <empty> | <br />
+---------------------------------------------------+ <br />
<br />
The resolver would then wait for a response to its query or a timeout. <br />
If the timeout occurs, it would try different servers, then different <br />
addresses of the same servers, lastly retrying addresses already tried. <br />
It might eventually receive a reply from SRI-NIC.ARPA: <br />
<br />
+---------------------------------------------------+ <br />
Header | OPCODE=SQUERY, RESPONSE | <br />
+---------------------------------------------------+ <br />
Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | <br />
+---------------------------------------------------+ <br />
Answer | <empty> | <br />
+---------------------------------------------------+ <br />
Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. | <br />
| NS A.ISI.EDU. | <br />
| NS VENERA.ISI.EDU.| <br />
+---------------------------------------------------+ <br />
Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 | <br />
| 172800 A 128.9.0.33 | <br />
| VENERA.ISI.EDU. 172800 A 10.1.0.52 | <br />
| 172800 A 128.9.0.32 | <br />
| A.ISI.EDU. 172800 A 26.3.0.103 | <br />
+---------------------------------------------------+ <br />
<br />
The resolver would notice that the information in the response gave a <br />
closer delegation to ISI.EDU than its existing SLIST (since it matches <br />
three labels). The resolver would then cache the information in this <br />
response and use it to set up a new SLIST: <br />
<br />
Match count = 3 <br />
A.ISI.EDU. 26.3.0.103 <br />
VAXA.ISI.EDU. 10.2.0.27 128.9.0.33 <br />
VENERA.ISI.EDU. 10.1.0.52 128.9.0.32 <br />
<br />
A.ISI.EDU appears on this list as well as the previous one, but that is <br />
purely coincidental. The resolver would again start transmitting and <br />
waiting for responses. Eventually it would get an answer: <br />
<br />
<br />
<br />
Mockapetris [Page 48] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
+---------------------------------------------------+ <br />
Header | OPCODE=SQUERY, RESPONSE, AA | <br />
+---------------------------------------------------+ <br />
Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | <br />
+---------------------------------------------------+ <br />
Answer | ISI.EDU. MX 10 VENERA.ISI.EDU. | <br />
| MX 20 VAXA.ISI.EDU. | <br />
+---------------------------------------------------+ <br />
Authority | <empty> | <br />
+---------------------------------------------------+ <br />
Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 | <br />
| 172800 A 128.9.0.33 | <br />
| VENERA.ISI.EDU. 172800 A 10.1.0.52 | <br />
| 172800 A 128.9.0.32 | <br />
+---------------------------------------------------+ <br />
<br />
The resolver would add this information to its cache, and return the MX <br />
RRs to its client. <br />
<br />
6.3.2. Get the host name for address 26.6.0.65 <br />
<br />
The resolver would translate this into a request for PTR RRs for <br />
65.0.6.26.IN-ADDR.ARPA. This information is not in the cache, so the <br />
resolver would look for foreign servers to ask. No servers would match, <br />
so it would use SBELT again. (Note that the servers for the ISI.EDU <br />
domain are in the cache, but ISI.EDU is not an ancestor of <br />
65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.) <br />
<br />
Since this request is within the authoritative data of both servers in <br />
SBELT, eventually one would return: <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 49] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
+---------------------------------------------------+ <br />
Header | OPCODE=SQUERY, RESPONSE, AA | <br />
+---------------------------------------------------+ <br />
Question | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR | <br />
+---------------------------------------------------+ <br />
Answer | 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA. | <br />
+---------------------------------------------------+ <br />
Authority | <empty> | <br />
+---------------------------------------------------+ <br />
Additional | <empty> | <br />
+---------------------------------------------------+ <br />
<br />
6.3.3. Get the host address of poneria.ISI.EDU <br />
<br />
This request would translate into a type A request for poneria.ISI.EDU. <br />
The resolver would not find any cached data for this name, but would <br />
find the NS RRs in the cache for ISI.EDU when it looks for foreign <br />
servers to ask. Using this data, it would construct a SLIST of the <br />
form: <br />
<br />
Match count = 3 <br />
<br />
A.ISI.EDU. 26.3.0.103 <br />
VAXA.ISI.EDU. 10.2.0.27 128.9.0.33 <br />
VENERA.ISI.EDU. 10.1.0.52 <br />
<br />
A.ISI.EDU is listed first on the assumption that the resolver orders its <br />
choices by preference, and A.ISI.EDU is on the same network. <br />
<br />
One of these servers would answer the query. <br />
<br />
7. REFERENCES and BIBLIOGRAPHY <br />
<br />
[Dyer 87] Dyer, S., and F. Hsu, "Hesiod", Project Athena <br />
Technical Plan - Name Service, April 1987, version 1.9. <br />
<br />
Describes the fundamentals of the Hesiod name service. <br />
<br />
[IEN-116] J. Postel, "Internet Name Server", IEN-116, <br />
USC/Information Sciences Institute, August 1979. <br />
<br />
A name service obsoleted by the Domain Name System, but <br />
still in use. <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 50] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
line-2507 John Kristoff(Technical Erratum #755) [Held for Document Update]<br />
based on outdated version<br />
Section 6.2.8. in the diagram shows 'QTYPE=A', but should be of<br />
type 'CNAME' based on the context of the example.<br />
It should say:<br />
[see above]<br />
[Quarterman 86] Quarterman, J., and J. Hoskins, "Notable Computer <br />
Networks",Communications of the ACM, October 1986, <br />
volume 29, number 10. <br />
<br />
[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network <br />
Information Center, SRI International, December 1977. <br />
<br />
[RFC-768] J. Postel, "User Datagram Protocol", RFC-768, <br />
USC/Information Sciences Institute, August 1980. <br />
<br />
[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793, <br />
USC/Information Sciences Institute, September 1981. <br />
<br />
[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT, <br />
September 1981. <br />
<br />
Suggests introduction of a hierarchy in place of a flat <br />
name space for the Internet. <br />
<br />
[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805, <br />
USC/Information Sciences Institute, February 1982. <br />
<br />
[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD <br />
Internet Host Table Specification", RFC-810, Network <br />
Information Center, SRI International, March 1982. <br />
<br />
Obsolete. See RFC-952. <br />
<br />
[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames <br />
Server", RFC-811, Network Information Center, SRI <br />
International, March 1982. <br />
<br />
Obsolete. See RFC-953. <br />
<br />
[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812, <br />
Network Information Center, SRI International, March <br />
1982. <br />
<br />
[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for <br />
Internet User Applications", RFC-819, Network <br />
Information Center, SRI International, August 1982. <br />
<br />
Early thoughts on the design of the domain system. <br />
Current implementation is completely different. <br />
<br />
[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821, <br />
USC/Information Sciences Institute, August 1980. <br />
<br />
<br />
<br />
<br />
Mockapetris [Page 51] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
[RFC-830] Z. Su, "A Distributed System for Internet Name Service", <br />
RFC-830, Network Information Center, SRI International, <br />
October 1982. <br />
<br />
Early thoughts on the design of the domain system. <br />
Current implementation is completely different. <br />
<br />
line-2751 Ivan Panchenko(Editorial Erratum #6461) [Verified]<br />
based on outdated version<br />
Networks",Communications of the ACM, October 1986,<br />
It should say:<br />
Networks", Communications of the ACM, October 1986,<br />
<br />
Missing space.<br />
[RFC-882] P. Mockapetris, "Domain names - Concepts and <br />
Facilities," RFC-882, USC/Information Sciences <br />
Institute, November 1983. <br />
<br />
Superceeded by this memo. <br />
<br />
[RFC-883] P. Mockapetris, "Domain names - Implementation and <br />
Specification," RFC-883, USC/Information Sciences <br />
Institute, November 1983. <br />
<br />
Superceeded by this memo. <br />
<br />
[RFC-920] J. Postel and J. Reynolds, "Domain Requirements", <br />
RFC-920, USC/Information Sciences Institute <br />
October 1984. <br />
<br />
Explains the naming scheme for top level domains. <br />
<br />
[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host <br />
Table Specification", RFC-952, SRI, October 1985. <br />
<br />
Specifies the format of HOSTS.TXT, the host/address <br />
table replaced by the DNS. <br />
<br />
[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server", <br />
RFC-953, SRI, October 1985. <br />
<br />
This RFC contains the official specification of the <br />
hostname server protocol, which is obsoleted by the DNS. <br />
This TCP based protocol accesses information stored in <br />
the RFC-952 format, and is used to obtain copies of the <br />
host table. <br />
<br />
[RFC-973] P. Mockapetris, "Domain System Changes and <br />
Observations", RFC-973, USC/Information Sciences <br />
Institute, January 1986. <br />
<br />
Describes changes to RFC-882 and RFC-883 and reasons for <br />
them. Now obsolete. <br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 52] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
[RFC-974] C. Partridge, "Mail routing and the domain system", <br />
RFC-974, CSNET CIC BBN Labs, January 1986. <br />
<br />
Describes the transition from HOSTS.TXT based mail <br />
addressing to the more powerful MX system used with the <br />
domain system. <br />
<br />
[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS <br />
service on a TCP/UDP transport: Concepts and Methods", <br />
RFC-1001, March 1987. <br />
<br />
This RFC and RFC-1002 are a preliminary design for <br />
NETBIOS on top of TCP/IP which proposes to base NetBIOS <br />
name service on top of the DNS. <br />
<br />
[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS <br />
service on a TCP/UDP transport: Detailed <br />
Specifications", RFC-1002, March 1987. <br />
<br />
[RFC-1010] J. Reynolds and J. Postel, "Assigned Numbers", RFC-1010, <br />
USC/Information Sciences Institute, May 1987 <br />
<br />
Contains socket numbers and mnemonics for host names, <br />
operating systems, etc. <br />
<br />
[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031, <br />
November 1987. <br />
<br />
Describes a plan for converting the MILNET to the DNS. <br />
<br />
[RFC-1032] M. K. Stahl, "Establishing a Domain - Guidelines for <br />
Administrators", RFC-1032, November 1987. <br />
<br />
Describes the registration policies used by the NIC to <br />
administer the top level domains and delegate subzones. <br />
<br />
[RFC-1033] M. K. Lottor, "Domain Administrators Operations Guide", <br />
RFC-1033, November 1987. <br />
<br />
A cookbook for domain administrators. <br />
<br />
[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET <br />
Name Server", Computer Networks, vol 6, nr 3, July 1982. <br />
<br />
Describes a name service for CSNET which is independent <br />
from the DNS and DNS use in the CSNET. <br />
<br />
<br />
<br />
<br />
<br />
Mockapetris [Page 53] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
Index <br />
<br />
A 12 <br />
Absolute names 8 <br />
Aliases 14, 31 <br />
Authority 6 <br />
AXFR 17 <br />
<br />
Case of characters 7 <br />
CH 12 <br />
CNAME 12, 13, 31 <br />
Completion queries 18 <br />
<br />
Domain name 6, 7 <br />
<br />
Glue RRs 20 <br />
<br />
HINFO 12 <br />
<br />
IN 12 <br />
Inverse queries 16 <br />
Iterative 4 <br />
<br />
Label 7 <br />
<br />
Mailbox names 9 <br />
MX 12 <br />
<br />
Name error 27, 36 <br />
Name servers 5, 17 <br />
NE 30 <br />
Negative caching 44 <br />
NS 12 <br />
<br />
Opcode 16 <br />
<br />
PTR 12 <br />
<br />
QCLASS 16 <br />
QTYPE 16 <br />
<br />
RDATA 13 <br />
Recursive 4 <br />
Recursive service 22 <br />
Relative names 7 <br />
Resolvers 6 <br />
RR 12 <br />
<br />
<br />
<br />
<br />
Mockapetris [Page 54] <br />
<br />
RFC 1034 Domain Concepts and Facilities November 1987 <br />
<br />
<br />
Safety belt 33 <br />
Sections 16 <br />
SOA 12 <br />
Standard queries 22 <br />
<br />
Status queries 18 <br />
Stub resolvers 32 <br />
<br />
TTL 12, 13 <br />
<br />
Wildcards 25 <br />
<br />
Zone transfers 28 <br />
Zones 19</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-RFC&diff=10DNS-RFC2024-03-04T05:32:10Z<p>Yu：</p>
<hr />
<div># 基础DNS相关RFC<br />
<br />
[[RFC 1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES]]<br />
<br />
<br />
# 基础DNS相关RFC</div>Yuhttps://www.dnswiki.cn/index.php?title=DNS-RFC&diff=9DNS-RFC2024-03-04T05:29:16Z<p>Yu：</p>
<hr />
<div>|header 1|header 2|header 3|<br />
|info 1|info 2<br>next line|info 3|<br />
|info 4|info 5|info 6|</div>Yuhttps://www.dnswiki.cn/index.php?title=%E9%A6%96%E9%A1%B5&diff=8首页2024-03-04T05:23:30Z<p>Yu：</p>
<hr />
<div>*[[DNS-RFC]]<br />
<br />
*[[BIND]]<br />
<br />
<br />
<br />
<br />
<strong>已安装MediaWiki。</strong><br />
<br />
请查阅[https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents 用户指导]以获取使用本wiki软件的信息。<br />
<br />
== 入门 ==<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings MediaWiki配置设置列表]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ/zh-hans MediaWiki常见问题]<br />
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki发布邮件列表]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources 本地化MediaWiki到您的语言]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam 了解如何在您的wiki上打击破坏]<br />
<br />
<br />
<br />
kjhkh<br />
<br />
<br />
jhk<br />
<br />
kjk<br />
kjhk<br />
<br />
kjhkjh<br />
<br />
hhjkhk<br />
<br />
kjhkh<br />
jhk<br />
<br />
kjk<br />
<br />
kjhk<br />
<br />
kjhkjh<br />
<br />
hhjkhk<br />
<br />
kjhkh<br />
<br />
jhk<br />
<br />
kjk<br />
<br />
kjhk<br />
<br />
kjhkjh<br />
<br />
hhjkhk<br />
<br />
kjhkh<br />
<br />
jhk<br />
<br />
kjk<br />
<br />
kjhk<br />
<br />
kjhkjh<br />
<br />
hhjkhk</div>Yu