1. 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 2016-03-13 11:32:38

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.)