IP ADDRESS CONFUSION

[optimised]

Hello,

Kinda confused! I currently have sdsl with two public ip addresses (paying extra for) which I intended to use for my two nameservers. I've configured the etho in both boxes using the 172.x.x.x ip's provided by the isp for public addresses. How come when I get on the net and use one of those sites that tells you your ip it comes back with a 205.x.x.x number?
Just trying to figure out how I will use these pubic ip addresses for my ns1 and ns2 boxes.
Thanks

 

[ifincham]

Hi,



You'd need to talk to your ISP to be sure but I would imagine it's all done with network address translation (nat).



Once the interface is active do :



/sbin/ifconfig eth0



That should tell you if there has been DHCP used during the pppoe negotiation. If not, I would guess that they are using nat to transparently (to you) change the IP address for whatever reason.



You don't give the full IP addresses (only 172.x.x.x). This seems a bit strange as supposedly 'public' addresses because the IP addresses 172.16.0.0 to 172.31.255.255 are reserved under RFC 1918 for private (non-internet) use. If they asked you to use an address in this range they must be using nat to translate it to a 'real' address at their end.



So, how would your dns servers work ? A very good question! They would definitely need a real public IP address to work from the internet. I can only guess that they gave you the wrong addresses. No-one could possibly connect to you without using a public IP address as the destination from their end, even if it was translated back and forward between you and the ISP. You need to know those dedicated IP addresses, especially if you are going to host dns for a real domain.



Maybe you aren't actually getting what you paid for...



See -->

http://www.faqs.org/rfcs/rfc1918.html

Rgds

 

[optimised]

Hi Ifincham,
Sorry I forgot to mention the paper they gave me has mapped to 205.x.x.x numbers for the two as well.
Does this mean that they are using nat or are they possibly there nameservers.
btw-thanks for responding

 

[ifincham]

Those two 205.x.x.x numbers are the ones you would host your dns on. If you've another box you should be able to check the connectivity from the internet by, for example, (temporarily ?) activating the telnet or ftp server and then trying to access from public internet to your boxes using the ip addresses given, e.g. ftp://205.x.x.x and logon using your usual Linux userid/password.

Once you know thats your box you can set up the 'NS' record for your domain to be associated with those two ip addresses.

To test what nameserver your connection is using simply do a command like :

dig redhat.com

At the bottom of the output it should tell you the nameserver IP used -

[snip]
;; Query time: 318 msec
;; SERVER: 213.1.119.99#53(213.1.119.99)
;; WHEN: Thu Aug 2 20:52:56 2001
;; MSG SIZE rcvd: 95

For example it's 213.1.119.88 in the above output.

You can do commands such as

dig @205.x.x.x redhat.com

to use a specific nameserver.

If you do 'dig redhat.com NS' it will specifically query what the definitive nameservers are for that domain.

You can also do stuff like 'dig redhat.com MX' to find the mail-exchanger and so on.

Rgds, Iain

 

[optimised]

Thanks Ifincham,
Just got off the phone with the isp tech support and you are right the 205.x.x.x numbers are the correct ones.
They map the 205.x.x.x to the 172... numbers on there router.
I asked them if these are the numbers I should use when I change my nameservers with net solutions but the lady wasn't sure If I could use them for my nameservers.(I don't know why not). She said that they could provide the name authority for my site and I'm sure they could for an additional fee.
Do you see any reason I can't provide my own primary and secondary with these 205... ip's?
Thanks again..
Btw- I can ping my server 205...ip but can't ftp I get and error that I don't have permission or server not found.

 

[ifincham]

In principle, once you have IP connectivity to the internet you host anything you like. The usual problems of upload bandwidth and dynamic addressing you should have already solved with sdsl and static ip addresses. The only reason I can think of that you couldn't host your own dns server would be if the ISP blocked Tcp/Udp traffic on port 53 (the DNS port) for 'marketing' reasons. In other words, conceivably they could have restrictions in their connectivity packages that restrict you capability to host certain services because they'd like to charge more for that. They could easily block dns traffic originating from the internet if they wanted to firewall it. However, unless they specified that there were restrictions I'd assume that you can run anything you like.





The easiest way to find-out is to set-up the bind package, get the named daemon running with a test domain and some junk addresses for testing (or real ones if u want) and then check what it resolves from outside. e.g. set up an address like mytest.junkdomain.com equating to some arbitratary ip address and then do a 'dig @205.x.x.x mytest.junkdomain.com'.


It should resolve it for you. Once you're happy it's working in network terms, to use it for a real domain you'll have to edit the domain record with the relevant domain admin authority to specify NS1 and NS2 as your two ip addresses. Once that's in place, anyone on the internet should be able to specify a canonical name for your domain and get it correctly resolved.
The way it works is the user's dns server (at their ISP) will look in its own cache and if not found (or time expired) will find the address of the definitive nameserver for the domain from the relevant root nameserver (e.g. root nameserver for .com). This would be your IP .. It will then obtain the address from your server and pass to the client.




On the FTP testing, firstly do you have a ftp server intstalled ? if not install the wu-ftpd rpm and edit /etc/xinetd.d/wu-ftpd file so that the 'disable=yes' line reads 'disable=no'. Once you've done that then, providing you have the xinetd service running then a client connection attempt should automatically start the ftp server. Certain ip servers running under xinetd are shipped as disabled by default for security reasons so you have to edit the relevant file in /etc/xinetd.d/ .

(DNS service named is not controlled by xinetd incidentally - you have to activate it as a service - e.g. as root '/sbin/chkconfig --level 2345 named on' )





Regards

 

[optimised]

Hi,
I have been working real hard to get this dsn going
Could you tell me if these files seam configured properly to host my domain myhostman.com (using rh 7.1 and bind 9.1)
used the gnome gui for setup and these are the results.

//vhost
<VirtualHost>
DocumentRoot /

http://www/domain

</VirtualHost>


//named.conf

options {
directory &quot;/var/named/&quot;;
};
zone &quot;.&quot; {
type hint;
file &quot;named.ca&quot;;
};

zone &quot;0.0.127.in-addr.arpa&quot; {
type master;
file &quot;0.0.127.in-addr.arpa.zone&quot;;
};

zone &quot;localhost&quot; {
type master;
file &quot;localhost.zone&quot;;
};
zone &quot;

http://www.myhostman.com&quot;

{
type master;
file &quot;

http://www.myhostman.com.zone&quot;;

};


//

http://www.myhostman.com.zone

$TTL 86400
@ IN SOA @ root.localhost{
2;serial
28800;refresh
7200;retry
604800;expire
86400;ttl
}
@ IN NS ns1.myhostman.com


//resolve.conf
search myhostman.com
nameserver 209.x.x.x (isp's)
nameserver 209.x.x.x (ips's)

Thanks for any input

 

[ifincham]

Hi,



From Bind 9.0.1 onwards there are a few differences versus bind 8 and these may cause you problems.



Firstly do :



cd /root

/usr/sbin/dnssec-keygen -a hmac-md5 -b 128 -n user rndc



This command creates two files with names starting Krndc..... In the one with the .private extension you will find something like :



Private-key-format: v1.2

Algorithm: 157 (HMAC_MD5)

Key: Nds78kjheRT8Ovwe==


The last line is what you're interested in as its the authentication key and should be put into /etc/rndc.conf and /etc/named.conf as follows :


Edit the file /etc/rndc.conf so that it looks something like this :



options {

default-server 172.16.16.1;

default-key rndc_key;

};



server localhost {

key rndc_key;

};



key rndc_key {

algorithm hmac-md5;

secret &quot;Nds78kjheRT8Ovwe==&quot;;

};



[set ip address to your server addr]



Then, edit /etc/named.conf to <add> the following :



key rndc_key {

algorithm hmac-md5;

secret &quot;Nds78kjheRT8vwe==&quot;;

};



controls {inet 172.16.16.1 port 953 allow {localhost;} keys {rndc_key;} ; };



[again change ip to yours]



Also, delete the zone &quot;.&quot; block because that is not necessary and is built-in to Bind 9.



Once you've done that restart 'named' as follows :



/etc/rc.d/init.d/named restart



then check messages to see if ok..



tail /var/log/messages



Hopefully it should now be up and running. Test it with 'dig', e.g. 'dig @localhost

http://www.ibm.com'

. It should work if you're online.



Then its a matter of editing the zone files in /var/named/ . I would strongly suggest NOT using bindconf as it will mess up your named.conf and the daemon will not start ! At the moment, I think you have no choice but to edit them by hand.



Regards, Iain

 

[optimised]

Hi,
I ran the dnssec-keygen and still having problems with dns server. When I exec dig ibm.com returns fine. If I run 'dig @localhost

http://www.ibm.com

it times out server not found. The is the same problem I'm having when trying to exec dig for my own domain but running dig google.com returns fine.
Looking for some help maybe with my config files ~

##named.conf
options {
directory &quot;/var/named/&quot;;
};

key rndc_key {
algorithm hmac-md5;
secret &quot;NDs78kjheRT8vwe==&quot;;
};

controls {inet 172.25.47.55 port 953 allow {localhost;} keys {rndc_key;};};

zone &quot;0.0.127.in-addr.arpa&quot; {
type master;
file &quot;0.0.127.in-addr.arpa.zone&quot;;
};

zone &quot;localhost&quot; {
type master;
file &quot;localhost.zone&quot;;
};
zone &quot;

http://www.hostman.com&quot;;

{
type master;
file &quot;

http://www.hostman.com.zone&quot;;;

};



##

http://www.hostman.com.zone

$TTL 86400
@ IN SOA @ root.localhost{
2;serial
28800;refresh
7200;retry
604800;expire
86400;ttl
}
@ IN NS ns1.hostman.com


##Hostfile
127.0.0.1 ns1.hostman.com ns1 localhost.localdomain localhost
172.25.47.98 ns1.hostman.com ns1
172.25.47.99 ns2.hostman.com ns2


##resolve.conf
search ns1.hostman.com
nameserver 209.x.x.x (isp's)
nameserver 209.x.x.x (ips's)


## httpd.conf - configuration for the Apache web server
ServerName ns1.hostman.com
ServerAdmin me@home.com
Listen *:80
Port 80
# Defaults for virtual hosts
ServerSignature on
# Virtual hosts
# Virtual host Default Virtual Host
<VirtualHost _default_:*>
ServerName _default_
DirectoryIndex index.php index.html index.htm index.shtml
ServerSignature email
LogLevel warn
HostNameLookups off
</VirtualHost>

# Virtual host

http://www.hostman.com

<VirtualHost 172.25.47.98>
DocumentRoot /home/myhostman/www/
ServerAdmin joeschmitt@bdstreet.com
ServerName

http://www.hostman.com

ServerSignature email
</VirtualHost>

Thanks!

 

[ifincham]

Are you absolutely sure that the named daemon is actually running - sounds to me that it didn't start for some reason.







If you do '/etc/rc.d/init.d/named restart'



then 'tail -n 15 /var/log/messages' you should see output similar to this :







Aug 6 21:11:02 xxhost named: named shutdown succeeded



Aug 6 21:11:02 xxhost named[1460]: starting BIND 9.1.3 -u named



Aug 6 21:11:02 xxhost named[1460]: using 1 CPU



Aug 6 21:11:02 xxhost named[1463]: loading configuration from '/etc/named.conf'



Aug 6 21:11:02 xxhost named[1463]: no IPv6 interfaces found



Aug 6 21:11:02 xxhost named[1463]: listening on IPv4 interface lo, 127.0.0.1#53



Aug 6 21:11:02 xxhost named[1463]: listening on IPv4 interface eth0, x.x.1.93#53



Aug 6 21:11:02 xxhost named[1463]: listening on IPv4 interface ippp0, x.x.12.202#53



Aug 6 21:11:02 xxhost named[1463]: listening on IPv4 interface vmnet1, 172.16.16.1#53



Aug 6 21:11:02 xxhost named[1463]: command channel listening on 172.16.16.1#953



Aug 6 21:11:03 xxhost named: named startup succeeded



Aug 6 21:11:03 xxhost named[1463]: running







(I changed the host name and hid two IP addresses above for a bit of privacy!)







If your's looks similar you should be able to 'dig' succesfully using any of the interface addresses shown as listening on port 53. (you can restrict the interfaces to listen on in the config file if you want).





As I said, I'm 99% sure you haven't yet managed to successfully start the server. It's probably a minor error in the rndc.conf or named.conf files.





Rgds

 

[Guest_imported]

Hello,
Here are the results 'tail -n 15 /var/log/messages' after bootup.
Aug 6 21:11:02 xxhost named[1460]: starting BIND 9.1.3 -u named
Aug 6 21:11:02 xxhost named[1460]: using 1 CPU
Aug 6 21:11:02 xxhost named[1463]: loading configuration from '/etc/named.conf'
Aug 6 21:11:02 xxhost named[1463]: no IPv6 interfaces found
Aug 6 21:11:02 xxhost named[1463]: listening on IPv4 interface lo, 127.0.0.1#53
Aug 6 21:11:02 xxhost named[1463]: listening on IPv4 interface eth0, x.x.25.78#53
Aug 6 21:11:02 xxhost named[1463]: gnome-name-server [1045] starting
Aug 6 21:11:02 xxhost named[1463]: gnome-name-server [1045] starting


When running '/etc/rc.d/init.d/named restart' response asked for command argument.
So I entered '/etc/rc.d/init.d/named

Then running 'tail -n 15 /var/log/messages' results inthe above plus error
Aug 6 21:11:02 xxhost named[1463]:could'nt open pid file 'var/run/named/named.pid; permission denied
Aug 6 21:11:02 xxhost named[1463]:exiting (due to fatal error)
I did find file named.pid is none existent on system.


I'm still thinking there is an resolve issue as well.
My isp broadstreet.com provided me these ip addresses for my two public ip addresess.
172.26.x.x mapped to 205.33.x.x
172.26.x.x mapped to 205.33.x.x
I configured the eth0 on both boxes using the 172#'s and can connect to the net. I can ftp and ping to the 205#'s etc. works no problem. I can dig any website or nameserver other then my own.

I registered my ns1 and ns2 using the 205#'s on friday 8-3.
If I change the nameservers in my resolve.conf from my isp's nameservers to my public ip 205#s I can no longer connect to the net.
Do I need to contact my isp? Any Ideas?

 

[ifincham]

Hi,



Did you do the '/etc/rc.d/init.d/named restart' as root ? The error message is saying it couldn't open the file that contains the process id for named so that the script could shut that process down and restart. It would need write permission to record the new pid.



What do you get if you do '/usr/sbin/rndc reload' - a permission denied message, or does it work ? What about (as root) '/usr/sbin/lsof -i | grep :domain' does it show the listening sockets on port 53 (aka domain) ?



You didn't show your /etc/rndc.conf file above.. did you put the same key info into that as in /etc/named.conf ? (See prior message for details)



If that all looks OK then I can't think of why it wouldn't be working. Ignoring the subsidiary files in /var/named, you should be able to 'dig @127.0.0.1 localhost' If that works your domain file must be wrong somehow.



On resolv.conf - On redhat with glibc it works like this.... The file /etc/nsswitch.conf controls the sequence in which the various resolution methods are used : you will see a line in there like :



hosts: files nisplus nis dns



This describes the hosts look-up order. As long as 'dns' is there dns lookup should work. If you put it second then it will be overridden by manual files, e.g. /etc/hosts.



The /etc/resolv.conf then lists nameservers but you should appreciate that if you are usng dhcp and that dhcp server sends a packet including dns servers then the contents of /etc/resolv.conf will be dynamically changed the same way as the relevant interface has it's ip address configured. It's part of the 'penalty' of using dhcp.



Due to the network address translation going on here, I believe that you should leave your resolv.conf with internal addresses. Once you're sure that the dns server is really working you should be able to dig@205.x.x.x

http://www.xxxx.com

from outside and that should be routed to you by your isp. Same as, now its registered, from outside you should be able to 'ping

http://www.yourdomain.com'

and it would resolve the ip from your server. The nat is supposed to work transparently. Resolv.conf is only significant to resolving addresses for applications running on your machine, e.g. mozilla, - it doesn't affect anyone else.



Regards