13 Čen
2016
13 Čen
'16
19:09
Hello Everybody,
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.
Is this the expected behaviour? Is this configurable?
Best Regards,
/rog
knotd (Knot DNS), version 2.2.1 on Ubuntu 14.04 installed from .cz package
knot:
Installed: 2.2.1-1+trusty+1
Candidate: 2.2.1-1+trusty+1
Version table:
*** 2.2.1-1+trusty+1 0
500 http://ppa.launchpad.net/cz.nic-labs/knot-dns/ubuntu/ trusty/main amd64
Packages
13 Čen
13 Čen
19:39
New subject: receiving rcode 9 NOTAUTH when expecting rcode 5 REFUSED
On 13/06/16 19:09, Roger Murray wrote:
Hi Roger,
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".
Is this the expected behaviour? Is this configurable?
Yes it is expected behaviour, and as far as I know, it's not configurable.
Regards,
Anand
14 Čen
14 Čen
14:21
New subject: receiving rcode 9 NOTAUTH when expecting rcode 5 REFUSED
Hey Anand,
Thanks for the quick response.
Best regards,
/rog
On 13Jun, 2016, at 19:39 , Anand Buddhdev
<anandb(a)ripe.net> wrote:
On 13/06/16 19:09, Roger Murray wrote:
Hi Roger,
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.
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”. Is this the expected behaviour? Is this
configurable?
Yes it is expected behaviour, and as far as I know, it's not configurable.
Regards,
Anand 
14:30
New subject: receiving rcode 9 NOTAUTH when expecting rcode 5 REFUSED
Hi Roger,
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).
Regards,
Daniel
On 06/14/2016 02:21 PM, Roger Murray wrote:
Hey Anand,
Thanks for the quick response.
Best regards,
/rog
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
On 13Jun, 2016, at 19:39 , Anand Buddhdev
<anandb(a)ripe.net> wrote:
On 13/06/16 19:09, Roger Murray wrote:
Hi Roger,
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.
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”. Is this
the expected behaviour? Is this configurable?
Yes it is expected behaviour, and as
far as I know, it's not configurable.
Regards,
Anand 
19:06
New subject: receiving rcode 9 NOTAUTH when expecting rcode 5 REFUSED
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
3426
days inactive
3427
days old
4 comments
4 participants
participants (4)
-
Anand Buddhdev -
Daniel Salzman -
Florian Maury -
Roger Murray