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
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
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
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:]
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,
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
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
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
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
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
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
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
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
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
14 matches
Mail list logo
