Erik Kline <ek=40google....@dmarc.ietf.org> wrote: > On Wed, 12 Sep 2018 at 15:38, Shane Kerr <sh...@time-travellers.org> wrote: > > > > Note that we can also use the RTT of this query to set a reasonable > > timeout for our port 853 traffic. A DNS server administrator may have > > configured port 853 support, but the network administrator may block > > this port for portions of the network or may later block this port. So > > we still need probing and a timeout - but it can be quite low in most cases.
Right, there will need to be some careful client-side engineering. > One thing a client might do with a positive TA bit and failed > connections to 853 is present that information to the user and ask for > confirmation they'd still like to use the network. That might be > useful, or might lead to confusion, idk. Seems worth trying, though. Yes, the TA bit will (inevitably) sometimes be wrong. My idea is that during the rollout phase it is probably worth having a TA bit so resolvers can avoid probing 853 when it is definitely futile. If TA=1 and 853 doesn't work then it'll probably be slower to resolve that server's domains, which is about the right level of breakage. (TA is a hint not a security feature.) > > I don't follow why the registries need to be involved with DANE for > > DNS-over-TLS any more than they do with HTTP-over-TLS or SMTP-over-TLS. > > Can you maybe try to explain more? The reason for wanting to include the NS targets' TLSA records in the glue is so that the resolver can immediately connect over DoT with authentication, without having to spend time chasing down TLSA records from below the zone cut. It would be a performance optimization. To some extent it also closes a privacy leak since it makes it easier for the resolver to query the child zone's servers without exposing which child zone it is asking about. > Exposing my considerable ignorance here (as usual), but can a TLSA > record be added for the in-addr.arpa/ip6.arpa name of a given > nameserver IP? Possibly... I think it was the DoH session at IETF 101 where a bunch of people got up to say that it's futile to expect the reverse DNS to be useful. It is perhaps less of a disaster area for mail server and maybe DNS server IP addresses. But it's shaky territory. The advantage in this context is that it might allow us to work around the problem of authoritative servers with lots of different names in NS targets. You could authenticate DoT to the server regardless of name by putting the TLSA record in the reverse DNS. Another disadvantage is that it might be a bit slow, because you can't look up the reverse DNS TLSA until after you have got the address records (rather than being able to look them up concurrently). On the gripping hand, since we can't include TLSA records in glue, the choice is between a followup query to get the TLSA records from the child zone, or from the reverse DNS, so the performance difference boils down to how quickly the resolver can iterate down the reverse DNS. Perhaps it makes sense to search for TLSA in both forward and reverse? Tony. -- f.anthony.n.finch <d...@dotat.at> http://dotat.at/ Fisher: West, backing southwest later, 5 to 7, occasionally gale 8 at first. Moderate or rough. Showers later. Good. _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
