## page was renamed from DNS/NXDOMAIN == DNS/返答/NXDOMAIN == <> [[../否定返答]]のひとつ、RCODE 3で示される。(AA on?) {{{ NOERRORを返答すべき状況なのに、NXDOMAINを返す権威サーバーが存在する。 NS毒盛対策に利用できる返答である。しかし、現時点で活用しているリゾルバーは見当たらない。 }}} そして、サービス妨害攻撃にも使える。[[/毒盛]] 関連項目: [[../NoData]] [[/awsdns]] [[DNS/NXDOMAIN]] https://www.extremenetworks.com/extreme-networks-blog/monitoring-dns-nxdomain/ [[/cloudflare]] <> [[DNS/RFC/2308]] でクリアになったのか。 　http://www.e-ontap.com/dns/onsen4/rfc2308.html#(6) NXDOMAINとは(RCODEがNXDomain, AA flag on, -> SOAあり)かと思っていたが、以下の場合もある。 Answer Sectionがあって、CNAMEレコードがあり、Authoritiy Section にSOAがない。 [[/RFC]] == NXDOMAINを返す状況 == いくつかの立場があるが、共通する解釈としては： 　問い合わせ名(qname)にはいかなる資源レコード(RR)も存在しないということ。 　　ただし、qnameに対するCNAMEが存在する場合には事情が異なる。(トラブルの元） 他方、NoData(NoError)は問い合わせtypeのRRが存在しないと言っているだけだ。[[DNS/返答/NoData返答]] この立場は排他的ではないので、同じドメイン名に対して、両方の返答がありえる。:-< 現時点ではDJBの実装(dnscache)が妥当だと考える。 　レコードがまったく存在しないドメイン名のqueryにはNXDOMAINを返してほしい。(NoDataではなく） 　　サブドメインが存在するかどうかを調べる手間はかけなくてよい。 -- ToshinoriMaeno <> == リゾルバーの立場 == 別typeのレコードが存在しているにも拘らず、NXDOOMAIN返答が返ってきたら、毒を疑うべきだ。 　RFC 2181にはこのあたりの話はない。(矛盾する返答といいながら。）-- ToshinoriMaeno <> あるいは毒ではないと判断したら、キャッシュにある同名のレコードは消去する。(BINDの動作） -- ToshinoriMaeno <> [[/TTL]] == 実際の返答 == NXDOMAIN(RCODE=3)返答でよくあるのは 　answer sectionが空で、authority sectionにひとつのSOAを含むというものだ。 しかし、そうでないものもありえる。 ゾーンサーバー(Authoritative server)が返してくる[[DNS/1/RCODE/NXDOMAIN]]返答(rcode=3)がおかしいことがある。 1. NoDataを返すべきときにNXDOMAINを返している。(SOAがある。） 2. NoErrorを返すべきときにNXDOMAINを返している。(SOAはなくて、Answerがある。） ほかにもある。 jp.edgekey.netの返事はNXDOMAINとNOERRORが混じる。(間違いとは言えない） 現状の調査を行い、なぜこうなったのかの理由を解明したい。 == 返答の扱い == 多くのリゾルバーはNoError扱いにしているようだ。(違った） 　リゾルバー側で毒盛に使われる心配もある。　 　　tssさんは共用サーバーで毒を入れやすくなると言っている。 　　　DoS攻撃に使えるとは思うが。 登録時にドメインの権利関係を確認しない共用DNSサービスはもともと危険な存在だ。 -- ToshinoriMaeno <> [[/リゾルバー]] == RFC == Negative Caching of DNS Queries (DNS NCACHE) https://tools.ietf.org/html/rfc2308 xNAME RCODE and Status Bits Clarification https://tools.ietf.org/html/rfc6604 NXDOMAIN: There Really Is Nothing Underneath https://tools.ietf.org/html/rfc8020 ---- [DNS/実装/NXDOMAIN]] [[/qname-minimisation]] NXDOMAIN返答から分かることを理解することで、[[/毒盛対策]]に出来ると分かった。 　[[../NoData返答]] も返るが、同様に対策に利用できる。-- ToshinoriMaeno <> == DNS/返答/NXDOMAIN == https://tools.ietf.org/html/rfc2308 Negative Caching of DNS Queries (DNS NCACHE) {{{ 2.1 - Name Error Name errors (NXDOMAIN) are indicated by the presence of "Name Error" in the RCODE field. In this case the domain referred to by the QNAME does not exist. Note: the answer section may have SIG and CNAME RRs and the authority section may have SOA, NXT [RFC2065] and SIG RRsets. }}} QNAME が存在しないことを示す。（でも、存在するとかしないとかの定義は？） 　　CNAMEレコードが存在するにもかかわらず、Name Error を返すというおかしな例だけが書かれている。 QNAMEをもつノードが存在しないというのが唯一の解釈であるが、それからの帰結はQNAMEのサブドメインも 存在しないというものである。 　しかしながら、これに従わないCDN(broken)が存在する。 {{{ 2.1.1 Special Handling of Name Error servers that are authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN responses, that is the authority section contains a SOA record and no NS records. }}} == Negative Answers == {{{ 3 - Negative Answers from Authoritative Servers Name servers authoritative for a zone MUST include the SOA record of the zone in the authority section of the response when reporting an NXDOMAIN or indicating that no data of the requested type exists. This is required so that the response may be cached. The TTL of this record is set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself, and indicates how long a resolver may cache the negative answer. The TTL SIG record associated with the SOA record should also be trimmed in line with the SOA's TTL. }}} SOAレコードを付けなければならない。MUST これに従わないのはbrokenということ。www.ntt.co.jp NSを調べてみよ。 （注：　SOAをつけるのはNXDOMAINあるいはno data返答に責任をもてるサーバだと解釈できる。） == RFC 2308 == [[DNS/RFC/2308]] https://www.rfc-editor.org/rfc/rfc2308.txt {{{ "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as described in [RFC1035 Section 4.1.1] and the two terms are used interchangeably in this document. }}} [[/DJBの見解]]：　http://cr-yp-to.996295.n3.nabble.com/Fixing-the-NXDOMAIN-NODATA-bug-in-tinydns-td17150.html#a17171 broken CDNs https://twitter.com/beyondDNS/status/653558544415916032?lang=ja {{{ "NODATA" - a pseudo RCODE which indicates that the name is valid, for the given class, but are no records of the given type. A NODATA response has to be inferred from the answer. }}} RCODE ではないことに注意せよ。[問い合せタイプの資源レコードをもたないドメイン名であることを示す。] NXDOMAIN really means there is nothing underneath (本当はこうあるべきなのだが） https://tools.ietf.org/html/draft-ietf-dnsop-nxdomain-cut-01 [[/akamai]] === 返答例 === [[/返答例]] Kaminsky型攻撃などでNXDOMAIN返答が返ってくるのを[[/毒盛対策]]に利用できないか、検討する。 [[/qmail.jp]] [[/SOA]] %dnsq a xxxx.yyyy.zzzzzzz.qmail.jp f.ns.qmail.jp {{{ 1 xxxx.yyyy.zzzzzzz.qmail.jp: 99 bytes, 1+0+1+0 records, response, authoritative, nxdomain query: 1 xxxx.yyyy.zzzzzzz.qmail.jp authority: qmail.jp 2560 SOA a.ns.qmail.jp hostmaster.m.qmail.jp 1454758295 16384 2048 1048576 2560 }}} 問い合わせたサーバの管理するqmail.jp ゾーンの下にはzzzzzzzゾーンがないことが分かる。（その下も） 　現状での多くのリゾルバーはこの情報を毒の判別には使っていないようだ。 NXDOMAIN返答につけるSOAレコードのラベルは 問い合わせた名前（レコードタイプも）が「存在しないこと」を把握しているゾーンの名前である。 (一番狭いというか、近いというか） [[/jp]] == これまでの議論 == 親子ゾーン同居時の返答を調べておく必要がある。[[ccTLD/uk/NXDOMAIN]] などを参照。 　　[[ccTLD/au/NXDOMAIN]] non-empty terminalの可能性は残っているが、NSを持たないことは保証されるので、NS毒の排除には使える。 ---- 別件： [[DNS/返答/NXDOMAIN/DJBの見解]] akamaiなどの返事を調べてみるといい。[[/dnscache]] https://tools.ietf.org/html/draft-bortzmeyer-dnsop-nxdomain-cut-02　[[/bortzmeyer]] ---- [[DNS/1/RCODE]] に定義されているもの。(RFC 1035) 経緯（歴史）を調べないと、どうあるべきかの議論にもならないらしい。 [[/議論]] -- ToshinoriMaeno <> [[DNS/1/資源レコード/NS/出現場所]] 　ドメイン名がNSレコードを持つ場合にはどういう返事になるか。 　　　yyyy.zzzzzzz.qmail.jp, zzzzzzz.qmail.jp にNSレコードがあればどういう返事になるか。 https://datatracker.ietf.org/doc/draft-ietf-dnsop-nxdomain-cut/ == RCODE (RFC 1035) == 4.1.1. ヘッダ節形式 Header section format {{{ Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist. }}} 名前エラー－権威あるネームサーバからの返答のときにだけ 意味がある。このコードは問合せで参照されたドメイン名が 存在しないことを示す。 1035 を見た後は 1536 も見た方がよさそう。 https://www.ietf.org/rfc/rfc1536.txt 結論はこれ： http://www.samiam.org/blog/20110423.html DJBの言うように RFC 2308 でおかしな利用法が認められてしまったものだから、相互運用の立場から、 {{{ 　「empty non-terminal については NXDOMAIN 返答をする」というのがよいというもの。 }}} 現状での理解だと、以下のページにあるNXDOMAIN/NODATAの説明と整合する。 つまり、以下のように理解しているひともいそうだということに。 　http://www.geekpage.jp/blog/?id=2014/7/25/1 ---- {{{ It is possible to distinguish between a referral and a NXDOMAIN response by the presense of NXDOMAIN in the RCODE regardless of the presence of NS or SOA records in the authority section. }}} http://www.ietf.org/mail-archive/web/dnsext/current/msg11156.html http://www.ietf.org/mail-archive/web/dnsext/current/msg11084.html == OpenDNS == https://engineering.opendns.com/2014/06/23/nxdomain-nodata-debugging-dns-dual-stacked-hosts/ この解釈は古いBINDの振る舞いを説明しているのかもしれない。 　　レコードがないことと、ドメイン名が存在しないことの区別がついていないのではないか。　＠SIG@ [[DNS/NODATA]] == 重要なのは RCODE == NXDOMAIN 返答にNSレコードがあっても(なくても)よいようだ。 毒かもしれない。ｗｎ {{{ NXDOMAIN responses can be categorised into four types by the contents of the authority section. These are shown below along with a referral for comparison. Fields not mentioned are not important in terms of the examples. }}} だが、例示はまずい内容だ。　Authority Section には外部名のNS! [[/４つのタイプ]]