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
