this is "selling past the close", an error we are all here oft guilty
of, but here i go anyway:
Andrew Sullivan wrote:
> IMO There is just an ambiguity in the RFCs, and I think it should be
> fixed.
yes. fundamentally, rrset ordering within answer sections needs
clarification. noone disagrees.
>
On Fri, Aug 14, 2015 at 07:45:09AM +1000, Mark Andrews wrote:
>
> RFC 1034 says to add to the answer. Not added to a list that will
> then be compiled into a answer with possible reordering once all
> the records have been collected.
But as I already pointed out upthread, Mark, "add" does not me
Hi Mark,
> > > why do you call a section a "set"?
> >
> > Because it isn't stated anywhere that they're not just a bag of
> > things that are added to, and `added' isn't `append'? It may seem
> > pedantic, but it has helped allow different interpretations to
> > spread over the years.
>
> RFC 103
In message <20150813133446.78c4228...@orac.inputplus.co.uk>, Ralph Corderoy wri
tes:
> Hi Paul,
>
> > >> "added" really does just mean "added" not "inserted".
> > >
> > > I don't know what that means. If you add something to an unordered
> > > set and then ask for the contents of the set, the or
神明達哉 wrote:
> At Wed, 12 Aug 2015 07:23:59 -0400,
> Andrew Sullivan wrote:
>
> > > So we are in agreement that glibc's stub resolver is acting really dumb
> > > here?
> >
> > I think that's overstating it. It appears that glibc implemented the
> > protocol according to a widely-held but (at lea
Hi Paul,
> >> "added" really does just mean "added" not "inserted".
> >
> > I don't know what that means. If you add something to an unordered
> > set and then ask for the contents of the set, the order you'll get
> > its contents is undefined.
>
> why do you call a section a "set"?
Because it
Hi G,
> How specific is the ordering dependency by resolver code variant? by
> version?
>
> If this becomes a candidate for typing specific resolvers, its useful
> knowledge
It varies quite a bit with the few I looked at, see
https://mailarchive.ietf.org/arch/msg/ietf/wdopuAP2ddLlQcdtX-iAWdUULZ8
In message <20150812185911.5b3e524...@orac.inputplus.co.uk>, Ralph Corderoy
writes:
> AIUI, forgetting SkyDNS exists, it's allowable for a stub resolver to be
> configured to talk to a server that can answer authoritatively for the
> CNAME and the A, thus some clarification may be needed.
Stub r
Hi Miek,
> So this discussion stems from this issue:
> https://github.com/skynetservices/skydns/issues/217
I deliberately didn't mention that so as to avoid getting into specifics
of one case when it clearly seems to be a more general issue. :-)
> And apparently the glibc resolver assume this i
Hi Andrew,
Andrew Sullivan wrote:
> > That still leaves open the question of whether the stub resolvers
> > can assume, as many have apparently been doing for years, that they
> > will be given CNAME before A.
...
> but I don't think there's any promise anywhere about what order the
> RRsets come
On Wed, Aug 12, 2015 at 11:23:22AM -0700, Paul Vixie wrote:
> why do you call a section a "set"?
I didn't mean to say that it _is_ one. I meant that nowhere is this
particularly clear, and there is a natural sense in which they are
sets because they hang together in some way relevant to what was
How specific is the ordering dependency by resolver code variant? by
version?
If this becomes a candidate for typing specific resolvers, its useful
knowledge
-G
On Wed, Aug 12, 2015 at 3:25 PM, Andrew Sullivan
wrote:
> On Wed, Aug 12, 2015 at 06:17:39PM +, Viktor Dukhovni wrote:
> > are or
On Wed, Aug 12, 2015 at 06:17:39PM +, Viktor Dukhovni wrote:
> are ordered so that in any chain of CNAMEs such as:
>
> A. IN CNAME B.
> B. IN CNAME C.
> ...
> L. IN CNAME M. ; logically *and* positionally last
>
> the last CNAME RR in the response is also the logicall
Andrew Sullivan wrote:
> On Wed, Aug 12, 2015 at 08:45:08AM -0700, Paul Vixie wrote:
>> section. "added" really does just mean "added" not "inserted".
>
> I don't know what that means. If you add something to an unordered
> set and then ask for the contents of the set, the order you'll get its
>
On Wed, Aug 12, 2015 at 01:59:55PM -0400, Andrew Sullivan wrote:
> The question, for the purposes of the protocol definition, is whether
> a message section (or maybe just the answer section) is an ordered set
> of unordered RRsets. If so, we probably ought to write that down
> somewhere, and spe
On Wed, Aug 12, 2015 at 08:45:08AM -0700, Paul Vixie wrote:
> section. "added" really does just mean "added" not "inserted".
I don't know what that means. If you add something to an unordered
set and then ask for the contents of the set, the order you'll get its
contents is undefined. Indeed, pe
At Wed, 12 Aug 2015 07:23:59 -0400,
Andrew Sullivan wrote:
> > So we are in agreement that glibc's stub resolver is acting really dumb
> > here?
>
> I think that's overstating it. It appears that glibc implemented the
> protocol according to a widely-held but (at least mostly) undocumented
> fe
On Aug 12 2015, Andrew Sullivan wrote:
On Wed, Aug 12, 2015 at 11:21:58AM +1000, Mark Andrews wrote:
RFC 3045 3.1.1. Including RRSIG RRs in a Response
I assume you meant 4035, but that section says absolutely nothing
about where in the section the RRSIG needs to go.
It is subliminally sug
Suresh Krishnaswamy wrote:
>> ...
>
> I suspect that it may also have to do, in part, with how the stub resolver
> performs its bailiwick checks. A cname target may be out of bailiwick if the
> alias has not come into view yet. Expecting the cname to precede the target
> could be an implementa
> On Aug 12, 2015, at 7:23 AM, Andrew Sullivan wrote:
>
> On Wed, Aug 12, 2015 at 07:27:53AM +0100, Miek Gieben wrote:
>> So we are in agreement that glibc's stub resolver is acting really dumb here?
>
> I think that's overstating it. It appears that glibc implemented the
> protocol according
On Wed, Aug 12, 2015 at 07:27:53AM +0100, Miek Gieben wrote:
> So we are in agreement that glibc's stub resolver is acting really dumb here?
I think that's overstating it. It appears that glibc implemented the
protocol according to a widely-held but (at least mostly) undocumented
feature of the p
On Wed, Aug 12, 2015 at 11:21:58AM +1000, Mark Andrews wrote:
>
> RFC 3045 3.1.1. Including RRSIG RRs in a Response
I assume you meant 4035, but that section says absolutely nothing
about where in the section the RRSIG needs to go.
> s/Add/Append/ and there is no dispute. I doubt anyone though
In message <20150812062753.gc15...@miek.nl>, Miek Gieben writes:
> [ Quoting in "Re: [DNSOP] Order of CNAME and A
> in..." ]
> >On Tue, Aug 11, 2015 at 08:12:20PM +0100, Miek Gieben wrote:
> >>
> >> So this discussion stems from this issue:
> >> https://github.com/skynetservices/skydns/issues/2
[ Quoting in "Re: [DNSOP] Order of CNAME and A in..."
]
On Tue, Aug 11, 2015 at 08:12:20PM +0100, Miek Gieben wrote:
So this discussion stems from this issue:
https://github.com/skynetservices/skydns/issues/217
And apparently the glibc resolver assume this is ordering is in effect.
I wond
In message <20150812004858.gl5...@mx2.yitter.info>, Andrew Sullivan writes:
> On Tue, Aug 11, 2015 at 08:12:20PM +0100, Miek Gieben wrote:
> >
> > So this discussion stems from this issue:
> > https://github.com/skynetservices/skydns/issues/217
> >
> > And apparently the glibc resolver assume t
On Tue, Aug 11, 2015 at 08:12:20PM +0100, Miek Gieben wrote:
>
> So this discussion stems from this issue:
> https://github.com/skynetservices/skydns/issues/217
>
> And apparently the glibc resolver assume this is ordering is in effect.
I wonder what it does if the RRSIG moves around. (Sorry,
[ Quoting in "Re: [DNSOP] Order of CNAME and A in..."
]
On Tue, Aug 11, 2015 at 05:00:05PM +0100, Ralph Corderoy wrote:
That still leaves open the question of whether the stub resolvers can
assume, as many have apparently been doing for years, that they will be
given CNAME before A.
In gener
On Tue, Aug 11, 2015 at 05:00:05PM +0100, Ralph Corderoy wrote:
> That still leaves open the question of whether the stub resolvers can
> assume, as many have apparently been doing for years, that they will be
> given CNAME before A.
In general, RRsets aren't ordered. Now, I think a CNAME respons
Hi Viktor,
> > Go implements its own resolver rather than use the local libc's,
> > e.g. glibc's. All of them are stub resolvers, yes, but if asked to
> > look up foo.bar.local and /etc/resolv.conf has only the
> > authoritative bar.local server in it then they get an authoritative
> > response
29 matches
Mail list logo
