Re: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records

[Ben Roberts]

Hi all,

I think I've gotten to the bottom of this and fortunately it was
misunderstanding on my part rather than an error in either piece of
software. I incorrectly thought the local bind masters were serving up
the DS record from within the child zone when queried, but they were
of course serving up the records from the parent zone. Had I been
delegating the child zone to a different physical server, this would
have been more obvious to me.

I was expecting the external slave to serve up DS records for my
signed zone, but it doesn't because the zone does not contain the DS
records for itself and so they are not transferred via AXFR; and
because the external was not authoritative for the parent zone so
didn't return them from there either. Not being a recursive resolve, I
now realise the external slave will never respond with any DS records
for this zone.

Finally, in my example zone with child delegation, the DS records for
the delegated zone ARE correctly included in the AXFR of the parent
and I was mistaken in thinking they were not. I am not yet replicating
these to the external slave so was basing my understanding of what was
happening based on the AXFR results alone. Had I been able to
replicate these to the slave, I would have spotted my mistake when
getting back DS records from the parent zone.

Thanks for your time and apologies for my confusion!

Ben

On 10 February 2017 at 06:51, Martin Basti <mba...@redhat.com> wrote:
> Hello,
>
> I'm not sure how your DNS data are structured, but usually (properly) DS 
> record is located in parent zone, so AXFR for subdomain.exmale.com should not 
> return DS record, but AXFR for example.com should return DS record of 
> subdomain.example.com.
>
> Martin
>
> - Original Message -
> From: "Ben Roberts" <m...@benroberts.net>
> To: "Tomas Krizek" <tkri...@redhat.com>
> Cc: freeipa-users@redhat.com
> Sent: Thursday, February 9, 2017 10:53:38 AM
> Subject: Re: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records
>
> Hi Tomas,
>
>> when I add a DS record to LDAP (without any DNSSEC configuration),
>> it is included in my AXFR transfer. I'm using bind-dyndb-ldap-10.1.
>>
>> I suppose you have DNSSEC configured. Could you be affected by the
>> limitations mentioned in [1]?
>
> Yes, dnssec is otherwise fully configured (the only bit I don't yet
> have is the DS records for the "example.local" parent domain
> registered upstream, but that shouldn't have any impact here. I don't
> think the linked limitations apply, I'm not attempting to use the CDS
> or CDNSKEY record types, and am manually specifying the DS records for
> the child zone.
>
> This is with bind 9.11 and bind-dyndb-ldap 11.0.
>
> Regards,
> Ben Roberts
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records

[Ben Roberts]

Hi Tomas,

> If I understand you correctly, the primary server is filled with data
> using bind-dyndb-ldap from an LDAP backend. Then the DS records are
> present on the primary server. At this point, bind-dyndb-ldap's work
> should be done, since it only serves as the backend LDAP driver for BIND.

You understand correctly.

> The issue happens when you try to replicate the zone to the secondary
> nameserver using AXFR. This leads me to believe that this might be some
> issue in the BIND component itself. Perhaps some special configuration
> is required.

I've not found any documentation that suggests special configuration
is required. I spoke to some of the people in #bind before posting to
this list, they were also surprised it wasn't working.

> It might help you if you'd test the setup without bind-dyndb-ldap with
> some mock data directly in BIND. If the AXFR doesn't contain the DS
> records then, it's related to BIND. Perhaps the BIND users
> (bind-us...@lists.isc.org) list might be able to assist you.

I've setup the test case directly on one of the primary nameservers
with a couple of domains and do see the DS glue records included in
the AXFR, so the missing records seem to only be happening when the
zonefile is backed by bind-dyndb-ldap.

Regards,
Ben Roberts

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records

[Tomas Krizek]

On 02/10/2017 08:42 AM, Ben Roberts wrote:
> Hi Martin,
>
>> I'm not sure how your DNS data are structured, but usually (properly)
>> DS record is located in parent zone, so AXFR for
>> subdomain.exmale.com should not return DS record, but AXFR
>> for example.com should return DS record of
>> subdomain.example.com.
> Herein lies the problem. The nameservers are authoritative for both
> the parent and child zones, and both are replicated from the primaries
> to the secondary nameserver. The DS glue records for the child zone
> contained within the parent zone are not being replicated across to
> the secondary via AXFR. Thus there is a complete chain for DNSSEC
> trust when queries are directed at the primaries, but not when queries
> are directed at the secondary nameserver.
>
> This affects both the DS glue records, and also the apex DS records
> which don't need to be present, but which bind-dyndb-ldap makes
> available automatically anyway. I raise this not because it's needed,
> but it might be relevant to identifying where the root cause is.
>
> Regards,
> Ben Roberts
If I understand you correctly, the primary server is filled with data
using bind-dyndb-ldap from an LDAP backend. Then the DS records are
present on the primary server. At this point, bind-dyndb-ldap's work
should be done, since it only serves as the backend LDAP driver for BIND.

The issue happens when you try to replicate the zone to the secondary
nameserver using AXFR. This leads me to believe that this might be some
issue in the BIND component itself. Perhaps some special configuration
is required.

It might help you if you'd test the setup without bind-dyndb-ldap with
some mock data directly in BIND. If the AXFR doesn't contain the DS
records then, it's related to BIND. Perhaps the BIND users
(bind-us...@lists.isc.org) list might be able to assist you.

-- 
Tomas Krizek




signature.asc
Description: OpenPGP digital signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records

[Ben Roberts]

Hi Martin,

> I'm not sure how your DNS data are structured, but usually (properly)
> DS record is located in parent zone, so AXFR for
> subdomain.exmale.com should not return DS record, but AXFR
> for example.com should return DS record of
> subdomain.example.com.

Herein lies the problem. The nameservers are authoritative for both
the parent and child zones, and both are replicated from the primaries
to the secondary nameserver. The DS glue records for the child zone
contained within the parent zone are not being replicated across to
the secondary via AXFR. Thus there is a complete chain for DNSSEC
trust when queries are directed at the primaries, but not when queries
are directed at the secondary nameserver.

This affects both the DS glue records, and also the apex DS records
which don't need to be present, but which bind-dyndb-ldap makes
available automatically anyway. I raise this not because it's needed,
but it might be relevant to identifying where the root cause is.

Regards,
Ben Roberts

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records

[Martin Basti]

Hello, 

I'm not sure how your DNS data are structured, but usually (properly) DS record 
is located in parent zone, so AXFR for subdomain.exmale.com should not return 
DS record, but AXFR for example.com should return DS record of 
subdomain.example.com.

Martin

- Original Message -
From: "Ben Roberts" <m...@benroberts.net>
To: "Tomas Krizek" <tkri...@redhat.com>
Cc: freeipa-users@redhat.com
Sent: Thursday, February 9, 2017 10:53:38 AM
Subject: Re: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records

Hi Tomas,

> when I add a DS record to LDAP (without any DNSSEC configuration),
> it is included in my AXFR transfer. I'm using bind-dyndb-ldap-10.1.
>
> I suppose you have DNSSEC configured. Could you be affected by the
> limitations mentioned in [1]?

Yes, dnssec is otherwise fully configured (the only bit I don't yet
have is the DS records for the "example.local" parent domain
registered upstream, but that shouldn't have any impact here. I don't
think the linked limitations apply, I'm not attempting to use the CDS
or CDNSKEY record types, and am manually specifying the DS records for
the child zone.

This is with bind 9.11 and bind-dyndb-ldap 11.0.

Regards,
Ben Roberts

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records

[Ben Roberts]

Hi Tomas,

> when I add a DS record to LDAP (without any DNSSEC configuration),
> it is included in my AXFR transfer. I'm using bind-dyndb-ldap-10.1.
>
> I suppose you have DNSSEC configured. Could you be affected by the
> limitations mentioned in [1]?

Yes, dnssec is otherwise fully configured (the only bit I don't yet
have is the DS records for the "example.local" parent domain
registered upstream, but that shouldn't have any impact here. I don't
think the linked limitations apply, I'm not attempting to use the CDS
or CDNSKEY record types, and am manually specifying the DS records for
the child zone.

This is with bind 9.11 and bind-dyndb-ldap 11.0.

Regards,
Ben Roberts

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records

[Tomas Krizek]

On 02/08/2017 11:59 PM, Ben Roberts wrote:
> Hi all,
>
> This is a question more about bind-dyndb-ldap rather than freeipa, but
> I understand it's written/maintained by the freeipa project and so
> this might be the most appropriate place to ask. I have setup
> bind-dyndb-ldap to read some zones from openldap, with multiple
> nameservers acting as masters and one nameserver running as a slave
> via the usual notify/transfer mechanism. I'm not seeing any DS records
> transfer across to the slave nameserver, nor when I manually query the
> primaries with an AFXR request. This includes both the apex DS
> records, automatically generated by bind-dyndb-ldap, but more
> importantly the glue dSRecord objects for a delegated subdomain.
>
> I note that the dSRecord entries are present in
> /var/named/dyndb-ldap/$view/master/$zone/raw but not present in
> /var/named/dyndb-ldap/$view/master/$zone/signed.
>
> Example (domain name and ip addresses obfuscated, but all other fields
> are unmodified):
> $ dig +noall +answer DS subdomain.example.local @127.0.01
> subdomain.example.local.   600 IN  DS  38589 7 1
> 6C410EF5A47631FBA2C3BC295A90363EA86A1846
> subdomain.example.local.   600 IN  DS  38589 7 2
> 23E22A49BBF2AD0E3F4668CB4C0DB52EE60ACA4308C1DE002A47AD7B 99734334
>
> $ dig +noall +answer AXFR subdomain.example.local @127.0.0.1
> | head -n 1
> subdomain.example.local.   600 IN  SOA ns1.example.local.
> hostmaster.example.local. 2016050416 43200 3600 1209600 3600
>
> $ dig +noall +answer AXFR subdomain.example.local @127.0.0.1
> | grep '\bDS\b'
> $
>
> This behaviour doesn't seem right to me. I would expect the DS records
> to be transferred to the slaves as normal so that any glue records are
> correctly present on all nameservers. I can't see any references in
> the bind-dyndb-ldap wiki/readme or code comments that would explain DS
> records being treated specially, but please do correct me if I'm wrong.
>
> Regards,
> Ben Roberts
>
>
Hi,

when I add a DS record to LDAP (without any DNSSEC configuration), it is
included in my AXFR transfer. I'm using bind-dyndb-ldap-10.1.

I suppose you have DNSSEC configured. Could you be affected by the
limitations mentioned in [1]?

[1] -
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/OpenDNSSEC2BINDKeyStates#Limitationsmissingfeatures

-- 
Tomas Krizek



signature.asc
Description: OpenPGP digital signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] bind-dyndb-ldap, AXFR and DS records

[Ben Roberts]

Hi all,

This is a question more about bind-dyndb-ldap rather than freeipa, but I
understand it's written/maintained by the freeipa project and so this might
be the most appropriate place to ask. I have setup bind-dyndb-ldap to read
some zones from openldap, with multiple nameservers acting as masters and
one nameserver running as a slave via the usual notify/transfer mechanism.
I'm not seeing any DS records transfer across to the slave nameserver, nor
when I manually query the primaries with an AFXR request. This includes
both the apex DS records, automatically generated by bind-dyndb-ldap, but
more importantly the glue dSRecord objects for a delegated subdomain.

I note that the dSRecord entries are present in
/var/named/dyndb-ldap/$view/master/$zone/raw but not present in
/var/named/dyndb-ldap/$view/master/$zone/signed.

Example (domain name and ip addresses obfuscated, but all other fields are
unmodified):
$ dig +noall +answer DS subdomain.example.local @127.0.01
subdomain.example.local.   600 IN  DS  38589 7 1
6C410EF5A47631FBA2C3BC295A90363EA86A1846
subdomain.example.local.   600 IN  DS  38589 7 2
23E22A49BBF2AD0E3F4668CB4C0DB52EE60ACA4308C1DE002A47AD7B 99734334

$ dig +noall +answer AXFR subdomain.example.local @127.0.0.1 | head -n 1
subdomain.example.local.   600 IN  SOA ns1.example.local.
hostmaster.example.local. 2016050416 43200 3600 1209600 3600

$ dig +noall +answer AXFR subdomain.example.local @127.0.0.1 | grep '\bDS\b'
$

This behaviour doesn't seem right to me. I would expect the DS records to
be transferred to the slaves as normal so that any glue records are
correctly present on all nameservers. I can't see any references in the
bind-dyndb-ldap wiki/readme or code comments that would explain DS records
being treated specially, but please do correct me if I'm wrong.

Regards,
Ben Roberts
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project