目录
资源记录RR的组成：
owner which is the domain name where the RR is found.
type which is an encoded 16 bit value that specifies the type
of the resource in this resource record. Types refer to
abstract resources.
This memo uses the following types:
A a host address
CNAME identifies the canonical name of an
alias
HINFO identifies the CPU and OS used by a host
MX identifies a mail exchange for the
domain. See [RFC-974 for details.
NS
the authoritative name server for the domain
PTR
a pointer to another part of the domain name space
SOA
identifies the start of a zone of authority]
class which is an encoded 16 bit value which identifies a
protocol family or instance of a protocol.
This memo uses the following classes:
IN the Internet system
CH the Chaos system
TTL which is the time to live of the RR. This field is a 32
bit integer in units of seconds, an is primarily used by
resolvers when they cache RRs. The TTL describes how
long a RR can be cached before it should be discarded.TTL为0表示禁止缓存
RDATA which is the type and sometimes class dependent data
which describes the resource:
A For the IN class, a 32 bit IP address
For the CH class, a domain name followed
by a 16 bit octal Chaos address.
CNAME a domain name.
MX a 16 bit preference value (lower is
better) followed by a host name willing
to act as a mail exchange for the owner
domain.
NS a host name.
PTR a domain name.
SOA several fields
请求与应答组成部分
Question Carries the query name and other query parameters.
Answer Carries RRs which directly answer the query.
Authority Carries RRs which describe other authoritative servers.
May optionally carry the SOA RR for the authoritative
data in the answer section.
Additional Carries RRs which may be helpful in using the RRs in the
other sections.
请求类型
The QTYPE field may contain: <any type> matches just that type. (e.g., A, PTR). AXFR special zone transfer QTYPE. MAILB matches all mail box related RRs (e.g. MB and MG). * matches all RR types.
For example, a mailer tying to send mail to Mockapetris@ISI.EDU might
ask the resolver for mail information about ISI.EDU, resulting in a
query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN. The response's answer
section would be:
ISI.EDU. MX 10 VENERA.ISI.EDU.
MX 10 VAXA.ISI.EDU.
while the additional section might be:
VAXA.ISI.EDU. A 10.2.0.27
A 128.9.0.33
VENERA.ISI.EDU. A 10.1.0.52
A 128.9.0.32
逆向查询
3.7.2. Inverse queries (Optional) Name servers may also support inverse queries that map a particular resource to a domain name or domain names that have that resource. For example, while a standard query might map a domain name to a SOA RR, the corresponding inverse query might map the SOA RR back to the domain name.
逆向查询并不是指反向查询
Example standard queries
A类型查询
6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A The query would look like: +---------------------------------------------------+ Header | OPCODE=SQUERY | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A | +---------------------------------------------------+ Answer | <empty> | +---------------------------------------------------+ Authority | <empty> | +---------------------------------------------------+ Additional | <empty> | +---------------------------------------------------+ The response from C.ISI.EDU would be: +---------------------------------------------------+ Header | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A | +---------------------------------------------------+ Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 | | 86400 IN A 10.0.0.51 | +---------------------------------------------------+ Authority | <empty> | +---------------------------------------------------+ Additional | <empty> | +---------------------------------------------------+ The header of the response looks like the header of the query, except that the RESPONSE bit is set, indicating that this message is a response, not a query, and the Authoritative Answer (AA) bit is set indicating that the address RRs in the answer section are from authoritative data. The question section of the response matches the question section of the query. If the same query was sent to some other server which was not authoritative for SRI-NIC.ARPA, the response might be: +---------------------------------------------------+ Header | OPCODE=SQUERY,RESPONSE | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A | +---------------------------------------------------+ Answer | SRI-NIC.ARPA. 1777 IN A 10.0.0.51 | | 1777 IN A 26.0.0.73 | +---------------------------------------------------+ Authority | <empty> | +---------------------------------------------------+ Additional | <empty> | +---------------------------------------------------+ This response is different from the previous one in two ways: the header does not have AA set, and the TTLs are different. The inference is that the data did not come from a zone, but from a cache. The difference between the authoritative TTL and the TTL here is due to aging of the data in a cache. The difference in ordering of the RRs in the answer section is not significant.
ANY类型查询
6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=* A query similar to the previous one, but using a QTYPE of *, would receive the following response from C.ISI.EDU: +---------------------------------------------------+ Header | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | +---------------------------------------------------+ Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 | | A 10.0.0.51 | | MX 0 SRI-NIC.ARPA. | | HINFO DEC-2060 TOPS20 | +---------------------------------------------------+ Authority | <empty> | +---------------------------------------------------+ Additional | <empty> | +---------------------------------------------------+ If a similar query was directed to two name servers which are not authoritative for SRI-NIC.ARPA, the responses might be: +---------------------------------------------------+ Header | OPCODE=SQUERY, RESPONSE | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | +---------------------------------------------------+ Answer | SRI-NIC.ARPA. 12345 IN A 26.0.0.73 | | A 10.0.0.51 | +---------------------------------------------------+ Authority | <empty> | +---------------------------------------------------+ Additional | <empty> | +---------------------------------------------------+ and +---------------------------------------------------+ Header | OPCODE=SQUERY, RESPONSE | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | +---------------------------------------------------+ Answer | SRI-NIC.ARPA. 1290 IN HINFO DEC-2060 TOPS20 | +---------------------------------------------------+ Authority | <empty> | +---------------------------------------------------+ Additional | <empty> | +---------------------------------------------------+ Neither of these answers have AA set, so neither response comes from authoritative data. The different contents and different TTLs suggest that the two servers cached data at different times, and that the first server cached the response to a QTYPE=A query and the second cached the response to a HINFO query.
MX类型查询
6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX This type of query might be result from a mailer trying to look up routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA. The response from C.ISI.EDU would be: +---------------------------------------------------+ Header | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX | +---------------------------------------------------+ Answer | SRI-NIC.ARPA. 86400 IN MX 0 SRI-NIC.ARPA.| +---------------------------------------------------+ Authority | <empty> | +---------------------------------------------------+ Additional | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 | | A 10.0.0.51 | +---------------------------------------------------+ This response contains the MX RR in the answer section of the response. The additional section contains the address RRs because the name server at C.ISI.EDU guesses that the requester will need the addresses in order to properly use the information carried by the MX.
NS类型查询
6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS C.ISI.EDU would reply to this query with: +---------------------------------------------------+ Header | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS | +---------------------------------------------------+ Answer | <empty> | +---------------------------------------------------+ Authority | <empty> | +---------------------------------------------------+ Additional | <empty> | +---------------------------------------------------+ The only difference between the response and the query is the AA and RESPONSE bits in the header. The interpretation of this response is that the server is authoritative for the name, and the name exists, but no RRs of type NS are present there.
不存在的域名查询的权威应答
6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A If a user mistyped a host name, we might see this type of query. C.ISI.EDU would answer it with: +---------------------------------------------------+ Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE | +---------------------------------------------------+ Question | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A | +---------------------------------------------------+ Answer | <empty> | +---------------------------------------------------+ Authority | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. | | 870611 1800 300 604800 86400 | +---------------------------------------------------+ Additional | <empty> | +---------------------------------------------------+ This response states that the name does not exist. This condition is signalled in the response code (RCODE) section of the header. The SOA RR in the authority section is the optional negative caching information which allows the resolver using this response to assume that the name will not exist for the SOA MINIMUM (86400) seconds.
不存在的域名查询的非权威应答
6.2.6. QNAME=BRL.MIL, QTYPE=A If this query is sent to C.ISI.EDU, the reply would be: +---------------------------------------------------+ Header | OPCODE=SQUERY, RESPONSE | +---------------------------------------------------+ Question | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A | +---------------------------------------------------+ Answer | <empty> | +---------------------------------------------------+ Authority | MIL. 86400 IN NS SRI-NIC.ARPA. | | 86400 NS A.ISI.EDU. | +---------------------------------------------------+ Additional | A.ISI.EDU. A 26.3.0.103 | | SRI-NIC.ARPA. A 26.0.0.73 | | A 10.0.0.51 | +---------------------------------------------------+ This response has an empty answer section, but is not authoritative, so it is a referral. The name server on C.ISI.EDU, realizing that it is not authoritative for the MIL domain, has referred the requester to servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative for the MIL domain.
A类型查询CNAME应答
不带authority及additional字段 与带两个字段
6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A The response to this query from A.ISI.EDU would be: +---------------------------------------------------+ Header | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A | +---------------------------------------------------+ Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. | | C.ISI.EDU. 86400 IN A 10.0.0.52 | +---------------------------------------------------+ Authority | <empty> | +---------------------------------------------------+ Additional | <empty> | +---------------------------------------------------+ Note that the AA bit in the header guarantees that the data matching QNAME is authoritative, but does not say anything about whether the data for C.ISI.EDU is authoritative. This complete reply is possible because A.ISI.EDU happens to be authoritative for both the ARPA domain where USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is found. If the same query was sent to C.ISI.EDU, its response might be the same as shown above if it had its own address in its cache, but might also be:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
+---------------------------------------------------+
Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. |
| NS A.ISI.EDU. |
| NS VENERA.ISI.EDU. |
+---------------------------------------------------+
Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 |
| 172800 A 128.9.0.33 |
| VENERA.ISI.EDU. 172800 A 10.1.0.52 |
| 172800 A 128.9.0.32 |
| A.ISI.EDU. 172800 A 26.3.0.103 |
+---------------------------------------------------+
This reply contains an authoritative reply for the alias USC-ISIC.ARPA,
plus a referral to the name servers for ISI.EDU. This sort of reply
isn't very likely given that the query is for the host name of the name
server being asked, but would be common for other aliases.
CNAME查询
6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would be: +---------------------------------------------------+ Header | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A | +---------------------------------------------------+ Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. | +---------------------------------------------------+ Authority | <empty> | +---------------------------------------------------+ Additional | <empty> | +---------------------------------------------------+ Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name server doesn't attempt to look up anything for C.ISI.EDU. (Except possibly for the additional section.)
MX类型查询
6.3.1. Resolve MX for ISI.EDU. Suppose the first request to the resolver comes from the local mailer, which has mail for PVM@ISI.EDU. The mailer might then ask for type MX RRs for the domain name ISI.EDU. The resolver would look in its cache for MX RRs at ISI.EDU, but the empty cache wouldn't be helpful. The resolver would recognize that it needed to query foreign servers and try to determine the best servers to query. This search would look for NS RRs for the domains ISI.EDU, EDU, and the root. These searches of the cache would also fail. As a last resort, the resolver would use the information from the SBELT, copying it into its SLIST structure. At this point the resolver would need to pick one of the three available addresses to try. Given that the resolver is on net 26, it should choose either 26.0.0.73 or 26.3.0.103 as its first choice. It would then send off a query of the form: +---------------------------------------------------+ Header | OPCODE=SQUERY | +---------------------------------------------------+ Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | +---------------------------------------------------+ Answer | <empty> | +---------------------------------------------------+ Authority | <empty> | +---------------------------------------------------+ Additional | <empty> | +---------------------------------------------------+ The resolver would then wait for a response to its query or a timeout. If the timeout occurs, it would try different servers, then different addresses of the same servers, lastly retrying addresses already tried. It might eventually receive a reply from SRI-NIC.ARPA: +---------------------------------------------------+ Header | OPCODE=SQUERY, RESPONSE | +---------------------------------------------------+ Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | +---------------------------------------------------+ Answer | <empty> | +---------------------------------------------------+ Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. | | NS A.ISI.EDU. | | NS VENERA.ISI.EDU.| +---------------------------------------------------+ Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 | | 172800 A 128.9.0.33 | | VENERA.ISI.EDU. 172800 A 10.1.0.52 | | 172800 A 128.9.0.32 | | A.ISI.EDU. 172800 A 26.3.0.103 | +---------------------------------------------------+ The resolver would notice that the information in the response gave a closer delegation to ISI.EDU than its existing SLIST (since it matches three labels). The resolver would then cache the information in this response and use it to set up a new SLIST: Match count = 3 A.ISI.EDU. 26.3.0.103 VAXA.ISI.EDU. 10.2.0.27 128.9.0.33 VENERA.ISI.EDU. 10.1.0.52 128.9.0.32 A.ISI.EDU appears on this list as well as the previous one, but that is purely coincidental. The resolver would again start transmitting and waiting for responses. Eventually it would get an answer: +---------------------------------------------------+ Header | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | +---------------------------------------------------+ Answer | ISI.EDU. MX 10 VENERA.ISI.EDU. | | MX 20 VAXA.ISI.EDU. | +---------------------------------------------------+ Authority | <empty> | +---------------------------------------------------+ Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 | | 172800 A 128.9.0.33 | | VENERA.ISI.EDU. 172800 A 10.1.0.52 | | 172800 A 128.9.0.32 | +---------------------------------------------------+ The resolver would add this information to its cache, and return the MX RRs to its client.
反向查询
6.3.2. Get the host name for address 26.6.0.65 The resolver would translate this into a request for PTR RRs for 65.0.6.26.IN-ADDR.ARPA. This information is not in the cache, so the resolver would look for foreign servers to ask. No servers would match, so it would use SBELT again. (Note that the servers for the ISI.EDU domain are in the cache, but ISI.EDU is not an ancestor of 65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.) Since this request is within the authoritative data of both servers in SBELT, eventually one would return:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR |
+---------------------------------------------------+
Answer | 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA. |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
840
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
