Query about tkey-gssapi-keytab and secure updates

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Query about tkey-gssapi-keytab and secure updates

Peter V

Hello Bind users,

Trying to extend my understanding about tkey-gssapi-keytab statement
and possibility to use multiple principal names in single keytab file

The use case is simple:
Merging to MS AD environments to single ISC BIND DNS server with secure updates using update-policy

For testing, I create two AD domains

  • test.local
  • test1.local

During multiple testing, it looks like that using 'tkey-gssapi-keytab' is not enough to verify properly secure updates
Let me details result of my example:

named.conf

options {
directory "/usr/local/etc/namedb/working";
listen-on {
"any";
};
pid-file "/var/run/named/pid";
tkey-gssapi-keytab "/usr/local/etc/namedb/working/keytab.krb5";
};

zone "test.local" {
type master;
file "/usr/local/etc/namedb/master/test.local";
update-policy {
grant "TEST.LOCAL" ms-self "." "ANY";
};
auto-dnssec maintain;
};
zone "test1.local" {
type master;
file "/usr/local/etc/namedb/master/test1.local";
update-policy {
grant "TEST1.LOCAL" ms-self "." "ANY";
};
auto-dnssec maintain;
};

keytab file is loaded and I can get TGT from AD for TEST.LOCAL

root@dns2:~ # ktutil -k /usr/local/etc/namedb/working/keytab.krb5 list
/usr/local/etc/namedb/working/keytab.krb5:

Vno Type Principal Aliases
9 arcfour-hmac-md5 DNS/[hidden email]
root@dns2:~ # kinit -k -t /usr/local/etc/namedb/working/keytab.krb5 DNS/[hidden email]
root@dns2:~ # klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: DNS/[hidden email]

Issued Expires Principal
Nov 4 23:28:05 2020 Nov 5 09:28:03 2020 krbtgt/[hidden email]
root@dns2:~ #

Possible challenge I see is that BIND does not use keytab file to compare GSS request with keytab;
I can see on debug 8 gss messages with failure 'No No kerberos credential available'

04-Nov-2020 23:29:04.945 client @0x803875000 10.0.110.207#61795 (612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): query: 612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592 IN TKEY -T (10.0.50.33)
04-Nov-2020 23:29:04.947 failed gss_inquire_cred: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_0).
04-Nov-2020 23:29:04.950 gss-api source name (accept) is AD207$@TEST.LOCAL
04-Nov-2020 23:29:04.951 process_gsstkey(): dns_tsigerror_noerror
04-Nov-2020 23:29:04.951 client @0x803875000 10.0.110.207#61795 (612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): send
04-Nov-2020 23:29:04.951 client @0x803875000 10.0.110.207#61795 (612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): sendto
04-Nov-2020 23:29:04.952 client @0x803875000 10.0.110.207#61795 (612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): senddone
04-Nov-2020 23:29:04.952 client @0x803875000 10.0.110.207#61795 (612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): next
04-Nov-2020 23:29:04.952 client @0x803875000 10.0.110.207#61795 (612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): endrequest
04-Nov-2020 23:29:04.952 client @0x803875000 10.0.110.207#61795: closetcp
04-Nov-2020 23:29:04.953 client @0x804c11000 10.0.110.207#61795: next
04-Nov-2020 23:29:04.953 client @0x804c11000 10.0.110.207#61795: request failed: end of file
04-Nov-2020 23:29:04.953 client @0x804c11000 10.0.110.207#61795: endrequest
04-Nov-2020 23:29:04.953 client @0x804c11000 10.0.110.207#61795: closetcp
04-Nov-2020 23:29:04.953 client @0x803bfa400 10.0.110.207#51833: UDP request
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833: using view '_default'
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833: request has valid signature: AD207\$\@TEST.LOCAL
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key AD207\$\@TEST.LOCAL: recursion available
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key AD207\$\@TEST.LOCAL: update
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': prerequisites are OK
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': update section prescan OK
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': deleting rrset at 'ad207.test.local' AAAA
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': deleting rrset at 'ad207.test.local' A
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': adding an RR at 'ad207.test.local' A 10.0.110.207
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': redundant request

but still update get in and is approved.

The same is accepted also for client from second domain - TEST1.LOCAL
Even I do not have keytab loaded with Principal Name from TEST1.LOCAL, update will get in

04-Nov-2020 23:31:39.879 client @0x803875000 10.0.110.216#59439 (932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): query: 932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2 IN TKEY -T (10.0.50.33)
04-Nov-2020 23:31:39.880 failed gss_inquire_cred: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_0).
04-Nov-2020 23:31:39.884 gss-api source name (accept) is AD206$@TEST1.LOCAL
04-Nov-2020 23:31:39.884 process_gsstkey(): dns_tsigerror_noerror
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439 (932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): send
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439 (932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): sendto
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439 (932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): senddone
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439 (932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): next
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439 (932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): endrequest
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439: closetcp
04-Nov-2020 23:31:39.885 client @0x804811a00 10.0.110.216#59439: next
04-Nov-2020 23:31:39.885 client @0x804811a00 10.0.110.216#59439: request failed: end of file
04-Nov-2020 23:31:39.885 client @0x804811a00 10.0.110.216#59439: endrequest
04-Nov-2020 23:31:39.885 client @0x804811a00 10.0.110.216#59439: closetcp
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407: UDP request
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407: using view '_default'
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407: request has valid signature: AD206\$\@TEST1.LOCAL
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key AD206\$\@TEST1.LOCAL: recursion available
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key AD206\$\@TEST1.LOCAL: update
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': prerequisites are OK
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': update section prescan OK
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': deleting rrset at 'ad206.test1.local' AAAA
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': deleting rrset at 'ad206.test1.local' A
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': adding an RR at 'ad206.test1.local' A 10.0.110.206
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': adding an RR at 'ad206.test1.local' A 10.0.110.216
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': redundant request
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key AD206\$\@TEST1.LOCAL: send

This update was not expected to get accepted.

=======================================

I did modification of test to include tkey-gssapi-credential
where I got more expected result

tkey-gssapi-credential "DNS/[hidden email]";

Update into main domain TEST.LOCAL shows sucessfull GSS

04-Nov-2020 23:35:12.167 client @0x803875000 10.0.110.207#60534: query
04-Nov-2020 23:35:12.167 client @0x803875000 10.0.110.207#60534 (612-ms-7.12-9a6b9d.7a3e8427-1ed6-11eb-438f-005056bd8592): query: 612-ms-7.12-9a6b9d.7a3e8427-1ed6-11eb-438f-005056bd8592 IN TKEY -T (10.0.50.33)
04-Nov-2020 23:35:12.168 gss cred: "DNS/[hidden email]", GSS_C_ACCEPT, 4294967295
04-Nov-2020 23:35:12.170 gss-api source name (accept) is AD207$@TEST.LOCAL
04-Nov-2020 23:35:12.170 process_gsstkey(): dns_tsigerror_noerror

with 2nd domain TEST1.LOCAL, ending in error

04-Nov-2020 23:36:07.223 client @0x804c11000 10.0.110.216#62340 (932-ms-7.53-192491b.2db42801-1eb9-11eb-d293-005056bddce2): query: 932-ms-7.53-192491b.2db42801-1eb9-11eb-d293-005056bddce2 IN TKEY -T (10.0.50.33)
04-Nov-2020 23:36:07.224 gss cred: "DNS/[hidden email]", GSS_C_ACCEPT, 4294967295
04-Nov-2020 23:36:07.224 failed gss_accept_sec_context: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Cannot find key for DNS/[hidden email] kvno 3 in keytab (request ticket server DNS/[hidden email]).
04-Nov-2020 23:36:07.224 process_gsstkey(): dns_tsigerror_badkey

where I understood that I apply explicitly 1 'security credential' to verify GSS;
Of course, update for TEST1.LOCAL is not valid for TEST.LOCAL Principal name

Other observation:

On my FreeBSD, I think BIND is caching Kerberos into

root@dns2:~ # ls -la /var/tmp/krb5_53.rcache2
-rw------- 1 bind wheel 13584 Nov 4 23:56 /var/tmp/krb5_0.rcache2

but log entry points to: /tmp/krb5cc_0


Making sum, my concern goes to:

  • is it expected to use single keytab file with multiple Principal Name authenticate clients from multiple domains?
    In case yes - did my I miss any configuration to be done or I hit area which is not covered

    In case no, we should be clear on documentation to point to single principal name to be used


Appreciate any feedback on this topic.


Best Regards,
Peter


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Query about tkey-gssapi-keytab and secure updates

Peter V
Hello all,

I send one more time my post as I realized that DMARC DNS record is not
friend for mailing lists
and failed to delivery for many domains.

I am trying to extend my understanding about tkey-gssapi-keytab
statement
and possibility to use multiple principal names in single keytab file

 From documentation:

tkey-gssapi-keytab
This is the KRB5 keytab file to use for GSS-TSIG updates.
If this option is set and tkey-gssapi-credential is not set,
updates are allowed with any key matching a principal in the specified
keytab.

1. tkey-gssapi-keytab
    Do I understand correctly that DNS server will allow any update after
received TKEY query matching Principal Name in my keytab file?
    Is there any verification of client and client's signature?
    I am not clear what would be usage if DNS server itself with not
perform any verification is GSS-TSIG signature
    Below test show details that even with failed 'failed
gss_inquire_cred' - Secure updates is accepted

2. Does this support multiple Principal Names in single keytab file?
    (I feel like should be the case, but I have unexpected result in my
test below

3. tkey-gssapi-credential
    I understand that only with this parameter DNS server will
authenticate keys exchange in handshake

    Does it imply that I can use only one Prinipal Name with GSS-TSIG?
    I do not see that option can be defined multiple times
    I understand that this parameter is not required anyway - [RT #22629]

4. Is there additional resources explaining overal GSS-TSIG handling?
    Reading C-code is not really my cup of cofee.

===================================================================================================================

Our test plan:

Merging to MS AD environments to single ISC BIND DNS server with secure
updates using update-policy

For testing, I create two AD domains (no domain trust at all)

* test.local
* test1.local

During multiple testing, it looks like that using 'tkey-gssapi-keytab'
is not enough to verify properly secure updates
Let me details result of my example:

named.conf

options {
directory "/usr/local/etc/namedb/working";
listen-on {
"any";
};
pid-file "/var/run/named/pid";
tkey-gssapi-keytab "/usr/local/etc/namedb/working/keytab.krb5";
};_

zone "test.local" {
type master;
file "/usr/local/etc/namedb/master/test.local";
update-policy {
grant "TEST.LOCAL" ms-self "." "ANY";
};
auto-dnssec maintain;
};
zone "test1.local" {
type master;
file "/usr/local/etc/namedb/master/test1.local";
update-policy {
grant "TEST1.LOCAL" ms-self "." "ANY";
};
auto-dnssec maintain;
};

keytab file is loaded and I can get TGT from AD for TEST.LOCAL

root@dns2:~ # ktutil -k /usr/local/etc/namedb/working/keytab.krb5 list
/usr/local/etc/namedb/working/keytab.krb5:

Vno Type Principal Aliases
9 arcfour-hmac-md5 DNS/[hidden email]
root@dns2:~ # kinit -k -t /usr/local/etc/namedb/working/keytab.krb5
DNS/[hidden email]
root@dns2:~ # klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: DNS/dns2.test.local@TEST.LOCAL_

Issued Expires Principal_
Nov 4 23:28:05 2020 Nov 5 09:28:03 2020 krbtgt/[hidden email]
root@dns2:~ #


Possible challenge I see is that BIND does not use keytab file to
compare GSS request with keytab;
I can see on debug 8 gss messages with failure 'No No kerberos
credential available'

04-Nov-2020 23:29:04.945 client @0x803875000 10.0.110.207#61795
(612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): query:
612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592 IN TKEY -T
(10.0.50.33)m
04-Nov-2020 23:29:04.947 failed gss_inquire_cred: GSSAPI error: Major =
Unspecified GSS failure. Minor code may provide more information, Minor
= No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_0).
04-Nov-2020 23:29:04.950 gss-api source name (accept) is
AD207$@TEST.LOCAL
04-Nov-2020 23:29:04.951 process_gsstkey(): dns_tsigerror_noerror
04-Nov-2020 23:29:04.951 client @0x803875000 10.0.110.207#61795
(612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): send
04-Nov-2020 23:29:04.951 client @0x803875000 10.0.110.207#61795
(612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): sendto
04-Nov-2020 23:29:04.952 client @0x803875000 10.0.110.207#61795
(612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): senddone
04-Nov-2020 23:29:04.952 client @0x803875000 10.0.110.207#61795
(612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): next
04-Nov-2020 23:29:04.952 client @0x803875000 10.0.110.207#61795
(612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): endrequest
04-Nov-2020 23:29:04.952 client @0x803875000 10.0.110.207#61795:
closetcp
04-Nov-2020 23:29:04.953 client @0x804c11000 10.0.110.207#61795: next
04-Nov-2020 23:29:04.953 client @0x804c11000 10.0.110.207#61795: request
failed: end of file
04-Nov-2020 23:29:04.953 client @0x804c11000 10.0.110.207#61795:
endrequest
04-Nov-2020 23:29:04.953 client @0x804c11000 10.0.110.207#61795:
closetcp
04-Nov-2020 23:29:04.953 client @0x803bfa400 10.0.110.207#51833: UDP
request
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833: using
view '_default'
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833: request
has valid signature: AD207\$\@TEST.LOCAL
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key
AD207\$\@TEST.LOCAL: recursion available
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key
AD207\$\@TEST.LOCAL: update
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key
AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': prerequisites are OK
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key
AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': update section
prescan OK
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key
AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': deleting rrset at
'ad207.test.local' AAAA
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key
AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': deleting rrset at
'ad207.test.local' A
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key
AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': adding an RR at
'ad207.test.local' A 10.0.110.207
04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key
AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': redundant request

but still update get in and is approved.

The same is accepted also for client from second domain - TEST1.LOCAL
Even I do not have keytab loaded with Principal Name from TEST1.LOCAL,
update will get in

04-Nov-2020 23:31:39.879 client @0x803875000 10.0.110.216#59439
(932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): query:
932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2 IN TKEY -T
(10.0.50.33)
04-Nov-2020 23:31:39.880 failed gss_inquire_cred: GSSAPI error: Major =
Unspecified GSS failure. Minor code may provide more information, Minor
= No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_0).
04-Nov-2020 23:31:39.884 gss-api source name (accept) is
AD206$@TEST1.LOCAL
04-Nov-2020 23:31:39.884 process_gsstkey(): dns_tsigerror_noerror
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439
(932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): send
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439
(932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): sendto
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439
(932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): senddone
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439
(932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): next
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439
(932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): endrequest
04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439:
closetcp
04-Nov-2020 23:31:39.885 client @0x804811a00 10.0.110.216#59439: next
04-Nov-2020 23:31:39.885 client @0x804811a00 10.0.110.216#59439: request
failed: end of file
04-Nov-2020 23:31:39.885 client @0x804811a00 10.0.110.216#59439:
endrequest
04-Nov-2020 23:31:39.885 client @0x804811a00 10.0.110.216#59439:
closetcp
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407: UDP
request
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407: using
view '_default'
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407: request
has valid signature: AD206\$\@TEST1.LOCAL
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: recursion available
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: update
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': prerequisites are
OK
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': update section
prescan OK
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': deleting rrset at
'ad206.test1.local' AAAA
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': deleting rrset at
'ad206.test1.local' A
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': adding an RR at
'ad206.test1.local' A 10.0.110.206
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': adding an RR at
'ad206.test1.local' A 10.0.110.216
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': redundant request
04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key
AD206\$\@TEST1.LOCAL: send

This update was not expected to get accepted.

=======================================

I did modification of test to include tkey-gssapi-credential
where I got more expected result

  tkey-gssapi-credential "DNS/[hidden email]";

Update into main domain TEST.LOCAL shows sucessfull GSS

04-Nov-2020 23:35:12.167 client @0x803875000 10.0.110.207#60534: query
04-Nov-2020 23:35:12.167 client @0x803875000 10.0.110.207#60534
(612-ms-7.12-9a6b9d.7a3e8427-1ed6-11eb-438f-005056bd8592): query:
612-ms-7.12-9a6b9d.7a3e8427-1ed6-11eb-438f-005056bd8592 IN TKEY -T
(10.0.50.33)
04-Nov-2020 23:35:12.168 gss cred: "DNS/[hidden email]",
GSS_C_ACCEPT, 4294967295
04-Nov-2020 23:35:12.170 gss-api source name (accept) is
AD207$@TEST.LOCAL
04-Nov-2020 23:35:12.170 process_gsstkey(): dns_tsigerror_noerror

with 2nd domain TEST1.LOCAL, ending in error

04-Nov-2020 23:36:07.223 client @0x804c11000 10.0.110.216#62340
(932-ms-7.53-192491b.2db42801-1eb9-11eb-d293-005056bddce2): query:
932-ms-7.53-192491b.2db42801-1eb9-11eb-d293-005056bddce2 IN TKEY -T
(10.0.50.33)
04-Nov-2020 23:36:07.224 gss cred: "DNS/[hidden email]",
GSS_C_ACCEPT, 4294967295
04-Nov-2020 23:36:07.224 failed gss_accept_sec_context: GSSAPI error:
Major = Unspecified GSS failure. Minor code may provide more
information, Minor = Cannot find key for DNS/[hidden email]
kvno 3 in keytab (request ticket server
DNS/[hidden email]).
04-Nov-2020 23:36:07.224 process_gsstkey(): dns_tsigerror_badkey

where I understood that I apply explicitly 1 'security credential' to
verify GSS;
Of course, update for TEST1.LOCAL is not valid for TEST.LOCAL Principal
name

Appreciate any feedback on this topic.

Best Regards,
Peter
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users