Hmmn, interesting changes. Here's a few questions. As a passive-aggressive DNS manager, I can put RESINFO records anywhere I want, including in my rDNS zones. I can even sign them. If a stub does a RESINFO lookup for a record that actually exists, what's the cache supposed to do? How can a stub tell a RESINFO generated by a RESINFO-aware cache from one passed through a non-aware cache? Does it matter? Presumably if I can put records in the rDNS I have some connection with whoever is using the address space.
Bonus question: what is the stub supposed to do about DNSSEC? The record passed through the non-aware is more likely to have valid DNSSEC than one inserted by the aware cache. For the issue of validating the certificate on a DoT or DoH server, how about this kludge: the client contacts the server by IP address, the server returns a certificate. If it has an IP address and it matches, swell, you're done. If it has a domain name, do a DNSSEC validated A or AAAA lookup, and if you get an answer with the IP of the server, it's OK. If it has multiple domain names, maybe look them all up or maybe don't do that. This can work even for servers in RFC 1918 space, since the IP address isn't used to contact the cache, only to confirm it's the right one. We Let's Encrypt fans can use DNS validation for the certificate, no need for the CA to contact the cache either. This potentially leaks info about the location of the cache to anyone who can observe the traffic, but usually if there's an observer. it is in the cache itself so how much of a problem would that be? After two minutes of thought I don't see any obvious security holes, but it's possible I'm missing something. It works for DoH and DoT on 8.8.8.8 and 8.8.4.4 now. It almost works on 9.9.9.9 except that the cert says *.quad9.net and the hostname is dns.quad9.net. R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
