Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am trying to understand how the A record for crl.verisign.net works. See the trace below, doing multiple dig doesn't always return the same ip. That is fine because I thought they were using kind of round-robin load-balancing. But doing a dig without the +short flag doesn't provide all the available A records.

    $ dig @127.0.0.1 crl.verisign.net +short
    199.7.52.190

    $ dig @127.0.0.1 crl.verisign.net +short
    199.7.52.190

    $ dig @127.0.0.1 crl.verisign.net +short
    199.7.59.190

    $ dig @127.0.0.1 crl.verisign.net +short
    199.7.59.190

    $ dig @127.0.0.1 crl.verisign.net +short
    199.7.51.190

    $ dig  crl.verisign.net

    ; <<>> DiG 9.9.2-P1 <<>> crl.verisign.net
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27537
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 11, ADDITIONAL: 12

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;crl.verisign.net.              IN      A

    ;; ANSWER SECTION:
    crl.verisign.net.       1       IN      A       199.7.59.190

    ;; AUTHORITY SECTION:
    verisign.net.           29151   IN      NS      k2.nstld.net.
    verisign.net.           29151   IN      NS      m2.nstld.net.
    verisign.net.           29151   IN      NS      h2.nstld.net.
    verisign.net.           29151   IN      NS      c2.nstld.net.
    verisign.net.           29151   IN      NS      g2.nstld.com.
    verisign.net.           29151   IN      NS      l2.nstld.com.
    verisign.net.           29151   IN      NS      a2.nstld.com.
    verisign.net.           29151   IN      NS      f2.nstld.com.
    verisign.net.           29151   IN      NS      d2.nstld.net.
    verisign.net.           29151   IN      NS      j2.nstld.net.
    verisign.net.           29151   IN      NS      e2.nstld.net.

    ;; ADDITIONAL SECTION:
    a2.nstld.com.           110706  IN      A       192.5.6.31
    a2.nstld.com.           23323   IN      AAAA    2001:503:a83e::2:31
    d2.nstld.net.           18060   IN      A       192.31.80.31
    e2.nstld.net.           4014    IN      A       192.12.94.31
    f2.nstld.com.           110706  IN      A       192.35.51.31
    g2.nstld.com.           57072   IN      A       192.42.93.31
    h2.nstld.net.           143445  IN      A       192.54.112.31
    j2.nstld.net.           117704  IN      A       192.48.79.31
    k2.nstld.net.           90449   IN      A       192.52.178.31
    l2.nstld.com.           113725  IN      A       192.41.162.31
    m2.nstld.net.           22505   IN      A       192.55.83.31

    ;; Query time: 7 msec
    ;; SERVER: 172.30.3.30#53(172.30.3.30)
    ;; WHEN: Tue Mar 26 12:14:19 2013
    ;; MSG SIZE  rcvd: 451

One example I can give is when I dig google.com I get multiple IPs.

    dig google.com

    ; <<>> DiG 9.9.2-P1 <<>> google.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28707
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 4, ADDITIONAL: 5

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;google.com.                    IN      A

    ;; ANSWER SECTION:
    google.com.             152     IN      A       74.125.226.70
    google.com.             152     IN      A       74.125.226.71
    google.com.             152     IN      A       74.125.226.72
    google.com.             152     IN      A       74.125.226.73
    google.com.             152     IN      A       74.125.226.78
    google.com.             152     IN      A       74.125.226.64
    google.com.             152     IN      A       74.125.226.65
    google.com.             152     IN      A       74.125.226.66
    google.com.             152     IN      A       74.125.226.67
    google.com.             152     IN      A       74.125.226.68
    google.com.             152     IN      A       74.125.226.69

    ;; AUTHORITY SECTION:
    google.com.             253951  IN      NS      ns1.google.com.
    google.com.             253951  IN      NS      ns3.google.com.
    google.com.             253951  IN      NS      ns2.google.com.
    google.com.             253951  IN      NS      ns4.google.com.

    ;; ADDITIONAL SECTION:
    ns1.google.com.         199215  IN      A       216.239.32.10
    ns2.google.com.         112828  IN      A       216.239.34.10
    ns3.google.com.         199396  IN      A       216.239.36.10
    ns4.google.com.         199396  IN      A       216.239.38.10

    ;; Query time: 6 msec
    ;; SERVER: 172.30.3.30#53(172.30.3.30)
    ;; WHEN: Tue Mar 26 12:14:10 2013
    ;; MSG SIZE  rcvd: 351

The problem is that we are trying to whitelist this ip into our firewall and we can't do it correctly because we never which ip is the right one.

How does this domain name works?

Thanks

share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

The nameserver of verisign.net. load-balancing system only provides a single IP-address for crl.verisign.net., with a TTL (time-to-live) of 1 (1 second), thus causing your recursive resolver to always perform subsequent requests to the authoritative server when a subsequent resolution is requested.

You thus can't know all IP-addresses of crl.verisign.net., since, unlike in Google's case, only one is provided at any given time. The best guess would be to whois one of the addresses, and see which network it belongs to, and, potentially, if all other addresses are from the same network, and the network is not overly big (a subjective notion), then maybe whitelist the whole network (especially if the firewall rule is only for a certain rather unique service or port combination).

% whois 199.7.59.190
…
NetRange:       199.7.48.0 - 199.7.63.255
CIDR:           199.7.48.0/20
OriginAS:
NetName:        VGRSGTLD-15
…

However, in general, such whitelisting, where you manually determine the IP-addresses that you have to whitelist, is doomed as a very fragile exercise, since the other party has no clue of such whitelisting on your part, and may, at any moment, change their configuration, resulting in a required update of the rules on your firewall.

Your best bet would be to email someone at verisign.net., and ask them whether you could whitelist their service in a firewall, and which IP-addresses or networks are guaranteed to do the job.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.