Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Samba] Samba4 AD DC Sites / Rename Default-First-Site-Name and internal DNS

735 views
Skip to first unread message

Achim Gottinger

unread,
Dec 29, 2012, 7:40:02 AM12/29/12
to
Hello,

I'm running a few tests here with two locations.

site1: server-site1.gsg.local subnet 192.168.200.0/24
site2: server-site2.gsg.local subnet 192.168.190.0/24

both are connected via VPN.

I migrated an samba3 domain at server-site1 it gets
Default-First-Site-Name assigned. Then I joined the new samba4 domain
withe server-site2. Both servers work and i can join and access them
with clients at both locations. I created reverse zones for both subnets
and added the required static entries.
Then I created an new site (name site2) and two subnets with MS AD Site
Management. I assigned subnet 192.168.200.0/24 to the site
"Default-First-Site-Name" and subnet 192.168.190.0/24 to the site
"site2". And moved server-site2 from Default-First-Site-Name to site2.
Machines at site1 randomly picked server-site2 for logins. On site2 they
always picked server-site2.

So I deleted a few DNS records.

_ldap._tcp.Default-First-Site-Name._sites.gsg.local SRV site2.gsg.local

_kerberos._tcp.Default-First-Site-Name._sites.gsg.local SRV site2.gsg.local

_gc._tcp.Default-First-Site-Name._sites.gsg.local SRV site2.gsg.local

_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.gsg.local SRV site2.gsg.local


And after an samba restart also

_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.gsg.local SRV site2.gsg.local

_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.gsg.local SRV site2.gsg.local

Afterwards machines at site1 also chose server-site1 most of the time.
Hope i can optimize the behaviour of logon server choosing abit more but
it happened really seldom and it all ran virtualized with 1GB bandwidth
for the VPN connection, which will be 1-2MBit once in production.

As an last step i renamed the site "Default-First-Site-Name" into
"site1". Restarted the samba services at both sites check replication.
But there are still a few DNS entries left whom i deleted manual.

_ldap._tcp.Default-First-Site-Name._sites.gsg.local SRV site1.gsg.local
_kerberos._tcp.Default-First-Site-Name._sites.gsg.local SRV site1.gsg.local
_gc._tcp.Default-First-Site-Name._sites.gsg.local SRV site1.gsg.local
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.gsg.local SRV site1.gsg.local
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.gsg.local SRV site1.gsg.local
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.gsg.local SRV site1.gsg.local

So there are no more (visible) entries left in

Default-First-Site-Name._sites.gsg.local
Default-First-Site-Name._sites.gc._msdcs.gsg.local
Default-First-Site-Name._sites.dc._msdcs.gsg.local

But the structure remains an can not be deleted. (things like
_tcp.Default-First-Site-Name._sites.gsg.local). Things still seem to
work at both sites but i'm curious if these leftovers can be completely
removed.

Thanks in advance
Achim Gottinger

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

Andrew Bartlett

unread,
Dec 29, 2012, 8:10:01 PM12/29/12
to
As you have noticed, we are very good at adding DNS records, but never
remove the old ones. What you have done seems reasonable, if you have
renamed the site, removing the remaining DNS references seems entirely
reasonable.

Please file a bug about the left-behind DNS stuff, we really should
clean that up.

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org

Matthieu Patou

unread,
Dec 30, 2012, 3:50:02 AM12/30/12
to
On 12/29/2012 04:38 AM, Achim Gottinger wrote:
> Hello,
>
> I'm running a few tests here with two locations.
>
> site1: server-site1.gsg.local subnet 192.168.200.0/24
> site2: server-site2.gsg.local subnet 192.168.190.0/24
>
> both are connected via VPN.
>
> I migrated an samba3 domain at server-site1 it gets
> Default-First-Site-Name assigned. Then I joined the new samba4 domain
> withe server-site2. Both servers work and i can join and access them
> with clients at both locations. I created reverse zones for both
> subnets and added the required static entries.
> Then I created an new site (name site2) and two subnets with MS AD
> Site Management. I assigned subnet 192.168.200.0/24 to the site
> "Default-First-Site-Name" and subnet 192.168.190.0/24 to the site
> "site2". And moved server-site2 from Default-First-Site-Name to site2.
> Machines at site1 randomly picked server-site2 for logins. On site2
> they always picked server-site2.
>
I'm not 100% sure that we implement everything that is needed for a
client to pickup the correct site, so you might see some issues still.

> As an last step i renamed the site "Default-First-Site-Name" into
> "site1". Restarted the samba services at both sites check replication.
> But there are still a few DNS entries left whom i deleted manual.
>
It's really not a good idea to delete rename the default-First site lots
of Windows admins don't advise to do so, you'd better leave it empty.

Matthieu
>


--
Matthieu Patou
Samba Team
http://samba.org

Achim Gottinger

unread,
Dec 30, 2012, 10:20:01 PM12/30/12
to
> As you have noticed, we are very good at adding DNS records, but never
> remove the old ones. What you have done seems reasonable, if you have
> renamed the site, removing the remaining DNS references seems entirely
> reasonable.
>
> Please file a bug about the left-behind DNS stuff, we really should
> clean that up.
>
> Andrew Bartlett

There is this menu option "cleanup old resource entries" in the DNS snap-in, guess it's normal AD behaviour. :-)
This does not yet work against an Samba4 AD DC. But I'll file an bugreport.

> I'm not 100% sure that we implement everything that is needed for a
> client to pickup the correct site, so you might see some issues still.
It had happened in very seldom cases with the samba3/bind/openldap before. In the Samba4 test environment it happened only once after i had removed the mentioned SRV records pointig to site2's dc in site1 folders. I'll report back if it happens on an regular basis.
>> As an last step i renamed the site "Default-First-Site-Name" into
>> "site1". Restarted the samba services at both sites check
>> replication. But there are still a few DNS entries left whom i
>> deleted manual.
> It's really not a good idea to delete rename the default-First site
> lots of Windows admins don't advise to do so, you'd better leave it
> empty. Matthieu

So to be on the safe side you recommend i create two new sites and assign the two servers to them, leaving Default-First-Site-Name with on assigned server.
I thought it is safer to leave the first server in that default site because i had read the sites thing is a work in progress. Renaming it was somethin i did after abit of online research which mentioned it is safe and not forbidden. Beside that now empty structure elements in dns the test environment is still work functional.

http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/2afc3cf5-7389-4368-bdeb-887e60c0081f

Beside all that for me samba4 is a great step forward an will simplify things alot compared to the previous samba3/bind/openldap solution

Matthieu Patou

unread,
Dec 30, 2012, 11:10:02 PM12/30/12
to
On 12/30/2012 07:10 PM, Achim Gottinger wrote:
>> As you have noticed, we are very good at adding DNS records, but never
>> remove the old ones. What you have done seems reasonable, if you have
>> renamed the site, removing the remaining DNS references seems entirely
>> reasonable.
>>
>> Please file a bug about the left-behind DNS stuff, we really should
>> clean that up.
>>
>> Andrew Bartlett
>
> There is this menu option "cleanup old resource entries" in the DNS
> snap-in, guess it's normal AD behaviour. :-)
Not it's not, there is KB about DNS server about how to clean old
records that were set by a client via DDNS
Ok good to know.

Matthieu.

--
Matthieu Patou
Samba Team
http://samba.org

Rob Townley

unread,
Dec 31, 2012, 12:30:02 PM12/31/12
to
>> http://social.technet.**microsoft.com/Forums/en-US/**
>> winserverNIS/thread/2afc3cf5-**7389-4368-bdeb-887e60c0081f<http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/2afc3cf5-7389-4368-bdeb-887e60c0081f>
>>
>> Beside all that for me samba4 is a great step forward an will simplify
>> things alot compared to the previous samba3/bind/openldap solution
>>
> Ok good to know.
>
> Matthieu.
>
>
> --
> Matthieu Patou
> Samba Team
> http://samba.org
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/**mailman/options/samba<https://lists.samba.org/mailman/options/samba>
>




MS ADS utilities would demand restoring from backups for deleting dns
records.

Assuming you are trying to have two different sites in the same domain,
you would not want to delete DNS records at all, but change the dns SRV
record such that the remote site has a lower priority (higher number) and
the local site has a better priority (lower number). In many computer
systems, higher priority is represented by a lower number. zero is often
the highest priority. Weight is different than priority. More Weight is
represented by a higher number. You may want to leave weight alone
because rfc2782 says WEIGHT zero is a special case. rfc2782 is a little
confusing as to what weight zero implies. It also states the order of
ResourceRecords returned matters in the selection process. Details are in
the URLs below. i would recommend reading about PRIORITY and WEIGHT in
2782.



http://en.wikipedia.org/wiki/SRV_record
http://tools.ietf.org/html/rfc2782

Achim Gottinger

unread,
Jan 1, 2013, 6:10:01 AM1/1/13
to
Am 31.12.2012 18:26, schrieb Rob Townley:
>>>>
>>>>
>>>>
>>>> MS ADS utilities would demand restoring from backups for deleting dns
>>>> records.
>>>>
>>>> Assuming you are trying to have two different sites in the same domain,
>>>> you would not want to delete DNS records at all, but change the dns SRV
>>>> record such that the remote site has a lower priority (higher number) and
>>>> the local site has a better priority (lower number). In many computer
>>>> systems, higher priority is represented by a lower number. zero is often
>>>> the highest priority. Weight is different than priority. More Weight is
>>>> represented by a higher number. You may want to leave weight alone
>>>> because rfc2782 says WEIGHT zero is a special case. rfc2782 is a little
>>>> confusing as to what weight zero implies. It also states the order of
>>>> ResourceRecords returned matters in the selection process. Details are in
>>>> the URLs below. i would recommend reading about PRIORITY and WEIGHT in
>>>> 2782.
>>>>
>>>>
>>>>
>>>> http://en.wikipedia.org/wiki/SRV_record
>>>> http://tools.ietf.org/html/rfc2782
Thank you for the explanation.

I redid the site reation and renaming once again, this time i did not
touch any DNS entry.

1. After the creation of the first DC

LDAP:

dn: DC=gsg,DC=local
fSMORoleOwner: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gsg,DC=local
msDs-masteredBy: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gsg,DC=local
msDS-IsDomainFor: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gsg,DC=local
masteredBy: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gsg,DC=local


dn: CN=Infrastructure,DC=gsg,DC=local
fSMORoleOwner: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gsg,DC=local

dn: CN=RID Manager$,CN=System,DC=gsg,DC=local
fSMORoleOwner: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gsg,DC=local

dn: CN=SERVER-SITE1,OU=Domain Controllers,DC=gsg,DC=local
serverReferenceBL:
CN=SERVER-SITE1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gsg,DC=local


DNS: gsg.local

_gc._tcp SRV 0 100 3268 server-site1.gsg.local
_kerberos._tcp SRV 0 100 88 server-site1.gsg.local
_kpasswd._tcp SRV 0 100 464 server-site1.gsg.local
_ldap._tcp SRV 0 100 389 server-site1.gsg.local

_kerberos._udp SRV 0 100 88 server-site1.gsg.local
_kpasswd._udp SRV 0 100 464 server-site1.gsg.local

_ldap._tcp.DomainDnsZones SRV 0 100 389 server-site1.gsg.local
_ldap._tcp.ForestDnsZones SRV 0 100 389 server-site1.gsg.local

_gc._tcp.Default-First-Site-Name._sites SRV 0 100 3268
server-site1.gsg.local
_kerberos._tcp.Default-First-Site-Name._sites SRV 0 100 88
server-site1.gsg.local
_ldap._tcp.Default-First-Site-Name._sites SRV 0 100 389
server-site1.gsg.local

_ldap._tcp.Default-First-Site-Name._site.DomainDnsZones SRV 0 100 389
server-site1.gsg.local
_ldap._tcp.Default-First-Site-Name._site.ForestDnsZones SRV 0 100 389
server-site1.gsg.local


DNS: _msdc.gsg.local

_kerberos._tcp.dc SRV 0 100 88 server-site1.gsg.local
_ldap._tcp.dc SRV 0 100 389 server-site1.gsg.local
_ldap._tcp.gc SRV 0 100 3268 server-site1.gsg.local
_ldap._tcp.pdc SRV 0 100 389 server-site1.gsg.local

_ldap._tcp.[DOMAIN ID].domains SRV 0 100 389 server-site1.gsg.local

_kerberos._tcp.Default-First-Site-Name._sites.dc SRV 0 100 88
server-site1.gsg.local
_ldap._tcp.Default-First-Site-Name._sites.dc SRV 0 100 389
server-site1.gsg.local

_ldap._tcp.Default-First-Site-Name._sites.gc SRV 0 100 3268
server-site1.gsg.local


2. Join server-site2 create site2 and move server-site2 into site2,
assign subnets to both sites.

LDAP:

dn: DC=gsg,DC=local

fSMORoleOwner: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gsg,DC=local

msDs-masteredBy: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gsg,DC=local
msDS-IsDomainFor: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gsg,DC=local
masteredBy: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gsg,DC=local

msDs-masteredBy: CN=NTDS
Settings,CN=SERVER-SITE2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gsg,DC=local
msDS-IsDomainFor: CN=NTDS
Settings,CN=SERVER-SITE2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gsg,DC=local
masteredBy: CN=NTDS
Settings,CN=SERVER-SITE2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gsg,DC=local

dn: CN=Infrastructure,DC=gsg,DC=local
fSMORoleOwner: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gsg,DC=local

dn: CN=RID Manager$,CN=System,DC=gsg,DC=local
fSMORoleOwner: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gsg,DC=local

dn: CN=SERVER-SITE1,OU=Domain Controllers,DC=gsg,DC=local
serverReferenceBL:
CN=SERVER-SITE1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gsg,DC=local

dn: CN=SERVER-SITE2,OU=Domain Controllers,DC=gsg,DC=local
serverReferenceBL:
CN=SERVER-SITE2,CN=Servers,CN=site2,CN=Sites,CN=Configuration,DC=gsg,DC=local


DNS: gsg.local

_gc._tcp SRV 0 100 3268 server-site1.gsg.local
_gc._tcp SRV 0 100 3268 server-site2.gsg.local
_kerberos._tcp SRV 0 100 88 server-site1.gsg.local
_kerberos._tcp SRV 0 100 88 server-site2.gsg.local
_kpasswd._tcp SRV 0 100 464 server-site1.gsg.local
_kpasswd._tcp SRV 0 100 464 server-site2.gsg.local
_ldap._tcp SRV 0 100 389 server-site1.gsg.local
_ldap._tcp SRV 0 100 389 server-site2.gsg.local

_kerberos._udp SRV 0 100 88 server-site1.gsg.local
_kerberos._udp SRV 0 100 88 server-site2.gsg.local
_kpasswd._udp SRV 0 100 464 server-site1.gsg.local
_kpasswd._udp SRV 0 100 464 server-site2.gsg.local

_ldap._tcp.DomainDnsZones SRV 0 100 389 server-site1.gsg.local
_ldap._tcp.ForestDnsZones SRV 0 100 389 server-site1.gsg.local

_gc._tcp.Default-First-Site-Name._sites SRV 0 100 3268
server-site1.gsg.local
_gc._tcp.Default-First-Site-Name._sites SRV 0 100 3268
server-site2.gsg.local
_kerberos._tcp.Default-First-Site-Name._sites SRV 0 100 88
server-site1.gsg.local
_kerberos._tcp.Default-First-Site-Name._sites SRV 0 100 88
server-site2.gsg.local
_ldap._tcp.Default-First-Site-Name._sites SRV 0 100 389
server-site1.gsg.local
_ldap._tcp.Default-First-Site-Name._sites SRV 0 100 389
server-site2.gsg.local

_ldap._tcp.Default-First-Site-Name._site.DomainDnsZones SRV 0 100 389
server-site1.gsg.local
_ldap._tcp.Default-First-Site-Name._site.ForestDnsZones SRV 0 100 389
server-site1.gsg.local

_gc._tcp.site2._sites SRV 0 100 3268 server-site2.gsg.local
_kerberos._tcp.site2._sites SRV 0 100 88 server-site2.gsg.local
_ldap._tcp.site2._sites SRV 0 100 389 server-site2.gsg.local


DNS: _msdc.gsg.local

_kerberos._tcp.dc SRV 0 100 88 server-site1.gsg.local
_kerberos._tcp.dc SRV 0 100 88 server-site2.gsg.local
_ldap._tcp.dc SRV 0 100 389 server-site1.gsg.local
_ldap._tcp.dc SRV 0 100 389 server-site2.gsg.local
_ldap._tcp.gc SRV 0 100 3268 server-site1.gsg.local
_ldap._tcp.gc SRV 0 100 3268 server-site2.gsg.local
_ldap._tcp.pdc SRV 0 100 389 server-site1.gsg.local

_ldap._tcp.[DOMAIN ID].domains SRV 0 100 389 server-site1.gsg.local
_ldap._tcp.[DOMAIN ID].domains SRV 0 100 389 server-site2.gsg.local

_kerberos._tcp.Default-First-Site-Name._sites.dc SRV 0 100 88
server-site1.gsg.local
_kerberos._tcp.Default-First-Site-Name._sites.dc SRV 0 100 88
server-site2.gsg.local
_ldap._tcp.Default-First-Site-Name._sites.dc SRV 0 100 389
server-site1.gsg.local
_ldap._tcp.Default-First-Site-Name._sites.dc SRV 0 100 389
server-site2.gsg.local

_ldap._tcp.Default-First-Site-Name._sites.gc SRV 0 100 3268
server-site1.gsg.local
_ldap._tcp.Default-First-Site-Name._sites.gc SRV 0 100 3268
server-site2.gsg.local

_kerberos._tcp.site2._sites.dc SRV 0 100 88 server-site2.gsg.local
_ldap._tcp.site2._sites.dc SRV 0 100 389 server-site2.gsg.local

_ldap._tcp.site2.gc SRV 0 100 3268 server-site2.gsg.local


So at this point Default-First-Site-Name contains SRV records for both
Servers and both with an weight of zero means they get choosen equal.
Site2 has only SRV records for site2 so there should be no problem.
Excerpt from RFC 2782

A server selection mechanism. The weight field specifies a
relative weight for entries with the same priority. Larger
weights SHOULD be given a proportionately higher probability of
being selected. The range of this number is 0-65535. This is a
16 bit unsigned integer in network byte order. Domain
administrators SHOULD use Weight 0 when there isn't any server
selection to do, to make the RR easier to read for humans (less
noisy). In the presence of records containing weights greater
than 0, records with weight 0 should have a very small chance of
being selected.

Means for Default-First-Site-Name Services i have to assign an weight
ther server-site1 records, the bigger the better so 65535 for all of them.

_service server-site1 weight 65535
_service server-site2 weight 0

To select a target to be contacted next, arrange all SRV RRs
(that have not been ordered yet) in any order, except that all
those with weight 0 are placed at the beginning of the list.

_service server-site2 weight 0
_service server-site1 weight 65535

Compute the sum of the weights of those RRs, and with each RR
associate the running sum in the selected order.

_service server-site2 weight 0 sum 0
_service server-site1 weight 65535 sum 65535

Then choose a uniform random number between 0 and the sum computed
(inclusive), and select the RR whose running sum value is the
first in the selected order which is greater than or equal to
the random number selected. The target host specified in the
selected SRV RR is the next one to be contacted by the client.

Means there is a very small chance that random number is zero and server-site2 would be picked.

Remove this SRV RR from the set of the unordered SRV RRs and
apply the described algorithm to the unordered SRV RRs to select
the next target host. Continue the ordering process until there
are no unordered SRV RRs. This process is repeated for each
Priority.

I read this as in my situation next time a client asks for _service at
Default-First-Site-Name it gets server-site2 assignd because
server-site1 has been removed from the list?
Anyway tested the logon process a few times and no matter what site the
clients always picket the right server, means clients at site1 always
choose server-site1. This is a different behaviour to my first tests
where server-site2 was randomly choosen from clients at site1.
When i assign both servers as dns servers to the clients and shutdown
one of the servers they always pick the one available. Even clients in
site2 pick server-site1 if server-site2 is down.

3. Rename Default-First-Site-Name into site1

LDAP:

dn: DC=gsg,DC=local
fSMORoleOwner: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=site1,CN=Sites,CN=Configuration,DC=gsg,DC=local

msDs-masteredBy: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=site1,CN=Sites,CN=Configuration,DC=gsg,DC=local
msDS-IsDomainFor: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=site1,CN=Sites,CN=Configuration,DC=gsg,DC=local
masteredBy: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=site1,CN=Sites,CN=Configuration,DC=gsg,DC=local

msDs-masteredBy: CN=NTDS
Settings,CN=SERVER-SITE2,CN=Servers,CN=site2,CN=Sites,CN=Configuration,DC=gsg,DC=local
masteredBy: CN=NTDS
Settings,CN=SERVER-SITE2,CN=Servers,CN=site2,CN=Sites,CN=Configuration,DC=gsg,DC=local
msDS-IsDomainFor: CN=NTDS
Settings,CN=SERVER-SITE2,CN=Servers,CN=site2,CN=Sites,CN=Configuration,DC=gsg,DC=local


dn: CN=Infrastructure,DC=gsg,DC=local
fSMORoleOwner: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=site,CN=Sites,CN=Configuration,DC=gsg,DC=local

dn: CN=RID Manager$,CN=System,DC=gsg,DC=local
fSMORoleOwner: CN=NTDS
Settings,CN=SERVER-SITE1,CN=Servers,CN=site,CN=Sites,CN=Configuration,DC=gsg,DC=local

dn: CN=SERVER-SITE1,OU=Domain Controllers,DC=gsg,DC=local
serverReferenceBL:
CN=SERVER-SITE1,CN=Servers,CN=site,CN=Sites,CN=Configuration,DC=gsg,DC=local

dn: CN=SERVER-SITE2,OU=Domain Controllers,DC=gsg,DC=local
serverReferenceBL:
CN=SERVER-SITE2,CN=Servers,CN=site2,CN=Sites,CN=Configuration,DC=gsg,DC=local


DNS: gsg.local

_gc._tcp SRV 0 100 3268 server-site1.gsg.local
_gc._tcp SRV 0 100 3268 server-site2.gsg.local
_kerberos._tcp SRV 0 100 88 server-site1.gsg.local
_kerberos._tcp SRV 0 100 88 server-site2.gsg.local
_kpasswd._tcp SRV 0 100 464 server-site1.gsg.local
_kpasswd._tcp SRV 0 100 464 server-site2.gsg.local
_ldap._tcp SRV 0 100 389 server-site1.gsg.local
_ldap._tcp SRV 0 100 389 server-site2.gsg.local

_kerberos._udp SRV 0 100 88 server-site1.gsg.local
_kerberos._udp SRV 0 100 88 server-site2.gsg.local
_kpasswd._udp SRV 0 100 464 server-site1.gsg.local
_kpasswd._udp SRV 0 100 464 server-site2.gsg.local

_ldap._tcp.DomainDnsZones SRV 0 100 389 server-site1.gsg.local
_ldap._tcp.ForestDnsZones SRV 0 100 389 server-site1.gsg.local

_gc._tcp.Default-First-Site-Name._sites SRV 0 100 3268
server-site1.gsg.local
_gc._tcp.Default-First-Site-Name._sites SRV 0 100 3268
server-site2.gsg.local
_kerberos._tcp.Default-First-Site-Name._sites SRV 0 100 88
server-site1.gsg.local
_kerberos._tcp.Default-First-Site-Name._sites SRV 0 100 88
server-site2.gsg.local
_ldap._tcp.Default-First-Site-Name._sites SRV 0 100 389
server-site1.gsg.local
_ldap._tcp.Default-First-Site-Name._sites SRV 0 100 389
server-site2.gsg.local

_ldap._tcp.Default-First-Site-Name._site.DomainDnsZones SRV 0 100 389
server-site1.gsg.local
_ldap._tcp.Default-First-Site-Name._site.ForestDnsZones SRV 0 100 389
server-site1.gsg.local

_gc._tcp.site1._sites SRV 0 100 3268 server-site1.gsg.local
_kerberos._tcp.site1._sites SRV 0 100 88 server-site1.gsg.local
_ldap._tcp.site1._sites SRV 0 100 389 server-site1.gsg.local

_gc._tcp.site2._sites SRV 0 100 3268 server-site2.gsg.local
_kerberos._tcp.site2._sites SRV 0 100 88 server-site2.gsg.local
_ldap._tcp.site2._sites SRV 0 100 389 server-site2.gsg.local


DNS: _msdc.gsg.local

_kerberos._tcp.dc SRV 0 100 88 server-site1.gsg.local
_kerberos._tcp.dc SRV 0 100 88 server-site2.gsg.local
_ldap._tcp.dc SRV 0 100 389 server-site1.gsg.local
_ldap._tcp.dc SRV 0 100 389 server-site2.gsg.local
_ldap._tcp.gc SRV 0 100 3268 server-site1.gsg.local
_ldap._tcp.gc SRV 0 100 3268 server-site2.gsg.local
_ldap._tcp.pdc SRV 0 100 389 server-site1.gsg.local

_ldap._tcp.[DOMAIN ID].domains SRV 0 100 389 server-site1.gsg.local
_ldap._tcp.[DOMAIN ID].domains SRV 0 100 389 server-site2.gsg.local

_kerberos._tcp.Default-First-Site-Name._sites.dc SRV 0 100 88
server-site1.gsg.local
_kerberos._tcp.Default-First-Site-Name._sites.dc SRV 0 100 88
server-site2.gsg.local
_ldap._tcp.Default-First-Site-Name._sites.dc SRV 0 100 389
server-site1.gsg.local
_ldap._tcp.Default-First-Site-Name._sites.dc SRV 0 100 389
server-site2.gsg.local

_ldap._tcp.Default-First-Site-Name._sites.gc SRV 0 100 3268
server-site1.gsg.local
_ldap._tcp.Default-First-Site-Name._sites.gc SRV 0 100 3268
server-site2.gsg.local

_kerberos._tcp.site1._sites.dc SRV 0 100 88 server-site1.gsg.local
_ldap._tcp.site1._sites.dc SRV 0 100 389 server-site1.gsg.local

_ldap._tcp.site1.gc SRV 0 100 3268 server-site1.gsg.local

_kerberos._tcp.site2._sites.dc SRV 0 100 88 server-site2.gsg.local
_ldap._tcp.site2._sites.dc SRV 0 100 389 server-site2.gsg.local

_ldap._tcp.site2.gc SRV 0 100 3268 server-site2.gsg.local


The LDAP tree has no occurence of Default-First-Site-Name now. In DNS
the records for Default-First-Site-Name still point to both servers. In
addition the neccesary records for site1 are there and point only to
server-site1.
I also created the Subnets for both sites and assigned the in the AD
Location and Services Snapin. Should there be an entry for those in LDAP?
After each step I performed i saved the output of "ldapsearch -b
DC=gsg,DC=local" (after kinit Administrator). In there i can not find
any references for the site subnets.
Tried to assign subnet1 to site2 and vice versa and the clients all
picked the servers from the other site, so it seems to be used to assign
clients to the sites.

4. Try to remove all site dependant entries.

Because it seemed those entries below _sites are not used and the
assignement happens based on the site subnets i tried to delete all the
service records below _sites. After restarting both servers
Default-First-Site-Name has now completely dissapeared from DNS.
There is no replacemet for these two records now.

_ldap._tcp.Default-First-Site-Name._site.DomainDnsZones SRV 0 100 389
server-site1.gsg.local
_ldap._tcp.Default-First-Site-Name._site.ForestDnsZones SRV 0 100 389
server-site1.gsg.local

Only those two records remained

_ldap._tcp.DomainDnsZones SRV 0 100 389 server-site1.gsg.local
_ldap._tcp.ForestDnsZones SRV 0 100 389 server-site1.gsg.local

Finaly i joined another server in subnet1 to the domain. It added it's
records to site1._sites and did not create Default-First-Site-Name again.

Enough testing for the 1st ;-) , happy new year.

Achim Gottinger

Achim Gottinger

unread,
Jan 1, 2013, 7:10:01 AM1/1/13
to
Well after some time and samba restarts the left over structure elements
had disappeared.
Had to remove two records with samba-tools because they could not be
accessed from the MS DNS Snapin.

samba-tool dns delete localhost gsg.local
"_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.gsg.local" SRV
"server-site1.gsg.local. 389 0 100"
samba-tool dns delete localhost gsg.local
"_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.gsg.local" SRV
"server-site1.gsg.local. 389 0 100"

Afterwards all appearances of Default-First-Site-Name disappeared.

There remains however still an issue with the site dependant SRV records
on an server. If a server is moved to another site or an site gets
renamed. The old SRV records for that server/site remain.

Achim Gottinger
0 new messages