Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
dig @server foobar +trace +recurse
948 views
Skip to first unread message
Anne Bennett
Jul 8, 2015, 6:34:39 PM7/8/15
to bind-...@lists.isc.org
I've been trying to debug a problem with dig, and it has finally
occurred to me that, if I understand this correctly, the "+trace"
option essentially overrides the @server specification, except for
the initial query for the root zone nameservers. (I was using
"+showsearch +trace +recurse".)
Is my understanding correct?
If it is, it might be helpful to add a quick note to the "dig"
manpage, perhaps under "SIMPLE USAGE", "server", something like:
Note that if when the +trace and +recurse options are in
use, only the initial query for the root zone uses the
server specified by "server" (or in /etc/resolv.conf);
subsequent queries use the authoritative servers in the
chain of delegation.
Anne.
--
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
an...@encs.concordia.ca +1 514 848-2424 x2285
Mark Andrews
Jul 8, 2015, 6:50:42 PM7/8/15
to Anne Bennett, bind-...@isc.org
In message <13180.14...@vindemiatrix.encs.concordia.ca>, Anne Bennett writ
es:
>
> I've been trying to debug a problem with dig, and it has finally
> occurred to me that, if I understand this correctly, the "+trace"
> option essentially overrides the @server specification, except for
> the initial query for the root zone nameservers. (I was using
> "+showsearch +trace +recurse".)
>
> Is my understanding correct?
>
> If it is, it might be helpful to add a quick note to the "dig"
> manpage, perhaps under "SIMPLE USAGE", "server", something like:
>
> Note that if when the +trace and +recurse options are in
> use, only the initial query for the root zone uses the
> server specified by "server" (or in /etc/resolv.conf);
> subsequent queries use the authoritative servers in the
> chain of delegation.
Given +trace isn't "simple usage" (dig @server name type), why would
> I've been trying to debug a problem with dig, and it has finally
> occurred to me that, if I understand this correctly, the "+trace"
> option essentially overrides the @server specification, except for
> the initial query for the root zone nameservers. (I was using
> "+showsearch +trace +recurse".)
>
> Is my understanding correct?
>
> If it is, it might be helpful to add a quick note to the "dig"
> manpage, perhaps under "SIMPLE USAGE", "server", something like:
>
> Note that if when the +trace and +recurse options are in
> use, only the initial query for the root zone uses the
> server specified by "server" (or in /etc/resolv.conf);
> subsequent queries use the authoritative servers in the
> chain of delegation.
one say that in the simple usage section? +trace states that it is
going to talk to each server in turn.
+[no]trace
Toggle tracing of the delegation path from the root name servers
for the name being looked up. Tracing is disabled by default. When
tracing is enabled, dig makes iterative queries to resolve the name
being looked up. It will follow referrals from the root servers,
showing the answer from each server that was used to resolve the
lookup.
+dnssec is also set when +trace is set to better emulate the
default queries from a nameserver.
Mark
> Anne.
> --
> Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1
> M8
> an...@encs.concordia.ca +1 514 848-2424 x22
> 85
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Anne Bennett
Jul 8, 2015, 8:54:12 PM7/8/15
to bind-...@isc.org
Mark Andrews <ma...@isc.org> responds to my suggestion:
>> [...] the "+trace"
>> option essentially overrides the @server specification, except for
>> the initial query for the root zone nameservers. [...]
>>
>> Is my understanding correct?
>>
>> If it is, it might be helpful to add a quick note to the "dig"
>> manpage, perhaps under "SIMPLE USAGE", "server", something like:
[deleted]
>> Is my understanding correct?
>>
>> If it is, it might be helpful to add a quick note to the "dig"
>> manpage, perhaps under "SIMPLE USAGE", "server", something like:
> Given +trace isn't "simple usage" (dig @server name type), why would
> one say that in the simple usage section?
> +trace states that it is
> going to talk to each server in turn.
while I was in the throes of trying to figure out my problem,
this managed to somehow escape me for quite a while. It would
still be nice to clarify it to avoid other people having the
same problem.
How about this:
> +[no]trace
> Toggle tracing of the delegation path from the root name servers
> for the name being looked up. Tracing is disabled by default. When
> tracing is enabled, dig makes iterative queries to resolve the name
> being looked up. It will follow referrals from the root servers,
> showing the answer from each server that was used to resolve the
> lookup.
initial query for the root zone name servers.
> +dnssec is also set when +trace is set to better emulate the
> default queries from a nameserver.
--
John Miller
Jul 8, 2015, 11:56:03 PM7/8/15
to Bind Users Mailing List
For my part, I'd be curious to know what sort of problem you're trying to solve with dig. We might be able to shed a little more light on what the best command would be for you.
The +recurse gets overridden when you use +trace:
+[no]recurse
... Recursion is automatically disabled when the
+nssearch or +trace query options are used.
The +recurse gets overridden when you use +trace:
+[no]recurse
... Recursion is automatically disabled when the
+nssearch or +trace query options are used.
so you're getting iterative queries whether you want them or not: +trace means you're treating yourself as a recursive nameserver, and the RD bit isn't set on your queries.
If you send a single query to a remote nameserver, you're only going to get a single response--that's how DNS works. So if you're looking to see the chain of lookups that a remote recursive nameserver takes to reach its final response, you can run dig +trace from the remote nameserver, or you could run a series of dig @server +norecurse <hostname> queries to get what you're looking for.dig @8.8.8.8 trombone.org +showsearch
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @8.8.8.8 trombone.org +showsearch
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9742
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
versus
dig @8.8.8.8 trombone.org
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @8.8.8.8 trombone.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36891
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
Even after flushing Google's cache (https://developers.google.com/speed/public-dns/cache), I still get the same response. Does anyone have insight on +showsearch, other than the following ;-)
BUGS
There are probably too many query options.
BUGS
There are probably too many query options.
John
On Wed, Jul 8, 2015 at 6:34 PM, Anne Bennett <an...@encs.concordia.ca> wrote:
I've been trying to debug a problem with dig, and it has finally
occurred to me that, if I understand this correctly, the "+trace"
option essentially overrides the @server specification, except for
the initial query for the root zone nameservers. (I was using
Anne Bennett
Jul 9, 2015, 2:17:06 AM7/9/15
to John Miller, Bind Users Mailing List
> For my part, I'd be curious to know what sort of problem
> you're trying to solve with dig.
zone depending where I queried from, but the differences
didn't match what I expected based on an internal/external view
classification of the client resolver. I eventually realized
that for the data I was examining, my resolvers (which have
access to the outside world) could randomly select an external
authoritative nameserver for my parent zone (external view),
or an internal one (internal view), hence the difference.
And of course there was caching involved as well, so data seemed
to toggle randomly back and forth on my various resolvers.
It's by tracing the queries down from the root zone several
times with "dig +trace" that it finally hit me what was going
on, and in retrospect it's obvious. At first I had been looking
for some kind of race condition with delegation data from the
grandparent zone getting cached, and then being overridden by
my parent zone's own NS records. At that point, I was trying
to use @server to try to affect that server's cache by forcing
it to pull certain data into its cache. But it turns out that
it isn't a child overriding its parents delegations that was
the "problem"; it's the fact that as an internal client, I am
able to access external views as well. And in the process
of investigating all this, I realized that of course if I
use +trace, all queries after the first one will *not* use
the @server. Duh. I just thought I might save someone else
the muddy thinking by offering a clarification for the manpage.
As for the problem itself, I'll probably fix it by setting up
a forwarding zone for my parent zone on my resolvers, to make
sure that I always get the internal view for their data.
> We might be able to shed a little more light on what the
> best command would be for you.
> The +recurse gets overridden when you use +trace:
>
> +[no]recurse
> ... Recursion is automatically disabled when the
> +nssearch or +trace query options are used.
>
> so you're getting iterative queries whether you want them or not: +trace
> means you're treating yourself as a recursive nameserver,
to "treat myself as a recursive nameserver", so I stuck in +recurse,
which was the wrong thing to do - fortunately it didn't work. ;-)
> If you send a single query to a remote nameserver, you're only going to get
> a single response--that's how DNS works. So if you're looking to see the
> chain of lookups that a remote recursive nameserver takes to reach its
> final response, you can run dig +trace from the remote nameserver, or you
> could run a series of dig @server +norecurse <hostname> queries to get what
> you're looking for.
I got. That's what comes from not looking seriously at DNS
stuff for months at a time and then trying to reload a lot of
context all at once!
> I admit ignorance on the +showsearch option: I'm not seeing the query flags
> change, nor am I seeing any different output when I run:
>
> dig @8.8.8.8 trombone.org +showsearch
> versus
> dig @8.8.8.8 trombone.org
[...]
> Does anyone have insight on +showsearch,
I'm sure someone does, but it's not me - I've bumped into enough
walls for one day! :-)
Tony Finch
Jul 9, 2015, 6:01:56 AM7/9/15
to Anne Bennett, Bind Users Mailing List
Anne Bennett <an...@encs.concordia.ca> wrote:
>
> As for the problem itself, I'll probably fix it by setting up
> a forwarding zone for my parent zone on my resolvers, to make
> sure that I always get the internal view for their data.
Note that the target server of a forward zone should offer recursive
>
> As for the problem itself, I'll probably fix it by setting up
> a forwarding zone for my parent zone on my resolvers, to make
> sure that I always get the internal view for their data.
service. You will have problems if the target is authoritative-only, and
serves the zone you are forwarding but not some child zone. Better to use
static-stub in that case; that makes BIND do normal iterative resolution
except it overrides the NS records for just that zone, not its children.
(We make our recursive servers authoritative for our zones to avoid
problematic dependency cycles - the kind of horror you find out about
when trying to recover from a power outage.)
Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
South Utsire: Northwesterly gale 8 or severe gale 9, decreasing 5 to 7 later.
Rough or very rough, occasionally moderate later. Showers. Good.
Bob Harold
Jul 9, 2015, 10:09:37 AM7/9/15
to John Miller, Bind Users Mailing List
dig @8.8.8.8 trombone.org +showsearch
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @8.8.8.8 trombone.org +showsearch
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9742
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0versus
dig @8.8.8.8 trombone.org
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @8.8.8.8 trombone.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36891
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0Even after flushing Google's cache (https://developers.google.com/speed/public-dns/cache), I still get the same response. Does anyone have insight on +showsearch, other than the following ;-)
...
"showsearch" has nothing to do with iteration or recursion. "showsearch" is related to the "search list" that is used if the domain name you are searching for is not fully qualified (does not end in a dot). Only useful if /etc/resolv.conf has a "search" list (or "domain" has more than two labels which creates an implied search list). See man page for resolv.conf for more.
Anne Bennett
Jul 9, 2015, 10:39:17 AM7/9/15
to Bind Users Mailing List
Tony Finch <d...@dotat.at> recommends:
>> As for the problem itself, I'll probably fix it by setting up
>> a forwarding zone for my parent zone on my resolvers, to make
>> sure that I always get the internal view for their data.
>
> Note that the target server of a forward zone should offer recursive
> service. You will have problems if the target is authoritative-only, and
> serves the zone you are forwarding but not some child zone.
> Better to use
> static-stub in that case; that makes BIND do normal iterative resolution
> except it overrides the NS records for just that zone, not its children.
by my resolvers (which are authoritative for my zones).
> (We make our recursive servers authoritative for our zones to avoid
> problematic dependency cycles - the kind of horror you find out about
> when trying to recover from a power outage.)
(days!) planned power outage lately for major electrical work,
so my careful redundancy planning has been well tested. :-)
The local resolvers are totally standalone - no dependencies
on directory services, NFS, or anything but the presence of
the local network and power.
Now back to the static-stub zones... reading the ARM, I see that
I cannot use "server-names" because the internal-view servers
for my parent zone are in the zone itself, thus I must use
"server-addresses". But I'm told that if I specify:
zone example.com {
type static-stub;
allow-query { APPROPRIATE_ACL_HERE };
server-addresses { 192.0.2.1; 192.0.2.2; };
};
then the following RR's are internally configured:
example.com. NS example.com.
example.com. A 192.0.2.1
example.com. A 192.0.2.2
But my parent (call it "example.com") *has* an A record;
they use it for their web server, I believe. Will the above
internally configured A RR not interfere with getting the
correct data for "host -t a example.com"? Or does the sentence
"These records are internally used to resolve names under the
static-stub zone" imply that they are used *only* for this
purpose, and never leaked out?
I guess I can test that in any case; just being paranoid!
Thanks for your suggestion; static-stub is indeed a better solution.
Tony Finch
Jul 9, 2015, 10:48:40 AM7/9/15
to Anne Bennett, Bind Users Mailing List
Anne Bennett <an...@encs.concordia.ca> wrote:
>
> But my parent (call it "example.com") *has* an A record;
> they use it for their web server, I believe. Will the above
> internally configured A RR not interfere with getting the
> correct data for "host -t a example.com"? Or does the sentence
> "These records are internally used to resolve names under the
> static-stub zone" imply that they are used *only* for this
> purpose, and never leaked out?
The latter. My toy nameserver has a slightly weird configration with
>
> But my parent (call it "example.com") *has* an A record;
> they use it for their web server, I believe. Will the above
> internally configured A RR not interfere with getting the
> correct data for "host -t a example.com"? Or does the sentence
> "These records are internally used to resolve names under the
> static-stub zone" imply that they are used *only* for this
> purpose, and never leaked out?
a recursive view containing static-stub zones pointing at its own
authoritative view, like
zone "cam.ac.uk" { type static-stub; server-addresses { ::1; }; };
And when I dig I get
; <<>> DiG 9.11.0pre-alpha <<>> +noedns +noall +cmd +comments +answer cam.ac.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41813
;; Got answer:
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; ANSWER SECTION:
cam.ac.uk. 3457 IN A 131.111.150.25
Trafalgar: Northerly or northwesterly, 4 or 5, occasionally 6 in north.
Moderate, occasionally rough in north. Fair. Good.
John Miller
Jul 9, 2015, 10:52:12 AM7/9/15
to Anne Bennett, Bind Users Mailing List
It's by tracing the queries down from the root zone several
times with "dig +trace" that it finally hit me what was going
on, and in retrospect it's obvious. At first I had been looking
for some kind of race condition with delegation data from the
grandparent zone getting cached, and then being overridden by
my parent zone's own NS records. At that point, I was trying
to use @server to try to affect that server's cache by forcing
it to pull certain data into its cache. But it turns out that
it isn't a child overriding its parents delegations that was
the "problem"; it's the fact that as an internal client, I am
able to access external views as well. And in the process
of investigating all this, I realized that of course if I
use +trace, all queries after the first one will *not* use
the @server. Duh. I just thought I might save someone else
the muddy thinking by offering a clarification for the manpage.
I just love those "frenzied reading of manpages" moments -- they're definitely not the easiest thing to skim when you're in the heat of the moment. Depending on the program, they sometimes require a state of Zen calmness to get what you need. You got to learn the hard way!
As for the problem itself, I'll probably fix it by setting up
a forwarding zone for my parent zone on my resolvers, to make
sure that I always get the internal view for their data.
We use stub zones for this purpose - a forwarding zone is what you want if you're forwarding to another _recursive_ nameserver (say for caching purposes), but if you're just telling your recursors which authoritative NSs to use, then stub zones are what you want. In terms of the actual DNS queries that go over the wire, it's whether the RD bit is/isn't set.
John
Tony Finch
Jul 9, 2015, 10:56:50 AM7/9/15
to John Miller, Bind Users Mailing List
John Miller <john...@brandeis.edu> wrote:
> We use stub zones for this purpose - a forwarding zone is what you want if
> you're forwarding to another _recursive_ nameserver (say for caching
> purposes), but if you're just telling your recursors which authoritative
> NSs to use, then stub zones are what you want.
The difference between stub and static-stub is that stub works like the
> We use stub zones for this purpose - a forwarding zone is what you want if
> you're forwarding to another _recursive_ nameserver (say for caching
> purposes), but if you're just telling your recursors which authoritative
> NSs to use, then stub zones are what you want.
root zone hints, i.e. the servers in the zone override the ones that you
configure for a stub zone, whereas the servers you configure for a
static-stub zone override the servers in the zone.
East Sole, Lundy, Fastnet, Irish Sea: Variable 3 or 4 becoming southerly 4 or
5, occasionally 6 in Irish Sea. Slight or moderate. Rain for a time except in
east Sole. Moderate or good, occasionally poor in Irish Sea.
Darcy Kevin (FCA)
Jul 9, 2015, 11:35:10 AM7/9/15
to John Miller, Anne Bennett, Bind Users Mailing List
I concur – if the requirement is to access a “special” version of the zone, which has different data than the version which is found by following the regular delegation hierarchy, then “stub” or “static-stub” is the way to go. That really is the whole _raison_d’etre_ for stub/static-stub – to override the resolver’s notion of where to pull the authoritative data. Sometimes stub/static-stub is necessary to work around delegations which are “broken” in some way (e.g. delegated nameservers aren’t reachable from some parts of a private network, or there’s a query-permissions problem). But that should be considered a temporary solution, until the underlying problem can be fixed.
Forwarding is only to get around connectivity restrictions (e.g. internal resolvers not being able to talk directly to Internet nameservers) or in attempts (usually futile) to optimize query performance.
- Kevin
John Miller
Jul 9, 2015, 1:35:45 PM7/9/15
to Bob Harold, Bind Users Mailing List
Even after flushing Google's cache (https://developers.google.com/speed/public-dns/cache), I still get the same response. Does anyone have insight on +showsearch, other than the following ;-)..."showsearch" has nothing to do with iteration or recursion. "showsearch" is related to the "search list" that is used if the domain name you are searching for is not fully qualified (does not end in a dot). Only useful if /etc/resolv.conf has a "search" list (or "domain" has more than two labels which creates an implied search list). See man page for resolv.conf for more.
Thanks for the clarification, Bob. I definitely didn't make the connection between "search" and "showsearch," so your response helped. Otherwise, some careful reading and educated guessing's definitely required to figure this out:
+[no]showsearch
Perform [do not perform] a search showing intermediate results.
Perform [do not perform] a search showing intermediate results.
This doesn't say anything about resolv.conf. "search," however, is clear-cut: use the list in resolv.conf or don't (default):
+[no]search
Use [do not use] the search list defined by the searchlist or domain directive in resolv.conf (if any). The
search list is not used by default.
+[no]search
Use [do not use] the search list defined by the searchlist or domain directive in resolv.conf (if any). The
search list is not used by default.
and it's easy to see the difference:
me@mybox ~ $ grep search /etc/resolv.conf
search brandeis.edu
me@mybox ~ $ dig alumni
;; QUESTION SECTION:
;alumni. IN A
jmiller@100degN ~ $ dig +search alumni
;; QUESTION SECTION:
;alumni.brandeis.edu. IN A
;; ANSWER SECTION:
alumni.brandeis.edu. 11396 IN A 129.64.101.157
me@mybox ~ $ grep search /etc/resolv.conf
search brandeis.edu
me@mybox ~ $ dig alumni
;; QUESTION SECTION:
;alumni. IN A
jmiller@100degN ~ $ dig +search alumni
;; QUESTION SECTION:
;alumni.brandeis.edu. IN A
;; ANSWER SECTION:
alumni.brandeis.edu. 11396 IN A 129.64.101.157
Because it uses resolv.conf , it gives the same results as using the "host" command.
And "showsearch" shows the full chain of queries made based on your search path -- "+showsearch" has an implied "+search" in it:
(server fqdn: dns-rec-xs-dev1.unet.brandeis.edu; search path: brandeis.edu unet.brandeis.edu)
[me@server ~]$ dig dns-rec-xs-dev1
;; QUESTION SECTION:
;dns-rec-xs-dev1. IN A
[me@server ~]$ dig +search dns-rec-xs-dev1
;; QUESTION SECTION:
;dns-rec-xs-dev1.unet.brandeis.edu. IN A
;; ANSWER SECTION:
dns-rec-xs-dev1.unet.brandeis.edu. 11306 IN A 129.64.100.67
[me@server ~]$ dig +showsearch dns-rec-xs-dev1
;; QUESTION SECTION:
;dns-rec-xs-dev1.brandeis.edu. IN A
;; AUTHORITY SECTION:
brandeis.edu. 1437 IN SOA dns-master.brandeis.edu. hostmaster.brandeis.edu. 1436381401 3600 1800 1209600 1800
;; QUESTION SECTION:
;dns-rec-xs-dev1.unet.brandeis.edu. IN A
;; ANSWER SECTION:
dns-rec-xs-dev1.unet.brandeis.edu. 10655 IN A 129.64.100.67
[me@server ~]$ dig dns-rec-xs-dev1
;; QUESTION SECTION:
;dns-rec-xs-dev1. IN A
[me@server ~]$ dig +search dns-rec-xs-dev1
;; QUESTION SECTION:
;dns-rec-xs-dev1.unet.brandeis.edu. IN A
;; ANSWER SECTION:
dns-rec-xs-dev1.unet.brandeis.edu. 11306 IN A 129.64.100.67
[me@server ~]$ dig +showsearch dns-rec-xs-dev1
;; QUESTION SECTION:
;dns-rec-xs-dev1.brandeis.edu. IN A
;; AUTHORITY SECTION:
brandeis.edu. 1437 IN SOA dns-master.brandeis.edu. hostmaster.brandeis.edu. 1436381401 3600 1800 1209600 1800
;; QUESTION SECTION:
;dns-rec-xs-dev1.unet.brandeis.edu. IN A
;; ANSWER SECTION:
dns-rec-xs-dev1.unet.brandeis.edu. 10655 IN A 129.64.100.67
_Two_ question and answer sections here: it shows both queries that dig makes. Same results as running host -v; just a different format.
I'd suggest substituting:
+[no]showsearch
Perform [do not perform] a search showing intermediate results.
+[no]showsearch
Perform [do not perform] a search showing intermediate results.
with
+[no]showsearch
Similar to +search, but show [do not show] results for each domain in the searchlist. Automatically enables
+search.
Similar to +search, but show [do not show] results for each domain in the searchlist. Automatically enables
+search.
I'll read through the contributors' guide and submit a patch.
John
Anne Bennett
Jul 14, 2015, 3:53:51 PM7/14/15
to Bind Users Mailing List
Tony Finch <d...@dotat.at> enlightens me thus:
> The difference between stub and static-stub is that stub works like the
> root zone hints, i.e. the servers in the zone override the ones that you
> configure for a stub zone, whereas the servers you configure for a
> static-stub zone override the servers in the zone.
set of servers it wants me to use, I configured my resolver
to have (this snippet from "named-checkconf -p" to deal with
include files and such):
zone "concordia.ca" {
type stub;
file "StubData/concordia.ca.SEC";
masters {
132.205.1.1 ;
132.205.7.51 ;
};
multi-master yes;
};
"named-checkconf" gave no errors. I issued a "reconfig", again
no errors logged or reported. I can confirm that the zone was
transferred correctly (showing me the internal view), because
I have "masterfile-format text" as a general option (small
enough number of zones that performance is not an issue, but
human ability to debug *is*), and "StubData/concordia.ca.SEC"
contains a perfectly normal-looking zone "stub":
----------------------------------------------------------
$ORIGIN .
$TTL 86400 ; 1 day
concordia.ca IN SOA ns1.concordia.ca. hostmaster.concordia.ca. (
2028969738 ; serial
43200 ; refresh (12 hours)
1800 ; retry (30 minutes)
2592000 ; expire (4 weeks 2 days)
1800 ; minimum (30 minutes)
)
NS ns1.concordia.ca.
NS ns2.concordia.ca.
----------------------------------------------------------
It all looks just peachy, but when I issued:
dig @localhost -t ns concordia.ca.
it gave me a SERVFAIL. I couldn't find anything abnormal
in the syslogs. I can't for the life of my figure out why
it's unhappy. How can I debug this? Is it normal that a
zone could be badly enough out of whack to SERVFAIL, yet
the named would syslog nothing?
(I'm syslogging default "syslog_all", minus edns-disabled,
lame-servers, rpz, and unmatched.)
Anne Bennett
Jul 15, 2015, 12:16:35 AM7/15/15
to Bind Users Mailing List
> zone "concordia.ca" {
> type stub;
> file "StubData/concordia.ca.SEC";
> masters {
> 132.205.1.1 ;
> 132.205.7.51 ;
> };
> multi-master yes;
> };
> ----------------------------------------------------------
> $ORIGIN .
> $TTL 86400 ; 1 day
> concordia.ca IN SOA ns1.concordia.ca. hostmaster.concordia.ca. (
> 2028969738 ; serial
> 43200 ; refresh (12 hours)
> 1800 ; retry (30 minutes)
> 2592000 ; expire (4 weeks 2 days)
> 1800 ; minimum (30 minutes)
> )
> NS ns1.concordia.ca.
> NS ns2.concordia.ca.
> ----------------------------------------------------------
Midnight insight: glue records??? The two listed NS are below the
zone cut. How can a stub zone work in those circumstances, if at all?
Tony Finch
Jul 15, 2015, 6:22:18 AM7/15/15
to Anne Bennett, Bind Users Mailing List
Anne Bennett <an...@encs.concordia.ca> wrote:
>
> It all looks just peachy, but when I issued:
> dig @localhost -t ns concordia.ca.
> it gave me a SERVFAIL. I couldn't find anything abnormal
> in the syslogs. I can't for the life of my figure out why
> it's unhappy. How can I debug this?
Try rndc trace 10. The debug logs are written to named.run (not syslog) by
>
> It all looks just peachy, but when I issued:
> dig @localhost -t ns concordia.ca.
> it gave me a SERVFAIL. I couldn't find anything abnormal
> in the syslogs. I can't for the life of my figure out why
> it's unhappy. How can I debug this?
default.
> (I'm syslogging default "syslog_all", minus edns-disabled,
> lame-servers, rpz, and unmatched.)
Southeast Iceland: Variable 3, becoming cyclonic 4 or 5 later. Moderate,
occasionally slight at first. Rain or showers, fog patches. Moderate or good,
occasionally very poor.
Anne Bennett
Jul 15, 2015, 3:09:21 PM7/15/15
to Bind Users Mailing List
Tony Finch suggested:
>> (I'm syslogging default "syslog_all", minus edns-disabled,
>> lame-servers, rpz, and unmatched.)
>
> Excluding lame-servers might be why you aren't seeing any log
> messages.
>> zone "concordia.ca" {
>> type stub;
>> file "StubData/concordia.ca.SEC";
>> masters {
>> 132.205.1.1 ;
>> 132.205.7.51 ;
>> };
>> multi-master yes;
>> };
[results in transferring:]
>> ----------------------------------------------------------
>> $ORIGIN .
>> $TTL 86400 ; 1 day
>> concordia.ca IN SOA ns1.concordia.ca. hostmaster.concordia.ca. (
>> 2028969738 ; serial
>> 43200 ; refresh (12 hours)
>> 1800 ; retry (30 minutes)
>> 2592000 ; expire (4 weeks 2 days)
>> 1800 ; minimum (30 minutes)
>> )
>> NS ns1.concordia.ca.
>> NS ns2.concordia.ca.
>> ----------------------------------------------------------
[but querying it for NS gives SERVFAIL]
> Midnight insight: glue records??? The two listed NS are below the
> zone cut. How can a stub zone work in those circumstances, if at all?
"concordia.ca" (which transfers information listing two NS
records as ns1.concordia.ca and ns2.concordia.ca but no glue
records), I get SERVFAIL (after a clean start of "named").
And in that circumstance, the other two stub zones I have set up
(for the IPv4 and IPv6 reverse zones for my parent networks) also
transfer the same set of two NS records, and also fail.
If I comment out the stub zone for "concordia.ca", but leave
in the two "reverse IP" stub zones, then these two zones work
correctly: when I query for NS, they give me ns1.concordia.ca
and ns2.concordia.ca, with their A records in the additional
section.
I think that clinches it: the implementation of stub zones
indeed "replicates only the NS records", but not the needed
glue records, so it cannot work in cases where all of the
listed NS are within the zone itself.
It would be a nice enhancement to make the stub zone pick up
glue records. Is this something I should report separately?
Meanwhile, I'll try a static-stub zone for this case...
Tony Finch has also suggested:
> Try rndc trace 10. The debug logs are written to named.run (not
> syslog) by default.
able to get the trace output. I append it (for a query on
the NS records of concordia.ca, with the stub zone in effect),
in case it is of use to anyone.
Anne.
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
an...@encs.concordia.ca +1 514 848-2424 x2285
-------------------------------------------------------------------------------
an...@encs.concordia.ca +1 514 848-2424 x2285
15-Jul-2015 14:54:47.342 debug level is now 10
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060: UDP request
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060: using view '_default'
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060: request is not signed
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060: recursion available
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060: query
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060 (concordia.ca): ns_client_attach: ref = 1
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060 (concordia.ca): query 'concordia.ca/NS/IN' approved
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060 (concordia.ca): replace
15-Jul-2015 14:54:47.353 clientmgr @0x2b31f95c2458: get client
15-Jul-2015 14:54:47.353 clientmgr @0x2b31f95c2458: recycle
15-Jul-2015 14:54:47.353 fetch: concordia.ca/NS
15-Jul-2015 14:54:47.353 client @0x2b31fc0dfa60: udprecv
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): create
15-Jul-2015 14:54:47.353 log_ns_ttl: fctx 0x2b3204c7f010: fctx_create: concordia.ca (in 'concordia.ca'?): 1 86400
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): join
15-Jul-2015 14:54:47.353 fetch 0x2b31f5babd18 (fctx 0x2b3204c7f010(concordia.ca/NS)): created
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): start
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): try
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): cancelqueries
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): getaddresses
15-Jul-2015 14:54:47.354 fetch: ns1.concordia.ca/A
15-Jul-2015 14:54:47.354 fctx 0x2b3204cc0010(ns1.concordia.ca/A): create
15-Jul-2015 14:54:47.354 log_ns_ttl: fctx 0x2b3204cc0010: fctx_create: ns1.concordia.ca (in 'concordia.ca'?): 1 86400
15-Jul-2015 14:54:47.354 fctx 0x2b3204cc0010(ns1.concordia.ca/A): join
15-Jul-2015 14:54:47.354 fetch 0x2b31f5babd78 (fctx 0x2b3204cc0010(ns1.concordia.ca/A)): created
15-Jul-2015 14:54:47.354 dns_adb_createfind: started A fetch for name ns1.concordia.ca (0x2b31f9c5a140)
15-Jul-2015 14:54:47.354 fetch: ns1.concordia.ca/AAAA
15-Jul-2015 14:54:47.354 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): create
15-Jul-2015 14:54:47.354 log_ns_ttl: fctx 0x2b3204cc0450: fctx_create: ns1.concordia.ca (in 'concordia.ca'?): 1 86400
15-Jul-2015 14:54:47.354 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): join
15-Jul-2015 14:54:47.354 fetch 0x2b31f5babd30 (fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA)): created
15-Jul-2015 14:54:47.354 dns_adb_createfind: started AAAA fetch for name ns1.concordia.ca (0x2b31f9c5a140)
15-Jul-2015 14:54:47.354 createfind: attaching find 0x2b31f9c58970 to adbname 0x2b31f9c5a140
15-Jul-2015 14:54:47.354 fctx 0x2b3204cc0010(ns1.concordia.ca/A): start
15-Jul-2015 14:54:47.354 fctx 0x2b3204cc0010(ns1.concordia.ca/A): try
15-Jul-2015 14:54:47.354 fctx 0x2b3204cc0010(ns1.concordia.ca/A): cancelqueries
15-Jul-2015 14:54:47.354 fctx 0x2b3204cc0010(ns1.concordia.ca/A): getaddresses
15-Jul-2015 14:54:47.354 fetch: ns2.concordia.ca/A
15-Jul-2015 14:54:47.354 fctx 0x2b3204d01010(ns2.concordia.ca/A): create
15-Jul-2015 14:54:47.354 log_ns_ttl: fctx 0x2b3204d01010: fctx_create: ns2.concordia.ca (in 'concordia.ca'?): 1 86400
15-Jul-2015 14:54:47.354 fctx 0x2b3204d01010(ns2.concordia.ca/A): join
15-Jul-2015 14:54:47.354 fetch 0x2b31f5babd60 (fctx 0x2b3204d01010(ns2.concordia.ca/A)): created
15-Jul-2015 14:54:47.354 dns_adb_createfind: started A fetch for name ns2.concordia.ca (0x2b31f9c5a010)
15-Jul-2015 14:54:47.354 fetch: ns2.concordia.ca/AAAA
15-Jul-2015 14:54:47.354 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): create
15-Jul-2015 14:54:47.354 log_ns_ttl: fctx 0x2b3204d01450: fctx_create: ns2.concordia.ca (in 'concordia.ca'?): 1 86400
15-Jul-2015 14:54:47.354 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): join
15-Jul-2015 14:54:47.354 fetch 0x2b31f5babd48 (fctx 0x2b3204d01450(ns2.concordia.ca/AAAA)): created
15-Jul-2015 14:54:47.354 dns_adb_createfind: started AAAA fetch for name ns2.concordia.ca (0x2b31f9c5a010)
15-Jul-2015 14:54:47.354 createfind: attaching find 0x2b31f9c58880 to adbname 0x2b31f9c5a010
15-Jul-2015 14:54:47.354 fctx 0x2b3204c7f010(concordia.ca/NS): addrwait
15-Jul-2015 14:54:47.354 fctx 0x2b3204d01010(ns2.concordia.ca/A): start
15-Jul-2015 14:54:47.354 fctx 0x2b3204d01010(ns2.concordia.ca/A): try
15-Jul-2015 14:54:47.354 fctx 0x2b3204d01010(ns2.concordia.ca/A): cancelqueries
15-Jul-2015 14:54:47.354 fctx 0x2b3204d01010(ns2.concordia.ca/A): getaddresses
15-Jul-2015 14:54:47.354 createfind: attaching find 0x2b31f9c58d30 to adbname 0x2b31f9c5a140
15-Jul-2015 14:54:47.355 createfind: attaching find 0x2b31f9c58790 to adbname 0x2b31f9c5a140
15-Jul-2015 14:54:47.355 createfind: attaching find 0x2b31f9c585b0 to adbname 0x2b31f9c5a010
15-Jul-2015 14:54:47.355 fctx 0x2b3204d01010(ns2.concordia.ca/A): addrwait
15-Jul-2015 14:54:47.355 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): start
15-Jul-2015 14:54:47.355 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): try
15-Jul-2015 14:54:47.355 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): cancelqueries
15-Jul-2015 14:54:47.355 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): getaddresses
15-Jul-2015 14:54:47.355 createfind: attaching find 0x2b31f9c586a0 to adbname 0x2b31f9c5a010
15-Jul-2015 14:54:47.355 fctx 0x2b3204cc0010(ns1.concordia.ca/A): addrwait
15-Jul-2015 14:54:47.355 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): start
15-Jul-2015 14:54:47.355 createfind: attaching find 0x2b31f9c58b50 to adbname 0x2b31f9c5a140
15-Jul-2015 14:54:47.355 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): try
15-Jul-2015 14:54:47.355 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): cancelqueries
15-Jul-2015 14:54:47.355 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): getaddresses
15-Jul-2015 14:54:47.355 createfind: attaching find 0x2b31f9c58a60 to adbname 0x2b31f9c5a010
15-Jul-2015 14:54:47.355 createfind: attaching find 0x2b31f9c58c40 to adbname 0x2b31f9c5a140
15-Jul-2015 14:54:47.355 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): addrwait
15-Jul-2015 14:54:47.355 createfind: attaching find 0x2b31f9c58e20 to adbname 0x2b31f9c5a010
15-Jul-2015 14:54:47.355 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): addrwait
15-Jul-2015 14:54:52.354 client 127.0.0.1#57060: UDP request
15-Jul-2015 14:54:52.354 client 127.0.0.1#57060: using view '_default'
15-Jul-2015 14:54:52.354 client 127.0.0.1#57060: request is not signed
15-Jul-2015 14:54:52.354 client 127.0.0.1#57060: recursion available
15-Jul-2015 14:54:52.354 client 127.0.0.1#57060: query
15-Jul-2015 14:54:52.354 client 127.0.0.1#57060 (concordia.ca): ns_client_attach: ref = 1
15-Jul-2015 14:54:52.354 client 127.0.0.1#57060 (concordia.ca): query 'concordia.ca/NS/IN' approved
15-Jul-2015 14:54:52.354 client 127.0.0.1#57060 (concordia.ca): replace
15-Jul-2015 14:54:52.354 clientmgr @0x2b31f95c2458: get client
15-Jul-2015 14:54:52.354 clientmgr @0x2b31f95c2458: recycle
15-Jul-2015 14:54:52.354 fetch: concordia.ca/NS
15-Jul-2015 14:54:52.354 client 127.0.0.1#57060 (concordia.ca): next
15-Jul-2015 14:54:52.354 client 127.0.0.1#57060 (concordia.ca): request failed: duplicate query
15-Jul-2015 14:54:52.354 client 127.0.0.1#57060 (concordia.ca): ns_client_detach: ref = 0
15-Jul-2015 14:54:52.354 client 127.0.0.1#57060 (concordia.ca): endrequest
15-Jul-2015 14:54:52.354 client @0x2b32000f2710: udprecv
15-Jul-2015 14:54:57.354 fctx 0x2b3204c7f010(concordia.ca/NS): timeout
15-Jul-2015 14:54:57.354 fctx 0x2b3204c7f010(concordia.ca/NS): done
15-Jul-2015 14:54:57.354 fctx 0x2b3204c7f010(concordia.ca/NS): stopeverything
15-Jul-2015 14:54:57.354 fctx 0x2b3204c7f010(concordia.ca/NS): cancelqueries
15-Jul-2015 14:54:57.354 fctx 0x2b3204c7f010(concordia.ca/NS): sendevents
15-Jul-2015 14:54:57.354 client 127.0.0.1#57060 (concordia.ca): rpz QNAME rewrite concordia.ca via concordia.ca stop on qresult in rpz_rewrite(): timed out
15-Jul-2015 14:54:57.354 client 127.0.0.1#57060 (concordia.ca): query failed (SERVFAIL) for concordia.ca/IN/NS at query.c:7677
15-Jul-2015 14:54:57.354 client 127.0.0.1#57060 (concordia.ca): error
15-Jul-2015 14:54:57.354 client 127.0.0.1#57060 (concordia.ca): send
15-Jul-2015 14:54:57.354 client 127.0.0.1#57060 (concordia.ca): sendto
15-Jul-2015 14:54:57.354 client 127.0.0.1#57060 (concordia.ca): senddone
15-Jul-2015 14:54:57.354 client 127.0.0.1#57060 (concordia.ca): next
15-Jul-2015 14:54:57.354 client 127.0.0.1#57060: UDP request
15-Jul-2015 14:54:57.354 client 127.0.0.1#57060 (concordia.ca): ns_client_detach: ref = 0
15-Jul-2015 14:54:57.354 client 127.0.0.1#57060: using view '_default'
15-Jul-2015 14:54:57.354 client 127.0.0.1#57060: request is not signed
15-Jul-2015 14:54:57.354 client 127.0.0.1#57060: recursion available
15-Jul-2015 14:54:57.354 client 127.0.0.1#57060: query
15-Jul-2015 14:54:57.354 client 127.0.0.1#57060 (concordia.ca): endrequest
15-Jul-2015 14:54:57.354 client 127.0.0.1#57060 (concordia.ca): ns_client_attach: ref = 1
15-Jul-2015 14:54:57.354 fetch completed at resolver.c:3525 for concordia.ca/NS in 10.000708: timed out/success [domain:concordia.ca,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
15-Jul-2015 14:54:57.354 fetch 0x2b31f5babd18 (fctx 0x2b3204c7f010(concordia.ca/NS)): destroyfetch
15-Jul-2015 14:54:57.354 fctx 0x2b3204c7f010(concordia.ca/NS): shutdown
15-Jul-2015 14:54:57.354 fctx 0x2b3204c7f010(concordia.ca/NS): doshutdown
15-Jul-2015 14:54:57.354 fctx 0x2b3204c7f010(concordia.ca/NS): stopeverything
15-Jul-2015 14:54:57.354 fctx 0x2b3204c7f010(concordia.ca/NS): cancelqueries
15-Jul-2015 14:54:57.354 client 127.0.0.1#57060 (concordia.ca): query 'concordia.ca/NS/IN' approved
15-Jul-2015 14:54:57.355 client 127.0.0.1#57060 (concordia.ca): replace
15-Jul-2015 14:54:57.355 clientmgr @0x2b31f95c2458: get client
15-Jul-2015 14:54:57.355 clientmgr @0x2b31f95c2458: recycle
15-Jul-2015 14:54:57.355 fetch: concordia.ca/NS
15-Jul-2015 14:54:57.355 fctx 0x2b3204c7f450(concordia.ca/NS): create
15-Jul-2015 14:54:57.355 log_ns_ttl: fctx 0x2b3204c7f450: fctx_create: concordia.ca (in 'concordia.ca'?): 1 86400
15-Jul-2015 14:54:57.355 fctx 0x2b3204c7f450(concordia.ca/NS): join
15-Jul-2015 14:54:57.355 fetch 0x2b31f5babd18 (fctx 0x2b3204c7f450(concordia.ca/NS)): created
15-Jul-2015 14:54:57.355 client @0x2b31fc0dfa60: udprecv
15-Jul-2015 14:54:57.355 fctx 0x2b3204c7f450(concordia.ca/NS): start
15-Jul-2015 14:54:57.355 fctx 0x2b3204c7f450(concordia.ca/NS): try
15-Jul-2015 14:54:57.355 fctx 0x2b3204c7f450(concordia.ca/NS): cancelqueries
15-Jul-2015 14:54:57.355 fctx 0x2b3204c7f450(concordia.ca/NS): getaddresses
15-Jul-2015 14:54:57.355 createfind: attaching find 0x2b31f9c584c0 to adbname 0x2b31f9c5a140
15-Jul-2015 14:54:57.355 createfind: attaching find 0x2b31f9c583d0 to adbname 0x2b31f9c5a010
15-Jul-2015 14:54:57.355 fctx 0x2b3204c7f450(concordia.ca/NS): addrwait
15-Jul-2015 14:54:57.355 fctx 0x2b3204cc0010(ns1.concordia.ca/A): timeout
15-Jul-2015 14:54:57.355 fctx 0x2b3204cc0010(ns1.concordia.ca/A): done
15-Jul-2015 14:54:57.355 fctx 0x2b3204cc0010(ns1.concordia.ca/A): stopeverything
15-Jul-2015 14:54:57.355 fctx 0x2b3204cc0010(ns1.concordia.ca/A): cancelqueries
15-Jul-2015 14:54:57.355 fctx 0x2b3204cc0010(ns1.concordia.ca/A): sendevents
15-Jul-2015 14:54:57.355 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): timeout
15-Jul-2015 14:54:57.355 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): done
15-Jul-2015 14:54:57.355 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): stopeverything
15-Jul-2015 14:54:57.355 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): cancelqueries
15-Jul-2015 14:54:57.355 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): sendevents
15-Jul-2015 14:54:57.355 fctx 0x2b3204d01010(ns2.concordia.ca/A): timeout
15-Jul-2015 14:54:57.355 fctx 0x2b3204d01010(ns2.concordia.ca/A): done
15-Jul-2015 14:54:57.355 fctx 0x2b3204d01010(ns2.concordia.ca/A): stopeverything
15-Jul-2015 14:54:57.355 fctx 0x2b3204d01010(ns2.concordia.ca/A): cancelqueries
15-Jul-2015 14:54:57.355 fctx 0x2b3204d01010(ns2.concordia.ca/A): sendevents
15-Jul-2015 14:54:57.355 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): timeout
15-Jul-2015 14:54:57.355 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): done
15-Jul-2015 14:54:57.355 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): stopeverything
15-Jul-2015 14:54:57.355 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): cancelqueries
15-Jul-2015 14:54:57.355 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): sendevents
15-Jul-2015 14:54:57.355 fetch 0x2b31f5babd78 (fctx 0x2b3204cc0010(ns1.concordia.ca/A)): destroyfetch
15-Jul-2015 14:54:57.355 fctx 0x2b3204cc0010(ns1.concordia.ca/A): shutdown
15-Jul-2015 14:54:57.355 adb: fetch of 'ns1.concordia.ca' A failed: timed out
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: skipping find 0x2b31f9c58970
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: skipping find 0x2b31f9c58d30
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: skipping find 0x2b31f9c58790
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: skipping find 0x2b31f9c58b50
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: skipping find 0x2b31f9c58c40
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: skipping find 0x2b31f9c584c0
15-Jul-2015 14:54:57.355 fetch 0x2b31f5babd30 (fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA)): destroyfetch
15-Jul-2015 14:54:57.355 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): shutdown
15-Jul-2015 14:54:57.355 adb: fetch of 'ns1.concordia.ca' AAAA failed: timed out
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: processing find 0x2b31f9c58970
15-Jul-2015 14:54:57.355 sending event 0x2b31f9c589f8 to task 0x2b31f9b1a010 for find 0x2b31f9c58970
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: processing find 0x2b31f9c58d30
15-Jul-2015 14:54:57.355 sending event 0x2b31f9c58db8 to task 0x2b31f9b1a250 for find 0x2b31f9c58d30
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: processing find 0x2b31f9c58790
15-Jul-2015 14:54:57.355 sending event 0x2b31f9c58818 to task 0x2b31f9b19e50 for find 0x2b31f9c58790
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: processing find 0x2b31f9c58b50
15-Jul-2015 14:54:57.355 sending event 0x2b31f9c58bd8 to task 0x2b31f9b19e50 for find 0x2b31f9c58b50
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: processing find 0x2b31f9c58c40
15-Jul-2015 14:54:57.355 sending event 0x2b31f9c58cc8 to task 0x2b31f9b1a250 for find 0x2b31f9c58c40
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: processing find 0x2b31f9c584c0
15-Jul-2015 14:54:57.355 sending event 0x2b31f9c58548 to task 0x2b31f9b1a010 for find 0x2b31f9c584c0
15-Jul-2015 14:54:57.355 fetch 0x2b31f5babd60 (fctx 0x2b3204d01010(ns2.concordia.ca/A)): destroyfetch
15-Jul-2015 14:54:57.355 fctx 0x2b3204d01010(ns2.concordia.ca/A): shutdown
15-Jul-2015 14:54:57.355 adb: fetch of 'ns2.concordia.ca' A failed: timed out
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: skipping find 0x2b31f9c58880
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: skipping find 0x2b31f9c585b0
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: skipping find 0x2b31f9c586a0
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: skipping find 0x2b31f9c58a60
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: skipping find 0x2b31f9c58e20
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: skipping find 0x2b31f9c583d0
15-Jul-2015 14:54:57.355 fetch 0x2b31f5babd48 (fctx 0x2b3204d01450(ns2.concordia.ca/AAAA)): destroyfetch
15-Jul-2015 14:54:57.355 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): shutdown
15-Jul-2015 14:54:57.355 adb: fetch of 'ns2.concordia.ca' AAAA failed: timed out
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: processing find 0x2b31f9c58880
15-Jul-2015 14:54:57.355 sending event 0x2b31f9c58908 to task 0x2b31f9b1a010 for find 0x2b31f9c58880
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: processing find 0x2b31f9c585b0
15-Jul-2015 14:54:57.355 sending event 0x2b31f9c58638 to task 0x2b31f9b19e50 for find 0x2b31f9c585b0
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: processing find 0x2b31f9c586a0
15-Jul-2015 14:54:57.355 sending event 0x2b31f9c58728 to task 0x2b31f9b1a250 for find 0x2b31f9c586a0
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: processing find 0x2b31f9c58a60
15-Jul-2015 14:54:57.355 sending event 0x2b31f9c58ae8 to task 0x2b31f9b19e50 for find 0x2b31f9c58a60
15-Jul-2015 14:54:57.355 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.355 cfan: processing find 0x2b31f9c58e20
15-Jul-2015 14:54:57.355 sending event 0x2b31f9c58ea8 to task 0x2b31f9b1a250 for find 0x2b31f9c58e20
15-Jul-2015 14:54:57.356 DNS_EVENT_ADBNOMOREADDRESSES
15-Jul-2015 14:54:57.356 cfan: processing find 0x2b31f9c583d0
15-Jul-2015 14:54:57.356 sending event 0x2b31f9c58458 to task 0x2b31f9b1a010 for find 0x2b31f9c583d0
15-Jul-2015 14:54:57.356 fctx 0x2b3204cc0010(ns1.concordia.ca/A): doshutdown
15-Jul-2015 14:54:57.356 fctx 0x2b3204cc0010(ns1.concordia.ca/A): stopeverything
15-Jul-2015 14:54:57.356 fctx 0x2b3204cc0010(ns1.concordia.ca/A): cancelqueries
15-Jul-2015 14:54:57.356 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): doshutdown
15-Jul-2015 14:54:57.356 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): stopeverything
15-Jul-2015 14:54:57.356 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): cancelqueries
15-Jul-2015 14:54:57.356 fctx 0x2b3204cc0010(ns1.concordia.ca/A): finddone
15-Jul-2015 14:54:57.356 dns_adb_destroyfind on find 0x2b31f9c58d30
15-Jul-2015 14:54:57.356 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): finddone
15-Jul-2015 14:54:57.356 dns_adb_destroyfind on find 0x2b31f9c58c40
15-Jul-2015 14:54:57.356 fctx 0x2b3204cc0010(ns1.concordia.ca/A): finddone
15-Jul-2015 14:54:57.356 fctx 0x2b3204cc0010(ns1.concordia.ca/A): unlink
15-Jul-2015 14:54:57.356 dns_adb_destroyfind on find 0x2b31f9c586a0
15-Jul-2015 14:54:57.356 fctx 0x2b3204cc0010(ns1.concordia.ca/A): destroy
15-Jul-2015 14:54:57.356 fctx 0x2b3204c7f010(concordia.ca/NS): finddone
15-Jul-2015 14:54:57.356 dns_adb_destroyfind on find 0x2b31f9c58970
15-Jul-2015 14:54:57.356 fctx 0x2b3204c7f450(concordia.ca/NS): finddone
15-Jul-2015 14:54:57.356 dns_adb_destroyfind on find 0x2b31f9c584c0
15-Jul-2015 14:54:57.356 fctx 0x2b3204c7f010(concordia.ca/NS): finddone
15-Jul-2015 14:54:57.356 fctx 0x2b3204c7f010(concordia.ca/NS): unlink
15-Jul-2015 14:54:57.356 dns_adb_destroyfind on find 0x2b31f9c58880
15-Jul-2015 14:54:57.356 fctx 0x2b3204c7f010(concordia.ca/NS): destroy
15-Jul-2015 14:54:57.356 fctx 0x2b3204c7f450(concordia.ca/NS): finddone
15-Jul-2015 14:54:57.356 dns_adb_destroyfind on find 0x2b31f9c583d0
15-Jul-2015 14:54:57.356 fctx 0x2b3204d01010(ns2.concordia.ca/A): finddone
15-Jul-2015 14:54:57.356 dns_adb_destroyfind on find 0x2b31f9c58790
15-Jul-2015 14:54:57.356 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): finddone
15-Jul-2015 14:54:57.356 dns_adb_destroyfind on find 0x2b31f9c58b50
15-Jul-2015 14:54:57.356 fctx 0x2b3204d01010(ns2.concordia.ca/A): doshutdown
15-Jul-2015 14:54:57.356 fctx 0x2b3204d01010(ns2.concordia.ca/A): stopeverything
15-Jul-2015 14:54:57.356 fctx 0x2b3204d01010(ns2.concordia.ca/A): cancelqueries
15-Jul-2015 14:54:57.356 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): doshutdown
15-Jul-2015 14:54:57.356 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): stopeverything
15-Jul-2015 14:54:57.356 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): cancelqueries
15-Jul-2015 14:54:57.356 fctx 0x2b3204d01010(ns2.concordia.ca/A): finddone
15-Jul-2015 14:54:57.356 fctx 0x2b3204d01010(ns2.concordia.ca/A): unlink
15-Jul-2015 14:54:57.356 dns_adb_destroyfind on find 0x2b31f9c585b0
15-Jul-2015 14:54:57.356 fctx 0x2b3204d01010(ns2.concordia.ca/A): destroy
15-Jul-2015 14:54:57.356 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): finddone
15-Jul-2015 14:54:57.356 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): unlink
15-Jul-2015 14:54:57.356 dns_adb_destroyfind on find 0x2b31f9c58e20
15-Jul-2015 14:54:57.356 fctx 0x2b3204cc0450(ns1.concordia.ca/AAAA): destroy
15-Jul-2015 14:54:57.356 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): finddone
15-Jul-2015 14:54:57.356 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): unlink
15-Jul-2015 14:54:57.356 dns_adb_destroyfind on find 0x2b31f9c58a60
15-Jul-2015 14:54:57.356 fctx 0x2b3204d01450(ns2.concordia.ca/AAAA): destroy
15-Jul-2015 14:54:57.362 received control channel command 'notrace'
-------------------------------------------------------------------------------
0 new messages