Re: How to debug BIND
On 30 November 2014 at 01:22, Kaouthar Chetioui kaoutharcheti...@gmail.com wrote: I want to do full debug for BIND I use this command: dig www.example.ma -d What's the problem you are having? What are you expecting to see when you perform a debug? What is the real name you are trying to diagnose? Steve ___ 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: How to debug BIND
On 30 November 2014 at 11:04, Kaouthar Chetioui kaoutharcheti...@gmail.com wrote: I want to know the exact path that follows bind to resolve a DNS query Please reply to the list not direct. The option you are looking for is +trace and needs to be invoked on the server/system that will be resolving the query for the client. You might want to try man dig and look at the documentation first in future... Steve ___ 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: How to debug BIND
I have already use +trace it gives me the following answer, like this:
global options: +cmd
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
I also add in 'named.conf' file, the following commands:
logging {
channel debug {
file data/named.log size 10m;
severity debug 99;
print-time yes;
print-severity yes;
print-category yes;
};
category default { debug; };
category general { debug; };
category database { debug; };
category security { debug; };
category config { debug; };
category resolver { debug; };
category xfer-in { debug; };
category xfer-out { debug; };
category notify { debug; };
category client { debug; };
category unmatched { debug; };
category network { debug; };
category update { debug; };
category queries { debug; };
category dispatch { debug; };
category dnssec { debug; };
category lame-servers { debug; };
};
and I used 'dig www.example.ma -d' to debug.
In the file 'named.log', I have the detail of debug but I dont find
functions that are used in Bind source files.
Thanks.
2014-11-30 11:10 GMT+00:00 Steven Carr sjc...@gmail.com:
On 30 November 2014 at 11:04, Kaouthar Chetioui
kaoutharcheti...@gmail.com wrote:
I want to know the exact path that follows bind to resolve a DNS query
Please reply to the list not direct.
The option you are looking for is +trace and needs to be invoked on
the server/system that will be resolving the query for the client.
You might want to try man dig and look at the documentation first in
future...
Steve
Kaouthar.
___
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: How to debug BIND
On 30.11.14 11:24, Kaouthar Chetioui wrote: I have already use +trace it gives me the following answer, like this: no, it doeas not: global options: +cmd you clearly did not use +trace here. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. How does cat play with mouse? cat /dev/mouse ___ 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: How to debug BIND
DIG is used to test/troubleshoot DNS queries. BIND logging is used to troubleshoot the BIND server itself. Which are you trying to debug? Also be mindful that BIND will cache any DNS entries it retrieves for the defined TTLs, so if you dig a second time chances are it's not going to go to the Internet, it will answer from cache. If you are trying to examine exactly what BIND is querying then use dig against the server for the requested records while running a packet capture on the server itself. Filter the capture for all DNS packets to see what's happening. Make sure BIND's cache is flushed between digs. If you want to debug the underlying BIND code then you'll need to use an actual code debugger, BIND's debug logging is for debugging the running of the program, so if you want to see it jumping through the various code functions then look at GDB (GNU Project Debugger) - not quite sure what you're hoping to gain from this though. Steve ___ 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: How to debug BIND
Try option (+nodnssec): dig www.example.ma +trace +nodnssec On 11/30/2014 04:40 PM, Matus UHLAR - fantomas wrote: On 30.11.14 11:24, Kaouthar Chetioui wrote: I have already use +trace it gives me the following answer, like this: no, it doeas not: global options: +cmd you clearly did not use +trace here. -- Kanogin Alex ___ 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: How to debug BIND
Kaouthar Chetioui kaoutharcheti...@gmail.com wrote: I want to know the exact path that follows bind to resolve a DNS query Try running $ rndc flush $ rndc trace 11 $ dig www.example.ma Then look at named's logs which will give you lots of details about queries, responses, and the parts of BIND involved in the process. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ South Fitzroy: Northerly 5 to 7, occasionally gale 8 at first. Rough, occasionally very rough at first. Showers. Good, occasionally moderate. ___ 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: DANE record rejected by named-checkzone
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/04/2014 11:54 PM, Mark Andrews wrote: In message 545954b0.8080...@offerman.com, Adrian (Aad) Offerman writes: named keeps refusing my zone file in which I included a DANE record: [root]# named-checkzone offerman.com db.offerman.com db.offerman.com:59: _443._tcp.offerman.com: bad owner name (check-names) db.offerman.com:60: _443._tcp.offerman.com: bad owner name (check-names) zone offerman.com/IN: loaded serial 2014110103 OK [root]# This appears to be caused by the underscores used in the port/protocol combination. Here's what the record looks like: _443._tcp IN TLSA3 0 1 a66939453856cd6b0f78427eb38d3a9921cfb8bab928d24017a172647e323ce Well that isn't a valid TLSA record. It has a bad hex encoding. There are 63 hex digits. Just an error in the cutting/pasting, in the mail message that is. TLSA records themselves are not subject to check-names processing so I suggest that you look at the reported lines in the file to find out what is actually there. In the example below it is the A record which has inherited the _443._tcp owner name. Ah, that did the job! :-) Inserting a block of TLSA records at the wrong place screwed up the inheritance for the next record. Thanks! Adrian Mark [rock:~/git/bind9] marka% bin/check/named-checkzone c.db c.db c.db:1: no TTL specified; using SOA MINTTL instead dns_rdata_fromtext: c.db:3: near eol: bad hex encoding c.db:4: _443._tcp.c.db: bad owner name (check-names) zone c.db/IN: loading from master file c.db failed: bad hex encoding zone c.db/IN: not loaded due to errors. [rock:~/git/bind9] marka% @IN SOA . . 0 0 0 0 0 @ IN NS . _443._tcp IN TLSA 3 0 1 a66939453856cd6b0f78427eb38d3a9921cfb8bab928d24017a172647e323ce IN A 1.2.3.4 It was created first using this: tlsa --create --output rfc offerman.com later using this: ldns-dane create offerman.com 443 both resulting in the same record, and both outputs resulting in the same error. I've upgraded the named version (on CentOS 6.6) from 9.8.2 to 9.9.6, but all to no avail :-( [root]# named-checkzone -v 9.9.6-RedHat-9.9.6-0.el6 Am I trying to do something here that is not yet supported or am I overlooking something? -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUe0v1AAoJECfzYtonqXzEKHgIAJyjwFIgXbZ1eO01eR8JO4Au s51DVqywT7/0nVfF55Zi6N8mOi9GygYJjSEFJ4lL6g2BI2TaNVzeAQqGp9oJ8UUf GzJOjLkb7UyPy5OXYjkIj4a2f7t8Eyk7kRXYhfDaPccox87R8NkIWkCftSrfgBEq LwwTlHrtf2QUi5QxzhsNP/ljuC5mF0EW2ipa3kEggTgHwQ3Sg9pSvxWwP8LVFRn4 RW1ng/9iALxrgQLS7qjEc29vTfj0emRskQEXOgS/Ipt0U9b2Ep5l8uHsULH0jNwP BJ5+QPJFETlHd6hqKNjpAsVBrZJ+fY4QgIC8Ig8nkWY4gBLtZ55qkb6zIbOFL4Y= =YVKh -END PGP SIGNATURE- ___ 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
