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.
A recursive DNS resolver requires that the information it recursively acquires is authoritative to return it as a response to a query; it does not make inferences.
Authority is established in DNS using SOA and NS records. The former is used to establish authority among authoritative servers, and is served from within the zone. For instance, the SOA record indicates which copy of the zone data is newer when authoritative DNS servers for some zone are doing a zone transfer. The latter is used to establish authority when querying.
When an NS record for a subdomain is in a domain, and the server that has it is not an authoritative server for the name being queried, this NS record is a delegation record. So, the recursive resolver will query for delegation records starting with the root .
. In your case, it goes up the chain toward this response from dns2.stabletransit.com.
:
subdomain.codecrab.org. 300 IN NS ns1.macmonster.co.uk.
This is a delegation record, because this data does not exist:
subdomain.codecrab.org. 300 IN NS dns2.stabletransit.com
What actually existed was this:
codecrab.org. 86400 IN NS dns2.stabletransit.com.
So, the server at dns2.stabletransit.com.
can give authoritative replies for codecrab.org.
, because the prior resolver delegated that zone to it. But it is not authoritative for subdomain.codecrab.org.
, so it cannot answer the query; it can only delegate.
DNS resolvers can of course be configured to be authoritative for any name the administrator wants. However, if they are configured to be authoritative for zones they are trying to delegate, they will instead give replies (without having the data), so this obviously is not done.
The way recursion works is simple, if not initially intuitive. The recursive resolver sends the full query to the nameservers for .
(which it has in its hint file for the root zone). The .
nameserver sends a reply, but a reply has two components we care about for this purpose: the authority section, and the answer section (there are also the additional section and the question section). The reply will contain records like:
org. 172800 IN NS b0.org.afilias-nst.org.
This tells the recursive resolver to repeat its query over there, because the zone is delegated. It also includes "glue" in the additional section giving the IP addresses of the nameservers in the authority section, beacuse it knows you won't be able to find the nameserver to query it otherwise. This is an administrative decision in managing DNS; if glue records are not present the recursive resolver will query the AAAA
or A
records for one of the authoritative servers before proceeding.
So, you may notice that when you send your query IN NS subdomain.codecrab.org.
to the last delegation, dns2.stabletransit.com.
, the reply looks like this:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35461
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;subdomain.codecrab.org. IN NS
;; AUTHORITY SECTION:
subdomain.codecrab.org. 300 IN NS ns2.macmonster.co.uk.
subdomain.codecrab.org. 300 IN NS ns1.macmonster.co.uk.
;; Query time: 104 msec
;; SERVER: 65.61.188.4#53(65.61.188.4)
;; WHEN: Sat Sep 28 14:50:45 MDT 2013
Notice how you get neither an additional section nor an answer section (but also NOERROR
for the return status). This is because the record is a delegation to ns2.macmonster.co.uk.
for subdomain.codecrab.org.
, for which dns2.stabletransit.com.
knows it is not authoritative. There is no additional section because the namesevers are over in co.uk.
and administratively it wasn't necessary to include glue because they are resolvable over there (though certainly, glue could have been included). So, to answer your query, because the answer has to come from an answer section (meaning it is identified by the replying server as an answer, coming from authority), your recursive resolver will try to find ns1.macmonster.co.uk.
, and finding it at 1.1.1.1
, will send its query over there.
Of course (as this address is in a debogon prefix) there is no nameserver there (yet). As for ns2.macmonster.co.uk.
at 2.2.2.2
, if someone at Wanadoo France were to decide that there were to be a nameserver carrying authoritative records for subdomain.codecrab.org.
and in particular:
subdomain.codecrab.org 99999999 IN NS now.go.away.or.i.will.taunt.you.a.second.time.
half the time (as often as that nameserver is chosen), the query will return now.go.away.or.i.will.taunt.you.a.second.time.
as the nameserver for your zone even though common sense would suggest that it should be ns2.macmonster.co.uk.
(and even though it was that latter nameserver which authoritatively gave that answer).
Best Answer
The difference is that yahoo.com and bbc.com are returning an
AUTHORITY
section, but stackoverflow.com and google.com are not.You could hide this from your trace with the
+noauthority
option, but it would also make the output largely useless as you would be hiding theAUTHORITY
section from the intermediate nameservers as well. (which, being delegations, is pretty much all there is to be seen unless you've set+additional
)It is up to individual nameserver implementations whether or not they wish to supply an
AUTHORITY
section in scenarios where they are not strictly required by RFC. BIND is one of the server implementations that does display this information by default, but it also provides aminimal-responses
option for disabling the behavior. I strongly recommend this option in customer facing recursion scenarios as it reduces the overhead of amplification attacks against spoofed source IPs. (sadly, BCP 38 is not as widely implemented as it needs to be)From the BIND ARM: