On Tue, Oct 02, 2012 at 07:54:04PM +0000, Paul Vixie wrote: > this doesn't work at the moment, even when there's code on the stub that > supports it, which is rare and experimental.
DNSSEC Trigger mostly works for me. It even has a "hotel sign on" mode, and it probes for all the failure modes you're talking about. > if ietf hadn't declared the dns protocol finished, and were not even now > working to close up the dnsext working group, i'd propose that we > develop a standard for carrying edns over tcp/80 and/or tcp/443, which > is for most mobile users what "the internet" consists of. There is nothing at all that prevents someone from getting together a BoF session in order to set up such a protocol effort. If you think you can get the interest, hold such a BoF. DNSEXT is closing because what you're talking about is not DNS, but a new protocol that looks kinda like DNS but runs on a different port. So's mDNS. But that aside, > i'm not sure how we expect DANE to make any difference when we don't > have working last mile DNSSEC. I don't think this is the problem at all. The problem is that even if you can get that out at the end point (and I can, using DNSSEC Trigger), it does you no good because your application _can't tell_ what happened. If I'm a web browser programmer, I want to be able to know whether the DNSSEC validation worked before I start using the TLSA record. Today, that is too much work (and probably reduces to "implement a resolver in the browser"). Best, A -- Andrew Sullivan [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
