Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Virtual interfaces

Status
Not open for further replies.

warmongr

MIS
Mar 17, 1999
214
0
0
US
I have DNS servers that need to have 1 private IP and 1 public IP. I decided to add a virtual interface to both with the public IP. The documents say to add an entry in the /etc/hostname.hme0:1 with the hostname advertised in my /etc/hosts file but there is already an entry there for the private IP. What do I do? Can I put the public IP address in the /etc/hostname.hme0:1 file?
 
It simply gets the FIRST occurence of the name and assumes that is the IP number for the interface. So you can be creative with the name, as long as it matches and you can add it as an alias.

/etc/hostname.hme0 has
myhost-public-1

/etc/hostname.hme0:1 has
myhost-private-1

and /etc/hosts has

1.2.3.4 myhost myhost-public-1
10.X.Y.X myhost-private-1

Also your need for 2 private/public IPs is strange. I think most people would NAT/port map the inbound DNS traffic to avoid routing woes.






 
For the most part that is correct however when I went to a split pocket configuration my slave DNS server saw the notify coming from a private IP space and dropped my internal addresses in my external directory and thus advertised to the globe that my IP's were of the 172.16.x.x range. In a subsequent thread not shown here someone stated that I would need to add a second IP and then at the slave use a transfer-source statement.

Thanks,
N
 
With newer bind 9, I don't think that is required. All you need is to use the "view" directive and the proper match-clients listing. It is worth a look see.
 
I am using Views. If something jumps out at you let me know.

Thanks,

---------------------------------

view "trusted" {
// These are the internal nets and brothers at
match-clients { 172.16.30.0/24; 172.29.92.0/22; 172.16.10.0/24; 172.16.20.0/24; 172.29.
99.0/24; 172.29.4.0/22; };
recursion yes;

// THE ROOT
zone "." {
type hint;
file "named.ca";
};

zone "someone.at.somewhere.com" {
type master;
file "master/internal/someone.at.somewhere.com.zone";
notify yes;
};
zone "88.32.140.IN-ADDR.ARPA" {
type master;
file "master/internal/88.32.140.rev";
notify yes;
};
view "nottrusted" {
// This is everyone else
match-clients { "any"; };
recursion no;

// And now for our external presence
zone "someone.at.somewhere.com" {
type master;
file "master/external/someone.at.somewhere.com.zone";
notify yes;
};
zone "88.32.140.IN-ADDR.ARPA" {
type master;
file "master/external/88.32.140.rev";
notify yes;
};
 
Reading this says exactly what you already knew:


In this example I think there should be an allow-transfer entry on the master named.conf for 192.168.0.254 on the master in the zone section.)

I believe this configuration is only when you want BOTH internal and external views. If the slave is only doing internal view, you don't need to do this, you just need to add the correct allow-transfer statements (I think).


Also reread the section. You need to add an additional private ip to the slave (to differentiate the source to the master so it knows which view to transfer). It is not adding any virtual ips to the master.
 
As luck would have it, it is documented in the ISC FAQ. I just missed it. I added a virtual IP to my primary and slave servers and then added the appropriate notify-source, transfer-source, and query-source address entries on both servers and transfer started working correctly. Imagine that. This is issus is resolved. Thanks for your help.

N
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top