Keep getting NOTAUTH with nsupdate TSIG

[Kevin Darcy]

Just to confuse matters, the original (RFC 2136) meaning of NOTAUTH was
"Not Authoritative", i.e. the server is not authoritative for the zone
which is sought to be updated, but the TSIG RFC (2845) appears to have
*re-interpreted* (or simply misunderstood) NOTAUTH to mean "Not
Authorized", and uses it as a catch-all or "major" error code, wherein the
TSIG error code (as opposed to the RCODE) is then a "minor" error code,
which gives more detailed information as to the exact cause of the error,
e.g. a time error, an unrecognized key, failure of signature validation,
etc.

Unfortunately, "nsupdate", even though it "supports" TSIG, doesn't show you
the TSIG error code even in debug mode, so you just have to basically
_guess_ what the error really was, all the while remembering that in some
contexts, NOTAUTH means "Not Authoritative", and in others, "Not
Authorized". What a mess.


- Kevin

Jim Reid wrote:

> >>>>> "Daniel" == Daniel Bodea <dali at dali-designs.com> writes:
>
>     Daniel> Is TSIG authentication REALLY implemented in bind 8.2p7?
>
> If you meant 8.2.2P7, then yes, TSIG is really implemented. Be sure
> that the hosts using TSIG have their clocks synchronised. There are
> timestamps in the Transaction Signatures to prevent reply attacks. If
> the clocks are out by "too much", the TSIGs will fail to verify.
>
>     Daniel> Without TSIG, everything works just fine. With TSIG, no
>     Daniel> matter what I do, i keep getting NOTAUTH in the debug
>     Daniel> sequence of nsupdate. I KNOW I'm authoritative for the
>     Daniel> zone and I KNOW the configs are good.
>
> Well why not show them here so another pair of eyes can check them?
> And if you could post extracts from the name server logs,that would be
> helpful too. So would the actual error message printed by nsupdate.
>
> BTW, although you say "KNOW you're authoritative for the zone", the
> NOTAUTH reply from the name server suggests otherwise. The name server
> is saying it's not authoritative for the zone and it *really* knows
> for sure about that. :-)
>
> Here's what RFC2136 has to say about the NOTAUTH error code:
>
>               NOTAUTH     9       The server is not authoritative for
>                                   the zone named in the Zone Section.
>
>    ....
>
>    3.1.1. The Zone Section is checked to see that there is exactly one
>    RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to the
>    requestor.  Next, the ZNAME and ZCLASS are checked to see if the zone
>    so named is one of this server's authority zones, else signal NOTAUTH
>    to the requestor.
>
> It might be an idea to check the name server logs and find out why
> it's not authoritative. Maybe there's a syntax error in the zone file
> or else you're trying to update some other zone that the server isn't
> master for.