Antwort: [SPAM] Re: TSIG signed Updates
Mark Andrews
Mark_Andrews at isc.org
Fri Feb 4 13:26:36 UTC 2005
> 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?
If you want to use TSIG/SIG(0) the update client has to
sign the update.
If you want to have the forwarded message signed by the
slave you will have to add code to named to do this. You
then would also have to deal with the issues of translating
TSIG errors between the slave and the master back into the
unsigned response that is sent to the client.
NOTAUTH is overloaded and the update client would not have
enough context to distiguish between the two error states.
> 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
>
>
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the bind-users
mailing list