Re: tkey-gssapi-credential
At Fri, 1 Oct 2010 07:05:40 -0600, Nicholas F Miller wrote: > > It is interesting, when I try an update from a client all I get are > denies. When I try an update using nsupdate -g from the DNS server I > will get a REFUSED but I will also get a DNS/h...@domain kerb ticket > from the keytab. It might be worth watching the Kerberos (UDP port 88) traffic during both exchanges, to see if there are visible differences. Basic capture of Kereberos can tell you a fair amount about principals, realms, and algorithm negotiations. tshark's -K option lets you load keytabs, which in theory might let you peer deeper into the packet, but I've never experimented with that option and don't know if it's useful in this scenario. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: tkey-gssapi-credential
That is how I created my keytab as well. It is interesting, when I try an update from a client all I get are denies. When I try an update using nsupdate -g from the DNS server I will get a REFUSED but I will also get a DNS/h...@domain kerb ticket from the keytab. _ Nicholas Miller, ITS, University of Colorado at Boulder On Sep 30, 2010, at 4:00 PM, Rob Austein wrote: > Sorry, I spent most of the last two weeks locked in a conference room > and mostly off net, still catching up. > > At Mon, 27 Sep 2010 07:54:54 -0600, Nicholas F Miller wrote: >> >> DNS Standard query TKEY >> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e >> Queries >> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, >> class IN >> Additional records >> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, >> class ANY >> Algorithm name: gss-tsig >> Signature inception: Sep 27, 2010 07:26:04.0 Mountain >> Daylight Time >> Signature expiration: Sep 28, 2010 07:26:04.0 Mountain >> Daylight Time >> Mode: GSSAPI >> GSS-API Generic Security Service Application Program Interface >> OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation) >> Simple Protected Negotiation >> negTokenInit >> mechTypes: 3 items >> MechType: 1.2.840.48018.1.2.2 (MS KRB5 - >> Microsoft Kerberos 5) >> MechType: 1.2.840.113554.1.2.2 (KRB5 - >> Kerberos 5) >> MechType: 1.2.840.113554.1.2.2.3 (KRB5 - >> Kerberos 5 - User to User) >> krb5_blob: >> KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - >> Kerberos 5) >> Kerberos AP-REQ >> Realm: >> Server Name (Service and Instance): >> DNS/ >> >> DNS Standard query response TKEY >> Queries >> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, >> class IN >> Answers >> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, >> class ANY >> Algorithm name: gss-tsig >> Signature inception: Dec 31, 1969 17:00:00.0 Mountain >> Standard Time >> Signature expiration: Dec 31, 1969 17:00:00.0 Mountain >> Standard Time >> Mode: GSSAPI >> Error: Bad key > > The nameserver appears to be rejecting the GSSAPI negotiation due to > some basic failure, there are too many possibilities (all of which the > protocol lumps into "BADKEY", sigh) to guess which. In theory named > should have logged something like "failed gss_accept_sec_context: > blah" where "blah" is the output of gss_error_tostring(); if there > really is no such message (ie, it's not just lost under all the > noise), this may indicate that you're somehow getting an "impossible" > GSSAPI failure, ie, something that we don't ever expect to fail, so > we're handling it via a RETERR() wrapper around an API call, or > something like that (in which case said error clearly is not > "impossible" and probably needs to be handled differently). > > The timestamps in the response is just the Unix epoch. I don't recall > offhand whether that's what TKEY is supposed to return in this mode if > there's no signature, but if not this would be consistent with the > theory that something is erroring out early in processing. > > FWIW, here's the ktpass incantation that's worked for me in the past: > > C:\> ktpass -out foo.keytab -princ DNS/foo.example@example.org -pass * > -mapuser f...@example.org > > where "foo.keytab" is the filename for the new keytab, > "DNS/foo.example@example.org" is the principal name, and > "f...@example.org" is the Active Directory user account. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: tkey-gssapi-credential
Sorry, I spent most of the last two weeks locked in a conference room and mostly off net, still catching up. At Mon, 27 Sep 2010 07:54:54 -0600, Nicholas F Miller wrote: > > DNS Standard query TKEY > 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e >Queries >472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, > class IN >Additional records >472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, > class ANY >Algorithm name: gss-tsig >Signature inception: Sep 27, 2010 07:26:04.0 Mountain > Daylight Time >Signature expiration: Sep 28, 2010 07:26:04.0 Mountain > Daylight Time >Mode: GSSAPI >GSS-API Generic Security Service Application Program Interface >OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation) >Simple Protected Negotiation >negTokenInit >mechTypes: 3 items >MechType: 1.2.840.48018.1.2.2 (MS KRB5 - > Microsoft Kerberos 5) >MechType: 1.2.840.113554.1.2.2 (KRB5 - > Kerberos 5) >MechType: 1.2.840.113554.1.2.2.3 (KRB5 - > Kerberos 5 - User to User) >krb5_blob: >KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - > Kerberos 5) >Kerberos AP-REQ >Realm: >Server Name (Service and Instance): > DNS/ > > DNS Standard query response TKEY >Queries >472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, > class IN >Answers >472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, > class ANY >Algorithm name: gss-tsig >Signature inception: Dec 31, 1969 17:00:00.0 Mountain > Standard Time >Signature expiration: Dec 31, 1969 17:00:00.0 Mountain > Standard Time >Mode: GSSAPI >Error: Bad key The nameserver appears to be rejecting the GSSAPI negotiation due to some basic failure, there are too many possibilities (all of which the protocol lumps into "BADKEY", sigh) to guess which. In theory named should have logged something like "failed gss_accept_sec_context: blah" where "blah" is the output of gss_error_tostring(); if there really is no such message (ie, it's not just lost under all the noise), this may indicate that you're somehow getting an "impossible" GSSAPI failure, ie, something that we don't ever expect to fail, so we're handling it via a RETERR() wrapper around an API call, or something like that (in which case said error clearly is not "impossible" and probably needs to be handled differently). The timestamps in the response is just the Unix epoch. I don't recall offhand whether that's what TKEY is supposed to return in this mode if there's no signature, but if not this would be consistent with the theory that something is erroring out early in processing. FWIW, here's the ktpass incantation that's worked for me in the past: C:\> ktpass -out foo.keytab -princ DNS/foo.example@example.org -pass * -mapuser f...@example.org where "foo.keytab" is the filename for the new keytab, "DNS/foo.example@example.org" is the principal name, and "f...@example.org" is the Active Directory user account. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: tkey-gssapi-credential
.
>> = Use Session Key: Do NOT use the session key to encrypt the ticket
>> ..1.
>> = Mutual required: MUTUAL authentication is REQUIRED
>> Ticket
>> Tkt-vno: 5
>> Realm:
>> Server Name (Service and Instance):
>> DNS/
>> Name-type: Service and Instance (2)
>> Name: DNS
>> Name:
>> enc-part rc4-hmac
>> Encryption type: rc4-hmac (23)
>> Kvno: 3
>> enc-part:
>> 29653f6457b51106240db14316c9ffef0f40e58852cf7a59...
>> Authenticator rc4-hmac
>> Encryption type: rc4-hmac (23)
>> Authenticator data:
>> 6b4d26e823ca79be98fa558115020ef589b859088566b9a3...
>> Other Size: 0
>>
>> 7344 161.605703DNS Standard query response
>> TKEY
>> ...
>> Queries
>> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY,
>> class IN
>> Name: 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e
>> Type: TKEY (Transaction Key)
>> Class: IN (0x0001)
>> Answers
>> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY,
>> class ANY
>> Name: 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e
>> Type: TKEY (Transaction Key)
>> Class: ANY (0x00ff)
>> Time to live: 0 time
>> Data length: 26
>> Algorithm name: gss-tsig
>> Signature inception: Dec 31, 1969 17:00:00.0 Mountain
>> Standard Time
>> Signature expiration: Dec 31, 1969 17:00:00.0 Mountain
>> Standard Time
>> Mode: GSSAPI
>> Error: Bad key
>> Key Size: 0
>> Other Size: 0
>>
>> The named.conf contains an update-policy like this:
>>
>> options {
>> ...
>> tkey-gssapi-credential "DNS/";
>> tkey-domain "";
>> }
>>
>> update-policy {
>> grant ms-self * A;
>> };
>>
>> Any ideas? Have I missed something obvious?
>> _
>> Nicholas Miller, ITS, University of Colorado at Boulder
>>
>>
>>
>> On Sep 17, 2010, at 11:08 PM, Rob Austein wrote:
>>
>>> At Fri, 17 Sep 2010 13:18:42 -0600, Nicholas F Miller wrote:
>>>>
>>>> Does anyone have instructions on how to setup a Linux bind server to
>>>> use GSS-TSIG against an AD? I have found many articles from people
>>>> having issues with it but none that had good instructions on how to
>>>> get it working. Last year we played around with it but were having
>>>> issues getting it to work. kinit would work against the AD on our
>>>> RHEL bind server but our clients couldn't update their records.
>>>
>>> Beyond what's already been posted here? Not really. I can perhaps
>>> tell you two things that might be useful.
>>>
>>> 1) The code really does work, honest. I have personally seen it work
>>> (in the lab -- my last stint as an operator supporting anything on
>>> Windows predated AD) with Windows 2000, Windows 2003 Server, and
>>> Windows XP. I have not (yet) personally tested it with anything
>>> more recent than that, but unless Microsoft has done something
>>> weird (nah) it still should.
>>>
>>> 2) If you run into problems, the best debugging tools I can recommend
>>> are:
>>>
>>> a) Running named with full debugging ("named -g" and capture the
>>>stderr output somewhere, or do the equivalent with logging
>>>options in named.conf); and
>>>
>>> b) A good packet sniffer watching both DNS and Kerberos traffic.
>>>
>>> For (b) I recommend Wireshark (or tshark, same difference). You
>>> can use some other tool (eg, tcpdump) to capture the dump, but
>>> understanding what happened requires an analyzer that do deep
>>> insepction of both DNS and Kerberos. Make sure you capture full
>>> packets for both Kerberos and DNS, ie, UDP ports 88 and 53 as well
>>> as TCP port 53 (Yes, Windows uses all three).
>>> ___
>>> bind-users mailing list
>>> bind-users@lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>> ___
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: tkey-gssapi-credential
4-hmac (23)
> Authenticator data:
> 6b4d26e823ca79be98fa558115020ef589b859088566b9a3...
> Other Size: 0
>
> 7344 161.605703DNS Standard query response
> TKEY
> ...
> Queries
> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY,
> class IN
> Name: 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e
> Type: TKEY (Transaction Key)
> Class: IN (0x0001)
> Answers
> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY,
> class ANY
> Name: 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e
> Type: TKEY (Transaction Key)
> Class: ANY (0x00ff)
> Time to live: 0 time
> Data length: 26
> Algorithm name: gss-tsig
> Signature inception: Dec 31, 1969 17:00:00.00000 Mountain
> Standard Time
> Signature expiration: Dec 31, 1969 17:00:00.0 Mountain
> Standard Time
> Mode: GSSAPI
> Error: Bad key
> Key Size: 0
> Other Size: 0
>
> The named.conf contains an update-policy like this:
>
> options {
> ...
> tkey-gssapi-credential "DNS/";
> tkey-domain "";
> }
>
> update-policy {
> grant ms-self * A;
> };
>
> Any ideas? Have I missed something obvious?
> _
> Nicholas Miller, ITS, University of Colorado at Boulder
>
>
>
> On Sep 17, 2010, at 11:08 PM, Rob Austein wrote:
>
>> At Fri, 17 Sep 2010 13:18:42 -0600, Nicholas F Miller wrote:
>>>
>>> Does anyone have instructions on how to setup a Linux bind server to
>>> use GSS-TSIG against an AD? I have found many articles from people
>>> having issues with it but none that had good instructions on how to
>>> get it working. Last year we played around with it but were having
>>> issues getting it to work. kinit would work against the AD on our
>>> RHEL bind server but our clients couldn't update their records.
>>
>> Beyond what's already been posted here? Not really. I can perhaps
>> tell you two things that might be useful.
>>
>> 1) The code really does work, honest. I have personally seen it work
>> (in the lab -- my last stint as an operator supporting anything on
>> Windows predated AD) with Windows 2000, Windows 2003 Server, and
>> Windows XP. I have not (yet) personally tested it with anything
>> more recent than that, but unless Microsoft has done something
>> weird (nah) it still should.
>>
>> 2) If you run into problems, the best debugging tools I can recommend
>> are:
>>
>> a) Running named with full debugging ("named -g" and capture the
>> stderr output somewhere, or do the equivalent with logging
>> options in named.conf); and
>>
>> b) A good packet sniffer watching both DNS and Kerberos traffic.
>>
>> For (b) I recommend Wireshark (or tshark, same difference). You
>> can use some other tool (eg, tcpdump) to capture the dump, but
>> understanding what happened requires an analyzer that do deep
>> insepction of both DNS and Kerberos. Make sure you capture full
>> packets for both Kerberos and DNS, ie, UDP ports 88 and 53 as well
>> as TCP port 53 (Yes, Windows uses all three).
>> ___
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: tkey-gssapi-credential
Signature inception: Dec 31, 1969 17:00:00.0 Mountain
Standard Time
Signature expiration: Dec 31, 1969 17:00:00.0 Mountain
Standard Time
Mode: GSSAPI
Error: Bad key
Key Size: 0
Other Size: 0
The named.conf contains an update-policy like this:
options {
...
tkey-gssapi-credential "DNS/";
tkey-domain "";
}
update-policy {
grant ms-self * A;
};
Any ideas? Have I missed something obvious?
_
Nicholas Miller, ITS, University of Colorado at Boulder
On Sep 17, 2010, at 11:08 PM, Rob Austein wrote:
> At Fri, 17 Sep 2010 13:18:42 -0600, Nicholas F Miller wrote:
>>
>> Does anyone have instructions on how to setup a Linux bind server to
>> use GSS-TSIG against an AD? I have found many articles from people
>> having issues with it but none that had good instructions on how to
>> get it working. Last year we played around with it but were having
>> issues getting it to work. kinit would work against the AD on our
>> RHEL bind server but our clients couldn't update their records.
>
> Beyond what's already been posted here? Not really. I can perhaps
> tell you two things that might be useful.
>
> 1) The code really does work, honest. I have personally seen it work
> (in the lab -- my last stint as an operator supporting anything on
> Windows predated AD) with Windows 2000, Windows 2003 Server, and
> Windows XP. I have not (yet) personally tested it with anything
> more recent than that, but unless Microsoft has done something
> weird (nah) it still should.
>
> 2) If you run into problems, the best debugging tools I can recommend
> are:
>
> a) Running named with full debugging ("named -g" and capture the
> stderr output somewhere, or do the equivalent with logging
> options in named.conf); and
>
> b) A good packet sniffer watching both DNS and Kerberos traffic.
>
> For (b) I recommend Wireshark (or tshark, same difference). You
> can use some other tool (eg, tcpdump) to capture the dump, but
> understanding what happened requires an analyzer that do deep
> insepction of both DNS and Kerberos. Make sure you capture full
> packets for both Kerberos and DNS, ie, UDP ports 88 and 53 as well
> as TCP port 53 (Yes, Windows uses all three).
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: tkey-gssapi-credential
At Fri, 17 Sep 2010 13:18:42 -0600, Nicholas F Miller wrote:
>
> Does anyone have instructions on how to setup a Linux bind server to
> use GSS-TSIG against an AD? I have found many articles from people
> having issues with it but none that had good instructions on how to
> get it working. Last year we played around with it but were having
> issues getting it to work. kinit would work against the AD on our
> RHEL bind server but our clients couldn't update their records.
Beyond what's already been posted here? Not really. I can perhaps
tell you two things that might be useful.
1) The code really does work, honest. I have personally seen it work
(in the lab -- my last stint as an operator supporting anything on
Windows predated AD) with Windows 2000, Windows 2003 Server, and
Windows XP. I have not (yet) personally tested it with anything
more recent than that, but unless Microsoft has done something
weird (nah) it still should.
2) If you run into problems, the best debugging tools I can recommend
are:
a) Running named with full debugging ("named -g" and capture the
stderr output somewhere, or do the equivalent with logging
options in named.conf); and
b) A good packet sniffer watching both DNS and Kerberos traffic.
For (b) I recommend Wireshark (or tshark, same difference). You
can use some other tool (eg, tcpdump) to capture the dump, but
understanding what happened requires an analyzer that do deep
insepction of both DNS and Kerberos. Make sure you capture full
packets for both Kerberos and DNS, ie, UDP ports 88 and 53 as well
as TCP port 53 (Yes, Windows uses all three).
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: tkey-gssapi-credential
Thanks, that will save me a bunch of time. Of course I spent my morning testing it out to no avail. Does anyone have instructions on how to setup a Linux bind server to use GSS-TSIG against an AD? I have found many articles from people having issues with it but none that had good instructions on how to get it working. Last year we played around with it but were having issues getting it to work. kinit would work against the AD on our RHEL bind server but our clients couldn't update their records. _ Nicholas Miller, ITS, University of Colorado at Boulder On Sep 17, 2010, at 12:54 PM, Rob Austein wrote: > At Fri, 17 Sep 2010 09:17:09 -0600, Nicholas F Miller wrote: >> >> I was wondering if it is possible to use the tkey-gssapi-credential >> and update-policy on a Windows install of bind. It strikes me that >> running bind on a Windows server, snapped into the AD it will serve >> DNS to, should be the easiest way of getting DDNS with update-policy >> control working. > > It would be, except for one small problem: the Windows native Kerberos > doesn't support GSS-API (or didn't, when last I checked), instead it > supports some similar-but-different Microsoft proprietary API whose > name has temporarily escaped my memory. So either we would have to > hack Windows-specific code here to use Microsoft's API, or we would > have to get a Unix-style Kerberos library working on Windows. > > We spent an insane amount of time banging our head against the latter > approach, but never got it to work, for reasons that never made a lot > of sense (eg, linking against precompiled MIT Kerberos binaries > resulted in binaries that worked fine for everything but GSS-TSIG but > failed silently for that, attempting to build MIT Kerberos for Windows > from source resulted in Kerberos code that couldn't even kinit, and > nobody on the MIT Kerberos project could tell us why). We eventually > gave up, because we had deadlines to meet and this configuration > (BIND9 running GSS-TSIG on Windows) wasn't on our critical feature > list. > >> Am I nuts? Should I just install it on a Linux box and be done? > > Yes, unless you (or some other brave soul) have the time and energy to > get this working on Windows, in which case please tell us what you did > (and i will stand you a beer if we ever meet...). > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: tkey-gssapi-credential
At Fri, 17 Sep 2010 09:17:09 -0600, Nicholas F Miller wrote: > > I was wondering if it is possible to use the tkey-gssapi-credential > and update-policy on a Windows install of bind. It strikes me that > running bind on a Windows server, snapped into the AD it will serve > DNS to, should be the easiest way of getting DDNS with update-policy > control working. It would be, except for one small problem: the Windows native Kerberos doesn't support GSS-API (or didn't, when last I checked), instead it supports some similar-but-different Microsoft proprietary API whose name has temporarily escaped my memory. So either we would have to hack Windows-specific code here to use Microsoft's API, or we would have to get a Unix-style Kerberos library working on Windows. We spent an insane amount of time banging our head against the latter approach, but never got it to work, for reasons that never made a lot of sense (eg, linking against precompiled MIT Kerberos binaries resulted in binaries that worked fine for everything but GSS-TSIG but failed silently for that, attempting to build MIT Kerberos for Windows from source resulted in Kerberos code that couldn't even kinit, and nobody on the MIT Kerberos project could tell us why). We eventually gave up, because we had deadlines to meet and this configuration (BIND9 running GSS-TSIG on Windows) wasn't on our critical feature list. > Am I nuts? Should I just install it on a Linux box and be done? Yes, unless you (or some other brave soul) have the time and energy to get this working on Windows, in which case please tell us what you did (and i will stand you a beer if we ever meet...). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
tkey-gssapi-credential
I was wondering if it is possible to use the tkey-gssapi-credential and update-policy on a Windows install of bind. It strikes me that running bind on a Windows server, snapped into the AD it will serve DNS to, should be the easiest way of getting DDNS with update-policy control working. Am I nuts? Should I just install it on a Linux box and be done? _ Nicholas Miller, ITS, University of Colorado at Boulder ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
tkey-gssapi-credential and tkey-domain
Can you set more than one Active Directory to use tkey-gssapi-
credential and tkey-domain in bind?
ie.
Two keytabs:
DNS/foo.example.org at AD1.EXAMPLE.ORG
DNS/foo.example.org at AD2.EXAMPLE.ORG
-- named.conf
-
[...]
options {
[...]
tkey-gssapi-credential "DNS/foo.example.org";
tkey-domain "AD1.EXAMPLE.ORG";
tkey-domain "AD2.EXAMPLE.ORG";
};
_
Nicholas Miller, ITS, University of Colorado at Boulder
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
