Latest Updates: networking

  • “Ping Hostname” Returning an IPv6 Address Instead of IPv4? (Windows)

    23:05 on May 31, 2012 | 0 Comments
    Tags: networking, ,

    On Windows based PCs and Servers, and where IPv6 is enabled on one of the network adapters, you may find that when you do a:

    ping name-of-host

    … you get an IPv6 address returned in the results.  But what if you want to test IPv4 connectivity?  You can add a -4 switch to the ping command to force it to use IPv4 as follows:

    ping -4 name-of-host

    Ping will now ping the IPv4 address as opposed to the IPv6.

    It’s worth noting, that if you do want to test for IPv6 connectivity, you can add a -6 switch to force that:

    ping -6 name-of-host
     
  • CIDR, Subnet Masks, and Usable IP Addresses Quick Reference Guide (Cheat Sheet)

    10:29 on August 26, 2011 | 1 Comments
    Tags: networking

    A quick reference Subnet and CIDR guide.

    What’s a /28?  How many IPs do I get to use with a /26?  Well, see the table below!
    Usable IPs is the Total IPs minus the Network and Broadcast IPs.

     

    CIDR

    Subnet Mask

    Total IPs

    Usable IPs

    /32 255.255.255.255 1 1
    /31 255.255.255.254 2 0
    /30 255.255.255.252 4 2
    /29 255.255.255.248 8 6
    /28 255.255.255.240 16 14
    /27 255.255.255.224 32 30
    /26 255.255.255.192 64 62
    /25 255.255.255.128 128 126
    /24 255.255.255.0 256 254
    /23 255.255.254.0 512 510
    /22 255.255.252.0 1024 1022
    /21 255.255.248.0 2048 2046
    /20 255.255.240.0 4096 4094
    /19 255.255.224.0 8192 8190
    /18 255.255.192.0 16,384 16,382
    /17 255.255.128.0 32,768 32,766
    /16 255.255.0.0 65,536 65,534
    /15 255.254.0.0 131,072 131,070
    /14 255.252.0.0 262,144 262,142
    /13 255.248.0.0 524,288 524,286
    /12 255.240.0.0 1,048,576 1,048,574
    /11 255.224.0.0 2,097,152 2,097,150
    /10 255.192.0.0 4,194,304 4,194,302
    /9 255.128.0.0 8,388,608 8,388,606
    /8 255.0.0.0 16,777,216 16,777,214
    /7 254.0.0.0 33,554,432 33,554,430
    /6 252.0.0.0 67,108,864 67,108,862
    /5 248.0.0.0 134,217,728 134,217,726
    /4 240.0.0.0 268,435,456 268,435,454
    /3 224.0.0.0 536,870,912 536,870,910
    /2 192.0.0.0 1,073,741,824 1,073,741,822
    /1 128.0.0.0 2,147,483,648 2,147,483,646
    /0 0.0.0.0 4,294,967,296 4,294,967,294


     
  • Using dig to Query a Specific DNS Server (Name Server) Directly (Linux, BSD, OSX)

    16:54 on August 12, 2011 | 0 Comments
    Tags: , , networking, ,

    There may be occasions when you wish to query a DNS server directly.  I often do it before changing DNS servers for a domain; I’ll setup the new records on the new DNS servers, and then query them directly to ensure they are returning the correct records.

    I recommend that anyone running DNS services for any domain looks into these commands – they’re very useful, especially when you’re making changes.

    dig has a feature which allows you to specify a name server along with the record you want to query.

    For example, one of the DNS servers for droptips.com is “ns.123-reg.co.uk”.  We can query this server directly, for the www record by doing the following:

    $ dig droptips.com @ns.123-reg.co.uk

    You’ll get some output with a section titled Answer Section:

    ;; ANSWER SECTION:
     droptips.com.       86400   IN      A       89.238.134.5

    This details the result (89.238.134.5) and also the TTL for the record (in seconds).  The TTL is important, as this is how long caching DNS servers should cache the result for – in this case, 86400 seconds which is 1 day. Using this command to find out a TTL value for a particular record is also quite useful, especially if you’re investigating DNS cache issues.

    You can also do the same to check other records such as MX records, by simpling adding the record type to the command.  For example, to get the MX records ns1.google.com is reporting for google.co.uk:

    $ dig MX google.co.uk @ns1.google.com

    … with the results:

    ;; ANSWER SECTION:
     google.co.uk.           10800   IN      MX      10 google.com.s9a2.psmtp.com.
     google.co.uk.           10800   IN      MX      10 google.com.s9b1.psmtp.com.
     google.co.uk.           10800   IN      MX      10 google.com.s9b2.psmtp.com.
     google.co.uk.           10800   IN      MX      10 google.com.s9a1.psmtp.com.

    You can see in this instance, that the TTL is 10800 seconds which is 3 hours, and all MX records have the same priority level of 10.