## page was renamed from DNS/1/返答/authority_section ## page was renamed from DNS/基礎知識/返答/authority_section ## page was renamed from DNS/用語/返答/authority_section ## page was renamed from DNS/用語/response/authority_section ## page was renamed from DNS/response/authority_section <> == DNS/response/authority_section == <> [[../answer_section]] [[../additional_section]] [[DNS/RFC/1035/4]] より： authority section の用途 {{{ the authority section contains RRs that point toward an authoritative name server; }}} 権威節は権威を持つネームサーバに近づくためのRRsを含む; 用途としては「委譲・委任」のための「参照先」を指すためにある。 [[DNS/毒盛/AncillaryDataAttacks]] 毒盛手段となる。 否定返答では、返答をしたゾーンの責任あるサーバーを示す。(queryにもっとも近いゾーンサーバー) [[/SOAレコード]] == レコード == [[/NSレコード]]以外にはSOAレコードが現れることがある。(NXDOMAIN返答） SIGレコードも認められているらしい。 Route 53 での説明など 　http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/DNSBehavior.html Knot DNS: A high-performance, authoritative DNS server http://lwn.net/Articles/606968/ == owner == query name の suffix == RFC 2181 より == https://tools.ietf.org/html/rfc2181 5.5. Sending RRSets (reprise) {{{ A Resource Record Set should only be included once in any DNS reply. It may occur in any of the Answer, Authority, or Additional Information sections, as required. However it should not be repeated in the same, or any other, section, except where explicitly required by a specification. For example, an AXFR response requires the SOA record (always an RRSet containing a single RR) be both the first and last record of the reply. Where duplicates are required this way, the TTL transmitted in each case must be the same. }}} ---- 6.1. Zone authority {{{ The authoritative servers for a zone are enumerated in the NS records for the origin of the zone, which, along with a Start of Authority (SOA) record are the mandatory records in every zone. Such a server is authoritative for all resource records in a zone that are not in another zone. The NS records that indicate a zone cut are the property of the child zone created, as are any other records for the origin of that child zone, or any sub-domains of it. }}} {{{ A server for a zone should not return authoritative answers for queries related to names in another zone, which includes the NS, and perhaps A, records at a zone cut, unless it also happens to be a server for the other zone. Other than the DNSSEC cases mentioned immediately below, servers should ignore data other than NS records, and necessary A records to locate the servers listed in the NS records, that may happen to be configured in a zone at a zone cut. }}} %grep -n -i -3 'authority section' rfc2181.txt ~/dnsdoc/RFC {{{ 255- In some cases, this could be a very large number of records, not 256- helped by their being rather large RRs. 257- 258: Thus, it is specifically permitted for the authority section to 259- contain only those SIG RRs with the "type covered" field equal to the 260- type field of an answer being returned. However, where SIG records 261- are being returned in the answer section, in response to a query for -- 266- Servers that receive responses containing SIG records in the 267: authority section, or (probably incorrectly) as additional data, must 268- understand that the entire RRSet has almost certainly not been 269- included. Thus, they must not cache that SIG record in a way that 270- would permit it to be returned should a query for SIG records be -- 357- + Data from a zone transfer, other than glue, 358- + The authoritative data included in the answer section of an 359- authoritative reply. 360: + Data from the authority section of an authoritative answer, 361- + Glue from a primary zone, or glue from a zone transfer, 362- + Data from the answer section of a non-authoritative answer, and 363- non-authoritative data from the answer section of authoritative 364- answers, 365- + Additional information from an authoritative answer, 366: Data from the authority section of a non-authoritative answer, 367- Additional information from non-authoritative answers. 368- -- 377- Unauthenticated RRs received and cached from the least trustworthy of 378- those groupings, that is data from the additional data section, and 379: data from the authority section of a non-authoritative answer, should 380- not be cached in such a way that they would ever be returned as 381- answers to a received query. They may be returned as additional 382- information where appropriate. Ignoring this would allow the -- 519- 520-7.1. Placement of SOA RRs in authoritative answers 521- 522: RFC1034, in section 3.7, indicates that the authority section of an 523- authoritative answer may contain the SOA record for the zone from 524- which the answer was obtained. When discussing negative caching, 525- RFC1034 section 4.3.4 refers to this technique but mentions the 526- additional section of the response. The former is correct, as is 527- implied by the example shown in section 6.2.5 of RFC1034. SOA 528: records, if added, are to be placed in the authority section. 529- }}} == RFC 3655 == Redefinition of DNS Authenticated Data (AD) bit https://www.ietf.org/rfc/rfc3655.txt == blog.catchpoint.com == http://blog.catchpoint.com/2014/07/09/dissecting-dns-communications/ {{{ When a name server like TLDs does not have the answer to the query (as is not authoritative), it will not send answer records. Instead it will populate the authority section with all of the name servers that it knows as authoritative to the domain or part of the domain tree (like .com), if it has them. These NS records are different from A records as they have a domain name in both the RR name and RR data fields. Unlike the answer section, the authority section can only have NS records. Note that NS records can be sent in other sections. }}}