Proper use of keyid in allow-transfer
Folks,
Came across usage of a keyid as an address list in a
allow-transfer option on a older server site. Didn't really know that was
legal. It seemed an easier way to allow zone transfers without constantly
updating a list of IP addresses on a master server. The only trouble - it
didn't seem to actually work?
We've been trying it in a older lab server running a Solaris
9.9.9-S4 version of bind. The master has:
options {
allow-transfer {key bongo; 192.168.1.1};
};
key "bongo" {
algorithm hmac-md5;
secret "BippityBop";
};
The slave server defines the same key and is located at
192.168.1.1. When we use the above on the master, transfers for any zone work
fine. If we remove the IP address and try a transfer we get 'denied'. What
are we missing? Thought we might have to associate the keyid with zones on the
slave, but couldn't find any options for that??? We don't use TSIG on these
servers.
Thanks for the help!
John
John Murtari - jm5...@att.com
Ciberspring
office: 315-944-0998
cell: 315-430-2702
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Proper use of keyid in allow-transfer
On 7 December 2017 at 07:41, MURTARI, JOHN wrote:
>
>
> The slave server defines the same key and is located at
> 192.168.1.1. When we use the above on the master, transfers for any zone
> work fine. If we remove the IP address and try a transfer we get
> ‘denied’. What are we missing? Thought we might have to associate the
> keyid with zones on the slave, but couldn’t find any options for that??? We
> don’t use TSIG on these servers.
>
The keys you've defined above are TSIG keys, so yes you're using TSIG–or
trying to at any rate. :)
I'm going to assume you're creatively redacting your key data, and that it
isn't actually "BippityBop", because that isn't a valid hmac-md5 hash.
You don't include your slave config, so I'll point out a couple of common
errors there you can look for:
1) the keys must have not only the same secret, but also the same name on
both the master and slave
2) make sure you've got a server{} clause on the slave which tells it to
use the key when speaking to that server. And note that server{} is a
root-level directive in BIND... it doesn't go inside the options{} block.
For example, if your master is 192.168.1.2, your slave needs:
server 192.168.1.2 {
keys { bongo; };
};
Alternatively, there's a config syntax for specifying the key to use on a
per-zone basis by adding it to each server in the masters list in a slave
zone definition. I think the TSIG section of the BIND ARM (Administrator
Reference Manual) discusses that, and for sure the zone syntax description
will.
If it's not one of those things, then I'd suggest you include a more
complete configuration in your next email (from both sides), possibly with
some log entries showing the failed zone transfer attempts (also from both
sides).
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC / Include a subdomain's KSK data, ZSK data or both in parent domain?
Hello list members.
I use the following configuration for a domain-subdomain pair:
zone "example.com" IN {
type master;
file "pri/example.com.zone";
auto-dnssec maintain;
inline-signing yes;
};
zone "subdom.example.com" IN {
type master;
file "pri/subdom.example.com.zone";
auto-dnssec maintain;
inline-signing yes;
};
As you can see, I specified automatic maintenance for both zones, and I
have included DS records for both the subdomain's key-signing key and
zone-signing key, freshly generated today, in example.com.zone. DNSSEC
verfication succeeds with this setup. However, with BIND's automatic
maintenance, I am not quite sure if this will change over time.
Would it be sufficient/advisable to include only the subdomain's KSK
data in the parent domain's zone file and remove ZSK data, or do I need
to keep both?
-Ralph
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC / Include a subdomain's KSK data, ZSK data or both in parent domain?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralph,
I run a site with a similar arrangement of parent and child zones on
the same signing server with "auto-dnssec maintain" and
"inline-signing yes".
My research found that only DS records for the child zone's KSK(s)
needed to be put into the parent zone. I was very happy to find
DNSViz (http://dnsviz.net) confirmed that for me.
BIND 9.11.x did not automatically do that for my configuration, so my
automated scripts take care of it for me.
On 12/7/2017 10:45 AM, Ralph Seichter wrote:
> Hello list members.
>
> I use the following configuration for a domain-subdomain pair:
>
> zone "example.com" IN { type master; file "pri/example.com.zone";
> auto-dnssec maintain; inline-signing yes; };
>
> zone "subdom.example.com" IN { type master; file
> "pri/subdom.example.com.zone"; auto-dnssec maintain; inline-signing
> yes; };
>
> As you can see, I specified automatic maintenance for both zones,
> and I have included DS records for both the subdomain's key-signing
> key and zone-signing key, freshly generated today, in
> example.com.zone. DNSSEC verfication succeeds with this setup.
> However, with BIND's automatic maintenance, I am not quite sure if
> this will change over time.
>
> Would it be sufficient/advisable to include only the subdomain's
> KSK data in the parent domain's zone file and remove ZSK data, or
> do I need to keep both?
>
> -Ralph
>
> ___ Please visit
> https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
- --
Douglas C. Stephens | Network Systems Analyst
Enterprise Information Services | Phone: (515) 294-6102
Ames Laboratory, US DOE | Email: steph...@ameslab.gov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
iEYEARECAAYFAlops6kACgkQ46phdn656QS0oACg4o0RCs8X64MmLK/KFgmzTfIy
CZAAoPV7tmYISvBWlanRwL/rdmejpVAC
=gvgE
-END PGP SIGNATURE-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
[Question] zone transfer issue with multiple views
Hi all, I wonder if anyone can help me find the cause of the problem I am currently having. I am testing BIND with two views - internal, external. Everything seems okay except for one thing - zone transfer doesn't look happening for reverse zone for external view. On my slave server, I can see the following log message: 08-Dec-2017 10:55:59.247 general: info: zone 0.20.172.in-addr.arpa/IN/external: refresh: unexpected rcode (NXDOMAIN) from master 192.168.0.7#53 (source 0.0.0.0#0) Servers are using TSIG for zone transfer. It looks like zone transfer itself working for all other zones except for reverse zone for external view. Could I please get help if possible? I am using Debian Jessie and BIND was installed from its repository. I am willing to post BIND configurations if needed. Thanks a lot. Eoin Kim Systems Administrator RCS Telecommunications Level 1 - The Annexe 133 Mary Street Brisbane, QLD, 4000 Office: 07 3228 0843 Mobile: 0419 726 231 [RCST logo drop shadow] ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
