Re: SERVFAIL on stub zone (WAS: dig @server foobar +trace +recurse)

2015-07-15 Thread Tony Finch
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)

2015-07-15 Thread Anne Bennett

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