Keep getting NOTAUTH with nsupdate TSIG

[Daniel Bodea]

I DID IT!!!!!!!!!!!!!!!!!!!!!!!!!!!!
You're a life saver!

There are some thing that should be pointed out though. First of all, the
NOTAUTH error is not really Not Authoritative. All I did was sync the dates
on the servers and all the errors disappeared. That means probably that
NOTAUTH means Not Authenticated or Not Authorised as I recall from the RFCs
as I have read them about a week ago cause I really do not see the
connection to the first description. Second, it may have been clear to a lot
of people but it wasn't to me, that the key on the client must have the same
name as the one on the server. That really blew me off the tracks for a
couple of hours.
That's about all I can remember right now but I'll be sure to share with you
any stuff that I may find, as I am pretty sure you'd do the same :)

A+ from the heart of Paris.
Daniel


"Jim Reid" <jim at rfc1035.com> a écrit dans le message news:
92su4b$q9g at pub3.rc.vix.com...
> >>>>> "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.
>
>
>
>