On Tue, Jun 19, 2018 at 2:51 PM 神明達哉 wrote:
> At Mon, 18 Jun 2018 17:51:26 -0400,
> Shumon Huque wrote:
>
> > Client applications delegate address sorting to name resolution functions
> > like getaddrinfo() - correct?
> >
> > Doing some quick tests of getaddrinfo() just now on a recent *NIX
> ma
On Tue, Jun 19, 2018 at 2:51 PM 神明達哉 wrote:
> At Mon, 18 Jun 2018 17:51:26 -0400,
> Shumon Huque wrote:
>
> > Client applications delegate address sorting to name resolution functions
> > like getaddrinfo() - correct?
> >
> > Doing some quick tests of getaddrinfo() just now on a recent *NIX
> ma
At Mon, 18 Jun 2018 17:51:26 -0400,
Shumon Huque wrote:
> Client applications delegate address sorting to name resolution functions
> like getaddrinfo() - correct?
>
> Doing some quick tests of getaddrinfo() just now on a recent *NIX machine,
> it appears to return addresses sorted roughly in acc
Florian Weimer wrote:
* Paul Vixie:
in other words we should re-order rrsets by default, so that very few
people or agents are ever prone to think their order is stable. the spec
says they are unordered, but human nature says, expect more of what
you're seeing.
But the client has to sort t
On Mon, Jun 18, 2018 at 7:05 PM Darcy Kevin (FCA)
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
Monday, June 18, 2018 4:23 AM
To: Erik Nygren ; dnsop WG
Subject: Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on
bind 9.12 bug (sorting rrsets by default)
On 06/15/2018 05:45 PM, Erik Nygren wrote:
> I suspect starting assumptions are roughly in the range of:
>
On Mon, Jun 18, 2018 at 5:14 PM Florian Weimer wrote:
> * Paul Vixie:
>
> > in other words we should re-order rrsets by default, so that very few
> > people or agents are ever prone to think their order is stable. the spec
> > says they are unordered, but human nature says, expect more of what
>
* Paul Vixie:
> in other words we should re-order rrsets by default, so that very few
> people or agents are ever prone to think their order is stable. the spec
> says they are unordered, but human nature says, expect more of what
> you're seeing.
But the client has to sort them again based on
to the extent that the dns technical community has a choice about
default behaviour, we should consider the costs to the rest of the
internet community of each default.
in my prior e-mail to this thread i gave examples of assumptions of
ordering that were violated by the first round-robin impl
On Fri, Jun 15, 2018 at 04:17:00PM -0400, Erik Nygren wrote:
> We have many years of software that relies on emergent behaviors from the
> current default.
Well, I think more accurately we have years of software that relies on
emergent behaviours of the prior default of certain implemnetations.
>
On 06/15/2018 05:45 PM, Erik Nygren wrote:
I suspect starting assumptions are roughly in the range of:
* Recursive (and stub?) resolvers (SHOULD/MUST?) do some form of
round-robin in RRset responses.
* There are a variety of ways to implement round-robin (randomize,
permute, etc).
* Server
On 16 Jun 2018, at 2:14, Shumon Huque wrote:
Yeah, good point about side channels. Let's stick to recommending
randomization!
Unbound has interesting middle ground here:
rrset-roundrobin:
If yes, Unbound rotates RRSet order in response (the
random number is taken from
On Fri, Jun 15, 2018 at 8:12 PM, Shumon Huque wrote:
> On Fri, Jun 15, 2018 at 6:40 PM Mark Andrews wrote:
>
>> What we should be asking is why a service that needs multiple machines
>> isn’t using SRV. It has randomisation between servers explicitly defined
>> along with proportional load balan
Yeah, good point about side channels. Let's stick to recommending
randomization!
Shumon.
On Fri, Jun 15, 2018 at 8:01 PM Colm MacCárthaigh wrote:
>
> I think so too; and I wouldn't be so strict on backwards compatibility
> there.
>
> That behavior is a side-channel that defeats DNS privacy in s
On Fri, Jun 15, 2018 at 6:40 PM Mark Andrews wrote:
> What we should be asking is why a service that needs multiple machines
> isn’t using SRV. It has randomisation between servers explicitly defined
> along with proportional load balancing.
>
That would be nice, but sadly major applications lik
I think so too; and I wouldn't be so strict on backwards compatibility
there.
That behavior is a side-channel that defeats DNS privacy in some cases.
E.g. I can query a record, watch you send an encrypted query, then query
the record again, and tell what you queried. Within some probability at
lea
On Fri, Jun 15, 2018 at 5:55 PM Colm MacCárthaigh wrote:
>
> Just a question on this: was the old/classic behavior really
> random/shuffled? Or was it that bind would "rotate" through iterations
> where the order was the same each time if you think of the rrset list as a
> ring, but with a differ
What we should be asking is why a service that needs multiple machines isn’t
using SRV. It has randomisation between servers explicitly defined along with
proportional load balancing.
It also addresses CNAME at the apex which quite frankly is only used to find
the name of the HTTP server for t
Just a question on this: was the old/classic behavior really
random/shuffled? Or was it that bind would "rotate" through iterations
where the order was the same each time if you think of the rrset list as a
ring, but with a different start and end point within that ring? (That's
what's described he
Erik Nygren wrote:
...
This ambiguity in the current specifications results in this
mismatch between the pedantic (rrsets are explicitly unordered, and a
consistent order is a subset of that) and the current reality
(applications and services rely on resolvers-at-scale to be
explicitly incons
On Fri, Jun 15, 2018 at 04:17:00PM -0400, Erik Nygren wrote:
> Software should have safe defaults that matches common expectations.
> Those common expectations, as demonstrated by the configuration of all
> of the large public resolvers I've tested, as well as by how common
> software behaves,
I a
On Fri, Jun 15, 2018 at 3:52 PM, Mukund Sivaraman wrote:
> On Fri, Jun 15, 2018 at 02:38:00PM -0400, Bob Harold wrote:
> > Round-robin is a documented feature that many applications use. Removing
> > it from DNS resolvers, and then having to add it to a much larger number
> of
> > applications,
On Fri, Jun 15, 2018 at 02:38:00PM -0400, Bob Harold wrote:
> Round-robin is a documented feature that many applications use. Removing
> it from DNS resolvers, and then having to add it to a much larger number of
> applications, does not seem like a good trade-off.
The _default_ in BIND 9.12 was
> On Jun 15, 2018, at 2:01 PM, Peter van Dijk
> wrote:
>
> Hello Andrew,
>
> On 15 Jun 2018, at 19:12, Andrew Sullivan wrote:
>
>> I believe that RRsets are unordered sets by definition. So I supect
>> that if people are relying on the order in which they come off the
>> wire, they're makin
On Fri, Jun 15, 2018 at 2:28 PM Shumon Huque wrote:
> On Fri, Jun 15, 2018 at 1:13 PM Andrew Sullivan
> wrote:
>
>> On Fri, Jun 15, 2018 at 11:45:19AM -0400, Erik Nygren wrote:
>> > A number of folks have been bitten by a bug in bind 9..12 where it
>> silently
>> > changes the default sorting of
On Fri, Jun 15, 2018 at 1:13 PM Andrew Sullivan
wrote:
> On Fri, Jun 15, 2018 at 11:45:19AM -0400, Erik Nygren wrote:
> > A number of folks have been bitten by a bug in bind 9..12 where it
> silently
> > changes the default sorting of rrsets to always be sorted (even if the
> > authoritative resp
Hello Andrew,
On 15 Jun 2018, at 19:12, Andrew Sullivan wrote:
> I believe that RRsets are unordered sets by definition. So I supect
> that if people are relying on the order in which they come off the
> wire, they're making a mistake.
This. One hundred million times, this.
Kind regards,
--
P
Andrew Sullivan wrote:
On Fri, Jun 15, 2018 at 11:45:19AM -0400, Erik Nygren wrote:
A number of folks have been bitten by a bug in bind 9..12 where it silently
changes the default sorting of rrsets to always be sorted (even if the
authoritative response wasn't sorted).
I believe that RRsets
On Fri, Jun 15, 2018 at 11:45:19AM -0400, Erik Nygren wrote:
> A number of folks have been bitten by a bug in bind 9..12 where it silently
> changes the default sorting of rrsets to always be sorted (even if the
> authoritative response wasn't sorted).
I believe that RRsets are unordered sets by d
Erik Nygren wrote:
> A number of folks have been bitten by a bug in bind 9.12 where it silently
> changes the default sorting of rrsets to always be sorted (even if the
> authoritative response wasn't sorted).
Huh, I noticed this and put the workaround in my config but I didn't
realise it counte
> On Jun 15, 2018, at 11:45 AM, Erik Nygren wrote:
>
> A number of folks have been bitten by a bug in bind 9..12 where it silently
> changes the default sorting of rrsets to always be sorted (even if the
> authoritative response wasn't sorted). This causes problems for services
> assuming a
A number of folks have been bitten by a bug in bind 9.12 where it silently
changes the default sorting of rrsets to always be sorted (even if the
authoritative response wasn't sorted). This causes problems for services
assuming at least some degree of round-robin behavior by clients as now
many cl
32 matches
Mail list logo
