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