14 Čen
2016
14 Čen
'16
19:06
On 14/06/2016 14:30, Daniel Salzman wrote:
> On 06/14/2016 02:21 PM, Roger Murray wrote:
>> On 13Jun, 2016, at 19:39 , Anand Buddhdev<anandb(a)ripe.net> wrote:
>>> I am seeing a response from a knot name server that I am working on
>>> that has me a little confused. When I do zone transfer requests
>>> from clients that aren’t allowed to do a zone transfer I expect to
>>> receive rcode 5 REFUSED, but I am receiving rcode 9 NOTAUTH.
>>
>> The REFUSED rcode is generally used to indicate that a server isn't
>> carrying the zone you queried for.
>>
>> However, when a server does have a zone loaded, and can answer
>> queries for it, but just won't allow zone transfers, then NOTAUTH
>> is the right response, meaning "I have the zone, but I won't XFR it
>> to you”.
>
> I am digging through the RFC’s and I interpret them to as saying the
> exact opposite. As far as I can tell the REFUSED rcode is a refusal
> based on policy (RFC1035) and then that NOTAUTH rcode is that the
> nameserver isn’t authoritive for the queried zone (RFC2136). I am
> finding mixed implementation in the wild and was wondering what the
> knot developers based the implementation decision on.
>>>
>>> Is this the expected behaviour? Is this configurable?
>>
>> Yes it is expected behaviour, and as far as I know, it's not
configurable.
As far as I know, the meaning of NOTAUTH depends on the context
(see
http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml).
So NOTAUTH is used here for "Not Authorized"
(RFC3845).
Hi,
RFC1035 explicitely states on page 26 that rcode 5 (REFUSED) may be used
to reject a zone transfer request.
Refused - The name server refuses to
perform the specified operation for
policy reasons. For example, a name
server may not wish to provide the
information to the particular requester,
or a name server may not wish to perform
a particular operation (e.g., zone
transfer) for particular data.
On the other hand, rcode 9 mnemonic is missing a letter to qualify the
exact meaning. RFC2136 (DDNS) clearly states that it means "not
authoritative" (page 5)
NOTAUTH 9 The server is not authoritative
for
the zone named in the Zone Section.
Still, RFC2845 overrides this definition. The rcode is used when the key
name, the algorithm of the signature is invalid (page 6).
At this point the keyed message digest operation is
performed. If the
algorithm name or key name is unknown to the recipient, or if the
message digests do not match, the whole DNS message MUST be
discarded. If the message is a query, a response with RCODE 9
(NOTAUTH) MUST be sent back to the originator with TSIG ERROR 17
(BADKEY) or TSIG ERROR 16 (BADSIG).
That is actually an authentication problem, and the complete mnemonic
should have been NOTAUTHN. I have no clue as to why the IANA registered
"Not authorized" (i.e. "NOTAUTHZ"), which is not mentionned anywhere
in
the RFC: my ctrl+f "authoriz" returned no result.
As a result, my thoughts are that a zone transfer rejected because of a
lack of TSIG/SIG(0)/whatever-valid-authentication-procedure could be
answered with rcode 9 (NOTAUTH(N)) or rcode 5 (REFUSED). A zone transfer
rejected because of an IP filter should be answered with rcode 5 (REFUSED).
Of course, RFCs, DNS, interpretations :o)
Cheers,
Florian