Sam Wilson wrote:
In article <mailman.814.1268703621.21153.bind-us...@lists.isc.org>,
Gary Wallis <wgg1...@gmail.com> wrote:
Let's say I have this setup :
BIND 9.4 named.conf includes a master.zones file with the following:
...
zone "ns1.yourdomain.com" {
type master;
file "master/external/n/ns1.yourdomain.com.signed";
};
zone "ns2.yourdomain.com" {
type master;
file "master/external/n/ns2.yourdomain.com.signed";
};
zone "yourdomain.com" {
type master;
file "master/external/y/yourdomain.com.signed";
};
...
More background for question below:
The yourdomain.com is I gather the zone APEX for all featured zones
above. (Is this the correct use of the term APEX?)
"Parent", as Mark has already pointed out.
Got that :)
I would be nice to know what a zone apex is since what I have found on
the web so far is pretty self-referential.
I am learning via trial and error about transitioning from DNS to DNSSEC
and we have these child zones (is ns1.yourdomain.com really a child
zone, as regards the setup above?) that currently have precedence over
the parent zone yourdomain.com for conflicting A records. For example:
If
ns1 A 123.123.123.123
is placed in yourdomain.com zone.
Some nitpicking - I'm not a DNSSEC expert and I'm not commenting on that
part of your question. Including this record would normally be an
error. ns1.yourdomain.com is delegated into its own zone and the A
record should be in that zone, not in the parent zone.[1]
And a similar RR is placed in ns1.yourdomain.com zone, like:
ns1 IN A 10.0.0.1
If you place ns1 in the zone ns1.yourdomain.com then the name will be
ns1.ns1.yourdomain.com. If you force the name to be ns1.yourdomain.com
[2] then that A record should override the one in the parent zone (see
[1] again).
Good job! You spotted my error/typo the test setup actually is:
...
@ IN A 10.0.0.1
...
for ns1.yourdomain.com zone file
And named reloaded.
dig @localhost ns1.yourdomain.com A +short
will return 10.0.0.1, the parent A RR is ignored.
Correct - see above
Can't answer your DNSSEC queries, but I'm not sure if they're relevant
if you correct the above.
Regarding my main question:
How to delegate signing authority from parent yourdomain.com to child
ns1.yourdomain.com.
In this case in the same BIND configuration (same named daemon) as shown
above in the named.conf frag.
I also need to know if the initial zone signing has to be changed, i.e.
sign the parent and child zones differently etc.
It seems that I need to provide the child DS record from
dsset-ns1.yourdomain.com that was generated by dnssec-signzone when I
signed the child.
dsset-ns1.yourdomain.com contents:
ns1.yourdomain.com. IN DS 181 5 1
FD110AAAFAC8101DD8EC946FD5B62FDC9B012EA1
That would go in the yourdomain.com parent db file. But I imagine some
other steps are needed and I'm not sure what they are.
I am reading about DS records now. But if anyone has a short how-to (or
listing of bash commands) for this simple case that would be great.
I still have to setup a DNSSEC resolver to be able to test my "test"
auth DNS server. And will provide results and a how-to if I manage to
get this "internal" DNSSEC parent-child delegation working on my own.
Sam
[1] UNLESS ns1.yourdomain.com is also the name of one of the nameservers
for a child zone in which case that record would be a glue record which
would be valid in the parent zone. It would normally be superseded by
the corresponding A record in the child zone which is regarded as a more
trustworthy source of data. There are various ways by which a server for
the parent zone can learn the correct data from the child zone.
This is what I know from experience but have never seen written
anywhere. Thx!
[2] You can do that by using the @ sign in the LHS of the A RR, or by
using a fully qualified name (inflexible), or by using the $ORIGIN
directive, or by leaving the name blank at the head of the zone
(slightly risky). Of these @ is the one mostly recommended.
Good. We started using @ several year ago but did not know about all
these details and differences you mention.
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Thanks all!
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
