== DNS/返答/NXDOMAIN/bortzmeyer == https://tools.ietf.org/html/draft-ietf-dnsop-nxdomain-cut-01 Appendix A. Why can't we just use the owner name of the returned SOA? {{{ In this document, we deduce the non-existence of a domain only for NXDOMAIN answers where the denied name was this exact domain. }}} If a resolver sends a query to the name servers of the TLD example, and asks the MX record for www.foobar.example, and receives a NXDOMAIN, it can only register the fact that www.foobar.example (and everything underneath) does not exist. Even if the accompanying SOA record is for example only, one cannot infer that foobar.example is nonexistent. The accompanying SOA indicates the apex of the zone, not the closest existing domain name. ---- [ドメイン名は存在するかもしれないが、zoneが存在しないことは導かれるはずだ] -- ToshinoriMaeno <> RFC-EDITOR: REMOVE BEFORE PUBLICATION: to use a real example today, ask the authoritative name servers of the TLD fr about anything.which.does.not.exist.gouv.fr. The SOA will indicate fr (the apex) even while gouv.fr does exist (there is no zone cut between gouv.fr and fr). {{{ $ dnsq a anything.which.does.not.exist.gouv.fr e.ext.nic.fr 1 anything.which.does.not.exist.gouv.fr: 115 bytes, 1+0+1+0 records, response, authoritative, nxdomain query: 1 anything.which.does.not.exist.gouv.fr authority: fr 5400 SOA nsmaster.nic.fr hostmaster.nic.fr 2223408548 3600 1800 3600000 5400 }}} gouv.fr はゾーンではない。（それ以下も同様） {{{ Deducing the non-existence of a node from the SOA in the NXDOMAIN reply may certainly help with random qnames attacks but this is out-of-scope for this document. }}} It would require to address the problems mentioned in the first paragraph of this section. A possible solution would be, when receiving a NXDOMAIN with a SOA which is more than one label up in the tree, to send requests for the domains which are between the QNAME and the owner name of the SOA. (A resolverwhich does DNSSEC validation or QNAME minimisation will need to do it, anyway.)