Re: SERVFAIL on stub zone (WAS: dig @server foobar +trace +recurse)
Anne Bennett a...@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 default. (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. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ 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. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SERVFAIL on stub zone (WAS: dig @server foobar +trace +recurse)
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.
I tried un-excluding it: nothing.
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.caIN 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?
I think I'm onto something; with the above stub zone for
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.
After a bit of tweaking of my logging configuration, I was
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
a...@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
SERVFAIL on stub zone (WAS: dig @server foobar +trace +recurse)
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.
... so, since I want my parent zone to be able to give me the
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.caIN 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.
--
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: SERVFAIL on stub zone (WAS: dig @server foobar +trace +recurse)
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.caIN 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?
Anne.
--
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dig @server foobar +trace +recurse
On Wed, Jul 8, 2015 at 11:55 PM, John Miller johnm...@brandeis.edu wrote: ... 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 ;-) ... 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. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig @server foobar +trace +recurse
Anne Bennett a...@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
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
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; ANSWER SECTION:
cam.ac.uk. 3457IN A 131.111.150.25
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
Trafalgar: Northerly or northwesterly, 4 or 5, occasionally 6 in north.
Moderate, occasionally rough in north. Fair. Good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dig @server foobar +trace +recurse
John Miller johnm...@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 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. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ 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. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig @server foobar +trace +recurse
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.
It does offer recursion, but your suggestion is most helpful nevertheless:
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.
Good point; I want queries for its children (my zones!) to be answered
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.)
Indeed. Here we're blessed with having had a long-duration
(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.
Anne.
--
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dig @server foobar +trace +recurse
For my part, I'd be curious to know what sort of problem you're trying to solve with dig. Oh, I solved it. I was getting different data for my parent 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. It all worked fine when I stopped barking up the wrong tree. ;-) 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, Yes; an overly quick reading of the docs on my part. I was trying 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. Right; I wanted the former, and that's what, despite myself, 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! :-) Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig @server foobar +trace +recurse
Anne Bennett a...@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 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. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig @server foobar +trace +recurse
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. 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. 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 ; 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. John On Wed, Jul 8, 2015 at 6:34 PM, Anne Bennett a...@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 +showsearch +trace +recurse.) Is my understanding correct? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig @server foobar +trace +recurse
In message 13180.1436394...@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 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 a...@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-users@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 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dig @server foobar +trace +recurse
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 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig @server foobar +trace +recurse
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] Given +trace isn't simple usage (dig @server name type), why would one say that in the simple usage section? Fair enough, and well taken; I can modify my suggestion. +trace states that it is going to talk to each server in turn. Very true, and very painfully obvious in retrospect, but 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. If @server is also specified, it affects only the 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. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
