On May 22, 2019, at 7:21 PM, John Levine <jo...@taugh.com> wrote: > 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?
Cache them. They're no different than any other DNS record. > How can a stub tell a RESINFO > generated by a RESINFO-aware cache from one passed through a non-aware > cache? They cannot. > Does it matter? No. > Presumably if I can put records in the rDNS I > have some connection with whoever is using the address space. Exactly. > 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. A validating stub would, well, validate. Again, these are no different than any other DNS record. > 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. That is possible, but outside the scope of this document. That is, the same would be true for *any* HTTPS client that gets a certificate with an IP address in the certificate but not a name that it likes. > 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? Agree. > 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. Those are implementation issues. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
