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
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.
