DNSSEC and child zones on same authoritative NS. Expert help needed.

[Gary Wallis]

Sam Wilson wrote:
> In article <mailman.814.1268703621.21153.bind-users at lists.isc.org>,
>  Gary Wallis <wgg1970 at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 

Thanks all!