Creates a new EC2 instance ( CentOS ) and by default it comes with a dns resolver to the outside world.
For our purposes - we had set up an internal dns server running (bind - process 'named' on a particular host).
When we were launching our pool of servers - we wanted to make sure that the new instances fall under the same domain that we specify it to be.
We also wanted to set the nameserver of the newly created instances pointing to the internal DNS server we have to resolve the ambiguity we have.
Before making the change - the file /etc/resolv.conf was looking as follows.
where 172.x.y.z was something set by Amazon EC2 by default.
Edit /etc/dhclient.conf ( Create one , if it does not exist )
I also found it useful to create an Elastic IP and associate the dns server instance with the elastic ip,
and then have the prepend domain-name-servers refer to the elastic ip , instead of the internal ip.
So - even if the internal dns server fails = we can reconstruct it from another AMI and associate with the elastic ip without affecting the rest of the system.
To see the changes to /etc/dhclient , do the following
This command forcibly renews the dhcp lease that will force the new credentials from /etc/dhclient.conf to be read.
After doing this , verify /etc/resolv.conf
So that completes the process and we are good about it.
For our purposes - we had set up an internal dns server running (bind - process 'named' on a particular host).
When we were launching our pool of servers - we wanted to make sure that the new instances fall under the same domain that we specify it to be.
We also wanted to set the nameserver of the newly created instances pointing to the internal DNS server we have to resolve the ambiguity we have.
Before making the change - the file /etc/resolv.conf was looking as follows.
# cat /etc/resolv.conf ; generated by /sbin/dhclient-script search some.internal.aws.domain nameserver 172.x.y.z
where 172.x.y.z was something set by Amazon EC2 by default.
Edit /etc/dhclient.conf ( Create one , if it does not exist )
supersede domain-name "ec2.mycompany.com" ; prepend domain-name-servers 10.p.q.r ;my internal company dns
I also found it useful to create an Elastic IP and associate the dns server instance with the elastic ip,
and then have the prepend domain-name-servers refer to the elastic ip , instead of the internal ip.
So - even if the internal dns server fails = we can reconstruct it from another AMI and associate with the elastic ip without affecting the rest of the system.
To see the changes to /etc/dhclient , do the following
$ dhclient -r ; dhclient
This command forcibly renews the dhcp lease that will force the new credentials from /etc/dhclient.conf to be read.
After doing this , verify /etc/resolv.conf
search ec2.mycompany.com nameserver 10.p.q.r ; our DNS server nameserver 172.x.y.z ; the one set by amzn
So that completes the process and we are good about it.
6 comments:
Really the right[tm] way to handle this is to use resolvconf and add your stuff to /etc/resolvconf/resolv.conf.d/base.
In the above notes you have:
prepend domain-name-servers 10.p.q.r ;my internal company dns
the "10.p.q.r" is referring to an EC2 instance, correct?
How can this be, since the EC2 instance internal IP will change whenever that instance is restarted?
notronwest said...
How can this be, since the EC2 instance internal IP will change whenever that instance is restarted?
using this...
http://alestic.com/2009/06/ec2-elastic-ip-internal
On resolv.conf
nameservers = to private IP ?
Thanks?
Good article, it worked on few servers, but not all server that I am currently building.
I added following entires to /etc/dhclient.conf file.
supersede domain-name "PROD.Local" ;
perpend domain-name-servers 10.10.1.10 ;
perpend domain-name-servers 10.10.2.10 ;
and ran following command.
dhclient -r ; dhclient
but the changes are not taking effect.
Did you ever came across this issue.
prepend, not perpend
Post a Comment