Re: [ActiveDir] DDNS and non-Windows DNS

[Al Mulnick]

We've danced this dance before? :) 

I can barely count the number of times I've heard the "but it's been working fine like that for years" speech only to find out no, it wasn't working fine, but it was masked by other processes or wasn't being relied upon until now etc.

 

I know I've harped this before, but what you're talking about would be quite confusing to the support staff and more difficult/time-consuming to troubleshoot than I prefer.  However, as it's not my network, here's my thinking:

 

Reverse zones register NS records.  As such, it's possible that the client can read that and redirect to the NS.  Which one?  Great question.  Whichever it picks from the list most likely. You may not have the control you want over that. Also, since the BIND servers are used by everything why bother with the AD integrated zones again? Have all of the zones on BIND servers and be done with it, right?  

 

Since that may not be an option, and so that I'm clear, you're proposing that forward zones for AD are hosted by AD and reverse zones for AD are hosted on BIND, but all clients will continue to prefer BIND for primary host resolution? If that's the case, then there's really no issue since the client should register PTR's with the BIND server as long as he's hosting the reverse zone. That's how I read this: " All clients use these servers for resolution. A new AD is being designed/built. New AD zones will be hosted by DC/DNS servers. Proposal: leave existing clients "as is" and configure new Windows clients to use these same BIND servers too (this means no changes to DHCP scopes for e.g.) Allow DDNS requests from Windows clients to be referred to DC/DNS servers via BIND servers. PTR updates will occur (assuming BIND servers allow DDNS). "

 

In summary: Forward zones in AD and reverse zones in BIND.  Primary name server is BIND for all clients.  Expected behavior: forward lookups for AD hosts should be redirected to (or use stub zones or secondary mechanism) AD DNS hosts.  Reverse lookup should be handled by BIND servers. 

 

Configuration: no reverse zones should be configured on the AD integrated zones. Since all clients are using BIND anyway, it's a non-issue as all hosts will be found from BIND query.

 

Will anything break?  Shouldn't.  AD doesn't *require* reverse zones to function.  They can be useful and are often recommended in large environments, but in this case they do exist on the BIND servers which will be looked at in the resolution path. No worries. :)

 

 

Al
 

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

 

PTR records *should* be no different.  However, you will need a way for the registration process to find the reverse zone's auth NS because they'll need a writeable copy. 
[Neil Ruston] Agreed.   

 

Are you saying that your BIND servers don't have those reverse zones? Or that you'd prefer that the AD NS's should be the authoritative NS for the reverse records?

 

From everything you're telling me Neil, I have to say that my instinct is screaming "don't do that! and don't run with scissors either." :)  Why?  Because it's way too complex for you to articulate in a paragraph or less. I've seen you post questions and answers before and you don't seem to normally suffer from an articulation problem.  That's significant because any name resolution system that is too complex is doomed to fail at some point in the future. I've never seen it any different although some might argue my definition of failure [1]. It's just business after all.

 

Personally I think you should either host it all on BIND else host all of AD related records on AD NS's.  The simplification will pay off through better reliability and happier clients.
[Neil Ruston] It's actually straight forward - I'm having a bad time of explaining it cohesively :)  This same model was used by a huge investment bank and still operates just fine today. In short, the situation is as follows: there are existing BIND servers that host various forward and reverse zones. All clients use these servers for resolution. A new AD is being designed/built. New AD zones will be hosted by DC/DNS servers. Proposal: leave existing clients "as is" and configure new Windows clients to use these same BIND servers too (this means no changes to DHCP scopes for e.g.) Allow DDNS requests from Windows clients to be referred to DC/DNS servers via BIND servers. PTR updates will occur (assuming BIND servers allow DDNS).

 

Whatever you end up doing, just remember that for your DDNS registration process, your clients must contact a writeable (authoritative) copy of the zone.  That includes forward and reverse zones. If you don't have a way for your clients to find that writeable copy of the zone, then I would not expect it to work (DHCP may help mask this depending on how you configure it.) It would be interesting then to see what the clients do when/if they need a reverse zone record.  How do they get to the zone?  What level of administration does this require? Is that acceptable?
[Neil Ruston] I still have a question mark around PTR records and how to best locate a writeable copy of the reverse zone. We've come full circle - this was the crux of my original post :) 

 

-ajm

 

[1] My definition of failure when it comes to Name Resolution? I define it as taking more than 1 hour to troubleshoot[2].  If you cannot determine the problem in less than one hour and that's due to the complexity ( i.e. you have too many variables to eliminate in the course of troubleshooting) then you should rethink your design.  

 

[2] Cost benefit: it's possible to make it so simple that you can do this faster, or you can introduce politics and make it take longer.  But the time that something is non-functional or has reduced functionality coupled with staff time to troubleshoot makes this is an easy case to just say no to complexity.  When you think about it anyway.

 

 

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

I should have included more detail - sorry.

 

Firstly, the RFCs don't really help here. They show how DDNS works but not how the request may / may not be 'referred'.

 

The BIND server (in my example) is *not* auth for the zone being updated, is not listed as a NS and does not have a secondary copy either. That was my point (but failed to make it!). The DNS hierarchy is well defined however, with root hints and several conditional forwarder entries.

 

I have tested various scenarios and DDNS always works fine - I'm still unclear whether different 'rules' apply to PTR records or not though.

 

Any further offers?

 

neil 

 

---

From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Al Mulnick
Sent: 27 January 2006 18:43
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] DDNS and non-Windows DNS

 

this looks familiar :)

 

My take. I think the following would be your best bet:

Read the RFC's related to DDNS.  Not perfect, but certainly a good point of reference. 

Setup a test for exactly that scenario to see what happens.

 

What should happen:

Forward: Because the client is using that BIND server, it should try to update it's records to dynamically register and update it's forward and reverse records.  That's because I have to guess that the zone is delegated to the BIND server and the BIND server is the authoritative/primary for that zone and configured to allow DDNS. The key here is that the DNS zone a.b.com is hosted on the BIND server.  I'm guessing that's the case.  If not, this is different.

 

Reverse: The reverse lookup zones are hosted on the BIND servers and the clients use that server as per their configuration.  As long as the security is appropriate, the XP machines can register their records on their configured DNS server (in this case the BIND server).

 

 

Where it becomes more interesting and contested is when there exists a DNS server in the AD that hosts the AD zone and a DNS server external to the AD that hosts a different domain.  If the clients are configured to use the external DNS server, it's a lot trickier and something I don't usually advise because of the complexity of trying to troubleshoot such a thing. 

 

Does that help? I'm sure Deji will have something to say here momentarily...

 

Al

 

 

 

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

Apologies for the long winded post :)

I need to settle a dispute around DDNS across "zone boundaries":

Scenario
=======
XP client resides in DNS zone / AD domain a.b.com
Client uses DHCP and DHCP configured to update dns records
Client uses BIND DNS (V8.2) servers in c.d.com for name resolution
BIND servers in c.d.com host all reverse zones
Server resides in a.b.com (as above)
Server has static IP address

Questions
========
Will DDNS succeed given that the client / server need to update records in a zone not hosted by their own DNS servers?
Will client successfully create/update A and PTR records (regardless of whether DHCP or the client itself is configured to update its PTR record)?

Will server successfully update A and PTR records?

Alternatively, can someone point me to a useful article that explains how DDNS works in detail? I have not managed to find a detailed article yet.

It has been suggested that DDNS will fail if the client/server needs to update a record not hosted by the DNS server used for name resolution. I'm 99% sure that's wrong, but would like to seek clarification and also further info regarding differences between A and PTR updates and DHCP vs. non-DHCP driven updates.

Thanks,
neil

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.

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.

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.