Archive for July, 2007

IP CIDR FORMAT

Posted: July 9, 2007 in IP

CIDR format?

Contributed by Dru Lavigne, DNSstuff Contributing Writer

Wednesday, 28 March 2007

When reading IP addresses you’ll often see the subnet mask written in CIDR format, meaning there is a / followed by a

number.

That CIDR mask represents a whole block of addresses; the smaller the number, the larger the amount of addresses in

the block. The IP address given with the mask is usually the starting address in the block; the following chart can help

you to quickly find the last address in that block: Chart 1: Last Address in a CIDR block Mask Octet 1

Octet 2 Octet 3 Octet 4 /8 stays the same 255 255 255 /9 stays the

same add 127 255 255 /10 stays the same add 63 255 255 /11

stays the same add 31 255 255 /12 stays the same add 15 255 255

/13 stays the same add 7 255 255 /14 stays the same add 3 255 255

/15 stays the same add 1 255 255 /16 stays the same stays the same

255 255 /17 stays the same stays the same add 127 255 /18 stays the

same stays the same add 63 255 /19 stays the same stays the same add 31

255 /20 stays the same stays the same add 15 255 /21 stays the same

stays the same add 7 255 /22 stays the same stays the same add 3 255

/23 stays the same stays the same add 1 255 /24 stays the same stays the

same stays the same 255 /25 stays the same stays the same stays the same

add 127 /26 stays the same stays the same stays the same add 63 /27 stays

the same stays the same stays the same add 31 /28 stays the same stays the

same stays the same add 15 /29 stays the same stays the same stays the same

add 7 /30 stays the same stays the same stays the same add 3 A few examples

will familiarize you with the chart. In the Country IP Range Lookup tool, I’ll lookup the blocks of addresses which have

been assigned to the Bahamas: # # IP Ranges for BS [Bahamas] # Generated by http://www.DNSstuff.com using data last

updated on 20 Mar 2007. # We highly discourage people from blocking E-mail from entire countries. # 24.231.32.0/19

24.244.128.0/18 64.150.192.0/19 65.75.64.0/18 69.4.160.0/20 216.137.0.0/20 # END The first assigned block of

addresses is 24.231.32.0/19. From the chart, /19 looks like this: Mask Octet 1 Octet 2 Octet 3

Octet 4 /19 stays the same stays the same add 31 25 Meaning the end block be this: 24. 231. (32+31=) 63. 255 Therefore, this /19 block includes 24.231.63.255. Let’s take a look at the next address block, 24.244.128.0/18: Mask Octet 1 Octet 2

Octet 3 Octet 4 /18 stays the same stays the same add 63 255 (128+63=) 191. 255 This /18 address block includes all of the addresses between 24.244.128.0 and 24.244.191.255.

Lastly, try the address block 69.4.160.0/20: Mask Octet 1 Octet 2 Octet 3 Octet 4 /20

stays the same stays the same add 15 255 69. 4. block includes all of the addresses between 69.4.160.0 and 69.4.175.255. Now that you know the starting and ending

addresses, are you able to visualize how many addresses lie in between? IP addresses are 32 bits long and the CIDR

mask tells you how many bits have already been used. This means if you subtract the CIDR mask value from 32 you are

left with the number of bits that are still available to create IP addresses. For the address 24.231.32.0/19 there are 13

(32-19) bits available for addresses. Since bits have two possible values (a bit can either be set to 1 or be set to 0) there

are 2 to the power of 13, or 8192, possible addresses found within this address block. That seems like a lot of addresses

so take a closer look at the starting and ending addresses: 24.231.32.0 to 24.231.63.255 That range represents the

following: 24.231.32.0, 24.231.32.1, 24.231.32.2, etc. up to 24.231.32.25524.231.33.0, 24.231.33.0, etc. up to

24.231.33.25524.231.34.0, 24.231.34.0, etc. up to 24.231.34.255 See how we continue to cycle through all of the

possibilities between 0 and 255 in the 4th octet as the 3rd octet increases by one? This will continue until the 3rd octet

has cycled up to 63. Another way to visualize this is to consider that the 3rd octet will cycle through 32 numbers (32

through 63) as the 4th octet cycles through 256 numbers (0 through 255). Not surprisingly, 32 times 256 is 8192. You

can save yourself some math by referring to Chart 2: Chart 2: Number of IP addresses per CIDR address block

CIDR Mask Number of IP Addresses /8 16,777,216 /9 8,388,608 /10

4,194,304 /11 2,097,152 /12 1,048,576 /13 524,288 /14 262,144

/15 131,072 /16 65,536 /17 32,768 /18 16,384 /19 8192

/20 4096 /21 2048 /22 1024 /23 512 /24 256 /25 128

/26 64 /27 32 /28 16 /29 8 /30 4 So, how many IP

addresses are available for the Bahamas? There are two /18s, two /19s and two /20s: (16384*2) + (8192*2) + (4096*2)

= 57,344 Looks like there are 57,344 addresses in the 6 address blocks assigned to the Bahamas. Note: often when

you use a CIDR/subnet mask calculator you will see two subtracted from the number of possible addresses. This is

required when you assign IP addresses to hosts as you have to reserve one address for the subnet and one address for

the broadcast.

member.dnsstuff.com

http://member.dnsstuff.com/rc Powered by Joomla! Generated: 9 July, 2007, 00:26

DNS 101

Posted: July 9, 2007 in DNS

DNS 101

Contributed by Dru Lavigne, DNSstuff Contributing Writer

Friday, 23 March 2007

While you probably use DNS every day, in fact you used DNS to find the webserver hosting this article, you may not be

clear on how DNS works.

This article will cover some of the terminology used in DNS. ICANN Think of DNS as a global telephone book that

computers know how to access. But instead of matching names to phone numbers, the global DNS keeps matches

computer hostnames to IP addresses. This allows you to type a name such as http://www.google.com into your web browser

and make a connection to the IP address 72.14.203.104. It’s important to ensure that the global DNS contains accurate

information and that it avoids duplicate IP addresses or hostnames. This is the job of ICANN. From their FAQ page:

“The Internet Corporation for Assigned Names and Numbers (ICANN) is responsible for managing and

coordinating the DNS to ensure that every address is unique and that all users of the Internet can find all valid

addresses. It does this by overseeing the distribution of unique IP addresses and domain names. It also ensures that

each domain name maps to the correct IP address.” root servers and TLDs While the DNS is a global

database, its contents have been distributed using a hierarchical format. The format looks like this: Root . Top level

domain . Second level domain . Hostname When you compare that format to a Fully Qualified Domain Name (FQDN) it

appears backwards. For example, in the FQDN http://www.google.com:- www is the hostname- google is the second level

domain (SLD)- com is the top level domain (TLD)

While resolving that FDQN to find its IP address, DNS will:

– query a root DNS server to find the IP address of the DNS server hosting the com portion of the database

– query the com DNS server to find the IP addresss of the DNS server hosting the google portion of the database

– query the google DNS server to find the IP address assocated with teh host named www The list of DNS root servers

can be found at root-servers.org; all DNS servers contain a copy of the file listing the root servers. You don’t see the root

in a FQDN as it is considered to be a silent or implicit dot at the end. The Internet Assigned Numbers Authority (IANA)

maintains the lists of TLDs. Some of the TLDs are by country name, such as us, uk, de, and jp. Others are the original

TLDs such as com and org, and the newer TLDs such as biz and name. Remember, the TLD is always the last part of a

FQDN. zone and resource records The SLD, or the middle part of a FQDN, is the portion that is purchased from a

Registrar. For example, Google had to purchase and register the google name. (You can see who purchased the name

and when by querying WHOIS—see the WHOIS article for details). When a name is registered, the Registrar is

responsible for adding the new entry to the TLD database. In other words, when google was registered, the Registrar

added an entry to the com database pointing to the address of the google DNS server. Once an SLD is registered, the

registrant becomes responsible for maintaining that portion of the DNS database and it will contain the DNS entries for

the hosts belonging to the SLD. That area of responsibility is known as a DNS zone which is why you’ll often see DNS

configuration files referred to as zone files. When configuring the zone, the DNS administrator adds entries describing

the hosts that need to be found via DNS. These entries are known as resource records as they describe the type of

resource. For example, an A resource record matches an IP address to a hostname, an MX resource record indicates

that the host is a mail server for the domain, and an NS record indicates that the host is a DNS server for the domain.

(additional resource records are described in detail in the resource records article) TCP vs UDP on port 53

The DNS protocol uses port 53 for communications. Interestingly, it uses both the UDP and TCP transports. As a general

rule of thumb:

– UDP is used when an FQDN needs to be resolved into an IP address

– TCP is used by the DNS servers within a zone to make sure they all have the most recent copy of the zone file; if a

DNS server has an out-dated version, it will request a zone transfer over TCP 53

– Occassionaly the information needed to resolve an IP address is too large to ship in a UDP packet and is sent in a TCP

packet instead When configuring a firewall, UDP 53 has to be left open so FQDNs can be resolved to IP addresses.

However, many administrators block TCP 53 entirely or restrict it to the IP addresses of that zone’s DNS servers. This is

because a DNS server outside of the zone has no legitimate reason to ask for a zone transfer. However, blocking TCP

53 will prevent the occasional name resolution packet that used TCP from entering the network. This is the reason why

you will see a warning in “TCP Allowed” section of the DNS Report if TCP 53 is being blocked by a firewall.

member.dnsstuff.com

http://member.dnsstuff.com/rc Powered by Joomla! Generated: 9 July, 2007, 00:20

Considerations when Configuring DHCP

Contributed by Dru Lavigne, DNSstuff Contributing Writer

Tuesday, 15 May 2007

When configuring a network to use DHCP for IP address allocation, there are several points an administrator needs to

keep in mind.

Spending a few moments to map out your network’s addressing needs can simplify the process of configuring the

DHCP servers. 1. Determine the DHCP scope(s): In DHCP terminology, a scope is equivalent to a subnet. The

number of scopes you will configure is dependent upon the subnet mask running on your network. If your network is not

running the default subnet mask, manually calculate or use a subnet calculator to determine the number of subnets and

the valid host range for each subnet.

For example, the network 192.168.1.0/27 creates 8 subnets (or DHCP scopes) each containing 30 host addresses. The

names of those scopes and the valid addresses available within each scope can be seen in Figure 1: Figure 1: Scopes

for 192.168.1.0/27 Scope Address Addresses Available for Lease on that Scope 192.168.1.0 192.168.1.1 –

192.168.1.30 192.168.1.32 192.168.1.33 – 192.168.1.62 192.168.1.64 192.168.1.65 – 192.168.1.94 192.168.1.96

192.168.1.97 – 192.168.1.126 192.168.1.128 192.168.1.129 – 192.168.1.158 192.168.1.160 192.168.1.161 –

192.168.1.190 192.168.1.192 192.168.1.193 – 192.168.1.222 2. Determine the exclusion ranges: Most subnets will

have at least one IP address which is inappropriate to lease out to hosts. For example, every subnet needs a default

gateway and the address used on the gateway should be statically assigned and excluded from the range of addresses

available for lease. Depending upon your network layout, you may also have some subnets containing other statically

assigned addresses such as those for your DNS servers, web servers, mail servers, or other servers. 3. Decide if you

will use reservations: An alternative to exclusion ranges is to use reservations. Rather than statically assigning the IP

addresses of your servers you can instead choose to reserve those addresses within DHCP. For example, you can tell

DHCP to permanently lease the address 192.168.1.1 to a specified server; that server will always receive that address

and that address is not available to other hosts within the scope. Note that reservations associate the host’s MAC

address to the IP address so you will need to remember to change the reservation if you ever replace the NIC within that

host. 4. Determine the address pool: The pool is the IP addresses available for DHCP clients to lease. The pool will

be the addresses in the scope minus any exclusion ranges and reserved addresses. 5. Decide upon the Option Types:

DHCP is capable of leasing any type of IP addressing information, not just the host’s IP address, subnet mask, and

default gateway addresses. Options include DNS servers, WINS servers, MTU, TTL, SMTP servers, and so on. The

complete list of available options can be found in RFC 2132. 6. Determine which options are global and which are local:

Once you know which options are appropriate to your network go through each option one at a time and ask yourself

“should all hosts receive this option or is it specific to this subnet?”. For example, all hosts will most likely use the same

DNS servers so the IP addresses of the primary and secondary DNS servers can be configured as global options.

However, the default gateway address is unique to each subnet. Every subnet will need a default gateway address, but

the actual address used differs by subnet, making this a local option. Take care to use the correct gateway address on

each subnet. 7. Determine if you need any DHCP relay agents: Some of the DHCP packets sent out by a client in order

to receive a DHCP lease are broadcast packets. If the DHCP server is on a different subnet than the DHCP client, it will

never receive that broadcast packet as routers don’t forward broadcasts to other subnets–meaning the DHCP client will

fail to get an IP address. If you have subnets containing DHCP clients but not a DHCP server, you will need to run DHCP

relay agent software on those subnets. 8. Prepare your firewall rules: If there are any firewalls between the DHCP

clients and the DHCP server, you will need to create rules to allow the DHCP packets. When creating your rules, keep

the following points in mind: – the DCHP client uses UDP port 68 – the DHCP server uses UDP point 67 – the first

time a DHCP client requests a least it doesn’t have an IP address and it doesn’t know the IP address of the DHCP server-

-meaning it uses IP address 0.0.0.0 as the source IP address and 255.255.255.255 as the destination IP address The

time you take writing out these considerations is well spent–your notes will make the actual DHCP configuration a breeze

and provide the added bonus of having documentation you can refer to when troubleshooting your IP network.

member.dnsstuff.com

http://member.dnsstuff.com/rc Powered by Joomla! Generated: 8 July, 2007, 23:58

DNS Security Basics

Posted: July 9, 2007 in DNS
Written by Dru Lavigne, DNSstuff Contributing Writer   
Wednesday, 25 April 2007
When configuring DNS for a network, there are several things an administrator can do to increase the security of the DNS servers. These include: Restricting Zone TransfersA DNS zone is the database containing the DNS records for a network. Every DNS zone needs a primary DNS server and at least one secondary DNS server. It is important that each of the DNS servers contains the most recent version of the zone; the process that accomplishes this is known as a zone transfer.It is good security practice to restrict zone transfers to the IP addresses of the DNS servers in your own network. For example, on the primary DNS server, input the IP addresses of the secondary DNS server(s)–this will prevent zone transfer requests from DNS servers or clients outside of your own network. On the secondary DNS server(s), input the IP address of the primary DNS server—this will prevent them from accepting zone information from DNS servers outside of your own network.Implementing Split DNSMost networks provide an internal DNS server which contains the DNS records for all of the hosts within that network. From a security perspective, you probably don’t want the world at large to know how many internal hosts you have and what their hostnames are, especially if those hostnames are descriptive. However, you do want the world to be able to find the DNS records for your web and mail servers.Split DNS means that the zone on your external DNS server contains just the DNS records for those hosts you want the world to access—in other words, this server only contains a small sub-set of your DNS zone. The internal DNS server contains the full zone. It is important that the DNS server configurations ensure that the internal and external DNS servers do not share their zone information via zone transfers.Using Separate NetworksWhere you place your DNS servers is also an important consideration. Placing all of your DNS servers on the same network or subnet is a bad idea, something that Microsoft learned when they fell victim to a DNS attack in 2001. Having DNS located on geographically dispersed networks greatly increases your DNS’ fault tolerance.It is an easy matter for both yourself and an attacker to determine if your network is vulnerable to this type of attack. Here is the DNS lookup for microsoft.com:How I am searching:Searching for microsoft.com NS record at j.root-servers.net [192.58.128.30]: Got referral to G.GTLD-SERVERS.NET. (zone: com.) [took 84 ms]Searching for microsoft.com NS record at G.GTLD-SERVERS.NET. [192.42.93.30]: Reports ns1.msft.net. [took 84 ms]Response:

Domain Type Class TTL Answer
microsoft.com. NS IN 172800 ns1.msft.net.
microsoft.com. NS IN 172800 ns2.msft.net.
microsoft.com. NS IN 172800 ns3.msft.net.
microsoft.com. NS IN 172800 ns4.msft.net.
microsoft.com. NS IN 172800 ns5.msft.net.
ns1.msft.net. A IN 172800 207.68.160.190
ns2.msft.net. A IN 172800 65.54.240.126
ns3.msft.net. A IN 172800 213.199.161.77
ns4.msft.net. A IN 172800 207.46.66.126
ns5.msft.net. A IN 172800 65.55.238.126

 This output shows that there are 5 DNS servers as there are 5 NS records. Note that every single DNS server is on a separate network: the first is on network 207.68.160.0, the next on 65.54.0.0, the next on 213.199.161.0, the next on 207.46.66.0, and the last on 65.55.0.0.Implementing TSIGTSIG is short for Transaction SIGnatures and it provides an additional mechanism for securing zone transfers. An attacker could spoof an IP address, meaning he could bypass your zone configuration restrictions in order to inject false DNS records into your zone or to transfer your zone information. TSIG requires your DNS servers to use a shared key; since the attacker would not have a copy of this key, his transaction request would be refused.Here are instructions for setting up TSIG on BIND and Windows 2000. Note that Microsoft refers to TSIG as Secure Dynamic Update.Configuring DNSSECWhile TSIG will require the DNS servers to authenticate to each other before they complete a transaction, it won’t protect you should an attacker compromise a DNS server in order to gain access to the key.DNSSEC stands for DNS SECurity Extensions. It provides additional security measures; for example, it uses public key cryptography instead of shared secrets for authentication and each transaction packet is digitally signed. In other words, every zone has its own key pair. The DNS servers for that zone use the private key to sign data and any DNS client can use the zone’s public key to verify that that data did indeed come from your zone. This can help prevent the return of false data introduced by an attacker.DNSSEC is available with Windows 2003 and BIND versions 8.2 and higher. DNSSEC.net has a large repository of resources regarding DNSSEC.

LINUX BANDWIDTH CONTROL WITH CBQ

Posted: July 8, 2007 in LINUX

LINUX BANDWIDTH CONTROL WITH CBQ  Think your friend has a Linux box which is running Red Hat 8.0 or 9.0 and the CBQ packege is installed there. If CBQ is not present, ask him to install it from the Linux CD. I am also guessing that, His external NIC is eth0 and internal NIC is eth1. After installation, ask your friend to edit the Example configuration file of CBQ.
#cd /etc/sysconfig/cbq
There he will find a file named cbq_0000.example.
Ask him to do the followings…
#cp cbq_0000.example cbq_0032.clients
#cp cbq_0000.example cbq_0032.cybercafe
#vi cbq_0032.cybercafe 

Then ask him to edit the file like this.. DEVICE=eth1,10Mbit,1Mbit
RATE=32Kbit
WEIGHT=3Kbit
PRIO=5
RULE=192.168.1.11
RULE=192.168.1.12
RULE=192.168.1.13
……………………….
……………………….
……………………….
RULE=192.168.1.26
Done for the Cyber cafe

Next for the Clients..
#vi cbq_0032.clients

Edit the file like this..

DEVICE=eth1,10Mbit,1Mbit
RATE=32Kbit
WEIGHT=3Kbit
PRIO=5
RULE=192.168.1.101
RULE=192.168.1.102
RULE=192.168.1.103
……………………….
……………………….
……………………….
RULE=192.168.1.110

Done.

If everything goes ok, then exicute the command..
#cbq stop
#cbq start

And if you want to Dedicate 2 or 3 kbps to any IP, just make your own configuration file.

Its too easy. 🙂