TSIG signed Updates

[Mark Andrews]

> 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