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 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
9.10.2-P2 not receiving/logging inbound queries.
Hi binders, What would cause a query to not show in any logs on BIND 9.10.2-p2, seems 9.10.2-p2 is not receiving Queries tcpdump shows the query's getting in but bind does not show the same incoming query in its logs, Therefore no response is returned ID8 shows this. Load on dns server is low with ~600 r-clients. The dummyrecordtest is a local hosted (test/canary) record on the recursive server. 122.150.6.5 is a recursive server with a virtual eth1:1 nic in CeonOS64bit on VMware with setting of responses-per-second 0; Running bind 9.9.7 does not show the same issues of missed inbound query's not being received by bind. Could this be some sort of socket/binding issue in bind9.10.2?, Is there something I need to do in the bind config? Sequence of bind logs and tcpdump were matched on time and clients source port. #Tcpdump log # ID1 13:07:39.567250 IP 122.150.6.3.7397 > 122.150.6.5.53: 26437+ A? dummyrecordtest. (50) ID1 13:07:39.567542 IP 122.150.6.5.53 > 122.150.6.3.7397: 26437* 1/0/0 A 254.254.254.254 (66) ID2 13:07:50.633388 IP 122.150.6.2.46493 > 122.150.6.5.53: 26437+ A? dummyrecordtest. (50) ID2 13:07:50.633554 IP 122.150.6.5.53 > 122.150.6.2.46493: 26437* 1/0/0 A 254.254.254.254 (66) ID3 13:07:54.496787 IP 122.150.6.3.55067 > 122.150.6.5.53: 26437+ A? dummyrecordtest. (50) ID3 13:07:54.497113 IP 122.150.6.5.53 > 122.150.6.3.55067: 26437* 1/0/0 A 254.254.254.254 (66) ID4 13:08:05.562151 IP 122.150.6.2.43627 > 122.150.6.5.53: 26437+ A? dummyrecordtest. (50) ID4 13:08:05.562309 IP 122.150.6.5.53 > 122.150.6.2.43627: 26437* 1/0/0 A 254.254.254.254 (66) ID5 13:08:09.523669 IP 122.150.6.3.42231 > 122.150.6.5.53: 26437+ A? dummyrecordtest. (50) ID5 13:08:09.523787 IP 122.150.6.5.53 > 122.150.6.3.42231: 26437* 1/0/0 A 254.254.254.254 (66) ID6 13:08:20.588682 IP 122.150.6.2.45139 > 122.150.6.5.53: 26437+ A? dummyrecordtest. (50) ID6 13:08:20.589284 IP 122.150.6.5.53 > 122.150.6.2.45139: 26437* 1/0/0 A 254.254.254.254 (66) ID7 13:08:24.545489 IP 122.150.6.3.45318 > 122.150.6.5.53: 26437+ A? dummyrecordtest. (50) ID7 13:08:24.548876 IP 122.150.6.5.53 > 122.150.6.3.45318: 26437* 1/0/0 A 254.254.254.254 (66) >> We get the packet coming in to the host but nothing logged into bind as show in queylog below >> ID8 13:08:35.620586 IP 122.150.6.2.59437 > 122.150.6.5.53: 26437+ A? dummyrecordtest. (50) ID9 13:08:39.577113 IP 122.150.6.3.43186 > 122.150.6.5.53: 26437+ A? dummyrecordtest. (50) ID9 13:08:39.589492 IP 122.150.6.5.53 > 122.150.6.3.43186: 26437* 1/0/0 A 254.254.254.254 (66) #Bind query log # ID1 09-Jul-2015 13:07:39.567 queries: info: client 122.150.6.3#7397 (dummyrecordtest): view resolver: query: dummyrecordtest IN A + (122.150.6.5) ID2 09-Jul-2015 13:07:50.633 queries: info: client 122.150.6.2#46493 (dummyrecordtest): view resolver: query: dummyrecordtest IN A + (122.150.6.5) ID3 09-Jul-2015 13:07:54.496 queries: info: client 122.150.6.3#55067 (dummyrecordtest): view resolver: query: dummyrecordtest IN A + (122.150.6.5) ID4 09-Jul-2015 13:08:05.562 queries: info: client 122.150.6.2#43627 (dummyrecordtest): view resolver: query: dummyrecordtest IN A + (122.150.6.5) ID5 09-Jul-2015 13:08:09.523 queries: info: client 122.150.6.3#42231 (dummyrecordtest): view resolver: query: dummyrecordtest IN A + (122.150.6.5) ID6 09-Jul-2015 13:08:20.588 queries: info: client 122.150.6.2#45139 (dummyrecordtest): view resolver: query: dummyrecordtest IN A + (122.150.6.5) ID7 09-Jul-2015 13:08:24.548 queries: info: client 122.150.6.3#45318 (dummyrecordtest): view resolver: query: dummyrecordtest IN A + (122.150.6.5) >> ID8 No query received into bind.??? ID9 09-Jul-2015 13:08:39.589 queries: info: client 122.150.6.3#43186 (dummyrecordtest): view resolver: query: dummyrecordtest IN A + (122.150.6.5) Thanks Neil ___ 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 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 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: bind 9.10 fallback to tcp
In message <559dbe9b.8000...@lancaster.ac.uk>, Graham Clinch writes: > Hi Carl, > > > I have a client with 9.10.2-P1-RedHat-9.10.2-2.P1.fc22 on Fedora 22, on > > a machine with a pppoe link with an mtu of 1492. The routers seem to be > > properly fragmenting udp - it can receive large packets such as > > > > dig www.byington.org +dnssec +bufsiz=4000 +notcp @205.147.40.34 > > > > which says: > > > > ;; MSG SIZE rcvd: 3790 > > > > However, a tcpdump for tcp port 53 shows a lot of traffic. In > > particular, > > > > rndc flushtree novell.com > > dig www.novell.com @localhost > > > > shows some tcp traffic to the .com servers. How does one isolate the > > query or server that is causing that fallback to tcp? > > We saw a similar jump in TCP traffic with 'cold' (not much in the cache) > resolvers after switching from 9.9 to 9.10. The cause seems to be a > change to the way edns sizes are advertised to unknown servers. The > gory details are in the ARM for the 'edns-udp-size' option, but here's a > simplified version: > > In 9.9, edns-udp-size is advertised initially, and only after problems > is it reduced to 512 bytes. > In 9.10, edns-udp-size sets the *maximum* size that could be advertised, > but the first query uses 512 and then it grows up as successes occur. > > The 'Address database dump' section of a cache dump (rndc dumpdb -cache) > has 'udpsize' notes along with edns success rates: > > ; [edns success/4096 timeout/1432 timeout/1232 timeout/512 timeout] > ; [plain success/timeout] > ; 148.88.65.105 [srtt 1489] [flags 6000] [edns 50/0/0/0/0] [plain > 0/0] [udpsize 1757] [ttl 173] 50 successful EDNS queries. No timeouts with a advertised EDNS buffersize of 4096 No timeouts with a advertised EDNS buffersize of 1432 (ethernet - IPv4+IPv6+UDP headers to allow for 4/6 encapsulation) No timeouts with a advertised EDNS buffersize of 1232 (IPv6 network - IPv6+UDP headers) No timeouts with a advertised EDNS buffersize of 512 (Stupid firewall) The largest UDP response seen had a size of 1757 bytes. If you timeout on a 512 byte advertised size it counts against all 4 counters If you timeout on a 1232 byte advertised size it counts against first 3 counters If you timeout on a 1432 byte advertised size it counts against first 2 counters If you timeout on a 4096 byte advertised size it only counts against the 4096 counter All counters shift right (divide by 2) when upper bit is set on one of them which make the self correcting. The timeout counts decide which EDNS udpsize is advertised after the first query or whether to shift to plain DNS. The known udp response size is a minimum even if there are enough timeouts to otherwise go to a smaller size. Plain DNS timeouts clear EDNS timeouts as they then be false positives. > though I'm not clear what udpsize is really reflecting here since it has > many different values (not just 512, 1232, 1432 & 4096, as I would > expect from the ARM). > > We see a freshly restarted (validating) 9.10 resolver need to make many > TCP connections before returning its first answer, but things settle > after it's got comfortable using larger edns sizes with the root & tld > servers. > > Graham > ___ > 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
Re: dig @server foobar +trace +recurse
Mark Andrews 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
Re: bind 9.10 fallback to tcp
Hi Carl, I have a client with 9.10.2-P1-RedHat-9.10.2-2.P1.fc22 on Fedora 22, on a machine with a pppoe link with an mtu of 1492. The routers seem to be properly fragmenting udp - it can receive large packets such as dig www.byington.org +dnssec +bufsiz=4000 +notcp @205.147.40.34 which says: ;; MSG SIZE rcvd: 3790 However, a tcpdump for tcp port 53 shows a lot of traffic. In particular, rndc flushtree novell.com dig www.novell.com @localhost shows some tcp traffic to the .com servers. How does one isolate the query or server that is causing that fallback to tcp? We saw a similar jump in TCP traffic with 'cold' (not much in the cache) resolvers after switching from 9.9 to 9.10. The cause seems to be a change to the way edns sizes are advertised to unknown servers. The gory details are in the ARM for the 'edns-udp-size' option, but here's a simplified version: In 9.9, edns-udp-size is advertised initially, and only after problems is it reduced to 512 bytes. In 9.10, edns-udp-size sets the *maximum* size that could be advertised, but the first query uses 512 and then it grows up as successes occur. The 'Address database dump' section of a cache dump (rndc dumpdb -cache) has 'udpsize' notes along with edns success rates: ; [edns success/4096 timeout/1432 timeout/1232 timeout/512 timeout] ; [plain success/timeout] ; 148.88.65.105 [srtt 1489] [flags 6000] [edns 50/0/0/0/0] [plain 0/0] [udpsize 1757] [ttl 173] though I'm not clear what udpsize is really reflecting here since it has many different values (not just 512, 1232, 1432 & 4096, as I would expect from the ARM). We see a freshly restarted (validating) 9.10 resolver need to make many TCP connections before returning its first answer, but things settle after it's got comfortable using larger edns sizes with the root & tld servers. Graham ___ 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: Reciving Timeout from DNS Server for a zone file Not present in named.conf.
1) status REFUSED - server with recursion turned off. with or without +norecurse on the dig command. 2) status NXDOMAIN - server with recursion turned on with or without +norecurse on the dig command (and access to the internet in my case) 3) status may be NOERROR depending on if a forwarder can resolve that zone. I'm on ubuntu with bind 9.9.5 (current level of bind9 from ubuntu 14.04.02 LTS) 4) Forgive my being a bit naive but isn't it e164.arpa. instead of e164.ld. ? l don't recall ld being a valid TLD. (That might affect your response) 5) YMMV with other Linux distros or other unixes because of differing bind versions (but probably not) Regards, Bob >Message: 5 >Date: Wed, 08 Jul 2015 12:38:20 -0400 >From: Barry Margolin >To: comp-protocols-dns-b...@isc.org >Subject: Re: Receiving Timeout from DNS Server for a zone file Not > present in named.conf >Message-ID: > >In article , >Harshith Mulky wrote: > >> Hello, >> I have a query here, >> I have named.conf configured But I do not have zone file configured for a >> domain name as "e164.ld" >> I am sending out a query asdig @ >> 8.7.9.8.6.0.3.6.6.9.1.e164.ld. NAPTR >> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>> >> 8.7.9.8.6.0.3.6.6.9.1.e164.ld. NAPTR;; global options: +cmd;; connection >> timed out; no servers could be reached >> I am receiving a Connection TimeOut message >> Should not i be receiving a NXDOMAIN response from DNS Server? >> What are the scenarios, I will be receiving a Timeout, or a NXDOMAIN, or a >> REFUSED from DNS Server >> I have Installed BIND on RHEL system! Would the reposnes be different in >> different servers like Linux, Solaris, CENTOS? > >Since you didn't use the +norecurse option, the server will try to make >a recursive query for you (assuming you're in its allow-recursion access >list). If dig times out before that completes, you'll get a timeout >error. > >-- >Barry Margolin >Arlington, MA ___ 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
Single Bind (nameserver) for multiple domains (zones)
Hi:
Up until this point I have configured bind to serve a single domain (zone)
and the bind server itself (the nameserver) lived on that domain. As an
example the server was ns.domain1.com and was the authoritative server for
domain1.com.
I am in a situation where I need to configure bind to service multiple
domains and have run into a problem.
My situation as such. The bind server itself sits on domain1.com (which is
actually the company primary domain) and as such the resolv.conf points to
the company DNS servers.
I then configure a zone (ie: devdomain.com) with the following zone file:
# devdomain.com
zone "devdomain.com" {
type master;
file "/var/named/dynamic/db.devdomain.com";
update-policy {
grant rndc-key zonesub ANY;
};
};
$TTL 10800 ; 3 hours
@ IN SOA usc1ks250.domain1.com. vcc...@domain1.com. (
42 ; serial
86400 ; refresh (1 day)
3600; retry (1 hour)
604800 ; expire (1 week)
3600; minimum (1 hour)
);
IN NS usc1ks250.domain1.com.
The problem I am running into is if I query that domain (devdomain.com) for
say test1.devdomain.com (which isn't present in the zone file) it ends up
query test1.devdomain.com.domain1.com. And our company domain (domain1 in
this example) returns a default IP for anything queried against it. Which I
don't want.
The search path in the resolv.conf on the bind server has domain1.com so it
appears bind couldn't find the result (since it wasn't in the zone file)
and then just followed the path the OS would do to lookup records (append
the search path and try those).
Any assistance would be appreciated.
Thanks
___
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
bind 9.10 fallback to tcp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a client with 9.10.2-P1-RedHat-9.10.2-2.P1.fc22 on Fedora 22, on a machine with a pppoe link with an mtu of 1492. The routers seem to be properly fragmenting udp - it can receive large packets such as dig www.byington.org +dnssec +bufsiz=4000 +notcp @205.147.40.34 which says: ;; MSG SIZE rcvd: 3790 However, a tcpdump for tcp port 53 shows a lot of traffic. In particular, rndc flushtree novell.com dig www.novell.com @localhost shows some tcp traffic to the .com servers. How does one isolate the query or server that is causing that fallback to tcp? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlWds+MACgkQL6j7milTFsGrfQCbBnfCydmoZOR7GyJyRu+8eu5m AQsAn3HfPcOBU4BhtVhkgb4slQq3lUEX =3RsN -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
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: dynamic zone file "style"
On Wed, Jul 08, 2015 at 05:38:59PM +0200, stefan.las...@t-systems.com wrote: > Mark Andrews: > >> By default, the bind daemon uses the "relative" style (or > >> something similar) when writing dynamic zone files to disk. > >> Guess what... all those "$ORIGIN" lines make it more difficult > >> to parse the f ile by a separate script... ;) > > > Truly, you don't wan't to be reading master files. If you need > > the content of the zone transfer it from the server. Doing that > > you will always get the latest content and don't have to worry > > about merging the journal etc. > > I understand your point. But for the script, I'll need the content > of all my zones in all views. Zone transfers won't be very > efficient for that. I am not sure how you figure this. I think a $ dig @127.0.0.1 example.com axfr will be far MORE efficient than a $ cat /path/to/zonefile/for/example.com In the former you are writing/reading an UDP socket on localhost, receiving data which is in named's memory. In the latter you are opening and reading from a file on disk, which, as noted by Mark, might not contain all the data you need. > Until now I have experimented with the "-j" option from > named-compilezone to take care of the journals. Though, I'm not > sure this is much more efficient. > Another option I evaluated was "rndc sync", but it isn't available > on bind 9.8 I suppose you know this already, but 9.8 is in EOL status. > But your reply made me think of yet another solution. "rndc dumpdb > -zones" gives me the latest content of all zones of all views in a > single file. And, luckily, it uses the "full" style :) So this > should be fine for me. > > But before I try to re-invent the wheel: > Does anyone know if there is already a parser for multiple > zone_files/zone_dumps/zone_transfers? I'm trying to filter all DNS > records that are related to a given host/ip? -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ 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: Receiving Timeout from DNS Server for a zone file Not present in named.conf
Does this nameserver have direct access to the Internet root nameservers? If not, does it have forwarding enabled? If the answer to both of those is "no", then a timeout is the expected behavior; that's what you get when you try to query nameservers that you can't reach. - Kevin From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Harshith Mulky Sent: Wednesday, July 08, 2015 6:17 AM To: bind-users@lists.isc.org Subject: Receiving Timeout from DNS Server for a zone file Not present in named.conf Hello, I have a query here, I have named.conf configured But I do not have zone file configured for a domain name as "e164.ld" I am sending out a query as dig @ 8.7.9.8.6.0.3.6.6.9.1.e164.ld. NAPTR ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>> 8.7.9.8.6.0.3.6.6.9.1.e164.ld. NAPTR ;; global options: +cmd ;; connection timed out; no servers could be reached I am receiving a Connection TimeOut message Should not i be receiving a NXDOMAIN response from DNS Server? What are the scenarios, I will be receiving a Timeout, or a NXDOMAIN, or a REFUSED from DNS Server I have Installed BIND on RHEL system! Would the reposnes be different in different servers like Linux, Solaris, CENTOS? ___ 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: Receiving Timeout from DNS Server for a zone file Not present in named.conf
In article , Harshith Mulky wrote: > Hello, > I have a query here, > I have named.conf configured But I do not have zone file configured for a > domain name as "e164.ld" > I am sending out a query asdig @ > 8.7.9.8.6.0.3.6.6.9.1.e164.ld. NAPTR > ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>> > 8.7.9.8.6.0.3.6.6.9.1.e164.ld. NAPTR;; global options: +cmd;; connection > timed out; no servers could be reached > I am receiving a Connection TimeOut message > Should not i be receiving a NXDOMAIN response from DNS Server? > What are the scenarios, I will be receiving a Timeout, or a NXDOMAIN, or a > REFUSED from DNS Server > I have Installed BIND on RHEL system! Would the reposnes be different in > different servers like Linux, Solaris, CENTOS? > Since you didn't use the +norecurse option, the server will try to make a recursive query for you (assuming you're in its allow-recursion access list). If dig times out before that completes, you'll get a timeout error. -- Barry Margolin Arlington, MA ___ 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: dynamic zone file "style"
It's possible to use TSIG keys to match views. So you could do the zone transfers with different TSIG keys and get different versions of the same zone. - Kevin -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of stefan.las...@t-systems.com Sent: Wednesday, July 08, 2015 11:39 AM To: ma...@isc.org Cc: bind-us...@isc.org Subject: AW: dynamic zone file "style" >> By default, the bind daemon uses the "relative" style (or something >> similar) when writing dynamic zone files to disk. >> Guess what... all those "$ORIGIN" lines make it more difficult to >> parse the f ile by a separate script... ;) > Truly, you don't wan't to be reading master files. If you need the > content of the zone transfer it from the server. Doing that you will always > get the latest content and don't have to worry about merging the journal etc. I understand your point. But for the script, I'll need the content of all my zones in all views. Zone transfers won't be very efficient for that. Until now I have experimented with the "-j" option from named-compilezone to take care of the journals. Though, I'm not sure this is much more efficient. Another option I evaluated was "rndc sync", but it isn't available on bind 9.8 But your reply made me think of yet another solution. "rndc dumpdb -zones" gives me the latest content of all zones of all views in a single file. And, luckily, it uses the "full" style :) So this should be fine for me. But before I try to re-invent the wheel: Does anyone know if there is already a parser for multiple zone_files/zone_dumps/zone_transfers? I'm trying to filter all DNS records that are related to a given host/ip? Thanks and Regards, Stefan ___ 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 ___ 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
AW: dynamic zone file "style"
>> By default, the bind daemon uses the "relative" style (or something >> similar) when writing dynamic zone files to disk. >> Guess what... all those "$ORIGIN" lines make it more difficult to >> parse the f ile by a separate script... ;) > Truly, you don't wan't to be reading master files. If you need the content > of the zone transfer it from the server. Doing that you will always get the > latest content and don't have to worry about > merging the journal etc. I understand your point. But for the script, I'll need the content of all my zones in all views. Zone transfers won't be very efficient for that. Until now I have experimented with the "-j" option from named-compilezone to take care of the journals. Though, I'm not sure this is much more efficient. Another option I evaluated was "rndc sync", but it isn't available on bind 9.8 But your reply made me think of yet another solution. "rndc dumpdb -zones" gives me the latest content of all zones of all views in a single file. And, luckily, it uses the "full" style :) So this should be fine for me. But before I try to re-invent the wheel: Does anyone know if there is already a parser for multiple zone_files/zone_dumps/zone_transfers? I'm trying to filter all DNS records that are related to a given host/ip? Thanks and Regards, Stefan ___ 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: dynamic zone file "style"
In message , stefan.las...@t-systems.com writes: > Hi, > > the "named-compilezone" tool can output zone files in two different styles (u > sing the -s option): > "full" (suitable for processing by a separate script) > "relative" (more human-readable) > > By default, the bind daemon uses the "relative" style (or something similar) > when writing dynamic zone files to disk. > Guess what... all those "$ORIGIN" lines make it more difficult to parse the f > ile by a separate script... ;) Truly, you don't wan't to be reading master files. If you need the content of the zone transfer it from the server. Doing that you will always get the latest content and don't have to worry about merging the journal etc. > Is there a way to change this into "full" style? I haven't found anything in > the doc's... > > I know I can use "named-compilezone -j -s full /path/to/zonefile" to re-style > the bind zones into a temp file, before parsing it. I'm just wondering if th > is is really necessary... > (I'm using RHEL bind 9.8.2) > > Regards, > Stefan > > ___ > 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
dynamic zone file "style"
Hi, the "named-compilezone" tool can output zone files in two different styles (using the -s option): "full" (suitable for processing by a separate script) "relative" (more human-readable) By default, the bind daemon uses the "relative" style (or something similar) when writing dynamic zone files to disk. Guess what... all those "$ORIGIN" lines make it more difficult to parse the file by a separate script... ;) Is there a way to change this into "full" style? I haven't found anything in the doc's... I know I can use "named-compilezone -j -s full /path/to/zonefile" to re-style the bind zones into a temp file, before parsing it. I'm just wondering if this is really necessary... (I'm using RHEL bind 9.8.2) Regards, Stefan ___ 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
Receiving Timeout from DNS Server for a zone file Not present in named.conf
Hello, I have a query here, I have named.conf configured But I do not have zone file configured for a domain name as "e164.ld" I am sending out a query asdig @ 8.7.9.8.6.0.3.6.6.9.1.e164.ld. NAPTR ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>> 8.7.9.8.6.0.3.6.6.9.1.e164.ld. NAPTR;; global options: +cmd;; connection timed out; no servers could be reached I am receiving a Connection TimeOut message Should not i be receiving a NXDOMAIN response from DNS Server? What are the scenarios, I will be receiving a Timeout, or a NXDOMAIN, or a REFUSED from DNS Server I have Installed BIND on RHEL system! Would the reposnes be different in different servers like Linux, Solaris, CENTOS? ___ 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
