Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie <[e-mail]>]

Matthew Pounsett wrote:
> ... I have seen no similar discussion of REFUSED-generated chaos in
> recursive servers.   If someone is seeing such brokenness, they
> haven't brought it to dnsop@, or dns-operations@, or an OARC or NANOG
> meeting.  If someone is seeing such brokenness, hopefully they'll
> speak up so that we can advise the authoritative
> implementations to change their behaviour again.

are you sure they'd be here listening, and that they would even 
understand the errors they are experiencing and connect those errors to 
this protocol change?

> ... but it does seem to be the consensus among the
> authoritative implementors that REFUSED is the correct response.

are you sure they aren't just copying BIND's behaviour? do you remember 
when BIND only included one RR per message in outbound AXFR, and that 
there were some AXFR initiators that depended on this behaviour since 
they had never witnessed any other behaviour and hadn't read the spec?

and how do you know about that consensus -- or do you mean a consensus 
among those present on this mailing list who have chosen to speak up?

> ... It wouldn't be the first time that a majority of implementations
> settled on a behaviour that didn't strictly follow the specification
> because it was necessary for good inter-operation.

i have seen no discussion, here or anywhere else, about necessity, or 
good interoperation, regarding this apparent departure from the spec. 
can you include a URI where i can study further? in other words, who 
argues for this, and on what basis?

when we change a protocol on an existing signal path, we have a burden 
of do-no-harm to existing implementations who will never be changed. 
this burden is even higher when re-purposing existing signalling. if 
it's possible to have interpreted the old signal in some way, then we 
have to treat our change as "bearing a cost".

> ... Perhaps someone who was present for an implementer's internal
> discussion about replacing upward referrals could comment on the
> reasoning, and what (if any) collaboration occurred between the
> authoritative and recursive implementations at the time.

i'd hope to see not only this, but someone currently participating in 
this discussion who can explain why an upward referral is a good signal. 
no query initiator should follow such a referral, but some may, which 
i'd view as a calamity. if the goal is some initiator reaction that is 
not what they would do if they heard SERVFAIL, then what is that goal?

-- 
P Vixie