Re: [UNsolved] was: what does dig +trace do?
In my case, dig is asking for the nameservers of the root-zone and is getting the answer: . IN NS root1 . IN NS root2 etc Next dig is asking for the A-record of root1. And here is the differrence: If I do dig root1 dig is asking exactly this, it is asking for the A-record of root1. And of course I get the correct answer from named. The +trace option does not do this! Instead, the +trace-option is using the searchsuffix in the resolv.conf and is asking for root1.my.search.suffix. and NOT for root1. This is why the +trace option fails every time. No, IMHO, it's a bug in your root zone. Names without dot at end are relative. Change your root zone to say . IN NS root1. . IN NS root2. (with dots appended) and you should be home. No. Sorry: The answer quoted above I typed by hand instead of copypaste and so I forgot the dots at the end. In my root zone there are of course dots at the end of the names. But the +trace option is ignoring these dots. As this bug is only visible if you have your own root-zone and Nameservers directly in this zone, I think there are not many people out there who will stumble over this. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ 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: [UNsolved] was: what does dig +trace do?
dig +trace calls getaddrinfo() and that needs to be able to resolve the hostname (without dots at the end). getaddrinfo() is called so that we don't have to have a full blown iterative resolver in dig. I see. So no way to solve this one in dig itself. The Internet moved from being a flat namespace (names without dots) for hostnames to a heirachical namespace (names with *internal* dots) a 1/4 century ago. http://tools.ietf.org/html/rfc921 Hostnames without dots are now local (e.g. localhost) or need to be qualified (resolv.conf: search). Yes, I heard something about a Internet that was invented some time ago... :-) But seriously: I don't see in the RFC that it is forbidden to have a hostname directly in the root-zone (without a internal dot). -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ 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: Re: about the additional section
Really? Maybe it is not. The recursor receives a response with additional section from a zone and if it finds that the nameservers in the authority section of the response belong to the zone, it will use the glue records in the additonal section, elsewise, it will laungh a new query about address of the nameservers. 2011-09-02 Mingxing 发件人： Doug Barton 发送时间： 2011-09-02 12:50:00 收件人： 风河 抄送： bind-users 主题： Re: about the additional section On 09/01/2011 21:23, 风河 wrote: i just want to make sure about it, The rules for what is and is not included in the ADDITIONAL section are not only not strict, they vary from server to server, and sometimes they vary with different versions of the same server. and will the client resolver use the additional records directly? Ok, now that is a question we can answer. :) Short answer is yes. The longer answer is that the real answer is usually yes, but you really don't need to worry about it. The resolver will do what it's going to do, in the most efficient manner possible. hope this helps, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
question about forward
hi everyone. i've had a question for a long time. when i set my dns server (via bind) as forward only server, i set two destination dns addresses. now, when the first destination dns server is down, will my server still send requests to it? when does my server send request to the second one? thank so much ___ 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: question about forward
On 02.09.11 14:52, JudahXIII wrote: when i set my dns server (via bind) as forward only server, i set two destination dns addresses. do you run bind server as forward only? why not use those forwarders directly? now, when the first destination dns server is down, will my server still send requests to it? because even if it's down, it may come up once. BIND does try ocasionally when does my server send request to the second one? BIND does prefer server that responds faster = when the first comes down, bind should start preferring another one, unless it's unreachable too. -- 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. The only substitute for good manners is fast reflexes. ___ 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: about the additional section
* 风河: i just want to make sure about it, and will the client resolver use the additional records directly? It is somewhat difficult to make correct use of the additional section. For example, Exim tried to do it, but they had to remove the code because it caused spurious mail delivery failures. Nowadays, Exim just sends explicit DNS queries for everything it needs, and no one has complained about that. Even if you manage that, there are other resolvers out there which do not scrub the additional section (unlike BIND 9), so if you use that data, you end up with a DNS poisoning vulnerability. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ 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: Fwd: Re: slow non-cached quries
On Sep 2, 2011 9:48 AM, TMK eng...@gmail.com wrote: -- Forwarded message -- From: Leonard Mills l...@yahoo.com Date: Aug 31, 2011 8:15 PM Subject: Re: slow non-cached quries To: TMK eng...@gmail.com ;; Received 738 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 3133 ms That pretty much is your delay. Look to your intermediate network segments, especially any smart devices. From: TMK eng...@gmail.com To: Mark Andrews ma...@isc.org Cc: bind-us...@isc.org Sent: Wednesday, August 31, 2011 4:44 AM Subject: Re: slow non-cached quries On Tue, Aug 30, 2011 at 9:26 AM, TMK eng...@gmail.com wrote: On Tue, Aug 30, 2011 at 6:55 AM, Mark Andrews ma...@isc.org wrote: In message CAAKgOtgoifGPNEpHtX7++w= cze1dpxx2degq1ppkz18dpuf...@mail.gmail.com, TMK writes: Dears, Probably this the thousand time you get these question. but our bind server have slow response time for the non-cached entries. I have run dig with +trace option and below is the result ; DiG 9.8.0-P2 @127.0.0.1 www.google.com +trace ; (1 server found) ;; global options: +cmd . 2013 IN NS i.root-servers.net. . 2013 IN NS g.root-servers.net. . 2013 IN NS l.root-servers.net. . 2013 IN NS m.root-servers.net. . 2013 IN NS d.root-servers.net. . 2013 IN NS b.root-servers.net. . 2013 IN NS k.root-servers.net. . 2013 IN NS j.root-servers.net. . 2013 IN NS c.root-servers.net. . 2013 IN NS a.root-servers.net. . 2013 IN NS h.root-servers.net. . 2013 IN NS e.root-servers.net. . 2013 IN NS f.root-servers.net. ;; Received 228 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. ;; Received 492 bytes from 199.7.83.42#53(l.root-servers.net) in 175 ms google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. ;; Received 168 bytes from 192.5.6.30#53(a.gtld-servers.net) in 250 ms www.google.com. 604800 IN CNAME www.l.google.com. www.l.google.com. 300 IN A 209.85.148.106 www.l.google.com. 300 IN A 209.85.148.104 www.l.google.com. 300 IN A 209.85.148.147 www.l.google.com. 300 IN A 209.85.148.99 www.l.google.com. 300 IN A 209.85.148.103 www.l.google.com. 300 IN A 209.85.148.105 ;; Received 148 bytes from 216.239.34.10#53(ns2.google.com) in 225 ms we are running bind version BIND 9.8.0-P2 on CentOS release 5.6 (Final) the process is running as mutlithreaded and consuming total of 60% of cpu utilization. do we have network issue or performance bottleneck. engtmk To better match what a nameserver does, what does dig +trace +dnssec show? dig +dnssec +trace www.google.com Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org Hi Mark, here is the output of the command dig @127.0.0.1 www.google.com +trace +dnssec ; DiG 9.8.0-P2 @127.0.0.1 www.google.com +trace +dnssec ; (1 server found) ;; global options: +cmd . 360 IN NS F.ROOT-SERVERS.NET. . 360 IN NS A.ROOT-SERVERS.NET. . 360 IN NS C.ROOT-SERVERS.NET. . 360 IN NS J.ROOT-SERVERS.NET. . 360 IN NS B.ROOT-SERVERS.NET. . 360 IN NS K.ROOT-SERVERS.NET. . 360 IN NS E.ROOT-SERVERS.NET. . 360 IN NS D.ROOT-SERVERS.NET. . 360 IN NS G.ROOT-SERVERS.NET. . 360 IN NS L.ROOT-SERVERS.NET. . 360 IN NS M.ROOT-SERVERS.NET. . 360 IN NS I.ROOT-SERVERS.NET. . 360 IN NS H.ROOT-SERVERS.NET. ;; Received 255 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms com.172800 IN NS f.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS
Re: [UNsolved] was: what does dig +trace do?
Hi Tom, At 23:42 01-09-2011, Tom Schmitt wrote: But seriously: I don't see in the RFC that it is forbidden to have a hostname directly in the root-zone (without a internal dot). From RFC 921: The names are being changed from simple names, or globally unique strings, to structured names, where each component name is unique only with respect to the superior component name. Because of the growth of the Internet, structured names (or domain style names) have been introduced. Each element of the structured name will be a character string (with the same constraints that previously applied to the simple names). The elements (or components) of the structured names are separated with periods, and the elements are written from the most specific on the left to the most general on the right. The above discusses about hierarchical names. It is about how the system was designed to work and not about what is forbidden. The syntax of a legal Internet host name was specified in RFC-952, updated by RFC 1123. Regards, -sm ___ 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: Fwd: Re: slow non-cached quries
From: Leonard Mills l...@yahoo.com Date: Aug 31, 2011 8:15 PM Subject: Re: slow non-cached quries To: TMK eng...@gmail.com ;; Received 738 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 3133 ms That pretty much is your delay. Look to your intermediate network segments, especially any smart devices. On 02.09.11 10:05, TMK wrote: Would creating master cash DNS and configure all other cache DNS to only forward requests to it would solve this issue that could make things faster but also more complicated. Is there any reason to use more caches instead of two (to have working DNS when one fails) and using those from anywhere? -- 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. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod ___ 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: what does dig +trace do?
On 31/08/11 16:36, Tom Schmitt wrote: What strikes me as odd is that the first query does return 4 (internal) root servers, but no glue records ? I have no idea why this is this way. Because +trace only displays the answer section of the responses by default. Try dig +trace +additional. Hi Chris, you are right, thank you. With this I see the glue records: ; DiG 9.8.0-P4 +trace example.com ;; global options: +cmd . 10800 IN NS root1. . 10800 IN NS root2. . 10800 IN NS root3. . 10800 IN NS root4. root1. 10800 IN A 10.111.111.111 root2. 10800 IN A 10.111.112.112 root3. 10800 IN A 10.111.113.113 root4. 10800 IN A 10.111.114.114 ;; Received 159 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms ;; connection timed out; no servers could be reached The main problem is still the same though. The trace option fails with a timeout. Even thought I'm operating on the shell of one of the root-servers itself (so there is not much network in between to cause trouble). What you will see when you trace this with wireshark is not quite what you'd expect. dig is following the referral at each step, but it's not using the glue provided. For each referral, it issues a query (following resolv.conf's configuration to chose the server to ask) for the address of one of the servers returned before then directly querying it for the name that's being looked up. This intermediate lookup doesn't appear in the dig +trace output. Does that shed any more light on what might be happening in your case? ___ 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: forward question
On 09/01/2011 11:53 PM, Vbvbrj wrote: On 01.09.2011 19:01, CT wrote: so did you end up setting up a slave zone (for the internal AD DNS) on your public DNS server ? No, for now I just left the AD DNS (Microsoft DNS) instead of BIND. I didn't have time to move all DNS servers to BIND and make them primary/slave for locale zone. ___ 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 I am still experimenting , if I find something out , I will post back.. best CT ___ 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
