Month: February 2011

Querying for DNS Glue Records (using dig)

On a project I’m working on, I need to establish if a domain has IPv6 glue records or not. If I had to do it on a once off, a whois lookup would answer that nicely:

$ /usr/bin/whois opensolutions.ie
<snip>
nserver:     dns1.dns.opensolutions.ie 87.232.1.40 2a01:268:4::40
nserver:     dns2.dns.opensolutions.ie 87.232.1.41 2a01:268:4::41
nserver:     dns3.dns.opensolutions.ie 87.232.16.61 2a01:268:3002::61

However, in this case, I will need to do it many times on many domains and do not need to have to worry about whois servers limiting the queries or parsing the output from different whois servers.

After some digging, it looks like the nameservers of TLDs return glue records in the additional section. Let’s look by example on opensolutions.ie. First, find the TLD servers for .ie:

$ dig NS ie
<snip>
;; ANSWER SECTION:
ie.                     172800  IN      NS      gns1.domainregistry.ie.
ie.                     172800  IN      NS      uucp-gw-1.pa.dec.com.
ie.                     172800  IN      NS      uucp-gw-2.pa.dec.com.
ie.                     172800  IN      NS      ns3.ns.esat.net.
ie.                     172800  IN      NS      banba.domainregistry.ie.
ie.                     172800  IN      NS      ice.netsource.ie.
ie.                     172800  IN      NS      gns2.domainregistry.ie.
ie.                     172800  IN      NS      ns-ie.nic.fr.
ie.                     172800  IN      NS      b.iedr.ie.

Now query one of these for the nameservers for opensolutions.ie:

$ dig NS opensolutions.ie @banba.domainregistry.ie.
<snip>
;; AUTHORITY SECTION:
opensolutions.ie.       172800  IN      NS      dns3.dns.opensolutions.ie.
opensolutions.ie.       172800  IN      NS      dns2.dns.opensolutions.ie.
opensolutions.ie.       172800  IN      NS      dns1.dns.opensolutions.ie.

;; ADDITIONAL SECTION:
dns1.dns.opensolutions.ie. 172800 IN    A       87.232.1.40
dns1.dns.opensolutions.ie. 172800 IN    AAAA    2a01:268:4::40
dns2.dns.opensolutions.ie. 172800 IN    A       87.232.1.41
dns2.dns.opensolutions.ie. 172800 IN    AAAA    2a01:268:4::41
dns3.dns.opensolutions.ie. 172800 IN    A       87.232.16.61
dns3.dns.opensolutions.ie. 172800 IN    AAAA    2a01:268:3002::61

As you can see, the authority section contains the nameservers for opensolutions.ie which are all on the opensolutions.ie domain. We then find the glue records for these nameservers in the additional section.

Useful RANCID Debugging Tips

I always find it difficult to find a good reference for RANCID debugging strategies and, after spending the afternoon on doing same on one installation, put together my own list.

I always find it difficult to find a good reference for RANCID debugging strategies and, after spending the afternoon on doing same on one installation, put together my own list.

Note that in the following, I use clogin and rancid which assumes a Cisco device. Change to the appropriate variations if you’re not trying to work with a Cisco.

  1. Test logging into a device: 
    > clogin rtr1.example.com
  2. Test logging into a device and a single command: 
    > clogin -t 90 -c"show version" rtr1.example.com
  3. Test logging into a device and run a sequence of commands: 
    > clogin -t 90 -c"show version;show calendar" rtr1.example.com
  4. Show what RANCID does with debugging output: 
    > rancid -d rtr1.example.com

    If the above throws some errors (especially a list of missed commands, and if you’re using TACACS, ensure you have authorisation to run all the commands RANCID tries but logging into the router as the RANCID user and executing them one at a time.

  5. Same as (4) but record all router / switch output for analysis: 
    > setenv NOPIPE YES
> rancid -d rtr1.example.com

    and then complete output can be found in the file: rtr1.example.com.raw (in this example).

  6. Run RANCID on a single switch / router tree rather than all: 
    > /usr/local/bin/rancid-run [tree]
  7. Run RANCID normally:
> /usr/local/bin/rancid-run
  1. Don’t forget that logs are available in RANCID’s logs/ directory.

IANA IPv4 Free Pool Exhausted

The IANA IPv4 free pool was exhausted today, 3 February 2011. Each of the Regional Internet Registries (RIRs) has now received one of the final five /8s.

The RIPE NCC updated yesterday that the IANA IPv4 free pool has been exhausted:

The IANA IPv4 free pool was exhausted today, 3 February 2011. Each of the Regional Internet Registries (RIRs) has now received one of the final five /8s. The RIPE NCC has been allocated 185/8.

The RIPE NCC is holding reserves totaling approximately four /8s (around 75 million individual IPv4 addresses), not including 185/8.

RIPE will most likely exhaust their reserves sometime in 2011:

As we unable to anticipate consumption rates, we cannot fully predict how long our reserves will last. However, we would like to reassure you that our supplies will not be exhausted within the coming months.