OS X and Active Directory Authentication
-
@nonpartisan said:
@morbiuswilters said:
I believe you just used Occam's Razor to slit your own wrists.
Occam's Razor says that the DC is returning an error code. Fix the error and the problems go away. The fact that we don't know the error code complicates things. But fixing whatever the DC is bitching about causes the problem to go away, regardless of how inferior the Mac client is. How'd I slit my wrist?Maybe. The hard coded IP vs server name seems like a WTF that could easily cause this. If, for whatever reason, the server got a different IP for a time via DHCP, then the Macs that aren't smart enough to use DNS would be screwed, but no one else would ever notice anything.
Alternatively, the ghost of Steve Jobs is punishing them for putting Macs on a Windows network.
-
@boomzilla said:
On one hand, you're correct. On the other hand, any admin that doesn't hard-code critical server IP addresses is the real WTF. If you have a major failure and your DHCP server goes down, now none of your services are available. Best practice is to hard-code IP addresses for all servers, at a minimum, that provide critical infrastructure services. We include DCs in that category, along with DHCP, DNS, mail, etc.Maybe. The hard coded IP vs server name seems like a WTF that could easily cause this. If, for whatever reason, the server got a different IP for a time via DHCP, then the Macs that aren't smart enough to use DNS would be screwed, but no one else would ever notice anything.
Alternatively, the ghost of Steve Jobs is punishing them for putting Macs on a Windows network.
There was some kind of a communication failure between the DC and the Mac. I guess that's really what it boils down to. This is where a capture would've been handy.
-
@nonpartisan said:
@boomzilla said:
On one hand, you're correct. On the other hand, any admin that doesn't hard-code critical server IP addresses is the real WTF. If you have a major failure and your DHCP server goes down, now none of your services are available. Best practice is to hard-code IP addresses for all servers, at a minimum, that provide critical infrastructure services. We include DCs in that category, along with DHCP, DNS, mail, etc.Maybe. The hard coded IP vs server name seems like a WTF that could easily cause this. If, for whatever reason, the server got a different IP for a time via DHCP, then the Macs that aren't smart enough to use DNS would be screwed, but no one else would ever notice anything.
Alternatively, the ghost of Steve Jobs is punishing them for putting Macs on a Windows network.
There was some kind of a communication failure between the DC and the Mac. I guess that's really what it boils down to. This is where a capture would've been handy.
Holy shit that is fucking retarded.. hard-coding IPs because you can't manage to run DHCP and DNS.
-
@nonpartisan said:
Occam's Razor says that the DC is returning an error code.
Occam's Razor says that if the Windows clients are working and the Macs aren't, the problem is with the Mac clients. Could it be a problem with the DC's hard-coded IP? Possible, but unlikely.
-
@morbiuswilters said:
Holy shit that is fucking retarded.. hard-coding IPs because you can't manage to run DHCP and DNS
Certain critical servers must be hard coded in order to be able to work. How is a host supposed to get an IP address from DHCP on a different subnet if the router doesn't know the IP address of the DHCP server to which to forward the request? The DHCP server must be on a constant IP for everything else to work. In theory, you could set all other servers for DHCP and let them grab addresses. But what if your DHCP server shits all over itself? Now you're screwed. Select critical servers, not every server, should be hard-coded for best practice so their services are not dependent on a failed DHCP server. Client machines should always use DHCP unless there's a specific reason not to.
-
@TheRider said:
But what do I say to those Mac enthusiasts that I have to work with who got a Windows laptop like everybody else...
Start printing out a few images from this site. eg:
-
@nonpartisan said:
@morbiuswilters said:
Holy shit that is fucking retarded.. hard-coding IPs because you can't manage to run DHCP and DNS
Certain critical servers must be hard coded in order to be able to work. How is a host supposed to get an IP address from DHCP on a different subnet if the router doesn't know the IP address of the DHCP server to which to forward the request? The DHCP server must be on a constant IP for everything else to work. In theory, you could set all other servers for DHCP and let them grab addresses. But what if your DHCP server shits all over itself? Now you're screwed. Select critical servers, not every server, should be hard-coded for best practice so their services are not dependent on a failed DHCP server. Client machines should always use DHCP unless there's a specific reason not to.No no no no no. You should have redundant DHCP and DNS servers to handle failures. I believe recent versions of IOS no longer require a hard-coded IP to do DHCP relay, but even if you hard code that it's only one config setting on a router.
You are advocating hard-coding IP addresses on clients WHICH IS WRONG. JUST WRONG.
-
@nonpartisan said:
Certain critical servers must be hard coded in order to be able to work. How is a host supposed to get an IP address from DHCP on a different subnet if the router doesn't know the IP address of the DHCP server to which to forward the request? The DHCP server must be on a constant IP for everything else to work. In theory, you could set all other servers for DHCP and let them grab addresses. But what if your DHCP server shits all over itself? Now you're screwed. Select critical servers, not every server, should be hard-coded for best practice so their services are not dependent on a failed DHCP server. Client machines should always use DHCP unless there's a specific reason not to.
I am not an admin. The OP is in a small company, so it's not crazy to think that the admin hat is just one of many that guy wears, and possibly because he was the best at googling for answers, not due to any particular experience or training.
Still, maybe it's not DHCP...maybe they are using static IPs, but changed it for some reason. Again, if everyone else is using DNS and the DNS gets updated properly (or whatever), then everyone using DNS is happy. OSX suckers are SOL. Sure, it's possible that some other error code is being returned, but this is the only actual concrete theory that would actually explain everything, and should be pretty easy to fix, when it happens again.
And "good practices" don't mean anything if they aren't followed.
-
@morbiuswilters said:
No no no no no. You should have redundant DHCP and DNS servers to handle failures. I believe recent versions of IOS no longer require a hard-coded IP to do DHCP relay, but even if you hard code that it's only one config setting on a router.
I'll look up the ip helper-address command. We've always had two entries, one pointing to the primary DHCP server and one pointing to the backup.@morbiuswilters said:
You are advocating hard-coding IP addresses on clients WHICH IS WRONG. JUST WRONG.
The hell I am. I have always said in this thread that the servers should have their IP addresses hard coded so that if DHCP goes MTTS that your critical infrastructure is still up and running. The clients should not have hard-coded IP addresses, except in cases of last resort (yes, there are vendors out there that still make brain-damaged equipment that won't do DHCP, or they do DHCP but they don't send their host name).The hypothesis was brought up that the DC got a different IP address from DHCP. I'm saying that the DC should never get its address from DHCP, that it is one of the pieces of critical infrastructure that should have its IP address hard coded in its network settings.
-
@nonpartisan said:
The hypothesis was brought up that the DC got a different IP address from DHCP. I'm saying that the DC should never get its address from DHCP, that it is one of the pieces of critical infrastructure that should have its IP address hard coded in its network settings.
I don't think anyone is arguing about what you should or shouldn't do, here, or in particular that using DHCP for servers is a good idea. We're just speculating about this OSX WTF.
-
@nonpartisan said:
The hell I am. I have always said in this thread that the servers should have their IP addresses hard coded so that if DHCP goes MTTS that your critical infrastructure is still up and running. The clients should not have hard-coded IP addresses, except in cases of last resort (yes, there are vendors out there that still make brain-damaged equipment that won't do DHCP, or they do DHCP but they don't send their host name).
Not hard-coded IP addresses for the clients, hard-coded addresses for the servers, which is what you are saying. Jesus Christ, can't you read?
Yes, it's wrong. Hard-coding server IPs on client machines shows you don't know how to run a network. DHCP and DNS handle all of this for you. Those are easy systems to set up redundancy for.
-
@boomzilla said:
@nonpartisan said:
The hypothesis was brought up that the DC got a different IP address from DHCP. I'm saying that the DC should never get its address from DHCP, that it is one of the pieces of critical infrastructure that should have its IP address hard coded in its network settings.
I don't think anyone is arguing about what you should or shouldn't do, here, or in particular that using DHCP for servers is a good idea. We're just speculating about this OSX WTF.
He's easily confused, apparently. Although I'm for using DHCP to assign server IP addresses, I never mentioned it in this thread. What I am in favor of is putting server IPs into DNS and having clients reference resources by hostname, not IP. nonpartisan seems to think hard-coding server IPs all over the place makes sense.
-
@morbiuswilters said:
DHCP and DNS handle all of this for you. Those are easy systems to set up redundancy for.
Pause for a moment's inquiry:How do you do redundant DHCP? I know a bunch of sys admins and took a few levels in it myself, and the best solution any of them has discussed involves multiple DHCP servers leasing out different ranges in the same subnet, which sucks.
-
@Weng said:
How do you do redundant DHCP? I know a bunch of sys admins and took a few levels in it myself, and the best solution any of them has discussed involves multiple DHCP servers leasing out different ranges in the same subnet, which sucks.
Several ways: one is a few DHCP servers that have reserved ranges with no overlap (avoiding collisions) but all communicate with a DDNS server that can populate DNS tables with the A REC corresponding to the lease. I've seen it done with several wireless routers all talking to one DNS server (but not sure fully how it worked).
Another is several DHCP servers reading some centrally-managed ARP table, so any one can provide the same information (IP, gateway, DNS info) if another fails - more load-balancing than mirroring. We did something similar years back when we changed some gateway stuff and found our servers - all with static IPs - had to be manually changed, so we added two DHCP servers to the network with identical lease tables mapping MACs to IPs. This was back in the days of NT4 and it was quicker to release/renew an IP than to reboot to pick up IP changes (and the DHCP logs showed a record of who had/hadn't picked up the new IPs).
Most of this emerged from a sysadmin that didn't understand networking working with a network admin that didn't fully know Windows Admin. At the end of it all, it worked, but more by chance and luck than by design. It seemed a very convoluted route to the final desired outcome.
-
@Weng said:
http://www.formortals.com/building-a-redundant-and-manageable-dhcp-infrastructure/ discusses a scheme that uses lots of VLANs, DHCP relays, and only two DHCP servers on non-overlapping ranges, with each range being sufficient for the expected number of users. So - yes; it's common. The alternative is to use failover. (Note that the second link mentions that the DHCP servers can be FQDN's - they don't have to be hard-coded ip addresses.)@morbiuswilters said:
DHCP and DNS handle all of this for you. Those are easy systems to set up redundancy for.
Pause for a moment's inquiry:How do you do redundant DHCP? I know a bunch of sys admins and took a few levels in it myself, and the best solution any of them has discussed involves multiple DHCP servers leasing out different ranges in the same subnet, which sucks.
-
@morbiuswilters said:
He's easily confused, apparently. Although I'm for using DHCP to assign server IP addresses, I never mentioned it in this thread. What I am in favor of is putting server IPs into DNS and having clients reference resources by hostname, not IP. nonpartisan seems to think hard-coding server IPs all over the place makes sense.
I get confused at times by imprecise language such as yours.To the average network engineer, this:
@morbiuswilters said:
You are advocating hard-coding IP addresses on clients WHICH IS WRONG. JUST WRONG.
means hard-coding the IP address of the client in the network configuration. And we are agreed on this -- it is wrong to hard-code the IP address of a client machine in its network configuration. Clients should get their IP addresses via DHCP whenever possible.
I originally addressed the following comment:
@boomzilla said:
If, for whatever reason, the server got a different IP for a time via DHCP,
to which I replied that critical servers should never be getting their IP addresses from DHCP.
What you, morbs, are saying, albeit not very clearly, and is a point which I never addressed, was that clients should never be hard-coded with the server IP addresses that they need to contact; they should use DNS. Which I agree with, with the understanding that due to software WTFs there are times when that's not possible and that I, as a network engineer, need to work around these. (True story: I took issue with the DHCP implementation of a redundant power company's product management cards, even e-mailed the author of the DHCP RFC -- he agreed their implementation was not compliant, and said company still insisted that it was compliant.)
So I never addressed whether hard-coding the IP address into the Mac OS X client was a WTF or not. I don't think it's right that the OS X client doesn't use the same DNS mechanism to get a complete list of DCs that Windows does. But the fact is, based on the OP, the configuration on the Mac didn't change and the configuration on the DC didn't change. That's why a capture in this case would have been revealing -- to see how the network communication was failing.
-
@nonpartisan said:
I took that to mean hard-coding the IP addresses of the servers on the clients (e.g. hard coding the DNS server, which in an office/LAN environment is usually unnecessary and/or inadvisable.)@morbiuswilters said:
You are advocating hard-coding IP addresses on clients WHICH IS WRONG. JUST WRONG.
means hard-coding the IP address of the client in the network configuration.
-
@nonpartisan said:
To the average network engineer, this:
@morbiuswilters said:You are advocating hard-coding IP addresses on clients WHICH IS WRONG. JUST WRONG.
means hard-coding the IP address of the client in the network configuration. And we are agreed on this -- it is wrong to hard-code the IP address of a client machine in its network configuration. Clients should get their IP addresses via DHCP whenever possible.If that's true, then the average network engineer needs to brush up on the English language (hmm...given that the average network engineer probably speaks some Chinese-Hindi hybrid, maybe you're right!). Now, if you changed the word on to of then you'd be correct. Maybe you just need new glasses. :-D
-
@boomzilla said:
If that's true, then the average network engineer needs to brush up on the English language (hmm...given that the average network engineer probably speaks some Chinese-Hindi hybrid, maybe you're right!). Now, if you changed the word on to of then you'd be correct. Maybe you just need new glasses. :-D
People need to learn to read in context. If you presume that I meant hard-coding server IP addresses on clients, then this statement:@nonpartisan said:
If you have a major failure and your DHCP server goes down, now none of your services are available.
makes no sense. The IP addresses of the necessary servers would be hard-coded into the clients. Ergo, services would still be available since the server addresses used by the clients are no longer reliant on DNS or DHCP.
No, the failure was to read my replies in context. My future replies also confirmed my intended context.
-
@nonpartisan said:
@boomzilla said:
If that's true, then the average network engineer needs to brush up on the English language (hmm...given that the average network engineer probably speaks some Chinese-Hindi hybrid, maybe you're right!). Now, if you changed the word on to of then you'd be correct. Maybe you just need new glasses. :-D
People need to learn to read in context. If you presume that I meant hard-coding server IP addresses on clients, then this statement:Look, don't think you can confuse us by trying to claim that you didn't totally misunderstand what morbs said. The context was you reading what morbs said in way that defied modern grammar and syntax and vocabulary.
@nonpartisan said:
@nonpartisan said:
If you have a major failure and your DHCP server goes down, now none of your services are available.
makes no sense. The IP addresses of the necessary servers would be hard-coded into the clients. Ergo, services would still be available since the server addresses used by the clients are no longer reliant on DNS or DHCP.
No, the failure was to read my replies in context. My future replies also confirmed my intended context.
Yeah, the context was that you quoted a post and said what you thought it meant. And you were wrong. I think you need to go back and re-read the thread.
-
@nonpartisan said:
You're losing me now.@nonpartisan said:
If you have a major failure and your DHCP server goes down, now none of your services are available.
makes no sense. The IP addresses of the necessary servers would be hard-coded into the clients. Ergo, services would still be available since the server addresses used by the clients are no longer reliant on DNS or DHCP.
Are you for or against having static IP's assigned to DHCP and (local) DNS servers? If for, are you for or against having these hard-coded in any/all clients?
-
@PJH said:
@nonpartisan said:
Jesus Christ.
You're losing me now.@nonpartisan said:
If you have a major failure and your DHCP server goes down, now none of your services are available.
makes no sense. The IP addresses of the necessary servers would be hard-coded into the clients. Ergo, services would still be available since the server addresses used by the clients are no longer reliant on DNS or DHCP.
Are you for or against having static IP's assigned to DHCP and (local) DNS servers? If for, are you for or against having these hard-coded in any/all clients?
A server's assigned IP address, if it is critical infrastructure (DNS server, DHCP server) should be hard-coded/statically assigned in the network config of the server.
A client's assigned IP address should be assigned by DHCP. DHCP will carry gateway, DNS, etc. information for the client.
A client should use DNS to find the IP addresses of the servers with which it needs to communicate. The DNS server IP addresses will be delivered by the DHCP response.
The DHCP server needs to have a static, non-changing IP address if it is on a subnet different from the client. The reason being that the router will see the DHCP request and needs to know the server to which to forward that request. If the DHCP server is on the same subnet, then it's not as critical, but the response from the DHCP server has its own IP listed as a "contact me when it's time to renew" reference. If the IP changes in the middle of the lease, there will be temporary confusion but ultimately things will work themselves out.
Clients that are brain-dead and can't do DHCP must have these references programmed in. Clients that don't do DHCP, however, tend to also be brain-dead enough that they won't do DNS resolution either.
I support delivering as much information as possible via DHCP to clients and letting them use DNS for all other needs.
-
@nonpartisan said:
Jesus Christ.
Well until this post, you weren't exactly making yourself clear...
-
@nonpartisan said:
to which I replied that critical servers should never be getting their IP addresses from DHCP.
I still consider that nonsense. Slightly less insane nonsense, but nonsense all the same. DHCP is a very robust protocol--the leases can be set for long validity periods in the case of a server. DHCP clients attempt to renew halfway through the lease and will continue to try if the server is down. The leases aren't going to expire out from underneath you unless you are too incompetent to get a hot spare DHCP up and running within a few hours or even days. Finally, I advocate the use of fixed reservations for servers, but these should still be handed out over DHCP. Trying to manage static IP assignments across thousands of servers is madness.
@nonpartisan said:
What you, morbs, are saying, albeit not very clearly, and is a point which I never addressed, was that clients should never be hard-coded with the server IP addresses that they need to contact; they should use DNS. Which I agree with, with the understanding that due to software WTFs there are times when that's not possible and that I, as a network engineer, need to work around these.
Well, that was what we were originally talking about; the fact that the Mac AD client requires a hard-coded IP instead of a hostname.
-
@nonpartisan said:
then this statement:
@nonpartisan said:
If you have a major failure and your DHCP server goes down, now none of your services are available.
makes no sense.
It doesn't make sense in any context. A DHCP server going down is not instantly going to bring down your services. You are either the least competent network engineer I've ever met or you are deliberately lying.
-
@nonpartisan said:
A server's assigned IP address, if it is critical infrastructure (DNS server, DHCP server) should be hard-coded/statically assigned in the network config of the server.
The only possible time this is acceptable is where the DHCP server is on another subnet and the router needs a static IP to do DHCP relay (which is what I already said). Then you can hard-code the DHCP servers' (note plural) IPs.
Why are you advocating this for DNS? True, your server will have a problem if your DHCP is down for several days. But if DHCP is down for several days then your network is fucked anyway.
-
@morbiuswilters said:
@nonpartisan said:
First of all, you know zilch about my network or my skills. So fuck you on that. I've never made a judgment about your programming skills because I don't know you.then this statement:
@nonpartisan said:
If you have a major failure and your DHCP server goes down, now none of your services are available.
makes no sense.
It doesn't make sense in any context. A DHCP server going down is not instantly going to bring down your services. You are either the least competent network engineer I've ever met or you are deliberately lying.
If you're so knowledgable in network design, you should know that a lot of it is based on value judgments. There is no one-size-fits-all design.
Now, before I entertain your question, tell me how you think DHCP can help me with my most critical infrastructure servers. Not application servers, which I can see having them on DHCP, but my basic DNS and DHCP servers. What possible advantage can there be, since there are so few of them, to put them on DHCP.
-
@nonpartisan said:
First of all, you know zilch about my network or my skills.
Given your comments in this thread, I'd say I know some.
@nonpartisan said:
Now, before I entertain your question, tell me how you think DHCP can help me with my most critical infrastructure servers. Not application servers, which I can see having them on DHCP, but my basic DNS and DHCP servers. What possible advantage can there be, since there are so few of them, to put them on DHCP.
The same benefits of putting your app servers on DHCP: central management. You're the one who's carving out this exception for DHCP and DNS; I think you need to justify yourself. I already said I could understand giving static addresses to DHCP servers because it is simpler. Why DNS?
-
@nonpartisan said:
If you have a major failure and your DHCP server goes down, now none of your services are available.
That statement makes no sense to me.
If your (one and only) DHCP server goes down, the only service that unavailable is DHCP. That suggests to me that any clients renewing their IP once the DHCP server is unavailable will be met with silence, but that should be a small percentage of the overall - depending upon the lease time. Most others will fire up, see that their assigned IP hasn't expired, and continue as normal.
Clients (and servers) already up and running prior to the DHCP server being unavailable will still retain IP information. Taking down a DHCP server doesn't magically disconnect existing connections, nor result in DNS failing - it just means that DHCP requests will go unfulfilled and suitable configuration parameters (lease times, etc) should be chosen to provide continuity in the event of a DHCP failure.
I'm not going to claim nonpartisan's level of network knowledge. All I can state is that I've configured DHCP and DNS for several small companies (less than 50 staff) and also run DHCP at home and all the settings I've used have made the loss of DHCP services a non-issue. I think my DHCP services need to be offline for more than 4 days before anyone encounters troubles.
-
@Cassidy said:
I'm not going to claim nonpartisan's level of network knowledge.
No. Apparently you have far more knowledge since you realize DHCP lease times can be made fault tolerant.
-
@morbiuswilters said:
The same benefits of putting your app servers on DHCP: central management. You're the one who's carving out this exception for DHCP and DNS; I think you need to justify yourself. I already said I could understand giving static addresses to DHCP servers because it is simpler. Why DNS?
Because DNS and DHCP are on the same box. Because the DNS server is outside the firewall with no DHCP access. Because there's no significantly useful information being delivered to the DNS servers by DHCP. Because the DNS server is already on its own portable /29 so there's no reason for the IP to ever change. Take your pick. There is zero advantage in our environment to having DNS servers maintain their IP addresses via DHCP.
-
@nonpartisan said:
Because DNS and DHCP are on the same box.
That's not a reason not to use DHCP for DNS hosts (i.e. standalone hosts). That's just why your small network can't use it (since the shared host already has a static IP since it also runs a DHCP daemon.)
@nonpartisan said:
Because the DNS server is outside the firewall with no DHCP access.
You can't forward DHCP requests?
@nonpartisan said:
Because there's no significantly useful information being delivered to the DNS servers by DHCP.
IP address, netmask, its own DNS server (assuming it is authoritative and not a recursive resolver).. Hey, fewer things to have to manage by-hand!
@nonpartisan said:
Because the DNS server is already on its own portable /29 so there's no reason for the IP to ever change.
Once again, this applies to your own small network. You made an across-the-board statement that DHCP was unsuitable for DNS hosts.
@nonpartisan said:
There is zero advantage in our environment to having DNS servers maintain their IP addresses via DHCP.
I see. So you want to retract this statement?
@nonpartisan said:
On the other hand, any admin that doesn't hard-code critical server IP addresses is the real WTF.
-
@nonpartisan said:
Because DNS and DHCP are on the same box.
.. and if only one box is providing those services, surely you're setting yourself up for a SPOF? That's not really a fault of DHCP or DNS, that's a result of not planning for failover services.
@nonpartisan said:
There is zero advantage in our environment to having DNS servers maintain their IP addresses via DHCP.
In your environment, perhaps. In my case we perform static allocation within DHCP and occasionally the change in MAC address means we have to update both DHCP and DNS simultaneously - it's not a problem, but having the two communicate means updates can be performed once, knowing all other dependent services (DNS) will also be informed of changes.
In the case of having completely dynamic IPs, running DDNS on another box is a must. Mainly for... well, situations where the DHCP server could be unavailable but clients are still able to resolve hostnames to IP addresses.
Perhaps I'm missing the point: I see DHCP and DNS as being complimentary services - one is responsible for handing out IPs and understanding who has it (and for how long), another is responsible for maintaining a central lookup list to determine what IP(s) hostname(s) resolve to. I've spoke to some Win2K Server Admins that conflated the two services and didn't quite understand the separation of responsibilities, but a network admin surely understands the role of these two services and can thus create a fault-tolerant design to main service continuity in the event of one or more nodes vanishing off the network.
At the end of it all I ain't gonna start telling you your job: I'm sure you do it effectively; I'm just a little confused by what you're stating, knowing my experiences - limited though they are - seem to conflict with your account.
-
@morbiuswilters said:
That's not a reason not to use DHCP for DNS hosts (i.e. standalone hosts). That's just why your small network can't use it (since the shared host already has a static IP since it also runs a DHCP daemon.)
If you consider 3,000+ routers/switches, 60,000 active hosts and 70,000+ ports small.Each server is both DNS and DHCP with redundancies built in.
@morbiuswilters said:
@nonpartisan said:
You would trust any DHCP requests that come from outside your firewall?Because the DNS server is outside the firewall with no DHCP access.
You can't forward DHCP requests?
@morbiuswilters said:
IP address, netmask, its own DNS server (assuming it is authoritative and not a recursive resolver).. Hey, fewer things to have to manage by-hand!
We did a full-on overhaul of DNS and DHCP two years ago. Never had to touch the network settings since.@morbiuswilters said:
Once again, this applies to your own small network. You made an across-the-board statement that DHCP was unsuitable for DNS hosts.
Not sure where you're going with this. Each of our DNS/DHCP servers is on its own /29 that we can pick up and move to a new site with zero effort. The /29 is there in case we need to add companion servers to the subnet, but we've had no need.@morbiuswilters said:
I see. So you want to retract this statement?
To what end? There is zero advantage for us to set our DNS(/DHCP) servers to use DHCP to obtain their IP addresses.
@nonpartisan said:
On the other hand, any admin that doesn't hard-code critical server IP addresses is the real WTF.
-
@Cassidy said:
I see DHCP and DNS as being complimentary services - one is responsible for handing out IPs and understanding who has it (and for how long), another is responsible for maintaining a central lookup list to determine what IP(s) hostname(s) resolve to.
(UK Centric): e.g. You don't necessarily want Virgin Media running 118 118, but you would like them to talk to one another occasionally to update their lists.
-
@nonpartisan said:
If you consider 3,000+ routers/switches, 60,000 active hosts and 70,000+ ports small.
Each server is both DNS and DHCP with redundancies built in.
Oh, wait, so you have a redundant DHCP setup? And you're complaining about that not working or something? You're really all over the place.
@nonpartisan said:
You would trust any DHCP requests that come from outside your firewall?
Presumably you have another firewall in front of your external machines. And presumably you have control of the external switch. You make it sound as if your DMZ servers are just completely out there where anybody could plug into them.
@nonpartisan said:
We did a full-on overhaul of DNS and DHCP two years ago. Never had to touch the network settings since.
Wow, I'm glad your network is so little used. Regardless, most networks have to do things like scale and replace hosts. It's a lot easier to centrally manage this stuff than to do it all by-hand. Then again, I'm guessing you also configure your servers by-hand, so the whole thing sounds like a colossal fuck-up.
@nonpartisan said:
Not sure where you're going with this. Each of our DNS/DHCP servers is on its own /29 that we can pick up and move to a new site with zero effort. The /29 is there in case we need to add companion servers to the subnet, but we've had no need.
Where I was going is: it doesn't really matter what your particular little network needs. You said that DHCP was unusable for assigning addresses to critical servers like DNS. That's clearly not true.
@nonpartisan said:
To what end? There is zero advantage for us to set our DNS(/DHCP) servers to use DHCP to obtain their IP addresses.
How many times do I have to repeat it? I really don't care about your network. You made a broad, sweeping generalization about the suitability of DHCP for critical servers. You were incorrect: DHCP is a suitable solution in many cases and I would generally consider it WTFy not to use it, unless you have a very tiny network.
-
@nonpartisan said:
I'll just throw another ETLF in here, which looks like it might be 'useful' to those in the know: OSPF....@morbiuswilters said:
That's not a reason not to use DHCP for DNS hosts (i.e. standalone hosts). That's just why your small network can't use it (since the shared host already has a static IP since it also runs a DHCP daemon.)
If you consider 3,000+ routers/switches, 60,000 active hosts and 70,000+ ports small.Each server is both DNS and DHCP with redundancies built in.
-
@Cassidy said:
We have multiple DNS/DHCP servers for different areas of our organization. It has been designed with redundancies such that there is no single point of failure. Let me also add that the overall structure was in place before I joined our networking team.@nonpartisan said:
Because DNS and DHCP are on the same box.
.. and if only one box is providing those services, surely you're setting yourself up for a SPOF? That's not really a fault of DHCP or DNS, that's a result of not planning for failover services.
@Cassidy said:
In your environment, perhaps. In my case we perform static allocation within DHCP and occasionally the change in MAC address means we have to update both DHCP and DNS simultaneously - it's not a problem, but having the two communicate means updates can be performed once, knowing all other dependent services (DNS) will also be informed of changes.
In the case of having completely dynamic IPs, running DDNS on another box is a must. Mainly for... well, situations where the DHCP server could be unavailable but clients are still able to resolve hostnames to IP addresses.
Our environment is diverse enough that, although we would like to have everything dynamic, we can't. Medical equipment that doesn't do DHCP (some devices don't even know about classless routing, let alone DHCP). Monitoring cards that do DHCP but won't send host name. Building automation panels that, while the panel does DHCP, the software that collects data from the panel doesn't do DNS. We have to accommodate all of it. Yes, we do DHCP reservations, and yes, if a network interface goes MTTS and gets replaced then we need to update the MAC and push out the changes.
@Cassidy said:
Perhaps I'm missing the point: I see DHCP and DNS as being complimentary services - one is responsible for handing out IPs and understanding who has it (and for how long), another is responsible for maintaining a central lookup list to determine what IP(s) hostname(s) resolve to. I've spoke to some Win2K Server Admins that conflated the two services and didn't quite understand the separation of responsibilities, but a network admin surely understands the role of these two services and can thus create a fault-tolerant design to main service continuity in the event of one or more nodes vanishing off the network.
You are absolutely correct. They are complimentary services. Just because a box will perform both services doesn't mean we don't have redundancies for them. Our field techs don't seem to understand that DNS and DHCP are complimentary either. That said, we manage both DNS and DHCP through a single Web interface, which tends to make it easy to think of them as one and the same.All I can say at this point is that there must be information that is not being made clear between us as to what you're envisioning and what I'm envisioning. With you, I believe we can end the discussion amicably. (Not so for morbs.)
@Cassidy said:
At the end of it all I ain't gonna start telling you your job: I'm sure you do it effectively; I'm just a little confused by what you're stating, knowing my experiences - limited though they are - seem to conflict with your account.
I'd comment further on this, but once again it'll just create more fodder for morbs, so I'll just say yes, I do my job effectively. Data reliably, consistently, gets from point A to point B and back on my "little" network.
-
@Zemm said:
@Mcoder said:
Oh, and also whatever abstraction layer Macs have over their BSD OS that won't permit that a local administrator access local resources. I always tought that WTF was Windows only.
Terminal and sudo should give access? Unless encrypted?
Never used OSX, but it is BSD, isn't it? Terminal and sudo should give you access. If it is encrypted, it should give access to the encrypted text, and you'll still need to the key to read it (but if some program can read it, the key must be somewhere on your disk).
-
-
@nonpartisan said:
I'd comment further on this, but once again it'll just create more fodder for morbs...
Eh, you've backpedaled from your original statement so far that you more-or-less agree with me now. That's all I ask: your complete agreement and submission in all things.
-
@morbiuswilters said:
That's all I ask: your complete agreement and submission in all things.
Save it for the home, bitch.
-
@powerlord said:
Sadly, this is reminding me of my experiences using Eclipse with the m2e plugin on Windows.
Project works fine, then suddenly one day Update Project Configuration starts throwing NullPointerExceptions and even updating to the latest version of Eclipse and m2e, reinstalling all Eclipse plugins, or even re-fetching the source from SVN fixes it.
m2e is beyond redemption. Finally gave up on it a couple of weeks ago, jumped ships to IDEA and I swear I'll never look back. I guess NetBeans is also at least 10 time more usable.
