On Tuesday, June 19, 2018 01:21 CEST, Shumon Huque <shu...@gmail.com> wrote: 
 
> On Mon, Jun 18, 2018 at 7:05 PM Darcy Kevin (FCA) <kevin.da...@fcagroup.com>
> wrote:
> 
> > RFC 6724 specifically says: "Rules 9 and 10 MAY be superseded if the
> > implementation has other
> > means of sorting destination addresses. For example, if the
> > implementation somehow knows which destination addresses will result
> > in the 'best' communications performance."
> >
> > So, technically, if an implementation chooses a method of "the exact order
> > in which I received the address records from my upstream resolver" as a way
> > to produce the "'best' communication performance", given the circumstances,
> > then that is technically not a violation of the standard. The local
> > optimization is to trust the upstream resolver to Do The Right Thing. It's
> > not always a wise choice, but most of the time it's better than sorting
> > based on prefix-length matching (right?)
> >
> > RFC 6724 is, after all, about *default* address selection (that word is
> > even in the title of the RFC). Defaults are made to be superseded -- that's
> > kind of the definition of what a default *is*.
> >
> 
> This whole thread is about "defaults"  though!
> 
> Application deployers attempting to rely (rightly or wrongly) on load
> balancing of addresses presented by name resolution APIs will have
> preferences for a particular default that allows them to achieve that goal.
> 
> (I'm well aware that the spec allows and that OSes provide knobs to tweak
> the address selection algorithm - I've lost track of how many times I've
> edited my gai.conf file to do various kinds of tests!)

Hello dnsop,

I believe that discussion about protocol level/resolver behavior is going to be
purely academic because DoH is going to cache whole messages and that's it.

Do you think that having different behavior on "classic" DNS and DoH is a good 
idea?

-- 
Petr Špacek  @  CZ.NIC

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to