The problem with SRV (and MX) is that you can’t tell what an empty additional section means. (By “you” I mean anything in the resolver chain: app, stub, recursor, etc.)
If the AAAA records are missing, does that mean there aren’t any? Does it mean they were not cached? Does it mean the server chose not to provide them for some other reason? If you want to find out, you have to make a follow-up query to get a clear answer, so you have spent two round trips instead of one. And hopefully your recursive server omitted the AAAA because it has an ncache entry so you get a quick answer, but that’s unlikely if the auth server didn’t provide AAAA and the resolver didn’t eagerly go chasing (which they don’t) and you are an early adopter of SRV so no one else filled the ncache for you. This can (in theory) be fixed with DNSSEC, but the additional section processing rules have to be changed so that they require the nonexistence proof when records are missing, and of course stubs and apps have to be changed to understand the NSEC(3) records. Mail servers generally regard additional sections as too unreliable to be useful, and take the simpler slower approach of making all the queries explicitly. It works for them because they are not especially worried about latency. Because of all this I can sympathize with browser authors to some extent; on the other hand, if they had adopted SRV before it was too late, we might have done more to fix these problems in the last 22 years. (eg an EDNS option to disambiguate missing additional records, maybe.) Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
