Information leakage via update prereqs (was: Consistent error message in named.log )

[Paul Vixie]

Chris Thompson <cet1 at hermes.cam.ac.uk> writes:

> > Also prerequisites are processed before any acls according to RFC 2136
> > which is why you see these even when updates are denied for everyone.
> 
> That is, section 3.3 comes after section 3.2. But the RFC seems not to
> provide justifcation as to why the authorisation check must not be done
> earlier.

the editor slipped up.  there had been a request to move authorization to
be earlier in the flow, but it didn't get changed and the lack of a fix
wasn't noticed during WGLC.

> The result is that update attempts can be used to find out some details of
> zones to which the requestor does not have query access. (I experimented
> with a zone with "allow-query{none;};".) By seeing whether the return code
> is {Y,N}X{DOMAIN,RRSET} rather than REFUSED, a client can see whether a
> domain name exists, if so whether it has RRs of a particular type, if so
> whether they (collectively) do or do not match some guessed values.
> 
> This doesn't seem a very serious security issue, but it gives me an uneasy
> feeling.

yes.
-- 
Paul Vixie