Antwort: [SPAM] Re: TSIG signed Updates

[holger.honert at signal-iduna.de]

Hi Mark,
thanks for your answer!

I have seen this in a captured trace between these two servers, that there 
was no additional record (TSIG Key) in the forwarded update. 

So if I get you right, there is no solution for my problem or what do I 
have to do for getting the slave signing the forwarded updates?

Would you (or someone else) please be so kind and explain me the section 
(maybe that's the solution?):

Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: REFUSED, id:   1138
;; flags: qr ra ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; TSIG PSEUDOSECTION:
dv.isc.org.key.         0       ANY     TSIG    hmac-md5.sig-alg.reg.int. 
1107437492 300 16 cAMnKq8kQWCuJKbGGAHBLw== 1138 NOERROR 0 

                 The slave does not sign the request when it forwards it.

                 The only thing the slave does is assign a transaction id,
                 from its own id space, so it can identify the reply.  The
                 original id is restored as it forwards the reply.  This 
is
                 why TSIG does not cover the transaction id.

                 The slave doesn't even need to know the TSIG being used 
to
                 authenticate the transaction.

                 Mark


Kind Regards/Freundlichen Gruß
 
Holger Honert
 
KOMN-97851
 
SIGNAL IDUNA Gruppe
Joseph-Scherer-Str. 3
 
44139 Dortmund
 
Phone: +49 231/135-4043
FAX: +49 231/135-2959
 
mailto: holger.honert at signal-iduna.de






Mark Andrews <Mark_Andrews at isc.org>
Gesendet von: Mark_Andrews at isc.org
03.02.2005 14:46
 
An:           holger.honert at signal-iduna.de
Kopie:        bind-users at isc.org
Thema:        [SPAM] Re: TSIG signed Updates



> Hi out there,
> for more securing dynamic updates that are forwarded via my secondary 
> nameserver (172.17.111.30) using the allow-update-forwarding statement, 
> these updates (should) be signed with a TSIG-Key.
> Unfortunately this does not work in my configuration. Every time I make 
an 
> update I get an an REFUSE and the primary nameserver (172.27.100.12) 
says 
> update denied in the log-file.
> 
> The key seems alright, because it is used for axfr with no problems.
> 
> Here is the sec. DNS config.:
> 
> key tsig-key {
>         algorithm hmac-md5;
>         secret "my-secret";
> };
> 
> server 172.27.100.12 {
>         keys { tsig-key ; };
> };
> 
> zone "nwf.local" in {
>         type slave;
>         file "secondary/db.nwf.local";
>         masters { 172.27.100.12;};
>         allow-update-forwarding { 127.0.0.1; ddns; };
> };
> 
> the pri. config:
> 
> key tsig-key {
>         algorithm hmac-md5;
>         secret "my secret";
> };
> 
> server 172.17.111.30 {
>         keys {
>                 tsig-key ;};
>         };
> 
> zone "nwf.local" {
>         type master;
>         file "primary/db.nwf.local";
>         allow-query {
>                 any;
>                 };
>         allow-transfer {
>                 key tsig-key;
>                 };
>         update-policy {
>                 grant dhcp-key-1 wildcard *.nwf.local. A TXT;
>                 grant tsig-key wildcard *.nwf.local. ANY;
>                 };
>         notify yes;
>         check-names ignore;
>         };
> 
> 
> The output from nsupdate:
> 
> > update add test1234.nwf.local. 1234 IN A 1.2.3.4
> > 
> Reply from SOA query:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id:  34852
> ;; flags: qr aa rd ra ; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, 
ADDITIONAL: 
> 0
> ;; QUESTION SECTION:
> ;test1234.nwf.local.            IN      SOA
> 
> ;; AUTHORITY SECTION:
> nwf.local.              0       IN      SOA     ns.nwf.local. 
> dnsadmin.signal-iduna.net. 189 1800 1800 604800 38400
> 
> 
> Found zone name: nwf.local
> The master is: ns.nwf.local
> 
> Reply from update query:
> ;; ->>HEADER<<- opcode: UPDATE, status: REFUSED, id:   8817
> ;; flags: qr ra ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
> 
> > 
> 
> output named.log from the primary:
> 
> 03-Feb-2005 09:48:05.248 update-security: error: client 
> 172.17.111.30#32905: update 'nwf.local/IN' denied
> 
> Where am I wrong?

                 You didn't sign your update request.  If you had you 
would
                 have got a response with a TSIG.  This was for a valid 
key
                 that was not allowed to update.

Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: REFUSED, id:   1138
;; flags: qr ra ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; TSIG PSEUDOSECTION:
dv.isc.org.key.         0       ANY     TSIG    hmac-md5.sig-alg.reg.int. 
1107437492 300 16 cAMnKq8kQWCuJKbGGAHBLw== 1138 NOERROR 0 

                 The slave does not sign the request when it forwards it.

                 The only thing the slave does is assign a transaction id,
                 from its own id space, so it can identify the reply.  The
                 original id is restored as it forwards the reply.  This 
is
                 why TSIG does not cover the transaction id.

                 The slave doesn't even need to know the TSIG being used 
to
                 authenticate the transaction.

                 Mark
 
> TIA!
> 
> Kind Regards/Freundlichen Gruß
> 
> Holger Honert
> 
> KOMN-97851
> 
> SIGNAL IDUNA Gruppe
> Joseph-Scherer-Str. 3
> 
> 44139 Dortmund
> 
> Phone: +49 231/135-4043
> FAX: +49 231/135-2959
> 
> mailto: holger.honert at signal-iduna.de
> 
> 
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org