Re: [ActiveDir] DNS oddities?

[Matheesha Weerasinghe]

Thanks Neil. That makes a lot of sense.

 

Cheers

 

M@

 

On 8/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED] > wrote:

netlogon is responsible for all SRV records and the DHCP client is responsible for the A record.

 

neil
 

---

From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Matheesha Weerasinghe

Sent: 01 August 2006 09:53

To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] DNS oddities?

 

Ha ha!

 

So would I be correct in assuming netlogon registers _ldap _gc records and KDC registers _kerberos and _kpasswd records and dhcpclient does the "A" record etc.. or am I way off?

 

Cheers

 

M@

 

On 8/1/06, joe <[EMAIL PROTECTED]> wrote:

> If it works for a subset of records, why not for all?

Subsets of records are probably working because you have different services responsible for the different records which also means different SPNs used to generate the kerberos tickets for the services.

 

 

> Just would have been nice to see some consistency in the results.

 

Oh now you are just asking for the moon.... ;o)

 

 

--

O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm 

 

 

---

From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Matheesha Weerasinghe

Sent: Monday, July 31, 2006 7:10 PM

To: ActiveDir@mail.activedir.org

Subject: Re: [ActiveDir] DNS oddities?

 

Thanks Dean. I didnt quite understand your explanation of the tokens for the dhcp client service. If it works for a subset of records, why not for all?

Anyways, I tried repro'ing. The 1st time I tried none of your recommendations worked other than ipconfig /registerdns. I deleted the zone on parent and recreated a secure update zone and rebooted the DC. None of the records were registered and all were rejected according to the network trace. restarting dhcp client fixed it this time even though it didnt before. Once the box was up, I deleted the zone and restarted dhcpclient. Did the "A" record but not the SRV records (excluding the ones beneath _msdcs which was in a different zone and I didnt clean them up). Restarting netlogon fixed that. So looks ike a combination of both restarting netlogon and dhcpclient is required. Then deleted and recreated zone, restarted client DC. All DDNS update records were refused. restarting dhcpclient was also not working with all records refused. After a while some of the records appeared minus the "A" record. Restarted dhcpclient again and the "A" record appeared.

However hosting the child domain's zone on the child dc doesnt seem to cause any issues.

I know whats required to to fix it. Thanks for the further clarification. Just would have been nice to see some consistency in the results.

M@

On 7/30/06, Dean Wells <[EMAIL PROTECTED] > wrote:

I bugged the behavior many moons ago … to my knowledge, no fix has appeared as yet.  The precise cause escapes me but IIR it was related to the ticket/token attached to the DHCP client service on the newly-born domain's DC.  Two immediate solutions exist - 

 

1.       reboot the new DC one more time

2.       or -

a.       temporarily configure the zone to permit non-secure updates &

b.      on the new DC, run ipconfig /registerdns or restart the DHCP client

 

HTH                                                                                                                                                                                             

--
Dean Wells
MSEtechnology
* Email: [EMAIL PROTECTED]
http://msetechnology.com

 

From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Matheesha Weerasinghe
Sent: Sunday, July 30, 2006 3:07 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] DNS oddities?

 

All

Can someone please explain the following observation?

Installed a new R2 DC forest with one DC/DNS.
created a new dns zone for use by a child domain (yet to be created). The zone is replicated to all domain controllers of the root domain. Enabled secure dynamic update only.
Installed a new child domain and pointed to root domain DC/DNS.

All records required were created apart from the A record for the child DC. How come it can create all records other than the "A" record?. If I delete the child donain's zone from the parent domain DC/DNS server, and recreate it, then use "netdiag /test:dns /fix" on the child DC. It does the same. Creates all records except for the "A".

I am puzzled as if the secure dynamic updates allow all these records to be created, whats up with the "A" record?

Also netdiag /test:dns on child DC reports all required everything as OK even though the "A" record is missing in the child domain zone.

Thoughts?

Cheers

M~

PLEASE READ: The information contained in this email is confidential and

intended for the named recipient(s) only. If you are not an intended

recipient of this email please notify the sender immediately and delete your

copy from your system. You must not copy, distribute or take any further

action in reliance on it. Email is not a secure method of communication and

Nomura International plc ('NIplc') will not, to the extent permitted by law,

accept responsibility or liability for (a) the accuracy or completeness of,

or (b) the presence of any virus, worm or similar malicious or disabling

code in, this message or any attachment(s) to it. If verification of this

email is sought then please request a hard copy. Unless otherwise stated

this email: (1) is not, and should not be treated or relied upon as,

investment research; (2) contains views or opinions that are solely those of

the author and do not necessarily represent those of NIplc; (3) is intended

for informational purposes only and is not a recommendation, solicitation or

offer to buy or sell securities or related financial instruments. NIplc

does not provide investment services to private customers. Authorised and

regulated by the Financial Services Authority. Registered in England

no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand,

London, EC1A 4NP. A member of the Nomura group of companies.