Difference between delegation and forward zone

[Mik J via bind-users]

Hello,
I would like to check if my understanding is correct regarding delegation and 
forward
Delegation: I want to delegate the administrative tasks to someone else for one 
subdomainsubdomain1.mydomain.orgI'll specify the NS of that 
subdomain1.mydomain.org in my mydomain.org zone fileThe other person will be 
able to create rr1.subdomain1.mydomain.org
Forward zone: I can forward a specific zone to a DNS that is different from the 
default fowarders or I won't attempt to do an iterative lookup.
=> Question 1: Can I have a forward zone that is a subdomain 
subdomain1.mydomain.org ? Or when the zone is a subdomain of mydomain (I'm 
athoritative) it's always a delegation ?
=> Question 2: When I do a delegation, is it correct that the remote DNS server 
holding subdomain1.mydomain.org must always answer the SOA with SOA records and 
NS records (RFC 2181 chapter 6.1)
Regards

___
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: Difference between delegation and forward zone

[McDonald, Daniel (Dan)]

Yes, you can forward to a subdomain.  Just define it as a separate zone and 
include the forwarders and forward-only lines.  I believe you need 
allow-query-cache for this to work.

Delegated zones don’t necessarily need to respond with SOA and NS records.  
Many load balancers use delegated zones for global server load balancing.  Just 
point your NS records at the load balancer and it should refer the querying DNS 
server along to the load balancer.  Assuming something else is doing the 
recursive lookups, you just need allow-query for this.  If this device is doing 
the recursive lookups, then you need allow-recursion for this to work.

You do need SOA and NS records if you are going to set up either a secondary or 
a stub zone.  In this case, you would need allow-query.

From: bind-users  on behalf of Bind Users 

Reply-To: Mik J 
Date: Monday, March 6, 2017 at 10:24
To: Bind Users 
Subject: Difference between delegation and forward zone

Hello,

I would like to check if my understanding is correct regarding delegation and 
forward

Delegation: I want to delegate the administrative tasks to someone else for one 
subdomain
subdomain1.mydomain.org
I'll specify the NS of that subdomain1.mydomain.org in my mydomain.org zone file
The other person will be able to create rr1.subdomain1.mydomain.org

Forward zone: I can forward a specific zone to a DNS that is different from the 
default fowarders or I won't attempt to do an iterative lookup.

=> Question 1: Can I have a forward zone that is a subdomain 
subdomain1.mydomain.org ? Or when the zone is a subdomain of mydomain (I'm 
athoritative) it's always a delegation ?

=> Question 2: When I do a delegation, is it correct that the remote DNS server 
holding subdomain1.mydomain.org must always answer the SOA with SOA records and 
NS records (RFC 2181 chapter 6.1)

Regards

___
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: Difference between delegation and forward zone

[Barry Margolin]

In article ,
 "McDonald, Daniel (Dan)"  wrote:

> Yes, you can forward to a subdomain.  Just define it as a separate zone and 
> include the forwarders and forward-only lines.  I believe you need 
> allow-query-cache for this to work.

This won't work reliably if the server is supposed to be authoritative 
for the parent domain. The problem is that queries from resolvers do not 
have the Recursion Desired flag set, and forwarding is only done when 
recursing.

Also, if there are no delegation records for the subdomain, the parent 
server believes it's authoritative for them, despite having forwarders 
configured.

Forwarding is generally only useful on resolvers, not authoritative 
servers.

-- 
Barry Margolin
Arlington, MA
___
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: Difference between delegation and forward zone

[Mik J via bind-users]

Barry: "Also, if there are no delegation records for the subdomain, the parent 
server believes it's authoritative for them, despite having forwarders 
configured." 
I don't understand what you just wrote above. Are you saying I need to do both 
delegation and forwarding on my authoritative server on the parent domain ?
So yes the case is load balancers or other devices that are not real DNS, they 
behave in funny way.




   ___
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

Adding/removing name servers under DNSSEC

[Mathew Ian Eis]

Hi BIND,

Hoping someone in the community will have experience with this.

We are looking to migrate off a set of nameservers to another set of 
nameservers. For all practical considerations, both sets of servers are slave 
to the same hidden master, which yields interesting considerations that are not 
part of the “normal” practices in terms of the migration. (Being that “normal” 
migrations are from one provider to another and require cutting a new set of 
keys).

I see the steps as:

1. Add new nameservers to zone NS records. (do not remove old nameservers yet)
2. Wait at least zone NS TTL. (new servers may not be trusted during this time)
3. Update registry to add new nameservers & remove old nameservers.
4. Wait at least registry NS TTL. (old nameservers may not be trusted as cache 
expires, but new servers will)
6. Remove NS records for old nameservers from zone.

The reason for not making the change in one quick pass would presumably be the 
risk of complete mismatch between the registry NS records and the zone NS 
records in the event the registry data is cached but the zone data is not.

Does anyone have any experience that would suggest differently?

Thanks in advance,

Mathew Eis
Northern Arizona University

___
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: Adding/removing name servers under DNSSEC

[Mark Andrews]

In message <924327f5-6d1d-49f4-80c1-b1a2c539f...@nau.edu>, Mathew Ian Eis 
writes:
> Hi BIND,
>
> Hoping someone in the community will have experience with this.
>
> We are looking to migrate off a set of nameservers to another set of
> nameservers. For all practical considerations, both sets of servers are
> slave to the same hidden master, which yields interesting considerations
> that are not part of the normal practices in terms of the migration.
> (Being that normal migrations are from one provider to another and
> require cutting a new set of keys).
>
> I see the steps as:
>
> 1. Add new nameservers to zone NS records. (do not remove old nameservers
> yet)
> 2. Wait at least zone NS TTL. (new servers may not be trusted during this
> time)
> 3. Update registry to add new nameservers & remove old nameservers.
> 4. Wait at least registry NS TTL. (old nameservers may not be trusted as
> cache expires, but new servers will)
> 6. Remove NS records for old nameservers from zone.
>
> The reason for not making the change in one quick pass would presumably
> be the risk of complete mismatch between the registry NS records and the
> zone NS records in the event the registry data is cached but the zone
> data is not.
>
> Does anyone have any experience that would suggest differently?
>
> Thanks in advance,
>
> Mathew Eis
> Northern Arizona University

* You configure the new servers. All servers should be serving the
  same content during the change sans zone transfer delays.
* You update the NS records (parent and child).
* Wait for all the servers to have the new NS records (parent and child).
* Wait for cached NS records to expire (max parent/child TTL).
* Deconfigure the old servers for the zone.

This really is independent of DNSSEC.  Many people don't do this
correctly.  They don't ensure new and old servers serve the same
content during the change over or add the necessary wait periods.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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

status openssl v1.1 support?

[PGNet Dev]

In Bind 9.11.0-P3's "CHANGES"

grep -i openssl CHANGES | grep "1\.1"
4129.   [port]  Address API changes in OpenSSL 1.1.0. [RT 
#39532]

seems the bug DB is private/closed, so can't see the status of that^.

Trying to build against openssl v11x fails @ configure

...
checking for OpenSSL library... using OpenSSL from 
/usr/local/openssl11/lib and /usr/local/openssl11/include
checking whether linking with OpenSSL works... yes
checking whether linking with OpenSSL requires -ldl... unknown
configure: error: OpenSSL has unsupported dynamic loading
...

Searching on that bug leads to


http://superuser.com/questions/1182479/configure-error-openssl-has-unsupported-dynamic-loading-when-building-bind9

"It turns out that bind does not yet support OpenSSL 1.1 (see 
OPenssl 1.1 and Bind on bind-users mailing list)."

and to the ML



OPenssl 1.1 and Bind
https://lists.isc.org/pipermail/bind-users/2016-August/097391.html

Where the last comment from marka at isc.org discusses direction

It was mostly accessor functions were missing which I wasn't worried
about as I expected them to turn up which they have.  You then have
to recode everything to deal with all the structures being opaque.

There is also the issue of making a code base that will compile w/
OpenSSL 1.1 and OpenSSL 1.0 (and 0.9 despite it being EOL).  I
suspect we will have static versions of the OpenSSL 1.1 accessor
functions so we can build w/ OpenSSL 1.0 and not have too many
#if/#else/#endif.  Aim to have all the code be written for OpenSSL 1.1.

Need to figure out how GOST is now done.

PKCS11 will most probably not be via OpenSSL anymore.

Then there is the gssapi support libraries that also need to support
OpenSSL 1.1.

but, afaict, nothing further.

What *IS* the current state/status of openssl 1.1 support in bind9?

Is it yet targeted for a specific release? or available as a current patchset?
___
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: Adding/removing name servers under DNSSEC

[Mathew Ian Eis]

To clarify this step *You update the NS records (parent and child)* - you add 
NS records for new nameservers to parent and child (at approximately the same 
time), but do not remove NS records for old nameservers (until after all cached 
records expire). Is this correct?

As to serving the same content from old and new nameservers, that will be easy 
in this case since all are slaves to the same (hidden) master.

Thanks again,

Mathew Eis
Northern Arizona University

-Original Message-
From: Mark Andrews 
Date: Monday, March 6, 2017 at 5:32 PM
To: Mathew Ian Eis 
Cc: "bind-users@lists.isc.org" 
Subject: Re: Adding/removing name servers under DNSSEC


In message <924327f5-6d1d-49f4-80c1-b1a2c539f...@nau.edu>, Mathew Ian Eis 
writes:
> Hi BIND,
>
> Hoping someone in the community will have experience with this.
>
> We are looking to migrate off a set of nameservers to another set of
> nameservers. For all practical considerations, both sets of servers are
> slave to the same hidden master, which yields interesting considerations
> that are not part of the normal practices in terms of the migration.
> (Being that normal migrations are from one provider to another and
> require cutting a new set of keys).
>
> I see the steps as:
>
> 1. Add new nameservers to zone NS records. (do not remove old nameservers
> yet)
> 2. Wait at least zone NS TTL. (new servers may not be trusted during this
> time)
> 3. Update registry to add new nameservers & remove old nameservers.
> 4. Wait at least registry NS TTL. (old nameservers may not be trusted as
> cache expires, but new servers will)
> 6. Remove NS records for old nameservers from zone.
>
> The reason for not making the change in one quick pass would presumably
> be the risk of complete mismatch between the registry NS records and the
> zone NS records in the event the registry data is cached but the zone
> data is not.
>
> Does anyone have any experience that would suggest differently?
>
> Thanks in advance,
>
> Mathew Eis
> Northern Arizona University

* You configure the new servers. All servers should be serving the
  same content during the change sans zone transfer delays.
* You update the NS records (parent and child).
* Wait for all the servers to have the new NS records (parent and child).
* Wait for cached NS records to expire (max parent/child TTL).
* Deconfigure the old servers for the zone.

This really is independent of DNSSEC.  Many people don't do this
correctly.  They don't ensure new and old servers serve the same
content during the change over or add the necessary wait periods.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org


___
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: status openssl v1.1 support?

[Mark Andrews]

OpenSSL 1.1 support is in the upcoming maintenance releases which
are available on the ISC web site 

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: Adding/removing name servers under DNSSEC

[Mark Andrews]

In message , Mathew Ian Eis 
writes:
> To clarify this step *You update the NS records (parent and child)* - you
> add NS records for new nameservers to parent and child (at approximately
> the same time), but do not remove NS records for old nameservers (until
> after all cached records expire). Is this correct?

No.  You can change both sets of NS records at the same time. 

> As to serving the same content from old and new nameservers, that will be
> easy in this case since all are slaves to the same (hidden) master.
>
> Thanks again,
>
> Mathew Eis
> Northern Arizona University
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: Difference between delegation and forward zone

[Mark Andrews]

In message <1993722142.5470245.1488838862...@mail.yahoo.com>, Mik J via 
bind-users writes:
> >
> Barry: "Also, if there are no delegation records for the subdomain, the
> parent server believes it's authoritative for them, despite having
> forwarders configured."
> I don't understand what you just wrote above. Are you saying I need to do
> both delegation and forwarding on my authoritative server on the parent
> domain?
> So yes the case is load balancers or other devices that are not real DNS,
> they behave in funny way.

Just delegate.  That is what you are trying to do and that is how
the DNS is designed to work.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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